CN111831269A - 一种应用开发系统、运行方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种应用开发系统、运行方法、设备及存储介质，所述系统，包括：交互层，用于提供操作界面，并将在操作界面上触发的创建请求发送到开发层，接收并显示已完成微服务；创建请求用于请求创建待开发业务事项的微服务；开发层，用于根据微服务生成调用请求，向中间层发送调用请求，以调用目标中间组件；进而在微服务框架中，利用目标中间组件创建业务事项的已完成微服务；中间层，用于向容器层发送调用请求，以调用目标容器，利用目标容器创建目标中间组件；容器层，用于提供搭建不同中间组件的至少两个容器，响应于调用请求，向中间层反馈目标容器；这样，能够使得开发人员专注于业务开发，从而提升研发效率。

Description

一种应用开发系统、运行方法、设备及存储介质

技术领域

本申请涉及计算机领域，尤其涉及一种应用开发系统、运行方法、设备及存储介质。

背景技术

大部分业务系统的建设开发中，每一个部门下面都有很多商家来实现这些功能，每一个部门对接的开发人员的研发标准不同，所以不同的开发人员需要配置不同的开发环境。这样，对于整个业务系统来说，开发速率较慢且消耗成本较高。

发明内容

本申请实施例提供一种应用开发系统、运行方法、设备及存储介质，通过统一不同开发人员的开发环境，能够使得开发人员专注于业务开发，从而提升研发效率。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种应用开发系统，包括：交互层，用于提供操作界面，并将在所述操作界面上触发的创建请求发送到开发层；所述创建请求用于请求创建待开发业务事项的微服务；所述开发层，用于根据所述微服务生成调用请求，向中间层发送所述调用请求，以调用目标中间组件；进而在微服务框架中，利用所述目标中间组件创建所述业务事项的已完成微服务，并将所述已完成微服务反馈至所述交互层；其中，所述微服务框架能够支持实现任意类型的业务事项；中间层，用于向容器层发送所述调用请求，以调用目标容器，利用所述目标容器创建所述目标中间组件；所述容器层，用于提供搭建不同中间组件的至少两个容器，响应于所述调用请求，向所述中间层反馈所述目标容器；所述交互层，用于接收并显示所述已完成微服务。

在一些实施例中，所述交互层，包括：日志管理平台，用于对获取的所述应用开发系统的工作日志进行处理，并将处理结果反馈至所述操作界面；所述操作界面，还用于接收所述日志管理平台反馈的所述处理结果，并对所述处理结果进行显示。

在一些实施例中，所述日志管理平台，包括：日志收集模块，设置于所述应用开发系统下的设备集群中的每一设备中，用于获取所述每一设备的工作日志，并将所述每一设备的工作日志发送至日志监测模块；所述日志监测模块，用于对所述每一设备的工作日志进行监测，当监测到所述工作日志中存在满足预设条件的异常信息时，向所述操作界面反馈告警信息，以使所述告警信息显示在所述操作界面。

在一些实施例中，所述容器层，包括：第一认证平台，用于对所述调用请求进行验证，如果所述调用请求满足认证条件，响应于所述调用请求，向所述中间层反馈所述目标容器；第二认证平台，用于当所述第一认证平台处于故障状态时，对所述调用请求进行验证，如果所述调用请求满足所述认证条件，向所述中间层反馈所述目标容器。

在一些实施例中，所述第二认证平台，包括：认证模块，用于当所述第一认证平台处于故障状态时，对所述调用请求进行验证，如果所述调用请求满足所述认证条件，向接口服务器反馈所述调用请求；接口服务器，用于响应所述调用请求，向所述中间层反馈所述目标容器。

第二方面，本申请实施例提供一种应用开发系统的运行方法，所述方法包括：采用交互层提供操作界面，并将在所述操作界面上触发的创建请求发送到开发层；所述创建请求用于请求创建待开发业务事项的微服务；采用所述开发层根据所述微服务生成调用请求，向中间层发送所述调用请求，以调用目标中间组件；采用所述中间层向容器层发送所述调用请求，以调用目标容器；采用所述容器层提供搭建不同中间组件的至少两个容器，响应于所述调用请求，向所述中间层反馈所述目标容器；采用所述中间层利用所述目标容器创建所述目标中间组件，并将所述目标中间组件发送给所述开发层；采用所述开发层，在微服务框架中，利用所述目标中间组件创建所述业务事项的已完成微服务，并将所述已完成微服务反馈至所述交互层；其中，所述微服务框架能够支持实现任意类型的业务事项；在所述交互层接收并显示所述已完成微服务。

在一些实施例中，所述开发层包括微服务平台和持续发布平台，所述采用所述开发层，在微服务框架中，利用所述目标中间组件创建所述业务事项的已完成微服务，包括：采用微服务平台根据获取的所述开发层运行环境的配置信息，搭建所述微服务框架；采用所述微服务平台在所述微服务框架中利用所述目标中间组件创建所述业务事项的已完成微服务；采用持续发布平台对所述微服务框架中输入的用于实现业务事项的开发代码进行管理，并发布所述已完成微服务。

在一些实施例中，所述微服务包括管理界面和组件模块，所述采用所述微服务平台在所述微服务框架中利用所述目标中间组件创建所述业务事项的已完成微服务，包括：采用所述管理界面接收所述创建请求，根据所述微服务生成所述调用请求，并将所述调用请求传递至组件模块；采用所述组件模块将所述调用请求发送至所述中间层，在所述框架中，根据在所述中间层调用的目标中间组件，创建所述已完成微服务。

在一些实施例中，所述微服务还包括监控模块、拓扑模块和链路追踪模块，所述方法还包括：采用所述监控模块对所述组件模块中的中间组件进行监控，并将监控结果发送至所述交互层，以在所述操作界面上进行显示；采用所述拓扑模块确定所述组件模块中的中间组件之间的拓扑关系，并根据所述拓扑关系，更新所述组件模块中的中间组件；采用所述链路追踪模块对所述已完成微服务的运行链路进行追踪，将运行出现故障的链路反馈至所述交互层，以在所述交互层的操作界面显示所述出现故障的链路。

在一些实施例中，所述采用持续发布平台包括存储库模块和镜像模块，所述采用持续发布平台对所述微服务框架中输入的用于实现业务事项的开发代码进行管理，并发布所述已完成微服务，包括：采用存储库模块获取并存储在所述微服务框架中输入的开发代码；采用所述发布模块根据所述开发代码，向镜像模块发送调用指令，以调用相匹配的镜像文件；采用所述镜像模块根据运行所述开发代码所需要的数据包，创建并存储镜像文件；采用所述发布模块根据所述镜像文件，部署能够发布所述已完成微服务的发布环境。

在一些实施例中，所述中间层包括中间件平台和通用组件平台，所述采用所述中间层利用所述目标容器创建所述目标中间组件，并将所述目标中间组件发送给所述开发层，包括：采用所述中间件平台提供用于创建不同待创建服务的至少两个中间组件；根据从所述容器层调用的所述目标容器，搭建所述目标中间组件，并将所述目标中间组件发送给所述开发层的微服务平台；采用所述通用组件平台提供预先编订的预设中间组件，所述预设中间组件的被调用频率大于等于预设频率，且所述预设中间组件能够根据输入的编辑指令进行更新，以得到更新的预设中间组件。

在一些实施例中，所述中间件平台包括前端显示界面、容器模块和容器仓库，所述采用所述中间件平台根据从所述容器层调用的所述目标容器，搭建所述目标中间组件，并将所述目标中间组件发送给所述开发层的微服务平台，包括：采用所述容器模块接收所述调用请求，向所述中间件平台的容器仓库发送加载指令，以加载所述目标容器，并将根据所述目标容器搭建的目标中间组件反馈至前端显示界面进行显示；采用所述容器仓库响应于所述加载指令，从所述容器层获取目标容器，并将所述目标容器反馈至所述容器模块；采用前端显示界面显示所述至少两个中间组件；所述前端显示界面包含于所述操作界面。

在一些实施例中，所述交互层包括日志管理平台和操作界面，所述在所述交互层接收并显示所述已完成微服务，包括：采用所述日志管理平台对获取的所述应用开发系统的工作日志进行处理，并将处理结果反馈至所述操作界面；采用所述操作界面接收所述日志管理平台反馈的所述处理结果，并对所述处理结果进行显示。

在一些实施例中，所述日志管理平台包括日志收集模块和日志监测模块，所述采用所述日志管理平台对获取的所述应用开发系统的工作日志进行处理，并将处理结果反馈至所述操作界面，包括：将所述日志收集模块设置于所述应用开发系统下的设备集群中的每一设备中；采用所述日志收集模块获取所述每一设备的工作日志，并将所述每一设备的工作日志发送至日志监测模块；采用所述日志监测模块对所述每一设备的工作日志进行监测，当监测到所述工作日志中存在满足预设条件的异常信息时，向所述操作界面反馈告警信息，以使所述告警信息显示在所述操作界面。

在一些实施例中，所述容器层包括第一认证平台和第二认证平台，所述采用所述容器层提供搭建不同中间组件的至少两个容器，响应于所述调用请求，向所述中间层反馈所述目标容器，包括：采用所述第一认证平台对所述调用请求进行验证，如果所述调用请求满足认证条件，响应于所述调用请求，向所述中间层反馈所述目标容器；当所述第一认证平台处于故障状态时，采用所述第二认证平台对所述调用请求进行验证，如果所述调用请求满足所述认证条件，向所述中间层反馈所述目标容器。

在一些实施例中，所述第二认证平台包括认证模块和接口服务器，所述当所述第一认证平台处于故障状态时，采用所述第二认证平台对所述调用请求进行验证，如果所述调用请求满足所述认证条件，向所述中间层反馈所述目标容器，包括：当所述第一认证平台处于故障状态时，采用所述认证模块对所述调用请求进行验证，如果所述调用请求满足所述认证条件，向接口服务器反馈所述调用请求；采用所述接口服务器响应所述调用请求，向所述中间层反馈所述目标容器。

第三方面，本申请实施例提供一种异常账号检测的设备，包括：存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现上述应用开发系统的运行方法。

第四方面，本申请实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的应用开发系统的运行方法。

本申请实施例具有以下有益效果：通过提供支持实现多服务业务的不同开发代码的应用开发系统，对于不同的开发人员在操作界面输入的调用请求均能够进行响应，以搭建实现该调用请求针对事项的已完成微服务；这样，统一了不同开发人员的开发环境，能够使得开发人员专注于业务开发，从而节省了开发人员的时间，提升了研发效率。

