首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

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

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

应用发布存在的问题

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

应用迭代频率高

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

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

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/b4db901ea5029eb2f5fcc5753
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券