Release 6.16.1(SEP 16, 2022) · Nepxion/Discovery

发布日志

发布策略

提醒：版本号右边， ↑ 表示>=该版本号， ↓ 表示<=该版本号

版本	SC	SB	SCA
8.0.0 (商业版)	2021.x.x	2.7.x 2.6.x	2021.x.x.x
7.0.0 (商业版)	2020.x.x	2.5.x 2.4.1 ↑	2021.x
6.16.1	H.SR5 ↑ H G F	2.3.x 2.2.x 2.1.x 2.0.x	2.2.7.RELEASE ↑
6.12.5 ↓	H.SR5 ↑ H G F	2.3.x 2.2.x 2.1.x 2.0.x	2.2.6.RELEASE ↓ 2.1.x 2.0.x
~~5.6.0~~	G	2.1.x	2.1.x
~~4.15.0~~	F	2.0.x	2.0.x
3.33.1	E	1.5.x	1.5.x
~~2.0.x~~	D	1.x.x	1.5.x
~~1.0.x~~	C	1.x.x	1.5.x

表示维护中 | 表示不维护，但可用，强烈建议升级 | 表示不维护，不可用，已废弃

8.x.x版本（适用于2021.x.x）将继续维护
7.x.x版本（适用于2020.x.x）将继续维护
6.x.x版本（同时适用于Finchley、Greenwich和Hoxton）将继续维护
5.x.x版本（适用于Greenwich）已废弃
4.x.x版本（适用于Finchley）已废弃
3.x.x版本（适用于Edgware）不维护，但可用，强烈建议升级
2.x.x版本（适用于Dalston）已废弃
1.x.x版本（适用于Camden）已废弃

版本变更

默认集成Spring Cloud Alibaba版本为2.2.9.RELEASE
默认集成SkyWalking版本为8.12.0

另：

8.0.0商业版版本变更

默认集成Spring Cloud Alibaba版本为2021.0.4
默认升级集成Spring Cloud版本为2021.0.4

功能迭代

多活单元化

多活单元化概念

异地多活，主要是为了提升系统的容灾能力，比如，单机房遭遇地震、火灾、网络故障、断电等不可抗因素，都有可能造成整个机房瘫痪

基于向外提供数据和服务实时性和连续性的要求，需要在不同城市建立独立的数据中心，并搭建配套的网关和服务集群，消息队列，数据库等，当某个城市的机房崩溃，则通过SLB等最高层的设施执行流量调拨，从一个城市切换到另一个城市，让外界感知服务永远处于有效状态

多活单元化梳理

要进行多活建设，需要梳理企业内的服务

下文提到的，单元和区域，一般来说等同于机房概念

服务所属的区域从多活的角度，一般分为两种类型

① 中心单元

部署在核心机房，机器性能，承载能力高
中心单元部署全局服务、核心服务和共享服务
中心单元是普通单元的特殊形式，限制一个

② 普通单元

部署在一般机房，机器性能，承载能力一般
中心单元部署核心服务和共享服务
普通单元可以水平扩容为N个

服务从多活的角度，一般分为三种类型

① 全局服务

具有数据强一致性和实时性高要求
多活单元化拆分存在很大的难度
数据在中心单元写，中心单元读

② 核心服务

多活单元化分片，按地域划分，就近原则访问
数据在各自单元写，各自单元读

③ 共享服务

全局服务的代理服务，读服务
共享服务和全局服务实现读写分离。数据由核心服务调用全局服务在中心单元写，共享服务向外暴露读接口，在各自单元被核心服务读

多活单元化方案

① 部署方案

中心单元区域只有一个，部署在机器性能，网络性能较好的机房内
普通单元区域可以有很多个，进行对等镜像部署方式，部署在机器性能，网络性能一般的机房内

最古典的多活方案，不建议出现全局服务的单机房部署。受制于历史包袱或者企业现状，全局服务无法进行多活单元化拆分，或者对数据一致性和实时性要求很高，故而出现全局服务的单机房架构。所以，需要保持中心单元机房内全局服务集群的高可用性是非常必要的

