在 Java-Chassis 2.8.2 版本, MicroserviceVersions的契约加载逻辑从单个微服务版本的契约只加载一次改为了每次实例列表有变化都重新加载一次契约, 因此在provider端微服务实例列表变化时, consumer端的全部实例都要重新加载provider端契约.
假设consumer端有 n 个实例, provider端有 m 个契约 i 个在网的版本, 则provider端有任何一次实例列表变化都将导致注册中心额外承载 n * m * i 次拉取契约的流量. 实际上, 由于微服务滚动升级上下线时还存在状态变化, 状态变化也算是实例列表变化, 流量问题可能更加密集. 而且契约的内容通常都比较多, 这也会导致注册中心的查询接口流量较大.
和 @liubao68 了解过, 这次修改 (#3451 ) 是为了方便开发环境 consumer 端能够不重启微服务进程而加载到 provider 端的新接口契约. 但是这个机制导致业务现网可能面临注册中心过载的风险. 麻烦考虑给这个特性增加一个开关, 比如只有开发环境(environment=development)才重新拉取契约, 以降低现网的注册中心压力.
在 Java-Chassis 2.8.2 版本,
MicroserviceVersions的契约加载逻辑从单个微服务版本的契约只加载一次改为了每次实例列表有变化都重新加载一次契约, 因此在provider端微服务实例列表变化时, consumer端的全部实例都要重新加载provider端契约.假设consumer端有
n个实例, provider端有m个契约i个在网的版本, 则provider端有任何一次实例列表变化都将导致注册中心额外承载n * m * i次拉取契约的流量. 实际上, 由于微服务滚动升级上下线时还存在状态变化, 状态变化也算是实例列表变化, 流量问题可能更加密集. 而且契约的内容通常都比较多, 这也会导致注册中心的查询接口流量较大.和 @liubao68 了解过, 这次修改 (#3451 ) 是为了方便开发环境 consumer 端能够不重启微服务进程而加载到 provider 端的新接口契约. 但是这个机制导致业务现网可能面临注册中心过载的风险. 麻烦考虑给这个特性增加一个开关, 比如只有开发环境(
environment=development)才重新拉取契约, 以降低现网的注册中心压力.