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

2024-01-09 09:55:19 +08:00
 lujiaxing

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

20990 次点击
所在节点    程序员
105 条回复
Narcissu5
2024-01-09 18:36:20 +08:00
之前面试过一个做国企项目的哥们,上面给他在小型机上分了 200G 内存,他在上面部署了一个 SpringCloud 。看不懂,大受震撼
wu00
2024-01-09 18:43:16 +08:00
大伙儿都痛恨强上微服务,但是架不住简历需要啊;
小公司有领导带着体验微服务就烧香拜佛吧。
veightz
2024-01-09 18:50:18 +08:00
过度微服务只会让事情更复杂, 这个确实没错. 当然也不是追求必须单体.
服务的拆分要看业务架构和组织架构, 一群人维护一个也痛苦.

但是容器化显然是有好处的.. 之前容器化后, 反而系统的合并,拆分调整变得容易了..
wxw752
2024-01-09 20:27:49 +08:00
微服务也不是一无是处,好像很多情况下是需要微服务的。

某些 ToC 的功能需要快速迭代,但是还有一些 toB 的功能白天不能停机。这种情况下微服务就不必考虑部署时间了
sampeng
2024-01-09 23:51:21 +08:00
反正作为运维,每个新项目我都要怼一次后端开发 leader:不许给我搞微服务,你就单体。

单体也需要运维,都让研发搞就是逗闷子的。只是真不需要一堆运维了,我一直认为国内公司,90%有且只需要两个运维。搞微服务?那就看架构吹牛逼吹多大了。

我怼得最多的一句:高并发?你自己试过本地 mysql 1000 万数据集两到三层良好索引的 sql 效率吗?没有?没有你扯犊子的因为性能横向扩展?
twofox
2024-01-10 02:22:11 +08:00
单体也能 CI/CD ,我现在就是。

搞什么微服务,目前的业务体量根本用不上。一旦用上微服务的各种中间件,内存占用就上去了。而且还增加我的心智负担。

单体应用也能扩展,只要做成无状态的就好了。东西都放在 redis 里面。docker 多开几个实例我就是一个集群
gaifanking
2024-01-10 08:47:02 +08:00
啊?看的都懵了。不拆服务有个严重的问题是一个业务有问题影响全局啊,比如登录出 bug cpu 爆了结果所有业务都挂了。
pkxutao
2024-01-10 08:50:26 +08:00
@xiangyuecn #46 请问“依赖的 jar 不需要上传”是什么样的部署方案?
ktqFDx9m2Bvfq3y4
2024-01-10 08:57:10 +08:00
@mightybruce #46
service weaver 不错,我在公司内部设计的混合型服务就跟它差不多。最终写出来的服务可单体可微服务可混合。
wocao666
2024-01-10 08:59:54 +08:00
业务体量不大的话,其实用上微服务完全就是徒增工作量;当然,在中国毕竟要面向面试编程……
QlanQ
2024-01-10 09:21:17 +08:00
@gaifanking 参考最近的 阿里崩,拆分成微服务并不能避免 业务挂的问题
如果 商场项目,购物车服务挂了,能说业务没挂吗?
如果是优惠券服务挂了,能说业务正常吗?
slowgen
2024-01-10 09:37:31 +08:00
有的时候其实不是微服务和单体的事,而是你的项目的性能和资源消耗的问题。举个例子:
有的微服务项目,一个实例启动需要 2 核 4G 甚至 4 核 8G~16G ,但是能承载的并发只有 100 甚至 50 ;
有的微服务项目,一个实例启动需要 2 核 4G 甚至 1 核 0.5G ,但是能承载的并发有 500~2000 ;

一年下来的开销差异可不少,真的别吹内存不值钱了,在云服务上就是真的贵。反正我是见过一年 2000w 云服务支出,一小半支出在云服务商的数据库上,另外大部分的钱都是 ECS ,cpu 大量空闲时间但是内存水位常年 75%以上占用的,是什么语言为主大家都懂的,钱都花在刀把上了,现在就在那里开猿节流、降本增笑。
crazyTanuki
2024-01-10 09:40:24 +08:00
还没学上应用上,就开始淘汰了
diagnostics
2024-01-10 09:47:03 +08:00
@mightybruce #47 从头条的翻译水文看的吧?但凡你看过 Google 的论文,你就知道这只是某个员工,水 KPI 的手段罢了,实际上就是抄 Akka 的 ClusterSharding ,然后加了点自己的东西
diagnostics
2024-01-10 09:52:41 +08:00
@xuanbg 应该是 cloud native 和传统部署的差异,写代码其实差异真没那么大。

cloud native 需要 k8s ,镜像库,cicd ,统一可观测性,这些东西的开销比较大。

例如日志,砍掉 loki ,splunk ,用人工一个一个服务去翻日志的报错,哪个成本高?一个人力一个资源,trade off 罢了,现在企业,人便宜,资源即使用不上,一直开着也费钱
jonsmith
2024-01-10 10:13:22 +08:00
话说上家公司是把微服务改了单体,那个微服务设计的四不像,所有服务公用一个数据库,里面几百张表,各个微服务都能读所有表,其实就是个分布式单体,乱的可怕。
gejun123456
2024-01-10 10:33:24 +08:00
@gaifanking 登录这种核心业务拆成微服务挂了也影响的,调提可以弄些自动重启,监控,先上线一部分机器等措施避免
coolcoffee
2024-01-10 10:47:02 +08:00
@xiangyuecn 你确定这个不是因为你分层不合理导致每次都全量下载?

docker 镜像是分层的,如果只是最后一层 jar 变更的话,每次更新也只会重新下载最新的一层。和你传一个 jar 的大小是差不多的呀。
WDATM33
2024-01-10 10:57:20 +08:00
见过一种架构,后端操作整合成一个服务,对外只暴露 dubbo 接口,对外有另一个服务负责把这些 dubbo 接口包装成 http 接口。对内其他组的程序则直接调用 dubbo 接口。不知道有啥好处
hancai
2024-01-10 11:10:39 +08:00
@shuimugan 没错,你说的就是我们公司。 不过现在在用 go 重构搞轻量化。我们这个还是涉及到给客户私有化部署, 人家客户说你们这玩意儿光启动就得 128G ?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1007047

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX