系统架构设计模板-高并发 - 高可用 - 分布式分场景

系统架构设计模板

高并发·高可用·分布式分场景

从需求分析到落地实施的全链路设计框架

10大章节·80+架构模板·200+设计要点

系统架构实战系列

目录

第一章系统架构设计的核心方法论

第二章架构设计文档的标准结构

第三章高并发架构设计模板

第四章高并发核心技术详解

第五章高可用架构设计模板

第六章高可用核心技术详解

第七章分布式架构设计模板

第八章分布式核心技术详解

第九章架构评审、演进与治理

第十章实战案例与速查表

系统架构设计模板·高并发/高可用/分布式分场景

第一章系统架构设计的核心方法论

1.1架构设计的本质

系统架构设计的本质是在约束条件下做出权衡。没有绝对最优的架构，只有最适合当前业务阶段、团队能力

和资源约束的架构。一个日活一万的系统和一个日活一亿的系统，需要的架构完全不同；一个有五十人技术团队的

公司和一个只有三个人的创业团队，能支撑的架构复杂度也完全不同。

架构设计的核心是回答三个问题。系统要解决什么问题？这是业务目标的明确。需要满足哪些非功能需

求？这是对性能、可用性、扩展性、安全性等质量属性的量化。在资源约束下如何取舍？这是对技术选型和架构

方案的决策。很多架构设计失败的根本原因，就是没有明确这些问题就开始画架构图。

1.2架构设计的原则

原则核心思想实践要点

合适优于先进选择成熟稳定、团队熟悉的技术新技术的引入成本往往被低估

简单优于复杂能用简单方案解决的不用复杂方案复杂度是最大的敌人

演进优于一步到位架构随业务演进，不必过度设计提前设计过度会导致浪费

拆分优于聚合模块化、组件化，降低耦合但拆分也有成本，要合理

冗余优于单点关键组件消除单点故障冗余的成本要评估

自动化优于人工部署、监控、扩缩容自动化人工操作是故障的主要来源

可观测优于黑盒系统行为可监控、可追踪、可分析没有可观测性就无法运维

容错优于完美假设组件会失败，设计容错机制分布式系统故障是常态

1.3架构设计的四个维度

架构设计可以从四个维度展开分析。每个维度关注不同的质量属性，需要不同的技术手段。

维度关注点关键指标核心技术

性能响应速度、吞吐能力延迟、QPS、TPS缓存、异步、批处理、并行

可用性系统不中断服务的能力SLA、MTBF、MTTR冗余、故障转移、限流熔断

扩展性应对业务增长的能力水平扩展能力、弹性伸缩无状态、分片、微服务

一致性数据在多副本间的一致性CAP权衡、一致性级别分布式事务、共识算法

1.4架构设计的标准流程

架构设计标准流程：

第1步：理解业务

-业务目标与核心场景

-用户规模与增长预期

-关键业务流程与数据流

第2步：量化需求

-性能需求：QPS、TPS、延迟

-可用性需求：SLA、RTO、RPO

-扩展性需求：峰值倍数、增长曲线

-安全合规需求：等保、数据驻留

第3步：现状分析

-现有系统的瓶颈

-团队技术栈和能力

-预算与资源约束

-时间和人力约束

第4步：方案设计

-总体架构图

-核心组件选型

-数据模型设计

-接口设计

第5步：方案评审

-技术可行性评估

-风险识别与应对

-成本估算

-与其他团队的依赖协调

第6步：原型验证

-关键技术的PoC

-性能基准测试

-失败场景验证

第7步：落地实施

-分阶段实施计划

-灰度发布策略

-监控与应急方案

第8步：持续演进

-性能数据收集

-瓶颈识别

-架构迭代优化

架构设计的常见误区：第一，为了技术而技术，引入团队不熟悉的技术栈。第二，过度设计，为不存在的需

求构建复杂系统。第三，忽视运维成本，只考虑开发不考虑长期运营。第四，脱离业务实际，架构方案无法支

撑真实业务场景。第五，缺乏量化，凭感觉而不是数据做技术决策。第六，不做PoC直接上线，把风险留到生

