幾個月前，Uber決定退出其基于模塊的整體monolithic架構艇挨，轉向靈活的微服務架構，此后负懦，uber花費了數千個工程小時重寫擴展微服務生態(tài)系統筒捺，使用各種語言和各種框架，這種持續(xù)的重構是一項艱巨的任務纸厉，在這里討論一下在Uber采取新技術帶來的機會和挑戰(zhàn)系吭，使用適合SOA遷移的一套技術堆棧和標準，Uber已經簡化了服務的開發(fā)颗品。下面是其原文：Rewriting Uber Engineering: The Opportunities Micr肯尺，大意如下：啟動一個新的服務在工程規(guī)模快速擴展期間躯枢，很難跟蹤所有的工作行為则吟，這種增長方式迫切呼喚一種機制來防止不同團隊的之間重復工作，在Uber锄蹂，通過要求新服務的作者必須提交一個請求注解（Request for Comment氓仲，簡稱RFC）解決了這個問題。新服務注解實際提出了對新服務的高層次目標得糜，概述服務的目標敬扛，架構和依賴以及其他Uber工程師討論的實現細節(jié)。RFC服務兩個目標：1).征求反饋意見以提高服務的開發(fā)質量朝抖。2).防止重復的工作或重復暴露合作的機會啥箭。幾個熟悉該領域的工程師負責審查服務的設計，一旦反饋已被納入到服務目標槽棍，建設這個新服務的“好玩游戲”（比喻具體實施過程是一個有樂趣的游戲）就啟動了捉蚤。實現一個新服務tincup是貨幣和匯率的服務案例，使用微服務實現的炼七，Tincup是一個及時更新現金和匯率數據的接口缆巧，它提供兩個端點服務：一個是獲得貨幣對象，另外一個是獲得該貨幣匯率（對美元的匯率）豌拙，這些端點是必要的陕悬，因為Uber是一個全球業(yè)務，匯率變化經常發(fā)生按傅，在Uber可以進行將近有60種貨幣的交易捉超。步步為營使用新技術實現微服務當構建Tincup時，重寫貨幣匯率所有邏輯提供了一次重新評估以前設計決策的機會唯绍，因此拼岳，使用了一系列新框架 協議和方式實現了Tincup。MVCS首先况芒，我們討論了有關貨幣匯率代碼的整體結構惜纸，過去已經多次修改了很多數據持久層，每一個修改都是漫長和繁瑣的，從這個過程中耐版，Uber認識到祠够，如果可能的話，最好是將應用程序邏輯從持久層細節(jié)中分離出來粪牲。這導致了一個應用程序的開發(fā)方法古瓤，稱為MVCS: 拓展了普通的MVC模式，將服務層包含到MVC中腺阳，MVCS中的S就是Service服務的意思落君，服務層是應用邏輯所在，通過將應用邏輯從其他地方分離到服務中舌狗，持久層能夠自我演進發(fā)展或被替代叽奥，這些都不會需要再重構業(yè)務邏輯了。UDR其次痛侍，我們考慮了貨幣匯率這個系統的持久層朝氓，在之前的Tincup中，數據是保存在關系數據庫PostgreSQL數據庫主届，使用自增的ID赵哲，這種數據存儲方式不能允許跨Uber全球多個數據中心復制數據，因為貨幣匯率需要從全球所有數據中心訪問君丁，因此更好持久層到UDR枫夺，這是Uber自己的全局復制可擴展伸縮的數據存儲。微服務增長的預關注在貨幣匯率系統決定了新的設計變化以后绘闷，關注點開始聚焦于微服務在工程產品領域的不斷增長上橡庞。Tornado阻斷網絡I/O是一個嚴重問題，可能會導致uWSGI任務的饑餓印蔗，如果在Tincup所有向服務的請求都是同步的扒最，一個服務的崩潰風險會引起多個連鎖反應，影響所有調用者华嘹，因此決定采取Tornado吧趣，這是一個基于事件循環(huán)的異步Python框架，能夠防止堵塞耙厚，因為是從過去整體代碼庫中分離出了很多小代碼强挫，因此選擇異步框架可以使得很多應用程序邏輯能保持不變。TChannel曾經一個API調用可能會波及大量的服務調用薛躬，為了促進大型系統中服務發(fā)現和單點風險的識別能力俯渤，Uber微服務使用了開源的Tchannel而不是Hyperbahn，后者是一個內部的多路RPC框架型宝，而TChannel提供了客戶端和服務器端的協議稠诲，使用hyperbahn智能路由網連接客服兩端侦鹏，解決了微服務中以下問題：1). 服務發(fā)現。 所有生產者和消費者將自己注冊到路由主機臀叙。消費者通過名稱訪問生產者，而不是需要知道對方的主機或端口价卤。2).容錯劝萤。 路由主機使用類似故障率和SLA進行測量∩麒担可以檢測到不健康的主機床嫌，并隨后將它們從可用主機池中刪除。3).限流和斷路器胸私。 這些功能確保壞的請求和緩慢的響應不會引起連鎖故障厌处。Thrift因為很多服務快速增長，有必要維護良好定義的結構供調用岁疼，使用IDL來管理結構阔涉，決定使用Thrift，能夠強迫服務擁有者發(fā)布嚴格的接口定義捷绒，簡化服務集成過程瑰排，不遵守接口的調用在Thrift級別就被拒絕了，而不是向服務泄漏暖侨，并導致代碼中更深層次的失敗椭住。公開聲明你的界面的這一策略強調了向后兼容性的重要性，因為服務的Thrift接口的多個版本可以在任何指定時間使用字逗。服務的作者不能進行斷崖式的變化京郑，而只能使非斷崖式的延續(xù)的兼容的接口定義，直到所有的消費者都準備好棄用葫掉。為Tincup大規(guī)模生產使用準備tincup接近完成時些举，我們使用一些有用的工具來準備生產環(huán)境tincup：Hailstorm我們意識到：Uber的流量是隨時間變化。能在預期的時間看到巨大的流量峰值挖息，像新年前夕和萬圣節(jié)金拒，所以我們必須確保服務可以處理這個突然增加的負載，建立了內部Hailstorm服務用于測試tincup端點負載和確定缺陷以及短路點套腹。uContainer有效率使用硬件是Uber工程目標绪抛，因為Tincup是一個相對輕量的服務，它可以很容易地與其他服務分享共用的同一個機器电禀。分享是重點關心嗎幢码？嗯，不總是尖飞，我們還是仍然希望確保每個服務獨立運行症副，不影響在同一臺機器上運行的其他服務店雅。為了阻止這種問題，我們使用uContainer一種Uber的Docker來部署Tincup贞铣，實現資源隔離和限制闹啦。ucontainer利用Linux容器容量和容器化Uber服務。它將一個服務封裝到一個孤立的環(huán)境中辕坝，以保證該服務將始終運行窍奋，而不管同一主機上的其他運行過程。ucontainer延伸Dcoker的能力酱畅，增加兩點：1）更為靈活的構建功能2）更多的Docker容器可見性工具琳袄。uDestroy為了準備不可避免地出現在生產中的中斷和網絡連接問題，我們使用了一個內部的工具稱為udestroy纺酸，用來釋放服務的調用控制混亂窖逗。通過模擬沖突和破壞，獲得了系統的彈性的可見性餐蔬。因為我們定期故意破壞我們的系統碎紊，可以發(fā)現漏洞并不斷努力提高耐久性。事后教訓通過構建Tincup吸取了拓展SOA的幾個教訓：1.遷移消費者（服務調用者）是一個漫長的用含，緩慢的過程矮慕，所以盡量讓它變得容易。提向遷移者提供供代碼示例以及預算時間啄骇。2.最好在一個小服務中學習一個新的技術棧痴鳄。tincup的應用邏輯是非常簡單的，它可以讓開發(fā)者專注于學習新的技術棧缸夹，而不是詳細的遷移業(yè)務邏輯痪寻。3.投入時間用于開發(fā)額外的單元和集成測試代碼。如果在開發(fā)環(huán)境中完成完成測試虽惭，代碼的調試問題要容易得多（少有壓力Ｏ鹄唷）。4.負載測試要盡早且經常芽唇。沒有什么比發(fā)現你的系統不能處理高峰流量更壞的事情顾画，尤其你已經花了幾個星期或幾個月的具體實現以后。Uber的SOA遷移提供了很多人擁有自己服務的機會匆笤，即使是那些只有有限的行業(yè)經驗的人研侣。擁有一個服務意味著一個很大的責任，但Uber的開放炮捧、知識共享文化使學習新的技術和擁有一個代碼庫變成一種榮耀和寶貴的經驗庶诡。
轉載地址：http://www.jdon.com/48183