存档

2011年5月 的存档

Best Android Apps

2011年5月29日 4 条评论

一份整理非常全面的 Android 最佳应用幻灯片,有超过 200 多页的内容。

知识共享图书《开源应用程序架构》

2011年5月28日 1 条评论

知识共享图书《The Architecture of Open Source Applications 》以 Creative Commons Attribution 3.0 Unported 许可方式发布,其内容覆盖 Asterisk, Berkeley DB, Hadoop, CMake, Eclipse, LLVM, Mercurial, Continuous Integration, NoSQL Ecosystem, Python Packaging, Erlang 等优秀开源软件和精彩内容,完全免费开放,别错过。

在线阅读

下载电子书 epub

分类: Architecture 标签:

Apache 之道

2011年5月28日 没有评论

作者:姜宁

  • Apache CXF committer, PMC member
  • Apache Camel committer, PMC member
  • Apache ActiveMQ committer

作者通过三个部分内容阐述了 The Apache Way:

1、Apache 软件基金会的介绍
2、Apache 之道是什么

  • 社区胜于代码 (Community over Code)
  • 任人为贤 (Meritocracy)
  • 共识决策 (Consensus)
  • 透明公开 (Transparency)
  • 非隶属关系 (Non-Affiliation)
  • 负责监督 (Responsible Oversight)

3、如何融入开源软件社区

  • 使用开源软件
  • 提交Bug报告
  • 完善开源社区文档
  • 参与邮件列表讨论
  • 成为开发者贡献代码

Apache 之道是 Apache 社区的文化体现,是一种重视协作的文化,Apache 已经成为协作开发的典范。

作者以其自身实际经历分享了他在Apache开源项目中的协作与成长,其理念不仅仅适用于开源软件社区,也同样适用于更为广泛的网络协作与分享,值得大家一读。

分类: Apache, Developers 标签: ,

Mozilla 构建系统

2011年5月11日 没有评论

英文来源:Mozilla’s Build System
中文出处:开放博客,由灰狐翻译小组制作

Mozilla 构建系统是一个非常酷的分布式系统,运行在BuildBot上。系统能在每次修改后自动重新构建和测试代码树。

目前,整个构建基础设施使用了大约 1,000 台机器并分组在3个 pools 池中,每个 pool 都有数台 Build Masters 和很多台 Slaves 组成:

构建池(Build Pool) 处理所有更改触发的构建,除了那些要去试验的构建:

  • 4 台 Build Masters
  • 大约 300 台 Slaves

试验构建池(Try Build Pool) 处理所有试验构建:

  • 1 台 Build Master
  • 大约 200 台 Slaves

测试池(Test Pool) 处理所有的测试,包括试验(Try):

  • 7 台 Test Masters
  • 大约 400 台 Slaves

它是如何工作的?

hg poller 每隔几分钟就在 hg.mozilla.org 仓库里寻找新的更改。这些更改通过构建调度者(Build Scheduler Master) 获得,并创建构建请求(Build Requests),为每一个支持的平台都创建一个。这些构建请求以待定的方式进入调度数据库。Build Masters 寻找待定的构建请求然后当有空闲Slaves就分配给它们。

为构建完整,Build Master 将状态更新到调度数据库中。另外,测试调度者(Test Scheduler Master) 为相应的测试创建测试构建请求。

接着,测试构建请求由 Test Masters 获得并分配给空闲的 Slaves。当测试完成,Test Master 更新它们的状态到调度数据库中。

每个 Build Master 和 Test Master 控制它们自己的一组 Slaves。

构建运行生命周期

每个推向 mozilla-central 的请求,如果成功的话,会生成总数为 168  个构建请求(截至2010年10月,但在未来会有所变化),其中 10 个构建(支持10种平台),108个单元测试和50个 talos tests。所有这些构建请求组成一个 Build Run。

10种平台的构建都需要有一套自己的测试请求。仅当相应的构建成功完成这些测试才被创建。这就意味着如果构建失败,这些测试将不被创建,Build Run 也不会有168个构建请求,

Build Run 生命周期中有两个非常重要的测量:等待时间(Wait Time) 和 端对端时间(End to End Time)。

等待时间测量在队列中的构建请求在开始执行前要等待多长时间,更具体的讲,它测量生成构建请求改变的时间戳和构建请求赋予空闲 Slave 的时间戳之前的时间差。(见上面 Build Run 的生命周期图)

