什麼是微服務？

微服務(Microservices Architecture)是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

微服務的概念源於2014年3月Martin Fowler所寫的文章“Microservices”martinfowler.com/articles/mi…

單體架構(Monolithic Architecture )

企業級的應用一般都會面臨各種各樣的業務需求，而常見的方式是把大量功能堆積到同一個單體架構中去。比如：常見的ERP、CRM等系統都以單體架構的方式執行，同時由於提供了大量的業務功能，隨著功能的升級，整個研發、釋出、定位問題，擴充套件，升級這樣一個“怪物”系統會變得越來越困難。

這種架構模式就是把應用整體打包部署，具體的樣式依賴本身應用採用的語言，如果採用java語言，自然你會打包成war包，部署在Tomcat或者Jetty這樣的應用伺服器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應用以目錄層次的形式打包

上圖：單體架構

大部分企業通過SOA來解決上述問題，SOA的思路是把應用中相近的功能聚合到一起，以服務的形式提供出去。因此基於SOA架構的應用可以理解為一批服務的組合。SOA帶來的問題是，引入了大量的服務、訊息格式定義和規範。

多數情況下，SOA的服務直接相互獨立，但是部署在同一個執行環境中（類似於一個Tomcat例項下，執行了很多web應用）。和單體架構類似，隨著業務功能的增多SOA的服務會變得越來越複雜，本質上看沒有因為使用SOA而變的更好。圖1，是一個包含多種服務的線上零售網站，所有的服務部署在一個執行環境中，是一個典型的單體架構。

單體架構的應用一般有以下特點：

• 設計、開發、部署為一個單獨的單元。
• 會變得越來越複雜，最後導致維護、升級、新增功能變得異常困難
• 很難以敏捷研發模式進行開發和釋出
• 部分更新，都需要重新部署整個應用
• 水平擴充套件：必須以應用為單位進行擴充套件，在資源需求有衝突時擴充套件變得比較困難（部分服務需要更多的計算資源，部分需要更多記憶體資源）
• 可用性：一個服務的不穩定會導致整個應用出問題
• 創新困難：很難引入新的技術和框架，所有的功能都構建在同質的框架之上
• 運維困難：變更或升級的影響分析困難，任何一個小修改都可能導致單體應用整體執行出現故障。

微服務架構（Microservices Architecture）

微服務架構的核心思想是，一個應用是由多個小的、相互獨立的、微服務組成，這些服務執行在自己的程式中，開發和釋出都沒有依賴。不同服務通過一些輕量級互動機制來通訊，例如 RPC、HTTP 等，服務可獨立擴充套件伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的程式語言來實現，由獨立的團隊來維護。簡單的來說，一個系統的不同模組轉變成不同的服務！而且服務可以使用不同的技術加以實現！

上圖：微服務架構

微服務設計

那我們在微服務中應該怎樣設計呢。以下是微服務的設計指南：

• 職責單一原則（Single Responsibility Principle）：把某一個微服務的功能聚焦在特定業務或者有限的範圍內會有助於敏捷開發和服務的釋出。
• 設計階段就需要把業務範圍進行界定。
• 需要關心微服務的業務範圍，而不是服務的數量和規模儘量小。數量和規模需要依照業務功能而定。
• 於SOA不同，某個微服務的功能、操作和訊息協議儘量簡單。
• 專案初期把服務的範圍制定相對寬泛，隨著深入，進一步重構服務，細分微服務是個很好的做法。

微服務訊息

在單體架構中，不同功能之間通訊通過方法呼叫，或者跨語言通訊。SOA降低了這種語言直接的耦合度，採用基於SOAP協議的web服務。這種web服務的功能和訊息體定義都十分複雜，微服務需要更輕量的機制。

同步訊息 REST

同步訊息就是客戶端需要保持等待，直到伺服器返回應答。REST是微服務中預設的同步訊息方式，它提供了基於HTTP協議和資源API風格的簡單訊息格式，多數微服務都採用這種方式（每個功能代表了一個資源和對應的操作）

非同步訊息 – AMQP, STOMP, MQTT

非同步訊息就是客戶端不需要一直等待服務應答，有應到後會得到通知。某些微服務需要用到非同步訊息，一般採用AMQP, STOMP, MQTT 這三種通訊協議

訊息格式 – JSON, XML, Thrift, ProtoBuf, Avro