附图说明

图1A是本申请实施例提供的应用开发系统的另一个可选的架构示意图；

图1B是本申请实施例提供的应用开发系统的架构示意图；

图2是本申请实施例提供的应用开发系统的另一架构示意图；

图3A是本申请实施例提供的应用开发系统的另一架构示意图；

图3B是本申请实施例提供的应用开发系统的又一架构示意图；

图4是本申请实施例提供的实现应用开发系统的运行方法的流程示意图；

图5是本申请实施例提供的云应用开发中台的框架示意图；

图6是本申请实施例容器平台的组成架构示意图；

图7是本申请实施例提供的中间件平台的组成架构示意图；

图8本申请实施例提供的通用组件的组成架构示意图；

图9本申请实施例提供的微服务平台的组成架构示意图；

图10是本申请实施例链路追踪的显示界面图；

图11是本申请实施例拓扑结构的显示界面图；

图12是本申请实施例数据显示的显示界面图；

图13本申请实施例提供的持续集成发布流程的组成架构示意图；

图14本申请实施例提供的运营平台的组成架构示意图；

图15是本申请实施例提供的云应用开发平台的功能展示图；

图16是本申请实施例提供的云应用开发平台的组成结构示意图；

图17是本申请实施例提供的在云应用开发中台进开发的流程示意图；

图18是本申请实施例提供的在云应用开发中台进行运维的流程示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)微服务：指的是用于采用高度可配置和可缩放方式来划分功能性的框架，其能够将期望的功能无缝地封装在包装器中，而无需系统设计者在设计时知道功能将如何或在哪些资源上被实行。在本申请实施例中，微服务可以理解为是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用超文本传输应用程序接口协议(HyperText Transfer Protocol ApplicationProgramming Interface，HTTP API)通讯。同时，服务会使用最小规模的集中管理(例如应用容器引擎(Docker))技术，服务可以用不同的编程语言与数据库等。

2)软件包管理器中的程序包(Helm Chart)：本地客户端，管理本地的程序包仓库，管理程序包，与服务器交互，发送程序包，实例安装、查询、卸载等操作。

3)容器：有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。与虚拟化相比，这样既不需要指令级模拟，也不需要即时编译。容器可以在核心处理器本地运行指令，而不需要任何专门的解释机制。此外，也避免了准虚拟化和系统调用替换中的复杂性。

4)云技术(Cloud Technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

5)云存储(Cloud Storage)，是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

在相关技术中，大中型企业的大部分业务系统的建设开发技术架构体系都比较落后(比如，政企部门的业务系统)，已经无法应对数字企业的发展需求，无论是性能需求，功能需求，还是业务需求的不断提升，传统的技术架构体系没发快速响应和应对，同时对于大中型企业的数字化改革和推进也提高很大的时间和财利成本。

团队协同成本高：一个人社的业务系统超过3000个功能模块，开发团队按照不同的业务类型分组进行开发。每一次系统的功能升级，都会导致整个几十人的团队把时间花费在协同工作上。

应用复杂度高：大中型企业的行业业务规模越来越庞大，业务复杂度也越来越高，传统的技术架构会牵一发动全身，任何一个小的问题都有可能造成应用实例的崩溃，从而影响到整个系统平台的正常运行。

数据库扩展能力弱：传统的政务应用系统的所有业务功能均在一个应用中，所有的数据也均保存在同一个数据库集群中，而数据库集群的数据库连接数量是有上限的，这就造成数据库连接数量的资源随着政务应用实例数量的增加而越来越捉襟见肘，有些厂商在政务应用的代码方面做了很多优化，会对应用实例的连接池大小进行压缩，但是大型省级平台或者国家平台的峰值数据库连接数量还是会达到数据库的上限，应用系统因为过高的数据库连接处于一个非常不稳定的状态。

应用扩展能力弱：一个包含上千个功能模块的压缩包所需要的初始化和运行资源就不会太小，使得需要采用较高资源配置的服务器支撑应用实例的运行。更重要的是，系统在出现业务处理瓶颈的时候，只是由于某一个或几个功能模块负载较高造成的，但因为所有的功能模块都打包在一起，所以在出现性能问题并且需要通过增加应用实例的方式分担服务负载时，则没法对单独的几个功能模块进行服务能力扩展，而只能将整个完整的应用进行扩容，带来了资源额外配置的消耗，成本较高。

应用开发技术框架不统一：数字化政企系统的各个部门平台项目开发，每个项目涉及众多开发厂商，开发厂商开发能力参差不齐，没有统一技术标准。

基于此，本申请实施例通过云应用开发中台提供统一、高质量的开发框架和技术组件，组织开发商进行相应的培训，将参与数字企业建设的各个开发商的技术能力提升到比较高的水平，从研发团队技术能力上保障数字化政企信息化的高质量。数字化政企系统中各个部门的应用在云应用开发中台之上快速开发、快速部署，并在应用中可根据需要快速迭代。

本申请实施例提供的应用开发系统结合A省数字化政企系统建设情况，根据该数字化政企系统的数字化系统开发的应用场景定制组合云应用开发中台的技术组件进行快速开发。支持传统技术架构升级分布式架构、微服务架构，可结合应用场景和项目组合定制高性能、高可用、高并发系统架构。该系统支持版本化，可经验复用、快速落地，一键安装，还支持政务应用系统开发完整的开发体系。如此，

下面说明本申请实施例提供的应用开发系统的示例性应用，本申请实施例提供的终端可以实施为各种类型的用户设备，也可以实施为服务器。下面，将说明终端实施为设备或服务器时示例性应用。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。参见图1A，图1A是本申请实施例提供的应用开发系统的另一个可选的架构示意图，包括区块链网络20(示例性示出了作为原生节点的应用开发系统200)、监测系统30(示例性示出归属于监测系统30的设备300及其图形界面301)，下面分别进行说明。

区块链网络20的类型是灵活多样的，例如可以为公有链、私有链或联盟链中的任意一种。以公有链为例，任何业务主体的电子设备例如用户设备和服务器，都可以在不需要授权的情况下接入区块链网络20；以联盟链为例，业务主体在获得授权后其下辖的电子设备(例如设备/服务器)可以接入区块链网络20，此时，成为区块链网络20中的一类特殊的节点即终端节点。

需要指出地，终端节点可以只提供支持业务主体发起交易(例如，用于上链存储数据或查询链上数据)功能，对于区块链网络20的原生节点的功能，例如下文所述的排序功能、共识服务和账本功能等，终端节点可以缺省或者有选择性(例如，取决于业务主体的具体业务需求)地实现。从而，可以将业务主体的数据和业务处理逻辑最大程度迁移到区块链网络20中，通过区块链网络20实现数据和业务处理过程的可信和可追溯。

区块链网络20接收来自业务主体(例如图1A中示出的监测系统30)的终端节点(例如，图1A中示出的归属于监测系统30的设备300)提交的交易，执行交易以更新账本或者查询账本，并在设备的用户界面(例如，设备300的图形界面301)显示执行交易的各种中间结果或最终结果。

下面以监测系统接入区块链网络以实现应用开发系统的上链为例说明区块链网络的示例性应用。

监测系统30的设备300接入区块链网络20，成为区块链网络20的终端节点。设备300通过传感器获取调用请求；并且，将最终确定的已完成微服务反馈给区块链网络20中的应用开发系统200或者保存在设备300中；在已对设备300部署上传逻辑或用户进行操作的情况下，设备300根据待处理任务/同步时间查询请求，生成对应更新操作/查询操作的交易，在交易中指定了实现更新操作/查询操作需要调用的智能合约、以及向智能合约传递的参数，交易还携带了监测系统30签署的数字签名(例如，使用监测系统30的数字证书中的私钥，对交易的摘要进行加密得到)，并将交易广播到区块链网络20。其中，数字证书可由监测系统30向认证中心31进行登记注册得到。区块链网络20中的原生节点，例如应用开发系统200在接收到交易时，对交易携带的数字签名进行验证，数字签名验证成功后，根据交易中携带的监测系统30的身份，确认监测系统30是否是具有交易权限，数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后签署原生节点自己的数字签名(例如，使用原生节点的私钥对交易的摘要进行加密得到)，并继续在区块链网络20中广播。区块链网络20中具有排序功能的节点接收到验证成功的交易后，将交易填充到新的区块中，并广播到区块链网络20中提供共识服务的节点。区块链网络20中的提供共识服务的节点对新区块进行共识过程以达成一致，提供账本功能的节点将新区块追加到区块链的尾部，并执行新区块中的交易：对于交互层触发的调用请求，开发层通过在中间层调用目标中间组件，完成微服务的搭建，并将已完成微服务显示于设备300的图形界面301中。

区块链网络20中的原生节点可从区块链中读取调用请求，并将调用请求呈现于原生节点的监测页面，原生节点也可以在在区块链中，响应调用请求部署该应用开发系统，以实现政务服务事项的开发。

在实际应用中，可为区块链网络20的不同原生节点设置不同的功能，例如设置应用开发系统200具有中间组件的调用功能和记账功能。对于该情况，可在交易过程中，应用开发系统200接收设备300输入的调用请求，在应用开发系统200中，通过提供支持多设备输入的调用请求的应用开发系统，对于不同的开发人员在操作界面输入的调用请求均能够进行响应，这样统一了不同开发设备的开发环境，能够使得开发人员专注于业务开发，从而提升开发效率。

将结合本申请实施例提供的设备的示例性应用和实施，说明本申请实施例提供的应用开发系统。

参见图1B，图1B是本申请实施例提供的应用开发系统的架构示意图，进行以下说明：

交互层101，用于提供操作界面，并将在操作界面上触发的创建请求发送到开发层。

在一些实施例中，创建请求用于请求创建待开发业务事项的微服务。该应用开发系统可以应用于任意类型的包括多种实现模块的大型或中型系统中，比如，应用于包括多部门的政务应用系统中，还可以应用于包括多科目的教育系统、多部门的大型企业的系统或道路交通系统等。操作界面用于提供给开发人员，当需要对某一政务服务事项进行开发时，开发人员在该操作界面上输入的调用请求，通过将该调用请求发送到开发层，从而调用实现该政务服务事项的中间件，进而实现政务服务事项的开发，即得到并显示已完成微服务。在一些具体例子中，已完成微服务可以理解是能够实现政务服务事项对应功能的一个模块。

