(转载)中大型网站架构演变之路

hz_pythoner hz_pythoner     2022-09-10     155

关键词:

 
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://lizhenliang.blog.51cto.com/7876557/1951651

前言

网上有很多文章类似于我今天要分享的课程,有架构师写的,有运维写的,还有开发些的,偏重点都不同,今天我以咱们运维角度全面讲解。

一个成熟的网站架构并不是一开始设计就具备高可用、高伸缩、高性能等特性的,它是随着用户量和业务线不断增加,基础架构才逐渐健壮的。在发展初期,一般都是从0到1,不会一上来就整一些大而全的架构,也很少人这么任性。

 

说明

适用业务:电商/门户/招聘网站

开发语言:PHP和JAVA

Web服务:Nginx/Tomcat8

数据库:MySQL

操作系统:CentOS

物理服务器:Dell R730/R430

 

录制视频地址:http://edu.51cto.com/course/10288.html

 

此文章为博主原创,转载请注明出处,抵制不道德行为!

 

技术分享

一、单台服务器部署

 

项目开发完成上线,用户访问量寥寥无几。

 

技术分享



二、WEB与数据库独立部署

 

 

有一定用户访问量,单台服务器性能有些吃力,想提高并发能力,增加一台服务器,将HTTP请求与SQL操作负载分散不同服务器。

技术分享

 

三、动静分离-初期

什么是动静分离?

静态页面与动态页面分离部署。

技术分享

四、数据库主从与查询缓存

 

uRedisCache

使用Redis缓存数据库查询结果,将热数据放到内存中,提高查询速度,减少数据库请求。

uMySQL主从

基于binlog异步复制。

uHA

MySQL:Keepalived

u怎么保证Redis缓存时效性?

a)增加中间件,在主从同步延迟时间内,中间件将SQL读操作还路由到主。

b)主从同步延迟时间后,再异步发起一次淘汰Cache。

c)增加消息队列和清理Cache程序,入库同时也写入消息队列,缓存清理程序订阅消息队列,一旦有数据更新,重新Cache。

d)Cache中的Item一定要设置过期时间。

技术分享

五、七层负载均衡、共享存储与Redis高可用

 

访问量越来越大,单台服务器性能已无法支撑,于是增加负载均衡,水平扩展WEB节点,同时调整动静分离。

 

u七层负载均衡

根据域名或者后缀转发不同的upstream。

uNFS网络文件系统

共享存储存放网站程序或者静态资源。

uRedis主从

u动静分离-中期

uHA

LB:Keepalived

NFS:DRBD+Heartbeat

Redis:Sentinel/Keepalived

uSession如何会话保持?

a)源IP Hash

b)Session共享

c)Session Sticky(粘滞会话)

d)Session复制

技术分享

六、数据库架构扩展

访问量上来了,SQL操作自然也就多了,单台数据库读性能到达瓶颈,响应很慢;业务读多写少,需要提升读性能,考虑扩展数据库架构。

u一主多从

基于binlog异步复制,多个从库同步主库。

u读写分离

a)代码逻辑层区分读写库。

b)使用中间件代理,对SQL解析区分处理;开源主流的有:Atlas、MyCat等。

u分库、分表、分区

分库:根据业务类型分离相关表到不同数据库;例如WEB、BBS、Blog等。

分表:单个表上千万条记录,操作耗时长,采用垂直拆分和水平拆分,将数据分散存储到不同小表上。

分区:根据表字段分成多个区块,这些区块可以分布在不同磁盘上。

以上主要是分散磁盘I/O压力,提高处理性能。

u从库四层负载均衡

当多个从库时,采用LVS实现负载均衡,对程序提供VIP,访问透明。

uHA

主库和从库LB:Keepalived

技术分享

七、SOA面向服务架构

uSOA

面向服务架构设计理念,拆分臃肿程序架构,以核心业务为单位分解,服务化、模块化,分布式部署。

u服务化治理

使用Dubbo分布式框架,治理SOA服务化,Dubbo提供高性能和透明化RPC远程调用方案 。

u配置中心

使用Zookeeper存储服务连接信息。

u消息队列

使用RabbitMQ解耦服务,保障服务直接通信。

技术分享

八、DNS轮训与数据库全文检索引擎

uDNS轮训

DNS负载均衡技术实现原理是在DNS服务器上一个主机名配置多个IP地址,用户访问时,轮训返回解析记录,从而达到负载均衡目的。

u全文检索引擎

