微服务架构面临的各服务间的通信问题如何解决

微服务架构自出现以来，一直面临一道难题 —— 各服务间的通信问题。微服务架构下，各个模块以微服务的形式被拆分到了不同的进程甚至节点上，服务间通信只能使用复杂的 RPC 通讯，这也成为了微服务架构的一个性能瓶颈。2016 年，Service Mesh 的概念被提出，其定位便是用来服务与服务之间的通讯的云原生基础设施。而后，谷歌、IBM 与 Lyft 三方共同发布了开源 Service Mesh 产品 ——Istio，旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。发展至今，Istio 已经成了最受欢迎的 Service Mesh 产品。

Istio 采用与应用容器并行的方式，部署使用 Sidecar 这种可编程的代理机制。Sidecar 最大的亮点就是业务无侵入，应用程序无需接受大幅改造，也没有额外的关联成本，也正是这个优点，让 Service Mesh 的理念深入人心。但是在一些对性能比较敏感的场景，Istio-Sidecar 模式也不可避免地会带来一些问题，诸如：应用协议绑定、性能损耗、资源开销、运维复杂度提升等等。而目前许多 RPC 框架并不能很好地解决 Istio-Sidecar 模式带的问题，也因此，很多企业在搭建微服务架构时面临阻碍。

为了能帮助更多企业快速构建微服务，2021 年 9 月，字节开源企业级云原生微服务架构的中间件集合 CloudWeGo，其中 CloudWeGo-Kitex 是一个支持多协议的 Golang RPC 框架。字节内部主要是 Thrift 协议，所以在 Thrift 协议深耕已久，做了大量优化，Kitex 开源希望能帮助其他企业快速构建微服务，但 Kitex 基于 gRPC 协议采用 Istio - Sidecar 解决方案存在上述问题，同时也希望使用 Thrift 协议的用户能基于 Istio 实现服务治理。

2023 年 5 月 28 日，GOTC2023 全球开源技术峰会 “Cloud Native Summit” 分论坛将在上海浦东新区张江科学会堂举办，CloudWeGo Reviewer & 火山引擎云原生资深研发工程师 - 胡文将分享 《基于 Kitex Proxyless 和 Istio 的云原生微服务实践》，除了介绍 Kitex Proxyless 实现细节和原理外，也会介绍实现中的问题以及如何解决。

Kitex Proxyless 期望可以满足一些对性能比较敏感的业务方诉求，也同时丰富服务网格在统一治理平面、异构数据面场景下的部署形态。此外，CloudWeGo-Kitex 目前已支持腾讯云微服务引擎 TSE 、阿里云微服务引擎 MSE & ARMS 链路追踪、华为云微服务引擎 CSE。CloudWeGo 也完全支持与公有云 PaaS 支持对接，兼容适配。除 Kitex，CloudWeGo 还包含 Kitex、Hertz、Volo、Netpoll、Shmipc 等多个重点子项目，上至框架下至基础库均是自研，并围绕这些项目，构建起了完整的生态。这些项目共同的特点是高性能、高扩展性、高可靠，专注于微服务通信与治理。

CloudWeGo 鼓励所有感兴趣的开发者参与贡献，这些贡献者来自各行各业，遍布国内海外，覆盖企业正式职员和大学生等不同角色，累计 Contributors 已经超过 200 个。其中通过参与开源贡献晋升为 Committer 的人数为 13 个，从 Committer 晋升至 Reviewer 的人数为 4 个。

未来，CloudWeGo 也将持续发力开源产品和社区，与广发开发者共筑开源生态。全球开源技术峰会（Global Open-source Technology Conference），简称 GOTC，是由开放原子开源基金会、上海浦东软件园、 Linux 基金会亚太区和开源中国联合发起的，面向全球开发者的一场盛大开源技术盛宴。5 月 27 日至 28 日，GOTC 2023 将于上海举办为期 2 天的开源行业盛会。大会将以行业展览、主题发言、特别论坛、分论坛的形式展现，与会者将一起探讨元宇宙、3D 与游戏、eBPF、Web3.0、区块链等热门技术主题，以及开源社区、AIGC、汽车软件、AI 编程、开源教育培训、云原生等热门话题，探讨开源未来，助力开源发展。

编辑：黄飞