DaoCloud 的微服务架构演化实践

Docker 的蓬勃发展为我们带来了很多机遇，国内外诸多云服务的提供者皆投身其中。与此同时，这也促使我们要有更深刻地思考，到底如何将 Docker 落地，才能为用户提供更优质的服务。 DaoCloud 就是这次大潮中的弄潮儿，他们在提供持续部署、微服务支持的过程中，通过不断演化架构，解决了所遇到的各种难题。DaoCloud 联合创始人、研发副总裁郭峰将在 8 月 29 日的 CNUTCon 全球容器技术大会上，分享题为《分布式平台微服务架构演化实践》的演讲，敬请关注。

嘉宾简介

郭峰，CNUTCon 讲师，DaoCloud 联合创始人兼研发副总裁。他 2007 年毕业于同济大学获计算机科学硕士，同年夏天作为第一批员工加入 EMC 中国研发中心。曾担任 EMC 中国研究院云平台的主任工程师，也是中国最早接触 Cloud Foundry、OpenStack 及 Docker 的技术人员，在开源社区拥有很高的声誉。郭峰拥有 20 多项美国专利申请，专长于云平台及服务构建、分布式系统、虚拟化技术、企业应用及数据平台化，曾参与 Spring 框架项目开发，是一名业内顶尖的应用架构专家。

InfoQ：持续交付一直是敏捷的终极目标，DaoCloud 的官网也提出了这样的口号：『让应用交付更便捷』，你们是如何面对不同的行业和技术栈，实现更便捷的交付的？

郭峰：提高用户的持续交付能力，DaoCloud 拥有两大法宝，Docker 容器技术和最佳实践的自动化。以 Docker 为代表的容器技术自 2013 年起在 IT 领域迅猛发展，Docker 之所以受到巨大的关注一个重要的原因就是 Docker 不仅仅是一个容器技术，它还提出了应用的统一交付——Docker 镜像。

基于 Docker 镜像交付的应用，可以跨平台、无差别运行，这一点为持续交付奠定了重要基础。之前企业实施 CI／CD 很难，尤其是在应用微服务化的大背景下，企业应用是由很多个服务组件组成的，由不同开发部门开发的服务组件使用的技术框架都各不相同，对测试部署环境的要求也千差万别，这种差异性使得持续交付流程必须对各个服务组件提供专门的集成，这样不可避免造成实施持续交付非常难，需要企业持续的投入。当我们的应用的交付方式都是容器镜像，运行方式都是容器，那我们就很容易的在多样化的应用组件中找到统一点，持续交付流程中针对不同技术栈的多条羊肠小道，都归结到仅面向 Docker 容器的康庄大道。

不同行业的应用，虽然它们解决的问题、所处的领域都不一样，但是应用的开发测试发布流程却差别不大。DaoCloud 便捷交付的一个关键是在于帮助用户实现“Code to Cloud”全流程自动化，包括代码托管、镜像构建、测试、版本控制、部署到云端等。这样一来，开发者能够把精力集中在核心的代码编写层面，从而实现更快速、便捷地交付应用。

InfoQ：相对于传统的 GAE 式的服务，容器云有什么样的优势？

郭峰：在 DaoCloud 之前，我在 PaaS 领域工作了很多年，当时遇到的最头疼的两个问题，一是为了上云，用户的应用实现需要做适配；二是出现问题，帮用户定位问题很困难。第一个问题是因为缺乏统一标准，各个云对应用的要求不一样，在本地可以跑的应用在云上不能跑，在一个云上能跑的应用在另外一个云上不能跑，这无疑会提高用户应用上云的门槛。第二个问题是 PaaS 平台要承载各种不同语言不同框架编写的应用，一旦用户的应用在你的平台起不来或者出现问题，虽然绝大部分问题都是应用自己的问题导致的，但是你不得不深入应用实现去帮助用户定位问题，这对云应用的管理维护带来了巨大挑战。 基于容器的应用云平台从根本上解决了这两大难题，容器的跨平台无差别运行的特性使得只要用户的应用容器在本地可以跑，调度到云端后肯定可以跑，而且跑出来的应用行为是一致的。这样，应用上云不需要做适配，本地可以跑，无需修改轻松云化，而且 PaaS 平台不需要在关心应用实现细节，仅需对容器负责，用户和 PaaS 云平台的接口被统一到了容器上。

