CN111930355A - 一种web后端开发框架及其构建方法 - Google Patents

Abstract

本发明公开了一种web后端开发框架，包括基础功能模块，用于集成web后端开发技术，以common包为基础，构建web后端开发的基础功能模块，便于开发其它功能模块；组件功能模块，用于以组件的方式提供额外的、可定制化的功能，功能完成以后都以单独的子模块的形式存在，便于开发人员在开发中引入使用；微服务功能模块，用于在基础功能模块的基础上，以app‑core模块为核心，扩展其它微服务子模块。本发明还提供一种web后端开发框架的构建方法。通过本方案能够解决现有开发框架中的技术集成问题，提高了开发效率，灵活性和可扩展性高，可以灵活的集成第三方框架，也可以对现有的功能通过组件的方式进行扩展，跨平台性能好，支持跨平台部署。

Description

一种web后端开发框架及其构建方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种web后端开发框架及其构建方法。

背景技术

软件框架，通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

框架的功能类似于基础设施，与具体的软件应用无关，但是提供并实现最为基础的软件架构和体系。软件开发者通常依据特定的框架实现更为复杂的商业运用和业务逻辑。这样的软件应用可以在支持同一种框架的软件***中运行。

现有的web后端开发框架的基础技术集成不够全面，开发的灵活性和可扩展性较差，跨平台性能不够友好。

发明内容

本发明的目的在于克服现有技术的不足，提供一种web后端开发框架及其构建方法。

本发明的目的是通过以下技术方案来实现的：

一种web后端开发框架，包括基础功能模块，用于集成web后端开发技术，以common包为基础，构建web后端开发的基础功能模块，便于开发其它功能模块；

组件功能模块，用于以组件的方式提供额外的、可定制化的功能，功能完成以后都以单独的子模块的形式存在，便于开发人员在开发中引入使用；

微服务功能模块，用于在基础功能模块的基础上，以app-core模块为核心，扩展其它微服务子模块。

具体的，所述基础功能模块具体包括动态数据源模块、Druid连接池模块、缓存模块、日志管理模块、异步处理模块、全局异常处理模块、ID生成器模块、自动审计模块、分页插件模块和慢查询追踪模块。

具体的，所述组件功能模块中的组件包括接口配置组件、文件上传组件、工作流组件、定时任务组件和***管理组件。

具体的，所述微服务功能模块中的功能包括注册中心、网关、配置中心、限流、统一认证、分布式事务和统一监控。

具体的，所述common包具体包括common-api、common-core、common-jpa、common-mybatis、common-security-core、common-security-client和common-security-server。

具体的，所述动态数据源模块的内部提供一个map，以map的key存储实际连接数据库的别名，以vlaue存储实际数据源。

具体的，所述异步处理模块包括有界线程池和异步注解；所述有界线程池用于在项目启动时，根据操作***的CPU核心数自动选择最优的线程数；所述异步注解用于标注异步处理过程中的操作。

具体的，所述全局异常处理模块中包括统一异常类KeepException，用于在开发接口的过程中，自动捕获rest层抛出的异常。

具体的，所述ID生成器模块以雪花算法作为模块的ID生成策略，模块生成的ID包括首位无效符、时间戳差值、机器编码和序列号。

一种web后端开发框架的构建方法，方法包括以下步骤：

S1，设计框架的基础功能模块架构，根据基础功能模块架构选定基础功能进行开发，并封装形成框架的基础构件库；

S2，设计组件功能模块架构，根据组件功能模块架构开发组件功能并进行封装，形成框架的组件库；

S3，设计微服务功能模块架构，以app-core模块为核心扩展开发部署框架的微服务功能，同时封装形成框架的微服务功能库；

S4，根据基础构件库、组件库和微服务功能库，整合形成web后端开发框架。

本发明的有益效果：

1、易用性：框架功能划分明确，所有功能都提供相应的API或配置文档，并且尽可能的简化配置。在使用上也符合开发人员的编程习惯，能够让开发人员快速的上手。各个技术在集成到框架的时候已经解决了集成问题，开发人员无需考虑，只需要使用即可；

2、开发效率性：常用的功能和技术都做了二次封装，大大提高了开发效率；

3、全面性：功能涵盖90%以上的互联网热门技术，开发人员不需要自己来集成相关技术了，只需要找到自己需要的技术使用即可；

