00.什麼是微服務架構

作者：由 kimmking 發表于書法時間：2019-07-01

微服務這個概念最早是在2011年5月威尼斯的一個軟體架構會議上討論並提出的，用於描述一些作為通用架構風格的設計原則。2012年3月在波蘭克拉科夫舉行的33rd Degree Conference大會上，Thoughtworks首席諮詢師James Lewis做了題為《Microservices - Java， the Unix Way》的演講（

http：//

2012。33degree。org/talk/

show/67

），這次演講裡James討論了微服務的一些原則和特徵，例如單一服務職責、康威定律、自動擴充套件、DDD等等。

微服務架構則是由Fred George在2012年的一次技術大會上所提出（

http：//

oredev。org/oredev2012/2

012/sessions/micro-service-architecture。html

），在大會的演講中他講解了如何分拆服務以及如何利用MQ來進行服務間的解耦，這就是最早的微服務架構雛形。而後由Martin Fowler發揚光大並且在2014年發表了一篇著名的微服務文章（

https：//

martinfowler。com/articl

es/microservices。html

），這篇文章深入全面的講解了什麼是微服務架構。隨後，微服務架構逐漸成為一種非常流行的架構模式，一大批的技術框架和文章湧現出來，越來越多的公司借鑑和使用微服務架構相關的技術。

然而微服務並不是萬能藥，我們在實施的過程中不能簡單的使用某些個微服務框架或者元件一蹴而就，而是需要將業務、技術和運維有機結合起來，配合同步實施，並且在此過程中還需要趟過很多的坑才能夠取得成功。

本書透過 Dubbo、Spring Cloud、Service Mesh 等技術構建微服務體系，並深入淺出的介紹了微服務架構發展歷程、領域驅動設計、穩定性保證的常用手段、分散式事務的一致性方案，以及透過大量的案例探討微服務落地方案，例如雙活體系建設，分散式監控，微服務編排，百億流量微服務閘道器的設計與實現，基於支付場景下的微服務改造等，展示了實現微服務架構的完整藍圖，並讓讀者瞭解到如何藉助於微服務來增強和重構現有的遺留系統。不管你是還沒聽過或者剛接觸過微服務的新手，還是正在嘗試藉助微服務解放生產力的開發人員或者運維人員，或者是立志於構建高可用可伸縮的微服務體系的架構師，閱讀本書，對讀者必有裨益。

本書的每一個章節都是相關領域的專家經過多年的技術積累提煉而成，秉承以理論為基礎，以大量企業實戰案例為核心，深入全面的介紹了微服務架構的實施方法以及在實施過程中所遇到的問題和解決方案，是一本內容詳實、“可落地”的理論實踐相結合的技術書籍。

內容簡介

本書共分為十四章：

第一章：微服務概述

從軟體架構的發展歷程講起，分別對單體架構、SOA架構和微服務架構的演進過程做了深入淺出的講解，同時也深入介紹了微服務架構的特點，本章以宏觀的視角為讀者開啟微服務的大門。

第二章：微服務領域驅動設計

本章介紹了領域驅動設計是什麼，常見的領域架構有哪些，如何將領域驅動應用到微服務中，以及如何使用領域驅動進行合理的服務劃分等，幫助讀者在正式學習微服務前修煉內功。

第三章：Dubbo原理與實現

目前Dubbo已經被阿里巴巴技術團隊重新維護並且得到了大力的發展和推廣，使用Dubbo依然可以很好的進行微服務建設，本章較為深入的講解了Dubbo的使用和技巧，以及透過原始碼的深入分析能夠讓讀者對Dubbo的原理實現有一個全面的認識。

第四章：Spring Cloud實戰案例

Spring Boot/Cloud是目前較為流行的微服務框架，本章以大量的實戰案例為讀者講解如何才能應用好Spring Cloud框架，以及如何避免在使用過程中遇到的坑。

第五章：微服務穩定性保證常用手段

當業務發展越來越快，規模也越來越大的情況下，我們所面臨的就是如何在服務越來越多的情況下保證微服務架構的穩定性，本章帶領讀者逐步揭開保障穩定性的常用技巧和手段。

第六章：微服務下事務的一致性保證

