微服務探索與實踐—總述

背景

軟件開發是一個不斷髮展的過程，從當初的面向過程爲主到現在的面向對象的開發，軟件開發者不斷探索與實踐更加符合時代發展要求的開發模式與架構思想，而這，也在極大程度上提升了軟件開發的效率。

微服務是一種架構模式或者說是架構風格，而架構這個詞語，相信有不少人都曾試圖爲它作出明確的定義，但是很難下，由於軟件架構也在不斷髮展，內涵也在不斷獲得豐富。只是不變的是，咱們須要經過軟件架構，根據族組織、業務、技術等因素劃分出不一樣的但能夠相互協做的應用系統，使得設計出來的系統具備較高的伸縮性、可維護性以及可擴展性。

三層架構

曾經在與朋友討論微服務的時候，朋友曾經說過三層架構是否是能夠避免在某種程度上因架構設計帶來的耦合度過大問題，我跟他說應該很難，由於三層就架構更多的關注是統一系統內的職責劃分問題，而架構更多的是關注多套系統。這裏的話，順便提一下三層架構，你們對這種架構應該不會陌生，它主要包括表示層、業務邏輯層以及數據訪問層，以下圖所示

能夠發現，三層架構方式使得各層的關注點更加清晰，但若是隨着業務的擴大，三層架構只是延長了系統的生命週期，並不會對系統架構帶來太大的改變。這就須要討論單體系統帶來的問題了。

單體系統

三層架構是一種經典的單體應用架構。單體系統有的特色就是，開發、測試、部署都比較簡單，之前我所在的公司，由於性能問題，幾乎須要花大力氣重構系統的時候，卻發現只須要再加幾臺服務器就能夠很簡單的解決這個問題了，這說明了系統的水平擴張也很是簡單。但即使他這麼簡單，如今也已經再也不推薦去作了。

單體系統意味着公司全部的業務邏輯都被整合進去了，想要一個新人快速上手幾乎不太可能，同時老員工離職所帶來的風險也是不可估量的。隨着大量功能的集成，也對將來新需求的繼續集成帶來了很大的困難，牽一髮而動全身，實在讓人迫不得已。更重要的是，互聯網的快速發展，要求咱們要作到快速開發、快速集成、快速上線、快速迭代，而單體應用很難作到這點，由於不少團隊都會要求對系統的核心功能進行迴歸。

因此從架構角度對系統進行拆分就成了一種必要，SOA也隨之誕生，本文不會具體討論SOA，只會簡單說明一下SOA關於系統拆分的理念。SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。相對而言，SOA對系統拆分的力度彷佛沒有太「微」，可是和微服務思想幾乎沒有什麼太大的區別了。

微服務與SOA

微服務與SOA的區別（因爲不少場景下，SOA會使用到ESB，放在這裏也方便與微服務作更好的比較，多說一句，ESB逐漸被P2P的虛擬總線所替代），以下圖所示

經過上圖，能夠知道微服務與SOA最大的區別在於，SOA使用了ESB來集成基於不一樣協議的服務之間的交互工做，而微服務去除了中間的管道，以服務化方式進行交互和集成。

	SOA	微服務架構
關注點	關注可重用性的最大化，但服務粒度較大	完全實現服務器的組件化，服務粒度較小，並關注「上下文邊界」
通訊協議	（一般會經過ESB調度）支持多種消息協議	使用輕量級協議，推薦使用REST full風格，如HTTP
開發與交付	修改時，因爲依賴較大，每每牽扯麪很大，交付並不靈活	能夠只是基於一套服務，交付快捷靈活
數據存儲	可共享數據存儲	每一個微服務擁有獨立的數據存儲
部署	使用通用平臺	能夠不基於通用平臺
服務治理	共同的治理和標準	服務微治理，實時生效
趨勢	DevOps、持續交付、容器，作的並非很好	DevOps、持續交付、容器在微服務方面的實踐很是的豐富

總的來講，微服務是SOA的一個子集或者是升級版，它是SOA在互聯網時代發展的必然進化結果，它有力的促進了企業級系統服務架構的實踐。

微服務特性

前面有講過，微服務是一種架構風格，一個大型應用系統有一個或多個微服務組成，系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的，每一個微服務體現着單一職責原則。它主要有如下特性:

• 完全的組件化
  • 完全的組件化有着極好的靈活性和可替換性，明確了單一職責，它能夠在不影響或者極少影響其餘業務組件的狀況下進行快速迭代與快速交付，也實現了業務的高度內聚
• 技術的異構性
  • 在微服務架構中能夠根據不一樣的業務特徵採用不一樣的技術方向，有針對性的解決具體的業務問題
• 獨立存儲與部署
  • 每一個微服務擁有本身的數據庫，並部署在不一樣的平臺上
• 圍繞業務組建團隊
  • 不一樣於傳統的IT團隊，對技能以及職責的區分很是明確，在微服務裏，提供以業務爲核心，按業務能力組建團隊，所以團隊成員的技能是跨領域的一體化團隊，一般團隊不會太大。

寫到最後

微服務確實有着無可比擬的優點，可是微服務也帶來了很大的缺點：

• 加大分佈式系統的複雜度：隨着服務的拆分，原先基於進程內通信的功能被遷移到了進程間通訊或者網絡通訊，增長了不穩定性；也會存在服務版本的變化必須兼容其餘服務的問題，從而致使接口版本過多，存有大量的重複代碼
• 測試壓力與運維成本：原先的一個系統被拆分出了不少套微服務，這些都須要增長測試與運維的投入
• 服務治理與監控也很是複雜，須要有人力的投入

因此，微服務的進行，須要根據現狀在作決定，切不可爲了拆分而拆分