开发层102，用于根据微服务生成调用请求，向中间层发送调用请求，以调用目标中间组件；进而在微服务框架中，利用目标中间组件创建业务事项的已完成微服务，并将已完成微服务反馈至交互层。

在一些实施例中，中间组件包括：关系型数据库管理系统(MySQL)、队列(kafka)、远程字典服务(Redis)、搜索服务器(elastic)、基于分布式文件存储的数据库(mongoDB)、非关系型数据库(Not Only Structured Query Language，NoSQL)、数据库(Cassander)、对象存储服务(MINIO)、消息队列(RabbitMQ)和反向代理全球广域网(World Wide Web，web)服务器(Nginx)等。目标中间组件为中间层的组件中的与调用请求匹配的组件。微服务框架能够支持实现任意类型的政务服务事项，还可以理解为微服务框架能够支持实现至少两类事项的不同开发代码的运行；也就是说，该微服务框架能够在任意厂商的开发环境下供开发人员进行政务服务事项的开发。在开发层的微服务框架中，已经搭建好了基础的配置信息，开发人员只需要在该框架中填入实现待开发政务服务事项的开发代码即可。在中间层调用到目标中间组件之后，在微服务框架中，通过采用这些目标中间组件，搭建实现调用请求针对的事项的已完成微服务。最后为了将开发完成的微服务呈现出来，将已完成微服务反馈至交互层，从而在交互层的操作界面上显示已完成微服务。

中间层103，用于向容器层发送调用请求，以调用目标容器，利用目标容器创建所述目标中间组件。

在一些实施例中，中间层自身会存储一些中间组件，比如，常用的数据库和消息队列等；如果调用请求需要的中间组件已经存储在中间层，则直接将已存储的中间组件作为目标中间组件，不需要再从容器层调用目标容器，来搭建目标中间组件。如果调用请求需要的中间组件未存储在中间层，则需要再从容器层调用目标容器，来搭建目标中间组件。

容器层104，用于提供搭建不同中间组件的至少两个容器，响应于所述调用请求，向所述中间层反馈所述目标容器。

在一些实施例中，容器层作为整个应用开发系统的容器层，为整个应用开发系统提供基础代码的支撑；容器层，还用于提供容器编排引擎和容器管理服务等。在一些可能的实现方式中，容器可以理解为，独立运行实现一定功能的一个或一组应用；搭建不同中间组件的至少两个容器，即在容器层中提供多个能够用来搭建中间组件的且可独立运行的应用。目标容器包括一个或多个容器，即是用来搭建目标中间组件的容器。

最后，交互层101，还用于接收并显示所述已完成微服务。

由上述交互层101、开发层102、中间层103和容器层104组成的应用开发系统可以应用于业务系统的私有云中，比如，应用于政务服务系统的私有云，或者教育系统的私有云等。

在本申请实施例中，应用开发系统中提供了交互层、开发层、中间层和容器层都具备高可用和高性能特性，可以灵活适配用户搭建高可用、高性能等政务服务系统；如此，通过提供支持多设备输入的调用请求的应用开发系统，对于不同的开发人员在操作界面输入的调用请求均能够进行响应，这样统一了不同开发设备的开发环境，最大限度减少架构设计人员在高可用、高性能设计中花费的时间和精力。

在一些实施例中，为提高政务服务系统中，开发人员的开发效率，在本申请实施例提供的应用开发系统的开发层，设置了微服务平台和持续发布平台，如图2所示，图2是本申请实施例提供的应用开发系统的另一架构示意图，结合图1B进行说明，开发层102包括：

微服务平台201，用于根据获取的开发层运行环境的基础配置信息，搭建微服务框架，在微服务框架中利用目标中间组件创建业务事项的已完成微服务。

在一些可能的实现方式中，开发层运行环境，是指运该开发层处于正常工作状态时所需要的运行参数，即所需要的配置信息，配置信息包括：安全网关、服务发现、负载均衡、流量控制、故障恢复和故障注入等特性。可以理解为，在微服务平台201中已经配置了实现安全网关、服务发现、负载均衡、流量控制、故障恢复和故障注入等参数，那么当开发人员在该应用开发系统上进行政务服务事项的开发时，便不需要再为开发环境进行参数配置，可直接在微服务框架中输入实现行政务服务事项的代码；如此，最大限度地让开发人员集中精力在业务开发上，而且减少了运维人员部署高可用、高性能系统和线上运维的工作量。

在一些实施例中，微服务平台201，可以通过以下模块实现：

管理界面211，用于创建请求，根据微服务生成所述调用请求，并将调用请求传递至组件模块。

这里，管理界面211为开发人员提供一个管理界面，开发人员可以在管理界面中输入对组件的配置信息，将这些配置信息下发到组件模块中，以使在组件模块中完成组件的配置，或者，将接收到的调用请求传递到组件模块，以使组件模块从中间层调用目标中间组件。

组件模块212，用于将调用请求发送至中间层，在微服务框架中，根据在中间层调用的目标中间组件，创建已完成微服务。

在一些实施例中，组件模块不仅能够将调用请求转发至中间层，还可以根据管理界面输入的组价的配置信息，对组件进行相应的配置，也就是说组件模块中，不仅包括目标中间组件，还存储有实现其他政务服务实现的中间组件；如此，在微服务框架中，根据调用的目标中间组件，创建实现政务服务事项的微服务。

监控模块213，用于对组件模块中的中间组件进行监控，并监控结果发送至交互层，以在操作界面上进行显示。

在一些可能的实现方式中，监控模块可以采用普罗米修斯(Prometheus)来实现，对于组件模块中的所有中间组件的参数、运行状态等进行监控，并且将监控结果反馈至显示模块。在其他实施例中，监控模块还可以监控中间组件在开发政务服务事项的整个过程中的工作状态，并且将该工作状态作为监控结果的一部分反馈至显示模块。

拓扑模块214，用于确定组件模块中的中间组件之间的拓扑关系，并根据所拓扑关系，更新组件模块中的中间组件；

在一些可能的实现方式中，拓扑模块可以采用格拉法纳(Grafana)来实现，首先，拓扑模块获取到组件模块中的多个中间组件，分析这些中间组件之间的拓扑关系，并形成如图11所示的拓扑关系图；而且在该拓扑模块中，还可以依据拓扑关系，重新编辑中间组件的配置信息，以更新组件模块中的中间组件。在一个具体例子中，如果开发人员认为当前中间组件之间的关联关系不能很好的实现待开发的政务服务事项，那么，可以通过在拓扑模块中输入需要重新编辑的中间组件要修改的参数，即可更新该中间组件。

链路追踪模块215，用于对已完成微服务的运行链路进行追踪，将运行出现故障的链路反馈至交互层，以在交互层的操作界面显示出现故障的链路。

在一些实施例中，链路追踪模块能够对一个已完成微服务的所有运行链路进行追踪，从中确定出发生故障的链路，并将该发生故障的链路反馈至交互层，以在交互层显示所述出现故障的链路，从而提示运维人员及时对故障的链路进行维护。或者，链路追踪模块还能够对多个已完成微服务进行追踪，从而确定出发生故障的微服务，将发生故障的微服务反馈至交互层，从而在交互层显示该微服务，以使运维人员及时对故障的微服务进行维护。

持续发布平台202，用于对微服务框架中输入的用于实现业务事项的开发代码进行管理，并发布已完成微服务。

在一些可能的实现方式中，持续发布平台202可以采用线性持续发布来实现，比如，采用作为线性通信模型的管线(pipeline)实现持续发布平台。持续发布平台202能够对微服务框架中输入的开发代码进行持续获取以及存储，并且对于获取到的代码，如果该代码已经运行完成，那么通过调用镜像文件，来部署发布环境，从而发布该已完成微服务。

在一些实施例中，持续发布平台202，可以通过以下模块实现：

存储库模块221，用于获取并存储在微服务框架中输入的开发代码。

在一些可能的实现方式中，存储库模块221可以采用集中式版本仓库(GitRepository)来实现，获取开发人员在微服务框架中输入的开发代码，并且进行存储。

发布模块222，用于根据开发代码，向镜像模块发送调用指令，以调用相匹配的镜像文件；根据所述镜像文件，部署能够发布已完成微服务的发布环境。

在一些实施例中，发布模块222包括用于从存储库模块221中拉取开发代码并进行打包处理的引擎，还包括用于支持代码运行的大量容器的容器仓库，以及还包括用户集群。在一些可能的实现方式中，首先，引擎从存储库模块221中拉取开发代码并进行打包处理，根据打包的代码，向镜像模块发送调用指令，得到该打包的代码的镜像文件；然后，容器仓库根据镜像文件，提供相应的容器；最后，在用户集群中根据镜像文件，部署发布环境，在发布环境中发布已完成微服务。

镜像模块223，用于根据运行开发代码所需要的数据包，创建并存储镜像文件。

在一些可能的实现方式中，镜像模块223可以采用应用容器引擎注册(DockerRegistry)平台来实现，镜像模块223从发布模块222中获取开发代码，根据运行该开发代码所需要的数据包，搭建形成这些数据包的镜像文件。如此，搭建完成这些镜像文件之后，就可以响应引擎下发的指令，用户集群需要的容器调回并且进行解析，根据解析结果拉取镜像文件，并在搭建的发布环境中发布已完成微服务，从而实现了持续发布已完成微服务。

在本申请实施例中，在微服务平台中搭建了已经配置基础信息的微服务框架，从而能够减少开发人员部署高可用、高性能系统和线上运维的工作量，并且能够提升系统的稳定性。

在一些实施例中，为能够使得开发人员可以直接调用运行开发代码的中间组件，在本申请实施例提供的应用开发系统的中间层，设置了中间件平台和持通用组件平台，如图3A所示，图3A是本申请实施例提供的应用开发系统的另一架构示意图，结合图1B进行说明，中间层103包括：

中间件平台301，用于提供用于创建不同待创建服务的至少两个中间组件；还用于根据从所述容器层调用的所述目标容器，搭建所述目标中间组件，并将所述目标中间组件发送给所述开发层的微服务平台。

在一些实施例中，待创建服务可以是实现任意功能的服务，也就是说，中间件平台能够提供创建实现任意功能的服务的中间组件。中间件平台中的中间组件可以是预先编订的，也可以是在开发过程中开发创建的。在中间件平台301中设置有显示界面，在显示界面上显示多个中间组件，以供开发人员进行点击选择。或者是，对于中间件平台中没有存储的中间组件，从容器层调用相应的容器进行搭建，以创建中间组件；搭建完成的中间组件，也可以显示在显示界面上。

