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

分久必合合久必分 我说一个我们的场景，比如 a -> b -> c | b -> d. 实际流量 b -> c 占了 80%（这很常见），这样耗时优化大头都在这里了，即使是内网，b 到 c 涉及 rpc 的协议编码（耗 cpu ）、服务发现、网络传输等 如果能把 b 和 c 部署在一起，在延迟和资源利用率上都有不少的收益。但不是简单的 sidecar 部署方式

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

不懂，只是看了一下线上 600 多个部署，想象不出来做成单体的样子

我的暴论：微服务是云厂商为了多卖机器搞火的，现在降本是主流，可以关注下 Koupleless 或者类似的加购

你这个言论，和上次某个 RoR 鼓吹者说开发可以回归单体服务一样，以为语言或者 AI 带来的加持能解决复杂度问题 然而并不是： 微服务带来的是，*物理*解耦依赖关系，按照现实组织拓扑进行划分服务 换句话说，每个服务有各自的资源，每个资源都有各自的 owner 把所有服务放到一起，最终各种飞线依赖，资源相互引用 @monkeyWie 正解！梳理好依赖关系的同时，按照单体服务开发，同时发布单独服务

微服务下也挺适合 ai 的，单个服务若抽象后的隔离性够好。

哈哈哈 我目前小作坊 op 说的这些情况基本都有 而且开发人员少 一个人还得开发多个服务 并且还是敏捷式开发那一套 说实话 没感觉到微服务的便捷 反而开发上很累 基本就是被压榨 一个 RPC 崩了的话 跟这个 RPC 关联的接口确实会全崩

@Ketteiron #50 单体服务理解别人的业务也需要时间 而且 so 这种写少读多且业务相对简单的系统没有什么可参考性

@aheadlead #30 几百个微服务，你们的人员归属怎么划分的