前面，已经统一了对框架的认识。

接下来看看如何做基础框架设计，聊聊要做些什么、以及如何做基础框架设计；然后再看看使用基础框架功能的基本方式。

一：基础框架要实现的功能的来源

1：持续积累的通用功能、公共功能

每个公司、团队，甚至开发人员自己，都会在工作中持续积累一些东西，比如一些通用功能和公共功能，这样就不用每次都一遍一遍重复去做这些事情了。

2：技术架构体系实现中蕴含的通用功能、公共功能

比如我们要使用Springboot+SpringCloud来实现微服务，那么这套技术架构体系里面，就会有一些通用的、公共的功能，如：幂等、远程调用、收发信息等等的。

不同的技术架构体系，里面蕴含的东西是不一样的，需要具体问题具体分析。

3：设计过程中提炼出的通用功能、公共功能

这类功能，有些可能做到基础框架里面，也有可能是体现成为一些公共的工具包，或者通用父类，一般来说，这些功能跟业务还是有一定的结合的，实现上也有一定的特殊性，适用面没有那么广。

二：基础框架中常见的基本功能

基础框架具体要实现些什么功能，还得结合具体的业务来说，实际上这样的功能会有很多，就看你自身的积累了，这里按照经验，挑几个常见的功能来聊聊。

1：CRUD等基础功能实现

一个系统包含很多的模块，每一个对应到实体操作和维护的模块，都会有CRUD的操作，这是最基本的功能。在系统实现过程中，还没有加入大量业务功能的情况下，系统大量实现的就是CRUD的功能。

虽然模块不同，操作的实体不同，属性也不同，但是实现方式是类似的，功能也是类似的。

因此我们需要去做一套通用的CRUD的基础功能。如果再配上代码生成器，就可以很轻松的实现整个系统的这多套CRUD功能了。

2：统一例外处理

咱们做的应用程序，不可能不抛出例外，对于例外，我们又可以分成两大种，一种是预期的例外，由开发人员在应用程序中主动抛出；另外一类是不预期的例外，就是程序运行出现了例外情况。

那这些例外怎么处理，这又涉及两个方面，一个是例外的统一处理；另一个是消息的统一处理，因为有些例外信息是要展示给用户看的，而抛例外的时候，是抛出的例外编号，到展示的时候，才通过统一的消息管理来获取相应的信息。

这些都是要进行统一处理的。从处理的角度，又可以把例外分成两大类，一类是抛给用户看的；另一类是记录日志的。因此为了统一管理例外，我们可能需要去自定义例外，并进行处理。

3：统一事务规划和处理

对于分布式事务的处理，基本步骤是：

（1）尽量不要出现分布式事务，都是本地的经典事务，这是最好的

（2）实在规避不了，需要出现分布式事务，也尽量是弱事务，最终一致即可。所谓弱事务，指的是主事务成功的时候，不强制要求子事务同时完成，可以在随后一段时间内，子事务自行完成，成功即可。另外，一般来说，弱事务失败不会导致主事务的回滚

（3）如果必须要使用分布式事务，且是强事务，那要选择并实现合理的事务处理方案，比如：使用Seata、本地消息表 等方案。

我们需要对于经典事务进行统一的事务规划和配置实现；对于分布式的事务，提供统一的、公共的事务实现的支持。

4：统一的微服务基础功能实现

微服务的架构中，各个微服务是要相互远程调用的，那它怎么调用过去的呢？该由谁来接这些调用的请求？一些公共的处理由谁来做？微服务的调用层和业务之间怎么结合起来？等等的一系列问题

对于这些问题，通常也需要结合具体的技术架构体系，抽取出公共的功能，去统一实现成为微服务的基础功能。

比如：使用SpringCloud的2020版（目前最新的）来实现微服务，那么微服务之间调用的基本方式，常用的组合是openfeign+loadbalancer+sentinel，被调用的服务会单独做一个由SpringMVC实现的Controller层，来负责接收并转发处理这些微服务之间调用的请求。

那么，这一层包含的一些公共的功能，通常就抽取实现到基础框架里面去。比如前面提到的统一的例外处理，调用时机一般来说就是在这个Controller层，也就是说，这个控制器层既相当于是外部访问服务的入口层，也相当于是服务内部返回到外部的最后一个出口层。

5：统一的幂等处理

微服务调用过程中，由于网络并不稳定，通常客户端调用的时候，都是开启了重试机制的，难免会出现一次请求多次重复调用某一个方法的情况，也就是说，微服务向外提供的接口，应该实现幂等性。

除了方法本身的业务进行幂等处理外，还需要一些基本的控制手段，比如明确发现是重复调用，可以不执行这次调用，这样也能避免无谓的资源损耗。

那这样统一进行幂等处理的功能实现在哪里呢？一般来说，也可以实现到公共的基础框架包里面。

6：统一的缓存实现

一般来说，缓存除了业务数据的缓存外，还有很大一部分是实体级别的缓存，这些缓存数据通常需要和实体数据的变化联系起来，简单说就是向数据库加数据的时候，应该同时加入缓存；同理修改数据库中数据的时候，应该同时修改缓存的数据。

对于这样的缓存功能，从某种意义上说，可以看成是另外一种数据层的实现，比如把Redis当作数据库，所谓操作缓存不就是操作数据库的数据嘛。

因此，我们可以把这样的一些缓存功能，当成通用的数据层实现，跟前面CRUD功能配套在一起，同时实现缓存的功能。当然，也可以做一些配置，进行功能的开启和装配，这个就不多说了。

还有很多，比如：分布式ID的统一生成、各种工具辅助类、权限管理、任务管理、消息管理、工作流、统一验证…… 等等，太多了，这里就不多说了

三：使用基础框架的几种基本使用方式

1： 通过继承的方式来使用基础框架提供的功能

如果基础框架提供的功能不能满足需要，或者是需要做一些调整，可以增加方法来扩展功能；或者是覆盖方法来改变原来的功能。

当然，如果是通用的，也可以提炼到基础框架中去。

2： 通过注解 或 注解 + AOP的方式

使用自定义注解来应用基础框架里面的功能。或者是使用AOP的方式，把基础框架里面的功能和业务功能结合起来。

这都是非常常用，也灵活的方式，对于项目基本无侵入。

3： 直接当作API功能实现进行调用

这个是最简单的使用方式，不用遵守特别的约定，当使用API一样，调用自己需要的功能。这种方式和代码是绑定在一起的，后期很难调整和修改公共功能。

4： 提供缺省功能实现，可通过SPI 进行扩展

这种应用方式相对难一些，如果用不上缺省的功能，就需要自己遵循SPI的约定，去扩展实现一套，能用在自己项目上的功能。

这种方式是用在基础功能结合具体应用，结合具体技术体系，变化会比较大的情况下，缺省提供一种常用的，其它没有实现的体系，可以由项目来扩展。也许经过几个类似项目验证后，把这些扩展的实现，都提到公共基础框架里面去，形成可选的实现，这也是一种积累和沉淀。