點擊上方“朱小廝的博客”，選擇“設為星標”

當當滿200減40優惠碼「J2KNAE」

來源：知乎

今天準備談下微服務架構下各個微服務間如何解耦，以及對于已經緊耦合的微服務如何進行重構。要明白實際上微服務后續出現的諸多問題往往都是一開始微服務模塊劃分就不合理導致，對于具體的模塊劃分方法和原則，我總結出了以下幾點。

• 原則1：劃分為<10個微服務模塊

• 原則2：強數據關聯模塊不要拆分

• 原則3：以數據聚合驅動業務功能聚合

• 原則4：從縱向功能劃分思路到橫向分層思路轉變

• 原則5：高內聚、松耦合的基礎原則

對于具體的內容在這篇文章不再重復給出。可以看到對于微服務模塊拆分更多的是屬于業務建模和系統分析方面的內容，而今天談的微服務解耦重點是想從可用的技術手段入手來談下可用的以下解耦方法和策略。

問題綜述

最近幾年對于微服務架構，企業中臺構建，組件化和服務化，平臺+應用構建模式，包括Docker容器化，DevOps等都越來越受到傳統企業的關注，也可以看到很多企業傳統架構也在朝這個目標進行演進和轉型。對于微服務架構本身的優點和缺點，包括傳統企業實施微服務架構的演進路線等，在我前面很多微服務架構相關的文章中都有所介紹，今天主要談下在微服務架構下的解耦問題。

要明白，企業實施微服務架構后，原來所有內部的接口調用，內部的完整事務都會變成微服務模塊間的跨域的接口服務調用，傳統事務也變成了分布式事務，這些本身是增加了系統復雜度。

原來一個系統就能夠完成的事情，現在要依賴底層技術組件服務，其它業務微服務模塊多個Http Rest API接口調用往往才能夠完成。只要其中任何一個API接口出現問題，都會直接影響到前端的業務功能使用。

微服務間的雪崩效應：在采用微服務架構后，各個微服務間存在大量的API接口服務調用，相互之間還形成了服務調用鏈，比如A-》B-》C，那么如果C服務出現故障就將直接影響到B服務無法正常訪問和服務阻塞，同時B的故障又將進一步傳導到A服務的消費和使用。

對于互聯網企業實施微服務架構，其中有幾個關鍵點。

• 其一就是微服務架構可以更好的進行平臺的性能擴展和高伸縮要求。

• 其二就是互聯網應用本身業務規則相對簡單，模塊間容易解耦。

• 其三就是大的互聯網企業IT技術積累更強，有更好的技術能夠搭建高可用的技術平臺，也有更好的技術能夠實現微服務架構實施后的自動化運維和監控。

而這些往往都是傳統企業在實施微服務架構所欠缺的，比如有些企業一開始實施微服務架構沒發現問題，結果最終上線后卻發現后續的系統運維和性能監控，故障問題分析和排查等能力跟不上，無法及時響應客戶需求并快速的定位和解決問題。

即前面經常說到的，傳統企業的IT治理和團隊技術能力跟不上，直接影響到微服務架構實施成敗。

那么回到正題，今天希望討論和分析下，企業實施微服務架構后，如何盡量減少微服務模塊的耦合導致的單個微服務模塊功能實現和運行故障，簡單來說就是一個微服務模塊中業務功能的運行，如何做到最小化的依賴外部微服務模塊Http API服務接口的可用性。即使外部模塊掛點，當前模塊也能夠正常使用，或者說能夠不影響到當前模塊核心功能的使用。后臺（朱小廝的博客）回復1024，即可領取k8s資料。

對于該問題，我們可以分開從幾個方面進行討論。

同步調用轉為異步調用

一說到解耦，我們一定會首先想到消息中間件來實現異步，即將同步轉為異步，通過異步來實現解耦。我們可以先想消息發送給消息中間件，只要消息中間件是高可用性的沒有宕機，整個接口集成過程就是OK的，而消息中間件再異步方式分發消息給目標系統，同時支持重試。

消息中間件的采用

