开门见山架构师干的所有事归结为一句话在约束条件下做取舍并承担后果。不是画图不是选型不是写文档。那些都是取舍的载体。取舍本身才是架构。一、开发者和架构师看同一个问题的区别一个需求丢过来“我们要做一个消息推送系统。”开发者想的是用什么MQ消息体怎么定义接口怎么写架构师想的是推送给谁一个人还是一千万人推送频率一天一条还是每秒一万条丢一条消息业务能不能忍忍多久团队现在会什么给我多少时间多少机器这套东西上线之后下一步业务最可能往哪个方向变看出区别了吗开发者从方案出发。架构师从约束出发。方案是无限的Redis、Kafka、RocketMQ、自研都能推消息。但约束是有限的——时间、人力、钱、团队技能、业务容忍度——这些东西框死之后方案空间会急剧收缩最后剩下的那一两个选择就是你的架构。二、架构设计的真实过程不是灵感一现画出一张漂亮的图。是下面这个过程第一步把模糊的问题变成具体的数字高并发不是需求。“双十一峰值每秒12万笔订单、平均响应200ms以内、数据不能丢”——这才是需求。你没有数字就没有架构。因为你不知道你在对抗什么量级的力。做法很暴力逼业务方给数字给不出就自己估估完让业务方确认。日活用户 × 人均操作次数 ÷ 活跃秒数 峰值QPS的量级有了数字你才知道单机扛得住还是扛不住才知道要不要引入缓存、要不要拆服务、要不要异步化。第二步画出数据怎么流动不要上来就画组件框图。先画数据一条数据从产生到最终被消费经过了哪些节点在每个节点停留多久变成了什么形态用户下单 → 订单写入DB → 发消息到MQ → 库存服务消费扣减 → 结果回写 ↓ 推送服务消费 → 通知用户数据流画清楚了系统的骨架就出来了。剩下的组件选型只是在骨架上填肉。第三步对每个节点问它会怎么死这一步是区分PPT架构师和实战架构师的分水岭。节点死法后果应对DB主库磁盘满写入全部失败监控自动扩容从库切主MQ broker网络分区消息堆积死信队列告警手动消费缓存冷启动/击穿请求全部打到DB预热布隆过滤限流下游服务超时调用方线程池耗尽熔断快速失败降级返回你不需要把所有死法都防住——你需要知道每种死法的代价是什么然后决定哪些值得防、哪些可以忍。这就是取舍。第四步为每个选型写下为什么不选另一个选了Kafka——为什么不选RocketMQ选了最终一致——为什么不选强一致选了单体——为什么不拆微服务如果你只能说出选了什么却说不出为什么不选另一个说明你没做过真正的决策只是在跟风。好的架构决策记录长这样决策消息队列选用 Kafka 备选方案 A. RocketMQ — 支持事务消息但团队无人熟悉运维成本高 B. Kafka — 团队三人有生产经验社区成熟吞吐量满足需求 C. Redis Stream — 轻量但持久化保障不够消息量大时内存扛不住 决策依据 - 团队熟悉度最重要三个月内要上线 - 吞吐量满足日均2000万条消息 - 不需要事务消息业务容忍最终一致 代价 - 放弃了事务消息能力后续如果需要要额外补偿机制三、架构品味什么是好什么是烂技术能力决定你能不能做。品味决定你做出来的东西是不是好的。好架构的特征1. 简单到让人觉得显而易见看到一个架构图第一反应是这不是理所当然的吗——这恰恰说明它好。好架构不让人觉得聪明让人觉得自然。2. 改一个需求只动一个地方如果加一个消息类型要改五个服务的代码——这架构烂了。3. 能说清楚什么不做好架构有清晰的边界。“这套系统不负责 XXX那是另一套系统的事”——说得清这句话说明你想明白了。烂架构的气味你一看就知道它烂但很多人说不出为什么。我帮你总结为了将来可能需要而加的抽象层— 将来90%的情况下不会需要所有服务都通过一个万能中间层通信— 单点、黑盒、出了问题谁都查不出微服务拆了20个但共享同一个数据库— 你拆了个寂寞耦合全在DB层到处写着TODO和临时方案但从来没人回来改— 不是技术债是技术烂账四、后端系统的三层审视法任何后端项目不管多复杂本质上只有三层关注点。架构师的工作就是在这三层之间反复穿梭、反复校验┌─────────────────────────────────────────────────┐ │ 功能层 — 系统做什么 │ │ 需求对不对、逻辑通不通、边界全不全 │ ├─────────────────────────────────────────────────┤ │ 设计层 — 系统怎么做 │ │ 性能够不够、一致性怎么保、扩展性怎么留 │ ├─────────────────────────────────────────────────┤ │ 工程层 — 系统怎么活 │ │ 怎么上线、怎么监控、怎么回滚、怎么不烂掉 │ └─────────────────────────────────────────────────┘大多数人只关注功能层——“能跑就行”。少数人关注设计层——“跑得好”。极少数人关注工程层——“跑得久”。而真正的架构师三层同时看。五、八维检查清单当你做架构设计、做方案评审、或者面试被追问还有吗的时候——心里默扫这张清单□ 功能正确性正常路径能跑通只是及格。异常路径才见功力。参数非法怎么办并发写入同一条数据怎么办上游重试导致重复请求怎么办幂等中间某一步失败了已经执行的步骤要不要回滚□ 性能别猜量化。热路径是哪条80%的流量走哪个分支有没有N1查询、全表扫描、无效循环缓存加在哪命中率预估多少穿透了怎么兜底响应时间的P99是多少不是平均值——平均值骗人。□ 扩展性下一个需求来的时候是加一行配置还是改三个服务加一种新类型/新规则要动几个文件有没有策略模式、插件机制、配置化的口子接口设计是否向前兼容老客户端升不了级怎么办□ 可观测性出了问题能不能在5分钟内定位到根因。关键路径有没有traceId串联错误日志是否带上了上下文用户ID、请求参数、耗时核心指标是否有dashboardQPS、延迟、错误率告警阈值设了没告警了谁来响应□ 运维代码写完才完成了30%。上线、变更、回滚才是剩下的70%。配置变更需要重启吗能不能热加载灰度策略是什么先放1%流量还是先放内部用户回滚要多久回滚后数据兼容吗数据库有DDL变更怎么做到不停服□ 安全你以为没人会攻击你的系统直到有人真的来了。接口鉴权在哪一层做网关还是服务内部用户A能不能通过篡改参数看到用户B的数据敏感字段手机号、身份证存储和日志里脱敏了没SQL注入、XSS这些基本功框架兜底了还是要手动处理□ 一致性分布式系统里没有一定一致只有多久之后一致和不一致了怎么修。缓存和DB之间的一致性窗口是多长业务能忍吗跨服务调用失败数据会不会处于中间状态有没有对账机制多久跑一次发现不一致了怎么修复□ 演化最难的问题不是今天怎么设计而是两年后这个系统会烂成什么样。哪些地方是你现在就知道会变的预留口子哪些地方是你赌它不会变的赌输了代价多大代码里有没有临时方案正在悄悄变成永久方案团队人员流动后新人能不能在一天内看懂核心链路六、怎么用这张清单场景一做架构设计时画完数据流之后拿清单逐条过一遍。不需要每条都有完美方案但每条你都要有明确的态度——要么我做了要么我决定先不做因为……。场景二做方案评审时别人讲方案的时候你心里拿这八条默扫。找到他没提到的那一两条提问——这就是高质量的评审意见。场景三面试被追问时面试官问还有吗你不需要慌。扫一眼清单找到还没提到的维度换个层面展开——每换一个维度你就在展示自己看问题的立体程度。七、怎么练出这种能力不讲虚的三件事1. 对你正在做的系统拿清单过一遍你会发现很多条你答不上来。答不上来的那些就是你系统里正在裸奔的风险。2. 每做一个技术决策写三行字选了什么 / 为什么选它 / 放弃了什么坚持三个月你会发现自己开始能说出为什么了。这就是架构思维的起点。3. 读反转故事从微服务回归单体的案例从云上搬回自建机房的案例从分布式缓存退回本地缓存的案例这些故事告诉你没有绝对正确的方案只有当下约束下的最优解。约束变了最优解就变了。最后架构师不神秘。他只是那个愿意在动手之前多想十分钟为什么的人。他只是那个能把模糊问题逼成具体数字的人。他只是那个敢说这个方案有缺陷但在当前约束下我接受这个代价的人。他只是那个脑子里有一张清单对每个