写点什么

从 Bitly 构建分布式系统中吸取的教训

  • 2014-08-05
  • 本文字数:2091 字

    阅读完需:约 7 分钟

在五月的 Bacon 会议中,bitly 应用开发主管 Sean O’Connor 讲解了bitly 开发人员从构建一个月处理点击量 60 亿的分布式系统中吸取到的相关教训。

什么是分布式系统?

Sean 表示,关于分布式系统的定义很容易在维基百科上找到,一个分布式系统有三个很明显的特征:

  • 组件节点间真正的并发,要有相关的开销和复杂度来协调这些节点。
  • 缺少一个共有的时钟,让不同节点上的事件按时间顺序发生是不可能的。
  • 独立的故障,应该被理解为具有这样的能力:一个节点的失败不会影响到系统中的其他节点。

构建一个分布式系统需要处理好这些特性。Sean 认为这样的一种方法已经过时了。这种方法通过将系统从一开始就抽象成不是分布式的系统,隐藏了一个系统的分布式特性带来的复杂度。Sean 说,由于系统的分布式特性迟早会从抽象中显现出来,这种方法注定会失败。取而代之的,抽象应该建立系统分布式特性的模型,并处理好任何显现出来的特性。

将服务作为积木

Bitly 的架构使用服务的概念进行定义。一个服务是通过 API 明确定义的、专门提供一些功能的抽象。根据 Sean 的描述,服务对应于分布式系统就像函数对应于代码,这就允许站在更高的层次上看问题,而不用知道所有的实现细节。这个想法带来了另一种思考问题的方式。

Sean 提到了通过小型服务构建系统所获得的益处:

  • 代码行数的减少,使得一个服务更容易被理解。
  • 独立的故障,因为如果一个服务停止只意味着系统失去了特定的功能,但整体上系统仍然保持运行。
  • 易于判别系统的哪部分存在问题。

异步消息传递

确保一个系统可扩展的关键点是,在节点之间使用异步消息和消息队列来改进节点的独立性,所以一个节点没有必要等待另一个节点的回应。

这样做的一个好处是,如果一个节点出现了一些问题而暂时不能处理所有到来的消息时,这些消息将被保存在队列中以便尽快处理。此外,一个节点的故障不会直接影响其他节点。

尽管在许多场景中,异步消息传递更自然地用于同步处理某一类操作,但它也有复杂之处。比如 Sean 提到,在 bitly,由于对数据处理有越快越好和一致性的要求,缩短 URL 是一个完全同步的操作。这意味着一个缩短后的 URL 不应该返回给不同的使用者。另一方面,分析有着不同的需求,适合于使用完全异步的操作执行。因此,当 bitly 想要收集处理关于用户在链接上的行为的度量数据时,它只是将数据放进流向下游处理的队列中,而不用关心处理需要花多长时间。根据 Sean 的解释,尝试将一个本质上同步的操作异步化可能非常复杂,因此最好能先了解这个操作的本质。

关于节点间的交互,Sean 最终的评论指出,相比于将消息看成是从一个节点流到另一个节点的命令,把消息当成事件将更有益。一个事件是对某地发生某事的一个描述,并且发送节点不需要知道接收节点的任何信息。另一方面,如果一条消息是一个命令,那么发送节点必须了解接收节点处理这条命令的能力。因此,在生产者节点不知道任何信息的情况下,把消息看待成事件极大地有助于节点隔离、天然地支持多消费者以及消费者的动态增加和删除。

把消息当成事件也会导致另外一种实现:从生产者的角度看,标记消息的方法比过滤消息的方法更好。作为一个例子,Sean 提到了私有和公有链接的处理。生产者可以对私有链接进行过滤,以确保这些链接不会到达对其不感兴趣的下游节点。但这要求生产者能推断出下游需要关心什么样的数据。取而代之地,bitly 对私有链接进行标记,让消息自由地流入下游,确信下游节点能够以适当的方式对消息进行处理。

让服务能良好地运行在一起

Bitly 通过以下方法确保服务良好地运行在一起:

  • 使用排压机制,让发送请求的节点知道一个服务是否繁忙或过载,这样它们就能够调节发送请求的速率。这有助于维持系统的健康,防止连锁错误的发生。作为一个例子,Sean 提到了服务缓存的初始化:如果在缓存初始化过程中不断地接收到请求,就会有导致数据出错的风险。
  • 根据服务的健康状态对请求进行负载均衡。Bitly 使用了自己开发的 hostpool 用于负载均衡,跟踪失败的服务并优先选择更健康的服务。

