苏宁RPC远程服务调用框架RSF.docxVIP

苏宁RPC近程服务调用框架RSF 1. 同步、异步 Future、异步 Callback 三种调用模型 同步调用：是最普遍使用的方式，使用同步调用，当前调用线程会堵塞等待服务调用前往结果或抛出特别。 异步 future：调用马上前往，当前线程不会堵塞，不会等待服务供应方执行完成。服务供应方的前往结果可以后续通过 Future get 来获得，这种调用方式在某些场景下会特殊有用，能实现并行调用服务。Future get 会堵塞当前线程，直到服务方前往结果或有特别抛出。 异步 Callback：调用马上前往，当前线程不会堵塞，不会等待服务供应方执行完成。当服务方前往结果或抛出特别时，异步执行 callback 中相应的方法。 使用 Future 及 Callback 异步调用在某些场景下格外有用，它能做到调用方的线程不会堵塞等待服务调用结果。结合一些其他的异步技术可以使得整个调用链条异步化。 2. 服务方异步前往调用结果 服务方异步前往调用结果的机制类似 Async Servlet，当前处理调用恳求的线程不前往最终结果，而是在其他线程中异步前往结果给消费方，比如服务实现方在实现服务 A 时，需要调用依靠的其他外部服务 B，假如外部服务 B 通过 Http 协议开放服务，则可以通过支持异步的 Http Client 来调用外部服务 B，然后在异步回调中前往 A 的最终调用结果。假如 B 也通过 RSF 开放服务，可以通过异步 Callback 来调用 B，在 callback 中前往 A 的最终调用结果。 处理恳求 A 的服务方线程本身不会堵塞等待 B 的调用结果，只是发起了一次异步 Http 或 RSF 调用就结束了。 通过这些异步手段，可以做到整个调用链条异步化，不会有线程堵塞（铺张）在等待服务调用结果上，从而能极大提高全体资源利用率。在线程技术还在主宰着 java 的今日，如何让线程不堵塞、少堵塞是一件很重要的事。 3. 全部服务调用相关配置统一管理，修改后实时生效 比如服务调用的超时时间、重试次数、授权、负载均衡方式、流控、熔断、成员权重、服务路由策略等等服务调用相关的全部配置，在 RSF 都不是写死在应用侧代码或配置文件中的，都是在 RSF 服务管理平台上统一管理的，并且支持修改马上生效，这一点针对线上问题干涉格外重要，可以想象一下，当一个服务消灭服务质量等问题时，想修改一个调用相关的配置，还需要发布应用是完全无法接受的。同时，这个力量还可以和监控体系有机结合起来，实现自动调控。 4. 重试及防重 当进行一次服务调用时，假如调用过程消灭可重试的特别（如网络特别，调用方资源不足），并且配置是允许重试的话，那么将发起重试。 RSF 的重试和大部分的重试设计相比，略微简单。大部分的重试设计都是包含重试的几次恳求之间是不交叉的，比如第一次恳求已经超时引发了其次次重试恳求，在其次次恳求过程中，第一次恳求结果回来了。大部分的重试设计是忽视第一次恳求结果的，由于认为第一次恳求的生命周期已经结束了。在 RSF 中则是认为第一次恳求前往的结果是有效的，这个设计的目的是尽可能的促使调用成功，但是也引发了一些简单的并发相关的问题需要处理，太过细节不再开放。 假如服务调用是冪等的，那么不管调用多少次都不会影响系统的形态，重试是平安的。但是，假如服务调用不是冪等的，那么重试就需要考虑防重的问题，RSF 中包含一些扩展点可以由用户来定义本人的防重规律，并且也自带了一个基于 redis 的默认防重实现。 5. 服务节点的自动注册和发觉 Service discovery 是服务框架中最核心的部件，这个部件的目标很明确，就是服务节点上下线 (包括扩缩容、应用发布、节点宕机等等场景) 引起服务方节点列表变更时，服务消费方能实时、精确?????的晓得。怎样达到则有各种设计，有基于中心化的如 Netflix/eureka，或者基于 ZooKeeper、etcd 的简约一点的方案，也有去中心化的方案，这个部件对数据全都性要求并不高，并不追求数据强全都性，但是如何做到牢靠格外关键，试想假如这个部件出问题，导致消费方错误的认为服务方节点全部或者大部分都下线了，会引起什么样的后果，假如是中心化的设计，则会引发全局性的灾难。 RSF 的服务节点发觉接受的是中心化的设计，但是我们认为去中心化的思路更优，由于不存在中心化架构下的中心瓶颈，出问题也不会是全局性的灾难，我们也曾基于 gossip 完整设计了一个方案，但是评估后认为实现较为简单，重点要规避的风险是任何情况下都不会引发 gossip 风暴。 RSF 的服务发觉会在本文后半部分略微深化的开放探讨。 6. 负载均衡 当消费方发起一次服务调用时，RSF 会基于随机策略优先选择当前负载低（Least Pending Req