滿大街微服務的年代，滬江任務排程系統獨特的設計思維

微服務是一些協同工作，小而自治的服務。它是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資料是一件無聊且繁瑣的事，為了一勞永逸，常常需要做一個“打樁”服務（這裡的“打樁”並不是上海人說的黃牛的意思），例如做一個永遠返回成功的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監控；並利用監控資料進行自動觸發，實現自動伸縮，讓業務應用更具彈性。還有就是能對業務進行評價，通過監控回饋資料的手段來輔助業務和開發分析業務執行和服務執行的健康度。

我今天的分享就到這裡，謝謝大家！