作者 | 褚杏娟
近日，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/ target=_blank class=infotextkey>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
