error errorreporter( 五 ) _「广东龙网」

// Tracer is executed at the start and finish of an RPC.type Tracer interface {Start(ctx context.Context) context.ContextFinish(ctx context.Context)}复制代码

【error errorreporter】Kitex 的监控打点、Metrics 上报以及链路追踪，都可以通过上述接口进行扩展。

目前 Kitex-contrib 组织下提供了 Prometheus 的监控扩展，OpenTracing 的链路追踪扩展，以及 OpenTelemetry 可观测性全家桶（Metrics + Tracing + Logging）扩展实现，用户可以按需接入相应的扩展。
微服务框架与服务网络

服务框架是传统微服务技术的核心所在。早期微服务技术中的服务注册、发现、调用、治理、观测都离不开服务框架。这也带来了一些问题，比如业务研发者需要感知并使用服务框架的服务治理能力，框架版本升级困难，框架越来越重难于维护等等。

服务网格（Service Mesh）是将无侵入服务治理定义的更为深入的微服务架构方案，被称为第二代微服务架构。通过将微服务治理能力以独立组件（Sidecar）整合并下沉到基础设施，服务网格可以实现应用业务逻辑与服务治理逻辑完全分离，这也使支持多语言、热升级等高阶特性变得顺理成章。

文章插图

进入云原生时代，随着服务网格技术的逐步发展，我们也要用发展的眼光进行架构规划和设计，微服务框架和服务网格未来必定会是并存的，统一组成服务治理体系。在字节跳动，服务治理体系就是由服务框架和服务治理组成。以 Golang 服务为例，CloudWeGo 提供业务强相关、强侵入的服务治理，字节 Service Mesh 提供业务弱相关、弱侵入的服务治理，相互搭配，相互协商，既解决了业务开发所需的脚手架和开发模式，又让服务治理的接入更加容易。

与此同时，在服务网格和服务框架同时使用的场景下，服务框架必须要支持灵活卸载治理能力，服务网格也需要保证功能的稳定性。在未来技术的演进方向上，服务框架也主要专注于编解码、通信效率、多协议支持等方面，而服务网格则可以深入更多无侵入的服务治理功能研发中。

此外，在大规模场景下，针对服务治理新功能的研发需求决策，我们往往还需要考虑以下因素：

性能: 大部分业务很在意，也是团队一直努力的重点；
普遍性: 需要评估是不是所有业务都需要的能力；
简洁: 通俗说，我们不太希望引入太多的线上问题或者太复杂的使用说明文档；
ROI：功能迭代、产品升级需要考虑整体投资回报率。

CloudWeGo 的开源之路

文章插图

字节内部版本的 Kitex 是依赖于开源版本的 Kitex，因此可以理解为 Kitex 内外同源，不存在两个 Kitex 。
为什么开源？

回到开篇的问题，为什么要创造一个新的项目，并且开源 CloudWeGo 呢？

首先，CloudWeGo 里面的项目都是在字节内部经过大规模落地实践验证的，开源后每个功能的迭代也都是第一时间在内部使用验证过的，是一个真正的企业级落地项目，开源用户和字节内部业务使用的是同一套服务框架；其次，CloudWeGo 提供的功能，尤其是协议支持和服务治理，都是能解决真实业务痛点的，每一行代码优化都能实实在在地提升用户服务的性能；最后，CloudWeGo 的研发也借鉴了一些知名开源项目的设计思路，同时也依赖一些开源项目的实现，我们把 CloudWeGo 开源出去也是为了回馈社区，给开源社区贡献一份力量。

特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。