剛剛看到這篇香的，立馬拿來當作今日轉貼：
A Brief History of Airbnb’s Architecture

文章裡介紹了 Airbnb 的架構從一個單體長成 SOA 的過程，包括他們在大單體時遇到的問題、逐步遷移的比對機制、SOA 的優缺點，以及他們搞的 API 框架等等。

這邊就節選一些我覺得有趣的地方，對其他部份有興趣的朋友可以直接閱讀文章。

因為搬家不是一兩天就搬得完的，所以 Airbnb 在過程中有對新舊系統的操作進行比對

例如讀取相關的操作，就同時呼叫新舊系統並且比對查詢結果，確定都沒問題之後才遷移過去

而寫入相關的操作，則是建立第二顆 DB，然後再查詢出來比對兩邊的內容

之所以對這段有興趣，是因為之前也遇過把舊系統的功能遷移到新系統的場景，喊了一聲「絞殺者模式！」就開始搬磚頭

當時也是藉由同時查詢兩邊來比對，現在看到人家也這麼幹，稍微安心了一點(?)

這篇文章裏面也整理了服務導向架構（Service-Oriented Architecture, SOA）的優缺點，也節錄上來讓大家參考（同時方便我之後查詢）

Some pros were as follows:
一些優點如下：

The system became more reliable and highly available. Even if one service went down, other parts of the service-oriented architecture could still function. 系統變得更加可靠且高度可用。即使其中一個服務出現故障，服務導向架構的其他部分仍然可以運作。

Services were now individually scalable, allowing fine-tuning of the resource allocation depending on the real needs of the system. 現在服務可以進行個別的可擴展性調整，根據系統的實際需求進行資源分配的微調。

Increased business agility due to separating different parts of the product into different services. Each team could iterate in parallel. 將產品的不同部分分開成不同的服務，能夠增加業務的靈活性。每個團隊都可以並行進行迭代。

However, there were some cons as well:
然而，也有一些缺點：

Engineers can take more time to ship a feature in service-oriented architecture because they need to first acquaint themselves with the various services. Also, any change potentially involves multiple services 工程師在服務導向架構中可能需要更多時間來發布一個功能，因為他們需要先熟悉各種服務。此外，任何變更都可能涉及多個服務。

Even though services were loosely coupled, certain patterns of logic had to be repeated across different services. 即使服務之間鬆散耦合，某些邏輯模式仍需要在不同服務之間重複。

Complicated dependency graph especially when there is a lack of API governance. This could also result in circular dependencies and also make it difficult for engineers to debug errors. 當 API 管理不足時，複雜的依賴關係圖可能會出現。這可能導致循環依賴，並使工程師難以調試錯誤。

那麼，今天的轉貼就到這邊。明天見～