本文根据DCOS联盟第3期线上分享整理而成
姜冲
DaoCloud高级软件工程师
Docker Contributor，负责公有云构建服务、DaoShip的设计与研发。
对微服务架构设计与实现有着丰富的理论与实践经验。
大纲：
正确构建镜像的目标和所需资源，以及如何规划和构建服务；
基于优良的微服务架构设计及网络层优化，为数十万用户的服务使用提供稳定高速的构建能力；
不同运营需求下的技术架构演进；
微服务带给客户的价值。
DaoShip 作为 DaoCloud Service 的一个基础组件，提供了利用 Docker 技术实现的代码构建、代码测试和持续集成功能，是基于云端的的 DevOps 工具，因为多租户安全隔离和高可用性的需要，从早期就采取了今天看来成为潮流的微服务设计。
这里应该很多人用过 jenkins 或者 travis ci 等持续集成服务。
无论何种构建服务或者集成服务，源代码是必不可少的，都会对接各种源码托管服务。针对国内用户，我们需要支持国外的 GitHub、Bitbucket、国内的 Coding 和企业内部自建的 GitLab 的源代码托管服务。我们会在这些代码仓库上设置 webhook，这样用户一推送代码，我们就能立刻开始自动化构建。
另外，对于每一次构建，用户最关心的莫过于结果，是成功还是失败，以及如果失败原因是什么。所以我们还得提供清晰的构建日志，方便用户查错。
内部实现上，由于我们面对的是众多不同的用户，还必须能多租户隔离，让不同用户的任务不会相互影响。容器技术出现前，我们需要起一个个虚拟机，来跑不同的任务，隔离程度最好。但是这样做，消耗资源大，而且启动时间长，在主机资源少的情况下，任务会排期长队，每个任务都需要等待很长时间。
Docker 的出现，使得我们可以秒级启动，同时资源消耗大幅下降，一台主机可以同时启动多个构建任务，所有任务全部容器化。
针对以上 3 点，我们总结下构建服务的基本目标：
集成代码托管服务；
提供清晰的构建日志；
隔离构建任务。
在初期我们的构建服务就是这样的：
有如下 3 个特点：
单机部署模式，单体应用。
应用太复杂，降低开发速度。因为所有模块都运行在一个进程中，任何一个模块中的一个 bug，比如空指针引用，将会弄垮整个进程，有单点故障。并且无法扩展，只有有限的服务能力。DaoShip API 中使用 docker daemon 做构建的模块（builder）更新频繁，但是每次更新，必须把 DaoShip API 整个更新。
调用本地 Docker Daemon。
这不是一件好事，构建全在本地，用户进程会影响 API 的性能。比如用户构建一个 node 应用，npm install 会分分钟把内存和 CPU 吃满。
Docker 的每次更新，都会带来很多新功能，解决大量 bug。通常我们会评估下，然后将新版本 Docker 引入到我们的构建服务里，为用户带来新的 Docker 功能。然而 DaoShip 内部与 docker daemon 的深度耦合，我们需要引用新的 docker api，修改这部分代码，然后再经历完整而漫长的测试，最后才能提心吊胆地上线。整个过程复杂而冗长，还无法保证质量。
日志存本地文件，可能因为主机故障而丢失，或者磁盘爆满，导致服务中断。
针对上面 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 点显而易见的益处：
通过分解巨大单体式应用为多个服务方法解决了复杂性问题，服务边界清晰，组件之间通过 rest api 和消息队列进行通信。
这种架构使得我们的每个服务都可以有专门开发团队或者人员来开发。即使某个服务的同事离职，也不会影响其他服务的开发，同时由于服务足够简单，新的同事可以快速上手掌握。
微服务架构模式下每个服务可以独立部署，每个组件都能单独快速测试发布。小步迭代，敏捷开发下，现在我们可以做到时刻无感知上线，一个小 bug 修复可以在 10 分钟内做到从编码到测试到上线。
微服务架构模式使得每个服务可以独立扩展。在偶尔的构建压力暴增情况下，我们可以快速扩展 builder，以符合服务需求。
今天我主要分享了 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的软件源，并实现更加高效快速构建。
原文发布时间为：2016-12-12
本文来自云栖社区合作伙伴DBAplus
