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

天下系统，合久必分，分久必合。

实在无法理解什么公司会去做这种逆向操作， 难道是为了省资源？ 花这种代价去重构微服务为单体，感觉没啥收益啊。

单体可横向扩展，后面数据库搞集群。

就是为了节省成本，省资源，省开发，单体又不是不能用，只要业务不崩，老板才不管你用什么技术

说白了就是减机器减配置，需求高了再加就是

说是减少运维成本和人力成本...

话说，大部分 ToG,ToB 甚至 ToC 的业务，有多少大到需要微服务？

微服务成本多高，做过的都知道吧，量不大的情况下，单体就是成本最低的。

对于大部分公司来说，微服务都只是噱头吧

稳定业务可以迁回啊，微服务和 cicd 这些就是为了快速迭代服务的，稳定了不需要迭代就可以迁回并降低运维成本和运维难度。

重构难道不用成本吗？

都是为了成本。现在是云原生，云原生虽然和你微服务不冲突，但是你微服务一个服务要 2c4g ，你两个微服务合一也只要 2c4g ，成本是不是就缩了。以前是为了扩展把服务拆散，现在就是为了钱把服务聚回来，核心服务当然还是不会去大动。

单体应用，一样能云原生能 devops 能 cicd 能不停服务部署几个人的团队整一大堆微服务纯属没事找事

不用重构吧，服务都跑一台机器上，业务稳定了，两个服务组，裁成一个组，慢慢重构呗

我看微服务在中国的火热只是大部分中年技术主管在 KPI 焦虑之下导致的

重构的成本和风险也挺大的，当然，也取决于你们现有业务的复杂度。

只要满足业务的情况下，单体节省成本啊，别说机器省了；就是人力，单体 crud 是个开发都能干吧，这不也省了一大块

就重构花费的成本和风险，足以让多数人望而却步了

依我看，上微服务是错第一回，迁回单体是智昏，错第二回。。省机器？要么是扯淡，要么原来机器都在闲置空跑，都挺离谱的。微服务云原生说好的弹性伸缩呢？

个人感觉绝大多数公司，业务模式完全没有到需要上微服务的程度。

想起以前待过一家公司，微服务写的好恶心，对某些 leader 来说，自己技术不行那就上微服务，堆机器堆人力，明明单机就能 cover 的硬要微服务我在做自己的开源项目，laf-tools.com ，只要你设计合理，stateless 做好了等体量一大再说微服务也是分分钟的事情

很正常，大部分程序员的固有思维是，越复杂越牛逼，这边导致很多技术专家，架构师把一些很简单的事情，想的复杂。但是想想，如果你们公司不是那头部的几个互联网公司，有多少需要那么复杂的技术的？说白了，node ，python 也直撸也能解决市场上 80%以上的服务。剩下的，加点监控，恢复就得了。但后来很多人，特别是他们的老板发现，程序员格局确实很有限。

大多数需求根本就上不到微服务的程度还有很多公司人员流动性是非常大的有的微服务搞得太复杂 交接成本也高

微服务/云原生指 K8s ？单体架构指传统裸机部署？真的会有这种回退操作吗。。表示很怀疑

压力大了怎么办？横向扩展啊。你见过一大堆因为微服务产生的业务锁跟事务脏数据的吗，太爽了

建议读一下串口并口发展历史。

微服务是为了你有一堆人，防止各团队互相冲突的，现在不需要那么多人和业务了

微服务跟性能没什么关系，甚至会降低性能，只要写的服务是无状态的能横向扩展，单体项目也能通过加机器应对很大的流量。微服务其实是解决多人协作的解耦问题，以及缩小发版时变更影响范围。对于一些团队就几个十个人的来说，上个🔨的微服务。

和大环境有很大关系，公司没钱搞这些了。

没微服务的概念之前就不发展了吗？

业务稳定，重构本来就不是必须的，只是没有新的需求和功能，不能让开发天天摸鱼而已

说白了就是业务规模与预期相差甚远，收益不佳，需要缩紧预算。成本意识强的公司，在 2023 年就该开始执行这一步。比如一家中小企业有 3-6 个项目运行在 Kubernetes 集群里，就意味着还有 CI/CD 、代码+镜像私仓、O3 之类、CDN 、云 Mysql/Redis 的服务要维护。每个月的云资源成本预计在 3k-8k 以上。其中 Kubernetes 和云 Mysql 的服务可能是最贵的，但只有 Kubernetes 是可以缩减的……总不能动生产数据库吧？把 Kubernetes 砍掉，那么相应的代码私仓、镜像私仓、O3 这些就可以一起干掉，能省个 40% - 60%。想象一下，3k-8k 的 40%-60%如果换成更大规模的 8k-12k 的 40%-60%呢？一年下来又是多少？不过公司把微服务架构和对应的 DevOps 改造、缩减后势必会影响军心，应该拉几个大会，让研发、运营（ devops/sre ）一起加入讨论，让每个人都意识到问题的严重性和必要性。

