【Dubbo】图解Dubbo官方文档

软件架构的演进过程

❶ 单体架构

理解： 全部功能集中地挤在一个项目内。

优点： 架构很简单，开发成本低，开发周期短，因此很适合小型项目。

缺点： 全部功能挤在一起，不利于扩展和维护；单一语言技术栈；系统性能扩展只能靠集群，成本高。

❷ 垂直架构

理解： 按照业务，对单体架构进行了基础的切割。

优点： 每个子项目可以使用不同的语言技术栈。

缺点： 几乎没有改良单体架构的缺点，依旧是扩展和维护困难、提高性能只能靠集群，甚至还多了各个子项目之间会耦合的缺点。

❸ SOA架构

理解： 将业务逻辑高度抽象为一个个服务，项目取调用服务

优点： SOA（Service-Oriented Architecture）即面向服务的架构，这一个个服务很好维护和扩展；最重要的，各个服务组件可以进行分布式部署，性能大大提高。

缺点： 这一个个服务的粒度依旧不小，所以依旧有耦合现象。

❹ 微服务架构

理解： 一个个微服务非常小，几乎完全独立

优点： 几乎没有耦合，每个微服务各自进行维护、扩展、优化、迭代、分布式，自然效率更高。

缺点： 微服务数量会很大，因此开发和维护的难度会高许多，是对团队的挑战。

 

从单体/垂直架构到SOA/微服务架构，在性能上有较大的提升，这正是从集群到分布式的变化。怎样理解集群与分布式的区别呢？

举个通俗的例子，一个厨师做菜太慢忙不过来，这是单机；又请来几个厨师同时做菜，这是集群；有的洗菜有的切菜有的炒菜，这是分布式——集群就是通过简单的怼单机数量，来解决单机问题；而分布式是对任务的拆解和结果的归并。

你会发现，抽象出的这一个个服务，与分布式的思想恰好契合。高度抽象，分布部署，正是当今时代的趋势。

 
 

简介

Apache Dubbo 是一款高性能的Java RPC框架，且可以与Spring框架无缝集成。

谈一谈对RPC的理解？

RPC全称Remote Procedure Call，即远程过程调用。比如有两台服务器A和B，A上的应用想要调用B上的服务，但是A和B在物理上压根不在一起，更别提在同一内存中，所以直接调用是不可能的；这时便需要通过网络，来传达语义和数据。

需要注意的是，RPC并不是一个具体的技术，而是泛指借助网络进行远程调用的一切手段。各个开发语言都有自己的RPC框架，Java的RPC框架比较多，被广泛使用的就有RMI、Hessian、Dubbo。

简要说一下Dubbo的核心功能有哪些？

面向接口的远程方法调用、智能容错与负载均衡、服务的自动注册和发现。

 
 

架构图解

节点角色说明

1）Provider，暴露服务的服务提供者

2）Consumer，调用服务的服务消费者

3）Registry，注册(与订阅)中心

4）Monitor，统计服务调用次数和调用事件的监控中心

5）Container，容器

箭头关系说明

0）加载容器，开启服务提供者

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

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

3）注册中心返回给消费者以提供者地址列表，如果有变更，注册中心也会通知消费者

4）消费者根据负载均衡算法，从提供者地址列表中挑选一台提供者进行远程调用

5）在内存中统计调用次数与调用时间，定时每分钟发送一次统计数据给监控中心

 
 

新需求

在大规模服务化之前，只是通过RMI、Hessian等工具，简单的暴露服务、一个服务一个URL、并通过F5等硬件进行负载均衡。

当服务越来越多，各个服务的URL管理变得困难。此时需要一个注册中心，动态的注册和订阅服务，使服务透明化。

同时，F5硬件负载均衡器逐渐力不从心。此时还是要借助注册中心，告诉消费者以提供者地址列表，实现软负载均衡和Failover。

当进一步发展，服务器依赖关系变得错综复杂，甚至分不清哪个应用要在哪个应用之前启动。这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。这种拓扑关系也是可以由Dubbo来维护的。

接着，服务的容量问题也暴露出来，这个服务需要多少个机器支撑？什么时候该加机器？为了解决这个问题，就是要统计出服务的调用次数和调用时间，作为容量规划的参考指标。

 
 
 
 

 
 
 
 

 
 
 
 

⭐️