本章介紹了從本地事務到分散式事務的演變，深入分析了微服務在強一致性場景和最終一致性場景下的解決方案，探討了二階段提交協議、三階段提交協議、TCC 模式、補償模式、可靠事件模式等。同時，對開源專案的分散式事務進行解讀，包括 RocketMQ 和 ServiceComb。

第七章：微服務億級閘道器設計

本章從百億流量交易系統微服務閘道器（API Gateway）的現狀和麵臨問題出發，闡述微服務架構與 API 閘道器的關係，理順流量閘道器與業務閘道器的脈絡，帶來最全面的 API 閘道器知識與經驗。

第八章：微服務編排

本章以Netflix Conductor框架為核心，從框架的使用和原理深入介紹了什麼是微服務編排，為微服務執行復雜的業務邏輯提供了一種新的思路。

第九章：微服務統計與資料抽取方案

在微服務架構下，服務必將越來越多，在這各情況下如何進行資料統計和分析將變得非常困難，本章將深入講解如何從不同服務的資料庫中抽取資料到統一的大資料平臺中，幫忙使用者更方便的進行資料的統計。

第十章：微服務雙活體系建設

在企業發展規模越來越大的情況下，使用者對系統的穩定性要求也越來越高，那麼單機房佈署勢必成為發展的瓶頸，本章將帶領讀者從零開始以實際案例出發進行同城雙活的建設。

第十一章：基於支付場景下的微服務改造和效能最佳化

本章從實際的案例出發，在具體的支付業務場景下，從一個新專案開始逐步講解如何利用領域驅動劃分服務，如何利用微服務框架進行服務治理，以及專案完成後怎樣提升微服務架構的效能。

第十二章：遺留系統的微服務改造

本章介紹了遺留系統的微服務架構改造，梳理了程式碼分層結構的轉變，提出一個新的程式碼分層思路來應對微服務的流行與普及，並深入思考了遺留系統的債券，深入探討單體系統拆分服務的方法論。同時，對遺留系統的微服務架構改造的解決方案給出 9 個切實可行的核心實踐思路。

第十三章：Service Mesh的入門與案例

隨著微服務的持續發展，下一代微服務架構已然出現，本章將深入介紹Service Mesh發展歷程，以及結合具體案例帶領讀者使用Istio進行具體實踐。

第十四章：微服務監控實戰

本章重點介紹APM的原理，從零開始開發APM監控系統，還深入介紹Prometheus的安裝和原理，以及如何使用Prometheus進行監控和預警。

1.6 架構的不同風格

典型的企業級應用系統或者網際網路應用系統一般都是透過Web提供一組業務服務能力。這類系統包括提供給使用者操作的、運行於瀏覽器中、具有UI的業務邏輯展示和輸入部分，運行於伺服器端、用後端程式語言構建的業務邏輯處理部分，以及用於儲存業務資料的關係資料庫或其他型別的儲存軟體。

根據軟體系統在執行期的表現風格和部署結構，我們可以粗略地將其劃分為兩大類：

1）整個系統的所有功能單元，整體部署到同一個程序（所有程式碼可以打包成1個或多個檔案），我們可以稱之為“單體架構”（Monolithic Architecture）；

2）整個系統的功能單元分散到不同的程序，然後由多個程序共同提供不同的業務能力，我們稱之為“分散式架構”（Distributed Architecture）；

任何一個體系（產品、平臺、商業模式等）如果想要發展壯大，途徑只有兩個模式：

a）容器模式：從外部提供越來越多的資源和能力，注入到體系的內部，不斷的從內擴充自己。單體架構的系統類似這種模式。

b）生態模式：以自己的核心能力為核心，持續的在外部吸引合作者，形成一個可以不斷成長的生態體系。分散式架構越來越像這種模式。

再結合軟體系統在整個生命週期的特點，我們可以進一步區分不同的架構風格。

對於單體架構，我們根據設計期和開發實現期的不同模式和劃分結構，可以分為：

簡單單體模式：程式碼層面沒有拆分，所有的業務邏輯都在一個專案（project）裡打包成一個二進位制的編譯後文件，透過這個檔案進行部署，並提供業務能力；

MVC模式：系統內每個模組的功能元件按照不同的職責劃分為模型（Model）、檢視（View）、控制器（Controller）等角色，並以此來組織研發實現工作；

