【应用运维】公司业务迭代迅速，运维如何高效进行应用发布？

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

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

应用发布存在的问题

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

应用迭代频率高

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

SLA要求高

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

应用数量多

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

环境管理难

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

极需标准化

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

应用发布系统设计

01 应用发布系统设计

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

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

配置管理：

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

原子化：

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

标准化：

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

自动化：

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

发布策略：

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

发布模式：

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

02 发布系统架构

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

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

服务树拓扑

2. 在CMDB之上进行扩展

纳管应用相关联的信息：

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

程序包管理：

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

应用配置文件管理：

提供基础的文件储存、版本管理能力，还可以通过变量配置与实例化的能力来支持不同环境下配置文件的变化。

应用配置管理

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

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

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

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

发布场景与发布策略

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

01 发布策略

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

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

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

并行发布

滚动发布

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

滚动发布

蓝绿发布

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

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

蓝绿发布

金丝雀发布（灰度发布）

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

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

金丝雀发布

02 发布窗口模式

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

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

发布窗口模式

03 传统应用的发布场景

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

传统应用

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

Service unit A：

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

Service unit B：

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

Service unit C：

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

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

总结

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