CN118283100A - 一种实现弹性部署的微服务***及部署方法 - Google Patents

一种实现弹性部署的微服务***及部署方法 Download PDF

Info

Publication number
CN118283100A
CN118283100A CN202410703178.6A CN202410703178A CN118283100A CN 118283100 A CN118283100 A CN 118283100A CN 202410703178 A CN202410703178 A CN 202410703178A CN 118283100 A CN118283100 A CN 118283100A
Authority
CN
China
Prior art keywords
service
deployment
unit
component
micro
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202410703178.6A
Other languages
English (en)
Inventor
王怀採
王先红
李修庆
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hunan Shengding Technology Development Co ltd
Original Assignee
Hunan Shengding Technology Development Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hunan Shengding Technology Development Co ltd filed Critical Hunan Shengding Technology Development Co ltd
Priority to CN202410703178.6A priority Critical patent/CN118283100A/zh
Publication of CN118283100A publication Critical patent/CN118283100A/zh
Pending legal-status Critical Current

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开一种实现弹性部署的微服务***及部署方法,包括后端服务模块、服务治理模块、web服务模块和发布服务模块;所述后端服务模块包括基础服务组件、业务服务组件和数据库组件;所述服务治理模块包括可插拔网关组件、可分离式注册中心组件和一体化配置服务组件;所述发布服务模块包括依次连接的服务打包组件、入库组件、拉取组件和项目部署组件。本发明的技术方案中,提出了一种通用的微服务技术架构,可采用集中式打包,单体部署,或者微服务分布式部署或者微服务打包,进行分布式集群部署,并且可以相互切换,可以极大的减少了对企业原有新、老多套架构的维护成本,在项目的应用和升级上降本增效显著,且利于技术插件的扩展。

Description

