作者在极端 deadline 下分别用单体和微服务架构打造两个金融科技平台，发现架构成败不在技术，而在团队、时间与现实约束是否匹配。
URLenglish Slug：
微服务是潮流？单体是过时？先别急着站队，听我说完这两个真实项目
很多人聊架构，张口闭口就是“微服务是未来”“单体早就该淘汰了”，好像不拆成几十个服务都不配叫现代工程。但现实哪有这么简单？我亲身打造过两个几乎一模一样的金融科技平台——一个用单体，一个用微服务，都在“不按时上线就项目死亡”的地狱 deadline 下硬扛。
结果？微服务那个团队三十人天天开会到崩溃，单体那个就我一个人，一个月上线，活到现在。这不是技术之争，这是现实与幻想的对决。你选的架构，如果匹配不了你的团队、时间、目标，再“先进”都是灾难。
什么是金融科技平台？你以为的“简单申请”，背后全是刀山火海
先说清楚，我讲的“金融科技平台”，不是那种用户点点就能借钱的普通 App。真正的金融平台，是一套涉及身份核验、背景调查、风控模型、银行对接、合规审计、监管报备的复杂系统。用户可能只花三分钟填个表，但后台要跑国家数字身份证接口、查央行征信、调用商业数据库、跑反欺诈规则、生成法律合同、记录完整审计日志——而且所有这些，都不能出错，因为出错就是真金白银的损失，甚至可能被吊销牌照。
更残酷的是，业务和法务团队早就跟监管机构承诺了上线日期，等需求落到工程师头上时，时间早就所剩无几，而需求还在疯狂变动。在这种环境下，架构不是炫技，是求生。
项目一：一个人、一个月、一个单体，硬生生把“废代码”变成活系统
第一个平台，完全是“接盘侠”剧本。我本来只是个前端，天天写内部管理后台，岁月静好。结果某天 IT 总监突然找我：“你不是会 Node 吗？帮忙看看这个项目，就几个小 bug。”我一打开代码，差点吐了——Express + React 的混合体，像是凌晨三点从五个 Stack Overflow 帖子拼凑出来的，逻辑混乱、毫无测试、根本跑不通。我修完 bug 就回去继续写表单了，心想这破项目谁爱搞谁搞。
结果两周后，我被拉进高管会议，才知道这根本不是“小项目”，而是公司押注的金融平台 MVP，必须年底前上线，否则整个业务线砍掉。他们问我能不能救。我说行，但条件是：现有代码全部扔掉，我用 NestJS 从零写一个单体后端。为什么选单体？不是情怀，是活命。一个人开发，哪有精力管什么服务拆分、API 网关、分布式事务？我要的是：一个代码库、一个数据库、一次部署、一条调用链。所有逻辑在一个地方，所有问题一眼就能定位。
那一个月，我每天泡在代码里，写了一堆“以后再重构”的脏代码，遇到了无数 Event Loop 的竞态问题，但系统始终是“连贯”的——用户从登录到放款，每一步都在同一个上下文中，我脑子里只有一个领域模型。到 deadline 那天，系统真的跑通了：用户用国家数字 ID 登录、提交申请、后台跑风控、对接合作方、拿到贷款、看到到账。不完美？当然。有 bug？肯定有。但它能演示、能过监管、能收钱。最关键的是——它活下来了。
更讽刺的是，原计划是 MVP 上线后就用 Go 重构成“高大上”的微服务架构。但客户一看这单体跑得又快又稳，直接说：“别重做了，就用这个赚钱！”于是这个“临时方案”一跑就是好几年，至今还在生产环境扛着真金白银的交易。
项目二：三十人、三十个服务、零时间，微服务成了“会议生成器”
第二个项目，完全是另一个世界。大品牌、大预算、大团队，从第一天就规划成微服务架构。听起来很专业对吧？但 deadline 一来，地狱模式开启。三十个人，来自不同团队，前端、后端、风控、合规、产品、测试……每个人都需要“对齐”。改一个字段？先开三个会，两个团队扯皮归属，再更新文档，再查日志，再同步产品。架构图在 PPT 上看起来干净漂亮，但人与人之间的协作成本高到窒息。
最荒谬的是，我们搞了几十个微服务，结果流量小到一个普通单体都能轻松扛住。我们却要维护几十个 CI/CD 流水线、几十个部署配置、几十个监控仪表盘。发布一次，像在走钢丝——A 服务改了个接口，B 服务没同步，C 服务就崩了。QA 团队被不同服务的集成测试搞到崩溃，前端等后端接口等到发疯，产品经理天天拉着二十人开“决策会”就为了定个按钮颜色。
我们“按时”上线了，技术上算成功。但没人觉得骄傲。每次发布都像在埋雷，任何一个“快速修复”都可能在三个服务外引爆连锁反应。微服务本该带来独立性和弹性，但在时间压力和沟通断层下，它把组织的混乱直接翻译成了系统故障。架构没救我们，反而放大了所有管理缺陷。
软件架构也有“皇马”和“马竞”？微服务是潮流，单体是信仰
如果你去过马德里，就知道那里有两大足球豪门：皇家马德里和马德里竞技。皇马是全球巨星，奖杯堆成山，粉丝遍布世界，穿皇马球衣没人会问“为什么”。而马竞，球迷少、星光弱，但死忠粉极其忠诚——选择马竞，不是因为方便，而是因为认同。
微服务就是软件界的皇马——流行、安全、时髦，写在简历上闪闪发光。单体则是马竞——不炫、不酷，但务实、可靠，只被真正懂行的人选择。我承认，微服务在某些场景下确实强大，但太多团队把它当“默认答案”，只因为它“看起来现代”。
而我？我不盲目追星。在架构选择上，我宁愿做那个穿马竞球衣的人——不是反对皇马，只是更相信适配现实的工具。
真正决定成败的，从来不是架构图，而是四个“无聊”问题
别再纠结“微服务 vs 单体”了。真正该问的是这四个看似枯燥、却致命关键的问题：
第一，你到底有多少时间？如果 deadline 是“下周必须上线给监管看”，那你根本没资格考虑微服务。每个新服务都意味着新仓库、新部署、新契约、新故障点。那是奢侈品，不是起步工具。
第二，你的团队有多强？三个能打的工程师在一个单体里协作，效率远超十个平庸开发者分散在十个服务里互相扯皮。微服务把技术复杂度转移成了组织复杂度——你团队能扛住吗？
第三，你们的流程能支撑吗？有没有清晰的服务契约？有没有版本管理纪律？有没有端到端追踪？如果没有，微服务就是定时炸弹。
第四，你的业务领域稳定吗？如果需求天天变，领域边界模糊，硬拆微服务只会让你每天都在改服务接口。单体反而能包容这种混沌，等业务稳定后再重构。
忽略这四点，再漂亮的架构图都是纸上谈兵。事实上，架构图越 fancy，现实打脸越疼。
单体什么时候是理智之选？微服务又在什么条件下才值得上？
经过这两个极端案例，我不再把单体和微服务看作对立信仰，而是两种工具——各有适用场景，也各有失败模式。
单体是理智之选，当：
- 团队小（≤5 人），沟通成本低；
- 时间紧，需要快速验证核心流程；
- 业务领域未定型，边界模糊；
- 目标是“先活下来”，而不是“先 scale”。
微服务真正值得上，当：
- 核心业务已稳定运行，领域边界清晰；
- 团队规模大（≥10 人）且资深，能独立负责服务全生命周期；
- 确实存在独立扩展需求（比如风控服务流量暴增，但用户服务平稳）；
- 具备成熟的 DevOps、监控、契约管理流程。
记住：单体失败是“慢”，微服务失败是“崩”。前者让你改代码，后者让你背锅。
为什么市场总爱选“皇马”？因为业务要的不是技术，是“看起来安全”
最扎心的真相是：架构选择，往往不是工程师决定的。是业务、是老板、是投资人，为了显得“现代化”“跟得上潮流”，才拍板上微服务。他们不在乎你有没有足够人力维护，不在乎需求是否稳定，只在乎 PPT 上画出的架构图能不能让投资人眼前一亮。
就像在马德里，穿皇马球衣不需要理由——因为它是默认选项。但真正懂球的人知道，马竞的战术纪律和团队韧性，有时比巨星堆砌更致命。软件工程也一样。架构不该是装饰品，而应是生存策略。当你在生死线边缘挣扎时，能救你的从来不是“先进”，而是“合适”。
写在最后：别追风，要追现实
我从执法者变成程序员，最大的感悟是：现实永远比理论复杂。在金融系统里，bug 不只是 crash，可能是百万损失；delay 不只是延期，可能是牌照作废。在这种环境下，架构不是炫技场，而是避难所。
如果你正在为下一个项目选型，请忘掉“微服务是未来”这种口号。先问自己：
我们有多少时间？
我们有多少人？
我们能承受多少协调成本？
我们的业务到底稳不稳定？
答案会告诉你该选什么。不是潮流，不是框架，不是博客文章——是你的现实。
我不会为皇马欢呼，也不会鄙视马竞。我只相信：适配现实的架构，才是好架构。