13 | 優雅關閉：如何避免服務停機帶來的業務損失？
我們在RPC架構下，需要考慮當服務重啓時，如何做到讓調用方系統不出問題。
當服務提供方要上線時，一般是通過部署系統完成實例重啓，在這個過程彙總，服務提供方不會事先告訴調用方哪些實例會被重啓，從而讓調用方切換流量。而對調用方來說，它也無法預測服務提供方哪些實例會重啓，因此負載均衡還是有可能降正在重啓的實例挑選出來，這樣導致請求被分發到正在重啓的服務實例中，造成調用方無法拿到正確的響應結果。
在服務重啓的時候，對於調用方來說，有以下2種情況：
- 調用方發請求前，目標服務已經下線。對於調用方來說，跟目標節點的連接會斷開，這時調用可以立刻感知到，並在其健康列表中將該實例刪除，這樣就不會被負載均衡選中。
- 調用方發請求時，目標服務正在關閉，但調用方並不知道它正在關閉，而且兩者之間的連接沒有斷開，所以這個節點還會存在健康列表裏面，有可能會被負載均衡選中。
我們可以通過服務發現來實時通知服務調用方關於服務提供方是否可用嗎？
不可以。這樣做的話，整個過程會依賴兩次RPC調用：一次是服務提供方通知註冊中心下線操作，一次是註冊中心通知服務調用方下線節點操作。註冊中心通知服務調用方都是異步的，服務發現只保證最終一致性，並不保證實時性，所以當註冊中心收到服務提供方下線的時候，並不能保證把這次要下線的節點推送給所有調用方，這樣，調用方還是有可能將請求發送給錯誤的服務提供方節點。
如何做到優雅關閉服務？
我們可以嘗試讓服務提供方來通知調用方，RPC裏面調用方和提供方之間是長連接，我們可以在提供方應用內存中維護一份調用方連接集合，當服務關閉時，挨個通知調用方去下線相關實例，這樣整個調用鏈路就變短了，對於每個調用方來說只一次RPC，可以確保調用的成功率很高。
但是上述方法不能徹底解決問題，因爲有時出問題請求的時間點和收到提供方關閉通知的時間點很接近，再加上網絡延遲，還是有可能在服務提供方關閉服務後再接收到新的請求。
解決辦法是我們在關閉的時候，在服務提供方設置一個請求“擋板”，它的作用是告訴調用方，我已經進入關閉流程，不能再處理新的請求了。
當服務提供方正在關閉，如果在之後還收到了新的業務請求，服務提供方直接返回一個特定的異常給調用方（ShutdownException），這個異常就是告訴調用方“我已經收到這個請求了，但是我正在關閉，沒有處理這個請求”，然後調用方收到這個異常響應後，RPC框架就把這個節點從健康列表中挪出，並把請求自動重試到其他節點，因爲這個請求沒有被服務提供方處理過，所以可以安全的重試到其他節點，這樣可以實現對業務無損。
我們還可以加上主動通知流程，讓服務提供方給相關調用方發送關閉通知，這樣既可以保證實時性，也可以避免通知失敗的情況。
在Java語言中，我們可以使用Runtime.addShudownHook方法，來註冊關閉的鉤子，在RPC啓動的時候，我們提前去註冊關閉鉤子，並在裏面添加連個處理程序：一個複雜開啓關閉標識，一個負責安全關閉服務對象，服務對象在關閉的時候會通知調用方下線節點。同時我們需要再調用鏈裏面加上擋板處理器，當新的請求進來時，會判斷關閉標識，如果正在關閉，就拋出特定異常。
對於關閉過程中還在處理的請求，我們可以根據引用計數器，等待正在處理的請求全部結束後再真正關閉服務，同時還可以設置一個超時控制，當超過指定時間，請求還沒有處理完，就強制退出應用。
總結一下，關於如何優雅關閉服務，包括以下步驟：
- 開啓關閉擋板，拒絕新的請求
- 利用引用計數器確保正在執行的請求處理完
- 設置超時時間，保證服務可以正常關閉
- 執行關閉時，服務提供方通知服務調用方下線相關節點
服務優雅關閉的示意圖如下。
“優雅關閉”的概念除了在RPC裏面，在其他很多框架中也很常見，例如Tomcat在關閉的時候，也是先從外層到裏層逐層進行關閉，先保證不接收新的請求，然後再處理關閉前收到的請求。
14 | 優雅啓動：如何避免流量達到沒有啓動完成的節點？
爲什麼Java程序運行一段時間會執行速度會變快？
這是因爲在Java裏面，在運行過程中，JVM虛擬機會把高頻的代碼編譯成機器碼，被加載過的類也會被緩存到JVM緩存中，再次使用的時候就不會觸發臨時加載，這樣就使得
“熱點”代碼的執行不用每次都通過解釋，從而提升執行速度。
什麼是啓動預熱？
啓動預熱就是讓剛啓動的服務提供方應用不承擔全部的流量，而是讓它被調用的次數隨着時間的移動慢慢增加，最終讓流量緩和地增加到跟已經運行一段時間後的水平一樣。
服務調用方應用通過服務發現能夠取得服務提供方的IP地址，然後每次發送請求前，都需要通過負載均衡算法從連接池中選擇一個可用連接，我們可以讓負載均衡在選擇連接的時候，區分一下是不是剛啓動的應用，如果是剛啓動的應用，我們可以調低它的權重值，這樣它被選中的概率會很低，隨着時間推移，我們逐漸增大它的權重值，從而實現一個動態增加流量的效果。
我們如何獲取服務提供方應用的啓動時間？有兩種方法：
- 服務提供方在啓動的時候，把自己啓動的時間告訴註冊中心。
- 註冊中心收到的服務提供方請求註冊的時間。
啓動越熱更多是從調用方的角度出發，去解決服務提供方應用冷啓動的問題，讓調用方的請求量通過一個時間窗口過渡，慢慢達到一個正常的水平，從而實現平滑上線。
從服務提供方的角度來說，有什麼優化方案嗎？服務提供方可以使用延遲暴露的方法來優化熱啓動過程。
問題：服務提供方應用在沒有完成啓動的時候，調用方的請求就過來了，而調用方請求過來的原因，在於服務提供方應用啓動過程中把解析到的RPC服務註冊到了註冊中心，這就導致了後續加載沒有完成的情況下，服務提供方地址就被服務調用方感知到了。
解決辦法：我們在應用啓動加載、解析Bean的時候，如果遇到了RPC服務的Bean，只先把這個Bean註冊到Spring-BeanFactory裏面，而不把這個Bean對應的接口註冊到註冊中心，只有等應用啓動完成後，才被接口註冊到註冊中心用於服務發現，從而實現讓服務調用方延遲獲取到服務提供方地址。
我們還可以利用服務啓動完成到註冊到註冊中心的那段時間，預留一個Hook，讓用戶可以擴展Hook邏輯，在Hook裏面模擬業務調用邏輯，從而使得JVM指令能夠預熱起來，同時還可以在Hook中預先加載一些資源，只有等所有緩存和資源都加載完成後，才把接口註冊到註冊中心，這樣也就完成了熱啓動整個流程。
如果我們有大批量的服務都需要重啓，如何避免同時重啓造成請求被分發到新啓動的應用實例而造成超時錯誤？
我們可以採取一些措施：
- 分時分批啓動，就像灰度發佈一樣。
- 根據重啓比例來設置重啓服務的權重。
- 在請求低峯重啓應用。
- 在重啓過程中，如有必要，對服務進行限流處理。