主要是访问量大的系统，或者关键业务部分，需要安全的发布代码，同时保证系统的可用及发生问题时的快速回滚。
灰度发布
最简单的是复制粘贴，然后写一个V2版本代码，分流过去一部分流量，精确记录日志，监测一定时间，如果没有问题，基本是好的，再全量发布。灰度发布也是一种不停服的更新手段，小规模的更新不停服是非常好的体验。
分流的方法有很多场景使用，例如微博发布新版页面，新功能内测，都是这样的手段。
完善开发流程的发布
需要更迭的代码一般是复杂，重要，需要提升性能的部分，有极大的更迭需求，不仅现在有，以后也会有的，如果时间充裕一定要完善文档。磨刀不误砍柴工。
流程：1. 和产品运营确定新版本的需求，确定文档，没有文档就先完成文档化，这个版本的文档对于以后更新也是很好的基础。 2. 完善技术文档和设计文档，实现逻辑也需要在代码中注释一下。 3. 完善单元测试和集成测试，涉及安全更新需要有渗透测试。 4. 开始进行api兼容级别改造。
文档的意义在于记录此次更新的原因，实现等，也为了以后备查，方便下次迭代。测试的意义在于保证上线后不出明显问题，而对于生产环境数据和测试环境数据不一致导致的其他问题，这个真的不能避免，如果是极微少量的旧数据错误，可以从代码和数据层面排查，提交新的覆盖全部情况的案例。如果是大规模的错误，则需要能够快速恢复旧版本的代码了，然后排查错误日志，找到错误数据，进行修正。代码层面撤回，然后重新修正，再次迭代发布。
没有绝对的避免小概率事件，只能尽可能的避免小概率事件发生。
© 方案来自 梦康交流群 煎鱼 大佬李 两位，个人做了一部分补充，当做笔记。
最后恰饭 阿里云全系列产品/短信包特惠购买 中小企业上云最佳选择 阿里云内部优惠券