訊息格式是微服務中另外一個很重要的因素。SOA的web服務一般採用文字訊息，基於複雜的訊息格式（SOAP）和訊息定義（xsd）。微服務採用簡單的文字協議JSON和XML，基於HTTP的資源API風格。如果需要二進位制，通過用到Thrift, ProtoBuf, Avro。

服務約定 – 定義介面 – Swagger, RAML, Thrift IDL

如果把功能實現為服務，併發布，需要定義一套約定。單體架構中，SOA採用WSDL，WSDL過於複雜並且和SOAP緊耦合，不適合微服務。

REST設計的微服務，通常採用Swagger和RAML定義約定。

對於不是基於REST設計的微服務，比如Thrift，通常採用IDL（Interface Definition Languages），比如Thrift IDL。

微服務整合 (服務間通訊)

大部分微服務基於RPC、HTTP、JSON這樣的標準協議，整合不同標準和格式變的不再重要。另外一個選擇是採用輕量級的訊息匯流排或者閘道器，有路由功能，沒有複雜的業務邏輯。下面就介紹幾種常見的架構方式。

點對點方式

點對點方式中，服務之間直接用。每個微服務都開放REST API，並且呼叫其它微服務的介面。

上圖：通過點對點方式通訊

很明顯，在比較簡單的微服務應用場景下，這種方式還可行，隨著應用複雜度的提升，會變得越來越不可維護。這點有些類似SOA的ESB，儘量不採用點對點的整合方式。

API-閘道器方式

API閘道器方式的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能個。通常，閘道器也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。

上圖：通過API-閘道器暴露微服務

所有的業務介面通過API閘道器暴露，是所有客戶端介面的唯一入口。微服務之間的通訊也通過API閘道器。\

採用閘道器方式有如下優勢：

• 有能力為微服務介面提供閘道器層次的抽象。比如：微服務的介面可以各種各樣，在閘道器層，可以對外暴露統一的規範介面。
• 輕量的訊息路由、格式轉換。
• 統一控制安全、監控、限流等非業務功能。
• 每個微服務會變得更加輕量，非業務功能個都在閘道器層統一處理，微服務只需要關注業務邏輯

目前，API閘道器方式應該是微服務架構中應用最廣泛的設計模式。

訊息代理方式

微服務也可以整合在非同步的場景下，通過佇列和訂閱主題，實現訊息的釋出和訂閱。一個微服務可以是訊息的釋出者，把訊息通過非同步的方式傳送到佇列或者訂閱主題下。作為消費者的微服務可以從佇列或者主題共獲取訊息。通過訊息中介軟體把服務之間的直接呼叫解耦。

上圖：非同步通訊方式

通常非同步的生產者/消費者模式，通過AMQP, STOMP, MQTT 等非同步訊息通訊協議規範。

資料的去中心化

單體架構中，不同功能的服務模組都把資料儲存在某個中心資料庫中。

每個微服務有自己私有的資料庫，其它微服務不能直接訪問。單體架構，用一個資料庫儲存所有資料

微服務方式，多個服務之間的設計相互獨立，資料也應該相互獨立（比如，某個微服務的資料庫結構定義方式改變，可能會中斷其它服務）。因此，每個微服務都應該有自己的資料庫。

每個微服務有自己私有的資料庫，其它微服務不能直接訪問。每個微服務有自己私有的資料庫，其它微服務不能直接訪問。

資料去中心話的核心要點：

• 每個微服務有自己私有的資料庫持久化業務資料
• 每個微服務只能訪問自己的資料庫，而不能訪問其它服務的資料庫
• 某些業務場景下，需要在一個事務中更新多個資料庫。這種情況也不能直接訪問其它微服務的資料庫，而是通過對於微服務進行操作。

資料的去中心化，進一步降低了微服務之間的耦合度，不同服務可以採用不同的資料庫技術（SQL、NoSQL等）。在複雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（閘道器）處理。

微服務架構的優點：

• 每個服務都比較簡單，只關注於一個業務功能。
• 微服務架構方式是鬆耦合的，可以提供更高的靈活性。
• 微服務可通過最佳及最合適的不同的程式語言與工具進行開發，能夠做到有的放矢地解決針對性問題。
• 每個微服務可由不同團隊獨立開發，互不影響，加快推出市場的速度。
• 微服務架構是持續交付(CD)的巨大推動力，允許在頻繁釋出不同服務的同時保持系統其他部分的可用性和穩定性。

