1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。
View Details目录： 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 […]
View Details经常在网络上看见有人介绍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
View Details之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章：《拜托，面试请不要再问我Spring Cloud底层原理！》。 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring Cloud 开发这么一个微服务系统，很有可能会干出这种事儿来。 我们来看看下面的这个图，直观的表达了上述的过程： 所以说，我们有必要使用 TCC 分布式事务机制来保证各个服务形成一个整体性的事务。 上面那几个步骤，要么全部成功，如果任何一个服务的操作失败了，就全部一起回滚，撤销已经完成的操作。 比如说库存服务要是扣减库存失败了，那么订单服务就得撤销那个修改订单状态的操作，然后得停止执行增加积分和通知出库两个操作。 说了那么多，老规矩，给大家上一张图，大伙儿顺着图来直观的感受一下： 落地实现 TCC 分布式事务 那么现在到底要如何来实现一个 TCC 分布式事务，使得各个服务，要么一起成功？要么一起失败呢？ 大家稍安勿躁，我们这就来一步一步的分析一下。咱们就以一个 Spring Cloud 开发系统作为背景来解释。 TCC 实现阶段一：Try 首先，订单服务那儿，它的代码大致来说应该是这样子的：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
<span class="hljs-keyword">public</span> <span class="hljs-class"><span class="hljs-keyword">class</span> <span class="hljs-title">OrderService</span> </span>{ <span class="hljs-comment">// 库存服务</span> <span class="hljs-meta">@Autowired</span> <span class="hljs-keyword">private</span> InventoryService inventoryService; <span class="hljs-comment">// 积分服务</span> <span class="hljs-meta">@Autowired</span> <span class="hljs-keyword">private</span> CreditService creditService; <span class="hljs-comment">// 仓储服务</span> <span class="hljs-meta">@Autowired</span> <span class="hljs-keyword">private</span> WmsService wmsService; <span class="hljs-comment">// 对这个订单完成支付</span> <span class="hljs-function"><span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title">pay</span><span class="hljs-params">()</span></span>{ <span class="hljs-comment">//对本地的的订单数据库修改订单状态为"已支付"</span> orderDAO.updateStatus(OrderStatus.PAYED); <span class="hljs-comment">//调用库存服务扣减库存</span> inventoryService.reduceStock(); <span class="hljs-comment">//调用积分服务增加积分</span> creditService.addCredit(); <span class="hljs-comment">//调用仓储服务通知发货</span> wmsService.saleDelivery(); } } |
如果你之前看过 Spring Cloud 架构原理那篇文章，同时对 Spring Cloud 有一定的了解的话，应该是可以理解上面那段代码的。 其实就是订单服务完成本地数据库操作之后，通过 Spring Cloud 的 Feign 来调用其他的各个服务罢了。 但是光是凭借这段代码，是不足以实现 TCC 分布式事务的啊？！兄弟们，别着急，我们对这个订单服务修改点儿代码好不好。 首先，上面那个订单服务先把自己的状态修改为：OrderStatus.UPDATING。 这是啥意思呢？也就是说，在 pay() 那个方法里，你别直接把订单状态修改为已支付啊！你先把订单状态修改为 UPDATING，也就是修改中的意思。 这个状态是个没有任何含义的这么一个状态，代表有人正在修改这个状态罢了。 然后呢，库存服务直接提供的那个 reduceStock() 接口里，也别直接扣减库存啊，你可以是冻结掉库存。 […]
View Details