4、灵活性：开发人员可以对需要的技术进行自由选择，只需要在工程中做相应的maven引入即可；

5、可扩展性：框架使用maven进行模块管理，使用spring进行基础构建的开发。可以灵活的集成第三方框架，也可以对现有的功能通过组件的方式进行扩展；

6、跨平台性：采用JAVA开发，部署支持跨平台。

附图说明

图1是本发明的开发框架的功能架构图。

图2是本发明的基础功能模块架构图。

图3是本发明的组件功能模块架构图。

图4是本发明的微服务功能模块架构图。

图5是本发明的web后端开发框架的构建方法流程图。

具体实施方式

为了对本发明的技术特征、目的和效果有更加清楚的理解，现对照附图说明本发明的具体实施方式。

本实施例中，如图1所示，一种web后端开发框架，其功能架构包括基础功能模块、组件功能模块和微服务功能模块。基础功能模块用于集成web后端开发技术，以common包为基础，构建web后端开发的基础功能模块，便于开发其它功能模块。组件功能模块用于以组件的方式提供额外的、可定制化的功能，功能完成以后都以单独的子模块的形式存在，便于开发人员在开发中引入使用。微服务功能模块用于在基础功能模块的基础上，以app-core模块为核心，扩展其它微服务子模块。

本实施例中，基础功能模块的架构设计如图2所示，基础功能模块一共分为7个包：common-api、common-core、common-jpa、common-mybatis、common-security-core、common-security-client和common-security-server。

common-api和common-core是基础部分，其中common-api中定义了一些基础的DTO、枚举、常量、异常信息等。common-core依赖于common-api，common-core中提供了动态数据源、jdbc连接池、缓存、日志、异步、全局异常处理等功能。

common-jpa和common-mybatis是框架的ORM能力部分，在开发中，可以2选1。其中common-jpa中运用的是JPA技术，common-mybatis中运用的是Mybatis和MybatisPlus技术。两个包都提供了自己的ID生成器和自动审计功能，common-mybatis中还提供了分页功能以及慢查询追踪功能。

common-security-core、common-security-client、common-security-server是框架的认证基础部分，是基于oauth2协议做的认证。其中common-security-core是common-security-client和common-security-server的基础，提供了Token解析、Token转换、CookieToken解析等功能。common-security-client主要提供资源服务器的配置以及授权等功能，common-security-server主要提供认证服务器的配置以及认证等功能。

其中，基础功能模块包括动态数据源模块、Druid连接池模块、缓存模块、日志管理模块、异步处理模块、全局异常处理模块、ID生成器模块、自动审计模块、分页插件模块和慢查询追踪模块。

动态数据源模块用于为开发人员提供灵活的，利于扩展的数据源。在实际开发过程中，开发人员经常碰到需要连接或者操作多个数据库的需求。如果只是在开发时配置多个数据源，如果碰到需求改变，需要改变操作的数据库的时候，或者增加、减少要操作的数据库的时候，就需要修改配置，还要修改代码，不够灵活，也不利于扩展。自定义的DynamicDataSource继承自AbstractRoutingDataSource，该数据源内部提供一个map，这个map的key存储实际连接的别名，value存储实际数据源。DynamicDataSource的默认数据源的key为default，其他每个数据源都有自己的唯一的key。在需要使用非默认数据源的方法上，通过@TargetDataSource注解指定数据源的key，就可以指定需要使用的数据源。如果不指定，则使用默认的default数据源。

Druid连接池模块用于提供能够重复利用数据库连接，提高对请求的响应时间和服务器的性能。Druid被称为是专门为监控而生的数据库连接池配置，它集合了c3p0、dbcp、proxool等连接池的优点，还加入了日志监控功能，能有效的监控DB池连接和SQL的执行情况以及性能，所以在本发明的web后端开发框架中集成了Druid连接池。

缓存模块用于缓解大量数据访问请求对数据库带来的压力。对于任何一个web应用***来说，数据访问是最常见的需求。对于一个客户端的数据访问请求，***会去后台查询数据库，然后把查询到的结果响应给客户端。在高并发的场景下，如果对于每次数据访问请求，我们都去查询数据库的话，会给数据库带来非常大的压力。本发明利用springboot技术中的CacheManager来对缓存进行管理，其中设置RedisCache作为默认的缓存实现，序列化方式选择Object的序列号方式。在需要增加缓存的方法上，使用@CachePut就可以增加缓存。在修改了数据库数据后，需要移除缓存的地方，使用@CacheEvit就可以移除缓存。

