原先操作面板上的高級功能去哪了？對已經接入的應用有什么影響？我還想開啟或關閉應該怎么操作？

在舊版的無損上下線控制臺交互中，提供了高級功能選項。而高級功能涉及比較多的微服務概念，所以新版交互從簡化使用的角度考慮，在將其進行了隱藏。舊版的高級功能包含兩個子功能：

• 通過就緒檢查前完成服務注冊。

  新版中仍然提供并默認開啟，如果您的應用原先未開啟，當您在控制臺無損上下線界面重新開啟無損上線后會自動開啟。如果您的應用原先已經開啟了該功能，我們不推薦您關閉。該功能在默認開啟的情況下，不會對應用帶來負面影響。默認開啟的情況下，可以規避發版時特定場景下流量跌零的風險，具體可以參考為什么配置55199/health。

• 通過就緒檢查前完成服務預熱。

  新版不再提供，該功能最初的設計目的是用來保證預熱效果達到預期狀態，避免出現開啟預熱的服務QPS曲線出現陡升的情況。本質上是通過推遲K8s就緒檢測通過的時間，來延長整體的發版時間，保障新節點可以有足夠的時間進行預熱，并且讓老節點在這個過程中繼續承擔一部分流量，不會被快速下掉。這樣就可以保證預熱的QPS曲線呈現出是一個緩慢升高的狀態。如果在發版過程中，新節點在預熱時，老節點已經全部下線，那么新節點就需要承受所有的線上流量，從而無法實現“小流量”的預熱。原先已經開啟該功能的應用不會受到影響，但是新應用設置規則時無法再對該功能進行開啟，如果您之前開啟了該功能，我們也不推薦您關閉。該功能在開啟的情況下，不會對應用帶來負面影響。在新版交互中，想要服務小流量預熱達到預期效果，可參見小流量預熱的最佳實踐。

小流量預熱的原理是什么？為什么小流量預熱需要提供者、消費者都接入服務治理？

當消費者對某個服務進行調用時，會對該服務的提供者進行選擇。在提供者應用開啟小流量預熱的情況下，服務治理對這里“選擇提供者”的過程進行了增強。在消費者選擇提供者時，會計算每個提供者的權重大小（0%~100%），權重越大的提供者節點，被選擇和調用的概率就會越高。開啟小流量預熱的提供者在剛啟動時，消費者對其計算的權重很低，因此預熱的節點被調用的概率也會變低，隨著時間增加，這個權重計算結果會不斷增大，最終達到100%，達到100%時，預熱流程就結束了，開始和正常節點一樣接收流量。提供者會在服務注冊的元數據中，帶上自身啟動的時間，以供消費者進行權重計算。這個過程需要提供者、消費者雙方都開啟服務治理才能實現。

為什么我的預熱曲線不符合預期？該如何解決？

正常情況下小流量預熱時，應用的QPS曲線圖如下：

但是有些時候由于不合理或不支持的使用場景，進行小流量預熱的應用，其QPS曲線圖形狀會不太符合預期（緩慢上升），下面是兩種常見的不符合預期的情況：

• QPS 曲線中途出現陡升現象

  

  這種現象一般發生在服務發布的場景，如果在服務發布時，新節點的預熱還沒有達到指定時長，老節點就被下線了，那么消費者端在選擇提供者時，就無法實現控制新節點被“低概率”調用到了。所以會在 QPS 曲線圖中看到，某個新節點的 QPS 曲線在前半段時緩慢上線的態勢，達到某個時間節點后，老節點被全部下線，QPS 曲線就出現陡升現象了。您可以參考小流量預熱的最佳實踐，來解決QPS曲線陡升的問題。

• QPS 曲線未呈現緩升趨勢

  

  出現這種現象，建議檢查對該應用發起請求的消費者應用已經接入服務治理，如果消費者端沒接入，則考慮將消費者應用都接入服務治理，就可以解決該問題。如果您需要預熱的應用，其流量來自外部（比如Java網關），這種場景下消費者是沒有接入服務治理的，小流量預熱也無法支持這種場景。

小流量預熱的最佳實踐是什么？

在滾動發布的情況下，經常會出現預熱不充分的問題。您可以參考以下實踐，來保證服務預熱達到預期效果：

• 配置最小準備時間（推薦）：您可以為工作負載配置.spec.minReadySeconds來控制pod就緒后達到可用狀態時的時間間隔，并且設置該參數的值大于pod的小流量預熱時長，以使得K8s等待 pod 預熱完畢后再繼續滾動發布。 如果您使用的是ACK，您可以直接在容器平臺上找到您的應用，在 更多 > 升級策略 > 滾動升級 > 最小準備時間（minReadySeconds） 中直接設置。（設置 minReadySeconds可以在發布時，讓新啟動的pod狀態達到ready并維持固定時長之后，才會繼續發布）

• 使用分批發布（推薦）：您可以考慮使用OpenKruise等方式，實現工作負載的分批發布，并且控制每個批次發布時的時間間隔大于小流量預熱時長，保證批次內的新節點預熱充分后，再繼續發布一下次批次的節點。

