前面我們已經提到單個服務器再優化，它的處理能力都是有上限的，因此我們選擇多擴容以及使用緩存和消息隊列等對程序進行優化。
下面介紹另一種方法，隨着項目需求完成越來越多，應用自然也會越來越大，架構師將一個應用整體拆分成多個應用。
拆分的原則：
1.業務優先，確定業務邊界
2.循序漸進，邊拆分邊測試
3.兼顧技術：重構、分層
4.可靠測試
拆分的思考：
1.應用之間的通信：RPC（dubbo等）、消息隊列
消息傳輸適用於傳輸數據包小但是數據量大，對實時性要求不高的場景。比如下單成功后通過短信通知用戶。而選用RPC框架實時性更高一些。
你應該知道的 RPC 原理
2.應用之間的數據庫設計：每個應用都有獨立的數據庫
3.避免事務操作跨應用，分布式事務是一個非常消耗資源的問題。這樣應用和應用的耦合度降低。
應用拆分：
服務化——Dubbo
微服務——SpringCloud
Dubbo是一種分布式的服務框架
要實踐微服務要解決4個問題：
1.客戶端如何訪問這些服務
API Gateway提供統一的服務入口，對前台透明，同時可以聚合后台的服務，提供安全過濾流控等api的管理功能
2.服務之間是如何通信的
異步的話使用消息隊列，同步調用使用REST或者是RPC，Rest可以使用springboot，RPC通常使用Dubbo
同步調用一致性強但是出現調用問題，REST一般基於http實現，能夠跨客戶端，同時對客戶端沒有更多的要求。
RPC的傳輸協議更高效，安全也更加可控。特別是在一個公司內部如果有統一的開發規范和統一的框架，它的開發效率會更加明顯。
而異步消息在分布式系統中有特別廣泛的應用，它既能減少調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方。
同時保證調用方的用戶的體驗，繼續干自己的活。付出的代價是一致性的減慢，需要接受數據的最終一致性
3. 如何實現如此多服務
在微服務架構中一般每一服務都會拷貝進行負載均衡，服務如何相互感知，如何相互管理，這就是服務發現的問題了，一般都是進行服務注冊信息的分布式管理。
4.服務掛了該如何解決，有什么備份方案和應急處理機制
分布式最大的特性就是網絡是不可靠的，當系統是由一系列的調用鏈組成的時候，其中任何一個出問題都不至於影響到整個鏈路。
相應的手段有：重試機制、應用的限流、熔斷機制、負載均衡、系統降級