學習筆記 - 微服務

引子

隨著領域驅動設計、持續交付、按需虛擬化、基礎設施自動化、小型自治團隊、大型叢集系統這些實踐的流行，微服務也應運而生——微服務不是被發明出來的，而是從現實世界中總結出來的一種趨勢。

微服務的第一步——高內聚低耦合

低耦合：修改一個服務不需要修改另外一個服務。

能夠獨立修改及部署單個服務而不需要修改系統的其他部分，這是使用微服務最重要的一點。一個鬆耦合的服務應該儘可能少地知道與之協作的那些服務的資訊，意味著應該限制兩個服務之間不同呼叫形式的數量，因為除了潛在的效能問題之外，過度的通訊可能會導致高耦合。

高內聚：把相關行為聚集在一起，把不相關行為放在別處。

如果我們要改變某個行為的話，最好能夠只在一個地方進行修改，然後就可以儘快地釋出。如果需要在很多不同的地方做修改，那麼可能就需要同時釋出多個微服務才能交付這個功能。在多個不同的地方進行修改會降低速度，同時部署多個服務風險也很高，這兩者都是我們想要避免的。

所以，找到問題域的邊界就可以確保相關的行為放在同一個地方，並且它們會和其他邊界以儘量低耦合的形式進行通訊。

持續整合

什麼是CI? 我們可以引用Jez Humble（《持續交付》的作者，持續交付的書名來源於敏捷宣言的第一條原則：“我們的首要任務是儘早持續交付有價值的軟體並讓客戶滿意。”）提出的三個問題用來測試我們是否真正理解CI。

我們是否每天簽入程式碼到主線？

我們應該保證程式碼能夠與已有程式碼進行整合。如果我們的程式碼和其他人的程式碼沒被頻繁地放在一起，那麼將來的整合就會非常困難。即使我們只使用生命週期很短的分支來管理這些修改，也要儘可能頻繁地把程式碼撿入到單個主線分支中。

我們是否有一組測試來驗證修改？

如果沒有測試，我們只能知道整合後沒有語法錯誤，但無法知道系統的行為是否已經被破壞。沒有對程式碼進行驗證的CI不是真正的CI。

當構建失敗後，我們是否把修復CI當作第一優先順序的事情來做？

綠色的構建意味著，我們的修改已經安全地和已有程式碼整合在一起。紅色的構建意味著，最後一次修改很可能有問題，這時只能提交修復構建的程式碼。如果我們允許別人在構建失敗時提交更多的修改，用於修復構建的時間就會大大增加。

ThoughtWorks武漢辦公室

將持續整合對映到微服務，每個微服務都會有自己的程式碼庫和構建流程。

持續整合

契約測試

契約測試最開始的概念由Martin Fowler（ThoughtWorks首席科學家） 提出， 它又被稱之為消費者驅動的契約測試（CDC：Consumer Driven Contracts）。這裡的契約是指軟體系統中各個服務間互動的資料標準格式，更多的指消費端（client）和提供端（server）之間互動的資料介面的格式。

系統工程中存在這樣的理論：線性系統（即複雜性隨規模線性增長的系統）的可靠性等於組成它的各個元件的可靠性之乘積。這容易理解，因為整個系統正常工作的條件是必須每個元件都同時正常工作。

線性系統的可靠性

如上圖表述的由三個元件共同支撐的系統。如果每個元件的可靠性是90%，那麼整個系統的可靠性就是 90%×90%×90%=72.9%，我們可以看到系統整體的可靠度是低於任一元件的可靠性的。如果一個系統由100個元件組成，每個元件即使能達到99%的可靠性，那麼整個系統的可靠性也會降到36.6%左右。

我們常說複雜性是軟體工程的最重要的特性，一個完善的軟體系統必然是由很多的子系統、元件共同撐起來的。隨著業務的複雜度越來越高，整個系統也變得越來越龐大和錯綜複雜，在微服務的架構下通常一個消費端會與多個服務端相互互動，可以想象一下如果某一個服務的介面發生變化將會影響整個系統的執行。

在微服務模式下如何保證各個服務端與消費端之間以及服務與服務之間能夠可靠的互動呢？在服務端介面發生變化的情況下通過契約測試可以很容易的測試出契約不匹配，在整合測試之前發現問題，儘早解決。（一般契約測試是在單元測試之後，整合測試之前進行的，首先在保證各自功能正確的前提下測試消費者和提供者的契約是否相匹配，然後再進一步的測試功能的完備性和整個業務流的正確性。）

契約測試

所以，契約測試能解決這樣的問題：

可以使得消費端和提供端之間測試解耦，不再需要客戶端和服務端聯調才能發現問題。

完全由消費者驅動的方式，消費者需要什麼資料，服務端就提供什麼樣的資料，資料契約也是由消費者來決定的。

測試前移，越早的發現問題，保證後續測試的完整性。

通過契約測試，團隊能以一種離線的方式（不需要消費者、提供者同時線上），通過契約作為中間的標準，驗證提供者提供的內容是否滿足消費者的期望。

後記

去中心化與微服務——為了最大化微服務能帶來的自治性，我們需要持續尋找機會，給擁有服務的團隊委派決策和控制權。讓團隊與組織保持一致，構建面向業務服務的團隊，幫助團隊的每個成員共同對系統技術願景的演化負責。

逐步開始的重要性——在有能力大規模使用微服務之前，請花費一定的時間來構建工具和實踐，幫助管理微服務。這個過程可以幫助我們瞭解組織改變的意願和能力，這將有助於正確地採用微服務。

本文作者萬學凡，ThoughtWorks首席諮詢師，武漢。作者保留本文一切權利，未經許可請勿轉載。