小明离职后的思考（番外篇）：架构师，从丁元英说起

小明最近重刷《天道》看到一个弹幕笑了丁元英如果来我们公司一定是个架构师。仔细想想还真是。论写代码他不如工程师论跑业务他不如销售。但他做了一件事——从零设计了一套系统让一群没文化没资金的农民跑通了整条音响产业链。这就是架构师干的事。不过今天不聊剧情。小明想借这个引子认真聊聊架构师到底需要什么样的思维体系01 架构师到底在做什么小明刚入行时以为架构师就是技术最牛的那个程序员。干了十年才明白这完全是两回事。架构师的核心工作不是写代码是做决策。 架构师的四大核心职责识别约束系统的边界在哪性能要求多少团队什么水平预算多少拆解问题把复杂问题分解为可独立解决的子问题设计方案选择架构风格、技术栈、模块划分、通信方式管控演进确保系统在变化中保持架构一致性这四项职责没有一项是写代码。识别约束需要懂业务、懂组织。拆解问题需要抽象思维。设计方案需要权衡取舍。管控演进需要沟通和影响力。所以架构师不是技术最好的人是能把复杂问题理清楚并做出正确决策的人。 顺便说一句丁元英在王庙村干的就是这四件事——摸清农民的条件识别约束、把音响生产拆成农户分散加工拆解问题、设计分散生产集中组装的模式设计方案、提前设好法律防火墙管控演进。这就是架构师思维的自然运用。02 架构师能力的四层模型小明这些年见过很多架构师有方案漂亮但落不了地的有技术选型总踩坑的有跟业务方永远聊不到一块的。后来他总结出一个规律架构师的能力是分层的越往上越稀缺。道理解人性·把握本质势理解业务·判断趋势法系统思维·架构方法论术技术深度·编码能力第一层术——地基不多说。不懂技术的架构师就是PPT架构师没人服你。 术的要求至少精通2-3个技术栈语言框架中间件理解底层原理操作系统、网络协议、数据库内核有大规模系统实战经验高并发、高可用、大数据量能快速评估技术方案的可行性和风险但术只是门槛。大多数高级工程师卡在这一层十年上不去因为往上的三层靠的已经不是技术能力了。第二层法——分水岭法是方法论是思考问题的方式。这一层决定了你能不能从执行者变成决策者。表格能力含义在架构中的体现抽象能力从具体业务中提炼通用模型能从100个需求中识别出5个核心领域对象分解能力把大系统拆成可管理的模块知道微服务在哪切一刀最合适权衡能力理解每种方案的优劣和代价不追新不守旧根据约束做取舍建模能力用架构视图描述系统不同维度能画出业务视图、技术视图、部署视图决策能力在信息不完整时做出判断追求当前约束下的最优解而非完美方案这五种能力没有一个是靠多写代码练出来的。 小明的亲身经历去年老板说做个电商平台。如果只停在术的层面第一反应是 Spring Cloud MySQL Redis开始写代码。但小明先用法来思考日活多少初期不超过5000后端几个人3个半年内有爆发式增长吗不会结论不拆微服务单体应用拆三个模块先跑通业务日活过万再考虑拆分。这就是法——先分析问题再选方案。而不是先选方案再套问题。 丁元英的法他在王庙村做事有一套清晰的五步逻辑——先看底层规律不是怎么赚钱而是这个行业凭什么赚钱再锁定必然性排除偶然因素找到一定会发生的事然后找准关键决策者核算最坏情况下的代价最后做了决定就承担后果。这五步跟架构师做技术决策的思路完全一致。第三层势——知道什么时候该做什么很多架构师法练得不错方案很漂亮但落不了地。因为不懂势。势是对业务和行业的理解。核心就一句话在正确的时间做正确的事。 势的三个维度业务建模能理解商业模式用DDD等方法对业务领域建模阶段判断知道公司处于什么阶段该用什么级别的技术方案演进规划能根据业务发展预测系统怎么变提前留好扩展点小明总结了一个反模式清单——不懂势的架构师最容易犯的错表格公司阶段错误做法正确做法初创期0→1上来就搞微服务、K8s、全链路监控单体快速验证能跑就行成长期1→10继续堆功能不还技术债开始拆分核心模块建立基础规范成熟期10→100还在用能用就行的思路打补丁系统性重构引入领域驱动设计 真实案例小明之前的公司才200人老板非要学大厂搞中台。花了半年搭中台业务需求一个没接中台也没人用。中台适合什么阶段业务线多、资源充足、需要复用能力的大公司。200人做中台就是杀鸡用牛刀。技术方案没有好不好只有合不合适。 丁元英的势他给王庙村设计的方案不是什么先进的管理模式——就是最朴素的农户分散生产。为什么因为农民没技术、没设备、但有力气能吃苦。这个方案在富士康是笑话在王庙村却是最优解。跟架构选型一样脱离约束条件谈方案都是耍流氓。第四层道——最被低估的能力很多人觉得架构师不需要道技术岗把事做好就行。大错特错。架构设计本质上是人与人的协作问题。你设计了一个完美方案团队理解不了、执行不了、维护不了那就是烂方案。 道包含什么沟通与影响力让不同背景的人理解并认同你的架构决策团队适配根据成员能力分配架构职责让每个人做最擅长的事利益协调理解各方诉求老板/产品/开发/运维在冲突中找最优解格局看到技术之外的东西——组织、文化、人的成长小明见过一个技术极强的架构师方案写得极其漂亮。但每次评审会都跟团队吵架最后大家阳奉阴违方案推不动。半年后他离职了。不是方案有问题是人不行。架构师不是在白板上画图的人是让一群人愿意跟着你的方案走的人。 插一句丁元英最厉害的地方就在这——他知道每个农民的诉求设计了一个让所有人都觉得对自己有利的结构不需要强迫大家自发执行。这就是道的最高境界好的架构不是管控出来的是自发协作涌现出来的。03 五个关键的架构决策思维四层模型告诉你架构师需要什么能力但具体做决策时怎么想小明分享五个自己常用的思维工具。① 约束优先拿到项目不要先想用什么技术先列出约束条件 • 时间什么时候上线 • 人力有多少人可以投入各自擅长什么 • 技术现有系统什么技术栈能不能兼容 • 成本服务器预算多少第三方费用多少 • 合规数据安全要求SLA要求约束条件列出来方案的选择空间自然就缩小了。正确的方案不是最好的是约束条件下最合适的。② 可逆性判断每个决策都有代价。关键判断标准这个决策可逆吗表格决策类型可逆性策略选哪个Web框架高可逆快速决策不合适就换数据库选型中等可逆评估迁移成本但可行单体 vs 微服务低可逆慎重评估一旦拆分很难合回来核心通信协议低可逆影响面大需要充分论证可逆的决策快速做不可逆的决策慎重做。很多架构师的问题不是能力不够是分不清轻重——在无关紧要的选择上纠结太久关键决策反而草率。③ 失败预设做方案时不要只想怎么成功要想失败的时候怎么办。小明每次架构评审都问三个问题 1. 如果这个服务挂了用户会怎样故障影响2. 如果流量是预期的10倍哪里先崩容量瓶颈3. 如果核心开发离职这个模块还有人能维护吗单点风险能回答好这三个问题才算真正过了法这一关。④ 渐进式演进架构不是一步设计好的是演进出来的。小明最怕听到一步到位。一步到位 花半年设计完美方案一次性上线。这种做法几乎没成功过。 演进式架构示例阶段一单体应用快速验证业务1-2个月阶段二拆出独立服务如用户中心、消息中心3-6个月阶段三核心交易链路独立引入消息队列解耦6-12个月阶段四按业务域拆分微服务引入治理体系12-18个月每一步都能独立运转每一步都在为下一步铺路。这才是正确的演进方式。⑤ 利益相关者架构方案不是写给自己的是让所有人理解和执行的。同一份方案对不同人要讲不同的话表格受众关心什么怎么讲CTO成本、风险、长期价值讲ROI讲竞品对比业务方上线时间、功能实现讲业务价值讲用户影响开发团队难不难、怎么干讲技术方案讲分工和边界运维好不好维护讲可观测性、故障预案能让所有利益相关者都理解并支持方案才能落地。这就是道层面的能力——不是技术能力是影响力。04 架构师的完整知识图谱说了这么多思维层面的东西回到硬知识。架构师到底需要掌握哪些表格知识领域核心内容架构师要达到的程度编程语言至少精通2门理解设计哲学能做技术选型设计模式23种GoF模式企业应用模式知道什么场景用什么模式架构风格分层/微服务/事件驱动/六边形等理解每种风格的适用场景和约束分布式系统CAP/BASE/一致性/容错能设计高可用方案数据架构关系型/NoSQL/缓存/搜索/数仓能根据场景选型并设计数据方案中间件消息队列/网关/注册中心理解原理能做容量规划DevOpsCI/CD/容器化/监控告警能设计完整的部署运维方案安全认证授权/数据安全/合规能识别风险并设计防护领域建模DDD/业务架构/数据建模能带领团队完成领域建模软技能沟通/文档/汇报/决策能让非技术人员理解你的方案看着多但核心原则就一个T型人才。至少1-2个领域深度精通T的竖其他领域有广度认知T的横。架构师不需要什么都懂但需要知道谁懂以及他给的方案合不合理。05 从工程师到架构师的成长路径最后怎么从工程师成长为架构师小明总结四个认知跃迁 四个跃迁跃迁一从怎么做→做什么——工程师想实现方式架构师想该不该做、做到什么程度跃迁二从局部最优→全局最优——不再追求自己模块的完美而是追求整体系统的最优跃迁三从技术思维→业务思维——先理解为什么做再决定怎么做跃迁四从解决问题→定义问题——不只是解决别人提出的问题而是发现别人没意识到的问题每个跃迁对应的练习方法表格跃迁练习方法怎么做→做什么每次接需求先问业务目标是什么有更简单的方案吗会引发什么新问题局部→全局画系统图时不只画技术架构还要画出数据流和业务流技术→业务每月和产品经理聊一次核心业务指标用业务语言描述你的系统解决→定义每月写系统健康报告有哪些隐患技术债在哪流量10倍哪里先崩06 写在最后回到开头的丁元英。他为什么能把一群农民组织成一条产业链不是因为他懂音响生产——论生产他不如农民。也不是因为他有钱——他从北京退下来后穷得卖唱片。是因为他的思维方式跟所有人都不一样先看底层规律再设计方案先算代价再做决策先想退路再找出路最后把每个人的利益都算进去让方案自己跑起来。这就是架构师的思维。丁元英没学过软件架构但他天然具备架构师最核心的能力——在复杂约束下做出正确决策并让决策落地。反过来说叶晓明的悲剧也不是能力不够是卡在了术这一层。他只看到了眼前的风险乐圣会报复看不到全局的布局法律防火墙早就设好了。这就是典型的只见树木不见森林——在软件开发中因为一个技术难点就想推翻整个方案的人也是同样的问题。有道无术术尚可求也有术无道止于术。技术可以学框架可以换但思维方式的升级才是架构师成长的核心命题。架构师不是技术最好的人是看得最远、想得最深、算得最准的人。小明的架构师之路还在继续。但他越来越明白一件事写代码只是基础做决策才是价值。