@Kirkcong #80 人不够用是很现实的问题，要么放弃，要么解决这个问题，这是绝大部分大中小厂在今天都会遇到的问题。公司内部探讨了很久，最终决定是将目前主要业务以单体形式编写，预估代码量超过 50 万行，随着业务扩张不知道最终会膨胀到多少，这个决定在我入职前就已定下来。面试时与面试官探讨了单体架构细节实现、预演各种场景，最终我选择加入并成为主要负责人之一。
我是个吹毛求疵的人，而目前运行中并且不断迭代的项目我很满意其整体质量。

还是那句话，复杂度不会消失，只会转移，最终还是要整个团队完美地处理好一切细节。
如果一个团队能处理好微服务产生的各种问题，那么同样不会在单体中出现上述任何问题。反之在单体中出现上述问题，那么在微服务也好不到哪去，最终只会转移变成另一个问题。
微服务有好处，也有坏处，而现实是我们无法承受其坏处。

@gl3081 #78 微服务有传染性，单体有排他性。兼容时期一般存在于单体架构慢慢演变为微服务架构，八股文称之为渐进式重构，最后会彻底变成微服务。

AGI 时代，人类劳动价值由剥削 AI 劳动价值衡量。
资本主义中，一个劳动者产出 100 元，资本家剥削了 60 元，劳动者获得 40 元，劳动者最终获得的金钱与被剥削价值大多数情况下是线性关系。
AGI 时代，一个劳动者通过剥削 AI 产出 200 元，AI 成本 70 元，资本家剥削了 90 元，劳动者获得 40 元。如果劳动者能更大程度地剥削 AI ，就能获得更多的回报。而在以前，劳动者可以通过学习各种技能、总结经验达到一样的效果，但在 AGI 时代效率太慢，资本主义会强迫一切事物向着更快获利的方向前进，它会强迫一切劳动者利用 AI 榨取出更多价值。
时代一直在变，但好像有些东西永远不会变，只是这个时代劳动者手里的工具名字叫做 AI 而已。

还有在 github 诈骗的，光是 v2 上的例子就不下 10 个，根本原因是全球经济都在下行

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

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