平台架构
# 架构
别让技术架构成为负担,合适的才是最好的!💪
# 🏗 单体架构:一台机器,搞定一切!
由单台机器就足以支撑其良好运行的系统,单体不仅易于开发、易于测试、易于部署,且由于系统中各个功能、模块、方法的调用过程都是进程内调用,不会发生进程间通信。
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 自动化部署。
# 🎯 结语
“世上最美的架构,不是最复杂的,而是最适合需求的。” —— 架构师箴言
单体架构和微服务架构各有千秋,没有绝对的好坏,只有合适不合适:
- 项目小?用单体,快、稳、简单。
- 业务复杂?拆成微服务,灵活、易扩展。