【系统架构设计百科】微服务架构深度审视:优势、代价与适用边界
微服务不是免费的午餐。本文从分布式系统八大谬误出发,拆解微服务真正解决的问题与引入的代价,梳理服务边界划分的工程方法论,还原 Amazon 和 Netflix 从单体到微服务的真实演进时间线,给出微服务适用与不适用的判断框架。
发布来自土法炼钢兴趣小组的知识、笔记、进展和应用。主题包括数据结构和算法、编程语言、网络安全、密码学等。
共 26 篇文章 · 返回首页
微服务不是免费的午餐。本文从分布式系统八大谬误出发,拆解微服务真正解决的问题与引入的代价,梳理服务边界划分的工程方法论,还原 Amazon 和 Netflix 从单体到微服务的真实演进时间线,给出微服务适用与不适用的判断框架。
从 Gossip 协议的 SI 传播模型出发,深入拆解 SWIM 故障检测协议的直接探测、间接探测和怀疑机制,分析 HashiCorp Memberlist 的源码实现,对比 Serf 与 Consul 的成员管理策略,并提供基于 Memberlist 构建集群成员管理的完整 Go 代码示例。
分布式系统中一致性模型不是二选一,而是一条光谱。本文从线性一致性、顺序一致性讲到因果一致性、最终一致性及其变体,用反例区分每一级的差异,用 Go 代码实现操作历史的一致性检测,并把 ZooKeeper、Spanner、DynamoDB、Cassandra 映射到这条光谱上。
最终一致性承诺'最终'收敛,但没说收敛之前用户会看到什么。你改了头像刷新后消失、余额先涨后跌、回复比原帖先出现——这些都是缺少会话保证的症状。Terry 等人在 1994 年定义了四种会话保证,COPS 和 Eiger 把因果一致性做到了跨数据中心,Bailis 的 Bolt-on 方案让老系统也能补上因果语义。
Paxos 是分布式共识的理论基石。本文从 Single-Decree Paxos 的精确语义和安全性证明出发,逐步推导 Multi-Paxos 的工程优化,分析 Dueling Proposers、性能瓶颈和实现困难,最后给出一份可运行的 Go 实现。
从性能基准、选型决策、隐藏成本三个维度,系统对比 Raft、Multi-Paxos、EPaxos 三大共识协议在工程实践中的真实表现,帮助架构师做出有据可依的选型决策。
分布式系统的正确性证明和协议设计都建立在系统模型之上。同步还是异步?崩溃还是拜占庭?这些看似学术的分类,直接决定了你能用什么协议、不能用什么协议。本文拆解通信模型、故障模型和进程模型三个维度,把 Paxos、Raft、PBFT、Bitcoin 放回它们各自的模型空间。
FLP 说异步系统中共识不可能,但 Raft 跑得好好的。CAP 说三选二,但 Spanner 声称兼得。矛盾不在定理本身,在于读定理时跳过了精确条件。本文回到 FLP、CAP、共识数和收割/产出四篇原始论文,逐一拆解它们的真实陈述、证明思路与工程边界。
Saltzer、Reed、Clark 1984 年的端到端论证解释了为什么很多'看上去合理'的中间层优化最终是错的。本文从原始论文出发,拆解端到端论证在幂等性、exactly-once 语义、E2E 加密中的现代应用,附带 Go 幂等性实现。
Raft 论文 18 页就能读完,但 etcd/raft 用了 15000 行 Go 才把它变成能在生产环境跑的代码。这篇文章从论文的每一个核心机制出发,逐一拆解工程实现中论文没说的东西:PreVote、ReadIndex、LeaderTransfer、ConfChange V2、流水线复制、Async Apply,以及 TiKV 的 Multi-Raft 实践。最后做一次精确的 Paxos 对比,并坦诚讨论 Raft 的已知缺陷。
Multi-Paxos 和 Raft 都依赖单一 Leader 排序所有写请求,Leader 成为吞吐瓶颈和延迟下限。EPaxos 用无主依赖图替代全序日志,Flexible Paxos 用不对称 Quorum 让写路径绕过多数节点。两条路的核心机制、隐含假设、工程代价和已知陷阱。
教科书把故障分成 crash 和 Byzantine 两种,但生产环境里最常见、最难处理的故障恰恰是两者之间的灰色地带:静默数据损坏、时钟跳变、GC 停顿、慢磁盘。本文从故障层级模型出发,逐层拆解五种故障类型,结合真实事故案例分析检测手段与工程应对策略。
顺序算法用时间复杂度和空间复杂度就能衡量好坏。分布式算法多了消息复杂度、轮次复杂度和容错数量三个维度,三者之间存在不可调和的 trade-off。本文从选主、共识、广播三个典型问题出发,梳理这些度量指标的定义、下界和工程影响。
分布式系统的物理时钟从来不精确:石英振荡器每天最多漂移 8.6 秒,NTP 校准依赖对称网络假设,闰秒可以在凌晨击垮 Linux 内核。本文拆解石英漂移的物理根源、NTP/PTP 协议的校准机制、时钟跳变对超时逻辑的破坏、Spanner TrueTime 和 AWS Clockbound 的工程方案,以及工程师应该遵守的墙上时钟与单调时钟使用规范。
物理时钟对不齐,逻辑时钟丢物理信息,向量时钟太重。HLC 用物理时间 + 逻辑计数器找到了平衡。但 Google 选了另一条路:用原子钟和 GPS 把物理误差压到几毫秒。这篇文章从 HLC 的算法正确性证明、CockroachDB 源码实现、TrueTime 工程架构,一直讲到 AWS Clockbound 的开源方案——在物理和逻辑之间,每种选择都是一笔工程账。
64 篇深度长文,从系统模型到前沿研究,覆盖分布式系统的每一个核心主题。
你在教科书上学到的一致性哈希——哈希环加虚拟节点——在生产环境中其实很糟糕。内存爆炸、负载不均、rebalance 元数据传播慢。Google 早在 2014 年就用 Jump Consistent Hash 干掉了它,2016 年又用 Maglev Hash 统治了网络负载均衡。是时候更新你的知识库了。
Raft 保证强一致,但 Leader 一挂全卡。CRDT 不需要共识也能合并——代价是元数据膨胀、只能单调、最终一致。G-Counter、LWW-Register、OR-Set 的 Go 实现,正确性验证,以及什么时候该用 Raft、什么时候该用 CRDT。
分布式系统里最难的问题之一:如何定义事件的先后?物理时钟对不齐,逻辑时钟丢信息,向量时钟太重。HLC 用物理时间 + 逻辑计数器找到了平衡点。从 Lamport 时钟一路推导到 CockroachDB 的工程实现。
Raft 论文 18 页,etcd raft 库 ~15000 行 Go。中间的差距不是代码量,是论文没提的工程 edge case:PreVote、流水线复制、ReadIndex、joint consensus。
Paxos 被引用了几千次,能正确实现它的人不超过几十个。Raft 用可理解性换工程落地,它的 Leader Election、Log Replication 和 Safety 三板斧,撑起了 etcd、TiKV 和大半个云原生基础设施。
一致性哈希算法原理与应用:分布式系统负载均衡与数据分片的核心技术
蒙特卡洛模拟显示:在 5-20 个节点的常见部署规模下,一致性哈希环的负载均衡效果远不如 Jump Consistent Hash、Rendezvous Hash 等替代方案。附完整模拟数据和选型决策框架。
深入探讨一致性哈希在实际应用中的溢出概率问题,通过交互式可视化展示为什么集群容量规划比你想象的更复杂
深度剖析 SLA "几个9"背后的统计陷阱:独立性假设、级联故障、关联故障如何让你的可用性数字沦为一厢情愿的幻觉
服务架构演化实践:从单体到微服务,系统扩展性设计与优化历程