好家伙, 灰度发布 还这么多细节

背景

其实就是优雅关机 流量切换不能有临时的接口不可用（ribbon 要有重试机制，服务通知要即时，可以看阿里云有一个 讲流量切换的 视频），然后就是 升级v2之后需要先验证一下，然后流量再切到v2，防止业务不可用的情况（具体原因没了解，应该是被用户说了。。。。）

思考题 带着问题看

看完这篇文章 你还有哪些部分是 有疑问的 我先说

1. nacos 配置实时生效 你说实时就实时啊，底层根据什么做的，如果一台业务服务 网络临时不好，后面恢复了，怎么补偿的？
2. aop @After @AfterReturning @AfterThrowing 你说是分开的 你怎么证明的？底下怎么执行的
3. aop 中的threadlocal 你说 不清除 会对系统有影响，什么影响，有什么现象？为什么？
4. 多线程 操作一个对象，会有数据一致性问题，除了你这里的 不可变类 还有别的办法么？ 有什么区别呢，有什么应用场景呢？

同志们 想了解哪个 评论区告诉下 我后面整理 发出来

技术调研

灰度发布这个东西 我之前没写过，只是听说，我之前的理解 给大家画个图

百度一下 灰度发布，什么玩意，你告诉我改改gateway 改改feign，v2项目启动 带上元数据，就这？闭环呢？

基础规范

1. 涉及到 版本的选择，那之后 元数据 每个都加上version: 具体版本号 这不就行了，避免了改元数据 可能导致的问题

需要确定问题

1. 开发流程 后台发布灰度之后 前端先测试 灰度 再上线，确定了想法，统一了思路，才能开始干活嘛 (问前端大哥)

之前有一版方案 参考下

参考之后 感觉之前的方案有点过于复杂，有一些无用功，进行缩减

思考

其实灰度发布 变为了 配置的统一管理

现在需要解决的问题

1. 配置文件的管理 从2个方案进行选择 （实现 配置实时生效， spring.cloud.nacos.config.shared-configs 如果要添加 你让我每个服务 添加重新发版