前後端分離模式：將前後端程式碼耦合的設計改為前端邏輯和後端邏輯獨立編寫實現的處理模式；

元件模式：系統的每一個模組拆分為一個子專案（subproject），每個模組獨立編譯打包成一個元件，然後所有需要的元件一起再部署到同一個容器裡；

類庫模式：A系統需要複用B系統的某些功能，這時可以直接把B系統的某些元件作為依賴庫，打包到A系統來使用。

對於分散式架構，我們根據設計期的架構思想和執行期的不同結構，可以分為：

面向服務架構（Service Oriented Architecture，SOA）：以業務服務的角度和服務匯流排的方式（一般是WebService與ESB）考慮系統架構和企業IT治理；

分散式服務架構（Distributed Service Architecture，DSA）：基於去中心化的分散式服務框架與技術，考慮系統架構和服務治理；

微服務架構（MicroServices Architecture，MSA）：微服務架構可以看做是面向服務架構和分散式服務架構的拓展，使用更細粒度的服務（所以叫微服務）和一組設計準則來考慮大規模的複雜系統架構設計。

此外，傳統的企業整合領域的EAI架構模式，本身還是各個系統獨立部署，但是各系統之間的部分業務使用特定的技術打通了，因此我們可以看做是單體和分散式之間的過渡狀態。

也有人把如上的各個架構風格總結為4個大的架構發展階段，如圖1-6所示：

1）單體架構階段

2）垂直架構階段

3）SOA架構階段

4）微服務架構階段

微服務架構發展階段

圖1-6

1.6.1 單體架構：簡單單體模式

簡單單體模式是最簡單的架構風格，所有的程式碼全都在一個專案中。這樣研發團隊的任何一個人都可以隨時修改任意的一段程式碼，或者增加一些新的程式碼。開發人員也可以只在自己的電腦上就可以隨時開發、除錯、測試整個系統的功能。也不需要額外的一些依賴條件和準備步驟，我們就可以直接編譯打包整個系統程式碼，建立一個可以釋出的二進位制版本。這種方式對於一個新團隊的創立初期，需要迅速開始從0到1，抓住時機實現產品最短時間推向市場，可以省去各種額外的設計，直接上手幹活，爭取了時間，因而是非常有意義的。

但是這種簡單粗暴的方式對於一個系統的長期穩定發展確實有很多壞處的。但是正如一個新出生的小動物野蠻生長，如果沒有正確的教導和規則的約束，最後成為一個忠實的導盲犬還是一條攜帶病毒的狂犬，就不得而知了。

首先，簡單單體模式的系統存在程式碼嚴重耦合的問題。所有的程式碼都在一起，就算是按照package來切分了不同的模組，各不同模組的程式碼還是可以直接相互引用，這就導致了系統內的物件間依賴關係混亂，修改一處程式碼，可能會影響一大片的功能無法正常使用。為了保障每次上線時的可靠性，我們必須花費很多的精力做大量的迴歸測試，對於經常需要修改維護的系統，這種代價是可怕的。

第二，簡單單體模式的系統變更對部署影響大，並且這個問題是所有的單體架構系統都存在的問題。系統作為一個單體部署，每次釋出的部署單元就是一個新版本的整個系統，系統內的任何業務邏輯調整都會導致整個系統的重新打包，部署、停機、再重啟，進而導致了系統的停機發布時間較長。每次釋出上線都是生產系統的重大變更，這種部署模式大大提升了系統風險，降低了系統的可用性。

第三，簡單單體模式的系統影響開發效率。如果一個使用Java的簡單單體專案程式碼超過100萬行，那麼在一臺膝上型電腦上修改了程式碼後執行自動編譯，可能需要等待十分鐘以上，並且記憶體可能不夠編譯過程使用，這是非常難以忍受的。

第四，簡單單體模式打包後的部署結構可能過於龐大，導致業務系統啟動很慢，進而也會影響系統的可用性。這一條也是所有單體架構的系統都有的問題。

第五，擴充套件性受限，也是所有單體架構的一個問題。如果任何一個業務存在效能問題，那麼都需要考慮多部署幾個完整的例項的叢集，或者再加上負載均衡裝置，才能保證整個系統的效能可以支撐使用者的使用。

