20240921

参会人： 王欣，陈健斌，汪忠祥，王明俊，钟正涛，吴江坷，王良，李树杰等

会议时间：2024/09/21

下次会议时间：2024/10/05 ReleaseManager: 亦夏

如有时间变更，再另行通知，请订阅邮件列表：[email protected]、[email protected]

会议规范:

• 每次开会时，如果完成掉的任务，会上就直接移除掉该部分内容。
• 一些比较大的功能点/设计，需要在讨论前形成技术文档，避免在大家不了解背景的情况下进行讨论。
• 同时做到事后可追溯 不开没有结论的会。哪怕“方案取消”或“下次再议”，也是结论的一种。

一、安全合规

• seata 项目安全漏洞 @清铭

  https://github.com/apache/incubator-seata/discussions/6233

  20240907: seata主项目目前还有4个漏洞，3个是前端的漏洞，升级依赖不一定能解决，需要替换相关依赖。

  20240921: 2.3时再进一步处理

• Apache Logo：Seata的Logo加上Apache元素。@清铭

二、活动/运营信息同步

• 开源之夏议题，具体可以参考[email protected]；

• ALC hangzhou活动；

• Apache Con 7.26周五健斌，7月28周日 祥坤

  20240803：已完成，相关pr发到公众号和官网博客 @祥琨 @健斌

• 蚂蚁外滩大会（上海）

  20240907-参与seata开源分享 @健斌

三、官网/文档

• 官网访问流量治理 @刘秋枫

  1. nacos和higress 已改版，后续dubbo，之后seata也进行改版。
  2. 智能答疑，参考nacos/higress

  20240907：交由阿里内部人员统一处理，sentinel改完后再改seata，需要几个月后才能完成，涉及合规相关问题，尽量小改。

• 官网关键词优化（长期）：前两周暂未处理，后面与提升页面体验分一起弄

• 提升页面体验分；todo（放二期；一期先关注合规 done；

• 文档：博客问题:@刘秋枫 官网文档目前是整体一篇，需要治理下;

• 2.0与2.1的新feature的需要一些博客pr，发布在官网，公众号等渠道

  • rocketmq集成 @嘉伟 - 暂无进展

  • api重构 设计文档发布到官网，然后再编写一篇博客 @瑞姗

  • namingserver @俊敏

    20240921：今天提交pr

  • seata-k8s @祥琨 - 暂无进展

  • seata默认序列化优化 @亦夏 - 暂无进展

  • 多版本协议 @明华

    20240921：已合并

  • Seata最佳实践博客 @健斌

    20240921：预计下周提交pr

四、发版信息

• 2.1 released

  • seata-samples 2.10 更新 TODO

    20240921：已合并

• 2.2 投票中

五、质量建设

• 单测/变更覆盖率目标@汪忠祥

  迭代中，单侧覆盖度的统计问题；单侧报告里面包含了依赖相关代码，导致覆盖率下降；TODO：调研解决

• 集测回归能力建设 @张嘉伟 @熊靖浏

  目标：完整、自动化、持续集成，能够完成功能、稳定性、用户体验、安全上能力的验证

  进度：20240907: 完成e2e seata-api 场景的合并

  进度：20240921：完成dubbo samples的 e2e测试，目前pr已提交待review

• 兼容性测试@王良

  目标：兼容性测试需要包含：jdk、mysql-driver，arch等，确保在各个环境下稳定运行

  整体依赖集成测试的进度

  20240817：先完成mysql-driver的兼容性测试

• BenchMark @亦夏

  目标：建立seata性能基线、能够获取到当前系统/服务的性能以及变化，并且进行图形化输出；支持火焰图、trace、基准比对，异常预警等能力；

  进度：已完成：提交第一版pr，支持微基准、profiler能力，后续：压力、吞吐量测试需要new出不同的seataClient，依赖api改造

  解决完第一版问题，合并一版

  • namingserver benchmark建设 @亦夏
  1. 服务暴露，服务发现，压力测试（需要结合，也需要拆分开单独压力测试）
  2. 可能涉及Prometheus的监控指标要记录（集成在namingserver侧）
  3. benchmark需要输出压力测试的结果，qps，rt，cpu等

2.2版本pr进度：

• naming server 和 client对接相关的pr

遗留问题：

1. namingserver 目前接口没有鉴权 @依霖

