本文共 2095 字，大约阅读时间需要 6 分钟。
Dubbo底层是使用netty这样的NIO框架，是基于tcp协议传输，配合以hessian序列化完成rpc通信
Dubbo是一个分布式、高性能的rpc框架。Rpc值远程调用协议，也就是两个服务器交互数据。
单一应用框架：网站流量很小时，只需要一个应用，将所有功能都部署在一起即可。
垂直应用架构：访问量逐渐增大，单一应用按照业务拆分成多个应用以提升效率。此时用于加速前端页面开发的web框架是关键。
分布式服务框架：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽离出来，作为独立的服务逐渐形成稳定的服务中心，使前端应用能更快的响应多变的市场需求。 此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
流动计算框架：当服务越来越多，容量的评估，小服务器资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的**资源调度和治理中心（soa）**是关键。
微服务架构：将一个个的小功能做成服务。用SpringCloud来进行统一管理。
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需要简单配置，没有任何api侵入。
软负载均衡及容错率机制，可以内网替代F5等硬件负载均衡器，降低成本。
注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务的提供者。
Provider:暴露服务的服务提供方
Consumer:调用远程服务的服务消费方
Registry：服务注册与发现的注册中心
Monitor：统计服务的调用次数和调用时间的监控中心
Container：服务运行容器
Provider绑定指定端口并启动服务
提供者连接注册中心，并发布本地ip、端口、应用信息和提供服务信息发送至注册中心存储。
Consumer订阅zookeeper注册中心
注册中心根据消费者所求服务信息匹配对应的提供者列表发送至consumer引用缓存。
Consumer在发起远程调用时，基于缓存的消费者列表选择其一发起调用。
Privider状态变更会实时通知注册中心，再由注册中心实时推送至consumer。
六、dubbo的架构设计？
服务接口层（service）
配置层（config）对外配置接口
服务代理层（proxy）
服务注册层(register)
集群层（cluster）
监控层（monitor）
远程调用层(protocol)
信息交换层（exchange）
网络传输层（transport）
Dubbo协议
Zookeeper注册中心
Multicas注册中心
Redis注册中心
Simple注册中心
可以，dubbo启动时，消费者会从zookeeper拉取注册的生产值地址和接口等数据，缓存在本地，每次调用时，按照本地存储的地址进行调用。
Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何api侵入，只需要spring加载dubbo配置即可，dubbo基于spring的schema扩展进行加载。
默认NIO netty框架
RandomRobin loadBalance：随机选取提供者策略，有利于动态调整提供者权重，界面碰撞率高，调用次数越多，分布越均匀。
RoundRobin loadBalance：轮询选取提供者策略，平均分布，但是存在请求累积的问题。
leastActive LoadBalance：最少活跃调用策略，解决慢提供者接受更少的请求
constantHash LoadBalance：一致性hash策略，使相同参数请求总是发到统一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动。
缺省时为random随机调用。
Failover cluster：失败自动切换，当出现失败，重试其他服务器通常用于读操作，但重试会带来更长迟延。
默认使用Hession序列化，还有dubbo、fastjson、java自带序列化
Dubbo在调用服务不成功时，默认会重试两次。
Spring cloud
Dubbo是soa时代产物，它的关注点主要在于服务的调用，流量分发，流量监控和熔断。
spring cloud诞生微服务架构时代，考虑的是微服务治理的方方面面，是一个生态
转载地址：http://mugpb.baihongyu.com/