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