实现DUBBO服务环境隔离

实现DUBBO服务环境隔离

欢迎加入DUBBO交流群：259566260

要说这个话题之前先讲讲之所以要做这个的需求。一般选择DUBBO来进行服务管理，都是在分布式应用的前提下，涉及到多个子系统之间的调用，DUBBO所做的事情就是维护各个子系统暴露的接口和自动发现对应接口的远程地址从而实现分布式RPC服务管理。

有了上面前提之后，那么在项目开发和测试过程中涉及到一个问题，就是接口的联调。如果每个子系统自己维护自己系统的联调环境，那么可能会导致别人调用接口的不稳定，因为环境是系统自己人来维护，可能挂了也可能调整接口没通知相关人员，这对开发接口联调测试是一个问题。那么如何做好这件事情呢？下面提出了STABLE环境的概念，一看字面意思就知道是一个稳定的环境，这个环境是和线上保持同步的，并且不是由开发负责维护，而是有专门的运维人负责维护，这样STABLE环境就相对比较稳定，那么调用这个环境的接口也就比较稳定了（你可能会问，怎么调用这个环境的接口？在项目的dubbo.properties里面把注册中心指向STABLE环境即可）。那么问题来了，STABLE不是开发维护，那么会导致如果一个项目涉及多个子系统变更呢？要说明这个问题，我先来个图先：

上面是整个STABLE环境的调用图，不管是哪个项目，将涉及到改动的子系统迁移出来构造一个子环境，然后最后一个节点切入到stable环境中，这样既保证了接口联调的稳定性，也确保了各个项目的开发并行化。关于STABLE环境的介绍不是本篇的内容，所以不做过多的解释。下面谈谈DUBBO怎么隔离各个子环境的服务。

直连加不发布服务

DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。下面我例举出通过哪些配置可以实现这种方案：

服务消费端:

DUBBO在消费端提供了一个url的属性来指定某个服务端的地址

<!--lang:xml-->
<dubbo:reference interface="com.alibaba.dubbo.demo.HelloWorldService" check="false" id="helloWorldService"/>

默认的方式是从注册中心发现接口为com.alibaba.dubbo.demo.HelloWorldService的服务，但是如果需要直连，可以在dubbo.properties下面配置dubbo.reference.helloWorldService.url=dubbo://ip:port/com.alibaba.dubbo.demo.HelloWorldService可以通过配置dubbo.reference.url=dubbo://ip:port/来让某个消费者系统的服务都指向制定的服务器地址（关于配置信息可以参考《DUBBO配置规则详解》）

服务提供端：

只需要在dubbo.properties里面添加dubbo.registry.register=false即表示当前系统的服务不发布到注册中心。

这种方式服务发布和服务消费就和注册中心没一点关系了，个人感觉这是一个退步，我们用dubbo就是它的服务管理，而这种方案是直接将我们打入了原始社会。这样也会导致如果一个项目设计的子系统很多，那么搭建一个项目的子环境将会比较头疼，因为你要配置那些直连地址。

注意&