新版本预览

本次发布的 Spring Cloud Alibaba 2.2.9.RELEASE 和 2021.0.4.0 两个新版本，分别基于社区 2.2.x 和 2021.x 两个主干分支进行的构建发布，其中 2.2.9.RELEASE 版本通过首次给 Spring Cloud 生态带来了阿里巴巴内部使用多年的异地多活能力，对规模较大的中大型企业构建高可用应用提供了参考解决方案。另外，我们在 2.2.9.RELEASE 和 2021.0.4.0 版本中提供了服务的 IPv6 地址注册与调用能力，可帮助应用实现 IPv4 向 IPv6 的迁移。详细的新版本预览内容如下：

2.2.9.RELEASE

是在 Spring Cloud Hoxton.SR12、Spring Cloud 2.3.12.RELEASE 的基础上，基于 Ribbon 负载均衡实现了针对Spring Cloud 应用的异地多活能力。另外，对生态中原有的包括注册配置中心、分布式消息等在内的众多组件进行了升级，属于一个重大特性发布的新版本。本次发布的 Spring Cloud Alibaba 2.2.9.RELEASE 版本对以下组件版本进行了升级：

• Seata：升级到了1.5.2版本[1]，该版本支持 xid 一致性负载均衡能力，以及修复了一些之前版本所暴露的安全风险问题。
• RocketMQ：升级到了4.9.4版本[2]，该版本提供了轻量级消息队列和为延迟消息提供异步发送功能等在内的诸多特性。
• Sentinel：升级到了 1.8.5 版本[3]，该版本提供了自动提取参数当使用 ParamFlowSlot 时，以及修复了部分 DashBoard 的bugs。

除了组件升级，另外也修复了一些之前版本所存在的问题，进一步提升了Spring Cloud Alibaba 使用的稳定性与健壮性。更多内容可参见该版本相关发版公告[4]。

2021.0.4.0

是在 Spring Cloud 2021.0.4、Spring Cloud 2.6.11的基础上对其中包括注册配置中心、分布式消息等在内的众多组件进行了升级，属于一个组件升级与 Bug 修改的版本。本次发布的 Spring Cloud Alibaba 2021.0.4.0 版本对以下组件版本进行了升级：

• Seata：升级到了1.5.2版本[1]，该版本支持 xid 一致性负载均衡能力，以及修复了一些之前版本所暴露的安全风险问题。
• RocketMQ：升级到了4.9.4版本[2]，该版本提供了轻量级消息队列和为延迟消息提供异步发送功能等在内的诸多特性。
• Sentinel：升级到了 1.8.5 版本[3]，该版本提供了自动提取参数当使用 ParamFlowSlot 时，以及修复了部分 DashBoard 的bugs。
• Nacos：升级Nacos客户端到2.0.4版本[5]，该版本新增了包括认证插件和配置加密插件等相关能力。
• Spring Boot: 适配 Spring Boot 2.6.11[6]，该版本修复了之前堆栈溢出等情况 BasicJsonParser 工作无法及时停止等问题。
• Spring Cloud: 适配Spring Cloud 2021.0.4[7]，该版本主要在 OpenFeign中允许覆盖二进制内容类型列表，以及 Spring Cloud Gateway 中将原生 JSON 添加到 gRPC 过滤器里。

除了组件升级，另外也修复了一些之前版本所存在的问题，进一步提升了Spring Cloud Alibaba 使用的稳定性与健壮性。更多内容可参见该版本相关发版公告[8]。

Spring Cloud Alibaba 版本的命名规则以及与 Spring Cloud 和 Spring Boot 当前各版本对应关系可参见官网Wiki版本说明[9]。

新特性介绍

异地多活解决方案

方案背景

随着社会生产力的进步，我们的业务系统越来越复杂。这样的系统，根据墨菲定律，只要规模足够大，或者运行时间足够长，就会遇上各种各样的故障，一般的故障类型如下图所示。

面对这些各种故障，我们不能坐以待毙，需要各种手段来缓解。这些手段里面应对最大规模故障（机房级故障）的的手段就是容灾架构。

容灾架构有许多种，需要从RPO、RTO、成本、性能等多方面因素来进行权衡。

如果你的系统需要分钟级的RTO，则只能选热备和多活。多活架构的多站点同时服务，资源利用率更高、关键时候更敢切、潜在容量更大，是一个大型稳定系统的最佳选择。

多活架构按照地域范围，分为异地多活和同城多活，如果需要应对城市级灾难，则必选异地多活，否则优先选择同城多活。

