从《毛选》读架构设计：那些被技术人忽略的顶级方法论

写在前面很多技术人对《毛泽东选集》的印象停留在政治读物。但凡真正翻过几篇会发现一个让人意外的事实——《毛选》里讨论的根本不是政治是方法论。实事求是、矛盾论、没有调查就没有发言权、论持久战、星星之火可以燎原……这些不是口号是一整套应对复杂局面的认知框架。而我们做架构设计每天面对的也正是复杂局面业务增长 10 倍怎么改架构性能要求 vs 开发效率怎么权衡单体改微服务从哪一刀切下去技术债务和新功能先做哪个这些问题没有标准答案。教科书给不了大厂方案也未必适用——因为你的业务、团队、阶段都跟别人不同。这篇文章我们抛开哪种技术更好的口水仗从《毛选》里拎几个核心思想出来看看它们怎么帮我们做更好的架构决策。不是穿凿附会是真的有用。一、实事求是架构不是炫技是解决问题实事就是客观存在着的一切事物是就是客观事物的内部联系即规律性求就是我们去研究。——《改造我们的学习》这句话翻译成架构设计的语言先看清楚业务到底是什么样、瓶颈到底在哪里、约束到底有哪些再决定用什么技术。技术圈的反实事求是特别多听说大厂用 K8s自己 5 个服务也要上 K8s看到一篇 ZGC 的文章立刻把 JDK 8 改 JDK 17 上 ZGC同行用了 Service Mesh赶紧给老板写 PPT 说我们也要上中台火了一阵所有公司都在建中台这种就是主观主义。技术选型不是看哪个新、哪个潮、哪个能写在简历上而是看它能解决你现在这个问题吗。一个真实的例子我们在做 iPaaS 引擎的时候有人提过“要不要上 Service Mesh把所有服务治理能力下沉到 Sidecar”如果跟风思维这是个政治正确的答案——技术先进、解耦彻底、CNCF 钦点。但用实事求是的视角问几个问题我们当前服务间调用的痛点是什么答没有特别痛的Dubbo Nacos 已经能做服务发现、负载均衡、熔断上 Mesh 解决什么答理论上多语言友好、运维统一我们有多语言诉求吗答99% 是 Java我们的运维能 Hold 住 Istio 吗答当前团队规模和经验吃不下这个复杂度收益和成本怎么算答收益模糊成本明确结论很清楚不该上。这不是技术保守是实事求是。类似的判断我们做过很多次别人在用我们的判断理由微服务全拆细粒度按流量特征分服务拆得细运维爆炸按流量拆才是真正的瓶颈隔离ES 做日志主存储ES 仅做查询主存储 DorisES 写入贵、压缩比差日志量到亿级扛不住全 Reactive仍以传统 Servlet 为主业务逻辑非纯 IOReactive 收益有限调试成本高全部上云原生 Java仍用 JDK 8 CMS历史包袱重迁移成本远大于收益实事求是的核心不要被什么是先进的绑架要问什么是适合我们的。二、矛盾论抓主要矛盾是架构师的核心能力在复杂的事物的发展过程中有许多的矛盾存在其中必有一种是主要的矛盾由于它的存在和发展规定或影响着其他矛盾的存在和发展。——《矛盾论》这是《矛盾论》最核心的一句话。翻译成架构语言任何系统在任何时刻都同时存在多个矛盾但其中只有一个是当下最关键的。架构师的本事就是看出哪个是主要矛盾。矛盾不会消失只会转化架构设计里永远存在的几对矛盾CAP空间换时间抽象成本易用性短期效率一致性可用性性能内存占用扩展性开发效率安全性用户体验长期可维护快速交付这些矛盾不是要消除的——矛盾不可能被消除只能在不同阶段被主导。举个例子业务从 0 到 1 阶段主要矛盾业务能不能跑起来 vs 用户能不能用次要矛盾代码是否优雅、架构是否完美这个阶段疯狂追求架构完美就是搞错主要矛盾——你产品都活不到第二年谈何 10 年可维护性。业务从 1 到 100 阶段主要矛盾系统能不能扛住 10 倍流量次要矛盾新功能开发速度这个时候还在堆功能不优化架构主要矛盾就抓错了。一个数环通的案例我们 Engine 服务最初是单体架构所有功能流程编排、流程执行、事件接入、API 管理在一起。随着业务增长出现了一个很典型的现象——同一个进程里不同的代码路径有完全不同的流量特征代码路径流量特征资源诉求管理后台接口低频QPS 几十CPU/内存够用即可Webhook 接入突发可能瞬间 1 万 QPS需要削峰能力流程执行高频常态化QPS 几千需要独立扩容后台调度极低频但单次资源消耗大需要资源隔离把这些放在一个进程里主要矛盾就是流量特征不同的代码互相干扰——一次 Webhook 突发就把整个服务拖垮包括完全无关的管理后台。按业务模块拆拆完还是没解决干扰问题。按流量特征拆拆成 3 个服务shuhuan-ipaas-gateway管理shuhuan-ipaas-event-center突发shuhuan-ipaas-engine高频各自独立扩缩容互不影响。问题瞬间解决。关键不在于拆而在于按什么维度拆——按主要矛盾的维度拆才能真正释放价值。三、没有调查就没有发言权架构决策必须有数据支撑你对于那个问题不能解决么那末你就去调查那个问题的现状和它的历史罢——《反对本本主义》这句话很多人耳熟能详但真正在架构决策时落实的人不多。技术圈里拍脑袋决策的现象太普遍“我感觉这个接口慢” → 优化半天发现瓶颈在别处“应该是数据库压力大” → 加机器后发现是连接池配置问题“ES 应该够用” → 上线后发现写入扛不住“缓存应该能命中 90%” → 实际命中率 40%没有数据就没有架构判断。调查的三个层次第一层现状调查做架构决策前必须搞清楚当前 QPS 峰值/均值/分布当前响应时间 P50/P99/P999当前资源使用率CPU/内存/IO/网络当前错误率和错误分布当前的瓶颈点不是猜的是 profile 出来的我们在做日志架构重构前做了一个月的现状调查ES 集群每天写入 8000 万条写入峰值 QPS 12000CPU 长期 80%索引压缩比 2.5即一份原始数据占 0.4 倍空间查询 QPS 不到 50主要场景是按时间范围捞日志历史数据保留要求 90 天存储成本占总基建 40%调查完之后结论自然就出来了这是个写多读少的场景且查询模式简单时间范围条件过滤。ES 用在这里就是杀鸡用牛刀——为了不存在的灵活查询付了大量写入成本。换 Doris列存、高压缩比、时间范围扫描快是显而易见的选择。如果不做这个调查谁敢动毕竟ES 是日志领域的事实标准。第二层历史调查架构里很多奇怪的设计背后都有历史原因。“为什么这里要这样写”“不知道前面同事写的我也没敢动。”每次重构前问几个问题这段代码当初为什么这么设计当时的业务场景是什么现在场景变了吗很多时候你会发现原本不合理的设计在当年的场景下其实是最优解。今天看着别扭是因为业务已经走得太远了。第三层用户调查如果你做的是平台型产品用户还包括平台的使用者——业务团队、其他研发团队。我们做 iPaaS 时反复跟客户技术接触你们最痛的集成场景是什么现在用什么方式接入第三方出问题时怎么排查回答出来的需求和我们最初想象的完全不同。最初我们以为客户最看重连接器数量多调查后发现他们最看重出问题能不能 5 分钟内定位。调研后我们重新调整了优先级——日志、追踪、错误回放优先级提到最高。四、矛盾的特殊性别照搬大厂方案共性个性、绝对相对的道理是关于事物矛盾的问题的精髓。——《矛盾论》每个企业的架构决策都受当下的业务规模、团队水平、历史包袱、资源约束影响。这就是矛盾的特殊性。大厂同款陷阱技术圈里有个流毒——“大厂方案 好方案”。阿里用了双活我们也要双活。字节用了 KubeVirt我们也要 KubeVirt。Netflix 用了 Hystrix我们也要全链路熔断。问题在哪里大厂的方案是为大厂的问题设计的大厂典型问题中小厂典型问题万亿级请求毫秒延迟必须保证千万级请求秒级延迟可接受几千名研发需要严格规范几十名研发灵活协作即可单业务线 100 人一个团队 5-10 人上千个微服务几十个微服务足够自研数据库才能扛RDS 完全够用把大厂方案直接搬到中小厂矛盾完全不一样结果就是 over-engineering——你为了不存在的规模付出了真实的复杂度。一个具体的对比我们 iPaaS 处理千万级日流程但单个流程的执行 QPS 不过几千团队规模 30 人。维度大厂方案我们的方案理由服务治理Service MeshDubboNacosJava 单语言没必要上 Mesh链路追踪自研协议SkyWalking 开源版够用运维成本低配置中心自研多机房Nacos单机房足够数据库自研分布式MySQL DorisTPS 没到自研临界点缓存自研多级缓存Redis 集群命中率已经 95%没必要折腾每个选择都不是先进的但是适合我们当前矛盾的。五、论持久战架构演进是长期过程因为它是持久战将经过三个阶段所以我们不可不预测全战争的总趋势的发展。——《论持久战》毛主席在 1938 年就预测了抗日战争分三阶段战略防御 → 战略相持 → 战略反攻。这种分阶段、有节奏的思维在架构演进上同样适用。架构的三个阶段第一阶段能跑就行战略防御业务从 0 到 1主要任务是验证产品价值。这个阶段的架构原则单体优先能不拆就不拆用成熟方案不要自研接受技术债务但要标记清楚监控基本到位不求高大上这个阶段最忌讳为未来做准备——你都不知道未来在哪凭什么准备第二阶段扛得住战略相持业务起来了流量来了问题暴露了。这个阶段开始还技术债识别瓶颈针对性优化拆分关键服务但不过度拆引入缓存、消息、批处理等手段监控告警体系成熟这个阶段最忌讳推倒重来——重写一个系统比修一个系统难 10 倍且没人会感谢你。第三阶段又快又好战略反攻系统稳定了开始追求极致平台化、产品化性能优化到极限自动化、智能化运维输出方法论和最佳实践这个阶段反过来不能求稳——已经到这步还求稳就是不思进取。数环通的演进路径v1: 单体MVPv2: 按业务模块拆v3: 按流量特征拆v4: 流程引擎专项优化v5: 日志多级缓冲架构v6: AI 辅助流程生成每一步都不是凭空跳跃都是前一步打好基础后才能做下一步。如果第一版就奔着 v6 去设计会犯什么错提前抽象出根本不存在的扩展点为了不存在的未来需求加一堆配置项性能优化各种过度设计但优化的根本不是真正的瓶颈架构演进是持久战不是闪电战。六、星星之火可以燎原MVP 的力量它是站在海岸遥望海中已经看得见桅杆尖头了的一只航船它是立于高山之巅远看东方已见光芒四射喷薄欲出的一轮朝日。——《星星之火可以燎原》技术人特别容易陷入完美主义——想做一个一步到位的系统。但好架构都是长出来的不是设计出来的。从能用到好用我们做日志多级缓冲架构时第一版很简单日志写入 → BatchQueue300条或1秒触发→ 批量写 Doris就这么个简单结构已经能解决 90% 的问题。上线观察一周发现两个新问题峰值时 BatchQueue 会积压突发流量下队列堆积网络抖动时丢数据StreamLoad 失败后数据丢了针对这两个问题迭代到 v2日志写入 → BatchQueue → 中间层批量INSERT → 文件buffer → Doris StreamLoad ↓ 失败时落本地文件加了中间层和文件 buffer。再观察一周又发现大字段的请求 body 把队列撑爆单条日志几 MB持续高负载时仍有抖动没有降级机制迭代到 v3日志写入 → BODY_SLIM_SIZE 裁剪 → BatchQueue → 中间层 → 文件buffer100MB轮转 ReentrantLock → Doris StreamLoad80%负载阈值降级 CallerRunsPolicy 背压这才是今天我们生产环境跑的架构。关键洞察如果第一版就直接做 v3会怎样至少 3 个月才能上线v1 只用了 1 周大量为以后准备的代码可能根本用不上真正的痛点裁剪、降级可能根本没考虑到让架构跟着真实问题长出来比一开始就设计完美架构靠谱得多。七、群众路线架构师不能脱离一线一切为了群众的观点一切向群众负责的观点相信群众自己解放自己的观点。——《关于领导方法的若干问题》架构师有一个特别危险的倾向——坐在办公室里画 PPT、设计图然后把方案下发给团队。这种自上而下的架构治理几乎都会失败。原因很简单一线开发才知道真正的痛在哪里。自下而上的架构我们团队有几个不成文的规矩架构方案先在写代码的人之间讨论不是先在管理层之间讨论一个 RPC 框架升级先问谁写最多 RPC 调用的工程师。他们会告诉你哪些坑、哪些场景没覆盖、哪些 API 设计反人类。故障复盘必须有一线开发主导架构师听一线讲故障比读报告有用 10 倍。报告会被美化复盘会议上的吐槽和叹气是最真实的。新方案的最终决策权下放架构师只提建议最终由模块 owner 决定用不用。模块 owner 不是听话的小弟是这个领域的专家。一个反面教材之前我们试过自上而下推一个统一异常处理框架。架构师设计得很漂亮——一个 BaseException 基类所有异常继承统一拦截器处理。推下去之后呢业务工程师吐槽“这个框架强制所有异常都要包装一层我直接抛 RuntimeException 不香吗”老代码改造工作量巨大没人愿意改各个模块自己又造了绕过框架的小工具最后方案改成什么样反过来。先观察各模块自己怎么处理异常找出共性最大的几个模式做了一个轻量的可选工具类——你想用就用不想用也行。奇迹发生了——这个轻量工具半年内被各模块自发引用了 80%。架构师的价值不是发号施令是把一线的好实践沉淀成可复用的能力。八、把这些思想沉淀成一张工作表为了让这些思想更可操作我们做了一张架构决策工作表每次重大架构变更前都会过一遍思想检查项触发动作实事求是这个技术解决我们的什么实际问题不是听说是实测过的问题没有具体问题→不要做主要矛盾当前阶段最关键的问题是什么这个方案解决的是它吗不解决主要矛盾→优先级降低没有调查就没有发言权现状数据齐了吗历史背景清楚吗用户访谈做了吗数据不全→先调查再决策矛盾的特殊性这个方案是别人家的还是我们自己的我们的特殊约束都考虑了吗完全照搬→警惕 over-engineering论持久战这是当前阶段该做的事还是过早优化分几步走跳跃式→拆解为分阶段星星之火能不能先做一个最小可用版本再迭代一步到位→拆 MVP群众路线一线开发参与设计了吗模块 owner 同意吗自上而下推→先听一线声音这张表不复杂但每一项都对应着真实踩过的坑。写在最后技术人有时候会陷入一种奇怪的优越感——觉得软实力是文科生的事技术人只关心代码就够了。但做到一定程度你会发现写代码是基本功做判断才是分水岭。代码可以教判断教不了。判断从哪里来从大量的决策训练中来从读那些经过历史检验的方法论中来。《毛选》是中国近代最成功的方法论之一——能在极端劣势下打赢极端复杂的战争背后是一整套认知工具。这套工具拿来对付架构设计这种多约束、多目标、多阶段的复杂决策是降维打击。不要把它当成意识形态读物。把它当成一本写得最好的复杂系统决策指南——你会有完全不同的理解。最后送一句《矛盾论》里的话当着我们研究一定事物的时候应当去发现这两方面及其相互关系发现一事物内部的两方面及其相互关系发现一事物和他事物的相互关系。翻译成架构语言任何系统都是矛盾的统一体架构师要做的就是看清矛盾把握矛盾在矛盾中找到当前阶段的最优解。这才是架构设计的最高心法。