消息中間件（message oriented middleware）是指支持與保障分布式應用程序之間同步/異步收發消息的中間件。消息是分布式應用之間進行數據交換的基本信息單位，分布式應用程序之間的通信接口由消息中間件提供。其中，異步方式指消息發送方在發送消息時不必知道接收方的狀態，更無需等待接收方的回復，而接收方在收到消息時也不必知道發送方的目前狀態，更無需進行同步的消息處理，它們之間的連接完全是松耦合的，通信是非阻塞的，這種異步通信方式是由消息中間件中的消息隊列及其服務機制保障的。

消息中間件實現了發布者和訂閱者在時間、空間和流程三個方面的解耦：

• 時間解耦—－發布方和訂閱方無需同時在線就能夠進行消息傳輸，消息中間件通過存儲轉發提供了這種異步傳輸的能力；

• 空間解耦——發布方和訂閱方都無需知道對方的物理地址、端口，甚至無需知道對方的邏輯名字和個數；

• 流程解耦——發布方和訂閱方在發送和接收數據時并不阻塞各自的控制流程。

從消息中間件的基本功能來看，無論是點對點消息中間件還是消息代理，其體系結構都是非常清晰簡單的。但由于分布式應用及其環境的多樣性和復雜性，導致了消息中間件的復雜性。

當前的消息中間件仍然分為兩類，一類是基于AMQP高級消息協議的，一類是基于JMS消息協議的。對于互聯網使用較多的RabbitMQ，Kafka等基本都基于AMQP高級消息協議。而對于Weblogic JMS，IBM MQ則是基于JMS消息協議的消息中間件產品。

對于Weblogic而言是一個企業級的應用服務器中間件，同時Weblogic JMS也是企業級的消息中間件產品，該產品是一個企業級消息中間件產品，具備了高可靠，高可用，高擴展，高性能基礎特性。支持主流的各種消息模型，消息發布訂閱，消息持久化，事務處理，集群等核心特性。

消息中間件的使用場景，具體包括了如下幾個方面：

• 消息通知：單據狀態變化后的事件通知，數據傳輸完成后的事件通知

• 異步集成：服務消費方只需要將數據送到OSB即實時返回，通過異步集成實現徹底解耦

• 目標系統削峰：大并發數據導入而目標系統處理性能受限的場景

• 消息發布訂閱：基礎主數據通過JMS實現1對多的實時數據分發

• 高可靠性場景：確保在數據集成中不出現任何丟失的情況

對于采用Weblogic JMS來實現消息集成，具體過程如下圖：

基于事件驅動的業務分析

而要做到同步轉異步，我們必須從業務需求分析開始就轉變思維，即從傳統的業務流程需求分析方法轉到事件驅動分析方法，這個在我很早的EDA事件驅動架構內容整理的時候專門談到過，今天摘錄部分內容供大家參考。

事件驅動框架（EDA）里事件可傳輸于松散耦合的組件和服務之間。一個事件驅動系統典型地由事件消費者和事件產生者組成。事件消費者向事件管理器訂閱事件，事件產生者向事件管理器發布事件。當事件管理器從事件產生者那接收到一個事件時，事件管理把這個事件轉送給相應的事件消費者。如果這個事件消費者是不可用的，事件管理者將保留這個事件，一段間隔之后再次轉送該事件消費者。

EDA架構往往具備如下特征：

• 廣播通信：參與通信的系統將事件廣播給任何對該事件感興趣的參與者。

• 實時性：在業務事件發生時候，EDA架構下可以實時的發送事件給消費方，而無需等待

• 異步：事件發布系統不用等待事件接收系統來處理事件，發送到EDA模塊即可返回。

• 細粒度：只要具備獨立的業務價值，即可以發布為細粒度的事件，而不是傳統服務下的粗粒度。

• 復雜事件處理：根據業務流程需求，事件間可以聚合和組裝，形成事件鏈滿足復雜事件處理。

• 并行運行：多個事件可以同時運行，單個事件可以同時分發給多個訂閱方。

• 非阻塞：EDA本身提供MQ等消息持久化機制，不會在事件大并發下出現事件阻塞情況。

