GitHub 前 CTO:全面微服务是最大的架构错误!网友:这不是刚改完 GitHub 吗 | 程序师 - 程序员、编程语言、软件开发、编程技术-迪欧吧

整理|褚杏娟

近日,GitHub 前 CTO Jason Warner 在推特上表示,“我确信过去十年中,最大的架构错误之一就是全面使用微办事。”从单体应用到微办事的规划挨次,Warner 的建议是:单体>应用程序>办事>微办事。

Warner 表示,这是一种思维方式而非规则。“任何构建过大型分布式系统的人都知道他们并不真的那样工作,但还必需适应它。”其次,Warner 表示认为,公司所处的阶段很重要。如果是一家 5-50 人的公司,只需坚持使用单体。

Warner 先对办事和微办事的定义进行了阐释。办事支持应用程序 / 单体,是核心基础设施,被大量需要,为核心合规功能,可能不是应用程序团队编写的(基础设施团队维护);微办事则有几百行代码,大部分是一次性的,可能或应该是库、SDK 等。对于为什么不太看好微办事,Warner 给出的理由如下:

一般来说,整个工程团队在一个大型应用程序中工作(想像 Rails 应用程序中的整个站点),比推理微办事将以何种方式失败要容易得多。

无论如何,随着企业发展而拥有的分布式系统,引入数十个微办事进行推理已经很难了,更不消说数百个各有风险的微办事。

完全微办事化时,需要引入新的概念来处理“sprawl”。

重要的是,每个定制的基础设施办事或微办事都是债务 IMV 的极端版本。代码是债务,但办事是债务的极端版本。

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 所说,企业应该按照本身的情况来选择,而不是一味追随潮流。

未经允许不得转载:迪欧吧_技术交流_资源分享_热点资讯_免费VPS空间 » GitHub 前 CTO:全面微服务是最大的架构错误!网友:这不是刚改完 GitHub 吗 | 程序师 - 程序员、编程语言、软件开发、编程技术-迪欧吧