左耳听风_026_25_分布式系统关键技术服务调度
你好，我是陈浩网名猪耳朵house.那对于服务治理呢，你应该已经听得很多了。
但是呢我想说你所听到的服务治理啊，可能混合了流量调度啊等其他内容。
所以我们这里呢会把服务治理和流量调度啊分开来讲。
那今天这节课呢只涉及服务治理上的一些关键技术，主要包括服务关键程度、服务依赖关系主务发现整个架构的版本管理和服务，应用生命周期的全管理。
啊，这几点我们先来讲一讲服务的关键程度和服务的依赖关系。
那关于服务关键程度啊，主要是需要我们梳理和定义服务的重要程度。
这不是使用技术啊就可以完成的。
它需要细致的管理，对业务的理解，才能定义出架构中各个服务的重要程度。
然后呢我们还要梳理出服务间的依赖关系啊，这点啊也非常重要。
我们常说没有依赖就没有伤害。
那这句话的意思呢就是说服务间的依赖啊是一件很易碎的事儿。
依赖越多，依赖越复杂，我们的系统呢就越易碎。
因为依赖关系呢就像铁索连环一样，一个服务的问题呢，很容易出现一条链上的问题。
所以传统的SOA呢是希望通过ESB来解决服务间的依赖关系啊，这也是为什么在微服务中是希望服务间啊是没有依赖的，而让上层或者前端业务来整合这些后台服务。
但是要真正做到服务间没有依赖呢，我认为还是比较困难的。
总是会有一些公有服务会被依赖。
所以呢我们只能去降低服务依赖的深度和广度，从而让管理啊更为简单和简洁。
那在这一点上呢，以spring boot为首的微服务开发框架就开了一个好头。
微服务呢是服务依赖最优解的上限，而服务依赖的下限呢是千万不要有依赖环。
那如果系统架构中有服务依赖环呢，那么就表明你的架构设计呢是错误的循环依赖啊有很多的副作用。
那最大的问题呢在于这是一种极强的耦合，会导致服务部署相当复杂和难解，而且啊会导致无穷尽的递归故障和一些你意想不到的问题。
那解决服务依赖环的方案呢，一般使用依赖倒置的设计模式。
在分布式架构上，你可以使用一个第三方的服务来解决这个事儿。
比如通过订阅或发布消息到一个消息中间件，就者呢把其中的依赖关系啊抽到一个第三方的服务中。
然后呢由这个第三方的服务啊来调用这些原本循环依赖的服务。
那服务的依赖关系呢是可以通过技术的手段来发现的。
而这其中呢ZP king就是一个很不错的服务调用跟踪系统。
它呢是通过google delper这篇论文来实现的那这个工具呢可以帮你梳理出服务的依赖关系，并且了解各服务的性能。
那在梳理完服务的重要程度和服务的依赖关系之后呢，我们啊就相当于知道了整个架构的全局。
就好像我们得到了一张城市地图，在这张地图上可以看到城市的关键设施和城市的主干道。
再加上相关的监控呢，我们就可以看到城市各条道路上的工作和拥堵情况。
那这对于我们整个分布式架构啊是非常非常关键的那我给很多公司啊都做过相关的咨询。
当他们需要我帮忙解决一些高并发或者架构问题的时候呢，我一般啊都会向他们要一张这样的地图啊。
但是呢几乎所有的公司啊都没有这样的地图。
那有了上面这张地图之后呢，我们还需要有一个服务发现的中间件。
那这个中间件呢是非常非常关键的。
因为这个架构城市啊是非常动态的，有的服务啊会新加进来，有的呢会离开，有的会增加更多的实例，有的呢会减少。
那还有的服务呢在维护过程中，所以呢我们需要有一个服务注册中心啊来知道这么几个事儿。
那第一呢是整个架构中啊有多少种服务。
第二，这些服务的版本啊是什么样的？第三呢，每个服务的实例数有多少个，他们的状态是什么样的。
第四呢，每个服务的状态啊是什么样的？是在部署中、运行中、故障中、升级中还是在回滚中、升升中或或者呢是在下线中。
那这个服务注册中心呢，有点像我们系统运维同学啊说的CMDB啊这样的东西，那也个非常关键的。
因为没有它呀，我们就没有办法知道这些服务运作的状态和情况。
那有了这些服务的状态和运行情况之后呢，你就需要对这些服务的生命周期啊进行管理了。
那服务的生命周期呢通常会有这么几个状态。
那第一呢是provision啊，代表在供应一个新的服务。
第二呢是ready啊，表示启动成功了。
第三呢是run啊，表示通过了服务健康检查。
第四是update啊，表示在升级中。
第五呢是roll back啊，表示在回滚中。
那第六是scale啊，表示正在伸缩中，那可以有scale in和scale out两种。
第七呢是destroy啊，表示在销费中，最后呢第八个状态是failed啊，表示失败状态。
那这几个状态呢需要管理好，那不然的话你就不知道这些服务啊在什么样的状态之下，那不知道在什么样的状态下呢，你就对整个分布式架构啊也就无法控制了。
那有了这些服务的状态和生命周期的管理，还有服务的重要程度和服务的依赖关系。
再加上一个服务运行状态的拟合控制，你一下子啊就有了管理整个分布式服务的手段了。
那一个纷乱无比的世界呢，从此就可以干干净净的管理起来了。
那接着呢我们再来谈一谈整个架构的版本控制。
那对于各个架构的版本管理这个事儿啊，我只见到在亚马逊啊，有这个东西叫version sion set.呃，也就是有一堆的服务的版本集啊所形成的整个架构的版本控制。
那除了各个项目的版本管理之外呢，还需要在上面啊再盖一层版本管理。
如果你build过linux分发包啊，那么你就会知道linux分发包中各个软件的版本之上呢，会再盖一层版本控制。
毕竟呢这些分发包也是有版本依赖的那这样呢可以解决各个包的版本兼容性问题。
所以呢在分布式架构中呢，我们也需要一个架构的版本，用来控制其中各个服务的版本兼容。
比如a服务的一点二版本只能和b服务的二点二版本一起工作。
那a服务的上个版本一点一呢，只能和b服务的二点零一起工作，那这个呢就是版本兼容性。
那如果架构中有这样的问题呢，那么我们就需要一个上层架构的版本管理。
那这样呢如果我们要回滚一个服务的版本，就可以把和它有版本依赖的服务啊也一起回滚掉。
那当然呢一般来说在设计过程中啊，我们是不希望有版本的依赖性问题的。
但可能有些时候啊我们会有这样的问题，那么就需要在架构版本中呢记录下这个事儿，以便可以回滚到上一次相互兼容的版本。
那要做的这个事儿呢，你需要一个架构的manifest啊，也就是一个服务清单。
那这个服务清单呢定义了所有服务的版本运行环境。
那其中包括服务的软件版本，服务的运行环境，服务运行的最大最小实例数等等。
每一次对这个清单的变更啊都需要记录下来啊，算是一个架构的版本管理。
而我们刚才所说的那个集群控制系统呢，需要能够解读啊，并且执行这个清单中的变更，来操作和管理整个集群上的相关变更。
那最后呢我们再来讲一讲资源和服务调度。
那资源和服务调度呢有点像操作系统。
操作系统呢一方面把用户进程在硬件资源上进行调度，那另一方面呢也提供了进程间的通信方式，可以让不同的进程啊在一起协同工作。
服务和资源调度的过程呢与操作系统调度进程的方式啊很相似，主要呢有这样一些关键技术，第一呢是服务状态的维持和拟合。
第二呢是服务的弹性伸缩和故障迁移。
第三呢是作业和应用调度。
第四呢是作业工作流的编排。
第五呢是服务变化。
所谓服务状态呢，不是服务中的数据状态，而是服务的运行状态。
换句话说呢，就是服务的status,而不是state,也就是服务运行时的生命周期中的状态，包括observation、 ready、 run、 scale、 roll back、 update、 destroy,还有failed啊等。
那服务务运行时状状态呢是非常关键的，在服务运行过程中呢状态啊也是会有变化的那这样的变化呢有两种，一种呢是没有预期的变化。
所谓服务运行，因为故障导致一些服务挂掉啊，或者是别的什么原因出现了服务不健康的状态。
而一个好的集群管理控制器呢应该能够强行维护服务的状态。
在健康的实例数变少的时候呢，控制器会把不健康的服务啊给摘除掉，而又启动几个新的强行维护健康的服务实例数。
那另外一种呢是预期的变化啊，比如我们需要发布新版本啊，需要伸缩，需要回滚。
那这个时候呢集群管理控制器啊就应该把集群啊从现有的状态迁移到另一个新的状态。
那这个过程呢并不是一蹴而就的，集群控制器啊，需要一步一步的向集群发送一些控制命令。
那这个过程呢叫拟合，就是从一个状态拟合到另一个状态，并且啊要尽所有的可能玩命的不断的拟合，直到达到目的。
那这里呢我详细说明一下，对于分布式系统的服务管理来说呢，当需要把一个状态变成另一个状态的时候呢，我们就需要对集群进行一系列的操作。
比如我需要对集群进行scale的时候呢，我们需要先扩展出几个节点，再往上呢部署服务，然后呢启动服务，随后啊再检查服务的健康情况啊，最后呢把新扩展出来的服务实例啊加入服务，发现中提供服务可以知道啊，这是一个比较稳健和严谨的scale过程。
那这个呢需要集群控制器啊，往生产集群中啊进行若干次操作。
那这个操作的过程呢一定是比较慢的那一方面呢需要对其他操作排他。
那另一方面呢，在整个过程中啊，我们的控制系统需要努力的逼近，最终的状态直到完全达到。
此外呢正在运行的服务呢可能也会出现问题。
此开了我们想要的状态，而控制系统检测到之后呢，会强行的维持服务的状态。
我们把这个过程啊叫做拟合。
那基本上来说呢，集群控制系统啊都是要干这个事儿的。
没有这种设计的控制系统的，都不能算作设计精良的控制系统，并且在运行的时候啊，一定会有很多的坑和bug.那如果你研究过cubon netice这个调度控制系统的，你就会看到它的思路啊，就是这个样子的那有了前面的服务状态，拟合的基础工作之后呢，我们就能很容易的管理服务的生命周期了。
甚至呢可以通过底层的支持进行便利的服务，弹性伸缩和故障迁移。
那对于弹性伸缩呢，在前面啊，我已经给出了一个服务伸缩所需要的操作步骤啊，还是比较复杂的那其中呢涉及到了底层资源的伸缩，服务的自动化部署，服务的健康检查啊，也发现的注册和服务流量的调度。
而对于故障迁移呢啊也就是说服务的某个实例出现问题的时候，我们需要自动的恢复它。
那对于服务来说啊，有两种模式，一种呢是宠物模式啊，一种呢是奶牛模式。
所谓宠物模式呢就是一定要救火，主要呢是对于statefold服务。
而奶牛模式呢就是不救火了啊，重新生成一个实力。
那对于这两种模式呢，在运行中啊也是比较复杂的那其中呢涉及到的服务的健康监控，这可能需要一个APM的监控。
那如果是宠物模式呢，就需要服务的重新启动和服务的监控报警。
那如果是奶牛模式呢，那就需要服务的资源，申请服务的自动化部署，服务发现的注册。
还有呢服务的流量调度。
我们可以看到弹性伸缩和故障恢复需要很相似的技术步骤。
但是呢要完成这件事情啊并不容易，你需要做很多的工作，而且呢会有很多细节上的问题啊，会让你感到焦头烂额。
呃，当然呢好消息是我们非常幸运的生活在了一个比较不错的时代。
因为有docker和cubnenetice这样的技术可以非常容易的让我们做好这个工作。
我们把传统的服务迁移到docker和cubnenetice上面来，再加上更上层的对服务生命周期的控制系统的调度。
我们啊就可以做到一个完全自动化的运维架构了。
正如前面和操作系统做的类比一样，一个好的操作系统呢需要通过一定的机制，把一堆独立工作的进程啊给协同起来。
那在分布式的服务调度中呢，这个工作叫做orchestration.国内呢把这个词翻译成编排，从分布式架构的冰与火这一讲中的SOA架构演化图来看呢，要完成这个编排工作。
传统的SOA呢是通过ESB啊，也就是企业服务总线来完成的。
Esb的主要功能呢是服务通信路由协议转换、服务编制和业务规则应用等等。
那这里要注意ESB的服务，编制呢叫做corrography,和我们说的orchestration是不一样的。
那orchestration的意思呢是一个服务啊，像一个大脑一样来告诉服大家应该怎么交互，就跟乐队的指挥样样。
而corography的意思呢，是在各自完成属于自己工作的基础上，怎样务相协作，就跟芭黎舞团的舞者一样。
而在微服务中呢，我们希望能使用更为轻量的中间件来取代ESB的服务编排功能。
能简单来说呢，这就需要一一个PII get way啊或一个简单的消息队列来做相应的编排工作。
而spring中中呢所有请请求呢统统通过过API get away来访问内部的服务。
那这个呢和cooper nanece中的inggress相似。
我觉得啊关于服务的编排呢，会直接导致一个服务编排的工作流引擎中间件的产生。
那这个呢可能是因为我受到了亚马逊的软件工程文化的影响所致。
因为亚马逊呢是一家超级喜欢工作流引擎的公司。
那通过工作流引擎呢可以非常快速的将好几个服务编排起来，形成一个业务内容。
那这个呢就是所谓的orcheststration的的conductor指挥。
好了，今天的分享呢就是这些。
让我们来总结一下今天的主要内容。
我们从服务的关键程度，服务的依赖关系，那整架架构版本管管啊等多个方面，全面阐述了分布式系统架构五大关键技术之一的服务资源调度。
啊，希望这些内容啊能对你有所启发。
那你现在的公司是怎样管理和运维线上的服务的呢？啊，欢迎你啊，也来分享一下你的经验和方法。
那下一讲中呢，我们将从流量调度和状态数据调度两个方面。
那接着聊分布式系统关键技术。
文末呢有系列文章分布式系统架构本质的目录供你查看，方便你找到自己感兴趣的内容。