Uber工程師Emily Reinhold最近介紹了他們是如何將整體式API拆分為靈活的模塊化微服務體系結構的。她重點介紹了在Uber的遷移工作中,設計和體系結構方面幾個最重要的考慮。
根據(jù) Reinhold的介紹,遷移至微服務的主要目標在于在三個指標方面實現(xiàn)更好的縮放性:應對流量的激增,更輕松地增添新功能,以及轉為使用一種在組織迅速增長的情況下能輕松適應規(guī)模變化的體系結構。
為了降低微服務之間的耦合,Uber工程師在常規(guī)設計方面做出了一些決策:
MVCS,對眾所周知的模型-視圖-控制器(Model-View-Controller)方法進行的擴展,可明確包含服務層并承載應用程序邏輯。這樣Uber就可以在業(yè)務邏輯和持久層之間實現(xiàn)解耦,借此更容易地修改持久層。 UDR,Uber的全球復制數(shù)據(jù)存儲,該技術取代了PostgreSQL,使得Uber可以通過多個數(shù)據(jù)中心同時為用戶提供乘車服務。此外為了應對大量服務所造成的后續(xù)問題,Uber工程師還對體系結構進行了一些重大更改:
異步網(wǎng)絡:為了處理數(shù)量日益增加的服務請求,Uber工程師通過一種基于Python事件環(huán)路(Event-loop)的異步網(wǎng)絡庫Tornado實現(xiàn)了同時縮放至數(shù)萬個開放連接的能力。使用Tornado的優(yōu)勢之一在于該技術可與Uber現(xiàn)有的Python網(wǎng)絡代碼集成,借此構建結構化的異步范式。 服務的發(fā)現(xiàn)和彈性:面對數(shù)量激增的服務,關鍵在于要能發(fā)現(xiàn)服務并找出故障點。例如需要收集故障率和SLA違背等指標,檢測運行狀況不正常的主機,通過短路(Circuit breaking)防止連鎖故障。Uber通過Hyperbahn使用TChannel解決了這一問題,這是一種他們自行開發(fā)并已開源的,適用于RPC的網(wǎng)絡多工(Multiplexing)和幀通訊協(xié)議。 嚴格的接口定義:Uber選擇使用Thrift通過IDL定義服務接口,并借此生成不同語言的客戶端源文件。Thrift使得他們能夠檢測出客戶發(fā)起的,與接口定義規(guī)范不符的調用。最后Reinhold還提到Uber會通過下列基本原則確保生產(chǎn)環(huán)境正常運行:
通過負載測試發(fā)現(xiàn)瓶頸和斷點。 通過容器實現(xiàn)更高的硬件利用率。 通過模擬服務中斷確保系統(tǒng)能夠順利恢復并發(fā)現(xiàn)可能存在的弱點。Emily Reinhold也曾在上一次紐約QCon活動中討論過這些話題。
查看英文原文:Breaking a Monolithic API into Microservices at Uber