最近在看阮一峰周刊的时候，无意间发现了这个网站，我感觉很合我胃口，讲的也很到位，在这里分享一下：https://blog.algomaster.io/p/30-system-design-concepts。
他的文章总是会拓展出很多方面，我第一次读他写的博客时，还是他在介绍从小到大的系统应该如何设计，挺有意思的，再加上他对自己博客中的很多内容都能够再一次跳转到另外一条已写过的博客，对于我这种总是要依靠再搜索来了解专业术语的人很有帮助。
本文应该也不会写的过于详细，毕竟是拾人牙慧，我打算从详细的笔记中挑选一部分重点进行分享，也能结合一些我编程的感受吧。
好吧这一篇实际上烂尾了，因为用ai折腾了一下笔记以后发现效果不是很好就废弃了，也贴在这里方便以后观看吧。
重点内容
1) Client-Server Architecture
- 是什么：客户端负责交互，服务器负责业务处理与数据访问。
- 为什么重要：它决定职责边界，后续 API、鉴权、日志、扩容都依赖这个边界。
- 实现关注点：业务规则放服务端；接口契约稳定；客户端尽量无状态。
4) Proxy / Reverse Proxy（以 NGINX 为主）
- 是什么：反向代理作为统一入口，接收请求后转发给后端服务。
- 为什么重要：入口层可以集中做 TLS、路由、限流、日志与基础防护。
- 实现关注点：后端不直接暴露公网；配置超时与健康检查；保留真实来源 IP。
6) HTTP / HTTPS
- 是什么：HTTP 是请求-响应协议，HTTPS 在其上增加 TLS 加密。
- 为什么重要：是 Web 系统默认通信基础，直接影响安全性与接口一致性。
- 实现关注点：统一状态码语义；全站 HTTPS；Header 规范（认证、追踪、缓存）。
8) REST API
- 是什么：围绕资源建模，通过标准方法操作资源。
- 为什么重要：减少接口歧义，便于前后端协作和服务治理。
- 实现关注点：路径按资源命名；方法语义一致；响应格式统一；版本策略清晰。
10) Databases
- 是什么：系统的持久化核心，保存业务长期数据。
- 为什么重要：业务正确性、查询效率、事务边界都落在数据层。
- 实现关注点：先设计读写路径再选型；关键表先定义主键、索引和约束。
11) SQL vs NoSQL（MySQL 作为主干）
- 是什么：SQL 偏结构化与事务一致性，NoSQL 偏灵活模型与横向扩展。
- 为什么重要：选型错误会导致后续查询复杂、扩容成本高。
- 实现关注点：核心交易数据优先 MySQL；NoSQL 按场景补充，不做整体替换。
14) Load Balancer
- 是什么：把请求分配到多台服务实例。
- 为什么重要：是水平扩展和高可用的基础能力。
- 实现关注点：分发策略 + 健康检查必须同时具备；失败重试策略与超时配置要统一。
16) Replication
- 是什么：将主库数据同步到副本，提升读能力与容灾能力。
- 为什么重要：单库压力与单点风险都能先被缓解。
- 实现关注点：明确读主/读从边界；监控复制延迟；故障切换流程可演练。
19) Caching
- 是什么：把高频数据放入更快存储，减少数据库和服务计算压力。
- 为什么重要：通常是响应时间优化中收益最高的一层。
- 实现关注点：优先 Cache Aside；设置 TTL；明确缓存失效与回源策略。
24) WebSocket
- 是什么：基于长连接的双向通信机制，服务端可主动推送。
- 为什么重要：实时场景（聊天、状态推送、协作）依赖它。
- 实现关注点：连接生命周期管理（建立/心跳/断线重连）；与普通 HTTP 接口分层。
29) API Gateway
- 是什么：外部请求统一入口，集中处理认证、路由、限流、监控。
- 为什么重要：把通用治理能力前置，减少后端服务重复实现。
- 实现关注点：网关做治理不做核心业务；与 NGINX 边界清晰；可观测性统一接入。
概念速览（其余 19 项）
请求接入与接口协议（1-9）
- 2 IP Address：网络地址标识，所有访问最终都落到 IP。
- 3 DNS：将域名解析到 IP，是请求进入系统前的关键一步。
- 5 Latency：端到端延迟指标，影响用户实际体验。
- 7 APIs：定义服务能力暴露方式，是系统协作契约。
- 9 GraphQL：客户端按需取字段，适合复杂聚合查询场景。
数据存储与查询组织（10-11, 15, 18, 20, 22）
- 15 Database Indexing：用索引加速查询，但会增加写入维护成本。
- 18 Vertical Partitioning：按字段拆分，降低单次查询负载。
- 20 Denormalization：通过冗余减少联表查询，提升读取效率。
- 22 Blob Storage：存大文件（图片/视频/附件），数据库存元数据。
扩展与高可用（12-14, 16-17, 19, 21, 23）
- 12 Vertical Scaling：提升单机配置，实施简单但上限明显。
- 13 Horizontal Scaling：增加实例横向扩容，是长期方向。
- 17 Sharding：按分片键拆数据，解决超大数据规模问题。
- 21 CAP Theorem：网络分区存在时，一致性与可用性需要权衡。
- 23 CDN：静态内容就近分发，降低跨地域访问延迟。
实时通信与系统解耦（24-27）
- 25 Webhooks：事件触发后主动回调外部系统。
- 26 Microservices：按业务能力拆分服务，支持独立部署与演进。
- 27 Message Queues：异步解耦与削峰填谷，降低同步链路压力。
统一治理与可靠性（28-30）
- 28 Rate Limiting：控制请求速率，防止系统被突发流量打垮。
- 30 Idempotency：重复请求只产生一次有效结果，保护关键操作。