左耳听风_028_27_洞悉PaaS平台的本质
你好，我是陈浩网名锁耳朵耗子。
在了解了前面几节课中提的问题之后呢，我们需要思考一下应该怎么解决这些问题。
那为了解决这些问题呢，请先允许我来谈一谈软件工程的本质。
我认为呢一家商业公司的软件工程能力啊主要体现在三个地方。
第一呢是提高服务的SLA.所谓服务的SLA呢，也就是我们啊能提供多少个九的系统可用性。
而每提高一个酒的可用性啊，都是对整个系统架构的重新洗礼。
那在我看来啊，提高系统的SLA主要表现在高可用的系统和自动化的运维这两个方面。
你可以看一下我在酷shell上写的关于高可用系统这篇文章。
我在文中呢也给你提供了链接。
他主要讲了构建高可用的系统需要使用的分布式系统设计思路。
但是呢这个还不够，我们还需要一个高度自动化的运维和管理系统。
因为故障是常态，如果没有自动化的故障恢复，就很难提高服务的SLA.那第二呢就是能力和资源的重用或者富有。
那软件工程啊还有一个重要的能力啊，就是让能力和资源可以重用它。
主要表现在两个方面，一是软件模块的重用。
二呢是软件运行环境和资源的重用。
为此呢需要我们有两个重要的能力，一个是软件抽象的能力。
那另一个呢是软件标准化的能力。
你可以认为啊软件抽象就是找出通用的软件模块或者服务。
而软件标准化呢，就是使用统一的软件通讯协议，统一的开发和运维管理方法等等。
那这样呢就能让整体的软件开发运维的能力和资源啊得到最大程度的复用，从而增加效率。
那体现软件工程能力的第三点呢在于过程的自动化。
那编程啊本来就是把一个重复工作，自动化的工程。
所以软件工程的第三个本质啊，就是把软件生产和运维的过程自动化起来啊，也就是表现在这两个方面，一是软件生产的流水线。
二呢是软件运维的自动化。
为此呢我们除了需要CI和CD的divorce那样的自动化之外呢，也需要能够对软在运程的生产环境中的软件进行自动化运维。
那了解了软件工程的这三个本质啊，你就会发现我们前面所说的那些分布式的技术点啊是高度一致的啊，也就是这三个方面的能力。
那第一呢是分布式多层的系统架构。
那第二呢是服务化的能力供应。
第三呢是自动化的运维能力。
只有做到了这些啊，我们才能够真正拥有云计算的威力，这就是所谓的clounative.而这些目标呢都完美的体现在了pass平台上。
前面讲述的分布式系统关键技术和软件工程的本质啊，都可以在pass平台上得到完全的体现。
所以呢需要一个pass平台，把那么多的东西啊给串联起来。
那在这里呢我结合自己的认知啊，给你讲一下pass相关的东西，并且啊把前面讲过的所有东西啊都做一个总结。
首先呢我们来谈一谈pass平台的本质。
那一个好的pass平台呢应该具有分布式服务化、自动化、部署高可用、敏捷和分层开放的特征，并且啊可以和INS实现良好的联动。
那以下这三件事是pass跟传统中间件最大的差别。
第一呢服务化是pass的本质，软件模块重用服务治理，对外提供能力是pass的本质。
第二呢，分布式是pass的根本特性，多租户隔离、高可用服务编排是pass的基本特性。
第三呢自动化是pass的灵魂，自动化部署安装和运维和自动化的伸缩调度是pass的关键。
那接着呢我们再来介绍一下pass平台的总体架构。
我在文中呢给你展示了一张总体架构图，你最好结合这张图，听我讲啊，这样呢你更容易理解。
从图中呢我们可以看到，我用了docker加couver netity层来做了一个技术缓冲层。
也就是说呢如果没有docker和cooon netice构建pass啊，将会复杂很多。
当然啊如果你正在开发一个类似pass的平台啊，那么你就会发现自己开发出来的东西啊，会跟docker和cuba啊非常像。
相信我，最终你还是会放弃自己的轮子来采用natidocker加couper natest在docker加cuba netice层之上呢是两个相关的pass层，一个呢是pass调度层。
很多人啊把它叫做i pass,那另一个呢是pass能力层，通常呢被称为a pass.那没有怕是调度层呢怕是能力差，就很难被管理和运维，而没有pass.能力层呢pass啊就失去了提供实际能力的业务价值。
而本节课更多的是在讲pass调度层上面的东西，在两个相关的pass层之上呢，还有一个流量调度的接入模块，这个也是pass中非常关键的东西。
流控路由降级、灰度聚合和串联等等啊，都在这里，包括最新的AWS拉姆达、service、小函数档也可以放在这里。
那这个模块啊应该是像CDN那样来部署的。
然后在这个图的两边呢，分别是跟运营和运维相关的那运营这边呢主要是管理一些软件资源方面的东西，类似docker、 hub和CMDB,还有呢就是外部接入和开放平台上的东西。
那这个呢主要是对外提供能力的相关组件。
而运维这边呢主要是对内的相关东西，主要呢就是带vops.这里呢我总结一下一个完整的pass平台啊，会包括以下几个部分。
第一呢是pass调度层，主要是pass的自动化和分布式，对于高可用高性能的管理。
第二呢是pass的能力。
服务层主要呢是pass真正提供给用户的服务和能力。
第三呢是pass的流量调度啊，主要是与流量调度相关的东西，包括对高并发的管理。
那第四呢是pass的运营管理啊，包括软件资源库、软件接入认证和开放平台门户。
那最后呢第五部分是pass的运维管理啊，主要啊是deve off相关的东西。
因为我画的啊是一个大而全的东西，所以看上去呢似乎很重很复杂。
但实际上呢，其中的很多组件是可以根据自己的需求被简化和裁剪，而且呢还有很多开源软件啊，能帮你简化好多的工作。
虽然构建怕的平台看上去很麻烦，但是其实啊并不是很复杂，不要被我吓到了。
那谈完pass平台的总体架构呢，最后啊我们来讲一讲pass平台的生产和运维。
在这里呢我在文中啊同样画了一个大概的软件生产运维和服务接入的流程图。
他把之前的东西啊都串起来了。
从左上开始，软件构建进入软件资产库，然后呢走deve OS的流程。
通过整体架构，控制器进入生产环境，生产环境，通过控制器操作docker加cba netice集群啊进行软件部署和生产变更。
那其中呢同步服务的运行状态，并且啊通过生命周期管理来拟合状态，就像图中右侧部分所展示的那样，服务运行时的数据啊会进入到相关的应用监控。
而应用监控中的一些监控事件又会同步到生命周期管理中，再由生命周期管理器啊来做出决定，通过控制器啊来调度服务运行。
当应用监控中心发现流量变化要进行强制性伸缩的时候，它就会通过生命周期管理来通知控制系统进行伸缩。
那左下呢是服务接入的相关组件啊，主要是网关、服务API聚合、编排和流程处理。
那这个呢就对应于之前所说的流量调度和API gateway的相关功能。
好了，到这里啊，恭喜你已经学完了分布式系统架构本质系列课程的七讲内容。
那接下来呢我们对这些内容啊做一下总结，传统的单体架构系统啊容量显然是有上限的。
同时呢为了应对有计划和无计划的下线时间性额、可用性啊也是有极限的那分布式系统呢给以上两个问题啊提供了解决方案，并且呢还附带了其他的优势。
但是呢要同时解决这两个问题啊并不容易。
为了构建分布式系统啊，我们面临呢有这些主要问题。
那第一个问题呢在于分布式系统的硬件故障发生率更高，故障发生啊是常态，需要尽可能的将运维流程自动化。
那第二个问题呢在于我们需要良好的设计服务，避免某个服务的单念故障，对依赖它的其他服务造成大面积的影响。
那第三个问题呢就是为了容量的可伸缩性，服务的拆分，自制和无状态变得更加重要。
可能啊需要对老的软件逻辑啊做大的修改。
那第四个问题呢在于老的服务啊可能是异构的那这个时候呢就需要他们使用标准的协议，以便可以被调度编排，而且啊互相之间可以通信。
那第五个问题呢，就是服务软件故障的处理啊，也变得复杂，需要优化的流程来加快故障的恢复。
那第六呢就是为了管理各个服务的容量，让分布式系统啊发挥出最佳性能，需要有流量调度的技术。
那第七个问题呢就是分布式存储啊会让事物处理变得复杂。
在事物遇到故障无法被自动恢复的情况下，手动恢复流程也会变得复杂。
那第八呢就是测试和查错的复杂度增大了。
那最后呢还有一个问题就是系统的吞吐量会变大啊，但是呢响应时间会变长。
那为了解决这些问题啊，我们深入了解了这样一些对应的解决方案。
那第一点呢就是需要有完善的监控系统，以便对服务运行状态啊有全面的了解。
那第二点呢就是设计服务的时候啊，要分析它的依赖链。
当非关键服务故障的时候，其他服务啊需要有自动降级的功能，避免调用这个服务。
那第三点呢就是重构老的软件啊，使它能被服务化，可以参考SOA和微服务的设计方式。
目标呢是微服务化，还可以使用docker和cuoonenetice来调度服务。
那第四点呢就是给老的服务啊，编写接口逻辑来使用标准协议，或者呢在必要的时候重构老的服务啊，让他们具备这些功能。
那第五点呢就是要自动构建服务的依赖地图，并且呢引入好的处理流程，让团队呢能以最快的速度定位和恢复故障。
那详细内容呢可以参考故障，处理最佳实件应对故障。
这一讲第六点呢就是使用一个API gateway,它具备服务流向、控制、流量控制和管理的功能。
那第七点呢就是事务处理啊，建议在存储层实现根据业务需求啊或者降级，使用更简单存储量更大的最终一致性方案。
或者呢通过二阶段提交pixils raft,还有NWR等方案之一啊，使用吞吐量小的强一致性方案。
那第八点呢就是通过更真实的模拟生产环境，甚至呢是在生产环境中做灰度发布啊，从而增加测试的强度。
同时呢做充分的单元测试和集成测试，以便发现消除缺陷。
最后呢在服务故障发生的时候，相关的多个团队啊同时上线自查服务状态最快速的定位故障原因。
那最后呢就是要通过异步调用来减少对短响应时间的依赖。
还要对关键服务啊提供专属的硬件资源，并优化软件逻辑，以此呢来缩短响应的时间。
你应该已经明白了，解决分布式服务的吞吐量和可用性问题啊，并不是一件容易的事儿，以及目前的主流技术啊是怎么办到的那衍生出来的许多子问题啊，每一个都值得去细化，去研究解决方案。
那这个啊已经超出这节课的篇幅所能讲的了。
但的确啊都是值得我们做技术的人去深入思考的。
在这里呢我想邀请你来讨论一下啊，你在分布式系统的哪个领域研究的比较深，有什么独特的心得能和我们分享，期待你的留言。
在本文末尾呢，也给出了分布式系统架构本质系列文章的目录啊，方便你查找自己关注的内容。