Dubbo学习脑图整理

为什么80%的码农都做不了架构师？>>>   

在线预览：http://naotu.baidu.com/file/2fa2533cecb78d0ff8c66459c980edfd?token=ac60101c33bef2e8

xmind 文件下载：
下载

** 禁止转载！**

#内容概述

架构演变

1. 单一应用架构

2. 垂直应用架构

3. 分布式服务架构

4. 流动计算架构

配置

1. dubbo:service/：服务配置

2. dubbo:reference/：引用配置

3. dubbo:protocol/：协议配置

4. dubbo:application/：应用配置

5. dubbo:module/：模块配置

6. dubbo:registry/：注册中心配置

7. dubbo:monitor/：监控中心配置

8. dubbo:provider/：提供方的缺省值

9. dubbo:consumer/：消费方缺省配置

10. dubbo:method/：方法配置

11. dubbo:argument/：用于指定方法参数配置

架构

角色

1. Provider: 暴露服务的服务提供方

2. Consumer: 调用远程服务的服务消费方

3. Registry: 服务注册与发现的注册中心

4. Monitor: 统计服务的调用次调和调用时间的监控中心

5. Container: 服务运行容器

流程说明

1. 服务容器负责启动，加载，运行服务提供者

2. 服务提供者在启动时，向注册中心注册自己提供的服务

3. 服务消费者在启动时，向注册中心订阅自己所需的服务

4. 注册中心返回服务提供者地址列表给消费者

5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用

6. 服务消费者和提供者定时每分钟发送一次统计数据到监控中心

连通性

1. 注册中心负责服务地址的注册与查找

2. 监控中心负责统计各服务调用次数，调用时间等

3. 服务提供者向注册中心注册其提供的服务

4. 服务消费者向注册中心获取服务提供者地址列表

5. 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

6. 注册中心通过长连接感知服务提供者的存在

7. 注册中心和监控中心全部宕机 消费者在本地缓存了提供者列表

8. 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

集群容错

1. Failover Cluster（故障转移）
2. Failfast Cluster（快速失败）
3. Failsafe Cluster（失败安全）
4. Failback Cluster（失败自动恢复）
5. Forking Cluster（并行调用多个服务器）
6. Broadcast Cluster（广播调用所有提供者）

负载均衡

1. Random LoadBalance
2. RoundRobin LoadBalance
3. LeastActive LoadBalance
4. ConsistentHash LoadBalance

线程模型

Dispatcher

1. all、
2. direct、
3. message、
4. executio、
5. connection

ThreadPool

1. fixed
2. cache
3. limited

特性

1. 这里是列表文本 绕过注册中心直接调用生产者

2. 只订阅

3. 只注册

4. 静态服务

5. 不同服务可使用不同协议。如rmi、dubbo协议等

6. 多注册中心

7. 服务分组

8. 多版本

9. 在低压力时间段，先升级一半提供者为新版本

10. 再将所有消费者升级为新版本

11. 然后将剩下的一半提供者升级为新版本

12. 分组聚合

13. 支持JSR303参数验证

14. 结果缓存

15. lru：基于最近最少使用原则删除多余缓存，保持最热的数据被缓存

16. threadlocal：当前线程缓存

17. jcache：与JSR107集成，可以桥接各种缓存实现

18. 隐式传参

19. 并发控制，限制执行某方法的线程数量

20. 连接控制，限制服务器端接受的连接不能超过某值

21. 令牌验证

转载于:https://my.oschina.net/giegie/blog/1456745