所以，簡單單體模式比較適用於規模較小的系統，特別是需要快速推出原型實現，以質量換速度的場景。

1.6.2 分散式架構：面向服務架構（SOA）

隨著IT技術逐漸成為各行各業的基礎性支撐技術之一，並且很多大型公司內部的IT系統規模越來越大，傳統架構思想的不足越來越明顯。針對如何更好的利用企業內部的各個IT系統能力，解決資料孤島問題，整合業務功能，先是出現了企業應用整合（Enterprise Application Integration，EAI）解決方案，即透過對現有各系統的資料介面改造，實現系統互通（特別是異構系統），這樣不同系統的資料就可以被整合到一起了。在大量的EAI專案實施的基礎上，架構設計關注的不僅僅是單個的專案，而是企業的整個IT系統集合。架構師們以超越單體架構的分散式思想和業務服務能力的角度來看待問題，這樣面向服務架構即SOA就發展起來了。

2006年IBM、Oracle、SAP、普元公司等一起建立了OSOA聯盟，共同制定 SCA/SDO標準。2007年4月，國際標準組織OASIS宣佈成立OASIS Open Composite Services Architecture （Open CSA）委員會，自此，OSOA的職能移轉至Open CSA組織。

SOA的概念最初由Gartner公司提出，2000 年以後，業界普遍認識到SOA思想的重要性。從2005年開始，SOA推廣和普及工作開始加速，幾乎所有關心軟體行業發展的人士都開始把目光投向SOA，各大廠商也透過建立廠商間的協作組織共同努力制定中立的SOA標準：SCA/SDO規範。同時產生了一個Apache基金會頂級專案Tuscany作為SCA/SDO的參考實現。SCA和SDO構成了SOA程式設計模型的基礎。經過10多年的廣泛探索研究和實際應用，SOA本身的理論、相關技術、工具等也已經發展到成熟、穩定的階段，在資訊化系統建設時普遍採用了SOA架構思想。

1.6.2.1 服務與SOA

面向服務架構（SOA）是一種建設企業IT生態系統的架構指導思想。SOA的關注點是服務。服務最基本的業務功能單元，由平臺中立性的介面契約來定義。透過將業務系統服務化，可以將不同模組解耦，各種異構系統間可以輕鬆實現服務呼叫、訊息交換和資源共享。

1）從宏觀的視角來看，不同於以往的孤立業務系統，SOA強調整個企業IT生態環境是一個大的整體。整個IT生態中的所有業務服務構成了企業的核心IT資源。各系統的業務拆解為不同粒度和層次的模組和服務，服務可以組裝到更大的粒度，不同來源的服務可以編排到同一個處理流程，實現非常複雜的整合場景和更加豐富的業務功能。

2）從研發的視角來看，系統的複用可以從以前程式碼級的粒度，擴充套件到業務服務的粒度；能夠快速應對業務需求和整合需求的變更。

3）從管理的角度來看，SOA從更高的層次對整個企業IT生態進行統一的設計與管理，對訊息處理與服務呼叫進行監控，最佳化資源配置，降低系統複雜度和綜合成本，為業務流程梳理和最佳化提供技術支撐。

在SOA體系下，應用軟體被劃分為具有不同功能的服務單元，並透過標準的軟體介面把這些服務聯絡起來，以SOA架構實現的企業應用可以更靈活快速地響應企業業務變化，實現新舊軟體資產的整合和複用，降低軟體整體擁有成本。

1.6.2.2 SOA戰略

SOA的實施對整個IT生態環境都有重要的影響，作為一種重大的IT變革和技術決策，必然要自上而下的進行。必須獲得管理層的支援，由技術決策層面直接推動，並和技術部門、相關業務部門一起，根據目前各個IT業務系統的現狀，統一規劃SOA戰略和分階段目標，制定可行方案與計劃步驟，逐步推進實施。

1.6.2.3 SOA落地方式

SOA的落地方式與水平，跟企業IT特點、服務能力和發展階段直接相關。目前常見的落地方式主要有分散式服務化和集中式管理兩種。

1）分散式服務化

