关于支持okhttp组件

[wxrqforever]

一、背景
目前seata里有提供一个支持事务信息传递的http组件：AbstractHttpExecutor，此也适配feign等组件。但是目前未支持okhttp组件。我们主要使用的okhttp组件，这里迁移到AbstractHttpExecutor成本太高(需要增加网关鉴权、适配各种调用方式、以及推动改造)。

因此目前已通过java-agent的方式对okhttp组件进行了增强，增加了事务传递的部分，想提交到社区，不知是否能接受。

[funky-eyes]

我赞成这个采纳feature，不过你准备提交的是java-agent的实现，还是在integration模块中集成okhttp的xid传递呢？
I support the adoption of this feature, but are you planning to submit the implementation for the Java agent, or integrate XID propagation in the OkHttp module within the integration module?

[wxrqforever]

我赞成这个采纳feature，不过你准备提交的是java-agent的实现，还是在integration模块中集成okhttp的xid传递呢？
I support the adoption of this feature, but are you planning to submit the implementation for the Java agent, or integrate XID propagation in the OkHttp module within the integration module?

准备提交的是java-agent的实现。

[funky-eyes]

我认为java-agent的实现不太利于社区的用户使用，并且与其他的实现有些割裂，建议直接在integration中进行扩展
I believe the implementation of the Java agent is not very user-friendly for the community and is somewhat disconnected from other implementations. I recommend extending it directly within the integration module.

[wxrqforever]

我认为java-agent的实现不太利于社区的用户使用，并且与其他的实现有些割裂，建议直接在integration中进行扩展
I believe the implementation of the Java agent is not very user-friendly for the community and is somewhat disconnected from other implementations. I recommend extending it directly within the integration module.

这里我没太理解直接在integration中进行扩展的意思。我计划的实现是在integration下新增一个子项目，命名为seata-http-agent，然后提交基于java-agent+bytebuddy的一个插件增强框架，并带上对于okhttp插件的实现。关于提到的实现割裂，确实因为它只是对于http类相关的增强，并没有具备完整seata的功能。但是我理解可以把它作为http类插件补充实现，对于社区的用户，尤其是存在大量存量类okhttp插件调用的场景(其他的比如httpclient3、httpclient4)，想要做到无侵入接入(如果是spring管理的，也许可以像feign那样，但是如果是非spring管理则难以做到)，就可以考虑自己扩展，还可以单独打包agent，和整个seata一并使用。

回复中提到的“直接在integration中进行扩展”，是希望我提供类AbstractHttpExecutor的实现，但是底层是通过okhttp的调用吗？

[slievrly]

java-agent is a system worth exploring, and it is necessary to pay attention to the agent order of multiple agents.If it's going to be an agent implementation, it needs to be a separate top-level module, and I think it's not just an adaptation of okhttp.

[wxrqforever]

java-agent is a system worth exploring, and it is necessary to pay attention to the agent order of multiple agents.If it's going to be an agent implementation, it needs to be a separate top-level module, and I think it's not just an adaptation of okhttp.

您好，按我个人目前的理解java-agent的使用场景，结合seata的能力来看，是比较适合用于各种已知组件的适配，让用户无感知。这里有点类似于TTL项目里TTL-SDK和TTL-agent之间的关系，可以通过额外部署TTL-agent来获得TTL变量在线程池场景的自动更新，用户是同时使用TTL-SDK和TTL-agent来达到这个效果。然后关于java-agent能不能在seata里做的更多，比如包括seata-client的核心功能？个人感觉由于seata是一个新东西，有自己的语义需要用户感知，java-agent突出的是无感知，所以感觉在这个场景下，难以成为一个完全独立的部分。

以上是我个人的一些不成熟看法，希望社区能就这个问题进一步讨论一下，非常期待各位大佬的看法和回复，多谢。

[funky-eyes]

java-agent对用户是有要求的，特别是如果出问题了如何排查？
一些轻量级的如监控，行为，日志采集等不影响业务运行和结果的功能更适合作为agent设计。
如果只有okhttp用java-agent方式开发，那么跟以往seata中xid传递的使用方式是极为割裂。
The Java agent has certain requirements for users, especially when it comes to troubleshooting if something goes wrong. Lightweight functionalities such as monitoring, behavior tracking, and log collection, which do not impact business operations and results, are more suitable to be designed as agents.

If only OkHttp is developed using the Java agent approach, it would be quite fragmented compared to the usual way of passing XID in Seata.