二、基本原理

对于系统架构来说，有一些事情需要考虑：什么是正确的组件，这些组件如何协作，需要做哪些正确的权衡。在真正需要可伸缩性之前的投资通常并不是一个明智的商业提议，然而，一些设计中的远见卓识将会在未来节省真正的时间和资源。

本节着眼于一些对于几乎所有大型Web应用都非常核心的因素：服务，冗余，分期和失败处理。每个因素均包含有选择和妥协，特别是在上一节提到的准则上下文中。为了详细解释这些，最好的方式就是从一个例子开始。

举例：图片托管应用

你很可能已经在网上上传过一张图片。对于托管和传送大量图片的大型网站来说，将会在架构建设上遇到很多挑战，比如成本效益、高可用性和低延迟性（能够快速检索）。

设想一个这样的系统：用户可以将他们的图片上传到一个中央服务器，并且图片可以通过一个web链接或者API（应用程序接口）进行请求，就像Flickr或者Picasa一样。为了简单起见，我们假定这个应用有两个关键部分：能够上传（写入）一张图片到服务器，能够查询一张图片。虽然我们希望上传能够更快速，但我们最关心的是系统能够快速分发用户请求的图片（比如图片可以被请求用于一张网页或是其他应用）。这些跟一个web服务器或者CDN（内容分发网络） edge server（CDN所使用的服务器，用于在很多位置存放内容，这样内容在地理/物理上更接近用户，起到更高性能的作用）所提供的功能非常类似。

系统其他重要的方面

• 对于存储的图片数量没有设限，所以就图片数量而言，需要考虑存储的可伸缩性。
• 对于图片的下载/请求需要做到低延迟。
• 如果一个用户上传了一张图片，那该图片应该总是存在的。（图片的数据可靠性）
• 系统需要易于管理（可管理型）。
• 由于图片托管不会带来很高的利润，所以系统需要做到有成本效益的。
• 

• 图片1.1：图片托管应用的简化架构图

   

  在这个图片托管例子中，系统必须做到（让用户）可感知到快速，存储数据的可靠性和那些所有高可伸缩的特征。构建一个小型的托管于单台服务器上的应用过于简单，也没有意义，对于本章来说也没有乐趣所在。来假设下，我们想要构建出可以成长为像Flickr一样的庞然大物。