海量数字化业务时代，企业应用发布自动化系统应该如何设计？

Posted 2021-09-18 嘉为科技

背景

 

01 应用运维背景

随着数字化转型的发展，线下业务逐渐线上化，应用数量与日俱增，应用架构也趋于多样化和复杂化，而 IT基础设施逐步云化标准化并趋于稳定，因此运维的重心和价值渐渐聚焦于应用。应用运维团队肩负着保障业务系统正常运转的重大责任。同时伴随着新业务形态，新技术架构的诞生，对应用运维提出了更高的要求。

 

02 应用发布存在的问题

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

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

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

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

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

 

应用发布系统设计

01 设计理念和原则

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

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

配置管理：应用发布的前提是做好配置管理，基于CMDB，支持不同类型的应用架构，打通其他系统形成一体化的发布平台。

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

标准化：一切自动化的前提都是标准先行，发布系统需要引导与规范应用运维人员操作和配置。

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

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

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

整体架构图如下：

02 发布系统架构

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

以应用为中心建设CMDB：

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

▲    服务树拓扑

在CMDB之上扩展应用配置中心：

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

程序包管理：提供基础文件存储，版本管理的能力，但是更加推荐对接制品库的方式。

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

模板集：是一组以应用为视角的k8s配置yaml文件的集合，通过参数管理与版本管理，简化资源管理的复杂度。

对接harbor仓库实现Helm的管理与发布。

▲    应用配置管理

完备的底层能力

发布的过程终归是对于发布对象的操作执行，平台强大的脚本作业的执行，文件的分发是操作的基础。

双流程编排

管理与执行的天然结合，更加贴切企业发布场景：

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

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

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

 

发布场景与发布策略

 

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

01 发布策略

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

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

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

▲    并行发布

滚动发布

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

▲    滚动发布

蓝绿发布

这种发布策略是为了解决滚动发布中，承担负载的实例数量减少，可能会带来未知的压力，蓝绿部署的方式是，先额外创建一批新的实例，并更新版本，然后将流量切换到新的实例上，由新的一批实例对外提供服务，在测试观察新版本没有问题后，将旧的实例销毁。这种方式意味着在升级的过程中，需要同时运行两套程序，所需要的资源是日常的两倍。但是这种策略的好处是，不中断服务，并且在发布过程中出现了问题，可以快速回滚。

▲    蓝绿发布

金丝雀发布（灰度发布）

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

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

▲    金丝雀发布

02 发布窗口模式

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

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

▲    发布窗口模式

03 传统应用的发布场景

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

▲    传统应用发布场景

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

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

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

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

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

 

总结

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

本文由嘉为科技原创，转载请注明来源。