端对端时间测量一个 Build Run 完成需要多长时间。也就是说,触发这个 Build Run  改变的时间戳和最终生成构建请求的时间戳之间的时间差(换句话说,就是当所有的构建和测试完成)。(见上面 Build Run 生命周期图)

正常情况下 mozilla-central 的端对端时间会少于4小时,但是随着系统负载的增加时间会有所延长。

Mac minis 垒的墙

构建是在一个虚拟机组合之上完成的,包含 1U 服务器,xserves 和 Mac minis,并且所有的测试都是在 Mac Minis 上完成的。

这堵 mac minis 墙是由 400 个 Mac minis 盒子垒成的,它被放在发布工程师在山景城的办公室里。

分类: Browser 标签: ,

深入 Facebook 消息应用服务器

2011年5月4日 没有评论

英文来源:Inside Facebook Messages’ Application Server
中文出处:开放博客,由灰狐翻译小组制作

要点:

  1. Facebook 统一消息系统(邮件、短信、聊天、消息等);
  2. HBase 作为后端存储设施,每个用户数据存储在 HBase 的单独一行里,每个实体(文件夹、主题、消息等等)都存储在自己的HBase列中;
  3. 涉及 HayStack 图片处理基础设施;
  4. 使用 Apache Lucene 维护反向索引列表;
  5. 镜像了大约 10% 用户的实时聊天和收件箱中的信息到测试集群中,并通过 dark launch 进行测试。

Facebook Messages 是我们曾经所创建的最具技术挑战性的一个代表产品。

当我们发布Facebook Messages 时所提到的是我们需要打造一个专门的应用服务器来管理其基础架构。

我们最近讨论了消息后台和我们如何处理所有来自 email, SMS, Facebook Chat 和 Inbox 的通信。

今天我们将深入消息应用服务器的核心。

应用服务器的业务逻辑

应用服务器集成了众多Facebook服务和保护(shields)来自各种终端的复杂性。它提供了一个简单接口方便客户端进行标准消息处理,包括:创建、读取、删除、更新消息和收件箱。

下面是每一部分的流程。

当创建一个新消息或回复消息时,应用服务器代表发送者传递消息到收件人。如果收件人是通过其邮件地址,则服务器通过HayStack获得附件(如果有的话),构造HTML主体,并创建一个RFC2822消息。

输出流

当消息发送给用户时,如果地址是一个回复处理,服务器将从存在的邮件地址和传递的输入消息中获得正确收件人的信息。服务器最终将消息传递到用户邮箱,运行所有必要的预处理和后期处理过程,并决定基于多个信号的文件夹和主题的消息路由。

输入流

当读取消息时,服务器取得有关用户邮箱的多个统计,如容量;消息、主题和回复数;朋友的数量等。同时也获得文件夹相关统计和属性,各种搜索条件的主题列表(文件夹,属性,作者,关键字等等),主题属性和这个主题的其它消息。

当删除消息时,服务器标记要删除的消息和主题。一个离线任务具体清除消息内容。

当更新消息和主题时,服务器改变消息或主题属性,如读取和到达状态,标签等等。同时也处理多个用户对主题的订阅和取消订阅的请求。

管理群组主题

Facebook Messages 使用一个聊天室模型管理群组消息主题。用户能加入(订阅)和离开(取消订阅)。

当邮件地址是是这个主题的指定接收者时这个模型是必须的,应用服务器创建一个回复处理器,类似聊天室ID。当一个邮件接收者回复了主题,则消息会被发送到回复处理器地址。

为了优化读取性能和简化移植和备份处理,消息主题以一种非规格化(denormalized)的方式存储。于是每个用户都拥有一份主题元数据和消息的拷贝,服务器广播订阅和取消订阅事件,在一个分散的方式中同步所有接收者订阅和回复处理的主题元数据。服务器也管理类似用户仍旧使用老的收件箱或通过他们的邮件地址订阅的情形。

缓存用户元数据

当用户访问收件箱时,应用服务器装载最常用的用户元数据(也称活动元数据)并将它们保存在最近最少使用的缓存中(a least recently used cache,也就是LRU算法)。随后,同一用户的请求会通过少量的HBase查询被快速的处理。

