DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制,直接配置远程接口的地址,这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题,但是服务提供端呢?如上图的B1它即是消费端也是服务提供端,它提供A1所依赖的接口,那么如果B1将它的服务发布到注册中心里面(这里需要提醒,STABLE环境机制里面所有子环境公用一个注册中心),那么势必会导致stable环境里面的A会发现B1提供的服务?势必会导致stable环境的不稳定(stable环境的机制是stable环境只能进不能出,就是不能调用外部其他子环境的服务)?所以B1不能发布服务到注册中心,dubbo也提供了相关的配置属性来支持这一点。下面我例举出通过哪些配置可以实现这种方案:
服务消费端:
DUBBO在消费端提供了一个url的属性来指定某个服务端的地址
<!--lang:xml-->
<dubbo:reference interface="comalibabadubbodemoHelloWorldService" check="false" id="helloWorldService"/>
默认的方式是从注册中心发现接口为comalibabadubbodemoHelloWorldService的服务,但是如果需要直连,可以在dubboproperties下面配置dubboreferencehelloWorldServiceurl=dubbo://ip:port/comalibabadubbodemoHelloWorldService可以通过配置dubboreferenceurl=dubbo://ip:port/来让某个消费者系统的服务都指向制定的服务器地址(关于配置信息可以参考《DUBBO配置规则详解》)
在传统rpc远程调用中,服务与服务依赖关系,管理比较复杂,所以需要使用服务治理,管理服务与服务之间依赖关系,可以实现服务调用、负载均衡、容错等,实现服务发现与注册。
服务治理SpringCloud Eureka在服务注册与发现中,有一个注册中心,当服务器启动的时候,会把当前自己服务器的信息比如服务地址通讯地址等以别名方式注册到注册中心上。
另一方消费者|服务提供者,以该别名的方式去注册中心上获取到实际的服务通讯地址,让后在实现rpc调用。
基本信息:
服务治理是微服务架构的核心与基础,主要实现各个服务实例的自动化注册与发现。Spring Cloud Eureka基于Netflix Eureka做了二次封装,主要负责完成微服务架构中的服务治理功能。主要用来实现服务注册发现,同时包含服务端,客户端组件。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)