运维自动化重点解读之监控系统（三）：架构(1)
2016-02-20 19:33:33   来源： Reboot运维开发 51CTO博客    评论：0 点击：

这一篇我们来聊聊监控系统的架构。欢迎大家加入运维开发讨论交流群来交流，群号 365534424，本文仅授权51reboot、51cto上发布。

架构这个词太大了，这里我们缩小一下，只来谈谈宏观的监控系统整体架构。在这个范围里面，web由于负责统一的系统管理和操作功能，缩减为一个模块。

最简单的架构如下图：

这是监控系统第一层的架构。比照百度地图的话，我们可以认为这个是全国地图。最粗粒度的几个模块就是这三个：web、数据采集、数据处理。

PUSH和PULL

我们先来关注数据采集模块到数据处理和报警模块的这个环节。

推和拉，技术选型里面常常遇到的一个选择题。 在Client/server结构中，信息获取方式是按“拉”(Pull)的模型进行的：服务器根据用户终端发送的服务请求进行处理并返回用户所需的结果。在Push模型中，服务器把信息“推”给Client。虽然两者数据传输的方向都是从服务器流向Client，但操作的发起者是不同的。从“信源”与 “用户”的关系来看，信息的流动可分为两种模式，即信息推送与信息拉取模式。

两种模型的对比见表格：

其中PUSH的好处是及时性好。但缺点是服务端要有比较复杂的状态管理。同时在到达率等方面都会有一些纠结的地方。而PULL的好处则是服务端简单，状态管理简单，但缺点是时效性上不可控。体现在监控系统上，如果所有要监控的监控项，都是需要Server端PUSH给Client，假设Client所在服务器关机了，那PUSH的时候就是不可达的。Server端就得想办法记录下来，并且再做重试等失败处理。而如果是Client端主动来PULL就好办了，服务器开机启动之后，Client立刻来拉取。到达率肯定要好，对Server的管理也简化了。但缺点就是想生效一个监控项，只能等着Client来 PULL，而无法立即生效。

这里还有一个比较经典的例子，也是我面试别人的时候总喜欢问的一个问题。当然我问面试者的时候主要是想去看看TA的逻辑思维能力。

题目：微博大家都用过。里面你可以关注一个人，也可以被人关注。当你发一条微博时，关注你的人都会收到一条提示。当你关注的人发一条微博时，你会收到一条提示。 请问这个提示，是PUSH 还是 PULL到你的微博客户端(浏览器或者手机微博)上的?

面试者：肯定会有人说，PUSH呗。

面试官：OK，然后我就会问了，姚晨在新浪微博上的粉丝数是5000多万，她发一条微博，是不是得PUSH 5000多万个消息到各个账号去?

面试者：额，那就是定时PULL

面试官：确定吗?几千万个客户端都PULL?

面试者：额。。。 面试者开始额头黑线了。

面试官：请问该怎么办?

PUSH的话，姚晨的一条微博，在系统里面就要产生5000万条消息要处理。如果她一天发个100条，估计新浪微博疯了。这还没有考虑很多客户端不登陆，消息就得缓存着。还有很多客户端一下子通知不到，还得处理失败。

PULL的话，如果大量用户在使用的生产系统，对存储和缓存是一个很大的挑战。

具体的，大家可以再去google一下，这个事情其实有很多方案。

经验比较丰富的研发一定会同意我的一个说法：两个争论不休的技术方案，最终能达成一个融合了二者的第三个方案。就好像两个特别对立的谈判方，到最后谈判结果是一个融合或者叫妥协的方案。PUSH和PULL也可以二者融合，将做到取长补短，使二者优势互补。根据推、拉结合顺序及结合方式的差异，又分以下四种不同推拉模式：

◆先推后拉——先由服务端PUSH，再由Client端有针对性地拉;

◆先拉后推——根据Client端PULL的信息，服务端进一步主动PUSH与之相关的信息;

◆推中有拉——在数据推送过程中，允许Client随时中断并PULL更有针对性的信息;

◆拉中有推——根据Client端PULL的过程，Server主动推送相关的最新信息