文章
文章用户文档快讯圈子网址导航

26. Dubbo原理解析-监控

释放双眼，带上耳机，听听看~！

Dubbo发布代码中，自带了一个简易的监控中心实现。对于一般的小业务这个监控中心应该能够满足需求，对于那些大业务量的大公司一般都会有自己的监控中心，更加丰富的功能如常用的报警短信通知等等。这章讲解分析使得读者能够了解一般的监控中心实现，也使得有自己接入监控中心需求的大概知道如何集成自己的监控中心实现。下面我们就以dubbo自带的监控中心开始讲解。

 

监控中心

1.  监控中心启动，我们先看下dubbo的属性文件

dubbo.container=
log4j,spring,registry,jetty

dubbo.application.name=
simple-monitor

dubbo.application.owner=

dubbo.registry.address=
zookeeper://127.0.0.1:2181

dubbo.protocol.port=
7070

dubbo.jetty.port=
8080

dubbo.jetty.directory=
${user.home}/monitor

dubbo.charts.directory=
${dubbo.jetty.directory}/charts

dubbo.statistics.directory=
${user.home}/monitor/statistic
s

 

相比于provider, consumer的启动注册中心多了registry, jetty容器启动

它们都是基于dubbo的spi扩展机制的。

SpringContainer容器启动就是加载classpath*:META-INF/spring/ *.xml spring的配置文件

<
bean
id="monitorService"
class="com.alibaba.dubbo.monitor.simple.SimpleMonitorService"

      
<
property
name="statisticsDirectory"
value="${dubbo.statistics.directory}"
/>

      
<
property
name="chartsDirectory"
value="${dubbo.charts.directory}"
/>

</
bean

<
dubbo:application
name="${dubbo.application.name}"
owner="${dubbo.application.owner}"
/>

<
dubbo:registry
address="${dubbo.registry.address}"
/>

<
dubbo:protocol
name="dubbo"
port="${dubbo.protocol.port}"
/>

<
dubbo:service
interface="com.alibaba.dubbo.monitor.MonitorService"
ref="monitorService"
delay="-1"
/>

<
dubbo:reference
id="registryService"
interface="com.alibaba.dubbo.registry.RegistryService"
/>

 

  1. SimpleMonitorService

监控中心配置了监控服务的实现SimpleMonitorService, 并且作为一个普通的dubbo服务暴露到注册中心，供服务的提供者和服务的消费方调用，将服务提供者和服务的消费方的调用数据保存到监控中心。

监控服务的接口定义

public
interface MonitorService {

   
/**

     *
监控数据采集
.

     * 1.
支持调用次数统计：
count://host/interface?application=foo&method=foo&provider=10.20.153.11:20880&success=12&failure=2&elapsed=135423423

     * 1.1host,application,interface,group,version,method
记录监控来源主机，应用，接口，方法信息。

     * 1.2
如果是消费者发送的数据，加上
provider
地址参数，反之，加上来源
consumer
地址参数。

     * 1.3 success,faulure,elapsed
记录距上次采集，调用的成功次数，失败次数，成功调用总耗时，平均时间将用总耗时除以成功次数。

     *

     * @param
statistics

     */

    void collect(URLstatistics);

 

   
/**

     *
监控数据查询
. 

     * 1.
支持按天查询：
count://host/interface?application=foo&method=foo&side=provider&view=chart&date=2012

07

03

     * 1.1host,application,interface,group,version,method
查询主机，应用，接口，方法的匹配条件，缺失的条件的表示全部，
host
用
0.0.0.0
表示全部。

     * 1.2 side=consumer,provider
查询由调用的哪一端采集的数据，缺省为都查询。

     * 1.3
缺省为
view=summary
，返回全天汇总信息，支持
view=chart
表示返回全天趋势图表图片的
URL
地址，可以进接嵌入其它系统的页面上展示。

     * 1.4 date=2012

07

03
指定查询数据的日期，缺省为当天。

     *

     * @param
query

     * @return
statistics

     */

    List<URL> lookup(URL query);

}

 

注: lookup方面可能在开源过程中依赖了阿里的什么系统，并没有具体的实现，如果使用着需要此功能则需要根据接口定义自己实现

 

MonitorService的dubbo默认实现SimpleMonitorService

