平台架构
# 架构
别让技术架构成为负担，合适的才是最好的！💪
# 🏗 单体架构：一台机器，搞定一切！
由单台机器就足以支撑其良好运行的系统，单体不仅易于开发、易于测试、易于部署，且由于系统中各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信。
Monolithic Application
Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform.
单体意味着自包含。单体应用描述了一种由同一技术平台的不同组件构成的单层软件。
# 📡 4G物联：单体架构的完美适配
要求：
- 服务器作为服务端，开放端口，等待客户端连接。
- 集中器作为客户端，连接服务器后，把数据上传，再由服务器透传给电力主站。
流程图如下所示：
这种项目直接使用单体架构就能满足条件。
# 🛰 北斗短报文：加个挑战，但依然单体
这一种架构其实和第一种没什么区别。单体架构就能满足条件。
北斗短报文物联和4G方式本质上差不多，依然可以用单体架构。但问题是——北斗通信方式自带两个限制：
- 单次数据量 < 80 字节
- 两次通信间隔 > 60 秒
📌 挑战： 如果数据量大，就得拆包；如果丢包了，还得有重传机制。虽然这些在架构上没啥变化，但流程设计上要保证数据最终能完整送达。
基于以上2个硬性条件限制，当使用其传输大容量报文时，需要考虑丢包补偿，超时重试机制。这个在架构上没什么特别的体现，主要是流程异常时还能够完成整个数据采集的流程。
# ⚙️ 微服务架构：拆分后更灵活！
微服务和单体架构最大的不同是：每个功能模块都是独立的小服务，它们可以用不同的技术栈开发，互相之间通过 API 通信。
微服务架构（Microservices）
微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
🤔 为什么从单体转向微服务？ 在业务不断扩展时，单体架构就不太好用了：
- 扩展难：每次改动一个功能，都可能影响整个系统。
- 维护难：代码越来越庞大，开发效率下降。
- 升级痛：版本更新可能会导致整个系统重启，影响用户体验。 所以，我们考虑把系统拆分成多个微服务。
# 🔗 设备接入：网关来帮忙！
很多物联网设备要么不能联网，要么联网需求不强，这时候可以借助网关：
- 设备通过 485 / 串口 / 无线 连接到网关。
- 网关负责和云平台通信，上传数据，接收指令。
# 🏢 平台层拆分
在微服务架构下，我们把平台拆成多个独立层级，每个层级各司其职：
| 层级 | 功能 |
|---|---|
| 连接层 | 设备数据上传、指令下发 |
| 中间件层 | 削峰，把突发的大量数据暂存到 Kafka 等消息队列 |
| 解析层 | 处理 Kafka 消息，解析数据 |
| 数据处理层 | 数据清洗、补偿、批处理 |
| 数据流转层 | 把数据推送给 Web、第三方平台、微信等 |
| 呈现层 | 提供 RESTful API，供运维人员排查系统 |
| 持久层 | 数据存储（NoSQL、时序数据库） |
| 业务层 | 设备管理、故障报警、消息通知等 |
# 💡 微服务架构的挑战
虽然微服务听起来很香，但拆分之后也带来了一些问题：
- ⚠️ 数据一致性 分布式系统数据状态同步是个难点，比如：设备 A 上传数据 -> 连接层收到 -> 解析层消费 -> 业务层处理如果某个环节失败了，怎么补救？
💡 方案：采用分布式事务，比如 SAGA、补偿机制等。
- ⚠️ 监控 & 运维
微服务越多，出问题时排查就越复杂。Kafka、Redis、MongoDB、服务器……都需要实时监控。
💡 方案：搭建监控系统，比如 Prometheus + Grafana，实时监测服务健康状态。
- ⚠️ 分布式日志 & 追踪 传统单体架构，一个日志文件就够了。微服务架构，每个服务都有自己的日志，出问题时得靠分布式日志系统来排查。
💡 方案：使用ELK（Elasticsearch + Logstash + Kibana）或 Grafana Loki 进行链路追踪。
- ⚠️ CI/CD 自动化部署 微服务=持续开发+持续集成（CI/CD），如果手动部署，光升级就累死了。
💡 方案：Docker + Kubernetes + Jenkins 自动化部署。
# 🎯 结语
“世上最美的架构，不是最复杂的，而是最适合需求的。” —— 架构师箴言
单体架构和微服务架构各有千秋，没有绝对的好坏，只有合适不合适：
- 项目小？用单体，快、稳、简单。
- 业务复杂？拆成微服务，灵活、易扩展。