Spring Cloud基于TCC补偿模式实现分布式事物
Try Confirm Cancel补偿模式
本实例遵循的是Atomikos公司对微服务的分布式事务所提出的RESTful TCC解决方案
RESTful TCC模式分3个阶段执行
Trying阶段主要针对业务系统检测及作出预留资源请求, 若预留资源成功, 则返回确认资源的链接与过期时间
Confirm阶段主要是对业务系统的预留资源作出确认, 要求TCC服务的提供方要对确认预留资源的接口实现幂等性, 若Confirm成功则返回204, 资源超时则证明已经被回收且返回404
Cancel阶段主要是在业务执行错误或者预留资源超时后执行的资源释放操作, Cancel接口是一个可选操作, 因为要求TCC服务的提供方实现自动回收的功能, 所以即便是不认为进行Cancel, 系统也会自动回收资源。
系统结构
基础组件
Zuul Gateway
Zuul在本实例中仅作为路由所使用, 配置降低Ribbon的读取与连接超时上限
Eureka H.A.
多个对等Eureka节点组成高可用集群, 并将注册列表的自我保护的阈值适当降低
Config Server
如果远程配置中有密文{cipher}*, 那么该密文的解密将会延迟至客户端启动的时候. 因此客户端需要配置AES的对称密钥encrypt.key, 并且客户端所使用的JRE需要安装Java 8 JCE, 否则将会抛出Illegal key size相关的异常.
(本例中Docker Compose构建的容器已经安装了JCE, 如果远程配置文件没有使用{cipher}*也不必进行JCE的安装)
spring:
cloud:
config:
server:
git:
uri: 'https://git.oschina.net/witless/conf-repo.git'
clone-on-start: true
encrypt:
enabled: false
application:
name: 'config-server'
为了达到开箱即用, 选用公开仓库Github或者GitOsc
本项目中有两个自定义注解
@com.github.prontera.Delay 控制方法的延时返回时间
@com.github.prontera.RandomlyThrowsException 随机抛出异常, 人为地制造异常
默认的远程配置如下
solar:
delay:
time-in-millseconds: 0
exception:
enabled: false
factor: 7
这些自定义配置正是控制方法返回的时延, 随机异常的因子等
我在服务order, product, account和tcc中的所有Controller上都添加了以上两个注解, 当远程配置的更新时候, 可以手工刷新/refresh或通过webhook等方法自动刷新本地配置. 以达到模拟微服务繁忙或熔断等情况.
总结
以 上就是我对Java大型互联网架构-Spring Cloud基于TCC补偿模式实现分布式事物 问题及其优化总结,分享给大家,觉得收获的话可以点个关注收藏转发一波喔,谢谢大佬们支持!
最后,每一位读到这里的网友,感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上,我们可以一起学习、一起进步!都能赢取白富美,走向架构师的人生巅峰!
想了解学习Java方面的技术内容以及Java技术视频的内容可加群:722040762 验证码:头条(06 必过)欢迎大家的加入哟!