② 注册中心方案

所有API网关、全局服务、核心服务和共享服务都注册到同一个物理空间下的注册中心
不同物理空间下的注册中心需要双向同步

③ 配置中心方案

一个单元区域配置一个配置中心，不同的单元区域的配置中心上是隔离的。每增/删/改一条配置数据，需要在不同单元区域的配置中心上重复操作一遍
一个单元区域配置一个配置中心，不同的配置中心跟注册中心一样双向同步。在遇到重复数据时候，同步的原则是时间更新的数据覆盖时间更老的数据
所有API网关、全局服务、核心服务和共享服务都订阅同一个物理空间下的配置中心

④ 数据库方案

中心单元区域拥有全局数据库，它具有强一致性，被全局服务写，被所有单元区域的共享服务读
每个单元区域都拥有有各自的分片数据库，它们之间双向同步，每个分片数据库被各自单元区域的核心服务读/写

⑤ 网关方案

API网关属于单元区域的范畴，一个单元区域需要部署一个API网关的集群
API网关具有跨区域路由的功能

⑥ 调用方案

不同单元区域之间服务调用是隔离的，两个单元区域的服务不能跨区域调用
普通单元区域的服务调用全局服务，通过路由（故障）转移方式访问中心单元区域
全局服务有回溯功能，例如，当调用链为核心服务 -> 全局服务 -> 核心服务，全局服务再调回核心服务的时候，仍旧选择发起调用的那个单元区域，即不会出现类似中心单元核心服务 -> 中心单元全局服务 -> 普通单元核心服务的情况，原则是从哪里来回哪里去

一般来说，回溯功能很少被用到，从多活架构上，全局服务是调用链最后一个环节，全局服务基本上不会出现在调用链头部和中部（不存在全局服务再去调用其它服务的情形）。本方案，为了考虑特殊性，支持回溯功能

⑦ 分流方案

前置的SLB或者下级Nginx根据请求IP进行二级域名分发
API网关配置多活切换的路由配置，映射出区域，并赋值给Headern-d-region全链路传递，实现区域隔离路由

⑧ 切换方案

配置多活切换的路由配置

域名前缀映射区域策略
用户Id范围映射区域策略

多活单元化用法

服务配置操作

① 多活服务（主要是核心服务和共享服务），执行如下操作

开启故障转移开关

# 启动和关闭区域故障转移。缺失则默认为false
spring.application.strategy.region.failover.enabled=true

标记元数据为多活属性，两种方式如下任选一个

spring.cloud.discovery.metadata.active=true
-Dmetadata.active=true

② 全局服务如果在调用链中部（例如，全局服务回溯调用核心服务），全局服务执行如下操作

开启故障转移开关

# 启动和关闭区域故障转移。缺失则默认为false
spring.application.strategy.region.failover.enabled=true

③ 全局服务如果在调用链头部（例如，API网关直接调用全局服务），API网关执行如下操作

开启故障转移开关

# 启动和关闭区域故障转移。缺失则默认为false
spring.application.strategy.region.failover.enabled=true

流量分拨和多活切换的操作

① 域名前缀映射区域策略

API网关过滤器实现域名前缀和区域映射逻辑

public class MyGatewayStrategyRouteFilter extends DefaultGatewayStrategyRouteFilter {
    @Autowired
    private GatewayStrategyContextHolder gatewayStrategyContextHolder;

    @Value("${active.strategy.domain}")
    private String activeStrategyDomain;

    @Override
    public String getRouteRegion() {
        String host = gatewayStrategyContextHolder.getURI().getHost();
        String region = host.substring(0, host.indexOf("."));        
        Map<String, String> map = JsonUtil.fromJson(activeStrategyDomain, Map.class);

        return map.get("active.unit." + region);
    }
}

通过配置中心添加如下Json格式的配置

active.strategy.domain={"active.unit.shanghai":"shanghai", "active.unit.hangzhou":"hangzhou"}

