NetSugar.Cap与CAP功能比对

前言

　　首先非常感谢开源社区，在各位作者无私得奉献下，我才有幸接触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的类。

缺陷

　　NetSugar.Cap客户端会定时的向数据库中T_CapRequeue表查询数据。T_CapClientNode、T_CapSubscriber刷新心跳。

　　不支持同一个项目中使用两个数据源。

写在最后

　　以上对比如有哪些欠缺或者错误还麻烦帮忙指出一下。特别是本人对CAP认知还不够的地方，还请帮忙多指出，免得误导了各位。NetSugar.Cap是我在学习了CAP代码之后写的，没有CAP就没有NetSugar.Cap,非常感谢CAP的作者。想试试NetSugar.Cap的可以参考源码中的测试代码，NetSugar.Cap的Nuget也已经发布了。支持提意见，不支持吐槽。