Airbnb 覆盤微服務

實現平衡是一個永無止境的追求。

當業務依賴軟件質量和速度來生存時，這種平衡就更難維持了。

許多公司都面臨着持續快速交付高質量軟件的挑戰，這些軟件通過質量工程限制生命週期。

Airbnb 在加速和擴展其價值主張的過程中面臨着衆多挑戰，尤其是其信息系統的發展過程。

本文分享了 Airbnb 在質量工程方面的架構迭代之旅，並附有實用要點。

—__1 —

從單體應用到微服務，什麼都沒改變

Airbnb 和許多軟件公司一樣，也是由一些積極進取的工程師發起構建最小可行產品以進入他們的市場從而發展起來的。

該產品最初是單倉內的單體架構（在此處訪問完整的 Airbnb 單倉旅程 [1]）。Airbnb 在這種模式下從 2008 年開始發展，其功能由各小團隊完成，小團隊之間的依賴及其有限。

但在 2017 年，這個集中式架構達到了它的極限：

• 軟件變更速度降低

• 平行演進面臨限制因素

• 組件所有權混亂

Airbnb 決定採用微服務。

現有的單體應用被拆分爲前臺和後臺（分別是爲了速度的 Hyperloop 和爲了穩定性的 Treehouse）。微服務出現在各自倉庫中，而專門的服務遷移團隊負責組件的轉換。

3 年後的 2020 年，該業務的收入達到 50 億美元（直到 COVID 爆發）。團隊和微服務持續增加。但是，原來的問題又回來了：功能需要由多個服務和不同團隊同時開發。

在他們的架構口號 “我們不能影響業務增長” 的推動下，工程團隊跳出原有方式，爲這些反覆出現的問題尋找可持續的解決方案。

—__2 —

Airbnb 架構演進的挑戰

Airbnb 面臨着架構解決方案的挑戰，不但要解決現在的問題，同時要支持未來的擴張；這就是質量工程要解決的問題。

Airbnb 採用了增量和迭代過程：

1. 定義問題

2. 找到改進的解決方案

3. 使用解決方案

4. 提高解決方案採用率

5. 處理解決方案的擴展挑戰

這種方法能夠分離每個問題的關注點，找到結構化的解決方案並在以後擴展它們。

Airbnb 在採用上述方法過程中實施了以下做法：

• 提供基礎設施即代碼以提高開發人員的生產力

• 明確所有權並通過工具和可觀察性進行改進

• 定義由組織和方法支持的新架構

• 引入一個棄用工作組以加速遷移

讓我們看看前述問題是如何解決的。

提供基礎設施即代碼以提高開發人員的生產力

當業務變革能力依賴於軟件時，緩慢和錯誤的軟件開發直接影響公司的競爭力。

憑藉在微服務架構方面的經驗，Airbnb 投資了自動化和工具化。但在一系列不斷髮展的技術中需要更快的迭代週期。

務實的解決方案是在單個倉庫中投資基礎設施即代碼，從而逐步並行提升各個服務的採用率。

當運行更多服務時，就會出現理解這種複雜性的擴展挑戰。

明確所有權並通過工具和可觀察性進行改進

有太多的微服務相互捆綁；即使很小的變化也會導致相互依賴的變化和影響，掌握起來很複雜。

Airbnb 投資於提高生產力，重點支持三個領域的新架構：

1、所有權

Airbnb 部署了 “Scry Ownership”，它是技術組件所有權數據（如所有者、維護者、通信渠道）的應用管理者。

2、可觀察性

Airbnb 設置了一系列可觀察性儀表板，以系統地審查實施過程。下面是一個儀表板示例，用於跟蹤正在設置的所有權：

3、工具

數據空間仍然存在挑戰。定製的 Thrift[2] 模式是有用的序列化器和數據描述符，但它們需要其他組件來檢索產品中的數據。

Airbnb 利用 GraphQL 構建了統一的數據訪問層，直接提供查詢能力。

代碼生成是提高開發人員生產力的最後一步。隨着技術的增加，Airbnb 爲每一層的標準組件提供了模板。

通過設計指明數據類型和訪問類型的代碼註釋，數據的訪問甚至直接就被嵌入在了代碼中。

當星號看起來對齊時，就會出現另一個速度問題。這一次，中央數據聚合器組件成爲了限制因素。

定義由組織和方法支持的新架構

中央數據聚合器的構建和部署時間太慢，團隊無法按時迭代。