表示域名前缀为shanghai的请求路由到shanghai单元区域，域名前缀为hangzhou的请求路由到hangzhou单元区域。如果hangzhou单元区域遭遇故障，转移到shanghai，修改"active.unit.hangzhou":"shanghai"，完成多活切换

② 用户Id范围映射区域策略

API网关过滤器实现用户ID范围和区域映射逻辑（伪代码）

public class MyGatewayStrategyRouteFilter extends DefaultGatewayStrategyRouteFilter {
    @Autowired
    private GatewayStrategyContextHolder gatewayStrategyContextHolder;

    @Value("${active.strategy.userId}")
    private String activeStrategyUserId;

    @Override
    public String getRouteRegion() {
        String userId = strategyContextHolder.getHeader("userId");

        Map<String, String> map = JsonUtil.fromJson(activeStrategyUserId, Map.class);
        String region = 轮询map，搜索userId是否落在map的value配置用户Id范围区间里

        return region;
    }
}

通过配置中心添加如下Json格式的配置

active.strategy.userId={"active.unit.shanghai":"0~1999", "active.unit.hangzhou":"2000~9999"}

表示用户Id范围为0~1999的请求路由到shanghai单元区域，用户Id范围为2000~9999的请求路由到hangzhou单元区域。如果hangzhou单元区域遭遇故障，转移到shanghai，修改"active.unit.shanghai":"0~9999"，并删除"active.unit.hangzhou":"2000~9999"，完成多活切换

③ 自定义映射区域策略

使用者只需要继承实现DefaultGatewayStrategyRouteFilter的public String getRouteRegion()方法，并结合配置中心的配置，可扩展出更多映射区域的策略

多活单元化场景下实施蓝绿灰度发布

例如，要对核心区的服务实施蓝绿灰度发布，假设核心区有A和B两个服务，分别有1.0和1.1两个版本，则可以通过如下规则策略实施

<?xml version="1.0" encoding="UTF-8"?>
<rule> 
    <strategy-release>
        <conditions type="blue-green">
            <!-- 蓝路由，条件expression驱动 -->
            <condition id="blue-condition" expression="#H['a'] == '1'" version-id="blue-route"/>
            <!-- 绿路由，条件expression驱动 -->
            <condition id="green-condition" expression="#H['a'] == '2'" version-id="green-route"/>
            <!-- 兜底路由，无条件expression驱动 -->
            <condition id="basic-condition" version-id="basic-route"/>
        </conditions>

        <routes>
            <route id="blue-route" type="version">{"core-service-a":"1.1", "core-service-b":"1.1"}</route>    
            <route id="green-route" type="version">{"core-service-a":"1.0", "core-service-b":"1.0"}</route>
            <route id="basic-route" type="version">{"core-service-a":"1.0", "core-b":"1.0"}</route>
        </routes>
    </strategy-release>
</rule>

一般来说，一个单元区域在执行蓝绿灰度发布的时候，另外一个单元区域不会同步执行，所以两个单元区域在某一个时刻，服务镜像是不对等的（例如，中心单元区域的核心服务里有核心区有A和B两个服务，分别有1.0和1.1两个版本，而普通单元区域里的核心服务，只有A和B服务的1.0版本，没有1.1版本）

基于上述情况，当实施单元区域切换的时候，需要清掉蓝绿灰度规则策略

变更运维平台进行无损下线API接口

旧版本接口允许group缺省，虽然优雅方便，但是缺省的两个参数，需要到注册中心做关联查询，当服务数和实例数很大的情况下，频繁的关联查询会让注册中心承受很大的压力。所以，只能牺牲一些便利来换取性能

新版本接口必须手工填写group和gatewayId，同时支持全局组订阅和局部网关订阅两种方式

String addBlacklist(String serviceId, String host, int port);

boolean deleteBlacklist(String serviceId, String serviceUUId);

变更为

String addBlacklist(String group, String serviceId, String host, int port);

