CloudWeGo 社区会议 3.11

会议主题: CloudWeGo 社区会议 3.11

参会人员: CoderPoet, liu-song, GuangmingLuo, Zheming Li, YangruiEmma, li-jin-gou, simon0-o, Dianjun Suo, jasondeng1997, lvnszn, baiyutang, Duslia, joway, Xuewu Jiang, AshleeT, yccpt.

会前必读: 官网https://github.com/cloudwego

议程 1 :新人自我介绍

内容:社区新成员和首次参加社区会议的内部成员分别进行自我介绍,主要包含个人基本情况和历史贡献。

议程 2 :CloudWeGo 仓库介绍

  1. 对 CloudWeGo 主仓库进行了简要介绍,欢迎社区成员对仓库进行补充加强。例如:欢迎大家在 Kitex_examples 仓库提交一些 Business demo,例如电商、医疗等不同行业场景下的典型案例 。
  2. Community 仓库:首先,Community 仓库刚成立不久,主要用于归档社区相关的材料,包括双周会的会议纪要(meeting_notes)和周报(weekly_report)。其次,也欢迎大家成为该仓库的正式成员,后续的活动可以第一时间通知到大家,便于大家参与到核心功能的讨论与开发。
  3. Kitex-contrib 仓库:该仓库包含了各种扩展的对接实现,比如对接 Prometheus,对接Opentracing 等。其中,OpenTelemetry 对接项目正处于提交 PR 的状态,欢迎大家参与到项目的共建和 review。

议程 3:社区后续工作介绍

  1. 源码解析和微服务实践解析系列文章志愿者筹集,以及宣传运营支持:譬如:我们可以通过开源中国等渠道去发布一些优质文章,欢迎大家在源码解析和微服务实践方面文章的投稿。
  2. 开放服务治理:后续会和其他的一些厂商以及开源社区共同合作,去完成服务治理标准的制定。
  3. 官网文档和页面优化:对 CloudWeGo 官网的 Document、About、Blog 和 Community 页面提出意见,进行优化。

议程 4: Kitex 3、4月 TO DO/DOING

事项介绍

  1. 性能优化
  • Kitex-gRPC Streaming 性能提升。
  • Protobuf 编解码性能优化,初步完成,完善边界 case 。
  • Frugal - 无生成代码的高性能动态 Thrift编解码库。
  1. 新特性支持
  • Thrift 泛化调用 新增对 Protobuf 的支持用于网关
  • Protobuf <-> Thrift 高性能的协议转换
  • 重试:支持用户自定义异常重试
  • Proxyless 支持:完成服务发现/路由对 xds 接口扩展
  1. 功能优化:
  • 重写连接池逻辑,支持更加优雅的空闲连接清理
  • 增加字段 Size 校验
  1. 外部需求
  • 连接预热、连接多路复用通知上游退出

Action Items

  1. Kitex 开源库单元测试补全任务:希望社区同学能够加入进行补全。有助于促进大家熟悉源代码,帮助大家的后续开发。重点需要补充的 package 后续会在 Kitex 仓库创建独立的 Issue, 欢迎大家认领。

补充单元测试原则

  1. 补充的单测必须是有意义的,验证某个逻辑的正确性,或者异常表现是否符合预期。

  2. 杜绝为了覆盖率而补全单测,宁可不加。

  3. 每个单测必须要有断言。

  4. 可以添加 mock 辅助单测。

  5. 建议单测通过注释明确验证的逻辑。

  6. 不要在单测代码里用 printf 等手段打日志人肉去检验。

议程 5:Q&A

Q:Kitex 啥时候支持 Thrift Streaming?

A:Kitex 支持 Thrift streaming 我们刚开始是计划要做的,但是之后了解到目前没有应用场景,没有用户提出需要用到 Thrift Streaming, 因此,这个计划我们就搁置了。如果没有收到真实的业务场景需求,我们暂时不去安排这个功能支持。

Q:Proxyless 支持这块是一个 doing 状态吗?

A:之前是有一个同学在跟进,但是后来因为内部有其它事情处理就没有再继续做了。如果你感兴趣的话,可以加入进来一起支持。

Q:字段 size 是说大包性能的问题么。类似拆包去分发?

A:首先,大包这一块的问题,我们目前是在 v1.8.0版本,就支持了可以去自定义整个包的 size。 其次,字段 size 校验的话,有可能有时我们的包出现错误,这个时候如果我们没有去校验 size, 那在解码的过程中,会因为这个错误的 size 可能导致去分配很大的内存。所以我们想对这个字段 size 增加一个校验。

Q:连接池优化是指高并发的时候,长连接变成短连接的问题吗?

A:不是的。我们的连接池有一个空闲连接的策略,空闲连接是指你配置了空闲时间,那么到了这个空闲时间,你这个连接就应该被清理掉。但实际上目前不是这样的逻辑,目前是我在用到这个连接的时候,我发现这个连接可能已经达到了我的空闲时间了,然后我才会把它给清理掉,这个是不合理的。基于此,我们打算重写这块的逻辑。