1、首先遠端服務呼叫有三種模式:同步、非同步 future、非同步 callback 三種呼叫模型,正常的都是同步呼叫，呼叫的時候阻塞當前執行緒，非同步一般只會在特殊的情景下有用。
2、全域性配置：所有服務的配置應該是需要在乙個全域性配置中心配置（zookeeper集群）的，而不是寫死在**裡面，避免出現問題還需要修改**、重啟所有機器。尤其是流量控制、介面降級、重試次數等。
3、介面的重試：遠端呼叫介面一般由於網路問題等問題經常會出現異常，這時候往往可以需要重試一下，但是不是所有的介面都需要重試，比如由於處理時間過長導致超時異常，其實只是處理慢了點而已，已經處理了，這時候再重試會有問題的，所以一般建議update、insert型別的介面就不要重試了，或者介面能保證冪等。（像由於介面異常問題導致的資料不一致可以通過mq實現重試，在消費mq時保證冪等。這樣能最大限度的保證資料一致性）
4、服務節點的自動註冊和發現：乙個分布式的rpc框架肯定缺不了服務的註冊與發現，註冊中心有很多種實現方式，一般採用zookeeper集群來實現。
5、負載均衡：client端對server的呼叫負載均衡能規避短板效應，常見的負載均衡演算法有輪詢、隨機、最少呼叫、一致hash等加權的演算法。
6、熔斷：這個功能也是乙個分布式框架必須要有的。比如服務方法級的熔斷可以使得client端在短時間內發現該方法大量異常就會直接丟擲異常，避免繼續給server端增加壓力，防止級聯崩潰。合適的設定消費方服務方法熔斷，既可以保護服務提供方，避免其已經處於不健康狀態下時繼續給壓。也可以避免消費方應用大量執行緒因等待服務方結果返回被阻塞（在同步呼叫下），有效的保護服務消費方自身。還有一種是服務節點級的熔斷，比如發現該節點cpu打滿、節點不可用，直接將本節點踢出集群，這樣client在負載均衡呼叫時會忽略這個節點。
7、流量控制：分client段的流量控制和server端的流量控制。
服務端的流量控制：避免請求超過系統設計的承受能力，防止服務崩潰，應該設定乙個合理的閥值，超過閥值的請求可以被快速拒絕。在服務提供方維護乙個執行緒池，該執行緒池負責服務介面的執行，執行緒池有個任務佇列，一但佇列滿了，直接拒絕服務。
消費方的流量控制：消費方可針對某個服務設定併發閥值，也可用執行緒池去維護，當併發量超過該閥值時則無法執行，合理的設定消費方的併發閥值不僅能有效的保護服務方，而且也能避免消費方大量執行緒因等待服務方結果返回被阻塞（在同步呼叫下），有效的保護服務消費方自身。
8、服務路由：client端的集群呼叫server端的那個集群是可以配置的，集群隔離也能有效的防止某個clinet的併發暴增導致的關鍵鏈路雪崩。在server端設定服務路由也能有效的控制所有client端呼叫的集群，集群隔離，保護自身。
9、服務治理及監控：trace監控也是很重要的，作為大型分布式系統，乙個api介面的server方可能級聯高達數十個，那麼監控同一鏈路不同層級server的效能和引數日誌就很重要，也可以依賴對此設定異常告警。
延伸乙個問題，在超大型分布式系統裡，為了更高的響應速度，可能會部署多機房，這時候很多業務的資料庫架構為了效能就會出現跨zone拒絕寫入的問題，這時候就很需要服務路由去解決找到正確的機房。
分布式服務框架 Zookeeper
createmode persistent 建立後只要不刪就永久存在 ephemeral 會話結束年結點自動被刪除，ephemeral結點不允許有子節點 sequential 節點名末尾會自動追加乙個10位數的單調遞增的序號，同乙個節點的所有子節點序號是單調遞增的 persistent sequen...
微服務 分布式服務框架
spring cloud rest與rpc比較 dubbo 和 spring cloud 對比 通訊協議 傳輸的格式都屬於協議 服務路由 分布式服務上線時都是集群組網部署，集群中會存在某個服務的多例項，消費者如何從服務列表中選擇合適的服務提供者進行呼叫，這就涉及到服務路由。分布式服務框架需要能夠滿足...
初識分布式服務框架dubbo
dubbo是乙個分布式服務框架，以及soa治理方案。其功能主要包括 高效能nio通訊及多協議整合，服務動態定址與路由，軟負載均衡與容錯，依賴分析與降級等。dubbo底層是tcp協議的netty nio spring boot底層是http協議 dubbo的七大標籤 config 配置層，對外配置介面...