重型网址架构演变,说说大型网址架构的演变进

现今,全球有近一半的人口在使用互联网,人们的生活因互联网而发生了巨大的改变。

大型网站技术架构核心原理与案例分析(一)大型网站演化

  • 特点
  • 历程
  • 价值观
  • 误区

有幸在图书馆借了本《大型网站技术架构:核心原理与案例分析》,拜读后获益匪浅,在此分享一下第一章 大型网站架构演化。

在互联网跨越式的发展历程的背后是不堪重负的网站架构,某些 B2C 网站逢促销必宕机似乎成为一种必然的规律,最著名的例子就是早期的铁道部的电子客票售卖平台O(∩_∩)O~

一、大型网站架构

好的互联网产品都是慢慢运营出来的,不是一开始就开发好的。这跟传统软件产品或企业应用系统不同。

大型网站架构解决的主要问题是高并发访问和海量数据

前言

传统的企业应用系统主要面对的技术挑战是复杂凌乱、千变万化的所谓业务逻辑,而大型网站主要面对的技术挑战是庞大的用户,高并发的访问和海量的数据处理;前者的挑战来自功能性需求,后者的挑战来自非功能性需求。与传统软件产品或企业应用系统一开始就规划好全部的功能和非功能需求不同,几乎所有的大型互联网网站都是从一个小网站开始,渐进地发展起来的。好的互联网产品都是慢慢运营出来的,不是一开始就开发好的,这也正好与网站架构的发展演化过程对应。

1 大型互联网应用的特点

  • 高并发,大流量:面对的是高并发的用户以及大流量的访问。
  • 高可用:系统 7 * 24 小时不间断服务。
  • 海量数据:需要存储并管理海量的数据,这会用到大量的服务器。
  • 用户分布广泛,网络情况复杂:许多的大型互联网应用都是为全球用户服务的,但用户分布范围广,而且各地的网络情况千差万别。
  • 安全环境恶劣:由于互联网的开放性,会使得网站很容易收到黑客的攻击。
  • 需求快速变更,发布频繁:大型网站每周都会有新版本发布,而中小型网站可能一天会发布几十次。
  • 渐进式发展:几乎所有的大型互联网网站都是从小网站起步,然后渐进发展的。

二、网站架构的演化

  • 数据库分离部署;文件服务器分离部署
  • 使用缓存减轻数据库压力
  • 应用服务器集群(负载均衡)
  • 数据库读写分离
  • CDN和反向代理服务器(缓存,使数据更早返回)
  • 分布式文件系统和分布式数据库(分布式数据库是最后手段,不到万不得已不会用,一般使用业务分库)
  • NoSQL和搜索引擎
  • 业务拆分
  • 分布式服务

初始阶段的网站架构

小型网站访问人数少,因此只需要一台服务器绰绰有余,应用程序、文件、数据库等所有的资源文件都在一台服务器上。通常服务器操作系统使用Linux,应用程序使用PHP开发,然后部署在Apache上,数据库使用MySQL,汇集各种开源软件及一台廉价服务器就可以开始网站的发展之路。

图片 1

初始阶段的网站架构

2 架构演化发展历程

因为庞大的用户,高并发的访问量以及海量的数据,所以任何简单的业务都要处理以 P(10 的 15 次方,1000 T = 1 P)级的数据,以及面对数以亿计的用户。我们的架构就是为了解决这些问题。

初始阶段

应用程序、数据库和文件部署在同一台服务器上。
操作系统使用Linux,应用程序使用PHP开发,部署在Apache上,数据库使用MySQL.

应用服务和数据服务分离

随着网站业务的发展,一台服务器逐渐无法满足需求:越来越多的用户访问导致性能变差,越来越多的数据导致存储空间不足。这时就需要把应用与数据库分离,分离后整个网站有三台服务器:应用服务器、文件服务器、数据库服务器。它们对硬件资源的要求各不相同:

  • 应用服务器需要处理大量业务逻辑,因此需要更快更大的CPU
  • 文件服务器需要存储大量用户上传的文件,因此需要更大的硬盘
  • 数据库服务器需要快速磁盘检索和数据缓存。

    图片 2

    应用服务和数据服务分离

2.1 初始阶段

小型网站没有太多人访问,所以只需要一台服务器就够咯:

应用程序、文件、数据库都部署在一台服务器上,通常是使用 LAMP(Linux/Apache/MySQL/PHP)。

应用和数据分离

