Skip to content

Releases: Nepxion/Discovery

6.16.2(SEP 20, 2022)

20 Sep 14:40
@HaojunRen HaojunRen
6.16.2
151eb35
Compare
Choose a tag to compare
6.16.2(SEP 20, 2022)

发布日志

发布策略

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

版本 状态 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.2 H.SR5 ↑
H
G
F		 2.3.x
2.2.x
2.1.x
2.0.x		 2.2.7.RELEASE ↑
6.12.6 ↓ 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.2 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

功能迭代

新增运维平台进行无损下线API接口

除了IP地址和端口外，增加直接添加serviceUUId的接口

该两个接口不仅可以支持单个UUId，也可以支持UUId的通配。例如：

① A服务有两个实例，实例1的UUId为20220920-113301-033-4289-533-056，实例2的UUId为20220920-113259-190-5762-550-884，代表它们同一天2022年09月20日上线

② 通过20220920*通配符的方式，表示屏蔽2022年09月20日上线的指定服务的所有实例，如果希望更精确，20220920-11*，表示屏蔽2022年09月20日11点上线的指定服务的所有实例

String addBlacklist(String group, String serviceId, String serviceUUId);

String addBlacklist(String group, String gatewayId, String serviceId, String serviceUUId);

新增UUId和AppId作为路由侦测的属性

gateway 
-> [ID=discovery-guide-service-a][UID=20220920-113259-190-5762-550-884][AID=11798][T=service][P=Nacos][H=192.168.31.237:3002][V=1.1][R=qa][E=common][Z=zone2][G=discovery-guide-group][A=true][TID=6f6addfd51494ff6][SID=403c9410afcfae78] 
-> [ID=discovery-guide-service-b][UID=20220920-113300-733-9197-181-332][AID=11799][T=service][P=Nacos][H=192.168.31.237:4002][V=1.1][R=dev][E=common][Z=zone2][G=discovery-guide-group][A=false][TID=6f6addfd51494ff6][SID=517d61bdbb2013b1]

AppId是Apollo配置中心独有的，如果使用的不是Apollo配置中心，将不会显示这个属性

重构优化

无

缺陷修复

无

相关发布

DiscoveryAgent发布

无

DiscoveryDesktop发布

无

相关下载

DiscoveryAgent下载

访问https://github.com/Nepxion/DiscoveryAgent/releases获取最新版本

DiscoveryDesktop下载

访问https://github.com/Nepxion/DiscoveryUI/releases获取最新版本

Assets 2
Loading

3.33.2(SEP 20, 2022)

20 Sep 14:28
@HaojunRen HaojunRen
3.33.2
bd565c1
Compare
Choose a tag to compare
3.33.2(SEP 20, 2022)

见 Nepxion Discovery 6.16.2发布

Assets 2
Loading

6.16.1(SEP 16, 2022)

16 Sep 11:45
@HaojunRen HaojunRen
6.16.1
f1ac79c
Compare
Choose a tag to compare
6.16.1(SEP 16, 2022)

发布日志

发布策略

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

