響應式微服務架構-分佈式系統設計原則

O’Reilly的電子書《Reactive Microservices Architecture》講述了微服務/分佈式系統的一些設計原則，本文是筆者閱讀完此書後的理解。

微服務相比傳統的單體應用可以帶來快速的響應，以小的系統產生大的影響。而隨着網絡加速、磁盤成本下降、RAM成本下降、多核技術的發展、雲架構技術的爆發，微服務再也不受這些客觀條件的限制，已經開始大規模的應用。

與SOA架構，微服務和它都具備相同的初衷：解耦、隔離、組合、集成、分散以及自主，可是SOA常常被誤解和誤用，尤爲是使用ESB來支持對多個單體系統的協議（複雜、低效、不穩定）調用，使得系統變得很是複雜。而隨着這些年硬件以及軟件架構理念的發展，全部的系統基本都已經變成分佈式架構，也帶來了不少新的挑戰。也就須要新的思路和理念來面對這些問題，其中本書所講述的響應式原則（Reactive principles）即一種解決分佈式系統的思路。響應式原則也並不是一個新的東西，Erlang中的Actor模型即一種響應式設計。微服務是響應式原則的一個架構設計，其借鑑了SOA架構中好的理念，並使用了現代的基礎服務設施（雲服務、自動化工具等）。

響應式微服務定義

使用微服務架構最關鍵的一個原則就是將系統劃分紅一個個相互隔離、無依賴的子系統，這些子系統經過定義良好的協議進行通訊。其中隔離是實現彈性、可伸縮系統的前提，而且須要在服務間創建異步通訊邊界，所以要在如下兩方面進行解耦：

• 時間：容許併發。
• 空間：容許分佈式和移動性，即服務可以隨時移動。

此外，微服務還須要消除共享狀態從而最小化相互協做、聯結的成本，要儘可能達到「不共享任何東西」。

隔離任何東西

隔離是微服務架構中最重要的特性。不只僅是微服務帶來的不少優點的基礎，也是對設計和架構影響最大的方面。如康威定律所說，它還對組織架構有很是大的影響，

1 複製代碼

系統的結構是對團隊組織架構的反映。複製代碼

失敗隔離是一種與「艙壁」（船艙的隔板）相關的設計模式：隔離錯誤、失敗以防止其蔓延至全部服務，致使更大面積的失敗。

「艙壁」這種模式已經在輪船上使用了幾個世紀：建立一個個密封不漏水的空間以防止船的外殼破損或者其餘泄漏。這些空間是徹底互相隔離的，這樣即便一個隔離區充滿了水，也不會蔓延流到其餘隔離空間中，從而使得船總體仍然可以運做。

彈性（從失敗中恢復的能力）即依賴於這種艙壁和失敗隔離的設計，而且須要打破同步通訊機制。由此，微服務通常是在邊界之間使用異步消息傳輸，從而使得正常的業務邏輯避免對捕獲錯誤、錯誤處理的依賴。

進一步的，服務之間的隔離使得「持續交付」變得很容易，可以隨時地部署服務而無需擔憂影響正常的業務。並且隔離的單個服務很容易監控、調試、測試和部署，很是便於擴展。

自主地行動

上面所講的隔離是自主性的前提。只有當服務之間是徹底隔離的，那麼纔可能實現徹底的自主，包括獨立的決策、獨立的行動以及與其餘服務協調合做來解決問題。

一個自主的服務僅僅保證其對外公佈的協議/API的正確性便可。如此，不只可以讓咱們更好地瞭解協做的這些系統以及對他們的建模，也可以在面對衝突、失敗情況時，只在一個服務內進行排查、修復便可。

使用自主服務可以給服務編排、工做流管理以及服務合做上帶來很大靈活性，同時也帶來可擴展性、可用性、運行時管理等優點。但其付出的代價就是須要花心思在定義良好的可組合的API設計上，這個是有必定挑戰性的。

只作一件事，而且作好

如Unix編程哲學所說：程序應該只作一件事，而且作好它。而後讓他們一塊兒工做完成任務。這也相似於面向對象編程語言中軟件開發單一職責原則（SRP）的描述。

