1.6 架構的不同風格

典型的企業(yè)級應用系統或互聯網應用系統一般通過Web提供一組業(yè)務服務能力。這類系統包括提供給用戶操作的、運行于瀏覽器中具有UI的業(yè)務邏輯展示和輸入部分，運行于服務器端、用后端編程語言構建的業(yè)務邏輯處理部分，以及用于存儲業(yè)務數據的關系數據庫或其他類型的存儲軟件。

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

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

（2）整個系統的功能單元分散到不同的進程，然后由多個進程共同提供不同的業(yè)務能力，我們稱之為“分布式架構”（Distributed Architecture）。

任何一個體系（產品、平臺、商業(yè)模式等）想要發(fā)展壯大，途徑只有兩個模式。

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

（2）生態(tài)模式：以自己的核心能力為內核，持續(xù)地在外部吸引合作者，形成一個可以不斷成長的生態(tài)體系。分布式架構越來越像這種模式。

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

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

● 簡單單體模式——代碼層面沒有拆分，所有的業(yè)務邏輯都在一個項目（project）里打包成一個編譯后的二進制文件，通過這個文件進行部署，并提供業(yè)務能力；

● MVC模式——系統內每個模塊的功能組件按照不同的職責劃分為模型（Model）、視圖（View）、控制器（Controller）等角色，并以此來組織研發(fā)實現工作；

● 前后端分離模式——將前后端代碼耦合的設計改為前端邏輯和后端邏輯獨立編寫實現的處理模式；

● 組件模式——系統的每一個模塊拆分為一個子項目（subproject），每個模塊獨立編譯打包成一個組件，所有需要的組件一起再部署到同一個容器里；

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

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

● 面向服務架構（Service Oriented Architecture, SOA）——以業(yè)務服務的角度和服務總線的方式（一般是WebService與ESB）考慮系統架構和企業(yè)IT治理；

● 分布式服務架構（Distributed Service Architecture, DSA）——基于去中心化的分布式服務框架與技術，考慮系統架構和服務治理；

● 微服務架構（MicroServices Architecture, MSA）——微服務架構可以看作面向服務架構和分布式服務架構的拓展，使用更細粒度的服務（所以叫微服務）和一組設計準則來考慮大規(guī)模的復雜系統架構設計。

此外，傳統的企業(yè)集成領域的EAI架構模式，各個系統還是獨立部署的，但是各個系統之間的部分業(yè)務使用特定的技術打通了，因此我們可以看作單體和分布式之間的過渡狀態(tài)。

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

1．單體架構：簡單單體模式

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

但是這種簡單粗暴的方式對于一個系統的長期穩(wěn)定發(fā)展確實有很多壞處。如同一個新出生的小狗野蠻生長，如果缺乏正確的教導和規(guī)則的約束，最后成為一條忠實的導盲犬還是一條攜帶病毒的狂犬，就不得而知了。

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

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

第三，簡單單體模式的系統影響開發(fā)效率。如果一個使用Java的簡單單體項目代碼超過100萬行，那么在一臺筆記本電腦上修改代碼后執(zhí)行自動編譯，可能需要等待數十分鐘以上，并且內存可能不夠編譯過程使用，這是非常難以忍受的。

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

第五，擴展性受限，同樣是所有單體架構都有的一個問題。如果任何一個業(yè)務功能點存在性能問題，那么都需要多部署幾個完整的實例，再加上負載均衡設備，才能保證整個系統的性能能夠支撐用戶的使用。

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

2．分布式架構：面向服務架構（SOA）

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

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

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

1）服務與SOA

面向服務架構（SOA）是一種建設企業(yè)IT生態(tài)系統的架構指導思想。SOA的關注點是服務。服務是最基本的業(yè)務功能單元，由平臺中立性的接口契約來定義。通過將業(yè)務系統服務化，可以將不同模塊解耦，各種異構系統間可以輕松實現服務調用、消息交換和資源共享。

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

（2）從研發(fā)的視角來看，系統的復用可以從以前代碼級的粒度，擴展到業(yè)務服務的粒度；能夠快速應對業(yè)務需求和集成需求的變更。