产环境。

1.5架构决策记录（ADR）

架构决策记录（ArchitectureDecisionRecord，ADR）是记录重要架构决策的标准实践。每个ADR记录一个决

策的背景、选项、决定和后果，便于后人理解"为什么当初这么设计"。

#架构决策记录模板

##ADR-001:选择消息队列技术

###状态

已接受

###背景

订单系统需要异步处理订单创建后的通知、积分、物流等下游操作。

当前采用数据库轮询方式，存在延迟高、数据库压力大的问题。

###决策

采用Kafka作为消息队列。

###考虑的方案

**方案一：RabbitMQ**

-优点：成熟稳定，支持复杂路由，社区活跃

-缺点：单机吞吐量相对较低（万级），扩展性一般

-成本：中等

**方案二：Kafka**

-优点：高吞吐（十万级），持久化，支持分区扩展

-缺点：运维复杂，消息延迟相对较高

-成本：较高（需要ZooKeeper或KRaft）

**方案三：RocketMQ**

-优点：阿里开源，支持事务消息，中文文档完善

-缺点：社区活跃度低于Kafka

-成本：中等

###决策理由

1.业务预期日订单量将达到百万级，需要高吞吐能力

2.团队有Kafka使用经验，运维成本可控

3.需要消息持久化和回溯能力

4.未来可能有流处理需求，Kafka生态更完善

###后果

-正面：吞吐量提升10倍以上，支持水平扩展

-负面：运维复杂度增加，需要额外维护Kafka集群

-风险：消息积压时的处理策略需要明确

###实施计划

1.搭建Kafka集群（3节点，副本数3）

2.订单系统改造，接入Kafka生产者

3.下游服务改造，接入Kafka消费者

4.灰度上线，观察2周

5.全量切换，下线数据库轮询方案

###相关决策

-ADR-002:消息幂等性保证方案

-ADR-003:消息积压监控与告警

第二章架构设计文档的标准结构

2.1架构文档的价值

架构设计文档是架构师的核心交付物之一。它不仅是技术方案的记录，更是团队沟通的媒介、后续演进的依

据、新人上手的教材。一份好的架构文档应该让读者能够回答三个问题：这个系统是做什么的、它是怎么设计的、

为什么这么设计。

2.2标准文档结构

章节内容读者

概述系统定位、业务价值、关键场景所有人

需求分析功能需求、非功能需求、约束条件产品、开发、测试

总体架构分层架构、模块划分、交互关系所有人

详细设计核心模块的详细设计开发

数据设计数据模型、存储选型、数据流开发、DBA

接口设计API定义、协议、版本策略开发、对接方

部署架构部署拓扑、环境规划、配置管理运维、SRE

监控告警监控指标、告警规则、应急方案运维、SRE

安全设计认证、授权、加密、审计安全、开发

演进规划架构演进路径、技术债务管理架构师、技术负责人

2.3需求分析章节模板

============================================================

【需求分析】

============================================================

一、业务背景

------------------------------------------------------------

【业务定位】

本系统是XX业务的订单中心，承载从下单到履约的全流程。

【业务目标】

-支撑日订单量100万，峰值5000TPS

-订单创建成功率达到99.99%

-支持多业务线复用，接入成本低于3人天

【关键场景】

1.用户下单：创建订单、扣减库存、发起支付

2.订单查询：按订单号、用户、时间范围查询

3.订单状态流转：待支付→已支付→已发货→已完成

4.订单取消：超时未支付自动取消、用户主动取消

二、功能需求

------------------------------------------------------------

|功能模块|功能点|优先级|说明|

|----------|--------|--------|------|

|订单创建|下单接口|P0|支持幂等|

|订单创建|库存扣减|P0|分布式事务|

|订单创建|优惠券核销|P1|支持回滚|

|订单查询|详情查询|P0|缓存加速|

|订单查询|列表查询|P1|支持分页|

|状态流转|状态更新|P0|状态机驱动|

|订单取消|超时取消|P0|定时任务|

|订单取消|主动取消|P1|退款流程|

三、非功能需求

