内容简介：今日更新日志: 新增 新增 Base、Delete、Poi、Save、Update、Query等6个功能的Controller接口，方便业务方并提供默认实现SuperSimpleController、SuperNoPoiController、SuperController、SuperCacheController。...

今日更新日志:

新增

• 新增 Base、Delete、Poi、Save、Update、Query等6个功能的Controller接口，方便业务方并提供默认实现SuperSimpleController、SuperNoPoiController、SuperController、SuperCacheController。
• 新增 SuperCacheController、SuperCacheService、SuperCacheServiceImpl 一套默认使用缓存的基类
• 新增 SuperController、SuperService、SuperServiceImpl 一套无缓存基类，用于区分上面的3个基类 
• 新增 手动查询当前登录用户、角色、岗位、组织信息。（原来只能用过 @LoginUser SysUser 方式注入）
• 新增 项目功能兼容 mysql 8.0.19 （nacos使用 mysql8 需要修改nacos官方源码中驱动的版本号，并自行编译！！！）
• 前端项目：所有的分页查询请求改成POST、分页切换页面时记忆历史选中项目、点击表格一行的任意位置即为勾选、默认创建时间支持 排序 、所有表格head筛选改成后端筛选。
• 操作日志记录支持DB存储和FILE存储2种选择，并重新定义日志格式，支持应用名、端口号、租户ID、用户ID、日志链路ID等信息
• 多租户模式支持配置成 租户字段模式
• 用户管理页面支持导出、导入校验功能
• 新增new LbqWrapper(entity);方法，当entity中有类型为RemoteData的字段时，key为空也忽略拼接该字段。 

优化

• 依赖升级：springboot -> 2.2.5、 mysql -> 8.0.18、lombok -> 1.18.12、 fastjson -> 1.2.66、 mybatis-> 3.5.3、guava -> 22.0、 hutool -> 5.2.1、knife4j -> 2.0.2
• 完全独立zuihou-commons包，并优化相关配置，使得完美兼容cloud和boot项目
• zuihou-commons相关jar发布至正式中央仓库。
• 优化代码生成器，兼容新增的几个基类（Super*）
• 废弃zuihou-api模块，将 zuihou-*-api 模块移动到 zuihou-* 模块下，方便部署编译
• 废弃原 BaseController 基类，并将原来写的所有代码，继承了全新的基类。
• 谨遵约定大于配置原则，优化zuihou-user-stater、zuihou-scan-stater使得选择Feign、Service、Rabbit模式时，其他模式的实现类完全不初始化
• 原来pom里面的配置移动到src/main/filters/config-ENV.properties
• 记录操作日志优化，支持开关、继承覆盖。
• 原zuihou-config下存放的配置文件移动到third-party/nacos/clientConfig
• 新增清理指定时段内的操作日志和登录日志的方法

修复

• 修复MultiTenantInterceptor拦截器类，无法替换部分复杂 SQL 表名的bug
• zuihou-admin-ui 刷新页面后，切换菜单时控制台报错。

zuihou-admin-cloud 项目1.9.x版本 代码更新升级指引：
0.以下几点只适用于在1.x版本中没有改动代码或者改动较少的情况，若对原来项目的代码该多较大，请重新找一个目录clone项目
1.在IDEA2019.3中，点击 Update Projects ,勾选： Merge the incoming changes into the current branch 后点OK
2.等代码更新完毕后，在文件资源管理器中将`zuihou-commons`、`zuihou-backend`、`zuihou-dependencies`3个文件夹直接删除。

配置文件变更（包含但不限于以下配置）：
0.nacos中 commmon.yml 新增：

zuihou:
  log:
    enabled: true
    type: DB         # 存储的Mysql还是Logger打印在日志文件中

1.nacos中 zuihou-order-server.yml 和 zuihou-demo-server.yml: 修改

zuihou:
  database:
    multiTenantType: NONE       # 修改前：     isMultiTenant: false

2.nacos中 mysql.yml: 修改

