比如一個股票系統有用戶信息、開戶、股票行情、交易、訂單等，拆分後如下圖所示：

原則

業務優先

每個系統都會有多個模塊，每個模塊又有多個業務功能；按照業務邊界進行切割，再對模塊進行拆分。

循序漸進

邊拆分邊測試，保證系統的正常運行。

兼顧技術：重構、分層

不能為了分布式而分布式，拆分過程不僅是業務梳理也是代碼重構的過程，根據技術進行分層來分配工作，ui對用戶體驗，熟悉C和C++對服務器，熟悉數據庫的對數據庫，做到術業有專攻，合適的人去做合適的事情。

可靠測試

測試完畢後，才可進行下一步，每一步都要有足夠的測試才可進行下一步，避免小錯誤引起蝴蝶效應。

思考

應用之間通信: RPC ( dubbo等)、消息隊列

消息隊列通常用於傳輸數據包小但是數據量大，對實時性要求低的場景，比如下單後短信通知客戶。而采用RPC要求實時性高，這裏通常不會http或者service服務，原因是使用PRC調用service方法無感知，在配置好後和本地方法很像。

應用之間數據庫設計:每個應用都有獨立的數據庫

通常情況下，每個應用都有自己獨立的數據庫，如果共同使用的信息，可以考慮放在common中使用。

避免事務操作跨應用

分布式事務是一個很消耗資源的問題，應用之間服務分開開發，能夠保持相互獨立。

框架

dubbo

spring cloud

微服務

獨立的服務共同組成一個系統

要實踐微服務要解決4個問題：

①客戶端如何訪問這些服務

API Gateway提供統一的服務入口，對前臺透明，同時可以聚合後臺的服務，提供安全過濾流控等api的管理功能。

②服務之間是如何通信的

異步的話使用消息隊列，同步調用使用REST或者是RPC，Rest可以使用springboot，RPC通常使用Dubbo。
同步調用一致性強但是出現調用問題，REST一般基於http實現，能夠跨客戶端，同時對客戶端沒有更多的要求。
RPC的傳輸協議更高效，安全也更加可控。特別是在一個公司內部如果有統一的開發規範和統一的框架，它的開發效率會更加明顯。
而異步消息在分布式系統中有特別廣泛的應用，它既能減少調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方。
同時保證調用方的用戶的體驗，繼續幹自己的活。付出的代價是一致性的減慢，需要接受數據的最終一致性

③如何實現如此多服務

在微服務架構中一般每一服務都會拷貝進行負載均衡，服務如何相互感知，如何相互管理，這就是服務發現的問題了，一般都是進行服務註冊信息的分布式管理。

④服務掛了該如何解決，有什麽備份方案和應急處理機制

分布式最大的特性就是網絡是不可靠的，當系統是由一系列的調用鏈組成的時候，其中任何一個出問題都不至於影響到整個鏈路。
相應的手段有：重試機制、應用的限流、熔斷機制、負載均衡、系統降級。

高並發處理思路與手段（四）：應用拆分