本文根据DCOS联盟第3期线上分享整理而成

姜冲

DaoCloud高级软件工程师

 

• Docker Contributor，负责公有云构建服务、DaoShip的设计与研发。

• 对微服务架构设计与实现有着丰富的理论与实践经验。

大纲：

DaoShip 作为 DaoCloud Service 的一个基础组件，提供了利用 Docker 技术实现的代码构建、代码测试和持续集成功能，是基于云端的的 DevOps 工具，因为多租户安全隔离和高可用性的需要，从早期就采取了今天看来成为潮流的微服务设计。

这里应该很多人用过 jenkins 或者 travis ci 等持续集成服务。

无论何种构建服务或者集成服务，源代码是必不可少的，都会对接各种源码托管服务。针对国内用户，我们需要支持国外的 GitHub、Bitbucket、国内的 Coding 和企业内部自建的 GitLab 的源代码托管服务。我们会在这些代码仓库上设置 webhook，这样用户一推送代码，我们就能立刻开始自动化构建。

另外，对于每一次构建，用户最关心的莫过于结果，是成功还是失败，以及如果失败原因是什么。所以我们还得提供清晰的构建日志，方便用户查错。

内部实现上，由于我们面对的是众多不同的用户，还必须能多租户隔离，让不同用户的任务不会相互影响。容器技术出现前，我们需要起一个个虚拟机，来跑不同的任务，隔离程度最好。但是这样做，消耗资源大，而且启动时间长，在主机资源少的情况下，任务会排期长队，每个任务都需要等待很长时间。

Docker 的出现，使得我们可以秒级启动，同时资源消耗大幅下降，一台主机可以同时启动多个构建任务，所有任务全部容器化。

针对以上 3 点，我们总结下构建服务的基本目标：

在初期我们的构建服务就是这样的：

有如下 3 个特点：

针对上面 3 点，我们做了两件事。

首先日志使用单独的分布式文件存储。其次分离处理构建的模块 builder，每个 builder 都部署在不同的主机上，直接接受 API 下发的任务。

图上展示的各个模块都支持独立横向扩展，似乎不会有单点故障。但是由于 API 是使用 Golang Channel 管理构建任务的，没有健壮的调度器，存在盲目调度的问题，一个 builder 很空闲，而另一个 builder 接受了很多任务可能很忙，导致宕机无响应。而 builder 一停机上面的任务会全失败，任务不会被重新调度，这问题严重影响用户体验。另外我们无法方便有效的更新 builder，由于 builder 几乎时刻都有任务在跑，我们必须等到夜深人静的时候，才能去更新，这样做非常麻烦。

所以为了解决盲调度和错误率高的问题，我们加了一个单独的调度器，做任务的调度。

调度器会把任务扔到任务队列里，builder 则根据自身的任务压力，去从任务队列中取任务。如果压力大，会隔很久才会取一个任务，保证发挥机器最大的性能。builder 还会发送心跳，如果某台 builder 失联或者宕机，其上的任务会被标识为需要重新调度，调度器识别出就会将任务重新扔入任务队列，等待新的 builder 来取。这样我们可以频繁更新，不用担心 builder 失联，同时构建错误率大幅下降，用户体验大幅提升。

随着产品迭代和体验提升，用户量急剧上升。用户量上来后，我们发现构建集中某几个时间段，比如下午1点到晚上 8点，都是构建的高峰期，而其它时间段构建很少。如果我们按高峰期来分配 builder 的数量，到低峰期时，资源会过剩，浪费严重。相反按低峰期分配 builder 数量，到高峰期，我们的任务会大量阻塞。所以这里我们还实现了根据 builder 的平均压力来自动扩展弹性伸缩，按需创建 builder。

另外根据收费计划，不同的用户有不同的套餐，比如专业版使用更好的构建机。同时我们的构建也分区为北京 BGP 和国外执行环境。所以我们还得能够根据用户的套餐和配置，把任务分配到不同的集群中。我们在调度器上建了一个任务派发器，把不同类型的任务派发到不同的构建集群。

加入健壮的任务派发器和弹性伸缩构建集群后，随着更快的功能迭代，逐渐形成了今天的架构，如上图所示。在运营增长和功能迭代的要求下，我们始终坚持微服务化，不断迭代升级 DaoShip，各个服务之间有明确的界限，职责也非常清晰。在整个架构演进中，微服务化给我们带来如下 4 点显而易见的益处：

今天我主要分享了 DaoShip的微服务架构是如何演进的，其中的技术细节下次我们再深入探讨。

Q1：你们微服务分解有什么经验吗？或是有什么方法吗？你们是怎么分解的？

A1：这个问题非常好，相信很多工程师都非常关心。说实话，我们公有云构建服务这一块，您已经看到了，由于我们没有很多的历史包袱，所以涉及到的服务拆分比较少，属于服务演进的范畴，少量的服务拆分也是在一开始的架构设计松耦合的方式下，成功演进。

Q2：宿主的Docker更新你们有做吗，如果做，要怎么在不停机的状况下做呢？

A2：Docker更新更是一个非常切实际的话题。我们目前的策略是：我们的 builder 是自动去取任务的，所以更新时，会让builder 停止取任务，然后上面的任务完成后，我们再更新Docker 。

Q3：你们的微服务主要存在哪个环节？

A3：关于微服务存在于哪些方面，这个问题。我们的认识是这样的。我们在镜像构建这边，尽管没有涉及到市面上的dubbo，zuul，APIgateway等内容，主要是因为本身不是一个复杂的系统，职责较为聚焦，但是整个构建的演进可以认为是具备微服务演进的基本特性，这里5个服务：API服务，日志服务，构建服务，调度服务，分发服务，它们的设计于演进都是结合场景，在需求之下，谋变，求突破，达到预期的效果。我个人的观点是：微服务与代码行数方面没有直接关系。

Q4：Python和node的镜像基本都要安装大量的包，IO的占用很大，你们在docker这边有什么优化吗？

A4：“Python和node的镜像基本都要安装大量的包，IO的占用很大，你们在docker这边有什么优化吗”。这又是一个实际过程中经常会遇到的问题。首先第一点，我们完完全全尊重用户编写的Dockerfile，其次在这基础上满足用户对构建高效，快速的需求。网络IO方面，我们采用两条线，一条国内，一条国外，一经发现用户构建涉及国外源，即分发至国外的构建机器。磁盘IO方面，我们全部采用的是SSD。因此，您可以发现，我们首先会从硬件基础设施层满足用户的需求。

Q5：目前这个架构中，还有没有可改进的地方？

A5：很好的话题。首先第一点，我们的架构肯定会跟着客户的需求来走，目前，我们这套可以服务20w用户的构建任务，日构建量达到15k，当前运行非常稳定。第二点，架构改进方面，我们后续计划在构建的自学习方面引进一类新的服务，即如何更好的帮助用户识别出Dockerfile的软件源，并实现更加高效快速构建。