Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。
主要核心部件：
-
Remoting: 网络通信框架，实现了 sync-over-async 和 request-response 消息机制.
-
RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能
-
Registry: 服务目录框架用于服务的注册和服务事件发布和订阅
Dubbo工作原理：
本文将通过实例进行讲解，包括入门以及和springMVC mybatis整合还有管理端的演示
部分大图直接观看不太清晰，请在图片上点击右键，选择新窗口打开
本文中有一个接口是实现了dao，和mybatis整合后进行与数据库的交互，另一个接口如上图演示的是主要想展示的多个服务提供者之间的负载均衡，均雷同，后面会提供具体的下载地址
步骤1： 定义共通接口，接口应该定义在一个单独的maven项目中（jar），这样服务提供者和消费者才能引入
和普通的jar接口一样，不解释
步骤2：实现服务提供者
服务提供者也很简单，就是实现了第一步里面定义的接口，这里很简单，就是打出一句话，以便后面区分消费者到底调用到了哪个服务提供者了。
另外，需要将服务暴露出去，所以配置文件里面的dubbox.xml就很重要了
这里需要注意的是，由于dubbox的服务注册要基于zookeeper，所以需要先启动一个，具体操作可以参考我博客的其他文章或者自行搜索。
为了区分消费者到底调用了哪个服务提供者，所以服务提供者我们至少要部署两套，所以，需要修改上面的端口，另外，实现类里面打印的文字，还是要区分下
步骤3：实现消费者
接口的调用方就很简单了，和标准的springMVC一样，这里我们是整合好了的，直接注入就可以了
这里因为要测试到底调用到了哪个服务提供者，所以我们循环调用1000次，根据打印的文字来进行区分，所以上面红色字体需要修改的地方一定要改
步骤4：启动dubbox-admin， 管理端可以查看到发布的服务以及服务的提供者有那些。（我通过源码编译获取的，稍后我会提供我打好包的下载地址）
a 将duboox-admin.war修改为ROOT.war并放在tomcat webAPp目录下，先删除掉ROOT文件夹， 然后启动
同时，启动后确认下zookeeper地址是否正确，若不正确，停止server，按下图修改好了再启动
步骤5：启动服务提供者1
看见我们的提供的接口了，因为现在还没有启动消费者这边，所以暂时没有消费者，点击任意接口进去看可以看到服务提供者的信息
注意到这里的端口，就是之前dubbo.xml里面配置的
步骤六，启动服务提供者2,如果在启动2的时候报端口被占用，那就是xml中端口没改，仔细检查下
启动后服务列表还是一样的，因为我们两个服务提供者提供的服务接口都一样，就不截图了
但是现在我们每个接口都有两个提供者了，理论上点进任意接口后有两个实现，并且端口还不一样 是不是？
如上图，和我们预期是一样的。
步骤7：启动消费者
启动消费者后我们在admin服务首页看，注意看重点，不要看这里的文字 红色圈起来的
最开始是没有消费者，现在变为了正常了
步骤8：启动消费者,进行测试，看看打印的log吧， 如果不是两个server信息，那就再仔细检查吧
另外可以在admin里面配置负载均衡机制再试试，
说说由此引发的"血案"：
之前的web项目，为了提高并行处理能力，除了代码优化外，一般都是部署了多套，前端通过nginx等负载均衡机制进行分发。
接触dubbox自己经过思考认为：
提供给web端的Controller层业务逻辑相对简单，占用的处理时间及资源相对较少，主要的处理逻辑在service层以及dao数据交互层
如果将controller层单独分离出来供用户直接访问， service和Dao一同作为服务部署多套，如果处理服务层的机器已经很吃力，则可以动态的增加服务节点来进行分担。
这样 controller层代码就可以减少很多部署资源，主要的在后端service和dao了。
然后“血案”就来了， 我正尝试着将现有项目进行拆分，通过压力测试来验证我的设想。。。。。。