基于分布式和容器虚拟化的弹性微服务系统及实现方法

1.本发明属于通信技术领域，涉及分布式和容器虚拟化微服务的技术领域，具体涉及一种基于分布式和容器虚拟化的弹性微服务系统及实现方法。


背景技术：

2.现代水利行业建设以数字化、网络化和智能化为主线，以虚拟仿真、精准预测和智慧决策为路径，通过全面推进算据、算法和算力建设实现数字赋能。因此对智慧水利系统的先进性、并发性、安全性、实时性有了更高的要求。
3.传统的单体应用架构下，开发人员能够快速完成较小的业务量、需求的应用开发以及部署，但随着时间推进，业务扩大、需求变动等因素不断影响，单体应用的调整成本越来越高。同时单体应用遇到的性能瓶颈，仅凭集群部署线性增加单体应用实例节点的方式并不能得到线性的性能增加。因此，如何适应随着时间推进的业务扩大以及需求变动的影响、克服业务发展所带来的性能瓶颈问题是开发人员在设计架构阶段就必须面对的问题。
4.另外，随着计算机领域的虚拟化技术不断革新，特别是容器虚拟化技术的出现给软件、硬件行业带来了新的机遇和挑战。在边缘计算技术逐渐被广泛应用到传统行业(如水利行业)中时，开发人员不得不在实现业务逻辑的同时，注意兼容编程语言以及其依赖项所处边缘节点的异构特征，而容器虚拟化技术的存在为提供高效、稳定、弹性的异构节点支持是快速生产部署边缘计算节点带来了可能。
5.因此，亟需一种基于分布式和容器虚拟化的弹性微服务系统来解决传统行业(如水利行业)的数字化建设中遇到的问题。


技术实现要素：

