Qunar应用全生命周期管理平台-portal


背景介绍


qunar是一家技术文化非常浓厚的公司,在追求业务飞速发展的同时,也非常注重产品质量的提高和工作效率的提升,因此各种各样的解决方案应用而生,而很多的解决方案最终落地为相应的工具或者管理平台。这些工具或管理平台给大家的日常工作带来了许多便捷,但是同时也引入了新的问题,比较关键的有以下几个:


1) 平台工具太多,增加了工程师的学习成本。工程师们除了需要专注于自己主要的工作内容外,还需了解各种各样的平台工具,无形中降低了工作效率;


2) 平台工具间的切换增加了时间成本,提高了出错概率。如一个应用从需求到上线,先要到PMO创建需求,再到应用中心申请appcode,然后再到应用树申请机器,再到发布系统编辑配置创建job,再到ops平台申请权限,然后发布,再到监控平台查看监控等等,过程中如有被打断,很容易出错,造成不可挽回的损失; 

  

3) 系统之间的壁垒严重,导致信息搬运和数据不一致。有些系统之间的数据存在上下游的依赖,如应用树申请机器后,需要人工copy到万事屋后发布才能获取到,如果有机器新增或者回收,很可能导致数据不一致;有些同类信息不同系统数据不一致,如应用树结构和watcher树结构,数据统计等无法确定统一标准;


4) 不同运维部门基于不同的维度提供服务,但是通常用户场景涉及多个服务,因而难以保证用户使用场景下完整服务的可靠性和稳定性。如一次发布过程,数据等已经准备完成,但是在上线过程却遇到发布账号无法登录机器的问题。发布逻辑是由CM控制,机器账号权限管理却在ops处维护,双方都只是保证自己服务的可靠性,但是对于中间对接环节的服务校验却成了盲区,如果能通过消息机制等保证上下游消息的稳定提供与正常消费,基于用户场景的服务提供和支持将会更加稳定和可靠。


为了解决这些问题,我们参考了scrum和devops管理思想和方法论,落地为工具——Portal,它是OPS、TC和CM联手打造的应用全生命周期管理平台,集成了应用管理、持续集成、线上发布、自助运维、线上监控、权限管理等功能,为工程师提供一站式解决方案,保证质量的同时提升效率,实现持续交付。


架构介绍

在动手之前,我们分析了现状,首先,ops同学已经提供了功能丰富的运维平台,但主要围绕机器,包括机器创建销毁,机器组件自助运维,监控告警等,然而机器是应用的承载,关注机器其实是对应用的关注。应用中心应用的注册、事件链路跟踪管理等都是以应用为单位,而且每个应用有一个唯一的标识appcode。发布系统虽然比较智能,但是主要以工程为单位,但是工程并非应用的最小单元,后续跟踪及数据统计比较难达到理想效果。综合分析以上三足鼎立的现状不难发现,应用是把它们串联起来的最小单位,因此将应用中心的appcode扩展到运维和发布领域,这个唯一标识就确定了。再次,从背景分析中,不同的服务模块之间既有服务的依赖性,又有数据的依赖性,因此一个服务的变更必须通知下游系统,因此我们采用已经搭建好的信息中心,所有系统定义自己的变更事件,并将变更事件消息推送到消息中心,依赖系统通过消费消息同步自己的数据,保证数据的一致性。最后,我们提供统一的web入口,为用户提供一站式应用注册,操作,发布,机器运维等入口,解决用户系统切换的问题。基础架构如下:

以上是我们第一阶段的架构图,主要是实现现有功能的整合,提供一站式用户服务平台。然而即使实现第一步,当前操作也主要依靠程序员自发,复杂业务场景更是困难重重。俗话说,罗马非一日建成,当数据积累到一定阶段,我们会逐步实现以事件驱动的自动化,实现以场景驱动的智能化。


功能介绍


1. 集中的应用信息展示


一个应用的信息包括管理员、所在树节点、创建时间等基本信息,还包含所属代码路径、部署路径、端口等发布信息,同时还包含机器及机器环境信息,应用日志信息等,以前如果想要完全获取这些信息需要切换应用树、应用中心、万事屋等多个系统,而像机器Jdk、tomcat等版本只能登陆机器查询,而通常一个应用会有多台机器,由于没有统一的入口,不同机器版本不同是很常见的现象,这样就给后续运维应用升级等带来了很大隐患。