即使提高了生產力，累積的結構複雜性仍然太高而無法在中央組件中處理。需要一個新的組織。

熵是系統隨着時間的推移變得更加複雜的自然趨勢，需要支持和反作用力來平衡生態系統。

質量工程力量在架構、組織和方法領域發揮作用。

1、支持增長的架構

太複雜了，團隊必須對不同領域執行緩慢且成本高昂的影響分析，協調多個團隊並糾正副作用錯誤。

讓我們分析一下 “純微服務架構” 級聯問題樹：

• 複雜性過度分佈在細粒度服務中

• 這些細粒度的微服務缺乏穩定的協作點

• 缺失的粘合劑最終分佈在組件和團隊之間

• 即使是很小的變化也往往會導致混合影響

核心問題是缺乏城市化，導致單體或微服務架構缺乏模塊化和關注點分離。

Airbnb 採用了一種新的架構風格 Micro macroservices：

在這樣的架構中，每種類型的複雜性分佈是一個清晰的層：

• 統一 API 是支持產品快速迭代的微服務

• 中央數據聚合器是具有緊密耦合的穩定單體

• 服務塊外觀 API 抽象了提供實體塊的微服務。

閱讀本文 [3]，瞭解有關速度和質量架構的價值的更多信息。

2、組織一致性支持新架構

旨在支持業務目標的組織可以改變遊戲規則。這種調整對於 Airbnb 的加速發展至關重要。

該組織與不斷髮展的架構保持一致，產品團隊在統一 API 之上工作，數據聚合團隊在中央數據層（即 “膠水”），以及每個數據方面的域平臺團隊（預留、用戶）。

3、方法強制通往新架構的鋪平道路

架構審查、IT 委員會、工藝治理——這些都是用於根據當前環境和未來架構審查提出的解決方案的方法。

這種方法的價值在於作爲一種反力量，在由其他目標驅動的項目環境之外，以平衡選擇。

Airbnb 使用這些方法爲 Micro macroservices 架構鋪平了道路。

即使不包括在內，Airbnb 的管理層肯定對領導轉型和發展新模式的文化以及發展技能產生了巨大影響，從而完成了 MAMOS 的範圍。

有了這些變化，Airbnb 能夠引領平行的遷移軌道。但是棄用 Monolith 仍然需要太多時間。

引入棄用工作組加速遷移

單獨更改我們的銀行賬戶已經是一場噩夢。當需要數年時間與多個團隊協調才能完成時，這項任務就更加複雜了。

Airbnb 就像許多其他擁有遺留系統和持續業務的組織一樣：他們無法在建造新房子的同時炸燬他們居住的房子。

一個特定的組織單位致力於加速從單體架構中遷移出來，領導以下工作：

• 移動應用程序棄用達 12 個月以上

• 提升和跟蹤整體債務以獲得可見性

• 日落低使用率的終端以加速刪除

• 遷移的長期所有權

• 認識到折舊對估值有影響

這個團體有遊說的反擊力量，但對於實現遷移目標至關重要。反對單體應用不能是 “每個人的責任”。

當這項任務完成時，將面臨其他挑戰。

—__3 —

Airbnb 的架構質量工程之旅

Airbnb 架構演變的這一觀點爲 Quality at Speed 軟件提供了具體的質量工程要點。

首先，區分局部問題或擴展問題可以更好地識別潛在原因，從而更好地採用增量解決方案。

在精益方法中，Airbnb 的團隊在遇到問題時解決問題，避免不必要的預優化等浪費。

從我的角度來看，一個可行的要點在於架構，MAMOS 的其他元素是這個結構塊的對齊。

從單倉內的單體應用出發，然後根據業務發展對其進行劃分，就像他們對兩個存儲庫所做的那樣。

然後，他們的故事舉例說明了 “純微服務架構” 的問題，並被具有延遲的反饋循環的 Micro macroservices 架構所取代。

你將使用哪種架構風格？

相關鏈接：

1. https://qeunit.com/blog/airbnbs-monorepo-journey-to-quality-engineering/

2. https://thrift.apache.org/

3. https://qeunit.com/blog/how-architecture-contributes-to-quality-at-speed/

分佈式實驗室 關注分佈式相關的開源項目和基礎架構，致力於分析並報道這些新技術是如何以及將會怎樣影響企業的軟件構建方式。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/RNOXIgz2GXchddsAJMTfPQ