boolean deleteBlacklist(String group, String serviceId, String serviceUUId);

String addBlacklist(String group, String gatewayId, String serviceId, String host, int port);

boolean deleteBlacklist(String group, String gatewayId, String serviceId, String serviceUUId);

新增n-d-group的Header作为提供端组隔离的方式

为统一起见，新增n-d-group的Header作为提供端组隔离的方式，同时也兼容支持老版本n-d-service-group的Header

新增规则策略配置和业务配置在配置中心的合并和分离

Nepxion Discovery框架支持策略配置和业务配置在配置中心合并，但支持Nacos和Apollo两种配置中心的分离

① Nacos配置中心

同一个Nacos服务器，同一个Namespace的配置方式

spring.cloud.nacos.config.server-addr=192.168.0.1:8848
# spring.cloud.nacos.config.namespace=application

表示，业务配置和规则策略配置在同一个Nacos服务器同一个Namespace下。如果Namespace为application，可以缺省不配置

同一个Nacos服务器，不同Namespace的配置方式

spring.cloud.nacos.config.server-addr=192.168.0.1:8848
# spring.cloud.nacos.config.namespace=application

nacos.namespace=nepxion

表示，同一个Nacos服务器，业务配置在application的Namespace下，规则策略配置在nepxion的Namespace下。如果Namespace为application，可以缺省不配置

不同Nacos服务器的配置方式

spring.cloud.nacos.config.server-addr=192.168.0.1:8848

nacos.server-addr=localhost:192.168.0.2:8848

表示，业务配置在192.168.0.1:8848的Nacos服务器下，规则策略配置在192.168.0.2:8848的Nacos服务器下。如果Namespace为application，可以缺省不配置

逻辑解释
在Nepxion Discovery层面上看，先去寻址nacos为前缀的配置，如果找不到，再去寻址spring.cloud.nacos.config为前缀的配置，如果都找不到，取缺省值application。所以，在取值方式上，nacos.x.y.z优先于spring.cloud.nacos.config.x.y.z

② Apollo配置中心

同一个Apollo服务器，同一个Namespace的配置方式

app.id=discovery
apollo.meta=http://192.168.0.1:8080
# apollo.bootstrap.namespaces=application

表示，业务配置和规则策略配置在同一个Apollo服务器同一个Namespace下。如果Namespace为application，可以缺省不配置

同一个Apollo服务器，不同Namespace的配置方式

app.id=discovery
apollo.meta=http://192.168.0.1:8080
# apollo.bootstrap.namespaces=application

apollo.namespace=nepxion

表示，同一个Apollo服务器，业务配置在application的Namespace下，规则策略配置在nepxion的Namespace下。如果Namespace为application，可以缺省不配置

逻辑解释
在Nepxion Discovery层面上看，先去寻址apollo.namespace配置，如果找不到，再去寻址apollo.bootstrap.namespaces配置，如果都找不到，取缺省值application。所以，在取值方式上，apollo.namespace优先于apollo.bootstrap.namespaces

重构优化

Nacos内置属性随着Nacos版本升级而不断增加中，6.16.0之前的版本是通过写死Nacos内置属性列表方式，现在通过PropertiesUtil.enrichProperties方式动态读取配置，不需要再关注Nacos内置属性的变化
历史包袱：为支持动态读取配置，配置前缀nacos.plugin.统一改成nacos.，例如，nacos.plugin.namespace替换成nacos.namespace
历史包袱：为支持动态读取配置，配置前缀apollo.plugin.统一改成apllo.，例如，apollo.plugin.namespace替换成apollo.namespace
历史包袱：去掉不再支持的规则策略XML节点<strategy-customization>，代替为<strategy-release>
历史包袱：优化XML解析中的静态变量

缺陷修复

增加env和zone的缺省值default。当该两项未配置的时候，会自动以缺省值default写入到注册中心的元数据Metadata
增加discovery-common-apollo模块的遗漏项additional-spring-configuration-metadata.json

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

6.16.1(SEP 16, 2022)