微服务架构的持续集成交付7页.docVIP

微服务架构的持续集成交付 首先介绍下微服务架构的优势与劣势。相较于单体应用来说，微服务架构有这么几个优点： 1.易于开发、理解。 由于每个服务只负责单一功能，开发者可以聚焦于自己负责的几个服务模块，对于其他服务，只需要理解接口即可。当然，单体应用经过良好设计也可以达到这个效果，但是，与单体应用的进程内通信或单机内的进程间通信不同的是，微服务的各服务之间一般采用 RESTfulAPI或者异步消息队列进行通信，无论 RESTful接口还是异步消息队列都是开发语言无关的，极易理解的通信方式。 2.全局稳定性提高。由于每个服务负责的功能单一，各服务的资源需求也相对更低。从而可以选择将服务分散的部署到多台中低配的服务器上，而不是一台高配的机器上。如果某个机器上的服务故障，譬如说内存泄漏，故障只会影响该机器上的某一个或几个服务，对全局影响不大。 3.不受限于任何技术栈，极大的提高团队搭建的速度。这一点对初创公司尤为重要，组建开发团队对初创公司来说本来就是个头疼的问题，如何还要求团队的技术栈一致，招聘难度可想而知。但是，如果产品架构采用微服务架构，那么我们可以允许不同的服务模块采用不同的技术栈，只需要定义好对外接口即可。 4.局部的修改很容易部署，从而大大的提高了功能的交付效率。 说完了微服务架构的优点，我们再来讨论下其缺点或者说复杂的地方： 1.如何确定软件功能切分的粒度，边界。太多的微服务模块会导致服务间通信成本和运维成本的增加，过犹不及；但是若粒度过大，又违背了微服务的初衷。 2.多种技术栈（譬如 C，Java，Python，Scala 等）我们需要为每种语言准备编译环境，运行环境等，增加了维护成本。这个可以通过Docker 隔离来解决，我们后面会详细展开。 3.微服务模块多了，会导致全局的上线次数变多，从而需要更复杂的版本管理和 Bug跟踪等，间接导致项目管理成本增加。 持续交付 持续集成和交付(CI/CD)是一种软件开发实践，使用得当，它会极大的提高软件开发效率并保障软件开发质量；持续集成和交付分为持续集成和持续交付两部分，这里我们不再具体探讨这两者的区别，统一按持续交付来处理。Jenkins是一个开源项目，它提供了一种易于使用的持续集成系统；除 Jenkins 外，常见的持续集成系统还有： Travis: / Codeship: / Stridercd: / 另外，常见的交付方式一般有： 1.源代码交付: 源代码交付需要将源代码以 tar 包等方式 download 到服务器，然后在服务器上借助程序的构建脚本去构建可执行程序，显然这种方式会经常因服务器环境差异，构建环境初始化失败等问题导致无法构建可执行程序。严重依赖于构建脚本的完备程度。 2.Linux 标准包交付: 将项目的依赖通过 Linux deb 或者 rpm 来管理，由于这种方式更符合 Linux 规范，间接的提高了项目在服务器上部署的成功率，但是有些时候仍然需要解决包冲突问题。 3.虚拟镜像交付: 虚拟镜像交付指的是我们将项目在虚拟机里测试成功后直接将该虚拟镜像部署到服务器上。显然，这种方式部署成功率接近100%而且隔离性好。但是随之而来的问题就是虚拟镜像本身对服务器资源的消耗。 4.docker image 交付： docker image 交付是虚拟镜像交付的进一步演进，在保证系统隔离的同时，docker image 对服务器的资源消耗更低。当然，docker 的隔离机制是进程级别的，可能不适合一些强隔离场景。我们团队目前正在使用这种方式进行交付。 上图(图片来自于网络)展示了围绕 Docker 镜像仓库的持续交付流程： 1.首先开发者将代码推送到代码仓库，譬如github 2.代码仓库的更新会触发新的代码构建，生成新的 docker 镜像并推送到 docker 镜像仓库 3.接下来会基于新的 docker 镜像进行集成测试 4.测试通过后，docker 镜像被交付到公有或者私有云上 通过上述持续交付的方式交付微服务架构的软件，能够很好的解决前面提到的第二与第三个问题，即 1.结合 Docker 解决多技术栈的环境维护问题； 2.按微服务模块交付来提高软件的交付效率 3.引入“版本服务”来可视化各微服务的版本信息 4.引入“ReleaseNote服务”来发布各微服务的 feature 更新 实践 微服务架构有多种，数人云的微服务架构有如下特点： 1.RESTAPI 与 消息队列 结合使用。微服务与外部用户通过 RESTAPI 通信，内部微服务之间通过消息队列通信。 2.全部 Docker 交付，这解决了多技术栈的环境维护问题。 3.一个微服务对应于一个持续交付的 Job，这保证了各服务在交付环节无相互依赖，单独触发。同时可以利用不同的 Docker 镜像为不同的