预期行为，这种服务器就是给用量小的服务用的。接着用还会更进一步地限速，最后变成不可用级别，直到下一个周期。

Google 应该是这几个里面亏最多的，大家都在等竞争者撑不住，赌未来的收益大于当下的亏损。

@lologame #72 对，这些问题都是单体换微服务的驱动力，但老一套说实话又不是不能用，至少一堆破烂 ERP/MES/CRM 等等玩意的用户根本不会在意，属于没有需求创造需求。

@cctv6 #70 对我个人来说，决定换成单体时 AI 因素确实占了挺大的比重。
微服务在人够用的时候还是有好处，屏蔽了很多耦合逻辑的心智负担，它强迫每个人一点一点组织出需要的数据，整体上是线性逻辑。
而单体需要像蜘蛛织网那样，考虑其他业务因素，考虑复用可能性，考虑如何组织代码，如何对相邻业务不清晰边缘进行重构，当业务复杂起来后可读性会越来越低，重构难度也会越来越大，难以划分开发人员职责边界。
如果在几年前，引导这样的项目确实很难，但我在深度使用 AI 辅助编写个人项目后改变了这个观点。
Agent 是世上最强大的静态代码分析器，是会思考的 linter ，是能胜任这个场合的助手，我们要做的是如何帮助它更好地理解我们的项目，反过来它就会了如指掌地为程序员提供错误率较低的解决方案和代码实现，我通过编写 MCP 服务实现了这一点，应该很多公司也在这么做。
我自己的实现是让 AI 顺着代码文件的依赖引用总结思考，最终生成一个包含依赖的摘要，自动在流水线上完成，每次合并都会更新相关改动的文件，而 Agent 就可以通过 MCP 服务获得所需全部摘要，在不依赖大量上下文消耗下能了解整条链路，对当前需求进行实现、检查、优化、提供建议，我个人认为是不错的。
其实 gpt-5-high 等模型配好 rules 和公开 MCP 也能实现类似功能，只是没法更快更智能。

@lbbdefy #61 我觉得你说的那些东西可能不叫微服务，叫多服务。
>代码量翻倍的结论从何而来
每一个真正意义上的微服务，有单独数据库，单独配置文件，单独对外接口，单独对内业务实现，微服务为了解耦必定存在大量相似代码且无法消除，再加上微服务生态带来的大量组件与配置，与单体相比平均代码量提升一倍，可能还说少了。
>接口兼容都整不明白
微服务无法实现自给自足，对一个需要功能变更的微服务自身来说，仅修改自身就能完成升级的概率是很低的，它很可能需要一个或多个上游根据它的需求进行升级，而下游可能也需要这个功能，一升一大串是比较常见的场景。

@iyaozhen #51 有些不用分，走错路的无法回头。
以我的观点，大概只有 1-2% 的项目有资格上微服务并确实享受益处。
这些项目要满足：
1. 能接受微服务带来的性能损耗和请求延时
2. 能以正确的方式理清业务优雅地拆分服务
3. 大量跨部门/跨公司的成员，存在较高的沟通成本+管理成本
4. 需要 5 个 9 甚至更高的可用性

@zhengfan2016 我们正在运行的单体项目，总代码量好像是 20w 行，最长的一个接口总实现不会超过 600 行，每个接口平均保持在 200 行，比较复杂的 excel/pdf/图像处理等逻辑不算在内。我不知道你是如何看待单体项目的，外观上它长得跟微服务差不多，微服务怎么拆分，单体也怎么拆分，只是无法更细致的定义对内对外与解耦。

@HolmLoh #45
>小而自治的团队
有多小，少于 20 人我认为是在搞笑，20-50 人勉强能上。
微服务解耦的同时，也引入了对内对外的概念增加复杂度，如果一个人/团队长期在负责的业务上堆砌业务实现，这是合理的。对于小团队来说，这是不合理的，开发者可能要跨越多个自己打造的业务壁垒，属于内耗。
单体也能解耦，只是没法解得像微服务那么彻底。

@kdd0063 #47 牛头不对马嘴，我已经提前排除掉了 1%，还是堵不上你们这些 5 个 9 的嘴

@misaka19000 #48 一个技术为何会诞生当然有必要的理由。
微服务可以让一个模块的相关开发者只需专注自己的业务，无需关心上下游的业务逻辑，这就叫解耦。
而现实是大量使用微服务的公司开始缩减人员，无法维持相关的人负责相关业务，必须相关的人负责不相关的业务，原本解耦的逻辑又得花费两倍的努力重新理解。
微服务是一项技术，但不是必须的技术，否则无法解释 StackOverflo 为什么在微服务盛行的年代一直是单体架构，团队只要选择适合自己的技术就行。

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

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

@nunterr 微服务是买不了的。大厂卖的不是微服务，而是成熟的各种云产品，他们能组成、补充微服务架构。这些产品用在单体上也一样。

@joshuacavell #26 因为 AI 编程确实影响了架构选型。这点还是让时间来验证吧。

@cccssss #19 没经历过。但是公司目前已经定下来了，已有的微服务不管，后续全部单体。如果业务扩张快，今年年底可能就是接近百人开发同一个项目。

@xuanbg 夸张说法，虽然业务中确实发现过一个请求弹了 12 次，但不管弹几次，就是无法实现单体的一次，内网延迟是真实存在的，响应速度就是比单体慢。微服务只是在一些场景是好的，完全先进过于绝对，至少性能损耗我个人不认。

@artiga033 1. 我想表达的是，最核心的模块挂了，那其余模块基本也算不可用，哪怕其余模块还是能正常 curd ，开发人员挨的喷不会少。恢复核心业务，无论是微服务还是单体，难度和流程都是一样的。
2. 我想表达的是，它无法带来预想中的简单与快捷。
我承认好处确实是有的。

3. 如果 Agent 能做到模拟开发者，那确实维护 100 个微服务更好。

4. 当下形式很明显，大量裁员与失业，除了少量扩张中的业务，基本都在收缩人员。数十人维护相同体量的微服务很困难，换成单体服务却非常轻松。

我觉得有点应该是共识，单体 monorepo 的维护难度和工作量比相同体量的微服务少很多。

@xuanbg 你说得对，就算一个请求在微服务里弹十几次，它依然是先进的，哈哈。

@darkengine 微服务会流行是因为大厂无法管理疯狂扩张的团队，而现在已经不需要管理了，一人顶两人甚至三人，单体完全能 hold 住。当然有需要的可以继续上。