|

技术选型与架构权衡:怎么做决策 学了限流、缓存、消息队列、微服务……每一块单看都讲得通，可真到自己上手做项目，最难的反而是站在岔路口那一下：这个场景，到底该用哪个？ 这篇不教新手段，讲的是怎么做技术选型决策：选型不是选最牛的那个，是选最合适

架构实战:设计一个秒杀系统 —— 把前面学的全串起来 秒杀是公认的后端压轴题：瞬时几十万人抢几百件货、库存绝对不能超卖、还混着一堆刷子——几乎把服务端的主要难点一次性全考了。这篇以秒杀为主线，把缓存、限流、消息队列、分布式锁这些零件如何在一

分布式锁与共识算法:从一把锁到一群节点的一致 单机防并发，synchronized 一把锁就够；可应用扩到十台机器，这把锁就锁不住了——它只管得了自己进程里的线程，管不了另外九台机器同时冲进来的请求，超卖就这么来的。这篇分两层：上半场讲分布

分布式事务:跨服务 / 跨库怎么保证一致 "扣库存 + 扣余额"在单库里一个事务就能搞定：BEGIN 到 COMMIT，要么全成、要么全回滚。可一旦拆成两个服务、两个库，数据库事务只管得了自己那一个连接——"要么都成功、要么都回滚"，突然成

分布式理论:CAP、BASE 与最终一致 数据存在多个节点上，就绕不开一个灵魂拷问：网络一旦出问题，你是保"数据一致"，还是保"服务可用"？ 这就是 CAP 定理——分布式系统的第一块理论基石，也是被误解最多的一个：很多人背得出"三选二"，

API 网关:微服务的统一入口 —— 别让客户端挨个去敲几十扇门 单体拆成微服务，几十个服务散在各处——客户端难道要挨个去调？ 每个服务还得自己做一遍鉴权、限流、跨域、日志？解法是在所有服务前面架一道统一大门——API 网关：请求只认这一个

服务通信:RPC、服务发现与注册 —— 拆成微服务后,"调用"怎么变成了一道难题 单体里调一个方法，orderService.create()，进程内瞬间返回。服务拆开之后，这行"调用"就得跨网络走一趟——用什么协议、对方在哪、有好几台调哪

微服务与服务拆分:何时拆、怎么拆 微服务这几年火得不行,几乎成了"先进架构"的代名词。但真正难的从来不是"会不会用微服务框架",而是两个更朴素的问题:到底要不要拆?该怎么拆? 这两个问题答错了,你不会得到一套优雅的微服务,而是得到一个"分布

异步与事件驱动架构 —— 把系统的协作方式从"打电话"改成"发消息" 同步调用像打电话:你拨过去,得等对方接、等他说完、等他挂,这期间你干不了别的;只要对方占线或不接,你就一直卡着。异步/事件驱动像发消息:发出去就走,对方什么时候看、什么时

用户其实不太关心你的架构画得多漂亮、用了多时髦的技术栈,他只关心一件事:我点进去,能不能用? 一个再优雅的系统,一年崩个十几次、每次半小时,用户照样跑光。所谓高可用(High Availability),说白了就是想尽办法让系统少宕机,宕了