分布式服务框架的服务调用

在分布式服务框架中某一个服务是否可用对消费者而言并不重要，最终的服务调用成功才是最重要的

1）通信链路故障

  a.通信过程中，对方突然宕机

  b.对方解码失败等原因rest掉连接，导致链路中断

  c.消费者read socketChannel发生IO异常，导致链路中断

  d.消费者write socketChannel发生IO异常，导致链路中断

  e.通信双发因心跳超时，主动关闭连接

  f.通信过程中网络发生闪断

  g.通信过程，交换机发生异常导致链路中断

  h.消费者或者服务提供者发生长时间的full gc导致链路中断

2）服务端超时

  a.服务端的IO线程未从网络中读取到客户端请求消息，导致问题的原因通常是IO线程意外阻塞或执行长周期操作

  b.服务端业务逻辑处理缓慢，或者长时间阻塞，如查询没有索引的数据库，导致全表查询，耗时较长

  c.服务端发生长时间的full GC导致所有的业务暂停运行，无法及时返回应答给客户端

3）服务端调用失败

  a. 服务端解码失败会返回消息解码异常

  b.服务端发生动态流控，返回流控异常

  c.服务端消息队列积压异常率超过最大阈值，返回系统拥塞异常

  d.访问权限校验失败，返回权限相关异常

  f.违反SLA策略，返回相关异常

  g.其它系统异常



容错策略：

1）failover：失败切换新的链路，场景：读操作(天然幂等操作)、幂等性服务(保证1-N次服务调用的结果相同)

2）failback：失败通知、记录异常，人工处理

3）failcache：失败缓存、等待一定周期之后自动重试，直到server可以正常服务

场景：服务有状态路由，定点发送到服务提供者

     对时延要求不敏感的服务 eg 通知类服务

注意：缓存时间和缓存上限的控制，防止内存溢出

      用户是否可以自定义缓存淘汰算法

      定时重试的周期T，重试的最大次数等是否支持用户自定义

异步服务调用：

1）增加监听器，结果返回之后，主动推送到客户端

2）客户端定时去轮询

异步调用化串行为并行，提升服务效率，减少业务阻塞时间，避免线程阻塞

服务调用的选择：

1）降低业务E2E延时，业务调用链过长、某些服务不太可靠？试试可不可以通过并行服务调用来提升效率

2）可靠性角度：若某些业务调用链上的关键服务不太可靠，一旦出现故障会导致大量资源被挂住，可以考虑异步服务调用，防止故障大量扩散

3）传统RPC调用使用比较简单，对时延要求不高的可以考虑使用同步服务调用