日志管理模块用于对业务开发过程中的日志代码进行统一管理。为此，框架集成了logback组件来对框架中的日志进行管理。logback当前分成三个模块：logback-core,logback- classic和logback-access。logback-core是其它两个模块的基础模块。此外logback-classic完整实现SLF4J API使开发人员很方便地更换成其它日志***如log4j或JDK14 Logging。本发明的框架将logback-access访问模块与Servlet容器集成，提供通过Http来访问日志的功能。

异步处理模块用于对客户端请求中带有附属事件进行异步处理。针对某些客户端的请求，在服务端可能需要针对这些请求做一些附属的事情，这些事情其实用户并不关心或者用户不需要立即拿到这些事情的处理结果，这种情况就比较适合用异步的方式处理这些事情。常规的解决办法是在程序中通过new Thread()的方式就可以新建一个线程来进行异步操作，但是经常会造成线程混乱、难以管理，还可能导致一些更严重的问题发生。因此，本发明的框架设计提供了一个叫做asyncExecutor的线程池，该线程池是一个有界线程池。在项目启动的时候，会根据操作***的CPU核心数自动选择最优的线程数。然后，提供一个异步注解，用于标注异步操作。开发人员在需要使用异步操作的方法上，只要打上@Async注解，该方法就会使用asyncExecutor线程池来异步执行方法。

全局异常处理模块用于按照预先设定的异常处理逻辑，针对性地处理程序异常，让程序尽最大可能恢复正常并继续执行，且保持代码的清晰。因此，本发明的框架中定义了统一异常类KeepException，通过@ControllerAdvice捕获在rest层抛出的异常。开发人员在开发的接口的时候，在rest层就无需通过try catch代码来捕获异常，框架会自动捕获抛出的异常。另外，在任何地方，只要开发人员抛出的异常是KeepException，框架会做统一的拦截处理。

ID生成器模块用于在存储业务数据时，为业务数据生成唯一的ID。在web***中，业务数据只要是存储在数据库中，都必须要有一个唯一的ID。特别是在分布式***中，ID更是要做到全局唯一。ID生成器生成ID的时候，需要一个ID生成策略。ID生成策略的好坏，直接影响到ID生成器的性能。本发明的框架采用雪花算法做为ID生成策略，生成的ID由首位无效符、时间戳差值，机器(进程)编码，序列号四部分组成，ID生成器模块把ID生成的相关逻辑绑定在了IdEntity中，只要继承了IdEntity的实体，在做***操作的时候，就会自动生成ID。

自动审计模块用于开发人员通过数据对问题进行追踪。本发明的框架提供AuditEntity，AuditEntity已经继承了IdEntity。因此，只要继承AuditEntity的实体，也就等同于继承了IdEntity，也有了自动生成ID的功能。同时，继承AuditEntity的实体，还具备了自动审计的功能。在做***操作的时候，会自动生成创建人、创建时间，在做更新操作的时候，会自动生成更新人、更新时间，极大程度上提高了开发人员的开发效率。

分页插件模块用于为开发人员提供分页查询功能。在数据量较大的时候，一次性查询所有数据显示在页面上是不合理的。本发明提供了通用的分页查询插件，只需要创建一个Page对象，指明page和size，然后把Page对象作为selectPage方法的参数，就可以自动进行分页查询。

慢查询追踪模块用于优化SQL查询语句。在web***中，如果存在某些SQL语句要执行很长的时间，这会导致数据库性能的急剧下降，最终影响整个应用。因此，需要慢查询追踪的功能，找出执行效率很慢的SQL语句并进行进行优化。因此，本发明的框架集成了慢查询监控插件，对执行查询时间长，查询效率差的SQL语句进行优化。由于慢查询追踪功能需要打印日志，所以默认设置是关闭的，需要在配置文件中指定sql.query.enable为true，方可打开慢查询功能。默认的慢查询阀值是10毫秒，可以通过sql.query.sql-query-time-threshold的值进行修改。

