Recently in Arch 分类

Instagram 架构分析笔记

| 12 Comments

Updated: 2012 年4月10日凌晨消息,Instagram 被 Facebook 以10亿美金收购。团队规模:13 人。

Instagram 团队上个月才迎来第 7 名员工,是的,7个人的团队。作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张。不得不说,这真他妈是个业界奇迹。

几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instances, Dozens of Technologies,披露了 Instagram 架构的一些信息,足够勾起大多数人的好奇心。读罢做点笔记,各种线索还是有一定参考价值的。能打开原文的建议直接读原文。

Instragram.png

Instagram 开发团队奉行的三个核心原则:

  • Keep it very simple (极简主义)
  • Don't re-invent the wheel (不重复发明轮子)
  • Go with proven and solid technologies when you can(能用就用靠谱的技术)

OS/主机

操作系统的选择,在Amazon EC2上跑 Ubuntu Linux 11.04 (Natty Narwhal) ,这个版本经过验证在 EC2 上够稳定。因为只有三名工程师,只有三名工程师,所以自己部署机器到 IDC 是不靠谱的事情。幸好有亚马逊。

负载均衡

此前曾用过两台 Nginx 做 DNS 轮询承载前端请求,这样做会有副作用,现在已经迁移到Amazon的ELB(Elastic Load Balancer),起了三个 Nginx 实例,在 ELB 层停掉了 SSL , 以缓解 CPU 压力。DNS 服务使用 Amazon Route53 服务。

应用服务器

启用了 25 个 Django 实例,运行在 High-CPU Extra-Large 类型的服务器实例上,之所以用 High-CPU Extra-Large 实例是因为应用请求是 CPU 密集型而非 IO 密集型。

使用 Gunicorn 作为 WSGI 服务器。过去曾用过 Apache 下的 mod_wsgi 模块,不过发现 Gunicorn 更容易配置并且节省 CPU 资源。使用 Fabric 加速部署。

数据存储

用户信息、图片元数据、标签等大部分数据存储在 PostgreSQL 中。主要的 Shard 数据库集群有 12个节点。

实践中发现 Amazon 的网络磁盘系统单位时间内寻道能力不行,所以有必要将数据尽量放到内存中。创建了软 RAID 以提升 IO 能力,使用的 Mdadm 工具进行 RAID 管理。

管理内存中的数据,vmtouch 这个小工具值得推荐。

PostgreSQL 设置为 Master-Replica 方式,流复制模式。利用 EBS 的快照进行数据库备份。使用 XFS 文件系统,以便和快照服务充分配合。 使用 repmgr 这个小工具做 PostgreSQL 复制管理器器。

连接池管理,用了 PgbouncerChristophe Pettus 的文章包含了不少 PostgreSQL 数据库的信息。

TB 级别的海量图片存储在 Amazon S3 上,CDN 采用的也是 Amazon 的服务,CloudFront。

Instagram 也是 Redis 的重度用户,Feed 以及 Session 信息都用 Redis 处理,Redis 也是以 Master-Replica 方式部署。在 Replica 节点上进行数据备份。

使用了 Apache Solr 承担 Geo-search API 的工作,Solr 简单的 JSON 接口也不错。

缓存使用了 6 个 Memcached 实例,库使用 pylibmc 和 libmemcached。亚马逊也提供缓存服务-Elastic Cache service ,Instagram 也有尝试,不过不便宜。

任务队列/发布通知

队列服务使用 Gearman ,通知系统则使用 pyapns 来实现。

监控

前面提及的服务器实例数量加起来,的确有100多个,有效的监控是相当有必要的。使用 Munin 作为主要监控工具 , 也写了不少定制插件,外部监控用 Pingdom 的服务。通知服务使用 PagerDuty

对于 Python 的错误报告,使用 Disqus 团队开源的 Sentry 来处理。

几个感想

0)轻装上阵说起来容易,做起来非常难。这也是 Instagram 团队目前最令人着迷的地方;

1)Python 社区已经足够成熟,各个环节上都已经有不错的解决方案了。

2)如果要问我最大的一个感慨,我要说:Amazon 真是一家伟大的公司,甚至比 Google 还伟大

--EOF--

Quora 用了哪些技术 ?

| 21 Comments

很多团队都在学习、研究 Quora 。前段时间看到这篇 Quora's Technology Examined ,阐述了 Quora 的技术架构,有一些值得关注的信息,记录并分享一下。

使用云计算服务

Quora 大量使用 Amazon EC2 与 S3 服务;操作系统部署的是 Ubuntu Linux,易于部署和管理;静态内容用 Cloudfront.服务分发,图片先传到 EC2 服务器,使用 Pyhon S3 API 处理后后传到 S3。

从开始就使用云计算服务的的好处是节省了大量人工维护硬件服务器的成本,当然这个做法在咱这片土地上不太可行。

Quora_China_chat.png.scaled500.png
(refer: Copyright )

Web 层与 CMS

