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.
会前必读： http://www.cloudwego.io/; https://github.com/cloudwego
议程 1 ：新人自我介绍
内容：社区新成员和首次参加社区会议的内部成员分别进行自我介绍，主要包含个人基本情况和历史贡献。
议程 2 ：CloudWeGo 仓库介绍
- 对 CloudWeGo 主仓库进行了简要介绍，欢迎社区成员对仓库进行补充加强。例如：欢迎大家在 Kitex_examples 仓库提交一些 Business demo，例如电商、医疗等不同行业场景下的典型案例 。
- Community 仓库：首先，Community 仓库刚成立不久，主要用于归档社区相关的材料，包括双周会的会议纪要（meeting_notes）和周报（weekly_report）。其次，也欢迎大家成为该仓库的正式成员，后续的活动可以第一时间通知到大家，便于大家参与到核心功能的讨论与开发。
- Kitex-contrib 仓库：该仓库包含了各种扩展的对接实现，比如对接 Prometheus，对接Opentracing 等。其中，OpenTelementry 对接项目正处于提交 PR 的状态，欢迎大家参与到项目的共建和 review。
议程 3：社区后续工作介绍
- 源码解析和微服务实践解析系列文章志愿者筹集，以及宣传运营支持：譬如：我们可以通过开源中国等渠道去发布一些优质文章，欢迎大家在源码解析和微服务实践方面文章的投稿。
- 开放服务治理：后续会和其他的一些厂商以及开源社区共同合作，去完成服务治理标准的制定。
- 官网文档和页面优化：对 CloudWeGo 官网的 Document、About、Blog 和 Community 页面提出意见，进行优化。
议程 4： Kitex 3、4月 TO DO/DOING
事项介绍
- 性能优化
- Kitex-gRPC Streaming 性能提升。
- Protobuf 编解码性能优化，初步完成，完善边界 case 。
- Frugal - 无生成代码的高性能动态 Thrift编解码库。
- 新特性支持
- Thrift 泛化调用 新增对 Protobuf 的支持用于网关
- Protobuf <-> Thrift 高性能的协议转换
- 重试:支持用户自定义异常重试
- Proxyless 支持:完成服务发现/路由对 xds 接口扩展
- 功能优化:
- 重写连接池逻辑，支持更加优雅的空闲连接清理
- 增加字段 Size 校验
- 外部需求
- 连接预热、连接多路复用通知上游退出
Action Items
- Kitex 开源库单元测试补全任务：希望社区同学能够加入进行补全。有助于促进大家熟悉源代码，帮助大家的后续开发。重点需要补充的 package 后续会在 Kitex 仓库创建独立的 Issue, 欢迎大家认领。
补充单元测试原则
补充的单测必须是有意义的，验证某个逻辑的正确性，或者异常表现是否符合预期。
杜绝为了覆盖率而补全单测，宁可不加。
每个单测必须要有断言。
可以添加 mock 辅助单测。
建议单测通过注释明确验证的逻辑。
不要在单测代码里用 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：不是的。我们的连接池有一个空闲连接的策略，空闲连接是指你配置了空闲时间，那么到了这个空闲时间，你这个连接就应该被清理掉。但实际上目前不是这样的逻辑，目前是我在用到这个连接的时候，我发现这个连接可能已经达到了我的空闲时间了，然后我才会把它给清理掉，这个是不合理的。基于此，我们打算重写这块的逻辑。