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

@Ketteiron “一个请求在微服务里弹十几次”。你这个是设计问题，你是怎么就敢把锅扣在模式的头上的？？？

1. 服务独立伸缩 2. 服务独立升级 3. 管理大量开发人员 三筛选条件一加，98%的软件项目就被过滤掉了

我的体会和楼主一样，我是小公司。。。

如果微服务往单体收敛，云原生的需求会减少，另外对资源的占用是不是就相对不那么突出。成熟的后台类库和框架会重新成为技术选型的主要因素。进而导致 Spring Boot 赢麻了。完美

@artiga033 1. 我想表达的是，最核心的模块挂了，那其余模块基本也算不可用，哪怕其余模块还是能正常 curd ，开发人员挨的喷不会少。恢复核心业务，无论是微服务还是单体，难度和流程都是一样的。 2. 我想表达的是，它无法带来预想中的简单与快捷。 我承认好处确实是有的。 3. 如果 Agent 能做到模拟开发者，那确实维护 100 个微服务更好。 4. 当下形式很明显，大量裁员与失业，除了少量扩张中的业务，基本都在收缩人员。数十人维护相同体量的微服务很困难，换成单体服务却非常轻松。 我觉得有点应该是共识，单体 monorepo 的维护难度和工作量比相同体量的微服务少很多。

历史到不会后退，但小团队和微服务确实没什么关系了，除了一丝丝的解耦，其他所有工作都是随项目数量成倍增加的

组织架构决定系统架构

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

一个单体项目 99 个人维护，你确定你经历过？ AI 盛行，一个 99 个人维护的单体项目代码量多大，部署一次要多久有概念么