滿大街微服務的年代，滬江任務調度系統獨特的設計思惟

內容來源：2017年4月22日，滬江學習系統技術經理黃凱在「【滬江技術沙龍】 -- 漫談微服務架構實踐」進行《任務也是微服務——滬江任務調度系統微服務化介紹》演講分享。IT 大咖說（id:itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2823 | 4分鐘閱讀

嘉賓演講視頻地址：suo.im/4NWSu8

摘要

微服務是一種分佈式解決方案，它整合了過去十年來的新概念和技術。在這個滿大街都是微服務的年代，如何使用好微服務是值得研究的議題。今天我以滬江的任務調度系統爲例，從架構拆分、測試、部署到監控，引伸出我廠微服務化的設計思想。

什麼是微服務

微服務是一些協同工做，小而自治的服務。它是SOA的一種特殊表現形式，但在通訊協議和三方組件的選擇上是不一樣的，微服務的顆粒度要比SOA小。

當服務愈來愈小的時候，微服務架構的優勢和缺點也就越明顯。優勢是服務越小就越不容易出錯，性能也越高。缺點是當微服務變多的時候，對於測試人員和運維人員來講工做量要翻倍。咱們認爲若是一個服務可以在兩個星期內重構，這樣的顆粒度大小就是正好的。

咱們以滬江的任務調度系統舉例。上圖中是咱們的第一代調度系統。Task Center專門用於分發任務，並會啓不少不少worker線程進行工做，架構很是簡單。這種架構的問題就在於它不適宜擴展，host若是宕機了，全部業務就只能停下來等它修復，這是一個很嚴重的問題。針對這個問題咱們作了第二代調度系統。

首先咱們作了業務拆分。咱們把業務理解成一個工廠的流水線，有一個「Boss」專門負責接任務，而後把任務發到流水線上。Worker們從流水線上拿一個合適的任務去作，第一個worker完成後交還給流水線，下一個worker再去流水線上找合適的任務作。每個worker都對應一個不一樣的DB進行存儲它的狀態信息，boss也有DB存儲本身的狀態信息，這兩種DB是分開的。

這種架構拆解把一個單例的應用拆成好幾個小的項目，並且每一個小的服務能夠作高可用，好比啓多個boss和worker。但同時也會發現其餘問題：當任務特別繁忙，須要橫向擴展一些worker進行工做時，只能新加一臺機器，在這臺機器上再啓兩個worker。但空閒時這些新增機器沒有辦法再回收了。

針對這種資源利用率不高的狀況，咱們又作了一個改版。

咱們在第三代任務調度系統中引入了些中間件。Mesos是咱們引入的第一個中間件，它專門用於作資源調度，主要是幫咱們調度worker。只要經過API告訴Mesos經過什麼策略來分配worker，Mesos就會自動在集羣內尋找合適的資源啓動任務。經過這套系統，咱們不只能完成現有業務任務，還能夠擴展給其餘任務型業務使用。

架構拆解過程

對於微服務的拆分，我總結爲如下三點：

結構分離：要從業務的角度把任務與調度分開，把任務的生產者和消費者分開，還要把任務記錄與業務邏輯也分離。

數據庫分離：首先要整理出數據庫的外鍵，從而尋找方法打破外鍵關係，其次就是分離共享數據。

事務分離：目前業界有兩種方式，第一種是作分佈式事務，但這種方法比較慢，並且設計也很複雜。另外一種方法就是追求最終一致性。選擇哪一種方式還須要結合各自的業務場景進行選擇。

測試

推行微服務在測試階段也會遇到一些問題。好比TEST CASE增多、單個流程走不通、性能測試也變得很是重要。

上圖爲比較通用的測試金字塔，在微服務時代，金字塔的每一層測試都有不一樣的測試方法，這裏不一一列舉。這裏主要講一些重要的測試手段。

MOCK與打樁

MOCK數據：微服務經常因爲功能太小，上下依賴嚴重，若是要測試單個服務，必須模擬上游數據，Mock就成爲常規的測試手段。這裏分爲外部依賴的MOCK數據和內部之間的MOCK數據。

