微服务之部署

如何在细粒度的架构中更好的微服务。这里会从持续集成和持续交付说起。

1.持续集成简介

CI(Continuous Integration , 持续集成)

CI能够保证新提交的代码与已有的代码进行集成,从而保证所有人保持同步。CI服务器会检测到

代码已提交并签出,然后花些时间来验证代码是否通过编译以及测试能否通过。

作为这个流程的一部分,我们经常会生成一些构建物(artifact)以供后续验证使用。

理想情况下,这些构建物应该只生成一次,然后在本次提交所对应的所有部署环节中使用。

CI的好处很多。通过它,我们能够得到关于代码质量的某种程度的快速反馈。

CI可以自动化生成二进制文件。用于生成这些构建物的所有代码都在版本的控制之下,

所以如果需要的话,可以重新生成这个版本的构建物。通过CI我们能够从已部署的构建物回溯到

相应的代码,有些CI工具,还可以使这些代码和构建物上运行过的测试可视化。

持续集成允许我们更快速,更容易的修改代码。

有人任务使用了CI工具就算采用了CI这个实践,事实上,只有工具是远远不够的。

测试别人是否真正理解CI的三个问题?

  • 你是否每天签入代码到主线?

你应该保证代码能够与已有代码进行集成

  • 你是否有一组测试来验证修改?

如果没有测试,我们只能知道集成后没有语法错误,但无法知道系统的行为是否已经被破坏。

没有对代码行为进行验证的CI不是真正的CI。

  • 当构建失败后,团队是否把修复CI当做第一优先级的事情来做?

绿色的构建意味着,我们的修改已经安全地和已有代码集成在了一起。红色的构建意味着,最后一次修改很可能有问题,

这时只能提交修复构建的代码。

2.把持续集成映射到微服务

前面已经提到过,每个微服务应该能够独立于其他服务进行部署。

所以如何在微服务、CI构建及源代码三者之间,建立起合适的映射呢?

最简单的做法,如下

图 6-1 把所有微服务放在同一个代码库中,并且只有一个构建

这种方法从表面上看比其他方法要简单的多:因为你需要关心的代码库比较少,

而且从概念上来讲,这种构建也比较简单。开发者的工作也得到了简化:

我们只需要提交代码即可,如果需要同时在多个服务上工作的话,一个提交就能搞定。

在同步发布(lock - step release)中,你需要一次性部署多个服务。

一般来讲,我们绝对应该避免这个模式,但是在项目初期是个例外。

当仅有一个团队在所有的服务上工作时,这种模式在短时间内是可接受的。

这种模式存在很多明显的缺点。

如果我仅修改了图6-1中用户服务中的一行代码,所有其他服务都需要进行验证和构建,

而事实上它们或许并不需要重新进行验证和构建,所以这里我们花费了不必要的时间。

更糟糕的是,我不知道那些构建物应该被重新部署,哪些不应该。

使用这种方式的组织,往往都会退回到同时部署所有代码的模式,而这也正是我们非常不想看到的。

很不幸,如果这一行的修改导致构建失败,那么在构建得到修复之前,其他服务相关的代码也无法提交。

这种方法的一个变体是保留一个代码库,但是存在多个CI会分别映射到代码库的不同部分。

如图 6-2

这种模式是个双刃剑。

一方面它会简化检出/检入的流程,但是另一方面,它会让你觉得同时提交对多个服务的修改

是一件简单的事情,从而做出将多个服务耦合在一起的修改。

但是相对于只有一个构建的多个服务来说,这个方式已经好很多了。

还有一种比较好的方式,每个微服务都有自己的CI,这样就可以将该微服务部署到生产环境之前做一个快速的验证。

如图6-3

这里的每个微服务都有自己的代码库,分别于相应的CI绑定。

当对代码库进行修改时,可以只运行相关的构建以及其中的测试。

每个微服务都有自己的代码库和构建流程。

我们也会使用CI构建流程,全自动话的创建出用于部署的构建物。

3. 构建流水线和持续交付

把一个构建分成多个阶段是很有价值的。

因为有的测试运行快,涉及范围小,有的测试运行耗时,涉及范围广,

如果放一起,快速如果失败,还会接着运行耗时的测试,这样就不合理。

解决这个问题的一个方案是,将构建分解成为多个阶段,从而得到我们熟知的构建流水线。

在第一个阶段运行快速测试,在第二个阶段运行耗时测试。

构建流水线可以很好的跟踪软件构建进度:每完成一个阶段,就离终点更近一步。

流水线也能够可视化本次构建物的软件质量。构建物会在整个构建的第一个环节生成,

然后会被用在整个流水线中。

CD(Continuous Delivery, 持续交付)基于上述概念,并在此之上有所发展。

CD能够检查每次提交是否达到了部署生成环境的要求,并持续地把这些信息反馈给我们,