而在微服務中一個很大的問題就是如何正確地肯定服務的大小。好比怎樣的粒度才能被認爲是「微」（micro）？多少行代碼還能被認爲是微服務。但這裏「micro」實際上是和職責範圍有關的，就如Unix的SRP原則：只作一件事而且作好。

每個服務都應該只有一個存在的緣由，提供了一組相關的功能，業務和職責不會糅雜在一塊兒。全部服務組織在一塊兒總體上可以便於擴展、具備彈性、易理解和維護。

擁有本身的私有狀態

微服務中有一個很關鍵的部分就是狀態（state），不少微服務也都是有狀態的實體，包括對狀態和行爲的封裝。而在「無狀態」的設計理念下，不少服務都把本身的狀態下沉到一個大的共享數據庫中，這也是不少傳統的Web框架的作法。如此就形成了在擴展性、可用性以及數據集成上很難作好把控。而本質上，一個有着共享數據庫的微服務架構本質仍是一個單體應用。

合理的方式是一個服務既然具備單一職責，那麼就應該擁有本身的狀態和持久化機制，建模成一個邊界上下文，有本身的域名和語言。這些也都是DDD（Domain-Drivern Design）裏面的技術。微服務受DDD影響很大，其中不少微服務的上下文的概念都來自於DDD。

當訪問一個服務時，也只能是客氣的請求其狀態而並不能強制其必定具備狀態。如此，每一個服務都可以經過事件溯源(Event Sourcing)和CQRS（Command Query Responsibility Segreation）自定義本身的狀態表示和實現（RDBMS、NoSQL、Time-Series、EventLog）。

去中心化的數據管理和持久化（多語言持久化）可以帶來不少優點。數據的存儲媒介能夠根據服務本身的須要選擇，服務包括其數據均可以看作一個單獨的單元。同時並不容許一個服務直接去訪問另外一個服務的數據庫，若是要訪問只能經過API（經過指定規範、策略和Code Review來保證）。

Event Log是一種消息的存儲方式。咱們能夠以消息進入服務的形式存儲（發送到服務的Commnds），即命令溯源(Command Sourcing)。咱們也能夠忽略命令，讓命令先執行對服務產生一些做用，若是觸發了狀態變動，那麼咱們捕獲這次變更並用事件溯源（Event Sourcing）將這次Event存儲到EventLog中。

消息有序存儲，可以提供服務全部的交互歷史。同時消息也保存了服務的事務，也就可以對這些事務日誌進行查詢、審計、重放從而用於彈性伸縮、調試以及冗餘等。

命令溯源和事件溯源是不一樣的語義。重放命令意味着會重放其帶來的反作用。而重放事件則是執行狀態的改變。須要根據具體場景的不一樣選擇使用哪一種溯源技術。

使用EventLog能夠避免」對象關係不匹配」的問題（ORM中常常出現）。而因爲其自身自然適合異步消息傳輸，所以絕大多數狀況下，Event Log是微服務中最佳的持久化模型。

擁抱異步消息傳輸

微服務之間的通訊的最佳機制就是消息傳輸。如上文所說，服務之間的異步邊界可以在時間和空間兩方面進行解耦，可以提高總體系統的性能。

異步非阻塞執行以及IO都是對資源的高效操做，可以最小化訪問共享資源時的阻塞消耗（擴展性、低延遲以及高吞吐的最大障礙）。簡單的例子：若是要發起對10個服務的訪問，其中每個請求須要耗時100ms，那麼若是使用同步模式，則完成全部請求則須要10*100=1000ms。而若是使用異步模式，同時發起10個線程，則一共就須要100ms。

異步消息傳輸還可以讓咱們注重網絡編程的限制，而不是僞裝這些限制不存在，尤爲是在失敗場景下。還可以讓咱們更關注工做流以及服務間的數據流、協議、交互是怎樣進行的。

然而目前微服務的默認通訊協議以REST爲主，其本質是同步通訊機制，比較適用於可控的服務調用或者緊耦合的服務調用上。

此外，使用異步消息傳輸的另外一個需求在於對消息的持續流處理（多是無界的）。也是咱們從「data at rest」到」data in motion」的理念的改變。以前的數據是離線被使用的，而如今的數據是被在線處理的。應用對數據變動的響應須要達到實時級別：當變更發生，須要實時進行持續的查詢、聚合並反饋給最終的應用。這個理念的造成經歷了三個主要階段：

