前言：

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

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

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

网络系统：差不多所有从Evernote进出的数据流量是通过HTTPS的443端口来到www.evernote.com的。这包括所有的“网络”活动，也包含所有通过俺们基于Thrift的API的客户端同步事件。总得加起来，每天这些活动要产生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来管理配置，俺们的监控服务是由Zabbix，Opsview和AlertSite提供的。俺们每晚会进行异地数据备份，这些备份数据将会通过1Gbps的宽带传输到另外一个数据中心。

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

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

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