-
Notifications
You must be signed in to change notification settings - Fork 8.8k
20240907
参会人:
会议时间:2024/09/07
下次会议时间:2024/9/21 ReleaseManager: 陈健斌
如有时间变更,再另行通知,请订阅邮件列表:[email protected]、[email protected]
会议规范:
- 每次开会时,如果完成掉的任务,会上就直接移除掉该部分内容。
- 一些比较大的功能点/设计,需要在讨论前形成技术文档,避免在大家不了解背景的情况下进行讨论。
- 同时做到事后可追溯 不开没有结论的会。哪怕“方案取消”或“下次再议”,也是结论的一种。
-
seata 项目安全漏洞 @清铭
https://github.com/apache/incubator-seata/discussions/6233
20240907: seata主项目目前还有4个漏洞,3个是前端的漏洞,升级依赖不一定能解决,需要替换相关依赖。
-
Apache Logo:Seata的Logo加上Apache元素。@清铭
-
开源之夏议题,具体可以参考[email protected];
-
ALC hangzhou活动;
-
Apache Con 7.26周五健斌,7月28周日 祥坤20240803:已完成,相关pr发到公众号和官网博客 @祥琨 @健斌 -
蚂蚁外滩大会(上海)20240907-参与seata开源分享 @健斌
-
官网访问流量治理 @刘秋枫
- nacos和higress 已改版,后续dubbo,之后seata也进行改版。
- 智能答疑,参考nacos/higress
20240907:交由阿里内部人员统一处理,sentinel改完后再改seata,需要几个月后才能完成,涉及合规相关问题,尽量小改。
-
官网关键词优化(长期):前两周暂未处理,后面与提升页面体验分一起弄
-
提升页面体验分;todo(放二期;
一期先关注合规 done; -
文档:博客问题:@刘秋枫 官网文档目前是整体一篇,需要治理下;
-
2.0与2.1的新feature的需要一些博客pr,发布在官网,公众号等渠道
- rocketmq集成 @嘉伟 - 暂无进展
- api重构 设计文档发布到官网,然后再编写一篇博客 @瑞姗
- namingserver @俊敏 - 暂无进展
- seata-k8s @祥琨 - 暂无进展
- seata默认序列化优化 @亦夏 - 暂无进展
- 多版本协议 @明华 - 暂无进展
- Seata最佳实践博客 @健斌 - 暂无进展
- 2.1 released
- seata-samples 2.10 更新 TODO
-
单测/变更覆盖率目标@汪忠祥
迭代中,单侧覆盖度的统计问题;单侧报告里面包含了依赖相关代码,导致覆盖率下降;TODO:调研解决
-
集测回归能力建设 @张嘉伟 @熊靖浏
目标:完整、自动化、持续集成,能够完成功能、稳定性、用户体验、安全上能力的验证
进度:20240907: 完成e2e seata-api 场景的合并
-
兼容性测试@王良
目标:兼容性测试需要包含:jdk、mysql-driver,arch等,确保在各个环境下稳定运行
整体依赖集成测试的进度
20240817:先完成mysql-driver的兼容性测试
-
BenchMark @亦夏
目标:建立seata性能基线、能够获取到当前系统/服务的性能以及变化,并且进行图形化输出;支持火焰图、trace、基准比对,异常预警等能力;
进度:已完成:提交第一版pr,支持微基准、profiler能力,后续:压力、吞吐量测试需要new出不同的seataClient,依赖api改造
解决完第一版问题,合并一版
- namingserver benchmark建设 @亦夏
- 服务暴露,服务发现,压力测试(需要结合,也需要拆分开单独压力测试)
- 可能涉及Prometheus的监控指标要记录(集成在namingserver侧)
- benchmark需要输出压力测试的结果,qps,rt,cpu等
- naming server 和 client对接相关的pr
遗留问题:
-
namingserver 目前接口没有鉴权 @依霖
-
namingserver changeVGroup 请求server,但是namingserver没有seata-server的token,暂定对相关接口不鉴权
20240907:全部流程及压测已经跑通,验收会上的问题已经修复,剩下一些使用优化和发版相关需要跟进
- 由于切流量后之前为了快速下线不可用节点,导致AT的全局事务要提交时无可用集群,AT模式的全局锁可能会延迟,比如回滚的时候,RM已经切走了,channel就不可用了
- 由于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
-
seata server vgroup统一存储
放在2.3版本做
-
2.2 notice和license更新
20240907:目前正在梳理中,预计下周提交一个pr
-
TM,RM -> TC registryRequest鉴权 @俊敏 @依霖
20240907:考虑从2.2上移除该特性
-
日志优化 总体进度:20%不到(@清铭 PR已提交,能满足国际化的要求,打出的堆栈都有对应的errorCode,错误信息里会显示一个链接链到FAQ页面中。)
根据定制的规范对其他的 exception 的格式做改造,待分配任务;待认领;
20240720:按模块先进行拆分,发布任务。
20240803:raft侧序列化白名单未命中时会通过seata exception进行输出日志,目前问题是输出的code可能无法与faq侧一样是自增的。
- faq不保留
- faq梳理成按错误的大类型来分类,比如config相关异常是0001-0099,其他的是xxx-xxx,不必直接自增这种方式。
- seata-go 代码的错误码、日志输出等规范,待分配任务;链接的官方的 FAQ 上;和 seata java 保持一致,等 java 完成再开始;
20240803:目前已与1.5.2版本对齐,samples需要更新版本。
-
TM/RM 快速失败只有在节点全部不可用才失败 @正涛
20240907:待提交pr,增加社区issue
-
seata-go 1.5.2 功能对齐 https://github.com/apache/incubator-seata/pulls?q=is%3Apr+label%3Amultilingual+is%3Aclosed
- TODO,检查哪些功能未对齐
-
client对raft节点健康检查
- 目前raft的discovery模块并没有针对metadata中的节点列表做健康检查,导致如果有follower宕机有几率会请求至宕机节点
- 如果用户使用的是lb地址做init address,当所有tc节点同时宕机时,不会复用这个lb节点重新进行发现服务
故需要将initaddress与metadata的nodes地址进行结合出一个地址列表,针对地址列表进行健康检查
20240907: 已被githubid:heliang666s 认领
-
raft集群nat场景支持
- 跨机房调用时,不同机房网段不同,通过nat转换后再不同的机房同一个tc的ip是不同的
- k8s场景,k8spodip无法被集群外直连,需要映射出一组可用的ip供外部使用
20240817: 前期先把server元数据,如权重等信息暴露到注册中心中供客户端使用,再讨论该问题
20240907:前置条件:元数据registry到注册中心
-
client多连接支持优化lb直连场景体验
- 无注册中心下,由于通过file读取lb地址后,针对一个地址只创建单一连接,导致tm,rm可能通过lb负载到了不同的tc节点,导致tm决议时,rm无法提交/回滚事务
- 单一连接可能存在连接异常,无限重传包等问题
20240817: xid->解析出server真实地址,然后rm侧建立连接,问题先暂缓,后续再评审。
-
seata-spring-boot-starter 支持读取file.conf和registry.conf
20240907: 已被 @李云龙 认领
-
拆分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)
-
当client为2.3.0时,server将merge msg还原回单独的rpcmsg,使其通过msg类型定位到对应的线程池,放入线程池中处理 client为2.3.0时,可直接通过单个response的id定位到future进行响应client的请求,并清理mergemap,避免因为由于单个响应导致client的mergemap无限膨胀无法清理的问题
-
而由于2.3的client可能跟多个版本server通信,多个版本的client也可能跟2.3server通信,所以老的逻辑不进行改变向下兼容。
20240907:历史merged消息当作一个消息处理,是否将merge详细直接在io线程里面拆分成单消息,使用业务线程去处理;2.3去看。梳理seata现有的线程模型
-
-
全局统一json工具,目前saga,tcc,包括at,以及server端有大量使用Jackson/fastjson用来序列化反序列化的情况,到处需要new一个objectmapper之类的实例,故是否应该在common里提供一个全局的json序列化工具。- TODO 建立issue,优化任务
20240907: saga Jackson 白名单api
-
批量删除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
-
单点服务限流 @靖浏
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版本中
-
https://github.com/apache/incubator-seata/pull/6629 针对只读的xa事务,二阶段是无法提交的,导致全局事务失败,该pr实现增加了一个XA_RDONLY的状态,使tc提交或回滚时忽略该分支。但是由于仅对oracle的xa做了处理,故该方案还需要商讨
结论:
20240907: pr已提交,待review
- 达梦driver无法获取on update的列,导致回滚时会漏回滚该列 @华栋
20240817: 考虑将only_care_update_column自动化配置,通过数据类型等方式来指定,而不是让用户自己配置。
-
apache fury 序列化集成 @树杰
20240907: 开发基本完成,待提交pr
-
jdk19+ 虚拟线程适配
- 去除非单例模式的synchronized关键字,改为ReentrantLock [Prevent virtual thread pinned · Issue #6724 · apache/incubator-seata (github.com)](https://github.com/apache/incubator-seata/issues/6724)
- 梳理seata client+server 中所有线程池,将线程池统一使用一个threadpoolfactory构建,以便在不同的java版本上使用不同的线程池,比如高版本可以统一为虚拟线程池
20240907:待投入人力
-
java独立日志文件输出,不和其他混在一起(现在框架和业务日志混在一起)@尹祥琨 todo
202409207:暂未投入
-
全链路支持gRPC协议
20240720:方案实践下来后,实际上属于类似于dubbo的triple协议,将seata协议转换在http2上。但无法直接兼容grpc协议,目前明俊正在做到在seata http2协议之中兼容grpc协议。
- seata server http2已跑通两阶段测试用例 seata 协议 转 http2
- 直接与grpc原生客户端通信正在测试
20240803:已完成与seata-server 跟 grpc原生客户端通信功能,grpc客户端需使用bi-stream(双向流)模式,下周会拉个进度会,演示http2,与grpc原生客户端通信能力
20240817:已完成对grpc的双向流支持,事务流程已通过,pr已提交,接下来完成server的http协议适配,并去除springmvc相关依赖
遗留问题:考虑seata协议在grpc之上,并且要关注grpc后续升级是否会存在不兼容,要保持协议版本的扩展的兼容。
20240907:已将grpc支持的pr根据修改建议进行修改,目前server http正在适配,预计月底前能完成。
-
与 Kubernetes 进行集成增强 seata-ctl 的运维能力
20240907:完成初版演示
-
实现控制台OpenAPI和提升系统安全性
20240720:正在设计方案
20240803:已经完成方案设计,投入开发中
20240817:下周同步进度
-
基于Raft和RocksDB实现配置中心
20240907:完成初版演示
主持人改为release manager,直接2个月为一个周期,并且2个月发版一次,本次release manager: @陈健斌
发版规则:
- 大版本计划改为每个版本有一个重点feature,只要这个重点feature完成,就可以考虑发大版本
- 如果没有达到第一点要求,release manager认为将bugfix和optimize的commits梳理后merge到小版本上进行pr提交,测试,验证,然后进行独立的小版本release. 本次2.2剩余问题
里程碑进展:
- namingserver从2.3挪至2.2里程碑,并列为首要目标,并且需要达到基本可用
- polardb-pg @清铭 后续同步进展
- k8s-apiserver 优先级降低
- grpc 预计2.2不上,2个月的发版周期应该来不及,纳入2.3