在一些可能的实现方式中，中间件平台301可以通过以下模块实现：

前端显示界面331，包含于所述操作界面，用于显示至少两个中间组件。

在一些实施例中，前端显示界面331作为操作界面上的一部分，属于中间层，可以理解为是一个显示大量中间组件的显示界面，开发人员通过在该显示界面中对中间组件的图标进行点击，即可调用该中间组件；比如，将：数据库、队列、远程字典服务、搜索服务器、基于分布式文件存储的数据库、分布式开源、数据库、对象存储服务、消息队列和反向代理web服务器等显示在该前端显示界面。

容器模块332，用于接收调用请求，向所述中间件平台的容器仓库发送加载指令，以加载目标容器，并将根据所述目标容器搭建的目标中间组件反馈至所述前端显示界面进行显示。

在一些实施例中，容器模块可以接收前端显示界面传递的调用请求，还可以获取开发人员在前端显示界面输入的中间组件的选择指令，对这些调用请求和选择指令进行响应，向容器仓库发送加载指令，从而加载到目标容器。

容器仓库333，用于响应于加载指令，从容器层获取目标容器，并将目标容器反馈至容器模块。

在一些实施例中，容器仓库与容器层连接，当接收到加载指令时，获取容器层的大量的容器，反馈至容器模块。

通用组件平台302，用于提供预先编订的预设中间组件，所述预设中间组件的被调用频率大于等于预设频率，且所述预设中间组件能够根据输入的编辑指令进行更新，以得到更新的预设中间组件。

在一些实施例中，通用组件平台302可以看成是中间组件平台的优化或者是一部分，用于提供预先编订好的通用组件，对于这些通用组件，可以根据输入的编辑指令，对这些预先编订的预设中间组件进行更新，即开发人员能够对预先编订的预设中间组件进行二次开发。在一些可能的实现方式中，对于中间组件平台中大量的中间组件，通用组件平台从中选择出被调用频率大于等于预设频率的中间组件；其中预设频率可以是指在所有已完成微服务中出现的频率，比如，100个微服务中出现了80次以上，即说明被调用频率大于等于预设频率。也就是说，通用组件平台，提供经常被调用的通用组件，这样，将经常被调用的通用组件呈现给开发人员，便于开发人员快速找到需要的中间组件，节省时间。

在一些实施例中，为了能够实时的对应用开发系统的工作日志进行处理，并将处理结果显示在操作界面上，供开发人员进行查看，在本申请实施例提供的应用开发系统的交互层，设置了日志管理平台和操作界面，如图3B所示，图3B是本申请实施例提供的应用开发系统的又一架构示意图，结合图1B进行说明，交互层101包括：

日志管理平台321，用于对获取的应用开发系统的工作日志进行处理，并将处理结果反馈至操作界面。

在一些实施例中，日志管理平台对整个应用开发系统的工作日志进行监控，首先获取这些工作日志，然后对工作日志进行处理，比如，进行监督和分析，将监督和分析的处理结果，反馈至操作界面。

在一些可能的实现方式中，日志管理平台321，可以采用以下模块实现：

日志收集模块，设置于应用开发系统下的设备集群中的每一设备中，用于获取每一设备的工作日志，并将所述每一设备的工作日志发送至日志监测模块。

在一些实施例中，设备的工作日志，包括该设备的运行参数、运行状态和运行速率、故障现象和损耗程度等；在设备集群中的每一设备上设置一个用于收集工作日志的日志收集模块，并且每一日志收集模块将收集到的工作日志发送至日志检测模块。

日志监测模块，用于对每一设备的工作日志进行监测，当监测到工作日志中存在满足预设条件的异常信息时，向操作界面反馈告警信息，以使告警信息显示在所述操作界面。

在一些实施例中，日志监测模块对于日志收集模块上报的工作日志进行监测，当监测到工作日志中存在异常信息时，生成告警信息，比如，监测到工作日志中代码的运行速率过低或数据包的流量过大等异常情况时，生成对应的告警信息，并且在告警信息中携带这些异常信息；在操作界面上显示这些告警信息，以及时的提醒运维人员对系统进行维护。

在其他实施例中，日志管理平台中还可以设置日志分析模块，用于对所述每一设备的工作日志的类型和数据进行分析，并输出分析结果，而且将该分析结果反馈至操作界面进行显示。

操作界面322，还用于接收日志管理平台反馈的处理结果，并对处理结果进行显示。

比如，对反馈的监督结果和日志分析结果进行显示。

在本申请实施例中，通过在交互层中设置日志监测模块和日志收集模块，对整个系统的工作日志进行监控和分析，从而能够使得开发人员及时的获取到系统的工作状态，以保证系统的稳定性。

在一些实施例中，为向整个应用开发系统提供底层支撑，在本申请实施例提供的应用开发系统的容器层，设置了两个认证平台，如下所示：

第一认证平台，用于对调用请求进行验证，如果调用请求满足认证条件，响应于调用请求，向中间层反馈目标容器。

在一些可能的实现方式中，第一认证平台可以采用容器层的认证代理来实现，通过对调用请求进行验证，对于通过验证的调用请求，向中间层的中间件平台反馈目标容器。比如，验证调用请求所携带的设备的标识信息是否合理，如果合理则验证通过。

第二认证平台，用于当第一认证代理处于故障状态时，对调用请求进行验证，如果调用请求满足认证条件，向中间层反馈目标容器。

在一些可能的实现方式中，第二验证平台可以采用接口认证的方式来实现，当第一认证平台出现故障时，启动第二认证平台对调用请求进行验证，从而保证了及时第一认证平台发生故障，也仍然能够为认证通过的调用请求提供目标容器。

在一些实施例中，第二认证平台可以通过以下模块实现：

认证模块，用于当第一认证平台处于故障状态时，对调用请求进行验证，如果调用请求满足认证条件，向接口服务器反馈调用请求。

在一些可能的实现方式中，当第一认证平台处于故障状态时，启动第二认证平台中的认证模块，利用该认证模块对调用请求进行验证，如果验证通过，将调用请求传递到接口服务器。

接口服务器，用于响应所述调用请求，向中间层反馈目标容器。

在一些可能的实现方式中，接口服务器接收到调用请求之后，对调用请求进行响应，向中间层反馈目标容器。

在本申请实施例中，通过设置两个认证平台，允许用户绕开第一认证平台，直接连接到下游集群的接口服务器。当容器层的服务器不可用时，仍能让用户访问下游的集群。

本申请实施例提供这一种应用开发系统的运行方法，采用该方法开发完成的应用开发系统能够为不同开发人员提供统一的开发环境，使得开发人员专注于业务开发，从而提升研发效率，如图4所示，图4是本申请实施例提供的实现应用开发系统的运行方法的流程示意图，结合图4所示的步骤进行以下说明：

步骤S401，采用交互层提供操作界面，并将在操作界面上触发的创建请求发送到开发层。

在一些实施例中，创建请求用于请求创建待开发业务事项的微服务。待开发的应用开发系统至少包括：交互层、开发层、中间层和容器层。开发人员可以在操作界面上输入需要进行系统开发的创建请求。

步骤S402，采用开发层根据所述微服务生成调用请求，向中间层发送调用请求，以调用目标中间组件。

步骤S403，采用中间层向容器层发送调用请求，以调用目标容器。

步骤S404，采用容器层提供搭建不同中间组件的至少两个容器，响应于调用请求，向中间层反馈目标容器。

步骤S405，采用中间层利用目标容器创建目标中间组件，并将目标中间组件发送给开发层。

步骤S406，采用开发层，在微服务框架中，利用目标中间组件创建业务事项的已完成微服务，并将已完成微服务反馈至所述交互层。

在一些实施例中，微服务框架能够支持实现任意类型的业务事项。

步骤S407，在交互层接收并显示已完成微服务。

上述步骤S401至步骤S407提供了一种应用开发系统的运行方法，该系统可以应用于任意类型的包括多种实现模块的大型或中型系统中，比如，应用于包括多部门的政务应用系统中，还可以应用于包括多科目的教育系统等，再这样的大中型系统中完成各个模块的微服务。

在本申请实施例中，采用支持实现多类服务业务的不同开发代码的应用开发系统，对于不同的开发人员在操作界面输入的调用请求均能够进行响应，以搭建实现该调用请求针对事项的已完成微服务；这样，统一了不同开发人员的开发环境，能够使得开发人员专注于业务开发，从而节省了开发人员的时间，提升了研发效率。

在一些实施例中，应用开发系统中的开发层包括微服务平台和持续发布平台，所述步骤S406，可以通过以下步骤实现：

步骤S461，采用微服务平台根据获取的开发层运行环境的配置信息，搭建微服务框架。

步骤S462，采用微服务平台在微服务框架中利用目标中间组件创建业务事项的已完成微服务。

在一些可能的实现方式中，微服务包括管理界面和组件模块，首先，采用管理界面接收创建请求，根据微服务生成调用请求，并将调用请求传递至组件模块；然后，采用组件模块将调用请求发送至中间层，在框架中，根据在中间层调用的目标中间组件，创建已完成微服务。

步骤S463，采用持续发布平台对所述微服务框架中输入的用于实现业务事项的开发代码进行管理，并发布所述已完成微服务。

在一些可能的实现方式中，采用持续发布平台包括存储库模块和镜像模块，首先，采用存储库模块获取并存储在微服务框架中输入的开发代码；其次，采用发布模块根据开发代码，向镜像模块发送调用指令，以调用相匹配的镜像文件；再次，采用镜像模块根据运行开发代码所需要的数据包，创建并存储镜像文件；最后，采用发布模块根据镜像文件，部署能够发布已完成微服务的发布环境。

在其他实施例中，为了能够对每一微服务进行实时追踪，微服务还包括监控模块、拓扑模块和链路追踪模块，所述方法还包括以下步骤：第一步，采用所述监控模块对所述组件模块中的中间组件进行监控，并将监控结果发送至所述交互层，以在所述操作界面上进行显示。第二步，采用所述拓扑模块确定所述组件模块中的中间组件之间的拓扑关系，并根据所述拓扑关系，更新所述组件模块中的中间组件。第三步，采用所述链路追踪模块对所述已完成微服务的运行链路进行追踪，将运行出现故障的链路反馈至所述交互层，以在所述交互层的操作界面显示所述出现故障的链路。

在本申请实施例提供的应用开发系统的开发层，通过设置微服务平台和持续发布平台，提高了政务服务系统中，开发人员的开发效率。

