背景
公司原本以A主体接入了芝麻认证API，实现认证流程，各业务也通过A主体去引导用户完成芝麻认证。后面公司下B主体也要接入芝麻认证，但是要以B主体接入，而芝麻商家后台会为不同主体分配不同的配置，所以原有的服务需要多主体的情况，才有了这次发布。
业务流程
认证流程
所以此次修改会涉及前端、网关和认证服务。需求评审时各个服务也确认了要添加修改的功能，确认好发布日期，然后开始开发。一切井然有序，好像没有什么问题，直到联调完要做发布计划时，另一个问题开始暴露...
问题
联调时，我们将开发完成的程序部署到测试环境，集成测试并没问题，但是服务要发布上线，总有个先后顺序，哪个先发，哪个后发引起了新的问题。根据分析不同发布顺序，无论哪个服务先发布，都会造成B主体下用户一直认证未通过。
解决
既然是发布时间差引起的各服务状态不一致，为了避免这个问题，有人提议发布维护公告，暂停服务半小时。方法简单暴力，但有点low。
另一个观点是，服务发布时间不能减少，那么可以先将网关的功能先发上去，然后通过配置作为开关，控制功能是否生效，这样切换开关比服务发布时间要短很多。在前端发布完后，打开开关是功能生效即可。出现问题只需把开关关闭，就完成回滚。
两种方案各有优缺点，方案1简单暴力，体验不好；方案2快速便捷，但增加开发和发布的复杂度，发布完成后开关功能也不在需要。
发布
我们确认以方案2的形式发布，发布当晚也出现了2回滚，一个是网关配置错误，导致请求不能转发到认证服务；另一个是发布完成后，另一个我们确认不会受影响的服务出现了监控数据波动，但是服务负责人不能快速定位原因，所以我们再次回滚。
总结
- 发布计划要反复推敲
- 回滚机会很重要
- 发布流程要规范，走捷径时要十分注意
网友评论