微服务之部署

Posted 2020-12-01 vincent-yuan

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

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构建流程，全自动话的创建出用于部署的构建物。

6.3 构建流水线和持续交付

。。