作者 | 褚杏娟

近日，GitHub 前 CTO Jason Warner 在twitter上则表示，“我坚信过去十年中，最小的构架严重错误之一就是全面采用微服务项目。”从乙烯应用领域到微服务项目的规划次序，Warner 的提议是：乙烯>插件>服务项目>微服务项目。

Warner 则表示，这是一种观念形式而非准则。“任何构筑过较大型网络通讯的人都知道他们并不真的那样组织工作，但还必须适应它。”其二，Warner 则表示指出，子公司所在的阶段很关键。假如是一家 5-50 人的子公司，只需坚持采用乙烯。

Warner Fossat服务项目和微服务项目的表述展开了阐述。服务项目支持插件/乙烯，是核心理念基础建设，被大量须要，为核心理念合规性功能，可能将并非插件项目组撰写的（基础建设项目组维护）；微服务项目则有几十行标识符，大部分是纸制的，可能将或假如是库、SDK 等。对于为什么不太看好微服务项目，Warner 得出的理由如下表所示：

Warner 还指出，当涉及十几个微服务项目或更大规模时，民营企业遇到通常并非技术问题，而是组织上的考验。

首先，基础建设几乎不会被优先选择考虑（假如子公司由非常和蔼可亲的 CEO 领导）；其二，过多的服务项目常常会导致使用权和边界争端；由此可见，为处置过多的微服务项目会导入更多的工具；更关键的是，本来假如是库、SDK 或其他东西的微服务项目单厢导入生产信用风险。标识符过多是开支，服务项目过多是客户面临的产品/新体验信用风险，二者都有开支和信用风险，但比率分布不同。

因此，Warner 引导民营企业根据自己的情况来选择，而并非一味追随小厂的作法，他得出的提议是：

对于 Warner 的观点，有开发者评价道，“我指出他提出了一些很好的观点，尤其是关于有多少东西真的假如是库。”也有开发者则表示，微服务项目的主要问题很简单，就是大多数人不了解如何正确设计它们。一个设计糟糕的乙烯构架几乎总好过设计糟糕的微服务项目构架。乙烯保护民营企业免受不良设计影响的底线要高得多。最小的严重错误是人们倾向于创建太小或太多的服务项目。

任职期间，GitHub 迁到微服务项目构架

Warner 曾在 Heroku 担任副总裁/工程主管三年多，并在担任 Ubuntu Desktop 工程主管近四年后，在 2017 年 5 月开始担任 GitHub 的首席技术官一职。Warner 现在已成为 Redpoint Ventures 的董事总经理。

Warner 十七八岁时才真正开始编程。当时的他刚进入 IBM 主要负责打印机联网，“他们最终说，嘿，假如你去学校学习如何编程和学习计算机科学，毕业后我们会给你一份组织工作。”Warner 曾在博客中回忆道。

尽管拥有计算机科学学士和硕士学位，Warner 还是指出自己可能将是一名普通的开发人员。初到 GitHub 时，Warner 将时间更多花在了产品方面，但随着开发者社区蓬勃发展，GitHub 构架面临着更大的扩展性考验。

Warner 刚来时，GitHub 拥有约 2000 万帐户，该网站每天大约有 150 万至 200 万活跃用户，注册量达 1 万人。但到 2021 年 7 月 Warner 离开时，这一数字已跃升至每天 50,000 人注册，日活跃用户也达到了 700 万。

显然，微服务项目构架成为当时 GitHub 减轻扩展限制的选择之一。微服务项目潮流曾被 Heroku 大力推动，或许 Heroku 任职的经历也让 Warner 支持 GitHub 展开微服务项目改造。“我实际上可以坐在那里倾听并真正为整体构架方法做出贡献。”Warner 曾在采访中提到。

如何迁移

一直以来， GitHub 是基于 Ruby on Rails 的乙烯构架，直到 2021 年，为了让超过一半的开发人员在乙烯标识符库之外富有成效地开展组织工作，GitHub 以赋能为出发点开始了向微服务项目构架的迁移。

GitHub 项目组指出，良好的构架始于模块化。拆分乙烯的第一步是考虑基于特性功能分割标识符和数据。这个过程可以在真正在微服务项目环境中拆分之前在乙烯中完成。

正确地拆分数据是从乙烯构架转向微服务项目的基础。GitHub 的作法是先在现有的数据库模式中识别功能边界，并按照这些边界将实际的数据库表分组。GitHub 研发项目组将生成的功能分组称为模式域，并记录在 YAML 表述文件中。在数据库模式中添加或删除表，都要更新这个文件。

接下来，对于每一模式域，项目组找了一个分区键。这是一个共享字段，将一个功能组中的所有信息联系在一起。最终，创建数据库模式功能组帮助项目组将数据拆分到微服务项目构架所需的不同服务项目器和集群上。GitHub 在乙烯中实现了一个查询监视器来帮助检测，并在发现跨域查询时发出告警信息。

