RPC框架关键指标

• 稳定性(保障策略)

  • 熔断

    • 在底层服务相应超时后，为了防止上层服务调用时堆积大量请求而宕机，这个时候就需要熔断，防止被调用的部分影响整个链路

  • 限流

    • 调用端发送请求到服务端，服务端需在执行业务前执行检查限流逻辑，若访问量过大超出限流条件，让服务端直接降级处理或返回给调用方一个限流异常。

  • 超时控制

    • 当下层的服务由种种原因响应过慢，下层服务直接主动停掉一些不太重要的业务，释放出服务器资源，避免浪费

  • 请求成功率

    • 实现负载均衡和重试就可以提高请求成功率，但是重试有放大故障的风险，会加大直接下游的负载(防止重试风暴，限制单点重试和限制链路重试)
    • 

  • 长尾请求

    • 响应时间明显大于平均的请求(P99标准)
    • 

• 易用性

这些增强稳定性的策略，主要通过注册中间件来实现(开箱即用，有轮子。Kitex使用Suite来打包自定义的功能，提供一键配置基础依赖)

• 扩展性

  提供很多的扩展，Middleware、Option、编解码层、协议层、网络传输层、代码生成工具插件这些都能扩展 一个请求发起首先经过治理层面，治理相关的逻辑封装在Middleware中，而一个个Middleware会构造成一个有序调用连接逐个执行，比如服务发现路由、负载均衡、超时控制等，mw执行后进入remote模块完成与远端的通信

• 观测性

  对于观测性，传统的Log、Metric、Tracing三件套有点不满足于框架，有些框架自身需要暴露出来，例如当前的环境变量、配置、Cient/Server初始化参数、缓存信息等

• 高性能

  • 高吞吐、低延迟(有时更重要)
  • 多路复用(大大减少链接带来的资源消耗，并提升了服务端性能，能提高了吞吐30%呢)
    • 非连接多路复用,每个请求持有一个链接,直到请求结束才会被关闭或者放入连接池复用,并发量与连接数是对等的关系。
    • 连接多路复用,所有请求都可以在同一个连接完成,二者对比一下连接资源利用上的差异。