[发明专利]一种治理功能插件化的微服务开发框架及实现方法

说明书

本发明涉及一种治理功能插件化的微服务开发框架及其实现方法，其采用插件的实现方式，通过面向对象接口设计，以及依赖注入等设计方案，解决了如何将功能模块变得通用且与框架松耦合的业务难题，大大降低接入方的使用维护成本，降低了微服务开发框架的内部复杂度。同时，本发明在微服务开发框架中定义了配置更新等独立功能的公共接口聚合定义，当插件实现了这些接口定义时，框架能够处理对应的逻辑来为插件自身的独立更新提供支持，在面对具体业务场景时，插件能够保证独立的提供服务，不被其他业务所影响，与业务和其他插件解耦。

技术领域

本发明属于微服务开发框架领域，尤其涉及一种治理功能插件化的微服务开发框架及实现方法。

背景技术

微服务是指在功能不变的情况下，把一个大型的单个应用程序和服务拆分为多个可管理的服务。每个服务根据自己的需要选择技术栈，互不影响，方便开发、维护，好处是有效的拆分应用，实现敏捷开发和部署。微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃。为了防止此类问题的出现，微服务在其架构中加入了服务治理相关策略，如服务限流、降级、熔断、容错等。但是这些治理策略与微服务代码高度耦合，使得修改微服务治理策略必须修改微服务代码。如此也增加代码维护性难度、运维复杂度。

由于微服务开发框架都需要引入治理功能。目前行业内对于“引入新功能”存在：直接将功能集成于内部或者调用接口进行参数传递两种主要解决方案。由于微服务集群的聚合特性，同一微服务集群往往会使用相同的治理功能。以上两种解决方案针对这一场景普遍存在如下问题：1. 开发人员需要感知并定义功能实现。若大型的微服务集群中微服务个体持有的治理功能都是一致的，不必要让每一个微服务开发人员都感知并定义这一级功能实现，由于每个功能都需要开发人员在代码层面使用大量处理逻辑，有时为了通用概念，还会进行业务封装，增大了不同微服务的理解成本。2. 若功能集成于内部时，会出现当前功能技术选型不符合业务现状时，无法便捷地完成单一功能替换的问题。3. 对于不同的微服务开发框架，若功能注册方式的不同，在切换框架时，需要重写功能实现的场景，加大了开发成本。

目前已有方案对于插件的依赖，没有一套标准有效的解决方案，行业内目前只能通过参数传递的方式，由开发人员自行处理初始化逻辑，这样非常容易将逻辑与框架耦合在一起，对于开发人员来说，也需要关注插件的生命周期，无法解决插件需要依赖解耦或采用松耦合的问题。

发明内容

本发明的目的在于提供一种治理功能插件化的微服务开发框架及实现方法，能够同时满足微服务治理功能的统一定义、便捷替换，并支持治理功能模块独立于微服务开发框架使用。

为了实现上述目的，本发明采用的技术方案是：

一种治理功能插件化的微服务开发框架，其包括网络层、治理功能层和基础设施层；

所述网络层在微服务开发框架运行过程中，承接实际网络请求的流入，并向下传递至治理功能层；

所述基础设施层包括基础设施实例和构造器池；所述构造器池存储所有的插件构造器和基础设施构造器的函数方法，所述插件构造器和基础设施构造器指的是可以带有入参依赖，具有返回值的构造方法；构造器池中存储的函数方法于微服务开发框架启动过程中统一使用fx框架进行依赖注入和实例生成；插件构造器函数生成的插件将置于治理功能层对应的功能模块中，基础设施构造器生成的基础设施实例将置于基础设施层中；所述基础设施层在微服务开发框架启动过程中，通过构造器池生成各功能模块需要的插件或基础设施实例；

所述治理功能层包括多个功能模块，所述功能模块包括多个插件；所述治理功能层在微服务开发框架运行过程中通过中间件、配置回调或直接提供实例的方式为服务提供对应治理功能；