这是一个创建于 641 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近看脉脉里有不少开发在讲自己所在企业的一些系统已经开始由微服务/云原生架构转为或者正在逐渐转为传统的单体架构. 原来的 DevOps 要么被优化要么转一线开发回去写 CURD 了. 问下诸位这种情况目前是否普遍? 未来还会不会有可能再大规模回归微服务架构?
 | 1 victimsss 2024-01-09 09:56:46 +08:00  3 天下系统，合久必分，分久必合。 |
 | 2 coderxy 2024-01-09 10:00:13 +08:00 实在无法理解什么公司会去做这种逆向操作， 难道是为了省资源？ 花这种代价去重构微服务为单体，感觉没啥收益啊。 |
 | 3 XSDo 2024-01-09 10:03:12 +08:00 单体可横向扩展，后面数据库搞集群。 |
 | 5 Huelse 2024-01-09 10:04:45 +08:00 说白了就是减机减配置，需求高了再加就是 |
 | 7 aw2350 2024-01-09 10:10:48 +08:00 3 话说，大部分 ToG,ToB 甚至 ToC 的业务，有多少大到需要微服务？ |
 | 8 TimLang 2024-01-09 10:14:58 +08:00 4 微服务成本多高，做过的都知道吧，量不大的情况下，单体就是成本最低的。 |
 | 9 QlanQ 2024-01-09 10:15:26 +08:00 对于大部分公司来说，微服务都只是噱头吧 |
 | 10 HTDit 2024-01-09 10:15:32 +08:00 via Android 9 稳定业务可以迁回啊，微服务和 cicd 这些就是为了快速迭代服务的，稳定了不需要迭代就可以迁回并降低运维成本和运维难度。 |
 | 12 Seulgi 2024-01-09 10:19:38 +08:00 都是为了成本。现在是云原生，云原生虽然和你微服务不冲突，但是你微服务一个服务要 2c4g ，你两个微服务合一也只要 2c4g ，成本是不是就缩了。以前是为了扩展把服务拆散，现在就是为了钱把服务聚回来，核心服务当然还是不会去大动。 |
 | 13 chendy 2024-01-09 10:21:31 +08:00 4 单体应用，一样能云原生能 devops 能 cicd 能不停服务部署 几个人的团队整一大堆微服务纯属没事找事 |
 | 15 undefine2020 2024-01-09 10:29:35 +08:00 12 我看微服务在中国的火热只是大部分中年技术主管在 KPI 焦虑之下导致的 |
 | 17 x7DnVcd9bA706oWp 2024-01-09 10:36:54 +08:00 只要满足业务的情况下，单体节省成本啊，别说机器省了；就是人力，单体 crud 是个开发都能干吧，这不也省了一大块 |
 | 18 lsk569937453 2024-01-09 10:44:27 +08:00 @QlanQ 就重构花费的成本和风险，足以让多数人望而却步了 |
 | 19 me1onsoda 2024-01-09 10:50:01 +08:00 1 依我看，上微服务是错第一回，迁回单体是智昏，错第二回。。 省机器？要么是扯淡，要么原来机器都在闲置空跑，都挺离谱的。微服务云原生说好的弹性伸缩呢？ |
 | 20 Worldispow 2024-01-09 10:50:26 +08:00 个人感觉绝大多数公司，业务模式完全没有到需要上微服务的程度。 |
 | 21 lstz 2024-01-09 11:01:35 +08:00 via iPhone 1 想起以前待过一家公司，微服务写的好恶心，对某些 leader 来说，自己技术不行那就上微服务，堆机器堆人力，明明单机就能 cover 的硬要微服务 我在做自己的开源项目，laf-tools.com ，只要你设计合理，stateless 做好了等体量一大再说微服务也是分分钟的事情 |
 | 22 bianhui 2024-01-09 11:04:05 +08:00 2 很正常，大部分程序员的固有思维是，越复杂越牛逼，这边导致很多技术专家，架构师把一些很简单的事情，想的复杂。但是想想，如果你们公司不是那头部的几个互联网公司，有多少需要那么复杂的技术的？说白了，node ，python 也直撸也能解决市场上 80%以上的服务。剩下的，加点监控，恢复就得了。但后来很多人，特别是他们的老板发现，程序员格局确实很有限。 |
 | 23 heliotrope 2024-01-09 11:04:12 +08:00 大多数需求根本就上不到微服务的程度 还有很多公司人员流动性是非常大的 有的微服务搞得太复杂 交接成本也高 |
 | 24 rebelsre 2024-01-09 11:05:38 +08:00 微服务/云原生指 K8s ？单体架构指传统裸机部署？真的会有这种回退操作吗。。表示很怀疑 |
 | 25 siweipancc 2024-01-09 11:09:46 +08:00 via iPhone 压力大了怎么办？横向扩展啊。 你见过一大堆因为微服务产生的业务锁跟事务脏数据的吗，太爽了 |
 | 26 tomczhen 2024-01-09 11:12:23 +08:00 via Android 建议读一下串口并口发展历史。 |
 | 27 vjnjc 2024-01-09 11:13:31 +08:00 微服务是为了你有一堆人，防止各团队互相冲突的，现在不需要那么多人和业务了 |
 | 28 Gress 2024-01-09 11:17:06 +08:00 2 微服务跟性能没什么关系，甚至会降低性能，只要写的服务是无状态的能横向扩展，单体项目也能通过加机器应对很大的流量。微服务其实是解决多人协作的解耦问题，以及缩小发版时变更影响范围。对于一些团队就几个十个人的来说，上个的微服务。 |
 | 30 RightHand 2024-01-09 11:26:07 +08:00 via Android 没微服务的概念之前就不发展了吗？ |