根据用户的需求和使用频率,我们最终选定了以下三个模块进行集中展示:

1)左侧为应用的属性配置等静态信息,包括基本配置、发布运维参数等,便于用户直观查看应用当前状况,应用的管理员可以进行日常维护;

2)右侧上半部分是应用的近期变更事件,类型包括FULL_GC、最近发布、配置变更、定时任务、机器启动、自定义,便于用户掌握应用最新动态,如果服务有异常告警,可根据此处变更事件快速排查定位问题;

3)右侧下半部分是应用的机器环境信息,应用管理员可以在此处管理应用的机器,包括编辑机器归属、分组、批次、调整机器顺序等,同时此处还会展示机器自身信息,包括jdk版本、Tomcat版本、机器当前部署版本等,解决了信息查询困难问题,除此之外,此处可以对机器进行批量的重启下线操作,解决了开发人员直接登录机器操作的风险和多台机器操作缓慢的问题。


2. 统一的应用管理入口

      

portal提供了应用维度的统一配置入口,既可以创建应用,也可以直接编辑基础信息、发布信息、机器环境信息等,还可方便的管理应用的机器资源,如主机申请回收、机器扩容、jdk升级(开发中)等,而且所有这些信息都是所见即所得,直接使用,用户不需要针对不同的使用场景进行信息搬运,减少了冗余数据、降低了维护的成本和出错的概率;


3. 智能便捷的发布过程

以前发布,用户需要先在万事屋创建schema(不同的环境需要重复编辑多次原路径、部署路径等信息,机器还需要从应用树copy),然后再创建job,然后切换到发布系统发布,发布过程日志复杂繁琐,内嵌多层链接,发布进程对用户貌似一个黑盒子,排查问题非常不方便,因而我们在portal做了完全改造,用户只需要编辑一份应用的发布参数,并将机器挂到应用对应的环境下,就可直接发布。同时当用户确认发布时,会给出发布信息预览,包括CI执行结果、本地发布端口、路径、机器批次详情等信息,让用户double check,避免不必要的错误,同时发布过程可视化的流程图让用户直观查看当前部署进度,便于排查问题;


4. 方便可追溯的权限管理


以前由于不同功能来源于不同的工具或平台,不同的工具平台又有不同的提供方,因此不同的权限入口不统一,授权策略也不同,拿发布来举例,dev和beta发布除与git相关的默认内置权限外,其他申请入口是在万事屋,方式是找job owner主动赋权,而线上发布又需要到ops入口申请,方式是流程审批,过程繁琐,新人很容易蒙圈,portal上对此做了改造。首先我们提供统一的权限申请入口,将各个模块的申请入口集成,包含qconfig配置修改、应用owner,成员、应用树owner、成员、应用开发成员、QA成员、线上发布成员等,同时对于申请方式的授权,记录详细的申请审批流水,便于日后追踪。同时,TC同学正在搭建qunar自己的IAM(Identity and Access Management),未来我们可以方便快捷的定义各种授权策略、用户组等,从而按用户属性、角色、组和动态组对各个业务模块进行权限访问控制。

 

由于Portal的功能由ops、TC、应用中心共同完成,以上只是基础的功能优化介绍,后续会有单贴详细介绍各个模块的详尽功能优化过程和改进点。


未来展望

目前,我们已经重新改造了发布模块,结合了持续集成cable,丰富了基础环境搭建,自助运维模块,新增了权限管理,集成了watcher实现了应用维度的持续监控和告警,形成了基本的devops回路,然而离目标依然还有很远,未来我们将在以下三个方面努力:

1)功能方面:在保证现有功能稳定性、易用性、可靠性的同时,继续扩充工具链路,将大家常用的或者经常用的工具集成进来,如环境管理Noah,需求管理奥丁等,打造完整的devops工具回路。

2)自动化方面:正如前文所说,目前应用生命周期中的大部分操作主要还是基于用户的自发和手动,当我们梳理清楚完整的业务流程,打造完整的工具链条,便可最大程度的实现过程自动化,如新增机器的自动授权、机器服务组件的自动升级、根据服务异常报警进行自动业务回滚、根据流量监控实现服务的自动缩容扩容等,尽可能的将大家从手工劳动中解放出来。

3)智能化方面:由于系统的打通,数据的可追溯和积累,可以为业务分析、数据处理提供可靠依据,同时可基于数据分析,挖掘问题现象背后根源,提供更优解决方案,并实现场景驱动的智能化。