1. 「data at rest」: 將大量數據存儲在HDFS相似的數據存儲媒介中，而後使用離線批處理技術去處理這些數據，通常會有數個小時的延遲。

2. 意識到了「data in motion」正變得愈來愈重要：在數秒內捕獲數據、處理數據並反饋給運行中的系統。Lambda即此時出現的一種架構: 加速層用來作實時在線計算；批處理層用來作複雜的離線處理。加速層實時處理的結果後續被批處理層的結果合併。這個模型解決了某些場景須要數據即時響應的問題，但其架構的複雜使得不容易維護。

3. 「data in motion」: 全面擁抱移動數據的概念。傳統的面向批處理的架構都在逐漸向純流處理的架構轉變。這種模型做爲通訊協議和持久化方案（經過Event Logging）也可以給微服務帶來「data in motion」和流處理的能力。

保持移動，但可尋址

如上述所講，異步消息傳輸帶來了對時間和空間的解耦。其中，對於空間的解耦也被稱爲「位置透明」：在多核或者多結點上的微服務在運行時無須改變結點便可以動態擴展的能力。這也決定了系統的彈性和移動性。要實現這些須要依賴雲計算帶來的一些特性和其「按需使用」模型。

而可尋址則是說服務的地址須要是穩定的，從而能夠無限地引用此服務，而不管服務目前是否能夠被定位到。當服務在運行中、已經中止、被掛起、升級中、已經崩潰等等情形下，地址都應該是可用的，任意客戶端可以隨時發送消息給一個地址。實際中，這些消息有可能進入隊列排隊、重提交、代理、日誌記錄或者進入死信隊列。此外，地址須要是虛擬的，能夠表明一組實例提供的服務。

• 在無狀態的服務間作負載均衡：若是服務是無狀態的，那麼請求被哪個服務實例處理都是沒任何問題的。也有不少種的路由算法供使用，如：輪訓、廣播或者基於度量信息。
• 在有狀態的服務之間構建Active-Passive的冗餘設計：若是一個服務是有狀態的，那麼可使用sticky路由算法（同一個客戶端的請求都會發送給同一個服務實例）。冗餘一個passive實例是爲了在主實例掛的時候接管上面的請求。所以，服務的每個狀態變更都須要同步到passive實例上。
• 有狀態的服務的重定位：將一個服務實例從一個位置移動到另外一個位置能夠提升引用的本地性（讓數據和計算靠近）和資源利用率。

使用虛擬地址可以讓服務消費方無須關心服務目前是如何配置操做的，只要知道地址便可。

微服務系統實現

一個微服務並不是真正的「微服務」，一系列微服務經過通訊、合做纔可以解決問題，才能組成一個完整的業務系統。實現一個服務是相對簡單的，困難的是其餘基礎設施的實現：服務發現、協做、安全、冗餘、數據一致性、容錯、部署以及與其餘系統的集成。

系統須要利用現實

微服務架構帶來的一個很大優點就在於它提供了一套工具，可以利用現實，模仿真實的世界來建立系統，包括真實世界的限制和機會。

首先根據「康威定律」，微服務的部署是和現實中工程組織/部門如何工做是相適應的。此外，還須要注意的是現實不是一致的，任何事情都是相對的，即便是時間和「如今」這個概念。

信息的傳播速度不可能比光快，甚至大部分是很慢的，這也意味着信息通訊是有延遲的。信息都是來自過去的，咱們稍微思考一下能夠知道信息承載的都是咱們觀察到的東西。而咱們觀察/學習到的事實至少都是很短期以前發生的，也就是說咱們老是在看過去，「如今」只是旁觀者的視角。

每個微服務均可以看作一個安全的小島，提供了肯定性和強一致性，上面的時間和「目前」都是絕對的。可是當離開一個微服務的邊界時，就進入了一片充滿非肯定性的大海-分佈式系統的世界。如不少人所說，構建分佈式系統是困難的。但現實世界同時也提供瞭如何解決諸如彈性、可伸縮、隔離性等分佈式問題的解決思路。所以，即便構建分佈式系統是困難的，可是咱們也不該該退化爲單體應用，而是學習如何使用一系列的設計原則、抽象概念和工具來管理它。

