聊点实在的：能落地的架构设计方法

聊架构设计，网上一搜一堆高大上的概念，从DDD到云原生，从四色原型到C4模型，看得人头都大。可是真到自己上手做项目，还是不知道从哪下手。

我踩过的坑，比你吃过的泡面还多。今天就说点能直接用的。

别拿‘完美架构’坑人了

刚做技术那几年，我也迷信完美架构。当时接了一个中小电商的订单，我硬着头皮给人拆了八个微服务，把能用上的设计模式全塞进去了，拍着胸脯说这个架构能撑十年。

结果呢？人家团队一共四个开发，改个活动页要跨三个服务联调，上线一次要等三天。不到一年，平台换服务商，我的‘完美架构’直接进了垃圾堆。

说出来好笑，那时候我还觉得是人家团队水平不行，配不上我的架构。现在想想，我那就是害人。

现在行业里这个风气真的不好，不管什么规模的项目，开口就是高可用可扩展，闭口就是领域驱动云原生，好像不做个能支撑千万并发的架构，就不算会做设计。

可你算笔账，千万并发要多少服务器多少人力，你那项目一天才几千个访问，提前花几百万做出来，不是纯纯浪费钱吗？

很多所谓的‘标准架构设计方法’，都是大厂几千人团队养出来的，你一个十几个人的创业团队拿来用，就相当于给奥拓装了个F1的引擎，跑不起来还能把车架撑散。

真正实用的架构设计方法，核心就是抓两个点

说实话，我做了十五年技术，见过能赚钱能活下去的项目，架构从来都是慢慢长出来的，不是一开始拍脑袋画出来的。

落地的方法一点都不复杂，就两步。

第一步，先把当前的业务痛点拆成不可再分的独立问题，别上来就谈重构谈拆分。

举个例子，你现在做内容平台，痛点是新内容发出来，五分钟才能推给用户，延迟太高。那你别上来就说我要把整个推送架构全换了，先看问题出在哪？是不是原来的推送队列优先级没做，热点内容被普通内容堵了？先加个热点内容插队规则，花一天改完，问题解决了，不好吗？

解决不了再往下拆，是不是数据库扛不住写入？是不是带宽不够？一个一个问题解决，比上来就重构整个系统靠谱一万倍。

第二步，找对业务里的不变量。架构设计最核心的本事，就是分清楚什么会变，什么永远不变。

不变的是什么？是你的核心业务逻辑。比如做电商，用户下单、扣库存、付款这个流程，不管你加多少新玩法，核心逻辑不会变。变的是什么？是营销活动、是推荐算法、是前端展示，这些东西变的频率很高。

那你设计的时候，就把不变的核心逻辑抽出来，做稳定的底层服务，变的部分放在上层，让业务团队自己改去，互不影响。这不就够了？

很多人设计架构，反过来了，把变的东西都塞到底层，不变的核心逻辑拆的七零八落，改个需求要动十几个服务，每次上线都心惊胆战，这不是架构，这是给自己埋雷。

不同阶段用不同方法，哪有什么万能公式

架构设计最忌讳的就是生搬硬套，什么阶段说什么话。

你是创业团队做MVP，十几个人要快速跑通业务，那你就老老实实写单体，所有东西放一块，改起来快，部署也简单，什么微服务什么DDD，先放一边。先把业务跑通，拿到融资了，用户起来了，再谈拆分不行吗？

我见过太多创业项目，死不是因为业务不行，是死在上来就搞复杂架构，把钱都花在养架构上了，业务还没跑出来，钱烧完了。

那到了几百人团队，业务稳定增长了，怎么用方法？那你就慢慢拆，按业务域一块一块拆，拆一块跑顺一块，别一下子推翻重来。原来的单体用了好几年，肯定有很多积累，你上来全扔了，那之前踩过的坑还要再踩一遍，图什么呢？

之前我在一家做零售的公司，原来的单体架构撑了五年，业务涨了八倍，后来拆微服务，我们拆了整整两年，一块一块切，从来没停过业务更新，也没出过大事故，这不香吗？

现在AI火了，好多人问我，AI会不会改变架构设计方法？

本质没变。工具变了而已，原来你要花一天画架构图，现在AI十分钟给你出十个方案，可哪个方案适合你，AI不知道啊。AI不知道你团队只有五个人，维护不了三十个服务，AI不知道你下个月就要上线大促，根本没时间改整个架构。

这些判断，还是要你自己来。

不过话说回来，也不是说完美架构不存在，只是完美的架构，从来不是设计出来的，是演化出来的。你今天留够了扩展空间，跟着业务长，三五年后自然就是好架构。

我现在看架构好不好，就三个标准：团队改起来快不快，出问题排查快不快，撑当前业务够不够。就这三个。满足了，就是好架构，不满足，吹的再天花乱坠也是垃圾。