Cloud Engine

Cloud Engine：大杀器如何炼成

 

郑昀 创建于2016/6/18 最后更新于2016/6/19

点击查看我的《如何从零搭建一个技术平台》，这是一个系列。转载时请注明“转载自旁观者-博客园”或者给出本文的原始链接。

---

本文档适用人员：技术人员

提纲：

1. 蚂蚁金服的研发协作是怎么运转的

2. 我们向何处去

3. 我们现阶段如何聚焦

4. CE 简介

---

何谓 ACP？阿里协作平台是也。

自动化测试、自动化构建、自动化运维、环境维护、资源申请和释放、虚拟机集群、容器集群……对于一支庞大的技术团队，这些名词术语意味着生产效率，意味着快速迭代，意味着研发、测试、运维 All in，当然也可能意味着混乱，有操不完的心，有维护不完的事，工程越多，并行项目越多，麻烦越大。

去年年底，我们的一支小分队与支付宝一起并肩作战了三个月，近距离观察了他们的研发协作和应用发布过程。回来后，志全、老白、明骏给大家分享了所见所闻，我们试图从中找到云纵研发协作和持续集成的未来之路。不久之后，田志全明确了切入方式，云纵 CloudEngine 开始开发。

我们先来看一眼 CloudEngine 的庐山真面目：

图0，云纵 CloudEngine 首页-管理员身份

下面先介绍一下蚂蚁金服的玩法。

蚂蚁金服的研发协作是怎么运转的

一套精密的体系

如下图1所示，我们可以把庞大的蚂蚁金服研发支撑体系浓缩为这四个平台：

1. ACP，阿里协作平台

2. 九州资源管控平台

3. AQC，蚂蚁质量基础设施平台

4. Zpass，蚂蚁集团发布部署平台

ACP 是总驱动方。九州，AQC，Zpass 是基础设施。

图1，蚂蚁金服协作平台之间的关系

先说最上层的 ACP。假设我作为一个项目的项目经理，负责某一个迭代版本，那么我在这个系统里这么做：

1. 新建一个项目

2. 拉流（创建分支）

3. 申请服务器资源

4. 系分 & 评审

5. 测分 & 评审

6. 功能测试完成后：

1. 督促测试人员验证结果

2. 开发人员填写发布计划

7. 回归测试完成后：

1. 督促测试人员及时响应回归结果

8. 测试风险评估

9. ARS 系统上填写发布计划评估

10. 发起会审：检查质量红线，测试风险评估，资损评估，DB和安全评估

11. 上预发环境，做回归测试，PD验收

12. 等待发布

13. 已发布，项目结束

14. 服务器资源自动回收

ACP 的很多能力来自于下层的基础设施系统。我们来看看下层的 AQC，它在开发自测、交付测试、日常测试、集成测试、环境冒烟、全站回归、线上回归中扮演重要的角色。下图2展示了 AQC 的业务架构，下图3展示了它的核心流程。

图2，AQC 业务架构

图3，AQC 核心流程示意

简而言之，ACP、AQC 等系统将蚂蚁金服项目全生命周期从流程流转到代码分支到资源管控都串起来了。

我们向何处去

生产效率如何提升

蚂蚁金服的体系庞大，经营多年，犹如高速运转的精密仪器，我们该如何下手呢？截至到去年年底，云纵自己的持续集成体系如下图4所示：

图4，云纵持续集成

云纵的 Java 和 PHP 应用，无论线下测试环境，还是线上生产环境，均运行在基于 Mesos+Marathon+Docker 的容器私有云上，由我们自主研发的 TouchStone（点金石）系统部署。当然光有 Docker 是不够的，还是有很多应用需要跑在虚拟机里。

我们最大的痛点是什么？我们要向支付宝学习什么呢？

田志全分析，我们最大的痛点是开发联调环境和测试环境的并行测试。