一种实现弹性部署的微服务***及部署方法
技术领域
本发明涉及弹性部署的服务构架技术领域,具体涉及一种实现弹性部署的微服务***及部署方法。
背景技术
随着云计算的迅速发展,项目规模日益庞大,业务也变得越来越复杂。传统的单体式应用程序采用集中式部署,但这种架构的高耦合性和复杂性,使得快速迭代和灵活部署变得困难,而微服务架构采用分布式,将应用程序拆分成小型、独立的服务单元,每个服务单元都能够独立部署和扩展。虽然增强了***的可扩展性、可维护性和可靠性,但部署时需要更多的服务器资源,部署过程也更为复杂,对小型项目造成了资源浪费,由于单体式与微服务架构的技术栈不同,同时维护两套架构的维护成本高,更新困难,而只维护其中一套架构容易导致难以应对不同应用场景,同时不易进行切换架构的问题。
发明内容
本发明的主要目的是提供一种实现弹性部署的微服务***及部署方法,旨在解决现有维护两套构架维护成本高,而只维护一套架构则难以应对不同应用场景的问题。
为实现上述目的,本发明提出的一种实现弹性部署的微服务***及部署方法,包括后端服务模块以及均与所述后端服务模块连接的服务治理模块、web服务模块和发布服务模块;所述后端服务模块包括基础服务组件、业务服务组件和数据库组件;所述服务治理模块包括可插拔网关组件、可分离式注册中心组件、自适应缓存组件和一体化配置服务组件,所述web服务模块通过所述可插拔网关组件与所述后端服务模块连接,所述web服务模块包括web服务器中部署的网页程序;所述发布服务模块包括依次连接的服务打包组件、入库组件、拉取组件和项目部署组件,所述服务打包组件用于对每一个应用服务同时打二个包,一个是可独立部署的运行包,一个是依赖包,所述入库组件用于将服务包推送到组件库,所述拉取组件用于拉取服务包到要部署的服务器,所述项目部署组件包括用于在单体环境中进行部署的单体部署单元、用于在搭建好的微服务环境中进行部署的分布式部署单元和用于根据业务访问和服务器节点性能进行集群规划的分布式集群部署单元。
优选地,所述基础服务组件包括服务间通信SDK单元、URL重写单元和启动排除单元,所述服务间通信SDK单元用于使用自定义的SDK进行服务调用,可在远程服务和本地服务之间灵活切换;所述URL重写单元用于切换部署方式时对URL进行重写,所述启动排除单元用于单体部署,项目启动时,自动排除掉微服务相关的启动类和服务熔断类的配置注入。
优选地,所述可插拔网关组件包括可插拔配置配置单元和身份认证单元,所述可插拔配置配置单元用于在一体化配置服务中,对网关的可插拔配置项进行配置,所述可插拔配置项在不同的部署依赖包中不同配置,所述身份认证单元用于对拦截到请求进行特定的验证处理。
优选地,所述一体化配置服务组件包括实时更新单元、权限认证单元、版本控制单元、多环境单元和开关切换单元;所述实时更新单元用于可以实时地更新配置信息;所述权限认证单元用于保护配置信息的机密性和完整性,所述版本控制单元用于保证配置信息可追溯性和可恢复性;所述多环境单元用于针对不同的环境提供不同的配置信息,方便部署和测试;所述开关切换单元包括总切换开关,所述总切换开关用于切换为微服务或单体服务,当切换成单体服务时,只会引入相关模块的依赖包,并会排除掉相关微服务的依赖包。
优选地,所述可分离式注册中心组件包括抽象接口单元、配置文件单元、中间件代理单元和服务注册协议单元;所述抽象接口单元用于将注册中心的核心功能抽象成接口,并定义标准的API规范,让服务提供者和消费者都可以使用API来进行服务注册和发现操作;所述配置文件单元用于将注册中心的地址、端口等信息写在一体化配置服务的文件中,并加上了开关配置,这样服务提供者和消费者就可以通过修改配置文件来更换注册中心的实现;所述中间件代理单元用于使用服务网格来进行注册中心的访问,将服务提供者和消费者与注册中心实现解耦;所述服务注册协议用于定义统一的服务注册协议Restful,并让不同的注册中心都遵循。
优选地,所述自适应缓存组件包括本地缓存单元,分布式缓存单元和缓存管理器单元,所述缓存管理器用于接收请求并从所述本地缓存单元或分布式缓存单元中获取数据,所述本地缓存单元用于管理本地缓存,所述分布式缓存单元用于管理分布式的缓存。
一种实现弹性部署的微服务***的部署方法,包括如下步骤:
采用如上任一所述的实现弹性部署的微服务***来开发底层基础服务和业务服务;
在业务服务开发完成后,同时发布基础服务与业务服务的独立部署包和依赖包,并推送到组件仓库;
按照不同的部署环境,规划服务器和配置服务器,根据部署环境从所述组件仓库拉取独立部署包或者依赖包搭建基础服务和业务服务。
优选地,所述按照不同的部署环境,规划服务器和配置服务器,根据部署环境从所述组件仓库拉取独立部署包或者依赖包搭建基础服务和业务服务的步骤,包括:
按照单体部署环境,规划一台服务器;
在服务器内搭建web服务器、基础数据库和业务数据库;
从组件仓库拉取支持单体部署的基础服务依赖包和业务服务依赖包并启动服务。
优选地,所述按照不同的部署环境,规划服务器和配置服务器,根据部署环境从所述组件仓库拉取独立部署包或者依赖包搭建基础服务和业务服务的步骤,包括:
按照微服务部署环境,规划多台服务器;
在其中一个节点服务器中搭建web服务器和可插拔网关服务器;
在另一个节点服务器中搭建可分离式注册中心服务器、自适应缓存服务器和一体化配置服务器,并进行可分离式注册中心、可插拔网关、基础服务和业务服务的配置;
在另一个节点服务器中搭建基础数据库和业务数据库;
在另一个节点服务器中从组件仓库拉取拉取基础服务的独立部署包并部署;
在另一个节点服务器中从组件仓库拉取拉取业务服务的独立部署包并部署。
本发明的技术方案中,提出了一种通用的微服务技术架构,可采用集中式打包,单体部署,或者微服务分布式部署或者微服务打包,进行分布式集群部署,并且可以相互切换,可以极大的减少了对企业原有新、老多套架构的维护成本,在项目的应用和升级上降本增效显著,且利于技术插件的扩展。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图示出的结构获得其他的附图。
图1为本发明一种实现弹性部署的微服务***的结构示意图。
图2为本发明一种实现弹性部署的微服务***的部署方法示意图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明的一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
在本发明中如涉及“第一”、“第二”等的描述仅用于描述目的,而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
另外,本发明各个实施例之间的技术方案可以相互结合,但是必须是以本领域普通技术人员能够实现为基础,当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在,也不在本发明要求的保护范围之内。
本发明提出一种实现弹性部署的微服务***及部署方法,包括后端服务模块以及均与所述后端服务模块连接的服务治理模块、web服务模块和发布服务模块;所述后端服务模块包括基础服务组件、业务服务组件和数据库组件;所述服务治理模块包括可插拔网关组件、可分离式注册中心组件、自适应缓存组件和一体化配置服务组件,所述web服务模块通过所述可插拔网关组件与所述后端服务模块连接,所述web服务模块包括web服务器中部署的网页程序;所述发布服务模块包括依次连接的服务打包组件、入库组件、拉取组件和项目部署组件,所述服务打包组件用于对每一个应用服务同时打二个包,一个是可独立部署的运行包,一个是依赖包,所述入库组件用于将服务包推送到组件库,所述拉取组件用于拉取服务包到要部署的服务器,所述项目部署组件包括用于在单体环境中进行部署的单体部署单元、用于在搭建好的微服务环境中进行部署的分布式部署单元和用于根据业务访问和服务器节点性能进行集群规划的分布式集群部署单元。
本发明的技术方案中,提出了一种通用的微服务技术架构,可采用集中式打包,单体部署,或者微服务分布式部署或者微服务打包,进行分布式集群部署,并且可以相互切换,可以极大的减少了对企业原有新、老多套架构的维护成本,在项目的应用和升级上降本增效显著,且利于技术插件的扩展。
1、一套通用的微服务技术架构,极大的减少了对企业原有新、老多套架构的维护成本,在项目的应用和升级上降本增效显著,且利于技术插件的扩展;
2、对于访问量较小,资源要求不高的项目,可采用集中式打包,单体部署。极大的减少了企业对硬件资源的采购、部署和维护成本;
3、对于访问量较小,对硬件网络资源要求高的项目,可用微服务分布式部署。可以降低单个硬件资源的采购成本,复用已有的设备;
4、对于业务逻辑复杂、访问量大、并发量高的项目,可采用按微服务打包,进行分布式集群部署。可以按访问量大小,动态调整集群节点的数量,而采用的技术架构和基础底座与单体式是一样的,只需改动极少配置,开发和运维的便利性、可维护性是不言而喻的。
具体的,
①一套统一的架构:设计一套统一的技术架构,应用于企业所有的项目。既可以按微服务进行分布式部署,也可以将所有微服务一起打包进行集中式部署。无论进行何种部署,架构上均不需要进行编码上的任何调整,仅需改动少量配置即可。
②支持多种部署方式:可视项目访问量大小,硬件资源条件,同时支持多种部署方式。对于访问量较小,对硬件网络资源要求不高的项目,可采用集中式打包,单体部署。访问量较小,对硬件网络资源要求高的项目,可用分布式部署。对于业务逻辑复杂、访问量大、并发量高的项目,可采用按微服务打包,进行分布式集群部署,并按访问量设置集群节点的数量。
更具体的,技术架构组成:
第一部分:web服务。采用前后端分离,前端主要是web服务器中部署的网页程序;
第二部分:后端服务。主要包括基础服务、若干业务服务、数据库,运行着后端应用和数据服务。
第三部分:服务治理。主要用于服务的注册查找、配置转发等,包括可插拔网关、可分离式注册中心、自适应缓存、一体化配置服务。
第四部分:扩展服务。用户提供可扩展的服务,包括消息服务、任务调度、对象存储、低代码、流程引擎等。
第五部分:发布服务。是本架构实现弹性部署的关键组件,它根据一体化配置服务信息,将每一个后端服务同时发布成支持微服务部署的独立运行包和支持单体布署的依赖包。对于可插拔网关,在单体部署中是可选的,可根据配置进行取舍。对于注册中心,在单体部署时被分离。对于缓存,可依部署形式,进行本地缓存或分布式缓存切换。对于扩展服务和数据库,不用改变,与部署形式无关。
依托开源生态,遵循云原生、分布式、无配置、弹性扩展的基础上,对注册中心、配置中心、统一网关、服务间调用、接口安全、服务扩展等组件均进行了定制化和创新,形成了一套适应弹性部署的通用技术底座。
在本发明的另一实施方式中,所述基础服务组件包括服务间通信SDK单元、URL重写单元和启动排除单元,所述服务间通信SDK单元用于使用自定义的SDK进行服务调用,可在远程服务和本地服务之间灵活切换;所述URL重写单元用于切换部署方式时对URL进行重写,所述启动排除单元用于单体部署,项目启动时,自动排除掉微服务相关的启动类和服务熔断类的配置注入。
具体的,基础服务:是进行灵活部署的通用技术底座,提供了强大的基础功能,为所有业务服务提供了可靠的基础支撑。主要功能特色有:
单点登录对token采用了自定义的加密算法;
控制器开发定义了Restful风格的资源访问规范,提供了版本号控制,封装了通用的响应数据格式;
文档中心基于swagger进行定制,为各个业务服务提供统一的访问与测试界面;
封装独立的API层,规范服务之间的接口数据;
数据访问层提供通用的接口层与动态sql,极大的减少了硬编码与重复编码;
实体层封装了多种主键策略、逻辑删除、数据自动填充;
权限模块提供了强大的数据权限、模块级权限、字段级权限,满足了业务架构的灵活调整,成功将业务需求推迟到了开发与使用阶段;
强大的工具库、***、过滤器、转换器、解析器等。
服务间通信SDK:传统微服务架构采用标准的OPEN-FEIGN组件进行调用,依赖性强,需要引入大量的微服务体系的依赖包。本设计中使用自定义的SDK进行服务调用,通过接口机制,可在远程服务和本地服务之间灵活切换;根据业务需求进行精简和定制,更灵活地控制请求和响应数据的格式和内容,避免引入不必要的依赖;还可对具体的业务需求进行优化,使用更加安全的加密算法和协议,从而提高数据的安全性。
URL重写:当使用微服务部署时,访问路径会带上微服务名称作为根目录。而在单体服务上所有的访问路径都不带这个根目录,所以需要对URL进行重写,访问时过滤掉这个根目录。
<rule>
<from>^/shandy-sys/(.*)</from>
<to>/$1</to>
</rule>。
启动排除:对于单体部署,会在项目启动时,自动排除掉微服务相关的启动类、服务熔断类的配置注入。
在本发明的又一实施方式中,所述可插拔网关组件包括可插拔配置配置单元和身份认证单元,所述可插拔配置配置单元用于在一体化配置服务中,对网关的可插拔配置项进行配置,所述可插拔配置项在不同的部署依赖包中不同配置,所述身份认证单元用于对拦截到请求进行特定的验证处理。
具体的,可插拔网关:在传统的路由转发、负载均衡、安全认证功能中,加强了可插拔配置、身份认证功能。
可插拔配置:在一体化配置服务中,对网关进行可插拔相关的配置,配置项如下。生成的支持单体部署的依赖包中不包含网关中路由转发、负载均衡等配置。单体部署时,该网关依赖包是可选的。
配置网关与可分离式注册中心的集成,使得网关能够自动发现和注销;
配置负载均衡策略;
配置安全认证和授权策略;
配置日志和监控方案;
配置自动扩容和缩容策略;
配置高可用和容错策略;
2)身份认证,对拦截到请求进行特定的验证处理:
finalstaticStringHEAD_DATA_SIGNATURE="Data-Signature";
publicMono<Void>filter(ServerWebExchangeexchange,GatewayFilterChainchain){
//Token放行
String
originalRequestURL=RequestProvider.getOriginalRequestURL(exchange);
Stringpath=exchange.getRequest().getURI().getPath();
if(isSkip(path)||isSkip(originalRequestURL)){
returnchain.filter(exchange);
}
//签名放行
StringdataSignature=exchange.getRequest().getHeaders().getFirst(HEAD_DATA_SIGNATURE);
if(SignatureUtils.isValid(dataSignature)){
returnchain.filter(exchange);
}
接口签名验证规则,在线下分配appId和appSecret,针对不同的调用方分配不同。签名的请求必须满足这个规则:时间戳10分钟内数据有效;signature所有数据的签名信息;通过appSecret加解密签名信息。请求头结构体如下:
publicinterfaceISignature{
StringINT_SIGNATURE="Signature";//请求签名
StringINT_APP_ID="App-Id";//应用标识
StringINT_TS="Data-Ts";//当前时间戳
}
在本发明的又一实施方式中,所述一体化配置服务组件包括实时更新单元、权限认证单元、版本控制单元、多环境单元和开关切换单元;所述实时更新单元用于可以实时地更新配置信息;所述权限认证单元用于保护配置信息的机密性和完整性,所述版本控制单元用于保证配置信息可追溯性和可恢复性;所述多环境单元用于针对不同的环境提供不同的配置信息,方便部署和测试;所述开关切换单元包括总切换开关,所述总切换开关用于切换为微服务或单体服务,当切换成单体服务时,只会引入相关模块的依赖包,并会排除掉相关微服务的依赖包。
具体的,一体化配置服务:集中管理所有的配置信息,包括:
实时更新:配置信息包括数据库连接、服务端口、日志级别、注册中心等,可以实时地更新配置信息而不需要重启服务;
访问控制和权限认证:保护配置信息的机密性和完整性
版本控制:保证配置信息可追溯性和可恢复性。
多环境:针对不同的环境(开发、测试、生产)提供不同的配置信息,方便部署和测试。
开关切换:配置一个总开关,在微服务与单体服务中灵活切换。当切换成单体服务时,只会引入相关模块的依赖包,而不是独立部署包,并会排除掉相关微服务的依赖包。
在本发明的又一实施方式中,所述可分离式注册中心组件包括抽象接口单元、配置文件单元、中间件代理单元和服务注册协议单元;所述抽象接口单元用于将注册中心的核心功能抽象成接口,并定义标准的API规范,让服务提供者和消费者都可以使用API来进行服务注册和发现操作;所述配置文件单元用于将注册中心的地址、端口等信息写在一体化配置服务的文件中,并加上了开关配置,这样服务提供者和消费者就可以通过修改配置文件来更换注册中心的实现;所述中间件代理单元用于使用服务网格来进行注册中心的访问,将服务提供者和消费者与注册中心实现解耦;所述服务注册协议用于定义统一的服务注册协议Restful,并让不同的注册中心都遵循。
具体的,可分离式注册中心:注册中心是一个关键的组件,它主要用于服务的注册与发现,本架构采用以下方法,实现单体部署时,与注册中心进行分离:
1)抽象接口:将注册中心的核心功能抽象成接口,定义标准的API规范,让服务提供者和消费者都可以使用这些API来进行服务注册和发现操作。这样,即使更换了注册中心的实现,对外暴露的API接口不变,服务提供者和消费者都不需要做出任何修改。
2)配置文件:将注册中心的地址、端口等信息写在一体化配置服务的文件中,并加上了开关配置,这样服务提供者和消费者就可以通过修改配置文件来更换注册中心的实现。
3)中间件代理:使用服务网格来进行注册中心的访问,将服务提供者和消费者与注册中心实现解耦。这样,在更换注册中心实现时,只需要修改中间件代理的配置即可。
4)服务注册协议:定义统一的服务注册协议Restful,让不同的注册中心实现都遵循这个协议。
@RestController
@RequestMapping("/register")
publicclassRegisterController{
@Autowired
privateRegisterServiceregisterService;
@PostMapping
publicResponseEntity<?>registerService(@RequestBodyServiceInfoserviceInfo){
if(registerService.registerService(serviceInfo)){
returnResponseEntity.ok().build();
}else{
returnResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).build();
}
}
@GetMapping("/{serviceName}")
publicResponseEntity<ServiceInfo>getServiceInfo(@PathVariableStringserviceName){
ServiceInfoserviceInfo=registerService.getServiceInfo(serviceName);
if(serviceInfo!=null){
returnResponseEntity.ok(serviceInfo);
}else{
returnResponseEntity.notFound().build();
}
}
}
在本发明的又一实施方式中,所述自适应缓存组件包括本地缓存单元,分布式缓存单元和缓存管理器单元,所述缓存管理器用于接收请求并从所述本地缓存单元或分布式缓存单元中获取数据,所述本地缓存单元用于管理本地缓存,所述分布式缓存单元用于管理分布式的缓存。
具体的,自适应缓存:设计一个本地缓存Caffeine和分布式缓存Redis方案,可根据配置进行组合应用与无缝切换:
1)服务启动时,初始化本地缓存Caffeine和分布式缓存Redis,然后将它们封装为一个缓存管理器。
2)当服务接收到请求时,从缓存管理器中获取缓存数据。如果本地缓存Caffeine中存在,则直接返回;否则,从分布式缓存Redis中获取数据,并将其缓存在本地缓存Caffeine中。
3)当缓存数据过期时,根据缓存策略选择是否从分布式缓存Redis中重新获取数据,并更新本地缓存Caffeine中的缓存数据。
4)评估分布式缓存Redis的性能,根据实际情况动态调整缓存策略。当Redis缓存性能差时,降低本地缓存Caffeine的过期时间。当Redis恢复正常或者性能提高,增加本地缓存Caffeine的过期时间,以提高缓存的命中率。
5)服务关闭时,释放缓存管理器中的资源。
在本发明的又一实施方式中,所述发布服务模块包括服务打包组件、入库组件、拉取组件和项目部署组件,所述服务打包组件用于对每一个应用服务同时打二个包,一个是可独立部署的运行包,一个是依赖包,所述入库组件用于将服务包推送到组件库,所述拉取组件用于拉取服务包到要部署的服务器,所述项目部署组件包括用于在单体环境中进行部署的单体部署单元、用于在搭建好的微服务环境中进行部署的分布式部署单元和用于根据业务访问和服务器节点性能进行集群规划的分布式集群部署单元。
具体的,服务打包:可使用maven、gradle、ant等工具进行打包,如用maven打包时注意在pom文件中指定。对每一个应用模块,需同时打二个包,一个是可独立部署的运行包,一个是依赖包。相关配置如下:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>full</classifier>
</configuration>
</execution>
</executions>
</plugin>
组件入库:使用如mvndeploy命令,将服务包推送到组件库如Nexus。
拉取组件:可以使用git、svn等工具拉取服务包到要部署的服务器,包括基础服务、业务服务、可插拔网关服务。
项目部署:
单体部署:在单体环境中,使用pm2等工具启动基础包即可,其它包如业务包、可插拔网关服务包均为依赖包,不需要独立启动。
分布式部署:在搭建好的微服务环境中,使用pm2等工具,独立启动拉取到的每个服务包。
分布式集群部署:视业务访问量大小和服务器节点的性能,对基础服务和业务服务进行集群规划,消除单点故障。
一种实现弹性部署的微服务***的部署方法,包括如下步骤:
S100,采用如上任一所述的实现弹性部署的微服务***来开发底层基础服务和业务服务;
S200,在业务服务开发完成后,同时发布基础服务与业务服务的独立部署包和依赖包,并推送到组件仓库;
S300,按照不同的部署环境,规划服务器和配置服务器,根据部署环境从所述组件仓库拉取独立部署包或者依赖包搭建基础服务和业务服务。
具体的,架构设计与开发。考虑到要同时支持单体部署和微服务分布式部署,并且只能采用一套统一的技术架构,所以采用上面的架构设计,开发底层技术框架,即基础服务。
第二步:SHANDY-DORC业务服务开发。使用本架构提供的基础服务,开发业务服务。
第三步:服务发布与组件入库:
3.1、业务服务开发完成后,同时发布基础服务与SHANDY-DORC业务服务的独立部署包、依赖包。
3.2、发布完成后,将服务包推送到组件仓库。
在本发明的又一实施方式中,所述S300的步骤,包括:
S310,按照单体部署环境,规划一台服务器;
S320,在服务器内搭建web服务器、基础数据库和业务数据库;
S330,从组件仓库拉取支持单体部署的基础服务依赖包和业务服务依赖包并启动服务。
具体的,单体环境部署。
规划好服务器,因为是单体环境,所以只需要一台性能较好的服务器即可,前端web服务器、后端基础服务、业务服务、数据库、扩展服务均部署在这台机器上。可插拔网关服务是可选的,这里不选择使用。
4.1、web服务器搭建:搭建web服务器如Nginx,部署前端项目并运行;
4.2、数据库搭建:一般选择关系数据库如mysql、postgresql等,搭建基础数据库、SHANDY-DORC业务数据库共二个;
4.3、服务部署:从组件仓库拉取支持单体部署的基础服务依赖包,SHANDY-DORC业务服务依赖包。然后用pm2启动基础服务,后端服务开始运行。
4.4、扩展服务部署:这个可根据项目需求选择,包括消息服务器、任务调度服务器、对象存储服务器;
在本发明的又一实施方式中,所述S300的步骤,包括:
S340,按照微服务部署环境,规划多台服务器;
S350,在其中一个节点服务器中搭建web服务器和可插拔网关服务器;
S360,在另一个节点服务器中搭建可分离式注册中心服务器、自适应缓存服务器和一体化配置服务器,并进行可分离式注册中心、可插拔网关、基础服务和业务服务的配置;
S370,在另一个节点服务器中搭建基础数据库和业务数据库;
S380,在另一个节点服务器中从组件仓库拉取拉取基础服务的独立部署包并部署;
S390,在另一个节点服务器中从组件仓库拉取拉取业务服务的独立部署包并部署。
具体的,升级到微服务分布式部署:
5.1、升级到微服务部署,规划好服务器,前期按5节点部署:
Web服务器+可插拔网关:1个节点A
可分离式注册中心+一体化配置服务+自适应缓存:1个节点B
基础数据库+业务数据库:1个节点C
基础微服务+扩展服务:1个节点D
SHANDY-DORC业务微服务:1个节点E
5.2、web服务器搭建:在A节点中搭建Nginx服务器,部署前端应用;
5.3、可插拔网关服务器搭建:拉取可插拔网关服务包到A节点,搭建网关微服务;
5.4、可分离式注册中心搭建:在B节点上搭建注册中心服务器;
5.5、一体化配置服务器搭建:在B节点上搭建配置服务器,然后上传项目中的配置文件,进行可分离式注册中心、可插拔网关、基础服务、业务服务的配置;
5.6、自适应缓存服务器搭建:在B节点中搭建分布式缓存如Redis,可与本地缓存Caffeine搭配使用;
5.7、数据库环境搭建:在C节点中搭建关系数据库服务器,并建立二个数据库,分别是基础服务数据库,SHANDY-DORC业务服务数据库;
5.8、基础微服务搭建:在D节点中拉取基础微服务独立部署包,用PM2进行管理;
5.9、扩展服务环境搭建:在D节点中部署相关扩展服务如消息服务器、任务调度服务器、对象存储服务器;
5.10、SHANDY-DORC业务微服务环境搭建:在E节点中拉取SHANDY-DORC业务服务独立部署包,用PM2进行管理;
在本发明的又一实施方式中,所述S300的步骤,包括:
升级微服务成集群部署:
随着业务的扩展,业务微服务必须由单节点,升级到多节点部署,按性能估算,按5节点集群部署,可以很好的满足高峰期的业务访问量。
其各节点部署可以参考第五步“升级到微服务分布式部署”,其中5.10步骤更新如下:
5.10、业务微服务环境搭建:在E1、E2、E3、E4、E5共5个节点中分别拉取业务服务独立部署包,用PM2进行管理;对于多节点部署,后期为了管理方便,可以使用Jenkins工具或K8S+Docker环境,进行自动化部署。
在本发明的又一实施方式中,以SHANDY-DORC业务服务为例,考虑以下场景,前期使用用户较少,决定使用单体部署,以节约服务器资源。随着业务推广,用户量急增,单服务器性能明显不能满足应用的性能需求,此时决定使用微服务分布式部署。后期业务量稳定,SHANDY-DORC微服务节点集群部署数量稳定在5个左右。
下面描述一下其具体的实施过程:
第一步:架构设计与开发。考虑到要同时支持单体部署和微服务分布式部署,并且只能采用一套统一的技术架构,所以采用上面的架构设计,开发底层技术框架,即基础服务。
第二步:SHANDY-DORC业务服务开发。使用本架构提供的基础服务,开发业务服务。
第三步:服务发布与组件入库:
3.1、业务服务开发完成后,同时发布基础服务与SHANDY-DORC业务服务的独立部署包、依赖包。
3.2、发布完成后,将服务包推送到组件仓库。
第四步:单体环境部署。
规划好服务器,因为是单体环境,所以只需要一台性能较好的服务器即可,前端web服务器、后端基础服务、业务服务、数据库、扩展服务均部署在这台机器上。可插拔网关服务是可选的,这里不选择使用。
4.1、web服务器搭建:搭建web服务器如Nginx,部署前端项目并运行;
4.2、数据库搭建:一般选择关系数据库如mysql、postgresql等,搭建基础数据库、SHANDY-DORC业务数据库共二个;
4.3、服务部署:从组件仓库拉取支持单体部署的基础服务依赖包,SHANDY-DORC业务服务依赖包。然后用pm2启动基础服务,后端服务开始运行。
4.4、扩展服务部署:这个可根据项目需求选择,包括消息服务器、任务调度服务器、对象存储服务器;
第五步:升级到微服务分布式部署:
5.1、升级到微服务部署,规划好服务器,前期按5节点部署:
Web服务器+可插拔网关:1个节点A
可分离式注册中心+一体化配置服务+自适应缓存:1个节点B
基础数据库+业务数据库:1个节点C
基础微服务+扩展服务:1个节点D
SHANDY-DORC业务微服务:1个节点E
5.2、web服务器搭建:在A节点中搭建Nginx服务器,部署前端应用;
5.3、可插拔网关服务器搭建:拉取可插拔网关服务包到A节点,搭建网关微服务;
5.4、可分离式注册中心搭建:在B节点上搭建注册中心服务器;
5.5、一体化配置服务器搭建:在B节点上搭建配置服务器,然后上传项目中的配置文件,进行可分离式注册中心、可插拔网关、基础服务、业务服务的配置;
5.6、自适应缓存服务器搭建:在B节点中搭建分布式缓存如Redis,可与本地缓存Caffeine搭配使用;
5.7、数据库环境搭建:在C节点中搭建关系数据库服务器,并建立二个数据库,分别是基础服务数据库,SHANDY-DORC业务服务数据库;
5.8、基础微服务搭建:在D节点中拉取基础微服务独立部署包,用PM2进行管理;
5.9、扩展服务环境搭建:在D节点中部署相关扩展服务如消息服务器、任务调度服务器、对象存储服务器;
5.10、SHANDY-DORC业务微服务环境搭建:在E节点中拉取SHANDY-DORC业务服务独立部署包,用PM2进行管理;
第六步:升级微服务成集群部署:
随着业务的扩展,SHANDY-DORC业务微服务必须由单节点,升级到多节点部署,按性能估算,按5节点集群部署,可以很好的满足高峰期的业务访问量。
其各节点部署可以参考第五步“升级到微服务分布式部署”,其中5.10步骤更新如下:
5.10、SHANDY-DORC业务微服务环境搭建:在E1、E2、E3、E4、E5共5个节点中分别拉取SHANDY-DORC业务服务独立部署包,用PM2进行管理;对于多节点部署,后期为了管理方便,可以使用Jenkins工具或K8S+Docker环境,进行自动化部署。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是在本发明的构思下,利用本发明说明书及附图内容所作的等效结构变换,或直接/间接运用在其他相关的技术领域均包括在本发明的专利保护范围内。

