可伸缩Web架构、OpenStack存储剖析、语义网工具演化—



 写点什么

本期的架构周报主要关注可伸缩 Web 架构技巧、Google 备份经验、OpenStack 存储剖析以及语义网工具演化等。

技术选型

OpenStack 存储

Openstack 通过 3 年多的发展，变得越来越庞大。这也是为了满足更多不同的需求，体现出开源项目灵活快速的特性。文章 OpenStack 存储剖析详细地总结了 Openstack 所涉及的各个组件的功能、配置和应用场景。

OpenStack 其实有三个与存储相关的组件，这三个组件被人熟知的程度和组件本身出现时间的早晚是相符的，按熟悉程度排列如下：

Swift—提供对象存储（Object Storage），在概念上类似于 Amazon S3 服务，不过 swift 具有很强的扩展性、冗余和持久性，也兼容 S3 API。对象存储支持多种应用，比如复制和存档数据、图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数据，为 Web 应用创建基于云的弹性存储。
Glance—提供虚机镜像（Image）存储和管理，它能够以三种形式加以配置：利用 OpenStack 对象存储机制来存储镜像；利用 Amazon 的简单存储解决方案（简称 S3）直接存储信息；或者将 S3 存储与对象存储结合起来，作为 S3 访问的连接器。OpenStack 镜像服务支持多种虚拟机镜像格式，包括 VMware（VMDK）、Amazon 镜像（AKI、ARI、AMI）以及 VirtualBox 所支持的各种磁盘格式。镜像元数据的容器格式包括 Amazon 的 AKI、ARI 以及 AMI 信息，标准 OVF 格式以及二进制大型数据。
Cinder–提供块存储（Block Storage），类似于 Amazon 的 EBS 块存储服务，OpenStack 中的实例是不能持久化的，需要挂载 volume，在 volume 中实现持久化。Cinder 就是提供对 volume 实际需要的存储块单元的实现管理功能。
Amazon 一直是 OpenStack 设计之初的假想对手和挑战对象，所以基本上关键的功能模块都有对应项目。除了上面提到的三个组件，对于 AWS 中的重要的 EC2 服务，OpenStack 中是 Nova 来对应，并且保持和 EC2 API 的兼容性，有不同的方法可以实现。

每个组件的具体介绍，可以查看 OpenStack 存储剖析。

语义网工具

文章语义网的工具演化系统、详细地分析了语义网所涉及的各个阶段中相关工具的发展，正如文中所说：语义网这个领域不缺理论，就缺系统和工具。作者认为，现有工具分为三类

学校搞出来的代表是 Protege，做 NSF 项目还行，对开发人员不友好。
小公司面向政府和行业用户搞出来，代表是 TopBraid Composer & Pellet，也对开发人员不友好。
大公司总结搞出来内部用的，代表是 Trinity & Graphd，一般人看都看不到。

作者认为，工具系统的竞争，是一个复杂的系统工程，绝不是一个标准化组织能组织和规划的。而工具的产生和演进，又是和用户与工程师的需求，理解能力和使用习惯密切相关的。基于 w3c 规范的工具系统，往往有太浓厚的学术性，不太贴合普通 Web 工程师的需求。

工具的改进，有对人不友好的问题，有对机器不友好的问题。我觉得这几年的当务之急是对人不友好的问题。云啊，可伸缩性啊，这些问题可以放一放，先把结构化数据生成的代价降下来再说。自然语言理解，数据库，用户交互这些都有用。个人认为核心问题还是用户交互，NLP 是起一个辅助的作用。工具的进化，说到底也一个社区的进化。是一群人建立了工具。所以从现有工具演化语义网的工具，也就是促进现有的程序员社区演化，用他们熟悉的语言，提供思路给他们解决他们头痛已久的问题。JSON, JS, Python, Lucene 等等，这些社区是希望所在。

架构技巧

可伸缩 Web 架构

Decide 公司 CTO _Kate Matsudaira_ 在文章可伸缩 Web 架构与分布式系统总结了自己的架构经验和设计准则，他提出，构建和运行一个可伸缩的网站或应用来说究竟意味着什么？从一个基本的层面来看，就是将用户和远程资源通过互联网连接起来——将其变得可伸缩的部分，是指这些资源或者访问这些资源是分布式的、贯穿于多个服务器。像很多生活中的事情一样，在构建一个 web 服务时花费时间提前做好计划将会帮助服务能够长久运行；理解一些大型网站背后的考量和权衡会在创建小型网站时帮助做出更明智的决定。下面是一些会影响到设计大型可伸缩性 Web 系统的关键准则：

可用性——一个网站的正常运行时间，对于很多公司的信誉和功能来说都是至关重要的。对于一些大型在线零售网站，甚至是几分钟的不可用都会导致数以千万计美元的收入损失，所以将他们的系统设计成不间断可用和能够弹性恢复既是一项基础业务也是一个技术需求。分布式系统的高可用性需要仔细考虑关键组件冗余，快速恢复部分有问题的系统，并且当出现问题时能够做到优雅降级。
性能——性能已成为大多数网站一个很重要的考量指标。一个网站的速度会影响到使用和用户满意度，同样也会影响到搜索引擎排名，将直接关系到网站收入和用户保持力（黏性）。因此，关键之处就在于创建一个为快速响应、低延迟的系统。
可靠性——一个系统需要做到可靠，这样才能使得对于（固定）数据的请求始终会返回同样的数据。如果数据发生变化或者更新，那相同的请求应该返回新的数据。用户需要知道，一旦一些数据被写入、存储到系统中，那么系统就会持久化（这些数据）并且能够让人信赖随时能够检索。
可伸缩性——对于任何大型分布式系统，系统规模只是可伸缩性需要考虑的一个方面。同样重要的是，增加容量能够处理更大量的负载所需的工作，通常在系统可伸缩性方面被提及到。可伸缩性会涉及到系统的很多不同的因素：系统额外还能够处理多少流量，是否能够轻易增加存储容量，还能多处理多少事务。

除此之外，还要考虑可管理性、成本等问题，具体的架构准则请查看 Kate 的文章。

Google 数据备份策略

Google 数据保密和数据安全负责人 Raymond Blum 在一次演讲中分享了 Google 数据备份的经验，Todd Hoff 在文章 Google 如何备份数据中详细总结了演讲的核心要点，有数十条之多，某些观点比较新颖，值得架构师和运维团队借鉴。InfoQ 中文站近期将推出详细的新闻报道，读者可以查看 Todd 的原文或者随后的中文报道。

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

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