数据量过多导致存储空间不足。
整个网站使用三台服务器,对硬件要求各不相同:

  • 应用服务器,处理大量业务逻辑,需要有强大的CPU
  • 文件服务器,存储大量用户上传的文件,需要更大的硬盘
  • 数据库服务器,需要快速磁盘检索和数据缓存

这个阶段,网站并发能力和数据存储空间有很大改善,但是,随着用户持续增多,网站仍然面临挑战:数据库压力大导致访问延迟,影响网站性能。

使用缓存改善网站性能

随着用户逐渐增多,网站又一次面临挑战:数据库压力太大导致访问延迟,进而影响网站性能和用户体验,这时需要对网站进一步优化。首先网站的访问特点和世界财富的分配一样遵循二八定律:80%的业务访问集中在20%的数据上。既然大部分业务访问集中在一小部分数据上,那么把这部分数据缓存在内存中,就可以减少数据的压力。网站使用的缓存可以分为两种:

  • 本地缓存:缓存在应用服务器上,访问速度更快,但受应用服务器内存限制。
  • 远程服务器缓存:缓存在专门的分布式缓存服务器上,可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,理论上可以不受内存容量限制。

    图片 3

    使用缓存改善网站性能

2.2 应用服务和数据服务分离

随着业务的发展,越来越多用户的访问导致性能越来越差,而越来越多的数据也会耗尽存储空间。这时,我们就需要将应用与数据分离:

这里使用三台服务器:应用服务器、文件服务器和数据库服务器。它们对硬件资源的要求不同。

服务器 对硬件资源的要求 说明
应用服务器 更快的 CPU 要处理大量的业务逻辑
文件服务器 更大的硬盘 要存储大量用户上传的文件
数据库服务器 更快的硬盘和更大的内存 需要快速的磁盘检索和数据缓存

不同特性的服务器可以承担不同的服务角色,使得网站的并发处理能力和数据存储空间都有了很大的改善。
但随着用户数量的再次增长,发现数据库的压力太大而导致的网站访问延迟问题,所以需要再次优化。

使用缓存

网站访问的二八定律:80%的业务访问集中在20%的数据上。

网站使用的缓存可以分为两种:

  • 应用服务器上的本地缓存,速度更快,但受服务器内存限制,且与应用程序争用内存
  • 专门的分布式缓存服务器上的远程缓存,使用大内存服务器做集群部署

这个阶段,数据访问压力得到缓解,但是,单一应用服务器能处理的请求连接数是有限的。在网络访问的高峰期,应用服务器成为性能瓶颈。

使用应用服务器集群改善网站的并发处理能力

使用缓存后数据访问压力得到缓解,但是单一的应用服务器能够处理的请求数有限,在访问高峰期,应用服务器将成为整个网站的瓶颈。这时可以使用集群。
  集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力不足时,与其换一台更强大的服务器,不如增加一台服务器去分担原有的服务器压力。对于大型网站而言,无论多么强大的服务器,都满足不了持续增长的业务需求,更高效的方式就是增加服务器来分担压力。对于网站架构而言,如果增添一台新的服务器可以改善负载压力,那么就可以使用同样的方式来应对源源不断的业务需求,从而实现系统的可伸缩性。
  通过负载均衡调度服务器,可将来自用户访问浏览器的请求分发到应用服务器集群中的任何一台服务器上。

图片 4

应用服务器集群

2.3 使用缓存改善性能

网站访问的特点遵循经典的二八定律:80% 的业务访问集中在 20% 的数据上。所有我们把这一小部分数据缓存在内存中,就能减少数据库的访问压力。

缓存可分为两种。在应用服务器上的本地缓存和在分布式缓存服务器上的远程缓存。

缓存类型 优点 不足
本地缓存 访问数据相对快 受应用服务器内存限制,可缓存的数据量有限
远程缓存 理论上可不受内存容量的限制 访问数据相对慢

远程分布式缓存使用集群,而且可以使用安装了大内存的服务器作为专门的缓存服务器。

使用缓存后,数据库的访问压力得到缓解,但单一的应用服务器能够处理的请求连接有限,所以在网站访问的高峰期,有可能成为整个网站的瓶颈。

使用应用服务器集群

一台服务器处理能力、存储空间不足时,不要企图更换更强大的服务器。恰当的做法是增加一台服务器。这就是所谓的垂直扩展和水平扩展。

应用服务器实现集群时可伸缩集群架构设计中较为简单成熟的一种。通过负载均衡来调度服务器,将浏览器的访问请求分发到应用服务器集群的任何一台服务器上。

数据库读写分离

使用缓存后,大部分数据读操作不需要通过数据库就能完成,但仍有小部分读操作(缓存不命中、过期)和全部写操作仍需要数据库来处理,当用户达到一定规模后就会出现数据库负载压力过高的问题。
  目前大多数的数据库都支持主从热备份,通过配置两台服务器的主从关系,可以将一台数据库服务器的数据更新同步到另一台,实现数据库读写分离,从而进一步改善数据库负载压力。为了便于应用程序访问分离后的数据库,通常在应用服务器使用专门的数据访问模块,是数据库读写分离对应用透明。

图片 5

数据库读写分离

2.4 应用服务器集群

使用集群是解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时,最恰当的做法是增加新的服务器,让它来分担原有服务器的访问和存储压力。

我们可以通过持续地增加服务器,来不断改善系统的性能,从而实现系统的可伸缩性:

通过负载均衡调度服务器,我们可以将用户的访问请求分发到应用服务器集群中的任何一台服务器上。如果有更多的用户,我们就可以在集群中加入更多的应用服务器咯O(∩_∩)O~

数据库读写分离

网站使用缓存后,仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作需要访问数据库。网站用户达到一定规模后,数据库因为负载压力过高而成为性能瓶颈。

目前主流的数据库都提供主从热备功能,配置主从关系可以将一台数据库服务器的数据更新同步到另一台服务器上。

  • 写数据时,访问主数据库
  • 读数据时,访问从数据库

通常,在应用服务器端使用专门的数据访问模块,使数据库读写分离对应用透明。

使用反向代理和CDN加速网站响应

由于中国复杂的网络环境,不同地区的用户访问网站时,速度差别也极大。为了提供更好的用户体验,加快网站访问速度,使用CDN和反向代理。一方面加快用户访问速度,另一方面也减轻后端服务器的负载压力。

  • CDN部署在网络提供商的机房,使用户在请求网站服务是,可以从距离最近最近的网络提供商机房获取数据。
  • 反向代理部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果有资源则直接返回给用户。

    图片 6

    使用反向代理和CDN加速网站响应

2.5 数据库读写分离

使用了缓存后,使得绝大多数数据的读操作可以不通过数据库就能完成。但仍然有部分的读操作(因为缓存访问没有命中或者缓存过期)和全部的写操作需要访问数据库,所以在用户量达到一定规模时,数据库还是会因为负载过高而成为瓶颈。

目前的主流数据库都提供了主从热备功能,可以通过配置两台数据库的主从关系,把一台数据库服务器的数据同步到另一台服务器上。我们可以利用这个功能,实现数据库的读写分离,进一步提高数据库的负载能力:

为了便于应用程序访问读写分离的数据库,一般会在服务器端使用专门的数据访问模块,让数据库的读写分离机制对应用程序透明,这样做不仅降低了代码编写的复杂度,还提高了可维护性,可谓两全其美O(∩_∩)O~

使用反向代理和CDN加速响应

加速网站访问速度的主要手段:

  • CDN
  • 反向代理

CDN和反向代理的原理都是缓存。

  • CDN部署在网络提供商的机房里。用户访问时,可以从最近的网络提供商机房获取数据。
  • 反向代理则部署在网站的中心机房。用户请求到达中心机房时,首先访问的俄是反向代理服务器,如果反向代理服务器中存在着用户请求的资源,就直接返回给用户。

使用CDN和反向代理服务器的目的都是尽早返回数据给用户:

  • 一方面加快用户访问速度
  • -另一方面减轻后端服务器的负载压力

使用分布式文件系统和分布式数据库系统

随着网站业务的发展,数据库、文件服务器就可以向应用服务器一样使用集群来提高性能,分别使用分布式数据库和分布式文件系统。
  分布式数据库是数据库拆分的最后手段,只有在单表数据规模非常庞大的时候才使用。不到万不得已,网站更常用的手段是业务分库,将不同业务的数据库部署在不同的物理服务器上。

图片 7

使用分布式文件系统和分布式数据库系统

2.6 使用反向代理和 CDN 加速响应

网站的访问延迟与用户的流失率正相关!因为网站访问的越慢,用户就越容易失去耐心而离去哦。

反向代理和 CDN 都是依赖缓存。区别是,CDN 是部署在网络供应商的机房,用户请求服务时,会从距离他最近的网络供应商机房获取数据;而反向代理是部署在网站的中心机房,所以用户请求服务式,会先访问反向代理服务器,如果它缓存着用户所请求的资源,就会直接把资源返回给用户!

使用反向代理和 CDN 的目的都是为了尽早地把数据返回给用户,这样不仅加快了用户的访问数据,而且也减轻了后端服务器的负载压力。

分布式文件系统和分布式数据库系统

数据库经过读写分离后,从一台服务器拆分为两台,但随着网站业务的发展仍然不能满足需求,这时候需要使用分布式数据库。文件系统也需要使用分布式文件系统。

分布式数据库是网站数据拆分的最后手段。只有在单表数据规模非常庞大的时候才使用。不到不得已时,更常用的手段是业务分库:将不同业务的数据库部署在不同的物理服务器上。

使用NoSQL和搜索引擎

随着网站业务越来越复杂,对数据存储和检索的需求越来越复杂,网站需要采用一些非关系型数据库(NoSQL)和非数据库查询技术如搜索引擎。应用服务器通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

图片 8

使用NoSQL和搜索引擎

2.7 使用分布式文件系统和分布式数据库系统

如果之前的架构仍然不能满足需求,那么就要使用分布式的文件系统和数据库系统啦O(∩_∩)O~

注意:一般情况下是对业务数据进行分库,即将不同业务的数据库部署到不同的物理服务器上。只有在单表的数据规模非常庞大时,才使用分布式数据库!

使用NoSQL和搜索引擎

随着网站业务越来越复杂,对数据存储和检索的需求也越来越复杂。网站需要使用一些非关系型数据库(如NoSQL)和非数据库查询技术(如搜索引擎)。

NoSQL和搜索引擎都源自互联网,对可伸缩的分布式特性有更好的支持。

应用服务器通过一个统一的数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

业务拆分

对于大型网站,我们可以分而治之,把整个网站的业务分为不同的模块,比如大型的交易购物完整可以分为首页、店铺、订单、买家等,分别交给不同的业务团队来负责。具体到技术上,也会拆分成许多不同的应用,每个应用独立部署维护。应用之间通过超链接建立关系(例如在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发,最后通过相同的数据存储系统来构成一个互相关联的完整系统。

图片 9

业务拆分

消息队列服务器:http://blog.csdn.net/reggergdsg/article/details/51711804

2.8 使用 NoSQL 和搜索引擎

随着业务变得越来越复杂,对数据存储和检索的需求也会变得复杂起来,这时候就会用到 NoSQL 和搜索引擎啦:

应用程序通过数据访问模块来访问搜索引擎与 NoSQL 服务器,这样就可以减轻应用程序管理多数据源的麻烦啦O(∩_∩)O~

业务拆分

大型网站一般将网站业务分成不同的产品线。
具体技术上,也会将一个网站拆分成多个不同应用,每个应用独立部署维护。应用之间通过首页的超链接建立关系,也可以通过消息队列进行数据分发。最多的还是访问同一个数据存储系统来构成完成系统。

分布式服务

随着业务拆分,整个系统越来越大,应用的整体复杂度呈指数级增加,部署维护越来越困难,并且所有的应用服务器都要与数据库服务连接, 在数万台服务器规模的情况下,这些连接的数目是服务器规模的平方,导致资源不足。这时候就要对相同的业务进行提取,独立部署,把这些可重用的业务和连接数据库等,提取出来作为公共业务服务,而应用系统只需要通过分布式服务访问公共业务服务完成业务操作。

图片 10

分布式服务

2.9 业务拆分

为了应对日益复杂的业务场景,通常使用分而治之的手段,把业务划分为不同的产品线。

每个应用独立部署维护,应用之间通过超链接建立关系,也可以通过消息队列进行数据分发,更通常的做法是通过访问同一个数据存储系统来构建一个完整的关联关系。

分布式服务

抽取可复用的业务,独立部署,连接数据库。应用系统只需要管理用户界面,通过分布式服务调用共用业务服务完成业务操作。

后记

大型网站的架构演化到这里,基本上大多数的技术问题都得以解决。既然大型网站架构解决了海量数据的管理和高并发事务的处理,那么就可以把这些解决方案应用到网站自身以外的业务上去。例如建设云计算平台,并将计算作为一种基础资源出售给中小网站付费使用。

2.10 分布式服务

随着业务被拆分的越来越小,存储系统变得越来越大,应用系统的整体复杂度呈指数级增长,部署和维护变得越来越困难。

这时候,我们可以把某些共用的服务提取出来,独立部署。而应用系统只需要管理用户界面,然后通过分布式服务调用共用的服务,来完成业务操作啦:

架构演化到了这里,大多数的技术问题都可以解决啦O(∩_∩)O~

这些解决方案甚至可以应用到网站自身业务之外,目前有许多大型网站都建设了云计算平台,将计算作为一种基础资源出售出去,这样中小网站就可以不必在关心架构问题,只要按需付费,就可以享受更大的存储空间和更多的计算资源啦。

三、价值观

网站的价值在于能够为用户提供什么价值,而不是它本身是怎么做的。网站很小的时候追求架构是舍本逐末。很多小网站十几年如一日使用LAMP(Linux Apache MySQL PHP)。

3 架构演化的价值观

大型网站都是从小型网站发展而来的。关键是这个网站能够为用户提供什么价值。如果在网站还很小的情况下,就去追求架构是舍本取末的表现,得不偿失。小型网站需要为用户提供好的服务来创造价值,获得用户的认可,这才是正途。

所以中小网站大多使用 LAMP 技术(Linux Apache MySQL PHP),因为它们即便宜又简单,而且对于中小网站来说,已经是绰绰有余得啦O(∩_∩)O~

核心价值观

大型网站架构技术的核心价值不是从无到有搭建大型网站,而是伴随业务发展,慢慢演化成一个大型网站。我们今天看到的大型网站,都是遵循着这种演化路线。

3.1 架构技术的核心价值

架构技术的核心价值是应需而变,灵活应对。通过业务的逐步发展,慢慢演化成为一个大型网站。

主要驱动力

主要驱动力是业务发展。业务成就技术,事业成就人,而不是相反。

有些传统企业投身互联网,自己业务没有理清楚就从外面挖来高手,仿照互联网公司打造技术平台,无疑是缘木求鱼。而高手离开了熟悉的工作环境和工作模式,也无法发挥应有的能力。

总之,有了业务和问题,才会出现解决问题的方法和技术。

3.2 驱动技术发展的力量

驱动技术发展的力量是业务的发展。
记住:是业务成就了技术,事业成就了人。

四、设计误区

4 设计的误区

一味追求大公司解决方案

淘宝就是这么搞的
Facebook就是这么搞的

4.1 一味追求大公司的解决方案

大公司的经验与成功模式值的学习借鉴,但如果因此变得盲从,迟早会迷失方向。

为了技术而技术

技术是为业务而存在的。

4.2 为了技术而技术

技术是为了业务而存在的。如果一味追求时髦的技术,很有可能会把网站的技术发展引入歧途。

企图用技术解决所有问题

2012年年初12306技术故障事件后,各路专业人士和非专业人士纷纷发声,甚至有人提议写个开源网站。但其实鲜有人认识到12306的问题其实不在技术架构,而是业务架构:不应该在几亿中国人一票难求的情况下以窗口售票的模式在网上卖票(零点之后出售若干天之后的车票)。应该调整业务需求,换一种方式卖票,引入排队机制,分时段售票。

技术只是解决业务问题的手段之一,不要忘了业务问题本身还是可以用业务手段解决。

4.3 企图用技术解决所有问题

技术不是银弹,它不是万能的!比如之前的 12306 的售票网站,之所以出现故障,真正的问题其实不是它的技术架构,而是出在业务架构上!它根本不该像淘宝那样,搞促销秒杀的手段(让几亿人在零点买十几天后的车票),买车票是刚需,所以搞促销干嘛呀O(∩_∩)O~

后来的 12306 换了一种卖票方式,它引入了排队机制、整点售票改为分时段售票。所以如果能够控制并发访问的量,很多棘手的技术问题自然迎刃而解啦。

技术可以解决业务问题,而业务问题也可以通过业务的手段来解决哦O(∩_∩)O~

五、总结

能够经历网站从小到大演化过程的架构师越来越少。小网站发展成大网站的机会本来就少,将来很可能就没有了。

正因为如此,架构师更应该对这个过程的来龙去脉做深入了解,在技术选型和架构决策时有的放矢。

本文由亚洲必赢娱乐游戏发布于必赢娱乐网址,转载请注明出处:重型网址架构演变,说说大型网址架构的演变进

TAG标签: 必赢娱乐网址
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。