zuihou:
  database:
    multiTenantType: SCHEMA   # 修改前：isMultiTenant: true  

3.项目中：zuihou-admin-cloud/zuihou-dependencies/pom.xml 中 profiles 相关的配置移动到了 zuihou-admin-cloud/src/main/filters/config-dev.properties

nacos.ip=127.0.0.1
nacos.port=8848
nacos.namespace=b16f7baf-56e7-4f4e-a26c-425ee0668016
seata.namespace=

4.原来存放在 zuihou-commons/src/main/resources 中的nacos配置文件，移动到了 third-party/nacos/clientConfig

 

为什么要将zuihou-commons模块独立出来？
    1.工具代码和业务代码存放在一个工程，复制项目时，会增加冗余代码。
    2.zuihou-commons项目下的所有模块均为独立的 工具 包，她的用途不局限于zuihou-admin-cloud和zuihou-admin-boot2个项目，而是适合任意SpringBoot或者SpringCloud项目

为何要将项目拆分成这么多子模块？
    这是高内聚低耦合的最佳体现
    增强代码的可读性、复用性、可维护性和易变更性
    模块内部的代码，相互之间的联系越强，内聚就越高， 模块的独立性就越好。 一个模块应该尽量的独立，去完成独立的功能！
    如果有代码非得引入到独立的模块，建议拆分成多模块！低内聚的代码，不好维护，代码也不够健壮
 

简介：

基于`SpringCloud(Hoxton.SR1)`  + `SpringBoot(2.2.5.RELEASE)` 的 SaaS型微服务脚手架，具备用户管理、资源权限管理、网关统一鉴权、Xss防跨站攻击、自动代码生成、多存储系统、分布式事务、分布式定时任务等多个模块，支持多业务系统并行开发，支持多服务并行开发，可以作为后端服务的开发脚手架。代码简洁，架构清晰，非常适合学习使用。核心技术采用Nacos、Fegin、Ribbon、Zuul、Hystrix、JWT Token、Mybatis、SpringBoot、Seata、Nacos、Sentinel、RabbitMQ、FastDFS等主要框架和中间件。

希望能努力打造一套从 SaaS基础框架 - 分布式微服务架构 - 自动化部署 - 系统监测 的解决方案。本项目旨在实现基础能力，不涉及具体业务。
 

功能点介绍:

服务注册与调用：

基于Eureka来实现的服务注册与调用，在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。

 服务鉴权:

通过JWT的方式来加强服务之间调度的权限验证，保证内部服务的安全性。

负载均衡：

将服务保留的rest进行代理和网关控制，除了平常经常使用的node.js、nginx外，Spring Cloud系列的zuul和ribbon，可以帮我们进行正常的网关管控和负载均衡。其中扩展和借鉴国外项目的扩展基于JWT的Zuul限流插件，方面进行限流。

 熔断机制：

因为采取了服务的分布，为了避免服务之间的调用“雪崩”，采用了Hystrix的作为熔断器，避免了服务之间的“雪崩”。

监控：

利用Spring Boot Admin 来监控各个独立Service的运行状态；利用turbine来实时查看接口的运行状态和调用频率；通过Zipkin来查看各个服务之间的调用链等。

数据权限：

利用基于Mybatis的DataScopeInterceptor拦截器实现了简单的数据权限

SaaS的无感解决方案：

使用Mybatis拦截器实现对所有SQL的拦截，修改默认的Schema，从而实现多租户数据隔离的目的。

二级缓存：

采用J2Cache操作缓存，第一级缓存使用内存(Caffeine)，第二级缓存使用 Redis。 由于大量的缓存读取会导致 L2 的网络成为整个系统的瓶颈，因此 L1 的目标是降低对 L2 的读取次数。 该缓存框架主要用于集群环境中。单机也可使用，用于避免应用重启导致的缓存冷启动后对后端业务的冲击。

优雅的Bean转换：

