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 （服务消费者）

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>