大型网站架构技术

随笔2周前发布 卯人
2 0 0

大型网站架构技术

大型网站特点

用户多,分布广泛
大流量、高并发
易受攻击
功能多、变更频繁
海量数据
从小到大、逐渐发展

架构目标

高性能:提供快速访问体验

高可用:网站服务一直正常访问

可伸缩:通过硬件增加/减少,提高/降低处理能力

可扩展:系统间耦合低,方便通过新增/移除方式,增加/减少新的功能模块

安全性:网站安全访问和数据加密,安全存储等策略

敏捷性:随需应变,快速相应

架构模式

分层:
分割:按业务/模块/功能特点进行划分
集群:负载均衡
缓存:将静态资源放在离用户最近的地方,业务数据放高性能数据库中
异步:
冗余:增加副本。提高可用性和性能(灾备
安全:敏感数据加密传输,脱敏、风控、反欺诈等
自动:将重复的、不需要人工参与的,通过工具自动完成
敏捷:

高性能架构

以用户为中心,提供快速的访问体验。主要体现在:响应快
以系统为中心,主要体现在:并发能力高性能稳定。

前端优化: 减少HTTP请求次数,使用浏览器缓存,JS压缩,CDN加速
应用服务层优化:使用多级缓存,异步,集群等
代码优化:合理的架构,多线程,资源复用(对象池),代码逻辑(循环查询数据库问题),cache等
存储优化:缓存。固态,读写分离,分布式存储(HDFS), NoSql等

高可用架构

大型网站在任何时候都应该可以正常访问,但是因为网站大型网站的复杂性,要保证高可用是非常困难的。行内一般用几个9表示可用性指标,比如99.99%

即不通用时间:0.01% * 365 *24 * 60 = 52.56 分钟 / 年

应用层:负载均衡、分级管理、快速失败、服务降级
数据库:主从复制、冷热备份、故障转移
中间件:集群部署、分片交叉备份等
外部环境:ups(不间断电源)、同城灾备、异地灾备

大型系统架构演进过程

使用分布式文件系统
使用NoSql和搜索引擎

大数据(数据仓库
ElasticSearch、
mangoDB

将应用服务器进行业务拆分
消息队列

解耦、削峰、异步

多中心

高可用

评估系统承载能力

业务预估

评估维度

预计三年注册用户数:500万
注册用户数、日均UA、日均PV
峰值预估:平常量的2-3倍

业务评估

- 每天的UA(二八原则): 500万 * 0.2 = 100万
- PV量: 100万 * 30 = 3000 万 (按照每日每个用户点击浏览30次
- 一天集中访问量(二八原则) : 24*0.2=4.8小时  3000万*0.8 = 2400 万
- 每分钟的并发:4.8*60=288分钟, 2400万/288 = 8.33万
- 每秒并发量:8.33万/60 = 1388
- 峰值每秒并发数(三倍):1388*3 = 4164

系统要求

核心接口在并发用户数100(在线用户数的万分之一):
TPS:200/s ,QPS: 5000/s

- TPS :Transactions Per Second(每秒传输的事务处理个数),即服务器每秒处理的事务数
- QPS:Queries-per-second(每秒查询数

步骤

准备压测环境(和线上配置保持一致
通过jmeter压测工具进行测试
测试程度(一般是机器CPU到80%

结果

Samples: 采样数/请求数
Average:平均响应时间,单位毫秒
90%Line:90%的请求响应时间。单位毫秒
Min,Maximum:最小、大响应时间。单位毫秒
Error%: 响应错误率
Throughput: 每秒吞吐量

评估改进

优化系统,以提高更多的负载能力
计算出后台至少需要多少台服务器才能满足要求

__EOF__

大型网站架构技术
本文作者: 遇见星光 本文链接: https://www.cnblogs.com/Right-A/p/17765521.html 关于博主: 评论和私信会在第一时间回复。或者直接私信我。 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处! 声援博主: 如果您觉得文章对您有帮助,可以点击文章右下角【推荐】一下。

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...