CN112311871A - 一种基于微服务架构的统一应用开发方法及系统 - Google Patents

Abstract

本发明公开了一种基于微服务架构的统一应用开发方法及系统，属于计算机软件架构领域；所述的系统具体包括信息转存模块、服务刷新模块、地址验证模块和节点通信模块；平台提供具有容错性和高可用性的去中心化的分布式服务注册机制,不需维护一个高可用的服务注册中心,而是将其分散到集群中的每个节点；在每个节点上启动一个注册模块,不同节点的多个注册模块之间没有主次之分,降低了注册模块的压力,而且其中一个注册模块宕机,不会影响集群中的其它注册模块,有效避免了只有一个注册模块的宕机而导致系统瘫痪的风险。

Description

一种基于微服务架构的统一应用开发方法及系统

技术领域

本发明公开一种基于微服务架构的统一应用开发方法及系统，涉及计算机软件架构技术领域。

背景技术

微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级的通信机制互相沟通(通常是基于Http协议的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够独立的部署到生产环境、类生产环境等

RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源

传统应用架构的弊端最早在大型企业和互联网行业中呈现,这些公司都遇到了复杂应用的开发维护成本变高、代码重复率增大、团队协作效率变差、系统可靠性变低、系统水平扩展困难、新功能上线周期变长等问题，因此众多大型公司经过了反复实践和尝试,推出了各种轻量级的架构模式,有效的解决了上述问题。

传统的应用架构在当下的问题包括:1)传统的企业应用代码庞杂并且业务组件之间耦合程度非常高,造成了业务应用维护难度大、升级成本高；2)业务模块之间的循环依赖、不合理的调用、冗长复杂的业务流程等问题对新功能的上线造成极大影响；3)系统功能组件出现无法恢复的故障时,整个节点处于不可用状态；4)在扩展性方面,由于传统应用大多是单一部署,在这种模式下一个应用某些部分偏I/O密集型、某些部分却偏CPU密集型,但应用却只部署在一台机器上,很难用单一硬件来满足应用各部分对硬件资源的不同要求,造成无法高效的应对多用户高并发的场景等问题；故现发明一种基于微服务架构的统一应用开发方法及系统，以解决上述问题。

发明内容

本发明针对现有技术的问题，提供一种基于微服务架构的统一应用开发方法及系统，所采用的技术方案为：一种基于微服务架构的统一应用开发方法，其特征是所述的方法具体步骤包括：

S1利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

S2服务注册中心接收到服务发现的Rest请求后进行服务刷新；

S3对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性；

S4服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息。

所述S1中的注册信息包括微服务访问地址、提供服务的列表和消费服务的列表。

所述S2服务注册中心接收到服务发现的Rest请求后进行服务刷新的具体步骤包括：

S201从本地的哈稀表中获取所有微服务的注册信息拼装成数组；

S202对所有注册信息计算MD5校验码，将数组和校验码一并返回；

S203服务发现器接收返回数据后,将注册信息数组保存到微服务容器的哈稀表中,作为服务提供者的列表。

所述S3对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性的具体步骤包括：

S301当地址存在时，服务注册中心认为该微服务存活；

S311当地址不存在时，服务注册中心认为微服务已经掉线；

S302从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码；

S303将存活状态信息和校验码一并返回；

S304去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对。

一种基于微服务架构的统一应用开发系统，所述的系统具体包括信息转存模块、服务刷新模块、地址验证模块和节点通信模块：

信息转存模块：利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

服务刷新模块：服务注册中心接收到服务发现的Rest请求后进行服务刷新；

地址验证模块：对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性；

节点通信模块：服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息。

所述信息转存模块中的注册信息包括微服务访问地址、提供服务的列表和消费服务的列表。

所述服务刷新模块具体包括信息拼装模块、信息计算模块和信息存储模块：

信息拼装模块：从本地的哈稀表中获取所有微服务的注册信息拼装成数组；

信息计算模块：对所有注册信息计算MD5校验码，将数组和校验码一并返回；

信息存储模块：服务发现器接收返回数据后,将注册信息数组保存到微服务容器的哈稀表中,作为服务提供者的列表。

所述地址验证模块具体包括服务激活模块、服务暂停模块、效验码模块、信息返回模块和信息比对模块：

服务激活模块：当地址存在时，服务注册中心认为该微服务存活；

服务暂停模块：当地址不存在时，服务注册中心认为微服务已经掉线；

效验码模块：从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码；

信息返回模块：将存活状态信息和校验码一并返回；