------------------------------------------------------------

【性能需求】

-订单创建接口P99延迟<200ms

-订单查询接口P99延迟<100ms

-系统支持峰值5000TPS

-数据库单表数据量<1000万

【可用性需求】

-SLA:99.99%（年停机<53分钟）

-RTO:<5分钟

-RPO:<1分钟

-支持同城双活

【扩展性需求】

-支持水平扩展，新增节点自动负载均衡

-支持业务线隔离，一个业务线的故障不影响其他

-支持未来3年的业务增长

【安全需求】

-用户敏感信息加密存储

-接口调用需要鉴权

-操作日志保留1年

-符合等保三级要求

四、约束条件

------------------------------------------------------------

【技术约束】

-团队技术栈以Java为主

-现有基础设施为阿里云

-数据库使用MySQL

【资源约束】

-预算：XX万元/年

-团队：5名后端+2名运维

-时间：3个月上线

【合规约束】

-需要等保三级认证

-支付相关需符合PCIDSS

-用户数据不能出境

2.4总体架构章节模板

============================================================

【总体架构】

============================================================

一、架构分层

------------------------------------------------------------

┌─────────────────────────────────────────────┐

│接入层（APIGateway）│

│路由/鉴权/限流/熔断/日志│

└────────────────────┬────────────────────────┘

│

┌────────────────────▼────────────────────────┐

│应用层（微服务）│

│订单服务/库存服务/支付服务/用户服务│

└────────────────────┬────────────────────────┘

│

┌────────────────────▼────────────────────────┐

│领域层（业务逻辑）│

│聚合根/领域服务/领域事件│

└────────────────────┬────────────────────────┘

│

┌────────────────────▼────────────────────────┐

│基础设施层│

│MySQL/Redis/Kafka/ES/OSS│

└─────────────────────────────────────────────┘

二、核心模块

------------------------------------------------------------

【接入层】

-APIGateway：统一入口，路由、鉴权、限流

-BFF：针对前端聚合后端服务

【应用层】

-订单服务：订单生命周期管理

-库存服务：库存扣减与回滚

-支付服务：支付流程编排

-用户服务：用户信息管理

【领域层】

-订单聚合：订单实体、值对象、领域事件

-库存聚合：库存实体、扣减策略

-支付聚合：支付单、支付方式

【基础设施层】

-MySQL：订单主数据存储

-Redis：缓存、分布式锁

-Kafka：异步消息

-Elasticsearch：订单检索

-OSS：附件存储

三、关键交互

------------------------------------------------------------

【下单流程】

1.客户端→APIGateway→订单服务

2.订单服务→库存服务（扣减库存）

3.库存服务→MySQL（更新库存）

4.订单服务→MySQL（写入订单）

5.订单服务→Kafka（发送订单事件）

6.订单服务→客户端（返回订单号）

【查询流程】

1.客户端→APIGateway→订单服务

2.订单服务→Redis（查询缓存）

3.缓存未命中→MySQL（查询数据库）

4.回写缓存→返回结果

四、技术选型

------------------------------------------------------------

|层次|技术|版本|选型理由|

|------|------|------|----------|

|网关|SpringCloudGateway|4.x|团队熟悉|

|服务框架|SpringBoot|3.x|生态完善|

|服务注册|Nacos|2.x|支持配置中心|

|RPC|Dubbo|3.x|高性能|

|数据库|MySQL|8.0|成熟稳定|

|缓存|Redis|7.x|高并发|

|消息队列|Kafka|3.x|高吞吐|

|检索|Elasticsearch|8.x|全文检索|

|容器|Kubernetes|1.28+|云原生|

第三章高并发架构设计模板

3.1高并发的本质

高并发的本质是让系统在单位时间内处理更多的请求。并发能力受限于系统的短板：可能是CPU、内存、磁

盘IO、网络带宽、数据库连接数、锁竞争。提升并发能力的方法就是找到瓶颈并消除它，或者通过水平扩展来分摊

压力。

高并发系统的设计需要从四个层面考虑。第一层是流量入口：如何承接大量请求，包括负载均衡、CDN、网

