关于Seata服务器支持更多SPI扩展点的讨论

[HEIBAIJIE]

我们发现了一些可能有益的新的SPI扩展点：

1. 消息类型、编解码器扩展：使Seata服务器支持对自定义消息类型的编解码
2. 消息处理钩子的扩展：在ServerOnRequestProcessor处理某类消息前后实现额外的扩展逻辑
3. 处理器扩展：允许服务器为上述自定义消息类型注册自定义处理器
4. 启动项扩展：允许Seata服务器在启动时执行额外的逻辑
5. 具体配置扩展：通过简单的实现来增加一个具体的配置项
6. 客户端相关：对原有硬编码进行少量变动，使Seata能与RM、TM以外的客户端类型建立连接

目前我们的功能已经基本实现，但我们并不奢望直接将具体功能合入，或者直接合入我们对扩展点的实现。
只是想在此了解一下社区对相关SPI扩展点的看法，讨论未来支持这些扩展点的可能性，欢迎给出意见和建议。

[funky-eyes]

1. 必然需要修改seata-server侧的代码，所以是直接侵入的。
2. 这块就是rm侧的hook就可以完成， 计划中
3. 不应该让业务参与到消息处理器的程度来，据我了解没有什么组件这么干的，你可以举几个别的主流主键支持把自己的processor开放出来允许业务随意注册的，既然注册肯定是有地方要魔改代码否则怎么收发消息rpc？
   4.Seata侧考虑做一些spi的方式，现在已经通过loader.path将libs下的所有jar装载，那么只要spi的实现类的jar被放入到这个路径下就能被感知到
   5.不明白什么意思
   6.为什么要跟rm tm以外的客户端建立连接？kafka，rocketmq这类有server的消息中间件有这么干的？再producer和consumer外允许其他非标连接？连接的意义是什么？

[funky-eyes]

1.大概明白了
2.可以举一些server上消息处理钩子的一些用途吗？做旁路分析采集，或者metric？
3.我想了解下什么样的架构需要与seata-server进行通信呢？如果已经有了第二点的支持，还需要3吗？

[HEIBAIJIE]

@a364176773

1. 关于消息处理钩子，我们目前用到的场景是拦截RM与server的交互，对上下文中的resourceID在Server侧进行一个动态的扩展。
   RM注册、上行时为resourceID添加一些标识，便于下行时找到特定范围的RM。
   标识的内容只有Server侧才配置，业务侧对此不感知。
   当然消息处理钩子还是有很多其他的扩展潜力的，比如您提到的旁路分析，特定的日志打印等等。
2. 根据我们的压测，在db模式、超高吞吐量的条件下，Seata服务器的性能表现严重受制于数据库交互，而且写多于读。所以我们让不同的Server集群连接不同的数据库实例，让绝大多数局域的分布式事务需求在该局域内解决，这样就把压力从一个数据库实例分摊到了多个实例。但是依旧存在一些跨域的事务，显然按照Seata现有的架构，如果全局事务与分支事务不在同一个数据库中，分支是无法注册成功的。那么我们就需要server之间通信，把分支事务转到全局事务所在的server处理。
   这个只有钩子是无法支持，一个简单的例子，seata-server原本不是用来处理分支提交/回滚的，但是某些时候我们需要它中转这种消息。

[funky-eyes]

明白了，第二点我建议直接用现有的分布式数据库比如oceanbase或者tidb来做分库分表，对seata-server而言还是连得逻辑表和逻辑库即可，你方便添加的们的钉钉群吗，我们下次月度讨论可以带上你这个需求，如果你有空的话可以跟我们做个在线分享或交流，让社区其他的开发者更清晰直接的了解这个需求。我们开发者钉钉群为33774360

[funky-eyes]

其次我们在2.0上会推出raft模式，目前已经是在跑各种压力测试和故障测试中，后续还会推出multi-raft模式，将不同的事务随机路由到不同的raft group中，比如3台tc，可以搭建3个group，那么每台为一个group的leader，其余两台为group的副本，来提升吞吐量，我们的测试结果相对db和redis模式下还是提升非常大的，如果你有兴趣也可以参与到这个pr的review和测试中 #5226

[HEIBAIJIE]

非常感谢，已加入钉钉群。

[funky-eyes]

通过社区内部沟通,seata将会考虑以下扩展点
1.消息处理钩子的扩展：在ServerOnRequestProcessor处理某类消息前后实现额外的扩展逻辑
2.处理器扩展：允许服务器为上述自定义消息类型注册自定义处理器