Uber改造拓展微服務的生態環境
大小：0.4 MB 人氣： 2017-10-10 需要積分：1
標簽：微服務架構(2870)
幾個月前，我們討論到 。從那時起，Uber 有許多工程師投入了數千小時，改造拓展 Uber 微服務的生態環境。新的架構使用了多種語言以及很多不同的框架結構，鑒于重構任務非常龐大，我們也利用此機會在 Uber 使用了一套新的微服務構建技術。借助適合 SOA 遷移的技術堆棧及標準，我們改進了在 Uber 開發服務的方式。開始一項新服務
在一家快速成長的工程類公司，想要追蹤所有進行中的任務是非常困難的，需要有相應的方法，才能避免各團隊工作重復。在 Uber，我們通過要求新服務的編寫者提交 RFC（Request for Comments） 來解決這個問題。RFC 是一份關于新服務的詳細議案，其中需要列出新服務的目的、架構、依賴與其他執行細節，讓 Uber 工程部門的其他員工一并參與討論。
提交 RFC 有兩個目的：
為即將開發的服務征集反饋，以提高服務質量；
避免工作重復，或者提供合作機會。
其他一些熟悉該領域的工程師會審閱這份服務設計稿，一旦將反饋融入到服務議案中，我們就可以開始快樂地投入新服務的構建了。
執行一項新服務
我們的貨幣與匯率服務「Tincup」正是微服務在 Uber 實現的良好案例。Tincup 是最新貨幣與匯率數據的接口，負責兩個主要端點任務：
獲得貨幣目標；
獲得指定貨幣的當前匯率（兌美元）。由于 Uber 提供的是全球性的服務，這些端點非常必要。匯率經常變動，而我們的業務涉及了將近60種貨幣。
無論你在什么地方，都可以點擊按鈕隨時叫車，Tincup會為你確保自動使用當前所在國的貨幣單位支付車費。
通過新技術來引導微服務
構建 Tincup 需要重構所有與貨幣和匯率相關的邏輯，這正好為我們提供了機會，重新評估 Uber 一些很久之前所做的設計決策。我們使用了一些新的框架、協議和約定來執行 Tincup。
MVCS
首先，我們搞定了貨幣與匯率相關的整體代碼結構。近幾年，我們修改了 Uber 很多數據集的持久層（點擊【閱讀原文】查看樣例），由于所有變化都是長期而繁瑣的，從這個過程中我們學到：如果可能的話，最好將持久層規范從應用邏輯中分離出來。這樣就形成了我們所謂的 MVCS 應用開發方法：擴大常見的 MVC 方法，將應用邏輯所在的服務層也包括在內。通過隔離服務層中的應用邏輯以及應用的其他部分，就能在無需重構業務邏輯的情況下，修改或替換持久層的內容——只需改動直接與存儲/讀取相關的那部分代碼。
UDR
其次，我們考慮了貨幣與匯率的持久層。在使用 Tincup 之前，這些數據存儲在PostgreSQL 關系數據庫中，以增量整數 ID 為標記。然而這種數據存儲方法無法支持 Uber 數據中心在全球范圍內執行數據復制，無法匹配我們的 all-active（所有數據中心同時提供行程服務）工作架構。由于訪問貨幣和匯率時，需要涉及所有的數據中心，我們換掉了持久層，用 UDR（Uber 的全球復制可擴展數據庫）來代替。
預測微服務成長中的問題
在決定對貨幣及匯率作出設計改動后，我們解決了隨著工程生態環境中的微服務數量增長而自然出現的新問題。
Tornado
網絡吞吐堵塞是非常嚴重的問題，可能會導致 uWSGI 的 worker 無事可做，如果類似 Tincup 的所有服務請求都是同步的，某個服務出現問題會導致連鎖反應，并影響所有調用者。我們決定采用 Tornado，這是一個基于 event-loop 的 Python 異步框架，目的是為了防止出現阻塞。由于我們從 Flask 整體單一式數據庫中剝離了大量的代碼，選擇使大多現有應用邏輯保持不變的異步框架讓風險降到最低，對我們來說非常重要。Tornado 符合這一需求，因為它允許同步查看代碼，但不會堵塞輸入/輸出。另外還有個替代方案：為了解決上述的吞吐問題，很多服務提供者都在使用新語言 Go。
TChannel
曾經對單獨一個API的調用，現在可能扇出成大量對微服務的調用。為了促進在大型生態系統中發現其他服務，并找出故障點，Uber 的微服務在 Hyperbahn 上使用了開源的 TChannel ，這是一個 RPC 內部開發的網絡多路復用和框架協議。TChannel 為客戶端和服務器提供協議，Hyperbahn 的智能路由網將這兩者連接起來。這樣一來，微服務中產生的幾個核心問題都得以解決：
服務的發現：所有生產者和使用者都注冊到了路由網上，使用者可以通過名稱來訪問生產者，而無需知道主機或端口名。
容錯問題：路由網絡追蹤類似故障率和SLA違反之類的指標，它可以檢測到出現問題的主機，將其從可用的主機池中移除出去。
速率限制與斷路器：這些功能可以確保在請求出錯的情況下，或者從客戶端發回的響應速度過慢的時候，不會造成級聯故障。
Thrift
由于所調用服務的數量增長迅猛，很有必要為每個調用維護一個定義良好的接口。由于想用 IDL 來管理這個接口，最終我們決定了使用 Thrift。Thrift 強制服務所有者發布嚴格的接口定義，從而簡化了服務的合成過程。不遵守接口定義的調用在 Thrift 層面上就被拒絕了。對接口公開聲明的策略也強調了向后兼容的重要性，因為某個服務Thrift 接口的多個版本可能會在指定時間內同時使用。服務編寫者絕對不能對接口定義作出重大修改，只能添加一些影響不大的內容，直到消費者不再使用為止。
為生產環境的服務聯合做好準備
最終，在 Tincup 的實現階段幾近完成時，我們使用了一些有用的工具為生產環境做準備：
Hailstorm
首先，我們知道 Uber 的流量在每天、每周以及每年的時間中都是變化的，在我們預測的時間——比如新年年夜及萬圣節時會出現流量高峰，因此我們必須在發布前確保這些服務能夠處理這些增額負載。按照規定，每當在 Uber 發布新服務的時候，我們會使用內部構建的 Hailstorm 服務來加載并測試 Tincup 的端點，確定缺陷以及在壓力下出現斷點的地方。
uContainer
下一步我們考慮到了 Uber 工程部的另一個主要目標：更高效地使用硬件。由于 Tincup 是很輕量級的服務，可以很容易地與其他微服務共享機器，分享就是關愛不是嗎？當然也并非總是如此：我們還想確保每項服務都能獨立運行，不會影響在同一臺機器上所運行的其他服務。為了避免這種問題出現，我們使用 uContainer（Uber 的 Docker）來執行資源隔離與限制的任務。uContainer “人”如其名，借助 Linux 的容器性能以及 Docker 來容器化 Uber 的服務。它會將某個服務打包到某個隔離的環境中，以確保無論在同一臺主機上還有什么其他進程運行，這項服務都能持續運行。uContainer 在 Docker 的基礎上添加了：1. 更靈活的構建功能；2. Docker 容器可見度更高的工具。
uDestroy
最后，為了迎接在生產環境中不可避免會出現的宕機及網絡連接的問題，我們使用了一個內部工具uDestroy，以測試在我們控制的混亂下服務的表現——通過模擬宕機的情況，來觀察系統的彈性。在定期、有目的地破壞系統的過程中，我們可以發現漏洞并不斷努力提高系統的耐久性。
實現完成后的心得
通過構建 Tincup 來擴展 SOA ，我們學到了一些經驗：
用戶遷移是一項長期、緩慢的過程，因此盡可能將其簡單化。提供代碼實例，預測遷移完成的時間。
我們了解到：技術堆棧最好存在于小的服務中，Tincup 的應用邏輯非常簡單，因此開發者得以集中精力來研究新的技術堆棧，而不需要將精力浪費在業務邏輯的遷移細節上。
一開始先開發通用單元并執行集成測試，如果是在開發環境中，使用代碼來debug要容易得多（壓力也更小）。
盡可能提早、頻繁地執行負載測試，沒有什么能比在花了數周或數月時間執行實現，卻發現系統無法應付峰值流量更糟糕了。
Uber的微服務
Uber 遷移到 SOA 的過程為許多服務的擁有者，甚至是行業經驗貧乏的人展示了機會。開發并擁有一項服務是很大的責任，不過 Uber 開放性的知識共享文化使得選擇一套新技術以及擁有代碼庫都成為了讓人收獲頗豐的珍貴體驗。
?
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%