@lvlongxiang199 不同时间，服务间的开销与负载会随时变化，例如商场打折，此时订单服务负载突然升高，微服务可以单独给订单模块加码，防止崩掉。单体只能多开几个机子，与订单无关的代码会浪费内存，部署时间会长很多。

微服务技术上不存在特别大的优越性，还会引来技术复杂性 能看到的摸得到的就是带来的**管理**成本优势， 那选择的时候，就看这个项目的阻碍是技术还是管理。 一个项目就 10 个人，上微服务就拿锤子找钉子 一个项目几十人甚至上百人，那就必须上

@HolmLoh #39 我也不知道领导咋想的，用的 k8s 集群部署，新起一个项目，先上十几二十来台服务器再说。 老项目好像一百多台服务器，我们是 PHP ，fpm 和队列服务器还要单独区分，有的队列需要更多消费者的，比一般的 web 服务器还多 我们活跃用户我估算下来才 10w 左右啊，不懂怎么搞的这么大阵仗

写过微服务以后再去写单体，就发现舒服太多了，起码可以方便地知道这个方法要啥参数，具体实现，复杂度骤降

@Ketteiron 会额外占多少内存, 有实际 benchmark 吗 ? 内存占用的绝对大头是在堆（ Heap ）上，而不是代码段（ Code Segment ）。

此事在《微服务架构设计模式》已有记载，我不否认你说的一些缺点，但你说的没有解耦只能说是你们团队有问题，微服务的关键作用就是为了解耦，维持小而自治的团队能降低每个人员的包袱，从而提高持续交付的能力，解耦都做不到还是别搞微服务了。

这都 2025 年， 谈这些我还以为活在 10 年前， 不少云是提供微服务治理的基础设施， 要单体要微服务这东西也能讨论， 实在是技术眼光太窄了。

槽点一大堆，懒得吐槽。估计你没见过玩多云，单云多 AZ ，跨双活专线跨云 K8 和有状态组构成蓝绿的玩法。你没见过的 Availability 严肃高要求，不代表真的不存在，你没见过而已。

楼主技术视野过于狭窄 微服务为什么会诞生，是因为它解决了一些之前难以解决的问题。当服务复杂到一定程度，代码的复杂程度会将维护成本无限提高，这时候需要微服务来进行解耦了。不是亲身经历项目几乎无法维护的场景，会很难理解。

@lujiaxing 以前一个微服务可能 100 人负责，现在剩 50 人，明年可能 25 人，要维护这么一个不可预测的巨大黑盒过于困难，微服务的解耦是用人数堆出来的，人不够用就相当酸爽了。 单体在后期维护上会稍微友好些，单体项目开发者将解耦的时间用于理解其他业务，即使只剩 10 人甚至 1 人，也能勉强保证项目不会出 bug ，能够有足够的人力进行其他业务尝试，不至于被微服务拖着等死。