DevOps任重道远，如何进行流程化管理？任务调度系统该怎样设计？

2020 年 7 月 13 日 InfoQ

开发测试管理和运行管理是 DevOps 平台实践中常见的两大问题。前者一般表现为开发效率低、版本质量差、环境交付慢、无统一工具设置和研发运维过程管控不足等，需要通过 DevOps 平台进行流程化管理。另一方面，随着云计算的发展，企业需要管理和维护的基础设施规模扩大，在混合云、多地域等各种异构网络环境下需要一套调度系统来管理和控制各类资源，解决运行管理问题。

7 月 2 日，京东智联云和英特尔联合举办了「DevOps 平台高可用架构与实践」线上公开课，来自京东智联云的云产品研发部架构师陈尧，和来自博云的售前解决方案架构师伞亚朋，分别介绍了大规模任务调度系统的架构设计与 DevOps 平台的流程化管理方法。

以下内容整理自两位老师的分享。

1 大规模任务调度系统的架构设计——基于 IM 的分布式控制系统原理解析

DevOps 平台为何需要任务调度系统

企业上线 DevOps 平台，本质上是为了以较低的成本高效处理运维需求。同样，任务调度系统的初衷也是为了控制成本、提高效率。当企业的线上业务规模逐渐扩大，单纯靠增加人手来解决系统升级、维护、部署、监控等事务的成本是很难承受的，这时就轮到自动化的任务调度系统登场了。

在实践中，业务规模较大的企业开发任务调度系统时会面临很多问题：机器规模庞大，分布地域广泛，甚至跨越全球；资源种类繁多（物理机 / 虚拟机 / 容器等）；公有云 / 私有云环境并存；操作系统多样化；VPC/ 子网等网络问题等等。要设计出能够从容应对这些挑战的任务调度系统绝非易事，因此我们就需要参考行业中已有的成熟经验和实践。

向黑客学习：设计大规模任务调度系统

自 2006 年熊猫烧香病毒事件后，整个黑客产业链开始将重心转向了通过 DDoS 等攻击手段获取不法收益上。随着攻击技术不断发展，如今一次大规模的 DDoS 的流量可达数以 Tbps 的惊人水平。

DDoS 的本质是黑客控制互联网上的大批机器向目标发送流量。这种技术要克服的障碍与任务调度系统有诸多相似点，例如规模巨大、网络不稳定、机器所在区域分散、系统版本众多等等。

为了解决这些问题，黑客选择的技术方案就是基于 IM 聊天协议的系统架构。作为控制方的黑客实际上是 IM 网络中的一个节点，被控制的机器等效于客户端，前者向后者发送消息，即可达成控制的目的。

在 DDoS 攻击活动中，黑客普遍使用的协议是 IRC：

在 IRC 模型中，攻击者自己建一个 master，再加一个控制服务器来控制僵尸网络中的节点；攻击者通过 master 连接到控制服务器上即可操纵僵尸节点发起攻击。需要注意的是 IRC 是匿名聊天协议，系统不关心连上控制服务器的是什么身份，只要能连上就可以实施控制。

但在典型的聊天应用场景中，更合适的选择是基于登录账号体系的 XMPP 协议：

在 XMPP 中，通信的各方都有自己的账号 / 身份，进而就可以发展出权限控制体系。如上图所示，XMPP 是对等互联网络，网络中的各节点都可以互相通信。由于各节点都有自己的身份，当某个节点收到其他节点发来的要求时，就可以根据对方的身份来选择是否遵从。

正因如此，XMPP 更适合作为任务调度系统的主协议。参照黑客使用的 IRC 网络模型，很容易得出基于 XMPP 模式的任务调度模型：

由于 master/agent 都有自己的账号 / 身份，就可以避免 agent 假冒 master 发送命令的攻击行为，确保系统的安全性。

另一方面，控制系统的目的并非单纯地控制机器本身，而是要对外提供服务。所以在上述模型的基础上还需要一个 api-server，用来包装业务需求，将其变为可执行的任务通过 master 分发给 agent。加入 api-server 后模型也比较简单：

系统对外开放的是上图中 api-server 账号。系统接收一个新任务（例如执行某个脚本）时，api-server 账号将任务以消息的形式发送给 master，之后 master 通过 xmpp server 再将任务分发给各个 agent。这里的权限设计是，agent 只听命于 master，而 master 只听命于 api-server。这样就得出了整个调度系统的业务逻辑模型。

上述业务模型是理论化，较为简单的模型。在现实应用中，任务调度系统使用的模型会复杂许多。

如前所述，现实中的大规模任务调度系统是需要满足跨地域和复杂网络环境的需求的。为了解决跨地域问题，需要搭建一个 XMPP 的 server 网络，其中每一个地域都有一个独立的分发网络，该地域的 agent 只连接到本地域的 XMPP server，以此类推。

