通信模型要了解物联网产品的难点，致命点，首先要了解物联网产品的模型和传统无状态互联网产品模型的本质区别。 传统无状态互联网交互模型众所周知，传统的Web应用是采用HTTP进行通信的。 而http是无状态的，客户端发送请求到后端，后端根据请求涵义把结果返回给前端。后端不保存前端的状态。后端不能主动的向前端发送消息。 后端是被动处理消息的。 无状态的后端通信模型，采用k8s等做负载均衡是对开发代码无侵入性的， 在不进行代码修改的情况下，是可以完成弹性扩展，可以做负载均衡的。 所谓的弹性扩展的能力：就是系统根据业务并发量自动启动或者停止运行实例，而满足客户并发量递增或者递减的能力。 所谓的负载均衡的能力：就是当有多个实例并发处理相同的业务时，系统根据预设规则算法，动态的保持多个实例之间的处理平衡。而不是把所有的请求都挤压到某个节点，导致节点崩溃的能力。 而基于HTTP的 request-response 模型很容易做到弹性扩展和动态扩容。换句话说，当后端节点不能满足现有的并发请求时， 稍加改造，就可以完成动态扩容。在技术上毫无难度。 以下图为基于http通信的模型  物联网的通信模型物联网的通信模型要比传统Web通信模型复杂的多。 物联网通信模型是有状态模型。 设备与用户，设备与后端，后端与用户均为全双工通信。 换句话说，任意一方都可以主动的给另一方发送数据。 除此之外， 物联网产品往往是一对多的关系， 一个用户要同时管理多个相同类型或者不同类型的设备。 并且与他们通信，或者发布消息。 综合以上，物联网系统要比传统Web产品的通信设计难度要大很多， 这也是为什么很多做互联网产品的团队，即使有很多的成功经验，依然难以胜任物联网产品开发的根本原因。 如下图为理想的物联网通信系统模型：  如上图所示， 我们画出了物联网系统的理想模型，但凡所有的用户如果能够把系统的模型做成如上模型，基本上系统的通信以及满足未来设备无限扩展，就不会有问题。系统通信就稳如磐石。但是这样的架构他属于基础设施。对于小米这样体量的公司，毫无疑问，系统也是这样设计的。 因为他们有强大的团队和金钱支撑。 对于小微企业，或者一般企业，则很少会考虑在基础设施上投入。 一开始就冲着业务而去的。 也不是任何团队都有能力能够把系统做成这样的模型。 大多数创业公司，一开始就有业务支撑，财务指标以及市场客户迫使他们短时间内交货。而无暇顾及系统的稳定性。最后卖出去的产品的问题层出不绝。随着新的业务的增加，系统不能胜任，而导致创业公司被撑死。 以上模型重点解决3个问题。
以上问题3也不是没有突破口， 那就是MQTT5.0协议的诞生，MQTT5.0 添加了一个特性“共享订阅”就是后端的负载均衡问题，只是为客户的业务系统提供了可以支持负载均衡的能力，至于客户系统到底如何设计，才能做到动态扩容，负载均衡。这就需要各个公司的架构师们发挥自己的才能进行系统的设计。 为此，云晶根据自己多年的经验设计出了一套满足上述要求的通信协议， 那就是 jiot-mqtts协议。 以上三个难点中，难点1不是企业发展过程中首要要解决的问题， 对于mqtt-broker只是转发器，转发数据，并不承担重量级业务处理。单节点，主从备份，扛起10万以内的设备连接还是没有问题的，（或者采购云服务厂商的mqtt-broker）就可以得到满足。 而系统的业务集群（如上图黄色部分）如果没有被设计成集群模式。那么单体架构的处理能力很快就到达了瓶颈。 会造成系统经常挂掉， 业务数据丢失，或者处理延时大缓慢等情况。 |
|
|
来自： 山峰云绕 > 《ARM物联网嵌入式实时即时芯片磁盘操作系统》
