多存储库与单存储库的微服务发布管理比较

译文 精选
存储 存储架构
本文从跟踪变更,获悉其不同的版本,以及发布管理的角度,比较了微服务应用多存储库与单存储库方式的差异性。

译者 | 陈峻

审校 | 孙淑娟

让我们来设想一个由数十个可持续部署(continuously-deployed)的自治服务所组成的微服务应用。该应用程序的每个服务群都有自己的存储库。它们拥有不同的版本控制方案,并由不同的团队在不断发布着新的版本。那么,由于变更历史分散在这数十个存储库中,我们该如何有效地跟踪变更,获悉其不同的版本,以及管理应用的发布呢?

想必这是任何使用微服务架构的团队,都需要处理的问题。下面,我将和您讨论可以用来管理微服务发布的两种不同方法。

通用方法:一个微服务配一个存储库

目前,使用微服务架构的应用通常会采用multirepo(多存储库)这一最常见的方法,即:

1. 设计一些可被分解为微服务。

2. 为每一个微服务创建一个单独的存储库。

3. 让每个存储库都有一个独立的CI/CD管道,用于将微服务持续部署到生产环境中。

这种细粒度的持续部署形式可以被称为微部署。通过微部署,微服务版本可以被独立地进行部署,而且几乎不需要任何集成测试。

每个微服务都有一个单独的CI/CD管道

可以说,微部署是将代码组织成为多存储库的必然结果。上图展示了目前Semaphore CI/CD部署微服务的方式。

维护多个发布

持续的微部署非常适合那些由Netflix或Semaphore CI/CD等平台托管的应用。在此类应用中,用户或客户不知道、也并不感兴趣其幕后运行的单个微服务的版本。然而,对于运行在本地(on-premise)的相同应用而言,持续部署并不能起作用。对此,我们只能发布包含了固定在特定版本中的一组微服务。例如,您可以使用Semaphore On-Premise在防火墙的后面,运行全功能版本的Semaphore CI/CD。

针对托管式应用的微部署,应结合产品的本地实例的发布

通常,我们可以按照如下步骤,发布被组织成multirepos的应用:

1. 在每个repo(存储库)中,标记那些有待发布的微服务版本。

2. 针对每个微服务,构建一个Docker镜像,并将微服务的版本映射到镜像标签上。

3. 在单独的测试环境中,使用集成测试、验收测试,甚至是手动测试等方式,全面测试有待发布的版本。

4. 在更新文档之前,检查每个存储库,并为发布的变更日志(changelog),编译相应的变更列表。

5. 识别旧版本所需的各种热修补程序。

6. 发布版本。

鉴于一个应用可以包含数十个微服务(和存储库),我们很容易看出,该发布方式会导致大量重复的管理开销。

使用Monorepos(单存储库)管理发布

显然Multirepos更适合于持续部署。而对于那些非定期、非持续的发布,我们需要将所有微服务集合到一个共享的存储库中。这便是Google、Airbnb和Uber等大公司,多年以来一直使用的Monorepo方法。

Monorepo包含了所有微服务和统一的CI/CD部署管道

Monorepo策略会让微服务感觉更像是一个单体应用,其好处在于:

  • 让创建一个发布就像创建某个分支和使用标签一样简单。
  • 单个CI/CD流程可标准化测试和部署。
  • 更容易实现集成和验收测试。
  • 单个Git历史更易于理解,并简化了编写变更日志和更新文档的过程。

由一个CI/CD来统管所有

针对变更的Monorepo模式的主要特点体现在如下方面:

  • 由于所有变更都被提交到一处,所以CI(持续集成)服务器会承受更大的压力。我们可以通过使用​​基于变更的执行​​​(change-based execution)或诸如:​​Bazel​​​、​​Pants​​之类的Monorepo感知工具,来处理此类问题。
  • 由于Git没有内置的代码保护功能,因此如果需要加固应用的安全性,则可以使用诸如:Bitbucket或​​GitHub CODEOWNERS​​之类的功能。
  • 当测试套件跨越多个单独的服务时,人们很难在CI的构建中发现和处理错误。对此,​​测试报告​​等功能可协助识别和分析问题。
  • Monorepo的CI/CD配置可能会出现许多重复的部分。对此,我们可以使用环境变量或参数化管道,来减少样板文件(Boilerplate)。

不要忘了可恢复性

到目前为止,我们只关注了应用的可发布性,下面我们再来关注可恢复性。

版本控制不仅能让我们实现协作、共享知识、跟踪代码、以及管理变更,还提供了在出现问题时的恢复能力。只要我们可以访问到项目中的任何一个变更,便可以“闪回”到任意版本。

不过,由于Multirepos没能记录微服务之间的关系,即:没有任何给定时间点,在生产环境中运行的服务版本的快照,因此,我们若要诊断某些集成类问题,则非常耗时。在某些情况下,我们甚至无法通过回滚微服务来解决问题。

Multirepos在查找失败的根本原因时具有挑战性,有时很难找到“最后一次使用过的微服务配置”

而Monorepo能够轻松地捕获系统的完整快照,以便为我们提供项目的历史记录中任意点所需的所有细节,进而在出现问题时,找到合适的回撤点。

Monorepo具有返回项目历史中任何时间点所需的微服务关系的详细信息

小结

综上所述,到底是应该采取为一个微服务配置一个管道和一个存储库,还是配置一个全局管道和一个共享村库,目前尚无绝对的定论。如果您的微服务是松耦合的话,那么Multirepo和Monorepo都可以正常工作。当然,Multirepos的负载虽大,但可以为您提供更多的自主权。而如果您的服务存在着耦合关系,那么您最好使用Monorepo来保证其可恢复性。

在上文提到的Semaphore平台中,持续的微部署方式能够达到较好的效果。但是在Semaphore On-Premise中,我建议您将核心的微服务迁移到Monorepo处。 

译者介绍

陈峻 (Julian Chen),51CTO社区编辑,具有十多年的IT项目实施经验,善于对内外部资源与风险实施管控,专注传播网络与信息安全知识与经验。

原文标题:Release Management for Microservices: Multi vs. Monorepos,作者:Tomas Fernandez

责任编辑:华轩 来源: 51CTO
相关推荐

2022-08-07 22:11:25

微服务架构

2022-09-09 16:27:09

微服务架构数据存储

2020-10-11 16:56:10

分解单体式数据库数据库微服务

2018-06-01 23:08:01

Spring Clou微服务服务器

2022-05-13 14:01:46

微服务架构安全微服务

2022-06-08 08:52:04

Tars微服务开发C++开发

2017-03-14 11:52:52

微服务架构数据管理

2021-02-07 09:05:56

微服务结构云原生

2020-04-13 09:54:44

微服务子集存储

2020-03-02 08:00:00

微服务架构软件开发

2020-04-26 09:44:04

微服务容器架构

2019-01-15 17:58:03

微服务架构数据

2019-12-17 08:40:33

微服务架构数据

2016-08-25 21:12:31

微服务架构发布

2021-04-06 09:43:41

微服务架构数据

2022-06-20 08:56:25

Kafka微服务运维

2022-05-06 10:03:51

2019-07-18 14:07:36

程序员Linux数据库

2019-05-17 15:25:59

云原生服务架构存储

2020-11-03 09:00:00

API微服务JavaScript框
点赞
收藏

51CTO技术栈公众号