GitHub 如何从单体架构迁移到微服务架构.pdf

文档介绍：GitHub 如何从单体架构迁移到微服务架构
本文介绍 GitHub 如何从单体架构迁移到微服务架构，并对其中一些最佳
实践做了详细说明。
1 旅程开启
GitHub 创建于 2008 年，其宗旨是为开发人员托管和分享代码提供便利。
GitHub 的创建者也是开源贡献者，他们在 Ruby 社区非常有影响力。正因为
如此，GitHub 的架构深深地扎根于 Ruby on Rails。
在公司的整个发展历程中，我们雇佣了世界上最好的 Ruby 开发人员，帮
助我们扩展和优化代码库。如今，我们的平台上已经有超过 5000 万名开发人
员，每年有超过 8000 万个 pull 请求合并，全球各大洲有超过 1 亿个代码存
储库。
如你所见，这个单体架构已经带我们走得很远。一个演进了 12 年的代码
库，每天要协调多次部署。我们有一个规模很大的平台，每天处理 10 亿次
API 调用，我们还提供了一个高性能的用户界面，专注于完成这项工作。
2 内部快速增长
在过去 18 个月中，GitHub 内部经历了快速增长。我们已经有超过 2000
名员工，为代码库做贡献的工程师数量已经是以前的两倍多。这种增长既包括
自身的逐步发展，也包括收购，如 Semmle、npm、Dependabot 和 Pull
Panda。
此外，GitHub 是一个高度分散的团队，在疫情发生前，我们就有超过
70% 的员工是在旧金山总部以外的地方办公。GitHub 的员工和承包商要跨六
大洲展开协作，他们工作的时区各不相同。我们有 1000 多名内部开发人员，
他们有各种各样的开发技能，涉及到许多不同的技术。
显然，我们需要从根本上重新考虑下 GitHub 的软件开发工作。让每个人
在参与开发之前都学习 Ruby，让所有人都在同一个单体代码库上进行开发，
不再是扩展 GitHub 最高效、最优化的方法。根据康威定律，任何组织设计的
系统，其结构都是对组织沟通结构的复制。
反之亦然，单体架构会导致更大规模的涉众会议，更复杂的决策过程，因
为交织的逻辑和共享的数据会影响所有团队。
3 单体 vs. 微服务
因此我们就想，是不是该从 Ruby on Rails 单体迁出，转向一种微服务架
构了？如果是这样的话，我们该如何进行？单体架构和微服务架构各有所长。
在单体环境中，配置并运行应用程序更简单，不用考虑复杂的依赖关系，
拉取所有必要的依赖项。新建一个 Hubber，只需几个小时就可以在本机上配置
好 GitHub 并运行起来。在单体架构中，代码在有些情况下会更简洁。例如，
不用添加超时处理逻辑，也不用考虑如何优雅地处理由网络延迟和中断所导致
的失败。
此外，由于所有人都工作在同一个技术