GitHub 有超过 5000 万用户和 1 亿个存储库，在这样的规模下，功能组可能将会变得非常大。这时，分区键就派上了用场。例如，一种简单的方法是根据数值范围将不同的用户分配到不同的数据存储。更常见的可能将是根据每一数据集的特性（如区域和大小）所做的逻辑分组。

GitHub 如何从乙烯中抽取服务项目呢？GitHub 指出，依赖方向只能从乙烯内到乙烯外，不能反过来，否则最终会得到一个分布式乙烯。即当从乙烯中抽取服务项目时要从核心理念服务项目入手，然后逐步到特性层面。

接下来，找出开发人员在乙烯环境中开发时所采用的助力工具。最后在新服务项目上线运行后，务必要删除旧的标识符路径。GitHub 通过名为 Scientist 的工具来识别谁在调用这个服务项目，并规划好如何将流量全部导向新服务项目，这样就不用总是支持两套标识符了。

GitHub 首先抽取的核心理念服务项目是身份验证和授权。GitHub 在乙烯外部将身份验证重写为一个镜像服务项目。GitHub 的 Rails 插件（乙烯）采用 Twirp（这是一个 gRPC 风格的服务项目到服务项目通信框架）和它通信，依赖方向是由内到外。

下一步，找一些简单的小特性从乙烯中迁移出来，例如那些没有复杂依赖和共享逻辑的特性。GitHub 是从 webhook 推送和语法高亮开始的。GitHub 通过查找经常一起更改和部署的标识符和数据，来确定耦合度较高的特性或功能，并以此为基础，自然地划分成可以独立于其他部分单独迭代和部署的分组。GitHub 根据产品和业务价值来确定微服务项目的大小。

此外，为了支持从乙烯到微服务项目的转型，节省时间、加速向微服务项目的过渡，GitHub 也做了必要的运营改变。例如，GitHub 创建了一个自助服务项目运行时平台，用于微服务项目的打包交付，目的是大幅减轻每一团队创建微服务项目时的运营负担。

如今，GitHub 已经成为基于“乙烯-微服务项目混合”的环境。

有人放弃微服务项目

微服务项目正在统治世界，甚至有可能将正在成为捷伊默认选项。但这几年，无数的中小项目组在微服务项目上陷入了挣扎，很多子公司在放弃微服务项目，其中包括一些较大型民营企业。

2020 年，Uber放弃了微服务项目，转而采用宏服务项目。Uber 支付新体验平台的工程经理 Gergely Oros 则表示，“Uber 最早通过构筑微服务项目来完成很小的需求或功能，以至于出现了很多由一个人构筑维护的微服务项目。这些微服务项目的存在带来了捷伊复杂性和考验，例如监控、测试、持续集成 / 持续交付（CI/CD）、服务项目级别协议（SLA）、跨所有微服务项目的库版（安全和时区问题）等等。”

因此在创建新平台的时候，Uber 支付新体验项目组对新服务项目展开了更加深思熟虑的规划：不再只是完成一件事，而是使其服务项目于一项业务功能，由 5-10 个工程师负责维护。Orosz 把这样的服务项目规划称之为宏服务项目。

同样，从事 SEO 优化的子公司Botify在运行了不到四年的微服务项目后也放弃了。

Botify 平台通过 Django 插件的负载均衡集群提供服务项目。2016 年底，Botify 工程项目组想让工程师和产品经理拥有更多的局部使用权，从而可以快速将他们的产品和技术栈投入采用。为此，项目组决定将他们的 Django 插件拆分为微服务项目。当时，他们的项目组大约为 15 人，也是从身份验证和授权入手实现第一个微服务项目，将 Django 插件当前的一部分功能转移到微服务项目中，微服务项目模块也须要和其他的 Django/Python 乙烯模块展开通讯。

Botify 平台的主要难点是对客户数据进行分析。处置用户相关数据的微服务项目构架旨在服务项目于高流量的 B2C 平台，而 Botify 的考验在于动态地聚合数以 GB 的 SEO 数据，使其在几秒钟内可用。对大约一万名客户的元数据以毫秒为单位展开响应，这项任务不须要高度可伸缩的微服务项目构架，但 Botify 的后端到后端通信减慢了这些简单的检索过程，花费了更多的时间。

鉴于每天都要在 JavaScript 身份验证后端和 Django 模块之间频繁地来回切换，在权衡了构架的优缺点以及潜在的迁移成本后，Botify 将身份验证后端重新加入到 Django 乙烯中，并于 2020 年 2 月停用了微服务项目。

微服务项目有好处也有弊端和信用风险。正如 Warner 所说，民营企业假如根据自己的情况来选择，而并非一味追随潮流。

参考链接：

https://www.infoq.cn/article/zYGF4FpIVVt5U2omioUu

https://thenewstack.io/what-a-former-github-cto-learned-about-scaling/

https://www.infoq.cn/article/KSzctluch2ijbRbKYBgO

https://twitter.com/jasoncwarner/status/1592227285024636928