发明内容
有鉴于此,本发明的目的在于提出一种基于微服务的一体化发布管理平台,旨在解决现有中无法有效快速管理发布微服务等问题。
为实现上述目的,本发明提供一种基于微服务的一体化发布管理平台,所述平台包括:
服务树,用于与服务资源模块、服务管理模块和服务发布模块进行交互,为各个模块提供元数据;
服务资源模块,用于展示业务拓扑信息,所述业务拓扑信息包括服务基本信息、发布信息、配置信息、版本历史以及资源使用情况;
服务管理模块,用于管理服务基本信息、发布信息、配置信息以及资源配额;
服务发布模块,用于结合所述服务资源模块实现服务的发布,所述服务的发布基于所述服务资源模块以及所述服务管理模块的信息进行实现。
优选的,所述服务树的纵向维度用于表示所展示的业务服务信息,所述服务树的横向维度用于表示所关联各个模块的资源。
优选的,所述服务树包括:
第一展示单元,用于根据区域模型、环境模型、业务模型以及服务模型的层级结构展示所述服务树;
请求单元,用于根据用户请求获取所述服务树时,通过广度优先搜索算法构造出对应的所述服务树;
查询单元,用于根据指定索引列作为查询条件进行服务的查询;
定位单元,用于通过深度优先搜索算法进行模糊搜索,以实现服务的定位。
优选的,所述服务资源模块包括:
查看单元,用于根据所述服务树的导航查看服务信息;
第二展示单元,用于在用户切换不同的区域模型时,所述平台获取所述服务树对应的所述业务拓扑信息,并重新进行渲染展示;以及,在用户点击服务模型时展示对应的服务信息,其中,所述服务信息包括基础信息、Rollout信息、容器信息和Service信息。
优选的,所述基础信息包括服务名称、环境、资源环境、描述、Git代码仓库以及负责人;所述Rollout信息包括服务名称、目标副本数、当前副本数、已更新副本数以及可用副本数;所述容器信息包括请求CPU、限制CPU、请求内存、限制内存、就绪探针和存活探针;所述Service信息包括服务名称、集群IP、端口、类型、外部IP以及存活时长。
优选的,所述服务管理模块包括:
服务列表查看单元,所述服务列表查看单元与所述服务树联动,在用户切换不同的区域模型时,所述平台获取对应的服务列表信息;
服务编辑单元,用于编辑服务基础信息以及服务部署配置信息;
服务创建单元,用于在用户填写所述服务基础信息和所述服务部署配置信息后,所述平台与ArgoCD组件进行交互,以创建相关的项目并关联,并触发更新生成新的所述服务树缓存;
服务的上线和下线单元,用于通过所述平台调用ArgoCD组件进行下线相关资源、修改服务状态。
优选的,所述服务部署配置信息支持普通表单编辑和高级编辑,所述高级编辑包括编辑YAML。
优选的,所述服务发布模块包括:
服务部署单元,用于利用蓝绿部署策略进行实现服务部署,所述蓝绿部署策略的部署过程包括代码打标签、待部署、容器部署、切换流量以及完成部署;
服务回滚单元,用于实现服务的版本回滚;
服务重启单元,用于实现服务的重启操作;
服务扩缩容单元,用于通过所述服务管理模块进行修改服务的容器信息,并触发服务发布以完成服务扩容或服务缩容。
有益效果:
本发明实施例提供的发布管理平台包括服务树、服务资源模块、服务管理模块以及服务发布模块,能够提高服务发布效率、降低错误率,并满足7 * 24的运营需求。
通过本发明提供的发布管理平台进行服务管理、服务发布、回滚、重启和扩容,可以显著提高工作效率;该平台能够将这些复杂的操作自动化,降低了人工干预,从而大大缩短了服务发布和管理的时间。
通过本发明提供的发布管理平台能够有效地管理和跟踪服务配置,从而减少因配置错误导致的问题,降低错误率。
通过本发明提供的发布管理平台能够实现自动化的回滚、重启和扩容功能,可以快速响应服务,保证服务的高可用性。
通过本发明提供的发布管理平台将所有的服务管理和运维工作集中在一个地方,使得运维人员可以更方便地进行服务管理和运维,以提升运维便利性。
具体实施方式
为使本发明实施方式的目的、技术方案和优点更加清楚,下面将结合本发明实施方式中的附图,对本发明实施方式中的技术方案进行清楚、完整地描述,显然,所描述的实施方式是本发明一部分实施方式,而不是全部的实施方式。基于本发明中的实施方式,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式,都属于本发明保护的范围。因此,以下对在附图中提供的本发明的实施方式的详细描述并非旨在限制要求保护的本发明的范围,而是仅仅表示本发明的选定实施方式。基于本发明中的实施方式,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式,都属于本发明保护的范围。
在本发明的描述中,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。
以下结合实施例详细阐述本发明的内容。
目前如何在一个集成平台上有效地管理和发布微服务是迫切需要解决的痛点。其中包括服务管理的复杂性、低效的服务发布过程以及回滚、重启、扩容等操作的困难。对于微服务管理的复杂性:在微服务架构中,服务数量多,每个服务都具有自己的生命周期。管理这些服务,包括维护服务的配置信息(例如服务树),服务的编辑和编排,以及服务的生命周期管理(例如版本控制),都需要大量的人工参与,效率低下,且易出错。对于低效的服务发布过程:现有的服务发布方法,如手动操作和脚本化部署,都存在效率低下的问题。手动操作的效率低下,且容易出错;脚本化部署虽然能提高一定的效率,但需要人工编写和维护脚本,且难以处理复杂的部署情况。对于回滚、重启、扩容操作的困难:微服务的运维操作,如回滚、重启、扩容等,往往需要复杂的操作和大量的人工参与,且容易出错。上述问题的原因主要在于微服务架构的分布式特性和服务数量的大幅增加导致了管理和运维的复杂性增加,而现有的工具和方法无法有效地处理这种复杂性,从而导致管理和运维效率低下,错误率高。此外,现有的解决方案通常无法满足7 * 24的运营需求,这对于需要持续运营的大型软件系统来说是无法接受的。
基于此,本发明提出一种基于微服务的一体化发布管理平台,能够提高服务发布效率、降低错误率,并满足7 * 24的运营需求。
参照图1、图2所示为本发明一实施例提供的一种基于微服务的一体化发布管理平台的架构示意图。
本实施例中,该平台包括服务树、服务资源模块、服务管理模块以及服务发布模块。如图1中展示了该平台上述的模块与功能,以及主要的用户与使用场景,通过该平台实现标准化流程、自动化操作,使得开发人员、QA与运维通过该平台协作,提升效率。其中,
服务树,用于与服务资源模块、服务管理模块和服务发布模块进行交互,为各个模块提供元数据。
进一步的,所述服务树包括:
第一展示单元,用于根据区域模型、环境模型、业务模型以及服务模型的层级结构展示所述服务树;
请求单元,用于根据用户请求获取所述服务树时,通过广度优先搜索算法构造出对应的所述服务树;
查询单元,用于根据指定索引列作为查询条件进行服务的查询;
定位单元,用于通过深度优先搜索算法进行模糊搜索,以实现服务的定位。
在本实施例中,基于全球化的业务场景,设计了规范标准化业务拓扑的模型结构,以区域/环境/业务/服务为模型来展示服务树。在纵向维度展示服务信息,服务名作为的唯一ID(identification),横向维度关联各个模块的资源,与服务资源模块、服务管理模块和服务发布模块进行交互,提供元数据支撑。
服务树底层的服务元数据在数据库设计上包含区域、环境、业务字段以及其他详细信息。当用户请求获取服务树时,通过广度优先搜索算法(Breadth-First Search)构造出服务树。为了提升数据查询与构建服务树的速度,在底层设计了联合索引,并在查询时指定区域、环境、服务名为索引列作为查询条件,从而提升查询速度。由于服务树是一个耗性能的场景,且变化频率不高,通过引入了Redis,并在查询时判断数据是否过期,如果数据过期,会重新生成数据并将其缓存到Redis中。在平台上展示服务树时,用户可以输入关键字,平台前端通过实现深度优先搜索算法(Depth-First Search,DFS)进行模糊搜索,从而快速定位到服务,让用户了解服务相关的信息,从而提升日常工作效率。
服务资源模块,用于展示业务拓扑信息,所述业务拓扑信息包括服务基本信息、发布信息、配置信息、版本历史以及资源使用情况。
进一步的,所述服务资源模块包括:
查看单元,用于根据所述服务树的导航查看服务信息;
第二展示单元,用于在用户切换不同的区域模型时,所述平台获取所述服务树对应的所述业务拓扑信息,并重新进行渲染展示;以及,在用户点击服务模型时展示对应的服务信息,其中,所述服务信息包括基础信息、Rollout信息、容器信息和Service信息。
在本实施例中,该服务资源模块用于统一展示服务信息,提高开发人员发布效率;展示的信息包含服务信息、发布信息、配置信息、版本历史、资源使用情况的展示。该服务资源模块基于服务树的结构,在平台上展示业务拓扑信息。用户可以根据服务树的导航查看服务信息。当用户切换不同区域后,平台会请求后端获取服务树的业务拓扑信息,并刷新显示业务拓扑信息。当用户点击服务后,平台会展示服务信息。服务信息包括基础信息、Rollout信息、容器信息和Service信息等。其中,
基础信息包括:名称、环境、资源环境、描述、Git代码仓库以及负责人等。
服务资源模块包含Kubernetes(开源容器编排平台)以及ArgoCD(一个遵循声明式GitOps理念的持续部署(CD)工具)这两个组件的一些相关资源信息。
Rollout信息是ArgoCD组件相关的信息,在展示时需要调用ArgoCD组件的API(Application Programming Interface)获取实时信息,包括:名称、目标副本数(DESIRED)、当前副本数(CURRENT)、已更新副本数(UPDATED)以及可用副本数(AVAILABLE)。
容器信息包括:请求CPU、限制CPU、请求内存、限制内存、就绪探针和存活探针等。在展示时,需要先调用ArgoCD组件,然后通过ArgoCD组件调用Kubernetes组件来获取这些信息。
Service信息包括:名称、集群IP、端口、类型、外部IP以及存活时长等。在展示时,同样需要先调用ArgoCD组件,然后通过ArgoCD组件调用Kubernetes组件来获取这些信息。
服务管理模块,用于管理服务基本信息、发布信息、配置信息以及资源配额。
进一步的,所述服务管理模块包括:
服务列表查看单元,所述服务列表查看单元与所述服务树联动,在用户切换不同的区域模型时,所述平台获取对应的服务列表信息;
服务编辑单元,用于编辑服务基础信息以及服务部署配置信息;
服务创建单元,用于在用户填写所述服务基础信息和所述服务部署配置信息后,所述平台与ArgoCD组件进行交互,以创建相关的项目并关联,并触发更新生成新的所述服务树缓存;
服务的上线和下线单元,用于通过所述平台调用ArgoCD组件进行下线相关资源、修改服务状态。
在本实施例中,服务管理模块用于管理服务基本信息、发布信息、配置信息、资源配额,为自动化做铺垫。
服务资源模块的主要用户是非运维人员,而服务管理模块所能修改的内容与服务资源模块展示的内容一致。由于服务管理模块的操作可能会影响在线服务,因此它主要面向运维人员。通过对用户信息的维护,实现权限控制功能。
服务管理模块的功能包括服务列表查看、服务编辑、服务创建以及服务的上线和下线。其中,服务列表与服务树是联动的,当切换区域时,可以获取不同区域对应的服务列表。同时,用户可以通过状态和关键词搜索来快速找到想要管理的服务。
服务的管理基于两个基础组件:Kubernetes(开源容器编排平台)和ArgoCD(一个遵循声明式GitOps理念的持续部署(CD)工具)。平台与这两个基础组件交互,实现服务管理模块的功能。
服务编辑主要包括两部分内容:基础信息和服务部署配置信息(即YAML配置)。在编辑服务时,在全局范围内实现了服务级别的分布式互斥锁,以防止多人同时编辑导致在线错误。锁定后,会生成一个编辑会话,在编辑会话期间,前端和服务器将定期进行通信以保持会话活跃,如果服务器在预设时间内(如5分钟内)未收到保持会话活跃的请求,会自动解锁,避免个人长时间未操作导致的长期占用。
服务部署配置信息支持普通表单编辑和高级编辑(编辑YAML)。在保存时,平台通过调用Kubeconform组件(使用Kubernetes的JSON schema来验证配置信息是否正确)来验证YAML配置信息是否符合Kubernetes的配置规范,验证通过后,再进行会话验证,最后保存。在编辑过程中,可以使用对比功能来防止错误的修改,即从Git中拉取保存的YAML配置进行对比;也可以通过“对比线上”功能,实时查询ArgoCD中的YAML配置进行对比,从而大大降低错误修改的可能性。
服务创建,用户需要填写基础信息和服务部署配置信息。然后平台将与ArgoCD交互,创建相关的项目并关联,同时保存到数据库,并触发更新生成新的服务树缓存。
对于服务的上线和下线操作,平台会调用ArgoCD来下线相关资源,修改服务状态,然后保存到数据库。
服务发布模块,用于结合所述服务资源模块实现服务的发布,所述服务的发布基于所述服务资源模块以及所述服务管理模块的信息进行实现。
进一步的,所述服务发布模块包括:
服务部署单元,用于利用蓝绿部署策略进行实现服务部署,所述蓝绿部署策略的部署过程包括代码打标签、待部署、容器部署、切换流量以及完成部署;
服务回滚单元,用于实现服务的版本回滚;
服务重启单元,用于实现服务的重启操作;
服务扩缩容单元,用于通过所述服务管理模块进行修改服务的容器信息,并触发服务发布以完成服务扩容或服务缩容。
在本实施例中,服务发布模块结合服务资源模块,提供自助化发布功能实现服务的发布,包括服务部署、回滚、重启、扩缩容等,提高效率。
服务的发布依赖于服务资源模块和服务管理模块的信息。平台将服务部署设计为蓝绿部署策略,其对应的部署步骤包括:代码打标签 ->待部署 ->容器部署 ->切换流量 ->完成。
服务的发布过程包括:研发人员选择代码的标签,填写发布说明,然后开始发布。发布过程中,平台会调用Kubernetes集群api-server的接口,获取集群的资源使用信息,如果计算出的资源使用率超过预设值(如90%),平台会提示用户是否继续发布,如果用户确认继续发布,平台首先会调用GitLab接口,修改服务对应的YAML中的镜像标签,修改成功后,平台会调用ArgoCD来触发发布,服务状态随后会更新为“发布中”。发布进度页面会显示从ArgoCD获取的实时发布信息。因为采用的是蓝绿部署,当新版本的服务全部启动后,平台会提示用户进行切换流量的操作。用户确认切换后,所有的业务请求都会转发到新版本的服务上,然后ArgoCD会销毁旧版本的服务并回收资源。这样,整个服务发布流程就结束了。平台会同步状态,并保存相关的操作日志。
服务回滚和重启的过程与服务发布流程及实现完全一致(具体参见上述过程)。
在进行服务扩容或缩容时,可以通过服务管理模块来修改服务容器资源的配额信息,比如修改请求CPU、限制CPU、请求内存、限制内存等,然后进行服务发布,从而完成服务的扩容或缩容。通过本实施例提出的发布管理平台能够提高发布效率、降低错误率、提高运维的便利性;通过自动化的回滚、重启和扩容功能,可以快速响应服务,提高服务可用性。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
上述说明示出并描述了本发明的优选实施例,应当理解本发明并非局限于本文所披露的形式,不应看作是对其他实施例的排除,而可用于各种其他组合、修改和环境,并能够在本文发明构想范围内,通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围,则都应在本发明所附权利要求的保护范围内。