sofa rpc介绍

服务发布与引用

• 作为一个对外发布的服务，主要有两个维度信息，接口与协议，sofarpc发布服务的时候也是需要指定这两个信息
• 服务发布不仅能配置多个协议、而且能够发布到多个注册中心
• 发布接口的时候，是直接指定一个接口类的class的方式。这种与thrift这种需要定义个IDL，然后编译的方式比简单很多。但问题就是如果跨语言调用的时候，可能需要重新写一遍接口（IDL可以直接服用IDL生成其他语言客户端）。
• 如果需要跨语言调用，最直接的方式是使用泛化调用（调用的过程中带着参数类型）

通信协议

• 支持多种协议、bolt、resetful（restful也是协议？）、dubbo、h2c（二进制协议，解决http1.x的多路服用，优先级等问题）、http（对应序列化为json）
• 协议不只是序列化，包括连接建立、心跳、链路监控等功能，bolt可以进行序列化的配置，hessian2和protobuf。有些协议包含了序列化过程比如二进制协议dobbo

注册中心

• 支持SOFARegistry、Zk、本地文件、Consul、Nacos，缺了个Euraka，基本上常见能支持的都支持了

自定义过滤器

• “SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户自定义 Filter 扩展，自定义 Filter 的执行顺序在内置 Filter 之后。”但没有说优先级的问题，多个用户自定义的优先级是如何？api的方式还能通过list中的顺序（是么）作为个优先级，注解的方式如何确定优先级？
• 与Zuul中的Filter概念有些类似，只不过Zuul中的Filter有优先级的概念

自定义路由寻址

• “SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。”通过这方式能自定义负载均衡策略。
• 同样的没有说优先级的问题，多个用户自定义路由寻址优先级是什么？

调用重试

• “重试只有在发生服务端的框架层面异常或者是超时异常才会发起。如果是业务抛出异常，是不会重试的。默认情况下 SOFARPC 不进行任何重试。请注意：超时异常虽然可以重试，但是需要服务端保证业务的幂等性，否则可能会有风险”，默认不重试，大多数情况下，失败一次再次重试也不会成功。
• 区分框架异常、业务异常很重要，但是绝大多数情况下，框架层面出现异常的场景不多，而业务异常大多数场景下重试也没有什么用

链路追踪

• “在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能”
• “SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能”

链路数据透传

• “链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。”，在服务内部如果要继续透传需要在新的线程中设置新的上线文，实现应该是一种ThreadLocal的方式
• 链路追踪中主要是调用的入参、出参信息，对业务是透明的。而透传可以理解为是使用跨服务的ThreadLocal，是和业务相关性比较大的

预热权重

• 能够指定预热阶段的流量的权重（会与其他服务一起合并进行计算权重）、预热的时间
• 想到另外一个问题，如何判断预热已经完成？因为场景不多，所以

容灾恢复

• 有默认的支持和Hystrix的支持两种
• 与Hystrix相比，都有一个leastWindowCount（多少次功能生效）、滑动窗口统计方式。但多了一些功能，如支持了逐步减小降级有降级比例和恢复比例的概念，而不是Hystrix那样一下子就没了全部流量；有降级的最小权重（不是一下子搞死）、降级最大IP数，这两个功能感觉很实用，在一些场景下如果服务出现问题因为目前大多数服务是无状态的，跑在云上配置基本基本都是一样的，很多时候一个后端节点出现问题，是后端都会有问题，如果没有这两个参数支持，很容易出现一个共性问题出现的时候，所有的服务进行降级，导致整个功能不能用。
• 还有个参数：“时间窗口内异常率与服务平均异常率的降级比值：在对统计信息进行计算的时候，会计算出该服务所有有效调用ip的平均异常率，如果某个ip的异常率大于等于了这个最低比值，则会被降级。”，这个参数也能避免上述说明的情况，避免后端大面积降级的场景。

优雅关闭

• 服务端优雅关闭，重要的是在关闭之前需要处理完成未完成的请求，RPC作为客户端也是如果有个请求还没有Response需要等待一段时间

参考

SOFA-prc