Uber改造拓展微服務(wù)的生態(tài)環(huán)境

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