之前本来一直在写spring源码解析这块，如下，aop部分刚好写完。以前零散看过一些文章，知道rpc调用基本就是使用动态代理，比如rmi，dubbo，feign调用等。自己也就想着试一下，于是有了mini-dubbo这个东西，暂时也不能称为一个框架，因为还不是生产级的，目前只是实现了一部分小功能，也没有监控，也没有xxx，反正就是缺的比较多。
曹工说Spring Boot源码（22）-- 你说我Spring Aop依赖AspectJ，我依赖它什么了
我就说下，里面用到的知识点吧，有兴趣的，可以克隆源码下来看看：
动态代理
服务注册和消费，使用redis作为注册中心，其中使用了redisson作为redis客户端，其中涉及到BeanFactoryPostProcessor的使用
因为传输层使用netty和mina，是异步的，但是上层又需要等待结果，所以用到了同步转异步
spring的xml解析，bean definition注册，spring 扩展xml 命名空间
自定义的spi的相关知识
分层思想，从dubbo借鉴了其分层，但是mini-dubbo要少几层，因为我暂时不是很清楚dubbo的每一层的具体职责，所以我按我自己理解分的层。上层依赖下层，只通过下层的接口，查找下层接口时，直接在spring容器中查找bean即可，类似于spring mvc的设计。当下层有多个实现时，通过类似spi机制来指定具体要使用的下层实现。
基于第5点，所以本框架非常容易替换各层的实现，只要自己自定义一个spring bean，实现对应的接口，然后在spi文件中指定本实现的类名即可。
netty和mina的tcp粘包拆包工作。
概要代码我放在了如下位置：
https://gitee.com/ckl111/mini-dubbo
我介绍下代码的整体结构：
服务端聚合工程比较简单，目前也没时间去仔细弄，包含了如下module：
<modules> <!--业务层api--> <module>../mini-dubbo-api</module> <!--业务层，服务端demo--> <module>../mini-dubbo-server</module> <!--配置层，解析xml的工作，在本层完成--> <module>../mini-dubbo-core</module> <module>../mini-dubbo-common</module> </modules>目前的大部分实现，是在客户端，包含了如下module：
<modules> <!--业务层api--> <module>../mini-dubbo-api</module> <!--业务层，测试demo--> <module>../mini-dubbo-client</module> <!--配置层，解析xml的工作，在本层完成--> <module>../mini-dubbo-core</module> <module>../mini-dubbo-common</module> <!--注册中心层--> <module>../mini-dubbo-registry-layer</module> <!--集群层，完成事情：负载均衡策略，集群容错策略等--> <module>../mini-dubbo-cluster-layer</module> <!--信息交换层，主要完成同步转异步的操作，因为下层的mina和netty为异步，本层同步等待结果--> <module>../mini-dubbo-exchange-layer</module> <!--传输层如使用netty实现，则需包含如下module--> <module>../mini-dubbo-transport-layer-netty</module> <!--传输层如使用mina实现，则需包含如下module--> <module>../mini-dubbo-transport-layer-mina</module> </modules>其中，模块间的依赖关系如下：
业务模块，一般只需要依赖mini-dubbo-core模块，mini-dubbo-core主要依赖了如下模块：
为什么这么划分，因为mini-dubbo-core模块，其实主要是完成解析业务模块（比如client）中的xml，根据其xml配置，注册对应的bean到spring 容器中，而具体的bean实现，就是放在各个模块的，比如，xml里配置netty作为传输层实现，那么mini-dubbo-core就得解析为mini-dubbo-transport-layer-netty中的一个实现类作为bean，注册到spring容器，供上层使用。
目前的分层，只是暂时的，后续可能会略有调整。
一次客户端调用的大体思路
业务module中，配置xml，示例如下：
<dubbo:registry address="redis://127.0.0.1:6379"/> <dubbo:reference interface="dubbo.learn.IGpsLocationUpdateService"/> <context:component-scan base-package="dubbo"></context:component-scan>其中的dubbo:reference就代表了一个远端的服务，业务代码中可以自动注入该接口，当调用该接口时，实际就会发起rpc调用。
熟悉的同学已经知道了，这块肯定是生成了一个动态代理。
继续之前，我们看看dubbo的十层架构：