大型网站架构技术

大型网站特点

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

架构目标

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

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

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

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

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

敏捷性：随需应变，快速相应

架构模式

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

高性能架构

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

前端优化： 减少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 许可协议。转载请注明出处！ 声援博主： 如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。