监控

通过引用Leslie Lamport 的话“一个分布式系统是一个这样的系统,系统中一台机器上未知的故障都可能会导致你自己的计算机无法使用”,Sean 引入了监控这个话题。Bitly 拥有400 多台服务器,所以监控是一个非常必要的任务,因为这是知道系统中某些东西无法正常工作的唯一途径。

Sean 提供了一些关于监控的诀窍:

  • 使用 Nagios 检查服务器状态。
  • 运行完整性检查以确保服务提供正确的数据。
  • 将日志集中在一起,因为集中不同节点的日志有助于分析和诊断系统中发生了什么。
  • 确保相关的人能及时收到相关的信息。Bitly 使用了自己开发的 nsq 消息平台,旨在通过和 Web UI 的结合,能容易地观察到部署期间的一举一动。

Bitly 是一个用于社交网络,短信和电子邮件的缩短URL 服务。除了缩短URL,bitly 也搜集关于引用链接的分析数据,这是bitly 商业模型的核心。

参考英文原文: Lessons Learned Building Distributed Systems at Bitly


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-08-05 23:222135

评论

发布
暂无评论
发现更多内容

为什么在做微服务设计的时候需要DDD?

xcbeyond

微服务 DDD 3月日更

币BI掌柜量化交易策略APP开发(系统案例)

《3%法则》读书笔记

boshi

读书笔记 七日更

复盘读书笔记

lenka

3月日更

第六次作业

秦挺

基于SparkMLlib智能课堂教学评价系统-相关研究及文献分析(二)

大数据技术指南

大数据 智能时代 28天写作 3月日更

去年,蚂蚁一面的一道笔试题,中等难度

yes

面试

Wireshark数据包分析学习笔记Day10

穿过生命散发芬芳

Wireshark 数据包分析 3月日更

源码分析 -Netty:多线程在Netty中的应用

程序员架构进阶

Java 源码分析 Netty 28天写作 3月日更

对产品经理的一些思考

ES_her0

28天写作 3月日更

算法攻关 - 从上到下打印二叉树2 (O(n))_offer32

小诚信驿站

刘晓成 小诚信驿站 28天写作 算法攻关 从上到下打印二叉树

如何使用标准稳压器输出几百毫伏极低直流电压?

不脱发的程序猿

28天写作 电路设计 3月日更 电源电路 标准稳压器

Web安全之XSS

架构精进之路

Web 安全 3月日更

团队开发工具之一——Wiki

吴脑的键客

wiki

redis分布式锁实现

Sakura

28天写作 3月日更

Android源码分析笔记:(2021-3-13)事件分发

Geek_416be1

甲方日常 93

句子

工作 随笔杂谈 日常

沟通视窗:改善人际沟通

石云升

28天写作 职场经验 管理经验 3月日更 沟通模型

如何在子线程中使用Toast显示消息

Geek_416be1

2021年金三银四全新版互联网大厂Java面试题,分类65份PDF,累计2340页

Java 架构 面试

种春草肥禾,织数字天下

脑极体

马特量化炒币机器人APP系统开发详情介绍

#区块链#

竞价实例一小时亏损21万

jinjin

阿里云 抢占式实例 竞价实例 spot

冒泡插入选择排序以及PHP实现

一个大红包

3月日更

第一天(VBA, Python最最最基础入门)

橙橙橙橙汁丶

自学 办公自动化 python excel IT蜗壳教学 vba

Mac Os下搭建Hadoop运行环境

白程序员的自习室

大数据 数仓 hadoo

使用Hadoop相关框架进行网站流量日志分析

五分钟学大数据

大数据 hadoop 28天写作 3月日更

BI币掌柜量化自动交易机器人开发

#区块链#

翻译:《实用的Python编程》05_02_Classes_encapsulation

codists

Python

5年Java开发,面试4大厂(阿里、拼多多、字节、美团)后,我总结出大厂高频面试真题及解析

Java架构之路

Java 程序员 架构 面试 编程语言

量化合约跟单交易系统开发软件

#区块链#

从Bitly构建分布式系统中吸取的教训_SOA_Sergio De Simone_InfoQ精选文章