|
|
|
@ -6,7 +6,77 @@
|
|
|
|
|
|
|
|
|
|
## 1. 项目内容说明
|
|
|
|
|
|
|
|
|
|
dev-protocol-test
|
|
|
|
|
base
|
|
|
|
|
jvm JVM剖析
|
|
|
|
|
best-practice
|
|
|
|
|
bd-support-project
|
|
|
|
|
my-ms-project 微服务项目实践讲解
|
|
|
|
|
sde 脚手架工程
|
|
|
|
|
dev-protocol-test
|
|
|
|
|
bigdata
|
|
|
|
|
clickhouse ClickHouse剖析
|
|
|
|
|
flink Flink剖析
|
|
|
|
|
kafka Kafka剖析
|
|
|
|
|
spark Spark剖析
|
|
|
|
|
zookeeper Zookeeper剖析
|
|
|
|
|
cloud-native
|
|
|
|
|
containered Containered
|
|
|
|
|
docker Docker
|
|
|
|
|
k8s K8s
|
|
|
|
|
podman Podman
|
|
|
|
|
database
|
|
|
|
|
binlog binlog 日志监听的案例
|
|
|
|
|
mycat Mycat中间件使用
|
|
|
|
|
mysql mysql剖析
|
|
|
|
|
shardingsphere Shardingsphere中间件使用
|
|
|
|
|
jpa Jpa 的方案
|
|
|
|
|
idea-do 设计方案
|
|
|
|
|
longpolling
|
|
|
|
|
demo Demo案例
|
|
|
|
|
file 用的文件
|
|
|
|
|
netty Netty剖析
|
|
|
|
|
practice 实战方案
|
|
|
|
|
mq
|
|
|
|
|
rabbitmq RabbitMQ剖析
|
|
|
|
|
rocketmq RocketMQ剖析
|
|
|
|
|
search
|
|
|
|
|
elasticsearch Elasticsearch剖析
|
|
|
|
|
utils
|
|
|
|
|
dev-protocol-id 分布式Id生成器
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
- dev-protocol-common
|
|
|
|
|
- pom 是基本项目的通用依赖
|
|
|
|
|
- README.md 基本的项目开发规范
|
|
|
|
|
- 代码 常用的一些规范和示例
|
|
|
|
|
dev-protocol-design-pattern
|
|
|
|
|
- Java设计模式总结
|
|
|
|
|
dev-protocol-devops
|
|
|
|
|
- 持续交付等的内容
|
|
|
|
|
dev-protocol-drools
|
|
|
|
|
- 规则引擎
|
|
|
|
|
dev-protocol-extend
|
|
|
|
|
- java-call-other Java 调用其他语言
|
|
|
|
|
-
|
|
|
|
|
dev-protocol-gateway
|
|
|
|
|
- 网关
|
|
|
|
|
dev-protocol-log
|
|
|
|
|
- 日志
|
|
|
|
|
dev-protocol-pay
|
|
|
|
|
- 支付
|
|
|
|
|
dev-protocol-shardingtask
|
|
|
|
|
- 分表分库
|
|
|
|
|
dev-protocol-springboot
|
|
|
|
|
- SpringBoot 研究
|
|
|
|
|
dev-protocol-springcloud
|
|
|
|
|
- SpringCloud 研究
|
|
|
|
|
dev-protocol-test
|
|
|
|
|
- 测试标准
|
|
|
|
|
dev-protocol-tools
|
|
|
|
|
- 常用的工具
|
|
|
|
|
|
|
|
|
|
## 2. 参考
|
|
|
|
|
|
|
|
|
|
- SpringBoot项目Test的编写规范及使用标准
|
|
|
|
|
- 参考: https://mp.weixin.qq.com/s/W5v8zOCHbc2_NvobMGaU8w
|
|
|
|
|
dev-protocol-log
|
|
|
|
@ -16,168 +86,4 @@ dev-protocol-gateway
|
|
|
|
|
dev-protocol-devops
|
|
|
|
|
- DevOps 相关的最佳实现
|
|
|
|
|
dev-protocol-shardingtask
|
|
|
|
|
- 配置多数据源和分表分库实现
|
|
|
|
|
|
|
|
|
|
### 1.1 基本命令(dev-protocol-log)
|
|
|
|
|
|
|
|
|
|
- Kafka
|
|
|
|
|
查看topic列表命令(连接其中一个就好了):
|
|
|
|
|
【旧版】kafka-topics.sh --zookeeper 172.16.26.183:2181 --list
|
|
|
|
|
【新版】kafka-topics.sh --bootstrap-server 172.16.26.183:9092 --list
|
|
|
|
|
(– zookeeper is not a recognized option主要原因是 Kafka 版本过高,命令不存在)
|
|
|
|
|
创建topic主题
|
|
|
|
|
kafka-topics.sh --bootstrap-server 172.16.26.183:9092 --create --topic topic1 --partitions 1 --replication-factor 3
|
|
|
|
|
--create 命令后 --topic 为创建topic 并指定 topic name
|
|
|
|
|
--partitions 为指定分区数量
|
|
|
|
|
--replication-factor 为指定副本集数量
|
|
|
|
|
向kafka集群发送数据
|
|
|
|
|
【无key型消息】kafka-console-producer.sh --bootstrap-server 172.16.26.183:9092 --topic topic1
|
|
|
|
|
【有key型消息】 kafka-console-producer.sh --bootstrap-server 172.16.26.183:9092 --topic topic1 --property parse.key=true
|
|
|
|
|
(默认消息键与消息值间使用“Tab键”进行分隔,切勿使用转义字符(\t))
|
|
|
|
|
kafka命令接受数据
|
|
|
|
|
kafka-console-consumer.sh --bootstrap-server 172.16.26.183:9092 --topic topic1 --from-beginning
|
|
|
|
|
kafka查看消费进度:(当我们需要查看一个消费者组的消费进度时,则使用下面的命令)(启动Consumer的时候才会真的生效)【这条命令对查询消费特别重要】
|
|
|
|
|
kafka-consumer-groups.sh --bootstrap-server 172.16.26.183:9092 --describe --group group1
|
|
|
|
|
|
|
|
|
|
### 1.2 注意事项(dev-protocol-log)
|
|
|
|
|
|
|
|
|
|
一致性确定
|
|
|
|
|
命令中的 --bootstrap-server 和配置文件中的要一致
|
|
|
|
|
# 允许外部端口连接
|
|
|
|
|
listeners=PLAINTEXT://0.0.0.0:9092
|
|
|
|
|
# 外部代理地址
|
|
|
|
|
advertised.listeners=PLAINTEXT://121.201.64.12:9092
|
|
|
|
|
https://blog.csdn.net/pbrlovejava/article/details/103451302
|
|
|
|
|
国内下载镜像加速
|
|
|
|
|
https://www.newbe.pro/
|
|
|
|
|
|
|
|
|
|
### 1.3 海量日志收集架构设计(dev-protocol-log)
|
|
|
|
|
|
|
|
|
|
- 海量日志收集架构示意图
|
|
|
|
|
![avatar](dev-protocol-log/pic/海量日志收集架构示意图.png)
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
- 标准架构(海量): Beats(日志收集) -> kafka(日志堆积) -> Logstash(日志过滤) -> ElasticSearch(日志查询) -> Kibana(效果展示)
|
|
|
|
|
- 简化收集方案1: 直接使用Log4j的插件和Logstash集成 -> ElasticSearch(日志查询) -> Kibana(效果展示)
|
|
|
|
|
- 简化收集方案2: 使用Log4j自己封装一个appender -> ElasticSearch(日志查询) -> Kibana(效果展示)
|
|
|
|
|
- 简化收集方案3: 直接使用kafka的appender(log4j提供的),直接实现 -> kafka(日志堆积) -> ElasticSearch(日志查询) -> Kibana(效果展示)
|
|
|
|
|
- 先进技术: SkyWalking 的 Netty或者Agent的方式,直接传到另外一个Agent端
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
- 实际落地架构图
|
|
|
|
|
![avatar](dev-protocol-log/pic/实际落地架构图.png)
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
- 全域日志收集架构落地图
|
|
|
|
|
![avatar](dev-protocol-log/pic/全域日志收集架构落地图.png)
|
|
|
|
|
|
|
|
|
|
### 1.4 日志输出设计
|
|
|
|
|
|
|
|
|
|
- 1. 使用 Log4j2 的相关技术进行日志定义
|
|
|
|
|
![avatar](dev-protocol-log/pic/日志输出功能详情.png)
|
|
|
|
|
- 2. 使用 filebeat 进行日志的收集
|
|
|
|
|
![avatar](dev-protocol-log/pic/FIleBeat日志收集.png)
|
|
|
|
|
|
|
|
|
|
启动前先进行检查 ./filebeat -c 配置文件.yml -configtest
|
|
|
|
|
启动顺序 kafka -> 自己的应用程序 -> filebeat
|
|
|
|
|
-
|
|
|
|
|
|
|
|
|
|
### 3.1 智能网关
|
|
|
|
|
|
|
|
|
|
#### JWT 在微服务架构下的认证过程
|
|
|
|
|
|
|
|
|
|
- A> 服务器自主验签方式
|
|
|
|
|
![avatar](dev-protocol-gateway/pic/服务器自主验签方式.png)
|
|
|
|
|
|
|
|
|
|
- 第一步,认证中心微服务负责用户认证任务,在启动时从 Nacos 配置中心抽取 JWT 加密用私钥
|
|
|
|
|
- 第二步,用户在登录页输入用户名密码,客户端向认证中心服务发起认证请求
|
|
|
|
|
- 第三步,认证中心服务根据输入在用户数据库中进行认证校验,如果校验成功则返回认证中心将生成用户的JSON数据并创建对应的 JWT 返回给客户端
|
|
|
|
|
- 第四步,在收到 JSON 数据后,客户端将其中 token 数据保存在 cookie 或者本地缓存中
|
|
|
|
|
- 第五步,随后客户端向具体某个微服务发起新地请求,这个 JWT 都会附加在请求头或者 cookie 中发往 API 网关,网关根据路由规则将请求与jwt数据转发至具体的微服务。中间过程网关不对 JWT 做任何处理
|
|
|
|
|
- 第六步,微服务接收到请求后,发现请求附带 JWT 数据,于是将 JWT 再次转发给用户认证服务,此时用户认证服务对 JWT 进行验签,验签成功提取其中用户编号,查询用户认证与授权的详细数据
|
|
|
|
|
- 第七步,具体的微服务收到上述 JSON 后,对当前执行的操作进行判断,检查是否拥有执行权限,权限检查通过执行业务代码,权限检查失败返回错误响应
|
|
|
|
|
- B> API 网关统一验签方案
|
|
|
|
|
![avatar](dev-protocol-gateway/pic/API网关统一验签方案.png)
|
|
|
|
|
API 网关统一验签与服务端验签最大的区别是在 API 网关层面就发起 JWT 的验签请求,之后路由过程中附加的是从认证中心返回的用户与权限数据,其他的操作步骤与方案一是完全相同的
|
|
|
|
|
|
|
|
|
|
## TODO-List
|
|
|
|
|
|
|
|
|
|
1. 使用 切面+注解 的方式对同一类的请求带上相对应的验证信息
|
|
|
|
|
2. 注意在调用请求的时候要对内部鉴权方式和外部鉴权方式进行区分,然后知道在使用JWT方案的时候要进行JWT防止伪造鉴定
|
|
|
|
|
3. Nginx相关的配置
|
|
|
|
|
|
|
|
|
|
## JPA审计
|
|
|
|
|
|
|
|
|
|
### 建议使用源码
|
|
|
|
|
|
|
|
|
|
dev-protocol-jpaauditing1 (自定义审计)
|
|
|
|
|
dev-protocol-jpaauditing2 (内部代码实现方式)
|
|
|
|
|
dev-protocol-jpaauditing3 (正式环境使用)
|
|
|
|
|
|
|
|
|
|
### 原理分析
|
|
|
|
|
|
|
|
|
|
1. 从 @EnableJpaAuditing 入手分析
|
|
|
|
|
|
|
|
|
|
1. package org.springframework.data.jpa.repository.config;
|
|
|
|
|
2. @Import(JpaAuditingRegistrar.class)
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
Auditing 这套封装是 Spring Data JPA 实现的,而不是 Java Persistence API 规定的
|
|
|
|
|
注解里面还有一项重要功能就是 @Import(JpaAuditingRegistrar.class) 这个类,它帮我们处理 Auditing 的逻辑。
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
步入 org.springframework.data.jpa.repository.config.JpaAuditingRegistrar.registerBeanDefinitions 方法
|
|
|
|
|
|
|
|
|
|
1. super.registerBeanDefinitions(annotationMetadata, registry);
|
|
|
|
|
2. registerInfrastructureBeanWithId(...);
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
2. 打开 AuditingEntityListener 的源码
|
|
|
|
|
1. AuditingEntityListener 的实现还是比较简单的,利用了 Java Persistence API 里面的@PrePersist、@PreUpdate 回调函数,
|
|
|
|
|
在更新和创建之前通过AuditingHandler 添加了用户信息和时间信息
|
|
|
|
|
|
|
|
|
|
### 原理分析结论
|
|
|
|
|
|
|
|
|
|
1. 查看 Auditing 的实现源码,其实给我们提供了一个思路,就是怎么利用 @PrePersist、@PreUpdate 等回调函数和
|
|
|
|
|
@EntityListeners 定义自己的框架代码。这是值得我们学习和参考的,比如说 Auditing 的操作日志场景等。
|
|
|
|
|
2. 想成功配置 Auditing 功能,必须将 @EnableJpaAuditing 和 @EntityListeners(AuditingEntityListener.class) 一起使用才有效。
|
|
|
|
|
3. 我们是不是可以不通过 Spring data JPA 给我们提供的 Auditing 功能,而是直接使用 @PrePersist、@PreUpdate 回调函数注解在实体上,
|
|
|
|
|
也可以达到同样的效果呢?答案是肯定的,因为回调函数是实现的本质。
|
|
|
|
|
|
|
|
|
|
### 整理
|
|
|
|
|
|
|
|
|
|
使用相对应的注解去注册进Spring容器
|
|
|
|
|
使用注册的回调函数进行注解化设置
|
|
|
|
|
|
|
|
|
|
## 正确使用 @Entity 里面的回调方法
|
|
|
|
|
|
|
|
|
|
### 概念掌握
|
|
|
|
|
|
|
|
|
|
Java Persistence API 里面规定的回调方法有哪些?
|
|
|
|
|
回调事件注解表
|
|
|
|
|
![avatar](jpa/pic/回调事件注册表.png)
|
|
|
|
|
|
|
|
|
|
- 注意事项
|
|
|
|
|
- 回调函数都是和 EntityManager.flush 或 EntityManager.commit 在同一个线程里面执行的,只不过调用方法有先后之分,
|
|
|
|
|
都是同步调用,所以当任何一个回调方法里面发生异常,都会触发事务进行回滚,而不会触发事务提交。
|
|
|
|
|
- Callbacks 注解可以放在实体里面,可以放在 super-class 里面,也可以定义在 entity 的 listener 里面,但需要注意的是:
|
|
|
|
|
放在实体(或者 super-class)里面的方法,签名格式为“void ()”,即没有参数,方法里面操作的是 this 对象自己;
|
|
|
|
|
放在实体的 EntityListener 里面的方法签名格式为“void (Object)”,也就是方法可以有参数,参数是代表用来接收回调方法的实体。
|
|
|
|
|
- Callbacks 注解可以放在实体里面,可以放在 super-class 里面,也可以定义在 entity 的 listener 里面,
|
|
|
|
|
但需要注意的是:放在实体(或者 super-class)里面的方法,签名格式为“void ()”,即没有参数,方法里面操作的是 this 对象自己;
|
|
|
|
|
放在实体的 EntityListener 里面的方法签名格式为“void (Object)”,也就是方法可以有参数,参数是代表用来接收回调方法的实体。
|
|
|
|
|
- JPA Callbacks 的使用方法
|
|
|
|
|
- 修改 BaseEntity,在里面新增回调函数和注解
|
|
|
|
|
|
|
|
|
|
### 使用总结
|
|
|
|
|
|
|
|
|
|
在实体中定义一些通用逻辑, 然后在对应 Listener中进行调用时机指定 (参数的合理化和健壮性检测)
|
|
|
|
|
JPA Callbacks 的实现原理,事件机制
|
|
|
|
|
|
|
|
|
|
### JPA Callbacks 的最佳实践
|
|
|
|
|
- 配置多数据源和分表分库实现
|