dubbo产生和原理

dubbo产生

关于dubbo的使用场景，这个要从系统的演变开始将起，既然dubbo的使用很多是在电商系统中，那么就从电商系统的演变开始讲起。

     一个简单的电商网站说起，它可能包含如下的几个模块和功能，如首页、detail页、list页、下单页、支付页以及后台管理等页面和功能。单一的系统架构，使得在开发过程中，占用的资源越来越多，而且随着流量的增加使得维护起来越来越难以维护。

      

于是就产生了垂直应用架构，垂直应用架构解决了单一应用架构所面临的扩容问题，流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。但是在垂直架构中相同逻辑代码需要不断的复制，不能复用。所以分布式系统就这样应运而生了。

      

    公共的逻辑业务提取出来形成服务，对外提供。这样对于维护和升级都只需要切分成一个一个的小系统去维护，也可以让前端业务系统与底层数据访问分离，团队分工更为明确。

      

    分布式系统所依赖的基础设施包括服务框架、消息中间件、数据访问中间件、配置中心、分布式缓存系统、持久化存储(关系数据库、nosql数据库)、搜索引擎、CDN网络、负载均衡系统、运维自动化系统、硬件虚拟化及镜像管理系统、分布式文件系统、日志收集系统、监控系统、离线计算、实时计算、数据仓库等等。随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA -----Service-Oriented Architecture)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。

    就这样为分布式系统的服务治理框架就出现了，dubbo也就这样产生了。dubbo在整个分布式系统的架构中，按照分层的架构来架构，使得各个层级之间最大限度的松耦合.

dubbo和mq的区别

两者都可以解耦合

dubbo

1，rpc的分布式集群支持：负载均衡是对外提供一个公共地址，请求过来时通过轮询、随机的形式来分摊压力，挂一台补一台

2，结合zookeeper解藕：(提供者注册和消费者订阅)客户端和服务端启动的时候都会把自己的机器IP注册到zookeeper上。客户端会把zk上的服务端ip拉到磁盘上，并记录哪些ip提供哪些服务（服务端启动的时候暴露给zk）。

然后调用的时候客户端会根据ip调用服务端的服务，这时候即使zk挂掉也没关系。

3：长连接通讯：nio通信抽象封装（暂时没接触）

可用场景：

1，商城做活动流量暴涨：防止系统崩掉 可以通过dubbo来控制访问量

2，分布式服务器rpc过程调用压力分担

mq一个点对点一个是分布式订阅

mq的2个好处是

1，消息不丢失：服务之间端掉消息会保存到mq中间件中，当消费者服务器恢复后就会重新发过去，消息不会丢失

2，异步处理：比如一个商城用户购买产品后后台会去更新数据库然后响应给客户端，如果在高并发的情况下，

这样更新数据库响应客户端会变慢，可以使用mq消息队列的消费者进程中获取数据来进行异步写数据，由于消息对垒的服务处理速度远快于数据库，

因此响应延迟能得到有效改善

 

 

应用架构

本篇博文的产生背景，在阅读阿里巴巴开源的Dubbo用户应用时，其论述到了随系统复杂度的增长，系统架构的变化和侧重点：

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。