版本 状态 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为前缀的配置，如果找不到，再去寻址`spr...
Read more
Assets 2
Loading

3.33.1(SEP 16, 2022)

16 Sep 11:44
@HaojunRen HaojunRen
3.33.1
ae1c3ef
Compare
Choose a tag to compare
3.33.1(SEP 16, 2022)

见 Nepxion Discovery 6.16.1发布

Assets 2
Loading

6.15.0(SEP 5, 2022)

05 Sep 04:21
@HaojunRen HaojunRen
6.15.0
109958b
Compare
Choose a tag to compare
6.15.0(SEP 5, 2022)

发布日志

发布策略

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

版本 状态 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.15.0 H.SR5 ↑
H
G
F		 2.3.x
2.2.x
2.1.x
2.0.x		 2.2.7.RELEASE ↑
6.12.3 ↓ 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.32.0 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）已废弃

版本变更

  • 默认集成SkyWalking版本为8.11.0
  • 默认集成OpenTelemetry版本为1.17.0

另：

7.0.0商业版版本变更

  • 默认升级集成Spring Cloud版本为2020.0.6

8.0.0商业版版本变更

  • 默认升级集成Spring Boot版本为2.6.11

功能迭代

新增全链路故障转移

故障转移，即在实施蓝绿灰度发布或者路由时候，消费端调用提供端，无法在提供端找到相应条件的服务实例，转移到指定的服务实例。支持版本、区域、环境、可用区、IP地址和端口五个维度的故障转移

五大维度的故障转移逻辑是可以并行叠加的，有两种实施方式：

  • 通过在配置中心修改添加如下规则
<?xml version="1.0" encoding="UTF-8"?>
<rule>
    <strategy-failover>
        <!-- 版本偏好，非蓝绿灰度发布场景下，路由到指定版本的实例 -->
        <version-prefer>{"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.0"}</version-prefer>
        <!-- 版本故障转移，无法找到相应版本的服务实例，路由到指定版本的实例 -->
        <version-failover>{"discovery-guide-service-a":"1.1", "discovery-guide-service-b":"1.1"}</version-failover>
        <!-- 区域调试转移，跨区调试路由到指定区域的实例 -->
        <region-transfer>qa</region-transfer>
        <!-- 区域故障转移，无法找到相应区域的服务实例，路由到指定区域的实例 -->
        <region-failover>dev</region-failover>
        <!-- 环境故障转移，无法找到相应环境的服务实例，路由到指定环境的实例 -->
        <env-failover>common</env-failover>
        <!-- 可用区故障转移，无法找到相应可用区的服务实例，路由到指定可用区的实例 -->
        <zone-failover>zone1</zone-failover>
        <!-- IP地址和端口故障转移，无法找到相应IP地址和端口的服务实例，路由到指定IP地址和端口的实例 -->
        <address-failover>*1</address-failover>
    </strategy-failover>
</rule>
  • 通过如下Header传递
n-d-version-prefer={"discovery-guide-service-a":"1.0", "discovery-guide-service-b":"1.0"}
n-d-version-failover={"discovery-guide-service-a":"1.1", "discovery-guide-service-b":"1.1"}
n-d-region-transfer=qa
n-d-region-failover=dev
n-d-env-failover=common
n-d-zone-failover=zone1
n-d-address-failover=*1

变更全链路隔离路由和故障转移的配置

新的配置如下：

# 版本故障转移，即无法找到相应版本的服务实例，路由到老的稳定版本的实例。其作用是防止蓝绿灰度版本发布人为设置错误，或者对应的版本实例发生灾难性的全部下线，导致流量有损
# 在开启版本故障转移的开关前提下，故障转移有三种策略：
# 1. 如果“version-failover”值已配置，指定版本的故障转移，即找不到实例的时候，直接路由到该版本实例
# 2. 如果“version-failover”值未配置
#    2.1 开启“version.failover.stable.enabled”开关，版本列表排序策略的（取最老的稳定版本的实例）故障转移，即找不到实例的时候，直接路由到最老的稳定版本的实例
#    2.2 关闭“version.failover.stable.enabled”开关，负载均衡策略的故障转移，即找不到实例的时候，执行负载均衡策略
# 启动和关闭版本故障转移。缺失则默认为false
spring.application.strategy.version.failover.enabled=true
# 开启和关闭版本列表排序策略下取稳定版本的版本故障转移。缺失则默认为false
spring.application.strategy.version.failover.stable.enabled=true

# 版本偏好，即非蓝绿灰度发布场景下，路由到老的稳定版本的实例。其作用是防止多个网关上并行实施蓝绿灰度版本发布产生混乱，对处于非蓝绿灰度状态的服务，调用它的时候，只取它的老的稳定版本的实例；蓝绿灰度状态的服务，还是根据传递的Header版本号进行匹配
# 在开启版本偏好的开关前提下，偏好有两种策略：
# 1. 如果“version-prefer”值已配置，指定版本的偏好，即不管存在多少版本，直接路由到该版本实例
# 2. 如果“version-prefer”值未配置，版本列表排序策略的（取最老的稳定版本的实例）偏好，即不管存在多少版本，直接路由到最老的稳定版本的实例
# 启动和关闭版本偏好。缺失则默认为false
spring.application.strategy.version.prefer.enabled=true

# 区域调试转移，即当未对服务指定访问区域的时候，转移到事先指定的区域
# 使用场景示例：
# 开发环境（个人电脑环境）在测试环境（线上环境）进行联调
# 访问路径为A服务 -> B服务 -> C服务，A服务和B服务在开发环境上，C服务在测试环境上
# 调用时候，在B服务上进行如下两个配置，并在最前端传入的Header（n-d-region）指定为B的开发环境区域（用来保证A服务和B服务只在开发环境调用），而B服务会自动转移调用到测试环境上的C服务实例，但不会转移到其它个人电脑的C服务实例
# 该功能的意义，个人电脑环境可以接入到测试环境联调，当多套个人环境接入时候，可以保护不同的个人环境间不会彼此调用
# 通过“region-transfer”值进行区域转移值配置，如果缺失，则报错
# 启动和关闭区域调试转移。缺失则默认为false
spring.application.strategy.region.transfer.enabled=true

# 在开启区域故障转移的开关前提下，故障转移有两种策略：
# 1. 如果“region-failover”值已配置，指定区域的故障转移，即找不到实例的时候，直接路由到该区域实例
# 2. 如果“region-failover”值未配置，负载均衡策略的故障转移，即找不到实例的时候，执行负载均衡策略
# 启动和关闭区域故障转移。缺失则默认为false
spring.application.strategy.region.failover.enabled=true

# 启动和关闭环境故障转移。缺失则默认为false
# 如果“env-failover”值未配置，则默认为common
spring.application.strategy.environment.failover.enabled=true

# 启动和关闭可用区亲和性，即同一个可用区的服务才能调用，同一个可用区的条件是调用端实例和提供端实例的元数据Metadata的zone配置值必须相等。缺失则默认为false
spring.application.strategy.zone.affinity.enabled=true

# 在开启可用区故障转移的开关前提下，故障转移有两种策略：
# 1. 如果“zone-failover”值已配置，指定可用区的故障转移，即找不到实例的时候，直接路由到该可用区实例
# 2. 如果“zone-failover”值未配置，负载均衡策略的故障转移，即找不到实例的时候，执行负载均衡策略
# 启动和关闭可用区故障转移。缺失则默认为false
spring.application.strategy.zone.failover.enabled=true

# 在开启IP地址和端口故障转移的开关前提下，故障转移有两种策略：
# 1. 如果“address-failover”值已配置，指定IP地址或者端口的故障转移，即找不到实例的时候，直接路由到该IP地址或者端口实例
# 2. 如果“address-failover”值未配置，负载均衡策略的故障转移，即找不到实例的时候，执行负载均衡策略
# 启动和关闭IP地址和端口故障转移。缺失则默认为false
spring.application.strategy.address.failover.enabled=true

新增运维平台进行无损下线API接口

  • 运维平台下线某个服务实例之前，调用Nepxion Discovery Console平台的BlacklistEndpoint如下API，把需要下线的服务实例根据IP地址和端口添加进黑名单，返回全局唯一的该服务实例的UUId，即可实现实时无损下线
String addBlacklist(String serviceId, String host, int port);
  • 运维平台每添加一个黑名单后，把返回的服务实例的UUId存储下来（推荐用高可用方案来存储）
  • 运维平台下线某个服务实例一段时间之后（大于负载均衡3个时钟周期，推荐5分钟），调用Nepxion Discovery Console平台的BlacklistEndpoint如下API，把过期的服务实例根据UUId从黑名单里删除掉
boolean deleteBlacklist(String serviceId, String serviceUUId);

需要注意，UUId全局唯一，同样的服务实例重启注册后，UUId会重新产生，不会重复，但追加过多的UUId，虽然不会影响功能，但UUId堆积过多，使规则文本变得臃肿，可能会影响配置订阅的响应效率

新增配置初始化失败往事件总线抛出事件

  • 当服务启动取配置中心读取规则策略，如果存在非法输入的问题，会导致解析规则策略失败
  • 当在配置中心修改规则策略，如果存在非法输入的问题，推动到服务时候，会导致解析规则策略失败
    框架将统一往事件总线抛出RuleFailureEvent事件，以便解耦订阅

订阅方式如下：

@EventBus
public class MySubscriber {
    @Subscribe
    public void onRuleRuleFailure(RuleFailureEvent ruleFailureEvent) {
        System.out.println("========== 规则更新失败, rule=" + ruleFailureEvent.getRule() + ", exception=" + ruleFailureEvent.getException());
    }
}

在配置类里@bean方式进行订阅类类创建

@Bean
public MySubscriber mySubscriber() {
    return new MySubscriber();
}

重构优化

  • 重构DefaultDiscoveryEnabledAdapter
    • 去掉discoveryClient.getInstances(String serviceId)作为寻找负载均衡服务列表的方式，改成ZoneAvoidanceRule.getPredicate().getEligibleServers(getLoadBalancer().getAllServers(), key)获取，可以提高不少性能
    • 去掉StrategyVersionFilter，DefaultDiscoveryEnabledAdapter过滤机制拆分成StrategyEnabledFilter基准接口的实现类，例如，StrategyVersionEnabledFilter，StrategyRegionEnabledFilter等，使架构更加清晰，可读性更好
  • InstanceEntity增加serviceUUId属性
  • UserEntity增加序列化方式

缺陷修复

  • 修复StrategyVersionFilter中区域、地址和全局唯一ID处理的遗漏项

相关发布

DiscoveryAgent发布

无

DiscoveryDesktop发布

无

相关下载

DiscoveryAgent下载

访问https://github.com/Nepxion/DiscoveryAgent/releases获取最新版本

DiscoveryDesktop下载

访问https://github.com/Nepxion/DiscoveryUI/releases获取最新版本

Contributors

bean
Assets 2
Loading

3.32.0(SEP 5, 2022)

05 Sep 04:19
@HaojunRen HaojunRen
3.32.0
41b2366
Compare
Choose a tag to compare
3.32.0(SEP 5, 2022)

见 Nepxion Discovery 6.15.0 发布

Assets 2
Loading

6.14.0(MAY 30, 2022)

30 May 13:18
@HaojunRen HaojunRen
6.14.0
6a3e9b4
Compare
Choose a tag to compare
6.14.0(MAY 30, 2022)

发布日志

发布策略

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

版本 状态 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.14.0 H.SR5 ↑
H
G
F		 2.3.x
2.2.x
2.1.x
2.0.x		 2.2.7.RELEASE ↑
6.12.1 ↓ 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.31.0 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）已废弃

版本变更

  • 默认集成SkyWalking版本为8.10.0
  • 默认集成OpenTelemetry版本为1.14.0

另：

3.x.x版本变更

  • Apollo版本降级为1.7.0，Spring Boot 1.5.x不支持高版本Apollo

7.0.0商业版版本变更

  • 默认升级集成Spring Boot版本为2.5.14

8.0.0商业版版本变更

  • 默认升级集成Spring Cloud版本为2021.0.3
  • 默认升级集成Spring Boot版本为2.6.8

功能迭代

全链路区域调试路由

在区域调试路由执行的时候，当未对服务指定访问区域的时候，路由到事先指定的区域。该功能属于静态隔离和动态路由结合在一起的灵活方案，适用于开发环境（个人电脑环境）在测试环境（线上环境）进行联调，同时当多套个人环境接入时候，可以保护不同的个人环境间不会彼此调用

在下面的全链路调用路径中

A服务 -> B服务 -> C服务 -> D服务

其中，A服务和B服务在开发环境上，C服务和D服务在测试环境上，希望A服务调用B服务的时候，只会走本地电脑，不会去访问测试环境的B服务，也不会去访问其它本地电脑的B服务；B服务调用C服务的时候，只会去访问测试环境的C服务，C服务调用D服务的时候，也只是在测试环境的区域内

只需要通过如下步骤：

  • A服务和B服务的区域（Region）元数据配置为MyDEV（本地电脑的名称或者可以区别其它电脑的特征值），如下
spring.cloud.nacos.discovery.metadata.region=MyDEV
  • C服务和D服务的区域（Region）元数据配置为FAT（测试环境），如下
spring.cloud.nacos.discovery.metadata.region=FAT
  • B服务和C服务，加上如下配置，保证B服务只访问测试环境上的C服务，C服务只访问测试环境上的D服务
# 开启和关闭跨区域路由
spring.application.strategy.region.route.enabled=true
# 路由的目标区域
spring.application.strategy.region.route=FAT
  • 前端传入B服务的区域Header。由于A服务是调用起点，所以不需要配置A服务的值
n-d-region={"service-b":"MyDEV"}

扩展场景：

如果希望C服务访问的是开发环境上的D服务，那么变成

A服务（本地环境） -> B服务（本地环境） -> C服务（测试环境） -> D服务（本地环境）

前端传入区域Header改为

n-d-region={"service-b":"MyDEV", "service-d":"MyDEV"}

总结

  • 要调用测试环境中的服务，包括开发环境调用测试环境和测试环境中的服务间调用，必须加上开启和关闭跨区域路由和路由的目标区域的两个配置
  • 要调用开发环境中的服务，包括测试环境回调开发环境和开发环境中的服务间调用，必须加上n-d-region的Header进行动态路由

重构优化

无

缺陷修复

无

相关发布

DiscoveryAgent发布

无

DiscoveryDesktop发布

无

相关下载

DiscoveryAgent下载

访问https://github.com/Nepxion/DiscoveryAgent/releases获取最新版本

DiscoveryDesktop下载

访问https://github.com/Nepxion/DiscoveryUI/releases获取最新版本

Assets 2
Loading

3.31.0(MAY 30, 2022)

30 May 13:13
@HaojunRen HaojunRen
3.31.0
dee9b4b
Compare
Choose a tag to compare
3.31.0(MAY 30, 2022)

见 Nepxion Discovery 6.14.0 发布

Assets 2
Loading

6.13.1(FEB 20, 2022)

21 Feb 09:07
@HaojunRen HaojunRen
6.13.1
eac2dc2
Compare
Choose a tag to compare
6.13.1(FEB 20, 2022)

本版本主要是升级兼容Spring Cloud Alibaba 2.2.7.RELEASE（不适用于2.2.6.RELEASE），以及外围一些中间件版本的升级

贡献列表

发布日志

发布策略

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

版本 状态 SC SB SCA
8.0.0 (商业版) 2021.x.x 2.7.x
2.6.x		 2022.x
7.0.0 (商业版) 2020.x.x 2.5.x
2.4.1 ↑		 2021.x
6.13.1 ↑ H.SR5 ↑
H
G
F		 2.3.x
2.2.x
2.1.x
2.0.x		 2.2.7.RELEASE ↑
6.12.1 ↓ 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.29.0 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.7.RELEASE
  • 默认集成Apollo版本为1.9.2
  • 默认集成SkyWalking版本为8.9.0
  • 默认集成OpenTelemetry版本为1.11.0
  • 默认集成Guava版本为31.0.1-jre
  • 默认集成Caffeine版本为2.9.3
  • 默认集成JEtcd版本为0.5.11

另：7.0.0商业版版本变更

  • 默认升级集成Spring Cloud版本为2020.0.5
  • 默认升级集成Spring Boot版本为2.5.9
  • 默认升级集成Spring Boot Admin版本为2.5.5

功能迭代

  • 适配Spring Cloud Alibaba 2.2.7.RELEASE，由于NacosServiceRegistry构造方法做了变更，同步变更NacosServiceRegistryDecorator，6.13.1只适用于Spring Cloud Alibaba 2.2.7.RELEASE及更高版本
  • 3.x.x（基于Spring Boot1.5.x）不再维护，本次发版的3.30.0为最后一个版本

重构优化

无

缺陷修复

  • ThreadLocalHook注册bug，，参考https://github.com/Nepxion/DiscoveryAgent/issues/5

相关发布

DiscoveryAgent发布

  • 修复Collections.emptyList()使用不当问题，参考https://github.com/Nepxion/DiscoveryAgent/issues/6

DiscoveryDesktop发布

无

相关下载

DiscoveryAgent下载

访问https://github.com/Nepxion/DiscoveryAgent/releases获取最新版本

DiscoveryDesktop下载

访问https://github.com/Nepxion/DiscoveryUI/releases获取最新版本

Contributors

yanbw and rottenmu
Assets 2
Loading

3.30.0(FEB 20, 2022)

21 Feb 09:05
@HaojunRen HaojunRen
3.30.0
fc4e14c
Compare
Choose a tag to compare
3.30.0(FEB 20, 2022)

见 Nepxion Discovery 6.13.1 发布

Assets 2
Loading