叶子叶来

一般在业务逻辑代码编写前的最重要步骤是进行关系模型的构建，也就是数据库表的设计，完成表设计后建立与Entity的对应关系、视图层VO设计、Mapper接口、Service服务、IMPI实现，如果使用MybatisPlus，可以使用代码生成器按照数据库配置扫描数据库完成上面所有工作，唯一要做的是在IMPL中定制化业务代码；...

当我们完成业务逻辑开发，把jar包发布到环境中启动，就是在该主机上拉起了1个进程，该进程会进行系统调用监听端口请求，返回计算结果，同一代码段（或者方法），比如用户登录方法在同时刻可以有多个请求过来，每个请求就是1个处理线程，线程是CPU的最小处理单元，可以把进程比作工厂，线程是流水线，工厂包含原材料、启动/关闭多个流水线、输出产物。......

SpringBoot的核心设计宗旨是约定大于配置，很多框架功能都给你默认加载和配置完成供你使用，但这就要求使用者对框架有一定的理解和改造能力，比如这个日志框架，是其他框架的基础，需要默认指定日志框架，但如果想要深入了解日志框架内容是很多的，比如logback 和 log4j 都是基于 SLF4J（Simple Logging Facade for Java） 的门面（Facade）设计模式进行集成的。

SpringBoot核心设计宗旨是约定大于配置，繁琐的配置不如默认配置好再去修改，异常处理场景中通常会继承 Exception 或其子类（如 RuntimeException）来定义业务异常类，用于封装业务相关的错误信息。一般选择继承 RuntimeException，因为它是一个非受检异常，在方法中抛出时不需要显式声明。

工作流引擎很多，也都提供了前端UI库，但是太过于冗杂了，元数据表都几十个，logincFlow和Turbo的组合提供了轻量化方式，turbo后端代码只有5个元数据表，logicFlow也提供了bpm的相关扩展功能，但缺点是turbo社区不活跃，logicFlow个人认为跟echarts这种内置完成所有实现的开源设计方案相比，以插件方式扩展来提供自由度的方式，上手有点难度；

芋道比若依多了租户概念，这也是因为它增加很多业务系统，首先后台管理系统肯定是多租户的，这意味着如商城系统的产品管理SPU、库存管理SKU都可以是多商户的，同样apk侧的header也携带了租户信息，这样apk的客户可以只看某个tenant_id的商户发的产品，这样就可以实现1个商户1个apk端展示，实现了商户的后台管理与用户访问产品的1对1，也就是说同一个后台可以提供给多个商户管理，并且每个商户有一个自己的tenant-id，每个商务有个apk的展示端

在之前博客中详细地说明了若依是如何实现登录鉴权与登录后菜单/按钮权限控制与数据控制的，本文基于+vue3前端（2.2版本）研究它是怎么实现菜单权限控制与数据隔离的；

按照前文所述app版本保持2.2，使用uniapp作为生成工具，因为app版本涉及到登录、商品、支付，微信小程序打包需要企业主权限，所以使用apk打包，使用uniapp自带的云打包，本地app打包实在太繁琐了；

​首先搞个ECS阿里主机，2C2g足够，最大程度保证是docker运行来减少主机资源占用，同时因为是公有云，端口策略安全很重要，每个对外服务的端口要通过安全组放开；mysql的docker使用8版本，首先获取镜像加速：阿里云登录 - 欢迎登录阿里云，安全稳定的云计算服务平台

芋道tags-2.3.0是2024年10月07号发布的，基于此研究下商城功能，全量建表语句已经上传，前端着手研究vue3；之前有关于芋道本地启动的说明，本次使用的2.3跟之前的2.0方式区别不大，其中的mysql的元数据表语句有变动；

简单总结下若依的前后端token鉴权体系流程：1、前端是通过/login接口来获取jwt-token的，jwt的配置在后端的application.yml中2、后端处理/login请求时先检验redis中验证码然后使用spring-security内部机制（过滤链），调用DaoAuthenticationProvider的retrieveUser->loadUserByUsername()来校验用户密码；3、/login接口使用spring-security内部机制会生成authentication这

已知使用MyBatisPlus代码生成器可以自动生成Entity、Mapper、Service、Controller代码，前提是数据库中有数据表，生成pojo类以及对于该数据表的增删改查命令的代码，若依更进一步能选择表后生成代码、预览、下载，同时可以生产前端代码，与后端一起还能实现权限管理和数据隔离。

