Dubbo分布式服务框架

Dubbo是一个高性能，基于Java的RPC框架，由阿里巴巴开源。一个分布式的服务框架。可以实现SOA（面向服务的架构）架构。Dubbo使用的公司：京东、当当、阿里巴巴、中国电信等等。

分布式服务架构的由来

以下式架构演变过程：

早期，电信只有座机的时候，系统只有一个打电话的功能和一个计费的功能。因为业务单一，所以只有一个系统。

单一业务的单体式架构

后来，电信业务丰富起来了。新增了“短信”、“宽带”、“手机流量”等业务功能。按照常规做法，也只会在原有的“打电话”单一业务系统的基础上，多添加几个业务功能模块而已。所有的业务功能（““电话”、“短信”、“宽带”、“手机流量””）都还是在一个项目内部。如下图：

多业务单体式架构

多业务模式下的单体架构，当业务不断扩张、系统内部的业务功能模块越来越多，会导致如下问题：

1、会导致业务功能模块的耦合度太高、不利于扩展和维护，以及推广。

2、再者程序中存在一个魔性的数字：65535（16bit最大值）限制，（因为调用方法的指令容量只有16bit，65535正好是16bit能容纳的最大数字）。重复的方法数太多，会加速达到这个上限。（比如Android应用65535很容易就上限了）。

比如淘宝、天猫、阿里巴巴三个项目都需要用到支付，设想，将淘宝、天猫、阿里巴巴三个项目整合成一个项目的三个业务功能模块，将会比较杂乱。所以，出现了淘宝、天猫、阿里巴巴三个独立的项目，类似下图：

垂直架构

通过一步一步演变，架构已经成为如图所示的垂直式架构。但是大家都发现了其中的计费功能出现了4次。这样肯定不利于项目的维护和统一配置。（并且上图的计费只是众多可能重复模块中的一员）。所以不得不将多个项目都要使用的相同模块独立出来，共享给业务功能使用。这样，就演变成如下图架构：

如图所示，计费被单独提炼出来成为一个独立的app，共其他app共同使用。图中“其他”模块用来代替千千万万类似计费的模块。

这样一来，每一个方块就是一个独立的应用。这样解决了业务复杂度，将业务模块化、独立化，方便共享和扩展。这样的架构带给我们需要解决的问题如下：

1、各个独立app之间的通信问题怎么解决？

2、怎么做到统一调度、协调处理。

3、如果计费模块是并发最大的模块，但是其他模块并发不是很大。则需要对计费进行负载均衡，怎么实现？

架构演变过程

什么是RPC？

RPC（Remote Procedure Call Protocol）远程过程调用协议。服务器A调用服务器B上的方法的一种技术。Dubbo就是一个RPC框架，实现了远程过程调用。

dubbo主要的三个要素：1、接口的远程调用2、负载均衡。3、服务自动注册和发现

dubbo默认每次只访问一个服务器，需要主从配合完成数据同。

dubbo:registry cluster="replicate"address="redis://192.168.72.188:6379"/

以上就是极悦小编介绍的"Dubbo分布式服务框架"，希望对大家有帮助，想了解更多可查看Dubbo教程，如有疑问，请在线咨询，有专业老师随时为您服务。