u014461495的博客

继续以netty为底层通讯框架来分析，个人认为dubbo的线程模型设计思路是居于netty的线程模型延伸开来的的；在netty中，处理开发者的业务逻辑如果过于复杂耗时的话，开发者利用线程池来另外创建线程来处理业务逻辑，这样不会占着IO线程的资源；反之如果业务逻辑简单计算较快的话，则使用IO线程来处理，则减少线程的损耗；dubbo就是在这基础上提炼，通过官网我们了解到：dubbo提供了5个线...

dubbo默认的是以netty为通讯框架，有了解过netty的清楚，不管是客户端还是服务端，在通讯过程中所产生的事件：连接断开，读/写，接受等事件，必定在：ChannelPipeline里面处理，而在：ChannelPipeline具体处理的就是：ChannelHandler了，据此，我们从学习笔记—DUBBO的服务暴露以及源码分析分析过，服务在暴露过程中，会建立NettyServer并且打开通道...

dubbo的服务引入分为以下步骤：dubbo的服务暴露分为以下步骤：1.URL的准备过程；2.Invoker的执行责任链生成过程；3.启动netty服务，存储对应的nettyServer服务4.与注册中心的结合，客户端的连接，注册对应的节点以及监听；5.最终生成exporter，封装了Invoker以及serviceBean的信息...

dubbo的服务调用的逻辑可以拆分为两部分来处理：消费端的调用；提供端的响应；消费端的调用：代码分析：从： String hello = demoService.sayHello(“world”) 开始，由上次dubbod的服务引入分析可以知道，这个：demoService就是Invoker包装类的代理对象，下一步执行的逻辑： @Override public Object ...

本篇笔记重点在与服务暴露逻辑，牵扯到的dubbo的spi与adaptive以及与spring的结合的逻辑不在此赘述；比较重要的元素：1.URL：主要在启动的过程中将启动参数，xml配置，控制台配置在注册中心的参数按照级别依次来覆盖存储，以启动参数的配置级别最为优先；以及在此过程中，按照配置的子节点优先于父节点的级别来配置；再结合dubbo本身的spi自适应功能来生成或者实例化对应的实现类来执行...