本实施例中，组件功能模块架构如图3所示，组件功能模块中的各个组件互相独立，但是都依赖于基础功能模块中的common-core。其组件有接口配置组件、文件上传组件、工作流组件、定时任务组件和***管理组件。

本实施例中，微服务功能模块架构如图4所示，其主要功能包括注册中心、网关、配置中心、限流、统一认证、分布式事务和统一监控。微服务功能模块以app-core模块为核心，其他所有子模块都从app-core扩展而来。注册中心有2个core，分别是eureka-core和alibaba-core。依赖eureka-core可以实现eureka注册中心，依赖alibaba-core可以实现nacos注册中心。

配置中心有2个core，分别是alibaba-core和config-server-core。依赖alibaba-core可以实现nacos配置中心，依赖config-server-core可以实现config配置中心。

网关有2个core，分别是zuul-core和gateway-core。依赖zuul-core可以实现zuul网关，依赖gateway-core可以实现gateway网关。

限流有2个core，分别是alibaba-core和app-cpre。依赖alibaba-core可以实现sentinel限流，依赖app-core可以实现hystrix限流。

分布式事务直接从app-core实现，实现了seata分布式事务客户端。

统一认证需要依赖uaa-core，uaa-core实现了一个统一认证中心。

监控有3个包，分别是admin-core、hystrix dashboard-core和app-core。依赖admin-core可以实现admin监控，依赖hystrix dashboard-core可以实现hystrixdashboard监控，只使用app-core依赖们可以实现sleuth、zipkin和skywalking监控。

本发明通过对基础功能模块架构、组件功能模块架构和微服务功能模块架构进行设计开发，并对应封装形成基础构件库、组件库和微服务功能库，同时整合形成web后端开发框架。

本实施例中，如图5所示，还提供一种web后端开发框架的构建方法，方法的构建流程包括：

步骤1，设计框架的基础功能模块架构，根据基础功能模块架构选定基础功能进行开发，并封装形成框架的基础构件库。

步骤2，设计组件功能模块架构，根据组件功能模块架构开发组件功能并进行封装，形成框架的组件库。

步骤3，设计微服务功能模块架构，以app-core模块为核心扩展开发部署框架的微服务功能，同时封装形成框架的微服务功能库。

步骤4，根据基础构件库、组件库和微服务功能库，整合形成web后端开发框架。

本实施例中，在组件功能模块的构建过程中，接口配置组件旨在为应用提供的一个接口配置工具，使得使用者无需开发任何代码就配置一个满足需求的接口，其设计构建过程如下：

动态接口：通过***的方式，实现对一个通用的url的拦截。这个url会做为所有通过接口配置工具配置的接口的前缀。所有的接口，配置后保存在数据库中。数据库设计两张表：interface_info和interface_release。interface_info记录接口的配置信息，interface_release记录接口的sql脚本等信息。进行接口请求的时候，首先会走***，然后通过interface_info查询接口的url和请求参数否合法。如果合法，再使用interface_release获取SQL脚本和返回配置信息，执行后做相应的处理后返回。

接口配置：整个接口配置、测试、发布，一站式都通过UI 界面完成。接口配置组件的接口配置流程如图3所示，首先在页面上进行接口创建，将需要制定接口访问的url和访问方式为POST或GET；在参数定义区，配置测试接口的请求参数，参数只支持JSON格式；在主工作区配置访问数据库的SQL语句；在主工作区配置接口返回的实体；通过测试按钮测试是否是预期的返回接口；最后通过发布按钮发布接口。

文件上传组件旨在为应用提供一个文件上传和下载的公用API。使得开发者在有文件上传或下载需求的时候，可以直接使用API来完成开发，其主要的设计构建过程如下：

文件存储：所有文件通过文件服务器的方式进行存储，文件服务器提供sftp协议进行通信。

文件上传：使用数据库来记录文件上传的元数据，元数据包括文件名、文件类别、文件批次号、文件保存路径等。其中文件保存路径对应文件在文件服务器上的存储路径。

文件下载：从数据库里查询文件的保存路径，然后调用文件下载的API接口进行下载。

本实施例中，为了最大限度的提高Web开发人员的生产力，本发明封门了一套基工作流组件，该组件没有直接嵌入业务***，而是单独部署成了服务，暴露接口供业务***调用，减少与业务***的耦合。其主要的设计构建过程如下：