Collect方法被远程调用后将数据url(传过来的url包含监控需要的数据)保存到一个阻塞队列中BlockingQueue<URL>

启动定时任务将统计日志记录到本地,

String filename =
${user.home}/monitor/statistic
s

                        +
"/" + day

                        +
"/" +statistics.getServiceInterface()

                        +
"/" +statistics.getParameter(METHOD)

                        +
"/" + consumer

                        +
"/" + provider

                        +
"/" + type +
"." + key

这是文件在本地存储的格式

文件内容如图保存时间方法消费耗时

 

3. 起定时任务利用JFreeeChart绘制图表,保存路径

${user.home}\monitor\charts\date\interfaceName\methodName

 

 

 

产生监控数据

注册中心暴露了MonitorService服务，它是被谁调用的呢，监控中心的数据是从哪里来呢，下面我们看下服务提供方与服务的消费方式如何介入监控中心的。

在服务的提供方跟消费方的dubbo配置加入如下配置

通过注册中心<dubbo:monitor protocol="registry" />

或者直连  <dubbo:monitor address="127.0.0.1:7070" />

在构建服务的调用链的时候有如上基于监控的扩展，下面我们就来看下这个类

@Activate(group = {Constants.PROVIDER, Constants.CONSUMER})

//此过滤器在服务的提供方，服务的消费方应用中被激活，也就是起作用

public class MonitorFilter implements Filter {

private MonitorFactory monitorFactory;

**    public Result invoke(Invoker<?>invoker, Invocation invocation) throws RpcException {**

**    if(invoker.getUrl().hasParameter(Constants.MONITOR_KEY)) {**

**         //
有注监控中心处理**

1. 
获取
invoker
的调用上下文

2. 
记录起始时间戳

3. 
并发计数加一

try {

4. 
调用调用链的下一步

5. 
采集调用信息

} finally {

6. 
并发计数减一

}

**    } else {**

**         //
没有配置监控中心，直接往下调用**

**         return invoker.inovke(invocation);**

**   }**

}

 

上面第5点信息采集

1. 计算调用耗时

2. 获取并发数

3. 获取服务名称

4. 获取方法名

5. 判断是服务消费方监控还是服务提供方监控

6. 由工厂类monitorFactory.getMonitor(监控url)，获取DubboMonitor对象，

构建调用监控中心服务的的Url， url中包括了监控中心所需的监控信息

monitor.collect(newURL(Constants.COUNT_PROTOCOL,

                  NetUtils.getLocalHost(),localPort,

                  service + "/" +method,

                  MonitorService.APPLICATION, application,

                   MonitorService.INTERFACE,service,

                   MonitorService.METHOD,method,

                   remoteKey, remoteValue,

                   error ?MonitorService.FAILURE : MonitorService.SUCCESS, "1",

                   MonitorService.ELAPSED,String.valueOf(elapsed),

                   MonitorService.CONCURRENT,String.valueOf(concurrent),

                   Constants.INPUT_KEY, input,

                  Constants.OUTPUT_KEY, output));

 

DubboMonitor是调用监控中心的服务的封装，之所以没有直接调监控中心而是通过DubboMonitor调用，是因为监控是附加功能，不应该影响主链路更不应该损害主链路的新能，DubboMonitor采集到数据后通过任务定时调用监控中心服务将数据提交到监控中心。

 

RegistryContainer

监控中心refer引用了注册中心暴露的RegistryService服务，主要是被下面的RegistryContainer使用的。

 

RegistryContainer主要是到注册中心收集服务，分组，版本信息，并注册回调当注册中心数据发生变化的时候更新到监控中心

下面看下RegistryContainer的start方法流程：

  1. 通过SpringContainer获取前面初始化的RegistryService, 得到其实是对注册中心的一个远程代理服务