打樁服務：常常製做Mock數據是一件無聊且繁瑣的事，爲了一勞永逸，經常須要作一個「打樁」服務（這裏的「打樁」並非上海人說的黃牛的意思），例如作一個永遠返回成功的CALLBACK服務，有的甚至能夠作一個經過參數調節的智能打樁服務。

端到端測試

端到端測試的重要性：端到端測試在微服務場合是很是重要的，它能夠保證業務的完整性和性能。它是指站在最終用戶的角度去測試整個微服務流程，但要實現端到端的測試卻很是的困難，須要整合全部微服務。這樣的測試雖難必行，只有完成過端到端的測試，咱們纔有勇氣交付給最終用戶。

端到端測試的弊端：顯而易見，當服務越多，端到端就越不容易實現。另外，誰來寫端到端測試用例也是不明確的。通常按照職責劃分團隊的公司，很難有對整個流程都很是清楚的測試人員。最後，端到端的測試時間也難以把握。

部署

進入微服務時代後，最後一個面臨的挑戰是部署，傳統的部署方式徹底沒法適應微服務的部署方式。最主要的問題就在於一臺一服務到多臺多服務的演變：

若是沒有好的部署方式，用人力部署微服務將是一件萬分可怕的事。因此必須引入無人值守的自動化部署工具。

持續集成

把鏡像做爲構建物：不少企業已經習慣於使用虛擬機vm來增長物理服務器的利用率。這樣的好處是把操做系統隔離出來，咱們何再也不進一步，把應用和相應的環境配置文件也包含在鏡像中，經過docker等容器化技術使部署變得更快。配置文件打入鏡像的好處是避免配置漂移。（配置漂移是指在很是規條件下，運維人員或開發人員爲了修復問題或調試，手動修改了產線配置文件卻忘了恢復，使得下次發佈的app和期待的配置不符）

構建PIPELINE：Pipeline是Jenkins2推薦的自動化構建方式，微服務能夠用其餘的方式實現自動化，只是用Pipeline能更清晰的知道每一步在幹什麼。下圖是滬江微服務發佈的一個Pipeline截圖。

區分部署和上線：部署和上線是兩個感念，微服務部署完畢並不等於微服務已經上線可用。它的好處在於在部署到上線之間，能夠接入一些常規測試來避免由於部署或配置等緣由致使的線上故障。入下圖所示，滬江在上線一個微服務的過程當中，引入了藍綠髮布，既藍色部分是部署一個微服務到一個產線環境中，但對外的LB並無指向新部署的程序。此時能夠藉助自動化測試腳本或人工黑盒作最基本的測試。若是測試經過，既變成綠色部分後，再把LB指向新部署程序上實現上線過程。整個過程以下圖所示。

多服務多服務器的挑戰

部署最關鍵的問題就在於服務多，服務器也多。將面臨如下問題：

海量的日誌：

服務越多，就越難找到程序的調用鏈。若是程序的調用鏈找不到，引入服務治理是個好方法。咱們能夠在日誌中嵌入一些服務治理的信息以打點，以下圖所示，咱們在每一個微服務的之中輸出了Trace Id和Host IP等信息，以方便ELK聚合。

要評估某一類服務的服務器佔用，還能夠以服務來聚合監控。

日誌跟蹤與指標跟蹤

日誌跟蹤與指標跟蹤的工具大部分是使用ELK，它的好處是能夠幫咱們聚合不少的數據。還有一個工具就是mesos metrics，它是mesos自帶的一個小工具，它能夠統計出agent上應用運行的指標。它的好處之一是能夠幫咱們以服務名來聚合運行指標。

對於監控哪些指標，咱們的經驗是：日誌是主要的監控指標，其餘還有cpu、memory和disk等。這些指標須要以服務名稱而不是以物理機來聚合。

監控還能幹什麼？

咱們在應用上線的時候引入BVT監控；並利用監控數據進行自動觸發，實現自動伸縮，讓業務應用更具彈性。還有就是能對業務進行評價，經過監控回饋數據的手段來輔助業務和開發分析業務運行和服務運行的健康度。

我今天的分享就到這裏，謝謝你們！