可伸缩 Web 架构与分布式系统

、基本原理

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

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

举例:图片托管应用

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

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

系统其他重要的方面

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

     

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