12.20 Day 5 - 分布式系统关键技术：服务调度

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 5 天，也是我第 5 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《分布式系统关键技术：服务调度》的文章。

关键词总结：服务关键程度、服务依赖关系、服务发现、服务状态管控、服务生命周期管控、服务架构版本管控、服务调度、服务状态维持、服务状态拟合、服务弹性伸缩、服务故障迁移、服务工作流、服务编排。

 

所学总结：

 

服务关键程度

分布式系统中的服务关键程度也即服务重要程度，这需要对业务有比较深入的理解，属于非技术相关的管控。

 

服务依赖关系

分布式系统中的服务依赖不能出现依赖环，依赖环会产生的问题有：服务部署变得异常复杂、服务间所产生的问题将会产生骨牌效应或涟漪效应。比较主流的解决方案是借鉴依赖倒置的设计模式来布局服务间的关系，服务间的通信可以基于消息队列服务器来完成，以降低耦合度和出错率。侦测服务间依赖关系的工具有基于 Google Dapper 论文所实现的服务调用链追踪系统 Zipkin。

 

服务状态管控

分布式系统中服务的状态包含：服务的种类、服务的版本、服务所持有的实例数量以及它们的运行状态、服务当前所处的状态。类似于运维里的配置管理数据库（CMDB，Configuration Management Database）系统。

 

服务生命周期管控

分布式系统中服务的生命周期指的就是服务的状态变更过程。常见的服务生命周期包含这些过程：Provision（审核）、Ready（已就绪）、Run（运行）、Update（升级）、Rollback（回滚）、Scale out（扩充）、Scale in（回收）、Destroy（销毁）、Failed（失败）。

 

服务架构版本管控

分布式系统中的服务架构版本能够管控的数据有：服务的软件版本、服务的运镜环境（环境变量、CPU、内存、可运行节点、文件系统）、服务最大最小实例数。当定义好需要进行管控的数据之后，我们还需要有一个能够通过这些数据对其所属的服务执行相应操作的集群管控系统。

 

服务和资源的调度

分布式系统中的服务和资源的调度涉及：服务状态的维持和拟合（请参考后续标题为《服务状态拟合》的内容）、服务的弹性伸缩和故障迁移、作业的应用调度、作业工作流编排、服务编排。

 

服务状态维持

分布式系统中主要的服务状态分为两种，第一种状态可以想象成是服务的当前形态，也就是 Status（一般的体现是形容词）。另一个种状态可以想象成是服务的当前举动，也就是 State（一般的体现是现在进行时动词）。而这里所指的状态是 Status，也就是服务当前在其生命周期中所处的形态：Provision、Ready、Run、Scale、Rollback、Update、Destroy、Failed。

 

服务状态拟合

分布式系统中的服务状态“拟合”，指的应该是服务在进行状态切换时其所具有的特征发生变化的一个过程，该过程是尽可能地将服务在原状态所持有的特征与该服务在目标状态里所应当具有的特征做匹配，服务的特征会在状态的切换过程中从原状态所具有的特征稳妥地过度到其在目标状态里应该具有的特征，确保服务的最终特征与目标状态里的服务所应当具有的特征保持一致。

 

服务弹性伸缩

分布式系统中的服务弹性伸缩功能包含：服务资源伸缩、服务自动化部署、服务健康检查、服务发现注册、服务流量调度。在做好服务状态维持及状态拟合的工作之后，弹性伸缩的工作将会更顺利。

 

服务故障迁移

分布式系统中的服务故障迁移主要有两种模式，第一种模式是宠物模式，就是要保证让有状态的实例时刻处于运行状态。另一种模式是奶牛模式，就是当实例实在无法再运行时重新生成一个新的实例。

而这两个模式的使用复杂度也是挺高的，过程还需要查看服务的健康指标，这可能会需要借助一个应用性能管理（APM，Application Performance Management）系统来进行监控。

两种模式的特性

• 宠物模式：服务重新注册、服务监控报警。特点是先自动重试，不行的话再手动。
• 奶牛模式：服务资源申请、服务自动化部署、服务发现注册、服务流量调度。特点是重试无效后，重新生成一个服务的实例。

 

服务工作流

分布式系统中的服务工作流将对后续提到的服务编排起到一定的辅助作用，借助工作流引擎，我们可以将服务集群编排成一套业务流程。AWS 的 Simple Workflow 正是亚马逊推出的工作流引擎服务。

 

服务编排

分布式系统中的服务编排是指对服务集群里的服务进行编排操作，起作用是为了降低服务之间的调用以及调用维护的复杂度。

 

末了

重新总结了一下文中提到的内容：服务关键程度、服务依赖关系、服务架构版本管理、服务资源调度。