Dubbo之旅--管理控制台

到现在为止我们的Dubbo之旅让我们对Dubbo跟注册中心有了初步的认识,接下来要分享的是Dubbo的管理控制台,在实际的项目中非常的有用,尤其是在dubbo服务提供数量逐渐加大的情况下,通过Dubbo管理控制台能够很好的被我们所用,从而让我们更好的使用Dubbo提供的服务.

首先需要准备Dubbo-Admin管理控制台程序,本人是通过项目的形式将控制台导入Eclipse中,通过Eclipse的方式来启动tomcat服务.当然也可以直接将程序的war包放入Tomcat的webapps中,直接启动tomcat也可以.

如下图:

接下来我们需要配置一下dubbo.properties的属性

上图中主要是三个属性:

dubbo.registry.address=zookeeper://127.0.0.1:2181  这里是配置Zookeeper注册中心的地址和端口,这个属性支持多个注册中心的配置,等到用到的时候本人再进行详细的说明.

dubbo.admin.root.password=root

dubbo.admin.guest.password=guest

以上两个属性很明了,是管理控制台的用户名密码.

接下来我们启动服务:

输入服务地址:http://localhost:8080/dubbo/(用户名:root,密码:root)
如下图:

至此我们的管理控制台程序已经搭建完毕,它提供了很多服务治理的功能如:对提供者和消费者的管理,对访问的控制,对权重的调节等等.当然从上图我们能看到相关的统计信息服务数,提供者和消费者数都是0,这是因为我们还没有往本地的Zookeeper中提供任何的服务.

在接下来的Dubbo之旅文章,本人将对dubbo的具体代码实例跟大家分享.到时候我们可以通过dubbo管理平台看到我们注册的相关服务.

时间: 2024-08-06 07:58:45

Dubbo之旅--管理控制台的相关文章

Dubbo之旅--集群容错和负载均衡

当我们的系统中用到Dubbo的集群环境,因为各种原因在集群调用失败时,Dubbo提供了多种容错方案,缺省为failover重试. Dubbo的集群容错在这里想说说他是因为我们实际的项目中出现了此类的问题,因为依赖的第三方项目出现异常,导致dubbo调用超时,此时使用的是默认的集群容错方式,而配置的reties='3',这样前段系统连续掉用了三次服务,结果可想而知. 先说一下各节点关系: 这里的Invoker是Provider的一个可调用Service的抽象,Invoker封装了Provider地

Dubbo之旅--注册中心

在介绍Dubbo的内部逻辑的时候提到很多次注册中心的概念.实现注册中心的有很多,主要是以下四个注册中心分别是: Multicast注册中心 Zookeeper注册中心 Redis注册中心 Simple注册中心 这里将对注册中心的一个实现Zookeeper跟大家分享,因为Zookeeper是应用比较多,也是我们项目中实际用到的注册中心. ZooKeeper 是一个为分布式应用所设计的分布的.开源的协调服务.分布式的应用可以建立在同步.配置管理.分组和命名等服务的更高级别的实现的基础之上. ZooK

Dubbo之旅--架构路线

从自己开始接触Dubbo到现在也有段时间了,在这段时间里,随着项目的不断进行,在项目中也遇到了各种各样的问题,而这些问题和相应的解决方案逐渐加深的对Dubbo有了认识和了解. 先说说什么是Dubbo? 官方的说法是:Dubbo是阿里巴巴SOA服务化治理方案的核心框架,每天为2,000+个服务提供3,000,000,000+次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点. 现在我们知道了,Dubbo是阿里巴巴的一个框架,不过自开源后,已有不少其他公司在使用Dubbo,例如:京东,去哪儿,大智

Dubbo之旅--结果缓存

在上篇文章中我们队Dubbo的扩展进行了一些基本了解.这些扩展能够很好的帮助我们在实际的项目中发挥作用,接下来对于dubbo的一些高级特征,针对特殊情况而进行的处理进行进一步的介绍,这里我们要说的是结果缓存. 为什么要用到结果缓存,主要是用于加速热门数据的访问速度,Dubbo提供声明式缓存,以减少用户加缓存的工作量. 下面我们将通过一个例子来对结果缓存进行一个接触. 1.客户端和服务提供端共用接口类 packagecom.alibaba.dubbo.demo; public interfaceC

Dubbo之旅--扩展协议

在实际工作中运用dubbo的时候,以上系列的文章基本上能够满足项目的基本需求,当然,对于一些特殊的需求Dubbo可以对其进行扩展,Dubbo拥有者丰富的扩展内容,这次主要将会带领大家去感受一下Dubbo的协议扩展和注册中心扩展. 首先要说的是协议扩展. 为什么要扩展协议呢?什么样的需求需要我们去扩展它? (1) 不同服务不同协议 需求:不同服务在性能上适用不同协议进行传输,比如大数据用短连接协议,小数据大并发用长连接协议. consumer.xml <?xmlversion="1.0&qu

Dubbo之旅--扩展注册中心

在上篇文章中我们介绍了关于协议的扩展,并了解扩展它所需要的需求.本篇主要是对注册中心的扩展进行着重的探索. 同样的问题,为什么我们需要去扩展注册中心的?主要有以下三个需求. (1) 多注册中心注册 需求:xx银行有些服务来不及在上海部署,只在北京部署,而上海的其它应用需要引用此服务,就可以将服务同时注册到两个注册中心. consumer.xml <?xmlversion="1.0"encoding="UTF-8"?> <beansxmlns=&qu

Dubbo之旅--问题汇总

在工作和学习的过程中,具体运用Dubbo的时候遇到了很多的问题,这些问题一方面让自己进一步了解所谓的dubbo,另一方面通过对它们的总结和分析能够在工作中加倍的提高效率,接下来将会对遇到的和别人总结的一些常见的问题进行汇总. 1.增加提供服务版本号和消费服务版本号. 这个具体来说不算是一个问题,而是一种问题的解决方案,在我们的实际工作中会面临各种环境资源短缺的问题,也是很实际的问题,刚开始我们还可以提供一个服务进行相关的开发和测试,但是当有多个环境多个版本,多个任务的时候就不满足我们的需求,这时

Dubbo之旅--内部逻辑

在没有开始用代码来解释之前,用图最能够表达一些关系,关于Dubbo的内部逻辑调用关系,借用官方的图示来说明一下,如下图 通过上图中的一个个方框我们称之为节点,总共有5个节点,这五个节点可以看成五个角色,每个角色都有一定的功能.每个角色的意思如下: Provider: 暴露服务的服务提供方. 在实际项目中一般称这个角色为提供者.它主要是向注册中心注册其提供的服务,并汇报调用时间到监控中心,此时间不包含网络开销. Consumer: 调用远程服务的服务消费方. 既然有提供者,对应的这就是消费者.服务

Dubbo之旅--需求

在上篇文章中,我们主要了解了Dubbo的架构路线,并对它有了一个比较简单点的印象和了解,而关于Dubbo基本需求是接下来要介绍的内容. 在大规模服务化之前,应用可能只是通过RMI或Hessian等工具,简单的暴露和引用远程服务,通过配置服务的URL地址进行调用,通过F5等硬件进行负载均衡. 关于F5硬件可以参考 F5 Networks (1)当服务越来越多时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也越来越大.此时需要一个服务注册中心,动态的注册和发现服务,使服务的位置透明.