模型管理设计：主要是对工作流模型表(ACT_RE_MODEL)的CURD操作以及一些扩展功能，如：模型导入导出，模型部署等功能。模型是流程的开端，流程的设计就是模型的设计过程；通过模型可以导出流程的定义文件*.bpmn 文件，可用于流程的部署。模型管理功能提供可视化的管理界面和设计界面。

流程定义管理设计：在使用工作流之前必须对流程进行定义，流程定义了还要对流程进行部署。为了部署流程，它们不得不包装在一个业务文档中。一个业务文档是工作流引擎部署的单元。一个业务文档相当于一个压缩文件，它包含BPMN2.0流程，任务表单，规则和其他任意类型的文件。 大体上，业务文档是包含命名资源的容器。当一个业务文档被部署，它将会自动扫描以.bpmn20.xml 或者.bpmn 作为扩展名的BPMN文件。每个文件都将会被解析并且可能会包含多个流程定义。流程定义提供可视化的管理界面，流程模型设计后在工作流组件中部署，不在业务***中部署。

启动流程设计：有了流程定义，就可以创建流程实例了。启动一个新流程实例，使用定义在流程定义里的id（对应XML文件中的process元素）。注意这里的id对于工作流来说， 应该叫做key（注：一般在流程模型中使用的ID，在工作流中都是Key，比如任务ID等）。创建一个流程实例，首先进入开始事件。开始事件之后，它会沿着所有的外出连线执行，到达第一个任务。工作流组件会把一个任务保存到数据库里。这时分配到这个任务的用户或群组会被解析，也会保存到数据库里。需要注意，工作流引擎会继续执行流程的环节，除非遇到一个等待状态，比如用户任务。在等待状态下，当前的流程实例的状态会保存到数据库中。 直到用户决定完成任务才能改变这个状态。这时，引擎会继续执行，直到遇到下一个等待状态，或流程结束。如果中间引擎重启或崩溃，流程状态也会安全的保存在数据库里。任务创建之后，startProcessInstanceByKey 会在到达用户任务这个等待状态之后才会返回。这时任务分配给了一个组，这意味着这个组是执行这个任务的候选组。启动流程不提供管理界面，只暴露接口供业务应用调用。

待办任务列表设计：此过程使用工作流引擎，一个非常重要的功能就是获取待办事项列表，在工作流中可以通过TaskService的相关API进行查询，虽然这些API设计优雅，但是实际使用中往往不够方便，也缺乏灵活性，达不到技术解决方案的要求。分析上述缺点和需求后，本发明认为通过API方式进行查询的话，总是有各种缺陷，因此把设计的目标放在数据库上，通过定义视图的方式解决问题，彻底解决查询的方便性、灵活性、通用性问题。工作流组件不提供待办任务列表的界面管理，只提供流程数据给业务***使用，数据的展现由业务***实现。

签收任务设计：当一个任务同时发送给多个人处理，且该任务不需要会签时，必须先签收才能办理任务。当前登录人认领这个任务。认领以后，这个用户就会成为任务的执行人，任务会从其他成员的任务列表中消失。任务会移动到签收任务的用户个人任务列表。当前登录人也会看到任务的执行人已经变成当前登陆的用户。该功能不提供操作界面，只提供接口调用。

任务办理设计：当前登录人签收完任务后，可以直接在待办任务列表里处理任务。对于工作流引擎，需要一个外部信息来让流程实例继续执行。 任务会把自己从运行库中删除。 流程会沿着单独一个外出连线执行，移动到第二个任务。与第一个任务相同的机制会使用到第二个任务上，不同的是任务是分配给其他的组或者人员。该功能不提供界面操作，只提供接口调用。

已办任务列表设计：已办任务是一个历史组件，它可以捕获发生在进程执行中的信息并永久的保存，与运行时数据不同的是，当流程实例运行完成之后它还会存在于数据库中。有5个历史实体对象: HistoricProcessInstances 包含当前和已经结束的流程实例信息、HistoricVariableInstances 包含最新的流程变量或任务变量、HistoricActivityInstances 包含一个活动(流程上的节点)的执行信息、HistoricTaskInstances 包含关于当前和过去的（已完成或已删除）任务实例信息、HistoricDetails 包含历史流程实例、活动实例、任务实例的各种信息。由于数据库中保存着历史信息以及正在运行的流程实例信息，就要考虑怎样尽量少的对运行。

