目标

一个开源的，强扩展性强，开箱即用的，高性能的，用户友好的通用物联网后台平台系统。

组件

1. 网关
   • 概述
     网关主要作用有2个 a:设备寻址. b:协议转换。
     其中协议转化又包括2方向:
     Event: 从设备上报的信息的抽象成一个事件（event)，包括产生事件的对象，事件类型，事件时间，事件参数等信息。
     Cmd: 对于从后端向设备发送命令抽象为指令，也抽象成一个remote call. http api调用,可以用contract（open api)描述接口，主要包括参数和返回。 多个cmd可以组合成一个复合cmd.
   • 关键点
     性能, NOI, 多实例部署。 可用性， 多实例部署，故障自动切换和恢复。 不停机可扩充协议。 QOS。
2. 事件和指令队列
   • 概述 缓存事件，提供事件顺序和持久化。接受后端指令产生非原始事件（可带有定时器）。缓存，持久化指令。cmd有状态，（缓存中，发送完毕，已返回）
   • 关键点 使用时序数据库持久化，事件和指令。 需要在事务性，性能，可用性之间找平衡。
3. 控制器
   • 自动控制器（规则引擎）。按规则链，设计。每个规则，由一个事件触发。编程的范式如下： step1.事件的参数的进行运算 step2.用事件的参数+一个查询模版对时序数据库的查询。 step3 对时序数据库查询的结果进行运算。 通过前3步中的参数和结果生成cmd的参数，发起一次cmd的调用。
   • 手动控制器。（页面控制）。step1用户输入参数 step2时序数据库查询结果(可选) step3组合1，2生成Cmd的参数。
   • 报警器
4. 页面（前端） 一个前端展示块，对应一个事件流+一个时序数据库的查询
   一个前端控制块，就是手动控制器由用户设置的参数。可以有默认值。 展示块和控制块应该放在一起。

“爸爸下了一盘20年的大棋，突然就穷途陌路了。”

一生很短，很快就穷途陌路了。怎么过好这一生？

1.想清楚自己要干什么？

蓝：儿子，你知道你要干什么吗？
李：我很知道我要干什么。
蓝：知道吗？
李：知道
蓝：你真的知道吗？
李：我真的知道。
蓝：（哭）特别好，特别好。

自由的，幸福的，充实的过完这一生。

• 自由的：永远不要放弃独立思考。永远不要放弃自由的言论。
• 幸福的：学会爱与被爱，爱你的妻小，坦然的享受被爱，忠于你的信仰。
• 充实的：享受数学和人工智能的乐趣。

2.实现你的目标，掌握你的命运，你只能依靠你自己。

关：我爹是个军人，他被敌人俘虏了，他们就把他的头砍下来，挂在城墙上，一挂就是3天，我为这3天准备了10年。
李：你都做了些什么？
关：我为这3天准备了10年，我的仇人是一个军阀，他手底下有很多兵，我觉得我一个人不行，需要有人来帮我，所以：我就预计遇见了我第一个丈夫。
李：然后呢？
关：他说：要等待时机。后来，我有了2个孩子。他说：你不要报仇了，你的仇人不用你杀，老天爷会惩罚他们的。
李：你怎么说？
关：我说：你滚。
李：他滚了吗？
关：滚了。从那时候起，我明白了，报仇只能靠我自己。一个人，一把枪，足以。

一个人，一把枪，足以。

3.在机会出现时，果断决绝的抓住他。不要做过度的准备，也不要为自己的蹉跎找借口。

蓝：穷途陌路啦，穷途末路啦！
关：我拿你做了个实验，我和你有一样的噩梦，一样的恐惧，放脚，练枪，开裁缝铺，都是为了回避，我最应该做的事，现在实验成功了。你都能做到，我也一定会做到。其实他已经出现在我店里了，他很老，满头白发。对不起，上次没跟你说实话。

机会10年，20年出现一次，通常你会在等待下次机会中，蹉跎了一生。要果断，要正面刚。

不忘初心，方得始终。

所有痛苦，艰难，迷茫，疲惫的时候，想想1,2,3。你会多那么一点机会过好你这一生。

