如何在MSE配置同可用区优先_微服务引擎(MSE)-阿里云帮助中心

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，对于灰度消费者而言，同可用区优先是生效的。