在一些实施例中，为了更加便捷的为开发人员提供支持代码运行的中间组件，比如，数据库和消息队列等，在应用开发系统的中间层设置中间件平台，所述步骤S405，可以通过以下步骤实现：

步骤S451，采用中间件平台提供用于创建不同微服务的至少两个中间组件。

步骤S452，采用中间件平台根据从容器层调用的目标容器，搭建目标中间组件，并将目标中间组件发送给开发层的微服务平台。

在一些可能的实现方式中，中间件平台包括前端显示界面、容器模块和容器仓库，首先，采用容器模块接收所述调用请求，向中间件平台的容器仓库发送加载指令，以加载目标容器，并将根据目标容器搭建的目标中间组件反馈至前端显示界面进行显示。然后，采用容器仓库响应于加载指令，从容器层获取目标容器，并将目标容器反馈至容器模块；最后，采用前端显示界面显示至少两个中间组件，前端显示界面包含于所述操作界面。

在本申请实施例中，通过在应用开发系统的中间层设置提供通用中间组件和普通中间组件的中间件平台，便于开发人员对中间组件的调用，从而提高开发效率。

在一些实施例中，为了能够对系统的工作日志进行实时监督和分析，从而提高系统的稳定性，在本申请实施例提供的交互层中设置了日志管理平台和操作界面，所述步骤S407，可以通过以下步骤实现：

步骤S471，采用所述日志管理平台对获取的所述应用开发系统的工作日志进行处理，并将处理结果反馈至所述操作界面。

在一些可能的实现方式中，日志管理平台包括日志收集模块和日志监测模块，首先，将所述日志收集模块设置于所述应用开发系统下的设备集群中的每一设备中；然后，采用所述日志收集模块获取所述每一设备的工作日志，并将所述每一设备的工作日志发送至日志监测模块；最后，采用所述日志监测模块对所述每一设备的工作日志进行监测，当监测到所述工作日志中存在满足预设条件的异常信息时，向所述操作界面反馈告警信息，以使所述告警信息显示在所述操作界面。

步骤S472，采用操作界面接收日志管理平台反馈的处理结果，并对处理结果进行显示。

在一些可能的实现方式中，处理结果包括告警信息和对工作日志的分析结果，其中，分析结果可以包括对工作日志类型的分析，以及数据量大小的分析等。

在本申请实施例中，通过在交互层中设置了日志管理平台和操作界面，能够对系统的工作日志进行实时监督和分析，从而提高系统的稳定性。

在一些实施例中，为了提高系统的可用性，在本申请实施例提供的容器层中设置了第一认证平台和第二认证平台，步骤S404可以通过以下步骤实现：

步骤S441，采用所述第一认证平台对所述调用请求进行验证，如果所述调用请求满足认证条件，响应于所述调用请求，向所述中间层反馈所述目标容器。

步骤S442，当所述第一认证平台处于故障状态时，采用所述第二认证平台对所述调用请求进行验证，如果所述调用请求满足所述认证条件，向所述中间层反馈所述目标容器。

在一些可能的实现方式中，第二认证平台包括认证模块和接口服务器，首先，当第一认证平台处于故障状态时，采用认证模块对调用请求进行验证，如果调用请求满足所述认证条件，向接口服务器反馈所述调用请求；然后采用所述接口服务器响应所述调用请求，向所述中间层反馈所述目标容器。

在本申请实施例中，通过在容器层中设置了第一认证平台和第二认证平台，当第一认证平台出现故障时，开发层仍然能够通过第二认证平台正常调用目标容器，从而提高了系统的可用性。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，以针对A省的数字化政企系统为例，进行说明。

本申请实施例提供的云应用开发中台主要的应用场景是针对数字化企业多个应用系统不同厂商快速搭建架构和开发，这些厂商的技术体系、能力水平都各不相同，一个大型应用系统开发的时候需要统一技术开发平台和共用的技术服务组件。

厂商应用系统开发的技术架构、技术实现方式的不同会使得数字化政企中的各部门、地市系统的建设规划管理变得复杂，尤其省级平台项目需要多个不同厂商联合开发的时候，研发阶段需要统一技术平台和通用技术组件来进行协同，这个过程往往比较耗时间和资源精力，而且这些工作要投入大量的人力资源去统筹设计规划，每个应用系统、项目都要重复性去设计，难以进行架构和技术的规划和管理，导致旧的项目中的经验在新的项目中难以得到高效的复用；数字化政企应用系统开发过程中，还面对着很多通用的技术组件重复开发的难题，每个项目的应用系统在研发交付过程中，都会重复性的开发构建，微服务架构、容器技术、路由代理(反向代理、负载均衡)，数据库组件、NoSQL组件、消息队列服务组件、日志服务组件、链路追踪服务组件、监控告警服务组件、音视频组件、即时通讯组件、组织机构管理组件、流程引擎组件、表单服务组件、单点登录组件、后台管理服务组件、分布式事务组件、调度服务组件，这些技术每个项目都所有的厂商完全自研或者掌握不太现实，需要提供一整套可以开箱即用的工具给他们简单快速的去使用这个能力，最大化降低应用系统开发的厂商面对技术的门槛和瓶颈，提升业务持续孵化深度，提高数字化政企项目建设的质量和效率。

针对数字化政企项目，本申请实施例在云应用开发中台通过一个平台，集中提供了微服务套件、容器技术、路由代理(反向代理、负载均衡)，数据库组件、NoSQL组件、消息队列服务组件、日志服务组件、链路追踪服务组件、监控告警服务组件、音视频组件、即时通讯IM组件、组织机构管理组件、流程引擎组件、表单服务组件、单点登录组件、后台管理服务组件、分布式事务组件、调度服务组件，覆盖了应用系统开发的大部分需求，较好地解决了应用系统研发交付过程中遇到的困难和挑战，大幅提升了开发和交付效率。

首先，云应用开发中台提供了容器技术，帮助用户采用云原生技术实现应用架构转型升级和高效管理。基于容器编排引擎(Kubernetes，K8S)实现的，完全兼容在K8S、Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务部署和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

云应用开发中台提供了微服务开发套件，基于微服务管理工具(Istio)套件实现，集微服务开发、服务注册与发现、服务间通信安全、负载均衡、故障恢复、流量控制、日志、监控、故障注入为一体化的工具包。通过微服务套件为数字化政企应用系统开发构建分布式的微服务应用提供高可靠，高可用，高性能可扩展的微服务架构，助力数字化政企互联网微服务架构转型，降低构建微服务架构的技术成本。云应用开发中台提供了路由代理组件，提供反向代理和负载均衡能力，针对于7层网络进行分流策略，将任务流量进行平衡，分摊到后台多个操作单元上执行，解决高性能，高可用，水平扩展。代理后台全球广域网，即web接收互联网外部请求，提供缓存加速web请求功能。云应用开发中台提供数据库组件，基于关系型数据库管理系统主从集群、提供的高可用特性能保证应用服务最大程度的提升服务质量。提供的读写分离特性能有效的提升应用服务性能和用户体验。提供有效保证数据存储安全，当事故发生时，将数据损失降至最低程度。基于使用传送门(PGPool-II)方式将对象-关系数据库服务器(Postgre SQL)服务组成集群，通过VIP对外提供一致服务。该集群能提供比关系型数据库管理系统主从集群更高的扩展性，扩展方式更加简单。当集群基本服务失效时，集群会及时获知并选举新的基本服务，服务不会受到任何影响。基于面向企业应用开发的大数据库集群(MyCAT)和开源数据库中间件(kingshard)是两个广泛使用的关系型数据库管理系统数据库集群中间件工具，面向企业应用开发的大数据库集群和开源数据库中间件都是开源的，提供了负载均衡、分库分表、跨节点查询、集群管理等功能。通过该类中间件能够让关系型数据库管理系统支持更大的数据量，能更灵活的支持业务的扩展。这类工具提供了管理功能，能帮助更好的管理关系型数据库管理系统集群，简化运维工作。云应用开发中台提供NoSQL组件，基于Redis支持多种数据类型和数据存储方式，满足绝大数应用场景的需要。Redis集群可以采用哨兵(Sentinel)或集群(Cluster)模式进行部署，都能提供高可用的Redis服务。基于分布式文件存储的数据库服务组合成副本集(Replica Set)的方式，能提供高可用高扩展性负载均衡的集群服务。基于数据库在大数据领域具有高容错、去中心化和高性能的特点，在一些无需强一致性的场景下，使用数据库能够存储海量的数据，并能预期这些数据存取的可靠性能。

云应用开发中台提供新的可扩展/高性能数据库(NewSQL)组件，基于融合型数据库产品(TiDB)和MinIO技术实现，融合型数据库产品能在保证数据强一致性的情况下，容纳海量的结构化数据，并达到普通关系型数据库的性能。融合型数据库产品也是云原生基金会孵化的产品，与云架构天然亲和。融合型数据库产品与MySQL完全兼容，从而降低了架构迁移的复杂性和学习曲线。MinIO有着优异的性能，同时与K8S能无缝集成。MinIO与云服务(AWS S3)有着完全兼容的应用程序接口(Application Programming Interface，API)，系统迁移会十分简单。MinIO整体运维管理工作非常简易。

云应用开发中台提供消息队列服务组件，基于消息队列和卡夫卡技术实现，消息队列内部利用面向并发的编程语言(Erlang)提供的分布式通信框架一次性密码(One TimePassword，OTP)来满足消费者和生产者在节点崩溃的情况下继续运行，以及通过添加更多的节点来线性扩展消息通信吞吐量，使客户端在失去一个消息队列节点连接的情况下，还是能够重新连接到集群中的任何其他节点继续生产、消费消息。基于卡夫卡实现分布式的、高吞吐量、高可扩展性消息队列服务，广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等。

云应用开发中台提供日志服务组件，提供一套完整的日志收集以及展示服务。提供日志数据收集、过滤、存储、聚合、搜索、分析、可视化展示等功能。满足微服务架构下，海量用户请求下的日志分析需求。

云应用开发中台提供链路追踪服务组件，基于链路追踪提供一套完整的与开放分布式追踪应用程序接口(Open Tracing API)完全兼容的分布式链路追踪服务。系统基于可伸缩性和并行性构建，资源开销低。支持动态采样策略，对具有高度动态网络行为的环境至关重要，如K8S集群。提供多种编程语言的客户端支持。兼容开源项目(Zipkin)，可以透明地接受和处理Zipkin span请求。支持容器化部署，提供K8S的运算功能，无缝接入K8S。

