浅谈Dubbo

Posted 2021-04-05 琉珞凡间

                                        后台回复【在吗】，每天一句话陪你

1

导读

这几年来技术发展特别快，微服务一词也是比较热门，行内行外的都津津乐道。今天要记录的主角Dubbo是其中的一员，但是它可不能完全代表微服务，Dubbo是基于面向服务的架构体系(SOA)，而微服务其实是SOA某种程度上的扩展。是一种架构风格，新的准则，有兴趣的话可以查看martin fowler写的有关论文。

2

Dubbo的结构

首先有一个Container,它是服务运行容器

它启动之后会加载各种Provider

服务提供者

这些Provider会把自己 注册(register) 到注册中心(Registry)

而有了服务提供者

就会有服务消费者(Consumer)

这些Consumer就会 订阅(subscribe) 注册中心的内容

当注册中心有什么服务可以提供时，就会去通知(notify) 服务消费者

服务消费者收到通知之后，就会去去找对应的服务提供者，而Monitor就是一个监控中心

它们的结构还有点像消息队列

整个过程也可以比喻为一个相亲过程

服务提供者比作男方，服务消费者比作女方，当男方想找女朋友时可以去婚介所(注册中心)登记自己的信息

于是你就可以去寻找ta，有一场美丽的邂逅

而monitor就像是幕后的"boss",它负责监控这一过程

3

为什么需要Dubbo呢?

这里记录一下这个技术是怎么来的

我们最早编写一个应用时

往往都把所有的模块都集中在一个应用程序上，并打成一个 (jar/war) 包部署到线上。(反正我是这样)

这个方法有个明显的好处，开发简单，无需考虑太多后期维护的东西

使用现在市面上的SpringBoot可以快速开发出一个小型应用,这种架构也被成为单一应用架构

但是缺点也是很明显的

比如有一天要修改某一个需求，改完之后就要重新打包部署，比较麻烦

因为需求这东西，改动挺频繁的

而且当应用访问流量大了之后，这样子的架构就有点吃不消，因为流量都往一台机器上顶，谁抗的住啊

于是慢慢出现了一种架构思想，垂直应用架构

这个架构说白了就是把编写好的出现打包部署到多个服务器上

底层通过一些硬件负载均衡来决定它们的工作调配问题

这样流量就从原来的都往一个服务器走，变成分散开往几个服务器走，流量问题解决了

随着服务器越来越多，服务器之间的调用关系越来越复杂

服务的调用量越来越大

服务的容量问题就暴露出来，这个服务需要多少机器支撑？

什么时候该加机器？

它们之间的启动顺序也有讲究

不同的服务器之间还不能乱了"辈份"…这就导致了内部负载均衡器压力也陡增。

没关系，这个社会就是被需求所推动的嘛

于是出现了新的架构:面向服务的架构体系(SOA)

将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心,同时增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率

Dubbo就是基于该体系的实现框架

它在整个分布式系统的架构中，按照分层的架构来架构，使得各个层级之间最大限度的松耦合

                          （部分图片源自网络，如有侵权，请联系作者删除）

   做一个开心的人