Dubbo分布式服务框架的概念理解
Dubbo是是一个高性能，基于Java的RPC框架，由阿里巴巴开源。一个分布式的服务框架。可以实现SOA（面向服务的架构）架构。 Dubbo使用的公司：京东、当当、阿里巴巴、中国电信等等。
分布式服务架构的由来
问题：比如电信的计费系统提供了最原始的扣费功能，需要接入此计费系统的应用比较多，比如打电话需要计费、比如流量需要计费、比如宽带需要计费、比如ITV需要计费等等。 如果在每一个系统中都写一套计费的逻辑就会出现代码冗余过大，并且逻辑无法做到统一可维护。 所以需要将计费功能单独提炼出来，作为一个业务模块提供给其他应用使用。以下式架构演变过程（以下案例纯粹为了说明问题，跟业务本身无关）：
早期，电信只有座机的时候，系统只有一个打电话的功能和一个计费的功能。因为业务单一，所以只有一个系统。
- 单一业务的单体式架构
后来，电信业务丰富起来了。新增了“短信”、“宽带”、“手机流量”等业务功能。按照常规做法，也只会在原有的“打电话”单一业务系统的基础上，多添加几个业务功能模块而已。所有的业务功能（““电话”、“短信”、“宽带”、“手机流量””）都还是在一个项目内部。如下图：
- 多业务单体式架构
多业务模式下的单体架构，当业务不断扩张、系统内部的业务功能模块越来越多，会导致如下问题：
1、会导致业务功能模块的耦合度太高、不利于扩展和维护，以及推广。
2、再者程序中存在一个魔性的数字：65535（16bit最大值）限制，（因为调用方法的指令容量只有16bit，65535正好是16bit能容纳的最大数字）。重复的方法数太多，会加速达到这个上限。（比如Android 应用65535很容易就上限了）。
比如淘宝、天猫、阿里巴巴三个项目都需要用到支付，设想，将淘宝、天猫、阿里巴巴三个项目整合成一个项目的三个业务功能模块，将会比较杂乱。所以，出现了淘宝、天猫、阿里巴巴三个独立的项目，类似下图：
- 垂直架构
通过一步一步演变，架构已经成为如图所示的垂直式架构。但是大家都发现了其中的计费功能出现了4次。这样肯定不利于项目的维护和统一配置。（并且上图的计费只是众多可能重复模块中的一员）。所以不得不将多个项目都要使用的相同模块独立出来，共享给业务功能使用。这样，就演变成如下图架构：
如图所示，计费被单独提炼出来成为一个独立的app，共其他app共同使用。图中“其他”模块用来代替千千万万类似计费的模块。
这样一来，每一个方块就是一个独立的应用。这样解决了业务复杂度，将业务模块化、独立化，方便共享和扩展。这样的架构带给我们需要解决的问题如下：
1、各个独立app之间的通信问题怎么解决？
2、怎么做到统一调度、协调处理。
3、如果计费模块是并发最大的模块，但是其他模块并发不是很大。则需要对计费进行负载均衡，怎么实现？
以上问题可以使用dubbo解决。