跳出纸面：重新理解活的架构设计方法
被高估的完美顶层设计
大多数讲方法的资料，上来就要求你梳理完所有需求，划分好所有模块，定下所有接口规范，才能开始动手写代码。 仿佛只要第一步错了，整个项目就满盘皆输。 错得离谱。 有哪个成熟的项目，需求是从一开始就百分之百确定的？就算是做了十年的传统行业ERP，每年业务变个两三次太正常。创业项目就更别说，三个月前做to C，三个月后转to B，赛道换了架构要全盘推倒，这都不是新鲜事。 一开始就追求完美顶层，本质上是把架构当成了静止的产物，而不是跟着业务生长的活系统。
传统瀑布式架构设计分层框图
很多公司面试的时候，就喜欢问你怎么设计一个高并发系统，要求你说出来全套的分层、缓存、限流、降级，可实际场景里，大多数公司的峰值活动，一年也就办个两三次，峰值也就几万QPS，用个单机缓存加队列就能搞定，根本不需要那么复杂的架构。 过度设计的坑，一半是被这种脱离实际的面试题惯出来的。 说白了，脱离业务场景谈方法，都是纸上谈兵。
适配变化的核心逻辑
我见过活的最久的系统，不是一开始就设计得多么完美，而是懂得把系统拆成不变的核心和可变的扩展两部分。 不变的是什么？是业务最底层的核心逻辑。做交易就是商品、订单、支付，做内容就是创作、审核、分发，这些东西三五年都不会变，就要把它稳定在核心层，尽量少动，不要随便加乱七八糟的逻辑进去。 可变的是什么？是对接的渠道、客户的个性化需求、新出的营销玩法，这些东西变起来快，就要给它做抽象，做隔离，不要让它污染核心逻辑。 举个反例，之前帮朋友看一个To B的项目，客户提了一个个性化的对账需求，开发图省事，直接把对账逻辑写进了订单核心模块，当时觉得没什么，下次另一个客户要不同的对账规则，核心模块动不了，改起来牵一发动全身，最后只能花几十万重写核心。 要是一开始就把对账做成核心层外的扩展模块，哪有这种麻烦？
架构设计可变与不变点划分示意图
这个逻辑说起来简单，做起来难。难就难在，很多人分不清什么该变，什么不该变。 有人把经常变的业务规则放进了核心，核心越来越重，改一次错一堆bug。有人把明明稳定的底层拆得七零八落，每天都要处理模块之间的依赖问题，得不偿失。 说白了，这就是个取舍的问题，没有标准答案，全靠你对自己业务的理解。
落地不能忽略的隐形约束
落地不能忽略的隐形约束
绝大多数讲方法的内容，都不会跟你谈约束。仿佛只要方法对，就能出好架构，可实际落地的时候，全是约束。 第一个约束是团队。一个五个人的创业团队，全栈都要兼三块活，你非要搞几十个微服务，光每天处理部署、依赖问题，就能耗掉一半的生产力，这不是先进，是自嗨。整个团队只有Java开发经验，你非要硬上一个陌生的技术栈，就算架构设计得再漂亮，出了问题没人能搞定，最后还是烂在那里。 第二个约束是时间。项目三个月就要上线，你非要花一个月做设计，做抽象，做扩展，时间到了交不出货，老板要骂娘，客户要撤单，方法再对有什么用？ 说实话，很多时候先跑起来，再慢慢重构，比憋半年出一个完美设计要靠谱得多。 还有一个约束是成本。你为了应对未来可能的一百万并发，一开始就买十台服务器做集群，结果半年下来每天也就几千访问，一半的钱都打了水漂，这值得吗？架构永远要跟成本匹配，超前太多就是浪费。 不过话说回来，很多人捧各种新潮的设计思路，说能解决所有问题，可要是你做的就是一个十多个页面的内部管理系统，总共也就几十个接口，业务逻辑一点都不复杂，你非要拆出一堆复杂抽象，写几十层接口，这就是把简单问题复杂化，新人上手要多花半个月，改个需求要找三天代码，图什么呢？ 现在到处都在讲新架构方向，可你连单体都玩不明白，拆什么微服务？上什么服务网格？多出来的复杂度，够你喝一壶的。 架构从来不是画给别人看的。是拿来用的。 适合你的，才是对的。 别被纸上的规则绑住了脚。