微服務架構的缺點：

微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其複雜性。

• 運維開銷及成本增加：整體應用可能只需部署至一小片應用服務區叢集，而微服務架構可能變成需要構建/測試/部署/執行數十個獨立的服務，並可能需要支援多種語言和環境。這導致一個整體式系統如果由20個微服務組成，可能需要40~60個程式。
• 必須有堅實的DevOps開發運維一體化技能：開發人員需要熟知運維與投產環境，開發人員也需要掌握必要的資料儲存技術如NoSQL，具有較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰。
• 隱式介面及介面匹配問題：把系統分為多個協作元件後會產生新的介面，這意味著簡單的交叉變化可能需要改變許多元件，並需協調一起釋出。在實際環境中，一個新品釋出可能被迫同時釋出大量服務，由於整合點的大量增加，微服務架構會有更高的釋出風險。
• 程式碼重複：某些底層功能需要被多個服務所用，為了避免將“同步耦合引入到系統中”，有時需要向不同服務新增一些程式碼，這就會導致程式碼重複。
• 分散式系統的複雜性：作為一種分散式系統，微服務引入了複雜性和其他若干問題，例如網路延遲、容錯性、訊息序列化、不可靠的網路、非同步機制、版本化、差異化的工作負載等，開發人員需要考慮以上的分散式系統問題。
• 非同步機制：微服務往往使用非同步程式設計、訊息與並行機制，如果應用存在跨微服務的事務性處理，事務的實現更具挑戰性，其實現機制會變得複雜化。
• 可測性的挑戰：在動態環境下服務間的互動會產生非常微妙的行為，難以視覺化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或採取其他必要的行動。但對於特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意。

關於微服務架構的取捨

• 在合適的專案，合適的團隊，採用微服務架構收益會大於成本。
• 微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。
• 需要避免為了“微服務”而“微服務”。
• 微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

最後給大家帶來一波福利

最新架構視訊免費獲取哦

時代在變，技術在變， IT行業對程式設計師的要求是越來越高，現在的程式設計師需要學習的東西更多了， 確實是更加辛苦了，當然，能力也更強了。

在現在網際網路寒冬中java程式設計師求職越來越難，面試中要求掌握的技術也是越來越難，那麼我們到底需要掌握哪些技術才不會被淘汰呢？

小編就職於某BAT大廠多年，現在也整理出來一套java進階學習路線圖，文末領取高清大圖！！

設計模式與Spring原始碼解讀

自動化工具

工欲善其事必先利其器，不管是小白，還是資深開發，玩Java技術體系，選擇好的工具，提升開發效率和團隊協作效率，是必不可少的：

• Maven，專案管理

• Jenkins，持續整合

• Sonar，程式碼質量管理

• Git，版本管理

微服務專題

業務越來越複雜，服務分層，微服務架構是架構升級的必由之路，Java技術體系，和微服務相關的技術有哪些呢？

• 微服務框架

• Spring Cloud

• Docker與虛擬化

• 微服務架構

高併發分散式專題

高併發，高可用，海量資料，沒有分散式的架構知識肯定是玩不轉的：

• 分散式架構原理

• 分散式架構策略

• 分散式中介軟體

• 分散式架構實戰

效能優化專題

任何脫離細節的ppt架構師都是耍流氓，向上能運籌帷幄，向下能解決一線效能問題，Java技術體系，需要了解：

• 效能指標體系

• JVM調優

• Web調優

• DB調優

頭條篇幅有限，腦圖還是放不下一整副的，收集這個腦圖也是讓自己身邊很多大牛都參與過，所以也算現在Java行業最全最新的啦，現在作為粉絲福利，免費送給大家，大家可以關注我後私聊我【Java】免費領取

如何一起學習，有沒有免費資料？

以上是自己收集總結的Java架構技術圖譜，自己因為比較喜歡技術，所以收集了一些Java高併發、分散式、JVM、spring、原始碼分析和kafka等架構技術資料，如果你也對技術感興趣可以來關注我

資料領取方式：轉發+收藏後加入群聊809389099即可免費獲取

資料領取方式：轉發+收藏後加入群聊809389099即可免費獲取