（3）從管理的角度來看，SOA從更高的層次對整個企業(yè)IT生態(tài)進行統一的設計與管理，對消息處理與服務調用進行監(jiān)控，優(yōu)化資源配置，降低系統復雜度和綜合成本，為業(yè)務流程梳理和優(yōu)化提供技術支撐。

在SOA體系下，應用軟件被劃分為具有不同功能的服務單元，并通過標準的軟件接口把這些服務聯系起來，以SOA架構實現的企業(yè)應用可以更靈活快速地響應企業(yè)業(yè)務變化，實現新舊軟件資產的整合和復用，降低軟件整體成本。

2）SOA戰(zhàn)略

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

3）SOA落地方式

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

（1）分布式服務化。

互聯網類型的企業(yè)，業(yè)務與技術發(fā)展快，數據基數與增量都大，并發(fā)訪問量高，系統間依賴關系復雜、調用頻繁，分布式服務化與服務治理迫在眉睫。通過統一的服務化技術手段，進一步實現服務的注冊與尋址、服務調用關系查找、服務調用與消息處理監(jiān)控、服務質量與服務降級等?，F有的一些分布式服務化技術有Dubbo（基于Java）、Finagle（基于Scala）和ICE（跨平臺）等。

（2）集中式管理化。

傳統企業(yè)的IT內部遺留系統包袱較重，資源整合很大一部分工作是需要打通新舊技術體系的“任督二脈”，所以更偏重于以ESB作為基礎支撐技術，以整合集成為核心，將各個新舊系統的業(yè)務能力逐漸在ESB容器上聚合和集成起來。比較流行的商業(yè)ESB有IBM的WMB和Oracle的OSB，開源ESB有Mule、ServiceMix、JBossESB、wso2esb和OpenESB。

商業(yè)的ESB，一般來說除了功能豐富，配套設置都比較齊全，對于比較簡單的場景來說可以做到開箱即用，維護性也比較強，但同時過于復雜、難用，內部的設計實現基本是黑盒，并且購買費用比較高。

開源的ESB，由于開發(fā)成本和通用性、開放性的考慮，往往在ESB Server上做得比較強大、擴展性比較好，但是配套設置做得較差（這也是絕大多數開源項目共有的問題，不僅是開源ESB的問題）。對企業(yè)來說可管理性非常重要，選擇開源ESB需要結合企業(yè)的實際情況，一步步地積累，下大功夫來做好。

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

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

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

EIP的介紹可以看這里：http://www.enterpriseintegrationpatterns.com/。

4）SOA的兩大基石：RPC與MQ

SOA關注于系統的服務化，不同系統服務間的相互通信就成為一個重要的話題。隨著RPC和MQ技術的發(fā)展，這兩種技術逐漸成為SOA的兩大基石，也是分布式技術體系里的重要基礎設施。

（1）RPC（Remote Procedure Call，遠程過程調用）。

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

RPC是一種通用性的系統通信手段，使得我們可以像調用本地方法一樣調用遠程系統提供的方法。一個場景的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等可以用于Java.Net/PHP/Python等就是平臺無關的）。

在Java里，我們一般可以基于JDK自帶的動態(tài)代理機制+Java的對象序列化方式實現一個簡單的RPC，由于動態(tài)代理和Java對象序列化都比較低效，導致這種方式性能較低。目前更常見的是基于AOP和代碼生成技術實現代理存根（stub）和服務存根（skeleton），然后用一個緊湊的二進制序列化方式實現一個高效的RPC框架。

按照調用方式來看，RPC有四種模式：

● RR（Request-Response）模式，又叫請求響應模式，指每個調用都要有具體的返回結果信息。

● Oneway模式，又叫單向調用模式，調用即返回，沒有響應的信息。

● Future模式，又叫異步模式，調用后返回一個Future對象，然后執(zhí)行完獲取返回結果信息。

● Callback模式，又叫回調模式，處理完請求以后，將處理結果信息作為參數傳遞給回調函數進行處理。

這四種調用模式中，前兩種最常見，后兩種一般是RR和Oneway方式的包裝，所以從本質上看，RPC一般對于客戶端來說是一種同步的遠程服務調用技術。與其相對應的，一般來說MQ恰恰是一種異步的通信技術。

