從服務化談起

軟件的協作方式並不是憑空而來，而是依據很多我們實際生活中的既有規則來設計的。理解軟件架構模式演化背後的動機，可以從我們實際生活中的場景尋找答案。傳統的農耕社會，大家的協作方式是以物換物。很容易出現需要一張羊皮，卻換回來一只羊的情況，如果這只羊攜帶了某種病毒，那問題就麻煩了。依賴軟件包進行開發就非常類似這種情形，某個軟件包有n個方法，而使用者通常僅需要少數幾個，一旦未被使用的部分有漏洞，則非常尷尬了。

可不可以僅僅按需使用呢？對，答案就是服務化。某個服務用或者不用，都在那裏。當然，依賴軟件包還有跨語言的問題，也存在大量資源浪費的問題。通過一種“契約式協議”，確定了輸入和輸出的邏輯關系，然後就可以按照需要進行使用。這就像銀行的存取款業務，服務一直在那裏，何時用、用哪些由您的需要決定。

服務化帶來的最大好處是可替代性增強。只要遵守“契約協議”，那麽就可以作為服務提供者。從設計角度來說，如果需要支持提供相同標準的多個服務提供者，那麽就需要考慮從需求出發，設計滿足需求的最小功能集的服務。

軟件分層架構

早期的時候，三層架構非常流行，展現層、邏輯層和數據庫層各司其職。每一層把各個功能的邏輯集中到一起，但是功能和功能之間沒有邊界。為了更好地體現“契約”，通常業務邏輯會由接口和實現接口的方法組成。但是功能邊界的問題依然沒有解決。

邊界不明確帶來的問題則是任何一個改動，幾乎整個大的功能都必須進行一次全面測試，因為無法確定這個改動的影響範圍。軟件規模越大，帶來的潛在風險越大，事故所造成的影響也越大。分層並不能使得開發人員在業務邏輯上聚焦，反而隨著業務越來越復雜，開發人員的負擔也會越來越重。

邊界的劃分

有一種模式在較長一段時間內被認為是很好的解決方案，那就是 MVC。這種模式最突出的特點就是數據和展現存在某種對應關系，控制層只做請求的轉發。比如某個頁面做列表展示，那麽只需要通過業務邏輯層獲取數據，然後綁定到數據對象上即可，展現層會根據數據去渲染。

這種通過頁面功能進行的邊界劃分，對於開發來說，通過不同的控制器可以較好地實現功能邊界隔離。但是，在某些場景下，某個功能的處理速度成為瓶頸，就會成為整個系統的瓶頸。然而，又無法針對某些場景下才用到的邏輯進行水平擴容。所以，必須從業務的角度去識別某些需要具備“彈性”的邏輯，然後從“物理”上進行隔離。

上雲與雲原生

應用上雲是一個曾經很熱的話題，這個問題最關鍵的不是能不能上雲，而是上雲之後怎麽辦。如果沒有使用雲的“彈性”，那麽上雲也就失去了意義。對既有系統的改造成為了重中之重，但是這個過程是非常痛苦的，涉及的方方面面太多，風險也會很大。於是，大家希望直接從設計之初就充分考慮雲的特性，然後再開發適應雲環境的應用。

當劃分好了業務邊界之後，每一個部分的職位就會相對單一，當然，這些部分都是服務化的。服務之間的交互采用標準的基於消息的協議，所有動作都是基於事件驅動。那麽當服務的職責足夠明確、單一，是否就是我們通常所說的微服務呢？其實，還不是！服務在雲上，必須具備一些特定屬性。

微服務特性

能夠稱之為微服務，則需要滿足雲原生的要求，這樣即使上雲也是很簡單的一個步驟。作為分布式系統中的一個組件，必須滿足：

• 具備熔斷機制

  某個服務可能依賴另一個服務，當被依賴的服務無法訪問時，則外部請求直接返回。當被依賴的服務恢復時，服務必須能夠自動更新熔斷狀態，外部請求可以直接訪問被依賴服務。

• 能夠獨立構建、測試和部署

  微服務開發通常由某個微型團隊負責，由於業務邊界比較清晰，業務邏輯也非常固定，所以可以按照自己的節奏進行叠代和升級。

• 支持健康檢查 微服務啟動後，可能是被依賴的服務，那麽被其他服務調用時，熔斷器可能會通過健康檢查結果設置自身容器狀態，所以必須具備健康檢查相關的接口。

• 支持重試機制

  服務在訪問被依賴服務時，很可能由於網絡延遲等原因獲取不到結果，但是重試機制可以確保，在一定的時間內獲取到結果。所以，分布式系統訪問的結果為：成功、失敗和超時。

• 配置註入

  微服務實例在運行時，可能會根據負載進行彈性伸縮，所以，依賴必須在運行時註入，而不能在編譯打包時固定，更加不能依賴基礎設施信息，比如IP地址等。

Kubernetes

Kubernetes 已經成為容器編排的事實標準，提供了很多特性來支持雲原生應用的部署。比如 Service、ReplicaSet、Deployment、ConfigMap&Secret 等等，其強大的社區已經逐漸影響到了其他容器編排引擎，比如 Mesos、Swarm 等等。基於 Kubernetes 打造企業輕量級 Paas 平臺已經成為了趨勢。

總結

微服務並不是憑空而來的，更不只是規模小。了解微服務的誕生過程，理解了背後的動機就能夠準確把握微服務拆分的粒度，以及在實踐微服務過程中要把握的要點。

作者：付輝，JFrog 資深工程師/DockOne社區翻譯

歡迎轉載，但轉載請註明作者與出處。謝謝！

微服務架構的原理