为什么ET的Star数比TCC-Transaction少？

[kwengelie]

根据作者发布的少有的几篇文章，大致可以了解到ET的功能、定位相对于TCC-Transaction要好很多。但是，不难发现ET的STAR数量远远不如TCC-Transaction，为什么呢？

从一个使用者的角度，首先考虑的就是是否容易上手。通过Baidu搜索ET的使用文档，基本上只有作者在Github代码首页发布的寥寥数语。还没说清楚WalletPayTccMethodRequest、WalletPayTccMethodResult、WalletPayTccMethod、EasyTransFacade之间的关系，说直接点，用ET的开发规范、规则到底是什么，没有一点说明，不易理解。如果我是架构师，负责技术选型，仅这一条基本上已经否定了ET，而转用其他框架。

而TCC-Transaction文档资料就做的很好，各种源码解读、用户示例通俗易懂。同样阿里开源的分布式事务框架，文档说明方面也做得很好，所以他们的用户多、STAR也多。

假如ET希望有更多的贡献，建议ET还需要再开放些，否则很难吸引用户。

好比一个人的实力很强，但是穿着打扮却很糟糕，大家就会很难接受他。

[skyesx]

关于使用方法在首页中仅作示意，更详尽的使用方法是在：DEMO以及UT中的案例中。但这确实不像文档一样友好，需要客户下载源码才能看的到，我后续将这些DEMO及UT的案例搬出来，做成个文档吧。

原理解读我觉得可以通过首页就能获得了，高层架构设计通过与seata的比对文档也可以获得，但源码解读确实是目前缺少的，我这个后续加上吧

感谢你的建议，如果还有我上面提漏的，可以提醒我，不过最近工作比较繁忙，更新的时间可能会晚一点

[kwengelie]

今天看了下demo，感觉这个框架的确很棒，易用性方面还是挺不错的。附demo实现interfacecall-wallet-api工程中WalletPayRequestCfg的说明，便于后续使用者使用： /**

• 本类很重要，用于衔接EasyTransaction框架，定义WalletPayMoneyService的具体访问接口。
• 逐一解释如下：
• appId：定义了WalletPayMoneyService对应的应用名称，该应用名称对应的IP地址和路由算法，见application.xml中的“wallet-service”属性值配置
• busCode:定义了将要访问的方法，该方法在服务提供方采用path="/{busCode}/{innerMethod}"的方式暴露，
• 对于本例，url path会暴露3个：/pay/doTry,/pay/doConfirm,/pay/doCancel；其中doTry，doConfirm，doCancel三个方法名，由框架维护
• rpcTimeOut:超时时间
• 本类定义后，可使用util.createTransactionCallInstance(WalletPayMoneyService.class, WalletPayRequestCfg.class);
• 方法，生成WalletPayMoneyService类型的访问代理实例。
• 在通过WalletPayMoneyService代理实例访问方法WalletPayMoneyService.pay时，
• ET框架会根据TCC调用规则，将访问方法busCode=pay转换为http请求，并根据业务情况访问doTry、doConfirm或者doCannel方法。

• 在服务提供方，通过注解@EtTcc(

• confirmMethod="doConfirmPay",
• cancelMethod="doCancelPay",
• idempotentType=BusinessProvider.IDENPOTENT_TYPE_FRAMEWORK,
• cfgClass=WalletPayRequestCfg.class)
• 对具体业务实现doPayTry方法进行注解，ET框架解析EtTcc注解中的confirmMethod、cancelMethod、cfgClass，
• 将具体实现的try、confirm和cancel方法 通过RestRibbonEasyTransRpcProviderImpl暴露http服务，以供服务消费方OrderService调用。
• 由此可见：WalletPayRequestCfg是非常重要的。本类要求继续请求参数WalletPayRequestVO，并实现TccMethodRequest<WalletPayResponseVO>。
• ET框架在代理类时，需要根据TccMethodRequest获取到对应具体的TCC协议执行类TccMethodExecutor。
• 通过跟踪WalletPayRequestCfg的类定义不难发现，WalletPayRequestCfg是TccMethodRequest的子类，而TccMethodRequest对应的执行协议是TccMethodExecutor。
• @author

*/ @BusinessIdentifer(appId=WalletServiceApiConstant.APPID,busCode="pay",rpcTimeOut=2000) public class WalletPayRequestCfg extends WalletPayRequestVO implements TccMethodRequest<WalletPayResponseVO>{ private static final long serialVersionUID = 1L; }

[xibaohe]

求一份，详细一点的源码分析文档。对这个框架比较感兴趣，想了解一下。

[skyesx]

简单写了一下，先看

Seata及EasyTransaction架构的比对思考 https://www.cnblogs.com/skyesx/p/10674700.html

再结合着代码看

https://www.cnblogs.com/skyesx/p/11111726.html

[chenld]

现在还没明白消息可靠和最大努力在源码是怎么体现的，哎，

[zhubing4019]

@chenld BestEffortMessageMethodExecutor、ReliableMessageMethodExecutor 比较执行器的区别， 1.可靠消息会存储到unfinish表中 2.最大努力通过logProcessContext.registerProcessEndEventListener事件触发 结论： 当主控服务crash，可靠消息可以通过unfinish表恢复执行，最大努力丢了无法恢复！