@wph95 #19 金融支付平台一般都是 5 个 9 ，但遇到故障家常便饭。

@testcgd #87 单体确实相对更考验素质，更考验 review 。我们几乎不会直接使用 ai 生成的代码，它只是个提效工具，开发人员提交 pr 之间必须完全理解逻辑。借助 ai 可以生成一大堆废话直接提交，也可以严肃且优雅地组织代码，这取决于人，不取决于 ai ，它仅仅是个工具。
说到测试，我们的单元测试很少，更偏向基于 playwright 的 e2e 测试。当然如果写 java 大量单元测试还是必不可少的。

@Kirkcong #86
>上面也有人和你说过各种微服务的好处，以及各种现实的例子
我写了 5 年微服务，我确实明白微服务的好处
>从这个观点提出来到现在已经很多年了
时代在变，人也在变
>大家都知道当前 ai 代码的质量有多差
我不知道，可能是那些人没办法定制 MCP ，没制定良好的 rules
>有这吹毛求疵的时间不如去招点和你一样吹毛求疵的人
实际上公司就是这么做的
>大厂中厂不会出现人不够用的情况的
你的公司太好了，我们正在经历的裁员、砍 HC 肯定是假新闻
>好的算法确实会让时间复杂度下降
时间复杂度是用空间复杂度换来的，计算机理论决定了复杂度不会凭空消失

笑麻了
但这本质上不是外包的问题，是请了外包以及没做好验收的问题

1. 有
2. 确实有用
3. 编得太离谱
4. 一定程度上是的
5. 不知道

其实这些都是细枝末节，代码写得好，100%。
在追求锦上添花的东西之前，先把简单的代码写好，就像 v2 的“好好说话”那样，程序员要做的仅仅是"好好写代码"，这就够了。
我说个实际情况，提供 5 个 9 服务的云厂商，自己的业务达不到 5 个 9 。

@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 为什么在微服务盛行的年代一直是单体架构，团队只要选择适合自己的技术就行。