＃28 现在很多都是众包的项目，Final 的甲方提出的运营 Request 可能就是要求微服务，方便扩展和运维管理之便。虽然拿到项目的每个乙方都只负责一小点儿，投入的人数也就是个位数。

前几年微服务弄的太火了，一堆菜鸡为了刷简历把项目改造成微服务，结果水平不够微服务不像微服务，单体不像单体。线上问题一堆。

立场不同，不必说谁格局小。程序员的立场：给自己简历造料，提高身价或者不可替代性又或者是 kpi 。都是身在江湖身不由己。中层管理把公司当自己家，员工调个休都要问清楚干什么去，格局大吗？

这是因为很多人放大了宕机带来的影响，就算是阿里这样的公司宕机几个小时也无所谓，事实上对与一家商业公司别说是宕机几个小时，就算是这家公司没了，对整个市场也没啥影响，很多人是杞人忧天，害怕自己的 KIP 罢了。

问了一个前同事 (现项目经理), 人家的原话是说:"缩减服务器成本只是一部分目的. 更重要的是缩减人力成本... 原本微服务开发虽然可伸缩了灵活了但是开发团队却过于臃肿. 一个不算很复杂的项目, 开发团队却有几十号人. 其中还有好几个负责专门维护 CI/CD, K8S 的人... 改成单体之后, 一堆微服务聚合成一个服务, 原本的 K8S 不再需要可以直接停, CI/CD 可以改手动. 等全部改完之后, 原本的那几个 DevOps 可以裁掉了, 开发团队可以裁一半. 原来的运维任务, 技术经理负责就行了"听完感觉一阵恶寒

devops 和微服务有啥必然联系吗？单体应用一样可以做 cicd 。

＃37 个人感觉，几十人的团队本来也不需要几个专门负责 ci/cd k8s 的人啊。 本质上还是业务不够复杂，本来也不需要这么多人。这不算是问题吧

改了一个公司内部应用，微服务转单体，生产环境 3 台物理机降到 1 台。一个月省了几百刀，给涨了点工资。

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

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

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

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

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

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

微服务不等于云原生， 微服务本身拆分和规划本身就不只是技术，还是团队管理问题。国内不少公司还停留在管理不善的问题阶段。多数人对 devops 并不理解吧，k8s 就是单体部署也没有什么问题。 国内和国外所了解的都不是一回事国外是谷歌新出的论文"towards modern development of cloud application"和 service weaver 对 微服务 发出新的构想。文章认为，微服务将逻辑边界（如何编写代码）与 物理边界（如何部署代码）混为一谈。提出的方案是将应用程序构建为逻辑整体， 但将其交给自动化运行时， 后者根据应用程序所需内容和可用内容来决定在哪里运行工作负载。

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

stackoverflow 九台服務器就可以支撐月訪問量 20 億大部分的應用都沒有這個規模上微服務都是自找麻煩。netflix 用那是因爲它需要，很多人那是簡歷需要微服務吧

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

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

你自己不去看看 java 的新题案和 解决策略比如 graalvm ， 你机器上没有 jvm 可以跑 java ， 是吧。jvm 设计之初就是为了充分利用服务器内存，甚至是多占用一些内存 来做 gc 。要对比 docker 那也是对比虚拟机像 kvm 、vmware 的方案。你什么都不懂就开始胡乱 at 人吧。

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

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

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

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

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

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

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

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

之前面试过一个做国企项目的哥们，上面给他在小型机上分了 200G 内存，他在上面部署了一个 SpringCloud 。看不懂，大受震撼

大伙儿都痛恨强上微服务，但是架不住简历需要啊；小公司有领导带着体验微服务就烧香拜佛吧。

过度微服务只会让事情更复杂, 这个确实没错. 当然也不是追求必须单体.服务的拆分要看业务架构和组织架构, 一群人维护一个也痛苦.但是容器化显然是有好处的.. 之前容器化后, 反而系统的合并,拆分调整变得容易了..

微服务也不是一无是处，好像很多情况下是需要微服务的。某些 ToC 的功能需要快速迭代，但是还有一些 toB 的功能白天不能停机。这种情况下微服务就不必考虑部署时间了

反正作为运维，每个新项目我都要怼一次后端开发 leader：不许给我搞微服务，你就单体。单体也需要运维，都让研发搞就是逗闷子的。只是真不需要一堆运维了，我一直认为国内公司，90%有且只需要两个运维。搞微服务？那就看架构吹牛逼吹多大了。我怼得最多的一句：高并发？你自己试过本地 mysql 1000 万数据集两到三层良好索引的 sql 效率吗？没有？没有你扯犊子的因为性能横向扩展？

单体也能 CI/CD ，我现在就是。搞什么微服务，目前的业务体量根本用不上。一旦用上微服务的各种中间件，内存占用就上去了。而且还增加我的心智负担。单体应用也能扩展，只要做成无状态的就好了。东西都放在 redis 里面。docker 多开几个实例我就是一个集群