網際網路型別的企業，業務與技術發展快，資料基數與增量都大，併發訪問量高，系統間依賴關係複雜、呼叫頻繁，分散式服務化與服務治理迫在眉睫。透過統一的服務化技術手段，進一步實現服務的註冊與定址、服務呼叫關係查詢、服務呼叫與訊息處理監控、服務質量與服務降級等等。現有的一些分散式服務化技術有dubbo（基於java）、finagle（基於scala）和ICE（跨平臺）等。

2）集中式管理化

傳統企業的IT內部遺留系統包袱較重，資源整合很大一部分是需要打通新舊技術體系的任督二脈，所以更偏重於以esb作為基礎支撐技術，以整合整合為核心，將各個新舊系統的業務能力逐漸的在ESB容器上聚合和整合起來。比較流行的商業ESB有IBM的WMB和oracle的osb，開源esb有mule、servicemix、jbossesb、wso2esb和openesb。

商業的esb，一般來說除了功能豐富以外，配套設定都比較齊全，對於比較簡單的場景來說可以做到開箱即用，維護性也比較強，但是一般來說過於複雜非常難用、內部基本是黑盒、而且很貴。

開源的esb，由於開發成本和通用性開放性的考慮，往往在esb server上做的比較強大、擴充套件性比較好，但是配套設定做的很差（這也是絕大多數開源專案共有的問題，不僅是開源esb的問題）。對企業來說可管理性非常重要，選擇開源esb的話，這一塊需要結合企業的實際情況，一步步的積累，下大功夫來自己做好。

一方面，集中式管理的SOA，其優勢在於管理和整合企業內部各處散落的業務服務能力，同時一個明顯的不足在於其中心化的架構方法，並不同解決各個系統自己內部的問題。另一方面，隨著自動化測試技術、輕量級容器技術等相關技術的發展，分散式服務技術越來越像微服務架構方向發展。

EIP（Enterprise Integration Patterns，企業整合模式）是整合領域的聖經，也是各種MOM和ESB的理論基礎。我們在MQ和ESB中常見的各種概念和術語，基本都是來自於EIP，比如訊息代理、訊息通道、訊息端點、訊息路由、訊息轉換、訊息增強、資訊分支、訊息聚合、訊息分解、訊息重排等等，並在《企業整合模式：設計、構建及部署訊息傳遞解決方案》一書中詳細的描述了它們的內容與特點。

EIP的直接實現一般叫EIP框架，開源的知名EIP框架有兩個：camel和spring integration。EIP可以作為ESB的基礎骨架，在這個基礎上填充其他必要的部分，定製出來一個ESB容器。

EIP的介紹可以看這裡：

http：//www。

enterpriseintegrationpatterns。com

1.6.2.4 SOA的兩大基石：RPC與MQ

SOA關注於系統的服務化，不同系統服務間的相互通訊就成為了一個重要的話題。並且隨著RPC和MQ技術的發展，這兩種技術逐漸成為SOA的兩大基石，也是分散式技術體系裡的重要基礎設施。

1） RPC（Remote Procedure Call，遠端過程呼叫）

兩個不同系統間的資料通訊，往往可以透過socket+自定義資料報文來實現。但是這種方式比較繁瑣，需要針對每個通訊場景定義自己的資料格式和報文標準，甚至互動的行為、異常和錯誤的處理等等。有沒有一種通用的技術手段呢？答案就是RPC技術。

RPC是一種通用性的系統通訊手段，使得我們可以像呼叫本地方法一樣呼叫遠端系統提供的方法。

一個場景的RPC機制如圖1-7：

RPC機制

圖1-7

RPC的呼叫關係裡，我們把提供具體的呼叫方法的系統叫服務提供者（Provider），呼叫服務的系統稱為服務消費者（Consumer）。把物件轉換為以便於網路傳輸的二進位制或文字資料的過程，叫做序列化（Serialization）；二進位制或文字資料再還原為物件的過程，叫做反序列化（Deserialization）。

我們可以看到，典型的RPC處理機制包括兩部分：

通訊協議，可以是基於tcp的，也可以是基於http的。

資料格式，一般是一套序列化+反序列化機制。