米价的故事

从前镇上的市场有3家米铺，分别是A记，R记，S记，其中A记的田质量最差，米的成本最高，但是A记的无论当家的还是伙计，都是身强力壮，无论耕田还是揍人都是一把好手，而且无论耕田还是揍人，技术都越来越熟练。 R记呢，田质量一般，伙计们战斗力也不行，也一直被A记打压，但他比较疯。S记田最好，家底也最厚，但拳头不硬也怕死，所以一直安心拜到A记门下当小弟。

镇上还有一个地主，地主家还有一群傻儿子，傻儿子不让出门。地主和R记关系比较好，以前地主家每个月要吃的米，一半都是R记直接送货上门，也签了长期供货合同。另一半，则是地主自己上街买。5块一斤。 地主买到米后，都是告诉他的傻儿子们20块钱一斤买的，你们吃了要记得给钱。

到了上个月，R记又开始疯，R记想：老子2块钱一斤卖米，亏死A记他娘的， 反正老子还有一半的米是5块一斤卖给我的”好兄弟”地主。S记的米成本最低才5毛，很早就也想降价搞倾销，但又怕A记揍他一直不敢，终于让他抓到机会， 于是他风一般跑去找A记说：”大哥，大哥，让我1块一斤卖米吧！，亏死R记他娘的”。但他心理想的其实是，最好A记，R记都亏死，剩我一家时，老子就翻他个100倍，50一斤走上人生巅峰。

本来这一切，对地主家也是好事，再怎么，也比5块一斤买米时便宜啊。但是地主上上个月也发疯，给他的傻子儿子们说：”孩儿们，爹年纪大了，以后就许了你们就自己上街买米吧”。 于是一群傻儿子哪里见过5块一斤这么便宜的大米，每个人像疯子一样拼命抢，市场上的米抢没有，还要下定金，下个月米也全要。

于是，当米价降到3毛钱的时候。地主和他的傻儿子们，还是在5块一斤的买大米。 R记没怎么亏，因为他有一半的米还是按5块一斤卖给了地主。 A记也没怎么亏，因为他也有一半的米按5块一斤的合约价格卖给了地主家的傻儿子们。 至于地主一家，囤的一堆5块钱的米，亏得内裤都快没啦，每次吃米都会气得吐血。

对于镇上的其他居民：3毛一斤的米真香！

写在特斯拉电池日之前

汽车是一个”耐用的”，”大件的”消费品，”耐用”代表其伴随用户的时间长，需要满足的用户多种的甚至变化的需求，使用的周期长也意味着持续的产生成本。 因此收益/成本比（后面就说”性价比”）很重要，而”大件”代表投入高，即性价比的些许改变也会带来较大的总体收益的改变。 因此围绕着”性价比”，在我个人看来电动车的发展总共有3个Mile Stone：

MS1: 性价比低，但能满足少数人的个性需求。能在和传统燃油车同等级的成本下造出电动车来已经是个了不起的Mile Stone. 已由特斯拉通过控制电池成本引导行业达成了。道理很容易讲：即使对燃油车，也会不少”昂贵”的”小众车”存在不是？

MS2: 电动车”综合的，平均的”性价比超过燃油车。一旦达成该路标，在每年全球新增的汽车销量中，电动车将会占主导。 电动车相对燃油车的优劣势都比较清楚也不再赘述。值得注意的是：电动车折旧率巨大，电池成本高，随着使用时间衰减大，这个是只用电动车的主要成本。 如果能降低电池的衰减，电动车的综合使用成本会全面低于燃油车（省油省钱这个就不说了），成本低了，收益即使不变，也可能让电动车的综合性价比超越燃油车。 所以：【传言中特斯拉会在电池日发布的”极低衰减”的电池，是我最期待的，可能就是电动车颠覆燃油车的关键！】感觉路标就在前方，心情激动！

