“逃離”單體，GitHub的微服務(wù)架構(gòu)實(shí)踐

1、旅程開啟

GitHub 創(chuàng)建于 2008 年，其宗旨是為開發(fā)人員托管和分享代碼提供便利。GitHub 的創(chuàng)建者也是開源貢獻(xiàn)者，他們在 Ruby 社區(qū)非常有影響力。正因?yàn)槿绱?，GitHub 的架構(gòu)深深地扎根于 Ruby on Rails。在公司的整個(gè)發(fā)展歷程中，我們雇傭了世界上最好的 Ruby 開發(fā)人員，幫助我們擴(kuò)展和優(yōu)化代碼庫。如今，我們的平臺(tái)上已經(jīng)有超過 5000 萬名開發(fā)人員，每年有超過 8000 萬個(gè) pull 請求合并，全球各大洲有超過 1 億個(gè)代碼存儲(chǔ)庫。如你所見，這個(gè)單體架構(gòu)已經(jīng)帶我們走得很遠(yuǎn)。一個(gè)演進(jìn)了 12 年的代碼庫，每天要協(xié)調(diào)多次部署。我們有一個(gè)規(guī)模很大的平臺(tái)，每天處理 10 億次 API 調(diào)用，我們還提供了一個(gè)高性能的用戶界面，專注于完成這項(xiàng)工作。

2、內(nèi)部快速增長

在過去 18 個(gè)月中，GitHub 內(nèi)部經(jīng)歷了快速增長。我們已經(jīng)有超過 2000 名員工，為代碼庫做貢獻(xiàn)的工程師數(shù)量已經(jīng)是以前的兩倍多。這種增長既包括自身的逐步發(fā)展，也包括收購，如 Semmle、npm、Dependabot 和 Pull Panda。此外，GitHub 是一個(gè)高度分散的團(tuán)隊(duì)，在疫情發(fā)生前，我們就有超過 70% 的員工是在舊金山總部以外的地方辦公。GitHub 的員工和承包商要跨六大洲展開協(xié)作，他們工作的時(shí)區(qū)各不相同。我們有 1000 多名內(nèi)部開發(fā)人員，他們有各種各樣的開發(fā)技能，涉及到許多不同的技術(shù)。顯然，我們需要從根本上重新考慮下 GitHub 的軟件開發(fā)工作。讓每個(gè)人在參與開發(fā)之前都學(xué)習(xí) Ruby，讓所有人都在同一個(gè)單體代碼庫上進(jìn)行開發(fā)，不再是擴(kuò)展 GitHub 最高效、最優(yōu)化的方法。根據(jù)康威定律，任何組織設(shè)計(jì)的系統(tǒng)，其結(jié)構(gòu)都是對組織溝通結(jié)構(gòu)的復(fù)制。反之亦然，單體架構(gòu)會(huì)導(dǎo)致更大規(guī)模的涉眾會(huì)議，更復(fù)雜的決策過程，因?yàn)榻豢椀倪壿嫼凸蚕淼臄?shù)據(jù)會(huì)影響所有團(tuán)隊(duì)。

3、單體 vs. 微服務(wù)

