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