常見的RPC技術有Cobra、RMI、。NET Remoting、WebService、JSON-RPC、XML-RPC、Hessian、Thrift、Protocol Buffer、gRPC等等。按照序列化機制的特點，我們可以把RPC技術分為文字的（WebService、JSON-RPC、XML-RPC等）和二進位制的（RMI、Hessian、Thrift、Protocol Buffer等）。按照常見的通訊協議來看，我們又可以分為基於HTTP的（WebService、Hessian等）和基於TCP的（RMI、。NET Remoting等）。按照是否可以用於多個不同平臺，又可以分為平臺特定的（RMI是Java平臺特定的、。NET Remoting是。NET平臺特定的）和平臺無關的（比如WebService、JSON-RPC、Hessian等可以用於

http：//

Java。Net

\PHP\Python等就是平臺無關的）。

在Java裡，我們一般可以基於JDK自帶的動態代理機制+Java的物件序列化方式實現一個簡單的RPC，但是由於動態代理和Java物件序列化都比較低效，導致這種方式效能較低。目前更常見的是基於AOP和程式碼生成技術實現stub和skeleton，然後用一個緊湊的二進位制序列化方式，實現一個高效的RPC框架。

按照呼叫方式來看，RPC有四種模式：

RR（Request-Response）模式，又叫請求響應模式，指每個呼叫都要有具體的返回結果資訊。

Oneway模式，又叫單向呼叫模式，呼叫即返回，沒有響應的資訊。

Future模式，又叫非同步模式，返回拿到一個Future物件，然後執行完獲取到返回結果資訊。

Callback模式，又叫回調模式，處理完請求以後，將處理結果資訊作為引數傳遞給回撥函式進行處理。

這四種呼叫模式中，前兩種最常見，後兩種一般是RR和Oneway方式的包裝，所以從本質上看，RPC一般對於客戶端的來說是一種同步的遠端服務呼叫技術。與其相對應的，一般來說MQ恰恰是一種非同步的呼叫技術。

2） MQ（Message Queue，訊息佇列）

非同步的遠端呼叫，如果能同時存在很多個請求，該如何處理呢？進一步地，由於不能立即拿到處理結果，假若需要考慮失敗策略，重試次數等，應該怎麼設計呢？

如果有N個不同系統相互之間都有RPC呼叫，這時候整個系統環境就是一個很大的網狀結構，依賴關係有N*（N-1）/2個。任何一個系統出問題，都會影響剩下N-1個系統，怎麼降低這種耦合呢？如圖1-8所示：

系統依賴關係

圖1-8

基於這些問題，我們發展出來了訊息佇列（MQ）技術，所有的處理請求先作為一個訊息傳送到MQ（一般我們叫做broker），接著處理訊息的系統從MQ拿到訊息並進行處理。這樣就實現了各個系統間的解耦，同時可以把失敗策略、重試等作為一個機制，對各個應用透明，直接在MQ與各呼叫方的應用介面層面實現即可，如圖1-9所示：

基於MQ的系統依賴關係

圖1-9

一般來說，我們把傳送訊息的系統稱為訊息生產者（message producer），接受處理訊息的系統稱為訊息消費者（message consumer）。

根據訊息處理的特點，我們又可以總結兩種訊息模式：

點對點模式（Point to Point，PTP），一個生產者傳送的每一個訊息，都只能有一個消費者能消費，看起來訊息就像從一個點傳遞到了另外一個點。

釋出訂閱模式（Publish-Subscribe，PubSub），一個生產者傳送的每一個訊息，都會發送到所有訂閱了此佇列的消費者，這樣對這個訊息感興趣的系統都可以拿到這個訊息。

透過這兩種訊息模式的靈活應用以及功能擴充套件，我們可以實現各種具體的訊息應用場景，比如高併發下的訂單非同步處理，海量日誌資料的分析處理等等。如果要總結一下訊息佇列在各類架構設計中能起到的作用，一般有如下幾點：

為系統增加了通用性的非同步業務處理能力，這個前面討論過了。

降低系統間的耦合性，無論是開發期的引用關係依賴，還是執行期的呼叫關係依賴，都明顯簡化或降低了。通訊的雙方只需要定義好訊息的資料格式（訊息頭有什麼欄位，訊息體是什麼格式的資料），就可以各自開發和測試，最後再各自上線即可整合到一起。

提升了系統間通訊可靠性，無論是從通訊本身的可靠性上（請求響應機制、重試），還是業務意義上（處理順序、事務、失敗策略），都相比RPC等方式有所增強。

