前言
首先非常感谢开源社区,在各位作者无私得奉献下,我才有幸接触CAP。在拜读源码和理解设计原理过程中,发现CAP的源码是一个非常值得我们学习的代码。本人代码的基本框架采用简单的DDD,在练习Demo中发现开启事务的时候放在UOW实现,此时不需要ICapPublisher类,但是CAP需要,所以感觉调用起来多余了。还有一点,当我打开仪表盘的时候,发现仪表盘的定时统计会对数据库造成一点压力。由于本人对别人的开源产品不知道怎么更改,因为没有在生产环境中使用CAP,发现自己在guthub问的问题有点不清不楚的样子,也不好意思去向CAP的作者提意见,所以就自己模仿了一个,就这样NetSugar.Cap诞生了。
支持对比
CAP | NetSugar.Cap | |
数据库存储对比 | 测试时为了支持高并发,请把连接池配置大一点 | |
SqlServer | 支持 | 支持 |
Mysql | 支持 | 支持 |
PostgreSql | 支持 | 支持 |
MongoDB | 支持 | 支持 |
消息中间件对比 | ||
RabbitMQ | 支持 | 支持 |
Kafka | 支持 | 暂不支持(本人没使用过Kafka,代码已撸但未测试) |
DiagnosticListener | ||
DiagnosticListener | 支持 | 不支持 |
Dashboard | 支持 | 支持 |
节点发现 | 支持 | 支持 |
Dashboard对比
1、CAP当中Dashboard的代码与接收端、发送端都是在同一个代码里面,而NetSugar.Cap的Dashboard与逻辑代码是隔离的。在使用上CAP使用只需要引用一个包就足够了。但是NetSugar.Cap的Dashboard提供了多个数据源的管理,可以配置多个数据源,并且每个数据源可以单独的配置读连接和写连接,尽可能的减少了打开后台之后对业务上使用数据库的引用。
2、对一些消息需要重新处理的处理,两个都有一个Requeue操作,但是CAP执行Requeue操作时必须引用客户端业务代码,但是NetSugar.Cap则不需要。因为NetSugar.Cap在Dashboard设计上,后台的一些操作只是产生指令往数据库插入的,然后等待业务端代码定时根据定义的ClientName去查找对应的需要处理的记录去处理。当然这里客户端代码上增加了定时查询需要执行的指令的开销。但是指令表与发送消息的表是分开的,所以消耗不大。
3、CAP可以多个数据库节点通过consul进行统一查看,但是NetSugar.Cap在一个数据源里面只能查看当前数据源,没有整合多个数据源的节点,但是可以在多个数据源之间进行随意切换。
4、CAP对当日发送和接收消息的统计,NetSugar.Cap不支持。
5、CAP可以仪表盘地址进行动态配置,而NetSugar.Cap只能使用固定地址/CapDashboard/Home
业务代码使用对比
CAP是利用扩展IDbConnection(IMongoClient或者其它的)的方法去实现。
NetSugar.Cap是通过ITransactionCoordinator这个事务协调器,往里面扔对应的事务或者Connection或者自定义实现ITransaction的类。
订阅
1、CAP同一个项目中,同一个路由只能被一个方法去执行,但是NetSugar.Cap可以被多个订阅者执行,但是同一个路由一个方法只能执行一次,能被多个方法执行。
2、方法参数绑定:
CAP只能有一个参数,但是NetSugar.Cap可以允许你有多个,两者参数反序列化都是根据Json来反序列化的。
3、回调
CAP执行发送事件中带回调方法,但是NetSugar.Cap不支持。NetSugar.Cap建议的是在订阅方法中发送一个执行完成的事件。
4、监听绑定
CAP支持Controller和继承ICapSubscribe的类,接口不行。NetSugar.Cap支持Controller和继承ICapSubscribe的类和接口。
5、监听断线重连
NetSugar.Cap Rabbitmq会在网络闪断之后会自动尝试重新开启监听。
缺陷
NetSugar.Cap客户端会定时的向数据库中T_CapRequeue表查询数据。T_CapClientNode、T_CapSubscriber刷新心跳。
不支持同一个项目中使用两个数据源。
写在最后
以上对比如有哪些欠缺或者错误还麻烦帮忙指出一下。特别是本人对CAP认知还不够的地方,还请帮忙多指出,免得误导了各位。NetSugar.Cap是我在学习了CAP代码之后写的,没有CAP就没有NetSugar.Cap,非常感谢CAP的作者。想试试NetSugar.Cap的可以参考源码中的测试代码,NetSugar.Cap的Nuget也已经发布了。支持提意见,不支持吐槽。