- 一般情况下，服务一般不是仅有一台服务器提供服务的，因此服务上线的过程中其实会经历一个灰度过程
如上所示，服务器A是新代码，走的是新逻辑，服务器B和C未发版，走的旧逻辑。
- 如果新上线的变更只涉及读逻辑的，那么这样的灰度上线是没问题的。
- 但如果上线的内容涉及写逻辑的变更，甚至还关联到异步处理的变更。那么这样的上线方式可能是不兼容的，会导致处理异常。
- 在服务全量发版之后，新的流量可能正常，但发版过程中导致一定的脏数据。
(图不画了，自行想象)
解决方案
- 开关！用配置中心开关控制，走新逻辑还是旧逻辑。默认旧逻辑。
- 代码需要保留两套，通过开关控制走哪个分支。
- 全量发版之后，此时线上全是新代码了，通过开关灰度(此时是业务灰度而不是机器灰度了)