一点总结

让策略模式的使用像if-else一样更简单、更高效。将复杂的代码结构简单化，便利开发小伙伴的更加丝滑的使用策略模式。

通常来说，我们在进行微服务内部调用以及调用第三方接口时都是直接写在各自的业务模块中的。当然有的公司会有接口总线，将第三方调用的参数转换业务写在接口总线中，然后业务模块去远程调用接口总线。 总之无论如何

我们部门的业务模块需要对接另一个系统的很多接口，且它这个系统经历过重构升级，导致一些接口在新老版本的请求参数、请求类型、返回值不一样。但是我们依然要去兼容它的多个版本。

在日常开发中，我们经常需要使用编程式事务来解决一些实在的业务问题。以Hibernate框架为例(其实对于ORM框架来说，都大同小异。我们公司使用的是Hiberante，所以这里就以Hibernate为

首先最基本的，我们要弄清楚什么的并发嘞？我简单粗暴的理解就是：一段代码，在同一时间段内，被多个线程同时处理的情况就是并发现象。下面简单画了个图： 那么只要是并发现象就需要我们进行并发处理吗？那肯定不是

一般来说，我使用线程池最多的地方有两点： 对大量耗时任务的并发处理 对频发业务的线程池隔离 通过一年来在工作中对于线程池的使用，也总结了一些还算是比较实用的经验。如果各位小伙伴有更好的经验，欢迎指正和

当前单据生成完成后会使用当前单据的数据进行整理汇总后下推执行其他模块的业务。我们在遇到这种问题的时候基本上就会使用异步任务或mq的方式进行消息推送。没错，但是在消息推送之前呢？我们是不是首先要将下游业