跳出流程图：重新理解架构设计方法的落地边界

从会议室的白板说起

上周在南京浦口的产业园开项目评审会。有人把画了三天的框图铺在会议桌上，满页面的组件框和连线，问我哪里不对。我指着最核心的业务模块说，这里没说清楚，当并发翻三倍的时候，哪个节点先崩？

全场安静了十秒。

很多人学了一堆范式，张嘴就是领域划分，闭口就是服务拆分，到了现场还是解决不了实际问题。为什么？因为把套路当成了标准答案，而不是解决问题的工具。大多数所谓的分享，都只讲了怎么做，没讲什么时候不能这么做。

说白了，你跑不通业务，解决不了当前的痛点，画再标准的图也没用。

隐藏在方法背后的约束条件

任何成型的思路，都有它成立的前提。

大家都在说单体臃肿，拆分灵活。那什么时候绝对不能拆分？去年接触的一个区县政务项目，整个开发团队就三个人，半年要上线，硬拆成八个微服务，光接口联调就花了两个半月，最后上线还出了一堆跨服务数据一致性问题，上线前一周天天熬夜回滚，何苦来哉？

架构设计的核心，从来不是追求最先进的范式，是匹配当前团队、业务、资源的所有约束。很多人会忽略这一点，拿大厂级别的方法论直接套十个人的创业项目，那不叫设计，叫削足适履。

网上很多内容，上来就讲高并发大流量的处理方案，可百分之九十的中小项目，流量连一台两核4G的云服务器都跑不满，要什么异地多活？纯粹是自找麻烦。

还有业务阶段的约束。早期项目要快速试错，你花一个月搭完所谓的完美架构，等你搭完，需求都变三回了。这个时候，快速出活比什么都重要，哪怕写点将就的代码，能跑通验证商业模式就是好设计。

反过来，当业务已经跑了两年，用户量翻了十倍，改一个小需求要动半个代码库，发布一次要熬夜盯三个小时，这个时候还说不用重构，那就是懒。

落地的路径：从问题出发，而非从框架出发

说实话，我见过太多工程师上来就选技术栈画模块，把所有能想到的扩展性都留好，最后发现大半预留的接口从来没人用过。

正确的路径其实反过来。先坐下来把当前的问题列出来。最疼的点是什么？是改个需求要跨三个部门审批？还是峰值的时候支付接口总超时？还是团队分成了两个组，每次合并代码都要打一架？找到那个最核心的痛点，再选对应的思路解决，而不是为了用方法而找问题。

举个例子，拆分服务的合理前提，是跨团队协作已经被单体拖住了，每个人改代码都要担心影响别人的模块，这个时候拆分才会提升效率。如果你拆分完了，改一个需求反而要找四个团队联调，那就是错的，完全背离了初衷。

我见过最离谱的一个例子，给一个只有内部十个人用的报表系统做异地多活，每年光服务器成本多花几十万，报表一周才导出三次，出问题晚两个小时修都没人在乎，这钱花的，换点团队季度奖金不好吗？

不过话说回来，也不能走另一个极端，就是完全不设计，堆完代码再说。架构的债，欠多了总是要还的。只是不要提前还，当问题还没出现的时候，没必要为了想象中的风险花真金白银。

说透了，这类方法的应用边界很清晰：它只能解决已知的不确定，解决不了完全的未知。你创业第一年，业务方向都没定，设计三年后的架构，全都是瞎猜，白费功夫。

这个领域最大的风险，从来不是设计不够完美，是过度设计，把简单问题复杂化，抬高了整个项目的沟通成本、维护成本、迭代成本。很多项目死不是死在架构不够好，是死在架构太“好”，好到提前透支了所有的资源，最后业务没起来，钱已经花完了。

最近两年能感觉到，行业慢慢回到务实，越来越多人接受适度设计的思路，不追求一步到位，不追求最先进，只追求最适合当前阶段的。那些做了十年以上还活的舒服的项目，大多不是一开始就设计得完美无缺，是跟着业务的问题慢慢调、慢慢改，一步步演化出来的。哪有什么一劳永逸的设计？都是踩着坑走出来的。