微服务架构的持续集成交付

《微服务架构的持续集成交付》由会员分享，可在线阅读，更多相关《微服务架构的持续集成交付（8页珍藏版）》请在装配图网上搜索。

1、-WORD格式-可编辑-专业资料-微服务架构的持续集成交付首先介绍下微服务架构的优势与劣势。相较于单体应用来说，微服务架构有这么几个优点：1. 易于开发、理解。由于每个服务只负责单一功能，开发者可以聚焦于自己负责的几个服务模块， 对于其他服务，只需要理解接口即可。当然，单体应用经过良好设计也可以达到这个效果，但是，与单 体应用的进程内通信或单机内的进程间通信不同的是，微服务的各服务之间一般采用RESTfulAPI或者 异步消息队列进行通信，无论RESTful接口还是异步消息队列都是开发语言无关的，极易理解的通信方 式。2. 全局稳定性提高。由于每个服务负责的功能单一，各服务的资源需求也相对更低

2、。从而可以选择 将服务分散的部署到多台中低配的服务器上，而不是一台高配的机器上。如果某个机器上的服务故障， 譬如说内存泄漏，故障只会影响该机器上的某一个或几个服务，对全局影响不大。3. 不受限于任何技术栈，极大的提高团队搭建的速度。这一点对初创公司尤为重要，组建开发团队 对初创公司来说本来就是个头疼的问题，如何还要求团队的技术栈一致，招聘难度可想而知。但是，如 果产品架构采用微服务架构，那么我们可以允许不同的服务模块采用不同的技术栈，只需要定义好对外 接口即可。4. 局部的修改很容易部署，从而大大的提高了功能的交付效率。说完了微服务架构的优点，我们再来讨论下其缺点或者说复杂的地方：1. 如何确

3、定软件功能切分的粒度，边界。太多的微服务模块会导致服务间通信成本和运维成本的增 加，过犹不及；但是若粒度过大，又违背了微服务的初衷。2. 多种技术栈（譬如 C， Java， Python， Scala 等）我们需要为每种语言准备编译环境，运行环境 等，增加了维护成本。这个可以通过Docker隔离来解决，我们后面会详细展开。3微服务模块多了，会导致全局的上线次数变多，从而需要更复杂的版本管理和Bug跟踪等，间 接导致项目管理成本增加。IRIVER WEB UVFAS&EiMGHMAMA 口 EIMEHTTRHRM ANACHM-LKiTBILLINGRESTF*MEhTT3持续交付持续集成和交付

4、(CI/CD)是一种软件开发实践，使用得当，它会极大的提高软件开发效率并保障软 件开发质量；持续集成和交付分为持续集成和持续交付两部分，这里我们不再具体探讨这两者的区别， 统一按持续交付来处理。Jenkins是一个开源项目，它提供了一种易于使用的持续集成系统；除Jenkins 外，常见的持续集成系统还有：Travis: https:/travis-Codeship: Stridercd: 另外，常见的交付方式一般有：1. 源代码交付: 源代码交付需要将源代码以 tar 包等方式 download 到服务器，然后在服务器上 借助程序的构建脚本去构建可执行程序，显然这种方式会经常因服务器环境差异，

5、构建环境初始化失败 等问题导致无法构建可执行程序。严重依赖于构建脚本的完备程度。2. Linux 标准包交付: 将项目的依赖通过 Linux deb 或者 rpm 来管理，由于这种方式更符合 Linux 规范，间接的提高了项目在服务器上部署的成功率，但是有些时候仍然需要解决包冲突问题。3. 虚拟镜像交付: 虚拟镜像交付指的是我们将项目在虚拟机里测试成功后直接将该虚拟镜像部署 到服务器上。显然，这种方式部署成功率接近100%而且隔离性好。但是随之而来的问题就是虚拟镜像本 身对服务器资源的消耗。4. docker image 交付： docker image 交付是虚拟镜像交付的进一步演进，在保证

6、系统隔离的同 时，docker image对服务器的资源消耗更低。当然，docker的隔离机制是进程级别的，可能不适合一 些强隔离场景。我们团队目前正在使用这种方式进行交付。Integration TestsDeploymentpldtf0rm&amazon上图（图片来自于网络）展示了围绕 Docker 镜像仓库的持续交付流程：1首先开发者将代码推送到代码仓库，譬如git hub2. 代码仓库的更新会触发新的代码构建，生成新的 docker 镜像并推送到 docker 镜像仓库3. 接下来会基于新的 docker 镜像进行集成测试4. 测试通过后，docker镜像被交付到公有或者私有云上通过上