​已知若依单体的前端采用vue-element-admin，在前端的专栏系列vue-element-admin的动态路由已详细拆解，其最大特点是使用后端返回数据控制前端菜单，每次接口请求前会有路由拦截来获取权限和菜单列表并重新渲染页面，配合若依后端自己实现的数据权限切面，能够实现很好地的数据隔离和权限隔离，那么现在就从代码层面分析其实现；​

国外卷技术，国内卷业务，做管理业务通常使用开源框架就可以快速满足，若依和芋道都是开源二开工具较为流行的框架，芋道是基于若依的，基本上是开发人员自己写业务开发框架的天花板，两者的前端都是基于vue-element-admin的，使用Gitee上两者的SpringBoot的最轻量化版本进行对比学习，分别是ruoyi-admin和ruoyi-vue-pro-master；和和。

若依的前后端分离版本中前端用的是vue-element-admin，它把菜单放在库中控制，后端用security权限管理，代码生成器是亮点，权限能控制到目录/菜单/按钮级别，对于一般开发人员来说不难，难在UI与需求定制化。

真实场景中假如有针对某个组件的状态来判断是否对数据源DataSource初始化或者移除，也就是动态地实例化DataSource的需求，经典场景是我们纳管多个数据库，如果管理平台或者主机层面有问题，那么我们不对数据库进行管理了，把某个数据源给剔除，或者我们在数据源的某个方法进行一些功能增强，就需要这么个实现。动态代理是运行态时候生效的，不是预编译成class代码后加载到jvm内存中后实现的，因此动态代理比较耗费内存；

本节内容基于个人应用开发经验总结，场景特指对于库的CURD操作，有脑就行，内容包括controller对外提供的接口返回规范、serviceImpl返回规范、Pojo类定义及序列化规范、开发中对于数据处理规范；

starter机制基于约定大于配置原则，当项目中配置了特定的starter后会自动导入相关的依赖并配置好bean对象无需手动配置，其使用是java的spi原则，自动加载maven或gradle依赖中的META-INF的spirng.factories下的自动配置类，从而把自动配置类中的bean加载到容器中；此类提供线程局部变量。@Autowired按照byType注入；本质没有大的区别，在加载到beanFactory中的顺序没有差别，只是对外的含义有差别，告诉使用者部分是servie，部分是pojo；

在BeanFactory的创建过程中有很多对外提供的扩展点，就是xxxPostProcessor接口和各种xxxAware接口了，在真实生产中用处极大，可以让我们自定义某些beanDefinition或者某个Bean的属性，或者我们直接拿到SpringContext容器实例化后的对象；

一级缓存中的对象是可以直接使用的，二级和三级缓存中的对象是进行了实例化但是还没有进行初始化的对象，三个缓存是一个factory工程；在bean实例化后的下一步就是填充属性了，如果有循环依赖怎么处理呢，待续。

学习设计模式的目的是让代码更加高效和优雅，光看定义很模糊，结合代码看就比较好理解，这里总结spring等框架种常用的设计模式及代码说明，持续补充；

ThreadLocal类提供线程局部变量。 这些变量不同于它们的普通对应变量，因为每个（通过其get或set方法访问的）线程都有自己的、独立初始化的变量副本。 ThreadLocal实例通常是希望将状态与线程相关联的类中的私有静态字段（例如，用户 ID 或事务 ID），本文中调介绍其概念及jdbc场景使用

记1次生产环境Java内存泄漏问题定位（使用Arthas），堆外内存溢出；

SpringBoot本质上是个脚手架，类似vue-cli，把常用的功能写入application.properties，或者把外部需要的包通过starter机制引入，就会把这些bean实例化到容器内直接使用，如果想使用DataSource数据源只要在application.properties配置数据源就行，因为SpringBoot的spring.factories会自动加载这几个关于数据源的实例对象，这几个实例对象直接读取配置加载

面向切面（AOP) 是spring重要特性，在功能上切面编程是面向对象编程的很好的补充，面向对象强调封装和开闭原则，如果多个对象有通用行为和方法，将造成很多冗余代码，AOP将通用功能作为切面插入到业务逻辑中（如通用的日志打印，异常处理，license判断等）抽取通用逻辑，减少代码冗余，并且无侵入地修改代码，在实现层面上都是通过动态代理实现，默认cglib方式，

