作者 | 褚杏娟
近日，GitHub 前 CTO Jason Warner 在推特上表示，“我確信過(guò)去十年中，最大的架構(gòu)錯(cuò)誤之一就是全面使用微服務(wù)。”從單體應(yīng)用到微服務(wù)的規(guī)劃順序，Warner 的建議是：?jiǎn)误w>應(yīng)用程序>服務(wù)>微服務(wù)。
Warner 表示，這是一種思維方式而非規(guī)則。“任何構(gòu)建過(guò)大型分布式系統(tǒng)的人都知道他們并不真的那樣工作，但還必須適應(yīng)它。”其次，Warner 表示認(rèn)為，公司所處的階段很重要。如果是一家 5-50 人的公司，只需堅(jiān)持使用單體。
Warner 先對(duì)服務(wù)和微服務(wù)的定義進(jìn)行了闡釋。服務(wù)支持應(yīng)用程序/單體，是核心基礎(chǔ)設(shè)施，被大量需要，為核心合規(guī)功能，可能不是應(yīng)用程序團(tuán)隊(duì)編寫(xiě)的（基礎(chǔ)設(shè)施團(tuán)隊(duì)維護(hù)）；微服務(wù)則有幾百行代碼，大部分是一次性的，可能或應(yīng)該是庫(kù)、SDK 等。對(duì)于為什么不太看好微服務(wù)，Warner 給出的理由如下：
一般來(lái)說(shuō)，整個(gè)工程團(tuán)隊(duì)在一個(gè)大型應(yīng)用程序中工作（想像 Rails 應(yīng)用程序中的整個(gè)站點(diǎn)），比推理微服務(wù)將以何種方式失敗要容易得多。 無(wú)論如何，隨著企業(yè)發(fā)展而擁有的分布式系統(tǒng)，引入數(shù)十個(gè)微服務(wù)進(jìn)行推理已經(jīng)很難了，更不用說(shuō)數(shù)百個(gè)各有風(fēng)險(xiǎn)的微服務(wù)。 完全微服務(wù)化時(shí)，需要引入新的概念來(lái)處理“sprawl”。 重要的是，每個(gè)定制的基礎(chǔ)設(shè)施服務(wù)或微服務(wù)都是債務(wù) IMV 的極端版本?。代碼是債務(wù)，但服務(wù)是債務(wù)的極端版本??。Warner 還指出，當(dāng)涉及幾十個(gè)微服務(wù)或更大規(guī)模時(shí)，企業(yè)遇到通常并非技術(shù)問(wèn)題，而是組織上的挑戰(zhàn)。
首先，基礎(chǔ)設(shè)施幾乎不會(huì)被優(yōu)先考慮（除非公司由非常隨和的 CEO 領(lǐng)導(dǎo)）；其次，過(guò)多的服務(wù)常常會(huì)導(dǎo)致所有權(quán)和邊界問(wèn)題；再者，為處理過(guò)多的微服務(wù)會(huì)引入更多的工具；更重要的是，本來(lái)應(yīng)該是庫(kù)、SDK 或其他東西的微服務(wù)都會(huì)引入生產(chǎn)風(fēng)險(xiǎn)。代碼過(guò)多是開(kāi)銷，服務(wù)過(guò)多是客戶面臨的產(chǎn)品/體驗(yàn)風(fēng)險(xiǎn)，兩者都有開(kāi)銷和風(fēng)險(xiǎn)，但百分比分布不同。
因此，Warner 鼓勵(lì)企業(yè)根據(jù)自己的情況來(lái)選擇，而不是盲目跟隨大廠的做法，他給出的建議是：
盡可能地延長(zhǎng)單體應(yīng)用的使用時(shí)間。 服務(wù)從基礎(chǔ)設(shè)施開(kāi)始，而非應(yīng)用程序。 如果要打破單體架構(gòu)，打破大型應(yīng)用程序，而不是小型服務(wù)。 認(rèn)為每個(gè)新應(yīng)用程序是貴公司的虛擬墻。 盡可能選擇庫(kù)而不是微服務(wù)。對(duì)于 Warner 的觀點(diǎn)，有開(kāi)發(fā)者評(píng)價(jià)道，“我認(rèn)為他提出了一些很好的觀點(diǎn)，尤其是關(guān)于有多少東西真的應(yīng)該是庫(kù)。”也有開(kāi)發(fā)者表示，微服務(wù)的主要問(wèn)題很簡(jiǎn)單，就是大多數(shù)人不了解如何正確設(shè)計(jì)它們。一個(gè)設(shè)計(jì)糟糕的單體架構(gòu)幾乎總好過(guò)設(shè)計(jì)糟糕的微服務(wù)架構(gòu)。單體保護(hù)企業(yè)免受不良設(shè)計(jì)影響的底線要高得多。最大的錯(cuò)誤是人們傾向于創(chuàng)建太小或太多的服務(wù)。
任職期間，GitHub 遷到微服務(wù)架構(gòu)
Warner 曾在 Heroku 擔(dān)任副總裁/工程主管三年多，并在擔(dān)任 Ubuntu Desktop 工程主管近四年后，在 2017 年 5 月開(kāi)始擔(dān)任 GitHub 的首席技術(shù)官一職。Warner 現(xiàn)在已成為 Redpoint Ventures 的董事總經(jīng)理。
Warner 十七八歲時(shí)才真正開(kāi)始編程。當(dāng)時(shí)的他剛進(jìn)入 IBM 主要負(fù)責(zé)打印機(jī)聯(lián)網(wǎng)，“他們最終說(shuō)，'嘿，如果你去學(xué)校學(xué)習(xí)如何編程和學(xué)習(xí)計(jì)算機(jī)科學(xué)，畢業(yè)后我們會(huì)給你一份工作。'”Warner 曾在博客中回憶道。
盡管擁有計(jì)算機(jī)科學(xué)學(xué)士和碩士學(xué)位，Warner 還是認(rèn)為自己可能是一名普通的開(kāi)發(fā)人員。初到 GitHub 時(shí)，Warner 將時(shí)間更多花在了產(chǎn)品方面，但隨著開(kāi)發(fā)者社區(qū)蓬勃發(fā)展，GitHub 架構(gòu)面臨著更大的擴(kuò)展性挑戰(zhàn)。
Warner 剛來(lái)時(shí)，GitHub 擁有約 2000 萬(wàn)帳戶，該網(wǎng)站每天大約有 150 萬(wàn)至 200 萬(wàn)活躍用戶，注冊(cè)量達(dá) 1 萬(wàn)人。但到 2021 年 7 月 Warner 離開(kāi)時(shí)，這一數(shù)字已躍升至每天 50,000 人注冊(cè)，日活躍用戶也達(dá)到了 700 萬(wàn)。
顯然，微服務(wù)架構(gòu)成為當(dāng)時(shí) GitHub 減輕擴(kuò)展限制的選擇之一。微服務(wù)潮流曾被 Heroku 大力推動(dòng)，或許 Heroku 任職的經(jīng)歷也讓 Warner 支持 GitHub 進(jìn)行微服務(wù)改造。“我實(shí)際上可以坐在那里傾聽(tīng)并真正為整體架構(gòu)方法做出貢獻(xiàn)。”Warner 曾在采訪中提到。
如何遷移
一直以來(lái)， GitHub 是基于 Ruby on Rails 的單體架構(gòu)，直到 2021 年，為了讓超過(guò)一半的開(kāi)發(fā)人員在單體代碼庫(kù)之外富有成效地開(kāi)展工作，GitHub 以賦能為出發(fā)點(diǎn)開(kāi)始了向微服務(wù)架構(gòu)的遷移。
GitHub 團(tuán)隊(duì)認(rèn)為，良好的架構(gòu)始于模塊化。拆分單體的第一步是考慮基于特性功能分割代碼和數(shù)據(jù)。這個(gè)過(guò)程可以在真正在微服務(wù)環(huán)境中拆分之前在單體中完成。
正確地拆分?jǐn)?shù)據(jù)是從單體架構(gòu)轉(zhuǎn)向微服務(wù)的基礎(chǔ)。GitHub 的做法是先在現(xiàn)有的數(shù)據(jù)庫(kù)模式中識(shí)別功能邊界，并按照這些邊界將實(shí)際的數(shù)據(jù)庫(kù)表分組。GitHub 研發(fā)團(tuán)隊(duì)將生成的功能分組稱為模式域，并記錄在 YAML 定義文件中。在數(shù)據(jù)庫(kù)模式中添加或刪除表，都要更新這個(gè)文件。
接下來(lái)，對(duì)于每個(gè)模式域，團(tuán)隊(duì)找了一個(gè)分區(qū)鍵。這是一個(gè)共享字段，將一個(gè)功能組中的所有信息聯(lián)系在一起。最終，創(chuàng)建數(shù)據(jù)庫(kù)模式功能組幫助團(tuán)隊(duì)將數(shù)據(jù)拆分到微服務(wù)架構(gòu)所需的不同服務(wù)器和集群上。GitHub 在單體中實(shí)現(xiàn)了一個(gè)查詢監(jiān)視器來(lái)幫助檢測(cè)，并在發(fā)現(xiàn)跨域查詢時(shí)發(fā)出告警信息。
GitHub 有超過(guò) 5000 萬(wàn)用戶和 1 億個(gè)存儲(chǔ)庫(kù)，在這樣的規(guī)模下，功能組可能會(huì)變得非常大。這時(shí)，分區(qū)鍵就派上了用場(chǎng)。例如，一種簡(jiǎn)單的方法是根據(jù)數(shù)值范圍將不同的用戶分配到不同的數(shù)據(jù)存儲(chǔ)。更常見(jiàn)的可能是根據(jù)每個(gè)數(shù)據(jù)集的特性（如區(qū)域和大小）所做的邏輯分組。
GitHub 如何從單體中抽取服務(wù)呢？GitHub 認(rèn)為，依賴方向只能從單體內(nèi)到單體外，不能反過(guò)來(lái)，否則最終會(huì)得到一個(gè)分布式單體。即當(dāng)從單體中抽取服務(wù)時(shí)要從核心服務(wù)入手，然后逐步到特性層面。
接下來(lái)，找出開(kāi)發(fā)人員在單體環(huán)境中開(kāi)發(fā)時(shí)所使用的助力工具。最后在新服務(wù)上線運(yùn)行后，務(wù)必要?jiǎng)h除舊的代碼路徑。GitHub 通過(guò)名為 Scientist 的工具來(lái)識(shí)別誰(shuí)在調(diào)用這個(gè)服務(wù)，并規(guī)劃好如何將流量全部導(dǎo)向新服務(wù)，這樣就不用總是支持兩套代碼了。
GitHub 首先抽取的核心服務(wù)是身份驗(yàn)證和授權(quán)。GitHub 在單體外部將身份驗(yàn)證重寫(xiě)為一個(gè)鏡像服務(wù)。GitHub 的 Rails 應(yīng)用程序（單體）使用 Twirp（這是一個(gè) gRPC 風(fēng)格的服務(wù)到服務(wù)通信框架）和它通信，依賴方向是由內(nèi)到外。
下一步，找一些簡(jiǎn)單的小特性從單體中遷移出來(lái)，例如那些沒(méi)有復(fù)雜依賴和共享邏輯的特性。GitHub 是從 webhook 推送和語(yǔ)法高亮開(kāi)始的。GitHub 通過(guò)查找經(jīng)常一起更改和部署的代碼和數(shù)據(jù)，來(lái)確定耦合度較高的特性或功能，并以此為基礎(chǔ)，自然地劃分成可以獨(dú)立于其他部分單獨(dú)迭代和部署的分組。GitHub 根據(jù)產(chǎn)品和業(yè)務(wù)價(jià)值來(lái)確定微服務(wù)的大小。
此外，為了支持從單體到微服務(wù)的轉(zhuǎn)型，節(jié)省時(shí)間、加速向微服務(wù)的過(guò)渡，GitHub 也做了必要的運(yùn)營(yíng)改變。例如，GitHub 創(chuàng)建了一個(gè)自助服務(wù)運(yùn)行時(shí)平臺(tái)，用于微服務(wù)的打包交付，目的是大幅減輕每個(gè)團(tuán)隊(duì)創(chuàng)建微服務(wù)時(shí)的運(yùn)營(yíng)負(fù)擔(dān)。
如今，GitHub 已經(jīng)成為基于“單體-微服務(wù)混合”的環(huán)境。
有人放棄微服務(wù)
微服務(wù)正在統(tǒng)治世界，甚至有可能正在成為新的默認(rèn)選項(xiàng)。但這幾年，無(wú)數(shù)的中小團(tuán)隊(duì)在微服務(wù)上陷入了掙扎，很多公司在放棄微服務(wù)，其中包括一些大型企業(yè)。
2020 年，Uber 放棄了微服務(wù)，轉(zhuǎn)而使用宏服務(wù)。Uber 支付體驗(yàn)平臺(tái)的工程經(jīng)理 Gergely Oros 表示，“Uber 最早通過(guò)構(gòu)建微服務(wù)來(lái)完成很小的需求或功能，以至于出現(xiàn)了很多由一個(gè)人構(gòu)建維護(hù)的微服務(wù)。這些微服務(wù)的存在帶來(lái)了新的復(fù)雜性和挑戰(zhàn)，例如監(jiān)控、測(cè)試、持續(xù)集成 / 持續(xù)交付（CI/CD）、服務(wù)級(jí)別協(xié)議（SLA）、跨所有微服務(wù)的庫(kù)版本（安全和時(shí)區(qū)問(wèn)題）等等。”
因此在創(chuàng)建新平臺(tái)的時(shí)候，Uber 支付體驗(yàn)團(tuán)隊(duì)對(duì)新服務(wù)進(jìn)行了更加深思熟慮的規(guī)劃：不再只是完成一件事，而是使其服務(wù)于一項(xiàng)業(yè)務(wù)功能，由 5-10 個(gè)工程師負(fù)責(zé)維護(hù)。Orosz 把這樣的服務(wù)規(guī)劃稱之為宏服務(wù)。
同樣，從事 seo 優(yōu)化的公司Botify在運(yùn)行了不到四年的微服務(wù)后也放棄了。
Botify 平臺(tái)通過(guò) Django 應(yīng)用程序的負(fù)載均衡集群提供服務(wù)。2016 年底，Botify 工程團(tuán)隊(duì)想讓工程師和產(chǎn)品經(jīng)理?yè)碛懈嗟木植克袡?quán)，從而可以快速將他們的產(chǎn)品和技術(shù)棧投入使用。為此，團(tuán)隊(duì)決定將他們的 Django 應(yīng)用程序拆分為微服務(wù)。當(dāng)時(shí)，他們的團(tuán)隊(duì)大約為 15 人，也是從身份驗(yàn)證和授權(quán)入手實(shí)現(xiàn)第一個(gè)微服務(wù)，將 Django 應(yīng)用程序當(dāng)前的一部分功能轉(zhuǎn)移到微服務(wù)中，微服務(wù)模塊也需要和其他的 Django/Python/ target=_blank class=infotextkey>Python 單體模塊進(jìn)行通訊。
Botify 平臺(tái)的主要難點(diǎn)是對(duì)客戶數(shù)據(jù)進(jìn)行分析。處理用戶相關(guān)數(shù)據(jù)的微服務(wù)架構(gòu)旨在服務(wù)于高流量的 B2C 平臺(tái)，而 Botify 的挑戰(zhàn)在于動(dòng)態(tài)地聚合數(shù)以 GB 的 SEO 數(shù)據(jù)，使其在幾秒鐘內(nèi)可用。對(duì)大約一萬(wàn)名客戶的元數(shù)據(jù)以毫秒為單位進(jìn)行響應(yīng)，這項(xiàng)任務(wù)不需要高度可伸縮的微服務(wù)架構(gòu)，但 Botify 的后端到后端通信減慢了這些簡(jiǎn)單的檢索過(guò)程，花費(fèi)了更多的時(shí)間。
鑒于每天都要在 JAVAScript 身份驗(yàn)證后端和 Django 模塊之間頻繁地來(lái)回切換，在權(quán)衡了架構(gòu)的優(yōu)缺點(diǎn)以及潛在的遷移成本后，Botify 將身份驗(yàn)證后端重新加入到 Django 單體中，并于 2020 年 2 月停用了微服務(wù)。
微服務(wù)有好處也有弊端和風(fēng)險(xiǎn)。正如 Warner 所說(shuō)，企業(yè)應(yīng)該根據(jù)自己的情況來(lái)選擇，而不是一味追隨潮流。
參考鏈接：
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
