Evernote架构摘要 – A Digest of Evernote’s Architecture (*)

前言:

这篇文章我最近研究小规模分布式系统时,在Evernote博客中发现的惊喜,里面大体介绍了Evernote后台的架构。虽然是一篇科普文没啥干货只有思路,但还是感触,老美的企业还是很有分享精神的(虽然据说Evernote正在走下坡路吧)。为了分(练)享(习)给(计)更(算)多(机)的(英)同(语)学,我选择翻译这一篇文章A Digest of Evernote’s Architecture (*)。翻译用的语调十分诙(dou)谐(bi),希望搏大家一笑的同时,能给大家带来知识。

evernote-highlevel-architecture1

让阿拉(译者:沪语的咱们)从这张简陋的Evernote服务物理构造概览开始。俺不想深入地说这张图里每一个组成部分的众多细节;俺们会计划在之后的文章中讨论这些有趣的点。

坐在图片的左上角的你是活动的起点,所有的统计数据截至2011年5月17日的…(译者:呵呵)

网络系统:差不多所有从Evernote进出的数据流量是通过HTTPS的443端口来到www.evernote.com的。这包括所有的“网络”活动,也包含所有通过俺们基于ThriftAPI的客户端同步事件。总得加起来,每天这些活动要产生1.5亿次HTTPS访问,峰值速率差不多是250Mbps。(俺们的凌晨运维团队脸很黑,太平洋时间每天凌晨6:30是流量高峰的来临时间。)(译者:中国是UTC+8时区,太平洋时间是UTC-8,这么算起来差不多北京时间22点达到流量高峰,啊哈哈哈原来Evernote码农睡不了懒觉是我大中华区的锅。)

俺们通过边界网关协议来引导由俺们的主运营商 (NTT) 和次运营商 (Level 3) 提供的专线网络流量。这些流量透过Vyatta路由器走向A10负载均衡器,这些全新的负载均衡器是一月份部署的,因为俺们旧负载均衡器的SSL表现出现了瓶颈。当前,俺们用一台AX 5000加上一个故障转移盒子就可以很爽地处理现在的流量,不过未雨绸缪的俺们正准备测试分布式N+1配置,以准备未来的流量增长。

Shards:Evernote的核心服务是由一大堆的服务器提供的,俺们管它们叫”Shards”。(碎片渣渣)每个Shard(碎片)处理一大伙差不多是100,000个Evernote注册用户的所有数据和流量。(web的和API的)从俺们有了超过九百万用户开始,这些数据流量被分配给了差不多90台Shard。

在物理上,Shards是部署在一组SuperMicro牌的机器上的,这些机器的配置是Intel四核处理器,大得很的内存和塞满了硬盘架的希捷RAID镜像硬盘阵列。在这些机器上,俺们运行了一个基础的Debian系统服务来管理两个Xen虚拟机。主虚拟机运行着俺们的核心程序栈:Debian + Java 6 + Tomcat + Hibernate + Ehcache + Stripes + GWT + MySQL(存储数据元) + 分层文件系统(存储文件数据)。(译者:这都是些啥。。。)

所有在一台机器上主虚拟机里的用户数据,会通过DRBD(Linux平台的分散式存储系统)同步复制到另一台机器上副虚拟机里头。这意味着,每一个byte的用户数据都至少分布在2台物理服务器的4块不同的企业级硬盘里,加上每晚上的定期备份。一旦俺们发现某个服务器出现了问题,俺们可以通过Heartbeat这个黑科技进行故障切换,将主虚拟机切换到那台副虚拟机上,宕机时间短得一笔。

因为每个用户的数据是完全位于一台虚拟Shard机上的,所以阿拉可以将每一个Shard作为一个孤岛,事实上没有干扰或是附属关系。这意味着,一台Shard上的问题,不会滚雪球一样地影响到其他的Shard。

为了将用户和他对应的Shard连接起来,俺们在开发负载均衡器上花了很多的心思。负载均衡器通过一大串的规则,在URL或者cookies里寻找这个用户的Shard。

用户存储:虽然大量的主要数据是存储于笔记仓库Shards里的,但是所有用户都共享唯一的一个主「用户仓库」账号数据库(也是基于MySQL的),其中包括每个账户小规模的信息,例如:用户名,密码的MD5,还有这个用户所对应的Shard编号。这个数据库足够小,以至于能够跑在内存里,不过俺们会结合RAID镜像、通过DRBD复制到备用服务器、并且每晚备份的方法,来保持高的冗余度。

AIR数据处理机:为了让你们看到图文并茂的笔记,俺们维护了一个拥有28台服务器的服务器池,这些服务器夜以继日地用它们8颗核心处理新图像。在繁忙的日子里,这些服务器将转换130万到140万个分散的图像。目前,这些服务器是Linux和Windows混着跑,不过既然俺们已经移除了一些麻烦的遗留依赖(估计是说Windows),俺们打算在这个月底之前将所有的服务器都运行Debian操作系统。

这些服务器正在流水化运行由俺们的R&B研发猴子团队开发的”Advanced Imaging and Recognition”(AIR)「高级图像和识别」(不是空气,也不是Adobe AIR)。这个软件清理【优化?】每一张图片,识别看上去像文字的区域,然后通过「识别引擎」根据列表匹配每一个字的含义。这套系统里的引擎,是由俺们在这方面的精英团队开发的,吹个牛逼举个例子,俺们的手写识别技术,可以和业界最佳的同行们的商业许可技术软件相媲美。

其他服务:每台服务都被俺们处心积虑想方设法地塞进一对专用的盒子里,然后放到俺们位于加州圣克拉拉市的数据中心里。除了为俺们提供核心服务的硬件以外,俺们还有差不多由一到两台刀片(刀片服务器)组成的服务器组或是Xen虚拟机用来运行一些轻量级服务。比如,俺们的「收件服务」SMTP入口是由一对运行着Postfix的Debian服务器负责的,然后俺们的自定义Java邮件处理进程是基于Dwarf搭建的。俺们的@myen Twitter入口是跑在内部运行的twitter4j进程上。

俺们所有的网站都是Apache的,俺们的博客学习Dick Wu是用的WordPress(逃,俺们几乎所有的备份接口切换是有惠普提供的(译者:这段翻译不是很会,贴上原文most of our fully redundant internal switching topology is from HP),俺们用Puppet来管理配置,俺们的监控服务是由ZabbixOpsviewAlertSite提供的。俺们每晚会进行异地数据备份,这些备份数据将会通过1Gbps的宽带传输到另外一个数据中心。

等等,可是为啥?俺意识到,这篇文章明显留下了许多问题:关于为啥俺们在许多地方选择X而不是Y?为啥俺们用自己的服务器而不是用阿里云?为什么用这么闷骚老旧的软件(Java, SQL, 本地存储等等)而不是新的黑科技?(译者:原文是魔术子弹)…

俺们会努力在接下来的几个月里透露这些问题的细节。

(*)2011年6月29日更新:在Conde Nast童鞋的要求下,文章的标题改成现在的了。原来的标题是《架构摘要》。

发表评论?

10 条评论。

  1. 单纯的笔记收费存储服务貌似并不能维持evernote的运营,真的是在走下坡路了,好高深的网络知识,直接看不大懂! 😛

发表评论


注意 - 你可以用以下 HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>