CloudWeGo 开源版本和字节内部使用版本有什么差异？企业用户常见问题 FAQ

CloudWeGo
618 阅读8分钟

CloudWeGo 是一套由字节跳动开源的、可快速构建企业级云原生架构的中间件集合，专注于微服务通信与治理，具备高性能、可扩展、高可靠的特点。自 2021 年 9 月正式开源以来，截止日前，总计收获了近 9000 个 Star，也受到了诸多企业用户的关注，森马、华兴证券已经将 CloudWeGo 相关项目用在了生产环境，见往期文章：华兴证券：混合云原生架构下的 Kitex 实践，Kitex 在森马电商场景的落地实践。除此之外，诸多企业用户也已经或在生产环境使用，或正在测试环境中进行测试与试用。在与诸多企业用户沟通和交流中，发现一些问题比较通用，于是整理成文，供有需要的用户阅读和参考。

问题一：开源版本的 Kitex 和 Hertz 和字节内部使用的有什么差异吗？

图片

在内外版本维护层面，Kitex 和 Hertz 的行为保持一致。

问题二：CloudWeGo 是否可以提供一个比较全面的微服务解决方案？

首先，从项目定位来说，Kitex 和 Hertz 都是开发框架，详见文章字节跳动自研高性能微服务框架 Kitex 的演进之旅，字节跳动开源 Go HTTP 框架 Hertz 设计实践。而在字节内部，开发框架只是庞大的微服务体系中的一环，服务注册发现、配置管理、可观测性都由内部的系统和相关产品来统一进行支持，服务治理诸多能力更是下沉到服务网格边车中去实现，服务网格能力也在开源规划中。

Kitex 和 Hertz 开源出来后，我们基于这两个开发框架去对接业界主流的开源生态，将这一部分能力给补齐，既方便用户在自己熟悉的技术栈上面进行开发对接，又方便和业界主流公有云微服务相关产品进行集成。相关扩展库实现和生态对接见：Kitex-contrib & Hertz-contrib。

问题三：如何实现服务注册发现？

服务注册发现方面，除了默认支持 DNS Resolver 和 Static IP 外，Kitex 支持了近乎所有主流的开源注册中心：etcd，Consul，Nacos，Eureka，Zookeeper，PolarisMesh。在各个扩展仓库中，我们既提供了基于默认配置的快速接入样例，也提供了自定义配置的接入样例。

图片

后续 Hertz 也会实现主流开源注册中心的对接，相关接口不同，但是整体使用体验上面会保持一致。

问题四：如何实现配置管理？

配置管理方面，我们正在 Kitex 框架中设计和研发动态配置的能力，将实现数据源可拔插、动态加载、配置变更观测，预计将在八月份完成相关功能的开发，后续也将通过社区去对接主流配置中心。

问题五：如何实现可观测性？

可观测性方面，我们默认支持了 OpenTracing 规范，见 kitex-contrib/tracer-opentracing & hertz-contrib/tracer。也支持了 Prometheus 用于 Metrics 监控，见 kitex-contrib/monitor-prometheus & hertz-contrib/monitor-prometheus。

鉴于 OpenTracing （This project is DEPRECATED!）开源项目处于存档状态，社区也开发支持了主流的 OpenTelemetry 规范，涵盖 Tracing（链路追踪）、Metrics（指标观测）、Logging （日志）可观测性三个层面，详见：

问题六：如何实现服务治理？

  1. Kitex 自身提供一定的服务治理能力，如超时控制（RPC 超时和连接超时）、请求重试（超时重试、Backup Request，建连失败重试）、熔断器（服务粒度和实例粒度的熔断）、负载均衡（WeightedRandom、ConsistentHash）、限流（最大连接数和最大 QPS）等，用户可以按需开启和使用，详见官网文档 Kitex 基本功能页面；

  2. Kitex 目前也正在支持对接 xDS 协议，让 Kitex 服务能够以 Proxyless 的模式被服务网格统一纳管，从而丰富网格数据面部署架构形态，让用户可以在不同场景下有更多更适合特定场景的部署形态选择。同时也可以实现服务实例数据和治理配置动态更新，具体包括：添加 RouterMW，支持动态路由；扩展 Resolver 接口实现 XdsResolver，判断服务发现类型，基于 eds 获取实例信息。目前正在开发中，预计 7-8 双月内完成：github.com/cloudwego/k…

  3. Kitex 也正在对接 OpenSergo 和 Polaris 服务治理套件，用户可按需选择，以扩展的方式集成。

问题七：有没有官方的性能测试文档？

