Kitex 口水话｜青训营笔记本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动”

这是我参与「第五届青训营」伴学笔记创作活动的第 19 天

本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动，如果你对我的其他文章感兴趣，可以去我的专栏中逛逛看有没有你想要的东西。

放在前面想说的话

去年有幸参与过 CloudWeGo 的建设，成为 Kitex 和 Netpoll 的 Contributor，Hertz 等其他项目是我在贡献 Netpoll 期间逐一 Public 的，所以还算了解这个社区。（因为后来想做数据库，所以半路提桶跑路了hhhh，狗头保命 =v=

开始口水话前，先以潜水狗的身份夸一下 CloudWeGo 社区：群里个个都是大佬，说话又好听，超喜欢在里面。;)

最近想捡一下后端的东西，便跑来参加一下字节的青训营，这篇笔记主要用于记录后端入门 - Go 框架设计与实现

口水话：指废话和没有用的话 -> 对于熟悉的人来说hhhh

关于 PRC（Remote Procedure Call），可以参考一下我之前为 “Kitex 前传” 贡献的部分 RPC 的工作原理: 让远程服务调用和本地调用一样方便。

这里写一点之前没关注到的东西：

可以使用 IDL（Interface Description Language），采用一种语言无关的方法来约定需要描述的接口，再用 Protobuf 或者 Kitex 一类的编译器工具生成代码，这个过程也可以叫做低代码编程，帮助提升生产效率；
RPC 封装了底层的网络通信细节（编解码、通信协议和网络传输），因此，在开发过程中可以更加关心业务逻辑本身的实现上；
PPT 里提到了扩展性高和性能更好，其实都是相对于 RESTful 而言，随着需求的变化，单个 RESTful API 会变得越来越臃肿，而性能更高在于 RPC 采用了 Protobuf 的数据传输格式。（个人感觉从业务架构去解释有点牵强，可能是我的没理解到位

第一章末给了三个问题，留到后面解答：

RPC 框架的核心有三层：编解码层、协议层和传输层。

先给一张 Thrift 的架构图，图片的注解和课件 PPT 不太一样：

编解码的核心问题在于数据格式：

对于数据格式的选型，课件中从三个维度进行了考虑：

至于协议层和传输层，课程讲解的内容实际上会更加通用一些：

如果按照 Thrift 的架构图去理解，协议层指支持的传输协议，传输层指的是支持的传输方式；

按照课程的中文注解是以操作系统的维度去解释的。（顺便吐槽一下：理解有出入能不能细说一下，feedback 时被 “Kitex老大确定没问题” 驳回了，可能是提 feedback 的人太蠢了 -。-

Anyway，这里就不展开解释了，都是计网和操作系统的基础知识。

至于（课件解释的）传输层选型：

课件里给了 5 个指标：稳定性、易用性、扩展性、观测性和高性能：

稳定性：通过服务降级（熔断、限流和超时）来保障服务，通过负载均衡和重试（可能会加重下游负载，同时也提到了两种解决方案：限制单点重试和限制链路重试）来提高请求成功率，长尾请求减少延迟和注册中间件提供服务；
易用性：开箱即用（生态好）和工具丰富（比如低代码工具）；
扩展性：可插拔的中间件，如服务发现、治理等等，核心都在于协议层和传输层；
观测性：Log、Metric 和 Tracing 三件套，代表的有 OpenTelemetry 之类的，以及内部观测服务；
高性能：低延迟和高吞吐，如多路复用之类的方案。

Kitex 用 Netpoll 替代了原生的 net 库：

因此，Netpoll 应运而生，并在编码层进行零拷贝等方案，以提升性能。

这里给一个框架图，简单解释一下，因为我感觉官方网站（中文）讲的更清楚，先指条路 CloudWeGo/Kitex，再来看一下架构图：

core 是它的主干逻辑，定义了框架的层次结构、接口，还有接口的默认实现：client 和 server 是对用户暴露的，client/server option 的配置都是在这两个 package 中提供的，还有 client/server 的初始化。

tool 则是与生成代码相关的实现，生成代码工具就是编译这个包得到的，里面包括 IDL 解析、校验、代码生成、插件支持、自更新等。

Kitex 的高性能、扩展性、稳定性在文档里都有提到，我这里就不再献丑了 :)

如果文章有问题，麻烦在评论区提醒一下，尽管都是一些口水话，还是尽量别说错了啊哈哈哈哈。