dubbo详解

分布式与RPC

软件架构

单一应用架构

• 即将所有的功能都部署到同一个服务器中

• 优点

  • 简单易用 开发难度低 适合用于规模流量小的网站

• 缺点

  • 扩展困难

  • 不利于多人同时开发 升级维护

  • 系统的空间占用大

分布式服务架构

• 即将核心业务抽取出来 形成一个独立的服务

分布式系统

• 即将服务分散部署到若干台计算机服务器上

• RPC(Remote Procedure Call)为远程过程调用

dubbo

概述

• 是一个分布式服务框架 是一个高性能轻量级的Java RPC框架

• 主要功能

  • 面向接口的远程方法调用

  • 智能容错与负载均衡

  • 服务自动注册与发现

基本架构

• 说明

  0. 服务容器Container负责启动、加载、运行服务提供者Provider

  1. Provider在启动时向注册中心Registry注册自己所提供的服务

  2. 服务消费者Consumer在启动时向Registry订阅自己所需的服务

  3. Registry返回Provider的地址列表给Consumer 若有变更 Registry将基于长连接推送变更数据给Consumer

  4. Consumer从Provider的地址列表中基于软负载均衡算法选一台Provider进行调用 若调用失败 再选另外一台Provider进行调用

  5. Provider与Consumer在内存中会累计调用次数与调用时间并每分钟定时的发送一次统计数据到监控中心Monitor

• dubbo支持多种协议 但官方推荐使用dubbo协议 端口号默认为20880

  <dubbo:protocol name="dubbo" port="20880" />
  

直连方式

• 即消费者直接通过一不变的url来访问固定的提供者

  <dubbo:reference url="dubbo://localhost:20880" />
  

术语

• 分包

  • 即将服务接口、服务模型(实体bean)、服务异常等都放到公共包中以便提供者与消费者调用

• 粒度

  • 服务接口要尽可能的大粒度 即每个服务方法应代表一个功能而不是某个功能的某个步骤 否则将面临分布式事务的问题 且dubbo暂未提供分布式事务的支持

  • 服务接口应以业务场景为单位来划分 并对相似业务进行抽象 以防止接口数量爆炸

  • 不建议使用过于抽象的接口 如Map query(Map map) 这样的接口没有明确的语义 会给后期的维护带来诸多不便

• 版本

  • 每个提供者、消费者都应定义版本号 为后续的不兼容升级提供便利
  • 变更服务版