《微服务设计》
总体观点
人人喊拆服务，但很多人拆完更痛苦：部署复杂、排查困难，一个请求串过十几个服务，出问题都不知道找谁。
微服务不是目的，是手段：把系统按业务边界切成能独立演进的小块，小步快跑、独立试错。但它有代价——分布式复杂度、运维成本、一致性难题一个都躲不掉。小团队、业务没想清楚、没自动化运维能力，单体可能是更好的选择。
它把“微服务”从时髦口号变成有章可循的工程实践：业务建模、独立部署、为失败而设计、可观察性。这些至今仍是云原生时代的常识。
核心观点
-
1. 先按业务拆，不按技术拆（康威定律）
拆服务按“下单、支付、库存”这样的业务能力，不按“前端队、后端队”分。康威定律：系统架构会复制组织沟通结构。反过来用：想让系统长成什么样，就先把团队按那个样子组织起来。
开餐厅别按“切菜组、炒菜组”分，按“川菜档、粤菜档”分，每个档口从点菜到上菜一条龙。促销和订单拆成两个服务后，促销团队双十一前一周还能独立上线新玩法，不用排队等排期。 -
2. 服务必须能独立部署，否则白拆
“微”不在代码量小，而在改一行代码只上线这一个服务，不用全站陪绑。改A必须连B、C一起上线，那就是“分布式单体”：享受了分布式的痛苦，没得到微服务的好处。
用户中心独立成服务后，头像功能一周上三个版本，订单系统一次没重启——这就是独立部署的价值。 -
3. 数据也要分家，别共用一个数据库
两个服务连同一个库，改表结构就得一起改、一起上线——拆了个寂寞。每个服务管自己的数据，别人走接口来要。跨服务一致性用“最终一致”（发消息异步同步）解决，不靠数据库事务。
订单和库存共用一张表，库存加个字段，订单的SQL全挂了。最后花两个月才把库拆开，代价比一开始就拆大得多。 -
4. 为失败而设计：服务一定会挂
保命四招：超时（别无限等）、熔断器（对方挂了别再敲门）。舱壁（一个服务hang死别拖死线程池）、重试加退避。
家里一个房间短路，空开只断这一间，不会整栋停电。支付网关给银行接口加熔断，银行宕机时几十秒自动切备用通道，用户只觉得“慢了一点”，而不是全站报错。 -
5. 智能端点、哑管道：服务之间通信尽量简单
别搞中央总线（ESB）那种“聪明的管道”：逻辑全塞总线，一升级全站陪葬。用简单的REST或消息队列传数据（哑管道），业务逻辑留在服务自己手里（智能端点）。管道越傻，系统越灵活。
小区快递柜：快递员只管放件（哑管道），取件码、身份验证都在App里（智能端点）。要是每个快递员都得去物业大厅登记审批，双十一那天大厅直接被堵死。 -
6. 先单体，痛了再拆：架构是演进出来的
新项目别一上来就微服务：业务没跑通，边界在哪都不知道，拆错比不拆还贵。先写单体，等哪个模块“改不动、一改全回归”了再拆出去。好边界是长出来的，不是画出来的。
装修先住进去，知道哪面墙碍事再砸，而不是毛坯就按五年后的家庭结构砌墙。某创业公司单体三个月上线，跑一年后才把“拼团”拆成独立服务——那时才真正搞清边界在哪。 -
7. 看不见就管不了：可观察性是必修课
微服务里一个请求串过十几个服务，日志散在十几台机器上。三件套缺一不可：日志聚合、关联ID（一个请求一个编号、全链路追踪）、监控告警。不然线上出问题只能靠猜。
给每个请求打上TraceID：一次“下单偶发超时”，十分钟定位到优惠券服务的慢SQL。以前得人肉对十几个服务的日志，至少半天。
全书思维导图 · 知识脉络树
全书结构
-
第1章 微服务
微服务是围绕业务领域建模、高度自治、具有单一职责且可独立部署的小型分布式服务集合。
电商团队将原本几百万行的巨型应用拆分为商品、库存、订单等独立服务，各服务由独立小团队用最适合的语言独立演进。 -
第2章 演化式架构师
架构师应当像城市规划师而非建筑师：定义好各个区域的建设边界、通信标准与安全红线，把内部具体实现留给团队自治。
架构师规定全公司所有服务必须暴露统一的健康检查路由与遵循标准日志规范，但服务内部是用 Java 还是 Go 由团队自主决定。 -
第3章 如何建模服务
借鉴领域驱动设计（DDD）的限界上下文（Bounded Context）划定服务边界，追求服务间低耦合与业务高内聚。
“用户”在营销服务中关注积分与促销画像，而在财务结算服务中关注银行账号与开票信息，两个服务各自拥有独立模型。 -
第4章 集成
遵循“智能端点与哑管道”原则，坚决杜绝不同微服务共用同一个数据库，在 RESTful 与异步事件发布订阅间权衡选型。
订单服务创建成功后向消息队列投递 OrderCreated 事件，库存服务异步订阅并扣减，两服务通过消息解耦且各自独享数据库。 -
第5章 分解单块系统
采用绞杀者模式（Strangler Fig）逐步从单体中蚕食迁移功能，优先剥离边界清晰、变更频繁或有特殊伸缩诉求的模块。
不推倒重来，而是把图片转码这种极耗 CPU 的独立模块先从单体抽离成独立微服务，单体负载骤降且迁移风险极低。 -
第6章 部署
推行基于容器化与不可变基础设施的自动化持续交付（CI/CD），确保每个微服务能在一分钟内独立构建与安全上线。
每个微服务拥有独立的 Git 仓库与部署流水线，修改发布订单服务无需拉上十几个团队开联调封版大会。 -
第7章 测试
坚守测试金字塔，利用面向消费者的契约测试（Pact）验证跨服务通信兼容性，严格控制端到端集成测试的数量。
客户端用 Pact 编写对下游接口的响应契约，下游服务在 CI 阶段自动校验契约，无需拉起二十个微服务全家桶就能确认兼容性。 -
第8章 监控
集中化日志检索（ELK）、分布式全链路追踪（Trace ID）与关键服务健康度看板是微服务生存的强制基础设施。
在所有跨服务 HTTP 和 RPC 请求头中透传全局 TraceId，线上出现慢请求时一键在监控大盘中拉出完整的服务调用耗时瀑布图。 -
第9章 安全
在 API 网关统一完成身份鉴权与限流，微服务内部通信推行相互 TLS（mTLS）加密认证与基于角色的最小特权授权。
外部客户端在网关层换取 JWT 令牌，微服务之间通信强制校验证书签名，避免内网单点被攻破后黑客随意横向嗅探。 -
第10章 康威定律和系统设计
系统架构必然反映设计该系统的组织沟通结构，全功能、端到端负责全生命周期的双披萨团队是微服务成功的组织基石。
把按“前端组、后端组、DBA组”划分的职能孤岛，改组为围绕“交易域、用户域”端到端闭环的跨职能微服务小团队。 -
第11章 规模化微服务
应用断路器（Circuit Breaker）、隔离舱壁（Bulkhead）与超时降级机制抵御级联故障，利用客户端负载均衡抵御单点抖动。
下游推荐服务响应超时，断路器立即熔断跳闸并返回兜底兜底的热门排行榜数据，阻止请求堆积拖垮核心结算线程池。 -
第12章 总结
微服务不是默认选项也不是万能银弹；单体系统在团队小、业务不明朗时往往更高效，唯有规模爆发时才应拥抱微服务。
早期初创公司三个人若硬拆十个微服务，会被分布式运维和网络延迟折腾死；先做优美单体，业务规模跑起来后再顺理成章拆分。