Dubbo——微服务框架（单体式-＞分布式-＞微服务）

是什么？

Dubbo是阿里巴巴开源的基于Java的高性能RPC（一种远程调用）分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。；

每天为2千多个服务提供大于30亿次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点以及别的公司的业务中；

简单的来说，Dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只是在分布式的时候才有Dubbo这样的分布式服务框架的需求；

并且本质上是个远程服务调用的分布式框架（告别Web Service模式中的Wsdl，以服务者与消费者的方式在Dubbo上注册）

Dubbo官网：Apache Dubbo

核心组件

• Remoting: 网络通信框架，实现了 sync-over-async 和 request-response 消息机制.

• RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能

• Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

工作原理

1. 生产者启动Dubbo容器，生产服务对象

2. 生产者把生成的服务发布到注册中心

3. 消费者向注册中心订阅服务，把发布的服务，下载到本地缓存，订阅服务后，本地缓存会自动更新生产者发布的服务

4. 当消费者需要调用服务时，按照RPC协议要求，向生产者发起服务的调用

5. 生产者把返回的对象交给Dubbo容器进行序列化处理后返回给消费者

6. 消费者接收到返回的数据后对其反序列化，得到Java对象

7. 监视器对服务性能做监控统计

注意：注册中心和监视器都不是必须的，可以缺少。如：缺少注册中心后消费者就不能自动更新生产者发布的服务信息，当生产者信息发生改变时，消费者很可能调用服务失败。比较出名的注册中心有zookeeper，eruka

我们的生产者服务在注册中心注册并被消费者拉取到之后，该生产者会在本地做一个缓存，因此即使后续注册中心挂掉了，只要之前消费者是调用过该服务的，那么消费者依旧可以在本地缓存中拉取到生产者服务；

为什么？

系统架构的演变史

B/S软件架构的出现标志着web开发时代的到来，当初应用都是比较简单，功能单一，访问量少。这些因素就决定了当年的应用结构是比较简单的

 随着家用电脑的普及，互联网的兴起，上网的人越来越多，逐渐显得简单的架构无法支撑应用程序的正常运行，软件科学家们就开始探讨如何去设计软件的架构，最初比较突出的两大问题在于1台服务器无法保证应用程序和数据库程序两个老虎的性能，科学家就提出把应用程序和数据库程序分别安装在2台服务器中，通过网络来进行数据传输，再通过应用程序中加本地缓存的方式来解决不常变动数据的查询性能问题，此时出现了最早期的分布式系统架构

 伴随着大数据时代的到来，这种简单是分布式系统架构也开始扛不住了，服务器宕机，成了常见的事情，科学家又开始探索，如何提高系统的稳定性和可用性，于是提出了，应用服务集群和数据库服务器集群，通过负载均衡的方式来维持系统的高可用和稳定性，以应对这个时代的高并发

 在某些业务中，关系型数据库明显不适合，如：点赞，评论，全文检索等。这些业务场景使用关系型数据库来完成会严重的影响数据库的性能，科学家们又拓展出非关系型数据库（NoSQL），用于项目中的某个特殊的业务场景，去弥补关系型数据的短板，此时这样的系统架构基本满足当前时代下的需求

 微服务应用演变史

JavaEE应用三层架构，取得巨大成功后，在很长的一段时间内，都没有出现过问题，直到大数据时代的到来某些数据量巨大的公司开始遇到了新的挑战。某些业务方法频繁调用，需要配置大量的资源，某些业务方法很少调用，只需配置少量资源，如：商城应用中的服务

 在商城的应用中，订单服务，积分服务，商品服务的使用频率远远大于其他服务，如果仅仅通过布置多台服务器的方式来缓解压力的造成的问题，此时会造成服务器成本的大量提升，并且资源得不到充分的利用，造成浪费，遇到某个关系型数据库不好处理的业务场景，在技术选择的时候也要充分去考虑系统稳定和冲突问题，于是科学家们又探索出基于服务的分布式应用架构，服务拆分越细，数量就越多，这种应用架构就是当下最热门的微服务应用架构。目前比较成熟，社区活跃的微服务框架有Dubbo，SpringCloud

• 生产者：提供业务逻辑实现的角色，对外提供服务

• 消费者：调用生产者提供的服务，使用其业务功能

如：订单服务器和商品服务分别对外提供了操作订单和商品的业务功能，此时它们都属于生产者，但是订单服务在查询订单的时候需要去获取当前订单有哪些商品，因此订单服务就要调用商品服务提供的功能，所以订单服务又是商品服务的消费者，表现层相关组件直接生产者提供的服务，因此它们都是消费者。服务间的调用都是使用RPC远程调用协议

微服务应用的优势

• 降低系统的耦合度

• 服务器之间都是相互独立，互补干扰，此时每个服务都能更好的选择符合业务场景的技术

• 充分使用服务器的硬件资源，避免造成不必要的浪费

• 降低维护成本和难度

• 提高应用系统的稳定性

分布式和微服务的区别

分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用

简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。

RPC协议调用原理

序列化和反序列化

序列化：把Java对象转变为二进制数据（需要在本地磁盘存储或者需要在网络中进行传输）；

反序列化：把二进制数据转变为Java对象；

流程

RPC远程调用底层的核心技术就是序列化和反序列化；

1.生产者发布服务；

2.消费者按照RPC协议要求生产者发布的服务；

3.生产者执行方法得到返回的对象；

4.生产者把对象序列化后返回给消费者；

5.消费者接收到数据后对其反序列化，得到Java对象；

Dubbo项目拆分

项目结构

从以上图中我们不难看出，我们至少需要创建5个项目

• product-api：定义商品相关的业务方法

• member-api：定义会员相关的业务方法

• product-sever：商品服务的提供者，同时也是会员服务的消费者，底层会去调用会员服务的相关功能

• member-sever：会员服务的提供者，提供会员业务方法的实现

• website：商品服务的消费者，使用商品服务提供的业务功能

  Zookeeper

  zookeeper的功能非常多，是大数据技术领域的核心组件之一，但是我们这里用不到那么多的功能，仅仅只是作为注册中心来使用一下

  注意：没有注册中心的情况下，Dubbo也是可以正常的运行的文章来源地址https://www.toymoban.com/news/detail-448830.html

到了这里，关于Dubbo——微服务框架（单体式-＞分布式-＞微服务）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！