丨優(yōu)雅啟動如何避免流量打到?jīng)]有完成的節(jié)點

換到應用上來看，原理也是一樣的。運行了一段時間后的應用，執(zhí)行速度會比剛啟動的應用更快。這是因為在Java里面，在運行過程中，JVM虛擬機會把高頻的代碼編譯成機器碼，被加載過的類也會被緩存到JVM緩存中，再次使用的時候不會觸發(fā)臨時加載，這樣就使得“熱點”代碼的執(zhí)行不用每次都通過解釋，從而提升執(zhí)行速但是這些“臨時數(shù)據(jù)”，都在我們應用重啟后就了。重啟后的這些“紅利”沒有了之后，如果讓我們剛啟動的應用就承擔像停機前一樣的流量，這會使應用在啟動之初就處于高負載狀態(tài)，從而導致調用方過來的請求可能出現(xiàn)大面積超時，進而對線上業(yè)務產(chǎn)生損害行為。在上一講我們，在微服務架構里面，上線肯定是頻繁發(fā)生的，那我們總不能因為上線，就讓過來的請求出現(xiàn)大面積超時吧？所以我們得想點辦法。既然問題的關鍵是在于“剛重啟的服務提供方因為沒有預跑就承擔了大流量”，那我們是不是可以通過某些方法，讓應用一開始只接少許流量呢？這樣低功率運行一段時間后，再逐漸提升至最佳狀態(tài)。這其實就是我今天要和你的重點 里面的一個實用功能——啟動預熱那什么叫啟動預熱呢那在RPC里面，我們該怎么實現(xiàn)這個功RPC調用流程是怎樣的，調用方應用通過服務發(fā)現(xiàn)能夠獲取到服務提供方的IP地址，然后每次發(fā)送請求前，都需要通過負載均衡算法從連接池中選擇一個可用連接。那這樣的話，我現(xiàn)在方案有了，我們就可以考慮具體實現(xiàn)中心收到的服務提供方的請求時間。這兩個時間我認為都可以，不過可能你會猶豫間是一個粗略值，即使機器之間的日期時間存在1分鐘的誤差也不影響，并且在真實環(huán)境中機器都會默認開啟NTP時間同步功能，來保證所有機器時間的一致性。不管你是選擇哪個時間，最終的結果就是，調用方通過服務發(fā)現(xiàn)，除了可以拿到IP列表，還可以拿到對應的啟動時間。我們需要把這個時間作用在負載均衡上，在[第11講]我們介紹過一種基于權重的負載均衡，但是這個權重是由服務提供方設置的，屬于一個固定狀態(tài)。現(xiàn)在我們要讓這個權重變成動態(tài)的，并且是隨著時間的推移慢慢增加到服務提供方設定的固定值，整個過程如下圖所示：預熱過程通過這個小邏輯的改動，我們就可以保證當服務提供方運行時長小于預熱時間時，對服務提供方進行降權，減少被負載均衡選擇的概率，避免讓應用在啟動之初就處于高負載狀態(tài)，從而實現(xiàn)服務提供方在啟動后有一個預熱的過程。關于這個問題，我是這么考慮的。當你大批量重啟服務提供方的時候，對于調用方來說，這些剛重啟的機器權重基本是一樣的，也就是說這些機器被選中的概率是一樣的，大家都是一樣得低，也就不存在權重區(qū)分的問題了。但是對于那些沒有重啟過的應用提供方來說，它被負載均衡選中的概率是相對較高的，但是我們可以通過[第11載啟動預熱是從調用方的角度出發(fā)，去解決服務提供方應用冷啟動的問題，讓調用方的請求量通過一個時間窗口過渡，慢慢達到一個正常水平，從而實現(xiàn)平滑上線。但對于服務提供方本身來說，有沒有相關方案可以實現(xiàn)這種效果呢？當然有，這也是我今天要的另一個重點，和熱啟動關，那就是延遲我們應用啟動的時候都是通過main，然后順序加載各種相關依賴的類。以Sring應用啟動為例，在加載的過程中，Sprig容器會順序加載SringBean，如果某個Bean是RPC服務的話，我們不光要把它到Sprin-BeaFactory里面去，還要把這個Bean對應的接口到中心。中心在收到新上線的服務提供方地址的時候 會把這個址推送到調用方應用內存中；當調用方收到這個服務提供方地址的時候，就會去建立連接發(fā)請求。但這時候是不是存在服務提供方可能并沒有啟動完成的情況？因為服務提供方應用可能還在加載其它的Bean。對于調用方來說，只要獲取到了服務提供方的P，就有可能發(fā)起RPC調用 但如果這時候服務提供方?jīng)]有啟動完成的話，就會導致調用失敗，從而使業(yè)務受損。那有什么辦法可以避免這種情況過程中把解析到的RPC服務到了中心，這就導致在后續(xù)加載沒有完成的情況下服就是在應用啟動加載、解析Bean的時候，如果遇到了RPC服務的Bean，只先把這個Bean到Spring-BeanFactory里面去，而并不把這個Bean對應的接口到中這樣是可以保證應用在啟動完后才開始接入流量的，但其實這樣做，我們還是沒有實現(xiàn)最開始的目標。因為這時候應用雖然啟動完成了，但并沒有執(zhí)行相關的業(yè)務代碼，所以JVM內存里面還是冷的。如果這時候大量請求過來，還是會導致整個應用在高負載模式下運行，從而導致不地返回請求結果。而且在實際業(yè)務中，一個服務的內部業(yè)務邏輯一般會依賴其它資源的，比如緩存數(shù)據(jù)。如果我們能在服務正式提供服務前，先完成緩存的初始化操作，而不是等請求來了之后才去加載，我們就可以降低重啟后第一次請求出錯的概率。那具體怎么實現(xiàn)呢我們還是需要利用服務提供方把接口到中心的那段時間。我們可以在服務提供方應用啟動后，接口到中心前，預留一個ook過程，讓用戶可以實現(xiàn)可擴展的Hook邏輯。用戶可以在Hook里面模擬調用邏輯，從而使JVM指令能夠預熱起來，并且用戶也可以在Hook里面事先預加載一些資源，只有等所有的資源都加載完成后，最后才把接口到中心。整個應用啟動過程如下圖所示：啟動順序包括[第11講]在內，到今天為止，我們就已經(jīng)把整個RPC里面的啟停機流程完了。就像前面的那樣，雖然啟停機流程看起來不屬于RPC主流程，但是如果你能在RPC里面把這些“微小”的工作做好，就可以讓你的技術團隊感受到的微服務帶另外，我們今天的兩大重點——啟動預熱與延遲，它們并不是RPC的專屬功能，我們在啟動預熱那部分，我們特意提到過一個問題，就是“當大批量重啟服務提供方的時候，會導致請求大概率發(fā)到?jīng)]有重啟的機器上，這時服務提供方有可能扛