yhs0092 commented on issue #3685:
URL:
https://github.com/apache/servicecomb-java-chassis/issues/3685#issuecomment-1447586682
现网还是有必要保障微服务契约不能被覆盖的吧? 当前即使是 Java-Chassis 2.x 版本,
consumer端调用接口也是要依赖provider端契约的. 假设业务使用新版本Java-Chassis开发微服务, 如果业务在新版本删除或修改了接口,
然后在现网误操作将旧版本软件包以新升级的版本号重新部署, 那么旧的契约会覆盖新的契约,
将导致一个instancePull周期内全部consumer都刷新成有问题的契约, 整个微服务的流量都会报错. 而在旧版本上,
微服务契约校验逻辑能够为业务拦截这种问题.
业务应该要确保, 当接口契约变化时, 升级微服务的版本号, 这应该是对使用者的基本要求. Java-Chassis 应该在这一前提下做好拦截保护机制.
对于当前的 Java-Chassis 框架来说, 这样做对业务来说才是安全的. 为了开发态的方便而放弃现网的变更可靠性, 这种交换未见得是业务方预期的,
建议谨慎考虑一下吧, 所以建议应该让 consumer 端重新加载契约的行为仅在开发环境生效才保险.
P.S. 也不是说热更新consumer端加载的契约不好, 而是说当前的 Java-Chassis 框架依赖契约做consumer端调用, 而新版本
Java-Chassis 的 consumer端会自动从注册中心刷新契约, 所以一旦有故障, **将会迅速扩散到全部 consumer 实例上**,
这是Java-Chassis 新版本新增的风险场景.
如果哪一天consumer端的调用逻辑像原生的 `RestTemplate` 或者 Feign 一样, 是客户端定好的逻辑转发, 那也就无所谓这个问题了.
> 注册中心的压力应该能够支持这样的场景（所有实例单线程并发完成某个具体的功能），否则不可避免会导致一些意想不到的问题。
---- 关于这一点, 以前升级的场景是 consumer 端不用重新加载旧契约, 只需要加载新契约即可; 而现在的场景,
consumer端需要反复加载新旧版本的契约, 所以至少一定时间内总流量是翻倍的, 而且由于业务服务端多是滚动升级, 升级过程中涉及上下线,
可能每个实例都有多次实例状态的变化, 所以查询契约的流量应该显著高于旧版本.
总之注册中心面临的压力会高于之前的版本, 建议宝哥还是跟 sc 的维护者沟通一下, 如果有风险可以提前告知各个业务, 或者在release
note之类的地方明确标注一下.
> 对于性能要求高的场景，可以考虑在客户端本地将服务端契约放进去，这样是最高效也能够保持兼容的处理方式。
这一点可能有难度, 对于大型业务而言, 各微服务升级不是同步的,
而且他们依赖Java-Chassis框架的接口兼容性转发能力(`OperationInstancesDiscoveryFilter`提供的). 据我观察,
大部分业务在consumer端都是从注册中心加载契约的.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