Claims (9)

1.一种实现弹性部署的微服务***,其特征在于,包括后端服务模块以及均与所述后端服务模块连接的服务治理模块、web服务模块和发布服务模块;所述后端服务模块包括基础服务组件、业务服务组件和数据库组件;所述服务治理模块包括可插拔网关组件、可分离式注册中心组件、自适应缓存组件和一体化配置服务组件,所述web服务模块包括web服务器中部署的网页程序;所述发布服务模块包括依次连接的服务打包组件、入库组件、拉取组件和项目部署组件,所述服务打包组件用于对每一个应用服务同时打二个包,一个是可独立部署的运行包,一个是依赖包,所述入库组件用于将服务包推送到组件库,所述拉取组件用于拉取服务包到要部署的服务器,所述项目部署组件包括用于在单体环境中进行部署的单体部署单元、用于在搭建好的微服务环境中进行部署的分布式部署单元和用于根据业务访问和服务器节点性能进行集群规划的分布式集群部署单元。
2.如权利要求1所述的一种实现弹性部署的微服务***,其特征在于,所述基础服务组件包括服务间通信SDK单元、URL重写单元和启动排除单元,所述服务间通信SDK单元用于使用自定义的SDK进行服务调用,可在远程服务和本地服务之间灵活切换;所述URL重写单元用于切换部署方式时对URL进行重写,所述启动排除单元用于单体部署,项目启动时,自动排除掉微服务相关的启动类和服务熔断类的配置注入。
3.如权利要求1所述的一种实现弹性部署的微服务***,其特征在于,所述可插拔网关组件包括可插拔配置配置单元和身份认证单元,所述可插拔配置配置单元用于在一体化配置服务中,对网关的可插拔配置项进行配置,所述可插拔配置项在不同的部署依赖包中不同配置,所述身份认证单元用于对拦截到请求进行特定的验证处理。
4.如权利要求1所述的一种实现弹性部署的微服务***,其特征在于,所述一体化配置服务组件包括实时更新单元、权限认证单元、版本控制单元、多环境单元和开关切换单元;所述实时更新单元用于可以实时地更新配置信息;所述权限认证单元用于保护配置信息的机密性和完整性,所述版本控制单元用于保证配置信息可追溯性和可恢复性;所述多环境单元用于针对不同的环境提供不同的配置信息,方便部署和测试;所述开关切换单元包括总切换开关,所述总切换开关用于切换为微服务或单体服务,当切换成单体服务时,只会引入相关模块的依赖包,并会排除掉相关微服务的依赖包。
5.如权利要求1所述的一种实现弹性部署的微服务***,其特征在于,所述可分离式注册中心组件包括抽象接口单元、配置文件单元、中间件代理单元和服务注册协议单元;所述抽象接口单元用于将注册中心的核心功能抽象成接口,并定义标准的API规范,让服务提供者和消费者都可以使用API来进行服务注册和发现操作;所述配置文件单元用于将注册中心的地址和端口信息写在一体化配置服务的文件中,并加上了开关配置,这样服务提供者和消费者就可以通过修改配置文件来更换注册中心的实现;所述中间件代理单元用于使用服务网格来进行注册中心的访问,将服务提供者和消费者与注册中心实现解耦;所述服务注册协议用于定义统一的服务注册协议Restful,并让不同的注册中心都遵循。
6.如权利要求1所述的一种实现弹性部署的微服务***,其特征在于,所述自适应缓存组件包括本地缓存单元,分布式缓存单元和缓存管理器单元,所述缓存管理器用于接收请求并从所述本地缓存单元或分布式缓存单元中获取数据,所述本地缓存单元用于管理本地缓存,所述分布式缓存单元用于管理分布式的缓存。
7.一种实现弹性部署的微服务***的部署方法,其特征在于,包括如下步骤:
采用如权利要求1-6中任一所述的实现弹性部署的微服务***来开发底层基础服务和业务服务;
在业务服务开发完成后,同时发布基础服务与业务服务的独立部署包和依赖包,并推送到组件仓库;
按照不同的部署环境,规划服务器和配置服务器,根据部署环境从所述组件仓库拉取独立部署包或者依赖包搭建基础服务和业务服务。
8.如权利要求7所述的一种实现弹性部署的微服务***的部署方法,其特征在于,所述按照不同的部署环境,规划服务器和配置服务器,根据部署环境从所述组件仓库拉取独立部署包或者依赖包搭建基础服务和业务服务的步骤,包括:
按照单体部署环境,规划一台服务器;
在服务器内搭建web服务器、基础数据库和业务数据库;
从组件仓库拉取支持单体部署的基础服务依赖包和业务服务依赖包并启动服务。
9.如权利要求7所述的一种实现弹性部署的微服务***的部署方法,其特征在于,所述按照不同的部署环境,规划服务器和配置服务器,根据部署环境从所述组件仓库拉取独立部署包或者依赖包搭建基础服务和业务服务的步骤,包括:
按照微服务部署环境,规划多台服务器;
在其中一个节点服务器中搭建web服务器和可插拔网关服务器;
在另一个节点服务器中搭建可分离式注册中心服务器、自适应缓存服务器和一体化配置服务器,并进行可分离式注册中心、可插拔网关、基础服务和业务服务的配置;
在另一个节点服务器中搭建基础数据库和业务数据库;
在另一个节点服务器中从组件仓库拉取拉取基础服务的独立部署包并部署;
在另一个节点服务器中从组件仓库拉取拉取业务服务的独立部署包并部署。
CN202410703178.6A 2024-06-03 2024-06-03 一种实现弹性部署的微服务***及部署方法 Pending CN118283100A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410703178.6A CN118283100A (zh) 2024-06-03 2024-06-03 一种实现弹性部署的微服务***及部署方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410703178.6A CN118283100A (zh) 2024-06-03 2024-06-03 一种实现弹性部署的微服务***及部署方法