更为复杂的是 master 的设计。对于小公司而言，只需一个 master 可能就足以管理所有机器，那么系统只需单个 master 作为调度器即可。但对于京东这样大规模的企业来说，需要多个 master 来分担庞大的任务负载，就需要将它们放在多个网络下面。

存在多个 master 时就需要考虑是否拆分 api-server。京东的选择是不做拆分，而 api-server 承接的业务逻辑最终形成一个 Redis 数据库作为一个中间件。负责不同地域的 master 启动后从中间件获取数据并分发任务，任务完成后也保存在中间件内。当外部用户查询 api-server，想要获得当前的任务状态时，api-server 会直接查询中间件，而非某个 master。

这个模型的最大优点是高可用性，某个节点出问题后并不影响整个网络继续运行。例如某个 master 发生故障后，当它重启后还能从中间件继续获取任务并分发下去，以此类推。

基于 XMPP 的这套系统模型解决了以下几个问题：

1. 适应各类网络模型。

使用 UUID 作为资源标识，不依赖机器名 /IP，可以应对复杂环境下的资源冲突情况；
公有云 / 私有云、VPC、子网均可用，不同的网络只需连接到固定的 server 上就能接入整个 XMPP 网络。
网络传输容忍度高，不同地域的子网不需要实时在线或低延迟。

2. 适配不同的硬件 / 系统环境。XMPP 库有大量开源实现，因而可以轻松解决各种环境的兼容性需求。

3. 系统性能高。

网络中的调度和分发模块拆分，内部是多节点组合，因而性能表现优异。
XMPP 本身性能强劲，单个集群可以应付百万客户端规模，实现秒级调度、执行。

总体而言，参考 IM 的架构设计，基于 XMPP 就可以打造出高性能、高可用性、可以适应复杂环境变量的大规模任务调度系统。

2 从开发到测试，如何通过 DevOps 平台进行流程化管理

DevOps 可以被理解是一个体系，其中的过程、方法和系统都是具体的表现形式。它更像是一把钥匙，打开了一扇大门，赋予团队无穷的想象。在本次分享中，伞亚朋老师介绍了企业应用 DevOps 平台进行流程化管理过程中需要关注的各个层面，其中重点包括团队协作，统一工具链和实施。

在企业打造 DevOps 平台的过程中，首先要明确的是 DevOps 的目标。伞亚朋老师认为，DevOps 主要解决的是人员沟通问题，它可以弱化人与人之间的沟通壁垒，使岗位之间信息流转更为明；从范围来看，DevOps 狭义上是产品从需求到交付、迭代的过程，广义上可以则涵盖整个公司和产品生态链。

团队协作与 DevOps 工具链管理

成功实现 DevOps 离不开高水平的团队协作，这里伞亚朋老师举了代码合并的例子。在企业中，常见的代码合并模式有三种：大多数公司采用的是开发经理合并代码模式；一些公司由测试负责合并代码，这样可以减少沟通环节，但需要同时掌握测试 / 开发 / 运维的复合人才；大公司常见的模式是专人合并代码，这对岗位的复合技能要求更高。

团队协作的另一个挑战是信息透明，需要通过流程定义内部需要的所有信息和沟通方式，这样就可以让团队成员都了解项目情况，并能明确责任，更好地定位问题，方便项目经理掌控全局。

另外，在工具链的选择和管理上，需要进行统一。DevOps 工具链分为角色、流程、规范、平台和工具四大类别。其中，从产品经理到开发、运维、运营人员等等，都是工具链中的重要角色。DevOps 实际生产中存在许多流程，每个流程都需要工具化、具体化，以免遗漏。开发工作中涉及众多规范，各种规范共同形成了工具链中重要的基石。

DevOps 工具太多，开源的、商业的，数不胜数，如果不能实现统一，在推进 DevOp 时会遇到很大的阻力。所以在工具链的选择上要遵循一个原则：实现同种功能的工具有且只能有一个。

企业该如何实施 DevOps

伞亚朋老师强调，在企业开始实施 DevOps 之前，必须要意识到 DevOps 平台的建设绝非一日之功，不可能一步到位，要考虑到诸多限制因素。

首先，企业要解决跨岗位 / 部门协作障碍，需要更高的领导层次给予强有力的和持续的支持；其次，DevOps 的文化建设是漫长的过程，需要相关人员逐渐理解和认同；DevOps 蓝图要解决的问题众多，涉及的工具多样，需要选择最适合自身需求的工具组合；最后，DevOps 落地需要一系列规范，建设规范体系也是长期过程。

在这样的背景下，DevOps 的成功落地需要满足几个条件：