正如Pat Helland在《Data on the Outside versus Data on the Inside.」》對」data on the inside」和「data on the outside」的對比所說：內部的數據就是咱們本地的「目前」，而外部數據-事件便是來自過去的信息，服務之間的命令則是「對將來的但願」。

服務發現

服務發現要解決的問題就是如何定位一系列的服務從而可使用地址去調用。其中最簡單的手段就是將地址和端口信息硬編碼在全部服務中或者外置在服務的配置文件中。這種方式的問題在於其是一種靜態部署模型，與微服務的初衷是相矛盾的。

服務須要保持解耦和移動，而系統須要是彈性和動態的。所以能夠經過使用控制反轉（Inversion of Control）模式引入一個間接層來解決此問題。也就是說每個服務都上報本身的信息（位置、如何訪問）給一個統一的平臺。這個平臺被稱做「服務發現」，是微服務平臺的一個基礎部分。這樣，一旦服務的信息被存儲了，服務就可使用「服務註冊中心」來查找調用服務的信息，這種模式被稱做「Client-Side服務發現」。另外一種策略是將信息存儲、維護在一個負載均衡器（AWS的ELB)或者直接維護在服務提供方的地址中-「Server-Side服務發現」。

能夠選擇CP特性的數據庫做爲服務信息的存儲，可以保證信息的一致性。可是這種數據庫是犧牲了必定程度的可用性來達到強一致性的，而且依賴一些額外的基礎設施，而不少時候強一致性並不是那麼須要。所以，更好的選擇是使用AP特性的點對點的技術來存儲，好比使用CRDTs（Conflict-Free Replicated Data Types ）與Epidemic Gossip能夠實現信息的最終一致性傳播，可以有更好的彈性，也不須要額外的基礎設施。

API管理

API管理解決的問題在於如何將服務的協議和API統一管理起來，以方便服務的調用。包括協議和數據版本的升級和後退等。解決此問題能夠經過引入一個負責序列化編碼、協議維護以及數據傳輸的層，甚至直接將服務版本化。這在DDD中被稱做」Anti-Corruption」層，能夠加入到服務自己或者在API網關中實現。

假如一個客戶端須要調用10個服務（每個都有不一樣的API）來完成一個任務，那麼對於這個客戶端來講是很是繁瑣的。相比起讓客戶端直接去調用服務，更好的方式是讓客戶端經過API網關服務來調用。API網關負責接受客戶端的請求，而後路由請求到相應的服務（若是有必要須要轉換協議），組裝響應並將其返回給客戶端。這樣，作爲客戶端和服務之間的一層其就可以簡化client-to-service協議。但這裏若是是中心化的則很難達到高可用和可擴展性，因此使用去中心化技術（好比服務發現）實現API網關則是更好的選擇。

但須要注意的是API網關，包括全部的核心出服務並非必定要自建的，理想地它應該是底層平臺的一部分。

管理通訊模式

在一個由數個微服務組成的系統中，使用點對點的通訊就能完成服務間的通訊工做。可是當服務數目愈來愈多，若是仍是讓他們之間直接調用，那麼很快整個系統會變得混亂不堪。解決此問題須要一個機制可以解耦發送者和接受者，而且可以按照某種定義好的原則路由數據。

發佈訂閱機制是一種解決方案：發佈者發佈信息到某個topic中，訂閱者監聽此topic以監聽消息。可使用可擴展消息系統（Apache Kafka、Amazon Kinesis）或者NoSQL數據庫（AP特性數據庫，如Cassendra和Riak）來實現。

在SOA架構中，ESB承擔的即這種角色。微服務中咱們確定不會使用它來橋接單體應用，可是能夠將它作爲一個發佈系統用來廣播任務和數據或者作爲系統間的通訊總線（經過Spark Streaming收集數據到Spark中）。

發佈訂閱協議有時候也是有不足的。好比沒法提供容許程序員自定義路由規則的高級路由特性或者數據的轉化、豐富、分隔以及合併等功能（可使用Akka Streams或者Apache Camel）。

微服務技術是程序員都離不開的話題，特別是對於有想法，有目標的程序員，因此順便在這裏給你們推薦一個交流學習羣：650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，如下的知識體系圖也是在羣裏獲取。相信對於已經工做和遇到技術瓶頸的碼友，在這個羣裏必定有你須要的內容。

