Dubbo 2.7.1 踩坑记 Dubbo 2.7 版本增加新特性，新系统开始使用 Dubbo 2.7.1 尝鲜新功能。使用过程中不慎踩到这个版本的 Bug。 系统架构 Spring Boot 2.14-Release + Dubbo 2.7.1 现象 Dubbo 服务者启动成功，正常提供服务，消费者调用偶现失败的情况。错误如下图: 可以看出，主要原因为 cause: message can not send, because channel is closed。 但是检查提供者，却发现服务进程正常。 登陆 Dubbo admin 查看提供者服务，发现这个服务存在两个节点。 192.168.164.77 为测试服务器的 ip，提供者位于这台机器，而另一个 10.20.80.67 却是本地电脑的 IP，但是此时本地并未运行这个服务。 再次查看服务报错的原因，可以看到提供者调用l本地提供 RPC 的服务。由于本地服务已停止，导致调用失败。 这个问题在之前版本从未碰到，刚开始隐约记得 Dubbo 服务提供者注册使用 ZooKeeper 临时节点，服务断开，会删除该节点。 问题原因 在 D....
有更新！

Dubbo 2.7.1 踩坑记

支付系统一般需要对接多个支付渠道，一是为了保证系统的可靠性，不能因为单一渠道的问题影响整个支付系统。二是为了提高支付能力，不同渠道提供支付能力不同。三是为了降低支付成本。 对接多个支付渠道以后，为了可以正确选择支付渠道支付，因此设计渠道路由系统。 从上图可以看到路由系统功能其实很简单，分发支付请求到正确的渠道。但就是这个简单系统，也经过几次系统改造升级，最终才成为现在的样子。下面就来说说这个系统是如何演进。 下面假设对接支付渠道为支付宝与微信。 初期 支付系统初期，这个阶段业务需求较简单，仅仅需要满足一个支付场景（例如使用支付宝支付）。为了快速上线，设计方案就简单粗暴，对外直接暴露支付服务接口，由业务系统发起直接调用。 系统设计图如下： 这个阶段由于只有一个支付渠道，所以也不需要有路由系统，直接由业务系统调用支付服务接口发起支付。 这个设计方案存在很多问题： 业务系统与支付系统位于同一个系统，系统任何一次变更都会影响整个系统。 扩展性问题。接入新支付渠道，如微信，需要新暴露一个微信支付服务接口。业务系统需要改动代码。从另一方面讲，业务系统承担路由系统的功能。 复用性。新支付渠....
有更新！

支付渠道路由系统进化史

上篇文章 ShutdownHook- Java 优雅停机解决方案 提到应用停机时需要释放资源，关闭连接。对于一些定时任务或者网络请求服务将会使用线程池，当应用停机时需要正确安全的关闭线程池，如果处理不当，可能造成数据丢失，业务请求结果不正确等问题。 关闭线程池我们可以选择什么都不做，JVM 关闭时自然的会清除线程池对象。当然这么做，存在很大的弊端，线程池中正在执行执行的线程以及队列中还未执行任务将会变得极不可控。所以我们需要想办法控制到这些未执行的任务以及正在执行的线程。 线程池 API 提供两个主动关闭的方法 ThreadPoolExecutor#shutdownNow 与 ThreadPoolExecutor#shutdown，这两个方法都可以用于关闭线程池，但是具体效果却不太一样。 线程池的状态 在说线程池关闭方法之前，我们先了解线程池状态。 线程池状态关系图如下： 从上图我们看到线程池总共存在 5 种状态，分别为： RUNNING：线程池创建之后的初始状态，这种状态下可以执行任务。 SHUTDOWN:该状态下线程池不再接受新任务，但是会将工作队列中的任务执行结束。 STOP....
有更新！

一文教你安全的关闭线程池