像电商网站首页都会有查询表单,当商品多且品种多,关系型数据库庞大,想要快速从数据库中精确检索出用户想要的商品就显的力不从心了。

引入全文检索引擎,建立索引缓存,快速查询海量数据,缓解数据库压力;开源主流的有:ElasticSearch、Sphinx。

技术分享

 

九、静态缓存服务器

 

每次请求静态资源负载都会落在WEB节点和NFS存储上,而且这些资源都是很少变动的,我们把这些资源缓存到上层,请求到来时先判断本地是否有缓存,如果有就直接返回,从而减少后端HTTP请求,响应会快很多。

技术分享

十、分布式文件系统与CDN

u分布式文件系统

当图片、视频很多时,NFS在处理效率和存储容量上受局限,这时用分布式文件系统(DFS)就比较合适了,DFS是一种NAS存储架构,C/S模式,多台廉价服务器组成存储集群,提供高性能、高可用、高扩展等特性。客户端挂载到本地,就像访问本地文件系统一样访问远程服务器文件。

uCDN

每次请求静态资源都会落在WEB节点和存储上,而且这些资源都是很少变动的,如果把这些资源放到网站入口,岂不减少后端大量HTTP请求,有什么方法呢?

使用CDN技术,它通过一种缓存技术将频繁访问的资源(主要静态)分布到全国各地边缘服务器,用户先访问CDN服务器,CDN根据职能DNS返回客户端就近网络中的缓存服务器,如果这个缓存服务器有缓存请求的静态资源就直接返回,否则回源站获取返回,从而提高网站访问速度,减少后端服务器压力。

技术分享

技术分享

十一、四层负载均衡与NoSQL数据库

u四层负载均衡

七层负载均衡要分析应用层协议,效率没有四层高,有些应用场景并不需要分析应用层协议,只想实现转发负载,那么,四层负载均衡是首选。

当然,也可以四层代理七层负载均衡,方面扩展七层负载均衡。

uNoSQL数据库

由于个别SQL查询量大,已经无法在深度优化,可以考虑使用NoSQL非关系型数据库,它的产生就是解决大规模、高并发、大数据量等问题。但比较适合非结构化数据存储,比如详情页内容、原始数据等。

技术分享

十二、现在

u弹性伸缩

自动扩容,节点降级。

u微服务

更细粒度拆分应用,实现服务化、轻量级、自动化部署等。

u内存化

磁盘数据尽可能在内存中处理。

u异地容灾

如果不可容忍网站不可用,应考虑到异地备份或异地双活。

u应急预案

 

十三、谈古至今

尽量将请求拦截在前面,从而减少数据库和HTTP请求

数据库层是架构瓶颈,需要精心设计,比如架构扩展、SQL优化(压缩、索引等)

避免单点

分解压力

扩展性

找瓶颈出方案

 

十三、应急预案

 

SRE:网站可靠性工程师

保证网站不宕机是他们的使命!

 

制作应急预案大致以下几步:

1、系统分级

按照业务系统重要性划分,比如订单服务挂了,将影响用户无法下单,因此需要投入更多的资源保障;比如管理后台挂了,不会影响到用户;根据业务划分不同级别,实施不同的质量保障和成本投入。

2、全链路分析

梳理从网站入口到数据存储的各个环节,找出依赖服务,假设性去分析问题,如果某环节故障,影响范围怎样。

3、全方位监控

对相关链路实施全面监控,包括基础资源监控、服务状态监控、接口监控、日志监控等,确保出现问题有依据可追溯。

4、制定应急预案

多思考方案可行性,不定期进行预案演习,验证预案正确性和可控性及掌握恢复时间。

 

十四、应对策略

网络接入层:

a)机房故障:从DNS轮训摘除该机房或者切换到其他机房

b)VIP网络异常:切换备用VIP

代理层:

a)IP限流:某些IP访问太大导致后端负载压力过高;实施IP限流

b)后端应用异常:如软硬件故障,摘除异常节点;如果某机房问题切换到其他机房

应用层和服务层:

a)服务异常:某服务访问超时,响应慢;摘除服务或切换到正常服务

b)程序线程池不够用:线程池设置太小,导致请求堆积;提供参数开关,比如动态调整线程池大小

c)请求量太大:请求量太大,超过实际处理能力;请求限流或者设置请求阈值自动扩展节点

缓存层和数据层:

a)Redis挂掉:主从切换

b)MySQL挂掉:主从切换,切换后验证

c)机房故障:切换缓存库/数据库到其他机房

 