采用Dozer组件来对 DTO、DO、PO等对象的优化转换

前后端统一表单验证：

严谨的表单验证通常需要 前端+后端同时验证， 但传统的项目，均只能前后端各做一次检验， 后期规则变更，又得前后端同时修改。 故在hibernate-validator的基础上封装了zuihou-validator-starter起步依赖，提供一个通用接口，可以获取需要校验表单的规则，然后前端使用后端返回的规则， 以后若规则改变，只需要后端修改即可。

防跨站脚本攻击（XSS）：

•      通过过滤器对所有请求中的 表单参数 进行过滤
•      通过Json反序列化器实现对所有 application/json 类型的参数 进行过滤

当前用户信息注入器：

 通过注解实现用户身份注入

在线API：

由于原生swagger-ui某些功能支持不够友好，故采用了国内开源的 knife4j ，并制作了stater，方便springboot用户使用。

代码生成器：

基于Mybatis-plus-generator自定义了一套代码生成器， 通过配置数据库字段的注释，自动生成枚举类、数据字典注解、SaveDTO、UpdateDTO、表单验证规则注解、Swagger注解等。

定时任务调度器：

基于xxl-jobs进行了功能增强。（如：指定时间发送任务、执行器和调度器合并项目、多数据源）

汉化 Eureka 注册中心页面：

请切换分支进行查看

大文件/断点/分片续传：

前端采用webupload.js、后端采用NIO实现了大文件断点分片续传，启动Eureka、Zuul、File服务后，直接打开docs/chunkUploadDemo/demo.html即可进行测试。 经测试，本地限制堆栈最大内存128M启动File服务,5分钟内能成功上传4.6G+的大文件，正式服耗时则会受到用户带宽和服务器带宽的影响，时间比较长。

分布式事务：

集成了阿里的分布式事务中间件：seata，以 高效 并且对业务 0侵入 的方式，解决 微服务 场景下面临的分布式事务问题。

灰度发布:
    
为了解决频繁的服务更新上线，版本回退，快速迭代，公司内部协同开发，本项目采用修改ribbon的负载均衡策略来实现来灰度发布。     

关联数据自动注入：

用于解决跨表、跨库、跨服务分页数据的属性或单个对象的属性 回显关联数据之痛, 支持对静态数据属性(数据字典)、动态主键数据进行自动注入。

项目代码地址

项目	gitee	github	备注
微服务项目	https://gitee.com/zuihou111/zuihou-admin-cloud	https://github.com/zuihou/zuihou-admin-cloud	SpringCloud 版本后端代码
单体项目	https://gitee.com/zuihou111/zuihou-admin-boot	https://github.com/zuihou/zuihou-admin-boot	SpringBoot 版本后端代码
租户后台	https://gitee.com/zuihou111/zuihou-ui	https://github.com/zuihou/zuihou-ui |	给客户使用的前端
开发&运营后台	https://gitee.com/zuihou111/zuihou-admin-ui	https://github.com/zuihou/zuihou-admin-ui	给公司内部开发&运营&运维等人员使用
代码生成器	https://gitee.com/zuihou111/zuihou-generator	https://github.com/zuihou/zuihou-generator	开发人员使用
核心工具包	https://gitee.com/zuihou111/zuihou-commons	https://github.com/zuihou/zuihou-commons	核心工具包

演示地址 （演示账号没有写权限，只能查询）

项目	演示地址	管理员账号	普通账号
租户后台	http://tangyh.top:10000/zuihou-ui	zuihou/zuihou	test/zuiou
开发&运营后台	http://tangyh.top:180/zuihou-admin-ui	demoAdmin/zuihou	无

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• OrangeAdmin 橙单中台化低代码生成器发布 v1.4 版本，支持多租户及租户运营管理功能
• Cloudant 多租户服务最佳实践
• Cloudant 多租户服务最佳实践
• 多租户已死！云架构上位
• 一文读懂HBase多租户
• [译] Kubernetes 多租户集群的实践

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。