系统设计没有银弹：50个权衡点告诉你拿什么换什么
内容提要
系统设计无银弹，本质是资源约束下的权衡取舍。加索引提升查询速度但降低写入性能；Kafka可降低总延迟；微服务降低故障率但增加开发运维成本，小团队宜用单体；CAP定理要求网络分区时在一致性和可用性间选择；事件溯源仅适合需审计场景。决策应明确场景重点、愿付代价及承受力。
延伸解读
权衡的本质：资源约束下的取舍
文章强调系统设计没有银弹，本质是在资源约束下做权衡。每个方案都有代价，如索引提升查询但降低写入性能，微服务降低故障率但增加开发运维成本。决策时应明确场景重点、愿付代价及承受力，而非盲目追求最佳实践。
反直觉的延迟优化：Kafka的linger.ms案例
Kafka通过设置linger.ms为5毫秒，主动等待批量发送，反而将端到端延迟从27.5毫秒降至7.5毫秒。这揭示了系统设计中表面与实际的差异，延迟与吞吐量通过排队理论相互关联，调整一个参数可能带来意想不到的效果。
微服务的代价：从单体到分布式痛苦的转换
微服务虽能降低故障率，但初期开发成本高，运维复杂度剧增，分布式调试和事务处理困难。文章指出，小团队或简单业务应优先考虑单体架构，避免为未来扩展而过度设计，因为大多数系统可能活不到需要微服务的那一天。
CAP定理与事件溯源：明确场景再选择
CAP定理要求网络分区时在一致性和可用性间抉择，金融系统选CP，社交媒体选AP。事件溯源虽提供审计追踪，但存储膨胀和查询困难使其仅适用于金融交易等少数场景。决策前需明确自身需求，避免盲目采用复杂技术。
Q&A
为什么说系统设计没有银弹？
因为系统设计本质上是在资源约束下做权衡取舍，没有最好的方案，只有最愿意忍受的代价。每个选择都会带来相应的失去，比如加索引提升查询速度但降低写入性能。
数据库索引过多会带来什么负面影响？
索引过多会显著降低写入性能，因为每次插入数据都需要更新所有索引，导致写入变慢。例如，一张表有五个索引，写一条数据相当于写六次。如果主键是随机值（如UUID），还会导致磁盘I/O爆炸。
Kafka中设置linger.ms为5毫秒为什么能降低端到端延迟？
因为批量发送消息可以减少网络请求次数，从而降低网络往返开销。例如，linger.ms=0时每秒需发2800次请求，改为5毫秒后降至1100次，减少了网络拥塞，整体延迟反而降低。
微服务架构相比单体架构有哪些代价？
微服务架构增加了运维复杂度、分布式调试难度和分布式事务处理难度，初期开发成本比单体高27%。虽然故障率低41%，但省下的故障时间会花在开发和运维上。小团队和简单业务更适合单体架构。
CAP定理中，网络分区时如何选择一致性和可用性？
网络分区时，一致性和可用性只能二选一。金融系统通常选择一致性（CP），宁可暂时不可用也不能出错；社交媒体通常选择可用性（AP），宁可显示旧数据也不能无法访问。
事件溯源适合在什么场景下使用？
事件溯源适合需要完整审计追踪和法律合规要求的核心领域，如金融交易、订单系统。不建议将整个系统建立在事件溯源上，因为会导致事件存储膨胀和查询困难。
做技术决策时应该问自己哪三个问题？
第一，我的场景里什么最重要？第二，我愿意用什么去换它？第三，如果这个交换出了问题，我能承受吗？这三个问题能帮助明确权衡取舍，避免盲目选择。
