Dubbo，相信做后端的同学应该都用过，或者有所耳闻。没错，我就是那个有所耳闻中的一员。
公司在好几年前实现了一套自己的RPC框架，所以也就没有机会使用市面上琳琅满目的RPC框架产品。
之所以想好好看看Dubbo，有以下几个原因
公司内部的框架一直在做迭代更新，配置越来越简洁，性能越来越好。但是作为使用者，它就像一个黑盒子，我们无法感知其内部的改动以及实现的原理
现在使用的框架，因为使用了thrift，让平时的开发显得格外的蹩脚，常常在各种model的转换中迷失自我，耗尽了耐心
阿里团队从去年开始重新维护Dubbo，并在春节之际进入Apache孵化器，在开源的道路上又猛跨一大步，其背后定然有我们值得学习借鉴的地方，更何况有阿里技术的背书
开源项目是很好的学习素材，希望借助学习Dubbo代码，了解序列化、分布式、网络通讯等方面的知识
Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。
GitHub：https://github.com/apache/incubator-dubbo
官网：
中文用户手册：
HelloWorld之前的两个小问题1.没有Dubbo之前，我们是什么样的工作方式
Dubbo代表的是一类RPC框架，类似的产品还有鼎鼎大名的gRPC。
没有Dubbo之前是什么样的，可以回想下我们学生时代做的项目。
一台电脑既是服务器又是客户端，估计当时也没有想过我调用的这个接口是哪台电脑上，我是不是可以多部署几台电脑，怎么样充分利用这几台电脑好让调用的效率更高。
因为即使想了，也搞不了，因为没钱！
即使我们在自己的PC上把项目做好了，需要部署到服务器上，那么我们只要记住那台服务器的IP，使用Socket通讯，就很简单的实现了服务的调用和通讯了。
2.Dubbo有什么用
接着学生时代的项目说，那时候我们做个图书管理系统，学籍管理系统，其访问量和并发量一般不会太高，准确说，是非常低。
但是如果还是一个服务端，大量的用户请求，达到高并发的场景，那么问题就来了，一台机子显然承受不住，这时候需要考虑分布式。
Dubbo的产生于微服务联系紧密，我们一方面想着借助微服务的思想，实现各个服务或者模块之间的解耦。那么我们另一方面就不能忽视服务之间的通讯，这时候Dubbo一类的RPC框架就应运而生。
我们需要考虑扩展性，比如为了防止访问过载，服务所在机器需要进行水平扩展，同时也要考虑不断增加的服务调用方。
我们需要考虑负载均衡，怎么样才能将服务集群的威力发挥到最大。
我们需要考虑如何自动的注册服务以及更新服务，如果做好异常情况下，比如注册中心宕机时，服务方和调用方之间的服务调用。
如此种种，都是催生Dubbo的重要因素。
HelloWorld的准备工作打开命令行，执行**git clone https://github.com/apache/incubator-dubbo.git**命令，将远程项目拉到本地
导入项目进IDE，使用mvn clean compile在项目目录下编译
下载安装zookeeper，在命令行执行brew install zookeeper
相应的启动zk和关闭zk服务的命令分别是zkServer start和zkServer stop
导入Dubbo项目并且完成编译后，可以看到Dubbo项目的目录结构如下
今天要介绍的是dubbo-demo，该子模块包括
dubbo-demo-api（提取出公共接口）
dubbo-demo-consumer（服务调用方）
dubbo-demo-provider（服务提供方）
dubbo-demo-api
该模块最核心的类就是DemoService接口，该接口只有一个方法sayHello
package com.alibaba.dubbo.demo; public interface DemoService { String sayHello(String name); }这个接口是联系调用方和提供方的纽带。
dubbo-demo-consumer