dubbo在多机房多注册中心的方案

技术交流群:534368042

起因:项目在服务化之后,开辟了一个新的专有云机房A,在原有物理机房B系统不迁移的情况下,需要A的系统调用B的各种dubbo服务,且A到B之间不能直接访问需要通过交换机做网络映射,现有B内部的网段是192.168.1.X A网段59.10.59.X 映射后A访问B的网段是10.59.10.X,造成A消费者无法直接注册到B的zookeeper集群注册中心,访问B的服务。

方案:通过dubbo的双注册中心的模式,A机房访问B机房服务通过修改A机房机器的hosts
例如B机房服务内网地址192.168.1.120 机器名app1 这在A机房机器消费者hosts配置app1 192.168.1.120服务注册是dubbo://app1:20880/XXX/XXX,B机房消费者保持不变,网络架构如下:

1.dubbo在A机房zookeeper注册中心通过app1模式,在B机房192.168.1.X 配置如下:

1
2
3
4
5
6
   <!-- 多注册中心配置 -->
   <dubbo:registry id="hangzhouRegistry" address="192.168.1.110:20880" />
   <dubbo:registry id="qingdaoRegistry" address="app1:20880" default="false" />

   <!-- 向多个注册中心注册 -->
   <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="hangzhouRegistry,qingdaoRegistry" />

2.修改dubbo包的的AbstractServer类构造函数

时间: 2024-07-31 04:45:18

dubbo在多机房多注册中心的方案的相关文章

Dubbo点滴(5)之服务注册中心

首先DUBBO本质上是一款RPC框架,不可缺少的2个角色:服务提供者和服务消费者. 已经剖析了服务端暴露端口过程.本文简单说下注册中心. 1.注册中心是什么玩意 这是官网提供的图例 通过图例,可以看出消费者和提供者并不是直接通信的,中间有个第三者,就是注册中心.这种结构,可以实现消费者和提供者两者的依赖,和参数信息的集群化.所以这带来了几个问题. 服务注册 服务发现 服务订阅 服务通知 2. 服务暴露及服务注册过程 <Dubbo点滴(4)之暴露服务解析>已经剖析了dubbo协议具体打开网络端口

说一下Dubbo 的工作原理?注册中心挂了可以继续通信吗?

面试题 说一下的 dubbo 的工作原理?注册中心挂了可以继续通信吗?说说一次 rpc 请求的流程? 面试官心理分析 MQ.ES.Redis.Dubbo,上来先问你一些思考性的问题.原理,比如 kafka 高可用架构原理.es 分布式架构原理.redis 线程模型原理.Dubbo 工作原理:之后就是生产环境里可能会碰到的一些问题,因为每种技术引入之后生产环境都可能会碰到一些问题:再来点综合的,就是系统设计,比如让你设计一个 MQ.设计一个搜索引擎.设计一个缓存.设计一个 rpc 框架等等. 那既

dubbo服务治理中间件,zookeeper注册中心

对传统项目架构进行拆分: 集群概念: 面向服务分布式架构: 服务层提供被注册的对象需要实现序列化接口Serializable: 配置表现层和服务层: 依赖包: 服务层: 1 <!-- 定义dubbo服务名称,此名称可以自定义,用于监控中心监控服务关系 --> 2 <dubbo:application name="content-service" /> 3 <!-- 使用dubbo通过Zookeeper协议注册服务 --> 4 <dubbo:re

Dubbo源代码实现三:注册中心Registry

我们知道,对于服务治理框架来说,服务通信(RPC)和服务管理两部分必不可少,而服务管理又分为服务注册.服务发现和服务人工介入,我们来看看Dubbo框架的结构图(来源网络): 图中可以看出,服务提供者Provider往服务注册中心Registry注册服务,而的消费者Consumer从服务注册中心订阅它需要的服务,而不是全部服务,当有新的Provider出现,或者现有Provider宕机,注册中心Registry都应该能尽早发现,并将新的Provider列表推送给对应的Consumer,有了这样的机

dubbo学习(五)注册中心zookeeper

初识zookeeper 下载地址:https://archive.apache.org/dist/zookeeper/ PS: 建议目前选择3.4的稳定版本进行使用 1.下载并解压文件 2.配置zookeeper 3.启动zookeeper 4.连接ZK PS:这里只简单介绍zookeeper,后续与dubbo整合作为注册中心进行操作将在实操篇进行详细说明 原文地址:https://www.cnblogs.com/riches/p/11199402.html

11. Dubbo原理解析-注册中心之基于dubbo协议的接口介绍

服务注册与发现的中心,服务的提供者将服务发布到注册中心,服务的使用着到注册中引用服务. Dubbo的注册中心提供了多种实现,其实现是基于dubbo的spi的扩展机制的,使用着可以直接实现自己的注册中心. @SPI("dubbo") public interface RegistryFactory { /** * 连接注册中心. * 连接注册中心需处理契约 * 1. 当设置check=false时表示不检查连接,否则在连接不上时抛出异常. * 2. 支持URL上的username:pas

13. Dubbo原理解析-注册中心之Zookeeper协议注册中心

下面我们来看下开源dubbo推荐的业界成熟的zookeeper做为注册中心, zookeeper是hadoop的一个子项目是分布式系统的可靠协调者,他提供了配置维护,名字服务,分布式同步等服务.对于zookeeper的原理本文档不分析,后面有时间在做专题. zookeeper注册中心 Zookeeper对数据存储类似linux的目录结构,下面给出官方文档对dubbo注册数据的存储示例 假设读者对zookeeper有所了解,能够搭建zookeeper服务,其实不了解也没关系,谷歌百度下分分钟搞起.

dubbo之多注册中心

Dubbo 支持同一服务向多注册中心同时注册,或者不同服务分别注册到不同的注册中心上去,甚至可以同时引用注册在不同注册中心上的同名服务.另外,注册中心是支持自定义扩展的. 多注册中心注册 比如:中文站有些服务来不及在青岛部署,只在杭州部署,而青岛的其它应用需要引用此服务,就可以将服务同时注册到两个注册中心. <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.sp

Dubbo注册中心介绍

Dubbo的注册中心有好多种,包括Multicast.Zookeeper.Redis和Simple等.Dubbo官方推荐使用Zookeeper注册中心,我所使用过的也只是Zookeeper注册中心. 首先介绍一下Zookeeper: ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件.它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护.域名服务.分布式同步.组服务等. 建议使用dub