分布式服务框架之功能模型

分布式服务框架

随着业务的扩展，应用规模不断扩大，系统内部巨无霸应用越来越多，常规的垂直应用架构无法应对复杂业务带来的各种挑战。通过将业务公告能力抽象成原子服务，对复杂应用进行水平拆分合垂直拆分，实现服务消费者和生产者的解耦，降低重复模块开发的人力成本和时间成本。

框架功能

尽管不同的分布式框架实现细节略有差别，功能特性也不近相同，但是都具有以下基本特性。

• 服务订阅与发布 ：

  • 配置化发布和引用服务：
    客户端通过xml文件配置进行服务的引用，服务端通过xml文件配置进行服务的发布，降低代码的侵入性；
  • 服务自动发现机制：
    支持服务试试自我发现，注册中心推送服务的上线下线或者地址变更，对于客户端来说服务透明化，降低消费者和服务者耦合性。
  • 服务在线注册和去注册：
    支持运行态服务的上下线，对于消费端来说，具有消息通知机制保证服务状态的更新。

• 服务路由：

  • 支持默认路由：
    例如随机,轮询，权重路由策略。
  • 路由定制:
    支持用户个性化路由策略定制。

• 集群容错：

  • FailOver机制:
    失败自动切换，当出现失败，重试其他服务器，通常用于读操作
  • Failback机制：
    失败自动回复，日志记录失败请求，定时重发，通常用于写操作
  • Failfast机制：
    快速失败，只发起一次调用，失败立即报错。

• 服务调用：

  • 同步调用：
    消费者发起服务调用后，阻塞等待服务端响应。
  • 异步调用：
    消费者发起调用以后，不阻塞立即返回，由服务端返回应答异步通知消费端。
  • 并行调用：
    消费者同时对多个服务发起调用。

• 多协议支持：

  • 支持公有协议：
  • 支持私有协议:

• 序列化：

  • 二进制序列化：
    支持Thrift, Protocol buff等二进制协议，提升序列化性能
  • 文本序列化：
    支持json,xml等文本类型的序列化方式，提升通用性和可读性。

• 统一配置管理：

  • 本地静态配置：
    安装部署修改一次，运行态不修改的配置，可以存放在本地配置文件中。
  • 基于配置中心动态配置：
    运行太需要调整的参数，统一放到哦欸之中心(服务注册中心)，修改之后同意下发，即时生效

---

系统可靠性

服务由单机应用扩展为多机集群甚至多机房调用，由于机器/网络故障等原因，都由可能导致服务调用失败，导致业务失败率增加，分布式服务框架需要具备很强的可靠性，具体措施如下：

• 服务注册中心：
  
  • 服务健康状态检测：
    注册中心通过心跳检测服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。
  • 故障切换：
    注册中心对等集群，任意一台宕机，将自动切换到另一台
  • 高可用：
    注册中心全部当掉，消费者和服务者仍能通过本地缓存进行通信。
• 消除单点故障：
  
  • 服务无状态：
  • 服务避免全局吗变量，人员一台宕机，不影响使用
  • 服务集群容错：只要就能中一台服务提供者可用，业务就不会中断。
• 网络链路健壮性：
  
  • 心跳检测：
    网络链路空闲时没有业务消息，通过定时心跳检测链路是否可用。
  • 断连重连机制：
    链路意外断连后，根据客户端配置的重连策略定时重连，重连 成功自谦消息不会路由到服务提供者上。

---

性能要求

应用分布式化以后，由原来的本地API调用变成跨进程/跨机器、甚至跨区域调用，网络通信、消息序列化和反序列化、反射调用和动态代理等都会导致性能损耗，了如果服务框架性能比较差，时延将会被方法数十倍，因此，分布式服务框架的性能指标非常重要。

指标 说明 高性能 在同等资源占用情况下，但服务提供者TPS尽量要高。 低时延 在同等资源占用情况下，服务调用时延要尽量低 性能线性增长 扩展服务提供者，性能要能够线性增长

注：

源代码见GitHub
Github博客

---

后记：纵使烟雾缭绕，我必奋然前行。