| 31 QlanQ 2024-01-09 11:35:51 +08:00 1 @lsk569937453 业务稳定，重构本来就不是必须的，只是没有新的需求和功能，不能让开发天天摸鱼而已 |
 | 32 konakona 2024-01-09 11:40:27 +08:00 1 说白了就是业务规模与预期相差甚远，收益不佳，需要缩紧预算。 成本意识强的公司，在 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 ）一起加入讨论，让每个人都意识到问题的严重性和必要性。 |
| 33 konakona 2024-01-09 11:42:11 +08:00 @Gress #28 现在很多都是众包的项目，Final 的甲方提出的运营 Request 可能就是要求微服务，方便扩展和运维管理之便。虽然拿到项目的每个乙方都只负责一小点儿，投入的人数也就是个位数。 |
 | 34 fkdog 2024-01-09 11:42:56 +08:00 5 前几年微服务弄的太火了，一堆菜鸡为了刷简历把项目改造成微服务，结果水平不够微服务不像微服务，单体不像单体。线上问题一堆。 |
| 35 me1onsoda 2024-01-09 11:46:54 +08:00 1 @bianhui 立场不同，不必说谁格局小。程序员的立场：给自己简历造料，提高身价或者不可替代性又或者是 kpi 。都是身在江湖身不由己。中层管理把公司当自己家，员工调个休都要问清楚干什么去，格局大吗？ |
 | 36 pengtdyd 2024-01-09 11:51:42 +08:00 1 这是因为很多人放大了宕机带来的影响，就算是阿里这样的公司宕机几个小时也无所谓，事实上对与一家商业公司别说是宕机几个小时，就算是这家公司没了，对整个市场也没啥影响，很多人是杞人忧天，害怕自己的 KIP 罢了。 |
 | 37 lujiaxing OP 2 @me1onsoda 问了一个前同事 (现项目经理), 人家的原话是说: "缩减服务器成本只是一部分目的. 更重要的是缩减人力成本... 原本微服务开发虽然可伸缩了灵活了但是开发团队却过于臃肿. 一个不算很复杂的项目, 开发团队却有几十号人. 其中还有好几个负责专门维护 CI/CD, K8S 的人... 改成单体之后, 一堆微服务聚合成一个服务, 原本的 K8S 不再需要可以直接停, CI/CD 可以改手动. 等全部改完之后, 原本的那几个 DevOps 可以裁掉了, 开发团队可以裁一半. 原来的运维任务, 技术经理负责就行了" 听完感觉一阵恶寒 |
 | 38 cookii 2024-01-09 13:28:32 +08:00 via Android devops 和微服务有啥必然联系吗？单体应用一样可以做 cicd 。 |
 | 39 brom111 2024-01-09 13:35:27 +08:00 @lujiaxing #37 个人感觉，几十人的团队本来也不需要几个专门负责 ci/cd k8s 的人啊。 本质上还是业务不够复杂，本来也不需要这么多人。这不算是问题吧 |
 | 40 liqiqiqi1995 2024-01-09 13:37:03 +08:00 改了一个公司内部应用，微服务转单体，生产环境 3 台物理降到 1 台。一个月省了几百刀，给涨了点工资。 |
 | 41 adoal 2024-01-09 13:49:10 +08:00 @coderxy 可能是上回换上台的领导，这回被换走了，就像 Uber 从 MySQL 到 PG 再从 PG 到 MySQL 那样 |
 | 42 lujiaosama 2024-01-09 14:45:30 +08:00 java 的微服务多了吃内存, 有点遭不住. 再加上 K8S 的成本是真的高. |
 | 43 zjuster 2024-01-09 14:46:34 +08:00 1 @undefine2020 大厂散播出去的技术毒瘤。 他们只会从大厂里照搬技术方案，不考虑业务的 |
 | 44 xiangyuecn 2024-01-09 14:53:45 +08:00 人家的微服务很牛逼，自己的微服务伸缩性还不如单体 |
 | 45 disorientatefree 2024-01-09 15:00:36 +08:00 1 云计算大厂的非云计算业务员工： 上一个组：试过没转成，根本不现实，未来不打算再试了 现在组同事：什么？我以为云是给外面的客户用的，我们内部也能用吗？？？ |