云应用开发中台提供监控告警服务组件，基于Prometheus和Grafana提供一套完整的监控告警服务。支持监控、告警、可视化展示等功能。支持物理主机、云资源、容器、K8S等基础设施监控。支持数十种流行中间件的监控，而且还在不断丰富中。基于时序数据库，采取全栈方式，吞吐能力强。支持容器化部署，提供K8S的运算功能，无缝接入K8S。

云应用开发中台提供即时通讯服务组件，平台提供一套标准化音视频服务组件，前端通过浏览器可以访问音频或视频服务。通过web程序集(web Assembly)技术将前端访问源自网页即时通信应用程序接口(Web Real-Time Communication API，WebRTC API)的高级编程语言(JavaScript，JS)代码进行封装，提升访问速度和网络传输性能。后端提供标准的WebRTC服务，并通过Nginx进行反向代理和负载均衡。整套服务组件能满足绝大多数有关音视频的应用场景，并有着较好的性能。

平台提供一套标准化即时通信服务组件。客户端支持网页浏览和应用程序访问两种方式。客户端使用全双工通信协议(WebSocket)与服务建立长连接，该长连接管道将用于客户端发送数据到服务器以及服务器向客户端推送数据。后端服务提供即时通信功能，并支持集群部署，服务器之间可以路由并互相传输数据。使用Nginx作为反向代理和负载均衡，有效提升并发用户数和服务性能。

云应用开发中台提供通用应用服务组件，组织机构管理组件、后台管理服务组件、流程引擎服务组件、统一认证服务组件、分布式事物服务组件、表单引擎服务组件、统一调度服务组件。云应用开发平台提供一套标准化组织机构管理组件：提供灵活的组织结构设计，能适应多分支机构管理和频繁的组织机构变化的需求。提供虚拟组织机构管理功能，以支持临时性项目小组的管理需求。支持组织架构快速批量调整，实时快捷应对组织变革。支持基于时间轴的组织管理及员工管理，组织变更、任职轨迹随时追溯。云应用开发平台提供一套标准化后台管理服务组件：提供K8S集群部署、管理等功能。提供平台中间件部署、管理功能。提供平台服务组件部署、管理功能。提供主机、K8S集群、中间件及应用监控告警可视化展示界面。提供应用持续集成、持续发布、配置等应用管理功能，支持容器和K8S方式部署。提供基于Istio的微服务的配置、管理功能。云应用开发平台提供一套标准化流程引擎服务组件：标准化流程引擎服务组件基于流动性，提供一套完整的流程引擎服务。即，提供业务流程模型和符号(Business Process Model and Notation，BPMN)引擎、案例管理模型和符号(Case Management Model and Notation，CMMN)引擎、决策模型和符号(DecisionModel and Notation，DMN)引擎、表单引擎(Form Engine)等模块。提供流程绘制的用户界面(User Interface，UI)界面。每个模块可以作为独立的引擎或服务运行，也可以集成在一起为业务流程管理提供丰富的套件。所有引擎都可以嵌入到Java应用程序中，或者作为单独服务部署。云应用开发平台提供一套标准化统一认证、单点登录组件：统一认证服务组件基于中央认证服务(Central Authentication Service，CAS)，提供一套完整的统一认证、单点登录服务。支持个人计算机端及移动端认证，扩展性强。支持数据库、轻型目录访问协议(Lightweight Directory Access Protocol，缩写：LDAP)、活动目录联合服务(ActiveDirectory Federation Services，ADFS)、Java工具包(Java Web Toolkit，JWT)等多种认证方式，并且提供多种类型平台的客户端支持。满足业务系统的各种统一认证、单点登录需求。支持容器化及K8S方式部署。云应用开发中台提供一套标准化表单引擎服务组件：表单引擎服务的设计是用于在协助完成一个项目上多表单的快速制作过程，省去开发人员用在简易但又数量巨大的表单程序开发时间，快速实施完成现有的交付项目。表单引擎配置可以分为新增表单、表单设计器、字段属性、表单修复、打印配置、数据关联、函数扩展、列表配置等、生成系统模块。并且后期维护相对简单，管理方便，在发布的表单时会对数据进行的页面静态化，生成一个真实的表单存档。

云应用开发中台提供一套标准化任务调度服务组件：基于计算机编程语言(Golang)开发的定时任务调度系统，支持http请求、运行Golang、计算机程序设计语言蟒蛇(Python)、计算机壳层(Shell)等调度任务。在wb节点对任务进行增加、修改、删除、克隆、运行任务等。实时查看正在运行的任务和任务的实时日志，并且可以对正在运行的任务进行终止操作。支持任务的定时调度、依赖调度、手动调度、手动恢复,实现双机集群系统(HighAvailable，HA)，机器宕机环境实现机器断线重连与心跳恢复与赫拉(hera)集群HA，节点单点故障环境下任务自动恢复，主进程断开，工作进程抢占主进程。

再者，云应用开发中台提供编排功能，可将多个关联的技术服务组件定制化编排在一起，一键触发完成技术架构搭建工作，构建架构的过程中无需人工干预。可以轻松支持开发工作中需要结合应用场景和项目配置进行架构组合和集成的需求。同时支持版本管理，可以大幅提升旧项目经验在新项目中复用的效率。

云应用开发中台提供不同应用场景的技术方案编排功能，可将不同的技术服务组件根据应用场景快速编排在一起，高可用方案、高性能方案、小程序对接方案、容灾方案、应急方案、服务降级方案、智能网关技术对接方案。

图5是本申请实施例提供的云应用开发中台的框架示意图，该平台包括：容器平台501、中间件平台502(中间件商店)、通用组件503(组件商店)、微服务平台504、持续集成发布流程505(Pipeline)以及运营平台506六部分；其中：

容器平台501以Docker和K8S为基础，提供额外的认证，基于角色的权限控制(RBAC)，K8S集群创建、导入、集中管理，以及K8S Resource(如节点(Node)、命名组(Namespace)、持久卷(Persistent Volumes)、存储类别(Storage Classes)、工作量(Workload)、服务(Service)等)管理等功能，为本申请实施例提供的应用开发系统其他部分提供容器编排支持，是产品的基础。

中间件平台502(中间件商店)以Helm Chart为基础，集成自定义的软件包管理器中的程序包库，以下简称程序包库(Helm Chart Repository)，并从程序包库中拉取由本申请实施例提供的应用开发系统开发人员预先编写好的列表，通过界面展示给用户。用户只需要从用户界面中选择相应的中间件，就能在K8S集群中自动部署。同一个集群中同一版本的中间件可以部署多套，互不干扰。

如图5所示，中间组件包括但不限于以下中间件：关系型数据库管理系统、队列、远程字典服务、搜索服务器、基于分布式文件存储的数据库、非关系型数据库、数据库、对象存储服务、消息队列和反向代理全球广域网服务器等

通用组件503(组件商店)中的通用组件由本申请实施例提供的应用开发系统开发人员开发实现，用户可以直接使用。用户可以在用户界面中选择相应的组件，触发组件在K8S集群中的自动化部署，部署实现原理和中间件超市类似。用户可以对通用组件进行二次开发。二次开发完成后可自行组织部署，亦可以升级程序包库中的列表，以继续使用组件商店的方式部署。

微服务平台504以Istio为基础。Istio提供安全网关、服务发现、负载均衡、流量控制、故障恢复、故障注入等特性，满足微服务需求。平台为用户提供一键启用Istio功能，自动完成Istio组件在K8S集群上的部署。同时，提供开箱即用的微服务架构全景图功能，链路追踪功能，以及监控告警功能。还提供用户界面支持对虚拟服务(Virtual Service)，Destination Rule等Istio自定义资源的创建和维护。

持续集成发布流程(Pipeline)505提供持续集成、发布功能。Pipeline从集中式版本仓库拉取代码，构建Docker镜像，推送到应用容器引擎注册，然后按照K8S资源文件的定义部署到K8S集群中。也可以在推送到应用容器引擎注册后，推送软件包管理器中的程序包到程序包库，然后使用Helm部署到K8S集群中。Pipeline支持自动和手动两种触发方式。

运营平台506为本申请实施例提供的应用开发系统中的K8S节点、组件、中间件及应用的工作量、Istio组件以及微服务等提供监控报警、日志分析、应用目录(比如，HelmChart Repository配置)等运营功能。

图6是本申请实施例容器平台的组成架构示意图，如图6所示，容器平台服务器600包括：

认证代理601(Authentication Proxy)：代理所有K8S应用程序接口调用。集成本地认证、活动目录(Active Directory)认证等认证服务。对于每个K8S API调用，认证代理y对调用者进行身份验证，并在将调用转发给K8S主进程之前设置适当的K8S模拟标头。

群集控制器602至604(Cluster Controller)：负责创建、导入集群，监控下游集群资源的变化，将下游集群的状态带到用户请求的状态；为集群设置访问控制策略。

这里，群集控制器602监控用户K8s集群1的资源的变化，群集控制器603监控用户K8s集群2资源的变化，群集控制器604监控用户K8s集群3的资源的变化。

群集代理605(Cluster Agents)：连接集群的K8s API服务器(K8S API Server)，在集群中管理工作量、最小可部署单元(Pod)以及部署方式(Deployment)等资源；向容器平台服务器传递集群信息，如事件、状态、节点信息和健康状况。

Kube-api-验证606(Kube-api-auth)：允许用户绕开认证代理601，直接连接到下游集群的K8s接口服务器661。当容器平台服务器不可用时，仍能让用户访问下游的集群。

这里，用户K8s集群1中包括K8s API服务器611，分布式的集群管理系统(kubelet)612，节点代理(Node Agent)613，ectd节点614，工作节点615和控制平面节点616。

图7是本申请实施例提供的中间件平台的组成架构示意图，如图7所示，中间件平台的组成架构包括：

本申请实施例提供的应用开发系统的开发人员会预先编写好平台中列举的中间件的程序包(Chart)包含单机版本和高可用版本，供用户使用时自行选择。这些程序包会被添加到平台的软件包管理器中的程序包仓库705(Helm Chart Repository)中。

用户可以在中间件超市前端UI 701触发，中间件平台后台702的本地软件包管理器中的程序包缓存刷新，即刷新软件包管理器中的程序包(Helm Chart)本地缓存703。

中间件超市前端UI 701请求后台的软件包管理器(Helm)，软件包管理器获取本地程序包详细列表信息并返回到前端UI进行展示。