信息比对模块：去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对。

本发明的有益效果为：平台提供具有容错性和高可用性的去中心化的分布式服务注册机制,不需维护一个高可用的服务注册中心,而是将其分散到集群中的每个节点；在每个节点上启动一个注册模块,不同节点的多个注册模块之间没有主次之分,降低了注册模块的压力,而且其中一个注册模块宕机,不会影响集群中的其它注册模块,有效避免了只有一个注册模块的宕机而导致系统瘫痪的风险；针对注册模块节点的宕机问题,提供了自动检测失败节点机制及周期性地恢复功能,为注册模块正常运行提供双重保障；

同时平台微服务开发框架提供了本地化的服务注册和发现功能,服务只需要向本地的注册模块进行注册；集群中不同注册模块之间同步注册信息,同步过程无需应答,有效减少了网络资源的消耗；从本地注册模块取到的注册信息即为集群中注册的所有服务信息，供微服务之间调用。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明方法的流程图；图2是本发明系统的结构示意图；图3是微服务工程的结构示意图；图4是去中心化的服务中心的结构示意图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明，以使本领域的技术人员可以更好地理解本发明并能予以实施，但所举实施例不作为对本发明的限定。

平台微服务开发框架基于约定优于配置的思想,封装了支撑微服务构建的组件库,不需要繁琐的配置即可使用Java语言开发微服务，平台总体技术架构如图3所示，

平台基于dropwizard提供微服务开发组件,以Undertow作为Web容器,引入Jersey提供标准Restful风格的Web访问,集成MyBatis等数据持久层访问组件；提供服务注册发现功能,自动注册本地服务到注册中心；通过可选的负载均衡策略,选择最优的服务地址；提供轻量级的RPC组件调用,保障高可用的服务调用，在开发阶段根据微服务框架Bundle特性,能够实现平台各模块的Bundle插件集成到微服务中,如任务调度、大数据组件、报表和展现框架等，同时,平台提供了去中心化的分布式服务注册中心,在每个节点上启动一个注册中心,不同节点的多个注册中心之间没有主次之分,降低了注册中心的压力,其中一个注册中心宕机,不会影响集群中的其它注册中心，针对注册中心节点的宕机问题,提供了自动检测失败节点机制及周期性地恢复功能,为注册中心正常运行提供双重保障。

微服务工程有三种,服务生产者,服务消费者和服务定义接口(API),服务由接口定义,服务生产者实现接口服务,服务消费者来调用。工程结构如图3所示，消费者和生产者微服务通过扩展微服务开发组件实现，微服务开发组件是对开源微服务组件dropwizard的二次封装,除了具有dropwizard提供的特性外,还封装了服务注册,发现,刷新,轻量级RPC,负载均衡，由以下核心模块协助完成，

服务实现

提供注解@Microservice,将类标记为微服务的业务处理逻辑构件，标记方式有两种:

作为接口引用的标记

public class TestFrontController{

private static final Logger logger＝LoggerFactory，getLogger(Bug4TestFrontController，class)；

@MicroService//标记为接口引用的微服务构件

private IBugService service；

}

作为接口实现的标记

监听器

ServerListenerServerListener在系统启动时加载,主要有以下功能，

服务注册，

发送http请求向服务注册中心,注册服务数据。

服务刷新和发现

定时向注册中心发送刷新服务请求,刷新请求返回的是服务的状态和路由列表,如果服务状态为死亡则重新注册服务,如果服务正常,判断本次路由表校验码与本地路由表校验和是否一致,不一致更新本地路由表；

传统的企业应用架构多采用中心化的分布式服务架构,一旦服务注册中心出现问题,整个系统就会瘫痪；同时所有应用向一个服务注册中心进行远程注册,会消耗大量的网络资源,造成服务注册中心压力过大，因此,如图4所示，平台采用去中心化的服务注册中心,也是本发明实现统一应用开发的技术目标；

实施例一：

一种基于微服务架构的统一应用开发方法，所述的方法具体步骤包括：

S1利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

S2服务注册中心接收到服务发现的Rest请求后进行服务刷新；

S3对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性；

S4服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息；

服务注册中心封装了开源分布式集群框架Serf,基于Gossip协议实现集群节点之间进行通信,同步所有的路由信息；同时封装go语言的Web服务框架Gin,实现服务发现,注册,刷新的http接口服务,供微服务和监控应用调用，节点之间,以事件的方式提供了信息同步功能,实现节点信息、路由信息的同步；