关。第二层是应用服务：如何快速处理请求，包括无状态、异步、批处理。第三层是数据存储：如何支撑高并发读

写，包括缓存、分库分表、读写分离。第四层是系统保护：如何在过载时保护系统，包括限流、熔断、降级。

3.2高并发架构模板

============================================================

【高并发架构设计】

============================================================

一、架构总览

------------------------------------------------------------

┌──────────────────────────────────────────────────┐

│客户端│

└────────────────────┬─────────────────────────────┘

│

┌────────────────────▼─────────────────────────────┐

│CDN│

│静态资源加速/边缘缓存│

└────────────────────┬─────────────────────────────┘

│

┌────────────────────▼─────────────────────────────┐

│负载均衡（L4/L7）│

│SLB/Nginx/DNS轮询│

└────────────────────┬─────────────────────────────┘

│

┌────────────────────▼─────────────────────────────┐

│API网关│

│路由/限流/熔断/鉴权/缓存│

└────────────────────┬─────────────────────────────┘

│

┌────────────┼────────────┐

│││

┌───────▼───┐┌────▼────┐┌───▼──────┐

│服务A││服务B││服务C│

│（无状态）││（无状态）││（无状态）│

└───────┬───┘└────┬────┘└───┬──────┘

│││

└────────────┼────────────┘

│

┌────────────┼────────────┐

│││

┌───────▼───┐┌────▼────┐┌───▼──────┐

│Redis││MySQL││Kafka│

│缓存集群││分库分表││消息队列│

└───────────┘└─────────┘└──────────┘

二、各层设计要点

------------------------------------------------------------

【CDN层】

-静态资源：图片、视频、CSS、JS

-动态加速：API响应边缘缓存

-回源策略：一致性哈希，避免回源风暴

【负载均衡层】

-L4：四层负载均衡，基于TCP/UDP

-L7：七层负载均衡，基于HTTP

-算法：轮询、加权、最少连接、一致性哈希

-健康检查：主动检查+被动熔断

【网关层】

-路由：基于路径、域名、Header

-限流：令牌桶、漏桶、滑动窗口

-熔断：Hystrix、Sentinel

-鉴权：JWT、OAuth2.0

-缓存：热点数据缓存

【应用层】

-无状态：会话外置，便于水平扩展

-异步：非核心逻辑异步化

-批处理：合并小请求为大请求

-并行：并行调用多个下游

-池化：连接池、线程池

【缓存层】

-多级缓存：本地→Redis→数据库

-缓存策略：Cache-Aside、Write-Through

-缓存穿透：布隆过滤器、空值缓存

-缓存击穿：互斥锁、热点永不过期

-缓存雪崩：过期时间随机化

【数据库层】

-读写分离：主写从读

-分库分表：水平拆分、垂直拆分

-索引优化：覆盖索引、最左前缀

-连接池：合理配置连接数

-慢查询治理：定期审查

【消息队列】

-异步解耦：削峰填谷

-流量缓冲：应对突发流量

-顺序保证：分区内有序

-幂等消费：去重表、幂等键

-死信处理：重试与告警

三、容量规划

------------------------------------------------------------

【容量评估】

-日活用户：100万

-日均请求：1亿次

-峰值QPS：10万

-平均响应时间：50ms

【资源估算】

-应用服务器：20台（8C16G）

-Redis：6节点集群（32G内存）

-MySQL：1主2从（16C64G）

-Kafka：3节点集群

【扩展策略】

-应用层：无状态，可水平扩展到100台

-缓存层：RedisCluster支持扩展到100节点

-数据库：分库分表支持100+分片

3.3高并发关键技术

技术作用适用场景注意事项

缓存减少数据库压力读多写少缓存一致性、穿透、雪崩

异步提升响应速度非核心逻辑最终一致性、消息可靠性

批处理减少网络开销批量操作延迟增加、错误处理

池化复用资源连接、线程池大小配置、监控

限流保护系统流量突增阈值设置、降级策略

熔断防止雪崩下游故障熔断阈值、恢复策略

降级保证核心功能资源不足降级策略、用户感知

