【亿级流量】网站架构核心技术思维导图分享
2024-02-21 11:42:22 0 举报AI智能生成
登录查看完整内容
【亿级流量】网站架构核心技术思维导图分享
作者其他创作
大纲/内容
避免过度设计、最小化可行产品
任何事都没有表面看起来那么简单
所有的事都会比你预计的时间长
会出错的事总会出错
如果你担心某种情况发生，那么它就更有可能发生
墨菲定律
第一定律：组织沟通方式会通过系统设计表达出来
一口气吃不成胖子，先搞定能搞定的
不指望绝对完美的系统，保障及时恢复的机制
复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的
第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情
做独立自治的子系统减少沟通成本
按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/低耦合，减少沟通成本
第三定律：线型系统和线型组织架构间有潜在的异质同态特性
合久必分，分而治之
第四定律：大的系统组织总是比小系统更倾向于分解
康威定律
通用原则
应用无状态，配置文件有状态
无状态
拆分
服务化
消息队列
构建查询视图，聚合数据到Redis或持久化KV存储
数据异构/数据聚合
浏览器端缓存
APP客户端缓存
1-推送机制：当内容变更时主动推送到CDN边缘节点
2-拉取机制：先访问边缘节点，没有内容时回源到源服务器拿到内容并存储到CDN节点
注意：URL的设计上不能有随机数，否则每次都会穿透CDN回源
CDN缓存
接入层缓存（Nginx）
堆内缓存（JVM）
堆外缓存（如Redis）
应用层缓存（Tomcat）
利用一致性哈希等算法进行分片
分布式缓存
缓存银弹
无依赖关系的数据可以并发化获取，提升整体性能
并发化
高并发原则
吞吐量、响应时间、降级方案等
SLA制定
监控报警
降级读：服务调用降级为只读缓存或只读默认降级数据（如库存默认有货）
开关前置化：如在Nginx层做开关，请求不回源后端Tomcat或者只是小部分回源
业务降级：保障核心业务，强一致性变为最终一致性
降级
隔离
通过接入层将故障负载的流量切走
切流量
限流
版本化管理，程序或数据可以回滚到最近一次正确的版本
可回滚
应急预案
高可用原则
防重
幂等
流程可定义
正向状态和逆向状态可根据系统特征来决定要不要分离存储
状态设计时必须有状态轨迹
当状态很多时使用状态机来驱动状态的变更和后续流程节点操作
状态与状态机
预览修改效果
后台系统操作可反馈
后台系统审批化
文档和注释
代码仓库
备份
业务设计原则
确保任何你开发的系统在发生故障时，至少有一个冗余的实例
1、N+1原则
确保系统可以回滚到以前发布的任何版本
2、回滚设计
设计某些会影响到其他系统或服务通信的高风险系统/功能时，要确保能通过开关禁用
3、禁用设计
在设计阶段就要考虑监控，而不是在实施阶段进行补充
4、监控设计
5、设计多活数据中心
新技术使用在对可用性要求不高的系统功能上
6、使用成熟的技术
7、异步设计
无状态才能弹性扩充
应用无状态，配置有状态
8、无状态系统
永远不要依赖更大、更快的系统
9、水平扩展非垂直升级
10、设计至少要有两个步骤的前瞻性
如果不是你最擅长的，也提供不了差异化的竞争优势，则外购
11、非核心能力外购
使用商品化生产的高性价比硬件，总成本低于高端硬件
12、使用商品化硬件
13、小构建、小发布、快试错
14、隔离故障
自动构建、自动部署、自动发布、自动化测试
15、自动化
AKF15个架构设计原则
如应用负载
数据库读写分离，主库写，备库自由扩容读
数据异构、数据聚合
X轴：无差别的克隆服务和数据
服务拆分（SOA、微服务）
Y轴：面向服务和资源的分割
面向查找分割，如将不同区域用户哈希到不同的服务
算法分片
业务维度
物理逻辑维度
分库分表
Z轴：基于客户或请求者分割工作
AKF扩展立方体
交易性系统设计原则
Last-Modified: 标示文档的最后修改时间
Expires: http/1.0规范定义，表示文档在浏览器中的过期时间，当缓存内容时间超过此时间，则需要重新去服务器获取
Cache-Control: http/1.1规范定义，表示浏览器缓存控制，max-age=20表示文档可以在浏览器里缓存20s。优先级高于Expires
1-首次访问，响应参数
浏览器请求时带上If-Modified-Since请求头，其值是上次请求响应中的Last-Modified，服务端验证这之后内容是否有变化，如果响应状态码是304，表示服务端通知浏览器直接使用缓存内容
2-F5刷新
请求时带上Cache-Control:no-cache 和 Pragma:no-cache，即通知服务端提供一份最新内容
3-Ctrl+F5强制刷新
浏览器直接使用缓存，不去服务端校验过期情况。如场景A页面跳转A页面，浏览器历史记录进行前进后退等
4-from cache
影响参数Age，一般用于缓存代理层（如CDN），代表内容在缓存代理层从创建到现在生存了多长时间
5-Age
6-Vary/Via/ETag
浏览器缓存
HttpClient通过职责链模式来支持可插拔的组件结构，客户端缓存就是通过CachingExec组件进行缓存相关操作的
HttpClient客户端缓存
Nginx代理层缓存
Http缓存
缓存回收机制：空间/容量/时间
缓存回收算法：FIFO/LRU/LFU
Java堆/Java堆外/磁盘缓存
Guava/Ehcache/MapDB
缓存使用模式：Cache-Aside/Cache-As-SoR/Copy Pattern
应用级缓存
热点数据与更新缓存
缓存原子性更新
缓存崩溃与快速修复
多级缓存
1、缓存银弹
异步处理（如注册邮件、注册赠券等）
系统解耦
databus、canal、otter等
数据同步
流量削峰
应用场景
缓冲队列
任务队列
ActiveMQ、Kafka
对请求进行排队、过滤、限流等
请求队列
数据库间的同步机制
数据总线队列
队列类型
阻塞队列
非阻塞队列
有界队列
无界队列
java队列
Disruptor是LMAX开源的一个高性能异步处理框架，提供高性能无锁内存队列实现，用于构建低延迟高吞吐量的交易型应用，也可以构建复杂的任务工作流。
Disruptor+Redis队列
2、队列术
连接池
线程池
3、池化
同步阻塞调用
异步Future
异步Callback
JDK8 CompletableFuture提供了新的异步编程思路，可以对多个异步处理进行执行次序的编排，实现更复杂的异步处理。
异步编排CompletableFuture
JVM缓存/hystrix缓存
请求缓存
CompletableFuture请求合并/Hystrix请求合并
请求合并
4、异步并发
硬件扩容
应用拆分
数据库拆分
当当开源Elastic-Job
任务系统扩容
扩容原则：AKF扩展立方体
基于MySql-Proxy开发的奇虎360Atlas
阿里Cobar、基于Cobar开发的Mycat
银联 upsql-Proxy
1-Sharding-JDBC
2-Sharding-Proxy
3-Sharding-Sidecar
混合架构
Mixed scheme of Sharding-JDBC & Sharding-Proxy
京东Apache项目Sharding-Sphere
中间件
TIDB 等
分布式数据库
事务表
补偿机制
TCC模式（预占、确认、取消）
Sagas模式（拆分事务+补偿机制）
分布式事务考虑最终一致性而不是强一致性
数据库分库分表
X轴扩容，通过是否开启事务导流到主（写）/备（读）库
数据库读写分离
订购MQ或Binlog
Elasticsearch搜索
订阅数据库binlog日志，进行数据消费。如数据镜像、数据异构、数据索引、缓存更新等。
基于阿里Canal实现数据异构
5、扩容
高并发
7-应用层
6-表示层
5-会话层
4-传输层
3-网络层
2-数据链路层
1-物理层
网络七层协议
LVS（软件负载均衡）/ F5（硬件负载均衡）
Nginx负载均衡（支持第七层Http负载均衡&&第四层TCP负载均衡）
round-robin：轮询
ip_hash：根据客户Ip进行哈希
hash_key：对某个key进行哈希或者使用一致性哈希
对请求URL进行负载均衡
least_conn：将请求负载均衡到最少活跃连接点
least_time：均衡到最小平均响应时间
负载均衡算法
失败重试机制
Nginx Tcp/Http 心跳监测
健康检查机制
Consul/etcd/eureka/zookeeper
nginx-upsync-module
动态负载均衡
关注点
1、负载均衡与反向代理
核心业务线程池/非核心业务线程池
线程隔离
多实例部署/子系统拆分
进程隔离
服务分组，构建单独服务集群
集群隔离
机房隔离
读写隔离
动静隔离
爬虫隔离
读热点采用多级缓存
写热点通过缓存+队列模式削峰
热点隔离
资源隔离/环境隔离/压测隔离/AB测试
使用Hystrix框架
基于Servlet3的请求隔离
2、隔离术
保证核心业务，降级非核心业务，提供有损服务
降级目的
页面降级/页面片段降级/页面异步请求降级
如后端服务有问题可以降级为只读缓存
读降级
如秒杀抢购，只进行Cache的更新，异步扣减库存到DB
写降级
将爬虫流量导向静态页或返回空数据
爬虫降级
识别机器人、拒绝高风险用户等
风控降级
降级功能点
超时降级
失败次数降级
流量降级
故障降级
人工开关降级
使用JDK7 WatchService实现监听配置文件变更
配置中心开关
信号量隔离
隔离方式
失败次数累计
接口超时
熔断方式
如果设置为线程隔离，则触发熔断时会通过Thread.interrupt() 中断子线程，抛出InterruptedException或其他线程中断异常，原主线程跳转到fallback（需要实现）
如果设置为线号量隔离，因为这时只有一个主线程，触发熔断后，正在执行的方法会继续执行下去，后续线程直接进入fallback
withExecutionTimeoutInMilliseconds：执行超时时间，默认为1000毫秒，如果命令是线程隔离，且配置了executionIsolationThreadInterruptOnTimeout=true，则执行线程将执行中断处理。如果命令是信号量隔离，则进行终止操作，因为信号量隔离与主线程是在一个线程中执行，其不会中断线程处理，所以要根据实际情况来决定是否采用信号量隔离，尤其涉及网络访问的情况。
熔断流程
熔断效果
触发开关后执行fallback方法
Hystrix降级/隔离/熔断
降级方式
肖飞-京东《服务降级背后的技术架构设计》
参考书
返回默认值，如默认有货/无货
返回兜底数据，如缓存数据、静态页面、排队页面、错误页面等
降级处理方案
3、降级
如数据库连接池、线程池
限制总并发数
如Nginx的limit_conn模块
限制瞬时并发数
限制时间窗口内的平均速率，如Guava的RateLimiter、Nginx的limit_req模块
限制远程接口调用速率、限制MQ消费速率等
根据网络连接数、网络流量、CPU或内存负载等来限流
常见的限流手段
设置固定速率流入，当桶满时新加入的令牌要么丢弃要么在缓冲区等待
令牌桶算法
设置固定速率流出，流入速率不限制，当桶满时溢出丢弃新请求
漏桶算法
限流算法
系统阈值，如Tomcat的acceptCount、maxConnections、maxThreads
限制总并发/连接/请求数
利用池化技术，如数据库连接池、线程池
限制总资源数
Java的AtomicLong或者Semaphore来作为计数器
Hystrix
限流某个接口的总并发/总请求数
可以使用Guava的Cache来存储计数器，过期时间设置为窗口时间
限流某个接口的时间窗请求数（秒/分/时/天）
Guava的令牌桶算法
平滑限流某个接口的请求数
应用级限流
关键点在于限流服务的原子化
Redis+Lua/Nginx+Lua
分布式限流
接入层主要任务：负载均衡、非法请求过滤、请求聚合、缓存、降级、限流、AB测试、服务质量监控等
《使用OpenResty开发高性能Web应用》
Nginx/F5接入层限流
throttleFirst：只处理第一次
throttleLast：只处理最后一次
特定时间窗口内对重复事件最多处理一次
throttleWithTimeout
如浏览器滚动事件、搜索关键词自动补全事件
限制多个重复事件最小执行时间间隔（专业术语防抖动）
节流
4、限流
读服务天然适合重试，写服务大部分不适合重试
合理设置重试机制，并且和熔断、快速失败机制配合
如Haproxy、Nginx、Twemproxy，需要设置与后端真实服务器之间的网络连接/读/写超时时间。Haproxy和Nginx可以实现请求的负载均衡，Twemproxy实现Redis的分片代理。
代理层超时与重试
如Tomcat/Jetty等，需设置客户端与容器的网络连接/读/写超时时间，以及容器默认Socket超时时间。
Web容器超时
如Dubbo、MQ等
中间件客户端超时与重试
连接超时时间、事务超时时间、获取连接池连接等待时间
数据库/NoSQL客户端超时
前端Ajax超时
分类
5、超时与重试
事务回滚
代码库回滚
部署版本化
小版本增量发布
大版本灰度发布
架构升级版本A/B Test平滑过渡
部署版本回滚
数据版本回滚
静态资源带版本号
设置合理的服务器端页面缓存时间
静态资源版本回滚
6、回滚机制
压测方案：压测接口、并发量、压测策略
压测指标：机器负载、QPS(每秒查询率)/TPS(每秒钟处理完的事务次数，吞吐量)、响应时间RT
压测报告：压测方案、机器负载、QPS/TPS、响应时间（平均、最大、最小）、成功率、相关参数（JVM参数/压测参数）根据压测报告结果进行系统优化和容灾。
机房不可用、DNS故障、VIP故障等
网络接入层
CDN故障、上游应用路由切换、限流、降级、隔离等
应用接入层
关注点：依赖服务的路由切换、连接池异常、限流、超时降级、服务异常降级、应用负载降级、数据库故障切换、缓存故障切换等
WEB应用层和服务层
数据库/缓存负载高、数据库/缓存故障
数据层
应急预案：首先进行系统分级，然后进行全链路分析、配置监控报警，最后制定应急预案。
吞吐能力
容量/流量
响应速度
系统评估
扩展/拆分
异步化
使用缓存
跨机房部署
系统升级
响应时间
可用性
降级方案
SLA规划与确认
线下压测
线上局部压测
线上军演
验证
系统体检
1-积极预防问题
系统整体指标、系统可用性、系统处理能力、系统负载、数据、主业务流程
监控/报警
2-及时发现问题
扩容、流量控制、降级、故障转移
培训、演练、现场值班、明确分工和绩效
3-迅速决策/处理
促销活动备战
7、压测与预案
高可用
亿级流量网站架构
0 条评论
回复 删除
下一页
