分布式可扩展web体系结构设计实例分析

Web分布式系统设计准则

下面以一个上传和查询图片的例子来说明分布式web结构的设计考虑和常用的提高性能的方法。该例子提供上传图片和下载图片两个简单功能，并且有一下假设条件？：

- 可以存储无上限数量的图片，即存储需要scalability

- 下载图片提供低带宽延时，即速度要快

- 如果客户上传了一张图片，图片将永久保存在数据库，除非客户删除。即可靠性

- 系统容易维护

- 整个系统不能花费太高。

首先，这个例子系统提到了如下web系统设计的基本要求，其最简单的设计逻辑结构如下图。

- Availability 可用性， 即每时每刻保证网站可用。

-  Performance 性能， 即用户的响应要迅速。

- Reliability 可靠性， 即可靠的结果，两次相同的请求得到相同的结果，以及数据的一致性。

- Scalability 可扩展性， 即系统在负载加大时容易扩展。

- Manageability 易管理性，即系统是可以并且容易管理的。

- Cost 花费。即系统的花费靠谱。

Services

- 将不同模块的功能分块，每块提供不同的service（SOA， service oriented architecture）,这样有利于管理和切分问题

- 另外考虑读写的性能时间消耗，一般读的速度要大于写的速度。因为读操作可以从cache读，且一般IP网络设置上传和下载速度比为1:3，写操作最后都要写到磁盘。即使全部对磁盘数据库操作，读数据库的性能也要好于写数据库，参见：(Pole Position, an open source tool for DB benchmarking, http://polepos.org/ and results http://polepos.sourceforge.net/results/PolePositionClientServer.pdf.).

- 对系统性能和并发连接数有提升（比如，apache默认连接数是500，若上传和下载在一台服务器上，读操作很快，写则需要占用大量时间，从能导致端口被消耗，并发数减少）

分块后结构图：

冗余设计

为保证系统稳定，并且关键模块在出现错误时迅速恢复，必须采用冗余技术，采用冗余后的基本结构如下图：

分块存储

如果数据过大，将导致单一服务器无法存储所有数据，而且所有数据都保存在一台服务器中使数据检索的性能下降。扩展可以分为竖直单机扩展和水平增加服务器扩展。目前业界倾向于后者。数据分块后的书评扩展基本结构为：

在web系统体系机构中，最challenge的问题是数据读取和存储部分，应用程序请求处理部分可通过负载均衡和水平扩展解决，下面将上述系统简化，重点讨论数据获取的相关技术,简化后的系统结构可简单理解为：

一般而言读数据要比写数据频繁，但写数据要写到磁盘，比读数据耗时，接下来从读写两方面来看数据获取方面在体系结构上的设计技巧，想象如下的场景：

如果这种设计，找到想要的数据无疑大海捞针，为了提高查找和读数据性能，我们一般采用如下技术：

Cache（Memcached， ）

上面设计的缺点是单个node的cache容量有限，解决见下图：

上图同样有缺点，当利用load balance时，若相同的request被分配到不同的node，很容易导致不同node的cache不命中，同样低效。

上图增加一个中间的统一大cache解决问题，若未命中，由global cache所在机器负责读硬盘，这可能导致cache频繁的换入换出是命中更低效。

上述结构为global的另外一种结构，即未命中有node自己去远程数据库查询。是gloabl的cache不会被换出，更适合于在global cache中存放频繁经常使用的全局数据。

代理（Squid and Varnish）

索引

Load Balance

写操作提高性能的技术可采用异步队列机制（RabbitMQ, ActiveMQ, BeanstalkD,  Zookeeper, Redis.）