文章来源：X \@techNmak
📌 系统设计的四个现实
系统设计不是画方框，而是清楚你愿意牺牲什么。你不可能全都要。你想要速度？可能就要丢数据。你想要100%上线时间？那就要烧钱。归根结底，只有四个现实：
-
总有东西会坏掉。别试图构建一个永远不坏的系统。那是不可能的。相反，要选择它在哪儿坏。
-
坏设计：数据库崩溃，整个应用返回502。
-
好设计：数据库崩溃，我们就用5分钟前的缓存数据继续服务，用户根本没察觉。你不是在阻止故障，而是在控制爆炸半径。
-
速度 vs. 真相。在分布式系统中，"真相"代价高昂。如果你想让每个用户在同一时刻看到完全相同的数据，系统就会又慢又脆弱。
-
权衡：我们常常选择在几秒钟内"撒谎"给用户（最终一致性），因为这能让系统更快、更便宜。你必须决定：数据错2秒可以接受吗？银行余额？绝对不行。"点赞"数量？完全可以。
-
复杂度是敌人。微服务很酷，但它把一个简单的函数调用变成了可能超时、失败或丢失的网络请求。
-
规则：如果你只有3个开发人员，就别把应用拆成50个服务。你会把所有时间花在调试网络上，而不是交付功能。为你现有的团队设计，而不是为Netflix的团队设计。
-
"瓶颈"游戏。每个系统都有极限。要么是CPU、内存，要么是网络。
-
你的任务：把瓶颈推到系统中最便宜的那部分。
-
例子：如果数据库是瓶颈，你就惨了（很难扩展）。如果Web服务器是瓶颈，那就没事（多买几台服务器就行）。
-
🛠 系统设计全景速查表（The Cheat Sheet）
| 分类 | 核心技术点 |
|---|---|
| [核心理论概念]{path-to-node="9,1,0,0"} | [CAP 定理 - 一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）（三选二）；PACELC 定理 - CAP的扩展（延迟 vs. 一致性）；ACID vs. BASE - 事务一致性 vs. 最终一致性；一致性哈希 - 在节点变化时分配请求（最小化重平衡）；Gossip 协议 - 节点间的"传染式"通信（Cassandra、DynamoDB）；背量级估算 - 容量预估（QPS、带宽、存储）]{path-to-node="9,1,1,0"} |
| [网络]{path-to-node="9,2,0,0"} | [DNS - 记录类型（A、AAAA、CNAME、MX）、名字服务器、Anycast；负载均衡器 - Layer 4（传输层/TCP）、Layer 7（应用层/HTTP）、轮询、加权；CDN - 边缘节点（PoPs）、边缘缓存、Anycast 路由；代理 - 正向代理（客户端侧）、反向代理（服务器侧）、透明代理；VPN - 隧道协议（IPSec、OpenVPN、WireGuard）；协议 - TCP vs. UDP，HTTP/1.1 vs. HTTP/2 vs. HTTP/3（QUIC）]{path-to-node="9,2,1,0"} |
| [存储]{path-to-node="9,3,0,0"} | [关系型数据库（RDBMS） - PostgreSQL、MySQL（ACID 合规）；NoSQL - 键值存储（Redis）、文档存储（MongoDB）、宽列存储（Cassandra）、图数据库（Neo4j）；对象存储 - S3、Azure Blob（非结构化数据、扁平层级）；文件系统 - NAS（NFS/SMB）、分布式（HDFS、Ceph、GlusterFS）；块存储 - SAN、AWS EBS（给虚拟机用的原始卷）；搜索引擎 - Elasticsearch、Solr（倒排索引）]{path-to-node="9,3,1,0"} |
| [计算]{path-to-node="9,4,0,0"} | [虚拟机 - 硬件虚拟化（EC2、GCE）；容器 - Docker、Podman（操作系统虚拟化）；编排 - Kubernetes（Pods、Nodes、Clusters）、ECS、Nomad；无服务器 - 函数即服务（Lambda、Cloud Functions）、后端即服务（Firebase）；批处理 - MapReduce、Spark、Flink]{path-to-node="9,4,1,0"} |
| [通信]{path-to-node="9,5,0,0"} | [同步 - REST、GraphQL、gRPC（Protobuf）、RPC；异步 - 消息队列（RabbitMQ、ActiveMQ）、发布/订阅（Kafka、SNS）；实时 - WebSockets、Server-Sent Events（SSE）、长轮询、WebRTC；事件驱动 - Webhooks、事件溯源]{path-to-node="9,5,1,0"} |
| [架构模式]{path-to-node="9,6,0,0"} | [微服务 - 服务发现、边车模式、API 网关；单体 - 模块化单体、分层架构；事件驱动 - CQRS（命令查询职责分离）、Saga；无服务器 - 事件触发、无状态函数；点对点（P2P） - 去中心化网络（BitTorrent、区块链）]{path-to-node="9,6,1,0"} |
| [可扩展性 & 可靠性]{path-to-node="9,7,0,0"} | [扩展 - 水平扩展（Scale-out）、垂直扩展（Scale-up）；数据库扩展 - 分片（水平分区）、复制（读副本）、联邦；弹性 - 断路器、舱壁模式、指数退避重试；限流 - 速率限制（令牌桶、漏桶、滑动窗口）；故障转移 - 主动-配备、主动-主动、心跳检测]{path-to-node="9,7,1,0"} |
| [安全]{path-to-node="9,8,0,0"} | [身份认证 - OAuth 2.0、OpenID Connect（OIDC）、JWT、SAML；访问控制 - RBAC（基于角色）、ABAC（基于属性）；加密 - 静态加密（AES）、传输加密（TLS/SSL、mTLS）；网络安全 - WAF（Web应用防火墙）、DDoS防护（Shield）、VPC；原则 - 零信任架构、最小权限原则]{path-to-node="9,8,1,0"} |
| [可观测性]{path-to-node="9,9,0,0"} | [监控 - Prometheus、Datadog（指标、告警）；日志 - ELK Stack（Elasticsearch、Logstash、Kibana）、Fluentd；链路追踪 - 分布式追踪（Jaeger、Zipkin、OpenTelemetry）；健康检查 - 存活探针、就绪探针]{path-to-node="9,9,1,0"} |
📺 实战进阶：Nginx 实现 mTLS 双向认证
在上述"安全"版块中，mTLS（双向认证）是确保微服务间零信任通信的核心技术。关于如何在 Nginx 中落地实现，可以参考我的实战视频演示：
视频地址（请复制链接浏览器打开）：https://www.bilibili.com/video/BV15R4y1P7Yf/(注：原短链为https://b23.tv/DdLBA2I)
底线：好的系统设计就是务实的悲观主义。假设网络已经断了、数据库很慢、新人会在周五推一个bug。为那样的世界去设计。
欢迎关注 B 站LeisureLinux频道，获取更多 Linux 运维与架构实战干货。
