背景

軟體開發是一個不斷發展的過程，從當初的面向過程為主到如今的面向物件的開發，軟體開發者不斷探索與實踐更加符合時代發展要求的開發樣式與架構思想，而這，也在極大程度上提高了軟體開發的效率。

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

三層架構

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

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

單體系統

三層架構是一種經典的單體應用架構。單體系統有的特點就是，開發、測試、部署都比較簡單，以前我所在的公司，因為效能問題，幾乎需要花大力氣重構系統的時候，卻發現只需要再加幾臺伺服器就可以很簡單的解決這個問題了，這說明瞭系統的水平擴張也非常簡單。但即便他這麼簡單，現在也已經不再推薦去做了。

單體系統意味著公司所有的業務邏輯都被整合進去了，想要一個新人快速上手幾乎不太可能，同時老員工離職所帶來的風險也是不可估量的。隨著大量功能的整合，也對未來新需求的繼續整合帶來了很大的困難，牽一發而動全身，實在讓人無可奈何。更重要的是，網際網路的快速發展，要求我們要做到快速開發、快速整合、快速上線、快速迭代，而單體應用很難做到這點，因為很多團隊都會要求對系統的核心功能進行回歸。

所以從架構角度對系統進行拆分就成了一種必要，SOA也隨之誕生，本文不會具體討論SOA，只會簡單說明一下SOA關於系統拆分的理念。SOA是一種粗粒度、松耦合服務架構，服務之間透過簡單、精確定義介面進行通訊，不涉及底層程式設計介面和通訊模型。相對而言，SOA對系統拆分的力度似乎沒有太“微”，但是和微服務思想幾乎沒有什麼太大的區別了。

微服務與SOA

微服務與SOA的區別（由於很多場景下，SOA會使用到ESB，放在這裡也方便與微服務做更好的比較，多說一句，ESB逐漸被P2P的虛擬匯流排所替代），如下圖所示

透過上圖，可以知道微服務與SOA最大的區別在於，SOA使用了ESB來整合基於不同協議的服務之間的互動工作，而微服務去除了中間的管道，以服務化方式進行互動和整合。

	SOA	微服務架構
關註點	關註可重用性的最大化，但服務粒度較大	徹底實現伺服器的元件化，服務粒度較小，並關註“背景關係邊界”
通訊協議	（通常會透過ESB排程）支援多種訊息協議	使用輕量級協議，推薦使用REST full風格，如HTTP
開發與交付	修改時，由於依賴較大，往往牽扯麵很大，交付並不靈活	可以只是基於一套服務，交付快捷靈活
資料儲存	可共享資料儲存	每個微服務擁有獨立的資料儲存
部署	使用通用平臺	可以不基於通用平臺
服務治理	共同的治理和標準	服務微治理，實時生效
趨勢	DevOps、持續交付、容器，做的並不是很好	DevOps、持續交付、容器在微服務方面的實踐非常的豐富

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

微服務特性

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

• 徹底的元件化
  • 徹底的元件化有著極好的靈活性和可替換性，明確了單一職責，它可以在不影響或者極少影響其他業務元件的情況下進行快速迭代與快速交付，也實現了業務的高度內聚
  • 
• 技術的異構性
  • 在微服務架構中可以根據不同的業務特徵採用不同的技術方向，有針對性的解決具體的業務問題
  • 
• 獨立儲存與部署
  • 每個微服務擁有自己的資料庫，並部署在不同的平臺上
  • 
• 圍繞業務組建團隊
  • 不同於傳統的IT團隊，對技能以及職責的區分非常明確，在微服務裡，提供以業務為核心，按業務能力組建團隊，因此團隊成員的技能是跨領域的一體化團隊，通常團隊不會太大。
  • 

寫到最後

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

• 加大分散式系統的複雜度：隨著服務的拆分，原先基於行程內通訊的功能被遷移到了行程間通訊或者網路通訊，增加了不穩定性；也會存在服務版本的變化必須相容其他服務的問題，從而導致介面版本過多，存有大量的重覆程式碼
• 測試壓力與運維成本：原先的一個系統被拆分出了很多套微服務，這些都需要增加測試與運維的投入
• 服務治理與監控也非常複雜，需要有人力的投入

所以，微服務的進行，需要根據現狀在做決定，切不可為了拆分而拆分