我们需要减少HBase查询,因为HBase不支持join, 为处理一个读请求,服务器可能需要在分开的HBase查询中查找多个索引和匹配元数据和消息体。HBase的最佳化体现在写操作而不是在读取上,用户行为通常拥有好的时间和地域性(good temporal and spatial locality),于是缓存能帮助解决这个问题并提升性能。

我们也在通过减少用户内存占用和转移到细粒度模式进而提升缓存的有效性方面做出了很多努力。我们能缓存5%-10%的用户量和95%的活跃元数据缓存命中率。我们在全局的memcache层缓存了访问极为频繁的数据(如在Facebook首页显示没有阅读的消息数)。当新消息到达时应用服务器标记缓存为(dirties)(注:dirties表示修改了但还没有写到数据文件的数据)。

同步

HBase对事务隔离提供了有限的支持。针对同一用户的多个更新可能同时发生。为解决它们之间的潜在冲突,我们使用应用服务器作为用户请求的同步点。一个用户在任何给定的时间里由独有的服务器提供服务。这样,同一用户请求就可以在应用服务器中以一种完整孤立的方式(Fashion)同步和执行。

存储模式

MTA代理特性附件和大量消息实体,在它们能到达应用服务器之前被存储在Haystack中。然而,元数据,包含索引数据和小的消息体,它们存储在HBase中并由应用服务器维护着。每个用户的收件箱都是独立于任何其它用户的;用户数据不会在HBase中共享(shared)。每个用户数据存储在HBase的单独一行里,它包含了以下部分:

元数据实体和索引

元数据实体包含收件箱对象属性,如文件夹、主题、消息等等。每个实体都存储在自己的HBase列中。不像关系型数据库(RDBMS),HBase没有提供用于索引的本地支持 。我们在应用级维护辅助索引(Secondary Indexes),同样以键/值对的方式存储在分开的列中。

比如,要回答查询“loading unread threads on the second page of the Other folder,” 应用服务器首先搜寻元数据索引以获得符合条件的主题列表,然后取出指定主题的元数据实体,以它们的属性构造响应。

正如我们前面所提到的,缓存和有效的预装载能减少HBase查询量以获得更好的性能。

活动日志

用户邮箱中的任何更新(如发表和删除消息,标记主题为已读等等)会立即以时间的顺序添加到列中,这称为一个活动日志(action log)。小的消息实体也存储在活动日志中。

我们能通过回放(replaying )活动日志的方式构造或恢复用户邮箱的当前状态,我们使用最后活动日志的ID以元数据实体和索引的版本回放。当用户邮箱被加载,应用服务器比较元数据版本和最后活动日志ID,如果元数据版本滞后(lags behind)则更新邮箱内容。

活动日志存储在应用级带来极大的灵活性:

  • 我们能通过回放活动日志无缝切换到一种新的模式并且能通过一个离线的 MapReduce 任务或在线的应用服务器自身生成新的元数据实体和索引。
  • 我们能在一个批处理中执行大量HBase异步写以节省网络带宽和减少HBase压缩成本。
  • 它是与其它组件交换持久性数据的标准协议。比如,我们通过将活动日志写到记录日志(Scribe log)做应用级的备份。这个移植管道转化用户老的收件箱数据到活动日志并且通过离线MapReduce生成元数据和索引。

搜索索引

为支持全文检索,我们维护着一个从关键字到匹配消息的反向索引。当一个新消息到达时,我们使用 Apache Lucene 去解析和转化它到一个(keyword, message ID, positions)元组(tuples)中,然后以递增的方式加入到 HBase 的列中。每个关键字都拥有自己的列。所有的消息,包括聊天记录,邮件和短信都被实时索引。

dark launch 测试

应用服务器是我们从零开始构建的一个全新软件,因此在将它推向5亿用户前我们需要监控它的性能、可靠性和伸缩性。我们最初开发了一个压力测试机器人(robot)用来生成模拟请求,但是我们发现这样的结果可能会受到其它一些新因素的影响,如消息长度,不同类型请求的分发,用户活跃度的分布等等。

为了仿真一个真实的产品负荷,我们制作了 dark launch,我们镜像了大约10%用户的实时聊天和收件箱中的信息到测试集群中。Dark launches 帮助我们发现更多性能问题和识别瓶颈。我们也使用它作为一个有说服力的指标来评价我们所做的很多改进 。接下来,我们会继续努力为我们的所有用户提供崭新的消息系统。

作者:Jiakai 是 Facebook Messages 开发小组成员。

分类: Architecture, Facebook 标签: