一切福田,不離方寸,從心而覓,感無不通。

Category Archives: Architecture

soul极简入门

目录: 1. 概述 2. 单机部署 3. 接入 Dubbo 应用 4. 接入 Spring Boot 应用 5. 接入 Spring Cloud 应用 6. rateLimiter 插件 7. hystrix 插件 666. 彩蛋 作者:芋道源码 原文地址 大家好,我是艿艿,一个永远 18 岁的技术宅 1. 概述 Soul 是基于 WebFlux 实现的响应式的 API 网关,具有异步、高性能、跨语言等特点。 作者:我希望能够有一样东西像灵魂一样,保护您的微服务。在参考了 Kong、Spring Cloud Gateway 等优秀的网关后,站在巨人的肩膀上,Soul 由此诞生! 作者是艿艿的大表弟,胖友信么?! 目前 Soul 功能列表如下: 支持各种语言,无缝集成到 Dubbo、Spring Cloud、Spring Boot 中。 Soul 是极其少支持 Dubbo 的 API 网关,通过 Dubbo 泛化调用 实现。 支持各种语言(http协议),支持 dubbo,springcloud协议。 插件化设计思想,插件热插拔,易扩展。 灵活的流量筛选,能满足各种流量控制。 内置丰富的插件支持,鉴权,限流,熔断,防火墙等等。 流量配置动态化,性能极高,网关消耗在 1~2ms。 支持集群部署,支持 A/B Test, 蓝绿发布。 整体架构如下图所示: 是不是看着就贼酷炫,实际一脸懵逼。不要慌~我们先来搭建 Soul 网关。 2. 单机部署 本小节,我们来单机部署一个 Soul 服务,适合测试环境。如下图所示: 2.1 MySQL 安装 相信大家都会,艿艿就不瞎哔哔了。嘿嘿~注意,目前最好安装 5.X 版本,艿艿一开始用 8.X 存在报错的情况。 安装完成后,创建 soul 数据库。 2.2 Soul Admin […]

龙生   22 Sep 2020
View Details

TCC和两阶段提交

经常在网络上看见有人介绍TCC时,都提一句,”TCC是两阶段提交的一种”。其理由是TCC将业务逻辑分成try、confirm/cancel在两个不同的阶段中执行。其实这个说法,是不正确的。可能是因为既不太了解两阶段提交机制、也不太了解TCC机制的缘故,于是将两阶段提交机制的prepare、commit两个事务提交阶段和TCC机制的try、confirm/cancel两个业务执行阶段互相混淆,才有了这种说法。 两阶段提交(Two Phase Commit,下文简称2PC),简单的说,是将事务的提交操作分成了prepare、commit两个阶段。其事务处理方式为: 1、 在全局事务决定提交时,a)逐个向RM发送prepare请求;b)若所有RM都返回OK,则逐个发送commit请求最终提交事务;否则,逐个发送rollback请求来回滚事务; 2、 在全局事务决定回滚时,直接逐个发送rollback请求即可,不必分阶段。 * 需要注意的是:2PC机制需要RM提供底层支持(一般是兼容XA),而TCC机制则不需要。 TCC(Try-Confirm-Cancel),则是将业务逻辑分成try、confirm/cancel两个阶段执行,具体介绍见TCC事务机制简介。其事务处理方式为: 1、 在全局事务决定提交时,调用与try业务逻辑相对应的confirm业务逻辑; 2、 在全局事务决定回滚时,调用与try业务逻辑相对应的cancel业务逻辑。 可见,TCC在事务处理方式上,是很简单的:要么调用confirm业务逻辑,要么调用cancel逻辑。这里为什么没有提到try业务逻辑呢?因为try逻辑与全局事务处理无关。 当讨论2PC时,我们只专注于事务处理阶段,因而只讨论prepare和commit,所以,可能很多人都忘了,使用2PC事务管理机制时也是有业务逻辑阶段的。正是因为业务逻辑的执行,发起了全局事务,这才有其后的事务处理阶段。实际上,使用2PC机制时————以提交为例————一个完整的事务生命周期是:begin -> 业务逻辑 -> prepare -> commit。 再看TCC,也不外乎如此。我们要发起全局事务,同样也必须通过执行一段业务逻辑来实现。该业务逻辑一来通过执行触发TCC全局事务的创建;二来也需要执行部分数据写操作;此外,还要通过执行来向TCC全局事务注册自己,以便后续TCC全局事务commit/rollback时回调其相应的confirm/cancel业务逻辑。所以,使用TCC机制时————以提交为例————一个完整的事务生命周期是:begin -> 业务逻辑(try业务) -> commit(comfirm业务)。 综上,我们可以从执行的阶段上将二者一一对应起来: 1、 2PC机制的业务阶段 等价于 TCC机制的try业务阶段; 2、 2PC机制的提交阶段(prepare & commit) 等价于 TCC机制的提交阶段(confirm); 3、 2PC机制的回滚阶段(rollback) 等价于 TCC机制的回滚阶段(cancel)。 因此,可以看出,虽然TCC机制中有两个阶段都存在业务逻辑的执行,但其中try业务阶段其实是与全局事务处理无关的。认清了这一点,当我们再比较TCC和2PC时,就会很容易地发现,TCC不是两阶段提交,而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现,仅此而已。     参考博客: 1. https://blog.csdn.net/Paranoia_ZK/article/details/79481976#commentsedit  TCC和两阶段分布式事务处理的区别 2. https://blog.csdn.net/Saintyyu/article/details/100822735 X/Open DTP模型与XA协议之我见 3、https://blog.csdn.net/Saintyyu/article/details/101054542 分布式事务的七种实现方案汇总分析   from:https://blog.csdn.net/Saintyyu/article/details/100862449

