2019年双十一，大型淘宝交易峰值每秒54.4万笔。分布这个数字背后，式网是站架一套把几千台服务器拧成一股绳的分布式系统。单机数据库早扛不住了，构设Oracle的计实践RAC集群在2010年前后就已经触到天花板——不是钱的问题，是大型物理极限。

分布式系统的分布第一个坎儿是数据一致性。用户下单扣库存，式网库存服务在A机房，站架订单服务在B机房，构设网络抖一下，计实践A扣了B没收到，大型用户看到下单失败但库存没了。分布这种破事在早期电商系统里天天发生。式网CAP理论说了，一致性、可用性、分区容忍性最多选俩。大部分互联网公司选了AP，用最终一致性兜底。具体做法？消息队列加本地事务表。订单服务先写本地消息表，再发MQ，库存服务消费后回调确认。中间任何环节挂了，定时任务扫消息表补发。听起来简单，坑在幂等——同一个消息可能被消费多次，库存得能识别重复扣减。

服务拆分是另一个头疼事。2015年我参与过一个项目，把单体应用拆成12个微服务，结果调用链从3层变成7层。一个请求超时，你根本不知道是哪个环节卡了。后来上了链路追踪，Zipkin埋点，每个请求带traceId，这才把问题定位时间从小时级压到分钟级。服务拆分的粒度是个玄学——拆太细，网络开销和运维复杂度爆炸；拆太粗，又回到单体老路。我的经验是，按业务边界拆，一个服务不超过3个人维护，数据库表不超过20张。

负载均衡和容错得一起看。Nginx做七层，LVS做四层，这是标配。但真正要命的是服务降级。大促时推荐服务挂了，不能让它拖垮整个交易链路。Hystrix的熔断机制，10秒内错误率超50%直接切断，走fallback返回默认推荐列表。这玩意儿配置有讲究，超时时间设短了误杀，设长了拖死。我们当时设的800ms，因为P99响应时间在600ms左右，留200ms缓冲。

数据分片是躲不过去的。MySQL单表2000万行性能断崖下跌，分库分表中间件用ShardingSphere或者MyCat。分片键选不好，热点问题能让你半夜爬起来扩容。用户表按user_id哈希分1024张表，订单表按订单创建时间分片——但跨片查询就是噩梦。后来我们搞了异构索引，用Elasticsearch做二级索引，查询走ES，回表走分片键。代价是数据同步延迟，业务上得容忍几秒的不一致。

监控体系比架构本身还重要。Prometheus抓指标，Grafana看板，ELK收日志。但光有这些不够，得做全链路压测。每年大促前，用影子库跑一遍真实流量，把瓶颈找出来。有一年压测发现Redis连接池不够，扩容后QPS从8万提到15万。这种问题不压测根本发现不了。

分布式系统没有银弹。每个决策都是权衡——一致性换可用性，性能换成本，复杂度换扩展性。最怕的是照搬大厂方案，人家日活过亿，你日活十万，上Kubernetes加Service Mesh，运维成本能吃掉全部利润。小团队用Spring Cloud Alibaba加Nacos，能跑起来就别折腾。架构是长出来的，不是画出来的。