MSE同可用性區域（Availability Zones）優先是一種負載平衡策略，其核心機制是通過動態識別服務調用端與提供方的可用性區域屬性，優先將請求分發給同一可用性區域內的服務節點。相較於傳統輪詢演算法，該策略通過減少跨區流量傳輸，可有效降低網路延遲、提升服務響應速度，同時增強系統容災能力。本文介紹如何在MSE上配置同可用性區域優先。
前提條件
已開通MSE微服務治理。具體操作，請參見開通MSE微服務治理。
已將目標應用及其消費者應用接入MSE治理中心。具體操作，請參見ACK和ACS微服務應用接入MSE治理中心（Java版）和ECS微服務應用接入MSE治理中心。
MSE 同可用性區域優先支援Dubbo服務和Spring Cloud服務，暫不支援K8s Service。
使用MSE 同可用性區域優先之前，應設定合理的安全閾值。只有同可用性區域提供者執行個體數占該應用總執行個體數超過設定閾值時，才會按照同可用性區域規則調用。
術語介紹
可用性區域：可用性區域（Availability Zones）是指在同一地區內，電源和網路互相獨立的物理地區。例如，華北2（北京）地區支援12個可用性區域，包括北京 可用性區域 A 和北京 可用性區域 B 等。同一可用性區域內執行個體之間的網路延時比跨可用性區域更小。
消費者、提供者：微服務情境下，發起調用的一方稱作服務消費者（Consumer），提供服務的一方稱作服務提供者（Provider）。更多時候，一個應用既是提供者又是消費者。
RT：請求往返時間，指從用戶端發起請求到接收服務端響應所經歷的總時間。
執行個體：等同於口語化表達中“節點”的概念。具體來說，在K8s情境下，應用工作負載下的一個Pod，就是一個應用執行個體；在ECS情境下，一台ECS上的單個應用進程，就是一個應用執行個體。
同可用性區域優先優勢
同可用性區域優先是一種微服務架構下的流量調度策略，通過負載平衡機制優先選擇與調用方處於同一可用性區域的服務提供者執行個體。在多可用性區域架構情境下，同可用性區域優先調用具備諸多優勢，包括但不限於：
跨可用性區域調用變為同可用性區域調用，整體系統RT時間長度會降低。
微服務調用會被限制在同可用性區域內執行，當單個可用性區域出現故障後，影響面會被局限在可用性區域內部。
同可用性區域優先功能不是必須使用的。但如果您希望降低系統整體的請求耗時，並且希望進一步提升系統整體的可用率，推薦您開啟該功能。
同可用性區域優先說明
MSE 微服務治理也提供了同可用性區域優先的能力。當為某個應用開啟同可用性區域優先功能時：該應用的消費者應用，在對當前應用發起調用時，會優先選擇同可用性區域的執行個體發起調用。例如，為應用P開啟了同可用性區域優先功能，當C1、C2、C3應用來調用P時，會優先選擇本可用性區域的P應用執行個體發起調用。
未開啟MSE同可用性區域優先調用，應用的調用模型如下：
開啟MSE同可用性區域優先調用，應用的調用模型如下：
MSE目前提供的同可用性區域優先功能，是只針對單個提供者應用生效的，即為某個應用開啟同可用性區域優先功能後，該應用的全體消費者在調用該應用時，會優先調用本可用性區域的執行個體。
同可用性區域安全閾值作用
使用MSE同可用性區域優先功能時，會遇到這樣的問題：某個應用開啟同可用性區域優先後，所有消費者都會往本可用性區域的提供者發起調用，那麼本可用性區域現有的提供者數目是否足夠支援整個可用性區域消費者的請求流量？換句話說，並非每個應用都是嚴格按照可用性區域打散且均勻部署的，那麼就可能存在應用在某個可用性區域部署的提供者節點數非常少，那麼該應用在這個可用性區域下的節點就無法支撐起本可用性區域消費者的流量調用。
例如有這樣一個情境，我們的應用在A、 B、C三個可用性區域的部署的執行個體數分別是3、3、1。在開啟同可用性區域優先的情況下，每個可用性區域接收的流量都是 1/3（假設每個可用性區域的消費者數目都是均衡的），但是 C 可用性區域只有1個執行個體，所以 C 可用性區域的這個執行個體就需要承受其他可用性區域執行個體 3 倍的流量，這可能會帶來穩定性風險。
這種情況下，我們就希望，對於C可用性區域的消費者來說，不要同可用性區域優先調用本可用性區域的該應用了。於是MSE同可用性區域優先提供了安全閾值的設定：應用在開啟同可用性區域優先調用的情況下，如果在某個可用性區域內部署的執行個體數佔總數比例小於安全閾值，那麼該可用性區域內消費者在調用該應用時，不會採取同可用性區域優先調用的策略，而是會回退到微服務架構預設的隨機或輪詢策略。
舉例來說，我們的應用在A、B、C 三個可用性區域部署的執行個體數分別是2、2、1（執行個體數分別佔比 40%、40%、20%），此時我們為該應用開啟同可用性區域優先，並設定安全閾值為30%，那麼C可用性區域的消費者不會同可用性區域優先調用，A和B可用性區域的消費者則正常進行同可用性區域優先調用。
配置MSE同可用性區域優先
使用條件
同可用性區域優先主要針對的是：按可用性區域打散部署的應用之間的調用。這裡的前提是，您部署資源的環境已經包含了多個可用性區域，並且應用也按照多可用性區域進行了打散部署。
如果您應用系統的部署現狀中，有應用存在嚴重的可用性區域部署不均的情況，請勿使用同可用性區域優先功能。
如果您的應用都是按照可用性區域打散部署的，推薦您使用同可用性區域優先功能。
如果您的應用不是嚴格按照可用性區域均勻部署的，也推薦您使用同可用性區域優先功能，但需要您評估並設定好安全閾值。（評估和設定方式，請參考設定安全閾值）。
如何讓應用進行可用性區域打散部署？
如果您是通過阿里雲ACK 方式對應用進行管理和部署，您應該保證您的節點池網路設定中，包含了多個可用性區域的虛擬交換器，這樣可以保證您的工作負載能夠部署在不同的可用性區域的節點中。另外，建議應用按照多可用性區域打散進行部署，您可以在工作負載中加入拓撲分布約束配置，位於
spec > template > spec中，具體工作負載按可用性區域打散配置請參見叢集高可用架構推薦配置。topologySpreadConstraints: - maxSkew: 1 topologyKey: "topology.kubernetes.io/zone" whenUnsatisfiable: ScheduleAnyway如果您的應用部署在阿里雲 ECS 上，您需要在建立執行個體時，為ECS 執行個體選擇不同可用性區域的虛擬交換器。然後在部署應用時，手工將應用的不同執行個體打散部署到這些ECS 執行個體上。
使用方法
登入MSE治理中心控制台，並在頂部功能表列選擇地區。
在左側導覽列，選擇，然後單擊目標應用的資源量卡片。
在側導覽列，單擊流量治理，然後選擇上方同可用区优先頁簽。
單擊配置資訊旁邊的設定，將開啟狀態改為開啟，輸入安全閾值，然後單擊確定。
之後，該應用的消費者在對該應用發起調用時，會自動優先選擇同可用性區域內的執行個體。注意，單擊確定後無需重啟任何應用即可生效。
設定安全閾值
安全閾值的作用：當前應用在單個可用性區域內應用提供者執行個體佔總數比例小於該值時，則該可用性區域內的消費者調用此應用時，不會進行同可用性區域優先調用，而是回退成微服務架構預設的隨機或輪詢調用策略。詳情請參見MSE同可用性區域優先安全閾值介紹。
安全閾值應該根據業務應用部署現狀合理設定，核心的落腳點應該是保護執行個體數較少可用性區域的執行個體不被流量擊垮。可以參考以下兩個情境進行設定：
情境一（常見）：應用按照可用性區域均勻部署，此時不存在某個可用性區域執行個體數較少的情況，那麼可以直接將安全閾值建議設定為小於可用性區域數的倒數。例如：應用在A、B、C 三個可用性區域分別部署 2、2、2 個執行個體，該應用在每個可用性區域實際的執行個體數佔比為33.33%，此時安全閾值可以設定成33%。
情境二：應用未按照可用性區域均勻部署，此時安全閾值的設定需要考慮到較少可用性區域實際的執行個體數。例如：應用在A、B、C 三個可用性區域分別部署 2、2、1 個執行個體，由於 C 可用性區域執行個體數較少，希望C 可用性區域不按照同可用性區域優先調用。此時可以設定安全閾值為30%，A 和 B 可用的執行個體數佔比都是40%，可以實現同可用性區域優先；C 可用性區域執行個體數佔比為20%，則退化為預設的隨機或輪詢調用策略。
安全閾值預設值是20%，是一個非常小的數值，更多用於測試環境驗證和體驗使用。建議您根據當前應用按可用性區域部署的情況來設定一個合適的數值。
注意事項
可用性區域內提供者數目必須嚴格大於安全閾值時，同可用性區域優先才會生效，等於安全閾值情況下同可用性區域優先是不生效的。
比較理想的情況下，提供者、消費者應用應該滿足均勻部署，不應該存在應用在某些可用性區域執行個體數非常高的情況，否則開啟同可用性區域優先後可能會導致流量負載嚴重不均的問題。
在進行服務發布時（尤其是基於K8s 變換的情境下），短時間內各個可用性區域的執行個體數可能會發生變化。此時某些可用性區域可能會出現執行個體數不滿足安全閾值的情況，進而可能會出現短時間內跨可用性區域調用的情況。
同可用性區域優先只應該用於流量層面的隔離，不應該用於業務層面的隔離，使用時必須保證可以容忍跨可用性區域調用的情況出現。
安全閾值在生效時，會計算同可用性區域內可用執行個體佔總結點數的佔比是否符合安全閾值。這裡計算可用執行個體數、總執行個體數時，統計的是已經經過全鏈路灰階邏輯篩選後的執行個體。（大多數情況下，業務系統只會在業務發版時使用全鏈路灰階，可以忽略該事項；如果您的系統將全鏈路灰階用於常態化的路由篩選，即非發版時期也會使用時，則需要注意該事項）
例如，某個應用在 A、B、C 三個可用性區域部署了 2、2、1 個節點，其中 A、B 可用性區域的 2 個節點中，都包含了一個灰階節點。此時，對於 A 可用性區域的正式版本消費者應用來說，A、B、C 三個可用性區域的節點數實際上是 1、1、1，如果安全閾值設定為 35%（小於 40%），此時對正式版本消費者而言，A、B 可用性區域的同可用性區域優先不生效的。對於A 可用性區域的灰階版本消費者來說， A、B、C 三個可用性區域的節點數實際上是 1、1、0，對於灰階消費者而言，同可用性區域優先是生效的。
可用性區域視角流量觀測
可用性區域節點和流量分布情況
同可用性區域優先提供了一定的觀測能力，接入MSE 服務治理後，您可以在同可用性區域優先頁簽下，看到當前應用的執行個體部署的分布情況、以及各可用性區域流量承載情況：
若應用本身未開啟同可用性區域優先功能，您也可以看到上述內容。
如果您是專業版使用者，或您的命名空間是專業版命名空間，則無法看到這些內容。請按照如下方式進行升級：
專業版命名空間升級企業版命名空間，詳情請參見升級微服務命名空間至企業版。
需要重點關注的內容
在同可用性區域優先的觀測介面中，您可以在整體視角這一欄，看到該應用在每個可用性區域部署的執行個體數。如果有應用存在嚴重的可用性區域部署不均的情況，會在圖中體現出來，推薦您的應用按照可用性區域打散部署，以提高系統整體的可用性。
另外，當您的應用已經開啟同可用性區域優先，您應該關注是否存在可用性區域的流量過高或過低，當前各可用性區域流量承接情況和對應可用性區域內的部署的節點數是否匹配。比如有可用性區域節點數很多，但是承接的流量很少，或者有可用性區域節點數很少，但是承接的流量很多，則需要考慮調整安全閾值，避免因為流量分配不均導致的穩定性風險。
同可用性區域優先降低系統RT時間
未開啟同可用性區域優先的情況下，微服務調用會採用預設的隨機或者輪詢策略，這會導致應用有許多跨可用性區域的服務調用。在下圖樣本中，該應用未開啟同可用性區域優先功能，可以觀測到最近5 分鐘的總體平均RT是7.88 ms。
當我們為整條鏈路上的應用都開啟同可用性區域優先功能後，可以觀測到，該應用整體的平均RT時間變為了6.85ms。
