提公升吞吐量，其實關鍵就兩個字：「非同步」，提高cpu等資源的利用率
非同步，最常用的方式就是返回 future 物件的 future 方式，或者入參為 callback 物件的**方式，而 future 方式可以說是最簡單的一種非同步方式了。我們發起一次非同步請求並且從請求上下文中拿到乙個 future，之後我們就可以呼叫 future 的 get 方法獲取結果。
對於 rpc 框架，無論是同步呼叫還是非同步呼叫，呼叫端的內部實現都是非同步的
呼叫端傳送的每條訊息都乙個唯一的訊息標識，實際上呼叫端向服務端傳送請求訊息之前會先建立乙個 future，並會儲存這個訊息標識與這個 future 的對映，動態**所獲得的返回值最終就是從這個 future 中獲取的；當收到服務端響應的訊息時，呼叫端會根據響應訊息的唯一標識，通過之前儲存的對映找到對應的 future，將結果注入給那個 future，再進行一系列的處理邏輯，最後動態**從 future 中獲得到正確的返回值。
服務端業務處理邏輯非同步
RPC實戰與核心原理之服務發現
為了高可用，在生產環境中服務提供方都是以集群的方式對外提供服務，集群裡面的這些 ip 隨時可能變化，我們也需要用一本 通訊錄 及時獲取到對應的服務節點，這個獲取的過程我們一般叫作 服務發現 對於服務呼叫方和服務提供方來說，其契約就是介面，相當於 通訊錄 中的姓名，服務節點就是提供該契約的乙個具體例項...
RPC實戰與核心原理之健康檢測
因為有了集群，所以每次發請求前，rpc 框架會根據路由和負載均衡演算法選擇乙個具體的 ip 位址。為了保證請求成功，我們就需要確保每次選擇出來的 ip 對應的連線是健康的 業內常用的檢測方法就是用心跳機制，就是服務呼叫方每隔一段時間就問一下服務提供方目前的狀態 可用率的計算方式是某乙個時間視窗內介面...
RPC實戰與核心原理之優雅啟動
優雅停機，就是為了讓服務提供方在停機應用的時候，保證所有呼叫方都能 安全 地切走流量，不再呼叫自己，從而做到對業務無損。其中實現的關鍵點就在於，讓正在停機的服務提供方應用有狀態，讓呼叫方感知到服務提供方正在停機。簡單來說，就是讓剛啟動的服務提供方應用不承擔全部的流量，而是讓它被呼叫的次數隨著時間的移...