大家好，我是架构摆渡人。这是实践经验系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

在日常工作中，无论是一周一个迭代，还是两周一个迭代，都避免不了上线的环节。唯一的区别就是上线的频次不同而已。那么我们如何保证在这么高频次的发版里面同时保证稳定性呢？

答案就是开关编程，所谓的开关编程其实就是加个if判断，但是可以动态去调整if里面的值，能够随时控制逻辑的走向。开关需要自己编写，自己控制，动态调整值则可以借助于配置中心，改变后实时刷新。

案例一：旧功能里面加新逻辑

假设你要对订单详情页面做调整，增加一部分内容或者修改老的逻辑。正常的做法就是直接改掉老逻辑，然后测试，然后上线。

如果测试覆盖了所有的场景，上线后也不会有任何问题。就怕有某些场景遗漏了，导致在测试环境中没有发现的问题，一上线就出问题了。此时你的逻辑已经是最新的了，唯一的解决办法就是回滚应用到之前的版本，回滚是下下策，不到万不得已千万不要做，因为回滚可能带来更严重的问题。

这次发布所有的新功能都丢了

如果执行回滚操作，也就意味着这次发布要上的新功能都没有了，如果你的服务拆的够细，可能影响面会稍微小点。

假设服务端回滚了，如果此时客户端已经发布，像H5还好说，也可以回滚，像APP如果用户已经更新到最新版本了，你服务端回滚了，用户一用到新功能就直接报错了。所以请慎重回滚。

所以此时你可能没办法回滚，只能快马加鞭改Bug，然后紧急发布进行修复，玩的就是心跳啊。

开关的作用来啦

在改动旧逻辑的时候，不要直接改，可以在内部采用分版本的方式进行调整。把之前的逻辑定位V1，要改的逻辑定位V2，然后通过开关去切换。

伪代码如下：

boolean switch = false;
if (switch) {
// 走新改的逻辑
} else {
// 走旧逻辑
}

通过增加开关来保证稳定性，默认开关是关闭的，上线后还是走旧逻辑，无任何影响。发布完成后再将开关开启，此时走新逻辑。如果新逻辑出现了Bug，立马将开关关闭走旧逻辑，不用回滚整个服务，是不是很稳。

此时，又有同学抬杠了，你这虽然能快速回滚，如果流量大的话影响还是很大啊。是的，如果要保证最小的影响，那么就需要结合灰度来实现了，这块后面再给大家介绍如何去做。

案例二：大促前的功能降级

对于很多电商公司来说，大促必不可少。每年都有像周年庆，618，双十一，双十二之类的大促期。

大促的时候，流量也是最高的时候。此时最重要的就是P0级别的核心链路，其他不是很重要的可以降级，以免影响到主链路的功能。

比如订单详情页里面，大部分都是订单的快照信息，可能有个别信息是需要调用其他的接口进行展示的，但这个信息不是必要的，此时就可以在调用这个接口的地方加开关，平时关闭，大促之前打开，不进行调用，这样就保证了详情页的稳定性。

伪代码如下：

boolean switch = false;
XxxInfo xxxInfo = null;
if (!switch) {
// 调用外部接口获取信息
xxxInfo = xxxRpc.getxxx();
}

开关注意点

开关虽然很有用，但是凡事有利也有弊。当项目中出现了很多的开关之后，对于代码的可读性比较差，特别是对于新同学来说，这么多开关，可能也不知道干嘛的，所以第一点就是注释一定要写清楚。

然后对于那些保证上线稳定性的开关，在上线后过一点时间，功能稳定了，就应该及时删除开关的逻辑，提高代码可读性。对于降级的开关，还是要保留的。

开关总结

我相信大家在工作中也会用开关去做一些事情，特别是在上线新功能，或者改老功能，或者重构的时候，真的很有用。

**有了开关，上线不慌，没有开关，听天由命。**想不想保住工作，就看你开关用的溜不溜啦！