HAProxy 作为前端负载均衡服务器,反向代理服务器是 Nginx,Nginx 后面则是 Pylons (Pylons + Paste) , 承担动态 Web 请求。

Webnode2 与 LiveNode 这两个内部系统承担创建、管理内容的重任,Webnode2 生成 HTML、CSS 与 JavaScript ,并且与 LiveNode 轻度耦合。LiveNode 的作用用以显示 Web 页面内容。用 Python、C++ 与 JavaScript 写的。特别提到用到了 jQuery 与 Cython。LiveNode 有可能开源。

为什么用 Python?

前面已经提到了一些 Python 相关的技术组件。有意思的是从 Facebook 出来的团队居然用 Python 作为主要开发语言。Quora 对此有所解释: Facebook 选择 PHP 也并非是最佳选择,而是有历史原因。Quora 技术团队在考察了多个语言之后选择的 Python ,当然理由有一大堆,总体看来,并非很激进。

通信处理

后端通信使用的是 Facebook 开源出来的 Thrift,除了开发接口简单之外,可能更为熟悉也是一个因素吧 :) Comet 服务器使用的是 Tornado,用以处理 Long polling 以及 Push 更新(不知道知乎用的什么?),Tornado 是前 FriendFeed 技术团队开源的产品。

实时搜索

因为 Sphinx 不能满足实时性方面的要求,Quora 启用了自己开发的搜索引擎,只使用了 Thrift 与 Python Unicode 库,此外没有用别的。Quora 的搜索比较特别,因为要对输入内容做关联并且要做有效提示,所以需要提供更好的前缀索引(Prefix indexing)功能。

Quora 搜索的实现还是挺有技术含量的,对后端的查询请求压力也不小(或许当前的并发请求量还没那么大)。对这个场景,做相关开发的朋友不妨仔细研究一下。如果大体框架类似,那么决定最后生出的因素很可能是那些细节。

数据持久层

大量使用 MySQL 作为存储方案,Memcached 作 Cache 层。没有使用当前比较火爆的 NoSQL 相关产品。Quora 这样做有自己的理由,用户量级没有达到百万的 SNS 站点完全没必要用 NoSQL 的东西。或许以后 Quora 也会启用。

