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

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 并运行起来。在单体架构中，代码在有些情况下会更简洁。例如， 不用添加超时处理逻辑，也不用考虑如何优雅地处理由网络延迟和中断所导致 的失败。 此外，由于所有人都工作在同一个技术栈上，大家对代码库都很熟悉，所 以可以方便地将开发人员和团队调去开发单体的其他特性，有利于实现特性的 全局最优。考虑到 GitHub 在过去 18 个月中的增长情况，微服务环境的一部 分优点吸引了我们。 例如，建立具有系统级所有权的特性团队，通过清晰定义的 API 契约确 立职责边界。在遵循 API 契约的前提下，团队有充分的自由选择最适合自己 的技术栈。代码库更小意味着阅读更容易、启动速度更快、问题排查更简单。 开发人员不用为了提高生产力去理解一整个庞大的代码库的内部运行机制。最 重要的是，服务现在可以根据各自的需求单独扩展。 4 务实——以赋能为