AOL 架构原则、优秀 API 设计、Yeoman 工具——架构周报

本期的架构周报主要关注 AOL（美国在线）的高可用性架构、技术专家 Joshua Bloch 对优秀 API 的设计观点、新的 Web 应用开发工具集 Yeoman 和 OpenStack 网络项目 Neutron 的介绍。

技术选型

Yeoman 工具集

随着 Web 2.0 和 HTML 5 的流行，现在的 Web 应用所能提供的功能和交互能力比之前传统的 Web 应用要强大很多。应用的很多实现逻辑被转移到了浏览器端来实现。浏览器不再只提供单一的数据接收和展现功能，而是提供更多的用户交互能力。浏览器端所包含的 HTML、CSS 和 JavaScript 代码也变得更加复杂。对于日益复杂的前端代码，需要有更好的流程和工具来管理开发的各个方面，包括初始的代码结构、开发流程和自动化测试等。Yeoman 是一个新兴的工具。它结合了 Yo、Grunt 和 Bower 等工具，组成了一个完整的工具集合，提供各种 Web 应用开发中所需的实用功能。Yeoman 的最大优势在于它整合了各种流行的实用工具，提供了一站式的解决方案，使得 Web 应用开发中的很多方面变得简单。Yeoman 使得开发人员可以专注于应用本身的实现，而不用在搭建应用的基础结构、进行任务构建和其他辅助任务上花费过多的时间和精力。Yeoman 同时也把一些好的最佳实践自动地引入到项目的开发中。比如当需要在应用中使用第三方的 JavaScript 库时，一般的做法是直接到库的网站上进行下载。而 Yeoman 中基于 Bower 进行依赖管理的做法则是更好的实践方式。

成富的文章“ Yeoman：Web 应用开发流程与工具”详细介绍了 Yeoman 的组成部分和使用技巧。

OpenStack 网络项目 Neutron

OpenStack 是一个开源的 IaaS（基础设施及服务）云计算平台，让任何人都可以自行建立和提供云端运算服务，具体可以从 devstack 脚本开始熟悉它。OpenStack 由一系列相互关联的项目提供云基础设施解决方案的各个组件，核心项目（9 个）：计算 (Compute) - Nova，网络和地址管理 - Neutron，对象存储 (Object) - Swift，块存储 (Block) - Cinder，身份 (Identity) - keystone，镜像 (Image) - Glance，UI 界面 (Dashboard) - Horizon，测量 (Metering) - Ceilometer，编配 (Orchestration) – Heat。

OpenStack 网络服务，现已由之前的 Quantum 改名为 Neutron。Neutron 是 OpenStack 核心项目之一，提供云计算环境下的虚拟网络功能。OpenStack Havana 版本的 Release Note 描述了 Neutron 新增加的功能：

1. Multi-Vendor-Support：同时支持多种物理网络类型，支持 Linux Bridge、Hyper-V 和 OVS bridge 计算节点共存；
2. Neutron-Fwaas：支持防火墙服务；
3. VPNaas：支持节点间 VPN 服务；
4. More-Vendors：更多的网络设备支持和开源 SDN 实现完善和提高，新增加了 ML2 (The Modular Layer2) 插件。

陈海洋的文章“ OpenStack 网络：Neutron 初探”对 Neutron 做了一个系统的介绍，感兴趣的读者可以查看其文章。

架构技巧

AOL 的高可用性架构

作为著名的新闻网站，AOL 日访问人次达 800 万，每秒请求达 20 万，在这样的访问压力下，其可用性依然达到了 99.999%。最近，AOL 的架构师 Dave Hagler 在 HighScalability 上分享了 AOL 的架构设计经验。其中，几个架构原则包括：

最重要的就是冗余一切，在系统中某个部分发生故障，或者需要离线维护时，有个备份无疑省时省力，而 5 个 9 的可用率要求每年不超过 5 分钟宕机时间。

第二个原则就是 AOL.com 不能依赖任何共享基础设施去交付页面，即使某个系统或内容发生故障，AOL.com 仍然需要维持着高可用。历史上，AOL 大部分的网络内容都共享一个被称为 Big Bowl 的基础设施，这样会存在一个非常致命的问题——不同内容之间的相互影响。为了解决这个问题，AOL 专门设计了不同内容之间的隔离，任何依赖 AOL.com 的内容都会被一个保护服务转移至一组更少的主机上，保护服务负责将调用聚集到下游系统。因此，不再是从上万个节点上接收请求，下游系统可能只会从 20 个不同的服务器上获取请求，响应同样会被缓存来减少负载。同时，运维团队还会对 AOL.com 备份外部数据库。这样一来，在整个系统中只有网络和协议服务被共享。

另一条原则是缓存可以被用于优化性能，但是系统不能依赖于缓存来实现可扩展性。网站的基础设施应该被设计成即使没有缓存，也可以正常服务于终端用户。

优秀 API 设计

谷歌架构师 Joshua Bloch 最近分享了一份幻灯片，系统的讨论了优秀 API 的设计原则。他指出：每个 API 接口应该只专注一件事，并做好：如果它很难命名，那么这或许是个不好的征兆，好的名称可以驱动开发、并且只需拆分与合并模块即可。设计原则包括：

• API 应尽可能地简洁：满足需求、对有疑问的地方可以暂时不使用（函数、类、方法、参数等，你可以不添加，但千万不要删除）、概念性的东西比体积重要）；
• 实现不要影响 API：关注实现细节（不要迷惑用户、不要随便改变实现方式）、意识到具体的实现细节（不要有越权的方法行为，例如不所有的调优参数都是可疑的）；
• 不要让实现细节“泄露”到 API（例如 on-disk 和 on-the-wire 格式等异常情况）；
• 最小化可访问：设计人员应尽量把类及成员设为私有，公共类不应该有公共字段（包括异常实例），最大限度地提高信息隐藏，允许模块可以被使用、理解、构建、测试和独立调试；
• 命名问题：应该见名知意，避免含糊的缩写、对同一样东西的命名应该有个一致性的前缀（遍及整个平台 API）、讲究对称、代码应该易读。

架构师书单

从本期开始，架构周报将推出“架构师书单”栏目，目的是向架构领域的读者推荐一些涉及技术选型、架构技巧、理论研究、案例分析、架构师软技能等方面的书籍。本期推荐的书都是大数据领域相关的，分别是“大数据：技术与应用实践指南”和“大数据挑战与NoSQL 数据库技术”，适合架构师做技术选型。

“大数据：技术与应用实践指南”，系统性地分析了大数据的发展背景、基本概念，从业务的角度分析了大数据应用的主要业务价值和业务需求，在此基础上介绍大数据的技术架构和关键技术，结合应用实践，详细阐述了传统信息系统与大数据平台的整合策略，大数据应用实践的流程和方法，并介绍了主要的大数据应用产品和解决方案。

“大数据挑战与NoSQL 数据库技术”分为三部分。理论篇重点介绍大数据时代下数据处理的基本理论及相关处理技术，并引入NoSQL 数据库；系统篇主要介绍了各种类型NoSQL 数据库的基本知识；应用篇对国内外几家知名公司在利用NoSQL 数据库处理海量数据方面的实践做了阐述。

这两本书可以帮助读者在涉及到大数据、NoSQL 数据库等领域时，进行各个相关技术、产品做技术对比和分析，从而对最终技术的采纳提供决策支持。

QCon 北京 2014 大会

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

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