用户点击前端UI中相应的中间件图标，输入必要的环境变量值(如MySQL的根密码等)，系统就会调用后台的软件包管理器将所选的中间件部署到用户K8S集群704中。用户可以查看部署状态，部署完成后，可以查看使用说明开始使用。

用户可以通过类似的方式在平台中对中间件进行升级、卸载。

得益于软件包管理器中的程序包的特性，即便是同一版本的同种中间件，也能在集群中安装多套，而且会有不同的K8S资源实例，相互独立。每套安装都会有一个唯一的发布(Release)名称，可以单独进行升级。例如，可以在同一个K8S集群704中安装多套基于分布式文件存储的数据库的复制集(Mongo DB ReplicaSet)集群，这些集群可以被独立使用以及独立升级。

对用户而言，这是名副其实的中间件商店，需要使用的时候只需点击一下图标，就能实现中间件的自动安装，从单机版到高可用版本一应俱全，安装完成后还能查看使用说明。整个过程高效又舒心。

图8本申请实施例提供的通用组件的组成架构示意图，如图8所示，通用组件包括：

通用组件由本申请实施例提供的应用开发系统的开发人员开发实现。通用组件会被打成Docker镜像添加到平台Docker注册表806(Docker Registry)中。

本申请实施例提供的应用开发系统的开发人员会预先编写好通用组件的程序包，这些程序包用于各通用组件的自动化部署，它们会被添加到平台的软件包管理器中的程序包仓库805中。

用户可以在通用组件超市前端UI 801触发，组件超市后台802的本地软件包管理器中的程序包缓存刷新，即刷新Helm Chart本地缓存803。

用户点击前端UI相应的组件图标，输入必须的环境变量值，系统就会调用后台的软件包管理器将所选的组件部署到用户K8S集群804中。用户可以查看部署状态，部署完成后，可以查看使用说明开始使用。

用户可以通过类似的方式在平台中对组件进行升级、卸载。

得益于软件包管理器中的程序包的特性，即便是同一版本的同种组件，也能在集群中安装多套，这取决于用户需求。这些集群会有不同的K8S资源实例，相互独立。每套安装都会有一个唯一的发布名称，可以单独进行升级。

对用户而言，这是名副其实的通用组件商店，需要使用时只需点击一下图标，就能实现组件的自动安装，安装完成后可以查看使用说明。整个过程高效又舒心。

如用户需要对通用组件进行二次开发，开发完成可以自行安排部署，也可更新软件包管理器中的程序包，推送到平台的软件包管理器中的程序包仓库，继续使用组件超市的部署方式。

图9本申请实施例提供的微服务平台的组成架构示意图，如图9所示，微服务平台包括：

平台为用户提供一键启用微服务管理工具功能，用户只需要在用户的管理界面901(Istio Resource)上点击启用，平台便通过Istio组件903(Istio Components)，自动完成Istio在K8S集群上的部署。同时完成链路追踪91(Jaeger)、图谱展示92(Kiali)、数据监控93(Prometheus)、数据展示94(Grafana)的部署和集成。

微服务平台902除支持Istio本身的安全网关、服务发现、负载均衡、流量控制、故障恢复、故障注入等特性外，还提供了额外的价值。

微服务平台902提供了分布式追踪系统，通过集成链路追踪实现，开箱即用。允许查看调用的全链路，这在问题分析和判断性能问题原因时很有用。如图10所示，图10是本申请实施例链路追踪的显示界面图，从链路追踪界面1001可以看出，可以通过集成链路追踪对每一微服务的实现进行链路追踪，搜索和比较等。

微服务平台提供了微服务架构全景图，通过集成Kiali实现，开箱即用。可以展示网格中的微服务，以及微服务之间的连接情况，流量速率和延迟等。便于检测网格的健康程度。如图11所示，图11是本申请实施例拓扑结构的显示界面图，从界面1101可以看出，可以通过集成Kiali对多个组件之间的拓扑关系进行展示，即在拓扑关系图1102中展示多个组件之间的关系。

在本申请实施例中，微服务平台提供了全面的监控和分析功能，通过集成普罗米修斯和格拉法纳实现，开箱即用。可以对Istio组件，微服务的运行情况进行分析和洞察。如图12所示，图12是本申请实施例数据显示的显示界面图，从界面1201可以看出，可以通过集成普罗米修斯和格拉法纳对普罗米修斯监控到的组件的运行数据进行显示，即在显示界面图中展示多个组件的监控数据。其中，Istio的流量管理、故障恢复、故障注入等功能一般通过虚拟服务、目标规则(Destination Rule)、入口网关(Ingress Gateway)等资源的定义来实现。因此平台会提供用户界面，帮助用户更容易地编辑和管理这些自定义资源。

图13本申请实施例提供的持续集成发布流程的组成架构示意图，如图13所示，持续集成发布流程的架构包括：

该流程可以自动或手动触发。触发后，引擎1302(Jenkins Engine)从存储库(GitRepository)1301中拉取应用代码，进行构建，运行单元测试等。然后生成Docker镜像，推送到镜像存储库平台(Docker Repository)1303。然后，如有程序包更新，则一并提交到软件包管理器中的程序包仓库平台1304。然后，触发应用在用户K8S集群1305中的部署。如果使用的是K8S资源文件方式部署，则直接从Docker存储库平台拉取镜像部署；如果使用的是Helm Chart方式部署，则直接运行Helm进行部署。Helm部署的过程中K8S集群也需要从Docker存储库平台拉取镜像。

图14本申请实施例提供的运营平台的组成架构示意图，如图14所示，运营平台架构包括：

本申请实施例通过集成日志收集系统(Fluentd)1401、搜索服务器(Elasticsearch)1402和日志分析平台(Kibana)1403来实现日志搜集和分析功能。通过在用户K8S集群1405的每个节点中部署一个日志收集系统的守护程序集(DeamonSet)进行日志的收集，然后转发到搜索服务器进行存储，使用日志分析平台对日志进行分析。搜索服务器和日志分析平台可以部署在K8S集群上，也可以使用用户现有的搜索服务器和日志分析平台。

本申请实施例通过集成普罗米修斯1404和格拉法纳1406实现监控告警功能，开箱即用。普罗米修斯负责在K8S集群在收集K8S组件、节点、应用和中间件工作量等的运行状态数据，还可以设置相应阀值对监控指标进行告警。格拉法纳从普罗米修斯获取数据进行展示和分析。

图15是本申请实施例提供的云应用开发平台的功能展示图，如图15所示，云应用研发工具箱指导数据化政企、智慧城市、政企中的各个部门等地市建设方案落地。其中，云应用开发平台具有的功能包括：

功能1501，快速辅助传统政务系统搭建高性能开发架构的中台产品，提供完整的高性能开发运行平台。

功能1502，提供高可用方案、高性能方案、高并发方案、运维方案、监控方案、容灾方案、应急方案、小程序建设方案、政务服务网建设方案、智能网关对接方案、统一认证对接方案等。

功能1503，通用技术组件补充编排技术架构路由代理、数据库组件、NoSQL组件、NewSQL组件、消息队列组件、日志组件、链路追踪组件、监控报警、即时通讯、组织架构、流程引擎、表单引擎、统一认证、后台管理、分布式事物、任务调度。

功能1504，微服务套件构建技术架构。

功能1505，云资源容器化构建云应用开发的沙箱环境。

基于上述功能，用户可实现以下交互流程：

产品交付部署在政务云后，提供云端访问，用户通过应用研发中台登录后根据应用场景的业务需求，可以选择定制化编排技术架构的服务组件，通过可视化界面的简单操作选择后，应用研发中台底层通过容器化技术去编排组合用户架构方案自动化生成一个线上即时可用的研发技术架构，用户通过研发中台生成的技术架构去构架的开发环境可以通过研发中台提供开放适配器进行敏捷快速开发，同时也支持开源的技术接口由开发人员自定义扩展架构中的所有服务组件，对于开发人员面对众多互联网技术架构和服务组件无需再投入大量的时间成本去研究技术选型和构建技术架构，不用在不断重复的在各个项目中制造技术服务组件，应用研发中台集成了企业it解决方案中涉及的全栈技术，提供应用研发全栈支持，最大限度地让开发人员集中精力在业务开发上。最大限度地减少运维人员工作量。扩缩容简单快捷安全，满足高可用、高性能需求。按节点资源使用情况进行工作负载调度，还可以因应用资源使用情况随时向集群添加、删除节点。为服务组件提供可编排的构建能力，云应用开发中台提供的自助式中间件平台、自助式通用组件，帮助应用架构设计人员、开发人员根据应用实际情况，对中间件、通用组件进行编排组合，快速搭建技术架构。帮助架构设计人员快速验证架构设计。最大限度地让开发人员集中精力在业务开发上。

提供已调优的中间件，成熟的通用组件，降低系统稳定性风险。在不同的项目中使用标准化的服务组件，便于问题排查、升级，同时让服务组件得到持续的优化。高阶适配集成方案，适配用户搭建高可用、高性能技术方案的选择，云应用开发中台提供的中间件、通用组件、微服务平台、容器平台都具备高可用和高性能特性。可以灵活适配用户搭建高可用、高性能等技术方案的选择。最大限度减少架构设计人员在高可用、高性能设计中花费的时间和精力。最大限度地让开发人员集中精力在业务开发上。减少运维人员部署高可用、高性能系统和线上运维的工作量。平台本身已经考虑了高可用、高性能要求，有助提升系统稳定性。

图16是本申请实施例提供的云应用开发平台的组成结构示意图，如图16所示，该云应用开发平台包括以下部分：

基础架构构建1601，用于构建容器化微服务架构环境。

服务组件编排1602，用于补充编排技术架构，定制化选择通用技术服务组件进行自动化架构编排适配。

开放平台1603，用于提供简单高效的开放平台的进行开发。

高阶集成方案构建1604，用于一键构建，场景丰富：高性能、高可用、高并发、异步并发、缓存隔离、服务降级、数字化政企平台对接、微服务应急方案、中台技术对接方案。

适配器1605，用于提供丰富的适配器集成、构建、开发。

图17是本申请实施例提供的在云应用开发中台进开发的流程示意图，如图17所示，该应用流程包括以下步骤：

步骤S1701，创建Git仓库。这里，为源代码创建Git仓库。可使用现有的Git或自行搭建。这一步在平台外完成。