簡單來講，消息集成，異步，徹底解耦，消息發布訂閱，事件鏈是EDA整個架構的核心。但是在EDA包括CEP復雜事件處理，在使用的時候首先還是應該了解清楚其和傳統流程驅動在業務分析方法上的區別。簡單來說，流程驅動和事件驅動的一個簡單比較可以用下圖描述：

基于EDA的核心業務分析思路說明

在事件驅動架構下，業務分析的核心就是事件的識別。而對于傳統方法往往則是關鍵流程和活動即可。在總體分析思路上的變化來說，傳統分析方法只分析到第2-3級業務流程，識別業務活動和交互點，而EDA需要業務分析時候分析到L4級的最底層EPC事件流程圖，并識別關鍵業務事件和事件分解，聚合關系。

在具體分析內容上的變化來說，傳統方法只關心業務活動，而不關系業務活動具體的啟動機制，業務活動完成后產生的業務事件。基于EDA業務分析方法，需要打開業務活動，識別業務活動的前者觸發條件和業務活動引起的業務對象狀態的變化，往往狀態變化點都是關鍵的事件識別點。

具體可以用下圖進行描述：

簡單事件-基于業務需求用例分析和識別

業務事件的識別可以從業務需求用例入手，分析業務用例中的業務前置觸發條件，分析業務對象的狀態流轉過程和后續操作，以找尋業務活動的事件輸入和事件產生。

從下圖里面也可以看到，對于事件的識別往往比用例的識別更加細化，需要詳細的分析業務用例中的基本流，擴展流，業務規則，特別是關注其中核心的業務對象和單據狀態的變化。同時對于用例分析中的觸發條件也需要重點分析，這些觸發條件往往是事件鏈形成，或者說觸發消息事件訂閱的來源。

復雜事件-基于事件識別形成事件鏈

傳統的基于流程的業務分析方法往往只會分析到業務流程，具體的業務活動，而不關心具體業務活動執行前或執行后產生的業務事件，這和接口平臺前期重點關注數據集成有關系。而為了保證業務實時響應需求，必須準確的識別業務事件，才能進一步設計基于業務事件的處理和響應機制。基于EPC事件流程鏈分析思路，需要對傳統分析流程進行細化，增加紅色事件識別點和事件分解聚合關系。在事件鏈的形成過程中往往存在一些復雜場景需要分析，包括了事件的一對多分發和訂閱，也包括了多個事件聚合，在滿足某個特定的業務規則后才觸發下一個新的業務活動和新事件。這些都是在復雜事件分析中必須考慮的內容之一。

從EDA事件驅動到CQRS

顧名思義，CQRS即命令查詢職責分離，將CUD操作和R查詢操作分離，對于CUD操作仍然參考傳統的領域模型建模思路來實現，但是在命令中增加了消息事件機制，實現CUD操作變更通過消息事件異步寫入到數據庫。

在CQRS中，查詢方面，直接通過方法查詢數據庫，然后通過DTO將數據返回，這個方面的操作相對比較簡單。而命令方面，是通過發送具體Command，接著由CommandBus來分發到具體的CommandHandle來進行處理，CommandHandle在進行處理時，并沒有直接將對象的狀態保存到外部持久化結構中，而僅僅是從領域對象中獲得產生的一系列領域事件，并將這些事件保存到Event Store中，同時將事件發布到事件總線Event Bus進行下一步處理；接著Event Bus同樣進行協調，將具體的事件交給具體的Event Handle進行處理，最后Event Handler把對象的狀態保存到對應Query數據庫中。

對于CQRS，最容易想到的還是在數據庫層面做的讀寫分離模式，可以看到CQRS本身和數據庫的讀寫分離模式可以更好的匹配，由于采用事件驅動和消息訂閱模式，對于R讀庫我們可以更加容易對數據變更信息進行更新，達到讀庫數據的及時同步更新。同時讀庫既可以采用讀寫分離數據庫，也可以采用類似Solr，Nosql等分布式，非結構化數據來實現彈性水平擴展能力。后臺（朱小廝的博客）回復1024，即可領取k8s資料。

在命令查詢職責沒有分離的時候，可以看到一方面是模型本身的擴展性受到影響，另外一方面是原有的領域模型本身偏重，而且Entity實體本身也通過完整的DTO對象進行傳輸，這樣在一些特殊的只需要更新或查詢個別字段的時候，整個模型仍然偏重。