Publications (1)

Publication Number Publication Date
CN118283100A true CN118283100A (zh) 2024-07-02

Family

ID=91648369

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410703178.6A Pending CN118283100A (zh) 2024-06-03 2024-06-03 一种实现弹性部署的微服务***及部署方法

Country Status (1)

Country Link
CN (1) CN118283100A (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180159747A1 (en) * 2016-12-05 2018-06-07 General Electric Company Automated feature deployment for active analytics microservices
CN116107590A (zh) * 2023-01-17 2023-05-12 山谷网安科技股份有限公司 软件产品开发部署中兼容微服务和单体架构的实现方法及***
CN116263663A (zh) * 2021-12-13 2023-06-16 山东华软金盾软件股份有限公司 一种微服务灵活部署的方法
CN117573111A (zh) * 2023-11-14 2024-02-20 佳都科技集团股份有限公司 一种微服务部署方法、装置、设备及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180159747A1 (en) * 2016-12-05 2018-06-07 General Electric Company Automated feature deployment for active analytics microservices
CN116263663A (zh) * 2021-12-13 2023-06-16 山东华软金盾软件股份有限公司 一种微服务灵活部署的方法
CN116107590A (zh) * 2023-01-17 2023-05-12 山谷网安科技股份有限公司 软件产品开发部署中兼容微服务和单体架构的实现方法及***
CN117573111A (zh) * 2023-11-14 2024-02-20 佳都科技集团股份有限公司 一种微服务部署方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
EP3700132B1 (en) Supporting compilation and extensibility on unified graph-based intent models
WO2019062304A1 (zh) 用于管理区块链节点的计算资源的方法、设备和***
CN114401098B (zh) 一种快速构建微服务的应用***及方法
US8719780B2 (en) Application server with a protocol-neutral programming model for developing telecommunications-based applications
CN106603582B (zh) 一种网络微服务发现方法
Strassner DEN-ng: achieving business-driven network management
US20120102080A1 (en) Computer system and storage capacity extension method
CN109948356A (zh) 一种基于微服务架构下服务调用权限控制方法
US20030069956A1 (en) Object oriented SNMP agent
JP2011527781A (ja) ネットワーク資源がサービス・ランドスケープ・インスタンス内でプロビジョンされるときに、ネットワーク・セキュリティ・ポリシ・ルールを更新するためのコンピュータ実装方法、システム及びコンピュータ・プログラム
WO2012054160A2 (en) High availability of machines during patching
EP3758292A1 (en) Managing multiple semantic versions of device configuration schemas
US20030069955A1 (en) SNMP agent object model
Hong et al. Netgraph: An intelligent operated digital twin platform for data center networks
JP2024505692A (ja) ブロックチェーンネットワークに基づくデータ処理方法、装置及びコンピュータ機器
CN112035216A (zh) 一种Kubernetes集群网络和OpenStack网络的打通方法
WO2007068175A1 (fr) Systeme et procede permettant de declencher un systeme de regles
CN113098982B (zh) 区块链消息的传输方法及装置
CN114363162A (zh) 区块链日志的生成方法及装置、电子设备、存储介质
CN118283100A (zh) 一种实现弹性部署的微服务***及部署方法
US20070299819A1 (en) Resource discovery and enumeration in meta-data driven instrumentation
WO2015196524A1 (zh) 软件升级处理方法、装置、终端及服务器
CN108270718A (zh) 一种基于Hadoop集群的控制方法和***
CN115225641B (zh) 一种Kong适配Nacos的客户端负载均衡方法及***
CN117908904B (zh) 一种k8s集群部署及运维管理的方法和***

Legal Events

Date Code Title Description
PB01 Publication
SE01 Entry into force of request for substantive examination