我感觉我们这里实践的微服务是几十个巨无霸几千上万核的大单体，加上几百个微服务

@junkk 说明你们的业务不正交. 意思就是每一块业务都是有明确清晰的业务边界的. 不互相影响. 但是这在一些品类的系统中显然是天方夜谭. 业务之间的互相影响如蜘蛛网一般复杂.

@joshuacavell #26 因为 AI 编程确实影响了架构选型。这点还是让时间来验证吧。

应该是单仓库 monorepo + 多服务部署才是最优解

@root71370 有的，我上家做跨境电商的，整个项目共用了 Java 、Python 、Go 3 种编程语言，用 GRPC 和 Kafka 进行服务间的通信，一共 80 多个微服务模块，包括订单、商品、支付、会员、营销、短链、推送、对账、风控、规则引擎、网关、认证授权、实时流计算、BI 可视化..... 开发人员就超过了 100 人。

OP 为啥不让公司花点小钱买个大厂的服务呢，这样既能使用微服务，也不用操心维护，而且微服务的优点也能最大化

"单体无法单独伸缩其中一个服务，只能全部一起水平扩容，这是确实存在的缺点，但 99%的项目并不需要该特性，基础建设很贵，机器很便宜。" 这为啥会是缺点 ? 一个函数你不调用它, 会额外消耗 cpu, 内存, IO ? 像是 db 连接, 可以设置 `maxIdleTime`

搞软件工程不是做二极管，即使被微服务伤害过，也不该投鼠忌器。平衡一下嘛，为什么要在纯单体和纯微服务之间做选择题呢？

@nunterr 微服务是买不了的。大厂卖的不是微服务，而是成熟的各种云产品，他们能组成、补充微服务架构。这些产品用在单体上也一样。

@junkk #24 经典一蹴而就的微服务单体架构，小厂 maven 分几个模块撸出来就行了，我以前也进去一家小厂差不多一个鸟样，面对的难题是基础设施不完善，没有时间和精力去梳理业务边界，而带来的好处对小厂来讲根本没有任何意义。 在活下来才是最大的难题之下，不如多花心思把产品快速稳定上线