流程追踪设计：流程启动后都有一个唯一的流程实例，通过流程实例可以追踪流程的执行情况。流程的追踪包含流程图片以及流转的历史列表。

子流程设计：子流程是包含其他的活动、网关、事件等的活动。子流程的实现，包括两种基于子流程的实现。一种是内嵌子流程：子流程元素内嵌在主流程元素之内，只能在该流程中使用该子流程，外部是无法访问到的。这种子流程一般作为局部通用逻辑处理，或者因为特定业务需要，使得比较复杂的单个主流程设计清晰直观。另一种是调用子流程：首先实现一个流程，在另一个流程中可以调用该流程，通常可以定义一些通用的流程作为这种调用子流程，供其他多个流程定义复用。这种子流程使用元素来进行调用，间接地嵌入到主流程中，用起来比较方便。

会签设计：在流程业务管理中，任务是通常都是由一个人去处理的，而多个人同时处理一个任务，这种任务我们称之为会签任务。流程组件不提供该功能的界面操作，只提供接口获取数据，界面由业务***实现。

收回/退回设计：在流程业务管理中，经常出现信息不完整或者误操作将流程发送到一下步处理人，在下一步处理人未处理前可以将任务收回重新处理，这就是流程的收回或者撤销。

定时任务组件，在现实生产中，要求在某个特点的时间点做点什么是常见的需求场景。这时候就需要用到定时任务。现有的Spring提供了通过使用@Schedule注解来标注方法实现定时任务的方式。但是此方式有个最大的问题，那就是如果涉及到需要对任务进行调整的时候，就不得不修改程序源代码。如果项目已经上线了，要修改源代码那就意味着需要停机，这几乎是不能被允许的。因此，本发明开发了一个不停机就能对任务进行调整的定时任务组件。其主要设计构建过程如下：

任务管理：通过数据库来存储任务的元数据信息。元数据包括任务ID、任务名称、任务分组、任务状态、cron表达式等。然后提供任务增删改查的接口，对任务数据库进行增删改查。

任务状态管理：提供任务状态管理接口对任务状态进行管理。任务状态有：已启动、暂停、停止。任务的修改，涉及到两个地方的改变。一个是内存中状态改变，一个是数据库中的数据的状态改变。

任务部署：任务可以分布式部署，也可以单台部署。对于分布式部署的方式，使用了分布式锁来避免多台机器上的任务重复执行。分布式锁默认使用数据库来做轻量级的实现，也可以自定义使用redis或zookeeper等。

任务日志：通过数据库来存储任务的日志。

***管理组件，对于web***来说，***管理是必不可少的模块。其主要设计思路如下：

机构管理：提供机构管理接口对机构进行增删改查等操作。其中，机构设计有父子机构的概念。

用户管理：提供用户管理接口对用户进行增删改查等操作。用户和机构进行关联，另外，还提供修改密码和密码重置的接口。

角色管理：提供角色管理接口对角色进行增删改查等操作。

菜单管理：提供菜单管理接口对菜单进行增删改查等操作。为了避免查询菜单的时候使用递归进行查询，给菜单设置了一个relationship字段。Relationship记录的是当前菜单id和所有父菜单id的链式结构，例如：1-5-7代表当前菜单id为7，父菜单id为5，父菜单的父菜单id为1。当前菜单处于第3层级。所以，通过relationship字段，查询菜单的时候可以通过like进行查询，并将菜单和角色进行关联。

岗位管理：提供岗位管理接口对岗位进行增删改查等操作。岗位设计有父子岗位的概念。此外，岗位和机构，岗位和角色，岗位和用户都有关联关系。

权限管理：提供权限管理接口对权限进行增删改查等操作。权限实际修改的是岗位和用户的关联关系。

本实施例中，微服务架构的功能以基础功能模块中的app-core模块为核心，其他所有子模块都从app-core扩展而来。

注册中心有2个core，分别是eureka-core和alibaba-core。依赖eureka-core可以实现eureka注册中心，依赖alibaba-core可以实现nacos注册中心。