6.有鉴于此，本发明的目的在于提供一种基于分布式和容器虚拟化的弹性微服务系统，采用相比于传统单体应用开发模式粒度更细的微服务开发模式，克服了传统开发模式的性能瓶颈以及扩展弊端；采用分布式网络拓扑结构、服务注册机制结合多种拓扑模型，解决边缘计算节点可能存在的分布式复杂网络拓扑结构部署问题；采用容器虚拟化技术为微服务提供异构节点运行支持。综合微服务开发模式、分布式网络拓扑、容器虚拟化技术实现的微服务框架让系统的移植性更强、稳定性更高、更加注重核心业务实现，从而达到扩展业务适用领域并给更多传统领域(如水利建设行业)带来新的应用开发、部署模式的目的。
7.为达到上述目的，本发明提供如下技术方案：
8.技术方案1：一种基于分布式和容器虚拟化的弹性微服务系统，包括业务逻辑层、网络拓扑层、虚拟容器层，其特征在于，所述业务逻辑层作为系统最高层，负责微服务消息收发，逻辑处理和数据存储，以及通过tcp/ip协议与网络拓扑层建立连接，成为网络节点与其他节点进行数据交换；
9.所述网络拓扑层作为系统中间层，集成在微服务系统中，负责提供分布式复杂网络拓扑构建支持，以及接收虚拟容器层对外开放端口输入的数据，经过服务注册表查询、负
载均衡和网络路由将数据转发至业务逻辑层，并将业务逻辑层处理结果通过路由发送至容器虚拟层，完成消息请求以及响应的完整流程；
10.所述虚拟容器层作为系统底层，负责提供微服务异构节点运行支持，以及对外开放端口连通虚拟容器内部的网络拓扑层和虚拟容器外部以建立与外部的通信链路。
11.进一步，所述业务逻辑层包括：逻辑处理模块、数据存储模块和消息处理模块；
12.所述逻辑处理模块用于实现业务逻辑层的业务处理工作，提供自定义编程语言支持，根据实际需求选择合适的编程语言进行业务逻辑的处理；所述数据存储模块用于存储逻辑处理模块产生的临时数据或永久数据，提供自定义数据库支持，根据实际需求选择适当的数据库进行业务处理数据的存储；所述消息处理模块用于接收、发送、编码和解码消息，通过tcp/ip协议与网络拓扑层建立连接并进行数据交换。
13.进一步，所述网络拓扑层包括：异步消息队列通信机制、负载均衡机制、服务注册机制、请求/响应模型、发布/订阅模型、管道模型和复合模型；
14.所述异步消息队列通信机制用于通过队列缓存来削弱通信网络可能存在的高并发峰值，降低对整体通信网络的影响，使用epoll、select等技术设计支持异步通信的消息队列，让网络拓扑层能够使用异步的方式与其他的微服务进行通信，解耦微服务之间的数据交互，保持微服务之间相互独立、互不影响的特性；
15.所述负载均衡机制用于集中接收网络拓扑层其他节点对本节点发送的消息，结合评价微服务性能状态指标将消息均衡地转发给同一个微服务的不同实例，使得网络拓扑层各节点间保持良好的性能；
16.所述服务注册机制用于定时监测微服务性能状态指标以及弹性调整微服务实例数量，当系统根据使用场景弹性调整微服务实例数量时，微服务对应的对外提供服务的节点地址等路由信息会主动在服务注册表中注册，当网络拓扑层需要向目标节点发送数据时，根据服务注册机制查询目标节点微服务路由信息；
17.所述请求/响应模型用于建立同一网络拓扑中节点发送和接收消息需要遵循的约束：连接的双方分为客户端和服务端，发送消息的一方为客户端，接收消息、处理消息并对消息作出响应的一方为服务端；客户端发送消息后，在接收到服务器对于该消息的回应之前，不能再次发送消息，服务端则必须先接收消息，在回应该消息之前，不能再次接收消息，具体表现为一问一答的情形；
18.所述发布/订阅模型用于建立同一网络拓扑中节点发送和接收消息需要遵循的约束：在所有建立间接的节点中，负责发送信息的节点称为发布节点，负责接收消息的节点称为订阅节点；在该模型的规则下，消息只能由发布者发布，所有订阅者都会接收到发布者发布的消息，但发布者不能接收订阅者的消息，订阅者也不能向发布者发布消息，发布者和订阅者之间建立单向通信链路；
19.所述管道模型用于建立同一网络拓扑中节点发送和接收消息需要遵循的约束：所有建立连接的节点，分为三种类型，最初负责产生任务的节点称为生产节点，负责接收任务并处理任务的称为消费节点；生产节点和消费节点之间建立管道模型，消费节点维护一个消息管道：生产节点连接到消费节点的消息管道中，并通过push操作将任务推至消费节点的消息管道远端，消费节点从消费节点的消息管道近端pull操作拉取最新的任务，并开始处理，处理结束后再从管道拉取下一个任务；
20.所述复合模型通过对基本请求/响应模型、发布/订阅模型和管道模型根据实际需求进行组合，用于构建分布式复杂网络拓扑结构。
21.进一步，所述微服务性能状态指标包括：单位时间消息处理数、空闲时间占比、内存占用率、网络信道丢包率、cpu占用率和网络连接时延。
22.进一步，所述虚拟容器层包括：容器生成模块、镜像构建模块、镜像管理模块和容器虚拟化引擎；
23.所述容器生成模块用于镜像文件实例化，将静态的镜像文件转变为动态运行的虚拟容器，网络拓扑层以及业务逻辑层运行在容器生成模块生成的容器内部，构成独立的运行环境；
24.所述镜像构建模块用于根据规范的构建镜像指令生成镜像文件，负责处理引用镜像、文件拷贝等操作并通过执行构建镜像指令构建独立于宿主节点的静态环境；
25.所述镜像管理模块用于管理所有镜像构建模块生成的镜像，包括镜像更新、镜像获取或镜像删除等操作；
26.所述容器虚拟化引擎作为虚拟容器层的底层支撑，用于对外抽象操作系统以及硬件平台，对内抽象编程语言以及实现核心功能的其他工具，为改良同一节点不同微服务的部署对于全局环境的影响以及微服务对于所在节点软件、硬件平台异构的支持起到了重要的作用。
27.进一步，所述镜像管理模块在执行镜像更新、镜像获取或镜像删除时，需要携带具有鉴权信息的令牌发起请求；所述镜像管理模块在收到对于镜像操作的请求时，首先检查该请求是否合法，如果请求没有携带令牌、令牌为伪造的、令牌已经过期或令牌没有执行该操作的权限，那么镜像管理模块将会拒绝执行该请求并返回错误提示；如果该请求通过合法性校验，那么镜像管理模块会根据请求的报文协议执行指定操作。
28.技术方案2：一种基于分布式和容器虚拟化的弹性微服务系统的实现方法，具体包括以下步骤：
29.s1：分析微服务核心业务需求，确定合适的编程语言进行业务逻辑层的业务处理实现，确定合适的数据存储工具，对重要的临时或永久数据进行存储，利用编程语言构建消息处理逻辑；
30.s2：根据步骤s1构建的消息处理逻辑，包括消息的接收、发送、编码和解码的具体实现并通过tcp/ip协议加入网络拓扑结构中与其他网络节点进行数据交换；
31.s3：测试微服务核心业务功能的完备性，初步完成微服务核心业务逻辑实现后，加入拓扑网络并与测试节点进行网络连通性测试，核心业务功能测试，数据库连接测试以及消息并发测试；
32.s4：通过步骤s3的核心业务功能的完备性测试后，主动通过服务注册机制向网络拓扑层注册成为正式的微服务节点，并为后续接收和处理外部传入的消息做好准备；
33.s5：在注册成为正式微服务节点后，进行镜像构建和更新镜像到镜像管理模块，通过容器生成模块将构建的镜像进行实例化部署；
34.s6：服务注册机制定时检测各注册微服务综合单位时间消息处理数、空闲时间占比、内存占用率、网络信道丢包率、cpu占用率和网络连接时延，生成对应微服务性能状态指标；
35.s7：根据步骤s6的微服务性能状态指标，微服务系统弹性调整单一微服务的实例化数量或动态调整合适的网络拓扑结构。
36.进一步，步骤s7中，微服务系统弹性调整的具体步骤如下：
37.s71：服务注册机制微服务性能状态指标，根据负载均衡机制判断当某一微服务的单一实例化对象的性能状态指标是否健康；
38.s72：当微服务性能状态指标为高负荷时，服务注册机制主动向底层容器虚拟层发出请求，请求容器生成模块向镜像管理模块搜索对应微服务构建的镜像文件，并将该镜像文件实例化为具体的微服务容器实例；
39.s73：镜像实例化为具体的微服务容器实例后，服务注册机制将新的微服务容器实例注册后，通过负载均衡机制分担同一微服务不同实例的消息处理压力，通过弹性扩容提升微服务系统整体消息处理能力、整体性能。
40.本发明的有益效果在于：
41.(1)在本发明微服务系统的开发模式下，开发人员应对系统需求的变动更加从容。对于单一需求的增加或者减少，可以抽象成为微服务的增加或者减少，借助于微服务的互相独立，低耦合的优良特性，开发人员将非常容易地对系统业务、需求变动进行抽丝剥茧。同时完成一个业务量复杂，规模庞大的系统开发，并不要求所有参与到系统开发的人员完全掌握系统的结构，而是通过模块化开发实现核心功能的方式，各团队或开发人员将系统分解的单一核心功能实现，并通过一定的规范或标准与其他微服务进行交互。
42.(2)本发明的微服务系统不等同于组件，微服务是被组装好的可以用于生产环境的单一核心功能的具体实现方案，而组件是构成完整系统或单一环节所使用的需要进一步加工的元件。通过容器包装的微服务，能够快速、便捷、稳定、跨平台部署到各种异构节点中。一旦新的业务链产生，如果新的业务链的拆分之后的大部分或全部业务核心功能都存在完整具体的微服务实现，利用微服务独立部署的特性结合容器虚拟化技术可以快速部署到新的节点上并投入生产环境。
43.(3)本发明基于弹性网络结构的分布式弹性微服务具有良好的动态扩展性，根据实际使用场景的不同，一个微服务可以弹性地部署一个实例或多个实例，结合服务注册机制定期对注册的服务性能状态指标进行检测，动态扩展或缩小边缘计算节点数量或微服务实例化对象，提升系统整体的稳定性和高效性。
44.(4)本发明是基于分布式和容器虚拟化的弹性微服务系统，有力地服务于以数字化、网络化和智能化为主线的现代水利行业建设。便捷的微服务系统开发模式对程序设计语言及其依赖工具的抽象以及容器虚拟化提供的软件、硬件平台异构支持为全面推进现代水利行业算据、算法、算力建设并最终实现行业数字赋能提供了基础保障；多种网络拓扑模型提供的弹性分布式网络基础满足现代水利行业建设的核心之一的智慧水利系统的先进性、并发性、安全性、实时性的要求。
45.本发明的其他优点、目标和特征在某种程度上将在随后的说明书中进行阐述，并且在某种程度上，基于对下文的考察研究对本领域技术人员而言将是显而易见的，或者可以从本发明的实践中得到教导。本发明的目标和其他优点可以通过下面的说明书来实现和获得。
附图说明
46.为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作优选的详细描述，其中：
47.图1为本发明基于分布式和容器虚拟化的弹性微服务系统的框架图；
48.图2为本发明的消息处理模块流程框图；
49.图3为本发明的负载均衡机制原理框图；
50.图4为本发明的服务注册机制原理框图；
51.图5为本发明的请求/响应模型流程框图；
52.图6为本发明的发布/订阅模型流程框图；
53.图7为本发明的管道模型流程框图；
54.图8为本发明的镜像管理模块认证流程框图。
具体实施方式
55.以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
56.请参阅图1～图8，图1为本发明提供的基于分布式和容器虚拟化的弹性微服务系统，具体包括业务逻辑层、网络拓扑层和虚拟容器层。
57.网络拓扑层作为架构中间层，集成在微服务架构中，负责提供分布式复杂网络拓扑构建支持、接收虚拟容器层对外开放端口输入的数据，经过服务注册表查询、负载均衡、网络路由将数据转发至业务逻辑层并将业务逻辑层处理结果通过路由发送至容器虚拟层，完成消息请求以及响应的完整流程。
58.虚拟容器层作为架构底层，负责提供微服务异构节点运行支持、对外开放端口，连通虚拟容器内部的网络拓扑层和虚拟容器外部并建立与外部的通信链路。
59.业务逻辑层作为架构最高层，提供微服务消息收发、逻辑处理、数据存储功能实现并通过tcp/ip协议与网络拓扑层建立连接，成为网络节点与其他节点进行数据交换。
60.具体的，业务逻辑层包括消息处理模块、逻辑处理模块、数据存储模块。
61.如图2所示，消息处理模块作为业务逻辑层与中间层网络拓扑层进行数据交换的基础模块，要负责通过tcp/ip通信协议从网络中接收数据并对所获得数据进行解码。作为一种优选的实施例，本实施例约定使用json格式字符串进行网络通信，因此消息处理模块负责将从网络拓扑层接收到的二进制数据解码为json格式字符串，在将数据发送至网络拓扑层前，消息处理模块负责将业务逻辑层的json格式字符串编码为可以在网络拓扑层传输的二进制数据。
62.作为一种优选的实施例，逻辑处理模块采用合适的编程语言python、c/c++、go、java进行业务处理逻辑的实现，用于实现本发明所述便捷、高效、稳定的微服务。
63.作为一种优选的实施例，数据存储模块采用合适的数据库mysql、redis、mongodb、
postgresql进行数据存储的实现，用于为微服务提供重要的临时、永久数据的写入、查询、读取、修改功能。
64.网络拓扑层包括异步消息队列通信机制、负载均衡机制、服务注册机制、请求/响应模型、发布/订阅模型、管道模型。
65.作为一种优选的实施例，异步消息队列通信机制使用epoll、select等技术提供支撑，使用队列缓存来削弱通信网络可能存在的高并发峰值，降低对整体通信网络的影响；使用异步的方式与其他的微服务进行通信，解耦微服务之间的通信交互，保持微服务之间相互独立、互不影响的特性。
66.作为一种优选的实施例，负载均衡机制用于集中接收网络拓扑层其他节点对本节点发送的消息，结合评价微服务性能状态指标将消息均衡地转发给同一个微服务的不同实例，使得网络拓扑层各节点间保持良好的性能；进一步的，负载均衡机制原理框图如图3所示。
67.服务注册机制用于定时检测微服务性能状态指标以及弹性调整微服务实例数量，当系统根据使用场景弹性调整微服务实例数量时，微服务对应的对外提供服务的节点地址等路由信息会主动在服务注册表中注册，当网络拓扑层需要向目标节点发送数据时，根据服务注册机制查询目标节点微服务路由信息。微服务性能状态指标包括单位时间消息处理数、空闲时间占比、内存占用率、网络信道丢包率、cpu占用率、网络连接时延。服务注册机制原理框图如图4所示。
68.请求/响应模型用于建立同一网络拓扑中节点发送和接收消息需要遵循的约束：连接的双方分为客户端和服务端，发送消息的一方为客户端，接收消息、处理消息并对消息作出响应的一方为服务端；客户端发送消息后，在接收到服务器对于该消息的回应之前，不能再次发送消息，服务端则必须先接收消息，在回应该消息之前，不能再次接收消息，具体表现为一问一答的情形。请求/响应模型流程框图如图5所示。
69.发布/订阅模型用于建立同一网络拓扑中节点发送和接收消息需要遵循的约束：在所有建立间接的节点中，负责发送信息的节点称为发布节点，负责接收消息的节点称为订阅节点；在该模型的规则下，消息只能由发布者发布，所有订阅者都会接收到发布者发布的消息，但发布者不能接收订阅者的消息，订阅者也不能向发布者发布消息，发布者和订阅者之间建立单向通信链路。发布/订阅模型流程框图如图6所示。
70.管道模型用于建立同一网络拓扑中节点发送和接收消息需要遵循的约束：所有建立连接的节点，分为三种类型，最初负责产生任务的节点称为生产节点，负责接收任务并处理任务的称为消费节点；生产节点和消费节点之间建立管道模型，消费节点维护一个消息管道：生产节点连接到消费节点的消息管道中，并通过push操作将任务推至消费节点的消息管道远端，消费节点从消费节点的消息管道近端pull操作拉取最新的任务，并开始处理，处理结束后再从管道拉取下一个任务。管道模型流程框图如图6所示。
71.虚拟容器层包括容器生成模块、镜像构建模块、镜像管理模块、容器虚拟化引擎。
72.容器生成模块用于镜像文件实例化，将静态的镜像文件转变为动态运行的虚拟容器，微服务框架中的网络拓扑层以及业务逻辑层运行在容器生成模块生成的容器内部，构成独立的运行环境。容器生成模块采用podman容器虚拟化工具，用于本发明基于分布式和容器虚拟化的弹性微服务系统，提供一种成熟、简单、稳定的容器虚拟化部署方案。
73.镜像构建模块用于根据规范的构建镜像指令生成镜像文件，镜像构建模块负责处理引用镜像、文件拷贝等操作并通过执行构建指令构建独立于宿主节点的静态环境。作为一种优选的实施例，镜像构建模块采用buildah镜像构建工具，用于本发明虚拟容器层提供镜像构建命令解析以及执行的方案。
74.镜像管理模块用于管理所有镜像模块生成的镜像，包括镜像更新、镜像获取、镜像删除等操作。镜像管理模块在执行镜像更新、镜像获取、镜像删除模块时，需要携带具有鉴权信息的令牌发起请求，镜像管理模块在收到对于镜像操作的请求时，首先检查该请求是否合法，如果请求没有携带令牌、令牌为伪造的、令牌已经过期、令牌没有执行该操作的权限，那么镜像管理模块将会拒绝执行该请求并返回错误提示；如果该请求通过合法性校验，那么镜像管理模块会根据请求的报文协议执行指定操作。镜像管理模块的认证流程框图如图8所示。
75.容器虚拟化引擎用于对外抽象操作系统以及硬件平台，对内抽象编程语言以及实现核心功能的其他工具，容器虚拟化引擎作为虚拟容器层的底层支撑，为改良同一节点不同微服务的部署对于全局环境的影响以及微服务对于所在节点软件、硬件平台异构的支持起到了重要的作用。作为一种优选的实施例，采用podman作为容器虚拟化引擎，用于本发明基于分布式和容器虚拟化的弹性微服务系统，提供一种成熟的容器虚拟化底层支持。
76.本发明提供的基于分布式和容器虚拟化的弹性微服务系统的实现方法，具体包括如下步骤：
77.步骤1：分析微服务核心业务需求，确定合适的编程语言进行业务逻辑层的业务处理实现、确定合适的数据存储工具，对重要的临时或永久数据进行存储、利用编程语言构建消息处理逻辑；
78.步骤2：根据步骤1的消息处理逻辑，包括消息的接收、发送、编码、解码的具体实现并通过tcp/ip协议加入网络拓扑结构中与其他网络节点进行数据交换；
79.步骤3：测试微服务核心业务功能的完备性，初步完成微服务核心业务逻辑实现后，加入拓扑网络并与测试节点进行网络连通性测试、核心业务功能测试、数据库连接测试、消息并发测试；
80.步骤4：根据步骤3的微服务，通过核心业务功能的完备性测试后，主动通过服务注册机制向网络拓扑层注册成为正式的微服务节点并为后续接收、处理外部传入的消息做好准备；
81.步骤5：根据步骤4的微服务，在注册成为正式微服务节点后，进行镜像构建、更新镜像到镜像管理模块、通过容器生成模块将构建的镜像进行实例化部署；
82.步骤6：服务注册机制定时检测各注册微服务综合单位时间消息处理数、空闲时间占比、内存占用率、网络信道丢包率、cpu占用率、网络连接时延，生成对应性能状态指标；
83.步骤7：根据步骤6的性能状态指标结合服务注册机制以及容器生成模块、镜像管理模块将弹性调整单一微服务的实例化数量并动态调整合适的网络拓扑结构。
84.具体的，步骤7的微服务架构弹性调整的具体步骤如下：
85.1)服务注册机制微服务性能状态指标，根据负载均衡机制判断当某一微服务的单一实例化对象的性能状态指标是否健康。
86.2)当微服务性能状态指标为高负荷时，服务注册机制主动向底层容器虚拟层发出
请求，请求容器生成模块向镜像管理模块搜索对应微服务构建的镜像文件，并将该镜像实例化为具体的微服务容器实例。
87.3)镜像实例化为具体的微服务容器实例后，服务注册机制将新的微服务容器实例注册后，通过负载均衡机制分担同一微服务不同实例的消息处理压力，通过弹性扩容提升微服务架构整体消息处理能力、整体性能。
88.最后说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本技术方案的宗旨和范围，其均应涵盖在本发明的权利要求范围当中。