首先进行服务注册，本发明方法按照S1利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

然后服务注册中心对服务器发现的Rest请求按照S2进行服务刷新；接着按照S3对URL中的地址参数进行解码，并在本地的哈希表中对地址的真实性进行验证，验证地址是都存在，再按照S4服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息；

平台提供了具有容错性和高可用性的去中心化的分布式服务注册机制,不需维护一个高可用的服务注册中心,而是将其分散到集群中的每个节点；在每个节点上启动一个注册模块,不同节点的多个注册模块之间没有主次之分,降低了注册模块的压力,而且其中一个注册模块宕机,不会影响集群中的其它注册模块,有效避免了只有一个注册模块的宕机而导致系统瘫痪的风险；针对注册模块节点的宕机问题,提供了自动检测失败节点机制及周期性地恢复功能,为注册模块正常运行提供双重保障；

同时平台微服务开发框架提供了本地化的服务注册和发现功能,服务只需要向本地的注册模块进行注册；集群中不同注册模块之间同步注册信息,同步过程无需应答,有效减少了网络资源的消耗；从本地注册模块取到的注册信息即为集群中注册的所有服务信息，供微服务之间调用；

进一步的，所述S1中的注册信息包括微服务访问地址、提供服务的列表和消费服务的列表；

进一步的，所述S2服务注册中心接收到服务发现的Rest请求后进行服务刷新的具体步骤包括：

S201从本地的哈稀表中获取所有微服务的注册信息拼装成数组；

S202对所有注册信息计算MD5校验码，将数组和校验码一并返回；

S203服务发现器接收返回数据后,将注册信息数组保存到微服务容器的哈稀表中,作为服务提供者的列表；

再进一步的，所述S3对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性的具体步骤包括：

S301当地址存在时，服务注册中心认为该微服务存活；

S311当地址不存在时，服务注册中心认为微服务已经掉线；

S302从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码；

S303将存活状态信息和校验码一并返回；

S304去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对。

服务注册中心接收到该Rest请求后,按照S3解码URL中的地址参数，去本地的哈希表中查询该地址是否存在；如果存在，服务注册中心按照S301认为该微服务存活；否则按照S311认为微服务已经掉线；当微服务处于存活状态时,按照S302从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码，然后按照S303将存活状态信息和校验码一并返回；服务刷新器接收返回数据后,判断存活状态为掉线时,按照S304去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对，不一致时,表明服务注册中心的注册信息发生变化,调用服务发现器去注册中心重新获取,保证微服务容器的服务提供者列表是最新的数据。

实施例二：

一种基于微服务架构的统一应用开发系统，所述的系统具体包括信息转存模块、服务刷新模块、地址验证模块和节点通信模块：

信息转存模块：利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

服务刷新模块：服务注册中心接收到服务发现的Rest请求后进行服务刷新；

地址验证模块：对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性；

节点通信模块：服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息；

服务注册中心封装了开源分布式集群框架Serf,基于Gossip协议实现集群节点之间进行通信,同步所有的路由信息；同时封装go语言的Web服务框架Gin,实现服务发现,注册,刷新的http接口服务,供微服务和监控应用调用，节点之间,以事件的方式提供了信息同步功能,实现节点信息、路由信息的同步；

首先进行服务注册，本发明系统通过信息转存模块利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

然后服务注册中心对服务器发现的Rest请求利用服务刷新模块进行服务刷新；接着使用地址验证模块对URL中的地址参数进行解码，并在本地的哈希表中对地址的真实性进行验证，验证地址是都存在，再通过节点通信模块服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息；

平台提供了具有容错性和高可用性的去中心化的分布式服务注册机制,不需维护一个高可用的服务注册中心,而是将其分散到集群中的每个节点；在每个节点上启动一个注册模块,不同节点的多个注册模块之间没有主次之分,降低了注册模块的压力,而且其中一个注册模块宕机,不会影响集群中的其它注册模块,有效避免了只有一个注册模块的宕机而导致系统瘫痪的风险；针对注册模块节点的宕机问题,提供了自动检测失败节点机制及周期性地恢复功能,为注册模块正常运行提供双重保障；

同时平台微服务开发框架提供了本地化的服务注册和发现功能,服务只需要向本地的注册模块进行注册；集群中不同注册模块之间同步注册信息,同步过程无需应答,有效减少了网络资源的消耗；从本地注册模块取到的注册信息即为集群中注册的所有服务信息，供微服务之间调用；

进一步的，所述信息转存模块中的注册信息包括微服务访问地址、提供服务的列表和消费服务的列表；