InfoQ：你们在自动化运维领域有哪些实践？

郭峰：随着 DaoCloud 平台规模的扩大以及提供服务的多样化，我们的部署规模已经由初期的几台服务器发展到了横跨 4 个数据中心的大规模混合云部署，这对 IT 运维管理，实施质量和响应速度都提出了很高的要求，传统的人工运维方式不仅运维质量不能保证，而且响应时间也不能满足平台动态弹性需求。
尤其是作为一个初创企业，人少事多不可避免，这也倒逼我们仅有的半个运维人员（一半时间是开发）摸索了一套标准化，自动化运维流程。首先，DaoCloud 平台是有超过 40 个微服务组成的，各个服务所使用的编程语言和技术框架各有不同，为了从各个语言的差异性中解脱出来，我们要求所有的 DaoCloud 平台组件都是 Docker 化部署的，组件的开发人员的职责延伸到组件整个生命周期，开发人员不仅要对代码负责，还要提供一整套支撑组件运行的配置，包括容器镜像，Docker Compose 描述文件等，这样运维能力仅需要围绕容器生命周期管理进行。其次，平台弹性扩展过程完全自动化，对于一个云平台，平台的弹性扩展是平台运维的最常见的任务之一，扩展自动化不仅能够更快响应弹性需求而且还减少了人为操作失误的可能性，当然这个也对云平台的实现提出了挑战，支持弹性的组件以及其他相关组件，要支持服务注册和自发现。

InfoQ：对于部署在 DaoCloud 上的应用，是如何得到安全保障的，DaoCloud 提供了哪些监控手段？

郭峰：首先，容器技术本身就会对现有应用的安全性起到一定的增强，在容器中运行的应用拥有完全独立的进程树，文件系统以及命名空间，再加上容器使用资源的限制，使得应用容器间互相影响的可能性降到最低。其次，在网络层面我们还采用了白名单安全策略，仅平台允许的访问请求才会被分发到应用容器中，同时容器间的访问也是被严格限制的。最后，为了应对公有云上的各种恶意应用，平台会实时监控容器的运行状态，一旦发现可疑应用容器，就会触发自动化应对策略，谨防恶意应用影响其他用户应用容器。

InfoQ：分布式的应用，如何在 DaoCloud 上得到统一的日志服务？

郭峰：应用日志是检查应用状态，排查问题的重要依据，提供应用日志是应用云平台必须要提供的一个功能，同时也是一个很大的挑战，尤其是面对一个分布式应用，应用由多个容器组成，容器分布在不同的部署节点上，我们不仅要保持 log 的实时性还要高效准确的归集属于相同应用不同容器产生的日志。我们的做法是所有容器的日志通过标准化的 syslog 协议发送至一个专门的日志收集组件，这个组件能够高效分析处理日志元信息，根据应用对日志做归集并添加必要元信息，再存放在支持高速查询的日志存储系统中。当用户查看应用日志时，通过日志存储系统查询应用日志，从而实现高效统一的日志服务。

InfoQ：对于部署在 DaoCloud 上的应用，是如何得到伸缩性支持的，是否有良好的容错机制？相比 Mesos，DaoCloud 有哪些实践？

郭峰： DaoCloud 的开发团队中有不少成员，包括我个人，都有丰富的云平台架构设计相关经验，DaoCloud 平台从设计的第一天就考虑了对应用伸缩性的支持，不仅能做到便捷的不终止服务前提下的应用弹性伸缩，还在应用容器放置策略上考虑了很周详的容错机制，把应用当机的可能性降到最低。首先，容器放置策略上，我们尽量把应用的不同容器放置在不同的可用区中，相同可用区中的容器也尽量分布在不同的部署节点上，这样当某个意外发生时，把应用受影响的容器控制在一定范围内，保证了应用不当机。同时，我们还实时监控应用的容器状态，当发现容器状态和期望的不一致，自动触发应对策略，保证应用容器按照计划运行。

InfoQ：你们是如何解决 Docker 在网络资源隔离和安全上的不足的？

郭峰：我们在平台层，对 Docker 做了不少补充，一方面，在网络层面我们采用了白名单安全策略，仅平台允许的访问请求才会被分发到应用容器中，同时容器间的访问也是被严格限制的；另外一方面，我们对容器使用资源进行了更全面的实时监控，尤其是对目前 Docker 本身不能限制的部分资源，做到发现异常自动应对。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。