
12
|
第
1
章
差,同一个指标在不同系统中的叫法都不一样。
与此同时,我们还创建了另一个用于收集用户活动信息的系统。这是一个
HTTP
服务
,前
端的服务器会定期连接进来,在上面发布一些
XML
格式的消息
。这些消息文件会被转移
到线下批处理平台进行解析和校对。同样,这个系统也有很多不足。
XML
文件格式无法
保持一致,解析这种文件非常耗费计算资源。如果要修改已经创建好的活动类型,则需要
在前端应用程序和离线处理程序之间做大量的协调工作。即使是这样,当数据结构发生变
化时,系统仍然会崩溃。另外,批处理以小时为单位,无法实现实时处理。
监控和用户活动跟踪无法使用同一个后端服务。监控服务太过笨重,数据格式不适用于活
动跟踪,而且监控使用的轮询拉取模式与活动跟踪使用的推送模式不兼容。另外,将跟踪
服务提供的数据作为指标太过脆弱,并且批处理模型不适用于实时的监控和告警。不过,
监控数据和活动跟踪数据之间存在很多共性,信息之间的关联度(比如特定类型用户活动
对应用程序性能的影响)还是很高的。特定类型用户活动数量的下降说明相关的应用程序
出现了问题,批处理模型数小时的延迟说明系统无法对这类问题做出及时的响应。
最开始,我们调研了一些现成的开源解决方案,希望找到一个能够实时访问数据并可以通
过横向扩展来处理大量消息的系统。我们使用
ActiveMQ
创建了一个原型系统
,但它当时
还无法满足横向扩展的需求。对
LinkedIn
来说
,这是一种脆弱的解决方案。
ActiveMQ
的
很多缺陷会导致
broker
暂
停服务,进而导致客户端的连接被阻塞