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

我们组，3 个后端。一个项目需要一次需要部署 20 个微服务，其中一部分是功能，一部分是业务，一部分是基础服务。有的 java 写的，有的 python 写的，有 go 写的，我觉得挺好。做的都是本地部署的活，到一个地方使用 K8S 写好的脚本一键部署，不需要修改的服务稳定运行几年都不需要动它，只需要修改常用的几个服务。 而且不存在人员不解耦，我就没看过其他人写的工程，并不影响开发我的服务功能，多人之间对话只有"接口"。 "服务升级很难只升级一个"，那说明你们架构师水平不行，接口兼容都整不明白。 "微服务有成本，首先代码量就先翻个倍", 代码量翻倍的结论从何而来？公共组件放 maven ，没有遇到过很多重复代码的问题，而且现在跨进程的框架越来越多，多服务开发和单服务开发体验本身就相差越来越小了。多服务开发甚至还有跨语言优势。 "微服务尝试解决什么问题？ 保障多个 p0 服务不会一崩全崩。然而实际上大多数微服务就是一崩全崩。" 保障业务持续运行不是高可用范畴该考虑的吗，这是微服务要解决的问题？退一万步说，确实有很多微服务一崩全崩，那不也有很多微服务崩了并不影响其他服务的时候？单服务崩了那才是百分百一崩全崩。 多服务和单服务从来不是二极管，也不是因团队大小决定。根据合适的场景选择合适的技术才是正解。

我觉得恰恰相反, 各种模块化, 各种碎片化我觉得, AI 自己调用各种纳米服务

需求或者说改变是永恒的，所以要想办法降低改变带来的影响，也就是做拆分。避免来一个需求，要梳理一整套代码来决定应该改哪，避免改一行代码要把整个系统测一遍，把整个系统重新部署，避免某一个接口的流量变化要把整个系统扩容。另外一个点就是关注分离了。也对应描述中说的服务独立部署和升级，以及一大堆开发人员。 具体怎么拆呢。一个系统里面，有些部分是频繁变化的，有些是很少变化的，有些部分经常会因为同一个原因（同一类需求）而一起变，而有些则不是。因此需要将经常因同一个原因变化的放到一起，从小往大讲就是放成一个函数，一个类，一个模块，一个微服务，或者一个业务域。这样一来，经常变的模块就自己升级自己测试，不会影响到不变的部分。 依赖关系上也是一样，首先要单向依赖，其次是经常变化的模块，要依赖不怎么变的部分，来降低变化带来的影响。 微服务其实就是服务级别的拆分，开发、测试、运维、维护会分得较为彻底。当然实际上还是要遵守上面的原则，如果拆分得不合理或者依赖关系不合理，影响面并没有减少，来一个需求还是要改一大堆服务梳理一大堆东西，那就是另一回事了

想多了，单体服务再配合 ai ，一个代码文件几千甚至几万行你 review 的过来，肯定是拆细好维护，就算 ai 再怎么乱改影响范围也是局限那一个微服务

@wuling 其实现在很多所谓的微服务, 如果深究都不能算微服务. 最多算分布式架构. 微服务得是拆的非常细的才叫微服务.

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

@Ketteiron 我的体会是因为选择了微服务这条路，才会出现小团队，小团队是果。

@Ketteiron #66 那你们公司对代码质量的把控还可以。我司代码基本上几千行是常态，python 一个 class 无所不包。还是领导用 ai 一键生成的，生成完就丢给底下安卓人在这个基础上接着拉，上面都完全不管代码质量了，同事大部分也是能用 ai 糊弄就用 ai 。我是觉得这种代码质量低的项目，还搞单体，更难维护，起码拆出去代码可读性的下限会高一些 https://i.imgur.com/agAJ0Rd.png

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