Dubbo作为RPC框架，实现的效果就是调用远程的方法就像在本地调用一样。如何做到呢？就是本地有对远程方法的描述，包括方法名、参数、返回值，在Dubbo中是远程和本地使用同样的接口；然后呢，要有对网络通信的封装，要对调用方来说通信细节是完全不可见的，网络通信要做的就是将调用方法的属性通过一定的协议（简单来说就是消息格式）传递到服务端；服务端按照协议解析出调用的信息，执行相应的方法，在将方法的返回值通过协议传递给客户端，客户端再解析。在调用方式上又可以分为同步调用和异步调用。简单来说基本就这个过程。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
如果要对传统的单机MVC项目进行分布式服务改造，那么一般将业务逻辑层及以下的做成服务，biz层的接口全部要对外公布，Web控制层去调用服务，服务完成拿到数据就与视图层进行交互。改造后控制层只有极少量的判断去调用服务，再跟界面进行交互。
改造过程
服务接口<Provider和Consumer子项目均会依赖>
将与Web无关的Common放置在此目录下
服务接口facade暴露服务接口
服务实现<Provider>
原有系统中业务逻辑放置在此目录下
服务接口facade实现<直接调用biz的方法即可>
Spring、MyBatis、JDBC、log4j配置文件
若想将服务部署在Servlet容器中，则需在此子项目的web.xml中引入spring-context.xml
加入dubbo-provider的配置文件，并在spring-context.xml中引入之。
Web控制<Consumer>
将与Web有关的Common放置在此目录下
Action类
Web Pages
Spring、Struts、log4j配置文件
加入dubbo-consumer的配置文件，并在spring-context.xml中引入之。
工程结构优化：考虑到真实系统中可能会有大量的服务提供者和消费者，而其中总有很多共用的代码（Common），可将其抽取出作为一个单独子项目，其他项目需使用时依赖即可！
如：
edu-common-parent （Maven父配置）
edu-common （公共工程）
edu-common-config （公共配置工程）
edu-common-core （公共core工程）
edu-common-web （公共web工程）
edu-facade-user （用户服务接口）
edu-service-user （用户服务实现）
edu-web-boss （服务消费者）
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>