Kitex 提供的 kitex-benchmark 项目展示了 kitex 的几种简单用法, 并提供了若干对比项目。由于不同框架使用的 协议、传输模式等 存在差异，不能强行拉齐。kitex 给出了几种简单的组合，可供参考。

  • Kitex:

    • 多协议：thrift (推荐)、protobuf
    • 多传输模式：长连接池(推荐)、连接多路复用(mux)

  • 对比项目:

    • thrift 方向，暂时没有找到较为流行的对比框架，后续可以添加。
    • protobuf 方向，提供了 grpc、rpcx 作为对比项目（均使用连接多路复用）。

Hertz 提供的 hertz-benchmark 项目提供若干 HTTP 框架在 Echo 场景（以100 concurrency 和 1k Header 为例）下的性能记录。该压测数据是在调用端有充分机器资源压满服务端的情况下测试，更侧重于关注服务端性能。

除 Kitex 和 Hertz ， 网络库 Netpoll 也单独提供了 netpoll-benchmark 仓库，用于展示 netpoll 对比 evio、gnet 在 RPC 场景下的性能对比。这里所说的 RPC 场景，是为了区别于 Redis 场景，特点是处理逻辑（Handler）耗时较长，不能串行处理。因此 RPC 场景，Handler 必须要异步处理，上下文切换、I/O 协作等都是必须考虑的代价。关于 Netpoll 的设计和性能优化可以参考这篇文章：字节跳动在 Go 网络库上的实践。

问题八：在阿里云、腾讯云上都提供哪些功能的集成？后续的规划是什么？

当前支持的云上的功能见以下产品接入文档，主要支持了基于 Kitex 的服务注册发现以及可观测性相关能力，方便用户快速完成上云接入：

  1. 阿里云-如何在MSE上为Kitex应用构建服务注册中心

  2. 阿里云-Kitex接入链路追踪

  3. 腾讯云-服务治理中心-Kitex接入

  4. 火山引擎相关微服务产品正在对接中

后续将继续深入服务治理深水区合作，共同探索与实现微服务治理相关标准，基于最佳实践为用户提供更加稳定可靠的微服务能力支撑：

  1. 跨不同开发语言和技术框架，微服务治理规范OpenSergo项目正式开源

  1. Linux 下一代架构基金会宣布：联合腾讯等企业和社区，发力微服务标准化建设

Hertz 框架刚刚开源，后续我们也会排期去对接公有云微服务基础设施和开放微服务治理标准，有相关进展后再同步给大家。

问题九：熔断，限流，超时等服务治理配置是否有云控平台？

Kitex 正在对接 xDS 支持 Proxyless Service Mesh 模式，后续可将 Istio （istiod） 作为服务治理配置中心，基于 Kiali （具体使用详见 Istio 这个官方文档）或者相关云厂商提供的 Istio 云产品，可实现云端配置动态控制，支持包括配置可视化、变更、新增以及删除等操作。

目前火山引擎也有提供基于 Istio 进行优化和增强的服务网格产品 AMS（邀测中），有需要的用户后续可以建联咨询相关解决方案、申请测试账号进行试用。

图源自 istio.io

问题十：API 文档管理怎么实现？有推荐的解决方案吗？

Hertz 核心是基于 IDL 进行代码生成以及更新，IDL 中包含 HTTP 注解，可作为服务上下游对齐的文档。Hz 是 Hertz 框架提供的一个用于生成代码的命令行工具。目前，hz 可以基于 thrift 和 protobuf 的 IDL 生成 Hertz 项目的脚手架，详见 hz 命令行工具使用。

另外 Hertz 也支持了 Swagger 2.0 中间件，支持自动生成 RESTful API 文档。

问题十一：CloudWeGo 如何实现跨语言调用？如何实现 Thrift<->HTTP协议转换？

Thrift 服务不支持 HTTP 协议，但 Kitex 有对网关场景提供 http<->thrift 支持，仅限于调用端使用，见Kitex 泛化调用使用指南。

这个问题目前有两个方案:

  • 方案1：分别提供 RPC(Kitex) 和 HTTP(Hertz) 两类服务；

  • 方案2：统一提供 RPC 服务，其他语言可以使用对应协议的框架，Thrift、gRPC 均可。

项目地址

GitHub：github.com/cloudwego

官网：www.cloudwego.io

【CSG 第二期】CloudWeGo 源码解读活动 ——“Hertz 框架篇”开始啦！ 活动链接：mp.weixin.qq.com/s/GURe6BXWj…

avatar
文章
阅读
粉丝