  2. 构建订阅注册中心数据的URL，看可以看出下面的url是订阅服务提供者和服务消费者的所有服务

subscribeUrl = newURL(Constants.ADMIN_PROTOCOL, NetUtils.getLocalHost(), 0,
"",

                Constants.INTERFACE_KEY,Constants.ANY_VALUE,
//
所有服务

                Constants.GROUP_KEY,Constants.ANY_VALUE,
//
所有分组

                Constants.VERSION_KEY, Constants.ANY_VALUE,
//
所有版本

                Constants.CLASSIFIER_KEY,Constants.ANY_VALUE,
//
所有分类

Constants.CATEGORY_KEY,Constants.PROVIDERS_CATEGORY +
","  + Constants.CONSUMERS_CATEGORY,
//
服务的提供者和服务的消费者

                 Constants.CHECK_KEY,String.valueOf(false));
//
不检查

3.  调注册中心服务registry.subscirbe(subscribeUrl,listener)订阅所有数据, NotifyListener在监控中心暴露为回调服务，由注册中心回调

回调接口NotifyListener实现的功能主要是按服务提供者和服务的消费者分类，收集服务名称，服务的url，服务提供方或者消费方的系统相关信息。 同时提供了一系列方法供注册中心调用查询。

 

JettyContainer

监控中心将采集到的信息通过内置jetty来展现给用户，这里为了不依赖与jsp, velocity，freemarker等一些编写web应用的技术，采用在servlet中将html，css，js打印出来

JettyContainer的start方法启动了内置的jettyweb容器

将监控中心访问的本地文件目录设置到ResourceFilter中，并设置这个filter的访问映射到jetty中   ， ResourceFilter主要是读取本地保存的JFreeChart绘制的图片到浏览器中去。

将监控中心的前置控制器PageServlet, 以及这个servlet的访问映射配置到jetty中。之所以叫PageServet为前置控制器，就像其他的mvc框架一样用来分发具体的业务类

 

PageServet的init初始化方法在web容器启动的时候加载所有的页面处理器PageHandler, 用来根据不同的请求生成不同的页面，前面说过这里页面html都是通过java代码打印出来的。

PageServet的init方法加载所有PageHandler时会判断PageHandler上是否有@Menu注解，将有注解的PageHandler加入集合，以被HomePageHandl er用来生成主页以及各个页面的uri

PageServet的doGet, doPost接收浏览器请求，请求以xx.hml形式，xx就是PageHandler扩展的key，找到对应的PageHandler绘制对应的页面返回给浏览器。

 

 

@Menu(name = "Home",desc = "Home page.", order = Integer.MIN_VALUE)

//
有注解
name
跟
desc
属性都是在页面中展示给用户看的

public class HomePageHandlerimplements PageHandler {

    public Page handle(URL url) {

        List<List<String>> rows =new ArrayList<List<String>>();

        for (PageHandler handler :PageServlet.getInstance().getMenus()) {

            String uri =ExtensionLoader.getExtensionLoader(PageHandler.class).getExtensionName(handler); 
//
这个
uri
其实就是
PageHandler
扩展配置的
key
，
页面中用它来请求选择具体的
handler
绘制
     //
出具体的
page

            Menu menu =handler.getClass().getAnnotation(Menu.class);

            List<String> row = newArrayList<String>();

            row.add("<ahref="" + uri + ".html">" + menu.name() +"</a>");

            row.add(menu.desc());

            rows.add(row);

        }

        return new Page("Home","Menus",  new String[]{"Menu Name", "Menu Desc"}, rows);  
//
一个
Page
实体就是一个页面，这里包含所有主要
HomePage
的页面内容

    }

}

 

PageHandler的在com.alibaba.dubbo.container.page.PageHandler文件中的扩展配置

index=com.alibaba.dubbo.container.page.pages.HomePageHandler

providers=com.alibaba.dubbo.monitor.simple.pages.ProvidersPageHandler

consumers=com.alibaba.dubbo.monitor.simple.pages.ConsumersPageHandler

。。。。

下面截图看下dubbo大概提供了哪些扩展

 下面截几张图看看监控中心的页面。

    

Related posts:

  1. Kafka、RabbitMQ、RocketMQ消息中间件的对比
  2. go-kit实践之5：go-kit微服务请求跟踪实现
  3. Spring Cloud构建微服务架构：分布式服务跟踪（抽样收集）【Dalston版】
  4. kafka原理和实践（六）总结升华

给TA打赏
共{{data.count}}人
人已打赏
[db:标签]分析数据监控监控数据系统
安全网络

CDN安全市场到2022年价值76.3亿美元

2018-2-1 18:02:50

安全运维

redis集群搭建

2021-12-19 17:36:11

猜你喜欢
❯

解锁会员权限

开通会员

解锁海量优质VIP资源

立刻开通
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索

  • 扫码打开当前页

返回顶部