[发明专利]微服务提供方法、装置及系统

说明书

技术领域

本发明涉及通信领域，尤其涉及一种微服务提供方法、装置及系统。

背景技术

当前在企业内部基本都是按照系统独立建设，对于业务系统按照单一应用建设模式下，业务系统本身再进行弹性扩展能力相当较弱，当前的单体应用本身主要带来的如下一些问题难以解决：

1.系统复杂：内部多个模块紧耦合，关联依赖复杂，牵一发而动全身。

2.运维困难：变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体运行出现故障。

3.无法扩展：无法拆分部署，出现性能瓶颈后往往只能够增加服务器或增加集群节点，但是DB问题难解决。

当前对于各个业务系统其内部完全是黑盒，即业务系统内部虽然也划分了多个模块和组件，但是各个模块之间无法做到独立部署和管理。同时由于所有模块都在一个开发工程项目里面，模块之间往往都是通过点对点相关应用程序编程(Application Programming Interface，简称为API)接口进行模块间的业务和数据交互，图1根据相关技术中的微服务系统的示意图，如图1所示，具体技术方案描述如下：业务系统内部各个模块组件紧耦合，无法实现组件化和服务化。业务系统内部各个模块之间通过点对点接口进行交互。当前业务系统内部的各个组件调用，大部分系统是直接通过Java内部的API接口进行调用，对于个别的业务系统当前使用了类似面向Java的动态模型系统(Open Service Gateway Initiative，简称为OSGI)的内部服务软总线模式，即将API接口发布注册到OSGI上再进行服务发布。接口当前有采用WebService方式实现的，经过初步调研有的业务系统采用了简单对象访问协议(Simple Object Access Protocol，简称为SOAP)WebService消息协议，有的业务系统采用了Restful WebService消息，但是该类接口服务的使用也仅仅局限在业务系统需要发布接口服务给外部业务系统使用时的场景。

对于当前的技术方案，在业务系统组件化和微服务化后，模块会暴露成白上线的服务，这些服务本身都需要进行安全，日志，缓存，负载，动态扩展等能力。如果仍然采用点对点服务调用，将导致每一个服务都需要去实现这些能力。在业务系统微服务化后，微服务模块会部署在类似Docker容器里面，其中，Docker是一个开源的应用容器引擎，那么对于微服务模块在通过容器动态扩展和部署的时候，都需要手工去配置和管理微服务的发布。对于一些特定的场景，往往需要将多个细粒度的微服务组合成一个领域服务能力，但是当前技术实现层面没有专门的组件和模块来实现该能力。微服务模块提供的API和IP地址会直接暴露给消费模块，即导致微服务模块在动态部署和IP调整时候都会影响到消费方。

针对相关技术中对于微服务模块在通过容器动态扩展和部署的时候，都需要手工去配置和管理微服务的发布的问题，目前尚未提出解决方案。

发明内容

本发明的主要目的在于提出一种微服务提供方法、装置及系统，旨在解决相关技术中相关技术中对于微服务模块在通过容器动态扩展和部署的时候，都需要手工去配置和管理微服务的发布的问题。

为实现上述目的，本发明实施例提供的一种微服务提供方法，所述方法包括：微服务网关接收服务消费方发送的服务访问请求；所述微服务网关根据所述服务访问请求查询预先设置的服务可用地址信息列表，确定提供该服务的微服务模块；所述微服务网关将所述微服务模块的地址信息反馈给所述服务消费方，供所述服务消费方进行服务访问。

优选地，所述微服务网关根据所述服务访问请求查询预先设置的服务可用地址信息列表，确定提供该服务的微服务模块包括：所述微服务网关根据所述服务访问请求查询所述服务可用地址信息列表，确定可提供该服务的多个微服务模块；所述微服务网关通过轮询或哈希算法对所述服务访问请求进行负载均衡处理，从所述多个微服务模块确定提供该服务的微服务模块。

优选地，在所述微服务网关通过轮询或哈希算法对所述服务访问请求进行负载均衡处理，从所述多个微服务模块确定提供该服务的微服务模块之后，所述方法还包括：所述微服务网关将所述服务访问请求路由到确定的所述微服务模块；所述微服务网关接收所述微服务模块返回的服务输出信息；所述微服务网关将服务输出信息返回给所述服务消费方。

优选地，所述方法还包括：所述微服务网关将所述服务输出信息存储到内部的消息中间件；所述微服务网关通过所述消息中间件的记录，将微服务访问的数据日志进行持久化记录。