2024 年了, 有多少公司和系统由微服务/云原生转为了单体架构?

[lujiaxing]

最近看脉脉里有不少开发在讲自己所在企业的一些系统已经开始由微服务/云原生架构转为或者正在逐渐转为传统的单体架构. 原来的 DevOps 要么被优化要么转一线开发回去写 CURD 了. 问下诸位这种情况目前是否普遍? 未来还会不会有可能再大规模回归微服务架构?

[adoal]

@coderxy 可能是上回换上台的领导，这回被换走了，就像 Uber 从 MySQL 到 PG 再从 PG 到 MySQL 那样

[lujiaosama]

java 的微服务多了吃内存, 有点遭不住. 再加上 K8S 的成本是真的高.

[zjuster]

@undefine2020 大厂散播出去的技术毒瘤。 他们只会从大厂里照搬技术方案，不考虑业务的

[xiangyuecn]

人家的微服务很牛逼，自己的微服务伸缩性还不如单体😂

[disorientatefree]

云计算大厂的非云计算业务员工：

上一个组：试过没转成，根本不现实，未来不打算再试了
现在组同事：什么？我以为云是给外面的客户用的，我们内部也能用吗？？？

[xiangyuecn]

去年有个项目砍掉 java 微服务的 docker 部署方案，以前每次更新一个微服务就得几百兆的打包上传服务器部署，砍掉后每次部署只需上传 1MB 不到的 jar 包（依赖的 jar 不需要上传），部署时间从十几分钟缩短到 1 分钟😂

十几个微服务内存占用从 20G 缩小到 5G😅

[mightybruce]

微服务不等于云原生， 微服务本身拆分和规划本身就不只是技术，还是团队管理问题。国内不少公司还停留在管理不善的问题阶段。

多数人对 devops 并不理解吧，k8s 就是单体部署也没有什么问题。 国内和国外所了解的都不是一回事

国外是谷歌新出的论文"towards modern development of cloud application"和 service weaver 对 微服务 发出新的构想。

文章认为，微服务将逻辑边界（如何编写代码）与 物理边界（如何部署代码）混为一谈。提出的方案是将应用程序构建为逻辑整体， 但将其交给自动化运行时， 后者根据应用程序所需内容和可用内容来决定在哪里运行工作负载。

[SoyaDokio]

@HTDit #10 感觉有道理，但迁回不是简单的迁就可以的，还需要重构不是吗？

[roundgis]

stackoverflow 九台服務器就可以支撐月訪問量 20 億

大部分的應用都沒有這個規模

上微服務都是自找麻煩。

netflix 用那是因爲它需要，很多人那是簡歷需要微服務吧

[summerLast]

@me1onsoda 都是工作量啊，业务不行，还不能整活？

[bthulu]

@mightybruce 别说的这么高大上. 我就问你, 你楼上的那个, docker 部署, jar 包从几百 M 缩减到 1M, 你拿什么来打? 内存从 20G 缩减为 5G, 你又咋说? 你说的天花乱坠, 省时间省成本了吗?

[mightybruce]

@bthulu 你自己不去看看 java 的新题案和 解决策略比如 graalvm ， 你机器上没有 jvm 可以跑 java ， 是吧。
jvm 设计之初就是为了充分利用服务器内存，甚至是多占用一些内存 来做 gc 。

要对比 docker 那也是对比虚拟机像 kvm 、vmware 的方案。
你什么都不懂就开始胡乱 at 人吧。

[bthulu]

@mightybruce 我就问一句, 你楼上是不是省时间省成本了?

[mightybruce]

@bthulu 先学会点礼貌先，没一点礼貌，我也不想回复你的任何问题

[lujiaxing]

@brom111 这就是上面很多人都说的... 好多团队跟项目就不适合搞微服务... 有些程序员为了简历好看硬上的而已.

[jimrok]

现在的业务应该能看到有扩展势头的都会看得到吧，看不到扩展希望的，还折腾什么微服务，直接合并到单体服务了。每年服务器能剩不少钱吧？

[mongodb]

其实这个世界上不是只有微服务和单体两种模式的……
很多公司，包括我个人的项目其实往往是若干个小服务，数量可控，好管理，又能取到尽可能多的优点……

[5sheep]

实事求是才是做事情的根本
以前我负责一个项目验收，就有个技术专家怼，这不是微服务，不行巴拉巴拉的。
结果这个项目单体跑了好多年了，运维成本超低，给各方都省老鼻子钱了。
再看看那些上微服务的同行，呵呵，公司小点的倒闭、公司大点的砍业务线。

存量竞争时期，大多数中小公司，单体一定会卷死微服务

[fregie]

我倒觉得没什么问题,只是在不同场景下作出不同的选择
微服务云原生这一套是为了适应大规模快速开发,业务快速增长而出现的
如果业务无法继续增长,意味着开发速度和人力都要大幅减少,这种情况则不再需要微服务这些的核心特性,所以转型也是合理的

[xuanbg]

单体和微服务的成本差异微乎其微啊，说微服务成本高的，真的做过微服务么？