吕健|Microservices 场景下的持续部署-【黑基网】

内容简介

近两年作者在海外交付中参与microservices下的团队，为客户提升Finance系统的扩展性。作者所在团队，3对开发（pairprogramming，2个dev为pair）为客户支撑着11个services，持续部署流水线（CDpipeline）是其中必不可少的一个技术实践。本次分享作者将从实践的角度分享microservices架构下的持续部署（CD）。内容概述

1.microservice概述：简要介绍microservice架构下的挑战
2.持续部署实践：这里会提到『BuildPipelineasCode』，『InfrastructureasCode』等概念。
3.持续部署了之后呢？这里会介绍CD结合团队的敏捷开发流程的实践经验。

microservices概述

当提到microservice的时候，我们通常会从下图开始：

为了从业务和技术方面得到更好的扩展能力，我们将单一架构的系统(Monolithicarchitecture)，拆分成若干的微服务(Microservicesarchitecture)，这种拆分是架构演进的一个过程。在整个拆分过程中，对团队的组织架构，数据的管理方式，部署监控技术方面都带来极大的挑战。持续部署（简称CD）是microservices架构中一个必备的实践之一。本文将介绍基于Docker的CD方式。

部署方面带来的挑战

单一架构下(Monolithic)，我们的系统Codebase可以在一个项目中，这个系统采用一个持续集成（简称：CI）pipeline，并且此时我们也可以采用持续集成（简称：CD）pipeline，最终将系统持续部署到生产环境中。在这种情况下，每当系统引入一个改变的时候，CI，CDpipeline都会执行一次。例如：

-10minsUnitTest
-2hoursAcceptanceTest
-15minspackage
-20minsdeployment

上面列举的例子并不算坏，更庞大的系统可能会需要更多的时间。当我们将Monolithic系统拆分成多个microservices时，并且将每个services进行独立部署。每当系统引入一个改变的时候（codechange），它只会影响个别service，我们只需要部署发生改变的部署，从新运行一个service的CI，CDpipeline：

-1minsUnitTest
-1minsIntegrationtest
-5minspackage
-5minsdeployment

这种拆分之后，更符合我们对解耦的追求：『当代码引入一个改变的时候，它应该影响的改动最小』此时所提到的改变涉及整个开发流程，从代码到部署的影响做到了最小。拆分services之后的代价是，每个service都需要独立部署，我们需要为每个service搭建CDpipeline。在microservices场景下，不同的service按照需求可能会采用不同的技术栈。并且在每次新建service时，配套的日志，监控，报警系统也需要进行配置。这个对CD提出了很大的挑战。

持续部署方面的实践

当我们谈持续部署的时候，此时也会包括持续集成。持续部署的整个过程会从代码push到master开始：

我们采用Docker来解决技术栈差异的问题，DevOps创建部署工具将部署，监控，报警等配置模板化。实践：

-使用Docker构建和发布service
-采用DockerCompose运行测试
-使用Docker进行部署

准则：

-BuildpipelineasCode
-InfrastructureasCode(baseonAWS)
-共享构建脚本

使用Docker构建和发布service

-使用Docker构建service，service已dockerimage的方式发布
-将docker发布到dockerregistry
-从dockerregistry上pulldockerimage进行部署

使用DockerCompose运行测试

DockerCompose可以将多个dockerimage进行组合。有些service需要访问数据，我们可以通过dockercompose将serviceimage和databaseimage组合在一起。组合之后，我们可以采用dockercompose运行持续集成。下面这个实例展示如何进行这种组合：https://gist.github.com/lvjian700/7c295e6a596e96526049f831d0eb8b13#file-docker-compose-yml

BuildpipelineasCode

通常我们使用Jenkins或者Bamboo来搭建CI/CDpipeline，每次创建pipeline需要进行大量的手工配置，此时很难自动化CI服务器配置。BuildpipelineasCode，即使用代码来描述pipeline，这样做可以带来非常好的可读性和重用性。我们可以很容易的做到CI服务器配置。今年团队将所有pipeline从Bamboo迁移到了BuildKite。在BuildKite上可以使用如下代码描述上图的pipeline：https://gist.github.com/lvjian700/7c295e6a596e96526049f831d0eb8b13#file-buildkite-yml

InfrastructureasCode

如果我们要发布一个基于HTTP协议的REST-fulAPIservice，我们需要service准备如下基础设施（Infrastructure）：

-可部署的机器
-机器的IP和网络配置
-设备硬件监控服务（GPU，Memory等）
-负载均衡（LoadBalancer）
-DNS
-AutoScaling（services自动伸缩服务）
-Splunk日志收集
-NewRelic性能监控
-Sentry.io和PagerDuty报警

这些基础设施的搭建和配置我们希望将其模板化，自动化。我们才用代码描述基础设施，DevOps提供工具模板化基础设施的描述。实践：

-采用AWS云服务进行部署
-采用AWSCloudFormation描述和创建资源
-将对资源操作的脚本进行sourcecontrol

准则：

-对资源的描述和操作应该在git中
-在所有环境中采用相同的部署流程
-使用ssh等手动操作资源的方式，只能用于测试环境和做一些debug。

共享构建脚本

在为多个services搭建CDpipeline之后，我们将CDpipeline归纳为三部：

1.运行测试
2.构建发布dockerimage
3.部署

分别为这三步提取出shellscripts：

1.test.sh
2.docker-tag.sh
3.deploy

吕健|Microservices 场景下的持续部署