从运维角度看中大型网站架构的演变之路

...点都不同,今天我以咱们运维角度全面讲解。一个成熟的网站架构并不是一开始设计就具备高可用、高伸缩、高性能等特性的,它是随着用户量和业务线不断增加,基础架构才逐渐健壮的。在发展初期,一般都是从0到1,不会一... 查看详情

大型网站架构演变和知识体系

...些架构方向的文章。本篇文章也是看到后感觉很棒,由于转载的并不是真正的作者,所以也就无法贴出真正作者地址了。以下是该文讲述,个人感觉看后还是很有感触的:之前也有一些介绍大型网站架构演变的文章,例如LiveJourn... 查看详情

大型网站架构-1.架构的演变过程

...发之路。 2.第二阶段:应用服务和数据服务分离随着网站的第一次上线,我们的网站如果运营得不错的话,在这之后应该会逐渐积累人气,业务也会随 查看详情

技术干货阿里云构建千万级别架构演变之路

...就了一个成熟稳定的大型架构。如淘宝网、Facebook等大型网站的架构,无不从一个 查看详情

大型网站架构演变史(含技术栈与价值观)

这篇文章是参考李智慧的《大型网站技术架构:核心原理与案例分析》和现蘑菇街CTO曽宪杰的《大型网站系统与Java中间件实践》写的一篇读书笔记。前言何谓大型网站?大型网站的特点是什么?大型网站架构发生演变的源动力... 查看详情

大型网站架构的发展演变过程(代码片段)

大型网站架构的发展演变过程  原文地址什么是大型网站如何定义一个网站是不是大型网站,一般我们会从两个纬度去考衡,访问量以及数据量,二者缺一不可。我们以javaweb为例,来搭建一个简单的电商系统,从这个系... 查看详情

《大型网站技术架构》读书笔记——大型网站软件系统架构演变(代码片段)

大型网站软件系统特点大型网站架构演化发展进程大型网站的技术挑战主要来自于庞大的用户,高并发的访问和海量的数据。初始阶段的网站架构大型网站都是从小型网站发展而来,网站架构也是一样,是从小型网站... 查看详情

大型网站架构演变

1、简介大型网站架构的演进最开始都是由小及大慢慢演变过来的,任何一个好的架构都不是设计出来了,是经过业务发展迭代而来的,这个观点我是赞同的。对于网站架构技术非常有兴趣,一直持续关注学习架构技术,本次想... 查看详情

互联网技术架构演变过程-软件架构设计学习第四天(非原创)

文章大纲一、演变过程思路图二、何为大型网站三、架构体系演进四、架构总结五、参考文章一、演变过程思路图二、何为大型网站1.大型网站特性既然说的是大型网站架构,那么架构的背后自然是解决人因面对大型网站特性而... 查看详情

mysql在大型网站的应用架构演变

写在最前:本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变可扩展性架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍一下&... 查看详情

转载大型网站架构的演进

参考 http://www.cnblogs.com/leefreeman/p/3993449.html一个成熟的大型网站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性。成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就;不同... 查看详情

网站系统架构演变

...的感觉。二、背景说明?  我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美,也没有一开始就具备高性能、高并发、高可用、安全性等特性,而是随着用户量的增加、业务功能的扩展逐步演变过来的,... 查看详情

大型网站架构系列:电商网站架构案例

转自itfly8:大型网站架构系列:电商网站架构案例(1)大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。除具... 查看详情

说说大型高并发高负载网站的系统架构(转载)

一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性能的要求都很简单,随着互联网业务的不断丰富,网站相关... 查看详情

大型网站架构系列:电商网站架构案例

大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。除具备功能需求外,还具备一定的高性能,高可用,可伸... 查看详情

大型网站架构系列:电商网站架构案例

大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。除具备功能需求外,还具备一定的高性能,高可用,可伸... 查看详情

大型网站架构之架构模式

上节讲了《大型网站架构之架构演变》,今天讲下架构的模式,什么是模式呢?每一个模式描述了一个再我们周围不断重复发生的问题及问题解决方案的核心,这样你就能一次次重用该方案而不必去做重复的工作,可见模式的关... 查看详情

大型网站架构演化历程

大型网站架构演化历程点击上方“Hollis”关注我,精彩内容第一时间呈现。全文字数:2500阅读时间:5分钟大型网站的挑战主要来自庞大的用户,高并发的访问和海量数据,任何简单的业务一旦需要处理数以P计的数据和面对数以... 查看详情