2. namingserver changeVGroup 请求server，但是namingserver没有seata-server的token，暂定对相关接口不鉴权

   20240907：全部流程及压测已经跑通，验收会上的问题已经修复，剩下一些使用优化和发版相关需要跟进

   1. 由于切流量后之前为了快速下线不可用节点，导致AT的全局事务要提交时无可用集群，AT模式的全局锁可能会延迟，比如回滚的时候，RM已经切走了，channel就不可用了

   2. 由于namingserver是无状态的，删除一个group时，无法在每个节点同时都生效，目前依靠group的缓存ttl来解决

      合并namingserver和server打包 [optimize: merge the packaging processes of namingserver and seata-server by funky-eyes · Pull Request #6819 · apache/incubator-seata (github.com)](https://github.com/apache/incubator-seata/pull/6819)

20240907：已完成合并二者打包逻辑，需要讨论下目前这样打包出来的结构是否满足要求。剩下需要该pr合并后，补充打包说明和部署使用文档

​ naming server 优化点会单独提一个pr，配置名称：seata

​ 20240921：已完成

• 2.2 notice和license更新

  20240907：目前正在梳理中，预计下周提交一个pr

  20240921：已完成

2.3版本pr进度

• seata server vgroup 统一存储

  20240921：暂无进展

• TM，RM -> TC registryRequest鉴权 @俊敏 @依霖

​ 20240907：考虑从2.2上移除该特性

​ 20240921：暂无进展

六、其他讨论事项

• 日志优化 总体进度：20%不到（@清铭 PR已提交，能满足国际化的要求，打出的堆栈都有对应的errorCode，错误信息里会显示一个链接链到FAQ页面中。）

  根据定制的规范对其他的 exception 的格式做改造，待分配任务；待认领；

  20240720：按模块先进行拆分，发布任务。

  20240803：raft侧序列化白名单未命中时会通过seata exception进行输出日志，目前问题是输出的code可能无法与faq侧一样是自增的。

  1. faq不保留
  2. faq梳理成按错误的大类型来分类，比如config相关异常是0001-0099，其他的是xxx-xxx，不必直接自增这种方式。
  • seata-go 代码的错误码、日志输出等规范，待分配任务；链接的官方的 FAQ 上；和 seata java 保持一致，等 java 完成再开始；

  20240803：目前已与1.5.2版本对齐，samples需要更新版本。

  20240921: 下周按模块拆分任务发布

• TM/RM 快速失败只有在节点全部不可用才失败 @正涛

  20240907：待提交pr，增加社区issue

  20240921：下周开始相关设计

• seata-go 1.5.2 功能对齐 https://github.com/apache/incubator-seata/pulls?q=is%3Apr+label%3Amultilingual+is%3Aclosed

  • TODO，检查哪些功能未对齐

• client对raft节点健康检查

  1. 目前raft的discovery模块并没有针对metadata中的节点列表做健康检查，导致如果有follower宕机有几率会请求至宕机节点
  2. 如果用户使用的是lb地址做init address，当所有tc节点同时宕机时，不会复用这个lb节点重新进行发现服务

  故需要将initaddress与metadata的nodes地址进行结合出一个地址列表，针对地址列表进行健康检查

  20240907: 已被githubid：heliang666s 认领

  20240921：暂无进展，尝试联系heliang666s

• raft集群nat场景支持

  1. 跨机房调用时，不同机房网段不同，通过nat转换后再不同的机房同一个tc的ip是不同的
  2. k8s场景，k8spodip无法被集群外直连，需要映射出一组可用的ip供外部使用

  20240817: 前期先把server元数据，如权重等信息暴露到注册中心中供客户端使用，再讨论该问题

  20240907：前置条件：元数据registry到注册中心

  20240921：拆分成任务，支持元数据暴露至注册中心，可参考dubbo相关设计

• client多连接支持优化lb直连场景体验

  1. 无注册中心下，由于通过file读取lb地址后，针对一个地址只创建单一连接，导致tm，rm可能通过lb负载到了不同的tc节点，导致tm决议时，rm无法提交/回滚事务
  2. 单一连接可能存在连接异常，无限重传包等问题

  20240817: xid->解析出server真实地址，然后rm侧建立连接，问题先暂缓，后续再评审。

• seata-spring-boot-starter 支持读取file.conf和registry.conf

  20240907: 已被 @李云龙 认领

  20240921：pr已提交下周进行review

• 拆分MergedWarpMessage处理逻辑，避免并行处理merge消息时forkjoin commonpool，二阶段并行下发也使用forkjoin commonpool，导致其出现线程互相等待hang死的问题，并且由于统一使用了默认50个核心数的业务线程池，方便线程调优

  [optimize: splitting MergedWarpMessage enhances the server parallel processing capability by funky-eyes · Pull Request #6807 · apache/incubator-seata (github.com)](https://github.com/apache/incubator-seata/pull/6807)

  1. 当client为2.3.0时，server将merge msg还原回单独的rpcmsg，使其通过msg类型定位到对应的线程池，放入线程池中处理 client为2.3.0时，可直接通过单个response的id定位到future进行响应client的请求，并清理mergemap，避免因为由于单个响应导致client的mergemap无限膨胀无法清理的问题

  2. 而由于2.3的client可能跟多个版本server通信，多个版本的client也可能跟2.3server通信，所以老的逻辑不进行改变向下兼容。

     20240907：历史merged消息当作一个消息处理，是否将merge详细直接在io线程里面拆分成单消息，使用业务线程去处理；2.3去看。梳理seata现有的线程模型

     20240921：下周进行prreview推动

• 全局统一json工具，目前saga，tcc，包括at，以及server端有大量使用Jackson/fastjson用来序列化反序列化的情况，到处需要new一个objectmapper之类的实例，故是否应该在common里提供一个全局的json序列化工具。- TODO 建立issue，优化任务

  ​ 20240907: saga Jackson 白名单api

  ​ 20240921：下周发布任务

• samples是否需要维护ioseata的兼容分支和org.apache.seata的主分支

  20240921: io seata的兼容性测试考虑在seata仓库的兼容模块中通过增加测试用例，或者专门搞一个ioseata-test模块来做测试，后续再进一步讨论，先修改包名为org.apache.seata.

• seata通用告警功能

  1. 考虑到有用户并没有Prometheus+grafana
  2. 需要一个通用的告警功能，如果sms，钉钉，邮件等方式

  20240921: 跟日志采集分析的告警有一定冲突。

待认领

进行中

• 批量删除undolog @明华 （依赖多版本协议支持及协议协商）

• tm/rm 注册失败需要返回原因 @明华（依赖多版本协议支持及协议协商）

  20240817：序列化少了一个字段，server抛异常时序列化时没有写回去。高版本上需要解决该问题

• jackson依赖问题 是强依赖 scope-provided 修改成compile依赖， jackson高版本禁用autotype，saga如何适配 @亦夏 方案设计中

  20240803：使用Jackson 白名单方式，文档上要体现出来

• TM/RM未init，rm注册，不再忽略，直接异常；改动影响比较大，暂定2.2版本去做； @亦夏 方案设计中

  20240803：等修复单测后开始review

• global_table积压问题 @付德蓉 下周一单独拉会 目前的现状是，committing状态在定时器扫描每次捞1000条数据的情况下，过滤出超过130s的事务，进行单条更新删除操作，在高并发5000r/s下，前者更新删除操作太缓慢，导致global_table数据太多了。 相关issue: https://github.com/apache/incubator-seata/issues/6615 单个节点，global_table累积多 上周结论: 方案1.数据分片,简单但是运维复杂,可靠性低, 方案2.使用多个锁. 缺点:global_table需要增加字段 20240720

  进展: 1.先解决单节点的问题，使用多线程的方式 2. 先不往复杂分布式的情况考虑

  1.rollbacking 50线程5000 query limit，业务线程也是50 3000tps，iftop 网卡，top -H，包括数据库40c，40c 6c 600%，xmx 2g

  20240921：后续单独再跟进 @健斌

• 单点服务限流 @靖浏

  20240720：已经提交sip至邮件组，目前限流组件选定为bucket4j

  20240803：下次周会前提交pr，遗留问题，因为bucket4j内部使用了concmap 有synchronized关键字，所以可能与虚拟线程的pr有冲突，可能考虑自实现令牌桶/滑动窗口。

  20240817：bucket4j内没有使用synchronized，所以不影响虚拟线程，可继续完成该任务。目前由于限流后client会报错，但是不方便追踪，故通过生成雪花id+client相关信息放入异常中，可通过server日志和client日志进行排查是否被限流，再增加一个metrics以便排查。

  遗漏问题：server与nacos结合时，metrics消失 @靖浏

  20240907：pr已提待review，放在2.3版本中

  20240921：下周开始review

• https://github.com/apache/incubator-seata/pull/6629 针对只读的xa事务，二阶段是无法提交的，导致全局事务失败，该pr实现增加了一个XA_RDONLY的状态，使tc提交或回滚时忽略该分支。但是由于仅对oracle的xa做了处理，故该方案还需要商讨 @树杰

  结论：

  20240907: pr已提交，待review

  20240921：下周开始review

• 达梦driver无法获取on update的列，导致回滚时会漏回滚该列 @华栋

​ 20240817： 考虑将only_care_update_column自动化配置，通过数据类型等方式来指定，而不是让用户自己配置。

• apache fury 序列化集成 @树杰

  20240907: 开发基本完成，待提交pr

  20240921: 疑似注册顺序导致id相同，类不同，导致反序列化失败

• Fastjson2 序列化集成 @树杰

  20240921：下周提交pr，后续看看跟fastjson的兼容性如何，是否可以直接取代

• jdk19+ 虚拟线程适配 @云清

  1. 去除非单例模式的synchronized关键字，改为ReentrantLock [Prevent virtual thread pinned · Issue #6724 · apache/incubator-seata (github.com)](https://github.com/apache/incubator-seata/issues/6724)
  2. 梳理seata client+server 中所有线程池，将线程池统一使用一个threadpoolfactory构建，以便在不同的java版本上使用不同的线程池，比如高版本可以统一为虚拟线程池

  20240907：待投入人力

  20240921：预计国庆期间投入开发

• java独立日志文件输出，不和其他混在一起（现在框架和业务日志混在一起）@尹祥琨 todo

  202409207：暂未投入

summer code

• 全链路支持gRPC协议

  20240720：方案实践下来后，实际上属于类似于dubbo的triple协议，将seata协议转换在http2上。但无法直接兼容grpc协议，目前明俊正在做到在seata http2协议之中兼容grpc协议。

  1. seata server http2已跑通两阶段测试用例 seata 协议 转 http2
  2. 直接与grpc原生客户端通信正在测试

  20240803：已完成与seata-server 跟 grpc原生客户端通信功能，grpc客户端需使用bi-stream（双向流）模式，下周会拉个进度会，演示http2，与grpc原生客户端通信能力

  20240817：已完成对grpc的双向流支持，事务流程已通过，pr已提交，接下来完成server的http协议适配，并去除springmvc相关依赖

  遗留问题：考虑seata协议在grpc之上，并且要关注grpc后续升级是否会存在不兼容，要保持协议版本的扩展的兼容。

  20240907：已将grpc支持的pr根据修改建议进行修改，目前server http正在适配，预计月底前能完成。

  20240921：namingserver 使用netty支持http和http2，目前设计仅watch功能为http2，server直接推送。

  Todo: tcc模式grpc协议压测，namingserver做好连接管理和重连，namingserver-client通过配置项启用http2，http2支持推送metaresponse。

• 与 Kubernetes 进行集成增强 seata-ctl 的运维能力

  20240907：完成初版演示

  20240921：代码已完成，Elk和日志系统，loki。日志采集为node级别。

• 实现控制台OpenAPI和提升系统安全性

  20240720：正在设计方案

  20240803：已经完成方案设计，投入开发中

  20240817：下周同步进度

• 基于Raft和RocksDB实现配置中心

  20240907：完成初版演示

  20240921：已提交pr和测试设计文档。

后续规划

主持人改为release manager,直接2个月为一个周期,并且2个月发版一次,本次release manager: @陈健斌

发版规则:

1. 大版本计划改为每个版本有一个重点feature,只要这个重点feature完成,就可以考虑发大版本
2. 如果没有达到第一点要求,release manager认为将bugfix和optimize的commits梳理后merge到小版本上进行pr提交,测试,验证,然后进行独立的小版本release. 本次2.2剩余问题

里程碑进展：

1. namingserver从2.3挪至2.2里程碑,并列为首要目标,并且需要达到基本可用
2. polardb-pg @清铭 后续同步进展
3. k8s-apiserver 优先级降低
4. grpc 预计2.2不上,2个月的发版周期应该来不及,纳入2.3