（2）MQ（Message Queue，消息隊列）。

現在我們來考慮異步的遠程調用，如果同時存在很多個請求，那么該如何處理呢？進一步地，由于不能立即獲取處理結果，假若需要考慮失敗策略、重試次數等，那么應該怎么設計呢？

如果N個不同系統相互之間都有RPC調用，這時整個系統環(huán)境就是一個很大的網狀結構，依賴關系有N×（N-1）/2個，如圖1-8所示。任何一個系統出問題，都會影響剩下N-1個系統，怎么降低這種耦合呢？

基于這些問題，我們發(fā)展出MQ（消息隊列）技術，所有的處理請求先作為一個消息發(fā)送到MQ（也叫作Message Broker），接著處理消息的系統從MQ獲取消息并進行處理。這樣就實現了各個系統間的解耦，同時可以把失敗策略、重試等作為一個機制，對各個應用透明，直接在MQ與各個調用方的應用接口層面實現即可，如圖1-9所示。

一般來說，我們把發(fā)送消息的系統稱為消息生產者（Message Producer），接收處理消息的系統稱為消息消費者（Message Consumer）。

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

● 點對點模式（Point to Point, PTP），一個生產者發(fā)送的每一個消息都只能由一個消費者能消費，看起來消息就像從一個點傳遞到了另外一個點。

● 發(fā)布訂閱模式（Publish-Subscribe, PubSub），一個生產者發(fā)送的每一個消息都會發(fā)送到所有訂閱了此隊列的消費者，這樣對這個消息感興趣的系統都可以獲取這個消息。

通過這兩種消息模式的靈活應用及功能擴展，我們可以實現各種具體的消息應用場景，比如高并發(fā)下的訂單異步處理，海量日志數據的分析處理等。如果要總結消息隊列在各類架構設計中能起到的作用，一般有如下幾點：

● 為系統增加了通用性的異步業(yè)務處理能力，這個在前面討論過了。

● 降低系統間的耦合性，無論開發(fā)期的引用關系依賴，還是運行期的調用關系依賴，都明顯簡化或降低了。通信的雙方只需要定義好消息的數據格式（消息頭有什么字段，消息體是什么格式的數據），就可以各自進行開發(fā)和測試，最后再各自上線即可集成到一起。

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

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

● 增強了系統的擴展能力，通過消息隊列處理業(yè)務，消費端的處理能力如果不夠，一般可以隨時多加幾個消費者來處理，從而可以直接擴展系統的業(yè)務處理能力，而不需要額外的代價。

3．分布式架構：微服務架構（MSA）

隨著互聯網技術的飛速發(fā)展，我們發(fā)現大型項目的設計開發(fā)和維護過程中，存在如下幾個重要的困難點。

● 擴容困難

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

● 部署困難

每次上線采用專人進行部署，上線之前需要與上線人員溝通上線的環(huán)境，防止上線出錯。

● 發(fā)布回滾困難

每次上線發(fā)現問題后，需要重新在SVN/GIT主干上面進行代碼編譯，但有時候會因為各種問題回滾失敗，而且重新編譯很耗時，導致回滾緩慢。

● 適配新技術困難

不同的模塊采用不同的語言開發(fā)，在架構中做技術升級都很困難，或者不支持技術升級。

● 快速開發(fā)困難

復雜項目中采用單體應用或簡單地分拆成2～3個系統，里面集成了太多功能模塊，無法快速進行功能開發(fā)，并且很容易牽一發(fā)動全身。

● 測試困難

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

● 學習困難

業(yè)務變化快，功能和項目結構都太復雜，整個項目中的邏輯關系相互關聯影響，采用的技術五花八門，技術本身的更新換代也很快，導致技術人員的學習曲線非常陡峭。

針對如何解決這些問題，“微服務架構”應運而生。

1）什么是微服務

