目录： 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 Detailsif ($server_port !~ 443){ rewrite ^(/.*)$ https://$host$1 permanent; }
View Details打开AS时出现了Unsupported Modules Detected: Compilation is not supported for following modules: app, KeyboardView. Unfortunately you can’t have non-Gradle Java modules and Android-Gradle modules in one project的错误，解决步骤如下： （1）关闭as （2）删除.idea目录 （3）删除app/build目录 （4）重新打开as from:https://blog.csdn.net/qq_40600379/article/details/106485687
View Detailsnetstat netstat -tunlp 用于显示 tcp，udp 的端口和进程等相关情况。 netstat 查看端口占用语法格式：
|
1 |
netstat -tunlp | grep 端口号 |
-t (tcp) 仅显示tcp相关选项 -u (udp)仅显示udp相关选项 -n 拒绝显示别名，能显示数字的全部转化为数字 -l 仅列出在Listen(监听)的服务状态 -p 显示建立相关链接的程序名 例如查看 8000 端口的情况，使用以下命令：
|
1 2 |
# netstat -tunlp | grep 8000 tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 26993/nodejs |
更多命令：
|
1 2 3 |
netstat -ntlp //查看当前所有tcp端口 netstat -ntulp | grep 80 //查看所有80端口使用情况 netstat -ntulp | grep 3306 //查看所有3306端口使用情况 |
from:https://www.cnblogs.com/music-liang/p/11912928.html
View Details忙了一早晨,就是因为这个错误提示!!!!No cached version of com.android.tools.build:gradle:3.6.2 available for offlin 先说我的android studio 版本号:3.6.2 在之前的版本当中Settings->Builder….bababa… >gradel> offline work有这么个选项,但是在最新的版本当中是没有这个选项的!!!我找了一早晨!! 好了废话不多说,正题,位置在哪里?在这里!!! 默认的状态是: 你只要取消选中就是offline work不启动,也就是离线模式不不启用!!如果在截图当中没有这个,那么这个界面就在view->window tool->gradle,只要你选择了就会在右则弹出来这个选项 from:https://www.cnblogs.com/flay/p/12641381.html
View Details前天电脑重装了系统，所有东西重新配置，打开项目编译后发现：Could not resolve all artifacts for configuration ':classpath'；这是什么鬼，然后常规clean、rebuild、offline work、修改本地gradle…一番操作之后，依然没用。最后上google寻求帮助，成功解决了这个问题。真凶尚不明确，怀疑是网络问题，资源库加载不下来。 解决办法如下：在根目录的build文件里加上这两句镜像代码，重新编译解决
|
1 |
maven{url 'http://maven.aliyun.com/nexus/content/groups/public/'} |
from:https://blog.csdn.net/c18871189293/article/details/105681103
View Details在 Android Studio 上新建项目，出现 Unable to start the daemon process. 错误,具体错误信息如下： Error:Unable to start the daemon process. This problem might be caused by incorrect configuration of the daemon. For example, an unrecognized jvm option is used. Please refer to the user guide chapter on the daemon at https://docs.gradle.org/3.3/userguide/gradle_daemon.html Please read the following process output to find out more: ———————-- OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 解决方法 方法一：删除 C:\Users\UserName\.gradle 目录，重新启动 Android Studio即可。重启动后，它会自动为你创建一个新的。 方法二：修改配置。File -> Settings. 选择左边导航栏的Compiler项，设置 VM Options 为 -Xmx512m即可。 方法三：其它应该，留出更多的内存空间试试。 from:https://blog.csdn.net/cto_1649900265/article/details/79419275
View Details|
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 31 32 33 34 35 |
DELIMITER // CREATE DEFINER=`root`@`localhost` PROCEDURE `p_Uppercase`(IN `dbname` varchar(200)) BEGIN DECLARE done INT DEFAULT 0; DECLARE oldname VARCHAR(200); DECLARE cur CURSOR FOR SELECT table_name FROM information_schema.TABLES WHERE table_schema = dbname; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; OPEN cur; REPEAT FETCH cur INTO oldname; SET @newname = UPPER(oldname); SET @isNotSame = @newname <> BINARY oldname; IF NOT done && @isNotSame THEN SET @SQL = CONCAT('rename table `',oldname,'` to `', LOWER(@newname), '_tmp` '); PREPARE tmpstmt FROM @SQL; EXECUTE tmpstmt; SET @SQL = CONCAT('rename table `',LOWER(@newname),'_tmp` to `',@newname, '`'); PREPARE tmpstmt FROM @SQL; EXECUTE tmpstmt; DEALLOCATE PREPARE tmpstmt; END IF; UNTIL done END REPEAT; CLOSE cur; END// DELIMITER ; |
View Details