🚧 这个分支是
TransmittableThreadLocal(TTL) v3
,在开发中还没有发布。
v3
的版本说明、工作项列表及其进展,参见 issue 432。👉 目前使用中的稳定发布版本
v2.x
在 分支2.x
上。
📖 English Documentation | 📖 中文文档
- 🔧 功能
- 🎨 需求场景
- 👥 User Guide
- 🔌 Java API Docs
- 🍪 Maven依赖
- 🔨 关于编译构建
- ❓ FAQ
- ✨ 使用
TTL
的好处与必要性 - 🗿 更多文档
- 📚 相关资料
- 💗 Who Used
- 👷 Contributors
👉 TransmittableThreadLocal
(TTL
):在使用线程池等会池化复用线程的执行组件情况下,提供ThreadLocal
值的传递功能,解决异步执行时上下文传递的问题。一个Java
标准库本应为框架/中间件设施开发提供的标配能力,本库功能聚焦 & 0依赖,支持Java 6~21
。
JDK
的InheritableThreadLocal
类可以完成父线程到子线程的值传递。但对于使用线程池等会池化复用线程的执行组件的情况,线程由线程池创建好,并且线程是池化起来反复使用的;这时父子线程关系的ThreadLocal
值传递已经没有意义,应用需要的实际上是把 任务提交给线程池时的ThreadLocal
值传递到 任务执行时。
本库提供的TransmittableThreadLocal
类继承并加强InheritableThreadLocal
类,解决上述的问题,使用详见 User Guide。
整个TransmittableThreadLocal
库的核心功能(用户API
、线程池ExecutorService
/ForkJoinPool
/TimerTask
及其线程工厂的Wrapper
;开发者API
、框架/中间件的集成API
),只有 ~1000 SLOC
代码行,非常精小。
欢迎 👏
- 建议和提问,提交 Issue
- 贡献和改进,Fork 后提通过 Pull Request 贡献代码
ThreadLocal
的需求场景即TransmittableThreadLocal
的潜在需求场景,如果你的业务需要『在使用线程池等会池化复用线程的执行组件情况下传递ThreadLocal
值』则是TransmittableThreadLocal
目标场景。
下面是几个典型场景例子。
- 分布式跟踪系统 或 全链路压测(即链路打标)
- 日志收集记录系统上下文
Session
级Cache
- 应用容器或上层框架跨应用代码给下层
SDK
传递信息
各个场景的展开说明参见子文档 需求场景。
使用类TransmittableThreadLocal
来保存值,并跨线程池传递。
TransmittableThreadLocal
继承InheritableThreadLocal
,使用方式也类似。相比InheritableThreadLocal
,添加了protected
的transmitteeValue()
方法,用于定制 任务提交给线程池时 的ThreadLocal
值传递到 任务执行时 的传递方式,缺省是简单的赋值传递。
注意:如果传递的对象(引用类型)会被修改,且没有做深拷贝(如直接传递引用或是浅拷贝),那么
- 因为跨线程传递而不再有线程封闭,传递对象在多个线程之间是有共享的。
- 与
JDK
的InheritableThreadLocal.childValue()
一样,需要使用者/业务逻辑注意保证传递对象的线程安全。
关于
transmitteeValue
方法 的 展开说明
关于构词后缀
er
与ee
的说明:
transmit
是动词传递,transmitter
动作的执行者/主动方,而transmittee
动作的接收者/被动方。er
与ee
后缀的常见词是employer
(雇主)/employee
(雇员)、caller
(调用者)/callee
(被调用者)。
具体使用方式见下面的说明。
父线程给子线程传递值。
示例代码:
TransmittableThreadLocal<String> context = new TransmittableThreadLocal<>();
// =====================================================
// 在父线程中设置
context.set("value-set-in-parent");
// =====================================================
// 在子线程中可以读取,值是"value-set-in-parent"
String value = context.get();
# 完整可运行的Demo代码参见SimpleDemo.kt
。
这其实是InheritableThreadLocal
的功能,应该使用InheritableThreadLocal
来完成。
但对于使用线程池等会池化复用线程的执行组件的情况,线程由线程池创建好,并且线程是池化起来反复使用的;这时父子线程关系的ThreadLocal
值传递已经没有意义,应用需要的实际上是把 任务提交给线程池时的ThreadLocal
值传递到 任务执行时。
解决方法参见下面的这几种用法。
使用TtlRunnable
和TtlCallable
来修饰传入线程池的Runnable
和Callable
。
示例代码:
TransmittableThreadLocal<String> context = new TransmittableThreadLocal<>();
// =====================================================
// 在父线程中设置
context.set("value-set-in-parent");
Runnable task = new RunnableTask();
// 额外的处理,生成修饰了的对象ttlRunnable
Runnable ttlRunnable = TtlRunnable.get(task);
executorService.submit(ttlRunnable);
// =====================================================
// Task中可以读取,值是"value-set-in-parent"
String value = context.get();
注意:
即使是同一个Runnable
任务多次提交到线程池时,每次提交时都需要通过修饰操作(即TtlRunnable.get(task)
)以抓取这次提交时的TransmittableThreadLocal
上下文的值;即如果同一个任务下一次提交时不执行修饰而仍然使用上一次的TtlRunnable
,则提交的任务运行时会是之前修饰操作所抓取的上下文。示例代码如下:
// 第一次提交
Runnable task = new RunnableTask();
executorService.submit(TtlRunnable.get(task));
// ...业务逻辑代码,
// 并且修改了 TransmittableThreadLocal上下文 ...
context.set("value-modified-in-parent");
// 再次提交
// 重新执行修饰,以传递修改了的 TransmittableThreadLocal上下文
executorService.submit(TtlRunnable.get(task));
上面演示了Runnable
,Callable
的处理类似
TransmittableThreadLocal<String> context = new TransmittableThreadLocal<>();
// =====================================================
// 在父线程中设置
context.set("value-set-in-parent");
Callable call = new CallableTask();
// 额外的处理,生成修饰了的对象ttlCallable
Callable ttlCallable = TtlCallable.get(call);
executorService.submit(ttlCallable);
// =====================================================
// Call中可以读取,值是"value-set-in-parent"
String value = context.get();
# 完整可运行的Demo代码参见TtlWrapperDemo.kt
。
省去每次Runnable
和Callable
传入线程池时的修饰,这个逻辑可以在线程池中完成。
通过工具类TtlExecutors
完成,有下面的方法:
getTtlExecutor
:修饰接口Executor
getTtlExecutorService
:修饰接口ExecutorService
getTtlScheduledExecutorService
:修饰接口ScheduledExecutorService
示例代码:
ExecutorService executorService = ...
// 额外的处理,生成修饰了的对象executorService
executorService = TtlExecutors.getTtlExecutorService(executorService);
TransmittableThreadLocal<String> context = new TransmittableThreadLocal<>();
// =====================================================
// 在父线程中设置
context.set("value-set-in-parent");
Runnable task = new RunnableTask();
Callable call = new CallableTask();
executorService.submit(task);
executorService.submit(call);
// =====================================================
// Task或是Call中可以读取,值是"value-set-in-parent"
String value = context.get();
# 完整可运行的Demo代码参见TtlExecutorWrapperDemo.kt
。
这种方式,实现线程池的传递是透明的,业务代码中没有修饰Runnable
或是线程池的代码。即可以做到应用代码 无侵入。
# 关于 无侵入 的更多说明参见文档Java Agent
方式对应用代码无侵入。
示例代码:
// ## 1. 框架上层逻辑,后续流程框架调用业务 ##
TransmittableThreadLocal<String> context = new TransmittableThreadLocal<>();
context.set("value-set-in-parent");
// ## 2. 应用逻辑,后续流程业务调用框架下层逻辑 ##
ExecutorService executorService = Executors.newFixedThreadPool(3);
Runnable task = new RunnableTask();
Callable call = new CallableTask();
executorService.submit(task);
executorService.submit(call);
// ## 3. 框架下层逻辑 ##
// Task或是Call中可以读取,值是"value-set-in-parent"
String value = context.get();
Demo参见AgentDemo.kt
。执行工程下的脚本scripts/run-agent-demo.sh
即可运行Demo。
目前TTL Agent
中,修饰了的JDK
执行器组件(即如线程池)如下:
java.util.concurrent.ThreadPoolExecutor
和java.util.concurrent.ScheduledThreadPoolExecutor
- 修饰实现代码在
JdkExecutorTtlTransformlet.java
。
- 修饰实现代码在
java.util.concurrent.ForkJoinTask
(对应的执行器组件是java.util.concurrent.ForkJoinPool
)- 修饰实现代码在
ForkJoinTtlTransformlet.java
。从版本2.5.1
开始支持。 - 注意:
Java 8
引入的CompletableFuture
与(并行执行的)Stream
底层是通过ForkJoinPool
来执行,所以支持ForkJoinPool
后,TTL
也就透明支持了CompletableFuture
与Stream
。🎉
- 修饰实现代码在
java.util.TimerTask
的子类(对应的执行器组件是java.util.Timer
)- 修饰实现代码在
TimerTaskTtlTransformlet.java
。从版本2.7.0
开始支持。 - 注意:从
2.11.2
版本开始缺省开启TimerTask
的修饰(因为保证正确性是第一位,而不是最佳实践『不推荐使用TimerTask
』:);2.11.1
版本及其之前的版本没有缺省开启TimerTask
的修饰。 - 使用
Agent
参数ttl.agent.enable.timer.task
开启/关闭TimerTask
的修饰:-javaagent:path/to/transmittable-thread-local-2.x.y.jar=ttl.agent.enable.timer.task:true
-javaagent:path/to/transmittable-thread-local-2.x.y.jar=ttl.agent.enable.timer.task:false
- 更多关于
TTL Agent
参数的配置说明详见TtlAgent.java
的JavaDoc。
- 修饰实现代码在
关于
java.util.TimerTask
/java.util.Timer
的 展开说明
Timer
是JDK 1.3
的老类,不推荐使用Timer
类。推荐用
ScheduledExecutorService
。
ScheduledThreadPoolExecutor
实现更强壮,并且功能更丰富。 如支持配置线程池的大小(Timer
只有一个线程);Timer
在Runnable
中抛出异常会中止定时执行。更多说明参见 10. Mandatory Run multiple TimeTask by using ScheduledExecutorService rather than Timer because Timer will kill all running threads in case of failing to catch exceptions. - Alibaba Java Coding Guidelines。
在Java
的启动参数加上:-javaagent:path/to/transmittable-thread-local-2.x.y.jar
。
注意:
- 如果修改了下载的
TTL
的Jar
的文件名(transmittable-thread-local-2.x.y.jar
),则需要自己手动通过-Xbootclasspath JVM
参数来显式配置。
比如修改文件名成ttl-foo-name-changed.jar
,则还需要加上Java
的启动参数:-Xbootclasspath/a:path/to/ttl-foo-name-changed.jar
。 - 或使用
v2.6.0
之前的版本(如v2.5.1
),则也需要自己手动通过-Xbootclasspath JVM
参数来显式配置(就像TTL
之前的版本的做法一样)。
加上Java
的启动参数:-Xbootclasspath/a:path/to/transmittable-thread-local-2.5.1.jar
。
Java
命令行示例如下:
java -javaagent:path/to/transmittable-thread-local-2.x.y.jar \
-cp classes \
com.alibaba.demo.ttl.agent.AgentDemo
# 如果修改了TTL jar文件名 或 TTL版本是 2.6.0 之前
# 则还需要显式设置 -Xbootclasspath 参数
java -javaagent:path/to/ttl-foo-name-changed.jar \
-Xbootclasspath/a:path/to/ttl-foo-name-changed.jar \
-cp classes \
com.alibaba.demo.ttl.agent.AgentDemo
java -javaagent:path/to/transmittable-thread-local-2.5.1.jar \
-Xbootclasspath/a:path/to/transmittable-thread-local-2.5.1.jar \
-cp classes \
com.alibaba.demo.ttl.agent.AgentDemo
关于
boot class path
的 展开说明
因为修饰了
JDK
标准库的类,标准库由bootstrap class loader
加载;修饰后的JDK
类引用了TTL
的代码,所以Java Agent
使用方式下TTL Jar
文件需要配置到boot class path
上。
TTL
从v2.6.0
开始,加载TTL Agent
时会自动设置TTL Jar
到boot class path
上。
注意:不能修改从Maven
库下载的TTL Jar
文件名(形如transmittable-thread-local-2.x.y.jar
)。 如果修改了,则需要自己手动通过-Xbootclasspath JVM
参数来显式配置(就像TTL
之前的版本的做法一样)。自动设置
TTL Jar
到boot class path
的实现是通过指定TTL Java Agent Jar
文件里manifest
文件(META-INF/MANIFEST.MF
)的Boot-Class-Path
属性:
Boot-Class-Path
A list of paths to be searched by the bootstrap class loader. Paths represent directories or libraries (commonly referred to as JAR or zip libraries on many platforms). These paths are searched by the bootstrap class loader after the platform specific mechanisms of locating a class have failed. Paths are searched in the order listed.
更多详见
当前版本的Java API文档地址: https://alibaba.github.io/transmittable-thread-local/apidocs/
示例:
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>transmittable-thread-local</artifactId>
<version>2.14.2</version>
</dependency>
可以在 search.maven.org 查看可用的版本。
编译构建的环境要求: JDK 8+
;用Maven
常规的方式执行编译构建即可:
# 在工程中已经包含了符合版本要求的Maven
,直接运行 工程根目录下的mvnw
;并不需要先手动自己安装好Maven
。
# 运行测试Case
./mvnw test
# 编译打包
./mvnw package
# 运行测试Case、编译打包、安装TTL库到Maven本地
./mvnw install
#####################################################
# 如果使用你自己安装的 maven,版本要求:maven 3.3.9+
mvn install
Q1. TTL Agent
与其它Agent
(如Skywalking
、Promethues
)配合使用时不生效?
配置TTL Agent
在最前的位置,可以避免与其它其它Agent
配合使用时,TTL Agent
可能的不生效问题。配置示例:
java -javaagent:path/to/transmittable-thread-local-2.x.y.jar \
-javaagent:path/to/skywalking-agent.jar \
-jar your-app.jar
原因是:
- 像
Skywalking
这样的Agent
的入口逻辑(premain
)包含了线程池的启动。 - 如果配置在这样的
Agent
配置在前面,到了TTL Agent
(的premain
)时,TTL
需要加强的线程池类已经加载(load
)了。 TTL Agent
的TtlTransformer
是在类加载时触发类的增强;如果类已经加载了会跳过TTL Agent
的增强逻辑。
更多讨论参见 Issue:TTL agent
与其他Agent
的兼容性问题 #226。
Q2. MacOS
下,使用Java Agent
,可能会报JavaLaunchHelper
的出错信息
JDK Bug: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021205
可以换一个版本的JDK
。我的开发机上1.7.0_40
有这个问题,1.6.0_51
、1.7.0_45
可以运行。
# 1.7.0_45
还是有JavaLaunchHelper
的出错信息,但不影响运行。
注:不读这一节,并不会影响你使用
TTL
来解决你碰到的问题,可以放心跳过;读了 User Guide 就可以快速用起来了~ 😄 这一节信息密度较高不易读。
好处:透明且自动完成所有异步执行上下文的可定制、规范化的捕捉与传递。
这个好处也是TransmittableThreadLocal
的目标。
必要性:随着应用的分布式微服务化并使用各种中间件,越来越多的功能与组件会涉及不同的上下文,逻辑流程也越来越长;上下文问题实际上是个大的易错的架构问题,需要统一的对业务透明的解决方案。
使用ThreadLocal
作为业务上下文传递的经典技术手段在中间件、技术与业务框架中广泛大量使用。而对于生产应用,几乎一定会使用线程池等异步执行组件,以高效支撑线上大流量。但使用ThreadLocal
及其set/remove
的上下文传递模式,在使用线程池等异步执行组件时,存在多方面的问题:
1. 从业务使用者角度来看
- 繁琐
- 业务逻辑要知道:有哪些上下文;各个上下文是如何获取的。
- 并需要业务逻辑去一个一个地捕捉与传递。
- 依赖
- 需要直接依赖不同
ThreadLocal
上下文各自的获取的逻辑或类。 - 像
RPC
的上下文(如Dubbo
的RpcContext
)、全链路跟踪的上下文(如SkyWalking
的ContextManager
)、不同业务模块中的业务流程上下文,等等。
- 需要直接依赖不同
- 静态(易漏)
- 因为要 事先 知道有哪些上下文,如果系统出现了一个新的上下文,业务逻辑就要修改添加上新上下文传递的几行代码。也就是说因 系统的 上下文新增,业务的 逻辑就跟进要修改。
- 而对于业务来说,不关心系统的上下文,即往往就可能遗漏,会是线上故障了。
- 随着应用的分布式微服务化并使用各种中间件,越来越多的功能与组件会涉及不同的上下文,逻辑流程也越来越长;上下文问题实际上是个大的易错的架构问题,需要统一的对业务透明的解决方案。
- 定制性
- 因为需要业务逻辑来完成捕捉与传递,业务要关注『上下文的传递方式』:直接传引用?还是拷贝传值?拷贝是深拷贝还是浅拷贝?在不同的上下文会需要不同的做法。
- 『上下文的传递方式』往往是 上下文的提供者(或说是业务逻辑的框架部分)才能决策处理好的;而 上下文的使用者(或说是业务逻辑的应用部分)往往不(期望)知道上下文的传递方式。这也可以理解成是 依赖,即业务逻辑 依赖/关注/实现了 系统/架构的『上下文的传递方式』。
2. 从整体流程实现角度来看
关注的是 上下文传递流程的规范化。上下文传递到了子线程要做好 清理(或更准确地说是要 恢复 成之前的上下文),需要业务逻辑去处理好。如果业务逻辑对清理的处理不正确,比如:
- 如果清理操作漏了:
- 下一次执行可能是上次的,即『上下文的 污染/串号』,会导致业务逻辑错误。
- 『上下文的 泄漏』,会导致内存泄漏问题。
- 如果清理操作做多了,会出现上下文 丢失。
上面的问题,在业务开发中引发的Bug
真是屡见不鲜 !本质原因是:ThreadLocal
的set/remove
的上下文传递模式 在使用线程池等异步执行组件的情况下不再是有效的。常见的典型例子:
- 当线程池满了且线程池的
RejectedExecutionHandler
使用的是CallerRunsPolicy
时,提交到线程池的任务会在提交线程中直接执行,ThreadLocal.remove
操作清理提交线程的上下文导致上下文丢失。 - 类似的,使用
ForkJoinPool
(包含并行执行Stream
与CompletableFuture
,底层使用ForkJoinPool
)的场景,展开的ForkJoinTask
会在任务提交线程中直接执行。同样导致上下文丢失。
怎么设计一个『上下文传递流程』方案(即上下文的生命周期),以保证没有上面的问题?
期望:上下文生命周期的操作从业务逻辑中分离出来。业务逻辑不涉及生命周期,就不会有业务代码如疏忽清理而引发的问题了。整个上下文的传递流程或说生命周期可以规范化成:捕捉、回放和恢复这3个操作,即CRR(capture/replay/restore)
模式。更多讨论参见 Issue:能在详细讲解一下replay
、restore
的设计理念吗?#201。
总结上面的说明:在生产应用(几乎一定会使用线程池等异步执行组件)中,使用ThreadLocal
及其set/remove
的上下文传递模式几乎一定是有问题的,只是在等一个出Bug
的机会。
更多TTL
好处与必要性的展开讨论参见 Issue:这个库带来怎样的好处和优势? #128,欢迎继续讨论
使用了TTL
的一部分开源项目:
- 中间件
sofastack/sofa-rpc
SOFARPC is a high-performance, high-extensibility, production-level Java RPC frameworkdromara/hmily
Distributed transaction solutionsdromara/gobrs-async
一款功能强大、配置灵活、带有全链路异常回调、内存优化、异常状态管理于一身的高性能异步编排框架。为企业提供在复杂应用场景下动态任务编排的能力。 针对于复杂场景下,异步线程复杂性、任务依赖性、异常状态难控制性dromara/dynamic-tp
轻量级动态线程池,内置监控告警功能,支持线程池上下文传递,基于主流配置中心(已支持Nacos、Apollo,Zookeeper,可通过SPI自定义实现)opengoofy/hippo4j
动态线程池框架,附带监控报警功能,支持 JDK、Tomcat、Jetty、Undertow 线程池;Apache RocketMQ、Dubbo、RabbitMQ、Hystrix 消费等线程池。内置两种使用模式:轻量级依赖配置中心以及无中间件依赖版本siaorg/sia-gateway
微服务路由网关(zuul-plus)huaweicloud/Sermant
Sermant, a proxyless service mesh solution based on JavaagentZTO-Express/zms
ZTO Message Servicelxchinesszz/tomato
一款专门为SpringBoot项目设计的幂等组件ytyht226/taskflow
一款轻量、简单易用、可灵活扩展的通用任务编排框架,基于有向无环图(DAG)的方式实现,框架提供了组件复用、同步/异步编排、条件判断、分支选择等能力,可以根据不同的业务场景对任意的业务流程进行编排foldright/cffu
🦝 Java CompletableFuture Fu, aka. CF-Fu, pronounced "Shifu"; include best practice/traps guide and a tiny sidekick library to improve user experience and reduce misuse.tuya/connector
The connector framework maps cloud APIs to local APIs based on simple configurations and flexible extension mechanisms
- 中间件/数据处理
apache/shardingsphere
Ecosystem to transform any database into a distributed database system, and enhance it with sharding, elastic scaling, encryption features & morebasicai/xtreme1
The Next GEN Platform for Multisensory Training Data. #3D annotation, lidar-camera annotation and image annotation tools are supportedsagframe/sagacity-sqltoy
Java真正智慧的ORM框架dromara/stream-query
允许完全摆脱Mapper的mybatis-plus体验;可以使用类似“工具类”这样的静态函数进行数据库操作SimonAlong/Neo
Orm框架:基于ActiveRecord思想开发的至简化且功能很全的Orm框架ppdaicorp/das
数据库访问框架(data access service),包括数据库控制台das console,数据库客户端das client和数据库服务端das server三部分didi/ALITA
a layer-based data analysis tooldidi/daedalus
实现快速创建数据构造流程,数据构造流程的可视化、线上化、持久化、标准化
- 中间件/流程引擎
dromara/liteflow
a lightweight and practical micro-process frameworkalibaba/bulbasaur
A pluggable, scalable process engine
- 中间件/日志
dromara/TLog
Lightweight distributed log label tracking frameworkfayechenlong/plumelog
一个java分布式日志组件,支持百亿级别minbox-projects/minbox-logging
分布式零侵入式、链路式请求日志分析框架。提供Admin端点进行采集日志、分析日志、日志告警通知、服务性能分析等。通过Admin Ui可查看实时链路日志信息、在线业务服务列表minbox-projects/api-boot
为接口服务而生的,基于“ SpringBoot”完成扩展和自动配置,内部封装了一系列的开箱即用Starters
ofpay/logback-mdc-ttl
logback扩展,集成transmittable-thread-local支持跨线程池的mdc跟踪oldratlee/log4j2-ttl-thread-context-map
Log4j2 TTL ThreadContextMap, Log4j2 extension integrated TransmittableThreadLocal to MDC
- 中间件/字节码
ymm-tech/easy-byte-coder
Easy-byte-coder is a non-invasive bytecode injection framework based on JVM
- 业务服务或平台应用
OpenBankProject/OBP-API
An open source RESTful API platform for banks that supports Open Banking, XS2A and PSD2 through access to accounts, transactions, counterparties, payments, entitlements and metadata - plus a host of internal banking and management APIsgz-yami/mall4j
电商商城 java电商商城系统 uniapp商城 多用户商城Joolun/JooLun-wx
JooLun微信商城HummerRisk/HummerRisk
云原生安全平台,包括混合云安全治理和容器云安全检测XiaoMi/mone
Mone
以微服务为核心的一站式企业协同研发平台。支持公共云、专有云和混合云多种部署形态;提供从“项目创建->开发->部署->治理->应用观测”端到端的研发全流程服务;通过云原生新技术和研发新模式,打造“双敏”,敏捷研发和敏捷组织,保障小米-中国区高复杂业务、大规模团队的敏捷研发协同,实现多倍效能提升。yangzongzhuan/RuoYi-Cloud
基于Spring Boot、Spring Cloud & Alibaba的分布式微服务架构权限管理系统somowhere/albedo
基于 Spring Boot 、Spring Security、Mybatis 的RBAC权限管理系统qwdigital/LinkWechat
基于企业微信的开源 SCRM 系统,采用主流的 Java 微服务架构,是企业私域流量管理与营销的综合解决方案,助力企业提高客户运营效率,强化营销能力,拓展盈利空间hiparker/opsli-boot
一款的低代码快速平台,零代码开发,致力于做更简洁的后台管理系统topiam/eiam
EIAM(Employee Identity and Access Management Program)企业级开源IAM平台,实现用户全生命周期的管理、统一认证和单点登录、为数字身份安全赋能Newspiral/newspiral-business
联盟区块链底层平台
- 工具产品
ssssssss-team/spider-flow
新一代爬虫平台,以图形化方式定义爬虫流程,不写代码即可完成爬虫nekolr/slime
🍰 一个可视化的爬虫平台Jackson0714/PassJava-Platform
一款面试刷题的 Spring Cloud 开源系统。零碎时间利用小程序查看常见面试题,夯实Java基础。 该项目可以教会你如何搭建SpringBoot项目,Spring Cloud项目。 采用流行的技术,如 SpringBoot、MyBatis、Redis、 MySql、 MongoDB、 RabbitMQ、Elasticsearch,采用Docker容器化部署martin-chips/DimpleBlog
基于SpringBoot2
搭建的个人博客系统zjcscut/octopus
长链接压缩为短链接的服务xggz/mqr
茉莉QQ机器人(简称MQR),采用mirai的Android协议实现的QQ机器人服务,通过web控制机器人的启停和配置
- 测试解决方案或工具
alibaba/jvm-sandbox-repeater
A Java server-side recording and playback solution based on JVM-Sandbox, 录制/回放通用解决方案vivo/MoonBox
Moonbox(月光宝盒)是JVM-Sandbox生态下的,基于jvm-sandbox-repeater重新开发的,一款流量回放平台产品。相较于jvm-sandbox-repeater,Moonbox功能更加丰富、数据可靠性更高,同时便于快速线上部署和使用alibaba/testable-mock
换种思路写Mock,让单元测试更简单shulieTech/Takin
全链路压测平台,measure online environmental performance test for full-links, Especially for microservicesshulieTech/LinkAgent
a Java-based open-source agent designed to collect data and control Functions for Java applications through JVM bytecode, without modifying applications codes
alibaba/virtual-environment
Route isolation with service sharing, 阿里测试环境服务隔离和联调机制的Kubernetes
版实现
Spring Cloud
/Spring Boot
的框架方案/脚手架YunaiV/ruoyi-vue-pro
一套全部开源的企业级的快速开发平台。基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 微信小程序,支持 RBAC 动态权限、数据权限、SaaS 多租户、Activiti + Flowable 工作流、三方登录、支付、短信、商城等功能YunaiV/yudao-cloud
RuoYi-Vue 全新 Cloud 版本,优化重构所有功能。基于 Spring Cloud Alibaba + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能zlt2000/microservices-platform
基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离的企业级微服务多租户系统架构dromara/lamp-cloud
基于Jdk11 + SpringCloud + SpringBoot 的微服务快速开发平台,其中的可配置的SaaS功能尤其闪耀, 具备RBAC功能、网关统一鉴权、Xss防跨站攻击、自动代码生成、多种存储系统、分布式事务、分布式定时任务等多个模块,支持多业务系统并行开发, 支持多服务并行开发,可以作为后端服务的开发脚手架zuihou/lamp-util
打造一套兼顾 SpringBoot 和 SpringCloud 项目的公共工具类
matevip/matecloud
一款基于Spring Cloud Alibaba的微服务架构gavenwangcn/vole
SpringCloud 微服务业务脚手架liuweijw/fw-cloud-framework
基于springcloud全家桶开发分布式框架(支持oauth2认证授权、SSO登录、统一下单、微信公众号服务、Shardingdbc分库分表、常见服务监控、链路监控、异步日志、redis缓存等功能),实现基于Vue全家桶等前后端分离项目工程liuht777/Taroco
整合Nacos、Spring Cloud Alibaba,提供了一系列starter组件, 同时提供服务治理、服务监控、OAuth2权限认证,支持服务降级/熔断、服务权重mingyang66/spring-parent
数据库多数据源、Redis多数据源、日志组件、全链路日志追踪、埋点扩展点、Netty、微服务、开发基础框架支持、异常统一处理、返回值、跨域、API路由、监控等budwk/budwk
BudWk
原名NutzWk
,基于国产框架 nutz 及 nutzboot 开发的开源Web基础项目,集权限体系、系统参数、数据字典、站内消息、定时任务、CMS、微信等最常用功能,不庞杂、不面面俱到,使其具有上手容易、开发便捷、扩展灵活等特性,特别适合各类大中小型定制化项目需求
yinjihuan/spring-cloud
《Spring Cloud微服务-全栈技术与案例解析》和《Spring Cloud微服务 入门 实战与进阶》配套源码louyanfeng25/ddd-demo
《深入浅出DDD》讲解的演示项目,为了能够更好的理解Demo中的分层与逻辑处理,我强烈建议你配合小册来深入了解DDD
- Jerry Lee <oldratlee at gmail dot com> @oldratlee
- Yang Fang <snoop.fy at gmail dot com> @driventokill
- Zava Xu <zava.kid at gmail dot com> @zavakid
- wuwen <wuwen.55 at aliyun dot com> @wuwen5
- rybalkinsd <yan.brikl at gmail dot com> @rybalkinsd
- David Dai <351450944 at qq dot com> @LNAmp
- Your name here :-)