MS3: 电动车综合的性价比甩开燃油车几条街。考虑一种情况：虽然电动车的综合性价比超过燃油车，它自己技术也还在高速迭代发展中，这样会使电动车老车型 贬值很快，对于非刚需，他可能因此延迟它的购买需求。哈哈，比如现在，在某些人看来，Model3的性价比已经秒杀一众不错燃油车了，但ModelY会不会更香？那是再等等吧。 租赁企业也会对快速贬值的标的有较大的忌惮。相反，设想一下：如果每年能只用付出万把块的成本，就可以享受一台静谧的，有驾驶乐趣，独享的，空间大的，甚至有完善自动驾驶的功能的车， 无论购买还是租赁，这个市场规模将会爆发性的增长。

服务网格+云原生的核心价值

从业务开发团队，运维团队，基础设施团队的接耦，接耦后提高了各团队的工作效率和质量。

耦合情况举例：

1. 业务团队内部耦合：
   • 对于巨大的单体应用，业务团队内部不同的人和子团队之间在开发和部署上存在相互依赖。通过微服务化，接耦。
2. 业务团队和运维团队的耦合:
   • 业务扩容，需由运维团队提供数据，业务团队设计方案（每个服务扩容多少，数据层怎么扩容，缓存层）。扩容的方案， 要借助服务发现机制或修改配置文件，由运维团队执行。
   • 服务治理相关的内容，因为属于服务化SDK的配置，SDK配置每个语言都不同，通常需要由业务团队给出方案，运维团队部署执行。
   • 灰度方案，同上，业务团队设计灰度方案，运维团队检验并执行。然后再由业务团队验证。
   • 故障注入，需要业务团队在代码级别注入故障，在演练结束后还需要再撤销。由运维团队注入的故障，往往只有kill 服务进程等非常简单。而且需要搭建额外的测试环境， 很难利用线上环境使用灰度的方式演练。

   最理想的情况是：业务团队只用专心在业务上，而所有其他工作可由运维团队和基础设施团队地理完成。

3. 业务团队和基础设施团队的耦合：
   • 基础设施团队为服务化SDK添加了新的功能，一个是需要对所有的语言的SDK添加并测试，第2个需要和业务代码一起上线。需要研发上线的窗口和所有语言的业务应用对齐。效率低下。
   • 对监控，策略执行的新的功能的添加，或者对接，更换新的后端应用，也有同上问题。
   • 基础设施团队，希望通过对应用和中间件之间的流量进行治理，缺乏通用工具。要依赖和业务团队合作，分别在中间件和应用SDK上做修改，并部署上线。
4. 基础设施团队和运维团队的耦合：
   • 基础设施中间件的性能通常需要随着业务性能扩展而扩展，因此和业务团队一样，需要更加接耦的伸缩机制。
   • 对中间件和应用之间的流量进行治理，即使基础能力在，需要由基础设施团队设计配置变更（缺乏通用配置），运维团队执行。
5. 3个团队的耦合：
   • 对于异常检测，需要由基础设施团队，业务团队设计相应的预案，运维团队执行相应的动作。
   • 对于上线新的指标的监控，需要业务人员开发或至少测试新的探针，基础设施团队对监控中间件修改相应的配置，运维团队执行变更。
   • 对于安全，需要业务团队设计验证安全方案，基础设施团队检验相关的安全设计，提供相应的安全中间件（证书管理），运维团队要负责网络层面的安全，并实际部署。
   • 对于流控等实时策略，需要业务人员完成业务端的开发或验证，基础设施团队提供相应的中间件功能。（redis的桶等），运维人员要实际部署，并做检验。

企业微服务化架构的演变

1. 微服务+VM时代
   • 业务团队内部的接耦。极大的提高新业务开发和发布的效率。
2. 微服务+云原生时代
   • 通过容器化技术让应用和运行平台接耦，K8S又为运维团队提供了强大的资源编排工具。实现了业务团队+基础设施团队和运维团队的解耦。极大的提高了运维和业务发布的效率，提升了业务伸缩性，可用性和发布的安全性。
3. 微服务+云原生+ServiceMesh时代
   • 在2的基础上，把服务治理，策略，监控，安全等能力基础设施化，实现了业务团队与基础设施团队的解耦。极大的提高了基础设施团队的工作效率。而基础设施能力的提升，又会极大的促进整个公司业务能力的提升。

