Airbnb的架構演進

banq發表於2022-03-13
AI架構
Jessica Tai 是 Airbnb 的一名工程經理，負責平臺基礎設施方面的工作。她在 QCon上就 Airbnb 的架構以及這些年來它是如何轉變的做了一場精彩的演講。
摘要如下：
自公司成立以來，Airbnb 的架構經歷了三個主要階段。
Airbnb 最初是一個 Ruby on Rails 單體，然後過渡到微服務架構，現在已經遷移到微服務和宏服務的混合體（一個宏服務聚合多個微服務）。
 

單體（2008 - 2017）
Airbnb 開始使用 Ruby on Rails 單體，它對公司非常有效。
大多數工程師都是全棧工程師，可以處理程式碼庫的每個部分，自己執行端到端的功能。功能可以在一個團隊內完成，這有助於公司非常快速地構建新產品。
然而，隨著 Airbnb 進入高速增長期，工程師、團隊和程式碼行的數量迅速增加。
單個工程師/團隊不可能理解並共享整個程式碼庫的上下文，因此需要所有權和團隊邊界。
由於單體應用非常緊密耦合，Airbnb 一直在努力劃定這些團隊邊界。
一個團隊中的程式碼更改對另一個團隊產生了意想不到的後果，並且誰擁有對程式碼庫不同部分造成混淆的東西。
還有其他擴充套件痛點，例如極其緩慢的部署，有時需要一天多的時間才能完成一次部署。
這些問題導致開發人員速度變慢，Airbnb 決定轉向面向微服務的方法來減少這些痛點。
  

微服務（2017 - 2020）
在從單體應用的經驗中學習之後，Airbnb 的工程師們希望在他們的微服務方法上更加自律。
他們決定有 4 種不同的服務型別

  1. 讀取和寫入資料的資料獲取服務
  2. 能夠應用功能並將不同的資料組合在一起的業務邏輯服務
  3. 用於編寫編排的工作流服務。這處理涉及跨多個服務接觸資料的操作。
  4. 一個 UI 聚合服務，將所有這些放在一起為 UI

為了避免單體應用出現所有權問題，每個微服務只有一個擁有它的團隊（每個團隊可以擁有多個服務）。
透過這些變化，Airbnb 也改變了工程團隊的結構方式。
以前，工程團隊是全棧的，能夠處理任何事情。但是現在，有了微服務，Airbnb 轉向了只專注於堆疊的某些部分的團隊。一些專注於某些資料服務，而另一些則專注於特定的業務邏輯。
Airbnb 也有一個專門的團隊負責將單體應用遷移到微服務。該團隊負責構建工具以幫助遷移，並向 Airbnb 工程師傳授微服務構建和運營的最佳實踐。
經過幾年的微服務遷移，新的挑戰開始出現。
管理所有這些服務及其依賴項非常困難。團隊需要更加了解服務生態系統，以瞭解任何依賴關係可能存在的位置。
構建端到端功能意味著在整個堆疊中使用各種服務，因此不同的工程團隊都需要參與其中：所有這些團隊都需要圍繞該功能有類似的優先順序，這很難管理，因為每個團隊都擁有多個服務。
 

微 + 宏服務 (2020 - )
為了應對這些協作挑戰，Airbnb 現在正在採用微服務和宏觀服務之間的混合方法。該模型側重於 API 的統一和整合，以便為某些資料或功能提供明確的位置。
他們正在建立一個系統，他們的內部後端服務從資料聚合服務中獲取資料。
然後，資料聚合器與各種服務塊進行通訊，其中每個服務塊都封裝了一組微服務。
Airbnb 工程師預見到這種方法的一個挑戰是資料聚合器可以成為一個新的單體。
為避免這種情況，他們對哪些資料/服務屬於哪裡的邊界非常自律。
對於服務塊層，工程師需要確保他們以乾淨的方式定義模式邊界。
有許多資料/邏輯可以跨越多個實體，因此需要明確定義。
 
欲瞭解更多詳情，您可以在此處觀看 Jessica 的完整演講。
 

相關文章