【每天5分钟，了解一个知识点】
在互联网企业中，高频发布已成为一种趋势。它带来了诸多收益，让我们一起来看看。
一、高频发布的收益
更多用户互动：有更多的机会与真实用户互动，从而快速决定或调整产品前进的方向。
降低部署风险：由于每次变更规模较小，软件系统没有剧烈的变化，从而降低部署风险。
降低成本：单次部署成本降低，且趋于恒定。
易定位修复：出现问题易定位、易修复，且能快速更正。
二、降低发布风险的方法
（一）蓝绿部署
准备两套完全一致的运行环境，一套作为正式生产环境，对外提供软件服务；另一套作为新版本的预生产环境，部署软件的新版本，并对其进行验收测试。当确认预生产环境没有问题后，将访问流量引流到这个新版本的环境中，作为正式的生产环境，同时保持旧版本所在环境不变。直至确定新版本没有问题后，再将旧版本所运行的环境作为下一个新版本的预生产环境，部署未来的新版本。“蓝”和“绿”仅代表两个互相独立的部署环境。
（二）滚动部署
从服务器集群中选择一个或多个服务单元，停止服务后执行版本更新，再重新将其投入使用。循环往复，直至集群中所有的服务实例都更新到新版本。
（三）金丝雀发布
泛指通过让一小部分用户先行使用新版本，以便提前发现软件存在的问题，从而避免让更多用户受到伤害的发布方式。
（四）灰度发布
将发布分成不同的阶段，每个阶段的用户数量逐级增加。如果新版本在当前阶段没有发现问题，就再拓展用户数量进入下一个阶段，直至拓展到全部用户。例如 1%、5%、10%、50%、100%等多个阶段。
（五）暗部署
功能或特性在正式发布之前，将其第一个版本部署到生产环境，以便在向最终用户提供该功能之前，团队可以对其进行测试，并发现可能的错误。“暗部署”中的“暗”字是针对“用户无感知”这一点而言，这可以通过开关技术来实现。
三、高频发布支撑技术
（一）功能开关技术
定义：从代码的角度来讲，每个开关的本质是一个“if...else...”条件语句块。
新用途：
隔离：将未完成功能的代码隔离在执行路径之外，使之对用户不产生影响。
快速止血：一旦生产环境出了问题，直接找到对应的开关选型，将其设置为“关闭”。
遵循原则：
在满足业务需求的前提下，尽可能少用开关技术。
如果在“分支”和“开关”之间选择，尽可能选择开关技术。可以在主干上与他人代码频繁集成，尽早发现设计冲突问题；创建分支会带来后期的分支合入以及多次测试成本。
软件团队应对开关配置项进行统一管理，方便查找和查看状态。
尽可能使用统一的开关框架和开关策略。
定期检查和清理不必要的开关项。
（二）数据迁移技术
原则：“字段尽可能只增不删”，即对数据库表中的原有字段不再进行修改和删除操作。
步骤：
为数据库结构增加一个新版本。
修改应用程序，同时向两个版本的结构中写入数据。
编写脚本程序，以后台服务的方式将原来的历史数据回填到新版本结构中。
修改应用程序，从新旧两个版本中读取数据，并进行比较，确保一致。
当确认无误后，修改应用程序，只向新版本结构写入数据。可以将原来的旧版本数据保留一段时间，以防止未预料的问题出现。
（三）数据库中两表合并的流程
修改数据库结构。编写对应的 SQL 脚本并执行。
修改应用程序，同时向两个版本的结构中写入数据。在应用程序中，修改代码，支持向两个结构中写入数据。
编写一个可离线执行的后台脚本，批量将原来的历史数据回填到新版本的结构中。
从新旧两个版本中读取数据，并进行比较，确保一致。
当确认无误后（稳定后），修改应用程序，只向新版本结构写入数据。
放弃旧版本（这是一个可选步骤）。
（四）抽象分支方法
“抽象分支方法”是在不创建真实分支的情况下，通过设计手段，将大的重构项目分解成很多个小的代码变更步骤，逐步完成重大的代码架构调整。
优点：
重构的同时也能交付业务功能需求。
可以逐步验证框架调整的方向和正确性。
如果遇到紧急的情况，很容易暂停，而且不浪费之前的工作量。
能够强化团队的合作性。
可以使软件架构更模块化，变得更容易维护。
四、升级替代回滚
回滚操作通常是将与待修复的问题相关的某次提交以及与之相关的任何提交一同从代码仓库中直接剔除，然后再次提交，等待下一次发布即可。尽可能以代码升级的方式代替二进制回滚。
五、影响发布频率的因素
增量发布带来的收益和可能性。
每次发布或部署的操作执行成本有多高。
出现问题的概率与这些问题带来的成本有多少。
维护同一软件的众多不同版本带来的成本。
高频发布模式对工程师的技能要求。
支撑这种高频发布所需要的基础工具设施与流程完善性。
组织对这种高频发布的态度与文化取向。
【关联阅读】
关注公众号，回复【Java面试】，获取更多面试资料