测试自定义starter包，该starter包中引入springboot的自动配置依赖，配置spring.factories文件中的自动加载类，实现的功能是在测试的springBoot工程中引入自定义的starter包的pom依赖后，能够调用starter包中的某些实例方法，具体而言是读取application.properties或者application.yml的配置输出；

了解springBoot启动过程能够帮助我们快速熟悉/集成/定制化第三方依赖包，快速地上手搭建工程，在实际上要完成比较复杂的业务代码，还需要继续探索bean的生命周期管理，并且能够在bean的生命周期内增加各种自定义的逻辑，bean的生命周期包括：创建，使用，销毁。bean的使用大家一般都比较熟悉，但最重要的是bean的创建过程，也就是跟随springBoot启动中加载bean的过程。；

动态代理从大的讲是动态语言特性，JAVA作为需要编译才能运行的静态语言，动态代理机制可以为JAVA提供在运行态时对某些对象进行功能增强，Spring中如果有对象使用了AOP相关注解，那么在bean进行实例化后会将对应的动态代理对象放在bean工厂，动态代理有2种实现方式：实现JDK原生动态代理接口，或者使用cglib实现，在默认情况下 Spring AOP 会采用 Java 动态代理实现，而当该类没有对应接口时才会使用 CGLib 动态代理实现。

JVM分析可以也可以使用，那么什么时候用到jvm信息分析呢，一般生产测试环境，能够最大化将问题暴露，但是总有些问题只有生产运行很长时间后才会被发现，jvm分析经常用于运行了很久的系统有异常情况时的调优，比如堆内存本身分配不合理，新生代中eden比例太低等。

gradle-wrapper会绑定一个版本的gradle，在gradle-wrapper.properties中，如6.1版本绑定的是6.4.1版本的gradle，其默认会下载对应版本的gradle，使用 GRADLE_USER_HOME作为包的本地仓库，gradle-wrapper.properties 文件记录：当前项目想使用的 gradle 版本？去哪里下载这个版本的 gradle？Gradle没有依赖包管理功能，它本地保存的是依赖缓存，没有本地仓库的概念，想在Gradle里加一个私有依赖比较麻烦；

Maven是一个Java工程的管理工具，跟其相同功能的工具如Gradle，Maven通过项目对象模型（POM：Project Object Model）用来描述整个项目，也就是POM.xml文件，使用Maven能够方便的管理JAR包依赖，Maven将当前工程需要的JAR 包从远程仓库下载到本地并自动完成依赖的传递，每个JAR有唯一标识也就是坐标，这是依赖可维护性的基础，Maven中的坐标是通过groupId、artifactId、version、packaging、classfier等这些元素定义。mave

熟悉语言和开发工具上基础快速使用框架构建应用是个机械工作，5分钟完成开发准备工作，没有冗余动作。

前面内容包括后端技术框架，以及前端框架选型，即完成单体应用的基本条件，从这里开始进行微服务化改造，后续进行流水线打包（CICD），docker容器化改造，打造成面向真实生产场景的完整解决方案；

纵览springboot启动过程会发现，其本质是创建1个IOC容器，也就是存放bean的容器，使用自动装配简化了spring的各种bean配置（xml文件），启动的所有过程都是为了构建这个bean容器服务。本来首先分析启动类上的注解，再分析SpringApplication的构建过程和run方法流程。

​前面介绍单体的security使用，微服务与单体不同在于所有服务都要过网关，若使用gateway则更要考虑异构问题（security是基于MVC的，而gateway是基于webFlux的），因此在实现上把登录/授权相关功能放在同个工程，而token校验要放在网关中（依然使用security），结合oauth2实现授权模式。假设使用security框架的登录/授权...

无

多模块开发在很大应用上是有必要的，微服务化必然是按照每个模块的功能拆分的，单体也可以进行多模块开发（按照每个模块的功能模块划分但每个模块都没有启动类，如若依），多模块代码的组织方式如下：

之前研究时候用mock.js和模拟登录接口完成Vue-Element-Admin的登录，生产很多场景会使用SpringSecurity框架，因为它功能较多，文档写的不错，所以现在使用真实的场景实现集成，security使用系列的过滤链完成请求的过滤和自定义，直接处理的是HttpServletResponse和HttpServletRequest对象。......

生产级环境前后端交互的封装需要进行标准化，包括后端响应的统一封装，方法返回体的统一封装等，这里介绍一个比较简单规范化的封装标准；

这里提供两种实现方式，一种是通过注解（拿来就用），另一种是自定义配置实现，通过一个工厂类提供创建方式：