从0开始搭建一个微服务的持续交付系统，教你如何快速搭建

本文介绍了如何利用开源软件快速搭建一套微服务的持续交付系统。本文假设的环境是Linux操作系统，用到的软件包括Git、Jenkins、Salt、ZooKeeper、Apache等。开始之前，我先简单介绍下持续交付和微服务的概念，以便大家更好的理解本文的精华。

什么是持续交付?我们先举个物流的例子，现在各大电商都非常重视物流的自动化建设，在实现包括运输、装卸、包装、分拣、识别等作业过程的设备和设施自动化的同时，更在研究无人机和自动驾驶汽车送货，达到物流的全自动。

那么软件开发呢，从开发人员check in代码到代码仓库，到代码的构建、部署、测试、发布，我们可以形象地把这个过程称为“软件物流”，现实世界的物流实现了相当的自动化，“软件物流”也应如是，实现从开发人员check in代码(客户下单)到生产系统上线(送货上门)的自动化。

说到这里，我们可以给持续交付下一个“非专业”的定义，持续交付就是实现“软件物流”的自动化。

图1.持续交付流水线

图1摘自《持续交付：发布可靠软件的系统方法》，展示了持续交付具体包括的内容。本文重点讨论如何实现微服务的持续交付流程，所以会忽略掉整个流程的一些细节(如代码分析、单元测试等等)。

那什么是微服务呢?微服务的概念最初由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。目前微服务的主流实现方式有两种：RESTful API和消息队列。

图2 RESTful微服务

图3 message queue微服务

图2、图3是两种典型微服务架构的简略图。当然现实中的系统会复杂的多，比如会有微服务聚合，多级缓存，注册中心等。

微服务相对单体式应用来说有明显的好处：

1. 解决了单体式应用的复杂性问题，单个微服务很容易开发、理解和维护。
2. 每个微服务都可以由独立的团队来开发，可以自由选择开发语言。
3. 每个微服务可以独立部署，系统可以快速演进。
4. 可以对每个微服务进行独立扩展，极大的提高系统伸缩性及资源利用率。

但在一个单体式应用拆分成数十个乃至上百个微服务，由于服务数量的增加，以及微服务支持多种编程语言的特性，对软件的构建，部署，测试，监控都带来了全新的挑战。本文将讨论如何通过持续交付来降低微服务构建，部署的复杂度。

微服务的持续交付：统一方法

由于微服务的特性，微服务的持续交付会比单体式应用的持续交付复杂的多。本节列出了为了降低微服务持续交付的复杂度，我们遵循的一些原则：

1. 统一方法。这里有两个层面的含义，第一是流程的统一，有很多公司对运维自动化非常重视，但在开发，测试阶段没有采用自动化的方法。随着DevOPS运动的兴起，大家逐渐意识到需要在开发，测试阶段采用与生产环境相同的交付方法，这样在系统部署到生产环境的时候，这一交付流程已经经过多次的检验，出错的概率大大降低了。第二层含义与微服务相关，各个微服务可能用不同的语言实现，如Java、Python、C++、Golang、纯前端(JavaScript)，我们要对采用不同语言实现的微服务使用统一的交付方法。
2. 在版本控制系统中，每个微服务应该对应一个独立的仓库。以Git为例，一个Project下面，每个微服务对应一个独立Repository。这样各个微服务可以独立check in代码，而不会在持续构建的时候互相影响。
3. 设计持续交付系统时要考虑实现软件交付的全自动化，虽然在现实中，会存在提交测试，生产变更审核等人工环节。但在理想情况下，开发人员check in 代码之后，能够自动触发构建，多套环境的部署及测试。
4. 支持单个微服务升降级，这要求持续交付系统，对每个可部署的单元(微服务)要有独立的版本号。
5. 程序与配置分离。要支持一套程序(可执行包+配置文件包)多处部署，这里强调了一套程序，是指在开发人员check in代码后，构建系统只生成一份程序(可执行包+配置文件包)。不管是部署到开发环境，测试环境，还是生产环境我们要用同一套程序，而不是对每个环境单独打包。我们知道Java war包会要求把配置文件包含在里面，这会造成不同的环境要求提供不同的war包，这就违反了我们说的这个原则，后面我们会讨论如何处理这个问题。
6. 在应用程序部署时，不得依赖外网资源。我们把部署过程独立为两个阶段：环境准备阶段和应用程序部署阶段。环境准备包括操作系统，JDK或其他语言运行时系统级依赖库的安装，得益于IaaS的相对成熟，我们把这一阶段独立出来。而应用的部署需要定制化，也是本文讨论的部分。在部署应用时，要求所有的资源从内网获得，这样可以保证应用部署过程的快速、稳定、可重复。

快速搭建微服务的持续交付：持续构建

下面我们结合一个虚构的项目来介绍持续交付的实现细节，假设我们有一个项目BetaCat，由ms1、ms2…msN，n个微服务构成。下面我们重点介绍ms1微服务如何实现持续交付，其它微服务可以类推。

本节讨论下如何实现持续构建，下一节会探讨持续部署。

图4 Jenkins处理仓库代码流程

（编辑：ASP站长网）