| 46 xiangyuecn 2024-01-09 15:02:02 +08:00 去年有个项目砍掉 java 微服务的 docker 部署方案，以前每次更新一个微服务就得几百兆的打包上传服务器部署，砍掉后每次部署只需上传 1MB 不到的 jar 包（依赖的 jar 不需要上传），部署时间从十几分钟缩短到 1 分钟 十几个微服务内存占用从 20G 缩小到 5G |
 | 47 mightybruce 2024-01-09 15:24:36 +08:00 1 微服务不等于云原生， 微服务本身拆分和规划本身就不只是技术，还是团队管理问题。国内不少公司还停留在管理不善的问题阶段。 多数人对 devops 并不理解吧，k8s 就是单体部署也没有什么问题。 国内和国外所了解的都不是一回事br /> 国外是谷歌新出的论文"towards modern development of cloud application"和 service weaver 对 微服务 发出新的构想。 文章认为，微服务将逻辑边界（如何编写代码）与 物理边界（如何部署代码）混为一谈。提出的方案是将应用程序构建为逻辑整体， 但将其交给自动化运行时， 后者根据应用程序所需内容和可用内容来决定在哪里运行工作负载。 |
 | 49 roundgis 2024-01-09 15:53:46 +08:00 2 stackoverflow 九台服器就可以支月量 20 大部分的用都有模 上微服都是自找麻。 netflix 用那是因它需要，很多人那是需要微服吧 |
 | 50 summerLast 2024-01-09 15:59:23 +08:00 @me1onsoda 都是工作量啊，业务不行，还不能整活？ |
 | 51 bthulu 2024-01-09 16:05:01 +08:00 @mightybruce 别说的这么高大上. 我就问你, 你楼上的那个, docker 部署, jar 包从几百 M 缩减到 1M, 你拿什么来打? 内存从 20G 缩减为 5G, 你又咋说? 你说的天花乱坠, 省时间省成本了吗? |