7、述持续交付的方式交付微服务架构的软件，能够很好的解决前面提到的第二与第三个问题， 即1. 结合 Docker 解决多技术栈的环境维护问题；2. 按微服务模块交付来提高软件的交付效率3. 引入“版本服务”来可视化各微服务的版本信息4. 引入“ReleaseNote服务”来发布各微服务的feature更新实践微服务架构有多种，数人云的微服务架构有如下特点：1. RESTAPI 与 消息队列 结合使用。微服务与外部用户通过 RESTAPI 通信，内部微服务之间通过 消息队列通信。2全部Docker交付，这解决了多技术栈的环境维护问题。3个微服务对应于一个持续交付的Job,这保证了各服务在交付环节无相

8、互依赖，单独触发。同 时可以利用不同的 Docker 镜像为不同的 Job 提供相应环境。4. 版本信息自动更新5. ReleaseNote 自动发布6. 构建环境 Docker 化，与底层隔离，保证宿主机环境的一致性，降低运维成本7. 利用 Dockercompose 维护本地开发环境，从而实现开发环境与生产环境的逻辑一致性数人云的架构设计模式如图所示。用户通过浏览器或者直接通过 RESTAPI 与后台通信，后台是一 个微服务集合，对外服务的接口一律采用 RESTAPI， 内部服务之间的接口采用消息队列。各微服务负 责维护自身的状态集，有自己独立的缓存和 DB （如有必要）。微服务本身尽量无

9、状态化，以保证横向 扩展能力。Docker 枫 i 灌件 4D代网玄坷山！ rAA Itfi 4B代們蛛c twr上图是我们目前采用的持续交付架构图。A, B, C, D四个git hub代码库分别存储着四个微服务 的源代码，相应的我们为每一个代码库创建了独立的构建作业，代码更新触发构建时，构建作业将执行 如下的大致步骤：1. 从 Docker 私有镜像仓库拉取相应的构建镜像2从git hub源码库拉取相应代码并挂载到构建容器里，触发特定脚本来执行构建3. 若构建成功，立刻从 Docker 私有镜像仓库拉取相应的 runtime 镜像，将构建成功的可执行程 序 Docker 化成新一版的微服务

10、镜像4. 将上述微服务镜像推送到 Docker 私有镜像仓库若已经设置了自动交付1. 则通过 Marathon 的 RESTful API 接口触发线上微服务的更新2. 更新版本服务里面对应微服务的版本信息3. 自动更新ReleaseNote服务里面对应微服务的ReleaseNote。开发者在实现了相应功能时已经 将对应的 ReleaseNote 放在了代码库特定目录下面（这个后面会详细提到）Me sea 81口*6节点Martig bofi调屋in巳託赵S世的Wl,粗迖直动Jankir*!；& 的弗令今|曲仃执腳|今Mea-oa 爼 I口叭&Xj1jenkls iMaier Frarneor

11、icJankES 的命令翳 *nk.n5 HowMbrothori FromewerkiSEMeso：运行 Jetilctns4. 另外，从架构图中我们可以看出，程序的构建环境和运行环境正在共享同一个 Mesos 资源池， 提高了资源利用率。把 Jenkins 运行在 Mesos 上有如下几个考虑：1. 把 Jenkins 运行到 Apache Mesos 上,或者说利用 Apache Mesos 向 Jenkins 提供 slave 资源, 最主要的目的是利用 Mesos 的弹性资源分配来提高资源利用率。2. 术栈的软件情况下尤其重要，可以极大降低运维成本。3. Marathon会对发布到它

12、之上的应用程序进行健康检查，从而在应用程序由于某些原因意外崩溃 后自动重启该应用。这样，选择利用Mara thon管理Jenkins Mas ter保证了该构建系统的全局高可用。 而且，Jenkins Mas ter本身也通过Mara thon部署运行在Mesos资源池内，进一步实现了资源共享， 提高了资源利用率。关于怎样将jenkins运行在mesos上，大家可以参考我以前在csdn发布的一篇文章 Docker承担了什么角色Docker在整个体系中承担了如下几个角色：各代码库的编译载体： 我们已经提前将各代码库的编译环境制作成了 docker 镜像交付介质: 编译成功的可执行程序将被打包成