创始人查理·奇弗(Charlie Cheever)与亚当·德安杰洛(Adam D'Angelo)之前都在 Facebook ,所以,Quora 的技术还真有不少 Facebook 的基因。Quora 的团队规模并不大,做技术的估计十余人而已,这么紧凑的团队利用了这么多的技术与产品,可见很多人都是多面手了。这是国内技术团队需要向国外同行学习的地方。

--EOF--

这只是一篇概要性的描述,如果要知道一些更为细节的东西,请看 Quora 上的相关评论,上文中已经给出相关链接。

按:这篇 How Facebook Ships Code 提供了大量的细节信息,之前已经有朋友提供了一个翻译版本,阅读之后发现有些许错误,并且原文有更新,所以基于前面的翻译版本我重新翻译了一个(完整的)版本。一并谢过。希望这个版本对大家也有所参考。

我对 Facebook 的运作方式着迷。这是个非常独特的环境,很难被复制(这个方式并不适合所有的公司,即使有些公司尝试过这么做)。下面这些笔记来自我和Facebook的许多朋友的交谈,关于他们开发、运维与软件发布等方面。

好像很多人都对 Facebook 感兴趣... 这家公司的工程师驱动文化(Developer-driven culture)已经被公众大加研究,并且其它其它公司也在探求是否/如何实现工程师驱动文化。Facebook 的内部流程实在够神秘,当然,工程师团队也会发布一些关于新功能以及部分内部系统公开备忘,不过这些大多数是"说明"类的文章(What),而非讲述"机制"(How)... 所以,外部人员很难明白 Facebook 的创新以及如何比其它公司做到更有效的对服务进行优化。我作为外部人员尝试深入理解 Facebook 的运作,汇集了几个月来的这些观察信息。出于对信息来源的隐私保护,我去掉了特定功能/产品的名字。我又等了6个月以后才发布这些记录,所以,有些信息肯定过时了。我希望发布这些信息会有助于了解 Facebook 的管理机制如何在组织中进行决策的推行而非逐步陷入混轮...很难说这与 Facebook 的成败或是 Facebook 的产品协作相关。我相信很多面向消费者的互联网公司会从 Facebook 这个案例受益。

*非常*感谢那些帮助我整理这篇文章的 Facebook 内部的朋友们。也要感谢项 epriest fryfrog 这样的朋友,他们协助我进行对本文进行校正、编辑。

记录:

  • 截止到2010年6月,Facebook有将近2000名员工,10个月前只有大约1100人,一年之间差不多翻了一番!
  • 工程部和运维部是两个最大的部门,每个大概都有 400-500人。这两个部门人数大约占了公司的一半。
  • 产品经理(PM)与工程师的比例大约为1-7到1-10。
  • 每个工程师入职时,都要接受 4 到 6 周的 "Boot Camp" 培训,通过修复Bug 和听更资深的工程师的课程来熟悉 Facebook 系统。每次 Boot Camp 大约有 10% 的人无法完成课程而被淘汰。
  • 培训结束后,每个工程师都可以访问线上的数据库【标准课程"能力越大,责任越大" ( "with great power comes great responsibility") 对此有阐释,另有一份明晰的"不可触犯的天条",比如共享用户的隐私数据】。
  • [修改, 感谢 fryfrog] "Facebook 有非常牢靠的安全保障,以免有人(你可以想象内部有人有这个权限的)不小心/故意做了些糟糕的的事。如果你已经"成为"了需要别人支持的人,事由将被记录,并且有谨慎的审计。这里不允许钻空子。
  • 任何工程师都可以修改Facebook的代码库,签入(Check-in)代码。
  • 浓厚的工程师驱动文化。"产品经理基本可以被忽略",这是Facebook一名员工的话。工程师可以修改流程的细节,重新安排工作任务,随时植入自己的想法。[评论] "本文的作者是一个产品经理,所以这个论断引起里我的注意。你看完整篇文章后会发现,很显然,Facebook 的文化实际上是拥抱产品经理的实践的,所以,不是产品经理的角色被忽略,而是,这家公司的文化看上去是想让"每个人"感受到对产品的责任"。
  • 在每月的跨部门会议上,由工程师来汇报工作进度,市场部和产品经理会出席会议,也可以做些简短的发言,但如果长篇大论的话,将如实反馈给他们的主管,"产品人员在上次会议说的太多"。他们确实想让工程师来主导产品的开发,对自己的产品负责。
  • 项目需要的资源都是自发征集的:
  • 某个产品经理把工程师们召集起来,让他们对自己的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说:"我下周想开发这5个新特性"。
  • 经理会让工程师独立开发,可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性 -- 前端 JavaScript/后端数据库,等等所有相关的部分。如果需要得到设计人员的帮助,需要先让设计人员对你的想法产生兴趣(专职的设计师很少)。请架构师帮忙也是如此。但总体来说,工程师要独立完成所有的任务。
  • 对于某个特性是否值得开发的争执,通常是这么解决的:花一个星期的时间实现,并在小部分用户中(如1%的内华达的用户)进行测试。
  • 工程师通常乐衷致力于架构、扩展性以及解决"难题",那样能获得声望和尊敬。他们很难对前端项目或用户界面产生太大的兴趣。这跟其他业务为导向的公司可能正好相反,那些公司人人都想做客户能直接接触到的东西,然后会指着某个特定的用户体验说,"那是我做的"。在 Facebook,后端的东西,比如 News Feed 算法、广告投放算法、Memcache 优化等等,是工程师真正倾慕的项目。
  • News Feed 因为太重要了,扎克会亲自审查任何变动。这是个特例。
  • [更正, 感谢 epriest ]"所有的代码变更都要经过强制性的代码审查(比如一个或者多个工程师)。我相信这篇文章只是说 扎克并不自己审查每一个变更"。
  • [更正, 感谢 fryfrog ]"所有的修改至少要被一个人审查,而且这个系统可以让任何人很方便地审核其他人的代码,即使你没有邀请他。提交未经审查的代码,将被视为恶意行为"。
  • 工程师负责测试、Bug 修复以及启动对自己项目的维护。有单元测试和集成测试的框架可用,但很少使用。
  • [更正, 感谢 fryfrog ] "补充一下,我们是有 QA 的,只是没有正式的 QA 组而已。每个办公室或通过VPN连接的员工会使用下一版的 Facebook,这个版本的 Facebook 会经常更新,通常比公开的早 1-12 小时。所有的员工被强烈建议提交 Bug,而且通常会很快被修复"。
  • 回复:很奇怪只有很少的 QA 或自动测试 -- "大部分工程师都能写出基本没有bug的代码,只是在其他公司他们不需要这么做。如果有 QA 部门,他们只要把代码写完,扔给他们就行了" [编辑:请注意这是很主观的,我选择包括这部分内容是因为这和那些其它公司的标准开发实践完全相反]
  • 回复:很奇怪,缺少产品经理的影响和控制 -- 产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的管理者搞好关系。需要大致了解技术,不要提一些愚蠢的想法。
  • 默认情况下,所有提交的代码每打包一次(周二)。
  • 只要多一分努力,终于一天会发生改变。
  • 星期二的代码发布,需要所有提交过代码的工程师在场。
  • 发布开始前,工程师必须在一个特定的 IRC 频道上候命,否则将会被公开问责。
  • 运维团队通过逐步滚动的方式进行代码发布:
  • Facebook 有大约 60000 台服务器。
  • 有9个代码发布级别。
  • [更正 感谢 eriest] "九个级别并非同轴的(concentric)。有三个同轴的阶段(p1=内部发布, p2=小范围外部发布, p3=完整的外部发布),其余六个阶段是辅助层,比如内部工具、视频上传主机等等"。
  • 最小的级别只有6台服务器。
  • 比如,星期二的代码发布会先发布到 6 台服务器上(第一级),运维组会观测这 6 台服务器,保证代码正常工作,然后再提交到下一级。
  • 如果发布出现了问题(如报错等等),那么就停止下一级的部署,提交出错代码的工程师负责修复问题,然后从头继续发布。
  • 所以一次发布可能会经历几次重复:1-2-3-修复,回到 1, 1-2-3-4-5-修复, 回到1, 1-2-3-4-5-6-7-8-9。
  • 运维团队受过严格训练,很受尊敬,而且极具有业务意识。他们的工作指标不止包括分析错误日志,负载和内存使用状态等等,还包括用户行为。比如,如果一个新的发布导致一定比例的用户对 Facebook 功能进行声讨,运维团队将查看相关指标,可能基于他们的调查停掉该次发布。
  • 在发布过程中,运维组使用基于 IRC 的通知系统,可以通过 Facebook、Email、IRC、IM SMS 通知每一个工程师,如果需要他们注意的话。对运维组不做回应会被公开问责。
  • 代码一旦发布到第9级,并且稳定运行,本周的发布宣告结束 。
  • 如果一个特性没有按时完成,也没什么大不了的(除非外部依赖严重),下次完成时一并发布即可。
  • 如果被 SVN-blamed(应该指没按照规范提交代码会受到的惩罚)、公开问责(Public shamed, 示众?还是通告批评?)或工作经常疏忽就很可能被开除。"这是一个高效的文化"。不够高效或者不够聪明的员工会被剔除。管理层会在 6 个月的时间里观察你表现,"你不能适应这种文化,只能说再见"。每一级都是这个待遇,即使是 C 级别和 VP 级别,如果不够高效,也会被开除。
  • [更正, 感谢 epriest ] "人们不会因为导致 Bug 而被解雇,只有在发布他们的代码时导致问题,而他们恰恰又不在场(也找不到其他可以替代的人)"。
  • [更正, 感谢 epriest] "被问责不会导致解雇。我们特别尊重别人,原谅别人。大部分高级工程师都或多或少犯过一些严重的错误,包括我。但没有人因此被解雇"。
  • [更正, 感谢 fryfrog] "我也没有遇到过因为上面提到过的犯错而被解雇。我知道有人不小心将整个网站宕掉过。一旦有人犯错,他们会竭尽全力修复问题,也让其他人得到了教训。就我来看,这种公然蒙羞与被解雇的恐惧相比更为奏效"。

分析 Facebook 的研发文化如何随着时间演化是件非常有趣的事。特别是当公司发展壮大到数千员工的时候,这种文化是否还能够延续?

你觉得如何?在你公司里,"开发者驱动(developer-driven)文化" 将会可行么?


译者后记:很多时候是管中窥豹也是非常有趣的,而且,应该细致一点儿。另外,或许我们更应该关注为什么 Facebook 能够形成这样的文化。你说呢?

译者后记续:Facebook 能形成工程师主导的文化,应该和 Facebook 的产品形态有很大关系。毕竟 Facebook 人人都会用 Facebook ... 换言之,如果是 Amazon / eBay 这样面向商业的用户的公司,业务逻辑会让工程师陷入五里雾中。

--EOF--

延伸阅读:Hacker News: What I Learned from Zuckerberg's Mistakes

Foursquare 长达 11 小时的宕机

| 25 Comments
今天是个值得庆贺的日子

前几天 Foursquare 经历了长达 11 个小时的宕机,没错,11 个小时。网站官方的解释是 Shard 负载不均匀造成后续的连锁反应。很多人都知道 Foursquare 在线的 DB 是 MongoDB,今天又看到 10gen (MongoDB的开发与支持团队)的 Eliot Horowitz 在得到 Foursquare 许可后,通过邮件组详细介绍了宕机的过程:Foursquare outage post mortem,不用说,也有为 MongoDB 辟谣的意味在里面。

读罢 10gen 团队的介绍(或者说解释)之后,发现这是一个很好的研究样本。值得分享。

为了提高响应速度,Foursquare 使用 MongoDB 存储 Check-in 的数据已经有一段时间了。这部分数据的数据库起初跑在一个 66GB 内存的 Amazon EC2 单实例上(全部在内存里),两个月前,出于对容量增长的考虑,迁移到两台 Shard 集群上。每个 Shard 机器都是 66GB 内存,为了冗余,每个 Shard 都有复制到 Slave 实例。迁移的目标是所有的 Check-in 数据都保存在内存中。数据根据 ID 分成 200 个 Shard 分片,两台机器各占一半,也就说联机数据在每台机器上各使用 33GB 的内存。两个月相安无事。

问题来了,因为 Shard 算法导致的数据分散不均衡,其中一台(Shard0)数据增长到 67GB(另外一台 50GB),超过了 66GB 的限制,读写部分分散到磁盘上,性能急剧下降。从而,网站宕机。

首先尝试增加第三台 Shard 机器,上线后开始迁移,读取从三台进行,Shard0 的数据迁移到 5% 的时候,但是写操作还是让 Shard0 宕机了。这个时候发现Shard0 存在数据碎片(data fragmentation),即使数据迁移走,还是会占用原来的内存。每个Check-in 文档大约占用 300 字节,而 MongoDB 是 4KB 的页(Page),也就说十几个文档会填满一个页,而迁移 5% 反而造成了页更加稀疏,并不是将页全部删除。

这个时候已经到了第二天,随着网站全面宕机,技术团队开始用 MongoDB 的 repairDatabase() 功能来对数据库进行压缩,因为数据库太大和 EBS 慢,也因为 repairDatabase() 不能充分利用多核CPU 的能力,这个过程耗费了 4 个小时。之后这 5% 的内存空间终于释放出来,系统重新上线。

随着 Shard0 修复,第三台成功上线,进而添加了更多的 Shard 服务器,现在数据已经更加的均衡,通过在Slave上运行 repairDatabase(),然后将其切换到 Master ,每台 Shard 内存占用缩减到 20GB左右。整个故障时间已经延续了 11 小时之多。

产生问题的主要原因就是系统过载,前面介绍每台 Shard 承载原来 50% 的压力,到了问题发生的时候,单台 Shard 的负载已经超过 Shard 之前的系统负载,这时候已经积重难返了,在容量的临界点增加新系统资源,必然导致更多的停机时间。暴露了 Foursquare 团队在容量规划方面的不足之处,或许也因为业务增长太快了吧。另外,内存碎片化的问题在没有宕机之前,技术团队应该没考虑过这个问题,如果文档的大小超过 4K,碎片化问题就不严重了,这是特定应用场景造成的特定问题。10Gen 现在已经着手研究如何进在线压缩(online compaction)。再次,Shard 键值的顺序和插入顺序是不同的,这造成了迁移数据的时候 Chunk 的迁移不是连续的。

这个过程给我们的启示是:最近 NoSQL 已经成为一个热词,类似 MongoDB 这样的新事物当然值得尝试,但是不能冒进,因为驾驭起来并非易事。仅仅能够使用是不够的,系统没出问题一切都好,一旦出了异常,有足够的技术力量(设想一下 Foursquare 得不到 10gen 团队的支持会如何?) 支持么?在极端情况下如何控制? 如果回答不了这个问题,那么还应该暂缓。最好的办法就是..."等待"。

给我的另一个感慨是 Amazon 在云计算领域已经真的成为一个赢家,而且越来越得到 Web 2.0 Startup的信赖。前面说的 66GB 内存,应该指的是EC2 的 "High-Memory Double Extra Large Instance",可提供的最大内存是 68.4 GB 。CPU 和内存能力都是可以接受的,存储方面的性能似乎还有点不足,也就是其中的 EBS ,指的是 Amazon Elastic Block storage。

--EOF--

从 C10K 到 C500K

| 16 Comments

还在谈 C10K 的问题?这个已经过时了,现在大家已经开始说 C500K

国外的 Urban Airship 公司的工程师在其官方网志上发文章介绍他们在产品环境中做到 50 万并发客户端,Java + Pure NIO 的实现,最近又有文章介绍针对 Linux Kernel 调优的经验:Linux Kernel Tuning for C500k 。并且指出了"单个 IP 最大并发数量上限为64K" 只是一个误解。

硬件环境?操作系统为 Ubuntu(Lucid),租用 Amazon 的 EC2 ,使用 EC2 Large instances,64 位操作系统,每个 7.5 GB 内存。

当然,Urban Airship 是做手机消息 Push 服务的(Android Push 架构),所以,如果你也要做到这样的并发,还要看你的应用场景是否合适。去年了解到曾在新浪、腾讯任职的杨建已经做到超过 20 万的 HTTP 并发(现在可能已经突破这个限制了),非常的惊人。我非常想知道现在各个公司在这方面的实践数据。

--EOF--

另外参考:A Million-user Comet Application with Mochiweb

更新:杨建同学发来消息,去年已经单击突破 46.5万 Connections, 两块网卡, 1.5G 输出。10万请求处理每秒,每个响应 2k 左右。据说当时遇到一个坎一直没能过 50 万,不过这个坎三个月前已经过了,现在过 60 应该没悬念,四核双 CPU 机器。据杨建说,"按现在 4 Core * 4CPU 的机器,我觉得可以冲刺 80~100万,前提需要4块网卡(千兆)"。可见,把事情做到极致是没有极限的。

按:承蒙林昊( @Bluedavy )看得起,嘱托我为他的大作《分布式Java应用:基础与实践》写序,倍感荣幸之余也颇有压力。读完本书的绝大部分章节后,这相信这会是我今年要向朋友们推荐的关于架构的图书。毕竟我在阿里系工作有年,对几家子公司的技术还算有所了解,内容有没有料还是可以一目了然的分辨的出来的。下文是推荐序。


  

提起诸如"高性能"、"高可用"、"大规模并发"、"可扩展性"这些词汇,我相信多数技术人的心情都是激动而稍有点复杂的,当然,也或许是不屑一顾。毕竟不是谁都有机会面对这些富有挑战的技术场景,也不是每个架构师在面对这些挑战之前都能做好技术上的准备。那些意外故障总是不期而至,疲于奔命的解决问题的场景回顾起来对架构师来说犹如一场噩梦。

  

本书阐述当一个面向数以亿计用户的网站经过几年高速发展,技术团队不得不面临大规模、高并发、高扩展性等挑战带来的技术困境的时候,一个出色的架构师经过多年一线实践后累积的经过时间考验的解决方案以及宝贵的实战经验。在这本书里,你会看到作者在解决一些关乎Web应用问题的指导原则、实践方法、多重工具的综合运用以及作者本人的感悟。要强调的是,本书讲述的内容是一个Web应用从小到大过程中遇到的棘手问题的解决之道,并非宏观解析,亦非屠龙之技。无论您面对的站点是大是小,皆会有参考作用,毕竟大站点会越来越复杂,而小站点总有一天也将变大。

  

如今到计算机书店里走一下,会发现Java架构相关的技术图书业已不少,但仍有理由相信本书内容填补了在Java架构实战方面的空白。在互联网应用大行其道的今天,有些名义上主题为Java架构的图书,要么单从Java本身阐述,缺乏整体应用的大局观;要么是高屋建瓴,从编程思想的高度坐而论道,缺乏实践性;要么是闭门造车之作,缺乏验证性。本书作者林昊多年来致力于推动OSGi在国内的发展,不乏理论技术功底,而后加盟淘宝网 (Taobao.com)的几年间奋战在架构一线,爬摸滚打积累了丰富的实践心得。所以,本书是一本不折不扣的"理论结合实践"之作。

  

考虑国内的技术图书出版环境以及必须尽力迎合读者的预期,写书本身是一件费力不讨好的事情,但将知识传递给更多人无疑是让人快乐的。现在,经过作者近两年的梳理与总结,这本书即将出版,相信您在研读本书之后有所收获并运用到您所面对的Web应用上,也期待将来有更多朋友能够分享架构实践经验,不亦快哉!

--EOF--
  

按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。

本篇是本系列的最终章,将总结一下App Engine在使用方面的注意点,最佳实践和适用场景,最后会谈一下我对App Engine的一些期望。

注意点

  • 执行速度偏慢:由于其分布式的设计,所以在速度方面不是最优的,比如普通的Memcache能在几毫秒完成操作,而App Engine的Memcache则大概需要50(毫)秒才能完成操作。
  • 私有API:其API有很多都是私有,特别是在其服务方面,虽然Google提供了很不错的文档,但是在学习和移植等方面,成本都很高。
  • 执行会出现失败的情况:根据很多人的实际经验,App Engine会不定时出现执行失败的情况,特别是Datastore和URLFetch这两部分,虽然Google已经将Datastore方面出现错误的几率从原先的0.4降至现在的0.1,但是失败的情况是很难避免的。
  • 有时会停机:虽然总体而言,停机并不频繁,但是在今年初出现长达136分钟故障导致部分用户的应用无法正常运行,其发生原因来自于其备份数据中心出现了问题。
  • 无法选择合适的数据中心:比如,你应用所面对的用户主要在欧洲,但是你应用所属App Engine服务器却很有可能是被部署在一个美国的数据中心内,虽然你的应用很有可能在将来移动至欧洲某个数据中心,但是你却无法控制整个过程。
  • 有时会处理请求超时:虽然能平均在100至200ms之间完成海量的请求,但是有时会出现处理请求超时的情况。
  • 不支持裸域名:只支持类似CNAME的子域名。

最佳实践

  • 适应App Engine的数据模型:因为其数据模型,并不是传统的关系模式,而且在性能方面表现也和关系型数据库差别很大,所以如果想要用好非常关键的Datastore,那么理解和适应其数据模型是不可或缺的。
  • 对应用进行切分:由于App Engine对每个应用都有一定资源限制,而且为了让应用更SOA化和更模块化,可以对一个应用切分多个子应用,比如,可以分成一个用于前端的Web应用和多个用于REST服务的后台应用。
  • 极可能多地利用Memcache,这样不仅能减少昂贵的Datastore操作,而且能减轻Datastore的压力。
  • 在上面提到过,由于App Engine在执行某些操作时会出现失败的情况,比如Datastore方面,所以要在设计和实现这两方面做好相应的异常处理工作。
  • 由于Datastore不是关系型数据库,导致在执行常见的求总数操作时显的有点"捉襟见肘",所以最好使用Google推荐的Sharded Counters技术来计算总数。
  • 由于Blobstore还只是刚走出试验期而已,而且其他模块对静态文件(比如图片等)支持不佳,比如Datastore只支持1MB以内的对象,同时每个应用只能最多上传一千个文件,而且速度不是最优,所以推荐使用其他专业的云存储,比如Amazon的S3或者Google马上就要推出的Google Storage等。
  • 尽量使用批处理方式,不论是在使用Datastore还是发送邮件等。
  • 不要手动创建Index:因为App Engine会自动根据你在代码中查询来创建相关的Index。

适用场景

现在而言,App Engne主要适用于下面这三个场景:

  • Web Hosting:这是最常见的场景,在App Engine上已经部署了数以十万计的小型网站(其中有很多主要为了学习目的),而且还部署了一些突发流量很大的网站,其中最著名的例子就是美国白宫的"Open For Questions"这个站点,主要用于让美国人民给奥巴马总统提问的,这个站点在短短的几个小时内处理接近百万级别的流量。
  • REST服务:这也是在App Engine平台上很常见的场景,最出名的例子就是BuddyPoke,BuddyPoke的客户端就是一个Flash应用,在用户的浏览器上运行,而它的服务器端则是以REST服务的形式放置在App Engine上,每当Flash客户端需要读取和存储数据的时候,它都会发请求给后端的REST服务,来让其执行相关的Datastore操作。
  • 依赖Google服务的应用:比如应用能够通过App Engine的Email服务来发送大规模的电子邮件。

未来的期望

  • 更稳定的表现,更少的超时异常和更快的反应速度,特别是在Datastore和Memcached这两方面。
  • 支持对数据中心的选择,虽然现在App Engine会根据应用的用户群的所在地来调整应用所在的数据中心,但由于整个过程对开发者而言是不可控的,所以希望能在创建应用的时候,能让用户自己选择合适的数据中心。
  • SLA,如果App Engine能像S3那样设定一些SLA条款,这样将使用户更放心地在App Engine上部署应用。
  • 新的语言:比如PHP,但是如果在现有的App Engine架构上添加一门新的语言,整个工作量会非常大的,因为App Engine有接近一半的模块是语言特定的,比如应用服务器和开发环境等,所以短期内我认为不太可能支持新的语言。

总体而言,Google App Engine是Google大战略中一个不可分割的一部分,因为Google希望能通过App Engine来降低Web应用开发的难度,只要难度降低了,那么Web应用替代客户端应用的整体速度将会加快,如果出现这样的情况的话,那么将会对Google今后的发展非常有利。

本系列文章结束。

参考资料:

--EOF--

按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。

本篇会首先会从程序员角度来介绍一下Datastore在使用方面的一些信息,之后会接着介绍Datastore是如何构建的。

使用方面

首先,在编程方面,Datastore是基于"Entity(实体)"这个概念,而且Entity和"对象"这个概念比较类似,同时Entity可以包括多个Property(属性),Property的类别有整数,浮点和字符串等,比如,可以设计一个名为"Person"的Entity,它包含名为"Name"的字符串Property和名为"Age"的整数Property。由于Datastore是"Schema-less"的,所以数据的Schema都由应用维护,而且能非常方便地对一个Entity所包含的属性进行增删和修改。在存储方面,一个Entity的实例可以被认为是一个普通的"Row(行)",而包含所有这种Entity的实例的Table被称为Kind,比如,所有通过"Person"这个Entity生成实例,比如小吴,小朱和小华等,它们都会存放在同一个名为"Person"的Kind中。在结构方面,虽然也能通过特定的方式在Datastore中实现关系型结构,但是Datastore在设计上是为层次(Hierarchical)性结构"度身定做"的,有Root Entity和Child Entity之分,比如,可以把"Person"作为Root Entity(父实体),"Address"作为"Person"的Child Entity,两者合在一起可以称为一个"Entity Group"。这样做的好处是能将这两个实体集中一个BigTable本地分区中,而且能对这两个实体进行本地事务。

接下来,将谈一下Datastore支持那些高级功能:其一是提供名为GQL(Google Query Language)的查询语言,GQL是SQL的一个非常小的子集,包括对">","<"和"="等操作符。其二是App Engine会根据代码中查询语句来自动生成相应Index,但不支持对Composite Index生成。其三是虽然由于Datastore分布式的设计,所以在速度方面和传统的关系型数据库相比一定的差距,但是Google的架构师保证大部分对Datastore的操作能在200ms之内完成,同时也得益于它的分布式设计,使得它在扩展性方面特别出色。其四是Datastore也支持在实体之间创建关系,比如在Python版App Engine中可以使用ReferenceProperty在实体间构建一对多和多对多的关系。

下表为Datastore和传统的关系型数据库之间的比较:

  Datastore 关系型数据库
SQL支持 只支持一些基本的查询 全部支持
主要结构 层次(Hierarchical) 关系
Index 部分可自动创建 手动创建
事务 只支持在一个Entity Group内执行 支持
平均执行速度(ms) 低于200 低于100
扩展型 非常好 很困难,而且需要进行大量的修改

表1. Datastore和关系型数据库之间的比较

最后,在接口方面,Python版提供一套私有的API和框架,在基本功能方面,比较容易学习,但在部分高级功能方面,比如关系和事务等方面,学习难度很高;Java版的API是基于JDO和JPA这两套官方的ORM标准,但是和现在事实的标准Hibernate有一定的差异。

实现方面

在实现方面,Datastore是在BigTable的基础上构建的,所以本段会首先重新介绍一下BigTable,之后会介绍Datastore的两个组成部分:Entities Table和Index,最后会讲一下它在事务和备份这两方面所采用的机制。

BigTable

在本系列的第一篇已经按照Google的Paper对BigTable技术做了一定的介绍,但其实BigTable本身其实没有之前介绍的那样复杂,其实就是一个非常巨大的Table,这也是是它之所以名为"BigTable"的原因,而且结构就像图1那样非常简单,就是一个个ROW,每个ROW都有一个Name和一组Cloumn,但是为了支持海量的数据,它将这个大的Table进行分片(Sharding)处理,每台服务器存储一个海量的Table的一小部分,并且为了查询效率,会对这个Table进行排序。就像App Engine的创始人之一Ryan Barrett所说的那样"BigTable is a sharded, sorted array "。

BigTable Simple.PNG

图1. BigTable简化版模型

在功能方面,首先,BigTable支持基本的CRUD操作,也就是增加(Create),查询(Read),更新(Update)和删除(Delete)。其次支持对Single-Row的事务与基于前缀和范围的扫描。

Entities Table

它是Datastore最核心的Table,是以BigTable的形式存在的,主要用于存储所有的Entity,而且是格式非常简单,每行都会有一个Row Name,也称为Entity Key(可认为它是一个Entity的Primary Key),而且只有唯一一个Column,主要用于存放被序列化的Entity。每个Entity的Key的生成是基于它的父Entity(如果有的话)和其父至上的Entity,直到其Root Entity。以下图为例,timmy的父Entity是jane,jane的父Entity兼Root Entity是Ethel,所以最后timmy的Entity Key是"/Grandparent:Ethel/Parent:Jane/Child:Timmy"。

entity keys.PNG

图2. Entity Key的例子

Index

Index主要是为方便和加速查询而生的,所以在切入Index之前,先介绍一下Datastore主要支持那些查询,主要有三类:其一是基于Kind的,其二是基于Property值的,其三是基于多个Property值的。

Index表也是以BigTable的形式存在,但是和上面的Entities Table是分离的,主要用来单独存放那些需要被Index的数据,而且由于怕Index表体积太大,所以不会有时将其放置在内存中以提升查询速度。

主要有下面这几种Index表:

  • Kind Index:用于加速那些用于获取所有属于某个Kind的Entity的查询,比如把所有属于Person这个Kind的Entity,包括小吴,小朱和小华等提取出来,Kind Index表每行有Kind和Entity Key这两个列,此Index会有系统自动生成。
  • Single-property Index:用于加速那些基于单一属性值的查询,比如要找出所有Age在20之下的Person,Age就是所谓的那个单一属性值,Single-property Index表每行除了Kind和Entity Key之外,还有属性名和属性值这两个列,此Index也会有系统自动生成,还会根据升降序的不同,生成两个表。
  • Composite Index:用于加速那些基于对多个属性值的查询,Composite Index表基本和上面的Single-property Index表非常类似,但是每行包括多个属性名和属性值,而且由于此Index消耗资源非常多,所有由开发人自己确定是不是需要这个Index,系统不自动生成。

事务

原则上所有对单一Entity的Write操作都是事务的,并基于上面提到的BigTable的Single-Row事务和Optimistic Concurrency Control这两个技术,下面是流程:首先,系统会读这个Entity的Committed Timestamp(提交时间戳),Write会以串行(Serialized)的形式写入到BigTable的日志中,之后,系统会将日志更新到BigTable的表中,如果成功的话,系统会更新这个Entity的Committed Timestamp,但如果系统发现在更新之前,Committed Timestamp发生了变化,也就是说另一个事务在这个事务执行过程中已经对这个Entity进行了操作,在这个时候,系统会重新执行这个事务。由于在整个事务过程采用Optimistic Concurrency Control,而不是Locking,所以在吞吐量方面表现不错。

如果要对多个Entity执行事务,那就需要将这几个Entity设为一个Entity Group,也就意味着将这几个Entity放在同一台物理机上。在执行的时候,会将以Root Entity的Committed Timestamp为准来对所有参与事务的Entity进行和上面差不多的事务操作。

备份

与BigTable基于Row级别的备份不同的是,Datastore是基于Enity Group级别,而且采用Paxos算法,所以Datastore的备份方法比BigTable的更安全。

总体而言,Datastore在设计理念上和传统的关系型数据库有很大的不同,所以其在反应速度和写数据方面不是最优的,但是现在Web应用以读为主,而且需要能通过简单的扩展就能支持其海量的数据,而这两点却是Datastore所擅长,所以Datastore非常适合支撑Web应用。

本篇结束,下篇是本系列的总结。

--EOF--