龙生   22 Sep 2020
View Details

终于有人把“TCC分布式事务”实现原理讲明白了!

之前网上看到很多写分布式事务的文章,不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事,在项目里到底如何使用。 所以这篇文章,就用大白话+手工绘图,并结合一个电商系统的案例实践,来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下,这里可能会牵扯到一些 Spring Cloud 的原理,如果有不太清楚的同学,可以参考之前的文章:《拜托,面试请不要再问我Spring Cloud底层原理!》。 业务场景介绍 咱们先来看看业务场景,假设你现在有一个电商系统,里面有一个支付订单的场景。 那对一个订单支付之后,我们需要做下面的步骤: 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤,无论大家有没有做过电商系统,应该都能理解。 进一步思考 好,业务场景有了,现在我们要更进一步,实现一个 TCC 分布式事务的效果。 什么意思呢?也就是说,[1] 订单服务-修改订单状态,[2] 库存服务-扣减库存,[3] 积分服务-增加积分,[4] 仓储服务-创建销售出库单。 上述这几个步骤,要么一起成功,要么一起失败,必须是一个整体性的事务。 举个例子,现在订单的状态都修改为“已支付”了,结果库存服务扣减库存失败。那个商品的库存原来是 100 件,现在卖掉了 2 件,本来应该是 98 件了。 结果呢?由于库存服务操作数据库异常,导致库存数量还是 100。这不是在坑人么,当然不能允许这种情况发生了! 但是如果你不用 TCC 分布式事务方案的话,就用个 Spring Cloud 开发这么一个微服务系统,很有可能会干出这种事儿来。 我们来看看下面的这个图,直观的表达了上述的过程: 所以说,我们有必要使用 TCC 分布式事务机制来保证各个服务形成一个整体性的事务。 上面那几个步骤,要么全部成功,如果任何一个服务的操作失败了,就全部一起回滚,撤销已经完成的操作。 比如说库存服务要是扣减库存失败了,那么订单服务就得撤销那个修改订单状态的操作,然后得停止执行增加积分和通知出库两个操作。 说了那么多,老规矩,给大家上一张图,大伙儿顺着图来直观的感受一下: 落地实现 TCC 分布式事务 那么现在到底要如何来实现一个 TCC 分布式事务,使得各个服务,要么一起成功?要么一起失败呢? 大家稍安勿躁,我们这就来一步一步的分析一下。咱们就以一个 Spring Cloud 开发系统作为背景来解释。 TCC 实现阶段一:Try 首先,订单服务那儿,它的代码大致来说应该是这样子的:

如果你之前看过 Spring Cloud 架构原理那篇文章,同时对 Spring Cloud 有一定的了解的话,应该是可以理解上面那段代码的。 其实就是订单服务完成本地数据库操作之后,通过 Spring Cloud 的 Feign 来调用其他的各个服务罢了。 但是光是凭借这段代码,是不足以实现 TCC 分布式事务的啊?!兄弟们,别着急,我们对这个订单服务修改点儿代码好不好。 首先,上面那个订单服务先把自己的状态修改为:OrderStatus.UPDATING。 这是啥意思呢?也就是说,在 pay() 那个方法里,你别直接把订单状态修改为已支付啊!你先把订单状态修改为 UPDATING,也就是修改中的意思。 这个状态是个没有任何含义的这么一个状态,代表有人正在修改这个状态罢了。 然后呢,库存服务直接提供的那个 reduceStock() 接口里,也别直接扣减库存啊,你可以是冻结掉库存。 […]

龙生   22 Sep 2020
View Details