严格来讲，本篇不讲源码，但是我们想了解熟悉整个框架时，肯定要知道框架的模块和设计思路。所以这里更多是分享理念和设计，也方便我们引入之后能按照场景更合适的按照自己业务扩展或定制需求。

当然，假如以后有需要，我们可以再讲讲各组件如何扩展，这里就不讲具体细节了。

Kitex

如果你还不了解 Kitex，可以看看《[ CloudWeGo 微服务实践 - 01 ] 开篇》。

如果你想参与 CloudWeGo 社区，给 Kitex 和其他组件贡献代码，可以看《如何给 CloudWeGo 做贡献》。

为什么要扩展

扩展性一直是 Kitex 有优势的一点，可以从两方面讲这个问题：

旧框架 Kitex 的困境

如果之前有看过《Go 微服务框架 KiteX 扩展性设计和实践 | JTalk Meetup 11期》视频，这里有详细的讲到了演进痛点和解决思路。

技术演进肯定是为了解决问题，比如：

做业务开发的同学也知道，如果不能找到特定处理规律，大多时候我们都是用 if else 或者 switch 来解决问题。但是这种硬编码的解决方式肯定不能在框架中使用。

不强绑定或依赖任何一项具体技术栈或组件

1. 如有人说“据我在多家公司的经历，thrift 基本都是老古董项目会使用”，很多人觉得 Protobuf 在 Go 生态中更为主流，但是 Kitex 的历史原因是使用了 thrift，不能强制要求统一，会失去灵活性，并且本身微服务以后也有多语言的需求。若依

2. 如注册中心，Kitex 已经兼容主流大部分的组件（kitex-contrib），至于选用那种，完全在于喜好和背景需求，使用时只需在 NewClient 或 NewServer 时，通过 WithOption 的方式把注册中心实例传入。当然也可以根据接口去定制。

3. 保证核心链路不变，作为一款 RPC 框架，核心是编解码和通信协议，这是框架的灵魂。如我们保证核心组件有默认处理，又支持用户自定义，如：

• 在传输层 Kitex 默认集成了自研的高性能网络库 Netpoll，但没有与 Netpoll 强绑定，同时也支持使用者扩展其他网络库按需选择；

• 在编解码 Kitex 默认支持内置的 TTHeader 传输协议，Payload 支持 Thrift 、KitexProtobuf、gRPC。另外，Kitex 集成 netpoll-http2 支持 HTTP2，目前主要用于 gRPC，后续会考虑基于 HTTP2 支持 Thrift。

以上，也是体验框架灵活性的方面。

只要框架的可扩展性足够，定制化的需求就可以通过用户自己的扩展来实现，而不是在 kitex 核心中 hardcode 实现。

支持扩展的组件

• Middleware 扩展

• Suite 扩展

• 服务注册扩展

• 服务发现扩展

• 负载均衡扩展

• 监控扩展

• 编解码(协议)扩展

• 传输模块扩展

• Transport Pipeline-Bound 扩展

• 元信息传递扩展

• 诊断模块扩展

支持扩展的组件，在官网讲的比较详细，可以直接参看《框架扩展》章节。