进一步的，所述服务刷新模块具体包括信息拼装模块、信息计算模块和信息存储模块：

信息拼装模块：从本地的哈稀表中获取所有微服务的注册信息拼装成数组；

信息计算模块：对所有注册信息计算MD5校验码，将数组和校验码一并返回；

信息存储模块：服务发现器接收返回数据后,将注册信息数组保存到微服务容器的哈稀表中,作为服务提供者的列表。

再进一步的，所述地址验证模块具体包括服务激活模块、服务暂停模块、效验码模块、信息返回模块和信息比对模块：

服务激活模块：当地址存在时，服务注册中心认为该微服务存活；

服务暂停模块：当地址不存在时，服务注册中心认为微服务已经掉线；

效验码模块：从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码；

信息返回模块：将存活状态信息和校验码一并返回；

信息比对模块：去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对；

服务注册中心接收到该Rest请求后,地址验证模块解码URL中的地址参数，去本地的哈希表中查询该地址是否存在；如果存在，服务注册中心通过服务激活模块认为该微服务存活；否则通过服务暂停模块认为微服务已经掉线；当微服务处于存活状态时,按照S302从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码，然后利用效验码模块将存活状态信息和校验码一并返回；服务刷新器接收返回数据后,判断存活状态为掉线时,按照信息比对模块去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对，不一致时,表明服务注册中心的注册信息发生变化,调用服务发现器去注册中心重新获取,保证微服务容器的服务提供者列表是最新的数据。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (8)

1.一种基于微服务架构的统一应用开发方法，其特征是所述的方法具体步骤包括：

S1利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

S2服务注册中心接收到服务发现的Rest请求后进行服务刷新；

S3对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性；

S4服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息。

2.根据权利要求1所述的方法，其特征是所述S1中的注册信息包括微服务访问地址、提供服务的列表和消费服务的列表。

3.根据权利要求2所述的方法，其特征是所述S2服务注册中心接收到服务发现的Rest请求后进行服务刷新的具体步骤包括：

S201从本地的哈稀表中获取所有微服务的注册信息拼装成数组；

S202对所有注册信息计算MD5校验码，将数组和校验码一并返回；

S203服务发现器接收返回数据后,将注册信息数组保存到微服务容器的哈稀表中,作为服务提供者的列表。

4.根据权利要求3所述的方法，其特征是所述S3对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性的具体步骤包括：

S301当地址存在时，服务注册中心认为该微服务存活；

S311当地址不存在时，服务注册中心认为微服务已经掉线；

S302从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码；

S303将存活状态信息和校验码一并返回；

S304去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对。

5.一种基于微服务架构的统一应用开发系统，其特征是所述的系统具体包括信息转存模块、服务刷新模块、地址验证模块和节点通信模块：

信息转存模块：利用Gin Web Framework，对外提供服务注册的Restful服务，接收微服务传递来的注册信息，并保存在本地的哈稀表中；

服务刷新模块：服务注册中心接收到服务发现的Rest请求后进行服务刷新；

地址验证模块：对URL中的地址参数进行解码，并在本地的哈希表中验证地址真实性；

节点通信模块：服务注册中心节点之间通过Gossip协议进行周期性的消息通信,传递节点信息。

6.根据权利要求5所述的系统，其特征是所述信息转存模块中的注册信息包括微服务访问地址、提供服务的列表和消费服务的列表。

7.根据权利要求6所述的系统，其特征是所述服务刷新模块具体包括信息拼装模块、信息计算模块和信息存储模块：

信息拼装模块：从本地的哈稀表中获取所有微服务的注册信息拼装成数组；

信息计算模块：对所有注册信息计算MD5校验码，将数组和校验码一并返回；

信息存储模块：服务发现器接收返回数据后,将注册信息数组保存到微服务容器的哈稀表中,作为服务提供者的列表。

8.根据权利要求7所述的系统，其特征是所述地址验证模块具体包括服务激活模块、服务暂停模块、效验码模块、信息返回模块和信息比对模块：

服务激活模块：当地址存在时，服务注册中心认为该微服务存活；

服务暂停模块：当地址不存在时，服务注册中心认为微服务已经掉线；

效验码模块：从本地的哈希表中获取所有微服务的注册信息后计算MD5校验码；

信息返回模块：将存活状态信息和校验码一并返回；

信息比对模块：去调用服务注册器重新注册,判断存活状态为掉线,然后拿本地保存的校验码与返回的校验码进行比对。

Images