此外，延長Readiness就緒檢測的初始探測時間（不推薦），也是一種方式，您可以增加工作負載Readiness 的首次探測延遲時長（initialDelaySeconds），并且大于小流量預熱時長、延遲注冊時長、應用啟動時間三者之和。注意，應用啟動時間一般需要觀測實際日志輸出來得出，并且隨著業務發展，應用的啟動時間也會隨之變化；此外，延遲 Readiness 通過的時間，也會導致新啟動的節點遲遲無法被加入到 K8s Service的Endpoint中，因此我們不推薦您使用這種方式來保證預熱效果達到最佳。

55199/health是做什么的？為什么不配置55199/health會有流量跌0的風險？

55199/health是MSE微服務治理提供的一套內置的、HTTP類型的就緒檢查端口，當應用的K8s就緒檢查配置成55199/health時，在新節點上線階段，如果該節點尚未完成服務注冊，則就緒檢查返回500；如果該節點已經完成服務注冊，則就緒檢查返回 200。

按照 K8s 默認的發布策略，新節點沒有就緒，老節點就不會下線。當就緒檢查配置了55199/health之后，新節點完成服務注冊之后，才會進入就緒狀態，即只有在新節點完成服務注冊的情況下，老節點才會下線。這樣就會保證注冊中心上該服務一直會有可用的節點。如果您不配置55199/health，可能會在服務發布時，新節點尚未注冊，老節點就被下線，進而導致注冊中心上該服務沒有可用節點，進而導致該服務的所有消費者在調用時因為沒有提供者而發生報錯，從而產生該服務的流量跌0。因此我們強烈建議您開啟無損上線，并為應用配置55199/health就緒檢測。

為什么應用先出現預熱事件后出現服務注冊事件？如何解決？

在當前版本下，服務收到了第一筆外部請求時，就會開始預熱流程，并且上報預熱開始事件。而有些時候，應用收到的第一筆請求，未必是微服務調用請求，因此這種請求也不會觸發業務邏輯的預熱。比如應用的工作負載配置了K8s的Liveness探針，在新節點上線時，即便還沒有進行服務注冊操作，只要K8s對Liveness進行了探測，就會判定預熱已經開始。

為了避免這種情況， 您可以在提供者應用工作負載的環境變量中，配置如下參數，來忽略這些請求對預熱邏輯的觸發：

# 忽略路徑為 /xxx、/yyy/zz 的請求對預熱流程的觸發
profile_micro_service_record_warmup_ignored_path="/xxx,/yyy/zz"

主動通知是做什么的？什么時候需要開啟主動通知？

主動通知是無損下線功能模塊提供的一種進階能力，該功能可以在SpringCloud提供者下線時，讓提供者主動發起一次網絡請求到服務消費者，告知其自身已經下線。消費者收到通知后，不會再對該節點進行調用。一般情況下，當提供者消費者都使用SpringCloud框架時，消費者本地會緩存提供者節點列表。在某些場景下，即便消費者收到注冊中心的通知，也可能沒有及時刷新本地緩存，進而導致消費者對下線的節點仍然發起調用。主動通知則很好地解決了這個問題。

主動通知功能默認關閉，因為開啟服務治理之后，默認的無損下線方案中，下線階段的提供者收到請求時，會在響應中加入一個特殊的header，消費者收到響應時會識別該header，并且不再調用該提供者節點。因此，只要在提供者下線時，消費者有流量到達下線的提供者，就會感知到該提供者已經下線，并且會自動將其“拉黑”。而如果在提供者下線的這段時間內（一般30秒左右），消費者沒有請求到達正在下線的提供者，消費者就有可能未感知到該提供者節點已經下線，有可能會在提供者剛好走完下線流程、即將停機時，消費者請求正好過來，此時就會出現請求報錯的問題。這個時候，就需要開啟主動通知。換句話說，如果消費者的流量非常“稀疏”，就建議您為提供者開啟主動通知的功能。

為什么已經看到無損下線事件后，流量還是沒有快速降為0？

一般情況下，看到無損下線事件后，流量會在短時間內快速降為0。如果沒有降為0，可能的原因和解決方案如下：

• 該應用收到了非微服務方式的調用，比如收到來自外部負載均衡器的流量，或者存在本地腳本、定時任務等調用方式產生了流量。

  目前無損上下線只支持治理內部微服務調用的流量，上述場景并不在無損上下線功能支持的范圍之內。建議您根據這些基礎設施、框架提供的優雅下線特性來定制相應的解決方案。

• 該應用需要開啟主動通知，但是沒有開啟。（您可以參考本文了解主動通知）

  建議您開啟主動通知后再次觀測下線曲線是否符合預期。

• 該應用使用的框架版本不在支持的范圍之內，服務治理無損上下線支持的框架可以參考：微服務治理支持的Java框架。

  如果您發現應用使用的框架版本不在支持版本之中，可以考慮對應用的框架版本進行升級。