在这个背景下，阿里巴巴于2021年12月，开源了AppActive。AppActive 建立在 阿里巴巴 使用 AHAS-MSHA 系统大规模运行生产应用系统的8年经验之上，且结合了来自阿里云商业化服务的外部多家客户和社区的最佳实践，是助力业务系统实现异地多活架构的利器。

异地多活方案

异地多活的思想类比于日常中的鸡蛋不要放在一个篮子里面，通过对业务应用进行单元化拆分部署，使得一个单元的故障影响面限定在特定单元内。其中，中心单元由于需要承载更多的业务属性，一般需要在CPU和内存等硬件、电力、网络带宽等硬资源更多或者说弹性更好的机房。

在此基础上，以基于冗余的隔离为核心理念，对数据进行复制和分片，通过全链路【包括网关、服务（RPC和MQ）、数据】的流量分片路由，让特定分片的数据到特定单元读写。

在日常态，不同分片的流量由不同的单元进行处理（读写）。当发生故障时，通过全链路流量控制，将流量从故障单元切走

由上图可以看到，要实现完整的异地活动解决方案，需要对从流量的入口处开始对应用进行改造，依次涉及网关、业务应用、注册中心、消息系统以及数据库等几大部分的改造。

网关和业务应用需要需要做单元化拆分与部署，分别需要拥有能路由本单元服务，对异常流量进行纠错等能力。注册中心和消息系统以及数据库本身另外需要通过数据同步等方式实现高可用，不能当某单元出现故障时，出现数据丢失而造成系统切流后运行异常。比如针对注册中心，可通过双注册双订阅或者服务同步组件实现每个注册中心都拥有整个系统完整的微服务实例列表信息。消息系统和数据库通过实时数据复制的方式，保证各单元内的相关模块都拥有系统完整数据。以保证系统切流时的可用性。

Spring Cloud Alibaba 中的 AppActive 模块主要是针对业务应用进行异地活动改造而设计，当引入相关模块按照使用文档对业务系统进行适当配置改造以后，系统内的微服务就具有了单元内流量路由以及流量纠错等方面能力。然后再配置 AppActive 社区现有的部分或未来将提供的包括网关、注册中心、消息系统和数据库的异地活动解决方案，就可以方便地构造完整的微服务异地多活系统。

最佳实践

前置条件

本节介绍一个电商系统应用利用 Spring Cloud Alibaba相关能力改造为多活架构的过程。

该系统由3个部分组成，包含三个微服务：

• frontend，一个传统的MVC服务。负责和用户交互，基于Spring Cloud Alibaba实现。
• product，产品服务。存储商品信息，包含商品详情、库存缓存等，基于Spring Cloud Alibaba实现，依托MySQL存储。
• storage，库存服务。存储产品的实时库存，支持下单、发货等动作，基于Spring Cloud Alibaba实现，依托MySQL存储。

改造过程

前期准备

1. 容灾选址。有一些基本条件需要满足：不在同一火山地震带（避免多机房同时遇灾）、不在同一个电网（避免多机房同时断电）等等，在此基础上，考虑带宽、时延、安全合规（主要是全球场景需要考虑）等因素
2. 网络打通。多机房需要做网络打通，无论是自建专线、VPN，还是利用现有的云产品都可
3. 业务梳理。选择简单业务进行试点，最终目的是重要业务（而非全量业务）及其强依赖业务具备容灾能力。针对选出来的业务进行分类，哪些是中心服务，哪些是单元服务，哪些是普通服务

中间件和数据库管理

1. 注册中心。在多单元部署注册中心（如Nacos），并进行服务同步(如Nacos-Sync)配置
2. 数据库。在多单元部署数据库，并配置数据同步（如otter）
3. 配置中心。在多单元部署配置中心（Nacos），作为多活命令通道

业务应用改造与部署

1. Spring Cloud 应用利用 Spring Cloud Alibaba 相关 SDK，将应用改造为多活形态。具体改造过程请参考项目中 AppActive-example 中的 readme-zh.md 文档。
2. 利用多活命令通道，下发多活规则。
3. 应用部署

1. 若资源充足，则在新环境中全量改造后的系统，并逐渐引流
2. 若资源紧缺，没有新环境，则在老环境中优先部署Provider，后部署Consumer，从底层应用到上层应用逐渐替换老的应用

结果验证

在正式进行结果验证之前，在业务系统应用层改造过程中，涉及以下核心概念。在基于 Spring Cloud Alibaba x AppActive 做应用多活方案中，可根据应用属性将应用分为全局、核心和普通服务 3 类，其又可归属到中心单元和一般单元 2 类单元中，单元一般用来指代机房。