配置中心有2个core，分别是alibaba-core和config-server-core。依赖alibaba-core可以实现nacos配置中心，依赖config-server-core可以实现config配置中心。

网关有2个core，分别是zuul-core和gateway-core。依赖zuul-core可以实现zuul网关，依赖gateway-core可以实现gateway网关。

限流有2个core，分别是alibaba-core和app-cpre。依赖alibaba-core可以实现sentinel限流，依赖app-core可以实现hystrix限流。

分布式事务直接从app-core实现，实现了seata分布式事务客户端。

统一认证需要依赖uaa-core，uaa-core实现了一个统一认证中心。

监控有3个包，分别是admin-core、hystrix dashboard-core和app-core。依赖admin-core可以实现admin监控，依赖hystrix dashboard-core可以实现hystrixdashboard监控，只使用app-core依赖们可以实现sleuth、zipkin和skywalking监控。

注册中心功能的构建过程中，架构集成了两个注册中心供开发选择：Eureka和Nacos。Eureka偏向于AP，Nacos同时支持AP和CP。框架对两个注册中心都提供了默认配置项，如果需要调整，可以修改application.yml中的内容进行调整。

Eureka是Spring Cloud Netflix 微服务套件中的一部分， 它基于NetflixEureka 做了二次封装， 主要负责完成微服务架构中的服务治理功能。Eureka以 REST API的形式为服务实例提供了注册、管理和查询等操作。

Nacos是阿里巴巴开源的一款支持服务注册与发现，配置管理以及微服务管理的组件。Nacos是集成了注册中心和配置中心的功能，做到了二合一。

网关功能的构建过程中，架构集成了两个网关供开发选择： Zuul（Zuul2版本）和Gateway。这两个网关都是基于异步非阻塞模型上进行开发的，性能方面相差不大。框架对两个网关都提供了默认配置项。如果需要调整，可以修改application.yml里的内容进行调整。

Zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。

Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

配置中心功能的构建过程中，架构集成了两个配置中心供开发选择：Config和Nacos。Config是Spring Cloud 生态圈的组件，可以和Spring Cloud体系无缝整合。Nacos虽然不是Spring Cloud 生态圈的组件的组件，但是也可以和Spring Cloud结合，框架已经实现了。并且，nacos同时还支持注册中心，做到了二合一。微服务架构在框架中实现了两个配置中心的配置动态刷新，config是结合bus总线实现，Nacos则是通过udp广播的方式。框架对两个配置中心都提供了默认配置项，如果需要调整，可以修改application.yml里的内容进行修改。

限流功能的构建过程中，框架集成了两个限流组件供开发选择：hystrix和Sentinel。其中，Sentinel是和Nacos中的配置中心（Sentinel配置的持久化）结合使用的，而Hystrix则没有限制。Sentinel需要单独部署。框架对2个限流组件都提供了默认的配置项，如果需要调整，可以修改application.yml里的内容进行调整。

Hystrix 是 Netflix 针对微服务分布式***采用的熔断保护中间件，相当于电路中的保险丝。Hystrix 通过 HystrixCommand 对调用进行隔离，这样可以阻止故障的连锁效应，能够让接口调用快速失败并迅速恢复正常，或者回退并优雅降级。

Sentinel是面向分布式服务框架的轻量级流量控制框架,主要以流量为切入点,从流量控制,熔断降级,***负载保护等多个维度来维护***的稳定性。

统一认证功能的构建过程中，架构提供统一认证服务端Uaa给开发直接使用，Uaa可直接部署。在微服务中，所有的App客户端都需要发请求到Uaa进行认证（oauth2 jwt方式）。这部分功能，框架已经做好了封装，开发人员无需开发认证相关代码。Uaa中还提供了用户管理、角色管理、接入***管理、账号管理等功能，开发人员可以直接做统一用户管理，也无需开发任何代码。

分布式事务功能的构建过程中，架构以Seata为底层实现，提供了分布式事务功能。开发只需要在App中做一些分布式事务的配置，然后在代码中用相应的注解对要实现分布式事务的方法进行标注就可以实现分布式事务。

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata目前的事务模式有AT，TCC，Saga三种模式，默认即是AT模式，AT本质上是2pc协议的一种实现。

