背景
出版了个人新书，只在朋友圈发了个推广。周围的一些相识同学不免感到有些“意外”，“惊讶”，“好奇”。也有同学说，也不见你宣传推广啊。联系了下PR团队，得到技术推广运营同学的支持，非常感谢。目前已经在弹性计算百晓生等渠道陆续发文了。这里我从书籍中抽取了部分内容，算是正式在ATA 自我推广下啊。
引文
随着企业数字化和全面上云的推进，更多的企业将在云上生云上长，云计算的集群管理调度技术支撑着所有云上业务应用。工程师应该像过去了解操作系统一样了解今天的集群管理调度。云时代的工程师，需要进一步了解这一领域，从而更好地理解云、利用云、发挥云的优势，赢在云计算时代。
本文，我将从资源视角，针对IaaS（Infrastructure as a Service）资源层的集群调度着重展开介绍，并就基础设施架构设计的基本原则、常用思路以及案例进行概括性分享（以务虚为主啊）。
如何理解集群调度
基本概念
图1 资源视角集群调度与管理
上面的划分方式，严格讲是有缺陷的，特别是云化后，客户对资源购买后的其他各种操作，如安全组管理、专有网络管理、续费、变配等等一序列的运维管控。这些其实也算集群管理的大范畴了，并且在云上，这部分管控直接展现出来的就是用户对云服务的体验。这里做好了，可以为后端省去很多不必要的麻烦。
如图1所示，集群调度包括任务调度和资源调度，集群管理包括资源管理和成本效率管理。有时候，又可以将其简化为任务调度、资源调度和资源管理，将成本效率管理“淡化”。从另一个层面来讲，任务调度、资源调度和资源管理的最佳实践过程，就是成本效率管理的实践过程。按照图2所示的关系来理解，也比较自然
图2 任务调度、资源调度、集群管理关系
举个例子，用户从阿里云控制台或者OpenAPI发起资源购买下单，这个相当于“任务”。当有很多用户在同一时间购买ECS 计算资源的时候，多用户请求就代表了多任务。每个用户的请求任务需要排队、进行路由等任务调度处理。后端调度系统收到具体任务后，需要从物理机房，众多物理机中，选择最合适的物理机，然后进行资源的分配、创建计算实例。这个过程就是资源的调度。调度的物理资源：服务器，需要采购、软硬件初始化、上线服务、故障维修等。这个资源供货管理的过程就代表了集群管理。
本文集群调度和管理，可以简化理解表达为集群资源调度和管理。
如何看待
今天在企业数字化转型、上云大背景下，企业如果理解了云供应商对于资源服务的工作路径，也有助于其 更好地上云、用云，管理并优化好自己的资源。
个人经验认为： 从DataCenter as One Computer开始，大规模集群调度和管理就拉开了序幕，曾经一度类似于Borg这样的系统，被誉为互联网公司的“核武器”，不轻易对外分享。随着技术的演进与发展，特别是近十年来云计算的蓬勃发展，集群调度和管理技术再一次走进大众的视野，典型的代表就是Google开源、CNCF孵化的开源集群调度和管理系统Kubernetes。Kubernetes被称为分布式操作系统，对标Linux单机操作系统，相关描述如：“Kubernetes is the new Linux”、“Kubelet is the new Kernel”、“Kubectl is the new GNU base system”、“Helm is the new Yum”、“Operators are the new Config Management tools”。
从商业化角度来看，Kubernetes只提供了分布式操作系统的“内核态”。商业化所需要的“用户态”内容，正依托社区吸纳全世界程序员来共建共享。从技术和商业两个角度来看，Kubernetes作为操作系统级别的系统程序，毫无疑问，它的业务抽象、架构设计、接口定义奠定这个系统的基础，也提高了其生命力，特别是生态发展的生命力，以及商业化盈利的概率。
今天，以Kubernetes为代表的集群调度和管理系统不再神秘，就像搜索引擎技术不再神秘一样。集群调度和管理是企业内部的“节流”，那么搜索引擎广告技术就是企业的“开源”。企业要生存，开源、节流必须是并存的。
在未来很长一段时间内，特别是大规模的集群调度和管理，会是大型数字化企业的必备基建能力，这个领域的发展值得我们继续探索。集群资源调度和管理的内容非常庞大，并且是偏基础的支撑，相当于IT服务的“地基”。这样的系统，一定是需要“设计图纸”的，并且非常依赖设计图纸，因为一但走错，后续“纠正”的代价巨大。接下来，就从架构设计聊聊。
架构设计的基本原则
就在IaaS层进行架构设计而言，需清楚以下三个基本原则：
简单化
主要是说在实现资源调度和管理系统，主链路足够简单，依赖组件尽量简单化。例如性能采集，应该足够简单，不需要融入太多数据分析、告警的业务。将分析、告警引流到数据系统上集中处理
稳定性
服务器资源是IT系统的基石，业务运行在服务器资源上。在云上，客户的业务都运行在云上，等于把自己的身家性命交给云平台。云平台必须确保服务器稳定。所以，资源调度和管理的技术设计，一定要稳定性优先。例如：客户资源的按打散度来调度，将客户实例尽可能分散在不同的物理机上。避免某个物理机出故障，影响同一个客户的多个实例。打散就意味着需要更多的物理服务器资源，也意味着云平台需要付出更多的成本
面向异常设计
硬件故障是客观存在的，软件bug也很难说不会出现。因此，面向异常设计是非常必要的。针对异常做架构层面支持，例如定义整个系统的异常事件，当出现异常的时候，相应异常订阅处理模块就可以快速感知，并执行异常处理
架构设计的多个考量方面
架构设计是一个很大的话题。我的理解是，一定需要结合业务，从不同方面进行设计和取舍。主要有以下几个方面
1 业务设计
主要是把客户、问题、价值梳理清楚，和上下游系统的关系、边界定义清楚，才能在做系统架构设计的时候，做最合适的取舍。
2 数据设计
例如数据的一致性、数据的实时性、数据的安全性。例如数据的存储、访问模型。
3 主链路或者高频链路设计
任何系统都有其核心服务的业务场景，这个场景的请求和处理就构成了主链路或者高频链路。 这个链路因为核心、高频，往往会不自觉地叠加更多的服务进来。这里建议做减法，确保主场景的稳定、可控。
4 稳定性设计
需要综合考虑事前、事中、事后的整体设计。事前充分预防，事中快速定位、止损、恢复。事后复盘总结，故障演练等。
5 面向异常设计
总是假设系统会有异常，这些系统在一开始都进行考虑。这样可以大大降低后续故障的修修补补的复杂性。
6 规模化设计
规模也是一个可大可小的考量方面。一般在初始阶段，业务刚刚起步阶段，不需要关注规模的影响。但是，如果一开始就有一些设计的思考，也可以更好地服务规模化的请求。
7 组织设计
有一句话说组织决定架构。在实践项目研发过程，组织架构的影响，也是需要考虑的。
8 其他
其他还有例如：演练、测试、限流、微服务、容量规划等架构设计
数据中心架构设计的主要思路
任何架构，首先它要能够解决问题。在基础设施领域，架构设计还需要支持规模化、稳定性优先，其次是考虑成本效能。由于基础设施在业务垂直分层链路中处于下层，越往下越简单，是关键的取舍依据。集群调度架构设计的核心思路是解决问题，支持规模化、稳定性优先且足够简单
按“多、快、好、省”对集群调度和管理要解决的问题进行描述，如图3所示。
图3 集群调度和管理的“多、快、好、省”
从宏观上讲，集群调度架构支撑解决利用率问题、效率问题、产品化问题，并且支持从“可编程基础设施+DevOps”演进到“云原生Serverless+AIOps”。这中间需要建立体系化的Insight能力。对Insight进一步分解，其不同发展阶段的侧重点如图4所示。
图4 分解Insight，其不同发展阶段的侧重点
面向过程的调度架构设计和实践
资源请求处理过程如图5所示。首先是提交请求，通过后进入分配队列，然后进行调度，接下来是实例资源分配，最后是实例启动、实例运行。如果请求被拒绝，则可能是因为额度限制、权限限制、参数不符合要求、资源库存不足等。
图5 资源请求处理过程
面向过程最直接的体现是：在用户侧可以看到整个链路的关键信息，并需要主动关注异常结果，对异常进行处理。对于研发来说，就需要针对下游API返回状态做正确、异常的感知，并做正确的资源清理处理，避免资源泄漏。另外，面向过程也是相对的，业务需求由更多的步骤构成，如果从其中一个步骤来看，则可以被看作是面向服务的。
面向终态的调度架构设计和实践
面向终态抽象如图6所示。相对于面向过程来说，面向终态进一步屏蔽了过程细节，过程中的失败对用户无感，使得基础设施可编程——编程每一个场景、需求的终态，等于编程了整个基础设施。
图6 面向终态抽象
面向终态表明不是一次性的，而是要持续不断地维持目标状态。终态代表一个概念、需求，实现这个概念、需求的具体错误被透明化了，更贴近人的行为习惯，所想即所得，所见即所得。为了实现业务视角的终态，一种策略是将业务一致性、终态的需求转换为存储一致性的需求，或者说依托存储一致性的需求来大大简化业务一致性的需求。
例如，基于工作流的状态变化机制支持需求的拆分以及子任务可重入、可并发，最终实现一组状态的持续变化，从而实现业务走向目标状态。比如资源视图的一致性，就是通过分布式存储、锁、消息订阅等实现的。无论是Paxis协议还是Raft协议及其改进版本，都大大降低了业务的复杂性。
面向服务的调度架构设计和实践
面向服务抽象如图7所示。用户只需关心业务逻辑部分，业务需要的服务器资源、服务器交付的过程、服务器编排调度等全部由基础设施完成，交付的是服务，或者简单理解为抽象的算力。
图7 面向服务抽象
Hadoop、YARN调度以及大数据算力服务，都将走向面向服务的调度。特别是云计算对基础设施的逐步收敛，共性的、基础性工作一步步被屏蔽。毫无疑问，对于一般用户来说，集群调度逐渐没有了，集群管理也会被第三方ISV服务商提供的工具托管维护。未来用户更多的是关注业务本身的发展，新的创新不再受限于基础设施资源的研发、运维和管理。
基于K8s架构设计的案例分享
基于K8s架构设计的案例如图8所示。这个架构设计的核心依然是k8s的原生架构。图中多了Insight、LBS等模块，这是实现稳定性的非常重要的手段。Insight对整个系统进行观察，对潜在的风险进行识别、预警，并及时干预。K8s是面向终态的，需要有人工介入、一键终止面向终态的部分机制，让系统模块针对性“lock”下，待问题解决后，再relock。LBS确保负载均衡、流控等。图中还对相关组件做了一些批注，这是作者认为非常重要的点，也是区别其他调度架构不同点的体现。
图8-基于k8s的架构案例
K8s的面向终态体现
1. 所有对集群的操作都经过apiServer，确保了资源的入口统一，避免了在大型数据中心，绕开调度系统的、直接对物理机配置或者资源的操作。因为一旦存在多个操作入口，就容易导致调度和管控的不一致性，从而引发资源泄露、资源的状态不一致性。
2.集群所有的数据统一存储，包括操作产生的正常、异常事件信息，都统一存储在etcd，也有存储在扩展的存储系统中，如metrics或者event等。
3.集群的Node，也就是物理资源的供给、上线、故障下线维修等，都统一走apiServer操作，走完整的上下线流程，避免了绕开apiServer、直接操作物理结点环境带来许多不一致的风险。
4.对资源的抽象、定义、持久化到etcd中，通过持续watch etcd的定义、比对Node上真实的上报信息，进行向“定义”发起“交付”的动作，并清理非定义的“资源”。
5.面向异常的设计。所有正常或者异常的操作都会生成event事件，并上报到master。在master订阅对于的事件，并执行对于事件的处理。这使得主链路相对干净：没有引入直接处理异常的复杂代码逻辑。另外，对异常的处理，可能需要联合更多的系统、数据一起决策，订阅模式提供了很好的解偶、扩展性，使得异常处理模块更加职责鲜明。
Kubernetes（简称k8s）已表现出强大的生态影响力，对k8s的各种运用和优化的案例太多了。这里仅仅是一种解读，希望我的解读能帮助大家更好地理解什么是面向终态的设计。
结语
总体上架构设计没有最佳，只有最合适。在合适的时间、支持了业务的发展，依赖规模化服务的进行架构的深度迭代、完善。大型数据中心既要管理大规模的服务器，又是业务底层的基础设施，因此对架构、稳定性、性能等都有极高的要求。这些挑战有哪些，又是如何解决的。
更多关于集群调度和管理，可以参考书籍《深入集群-大型数据中心资源调度与管理》。
预售链接
天猫： https://detail.tmall.com/item.htm?id=641482752107