通過命令查詢職責的解耦，不僅僅是提升整個框架模型的擴展性，更加重要是將兩類業務規則和實現徹底的解耦開，方便后續的功能開發和運維，特別是在整個業務場景和邏輯實現復雜的情況下，這種解耦會使整個開發架構更加清晰簡單。

同時也可以看到有一Command命令都是采用異步事件的方式進行寫入，因此不存在同步和長連接占用的問題，有利于提升整個平臺在大并發下的整體響應性能。

當然，采用CQRS模式最大的一個問題點就是無法實現命令和查詢兩部分內容的強一致性保障，即很可能你界面上查詢到的數據不是最新的持久化數據庫里面的數據，這個本身和消息管道異步寫入的實時性有關系。

其次在使用CQRS模式的時候，有一個重要假設就是，在事件和命令發出后，無特殊情況在事件接收方都必須要能夠接收事件成功處理，否則就存在大量的異常錯誤消息的異步回寫，反而增加系統的復雜度。舉個簡單例子來說：

當我們在電商平臺購買一個商品的時候，只要訂單提交成功，那么這個訂單就一定能夠生效，也一定有庫存能夠發運和配送，而不是在后續到了配送環節的時才發現沒有庫存而導致訂單取消。如果這樣的話就極大的降低了系統本身的易用性。

即在異步命令和事件發送場景，當命令發送成功時候，雖然我們沒有及時接收到處理方的事件處理結果信息，但是我們默認是接收方能夠成功處理事件。但是我們也看到在CQRS場景框架下，只要命令事件發出，我們并不需要等待任何反饋信息。

另外還有一種CQRS實現場景，即雖然在內部對Command命令處理的時候是基于事件機制，異步響應，但是客戶在前端的操作是同步等待返回。在這種情況下我們就可以保持前端連接，但是是否后端的類似DB連接等。

在CQRS模型下，由于職責分離，可以看到我們通過事件和消息的訂閱，可以實現多個讀庫的訂閱，這些讀庫既可以是結構化數據庫，也可以是非結構化數據庫；既可以用來實現業務功能本身的查詢讀，也可以用來做海量數據本身的分布式全文檢索。

對于CQRS框架的實施，不是簡單的設計模式使用問題，更加重要的仍然是是否能夠接受最終一致性要求，同時在該要求下將傳統的同步請求下業務功能和邏輯處理機制轉變為異步事件價值下的事件鏈驅動模式。要實現這種轉變就必須能夠拆分出獨立，自治的命令和事件，同時確保這些事件在朝后端業務功能和邏輯模塊發送的時候能夠處理成功（即該做的校驗必須提前做完）。

將同步接口調用轉為本地消息緩存

這個類似消息中間件的功能，舉例來說我們設計了一個同步發送訂單到ERP系統的接口，如果在同步實時調用這個接口服務的時候出現異常，那么我們可以首先將消息存儲到本地，然后設置定時任務和重試機制，通過重試方式將消息發送到目標系統。

即對于業務功能來說不用關心實時是否發送成功，而由業務系統自身機制來完成消息發送的重試。而要做到這點，在接口功能設計時候，最好要做到單據業務完整性校驗接口和實際的數據發送接口分離，即先調用接口進行完整性校驗，在校驗沒有問題后再進行消息發送。以確保最終發送的消息不會因為數據完整性的原因導致無法發送成功。

查詢數據的本地化緩存或落地

memcached是一套分布式的高速緩存系統，由LiveJournal的Brad Fitzpatrick開發，但被許多網站使用。這是一套開放源代碼軟件，以BSD license授權發布。

memcached的API使用三十二比特的循環冗余校驗（CRC-32）計算鍵值后，將數據分散在不同的機器上。當表格滿了以后，接下來新增的數據會以LRU機制替換掉。由于memcached通常只是當作緩存系統使用，所以使用memcached的應用程序在寫回較慢的系統時（像是后端的數據庫）需要額外的代碼更新memcached內的數據。