集成

系統與外界或者系統之間的通訊都是必需的。當與一個外部系統通訊時，尤爲當外部系統沒法把控時，那麼就會有很大的失敗風險（系統超載、業務失敗）。所以即便協議協商得再好，也不能信賴外部服務，須要作好各類預防措施以保證自身服務的安全。

首先要達成一個良好的協議從而能夠最小化一個系統突發超載形成服務不可用的風險，好比要避免發起的請求超過服務提供方的承載能力。也要儘可能避免使用同步通訊機制，不然就把自身服務的可用性放在了依賴的第三方服務的控制中。

避免級聯失敗須要服務足夠解耦和隔離。使用異步通訊機制是一個最佳的方案。此外，還須要經過背壓（back-pressure，接收方根據本身的接受情況調節接受速率，經過反向的響應來控制發送方的發送速率）來達成數據流速度的一致性，以防止響應快速的系統壓垮其中較慢的部分。而愈來愈多的工具和庫都在開始擁抱「響應式流」（Reactive Streams）規範（Akka Stream、RxJava、Spark Streaming、Cassandra drivers），這些技術使用異步背壓實時流來橋接系統，從而在整體上提升系統的可靠性、性能以及互操做性。

如何管理調用服務時候的失敗也是微服務中一個關鍵的問題。捕獲到錯誤後，先重試，而若是錯誤一直髮生，那麼就隔離服務一段時間直到服務恢復-「斷路器」模式（Netflix和Akka中都有實現）。

面對可擴展性、高吞吐以及可用性的要求，系統集成的實現從傳統的依賴於中心化服務如RDBMS/ESB逐漸變爲如今採用去中心化策略（HTTP REST、ZeroMQ）或者訂閱發佈系統（Kakka、Amazon Kinesis）。而最近事件流平臺（Event Streaming Platforms）正成爲系統集成選型的趨勢，其理念來自於Fast Data和實時數據管理。

如上文所述，服務之間使用異步通訊機制可以獲得不少的好處。可是若是是客戶端（瀏覽器、APP）與服務之間的通訊，使用REST常常是更好的選擇。可是並不是全部的地方都非得使用同步通訊機制，須要根據不一樣的場景作不一樣的評估。不少狀況下，開發者出於習慣都會傾向於使用同步方案，而不是根據真正的須要做出可以簡化操做、提高操做性的選擇。這裏給出幾個一般會使用同步方案建模但其本質是異步行爲的事例：

• 查詢一個商品是否有貨，若是此商品比較熱門被賣光了，用戶要獲得通知。
• 若是一個餐館的特價菜單改動了，用戶要馬上知道。
• 用戶對於一個網站的評論須要實時對話。
• 廣告系統根據用戶在頁面上的行爲輸出不一樣的響應。

對於上述實例，咱們須要分別進行分析去理解怎樣纔是符合客戶端和服務通訊的最天然的方式。同時也常常須要根據數據的完整性約束來尋找能夠弱化一致性保證（有序）的可能，目的就是找到最少的協調約束條件給用戶以直觀的語義：找到利用現實的最佳策略。

安全管理

安全管理主要是對服務的認證受權管理，限制某些service只容許某些服務訪問。

• TLS Client Certificates也被稱爲相互驗證、雙路驗證。它給每個service都分配一個單獨的私鑰和證書，從而可以很好地保證服務間的認證訪問。不只僅服務要驗證客戶端的身份，客戶端也要驗證服務的身份。所以，其不只能防止數據被竊聽，並且即便在不安全的網絡中也能防止對數據的攔截和轉發。基於SSL之上的通訊不只安全，其也是一個公開、易於理解的標準。可是其很是複雜，沒法獲得底層平臺的足夠支持。一樣的，HTTPS Basic Authentication也是雙路驗證，但其對SSL證書的管理也很複雜，請求也不能被反向代理緩存。
• Asymmetric Request Signing：每個服務都須要使用本身的私鑰給本身發送的請求進行簽名，同時每個服務的公鑰都要上報給「服務發現」服務。此方案的缺點在於一旦網絡不可靠，那麼則很難防止數據竊聽或者請求重放攻擊。
• Hash Message Authentication Code (HMAC) ： 基於共享密鑰來對請求進行必定規則的簽名。這個方案比較簡單，可是因爲每一對須要通訊的服務都須要惟一的一個共享密鑰，整個系統則須要全部服務排列數目的共享密鑰數量，實現起來比較麻煩。