分片分散压力数据量大分片键选择、扩容方案

3.4高并发性能指标

指标定义目标值优化方向

QPS每秒查询数视业务而定减少单请求耗时、增加并行度

TPS每秒事务数视业务而定减少事务范围、异步化

P99延迟99%请求的响应时间<200ms减少长尾请求

并发数同时处理的请求数视资源而定增加处理能力

错误率失败请求的占比<0.1%减少错误、增加重试

资源利用率CPU/内存/IO使用率60%-80%避免过载或浪费

第四章高并发核心技术详解

4.1缓存设计与实战

缓存是高并发系统最重要的优化手段。合理使用缓存可以将数据库压力降低90%以上。但缓存也引入了新的复

杂度：一致性、穿透、击穿、雪崩。

#缓存使用的标准模式

##模式一：Cache-Aside（旁路缓存）

#读：先查缓存，未命中查数据库，回写缓存

defget_user(user_id):

#1.查缓存

cache_key=f"user:{user_id}"

data=redis.get(cache_key)

ifdata:

returnjson.loads(data)

#2.缓存未命中，查数据库

user=db.query("SELECT*FROMusersWHEREid=%s",user_id)

ifuser:

#3.回写缓存，设置过期时间

redis.setex(cache_key,3600,json.dumps(user))

returnuser

#写：先更新数据库，再删除缓存

defupdate_user(user_id,data):

#1.更新数据库

db.execute("UPDATEusersSET...WHEREid=%s",user_id)

#2.删除缓存（不是更新缓存）

redis.delete(f"user:{user_id}")

##模式二：Write-Through（写穿透）

#写：同时更新数据库和缓存

#读：只查缓存，缓存保证有数据

#优点：缓存永远有数据，读性能最好

#缺点：写性能下降，需要缓存组件支持

##模式三：Write-Behind（写回）

#写：只更新缓存，异步批量写数据库

#优点：写性能极高

#缺点：可能丢失数据，实现复杂

##缓存问题及解决方案

#1.缓存穿透：查询不存在的数据

#方案一：布隆过滤器

defget_user_with_bloom(user_id):

ifnotbloom_filter.contains(user_id):

returnNone#一定不存在

returnget_user(user_id)

#方案二：空值缓存

defget_user_with_null_cache(user_id):

cache_key=f"user:{user_id}"

data=redis.get(cache_key)

ifdata=="NULL":

returnNone

ifdata:

returnjson.loads(data)

user=db.query(...)

ifuser:

redis.setex(cache_key,3600,json.dumps(user))

else:

redis.setex(cache_key,60,"NULL")#空值短期缓存

#2.缓存击穿：热点key过期瞬间大量请求打到数据库

#方案一：互斥锁

defget_hot_data(key):

data=redis.get(key)

ifdata:

returndata

#获取分布式锁

lock_key=f"lock:{key}"

ifredis.set(lock_key,"1",nx=True,ex=10):

try:

#二次检查

data=redis.get(key)

ifdata:

returndata

#查数据库

data=db.query(...)

redis.setex(key,3600,data)

returndata

finally:

redis.delete(lock_key)

else:

#未获取锁，短暂等待后重试

time.sleep(0.1)

returnget_hot_data(key)

#方案二：热点数据永不过期

#后台定时任务主动更新缓存，不设置TTL

#3.缓存雪崩：大量key同时过期

#方案一：过期时间随机化

importrandom

ttl=3600+random.randint(-300,300)

redis.setex(key,ttl,data)

#方案二：多级缓存

#L1:本地缓存（Caffeine）

#L2:Redis

#L3:数据库

#方案三：缓存预热

#系统启动或定期将热点数据加载到缓存

4.2限流设计与实战

#限流算法详解

##算法一：固定窗口计数

#简单但存在临界问题

classFixedWindowRateLimiter:

def__init__(self,max_requests,window_seconds):

self.max_requests=max_requests

self.window_seconds=window_seconds

self.counter={}

defallow(self,key):

importtime

window=int(time.time()/self.window_seconds)

window_key=f"{key}:{window}"