啊？看的都懵了。不拆服务有个严重的问题是一个业务有问题影响全局啊，比如登录出 bug cpu 爆了结果所有业务都挂了。

＃46 请问“依赖的 jar 不需要上传”是什么样的部署方案？

＃46service weaver 不错，我在公司内部设计的混合型服务就跟它差不多。最终写出来的服务可单体可微服务可混合。

业务体量不大的话，其实用上微服务完全就是徒增工作量；当然，在中国毕竟要面向面试编程……

参考最近的 阿里崩，拆分成微服务并不能避免 业务挂的问题如果 商场项目，购物车服务挂了，能说业务没挂吗？如果是优惠券服务挂了，能说业务正常吗？

有的时候其实不是微服务和单体的事，而是你的项目的性能和资源消耗的问题。举个例子：有的微服务项目，一个实例启动需要 2 核 4G 甚至 4 核 8G~16G ，但是能承载的并发只有 100 甚至 50 ；有的微服务项目，一个实例启动需要 2 核 4G 甚至 1 核 0.5G ，但是能承载的并发有 500~2000 ；一年下来的开销差异可不少，真的别吹内存不值钱了，在云服务上就是真的贵。反正我是见过一年 2000w 云服务支出，一小半支出在云服务商的数据库上，另外大部分的钱都是 ECS ，cpu 大量空闲时间但是内存水位常年 75%以上占用的，是什么语言为主大家都懂的，钱都花在刀把上了，现在就在那里开猿节流、降本增笑。

还没学上应用上，就开始淘汰了

＃47 从头条的翻译水文看的吧？但凡你看过 Google 的论文，你就知道这只是某个员工，水 KPI 的手段罢了，实际上就是抄 Akka 的 ClusterSharding ，然后加了点自己的东西

应该是 cloud native 和传统部署的差异，写代码其实差异真没那么大。cloud native 需要 k8s ，镜像库，cicd ，统一可观测性，这些东西的开销比较大。例如日志，砍掉 loki ，splunk ，用人工一个一个服务去翻日志的报错，哪个成本高？一个人力一个资源，trade off 罢了，现在企业，人便宜，资源即使用不上，一直开着也费钱

话说上家公司是把微服务改了单体，那个微服务设计的四不像，所有服务公用一个数据库，里面几百张表，各个微服务都能读所有表，其实就是个分布式单体，乱的可怕。

登录这种核心业务拆成微服务挂了也影响的，调提可以弄些自动重启，监控，先上线一部分机器等措施避免

你确定这个不是因为你分层不合理导致每次都全量下载？ docker 镜像是分层的，如果只是最后一层 jar 变更的话，每次更新也只会重新下载最新的一层。和你传一个 jar 的大小是差不多的呀。

见过一种架构，后端操作整合成一个服务，对外只暴露 dubbo 接口，对外有另一个服务负责把这些 dubbo 接口包装成 http 接口。对内其他组的程序则直接调用 dubbo 接口。不知道有啥好处

没错，你说的就是我们公司。 不过现在在用 go 重构搞轻量化。我们这个还是涉及到给客户私有化部署， 人家客户说你们这玩意儿光启动就得 128G ？

好多微服务连性能测量都没做，所以没办法伸缩机器空跑另一个原因可能是资源池并没有提供那么多容量，所以即使不用也先占上 单体应用不提方便做集成测试

大厂都大规模宕机多少次了。。

幸存者偏差吧，你只看到了大规模宕机，很多微服务挂掉处理好没影响全局这个我们不知道。

是的，报价里附带的服务器配置清单和参考价格，分分钟比系统还贵，直接劝退不少客户。

＃68 ＃78 没办法 烂摊子 水平也低，所有依赖都打包进的一个 jar 再打包 docker 镜像，确实是分层的问题；后面调整的时候干脆去掉了 docker ，只需打包 jar 再上传 重新运行这个 jar ，少了不少步骤，依赖的 jar 没有变化就不需要上传 回到了最原始做法 比较省心😂

有道理.中小公司和中小规模的业务还是多数.做好分布式 ID,分布式锁,分布式事务,把定时任务抽出来. 单体一样能部署多实例一样能打.

同一个服务也可以按功能给不同的实例的

Java8/11+Spring 就不是云原生 Ready 的。明知山有虎，偏向虎山行的结果就是资源浪费，说到底这些技术栈就不应该搞所谓“微服务”和去容器化。而且现在业务不扩张了，老板也不需要那些花里胡哨的 DevOps 来降低业务横向扩展成本。运维被开了拿 n+1 笑着找下家，原来的开发也回到了舒适区，老板也节省了成本，怎么感觉是三赢？

换回单体，50%的开发被开了，开猿节流

再招聘几个应届 CRUD ，成本嘎嘎降

看到去 DevOps 就知道这根技术无关了，就是「开猿节流，降本增笑」。楼主后面补的话，更证实了这一点。

一听就是狗家