在企业已经部分应用微服务+云原生的条件下，ServiceMesh应对的痛点场景

Istio-主流ServiceMesh方案

主要优势:

1. 生态兼容性好，很容易和其他（如监控，分布式跟踪，策略）开源产品一起组成完整的企业后端解决方案方案。
2. 由IBM, google发起，项目架构优异，可扩展性好。功能强大。
3. 社区活跃度最高，github 2018年贡献者发展最快的top 5项目。
4. 和容器化编排的事实标准K8S深度融合，复用大量K8S的概念和基础能力，与K8S的能力整合得最好，在使用K8S的基础上，学习和应用复杂度相对较低。
5. 对应用可实现零侵入。
6. 跨云统一治理能力好。
7. 通过ServiceEntry来实现云原生内外互通，和部分统一治理能力。

Istio的能力和架构概述

功能概述：

1. 流量治理：包括服务发现，负载均衡，路由控制，限流，熔断，容错，故障注入，灰度发布，流量镜像等。
2. 可观测性：包括监控，日志聚合，计量，分布式跟踪
3. 实时规则（策略）
4. 安全：加密通信，认证，授权。
5. 服务访问接口：南北向通信
6. 跨云融合

可以看到其功能丰富，对与大部分企业来说在功能上能满足。并且能构成企业后端的完整解决方案和统一的技术栈

架构概述：

1. Proxy即为数据面，负责规则的执行。使用功能强大，扩展性好，性能优异的Envoy
2. Mixer复杂把监控信息，和实时规则（策略）信息转发给对应的后端，支持多种不同的后端
3. Citadel负责维护分发安全证书，可实现透明的，可插拔的双向认证TLS通信，保障服务间通信安全。也能执行RBAC。
4. Pilot负责所有的配置的下发。
5. Galley 代理屏蔽不同的运行时实现，和Istio其他组件通信。验效配置。

Istio的现阶段的不足-可发展的潜力

1. 所有的公司现有的非ServiceMesh的服务基础设施，因其做为业务的底座，和业务高度绑定，更新的成本很大。考虑到业务的连续性和稳定性，也几乎不可能将其同时的迁移至Istio,所以需要更高效的模型，工具，帮助客户实现第1代SDK微服务，和第2代Service Mesh微服务Istio的互通调用和统一治理。
2. 可以考虑把SDK变成独立进程并下沉至基础设施这一想法继续深化，不限于服务治理，监控的范畴，比如把Envoy扩展为包含对分布式redis访问的SDK，这样当需要升级redis的SDK实现时，业务代码不用变化，同时也让分布式redis的水平伸缩变得更加容易。同样的考虑也适用MQ，数据库。从另一个观点来看，就是让Envoy支持更多特殊协议。
3. 安全模块的功能，架构还在高速变化，还未到达生产可用。
4. 因Istio重架构，暂时在性能优化方面分配较少精力。所以在大规模ServiceMesh场景下会遇到性能瓶颈，主要集中在Mixer和Pilot, 可以做进一步优化。

初步设计方案A:

1. 注册中心ServiceCenter要添加服务治理的配置储存功能
2. ServiceCenter要支持MCP协议
3. 改造Java-chassis支持xDS协议
4. 改造Mesher支持xDS协议
5. 控制面Pilot改造，提高其性能，后期可以考虑添加服务注册透传功能
6. Sidecar可以发展Mesher,也可以folk envoy，为其添加ServiceCenter服务注册能力。
7. Mixer复用Istio的。对于非云原生业务，要另外实现相关功能。

初步设计方案B:

1. Edge-Sidecar既是所有跨云和非云的流量的代理，也是作为非云原生应用的边车的集群，要能部署多个实例，能执行xDs协议，实现和Istio的更多功能的统一治理。
2. 扩展Scb已有组件Syncer实现和Istio的服务同步，和互相发现。
3. ServiceCenter作为所有非云原生的注册中心。
4. 对于所有的SDK微服务（包括Spring cloud，Dubbo)的存量应用，通过让其支持ServiceCenter来实现与Istio的融合。
5. 对于没有SDK的服务，可以通过Mesher实现无侵入接入Mesh。