| 52 mightybruce 2024-01-09 16:09:32 +08:00 @bthulu 你自己不去看看 java 的新题案和 解决策略比如 graalvm ， 你机器上没有 jvm 可以跑 java ， 是吧。 jvm 设计之初就是为了充分利用服务器内存，甚至是多占用一些内存 来做 gc 。 要对比 docker 那也是对比虚拟机像 kvm 、vmware 的方案。 你什么都不懂就开始胡乱 at 人吧。 |
| 53 bthulu 2024-01-09 16:12:38 +08:00 @mightybruce 我就问一句, 你楼上是不是省时间省成本了? |
| 54 mightybruce 2024-01-09 16:14:57 +08:00 @bthulu 先学会点礼貌先，没一点礼貌，我也不想回复的任何问题 |
| 55 lujiaxing OP @brom111 这就是上面很多人都说的... 好多团队跟项目就不适合搞微服务... 有些程序员为了简历好看硬上的而已. |
 | 56 jimrok 2024-01-09 17:16:02 +08:00 现在的业务应该能看到有扩展势头的都会看得到吧，看不到扩展希望的，还折腾什么微服务，直接合并到单体服务了。每年服务器能剩不少钱吧？ |
 | 57 mongodb 2024-01-09 17:18:43 +08:00 其实这个世界上不是只有微服务和单体两种模式的…… 很多公司，包括我个人的项目其实往往是若干个小服务，数量可控，好管理，又能取到尽可能多的优点…… |
 | 58 sivl6p 2024-01-09 17:37:20 +08:00 实事求是才是做事情的根本 以前我负责一个项目验收，就有个技术专家怼，这不是微服务，不行巴拉巴拉的。 结果这个项目单体跑了好多年了，运维成本超低，给各方都省老鼻子钱了。 再看看那些上微服务的同行，呵呵，公司小点的倒闭、公司大点的砍业务线。 存量竞争时期，大多数中小公司，单体一定会卷死微服务 |
 | 59 fregie 2024-01-09 17:46:50 +08:00 我倒觉得没什么问题,只是在不同场景下作出不同的选择 微服务云原生这一套是为了适应大规模快速开发,业务快速增长而出现的 如果业务无法继续增长,意味着开发速度和人力都要大幅减少,这种情况则不再需要微服务这些的核心特性,所以转型也是合理的 |
 | 60 xuanbg 2024-01-09 17:55:05 +08:00 单体和微服务的成本差异微乎其微啊，说微服务成本高的，真的做过微服务么？ |
 | 61 Narcissu5 2024-01-09 18:36:20 +08:00 之前面试过一个做国企项目的哥们，上面给他在小型机上分了 200G 内存，他在上面部署了一个 SpringCloud 。看不懂，大受震撼 |
 | 62 wu00 2024-01-09 18:43:16 +08:00 大伙儿都痛恨强上微服务，但是架不住简历需要啊； 小公司有领导带着体验微服务就烧香拜佛吧。 |
 | 63 veightz 2024-01-09 18:50:18 +08:00 过度微服务只会让事情更复杂, 这个确实没错. 当然也不是追求必须单体. 服务的拆分要看业务架构和组织架构, 一群人维护一个也痛苦. 但是容器化显然是有好处的.. 之前容器化后, 反而系统的合并,拆分调整变得容易了.. |
 | 64 wxw752 2024-01-09 20:27:49 +08:00 微服务也不是一无是处，好像很多情况下是需要微服务的。 某些 ToC 的功能需要快速迭代，但是还有一些 toB 的功能白天不能停机。这种情况下微服务就不必考虑部署时间了 |
 | 65 sampeng 2024-01-09 23:51:21 +08:00 via iPhone 反正作为运维，每个新项目我都要怼一次后端开发 leader：不许给我搞微服务，你就单体。 单体也需要运维，都让研发搞就是逗闷子的。只是真不需要一堆运维了，我一直认为国内公司，90%有且只需要两个运维。搞微服务？那就看架构吹牛逼吹多大了。 我怼得最多的一句：高并发？你自己试过本地 mysql 1000 万数据集两到三层良好索引的 sql 效率吗？没有？没有你扯犊子的因为性能横向扩展？ |
 | 66 twofox 2024-01-10 02:22:11 +08:00 1 单体也能 CI/CD ，我现在就是。 搞什么微服务，目前的业务体量根本用不上。一旦用上微服务的各种中间件，内存占用就上去了。而且还增加我的心智负担。 单体应用也能扩展，只要做成无状态的就好了。东西都放在 redis 里面。docker 多开几个实例我就是一个集群 |
 | 67 gaifanking 2024-01-10 08:47:02 +08:00 啊？看的都懵了。不拆服务有个严重的问题是一个业务有问题影响全局啊，比如登录出 bug cpu 爆了结果所有业务都挂了。 |
 | 68 pkxutao PRO @xiangyuecn #46 请问“依赖的 jar 不需要上传”是什么样的部署方案？ |
 | 69 ktqFDx9m2Bvfq3y4 2024-01-10 08:57:10 +08:00 @mightybruce #46 service weaver 不错，我在公司内部设计的混合型服务就跟它差不多。最终写出来的服务可单体可微服务可混合。 |
 | 70 wocao666 2024-01-10 08:59:54 +08:00 业务体量不大的话，其实用上微服务完全就是徒增工作量；当然，在中国毕竟要面向面试编程…… |
