優雅停機，就是為了讓服務提供方在停機應用的時候，保證所有呼叫方都能「安全」地切走流量，不再呼叫自己，從而做到對業務無損。其中實現的關鍵點就在於，讓正在停機的服務提供方應用有狀態，讓呼叫方感知到服務提供方正在停機。
簡單來說，就是讓剛啟動的服務提供方應用不承擔全部的流量，而是讓它被呼叫的次數隨著時間的移動慢慢增加，最終讓流量緩和地增加到跟已經執行一段時間後的水平一樣。
服務提供方應用在沒有啟動完成的時候，呼叫方的請求就過來了，而呼叫方請求過來的原因是，服務提供方應用在啟動過程中把解析到的 rpc 服務註冊到了註冊中心，這就導致在後續載入沒有完成的情況下服務提供方的位址就被服務呼叫方感知到了。
在服務提供方應用啟動後，介面註冊到註冊中心前，預留乙個 hook 過程，讓使用者可以實現可擴充套件的 hook 邏輯。使用者可以在 hook 裡面模擬呼叫邏輯，從而使 jvm 指令能夠預熱起來，並且使用者也可以在 hook 裡面事先預載入一些資源，只有等所有的資源都載入完成後，最後才把介面註冊到註冊中心。
整個應用啟動過程如下圖所示
RPC實戰與核心原理之非同步RPC
提公升吞吐量，其實關鍵就兩個字 非同步 提高cpu等資源的利用率 非同步，最常用的方式就是返回 future 物件的 future 方式，或者入參為 callback 物件的 方式，而 future 方式可以說是最簡單的一種非同步方式了。我們發起一次非同步請求並且從請求上下文中拿到乙個 future...
RPC實戰與核心原理之服務發現
為了高可用，在生產環境中服務提供方都是以集群的方式對外提供服務，集群裡面的這些 ip 隨時可能變化，我們也需要用一本 通訊錄 及時獲取到對應的服務節點，這個獲取的過程我們一般叫作 服務發現 對於服務呼叫方和服務提供方來說，其契約就是介面，相當於 通訊錄 中的姓名，服務節點就是提供該契約的乙個具體例項...
RPC實戰與核心原理之健康檢測
因為有了集群，所以每次發請求前，rpc 框架會根據路由和負載均衡演算法選擇乙個具體的 ip 位址。為了保證請求成功，我們就需要確保每次選擇出來的 ip 對應的連線是健康的 業內常用的檢測方法就是用心跳機制，就是服務呼叫方每隔一段時間就問一下服務提供方目前的狀態 可用率的計算方式是某乙個時間視窗內介面...