中大型网站架构演变之路

2019年4月19日 0 条评论 61 次阅读 0 人点赞

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

image.png

一、单台服务器部署

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

image.png

二、WEB 与数据库独立部署

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

三、动静分离-初期

什么是动静分离?静态页面与动态页面分离部署。

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

  • Redis Cache

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

 

  • MySQL 主从


基于 Binlog 异步复制。

  • HA


MySQL:Keepalived

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


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

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

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

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

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

image.png

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

  • 七层负载均衡

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

  • NFS 网络文件系统

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

  • Redis 主从

  • 动静分离-中期

  • HA

LB:Keepalived

NFS:DRBD + Heartbeat

Redis:Sentinel / Keepalived

  • Session 如何会话保持?

a)源 IP Hash

b)Session 共享

c)Session Sticky(粘滞会话)

d)Session 复制

六、数据库架构扩展

image.png

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

  • 一主多从

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

  • 读写分离

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

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

  • 分库、分表、分区

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

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


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


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

  • 从库四层负载均衡

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

  • HA

主库和从库 LB:Keepalived

七、SOA 面向服务架构

image.png

  • SOA

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

  • 服务化治理

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

  • 配置中心

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

  • 消息队列

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

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

image.png

  • DNS 轮询

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

  • 全文检索引擎

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

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

九、静态缓存服务器

image.png

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

十、分布式文件系统与 CDN

  • 分布式文件系统

image.png

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

  • CDN

image.png

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

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

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

image.png

  • 四层负载均衡

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

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

  • NoSQL 数据库

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

十二、现在

  • 弹性伸缩

自动扩容,节点降级。

  • 微服务

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

  • 内存化

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

  • 异地容灾

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

  • 应急预案

十三、谈古至今

  • 尽量将请求拦截在前面,从而减少数据库和 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)机房故障:切换缓存库/数据库到其他机房

每个互联网公司都有网站!而熟悉网站架构流程已成为运维/开发/测试工程师必备技能之一,同样面试中也经常提问,希望大家好好看看,温故思路及经验总结。

来自:https://blog.51cto.com/lizhenliang/1951651




Sevenfal

这个人太懒什么东西都没留下

文章评论(0)