最小化數據耦合

微服務架構中，完成一個任務須要多個服務的協同，所以最小化服務之間的狀態協做成本，有助於提高微服務系統的總體性能。

須要作的是要從業務的視角去分析數據以理解數據間的關係、擔保和完整性約束。而後對數據進行反範式設計並在系統內定義一致性邊界。如此，能夠在邊界內部實現強一致性。接着，須要使用這些邊界來驅動微服務的設計和範圍。若是設計的服務之間有不少數據依賴和關係，那麼就須要去減小甚至是消除這些數據的耦合，從而避免對服務狀態的協同。

最小化協做成本

如上節所述，已經最小化數據耦合了，但仍然仍是會有業務場景須要多個服務協做完成。這個的確是沒法避免的，但到了目前這一步，須要作的是能夠根據須要逐漸的添加協做，而不是一開始各類耦合再逐漸去消除（比較麻煩和困難）。

這裏提供幾種可擴展、彈性伸縮的方式來協同數據改變，以達到Composability（對數據的變更無須中止數據所在的服務，也無須等待某些條件）。

• Apology-Oriented Programming: 基於請求原諒比請求權限容易的想法。若是你不能響應協做，那麼就作出一個合理的猜想，賭一個條件已經知足，後續若是錯了，那麼就道歉並作補償。這種作法和現實是很是類似的。好比航班的超售，若是起飛的時候沒有座位那麼就去作一些補償措施。
• 事件驅動架構（Event-Driven Architecture ）：基於異步消息傳輸和事件溯源。須要區分命令和事件，命令表示一個將要產生反作用的操做意圖（對將來的但願），而事件表示已經發生的事實。使用CQRS模式進行查詢，將寫入方（持久化事件日誌）與讀取方（將數據存入RDBMS或者NoSQL數據庫中）分離。這裏使用事件日誌作狀態管理和持久化具備不少好處：簡化審計、調試、冗餘、容錯，而且容許重放過去任意時間點的事件流。
• ACID2.0：由Pat Helland創造，定義了一組原則，目的是實現可擴展、彈性的協議以及API設計。A是Associative，表示分組消息不會產生影響，能夠批量處理。C是Commutative，表示消息的順序不重要。I是Idempotent，表示消息重複不會產生影響。D是Distributed，沒有實質的意義，猜想是爲了湊ACID這個首字母縮寫。

CRDTs是一個囊括了上面這些東西的工具，能夠實現最終一致性、據有豐富的數據結構（counters、sets、maps、graphs），而且不須要協做就能夠收斂聚合。其更新操做的順序先後也並不影響最終的合併結果，可以自動安全的進行合併。雖然CRDTs最近纔出如今業界視野中，但其實它已經在生產環境使用了不少年。已經有一些生產級別的庫能夠直接使用（Akka、Riak）。

然而，不少業務場景並不容許最終一致性。這時可使用因果一致性（causal consistency）。因果關係很容易被你們理解。並且因果一致性模型可以實現可擴展性和可用性。其通常使用邏輯時間，在不少NoSQL數據庫、事件日誌以及分佈式事件流產品中均可用。

分佈式事務是一個常用的方式用來協調分佈式系統的變更，但其本質須要約束併發執行，保證同一時間只有一個用戶在操做。所以其成本很是昂貴，會使得系統變慢、沒法擴展。Saga模式是分佈式事務以外的一個可以實現可擴展、彈性伸縮的選擇。它的理論基礎在於一個長時間運行的業務事務大多時候都是由多個事務步驟組成的，而事務步驟的整體一致性可以經過將這些步驟分組成一個整體的分佈式事務來實現。該技術將每個階段的事務與一個可補償回滾的事務配對，若是一個階段的事務失敗了，那麼整體的分佈式事務就能夠回滾（反向順序）。

總結

當設計一個響應式微服務時，須要堅持隔離、單一職責、自主、獨佔狀態、異步消息傳輸和移動等特質。微服務須要協做才能造成一個系統去發揮做用。一個可以提供基礎服務和響應式原則模式的複雜微服務平臺是有必要的。