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

用户头像
嘉为蓝鲸
关注
发布于: 4 小时前
【应用运维】公司业务迭代迅速,运维如何高效进行应用发布?

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



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



应用发布存在的问题



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



应用迭代频率高

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



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

发布于: 4 小时前 阅读数: 4
用户头像

嘉为蓝鲸

关注

研运至简,无限可为 2020.08.13 加入

蓝鲸智云一级技术合作伙伴,中国领先的研发运营一体化解决方案提供商

评论

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