步骤S1702，自助安装中间组件。这里，根据项目实际情况需要，在开发中台用户界面中选择合适的中间件进行自动化安装。由于项目需要用到中间件MongoDB和MySQL，开发人员进入云应用开发中台，在中间件超市选择MongoDB和MySQL分别点击安装。开发人员认为开发环境没有高可用和高性能要求，因此他选择了单机版。如果有高可用和高性能要求可以选择集群版。安装完成后，页面会分别给出MongoDB和MySQL的连接地址，用户名密码等信息。接下来，开发人员就可以开始使用平台提供的基于分布式文件存储的数据库和MySQL了。

步骤S1703，自助安装通用组件。这里，根据项目实际情况需要，在开发中台用户界面中选择合适的中间件进行自动化安装。由于项目需要统一认证(单点登录)通用组件，开发人员进入云应用开发中台，在组件超市选择单点登录组件点击安装。安装完成后，页面会给出组件的访问地址，详细使用说明(例如怎样和应用服务集成)的链接地址。接下来，开发人员就可以阅读使用说明，开始运用单点登录系统了。

步骤S1704，启用Istio，实现自动化部署。这里，根据项目实际情况在用户界面中一键启动Istio自动化部署。如不需要使用服务网格(Service Mesh)，可以不启用。开发人员希望使用平台中提供的Istio来开发微服务。开发人员进入云应用开发中台，点击开启Istio，等待Istio在K8S中部署完成。接下来，开发人员就可以使用Istio的各种特性了。

步骤S1705，编写业务代码。这里，开发人员开始编写业务代码，这一步可以在平台外完成。

步骤S1706，根据项目实际情况，配置持续集成和持续部署(ContinuousIntegration/Continuous Deployment，CI/CD)。这里，根据项目实际情况，在开发中台中进行CI/CD管线配置。手动触发部署或配置按条件触发部署。

开发人员完成大部分的业务代码，进入云应用开发中台，配置CI/CD，手动触发应用部署或配置按条件(如每天定时触发，每次提交代码都触发等)触发应用部署。部署完成后，开发人员可以进入云应用开发中台，在Istio管理界面配置微服务的流量控制、故障恢复等规则。

步骤S1707，查看日志监控。这里，有需要的情况下可以方便的查看日志和监控。开发人员验证应用功能，必要时可以进入云应用开发中台查看监控信息和日志。

上述步骤S1701至1704，步骤S1706和步骤S1707均在云应用开发中台中完成。

在一个具体例子中，用户要开发一个在线展示书评的系统。这个系统包括一个前端页面和两个微服务。前端页面用于展示书评信息。两个微服务分别是review服务和rating服务。review服务用于获取书评，还会调用rating服务，获取书本的星级(1-5星)。review服务要使用MongoDB，rating服务要使用MySQL。系统还需要统一认证(单点登录)。

图18是本申请实施例提供的在云应用开发中台进行运维的流程示意图，如图18所示，该应用流程包括以下步骤：

步骤S1801，添加、编辑或删除集群，以进行多集群管理。这里，运维人员可以添加、编辑或删除集群，配置用户认证、权限等操作。

步骤S1802，对集群进行监控，以实现集群管理。这里，运维人员可以进行集群监控，集群备份、恢复，添加、编辑、删除节点，集群存储管理，集群证书更新。

步骤S1803，基于项目内容，进行内存等资源的分配和限制。这里，运维人员可以进行基于项目(命名空间(Namespace)分组)给团队进行内存、CPU等资源的分配和限制，制定网络策略。

步骤S1804，对开发的政务服务事项进行监控告警。这里，运维人员可以进行配置监控告警，查看监控数据。

上述步骤S1801至步骤S1804均在云应用开发中台中完成。

在本申请实施例中，一方面，云应用开发中台提供的容器平台、中间件平台、通用组件、微服务平台、CI/CD平台、运营平台几乎覆盖了应用开发和生命周期管理的各个方面，使用简单、快捷。提升开发效率。最大限度地让开发人员集中精力在业务开发上。最大限度地减少运维人员工作量，提升了运维效率；扩缩容简单快捷安全，满足高可用、高性能需求，提升了应用弹性；而且按节点资源使用情况进行工作负载调度，还可以因应资源使用情况随时向集群添加、删除节点。另一方面，云应用开发中台提供的自助式中间件平台、自助式通用组件，帮助应用架构设计人员、开发人员根据应用实际情况，对中间件、通用组件进行编排组合，快速搭建技术架构。如此，帮助架构设计人员快速验证架构设计，实现架构快速试错；这样，能够最大限度地让开发人员集中精力在业务开发上，提升了开发效率；而且通过提供已调优的中间件，成熟的通用组件，降低系统稳定性风险，提升了系统稳定性，以及，通过在不同的项目中使用标准化的服务组件，便于问题排查、升级，同时让服务组件得到持续的优化，提升了系统标准化。再一方面，云应用开发中台提供的中间件、通用组件、微服务平台、容器平台都具备高可用和高性能特性。如此，可以灵活适配用户搭建高可用、高性能等技术方案的选择。这样，最大限度减少架构设计人员在高可用、高性能设计中花费的时间和精力，提升架构设计效率；而且最大限度地让开发人员集中精力在业务开发上，提升了开发效率；通过减少运维人员部署高可用、高性能系统和线上运维的工作量，减少了运维工作量；由于平台本身已经考虑了高可用、高性能要求，从而有助提升系统稳定性。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法。在一些实施例中，存储介质可以是闪存、磁表面存储器、光盘、或光盘存储器等存储器；也可以是包括上述存储器之一或任意组合的各种设备。在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(Hyper Text Markup Language，HTML)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个车载计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备执行。综上所述，本申请实施例通过提供支持实现多类政务服务事项的不同开发代码的应用开发系统，对于不同的开发人员在操作界面输入的调用请求均能够进行响应，以搭建实现该调用请求针对事项的已完成微服务；这样，统一了不同开发人员的开发环境，能够使得开发人员专注于业务开发，从而节省了开发人员的时间，提升了研发效率。以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种应用开发系统，其特征在于，所述应用开发系统包括：

交互层，用于提供操作界面，并将在所述操作界面上触发的创建请求发送到开发层；所述创建请求用于请求创建待开发业务事项的微服务；

所述开发层，用于根据所述微服务生成调用请求，向中间层发送所述调用请求，以调用目标中间组件；进而在微服务框架中，利用所述目标中间组件创建所述业务事项的已完成微服务，并将所述已完成微服务反馈至所述交互层；其中，所述微服务框架能够支持实现任意类型的业务事项；

中间层，用于向容器层发送所述调用请求，以调用目标容器，利用所述目标容器创建所述目标中间组件；

所述容器层，用于提供搭建不同中间组件的至少两个容器，响应于所述调用请求，向所述中间层反馈所述目标容器；

所述交互层，用于接收并显示所述已完成微服务。

2.根据权利要求1所述的系统，其特征在于，所述开发层，包括：

微服务平台，用于根据获取的所述开发层运行环境的配置信息，搭建所述微服务框架，在所述微服务框架中利用所述目标中间组件创建所述业务事项的已完成微服务；

持续发布平台，用于对所述微服务框架中输入的用于实现业务事项的开发代码进行管理，并发布所述已完成微服务。

3.根据权利要求2所述的系统，其特征在于，所述微服务平台，包括：

管理界面，用于接收所述创建请求，根据所述微服务生成所述调用请求，并将所述调用请求传递至组件模块；

所述组件模块，用于将所述调用请求发送至所述中间层，在所述框架中，根据在所述中间层调用的目标中间组件，创建所述已完成微服务。

4.根据权利要求3所述的系统，其特征在于，所述微服务平台，还包括：

监控模块，用于对所述组件模块中的中间组件进行监控，并将监控结果发送至所述交互层，以在所述操作界面上进行显示；

拓扑模块，用于确定所述组件模块中的中间组件之间的拓扑关系，并根据所述拓扑关系，更新所述组件模块中的中间组件；

链路追踪模块，用于对所述已完成微服务的运行链路进行追踪，将运行出现故障的链路反馈至所述交互层，以在所述交互层的操作界面显示所述出现故障的链路。

5.根据权利要求2所述的系统，其特征在于，所述持续发布平台，包括：

存储库模块，用于获取并存储在所述微服务框架中输入的开发代码；

发布模块，用于根据所述开发代码，向镜像模块发送调用指令，以调用相匹配的镜像文件；根据所述镜像文件，部署能够发布所述已完成微服务的发布环境；

所述镜像模块，用于根据运行所述开发代码所需要的数据包，创建并存储镜像文件。

6.根据权利要求1所述的系统，其特征在于，所述中间层，包括：

中间件平台，用于提供用于创建不同待创建服务的至少两个中间组件；还用于根据从所述容器层调用的所述目标容器，搭建所述目标中间组件，并将所述目标中间组件发送给所述开发层的微服务平台；

通用组件平台，用于提供预先编订的预设中间组件，所述预设中间组件的被调用频率大于等于预设频率，且所述预设中间组件能够根据输入的编辑指令进行更新，以得到更新的预设中间组件。

7.根据权利要求6所述的系统，其特征在于，所述中间件平台，包括：

容器模块，用于接收所述调用请求，向所述中间件平台的容器仓库发送加载指令，以加载所述目标容器，并将根据所述目标容器搭建的目标中间组件反馈至前端显示界面进行显示；

所述容器仓库，用于响应于所述加载指令，从所述容器层获取目标容器，并将所述目标容器反馈至所述容器模块；

前端显示界面，包含于所述操作界面，用于显示所述至少两个中间组件。

8.一种应用开发系统的运行方法，其特征在于，所述方法包括：

采用交互层提供操作界面，并将在所述操作界面上触发的创建请求发送到开发层；所述创建请求用于请求创建待开发业务事项的微服务；

采用所述开发层根据所述微服务生成调用请求，向中间层发送所述调用请求，以调用目标中间组件；

采用所述中间层向容器层发送所述调用请求，以调用目标容器；

采用所述容器层提供搭建不同中间组件的至少两个容器，响应于所述调用请求，向所述中间层反馈所述目标容器；

采用所述中间层利用所述目标容器创建所述目标中间组件，并将所述目标中间组件发送给所述开发层；

采用所述开发层，在微服务框架中，利用所述目标中间组件创建所述业务事项的已完成微服务，并将所述已完成微服务反馈至所述交互层；其中，所述微服务框架能够支持实现任意类型的业务事项；

在所述交互层接收并显示所述已完成微服务。

9.一种应用开发系统的运行设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求8所述的方法。

10.一种存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求8所述的方法。

Images