统一监控功能的构建过程中，提供多种监控手段供开发选择，有Admin、Hystrixdashboard、Sleuth、Zipkin、Skywalking。框架对所有监控组件都提供了默认的配置项，如果需要调整，可以修改application.yml里的内容进行调整。

Admin是一个Web应用，用于管理和监视Spring Boot应用程序的运行状态。每个Spring Boot应用程序都被视为客户端并注册到管理服务器。背后的数据采集是由SpringBoot Actuator端点提供。

Hystrix dashboard 是Spring Cloud提供的一个仪表盘（Dashboard），用于Hystrix进行监控断路的情况，从而让开发者监控可能出现的问题。

Sleuth是Spring Cloud提供的分布式***服务链追踪组件,它在整个分布式***中能跟踪一个用户请求的过程(包括数据采集，数据传输，数据存储，数据分析，数据可视化)，捕获这些跟踪数据，就能构建微服务的整个调用链的视图，这是调试和监控微服务的关键工具。

Zipkin是Twitter基于***的分布式监控***Dapper（论文）的开发源实现，Zipkin用于跟踪分布式服务之间的应用数据链路，分析处理延时，帮助我们改进***的性能和定位故障。

Skywalking 是一个APM***，即应用性能监控***，为微服务架构和云原生架构***设计。它通过探针自动收集所需的指标，并进行分布式追踪。通过这些调用链路以及指标，Skywalking APM会感知应用间关系和服务间关系，并进行相应的指标统计。

以上显示和描述了本发明的基本原理和主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护的范围由所附的权利要求书及其等效物界定。

Claims (10)

1.一种web后端开发框架，其特征在于，包括

基础功能模块，用于集成web后端开发技术，以common包为基础，构建web后端开发的基础功能模块，便于开发其它功能模块；

组件功能模块，用于以组件的方式提供额外的、可定制化的功能，功能完成以后都以单独的子模块的形式存在，便于开发人员在开发中引入使用；

微服务功能模块，用于在基础功能模块的基础上，以app-core模块为核心，扩展其它微服务子模块。

2.根据权利要求1所述的一种web后端开发框架，其特征在于，所述基础功能模块具体包括动态数据源模块、Druid连接池模块、缓存模块、日志管理模块、异步处理模块、全局异常处理模块、ID生成器模块、自动审计模块、分页插件模块和慢查询追踪模块。

3.根据权利要求1所述的一种web后端开发框架，其特征在于，所述组件功能模块中的组件包括接口配置组件、文件上传组件、工作流组件、定时任务组件和***管理组件。

4.根据权利要求1所述的一种web后端开发框架，其特征在于，所述微服务功能模块中的功能包括注册中心、网关、配置中心、限流、统一认证、分布式事务和统一监控。

5.根据权利要求1所述的一种web后端开发框架，其特征在于，所述common包具体包括common-api、common-core、common-jpa、common-mybatis、common-security-core、common-security-client和common-security-server。

6.根据权利要求2所述的一种web后端开发框架，其特征在于，所述动态数据源模块的内部提供一个map，以map的key存储实际连接数据库的别名，以vlaue存储实际数据源。

7.根据权利要求2所述的一种web后端开发框架，其特征在于，所述异步处理模块包括有界线程池和异步注解；所述有界线程池用于在项目启动时，根据操作***的CPU核心数自动选择最优的线程数；所述异步注解用于标注异步处理过程中的操作。

8.根据权利要求2所述的一种web后端开发框架，其特征在于，所述全局异常处理模块中包括统一异常类KeepException，用于在开发接口的过程中，自动捕获rest层抛出的异常。

9.根据权利要求2所述的一种web后端开发框架，其特征在于，所述ID生成器模块以雪花算法作为模块的ID生成策略，模块生成的ID包括首位无效符、时间戳差值、机器编码和序列号。

10.一种web后端开发框架的构建方法，其特征在于，方法包括以下步骤：

S1，设计框架的基础功能模块架构，根据基础功能模块架构选定基础功能进行开发，并封装形成框架的基础构件库；

S2，设计组件功能模块架构，根据组件功能模块架构开发组件功能并进行封装，形成框架的组件库；

S3，设计微服务功能模块架构，以app-core模块为核心扩展开发部署框架的微服务功能，同时封装形成框架的微服务功能库；

S4，根据基础构件库、组件库和微服务功能库，整合形成web后端开发框架。

Images