微服務架構是什么？

微服務與SOA架構微服務

維基上對其定義為：一種軟件開發技術- 面向服務的體系結構（SOA）架構樣式的一種變體，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API）。每個服務都圍繞著具體業務進行構建，并且能夠獨立地部署到生產環境、類生產環境等。另外，應盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據上下文，選擇合適的語言、工具對其進行構建。

微服務概念的由來是怎么樣的呢，參考維基百科英文版，簡單梳理后的微服務出現的歷史：

2005年：Dr. PeterRodgers在Web ServicesEdge大會上提出了“Micro-Web-Services”的概念。2011年：一個軟件架構工作組使用了“microservice”一詞來描述一種架構模式。2012年：同樣是這個架構工作組，正式確定用“microservice”來代表這種架構。2012年：ThoughtWorks的James Lewis針對微服務概念在QCon San Francisco 2012發表了演講。2014年：James Lewis和Martin Flower合寫了關于微服務的一篇學術性的文章，詳細闡述了微服務。順便說一句，這幾個人都是大名鼎鼎的，名字可能陌生，但是擺出他們的作品，相信多少是有些了解的。 Martin Flower是《重構》、《UML 精粹》的作者；Robert Martin，人稱 Bob 大叔，敏捷專家，《代碼整潔之道》、《架構整潔之道》的作者。 既然微服務是SOA架構的一種變體，那么，談微服務，SOA就是一個跨不過去的一個話題。

SOA

SOA的全稱是“Service Oriented Architecture”，中文翻譯是“面向服務架構”，1996年，由Gartner公司最早提出SOA概念。它的誕生是有其歷史背景的。

公司內部所有部門都有自己獨立的IT系統隨著每個部門的業務發展，獨立的IT系統的復雜度越來越高同時，基于這樣的背景，Gartner公司提出了SOA的概念，并且還給了一個預言，它預言在2008年，SOA會成為一種最流行的、且占有絕對優勢的軟件工程實踐辦法。

基于你對軟件行業發展的關注和理解，Gartner公司關于SOA的預言是否靠譜呢？很顯然，Gartner的預言并不是很準確，雖然在一段時間內SOA的概念、設計思路有占據過一段熱點排行，但最終它也將成為架構歷史長河中的一個匆匆過客。這也正是驗證了那句話：“沒有最好的架構，只有最合適的架構”

SOA架構圖：SOA架構示意圖

很多時候，我們認為SOA已經消失在江湖，實際上并非如此，許多傳統行業，比如物流、倉儲行業的系統都是采用SOA架構來構建的。

對于SOA，從圖中可以看到，它的每一項業務功能都是一個服務，都需要對外提供服務的能力，來完成企業所需的各項業務功能，也就意味著它具有對外提供開放的能力，這些能力無需定制化就可以實現。為什么無需定制化呢，核心就在于ESB。

ESB（ Enterprise Service Bus ）即，企業級服務總線，ESB是SOA架構中的核心，起著將企業中不同異構系統的連接在一起的作用。它本身提供了消息路由、協議轉換等等能力。通過ESB，SOA架構實現了服務與服務之間的松耦合，減少了各個服務間的依賴和相互影響。每項服務只需要關注自身對外提供的能力即可，無需關注其他服務是怎么實現的。

看到ESB的功能，是不是覺得它的功能有點似曾相識？是的，它就是微服務所需要的基礎服務。

微服務架構簡而言之，微服務架構風格 ，是一種將單個應用程序開發為一組小服務的方法，每個小服務都在自己的進程中運行并與輕量級機制（通常是 HTTP 資源 API）進行通信。 這些服務是圍繞業務能力構建的，并且可以通過全自動部署機制獨立部署。 這些服務的集中管理最少，可以用不同的編程語言編寫并使用不同的數據存儲技術。

圖：微服務架構示意圖

上面一段話是Martin Fowler關于微服務架構論文中的核心片段，從上述片段中，我們提煉出微服務架構的核心有三點：

其一是“小服務”，將應用拆分為一組小服務；

其二是“在自己的進程中運行并與輕量級機制（通常是 HTTP 資源 API）進行通信”，微服務是由獨立進程且進程之間通過輕量級機制進行通信；

其三是“可以通過全自動部署機制獨立部署”，也就是說每個微服務可以快速獨立部署。

其實這已經非常精確、精準的描述出了微服務的基本特征。完全可以作為在微服務架構實踐中落地的三個參考依據與檢驗標準。

微服務與SOA對比對比維度

微服務

SOA

舉例

技術本質

Smart endpoints and dumb pipes

Smart pipes and dumb endpoints

應用場景

互聯網行業

傳統行業或企業內部

SOA，企業OA；微服務，電商平臺

服務粒度

細

較粗

服務通信

標準化，輕量級

重量級

SOA，ESB；微服務，HTTP，RCP

服務交付

快速

較慢

微服務，服務小容易升級；SOA功能集中，較難升級

應用架構的演化圖：應用架構的變遷

最初的應用都是單體架構，所謂單體架構就是將一系列功能全部集中在一個大的應用中，比如傳統行業一般整個財務就做一個系統，將費用管理、賬務管理、薪資結算等等都集中在一起，這種架構的局限性非常明顯，不適合大規模項目的建設。

當項目逐漸變大后，代碼量逐漸增多，會出現編譯、打包費時，嚴重影響效率。當業務逐漸增多后，不同的業務創建不同的項目，不同的項目的功能模塊可能會出現重復建設的情況，造成浪費。隨著軟件架構的發展，出現SOA架構，SOA將單體架構做了拆分，拆分成粗粒度的服務，同時將部分公共功能獨立出來形成ESB，它的優點是

把模塊拆分，使用接口通信，降低模塊之間的耦合度把項目拆分成若干個子項目，不同的團隊負責不同的子項目增加功能時只需要在增加一個子項目，調用其它系統的接口就可以可以靈活的進行分布式部署但是由于SOA架構需要一個統一的通信交互（ESB）， 導致了接口開發增加工作量。

更進一步發展，微服務架構出現，對服務進一步的拆分，拆分成更細粒度的服務；進一步提供了架構選擇的多樣性，微服務架構主要優點是

開發簡單，每個服務都盡可能的小。獨立提供更小的業務能力。技術棧靈活，不需要在乎使用什么語言、數據存儲方式等服務獨立無依賴，每個服務都能獨立部署、獨立運行獨立按需擴展，更少的依賴，更高的擴展性高可用性，獨立模塊，即使一個進程宕機也不影響整體服務能力。正是因為微服務將服務拆分的更小，它同樣也帶來了一些挑戰，比如多服務運維難度增大、服務通信成本變高、數據一致性保持更難、性能監控要求提升等等。

所以業務在選擇架構的時候，應從多方面考量選擇更合適的架構。

順便說一句，這里的架構演化是指整個架構的發展歷史，并不是說你的服務就一定要經過這個演化過程，只是更多的架構模式提供更多的選擇。我們在做架構演進的時候，更多的是將單體應用演進到SOA架構或者演進到微服務架構。