它会把每次提交当成候选发布版本来对待。

为了更好的理解这些概念,我们需要对从代码提交及部署到生产环境这个过程中,所需要经历的流程进行建模,

并知道哪些版本的软件时可发布的。

UAT(User Acceptance Testing, 用户验收测试)流程。

通过对整个软件上线过程进行建模,软件质量的可视化得到了极大改善,这可以大大减少发布之间的间隔,

因为可以在一个集中的地方看到构建和发布流程,这也是可以引入改进的一个焦点。

在微服务的世界,我们想要保证服务之间可以独立于彼此进行部署,所以每个服务都有自己独立的CI.

不可避免的例外

所有好的规则都需要考虑例外。

当一个团队刚开始启动一个新项目时,尤其是什么都没有的情况下,你可能会花很多时间来识别出服务的边界。

所以在你识别出稳定的领域之前,可以把初始服务都放在一起。

在最开始的阶段,经常会发生跨服务边界的修改,所以时常会有些内容移入或者移出某个服务。

在这个阶段,把所有的服务都放在一个单独的构建中,可以减轻跨服务修改所带来的代价。

当然,在这个阶段你必须把所有服务打包发布,但这应该是一个过渡步骤。

4.平台特定的构建物

大多数技术栈都有相应的构建物类型,同时也有相关的工具来创建和安装这些构建物。

Ruby中有gem,Java中有JAR包和WAR包,Python中有egg。

但是,从微服务部署的角度来看,在有些技术栈中只有构建物本身是不够的。

所以为了部署和启动这些构建物,需要安装和配置一些其他软件,再启动这些构建物。

自动化可以对不同构建物的底层部署机制进行屏蔽。

5.操作系统构建物

有一种方法可以避免多种技术栈下的构建物所带来的问题,那就是使用操作系统支持的构建物。

举个例子,对基于RedHat或者CentOS的系统来说,可以使用RPM;对于Ubuntu来说,可以使用deb包;

对于Windows来说,可以使用MSI。

使用OS特定构建物的好处是,在做部署时不需要考虑底层使用的是什么技术。只需要简单使用内置的工具就可以完成软件的安装。

OS包管理工具,可以帮你完成很多原本需要使用Chef或者Puppet来完成的工作。

其缺点是,刚开始编写构建脚本的过程可能会比较困难。

当然,还有另一个缺点,即如果你需要部署到多个操作系统的话,维护不同版本构建物的开销就会很大。

但如果软件时部署在你可控的机器上,那么建议,尽量减少需要维护的操作系统的数量,最好只维护一种。

它可以大大减少不同机器之间可能存在的不同之处,并减小部署和维护的工作量。

特别是如果你在linux上工作,而且采用多种技术栈来部署微服务,那么这种方法就很合适。

6.定制化镜像

使用类似Puppet、Chef及Ansible这些自动化配置管理工具的一个问题是,需要花费大量时间在机器上运行这些脚本。

什么是蓝绿部署?

蓝绿部署允许我们在老版本服务不下线的同时,去部署新版本的服务。可以减少在部署时,服务停止的时间增加。

一种减少启动时间的方法是创建一个虚拟机镜像,其中包含一些常用的依赖。

现在你可以把公共的工具安装在镜像上,然后在部署软件时,只需要根据该镜像创建一个实例,

之后在其上安装最新的服务版本即可。

你只需要构建一次镜像,然后根据这些镜像启动虚拟机,不需要再花费时间来安装相应的依赖,

因为它们已经在镜像中安装好了,这样就可以节省很多时间。如果你的核心依赖没有改变,

那么新版本的服务就可以继续使用相同的基础镜像。

这个方法也有些缺点。

首先,构建镜像会花费大量的时间。

其次,产生的镜像可能会很大。例如,当你创建VMWare镜像时,在网络上传送一个20GB的镜像文件会怎么样。

由于历史原因,构建不同平台上的镜像所需的工具是不一样的。

6.1 将镜像作为构建物

我们可以把服务本身也包含在镜像中,这样就把镜像变成了构建物。

就像使用OS特定软件包那样,可以认为这些VM镜像时对不同技术栈的一层抽象。

我们不需要关心运行在镜像中的服务,所使用的语言是Ruby还是Java,最终构建物是gem还是JAR包,

我们唯一需要关心的就是它能否工作。

这个简洁的方法有助于我们实现另一个部署概念:不可变服务器。

6.2 不可变服务器

通过把配置都存到版本控制中,我们可以自动化重建服务,甚至重建整个环境。

但是如果部署完成后,有人登陆到机器上修改了一些东西呢?

这就会导致机器上的实际配置和源代码管理中的配置不再一致,这个问题叫做配置漂移。

为了避免这个问题,可以禁止对任何运行的服务器做手动修改。

相反,无论修改多么小,都需要经过构建流水线来创建新的机器。

7.环境

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券