Uber從單體架構轉向微服務架構
在成立之初，Uber採用單體架構構建了一款僅服務於一座城市的產品。但隨著Uber的迅速發展、核心領域模型的擴大，元件成了緊耦合的，持續整合成了很大的負擔。新增特性、Bug修復、技術債務解決，全都在單個庫中進行，這極其困難。因此，他們決定效仿那些快速成長的公司（如亞馬遜、Netflix、Twitter等）將單個程式碼庫拆分成多個程式碼庫，由單體架構遷移到微服務架構。近日，Uber官方網站介紹了這一遷移過程。
他們之所以遷移到微服務架構，主要是為了達成以下三個目標。
易見性
在遷移之前，他們已經有500多個服務，服務發現變得非常困難。每個服務都有自己的結構，服務的用法不能做到顯而易見。通常，服務提供的
- 提供客戶端庫的方式要簡單；
- 提供跨語言支援；
- 超時和重試策略可調整；
- 測試和開發高效。
因此，他們認為Uber需要一種已有的介面定義語言（IDL），而且該語言還提供了大量預構建的工具。經過評估，他們發現，Apache Thrift最能滿足他們的需求。Thrift提供一個構建可擴充套件、跨語言服務的庫和工具集合。資料型別和服務介面定義在一個語言無關的檔案中，然後生成程式碼將服務之間RPC訊息的傳遞和編碼抽象出來，而這些服務是使用不同語言編寫的。
安全性
Thrift最吸引他們的地方是其安全性。Thrift通過將服務繫結到嚴格的契約來確保安全性。該契約描述了服務的互動方式，包括如何呼叫服務、提供什麼輸入以及會產生什麼輸出。
彈性
他們從Netflix的Hystrix庫和Twitter的Finagle庫獲得了處理系統彈性問題的靈感，編寫了一個可以確保客戶端成功處理失敗場景的庫。他們後續會對此進行詳細介紹。
遺憾的是，Thrift工具集相對還不成熟，面向Python和Node的工具也不夠多。這有個風險，就是他們可能需要花費大量的時間建立這樣的工具。另外，身份驗證和跨服務跟蹤也是他們面臨的兩個挑戰。