dubbo-环境隔离

        大家在平时开发和测试阶段定位一些bug的时候，需要调用本地启动的dubbo服务debug。如果与服务器、其他同事共用一个注册中心的话，就会调用到别人的服务或者自己本地的服务被别人调用到，造成一些调用失败或者其他异常。

       解决如上问题有大致几种解决方案：

       1、dubbo直连；

       2、dubbo group 服务分组；

       3、dubbo version 版本过渡；

        在开发以及测试环境下，经常需要绕过注册中心，只测试指定服务的提供者，这时候可  以使用点对点直连的方式。点对点直连方式，将以服务接口为单位，忽略注册中心的提供者表。A接口配置点对点，不影响B接口从注册中心获取列表。

      消费者应用，在注入的提供者api上添加 @Reference(version = "100", url = "dubbo://ip:port") 即可！

      此时，如果提供者不希望本地的服务被别人调用到，设置：dubboregistryregister=false,默认值是true。该属性含义： 是否向此注册中心注册服务，如果设为false，将只订阅，不注册。

        通过服务分组实现环境隔离，不用绕过注册中心，大家可以共用一个注册中心。服务注册分组，使跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。

      场景：服务A希望调用到本地的服务B(此时，B服务正常的调用远程服务C)，而不是远程服务B。

      本地服务B的配置设置如下：                                                                                                          //应用全局配置                                                                              dubboprovidergroup=local-group   //设置本地B所提供的dubbo服务均在local-group分组下如图：

       //针对某个Api进行配置

      也可以针对某个api单独做分组，例如：@Service(version = "100",group = "local-group")服务A：在注入的B dubbo服务的api上加 @Reference(version = "100", group = "local-group")  即可。

      服务分组的几个属性解释：

1、dubboregistrygroup=local-group 

          该值自行定义，确保唯一即可，该属性含义：服务注册分组，跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。 该配置不推荐配置，配置之后服务在dubbo admin上默认无法查看，也调用不到该服 务。不同环境，通过zookeeper做数据隔离。

            

      2、dubboprovidergroup=local-group  

       该属性含义：服务分组，当一个接口有多个实现，可以用分组区分。该配置使当前服务所有的提供者都在local-group下。也可以只针对某个api做配置@Service(version ="100",group ="local-group")；推荐后者！

     3、dubboconsumergroup=local-group 

           该配置使当前服务只消费local-group分组下的提供者，建议只针对某个api进行配置即可，例如： @Reference(version ="100", group ="local-group")

            当一个接口的实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。dubboproviderversion=10 //服务版本， 建议使用两位数字版本，如：10 ，通常在接口不兼容时版本号才需要升级。

 dubboconsumerversion=10 //消费10版本的提供者

 可全局配置，亦可配置到某个api服务上，此时优先级大于全局配置。

 提供者服务示例：@Service(version ="your version")

 消费者api服务示例： @Reference(version ="your version")

本文章介绍如何使用jmeter测试dubbo接口,涉及如下两种方式

1使用官方dubbo版本包测试dubbo接口

2通过自己编写java请求插件,实现dubbo调用

选择方式1或方式2并没有什么区别,取决于部分自研公司对dubbo进行了封装,导致官方提供的dubbo包并不适用于方式1,则可以通过方式2去调用

>

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。而Dubbo则是SOA服务化治理方案的一个核心框架。

Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。

作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：

Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出 服务提供方（Provider） 和 服务消费方（Consumer） 两个角色。

Dubbo包含 远程通讯、服务集群和服务发现与注册 三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo服务组件调用关秕说明 ：

Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。

下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：

从上图可以看出， Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的） 。

根据官方提供的，对于上述各层之间关系的描述，如下所示：

以上就是关于dubbo-环境隔离全部的内容，包括:dubbo-环境隔离、关于jmeter测试dubbo接口方式、Dubbo分布式服务框架介绍等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！