| 71 QlanQ 2024-01-10 09:21:17 +08:00 |
 | 72 slowgen 2024-01-10 09:37:31 +08:00 1 有的时候其实不是微服务和单体的事，而是你的项目的性能和资源消耗的问题。举个例子： 有的微服务项目，一个实例启动需要 2 核 4G 甚至 4 核 8G~16G ，但是能承载的并发只有 100 甚至 50 ； 有的微服务项目，一个实例启动需要 2 核 4G 甚至 1 核 0.5G ，但是能承载的并发有 500~2000 ； 一年下来的开销差异可不少，真的别吹内存不值钱了，在云服务上就是真的贵。反正我是见过一年 2000w 云服务支出，一小半支出在云服务商的数据库上，另外大部分的钱都是 ECS ，cpu 大量空闲时间但是内存水位常年 75%以上占用的，是什么语言为主大家都懂的，钱都花在刀把上了，现在就在那里开猿节流、降本增笑。 |
 | 73 crazyTanuki 2024-01-10 09:40:24 +08:00 还没学上应用上，就开始淘汰了 |
 | 74 diagnostics 2024-01-10 09:47:03 +08:00 @mightybruce #47 从头条的翻译水文看的吧？但凡你看过 Google 的论文，你就知道这只是某个员工，水 KPI 的手段罢了，实际上就是抄 Akka 的 ClusterSharding ，然后加了点自己的东西 |
| 75 diagnostics 2024-01-10 09:52:41 +08:00 @xuanbg 应该是 cloud native 和传统部署的差异，写代码其实差异真没那么大。 cloud native 需要 k8s ，镜像库，cicd ，统一可观测性，这些东西的开销比较大。 例如日志，砍掉 loki ，splunk ，用人工一个一个服务去翻日志的报错，哪个成本高？一个人力一个资源，trade off 罢了，现在企业，人便宜，资源即使用不上，一直开着也费钱 |
 | 话说上家公司是把微服务改了单体，那个微服务设计的四不像，所有服务公用一个数据库，里面几百张表，各个微服务都能读所有表，其实就是个分布式单体，乱的可怕。 |
 | 77 gejun123456 2024-01-10 10:33:24 +08:00 @gaifanking 登录这种核心业务拆成微服务挂了也影响的，调提可以弄些自动重启，监控，先上线一部分机器等措施避免 |
 | 78 coolcoffee 2024-01-10 10:47:02 +08:00 @xiangyuecn 你确定这个不是因为你分层不合理导致每次都全量下载？ docker 镜像是分层的，如果只是最后一层 jar 变更的话，每次更新也只会重新下载最新的一层。和你传一个 jar 的大小是差不多的呀。 |
 | 79 WDATM33 2024-01-10 10:57:20 +08:00 见过一种架构，后端操作整合成一个服务，对外只暴露 dubbo 接口，对外有另一个服务负责把这些 dubbo 接口包装成 http 接口。对内其他组的程序则直接调用 dubbo 接口。不知道有啥好处 |
 | 80 hancai 2024-01-10 11:10:39 +08:00 @shuimugan 没错，你说的就是我们公司。 不过现在在用 go 重构搞轻量化。我们这个还是涉及到给客户私有化部署， 人家客户说你们这玩意儿光启动就得 128G ？ |
 | 81 julyclyde 2024-01-10 11:11:14 +08:00 |
 | 82 KgM4gLtF0shViDH3 2024-01-10 11:20:14 +08:00 @gaifanking 大厂都大规模宕机多少次了。。 |