提升了系統的業務緩衝能力，一般又叫削峰填谷，指的是經過MQ做為中間的緩衝，如果業務量突然增大時可以先把處理請求緩衝到佇列中，再根據業務消費處理能力逐個訊息處理，保障了系統不會因為突然爆發的大量請求而過載癱瘓，影響系統的連續服務能力。

增強了系統的擴充套件能力，透過訊息佇列處理的業務，消費端的處理能力如果不夠，一般可以隨時多加幾個消費者來處理，從而可以直接擴充套件系統的業務處理能力，而不需要額外的代價。

1.6.3 分散式架構：微服務架構（MSA）

隨著目前網際網路的飛速發展，我們發現大型專案的設計開發和維護過程中，存在如下幾個重點的困難點：

擴容困難

我們之前開發專案用的是虛擬機器，每次上線專案需要加機器總會遇到資源不足的情況，還要走非常複雜工單審批流程，還要與運維人員不斷PK，才能申請下來資源，整個流程冗長，機器資源申請困難。

部署困難

每次上線採用專門的人進行佈署，上線之前需要與上線人員溝通上線的環境，防止上線出錯。

釋出回滾困難

每次上線發現問題後，需要重新從SVN/GIT主幹上面進行程式碼編譯，但是有時候會因為各種問題回滾失敗，而且重新編譯很耗時導致回滾緩慢。

適配新技術困難

如果打算在不同的模組採用不同的語言開發，或者想在架構中做技術升級都很困難或者不支援。

快速開發困難

複雜專案中採用單體應用或者簡單的分拆成2-3個系統，裡面集成了太多功能模組，無法快速進行功能開發並且很容易牽一髮動全身。

測試困難

測試人員沒有自動化測試框架，或者Mock系統，導致只能採用簡單的人工測試流程，而且還經常發生功能覆蓋不全面等問題。

學習困難

業務變化日新月薪，功能和專案結構都太複雜，整個專案中的邏輯關係相互關聯影響，採用的技術五花八門，技術本身的更新換代也很快，導致技術人員學習曲線非常陡峭。

我們把遇到以上這些問題的專案也叫做單體專案。

1.6.3.1 什麼是微服務

The microservice architectural style is an approach to developing a single application as a suite of small services， each running in its own process and communicating with lightweight mechanisms， often an HTTP resource API。 These services are built around business capabilities and independently deployable by fully automated deployment machinery。 There is a bare minimum of centralized management of these services ， which may be written in different programming languages and use different data storage technologies。

引用自

http：//

martinfowler。com/articl

es/microservices。html

透過Martin Flowler的這段微服務描述，可以抽象出以下幾個關鍵點：

由一些獨立的服務共同組成應用系統

每個服務單獨佈署、獨立跑在自己的程序中

每個服務都是獨立的業務

分散式管理

通過幾個關鍵點可以看出微服務重在獨立佈署和獨立業務，而所謂的微服務，並不是越小越好，而是透過團隊規模和業務複雜度由粗到細的劃分過程，所遵循的原則是松耦合和高內聚，如圖1-10所示：

微服務架構

圖1-10

松耦合

修改一個服務不需要同時修改另一個，每個微服務都可以單獨修改和佈署

高內聚

把相關的事務放在一起，把不相關的排除出去，聚集在一起的事務只能幹同一件事

1.6.3.2 微服務和SOA的區別

1、微服務只是一種為經過良好架構設計的SOA解決方案，是面向服務的交付方案。

2、微服務更趨向於以自治的方式產生價值。

3、微服務與敏捷開發的思想高度結合在一起，服務的定義更加清晰，同時減少了企業ESB開發的複雜性。

4、微服務是SOA思想的一種提煉！

5、SOA是重ESB，微服務是輕閘道器。

1.6.3.3 大規模使用微服務

使用微服務也就面臨著由單體專案向微服務專案過渡，而採用了微服務架構後也就意味著服務之間的呼叫鏈路會比以前延長了很多，在呼叫鏈路上發生故障的機率也就隨之增大，同時呼叫鏈路越長，效能越會受影響。微服務架構中是存在很多陷阱的，並不是簡單的拿來使用就可以，所以企業要大規模使用微服務不僅僅是從思想和業務上面進行合理劃分，還需要諸多技術元件以及高效的運維來協同合作，如圖1-11所示。