详细的交易一致性问题,请看<交易一致的由来>.
交易一致性的问题,解决的思路只有一个,那就是本地事务和远程调用的分离.虽然spring帮我们实现了在任意代码里面可以使用事务,但是一旦事务中包含远程调用,上述文章的内容就无法避免.
有的公司也使用"流程引擎"来解决,但是很不幸,如果引入"流程引擎",因为涉及到状态补单,"流程引擎"还有自己的保存事务,业务的订单也有自己的保存事务,引入"流程引擎"会因为额外的事务引入,会让情况变的更加复杂.qilu-state被设计成没有存储的最主要原因.
spring-cache提供了很好的调用接口,对于开发人员在使用cache的时候,可以做到很简单.但是spring-cache有下面几点做的很不好,而且在短时间内,看不到spring有优化的可能
qilu-cache仿照spring-cache的api,支持上述2种场景,缓存数据存储使用fastjson做数据序列化.和一般的cache封装不太一样,除了提供原始介质的set,get操作,还提供cacheService的高级封装操作,可以有效避免缓存穿透.
因为工作原因,看了一下动态数据源的东东,从开源的东西上看,动态数据源都是基于spring的AbstractRoutingDataSource进行扩展,spring内部还是认为一个数据源,管理的还是一个连接.
但是外部大量的开源的内容,都没考虑到动态数据源在项目使用过程中的意义.这边有必要说明下.
所谓的动态数据源,主要有2种场景
当看到Feign的源码,我就想到我曾经写的HttpService,在springCloud还没有流行的时候,我曾经开发的HttpService的中间件就已经在使用类似的机制来实现远程调用了.
在差不多12年的时候,当时设计的初衷就是不想使用Dubbo,因为dubbo太重量级,如果直接通过http进行远程服务的调用,会更加轻量级.而早在spring1.x的年代,spring就已经推出HttpInvoker,使用Http协议进行远程调用了.当时我们看到HttpInvoker非常不好用,就自己写了HttpService.
所以直到目前为止,我对于springCloud中广为吹牛的ribbon,hytrix等功能,都不是太感冒,中间整了那么多概念,本质上就是通过java来实现了NGINX的功能,非常华而不实.
logTrace是在排错的时候,查询服务器日志的时候冒出来的需求.一旦一个应用被部署到服务器上以后,在应用的手段内,就只能看到日志情况,而日志本身会受到多线程并发的影响,在并发比较大的情况下,排查一个线程的执行情况,如果没有一个traceKey作为查询条件的话,会面临一种很无力的局面.
logTrace最大的想法,是结合linux的grep命令,在最小侵入开发的情况下,最大程度的提供日志查询的简洁---通过2组grep命令,来实现查看某一个线程的所有日志.
logback集成请引入
<dependency>
<groupId>com.9istock.base</groupId>
<artifactId>qilu-logtrace-logback</artifactId>
<version>1.0.0</version>
</dependency>
log4j集成,请引入
<dependency>
<groupId>com.9istock.base</groupId>
<artifactId>qilu-logtrace-log4j</artifactId>
<version>1.0.0</version>
</dependency>超级导出是基于base开出的一朵花,其中的导出功能强大而隐秘,同时兼具扩展性,解决了我心中一个多年的愿望-----用查询功能写导出. 从这个中间件也可以看出,当底层被大量统一以后,会诞生出更多的中间件.这就是规范能带来的提升.
超级导出实现了一个单独的导出功能,对于controller或者service的直接复用.可以实现所见即导出,也可以手动实现各种导出功能.支持excel导出和CSV导出.
超级导出内部实现了一个强悍的数据转化工具,可以实现对list的增强操作,有了这个实现以后,结合qilu-mybatis生成的example代码,把原本需要使用多表关联的功能,转化为二次查询.
在开源领域已经存在pageHelper,mybatis-plus的情况下,为啥还要开发qilu-mybatis????
主要是我有偏见,我们认为在pageHelper和mybatis-plus之外,还有一种更好用的mybatis的使用方式.这种方式在于在mybatis-generator-tool自动生成的各种操作太好用了,以至于我认为可以抛弃pageHelper和mybatis-plus带来的便利,而一定要集成mybatis-generator的生成类的方式来使用mybatis.
qilu-mybaits主要特性
qilu-task主要是为了满足项目中的各种定时任务的防并发机制,都已经2020年了,难道一个系统上线,因为有个跑P的任务,所以要针对跑P功能单独开发应用程序,并且和运维同学商量好"这个包只部署一台服务器"???
流程的实现有简单和复杂的区别,复杂的流程一般都会包含配置界面,各种图形界面,断点,重跑之类的,而简单的,甚至都可以不要流程模型,比如我们当前的QiluTask的实现.当我们去掉配置界面以后,我们同样发现,整个的流程模型也能去掉,所以QiluTask可以被用在不需要流程的交易系统的各种异步补单中.
和quartz/spring-schedule不一样的地方在于,没有触发控制,只负责执行.使用简单的DB存储,告别quartz的8张表,具备简单的去重功能,有断点执行功能,主要是通过DB的机制来防并发,通过修改状态来实现简单的任务重跑.
开源领域已经存在hibernate.validation,我在使用的时候,总感觉是一个鸡肋,用他有很多不爽,不用,又没有一个很好的替代方案.所以这边就自己写了一个.
主要的不爽的地方如下
<dependency>
<groupId>com.9istock.base</groupId>
<artifactId>validation-api</artifactId>
<version>1.0.0</version>
</dependency>