| 83 gaifanking 2024-01-10 11:40:43 +08:00 @bestkayle 幸存者偏差吧，你只看到了大规模宕机，很多微服务挂掉处理好没影响全局这个我们不知道。 |
| 85 xiangyuecn 2024-01-10 12:01:31 +08:00 @pkxutao #68 @coolcoffee #78 没办法 烂摊子 水平也低，所有依赖都打包进的一个 jar 再打包 docker 镜像，确实是分层的问题；后面调整的时候干脆去掉了 docker ，只需打包 jar 再上传 重新运行这个 jar ，少了不少步骤，依赖的 jar 没有变化就不需要上传 回到了最原始做法 比较省心 |
 | 86 Foxkeh 2024-01-10 12:39:55 +08:00 有道理. 中小公司和中小规模的业务还是多数. 做好分布式 ID,分布式锁,分布式事务,把定时任务抽出来. 单体一样能部署多实例一样能打. |
 | 87 samun 2024-01-10 13:22:27 +08:00 @gaifanking 同一个服务也可以按功能给不同的实例的 |
 | 88 ZeroAsh 2024-01-10 13:51:49 +08:00 Java8/11+Spring 就不是云原生 Ready 的。明知山有虎，偏向虎山行的结果就是资源浪费，说到底这些技术栈就不应该搞所谓“微服务”和去容器化。 而且现在业务不扩张了，老板也不需要那些花里胡哨的 DevOps 来降低业务横向扩展成本。运维被开了拿 n+1 笑着找下家，原来的开发也回到了舒适区，老板也节省了成本，怎么感觉是三赢？ |
 | 89 salmon5 2024-01-10 14:01:14 +08:00 换回单体，50%的开发被开了，开猿节流 |
| 90 salmon5 2024-01-10 14:02:32 +08:00 再招聘几个应届 CRUD ，成本嘎嘎降 |
91 nothingistrue 2024-01-10 14:19:30 +08:00 看到去 DevOps 就知道这根技术无关了，就是「开猿节流，降本增笑」。楼主后面补的话，更证实了这一点。 |
 | 92 Amex 2024-01-10 14:23:44 +08:00 via iPhone @disorientatefree 一听就是狗家 |
 | 93 gerefoxing 2024-01-10 21:02:33 +08:00 简单，方便开发，单体前后端不分离的项目，找个基本的框架不断完善，一个人写就行了，开发快 |
 | 94 Beats 2024-01-10 22:43:47 +08:00 @WDATM33 分层啊，比如我页面有的数据需要几个接口数据合并咋整，一直改后端服务？ 现在这层好多地方都是给前端了，node 做聚合做数据收集和转换，后端只关注核心接口 |
| 95 Beats 2024-01-10 22:45:54 +08:00 @bestkayle 没微服务给你做监控处理，机器挂了咋整，有的物理机有问题咋整，全人肉维护就.....，稍微上点规模还是得微服务 |
 | 96 koloonps 2024-01-10 23:33:57 +08:00 @Beats "没微服务给你做监控处理，机器挂了咋整，有的物理机有问题咋整，全人肉维护就.....，稍微上点规模还是得微服务" 没有微服务这也能做啊,你不会认为只有微服务才可以吧? |
| 97 Beats 2024-01-11 00:19:04 +08:00 @koloonps 关键是如果业务规模大一点都做了 devops 这些了，哪还会有单机服务的存在，除了公司规模就几个研发那种，单机服务现在就是个伪命题 |
| 98 Beats 2024-01-11 00:22:18 +08:00 @konakona 微服务也不一定就一定要 k8s 吧，我上家公司最初的架构就没有 k8s ，只是通过 jekins 相关的工具简单做的。 |
| 99 xuanbg 2024-01-11 08:28:44 +08:00 @lujiaxing 好几个负责专门维护 CI/CD, K8S 的人？不管是微服务还是单体，这些都不需要人维护啊。当然，单体不需要 k8s ，但照样可以有 CI/CD 。 |
Select Language