count=self.counter.get(window_key,0)

ifcount>=self.max_requests:

returnFalse

self.counter[window_key]=count+1

returnTrue

##算法二：滑动窗口

#解决临界问题，但需要存储更多状态

classSlidingWindowRateLimiter:

def__init__(self,max_requests,window_seconds):

self.max_requests=max_requests

self.window_seconds=window_seconds

self.requests={}#key->[timestamps]

defallow(self,key):

importtime

now=time.time()

timestamps=self.requests.get(key,[])

#移除窗口外的记录

timestamps=[tfortintimestampsift>now-self.window_seconds]

iflen(timestamps)>=self.max_requests:

returnFalse

timestamps.append(now)

self.requests[key]=timestamps

returnTrue

##算法三：令牌桶

#允许一定程度的突发流量

classTokenBucket:

def__init__(self,capacity,refill_rate):

self.capacity=capacity#桶容量

self.refill_rate=refill_rate#每秒补充的令牌数

self.tokens=capacity

self.last_refill=time.time()

defallow(self,tokens_needed=1):

now=time.time()

#补充令牌

elapsed=now-self.last_refill

self.tokens=min(self.capacity,self.tokens+elapsed*self.refill_rate)

self.last_refill=now

ifself.tokens>=tokens_needed:

self.tokens-=tokens_needed

returnTrue

returnFalse

##算法四：漏桶

#严格按固定速率处理，不允许突发

classLeakyBucket:

def__init__(self,capacity,leak_rate):

self.capacity=capacity

self.leak_rate=leak_rate#每秒漏出的请求数

self.water=0

self.last_leak=time.time()

defallow(self):

now=time.time()

#漏水

elapsed=now-self.last_leak

self.water=max(0,self.water-elapsed*self.leak_rate)

self.last_leak=now

ifself.water<self.capacity:

self.water+=1

returnTrue

returnFalse

#分布式限流：基于Redis的实现

importredis

classDistributedRateLimiter:

def__init__(self,redis_client,max_requests,window_seconds):

self.redis=redis_client

self.max_requests=max_requests

self.window_seconds=window_seconds

defallow(self,key):

#使用Lua脚本保证原子性

script="""

localkey=KEYS[1]

localmax_requests=tonumber(ARGV[1])

localwindow=tonumber(ARGV[2])

localcurrent=redis.call('INCR',key)

ifcurrent==1then

redis.call('EXPIRE',key,window)

end

ifcurrent>max_requeststhen

return0

end

return1

"""

result=self.redis.eval(

script,1,key,

self.max_requests,self.window_seconds

)

returnresult==1

4.3异步与消息队列

#异步化设计模式

##模式一：异步解耦

#场景：下单后需要发短信、加积分、通知物流

#同步方式：下单接口调用三个下游，任一失败影响下单

#异步方式：下单成功后发消息，下游订阅消息

@transaction

defcreate_order(user_id,items):

#1.创建订单（核心逻辑，同步）

order=Order.create(user_id,items)

db.save(order)

#2.发送消息（异步）

kafka.send("order.created",{

"order_id":order.id,

"user_id":user_id,

"amount":order.amount

})

#3.立即返回

returnorder

#下游服务订阅消息

@kafka_consumer("order.created")

defhandle_order_created(message):

#发送短信

sms_service.send(message["user_id"],"订单创建成功")

#加积分

