大型网站架构首页投稿(暂停使用,暂停投稿)Java技术升华

【笔记】大型网站技术架构(一)-大型网站架构演化

2018-03-11  本文已影响95人  程序员Anthony

大型网站软件系统特点

大型网站架构演化发展历程

1 初始阶段

所有的业务集中在一起,网站,数据库和文件都放在一个服务器中,典型的LAMP架构
2 应用服务和数据服务分离
随着业务的发展,网站用户越来越多,一台服务器逐渐不能应对需求(存储空间越来越少,性能越来越差);此时需要将应用和数据分离分别放在3台服务器上:

三者分工不同,对相应的数据库性能要求也不一样:应用程序服务器处理大量业务逻辑,它对CPU的性能要求较高;数据库服务器要快速检索数据和数据缓存,因而对内存和硬盘要求较高;文件服务器要存储大量文件(用户上传的图片等),要求更大的硬盘容量。

三个服务器各司其职,暂时解决了第一阶段的存储容量问题,也提高了并发处理能力。
3 缓存
随着用户的增加,数据库的压力越来越大,用户的每一次登录都要访问数据库,导致响应缓慢,影响用户体验,我们分析发现:

网站访问特点和现实世界的财富分配一样遵循二八定律:80%的业务访问集中在20%的业务上

我们只需将这20%的业务做一下缓存就可以缓解数据库压力大的问题。
网站使用的缓存有两种:1.放在应用服务器上的本地缓存(速度快但是会占用应用程序的内存);2.放在专门的分布式缓存服务器上的远程缓存(可以用多台服务器做集群,实现大内存容量的缓存服务)。

4 应用服务器集群
此时的应用程序服务器只有一个,它能处理的请求连接有限,在网站访问高峰期应用程序服务器的压力会很大,导致访问排队,响应等待时间长。于是我们要对应用服务器做集群,通过负载均衡调度服务器分发请求给应用程序服务器,多个服务器来处理请求,每一个应用程序服务器的压力都不会太大。

5 数据库读写分离
现状是加完缓存,大部分数据访问可以不通过数据库,但还有少量的数据读取(未作缓存的数据,缓存过期和缓存未命中的数据)以及全部的数据写入都要访问数据库。随着用户量的增长,数据库的压力越来越明显,逐渐成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能,实现数据库读写分离,从而改善数据库负载压力。

应用程序的写操作访问主数据库服务器,将数据写入;为保证数据一致性,主数据库通过主从复制机制将数据更新同步到从数据库服务器;应用程序的读取数据访问从数据库服务器就可以获取。

为了便于应用程序访问读写分离后的数据库,通常在应用服务器端使用专门的数据访问模块,是数据库读写分离对应用透明。

6 反向代理和CDN
为了让网络环境不是很好的区域的用户也能很好的访问我们的网站,网站需要加速网站的访问速度,此时就会用到反向代理和CDN。

CDN和反向代理的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,使用户在请求网站服务是,可以从距离自己最近的网络提供商机房获取数据;而反向代理则部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存这用户请求的资源,就将其直接返回给用户。

这一阶段的目的就是尽快将数据返回给用户,此时的架构一方面加快了用户的访问速度,另一方面也缓解了后端服务器的负载压力。
7 分布式文件系统和分布式数据库
当业务发展到一定程度,数据量十分庞大的时候,两台数据库服务器已经无法满足需求,此时要做分布式数据库和分布式文件系统。
将数据库按照业务进行拆分,将不同业务的数据库部署在不同的物理服务器上。

8 NoSql和搜索引擎
随着业务越来越复杂,对数据的存储和检索的需求也变得复杂起来,此时需要使用非关系数据技术(如NoSql)和非数据库查询技术(如搜索引擎)来帮忙。

NoSql和搜索引擎都是源自互联网的 技术手段,对可伸缩的分布式特性具有更好的支持。

9 业务拆分
为应对日益复杂的业务场景,将网站以业务为模块进行拆分然后交给不同的业务团队负责管理,达到分治的目的。
具体来说就是将应用服务依业务拆分成一个个小系统(包括商品管理系统,支付系统,订单系统等),然后每个系统独立部署维护。各系统之间通过超链接建立联系,也可以通过消息队列进行数据分发。但都会访问同一个数据存储系统来构成一个完整的网站系统。

10 分布式服务
上一阶段每个业务系统都访问数据库资源,随着业务发展必然会导致数据库资源不足,系统的维护也更加困难。分析发现有很多公共业务(如 用户管理,商品管理等),将其提取出来做成公共服务,可以有效缓解上一阶段造成的问题。

此时的网站总体架构:

网站架构演化的价值观

网站架构设计误区

参考书籍

更多细节请阅读原书籍:
大型网站技术架构

上一篇下一篇

猜你喜欢

热点阅读