最新消息:

构建高可扩Web架构和分布式系统实战

365bet开户 采集侠 浏览 评论

开源软件已经成为许多大型网站的基本组成部分,随着这些网站的逐步壮大,他们的网站架构和一些指导原则也出现在开发者们的面前,给予切实有用的指导和帮助。本文旨在介绍一些核心问题以及通过构建模块来制作大型网站,实现最终目标。

这篇文章主要侧重于Web系统,并且也适用于其他分布式系统。

Web分布式系统设计的原则

构建并运营一个可伸缩的Web站点或应用程序到底指的是什么?在最初,仅是通过互联网连接用户和访问远程资源。

和大多数事情一样,当构建一个Web服务时,需要提前抽出时间进行规划。了解大型网站创建背后的注意事项以及权衡可能会给你带来更加明智的决策,当你在创建小网站时。下面是设计大型Web系统时,需要注意的一些核心原则:

1.可用性

2.性能

3.可靠性

4.可扩展

5.易管理

6.成本

上面的这些原则给设计分布式Web架构提供了一定的基础和理论指导。然而,它们也可能彼此相左,例如实现这个目标的代价是牺牲成本。一个简单的例子:选择地址容量,仅通过添加更多的服务器(可伸缩性),这个可能以易管理(你不得不操作额外的服务器)和成本作为代价(服务器价格)。

无论你想设计哪种类型的Web应用程序,这些原则都是非常重要的,甚至这些原则之间也会互相羁绊,做好它们之间的权衡也非常重要。

基础

当涉及到系统架构问题时,这几件事情是必须要考虑清楚的:什么样的模块比较合适?如何把它们组合在一起?如何进行恰当地权衡?在扩大投资之前,它通常需要的并不是一个精明的商业命题,然而,一些深谋远虑的设计可以帮你在未来节省大量的时间和资源。

讨论的重点几乎是构建所有大型Web应用程序的核心:服务、冗余、分区和故障处理能力。这里的每个因素都会涉及到选择和妥协,特别是前面所讨论的那些原则。解释这些核心的最佳办法就是举例子。

图片托管应用程序

有时,你会在线上传图片,而一些大型网站需要托管和传送大量的图片,这对于构建一个具有成本效益、高可用性并具有低延时(快速检索)的架构是一项挑战。

在一个图片系统中,用户可以上传图片到一个中央服务器里,通过网络连接或API对这些图片进行请求,就像Flickr或者Picasa。简单点,我们就假设这个应用程序只包含两个核心部分:上传(写)图片和检索图片。图片上传时最好能够做到高效,传输速度也是我们最关心的,当有人向图片发出请求时(例如是一个Web页面或其他应用程序)。这是非常相似的功能,提供Web服务或内容分发网络(一个CDN服务器可以在许多地方存储内容,所以无论是在地理上还是物理上都更加接近用户,从而导致更快的性能)边缘服务器。

该系统需要考虑的其他重要方面:

1.图片存储的数量是没有限制的,所以存储应具备可伸缩,另外图片计算也需要考虑

2.下载/请求需要做到低延迟

3.用户上传一张图片,那么图片就应该始终在那里(图片数据的可靠性)

4.系统应该易于维护(易管理)

5.由于图片托管不会有太高的利润空间,所以系统需要具备成本效益

图1是个简化的功能图

图1 图片托管系统的简化结构图

在这个例子中,系统必须具备快速、数据存储必须做到可靠和高度可扩展。构建一个小型的应用程序就微不足道了,一台服务器即可实现托管。如果这样,这篇文章就毫无兴趣和吸引力了。假设我们要做的应用程序会逐渐成长成Flickr那么大。

服务

当我们考虑构建可伸缩的系统时,它应有助于解耦功能,系统的每个部分都可以作为自己的服务并且拥有清晰的接口定义。在实践中,这种系统设计被称作面向服务的体系结构(SOA)。对于此类系统,每个服务都有它自己的独特功能,通过一个抽象接口可以与外面的任何内容进行互动,通常是面向公众的另一个服务API。

把系统分解成一组互补性的服务,在互相解耦这些操作块。这种抽象有助于在服务、基本环境和消费者服务之间建立非常清晰的关系。这种分解可以有效地隔离问题,每个块也可以互相伸缩。这种面向服务的系统设计与面向对象设计非常相似。

在我们的例子中,所有上传和检索请求都在同一台服务器上处理。然而,因为系统需要具备可伸缩性,所以把这两个功能打破并集成到自己的服务中是有意义的。

快进并假设服务正在大量使用;在这种情况下,很容易看到写图片的时间对读图片时间有多大影响(他们两个功能在彼此竞争共享资源)。根据各自体系,这种影响会是巨大的。即使上传和下载速度相同(这是不可能的,对于大多数的IP网络来说,下载速度:上传速度至少是3:1),通常,文件可以从缓存中读取,而写入,最终是写到磁盘中(也许在最终一致的情况下,可以被多写几次)。即使是从缓存或者磁盘(类似SSD)中读取,数据写入都会比读慢(Pole Position,一个开源DB基准的开源工具和结果)。

这种设计的另一个潜在问题是像Apache或者Lighttpd这些Web服务器通常都会有一个并发连接数上限(默认是500,但也可以更多),这可能会花费高流量,写可能会迅速消掉所有。既然读可以异步或利用其他性能优化,比如gzip压缩或分块传输代码,Web服务可以快速切换读取和客户端来服务于更多的请求,超过每秒的最大连接数(Apache的最大连接数设置为500,这种情况并不常见,每秒可以服务几千个读取请求)。另一方面,写通常倾向于保持一个开放的链接进行持续上传,所以,使用家庭网络上传一个1 MB的文件花费的时间可能会超过1秒,所以,这样的服务器只能同时满足500个写请求。

图2:读取分离

规划这种瓶颈的一个非常好的做法是把读和写进行分离,如图2所示。这样我们就可以对它们单独进行扩展(一直以来读都比写多)但也有助于弄明白每个点的意思。这种分离更易于排除故障和解决规模方面问题,如慢读。

这种方法的优点就是我们能够彼此独立解决问题——在同种情况下,无需写入和检索操作。这两种服务仍然利用全球语料库的图像,但是他们可以自由地优化性能和服务方法(例如排队请求或者缓存流行图片——下面会介绍更多)。从维护和成本角度来看,每一个服务都可以根据需要独立进行扩展,但如果把它们进行合并或交织在一起,那么有可能无意中就会对另一个性能产生影响,如上面讨论的情景。

发表我的评论
取消评论

表情

您的回复是我们的动力!

  • 昵称 (必填)
  • 验证码 点击我更换图片

网友最新评论