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