3 类服务：

• 全局服务：强一致性的服务（例如库存、金额等），无法做异地多活单元化拆分，其需要在中心单元进行服务读写。
• 核心服务：做单元化拆分的业务应用，根据预设的多活规则，根据请求信息在特定单元进行读写的业务，核心业务的拆分是异地多活系统建设中的核心。
• 普通服务：属于系统非核心链路上的业务，对数据一致性要求较低的应用，一般出于成本考虑不做单元化拆分。

2 类单元：

• 中心单元：中心单元，也可称为中心机房，可承载全局、核心和普通服务 3 类，其一般在机房硬件配置上较一般单元高。
• 一般单元：其他非中心单元的单元，用来承载非全局服务以外的其他服务，也可称为一般机房。

按照项目中 AppActive-example 中的 readme-zh.md 文档完成应用部署后，接下来演示一下，核心服务根据特定请求信息在特定单元进行读写的业务的过程。我们配置如下规则，其表示，用户Id为 0 ~ 1999 的请求将发送给下游提供者中的一般（Unit）单元中的核心应用实例，用户Id为 2000 ~ 9999 的请求将发送给下游提供者中的中心（Center）单元全局应用实例。

{
  "itemType": "UnitRuleItem",
  "items": [
    {
      "name": "unit",
      "conditions": [
        {
          "@userIdBetween": [
            "0~1999"
          ]
        }
      ]
    },
    {
      "name": "center",
      "conditions": [
        {
          "@userIdBetween": [
            "2000~9999"
          ]
        }
      ]
    }
  ]
}

如下图，模拟一个用户Id为 1999 的请求，可见请求通过 frontend 发送到了下游中 product 的一般（Unit）单元中的核心应用实例。

如下图，模拟一个用户Id为 2000 的请求，可见请求通过 frontend 发送到了下游中 product 的中心（Center）单元中的全局应用实例。

更多详细的演示过程请参考项目中 appactive-example 中的 readme-zh.md 文档进行体验。

异地多活方案未来规划

AppActive作为一个应用多活解决方案，当前支持按照多活规则的流量调度功能，还支持切流、数据保护等功能。未来，为了给用户提供一站式的应用多活容灾改造体验，AppActive 计划集成各类同步组件，包括消息同步、数据库同步、注册中心同步等，并提供基础的控制台功能，这样用户就可以避免选型，直接利用 AppActive 完成应用多活的一站式改造，敬请期待！

社区动态

新 Committer 介绍

Spring Cloud Alibaba 社区近几个月涌现了一些积极参与社区维护迭代的外部贡献者，在此，向他们表示感谢！另外，对于其中一直参与社区活动，做出重要贡献 feature 的程兴源同学，社区按照新 Committer 提名与投票制度在近期双周会中正式提名其为社区 Committer，在此也向其表示祝贺。欢迎更多外部同学关注 Spring Cloud Alibaba 开源社区和贡献开源社区。

Spring Cloud Alibaba社区最新的维护团队由 5 位Steering Committee Member，9 位Committer成员组成。更多社区维护团队信息见[X]

编程之夏优秀毕业生

2022年度阿里巴巴开始于今年5月底，共有26个顶级开源项目参与，开放87个选题任务。整个活动面向在校生群体，由学生选题并提交申请、导师面试审核、参与社区任务、中期考核、结业考核 5 部分组成，更多信息可见活动官网[X]。在本次活动中，Spring Cloud Alibaba 社区共开放如下4个选题：

经过层层选拔与考核，最终社区3位同学，以优异的表现完成了社区任务通过了结业考核，在此向其表示祝贺！

社区未来规划

在未来，如果说 Spring Cloud Alibaba 过去的第一阶段工作是丰富 Spring Cloud 生态，让广大外部用户能够轻松地拥抱微服务。接下来，第二阶段，Spring Cloud Alibaba会通过自身的努力让外部的用户用好微服务，构建微服务治理和业务高可用相关能力，满足用户在微服务使用过程中的这些更高层次的诉求。具体的话比如通过全面支持RocketMQ 5.0和Sentinel 2.0等带来更丰富的中间件使用体验，投入力量构建Spring Cloud生态的微服务治理（标签路由，服务鉴权以及全链路灰度等）和分布式任务调度等方面能力。欢迎感兴趣的同学扫描下放二维码加入社区交流群，一起参与社区未来建设。