points_service.add(message["user_id"],message["amount"]//10)

#通知物流

logistics_service.notify(message["order_id"])

##模式二：削峰填谷

#场景：秒杀活动，瞬时流量是平时的100倍

#方案：请求先入队，后台按能力消费

defseckill(user_id,product_id):

#1.校验资格（快速失败）

ifnotcheck_eligibility(user_id,product_id):

return{"code":400,"msg":"无资格"}

#2.入队

kafka.send("seckill.requests",{

"user_id":user_id,

"product_id":product_id,

"timestamp":time.time()

})

#3.返回排队中

return{"code":200,"msg":"排队中，请稍后查询结果"}

#后台消费者按能力处理

@kafka_consumer("seckill.requests",max_rate=1000)

defprocess_seckill(message):

#扣库存

ifinventory_service.deduct(message["product_id"]):

order_service.create(message["user_id"],message["product_id"])

##模式三：最终一致性

#场景：分布式事务，无法用两阶段提交

#方案：本地消息表+定时补偿

defcreate_order_with_message(user_id,items):

withdb.transaction():

#1.创建订单

order=Order.create(user_id,items)

db.save(order)

#2.写入本地消息表

db.save(OutboxMessage(

topic="order.created",

payload=json.dumps({"order_id":order.id}),

status="pending"

))

#3.后台任务扫描消息表，发送到MQ

#4.发送成功后标记消息为sent

#5.如果失败，定时重试

4.4池化与连接管理

池类型作用配置要点

线程池复用线程，减少创建销毁开销核心线程数、队列、拒绝策略

数据库连接池复用数据库连接最大连接数、空闲连接、超时

HTTP连接池复用HTTP连接最大连接、每路由连接数

Redis连接池复用Redis连接最大连接、最小空闲、超时

对象池复用大对象适用于创建成本高的对象

#线程池配置示例

fromconcurrent.futuresimportThreadPoolExecutor

importqueue

#自定义线程池

classCustomThreadPool:

def__init__(self):

self.pool=ThreadPoolExecutor(

max_workers=20,#最大线程数

thread_name_prefix="worker-"

)

self.queue=queue.Queue(maxsize=1000)#等待队列

defsubmit(self,func,*args,**kwargs):

"""提交任务，队列满时快速失败"""

try:

self.queue.put_nowait(1)

exceptqueue.Full:

raiseException("系统繁忙，请稍后重试")

defwrapper():

try:

returnfunc(*args,**kwargs)

finally:

self.queue.get()

returnself.pool.submit(wrapper)

#线程池大小计算公式（IO密集型）

#核心数=CPU核数×(1+IO等待时间/CPU计算时间)

#示例：8核CPU，IO等待90ms，计算10ms

#核心数=8×(1+90/10)=80

#数据库连接池配置

#HikariCP配置示例

hikari_config={

"maximumPoolSize":20,#最大连接数

"minimumIdle":5,#最小空闲连接

"connectionTimeout":30000,#获取连接超时(ms)

"idleTimeout":600000,#空闲连接超时(ms)

"maxLifetime":1800000,#连接最大生命周期(ms)

"connectionTestQuery":"SELECT1"

}

#连接池监控关键指标

#-活跃连接数（ActiveConnections）

#-空闲连接数（IdleConnections）

#-等待获取连接的线程数（WaitCount）

#-连接获取平均耗时（AcquireTime）

第五章高可用架构设计模板

5.1高可用的本质

高可用的本质是让系统在部分组件故障时仍能继续提供服务。分布式系统的基本假设是：任何组件都可能失

败，网络随时可能中断。高可用架构的设计目标不是"不故障"，而是"故障时快速恢复"和"故障时降低影响"。

衡量高可用的关键指标是SLA（ServiceLevelAgreement）。99.9%的可用性意味着年停机时间不超过8.76小

时；99.99%意味着不超过52.6分钟；99.999%意味着不超过5.26分钟。每提升一个9，成本往往增加数倍，需要根据

业务价值权衡。

5.2高可用架构模板

============================================================

【高可用架构设计】

============================================================

一、SLA目标定义

------------------------------------------------------------

|系统等级|SLA|年停机|月停机|适用场景|

|----------|-----|--------|--------|----------|

|核心系统|99.99%|52.6分|4.4分|支付、交易|

|重要系统|99.95%|4.4小时|21.6分|用户、商品|

|一般系统|99.9%|8.8小时|43.2分|后台管理|

|内部系统|99%|87.6小时|7.2小时|监控、日志|

二、高可用架构层次

------------------------------------------------------------

┌─────────────────────────────────────────────┐

│第一层：接入高可用│

│DNS轮询/多IP/CDN/负载均衡│

└────────────────────┬────────────────────────┘

│

┌────────────────────▼────────────────────────┐

│第二层：服务高可用│

│多实例部署/无状态/健康检查/自动扩缩容│

└────────────────────┬────────────────────────┘

│

┌────────────────────▼────────────────────────┐

│第三层：数据高可用│

│主从复制/多副本/跨机房/备份恢复│

└────────────────────┬────────────────────────┘

│

┌────────────────────▼────────────────────────┐

│第四层：容灾与备份│

│同城双活/异地灾备/数据备份│

└─────────────────────────────────────────────┘

三、各层设计要点

------------------------------------------------------------

【接入层高可用】

-DNS多IP解析，客户端自动切换

-多可用区部署负载均衡

-健康检查自动摘除故障节点

-灰度发布，逐步切流

【应用层高可用】

-无状态设计，会话外置

-多实例部署，至少2个实例

-健康检查（liveness+readiness）

-自动扩缩容（HPA）

-优雅停机（GracefulShutdown）

-服务降级与熔断

【数据层高可用】

-主从复制：异步/半同步/同步

-多副本：Raft/Paxos

-读写分离：主写从读

-故障转移：自动切换

-数据备份：全量+增量

-跨机房：同城双活/异地灾备

【容灾与备份】

-RTO：恢复时间目标

-RPO：恢复点目标

-同城双活：RTO分钟级，RPO秒级

-异地灾备：RTO小时级，RPO分钟级

-定期演练：每季度至少一次

四、故障场景与应对

------------------------------------------------------------

|故障场景|影响|应对措施|RTO|

|----------|------|----------|-----|

|单实例故障|服务能力下降|健康检查摘除|秒级|

|可用区故障|部分服务不可用|切换其他可用区|分钟级|

|数据库主库故障|写入不可用|主从切换|秒级到分钟级|

|数据库从库故障|读能力下降|摘除从库|秒级|

|缓存集群故障|性能下降|降级到数据库|分钟级|

|消息队列故障|异步功能不可用|降级为同步或延迟处理|分钟级|

|机房故障|全部服务不可用|切换异地机房|小时级|

5.3高可用关键技术

技术作用实现方式注意事项

冗余部署消除单点多实例、多副本、多可用区成本增加，需要负载均衡

健康检查发现故障实例主动探测、被动熔断避免误判导致雪崩

故障转移自动切换主备切换、VIP漂移脑裂问题、数据一致性

限流保护系统令牌桶、漏桶阈值设置要合理

熔断防止雪崩断路器模式半开状态、恢复策略

降级保证核心关闭非核心功能用户体验、通知

隔离限制故障范围线程池隔离、集群隔离资源预留、监控

超时快速失败连接超时、读超时避免过长导致级联

重试处理临时故障指数退避、抖动幂等性保证

5.4故障转移机制

#故障转移核心机制

##机制一：健康检查

#主动检查：定期探测服务状态

#被动检查：根据请求成功率判断

#Kubernetes健康检查配置

apiVersion:v1

kind:Pod

spec:

containers:

-name:app

livenessProbe:#存活探针

httpGet:

path:/health/live

port:8080

initialDelaySeconds:30#启动后30秒开始检查

periodSeconds:10#每10秒检查一次

timeoutSeconds:3#超时3秒

failureThreshold:3#连续3次失败则重启

readinessProbe:#就绪探针

httpGet:

path:/health/ready

port:8080

initialDelaySeconds:5

periodSeconds:5

failureThreshold:2#连续2次失败则摘除流量

startupProbe:#启动探针

httpGet:

path:/health/startup

port:8080

failureThreshold:30#允许启动300秒

periodSeconds:10

##机制二：熔断器

#三态：关闭、打开、半开

classCircuitBreaker:

def__init__(self,failure_threshold=5,recovery_timeout=30):

self.failure_threshold=failure_threshold

self.recovery_timeout=recovery_timeout

self.state="CLOSED"

self.failure_count=0

self.last_failure_time=None

defcall(self,func,*args,**kwargs):

ifself.state=="OPEN":

iftime.time()-self.last_failure_time>self.recovery_timeout:

self.state="HALF_OPEN"

else:

raiseCircuitOpenError("熔断器打开")

try: