应用软件架构在不断发展，用户需求爆炸式增加，应用数量成倍数增长，发布迭代速度越来越快，应用运维团队肩负着业务系统正常运转的重大责任。



不仅得确保应用系统高效稳定运行，同时还要响应研发、业务人员诉求完成版本变更或上线的业务价值交付，并提供相关的数据和服务给到业务、运营和测试等外部人员，其中，应用发布作为应用运维最基础、最核心的工作，一般会作为应用运维自动化的第一个解决场景。



应用发布存在的问题



当前企业应用发布容易遇到以下问题：



应用迭代频率高

因业务的需求，应用迭代的频率越来越高，如果依旧为人工发布，出错概率大大提升，迫使人工运维转向自动化。



SLA要求高

SLA的要求越来越高，那么就促使发布过程中，不同发布策略的灵活使用。



应用数量多

应用的数量越来越多，架构越来越复杂，需要一套配置管理工具快速响应应用的变化，并且能支持多种应用架构。



环境管理难

环境的管理，从开发到上线，不同环境的切换繁琐，难控制，易出错。



极需标准化

标准化，自动化的前提工作是先做好标准化，如果无法有效协同资源对象，那么在构建相应应用运维工具时就会陷入无穷无尽的适配工作中。



应用发布系统设计



01 应用发布系统设计



随着分布式系统的不断推广，应用发布越来越频繁，应用数量越来越多，建立一个功能齐全、灵活的发布工具成为自动化最紧急重要的需求。



在设计一个发布系统时应考虑可复用性，和易用性，设计原则如下：



配置管理：

应用发布的前提是做好配置管理，与CMDB结合，并能支持不同类型的应用架构。



原子化：

将发布中的操作进行建模拆解，建立细颗粒度的操作原子，通过编排进行操作场景的组合，大大提升可复用性。



标准化：

发布系统在一定程度上应该引导与规范应用运维人员操作和配置。



自动化：

发布操作尽可能的自动化，防止过多的人工干预。



发布策略：

支持常用的发布策略，并行发布，滚动发布等。



发布模式：

支持多模块的发布，支持多模块的发布顺序的编排。



02 发布系统架构



我们使用蓝鲸平台，在此之上构建应用发布系统，设计思路如下：



1. 以应用为中心建设CMDB，着眼于应用而不是资源对象，以纵向的维度划分模块，使用服务树拓扑管理应用，拓扑的设计支持传统应用架构和互联网应用架构，支持多环境，多集群管理。



服务树拓扑



2. 在CMDB之上进行扩展



纳管应用相关联的信息：

应用的程序包、配置文件、进程、基础资源、主机、发布参数，并支持模块与模块之间的调用关系管理，从而向上支撑应用运维场景。



程序包管理：

不仅提供文件存储，版本管理的能力，并且可以支持对接制品库，同时支持程序包与应用的关系管理。



应用配置文件管理：



应用配置管理



3. 完备的底层能力，发布的过程终归是对于发布对象的操作执行，蓝鲸平台强大的脚本作业的执行，文件的分发是操作的基础。



4. 发布方案强大的可视化编排能力，支持单/多应用的发布编排，支持定时、并行、滚动发布。



5. 发布过程提供实时的过程跟踪与丰富的控制能力。



6. 执行流程原子化与编排，提供灵活的编排能力，可以将操作原子编排组合起来，并提供参数化管理，使得编排出来的流程可以灵活复用，当内置原子无法满足对应操作场景时，可以自定义开发实现。



发布场景与发布策略



我们按照上述发布系统的设计，可以支撑企业中不同发布场景的需求。



在应用发布过程中，为了保证应用对外提供正常的服务，应用发布自动化需支持不同的发布策略。



一次性全部部署（并行发布）

将应用下所有实例同时停止运行，并行更新版本，然后同时启动所有实例，这种策略在发布时不需要额外的资源，但是存在服务中断。



并行发布

滚动发布

滚动的策略，设置停止实例的数量，例如1，意味着在发布过程中，先停止一个旧实例，更新完成后启动它，然后周而复始，直至所有实例更新完毕，这样就可以保证发布过程中服务不中断，也不需要额外的资源，但是他的缺点是发布需要的时间很长。



滚动发布



蓝绿发布

这种发布策略是为了解决滚动发布中，承担负载的实例数量减少，可能会带来未知的压力。蓝绿部署的方式是：先额外创建一批新的实例、更新版本，然后将流量切换到新的实例上，由新的一批实例对外提供服务，在测试观察新版本没有问题后，将旧的实例销毁。



这种方式意味着在升级的过程中，需要同时运行两套程序，所需要的资源是日常的两倍。但是这种策略的好处是，不中断服务，并且在发布过程中出现了问题，可以快速回滚。



蓝绿发布



金丝雀发布（灰度发布）

这种策略的做法是，先在旧的实例中，挑出少量的实例，将他们踢出负载均衡进行更新，然后将部分流量引导到新的实例上进行流量验证（金丝雀测试），保证新版本没有问题之后，将剩下的实例进程更新。这个过程就像，旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，再决定是否能进入矿洞。



在金丝雀过程中就需要对流量进行筛选，通常我们可以使用nignx针对于IP，设备类型，浏览器类型进行流量的切割，针对于特定用户类型的流量，我们可以通过定制http请求头的方式进行条件的筛选。



金丝雀发布



02 发布窗口模式

目前大部分企业的应用发布模式还是以发布窗口的形式存在。



发布窗口指一个特定的时间段（一般选择系统负载较低的时候进行），在这个时间段内一个或多个团队可以发布应用到生产环境。应用数量多，且应用之间存在依赖，这时针对于多模块发布的场景，编排就成了发布系统重要的功能之一。



发布窗口模式



03 传统应用的发布场景



在传统的应用发布场景中，经常会存在着同一个模块下的不同主机可能运行着不同的进程（或是进程不同，或是端口不同，或是启动命令不同），但使用的程序包是一样的。



传统应用



如图，我们可以看到的一种单模块多服务的场景：



Service unit A：

服务A运行在不同主机上，每个主机上运行着一个实例，并对外提供相同的端口服务。这样在发布时，同一模块不同应用实例是统一的，我们只需要关注每一个服务实例的配置信息即可。



Service unit B：

服务B在不同实例上运行着相同的进程，但是实例监听着不同的端口。这样在发布时，我们需要对于参数的管理下沉到主机，这样会大大增加了适配上的工作量。



Service unit C：

服务C在不同实例上运行着不同的进程，且存在多个实例运行在同一个主机上，那么在发布时，我们要关注的颗粒度就会非常的小，细化到进程的管理，管理上的难度随着场景的复杂度成倍增加。



面对于这种传统的场景，我们通过对于进程的管理来实现这种细颗粒度参数管理，从而满足传统应用的发布。



总结

以CMDB为基础，在此之上扩展应用配置管理完成对于应用配置信息的纳管，底层抽象发布中的执行流程，以应用发布自动化为枢纽联动应用配置管理与执行流程，实现单/多模块发布，可视化任务编排、任务执行实时跟踪，发布策略，和多种人工干预方式等。