微服務分布式事務
1. AB方法都有事務，AB在同一微服務內，不同service，A調用B後，B出現異常，B回滾了，但是A沒有回滾
@Transactional採用的是資料庫的事務回滾機制，也就是說，如果整個系統只操作一個庫，那麼這內種機制是可行的容。如果不是，那麼這種機制就無法運行
針對你說的問題，感覺你的A服務，B服務，操作的是不同的資料庫，那麼依賴於資料庫的回滾機制是不行的。要使用：分布式事務（JTA）
2. 微服務 是什麼
首先，微服務簡單來說就是細粒度的獨立的服務。在微服務架構裡面這些服務都是獨立部署的，服務是獨立開發測試變更。這些服務都有自己的數據，這是微服務架構。
3. 為什麼說分布式事務不再適用於微服務架構
樓主這個說法很標准，不是不可用，只是不適用。我們看下為什麼分布式事務不再適用於微服務架構。
多個微服務應用就構成了分布式系統，由此會帶來固有的復雜性。開發者需要在RPC或者消息傳遞之間選擇並完成進程間通訊機制。更甚於，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這並不是什麼難事，但相對於單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。
另外一個關於微服務的挑戰來自於分區的資料庫架構。商業交易中同時給多個業務分主體更新消息很普遍。這種交易對於單體式應用來說很容易，因為只有一個資料庫。在微服務架構應用中，需要更新不同服務所使用的不同的資料庫。使用分布式交易並不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL資料庫和消息傳遞中間件並不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。
部署一個微服務應用也很復雜，一個分布式應用只需要簡單在復雜均衡器後面部署各自的伺服器就好了。每個應用實例是需要配置諸如資料庫和消息中間件等基礎服務。相對比，一個微服務應用一般由大批服務構成。例如，根據Adrian Cockcroft，Hailo有160個不同服務構成，NetFlix有大約600個服務。每個服務都有多個實例。這就造成許多需要配置、部署、擴展和監控的部分，除此之外，你還需要完成一個服務發現機制，以用來發現與它通訊服務的地址（包括伺服器地址和埠）。傳統的解決問題辦法不能用於解決這么復雜的問題。接續而來，成功部署一個微服務應用需要開發者有足夠的控制部署方法，並高度自動化。
總而言之，一句話概括，由於每個微服務實現方式五花八門，當微服務多了情況下，一個服務流程可能會涉及多個服務，如果這些微服務耦合過於強，那必然要確保其事務的一致性，但是這是個及其困難的事情。
4. 服務化架構的分布式事務問題用什麼方法解決
1. 性能和時延問題
在服務化之前，業務通常都是本地API調用，本地方法調用性能損耗較小。服務化之後，服務提供者和消費者之間採用遠程網路通信，增加了額外的性能損耗：
1） 客戶端需要對消息進行序列化，主要佔用CPU計算資源。
2） 序列化時需要創建二進制數組，耗費JVM堆內存或者堆外內存。
3） 客戶端需要將序列化之後的二進制數組發送給服務端，佔用網路帶寬資源。
4） 服務端讀取到碼流之後，需要將請求數據報反序列化成請求對象，佔用CPU計算資源。
5） 服務端通過反射的方式調用服務提供者實現類，反射本身對性能影響就比較大。
6） 服務端將響應結果序列化，佔用CPU計算資源。
7） 服務端將應答碼流發送給客戶端，佔用網路帶寬資源。
8） 客戶端讀取應答碼流，反序列化成響應消息，佔用CPU資源。
通過分析我們發現，一個簡單的本地方法調用，切換成遠程服務調用之後，額外增加了很多處理流程，不僅佔用大量的系統資源，同時增加了時延。一些復雜
的應用會拆分成多個服務，形成服務調用鏈，如果服務化框架的性能比較差、服務調用時延也比較大，業務服務化之後的性能和時延將無法滿足業務的性能需求。
1.1RPC框架高性能設計
影響RPC框架性能的主要因素有三個。
1） I/O調度模型：同步阻塞I/O（BIO）還是非阻塞I/O（NIO）。
2） 序列化框架的選擇：文本協議、二進制協議或壓縮二進制協議。
3） 線程調度模型：串列調度還是並行調度，鎖競爭還是無鎖化演算法。
1. I/O調度模型
在I/O編程過程中，當需要同時處理多個客戶端接入請求時，可以利用多線程或者I/O多路復用技術進行處理。I/O多路復用技術通過把多個I/O的
阻塞復用到同一個select的阻塞上，從而使得系統在單線程的情況下可以同時處理多個客戶端請求。與傳統的多線程/多進程模型比，I/O多路復用的最大
優勢是系統開銷小，系統不需要創建新的額外進程或者線程，也不需要維護這些進程和線程的運行，降低了系統的維護工作量，節省了系統資源。
JDK1.5_update10版本使用epoll替代了傳統的select/poll，極大地提升了NIO通信的性能，它的工作原理如圖1-1所示。
圖1-1非阻塞I/O工作原理
Netty是一個開源的高性能NIO通信框架：它的I/O線程NioEventLoop由於聚合了多路復用器Selector，可以同時並發處理成
百上千個客戶端Channel。由於讀寫操作都是非阻塞的，這就可以充分提升I/O線程的運行效率，避免由於頻繁I/O阻塞導致的線程掛起。另外，由於
Netty採用了非同步通信模式，一個I/O線程可以並發處理N個客戶端連接和讀寫操作，這從根本上解決了傳統同步阻塞I/O一連接一線程模型，架構的性能、彈性伸縮能力和可靠性都得到了極大的提升。
Netty被精心設計，提供了很多獨特的性能提升特性，使它做到了在各種NIO框架中性能排名第一，它的性能優化措施總結如下。
1） 零拷貝：（1）Netty的接收和發送ByteBuffer採用DIRECT
BUFFERS，使用堆外直接內存進行Socket讀寫，不需要進行位元組緩沖區的二次拷貝。如果使用傳統的堆內存（HEAP
BUFFERS）進行Socket讀寫，JVM會將堆內存Buffer拷貝一份到直接內存中，然後才寫入Socket中。相比於堆外直接內存，消息在發送
過程中多了一次緩沖區的內存拷貝。（2）Netty提供了組合Buffer對象，可以聚合多個ByteBuffer對象，用戶可以像操作一個Buffer
那樣方便地對組合Buffer進行操作，避免了傳統通過內存拷貝的方式將幾個小Buffer合並成一個大的Buffer。（3）Netty的文件傳輸採用
了transferTo方法，它可以直接將文件緩沖區的數據發送到目標Channel，避免了傳統通過循環write方式導致的內存拷貝問題。
2）
內存池：隨著JVM虛擬機和JIT即時編譯技術的發展，對象的分配和回收是個非常輕量級的工作。但是對於緩沖區Buffer，情況卻稍有不同，特別是對於
堆外直接內存的分配和回收，是一件耗時的操作。為了盡量重用緩沖區，Netty提供了基於內存池的緩沖區重用機制。性能測試表明，採用內存池的
ByteBuf相比於朝生夕滅的ByteBuf，性能高23倍左右（性能數據與使用場景強相關）。
3）
無鎖化的串列設計：在大多數場景下，並行多線程處理可以提升系統的並發性能。但是，如果對於共享資源的並發訪問處理不當，會帶來嚴重的鎖競爭，這最終會導
致性能的下降。為了盡可能地避免鎖競爭帶來的性能損耗，可以通過串列化設計，即消息的處理盡可能在同一個線程內完成，期間不進行線程切換，這樣就避免了多
線程競爭和同步鎖。為了盡可能提升性能，Netty採用了串列無鎖化設計，在I/O線程內部進行串列操作，避免多線程競爭導致的性能下降。表面上看，串列
化設計似乎CPU利用率不高，並發程度不夠。但是，通過調整NIO線程池的線程參數，可以同時啟動多個串列化的線程並行運行，這種局部無鎖化的串列線程設
計相比一個隊列-多個工作線程模型性能更優。
4） 高效的並發編程：volatile的大量、正確使用；CAS和原子類的廣泛使用；線程安全容器的使用；通過讀寫鎖提升並發性能。
2. 高性能序列化框架
影響序列化性能的關鍵因素總結如下。
1） 序列化後的碼流大小（網路帶寬的佔用）。
2） 序列化&反序列化的性能（CPU資源佔用）。
3） 是否支持跨語言（異構系統的對接和開發語言切換）。
4） 並發調用的性能表現：穩定性、線性增長、偶現的時延毛刺等。
相比於JSON等文本協議，二進制序列化框架性能更優異，以Java原生序列化和Protobuf二進制序列化為例進行性能測試對比，結果如圖1-2所示。
圖1-2序列化性能測試對比數據
在序列化框架的技術選型中，如無特殊要求，盡量選擇性能更優的二進制序列化框架，碼流是否壓縮，則需要根據通信內容做靈活選擇，對於圖片、音頻、有大量重復內容的文本文件（例如小說）可以採用碼流壓縮，常用的壓縮演算法包括GZip、Zig-Zag等。
3. 高性能的Reactor線程模型
該模型的特點總結如下。
1） 有專門一個NIO線程：Acceptor線程用於監聽服務端，接收客戶端的TCP連接請求。
2） 網路I/O操作：讀、寫等由一個NIO線程池負責，線程池可以採用標準的JDK線程池實現，它包含一個任務隊列和N個可用的線程，由這些NIO線程負責消息的讀取、解碼、編碼和發送。
3） 1個NIO線程可以同時處理N條鏈路，但是1個鏈路只對應1個NIO線程，防止產生並發操作。
由於Reactor模式使用的是非同步非阻塞I/O，所有的I/O操作都不會導致阻塞，理論上一個線程可以獨立處理所有I/O相關的操作，因此在絕大多數場景下，Reactor多線程模型都可以完全滿足業務性能需求。
Reactor線程調度模型的工作原理示意如圖1-3所示。
圖1-3高性能的Reactor線程調度模型
1.2業務最佳實踐
要保證高性能，單依靠分布式服務框架是不夠的，還需要應用的配合，應用服務化高性能實踐總結如下：
1） 能非同步的盡可能使用非同步或者並行服務調用，提升服務的吞吐量，有效降低服務調用時延。
2） 無論是NIO通信框架的線程池還是後端業務線程池，線程參數的配置必須合理。如果採用JDK默認的線程池，最大線程數建議不超過20個。因為JDK的線程池默認採用N個線程爭用1個同步阻塞隊列方式，當線程數過大時，會導致激烈的鎖競爭，此時性能不僅不會提升，反而會下降。
3）
盡量減小要傳輸的碼流大小，提升性能。本地調用時，由於在同一塊堆內存中訪問，參數大小對性能沒有任何影響。跨進程通信時，往往傳遞的是個復雜對象，如果
明確對方只使用其中的某幾個欄位或者某個對象引用，則不要把整個復雜對象都傳遞過去。舉例，對象A持有8個基本類型的欄位，2個復雜對象B和C。如果明確
服務提供者只需要用到A聚合的C對象，則請求參數應該是C，而不是整個對象A。
4） 設置合適的客戶端超時時間，防止業務高峰期因為服務端響應慢導致業務線程等應答時被阻塞，進而引起後續其他服務的消息在隊列中排隊，造成故障擴散。
5） 對於重要的服務，可以單獨部署到獨立的服務線程池中，與其他非核心服務做隔離，保障核心服務的高效運行。
6） 利用Docker等輕量級OS容器部署服務，對服務做物理資源層隔離，避免虛擬化之後導致的超過20%的性能損耗。
7） 設置合理的服務調度優先順序，並根據線上性能監控數據做實時調整。
2. 事務一致性問題
服務化之前，業務採用本地事務，多個本地SQL調用可以用一個大的事務塊封裝起來，如果某一個資料庫操作發生異常，就可以將之前的SQL操作進行回滾，只有所有SQL操作全部成功，才最終提交，這就保證了事務強一致性，如圖2-1所示。
服務化之後，三個資料庫操作可能被拆分到獨立的三個資料庫訪問服務中，此時原來的本地SQL調用演變成了遠程服務調用，事務一致性無法得到保證，如圖2-2所示。
圖2-2服務化之後引入分布式事務問題
假如服務A和服務B調用成功，則A和B的SQL將會被提交，最後執行服務C，它的SQL操作失敗，對於應用1消費者而言，服務A和服務B的相關
SQL操作已經提交，服務C發生了回滾，這就導致事務不一致。從圖2-2可以得知，服務化之後事務不一致主要是由服務分布式部署導致的，因此也被稱為分布
式事務問題。
2.1分布式事務設計方案
通常，分布式事務基於兩階段提交實現，它的工作原理示意圖如圖2-3所示。
圖2-3兩階段提交原理圖
階段1：全局事務管理器向所有事務參與者發送准備請求；事務參與者向全局事務管理器回復自己是否准備就緒。
階段2：全局事務管理器接收到所有事務參與者的回復之後做判斷，如果所有事務參與者都可以提交，則向所有事務提交者發送提交申請，否則進行回滾。事務參與者根據全局事務管理器的指令進行提交或者回滾操作。
分布式事務回滾原理圖如圖2-4所示。
圖2-4分布式事務回滾原理圖
兩階段提交採用的是悲觀鎖策略，由於各個事務參與者需要等待響應最慢的參與者，因此性能比較差。第一個問題是協議本身的成本：整個協議過程是需要加
鎖的，比如鎖住資料庫的某條記錄，且需要持久化大量事務狀態相關的操作日誌。更為麻煩的是，兩階段鎖在出現故障時表現出來的脆弱性，比如兩階段鎖的致命缺
陷：當協調者出現故障，整個事務需要等到協調者恢復後才能繼續執行，如果協調者出現類似磁碟故障等錯誤，該事務將被永久遺棄。
對於分布式服務框架而言，從功能特性上需要支持分布式事務。在實際業務使用過程中，如果能夠通過最終一致性解決問題，則不需要做強一致性；如果能夠避免分布式事務，則盡量在業務層避免使用分布式事務。
2.2分布式事務優化
既然分布式事務有諸多缺點，那麼為什麼我們還在使用呢？有沒有更好的解決方案來改進或者替換呢？如果我們只是針對分布式事務去優化的話，發現其實能改進的空間很小，畢竟瓶頸在分布式事務模型本身。
那我們回到問題的根源：為什麼我們需要分布式事務？因為我們需要各個資源數據保持一致性，但是對於分布式事務提供的強一致性，所有業務場景真的都需
要嗎？大多數業務場景都能容忍短暫的不一致，不同的業務對不一致的容忍時間不同。像銀行轉賬業務，中間有幾分鍾的不一致時間，用戶通常都是可以理解和容忍
的。
在大多數的業務場景中，我們可以使用最終一致性替代傳統的強一致性，盡量避免使用分布式事務。
在實踐中常用的最終一致性方案就是使用帶有事務功能的MQ做中間人角色，它的工作原理如下：在做本地事務之前，先向MQ發送一個prepare消
息，然後執行本地事務，本地事務提交成功的話，向MQ發送一個commit消息，否則發送一個rollback消息，取消之前的消息。MQ只會在收到
commit確認才會將消息投遞出去，所以這樣的形式可以保證在一切正常的情況下，本地事務和MQ可以達到一致性。但是分布式調用存在很多異常場景，諸如
網路超時、VM宕機等。假如系統執行了local_tx()成功之後，還沒來得及將commit消息發送給MQ，或者說發送出去由於網路超時等原因，MQ
沒有收到commit，發生了commit消息丟失，那麼MQ就不會把prepare消息投遞出去。MQ會根據策略去嘗試詢問（回調）發消息的系統
（checkCommit）進行檢查該消息是否應該投遞出去或者丟棄，得到系統的確認之後，MQ會做投遞還是丟棄，這樣就完全保證了MQ和發消息的系統的
一致性，從而保證了接收消息系統的一致性。
3. 研發團隊協作問題
服務化之後，特別是採用微服務架構以後。研發團隊會被拆分成多個服務化小組，例如AWS的Two Pizza Team，每個團隊由2~3名研發負責服務的開發、測試、部署上線、運維和運營等。
隨著服務數的膨脹，研發團隊的增多，跨團隊的協同配合將會成為一個制約研發效率提升的因素。
3.1共用服務注冊中心
為了方便開發測試，經常會在線下共用一個所有服務共享的服務注冊中心，這時，一個正在開發中的服務發布到服務注冊中心，可能會導致一些消費者不可用。
解決方案：可以讓服務提供者開發方，只訂閱服務（開發的服務可能依賴其他服務），而不注冊正在開發的服務，通過直連測試正在開發的服務。
它的工作原理如圖3-1所示。
圖3-1隻訂閱，不發布
3.2直連提供者
在開發和測試環境下，如果公共的服務注冊中心沒有搭建，消費者將無法獲取服務提供者的地址列表，只能做本地單元測試或使用模擬樁測試。
還有一種場景就是在實際測試中，服務提供者往往多實例部署，如果服務提供者存在Bug，就需要做遠程斷點調試，這會帶來兩個問題：
1） 服務提供者多實例部署，遠程調試地址無法確定，調試效率低下。
2） 多個消費者可能共用一套測試聯調環境，斷點調試過程中可能被其他消費者意外打斷。
解決策略：繞過注冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直聯方式將以服務介面為單位，忽略注冊中心的提供者列表。
3.3多團隊進度協同
假如前端Web門戶依賴後台A、B、C和D
4個服務，分別由4個不同的研發團隊負責，門戶要求新特性2周內上線。A和B內部需求優先順序排序將門戶的優先順序排的比較高，可以滿足交付時間點。但是C和
D服務所在團隊由於同時需要開發其他優先順序更高的服務，因此把優先順序排的相對較低，無法滿足2周交付。
在C和D提供版本之前，門戶只能先通過打測試樁的方式完成Mock測試，但是由於並沒有真實的測試過C和D服務，因此需求無法按期交付。
應用依賴的服務越多，特性交付效率就越低下，交付的速度取決於依賴的最遲交付的那個服務。假如Web門戶依賴後台的100個服務，只要1個核心服務沒有按期交付，則整個進度就會延遲。
解決方案：調用鏈可以將應用、服務和中間件之間的依賴關系串接並展示出來，基於調用鏈首入口的交付日期作為輸入，利用依賴管理工具，可以自動計算出調用鏈上各個服務的最遲交付時間點。通過調用鏈分析和標准化的依賴計算工具，可以避免人為需求排序失誤導致的需求延期。
3.4服務降級和Mock測試
在實際項目開發中，由於小組之間、個人開發者之間開發節奏不一致，經常會出現消費者等待依賴的服務提供者提供聯調版本的情況，相互等待會降低項目的研發進度。
解決方案：服務提供者首先將介面定下來並提供給消費者，消費者可以將服務降級同Mock測試結合起來，在Mock測試代碼中實現容錯降級的業務邏輯（業務放通），這樣既完成了Mock測試，又實現了服務降級的業務邏輯開發，一舉兩得。
3.5協同調試問題
在實際項目開發過程中，各研發團隊進度不一致很正常。如果消費者坐等服務提供者按時提供版本，往往會造成人力資源浪費，影響項目進度。
解決方案：分布式服務框架提供Mock樁管理框架，當周邊服務提供者尚未完成開發時，將路由切換到模擬測試模式，自動調用Mock樁；業務集成測試和上線時，則要能夠自動切換到真實的服務提供者上，可以結合服務降級功能實現。
3.6介面前向兼容性
由於線上的Bug修復、內部重構和需求變更，服務提供者會經常修改內部實現，包括但不限於：介面參數變化、參數欄位變化、業務邏輯變化和數據表結構變化。
在實際項目中經常會發生服務提供者修改了介面或者數據結構，但是並沒有及時知會到所有消費者，導致服務調用失敗。
解決方案：
1） 制定並嚴格執行《服務前向兼容性規范》，避免發生不兼容修改或者私自修改不通知周邊的情況。
2） 介面兼容性技術保障：例如Thrift的IDL，支持新增、修改和刪除欄位，欄位定義位置無關性，碼流支持亂序等。
4. 總結
服務化之後，無論是服務化框架，還是業務服務，都面臨諸多挑戰，本章摘取了其中一些比較重要的問題，並給出解決方案和最佳實踐。對於本章節沒有列出的問題，則需要服務框架開發者和使用者在實踐中探索，找出一條適合自己產品的服務化最佳實踐。
5. 談談分布式事務有哪些特點
現今互聯網界，分布式系統和微服務架構盛行。一個簡單操作，在服務端非常內可能容是由多個服務和資料庫實例協同完成的。在一致性要求較高的場景下，多個獨立操作之間的一致性問題顯得格外棘手。
基於水平擴容能力和成本考慮，傳統的強一致的解決方案（e.g.單機事務）紛紛被拋棄。其理論依據就是響當當的CAP原理。往往為了可用性和分區容錯性，忍痛放棄強一致支持，轉而追求最終一致性。
分布式系統的特性
在分布式系統中，同時滿足CAP定律中的一致性 Consistency、可用性 Availability和分區容錯性 Partition Tolerance三者是不可能的。在絕大多數的場景，都需要犧牲強一致性來換取系統的高可用性，系統往往只需要保證最終一致性。
https://www.hu.com/question/65292792/answer/229459320
6. 常用的bbo分布式事務解決方案介紹有多少種
分布式事務是一個繞不過去的挑戰！微服務架構本質上就是分布版式服務化架構，微服務架構權的流行，讓分布式事務問題日益突出！尤其是在訂單業務、資金業務等系統核心業務流程中，一定要有可靠的分布式事務解決方案來保證業務數據的可靠性和准確性。
為了解決大家在實施分布式服務化架構過程中關於分布式事務問題的困擾，本教程將基於支付系統真實業務中的經典場景來對「可靠消息的最終一致性方案」、「TCC兩階段型方案」和「最大努力通知型方案」這3種柔性事務解決方案進行具體設計實現和詳細分析。
基於"" ゛龍゛果゛學゛院゛開源的微支付系統進行實現，使用Dubbo作為服務化框架，所實現的分布式事務解決方案在Java體系中的微服務架構系統都能通用，與具體的開發框架無關。
項目中用到的技術及相應的環境：Dubbo、Spring、SpringMVC、MyBatis、Druid、JDK7（或JDK8）、MySQL5.6、Tomcat
7. 什麼是微服務架構啊
微服務架構其實沒有一個非常准確的定義，大概描述的是一個大型復專雜軟體應用系統由若屬干個微服務組成。系統中的各個微服務能被獨立部署和擴展，每個微服務還能提供一個穩固的模塊邊界。各個微服務之間是松耦合的，微服務很小，專注於做好一件事情。微服務框架帶了良好的技術異構性、彈性、擴展性，它的簡化部署為持續交付提供了巨大推動力。但是它同時也帶來一些挑戰，比如分布式事務一致性，網路性能消耗等問題。所以選用的時候要結合實際業務考慮，若想深入學習的話建議使用些現成的一些大廠商開源的微服務框架開發試試手，用一用spring cloud、servicecomb，網上資料都很多，希望這個回答對你有幫助。
8. 微服務架構的分布式事務問題如何處理
分布式系統架構中，分布式事務問題是一個繞不過去的挑戰。而微服務架構的流行，讓分布式事問題日益突出！
下面我們以電商購物支付流程中，在各大參與者系統中可能會遇到分布式事務問題的場景進行詳細的分析！
9. 什麼是微服務
「Mesh App and Service Architecture」作為Gartner2016 十大戰略技術趨勢中之一，裡面大量提到微服務的概念。微服務（Microservices）這個概念不是新概念，很多公司已經在實踐了，例如Google、Netflix、Facebook、Twiter、Alibaba。微服務架構模式（Microservices Architecture Pattern）的目的是將大型的、復雜的、長期運行的應用程序構建為一組相互配合的服務，每個服務都可以很容易得局部改良。
微服務從去年以來一直受到眾多開發者的熱捧，已經看到有許多項目嘗試使用微服務架構，結果很鼓舞人心。然而，在微服務架構帶來可獨立部署、高擴展與伸縮、自由選擇開發語言、高效利用資源、故障隔離等優點，同時也因為服務多帶來分布式事務、服務之間通信、監控、部署等新的問題。
提到微服務架構時，我們常常會做的一件事情，就是會拿來與單體架構進行比較，單體架構存在如下缺點：代碼維護難度大，臃腫的部署，局限的彈性與擴展能力，阻礙團隊與技術革新等等；微服務架構存在如下優點：代碼維護簡化，可獨立部署，高擴展與伸縮，自由選擇開發語言等優點。那麼單體架構真的如此不堪一擊嗎？答案顯然不是這樣，下面我們來看Martin Fowler在其一篇文章裡面給出關系圖：
上面的圖來自 Martin Fowler 的文章，揭示了生產率和復雜度的一個關系。在復雜度較小時採用單體應用（Monolith）的生產率更高，復雜度到了一定規模時，單體應用的生產率開始急劇下降，這時對其進行微服務化的拆分才是合算的。所以說脫離業務場景，空談架構絕對是耍流氓。異常牛逼的架構設計，如果無法在業務場景中落地實施，也只是空談。因此架構需要服務於業務，針對不同的業務場景架構設計也會不同，架構設計不必追求高大上，簡而美的架構，若能滿足業務發展需求，便是好架構。此外，好的架構不完全是設計出來的，隨著業務量、請求量的增長，好的架構是演化而來的。微服務架構之所以得到廣泛認可，源於對於業務多變性的不可預測，微服務架構能夠不斷的自演化，進而快速適應業務變化。但相對於單體架構且經過嚴格定義的大規模開發項目，微服務架構要求大家面對由眾多小型服務所構成的復雜生態系統。
鑒於此，如果長期業務規劃不需要微服務架構或者團隊不具備實施微服務一些基本的條件，不建議各位盲目邁向微服務這一新興架構領域，或者從試點入手，逐步在團隊中推行微服務架構。