error errorreporter( 三 )


服务注册与发现

Kitex 并不提供默认的服务注册发现,体现了框架的中立特征 。Kitex 支持自定义注册模块和发现模块,使用者可自行扩展集成其他注册中心和服务发现实现,该扩展分别定义在 Pkg/Registry 和 Pkg/Discovery 下 。


Kitex 服务注册扩展接口如下所示,更多详情可以查看官网框架扩展 -> 服务注册扩展 。
type Registry interface {Register(info *Info) errorDeregister(info *Info) error}复制代码


Kitex 服务发现扩展接口如下所示,更多详情可以查看官网框架扩展 -> 服务发现扩展 。


type Resolver interface {Target(ctx context.Context, target rpcinfo.EndpointInfo) stringResolve(ctx context.Context, key string) (Result, error)Diff(key string, prev, next Result) (Change, bool)Name() string}复制代码


截止日前,Kitex 已经通过社区开发者的支持,完成了 ETCD、ZooKeeper、Eureka、Consul、Nacos、Polaris 多种服务发现模式,当然也支持 DNS 解析以及 Static IP 直连访问模式,建立起了强大且完备的社区生态,供用户按需灵活选用 。


error errorreporter

文章插图



特别鸣谢 @li-jin-gou @liu-song @baiyutang @duduainankai @horizonzy @Hanson 等几位社区贡献者对上述服务发现扩展库的实现与支持 。(更多代码详情可以查看:
https://github.com/kitex-contrib)
熔断

前面介绍了 Kitex 服务注册与发现机制,这一点对于业务接入框架非常重要,缺少这一环节微服务之间无法实现互通 。那么熔断对于微服务有什么作用呢?


在微服务进行 RPC 调用时,下游服务难免会出错,当下游出现问题时,如果上游继续对其进行调用,既妨碍了下游的恢复,也浪费了上游的资源 。为了解决这个问题,可以设置一些动态开关,当下游出错时,手动的关闭对下游的调用,然而更好的办法是使用熔断器,自动解决这个问题 。


Kitex 提供了熔断器的实现,但是没有默认开启,需要用户主动开启后即可使用 。


Kitex 大部分服务治理模块都是通过 Middleware 集成,熔断也是一样 。Kitex 提供了一套 CBSuite,封装了服务粒度的熔断器和实例粒度的熔断器 。


  • 服务粒度熔断:按照服务粒度进行熔断统计,通过 WithMiddleware 添加 。服务粒度的具体划分取决于 Circuit Breaker Key,即熔断统计的 Key,初始化 CBSuite 时需要传入 GenServiceCBKeyFunc 。默认提供 circuitbreaker.RPCInfo2Key,该 Key 的格式是 fromServiceName/toServiceName/method,即按照方法级别的异常做熔断统计 。
  • 实例粒度熔断:按照实例粒度进行熔断统计,主要用于解决单实例异常问题,如果触发了实例级别熔断,框架会自动重试 。


熔断器的思路很简单:根据 RPC 成功或失败的情况,限制对下游的访问 。通常熔断器分为三个时期:CLOSED、OPEN、HALFOPEN 。当 RPC 正常时,为 CLOSED;当 RPC 错误增多时,熔断器会被触发,进入 OPEN;OPEN 后经过一定的冷却时间,熔断器变为 HALFOPEN;HALFOPEN 时会对下游进行一些有策略的访问,然后根据结果决定是变为 CLOSED,还是 OPEN 。总的来说三个状态的转换大致如下图:


error errorreporter

文章插图



关于 Kitex 熔断器实现的更多细节和原理,可以查看官网基本特性 -> 熔断器章节 。
限流

如果说熔断是从客户端出发保护调用链,以防止系统雪崩,那么限流则是一种保护服务端的措施,防止上游某个 Client 流量突增导致 Server 过载 。


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