微服務這個概念最早是在2011年5月威尼斯的一個軟件架構會議上討論并提出的，用于描述一些作為通用架構風格的設計原則。2012年3月在波蘭克拉科夫舉行的33rd Degree Conference大會上，ThoughtWorks首席咨詢師James Lewis做了題為“Microservices - Java, the Unix Way”的演講。這次演講里，James討論了微服務的一些原則和特征，例如單一服務職責、康威定律、自動擴展、DDD等等。

微服務架構則是由Fred George在2012年的一次技術大會上所提出的，在大會的演講中，他講解了如何分拆服務，以及如何利用MQ來進行服務間的解耦，這就是最早的微服務架構的雛形。而后由Martin Fowler發(fā)揚光大，并且在2014年發(fā)表了一篇著名的微服務文章，這篇文章深入全面地講解了什么是微服務架構。隨后，微服務架構逐漸成為一種非常流行的架構模式，一大批的技術框架和文章涌現出來，越來越多的公司借鑒和使用微服務架構的相關技術。

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/articles/microservices.html。通過Martin Flowler的這段微服務描述，可以抽象出以下幾個關鍵點：

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

● 每個服務單獨部署、獨立運行在自己的進程中；

● 每個服務都是獨立的業(yè)務；

● 分布式管理。

通過幾個關鍵點可以看出微服務重在獨立部署和獨立業(yè)務，所謂的微服務，并不是越小越好，而是通過團隊規(guī)模和業(yè)務復雜度由粗到細的劃分過程，所遵循的原則是低耦合和高內聚，如圖1-10所示。

● 低耦合

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

● 高內聚

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

2）微服務和SOA的區(qū)別

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

（2）微服務更趨向于以自治的方式產生價值。

（3）微服務與敏捷開發(fā)的思想高度結合在一起，服務的定義更加清晰，同時減少了企業(yè)ESB開發(fā)的復雜性。

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

（5）SOA是重ESB，微服務是輕網關。

3）大規(guī)模使用微服務

使用微服務也面臨由單體項目向微服務項目過渡的問題，而采用微服務架構后意味著服務之間的調用鏈路會比以前延長了很多，在調用鏈路上發(fā)生故障的概率也就隨之增大，同時調用鏈路越長，性能越會受影響。微服務架構中是存在很多陷阱的，并不是簡單地拿來使用就可以，所以企業(yè)要大規(guī)模使用微服務不僅僅是從思想和業(yè)務上面進行合理劃分，還需要諸多技術組件，以及高效的運維來協同合作，如圖1-11所示。

● 防止雪崩

當一個服務無法承受大請求壓力的時候，是否會影響所依賴的其他服務？這時候可以考慮限流等措施。

● 功能降級

當某個服務出現故障時，是否有容錯手段能夠讓業(yè)務繼續(xù)運行下去，而不影響整體應用。

● 冪等

當用戶多次下同一訂單時，得到的結果永遠是同一個。

● 緩存

當請求量較大時，為避免對數據庫造成較大壓力，可以適當將一些變化較小、讀取量較大的數據放入緩存。

● 超時

超時時間對于調用服務來說非常重要，超時時間設置太長可能會把整體系統拖慢，而設置短了又會造成調用服務未完成而返回，我們在實際工作中需要根據業(yè)務場景進行分析，選擇一個恰當的超時設定值。

● 熔斷

當請求下游的服務時發(fā)生一定數量的失敗后，熔斷器（斷路器）打開，接下來的請求快速返回失敗。過一段時間后再來查看下游服務是否已恢復正常，重置熔斷器。

● 服務隔離

當所調用的服務發(fā)生故障時，上游服務能夠隔離故障以確保業(yè)務能夠繼續(xù)運行下去

● 可伸縮

當并發(fā)量較大，原有服務集群無法滿足現有業(yè)務場景時，可以采用擴容策略；當并發(fā)量較小時，服務集群可以采用縮容策略，以節(jié)省資源。

● 數據庫拆分

通過為每個獨立部署的服務提供單獨的數據庫，降低了數據庫耦合，也讓不同微服務間隔離得更徹底，系統更健壯，同時也利于針對不同數據分別進行擴容和其他處理。

● 可擴展

系統經過良好的設計，可以隨時靈活地以比較小的改動代價增加新的功能或能力。