本文作者
李雨前，阿里云弹性计算技术专家，有 5 年的大规模集群资源管理调度实践经验：针对 long-time service 及 co-location 调度具有全面、深入的一线实践和解决问题经验，提交 10+ 项相关发明专利；擅长稳定性优先的集群调度策略和稳定性架构设计、全局稳定性数据分析实践，以及 Java 和 Go 编程语言。
引文
随着企业数字化和全面上云的推进，更多的企业将在云上生云上长，云计算的集群管理调度技术支撑着所有云上业务应用。工程师应该像过去了解操作系统一样了解今天的集群管理调度。云时代的工程师，需要进一步了解这一领域，从而更好地理解云、利用云、发挥云的优势，赢在云计算时代。
如何理解集群调度？
图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 层进行架构设计而言，需清楚以下三个基本原则：
1. 简单化
主要是说在实现资源调度和管理系统，主链路足够简单，依赖组件尽量简单化。例如性能采集，应该足够简单，不需要融入太多数据分析、告警的业务。将分析、告警引流到数据系统上集中处理。
2. 稳定性
服务器资源是 IT 系统的基石，业务运行在服务器资源上。在云上，客户的业务都运行在云上，等于把自己的身家性命交给云平台。云平台必须确保服务器稳定。所以，资源调度和管理的技术设计，一定要稳定性优先。例如：客户资源的按打散度来调度，将客户实例尽可能分散在不同的物理机上。避免某个物理机出故障，影响同一个客户的多个实例。打散就意味着需要更多的物理服务器资源，也意味着云平台需要付出更多的成本。
3. 面向异常设计
硬件故障是客观存在的，软件 bug 也很难说不会出现。因此，面向异常设计是非常必要的。针对异常做架构层面支持，例如定义整个系统的异常事件，当出现异常的时候，相应异常订阅处理模块就可以快速感知，并执行异常处理。
数据中心架构设计的多个考量方面
架构设计是一个很大的话题。我的理解是，一定需要结合业务，从不同方面进行设计和取舍。主要有以下几个方面：
1. 业务设计
主要是把客户、问题、价值梳理清楚，和上下游系统的关系、边界定义清楚，才能在做系统架构设计的时候，做最合适的取舍。
2. 数据设计
例如数据的一致性、数据的实时性、数据的安全性。例如数据的存储、访问模型。
3. 主链路或者高频链路设计
任何系统都有其核心服务的业务场景，这个场景的请求和处理就构成了主链路或者高频链路。这个链路因为核心、高频，往往会不自觉地叠加更多的服务进来。这里建议做减法，确保主场景的稳定、可控。
4. 稳定性设计
需要综合考虑事前、事中、事后的整体设计。事前充分预防，事中快速定位、止损、恢复。事后复盘总结，故障演练等。
5. 面向异常设计
总是假设系统会有异常，这些系统在一开始都进行考虑。这样可以大大降低后续故障的修修补补的复杂性。
6. 规模化设计
规模也是一个可大可小的考量方面。一般在初始阶段，业务刚刚起步阶段，不需要关注规模的影响。但是，如果一开始就有一些设计的思考，也可以更好地服务规模化的请求。
7. 组织设计
有一句话说组织决定架构。在实践项目研发过程，组织架构的影响，也是需要考虑的。
其他还有例如：演练、测试、限流、微服务、容量规划等架构设计。
数据中心架构设计的主要思路
任何架构，首先它要能够解决问题。在基础设施领域，架构设计还需要支持规模化、稳定性优先，其次是考虑成本效能。由于基础设施在业务垂直分层链路中处于下层，越往下越简单，是关键的取舍依据。集群调度架构设计的核心思路是解决问题，支持规模化、稳定性优先且足够简单。
按“多、快、好、省”对集群调度和管理要解决的问题进行描述，如图 3 所示。
图3 集群调度和管理的“多、快、好、省”
从宏观上讲，集群调度架构支撑解决利用率问题、效率问题、产品化问题，并且支持从“可编程基础设施+DevOps”演进到“云原生 Serverless+AIOps”。这中间需要建立体系化的 Insight 能力。对 Insight 进一步分解，其不同发展阶段的侧重点如图 4 所示。
图4 分解 Insight，其不同发展阶段的侧重点
面向过程的调度架构设计和实践
资源请求处理过程如图 5 所示。首先是提交请求，通过后进入分配队列，然后进行调度，接下来是实例资源分配，最后是实例启动、实例运行。如果请求被拒绝，则可能是因为额度限制、权限限制、参数不符合要求、资源库存不足等。
图5 资源请求处理过程
面向过程最直接的体现是：在用户侧可以看到整个链路的关键信息，并需要主动关注异常结果，对异常进行处理。对于研发来说，就需要针对下游 API 返回状态做正确、异常的感知，并做正确的资源清理处理，避免资源泄漏。另外，面向过程也是相对的，业务需求由更多的步骤构成，如果从其中一个步骤来看，则可以被看作是面向服务的。
面向终态的调度架构设计和实践
面向终态抽象如图 6 所示。相对于面向过程来说，面向终态进一步屏蔽了过程细节，过程中的失败对用户无感，使得基础设施可编程——编程每一个场景、需求的终态，等于编程了整个基础设施。
图6 面向终态抽象
面向终态表明不是一次性的，而是要持续不断地维持目标状态。终态代表一个概念、需求，实现这个概念、需求的具体错误被透明化了，更贴近人的行为习惯，所想即所得，所见即所得。为了实现业务视角的终态，一种策略是将业务一致性、终态的需求转换为存储一致性的需求，或者说依托存储一致性的需求来大大简化业务一致性的需求。
例如，基于工作流的状态变化机制支持需求的拆分以及子任务可重入、可并发，最终实现一组状态的持续变化，从而实现业务走向目标状态。比如资源视图的一致性，就是通过分布式存储、锁、消息订阅等实现的。无论是 Paxis 协议还是 Raft 协议及其改进版本，都大大降低了业务的复杂性。
面向服务的调度架构设计和实践
面向服务抽象如图 7 所示。用户只需关心业务逻辑部分，业务需要的服务器资源、服务器交付的过程、服务器编排调度等全部由基础设施完成，交付的是服务，或者简单理解为抽象的算力。
图7 面向服务抽象
Hadoop、YARN 调度以及大数据算力服务，都将走向面向服务的调度。特别是云计算对基础设施的逐步收敛，共性的、基础性工作一步步被屏蔽。毫无疑问，对于一般用户来说，集群调度逐渐没有了，集群管理也会被第三方 ISV 服务商提供的工具托管维护。未来用户更多的是关注业务本身的发展，新的创新不再受限于基础设施资源的研发、运维和管理。
基于 Kubernetes 架构设计的案例分享
基于 Kubernetes（简称 k8s） 架构设计的案例如图 8 所示。这个架构设计的核心依然是 k8s 的原生架构。图中多了 Insight、LBS 等模块，这是实现稳定性的非常重要的手段。Insight 对整个系统进行观察，对潜在的风险进行识别、预警，并及时干预。k8s 是面向终态的，需要有人工介入、一键终止面向终态的部分机制，让系统模块针对性“lock”下，待问题解决后，再 relock。LBS 确保负载均衡、流控等。图中还对相关组件做了一些批注，这是作者认为非常重要的点，也是区别其他调度架构不同点的体现。
图8 基于 k8s 的架构案例
k8s 的面向终态体现：
- 所有对集群的操作都经过 apiServer，确保了资源的入口统一，避免了在大型数据中心，绕开调度系统的、直接对物理机配置或者资源的操作。因为一旦存在多个操作入口，就容易导致调度和管控的不一致性，从而引发资源泄露、资源的状态不一致性。
- 集群所有的数据统一存储，包括操作产生的正常、异常事件信息，都统一存储在 etcd，也有存储在扩展的存储系统中，如 metrics 或者 event 等。
- 集群的 Node，也就是物理资源的供给、上线、故障下线维修等，都统一走 apiServer 操作，走完整的上下线流程，避免了绕开 apiServer、直接操作物理结点环境带来许多不一致的风险。
- 对资源的抽象、定义、持久化到 etcd 中，通过持续 watch etcd 的定义、比对 Node 上真实的上报信息，进行向“定义”发起“交付”的动作，并清理非定义的“资源”。
- 面向异常的设计。所有正常或者异常的操作都会生成 event 事件，并上报到 master。在 master 订阅对于的事件，并执行对于事件的处理。这使得主链路相对干净：没有引入直接处理异常的复杂代码逻辑。另外，对异常的处理，可能需要联合更多的系统、数据一起决策，订阅模式提供了很好的解偶、扩展性，使得异常处理模块更加职责鲜明。
k8s 已表现出强大的生态影响力，对 k8s 的各种运用和优化的案例太多了。这里仅仅是一种解读，希望我的解读能帮助大家更好地理解什么是面向终态的设计。
结语
总体上架构设计没有最佳，只有最合适。在合适的时间、支持了业务的发展，依赖规模化服务的进行架构的深度迭代、完善。大型数据中心既要管理大规模的服务器，又是业务底层的基础设施，因此对架构、稳定性、性能等都有极高的要求。
希望本文对从事相关工作的同学们有所帮助，帮助你们在实战中多避坑、少踩雷。
