zuihou-admin-cloud 升级,独立 Schema 的微服务 SaaS 平台
# 更新日志:
1,完善用户中心(修改头像、登录时间、账号信息、修改密码等)相关接口对接
2,完善用户管理的用户信息修改相关接口
3,修复jobs服务启动报错
4,统一jobs服务的logback日志配置
5,完善启动文档&脚本
6,修复文件服务在window系统下返回路径错误的bug
7,发布启动教学视频
# 功能点介绍:
- 服务注册与调用:
基于Eureka来实现的服务注册与调用,在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验,开发者完全感知不到这是远程方法,更感知不到这是个HTTP请求。
- 服务鉴权:
通过JWT的方式来加强服务之间调度的权限验证,保证内部服务的安全性。
- 负载均衡:
将服务保留的rest进行代理和网关控制,除了平常经常使用的node.js、nginx外,Spring Cloud系列的zuul和rebbion,可以帮我们进行正常的网关管控和负载均衡。其中扩展和借鉴国外项目的扩展基于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):
- 当前用户信息注入器:
- 在线API:
由于原生swagger-ui某些功能支持不够友好,故采用了国内开源的`swagger-bootstrap-ui`,并制作了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侵入** 的方式,解决 微服务 场景下面临的分布式事务问题。
# 项目代码地址
微服务后端 代码:
[gitee] https://gitee.com/zuihou111/zuihou-admin-cloud /[github] https://github.com/zuihou/zuihou-admin-cloud
租户系统 代码:
[gitee] https://gitee.com/zuihou111/zuihou-ui / [github] https://github.com/zuihou/zuihou-ui
开发&运营管理系统 代码:
[gitee] https://gitee.com/zuihou111/zuihou-admin-ui / [github] https://github.com/zuihou/zuihou-admin-ui
[代码生成器] https://github.com/zuihou/zuihou-generator
# 演示地址 (演示账号没有写权限,只能查询)
[租户系统演示环境] http://tangyh.top:10000/zuihou-ui/
平台管理员账号/密码: zuihou/zuihou
普通用户账号/密码: test/zuiou
[开发&运营平台演示环境] http://tangyh.top:180/zuihou-admin-ui/
账号/密码: demoAdmin/zuihou
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一文彻底搞懂Cookie、Session、Token到底是什么
> 笔者文笔功力尚浅,如有不妥,请慷慨指出,必定感激不尽 Cookie 洛:大爷,楼上322住的是马冬梅家吧? 大爷:马都什么? 夏洛:马冬梅。 大爷:什么都没啊? 夏洛:马冬梅啊。 大爷:马什么没? 夏洛:行,大爷你先凉快着吧。 在了解这三个概念之前我们先要了解HTTP是无状态的Web服务器,什么是无状态呢?就像上面夏洛特烦恼中经典的一幕对话一样,一次对话完成后下一次对话完全不知道上一次对话发生了什么。如果在Web服务器中只是用来管理静态文件还好说,对方是谁并不重要,把文件从磁盘中读取出来发出去即可。但是随着网络的不断发展,比如电商中的购物车只有记住了用户的身份才能够执行接下来的一系列动作。所以此时就需要我们无状态的服务器记住一些事情。 那么Web服务器是如何记住一些事情呢?既然Web服务器记不住东西,那么我们就在外部想办法记住,相当于服务器给每个客户端都贴上了一个小纸条。上面记录了服务器给我们返回的一些信息。然后服务器看到这张小纸条就知道我们是谁了。那么Cookie是谁产生的呢?Cookies是由服务器产生的。接下来我们描述一下Cookie产生的过程 浏览器第一次访问服务端时...
- 下一篇
ycss 1.0.1发布
1.增加全局变量设置 2.增加输出目标文件设置 3.增加演示图片 Next: 1.增加rn基础正则。 2.增加初始化处理。 3.文件不存在,不能按照预期处理文件。 github地址
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- MySQL8.0.19开启GTID主从同步CentOS8
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8编译安装MySQL8.0.19
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS关闭SELinux安全模块
- Hadoop3单机部署,实现最简伪集群
- CentOS6,7,8上安装Nginx,支持https2.0的开启