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