分布式系统关键技术：服务调度

1、服务关键程度

服务关键程度，主要是梳理和定义服务的重要程度。这不是使用技术可以完成的，而是需要细致地管理对业务的理解，才能定义出架构中各个服务的重要程度。

2、服务依赖关系

• 梳理出服务间的依赖关系，这点也非常重要。我们常说，“没有依赖，就没有伤害”。这句话的意思就是说，服务间的依赖是一件很易碎的事。依赖越多，依赖越复杂，我们的系统就越易碎。
• 微服务是服务依赖最优解的上限，而服务依赖的下限是千万不要有依赖环。
• 服务的依赖关系是可以通过技术的手段来发现的。其中 Zipkin 这个工具可以帮你梳理服务的依赖关系，以及了解各个服务的性能。

在梳理完服务的重要程度和服务的依赖关系之后，我们相当于知道来整个架构的全局。就好像扽到了一张城市地图，再加上相关的监控，我们就可以看到城市各条道路上的工作和拥堵情况。

3、服务发现

由于整个系统是非常动态的，有的服务会新加进来，有的会离开，有的会增加更多的实例，有的会减少，所以在这个系统中我们需要一套可以自动服务发现的机制，也叫服务注册中心。在服务注册中心上面可以清楚的知道每个服务的状态。 

有了这些服务的状态和生命周期的管理，以及服务的重要程度和服务的依赖关系，在加上一个服务运行状态。管理分布式服务就可以变的方便很多。

4、整个架构的版本管理

在分布式架构中，我们也需要一个架构的版本，用来控制其中各个服务的版本兼容。 比如，A 服务的 1.2 版本只能和 B 服务的 2.2 版本一起工作，A 服务的上个版本 1.1 只能 和 B 服务的 2.0 一起工作。这就是版本兼容性。

需要一个架构的 manifest，一个服务清单，这个服务清单定义了所有服 务的版本运行环境，其中包括但不限于:

• 服务的软件版本;
• 服务的运行环境——环境变量、CPU、内存、可以运行的结点、文件系统等;
• 服务运行的最大最小实例数。

每一次对这个清单的变更都需要被记录下来，算是一个架构的版本管理。

5、服务应用生命周期全管理

1）服务和资源调度过程的关键技术：

1>.服务状态的维持和拟合
所谓服务状态，是服务运行时生命周期中的状态
服务运行过程中，状态也是会有变化的，这样的变化有两种。
一种是不预期的变化：服务运行因为故障导致一些服务挂掉，集群管理控制器应该能够强行维护服务的状态。在健康的实例数变少时，控制器会把不健康的服务给摘除，而又启动几个新的，强行维护健康的服务实例数。
另外一种是预期的变化：当需要发布新版本，需要伸缩，需要回滚。这时，集群管理控制器就应该把集群从现有状态迁移到另一个新的状态。这个过程并不是一蹴而就的，集群控制器需要一步一步地向集群发送若干控制命令。这个过程叫“拟合”——从一个状态拟合到另一个状态，而且要穷尽所有的可能，玩命地不断地拟合，直到达到目的。

服务的弹性伸缩和故障迁移。

弹性伸缩的步骤：
先扩展出几个结点;
再往上部署服务;
然后启动服务;
再检查服务的健康情况;
最后把新扩展出来的服务实例加入服务发现中提供服务。

在此过程中涉及到如下要素：
底层资源的伸缩;
服务的自动化部署;
服务的健康检查;
服务发现的注册;
服务流量的调度。

故障迁移：当服务的某个实例出现问题时，需要自动地恢复它。有两种模式，一种是宠物模式，一种是奶牛模式。
所谓宠物模式，就是一定要救活，主要是对于 stateful 的服务。
而奶牛模式，就是不救活了，重新生成一个实例。

这个过程涉及：
服务的健康监控(这可能需要一个 APM 的监控)。
如果是宠物模式，需要:服务的重新启动和服务的监控报警(如果重试恢复不成功，需要人工介入)。
如果是奶牛模式，需要:服务的资源申请，服务的自动化部署，服务发现的注册，以及服务的流量调度。

服务编排。

编排：通过一定的机制把一堆独立工作的进程给协同起来。在分布式的服务调度中，这个工作叫做 Orchestration。
传统的 SOA 是通过 ESB(Enterprise Service Bus)——企业服务总线来完成编排的。ESB的主要功能是服务通信路由、协议转换、服务编制和业务规则应用。

ESB 的服务编制叫 Choreography，与我们说的 Orchestration 是不一样的。
Orchestration 的意思是，一个服务像大脑一样来告诉大家应该怎么交互，就跟乐队的指挥一样。
Choreography 的意思是，在各自完成专属自己的工作的基础上，怎样互相协作，就跟芭蕾舞团的舞者一样。

在微服务中，我们希望使用更为轻量的中间件来取代 ESB 的服务编排功能。 简单来说，这需要一个 API Gateway 或一个简单的消息队列来做相应的编排工作。在 Spring Cloud 中，所有的请求都统一通过 API Gateway(Zuul)来访问内部的服务。