WhatsApp 架构、Java EE 7 特性、HackerEarth 经验——架构周报

本期的架构周报主要关注 WhatsApp 架构分享、Java EE 7 的新特性、HackerEarth 利用 Apache 和 Django 建站的优化经验、MySQL 还是 NoSQL 的选择。

WhatsApp 架构分享

Facebook 以 190 亿美元收购 WhatsApp，其每月 4.5 亿活跃用户奠定了其价值，Tod Hoff 撰文分析了支撑每日数百亿消息的高可靠架构。其中的细节包括：

• WhatsApp 做后端消息路由的服务器系统使用 Erlang 实现，如此庞大数量的活跃用户只使用非常少的服务器来管理，团队一致认为这很大程度上归功于 Erlang。
• WhatsApp 使用了什么样的协议？WhatsApp 服务器池使用了 SSL Socket，在客户端重新连接对消息进行获取之前，所有消息都会在服务器上排队。消息的成功获取会发回给 WhatsApp 服务器，它将会被重新转发给原始发送者，一旦客户端成功接收这条消息，它就会在服务器存储中擦除。
• 系统的健康状况主要看队列的长度，每个节点上消息队列的长度都会被一直监控，超过预先设置的临界值则会发出提醒，多个警报发生则标志着系统进入了下一个瓶颈。
• 有些代码基本上每天都在变化，通常情况下是一天几次。当然，峰值期间必须避开的。Erlang 非常适用于将修改或者是新功能添加到产品，热加载意味着无需重新启动就可以实现修改，错误可以很快的得到解决，同样通过热加载，系统变得更加松耦合，这可以让更新快速的发布。
• 记录整个系统状态，包括 OS 状态、硬件状态、BEAM 状态。这是为了便于从其他系统获取状态信息，如虚拟内存。跟踪记录 CPU 利用率、系统整体利用率、用户时间、系统时间、中断时间、上下文切换、系统调用、系统陷入、数据包发送和接收、所有进程队列中总消息数、繁忙的端口事件、通信速率、字节输入 / 输出、调度状态，垃圾回收状态等。

更多架构详情，可以查看 Tod Hoff 的技术文章。

Java EE 7 特性

Java EE 7 的新特性主要集中在提高开发人员的生产力、加强对 HTML5 动态可伸缩应用程序的支持和进一步满足苛刻的企业需求这三个方面。Java EE 7 使得开发人员可以写更少的样板代码，通过丰富的组件来提供一个完整、全面、集成的堆栈来支持和构建最新的 Web 应用程序和框架，同时提供更具扩展性、丰富性和简易的功能。

“ Java EE 7 三大新特性的介绍”介绍了组件 WebSocket 1.0、JSON Processing 1.0、JAX-RS 2.0、JSF 2.2 和 JMS 2.0 等。主要的特性可以概括为：

• 提高开发人员的生产力——通过一个紧密集成的平台简化了应用架构，减少样板代码和加强对注释的使用来提高效率，另外借助标准 RESTful Web 服务对客户端的支持提高了应用程序的可移植性。
• 加强对 HTML 5 动态可伸缩应用程序的支持——基于其可扩展的基础架构，Java EE 7 推动了对 HTML 5 应用的构建和支持。在新的平台中，借助具有行业标准的 JSON 简化了数据分析和交换，并通过低延迟和双向通信的 WebSockets 减少了响应时间。以及利用改进的 JAX-RS 2.0 更好地支持异步的、可扩展的、高性能的 RESTful 服务，从而更好地支持多用户的并发操作。
• 满足苛刻的企业需求——细化批处理作业，形成可管理的区块，以实现不间断的 OLTP 性能；简化多线程并发任务的定义，以提高可扩展性；以及提供具有选择性和灵活性的事务应用程序等。

HackerEarth 利用 Apache 和 Django 建站的优化经验

HackerEarth 是一个对编程技能进行实践和测试的服务网站，highscalability 上刊载了有关 HackerEarth 利用 Apache 和 Django 建站的优化经验，其中包括：

• 删除不必要的 Apache 模块。节省内存并提高性能。通过只包括你所需要的模块你可以将需要加载的模块数削减为一半。
• 使用 Apache MPM (Multi-Processing Module 多路处理模块) worker。对于高流量服务器一般是一个更好的选择，因为它与 prefork MPM 相比会占用更少的内存。
• 关掉 KeepAlive。实验显示，对于 CloudFont 中供应的静态文件来说这样做是更加有效的，进程 / 线程可以自由地瞬间处理新的请求，而不必等待一个请求到达旧的连接上去。
• 检查配置。启用 mod_status.so 和 mod_info.so 模块来看 Apache 是怎样运行的。这些信息帮助他们显著地减少了我们要运行的服务器数量，并且使应用程序更稳定，抵御流量的突增。
• 不要为运行了 100 台服务器而引以为豪。而应该写出更好的代码并调整系统。在大量的请求中投放许多服务器并不是什么值得骄傲的事，这意味着要确保，例如，一个请求不能查询数据库 20 以上。

MySQL 还是 NoSQL 的选择

开源数据领域被分成了两派，NoSQL 和 MySQL。John Engates撰文分析了 NoSQL 和 MySQL 的选择问题。他认为：

如果规模和性能比 24 小时的数据一致性更重要，那 NoSQL 是一个理想的选择。NoSQL 依赖于 BASE 模型——基本可用、软状态、最终一致性。但如果要保证到“始终一致”，尤其是对于机密信息和财务信息，那么 MySQL 很可能是最优的选择。MySQL 依赖于 ACID 模型——原子性、一致性、独立性和耐久性。

作为开源数据库，无论是关系型数据库还是非关系型数据库都在不断成熟，我们可以期待还会有一大批基于 ACID 和 BASE 模型的新应用产生。暂且把它称为混合方案。有时这些应用程序的设计需要认真地权衡利弊，有时还能意外的得到发展，做出一系列调整以适应不断变化的数据需求。

对架构领域感兴趣的读者可以关注即将于 2014 年 4 月 25~27 日在北京国际会议中心召开的QCon 北京 2014 大会，专题包括知名网站案例分析、扩展性、可用性与高性能、云计算服务探秘、大数据处理与大数据应用等，许多讲座都与架构相关。读者可点击大会主页查看详情。

欢迎读者朋友推荐或者投稿架构相关的文章，联系邮箱为 editors@cn.infoq.com ，标题请注明“架构专栏”。