因此我們就想，是不是該從 Ruby on Rails 單體遷出，轉(zhuǎn)向一種微服務(wù)架構(gòu)了？如果是這樣的話，我們該如何進(jìn)行？單體架構(gòu)和微服務(wù)架構(gòu)各有所長。在單體環(huán)境中，配置并運(yùn)行應(yīng)用程序更簡單，不用考慮復(fù)雜的依賴關(guān)系，拉取所有必要的依賴項(xiàng)。新建一個(gè) Hubber，只需幾個(gè)小時(shí)就可以在本機(jī)上配置好 GitHub 并運(yùn)行起來。在單體架構(gòu)中，代碼在有些情況下會(huì)更簡潔。例如，不用添加超時(shí)處理邏輯，也不用考慮如何優(yōu)雅地處理由網(wǎng)絡(luò)延遲和中斷所導(dǎo)致的失敗。此外，由于所有人都工作在同一個(gè)技術(shù)棧上，大家對代碼庫都很熟悉，所以可以方便地將開發(fā)人員和團(tuán)隊(duì)調(diào)去開發(fā)單體的其他特性，有利于實(shí)現(xiàn)特性的全局最優(yōu)?？紤]到 GitHub 在過去 18 個(gè)月中的增長情況，微服務(wù)環(huán)境的一部分優(yōu)點(diǎn)吸引了我們。例如，建立具有系統(tǒng)級所有權(quán)的特性團(tuán)隊(duì)，通過清晰定義的 API 契約確立職責(zé)邊界。在遵循 API 契約的前提下，團(tuán)隊(duì)有充分的自由選擇最適合自己的技術(shù)棧。代碼庫更小意味著閱讀更容易、啟動(dòng)速度更快、問題排查更簡單。開發(fā)人員不用為了提高生產(chǎn)力去理解一整個(gè)龐大的代碼庫的內(nèi)部運(yùn)行機(jī)制。最重要的是，服務(wù)現(xiàn)在可以根據(jù)各自的需求單獨(dú)擴(kuò)展。

4、務(wù)實(shí)——以賦能為出發(fā)點(diǎn)

在開始遷移 GitHub 之前，我們花了一些時(shí)間考慮為什么要這樣做，以及這樣做的目標(biāo)是什么。對我們來說，這是文化上的巨大轉(zhuǎn)變，需要做大量的工作。我們得想好，到底要解決什么問題和痛點(diǎn)。在 GitHub，這樣做可以讓超過一半的開發(fā)人員（在過去的 18 個(gè)月中加入）在單體代碼庫之外富有成效地開展工作。我們的目標(biāo)是賦能而非替代。為此，我們得接受這樣一個(gè)現(xiàn)實(shí)，GitHub 未來的特性將基于一個(gè)單體 - 微服務(wù)混合的環(huán)境。也就是說，對于我們來說，維護(hù)和改進(jìn)現(xiàn)有的單體代碼庫仍然很重要。有一個(gè)很好的例子是，我們最近升級到了 Ruby2.7。感興趣的話，可以從 GitHub 官方博客上了解我們做了什么，以及我們總體上如何改進(jìn)系統(tǒng)。

5、良好的架構(gòu)始于模塊化

良好的架構(gòu)始于模塊化。拆分單體的第一步是考慮基于特性功能分割代碼和數(shù)據(jù)。這個(gè)過程可以在真正在微服務(wù)環(huán)境中拆分之前在單體中完成。使代碼庫易于管理，通常都是一種良好的架構(gòu)實(shí)踐。確保每個(gè)服務(wù)都有自己的數(shù)據(jù)，并且能夠控制對這些數(shù)據(jù)的訪問，而且只能通過明確定義的 API 契約訪問。我看到，在很多情況下，人們會(huì)首先抽出代碼邏輯，但仍然使用單體的共享數(shù)據(jù)庫。這往往會(huì)導(dǎo)致分布式單體，這是最糟糕的單體，同時(shí)也是最糟糕的分布式。沒有獲得任何好處（比如，單獨(dú)快速地向生產(chǎn)環(huán)境中部署一組特性），卻還要應(yīng)對微服務(wù)的復(fù)雜性。

6、數(shù)據(jù)拆分

正確地拆分?jǐn)?shù)據(jù)是從單體架構(gòu)轉(zhuǎn)向微服務(wù)的基礎(chǔ)。這里將稍微詳細(xì)地介紹下 GitHub 的做法。首先，我們在現(xiàn)有的數(shù)據(jù)庫模式中識(shí)別功能邊界，并按照這些邊界將實(shí)際的數(shù)據(jù)庫表分組。例如，我們將所有存儲(chǔ)庫相關(guān)的表分到一起，所有用戶相關(guān)的分到一起，所有項(xiàng)目相關(guān)的分到一起。我們將生成的功能分組稱為模式域，并記錄在 YAML 定義文件中?，F(xiàn)在，這個(gè)文件就成了事實(shí)來源。在數(shù)據(jù)庫模式中添加或刪除表，都要更新這個(gè)文件。我們通過一種靜態(tài)分析測試方法來提醒開發(fā)人員，在修改數(shù)據(jù)庫模式時(shí)，要更新這個(gè)文件。接下來，對于每個(gè)模式域，我們找了一個(gè)分區(qū)鍵。這是一個(gè)共享字段，將一個(gè)功能組中的所有信息聯(lián)系在一起。例如，存儲(chǔ)庫模式域（其中包含所有與存儲(chǔ)庫相關(guān)的數(shù)據(jù)，如問題、pull 請求、評審意見）使用存儲(chǔ)庫 ID 作為分區(qū)鍵。最終，創(chuàng)建數(shù)據(jù)庫模式功能組幫助我們將數(shù)據(jù)拆分到微服務(wù)架構(gòu)所需的不同服務(wù)器和集群上。對于當(dāng)前的跨域查詢，我們做了修復(fù)，以防數(shù)據(jù)拆分對產(chǎn)品造成破壞。在 GitHub，我們在單體中實(shí)現(xiàn)了一個(gè)查詢監(jiān)視器來幫助我們檢測，并在發(fā)現(xiàn)跨域查詢時(shí)發(fā)出告警信息。我們會(huì)根據(jù)域邊界，把這些查詢拆分并重寫成多個(gè)，并在應(yīng)用程序?qū)訉?shí)現(xiàn)必要的連接。在劃分完功能組后，我們開始通過一個(gè)類似的過程，進(jìn)一步將數(shù)據(jù)分片到相應(yīng)的租戶組。GitHub 有超過 5000 萬用戶和 1 億個(gè)存儲(chǔ)庫，在這樣的規(guī)模下，功能組可能會(huì)變得非常大。這時(shí)，分區(qū)鍵就派上用場了。例如，一種簡單的方法是根據(jù)數(shù)值范圍將不同的用戶分配到不同的數(shù)據(jù)存儲(chǔ)。更常見的可能是根據(jù)每個(gè)數(shù)據(jù)集的特性（如區(qū)域和大小）所做的邏輯分組。Tenantizing 是一個(gè)很好的方法，可以將數(shù)據(jù)存儲(chǔ)故障的爆炸半徑限制在客戶的一個(gè)子集里，而不是一下子影響到所有人。

7、從核心服務(wù)和共享資源入手

我們已經(jīng)花了很多時(shí)間討論數(shù)據(jù)拆分的重要性。現(xiàn)在，我們換個(gè)話題，介紹下從單體中抽取服務(wù)的基礎(chǔ)工作。一定要記住，依賴方向只能從單體內(nèi)到單體外，不能反過來，否則，我們最終會(huì)得到一個(gè)分布式單體。也就是說，當(dāng)從單體中抽取服務(wù)時(shí)，要從核心服務(wù)入手，然后逐步到特性層面。接下來，找出開發(fā)人員在單體環(huán)境中開發(fā)時(shí)所使用的助力工具。隨著時(shí)間的推移構(gòu)建一些共享工具以方便單體開發(fā)，這是很常見的。例如，我們的特性標(biāo)識(shí)，可以讓單體開發(fā)者安心地將新特性從測試環(huán)境轉(zhuǎn)到生產(chǎn)環(huán)境，因?yàn)樵谶@個(gè)過程中，他們可以通過這個(gè)標(biāo)識(shí)控制誰能看到這些特性。將助力工具轉(zhuǎn)移出來，讓開發(fā)人員在單體之外也可以使用這些工具。最后，在新服務(wù)上線運(yùn)行后，務(wù)必要?jiǎng)h除舊的代碼路徑。通過工具來識(shí)別誰在調(diào)用這個(gè)服務(wù)，并規(guī)劃好如何將流量全部導(dǎo)向新服務(wù)，這樣你就不用老是為兩套代碼提供支持了。在 GitHub，我們使用一個(gè)名為 Scientist 的工具幫我們處理這種上線，我們可以用它并排運(yùn)行和比較新舊代碼路徑。

8、AuthN/AuthZ 抽取

在 GitHub，我們決定首先抽取的核心服務(wù)是身份驗(yàn)證和授權(quán)。身份驗(yàn)證相當(dāng)復(fù)雜，因?yàn)樗袞|西都依賴于它。網(wǎng)站和 Git 操作之間有一大堆的共享邏輯。也就是說，如果 github.com 宕掉了，那么 Git 系統(tǒng)就無法訪問了，即使是使用命令行窗口，也無法執(zhí)行像 pull、push 這樣的 Git 操作。這就是為什么把這些基礎(chǔ)部分抽取出來如此重要，那可以讓主要功能脫離單體而運(yùn)行。對于我們來說，身份驗(yàn)證已經(jīng)很簡單，因?yàn)槲覀円呀?jīng)在單體外部將它重寫為一個(gè)鏡像服務(wù)。當(dāng)前的 Rails 應(yīng)用程序（即我們的單體）使用 Twirp（這是一個(gè) gRPC 風(fēng)格的服務(wù)到服務(wù)通信框架）和它通信，依賴方向是由內(nèi)到外。

9、運(yùn)營變化

監(jiān)控、CI/CD、容器化都不是什么新概念，但為了支持從單體到微服務(wù)的轉(zhuǎn)型，節(jié)省時(shí)間，加速向微服務(wù)的過渡，運(yùn)營要做必要的改變。在修改這些工作流時(shí)，要時(shí)刻記著微服務(wù)的特性。與為一個(gè)大型單體運(yùn)行單個(gè)高度定制化的管道相比，為眾多小型的、獨(dú)立運(yùn)行的、基于不同技術(shù)棧的服務(wù)提供運(yùn)營支持存在很大的差別。將監(jiān)控從功能調(diào)用指標(biāo)升級為網(wǎng)絡(luò)指標(biāo)和契約接口。推動(dòng)實(shí)現(xiàn)自動(dòng)化程度更高、更可靠的 CI/CD 管道，并使其可以在服務(wù)之間共享。使用容器化技術(shù)支持各種語言和技術(shù)棧。創(chuàng)建工作流模板以實(shí)現(xiàn)重用。例如，在 GitHub，我們創(chuàng)建了一個(gè)自助服務(wù)運(yùn)行時(shí)平臺(tái)，可以用于微服務(wù)的打包交付。其目的是大幅減輕每個(gè)團(tuán)隊(duì)創(chuàng)建微服務(wù)時(shí)的運(yùn)營負(fù)擔(dān)。它提供了現(xiàn)成的 Kubernetes 模板，可自由使用的 Ingress 負(fù)載均衡設(shè)置。它可以將日志自動(dòng)提取到 Splunk，并集成了我們內(nèi)部的部署流程。這樣，任何團(tuán)隊(duì)想要試驗(yàn)或上線一個(gè)新的微服務(wù)都會(huì)更容易。

10、小處著手，考慮產(chǎn)品 / 業(yè)務(wù)價(jià)值

到目前為止，我們主要討論的還是結(jié)構(gòu)性變化，以及從單體成功過渡到微服務(wù)架構(gòu)所需要的基礎(chǔ)工作。此后，任何新特性都應(yīng)該創(chuàng)建成單體外的一個(gè)微服務(wù)。下一步，找一些簡單的小特性從單體中遷移出來，例如，那些沒有復(fù)雜依賴和共享邏輯的特性。在 GitHub，我們是從 webhook 推送和語法高亮開始的。我們希望在遷移更多更大的單體功能之前，找出常見的模式和兩種架構(gòu)之間的差別。我們是根據(jù)產(chǎn)品和業(yè)務(wù)價(jià)值來確定微服務(wù)的大小。我們通過查找經(jīng)常一起更改和部署的代碼和數(shù)據(jù)，來確定耦合度較高的特性或功能，并以此為基礎(chǔ)，自然地劃分成可以獨(dú)立于其他部分單獨(dú)迭代和部署的分組。此外，專注于產(chǎn)品和業(yè)務(wù)價(jià)值，還有助于組織內(nèi)跨工程團(tuán)隊(duì)、產(chǎn)品和設(shè)計(jì)開展緊密合作。請注意，拆分得太小往往會(huì)增加不必要的復(fù)雜度和開銷。例如，需要維護(hù)單獨(dú)的部署密鑰，更多的服務(wù)臺(tái)職責(zé)，以及由于缺少知識(shí)共享而導(dǎo)致的單點(diǎn)故障。