對于實時查詢類接口，將查詢的基礎數據進行本地化緩存，即如果在實時查詢出現異常的時候，我們可以直接查詢本地緩存的數據，減少對業務功能使用的影響。

比如查詢供應商接口服務，如果主數據系統提供的接口出現異常，我們可以直接查詢本地緩存的供應商數據。這種模式對于變更不頻繁的數據基本都適應，同時本身也減少實時調用接口帶來的性能損耗。

如果是接口服務注冊在API網關或ESB服務總線上面，我們還可以考慮在ESB服務總線上啟用緩存能力，即對于調用過的接口，在同樣參數重復調用的時候能夠通過緩存數據獲取，這樣即使在源端業務系統不可用的情況下，也不好影響到當前接口服務的成功調用。

可以適度考慮數據落地

在微服務架構里面，我們一直在強調一點，即數據實時需要實時訪問，不進行底層數據庫的數據集成和同步，這既滿足了數據的高一致性，也滿足了數據實時性的要求。

但是帶來的問題就是強耦合，如果數據提供方出現異常，那么導致消費方業務功能也無法使用。后臺（朱小廝的博客）回復1024，即可領取k8s資料。

因為我們可以適量考慮數據落地方式的數據集成在整體微服務架構實施過程中，對于變化不頻繁的數據適度落地到微服務模塊本地。這樣本身可以減少實時的業務接口服務調用，增加單個微服務模塊的可用性和可靠性。

對于已經出現強耦合如何重構

如果微服務已經實施完成并出現了大量緊耦合的情況，那么我們就需要在后期考慮對微服務架構進行重構，具體重構的方法可以從如下幾點考慮。

兩個微服務本身緊耦合

如果兩個微服務間出現大量接口相互調用，即可以認為緊耦合。

或者我原來的判斷標準，即兩個微服務對應的后臺數據表，其中30%以上都需要兩個微服務交叉訪問，那么就認為兩個微服務本身耦合性極強。

在這種情況下處理措施就是原來微服務劃分的太細了，需要對兩個微服務進行合并。

交叉依賴變為共性依賴

要知道在傳統軟件開發里面往往是不允許兩個組件交叉依賴的。

但是在新的IOC和微服務開發里面，大量都是反射調用，兩個組件相互依賴不會有問題。但是這本身也不是一種很好的設計方法。

如果兩個微服務或多個微服務相互依賴內容本身具備共性。那么最好的做法就是將共性內容全部移出，下沉為一個共性基礎微服務模塊再朝上提供服務。

即交叉依賴轉變為對底層的共性依賴。

對某個微服務實現單元進行遷移

為什么出現這種場景？

簡單來說就是原來的微服務模塊劃分和業務功能劃分不合理。比如上圖中的微服務A中的A1部分。這個部分內容需要大量被微服務B調用，但是A1實際依賴微服務A中其它部分的內容卻很少。

這種就是典型的A1部分功能劃分位置不合理。

最好的做法就是將A1功能從微服務A遷移到微服務B，實現對原有業務劃分不合理的糾正。

將細粒度服務轉變為粗粒度服務

服務本身應該具備粗粒度屬性，暴露僅僅需要暴露的內容。

比如微服務A實現客戶信用檢查和評級。微服務B需要客戶信用。有兩種做法

第一種是B調用A多個接口，把客戶基本信息，客戶交易信息，客戶違約信息全部查詢過來，然后自己計算客戶信用。

第二種即是只需要輸入客戶編碼，微服務A返回最早的信用評級。

對于后者就是我們常說的粗粒度接口或領域服務，服務間的交互應該以領域服務和粗粒度服務為主，避免掉完全的數據庫表的CRUD類服務接口。

想知道更多？掃描下面的二維碼關注我

當當1024圖書優惠活動，“實付滿200再減40”的優惠碼「J2KNAE」，囤書薅羊毛再走一波~~（使用時間：10月20日~11月3日，使用渠道：當當小程序或當當APP）

【精彩推薦】

• 原創|OpenAPI標準規范

• 如此簡單| ES最全詳細使用教程

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

點個贊+在看，少個 bug?????

總結

以上是生活随笔為你收集整理的架构 | 微服务架构下如何解耦，对于已经紧耦合下如何重构？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。