大型网站架构的演化

简介:

一个成熟的大型网站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性,它总是随着用户量的增加,业务功能的扩展 逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。

(欢迎大家访问我的个人网站:工学1号馆

所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索、下 单、支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这 些不同的网站背景下,找出其中共用的技术,这些技术和手段可以广泛运行在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和 手段。

1、初始阶段的网站架构

应用程序、数据库、文件等都在一台服务器上,典型的LAMP结构

20160130191801

2、应用服务和数据服务分离

随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,这 3 台服务器对硬件资源的要求各不相同:应用服务器需要处理大量的业务逻辑,因此需要更快更强大的CPU;数据库服务器需要快速磁盘检索和数据缓存,因此需要 更快的磁盘和更大的内存;文件服务器需要存储大量用户上传的文件,因此需要更大的硬盘。

20160130192022

应用和数据分离后,不同特性的服务器承担不同的服务角色,网站的并发处理能力和数据存储空间得到了很大改善,支持网站业务进一步发展。但是随着用户 逐渐增多,网站又一次面临挑战:数据库压力太大导致访问延迟,进而影响整个网站的性能,用户体验受到影响。这时需要对网站架构进一步优化。

3、使用缓存改善网站性能

网站访问的特点和现实世界的财富分配一样遵循二八定律:80% 的业务访问集中在20% 的数据上。既然大部分业务访问集中在一小部分数据上,那么如果把这一小部分数据缓存在内存中,就可以减少数据库的访问压力,提高整个网站的数据访问速度, 改善数据库的写入性能了。 网站使用的缓存可以分为两种:缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。

本地缓存的访问速度更快一些,但是受应用服务器内存限制,其缓存数据量有限,而且会出现和应用程序争用内存的情况。远程分布式缓存可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,可以在理论上做到不受内存容量限制的缓存服务。

20160130195348

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

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

使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时,不要企图去更换更强大的服务器,对大型网站而言,不 管多么强大的服务器,都满足不了网站持续增长的业务需求。这种情况下,更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。 对网站架构而言,只要能通过增加一台服务器的方式改善负载压力,就可以以同样的方式持续增加服务器不断改善系统性能,从而实现系统的可伸缩性。应用服务器 实现集群是网站可伸缩架构设计中较为简单成熟的一种。

20160130195521

通过负载均衡调度服务器,可以将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上,如果有更多用户,就在集群中加入更多的应用服务器,使应用服务器的压力不再成为整个网站的瓶颈。

5、数据库读写分离

网站在使用缓存后,使对大部分数据读操作访问都可以不通过数据库就能完成,但是仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作都需要 访问数据库,在网站的用户达到一定规模后,数据库因为负载压力过高而成为网站的瓶颈。 目前大部分的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一 功能,实现数据库读写分离,从而改善数据库负载压力。

20160130195622

应用服务器在写数据的时候,访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库,这样当应用服务器读数据的时候,就可以通过从数据库 获得数据。为了便于应用程序访问读写分离后的数据库,通常在应用服务器端使用专门的数据访问模块,使数据库读写分离对应用透明。

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

随着网站业务不断发展,用户规模越来越大,由于中国复杂的网络环境,不同地区的用户访问网站时,速度差别也极大。有研究表明,网站访问延迟和用户流 失率正相关,网站访问越慢,用户越容易失去耐心而离开。为了提供更好的用户体验,留住用户,网站需要加速网站访问速度。主要手段有使用 CDN 和方向代理。

20160130195743

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

使用 CDN 和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速度,另一方面也减轻后端服务器的负载压力。

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

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后,从一台服务器拆分成两台服务器,但是随着网站业务的发展依然不能满足需求,这时需要使用分布式数据库。文件系统也一样,需要使用分布式文件系统。

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

20160130200132

8、使用 NoSQL 和搜索引擎

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

NoSQL 和搜索引擎都是源自互联网的技术手段,对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

20160130200351

9、业务拆分

大型网站为了应对日益复杂的业务场景,通过使用分而治之的手段将整个网站业务分成不同的产品线。如大型购物交易网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线,分归不同的业务团队负责。

具体到技术上,也会根据产品线划分,将一个网站拆分成许多不同的应用,每个应用独立部署。应用之间可以通过一个超链接建立关系(在首页上的导航链接 每个都指向不同的应用地址),也可以通过消息队列进行数据分发,当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

20160130200449

10、分布式服务

随着业务拆分越来越小,存储系统越来越庞大,应用系统的整体复杂度呈指数级增加,部署维护越来越困难。由于所有应用要和所有数据库系统连接,在数万台服务器规模的网站中,这些连接的数目是服务器规模的平方,导致数据库连接资源不足,拒绝服务。

既然每一个应用系统都需要执行许多相同的业务操作,比如用户管理、商品管理等,那么可以将这些共用的业务提取出来,独立部署。由这些可复用的业务连接数据库,提供共用业务服务,而应用系统只需要管理用户界面,通过分布式服务调用共用业务服务完成具体业务操作。

20160130200656

大型网站的架构演化到这里,基本上大多数的技术问题都得以解决,诸如跨数据中心的实时数据同步和具体网站业务相关的问题也都可以通过组合改进现有技术架构解决。

相关实践学习
Serverless极速搭建Hexo博客
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
7月前
|
缓存 NoSQL 应用服务中间件
性能基础之大型网站架构演化(整理篇)
【2月更文挑战第14天】性能基础之大型网站架构演化(整理篇)
100 1
性能基础之大型网站架构演化(整理篇)
|
2月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
4月前
|
运维 Cloud Native 开发者
云原生时代下的微服务架构演化之路
【8月更文挑战第20天】在数字化转型的浪潮下,企业级应用纷纷拥抱云原生架构。本文将深入探讨微服务架构在适应云原生环境的过程中所面临的挑战与机遇,并分析如何通过优化设计、容器化技术及自动化运维,实现高效、灵活且可靠的系统构建。
182 65
|
4月前
|
消息中间件 存储 Java
图解Kafka:Kafka架构演化与升级!
图解Kafka:Kafka架构演化与升级!
98 0
图解Kafka:Kafka架构演化与升级!
|
4月前
|
Cloud Native 持续交付 开发者
云原生之旅:从传统到现代的架构演化
本文将通过一次虚拟的旅行,带领读者穿越回过去,探索软件架构的发展脉络。我们将从单体应用开始,一路经过服务化拆分,最终抵达云原生的乐土。这不仅是一段技术演进的历史,也是对如何在不断变化的技术浪潮中保持初心与创新的启示录。
48 2
|
6月前
|
运维 监控 Cloud Native
云原生架构的演化与实践
【6月更文挑战第29天】云原生技术,作为现代软件开发和运维的前沿阵地,其核心理念在于构建可弹性扩展、高度可靠且易于管理的系统。本文将深入探讨云原生架构的发展脉络,解析其关键技术组件,并通过实际案例展示如何将这些原则应用于日常开发和运维中。我们还将讨论在采纳云原生技术时所面临的挑战及应对策略,以期为读者提供一套全面而实用的云原生解决方案。
161 1
|
7月前
|
敏捷开发 监控 测试技术
软件架构的艺术:探索演化之路上的18大黄金原则
实际工作表明,一步到位的设计往往不切实际,而演化原则指导我们逐步优化架构,以灵活响应业务和技术的变化。这不仅降低了技术债务和重构风险,还确保了软件的稳定性和可扩展性。同时,架构的持续演进促进了团队协作,激发了成员间的知识共享与技能提升。
143 0
软件架构的艺术:探索演化之路上的18大黄金原则
|
消息中间件 监控 数据处理
消息队列和应用工具产品体系-APM 系统简述和架构演化
消息队列和应用工具产品体系-APM 系统简述和架构演化
|
7月前
|
开发框架 供应链 监控
【从零开始学微服务】03.软件架构的演化过程
大家好,欢迎来到万猫学社,跟我一起学,你也能成为微服务专家。
83 0
【从零开始学微服务】03.软件架构的演化过程
|
缓存 负载均衡 应用服务中间件
大型网站技术架构(一)——大型网站架构演化
大型网站技术架构(一)——大型网站架构演化