微服務架構的思想已經被廣泛接受，各種最佳實踐也層出不窮。雖然有各種方法論的指導，但到了具體實踐的過程中，還是會有諸多的困惑。本文試圖剖析從單體架構到微服務架構演化背後的深刻原因，從而更好地理解微服務的精髓。
從服務化談起
軟件的協作方式並不是憑空而來，而是依據很多我們實際生活中的既有規則來設計的。理解軟件架構模式演化背後的動機，可以從我們實際生活中的場景尋找答案。傳統的農耕社會，大家的協作方式是以物換物。很容易出現需要一張羊皮，卻換回來一隻羊的情況，如果這隻羊攜帶了某種病毒，那問題就麻煩了。依賴軟件包進行開發就非常類似這種情形，某個軟件包有n個方法，而使用者通常僅需要少數幾個，一旦未被使用的部分有漏洞，則非常尷尬了。
可不可以僅僅按需使用呢？對，答案就是服務化。某個服務用或者不用，都在那裏。當然，依賴軟件包還有跨語言的問題，也存在大量資源浪費的問題。通過一種“契約式協議”，確定了輸入和輸出的邏輯關係，然後就可以按照需要進行使用。這就像銀行的存取款業務，服務一直在那裏，何時用、用哪些由您的需要決定。
服務化帶來的最大好處是可替代性增強。只要遵守“契約協議”，那麼就可以作爲服務提供者。從設計角度來說，如果需要支持提供相同標準的多個服務提供者，那麼就需要考慮從需求出發，設計滿足需求的最小功能集的服務。
軟件分層架構
早期的時候，三層架構非常流行，展現層、邏輯層和數據庫層各司其職。每一層把各個功能的邏輯集中到一起，但是功能和功能之間沒有邊界。爲了更好地體現“契約”，通常業務邏輯會由接口和實現接口的方法組成。但是功能邊界的問題依然沒有解決。
邊界不明確帶來的問題則是任何一個改動，幾乎整個大的功能都必須進行一次全面測試，因爲無法確定這個改動的影響範圍。軟件規模越大，帶來的潛在風險越大，事故所造成的影響也越大。分層並不能使得開發人員在業務邏輯上聚焦，反而隨着業務越來越複雜，開發人員的負擔也會越來越重。
邊界的劃分
有一種模式在較長一段時間內被認爲是很好的解決方案，那就是 MVC。這種模式最突出的特點就是數據和展現存在某種對應關係，控制層只做請求的轉發。比如某個頁面做列表展示，那麼只需要通過業務邏輯層獲取數據，然後綁定到數據對象上即可，展現層會根據數據去渲染。
這種通過頁面功能進行的邊界劃分，對於開發來說，通過不同的控制器可以較好地實現功能邊界隔離。但是，在某些場景下，某個功能的處理速度成爲瓶頸，就會成爲整個系統的瓶頸。然而，又無法針對某些場景下纔用到的邏輯進行水平擴容。所以，必須從業務的角度去識別某些需要具備“彈性”的邏輯，然後從“物理”上進行隔離。
上雲與雲原生
應用上雲是一個曾經很熱的話題，這個問題最關鍵的不是能不能上雲，而是上雲之後怎麼辦。如果沒有使用雲的“彈性”，那麼上雲也就失去了意義。對既有系統的改造成爲了重中之重，但是這個過程是非常痛苦的，涉及的方方面面太多，風險也會很大。於是，大家希望直接從設計之初就充分考慮雲的特性，然後再開發適應雲環境的應用。
當劃分好了業務邊界之後，每一個部分的職位就會相對單一，當然，這些部分都是服務化的。服務之間的交互採用標準的基於消息的協議，所有動作都是基於事件驅動。那麼當服務的職責足夠明確、單一，是否就是我們通常所說的微服務呢？其實，還不是！服務在雲上，必須具備一些特定屬性。
微服務特性
能夠稱之爲微服務，則需要滿足雲原生的要求，這樣即使上雲也是很簡單的一個步驟。作爲分佈式系統中的一個組件，必須滿足：
具備熔斷機制
某個服務可能依賴另一個服務，當被依賴的服務無法訪問時，則外部請求直接返回。當被依賴的服務恢復時，服務必須能夠自動更新熔斷狀態，外部請求可以直接訪問被依賴服務。
能夠獨立構建、測試和部署
微服務開發通常由某個微型團隊負責，由於業務邊界比較清晰，業務邏輯也非常固定，所以可以按照自己的節奏進行迭代和升級。
支持健康檢查 微服務啓動後，可能是被依賴的服務，那麼被其他服務調用時，熔斷器可能會通過健康檢查結果設置自身容器狀態，所以必須具備健康檢查相關的接口。
支持重試機制
服務在訪問被依賴服務時，很可能由於網絡延遲等原因獲取不到結果，但是重試機制可以確保，在一定的時間內獲取到結果。所以，分佈式系統訪問的結果爲：成功、失敗和超時。
配置注入
微服務實例在運行時，可能會根據負載進行彈性伸縮，所以，依賴必須在運行時注入，而不能在編譯打包時固定，更加不能依賴基礎設施信息，比如IP地址等。
Kubernetes
Kubernetes 已經成爲容器編排的事實標準，提供了很多特性來支持雲原生應用的部署。比如 Service、ReplicaSet、Deployment、ConfigMap&Secret 等等，其強大的社區已經逐漸影響到了其他容器編排引擎，比如 Mesos、Swarm 等等。基於 Kubernetes 打造企業輕量級 Paas 平臺已經成爲了趨勢。
總結
微服務並不是憑空而來的，更不只是規模小。瞭解微服務的誕生過程，理解了背後的動機就能夠準確把握微服務拆分的粒度，以及在實踐微服務過程中要把握的要點。
作者：付輝，JFrog 資深工程師/DockOne社區翻譯
歡迎轉載，但轉載請註明作者與出處。謝謝！