13、docker 镜像， 镜像的 tag 对应于程序版本信息Runtime 环境： 运行环境已经被打包到 docker 镜像中了，启动的 docker 容器将作为微服务的 runtime 环境资源隔离： docker 本身支持进程级别隔离，已经满足内部应用需求为了保证单机开发环境与线上环境的配置/架构一致，我们在单机开发环境利用 docker-compose 来编排整个微服务环境，以便于调试版本调试在实践微服务架构时，我们碰到了这么一个问题：各微服务模块频繁交付，如何确认线上各微服务 的版本， 即我们需要对各微服务进行版本控制。目前团队迭代出了如下解决方案：交付成功后，交付job会截取docker

14、镜像里相应的tag （代 表着版本信息），并把该信息推送到一个 NginxServer 的静态文件里面, 前端页面访问该静态文件来 获取相应微服务的版本信息。另外，同一个微服务会部署到开发，测试和生产三个环境上，所以基于不 同的环境，我们会维护三个不同的静态文件 。ReleaseNote 服务在多人协作的微服务项目开发中，由于多人频繁的merge代码，ReleaseNote的管理也会成为团 队的负担。我这里推荐的做法是这样：文档规约：团队达成一个 agreement: 对重大 feature 或 bug-fix 的提交都需要在目录 pending-release 里面创建相应的 markdow

15、n 文件，并将改动添加到里面。这样，我们可以控制交付 Job 在交付时扫描 pending-release 目录并将其中的文本 merge 到一起生成这次交付的 ReleaseNote。git pre-commit-hook:同时，为了避免团队成员忘记这个agreement,我们还可以在本地的 git-precommit-hook 中添加相应的扫描提醒。配置中心服务目前网络上关于配置管理的解决方案已经非常成熟，我这里就不过多解释了。唯一需要提到的就是， 我们的配置中心服务还没有完全融入到整个交付过程中来，微服务的配置文件仍然需要手工介入。持续集成的消息通知显然，团队希望CI服务器在执行了持续集

16、成后能够及时的将集成结果通知团队成员，Jenkins本 身是有 irc notification 插件的，但是国内开发者可能使用 IRC 的并不多；微信是小团队使用比较 多的沟通工具，我们可以使用微信公众号进行消息通知；或者使用国内的 LessChart 等交流工具，它 们本身支持 webhook 调用。开发环境的搭建微服务架构导致软件模块增多，增加了开发环境搭建的难度，同时也导致了团队新成员上手门槛的 提高。我们目前是利用 docker-compose 维护本地开发环境来解决这个问题的。它不仅实现了开发环境 与生产环境的逻辑一致性，同时也可以让相应模块的开发者聚焦于自己的业务，不必纠结于如何

17、启停其 它微服务。下面是我们的 docker-compose 文件的一部分。gmOl ./-f i-xmttkL|Iq 1 one; : /uvir/-Bi*Kira/ri(ii n?t/Trfc1 : ra-./K5inyrip-| BX: /Wt-t/FflifiOQ/sg: nr. ,ci?nit： mQ./FnmurwliXnZikKHan/ia!L/&il c ce rt t Fit a -l t. c r l :! et-c/ralrai/i-sl ccrtl fkease. ere.; nt- ./lmvtHrxlircinirZdr:t3HnnZnl /mm. dalaaan

18、. La-no-ahspfim-B-/tc/rflnxZnni. dac mm =1 口-na-pai hphroa .:re-EtuSitBJ-PPP* vwtrL eiEFkrt:i 凹 41右眄! i/ 局pwdT MAS ：llniu-clMTker-vdiLumu :- g如空 r Ai|.r/*harnfli-|rTK/lit*i i r.PX HHE4t：Z.tL!rnfl,linM/a1VU . umf ! n- .,Fngritnn(i7c nnF/arcHBVR.l/ij.l_Cirrti!f 1-nt I ,:I內 ,c-rfc ; rp =. /fcnt*fid/c4n

19、r/daarawo-fMknop4is-Gpnrd .ky: r4tJJl U EMat LMHn :-(Zi?M*ga 1Ut-fiHH.l.LtriCIi-Wflrvrt s._rsql _I :qLct 5-_fk E i_ L: red! 1” Bnr*tfk chj.- rai 1: rmq-PPFtuLld t - . j*4HH|a-d47pVl i !xqL亠uWhe或hL 三-d1 弘- MFWl C； qMtr*Lc.-Lid?.cwgij ik-rlFS严 F*!:voLiea;_ rPoaBvd tr i u/amapa -.vrt rtcsi .ytmL . al : /vl -fuatvEa/mEiic -ODtirLB叭-a raTEoMda- iiBi-vf eha_rt _L ; rsd k .-E WiJjtftflHJfdb: