分布式服务框架设计架构原理

通常，分布式服务框架的架构可以抽象为三层：

在这里插入图片描述

1. RPC层：包括底层通信框架（例如NIO框架的封装、公有协议的封装等）、序列化和反序列化框架、用于屏蔽底层通信协议细节和序列化方式差异的Remoting框架。
2. Filter Chain层：服务调用职责链，提供多种服务调用切面供框架自身和使用者扩展，例如负载均衡、服务调用性能统计、服务调用完成通知机制、失败重发等等。
3. Service层：主要包括Java动态代理。消费者使用，主要用于将服务提供者的接口封装成远程服务调用：Java反射。服务提供者使用，根据消费者请求消息中的接口名、方法名、参数列表反射调用服务提供者的接口本地实现类。再向上就是业务的服务接口定义和实现类。

从功能角度来看，分布式服务框架通常会包含另外两个重要功能：服务治理中心和服务注册中心，业务需求不同，具体实现细节也会有很大的差异，比如HSF使用的服务注册中心是基于数据库的ConfigServer，Dubbo默认使用的是Zookeeper。

服务注册中心：负责服务的发布和通知。
服务治理中心：通常包含服务治理接口和服务治理Portal。

通信框架

长连接还是短链接

绝大多数分布式服务框架（RPC框架）都推荐长连接，因为相比短链接，长连接更节省资源，如果每发一条消息，都要创建链路、握手、关闭链路释放资源，会消耗大量系统资源。因为远程通信中调用时延是关键指标：服务化后，本地API调用变成了远程服务调用，链路层的时延消耗远远大于服务调用本身的损耗。

BIO还是NIO

在JDK1.4推出Java NIO之前，基于Java的所有Socket通信都采用了同步阻塞模式（BIO），这种一请求以应答的通信模式简化了上层的应用开发，但是在性能和可靠性方面却存在着巨大的瓶颈。
NIO采用多路复用技术，一个多路复用器Selector可以同时轮询多个Channel。

随着开源NIO框架的发展，例如Hadoop的RPC框架和实时流式计算框架Storm使用Netty作为底层通信框架。

序列化与反序列化

序列化与通信框架不是强耦合的关系，通信框架提供的编码、解码可以非常方便的支持用户通过拓展实现自定义的序列化格式。用户也可以在应用程序及其他位置实现对象的序列化和反序列化。通信框架提供的编码、解码接口可以作为可选项，并不强制用户一定要在通信框架内部实现消息的序列化和反序列化。

协议栈

不同服务在性能上适用于不同的协议进行传输，比如对接异构第三方服务的时候，通常会选择HTTP/Restful 等公有协议；对内部不用模块之间的服务调用，往往会选择性能较高的二进制私有协议。

大部分服务框架都支持多协议，但多协议不是必须的。如果是开源的分布式服务框架，会考虑协议的通用性，一般会采用例如Web Service 和HTTP之类的协议。

服务路由

分布式服务框架运行时都是集群组网，这意味着集群中存在某个服务的多个实例的部署。消费者如何选取最佳实例，这就涉及到服务的路由。

基于服务注册中心的订阅发布

透明化路由
很多开源的RPC框架调用者需要配置服务提供者的地址信息，尽管可以通过读取数据库的服务地址列表等避免硬编码地址信息，但是消费者仍然要感知服务提供者的地址信息，这违反了透明化路由的原则。

在分布式服务框架中，服务注册中心用于存储服务提供者的地址信息、服务发布相关的属性信息。
消费者通过主动查询和被动通知两种方式来获取服务提供者的地址信息，而不需要硬编码地址信息，消费者只需要知道服务，不需要知道服务提供者的位置，这就是透明化路由。

透明化路由的工作原理就是基于服务注册中心的订阅发布机制（例如Zookeeper）。

在这里插入图片描述

在该机制下，消费者和提供者与服务注册中心建立链路（如ZK建立的长连接）。

负载均衡

1. 随机
   采用随机算法实现负载均衡，通常在对等集群组网中，随机路由算法消息分发还是比较均匀的，它的缺点主要是：如果是非对等集群组网，或者硬件配置差异打，会导致各个节点负载不均衡。
2. 轮询
   按照权重轮询服务提供者列表。
3. 服务调用时延
   周期性的计算服务调用的平均时延，然后根据每个服务者的调用时延与平均时延的差值重新设计权重，保障服务时延小的接收更多的信息，防止消息堆积。
4. 一致性哈希
   一致性哈希在我以前的博客中提到过，不做赘述。

集群容错

集群服务调用失败后，服务框架需要能够在底层自动容错。下面介绍几种容错策略：

1. 失败自动切换（Failover）
   服务调用失败自动切换策略指的是当发生RPC调用异常时，重新选路，查找下一个可用的服务提供者。
2. 失败通知（Failback）
   在有些业务场景下，消费者需要知道服务调用失败的具体信息，以决定后续执行策略，如非幂等性的服务调用。
3. 失败缓存（Failcache）
   失败缓存是失败自动恢复的一种，如果重试达到上限仍然失败，则需要丢弃消息，记录一场日志。该方法适合对时延要求不敏感。
4. 快速失败（Failfast）
   在业务高峰期，对于一些非核心业务，希望只调用一次，即使失败也不重试，为其他核心服务节约运行资源。

服务降级

在大促或者业务高峰时，为了保证核心服务的SLA，往往需要停掉或者强制降级一些不太重要的服务，比如商品评论或者用户积分等等。

对非核心服务做强制降级，不发器远程服务调用，直接返回空、异常或者执行特定的本地逻辑，减少自身对公共资源的消费，把资源释放出来供核心服务使用。
屏蔽降级流程如下：

在这里插入图片描述

分布式消息跟踪

随着业务分布式架构的发展，一个功能的实现往往涉及到底层上百次的服务调用，涉及到的中间件可能包括分布式服务框架、消息队列、分布式缓存、分布式文件存储系统、分布式日志采集等等，如果无法有效理清后端分布式调用和依赖关系，故障定位将非常困难。

在传统应用软件发生故障时，往往通过接口日志手工从故障节点采集日志进行问题分析定位，分布式服务化之后，一次业务调用可能涉及到后台上百次服务调用，每个服务又是集群组网，这样效率会很慢。

如果利用调用链进行快速故障界定，通过在业务日志中增加调用链ID，可以实现业务日志和调用链的动态关联。

通过对调用链和调用路径的分析，可以识别应用的关键路径，如下图所示：

在这里插入图片描述

通过调用去向分析，可以对服务的依赖关系进行梳理：

1. 应用直接和间接依赖了哪些服务。
2. 更层次依赖的调用时延、QPS、成功率等性能KPI指标。
3. 识别不合理的强依赖或者冗余依赖。