举一个例子。版本 V1.0 中，业务中心 A 并没有代码变更，测试周期一周；版本 V1.1 中，业务中心 A 有代码变更，提测时间肯定晚了一些，小版本的测试周期为三天。常规分支对应的测试环境里，V1.1里 A 的代码变更，可能造成业务中心 A 的不稳定，会影响 V1.0的正常测试，所以二者难以在一个环境里并行测试。

以前我们一般这么解决：

1. 多整几个测试环境。V1.0 一个环境，V1.1 一个环境。但环境维护艰巨，对工程师来说也不胜其扰。

2. 代码变更要求向上兼容。但第一，向上兼容没那么容易，第二，总有不能兼容的时候，咋办，只能串行测试。

那么我们向支付宝学习两点：

• 项目经理/研发经理通过 paas 平台，为应用申请环境资源：

• 一切都通过交互界面完成，无需东奔西走（注：理想而已，有了流程，节点审批还是要打电话催的）；

• 引入 Stable 环境概念：

• 一般一个项目包括两套日常环境，一套开发用，一套测试用；

• 开发环境：项目或升级包开始由开发申请，用于调试代码、自测以及后续修补缺陷调试使用

• 测试环境：进入测试之前由测试申请，用于功能测试

• 两套环境从域名上区别如下：

• xxx.dxxx.yourcompany.net，开发用

• xxx.txxx.yourcompany.net，测试用

• Stable 环境是一套比较完整的系统，服务于日常开发环境和日常测试环境

• 日常开发和测试环境申请机器时，通常只包含代码有变更的系统，所依赖的其他系统均来自于 Stable 环境

 

我们现阶段如何聚焦

paas 平台和 stable 环境如何发挥价值

明确了学习目标后，我们就要假想出现阶段的各种应用场景，作为系统的愿景。

首先，应用可以发布在虚拟机上，也可以发布在容器上，应该允许工程师选择。毕竟不是每一个应用都适合容器化。

其次，与 ACP 一样，应用发布的过程可视化，这包含两层意思：

1. 状态变迁可视化，ACP 里的状态变迁如下图5所示：

• 

• 图5，ACP 应用发布状态

2. 部署信息可以聚合展示，如果部署失败，我可以看到是哪一步出错，出错信息是什么。

按我的《如何从零搭建一个技术平台》所说，整理了首期应实现的六个主应用场景：

1. 登记和维护应用，应用的配置管理

2. 环境查看和监控

3. 环境的公共配置管理

4. 服务器资源（虚拟机和容器资源）申请和审核

5. 服务器资源释放（和续租）

6. 服务器资源找回帐号密码

CE简介

CloudEngine 像 ACP 一样，架设在我们的 TouchStone、SimpleWay 和 iDB 之上，可以理解为元数据管理和流程调度发起者，同时支持虚拟机和容器资源申请。这几者调用关系如下图6所示：

图6，有了CE之后的调用关系

它们可以粗糙地对应到蚂蚁金服系统上：

• CloudEngine = ACP 的一小部分，更接近于 AQC 的功能角色

• TouchStone = AQC 一部分+ Zpaas 一部分

• SimpleWay = Zpaas

工程师角色进入 CE 后，可以在首页工作台看到自己名下有多少个应用，发出过多少个机器资源申请，已分配多少机器，能看到当前有几个环境，环境里虚拟机和容器的机器配额各是多少，已分配了多少机器（虚拟机或容器），如下图所示：

图7，CE首页工作台-工程师角色

上图中：

[vm]开发环境[2/90]：指开发联调环境的虚拟机（vm）配额为90，当前已分配2个虚拟机；

[docker]开发环境[1/90]：指开发联调环境的容器（docker）配额为90，当前已分配1个容器。

服务器申请，按审核节点分有两种：

1. 有审核：申请 Stable 环境资源，意味着长期租用，需要审核；

2. 无审核：否则是有限期的租用，无审核。

其他功能不再赘述。有机会再分享给大家。

小结

希望 CloudEngine 能促进云纵开发联调环境和测试环境的并行测试，减小工程师对环境和应用的维护成本，提高技术团队的项目吞吐率。

-EOF-

点击查看《如何从零搭建一个技术平台》。