Dubbox 基本特性之直接调用

Dubbo的原作者梁飞说过，其实对于远程调用RPC来说，远程调用的大白话理解就是服务消费者直接通过网络IO传递参数，传递方法名，服务提供者获取到参数，方法名之后通过反射来调用本地的方法，执行完本地的方法之后，将结果再通过网络传递给调用方，这个过程就是RPC最最简单也是最最精髓的实现，关于注册中心，其实是服务治理的模块，注册中心方便服务的管理，发现，统计等等好处，注册中心把服务提供者的地址发送给服务消费者，服务消费者拿着服务提供者的地址，就可以完成服务消费了。

  言归正传，如果服务消费者获取到服务提供者的地址就可以跳过注册中心，完成服务消费者直接调用服务提供者了，完成直连调用的功能。

  直接调用这样的功能，其实很实用，在开发环境中，场景是程序猿A机器本地启一个Tomcat提供一个服务，程序猿B机器获取到程序猿B的机器IP和暴露的服务的端口号，直接调用，这样可以方便调试，因为走正常的注册中心，可能程序猿C也是服务提供者，它也启动了Tomcat，注册中心根据负载均衡的算法，把请求发送给程序猿C，那么就是悲剧了，不利于开发环境的联调，所以直接调用还是有它的使用场景的

3.4.1 Dubbo直接调用实现的Demo

 

  Dubbo作为RPC的始祖，它肯定是支持直接调用的，而且配置相当简单，服务提供者不用做任何修改，我们可以使用第一章的IDemoService那个helloworld的版本的作为服务提供者，只需要简单修改一下服务消费者的spring的配置文件就可以了spring-dubbo-consumer-direct.xml

我们可以清晰地看清楚配置文件的改变，多了一个URL,

这个配置文件的关注点有2点，第一点，去掉了常用的 这样的registry的注册节点，说明直接是不需要注册中心的支持的，第二点就是在中加了url的配置，这个url指的就是服务提供的地址和端口号，这是必须的，否则又没有注册中心的支持，如何支持服务提供的地址呢？

  然后就是在代码的调用上，不管是使用注册中心服务的发现还是直连来说，对于调用还是很透明的，与普通的调用方式是一样的

package org.bazinga.service.test;

import org.bazinga.service.IDemoService;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class DubboConsumerDirectInvokeService {
	
	public static void main(String[] args) throws InterruptedException {
		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
				"spring-dubbo-consumer-direct.xml");
		context.start();
		IDemoService demoService = (IDemoService)context.getBean("demoService");
		System.out.println(demoService.sayHello());
		Thread.sleep(2000000l);
	}

}

启动测试服务类DubboxProviderDemoService.java，然后再启动DubboConsumerDirectInvokeService.java，发现服务消费者能正常消费

我们再看一眼监控中心的控制台，显示没有消费者，这就说明我们没有通过注册中心发现服务，而是通过直接调用的方式，完成远程调用的：

3.4.2 本章小结

 

  本章主要说明了在RPC框架Dubbo对直接调用的支持，也稍微说明了直接调用的使用场景，直接调用适用于开发调试阶段，方便程序的调试，但是在线上环境，直接调用是不建议被采纳的，因为如果服务提供者的地址修改之后，服务消费者需要修改代码，并且也不方便服务的管理，注册中心的好处不必多说，如果直接调用，注册中心不能对此服务进行管理，统计，审核等，是不符合服务治理这个理念的。