11、實(shí)現(xiàn)異步性和彈性代碼

從單體轉(zhuǎn)向微服務(wù)是重大的模式轉(zhuǎn)變。在這個(gè)過程中，不管是軟件開發(fā)流程，還是實(shí)際的代碼庫，都會(huì)發(fā)生很大的變化。在最后一部分內(nèi)容中，我們將快速了解下服務(wù)之間的通信以及失敗機(jī)制（designing for failure），這兩個(gè)都是微服務(wù)開發(fā)中非常重要的概念。服務(wù)之間的通信方式有兩種：同步和異步。使用同步通信，客戶端在發(fā)送請求后會(huì)等待服務(wù)器的響應(yīng)。使用異步通信， 客戶端在發(fā)送請求后不會(huì)等待響應(yīng)，每條消息都可以由多個(gè)接收者處理。在 GitHub，我們使用 Twirp 實(shí)現(xiàn)單體與單體外部核心服務(wù)（如授權(quán)）之間的同步通信。然而，隨著越來越多的服務(wù)移到單體之外，同步通信開始變得非常低效。而且，那還導(dǎo)致了服務(wù)之間的緊耦合，背離了遷移到微服務(wù)架構(gòu)的初衷。更好的做法是創(chuàng)建一個(gè)共享的事件管道，協(xié)調(diào)多個(gè)生產(chǎn)者和消費(fèi)者之間的消息。在 SendGrid，我們使用的就是這種架構(gòu)。由于服務(wù)不再是運(yùn)行在一臺(tái)服務(wù)器上，所以考慮網(wǎng)絡(luò)通信中的延遲和故障非常重要。對于大部分暫時(shí)的網(wǎng)絡(luò)問題，使用一種簡單的重試機(jī)制，定義好重試頻率和最大重試次數(shù)，就足夠了?？梢钥紤]使用指數(shù)退避讓重試邏輯變得更加智能。例如，隨著重試次數(shù)的增加延長等待時(shí)間，而不是間隔同樣的時(shí)間，從而緩解那些因?yàn)檫^載而無法響應(yīng)的服務(wù)器的壓力。作為一種自我保護(hù)和自愈機(jī)制，還可以在服務(wù)之間增加斷路器。例如，在多次嘗試失敗之后，斷路器會(huì)打開，在服務(wù)恢復(fù)之前，不再允許額外的請求進(jìn)入。為服務(wù)設(shè)置超時(shí)時(shí)間，這樣服務(wù)就不會(huì)一直等待外部服務(wù)的響應(yīng)。設(shè)法實(shí)現(xiàn)優(yōu)雅的失敗，可以向用戶展示友好的提示信息，或者恢復(fù)到緩存中上一個(gè)已知的良好狀態(tài)。關(guān)注用戶體驗(yàn)，做對企業(yè)有益的事。

12、小結(jié)

本文前 4 部分主要介紹了在開啟從單體到微服務(wù)的旅程之前應(yīng)該了解的基礎(chǔ)內(nèi)容。關(guān)注遷移原因。考慮模塊化和數(shù)據(jù)拆分。從核心服務(wù)和共享資源入手，做必要的運(yùn)營調(diào)整。做好這些準(zhǔn)備，整個(gè)組織的微服務(wù)轉(zhuǎn)型之旅就會(huì)更加令人愉快。接下來，我們討論了從哪里入手，以及如何將微服務(wù)與產(chǎn)品和業(yè)務(wù)價(jià)值聯(lián)系起來。最后，我們介紹了微服務(wù)的兩個(gè)關(guān)鍵概念：服務(wù)之間的通信和構(gòu)建彈性系統(tǒng)。

編輯：黃飛