2024 年了, 有多少公司和系统由微服务/云原生转为了单体架构?
source link: https://www.v2ex.com/t/1007047
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
最近看脉脉里有不少开发在讲自己所在企业的一些系统已经开始由微服务/云原生架构转为或者正在逐渐转为传统的单体架构. 原来的 DevOps 要么被优化要么转一线开发回去写 CURD 了. 问下诸位这种情况目前是否普遍? 未来还会不会有可能再大规模回归微服务架构?
 |
victimsss 3 小时 45 分钟前 天下系统，合久必分，分久必合。
|
 |
coderxy 3 小时 42 分钟前 实在无法理解什么公司会去做这种逆向操作， 难道是为了省资源？ 花这种代价去重构微服务为单体，感觉没啥收益啊。
|
 |
XSDo 3 小时 39 分钟前 单体可横向扩展，后面数据库搞集群。
|
 |
Huelse 3 小时 37 分钟前 说白了就是减机器减配置，需求高了再加就是
|
 |
aw2350 3 小时 31 分钟前 话说，大部分 ToG,ToB 甚至 ToC 的业务，有多少大到需要微服务？
|
1 |
TimLang 3 小时 27 分钟前 微服务成本多高，做过的都知道吧，量不大的情况下，单体就是成本最低的。
|
 |
QlanQ 3 小时 27 分钟前 对于大部分公司来说，微服务都只是噱头吧
|
 |
HTDit 3 小时 26 分钟前 via Android 稳定业务可以迁回啊，微服务和 cicd 这些就是为了快速迭代服务的，稳定了不需要迭代就可以迁回并降低运维成本和运维难度。
|
 |
Seulgi 3 小时 22 分钟前 都是为了成本。现在是云原生，云原生虽然和你微服务不冲突，但是你微服务一个服务要 2c4g ，你两个微服务合一也只要 2c4g ，成本是不是就缩了。以前是为了扩展把服务拆散，现在就是为了钱把服务聚回来，核心服务当然还是不会去大动。
|
 |
chendy 3 小时 20 分钟前 单体应用，一样能云原生能 devops 能 cicd 能不停服务部署
几个人的团队整一大堆微服务纯属没事找事 |
 |
undefine2020 3 小时 12 分钟前 我看微服务在中国的火热只是大部分中年技术主管在 KPI 焦虑之下导致的
|
 |
duange7X24 3 小时 5 分钟前 只要满足业务的情况下，单体节省成本啊，别说机器省了；就是人力，单体 crud 是个开发都能干吧，这不也省了一大块
|
 |
lsk569937453 2 小时 58 分钟前 @QlanQ 就重构花费的成本和风险，足以让多数人望而却步了
|
 |
me1onsoda 2 小时 52 分钟前 依我看，上微服务是错第一回，迁回单体是智昏，错第二回。。
省机器？要么是扯淡，要么原来机器都在闲置空跑，都挺离谱的。微服务云原生说好的弹性伸缩呢？ |
 |
Worldispow 2 小时 52 分钟前 个人感觉绝大多数公司，业务模式完全没有到需要上微服务的程度。
|
 |
lstz 2 小时 40 分钟前 via iPhone 想起以前待过一家公司，微服务写的好恶心，对某些 leader 来说，自己技术不行那就上微服务，堆机器堆人力，明明单机就能 cover 的硬要微服务
我在做自己的开源项目，laf-tools.com ，只要你设计合理，stateless 做好了等体量一大再说微服务也是分分钟的事情 |
 |
bianhui 2 小时 38 分钟前 很正常，大部分程序员的固有思维是，越复杂越牛逼，这边导致很多技术专家，架构师把一些很简单的事情，想的复杂。但是想想，如果你们公司不是那头部的几个互联网公司，有多少需要那么复杂的技术的？说白了，node ，python 也直撸也能解决市场上 80%以上的服务。剩下的，加点监控，恢复就得了。但后来很多人，特别是他们的老板发现，程序员格局确实很有限。
|
 |
heliotrope 2 小时 38 分钟前 大多数需求根本就上不到微服务的程度
还有很多公司人员流动性是非常大的 有的微服务搞得太复杂 交接成本也高 |
 |
rebelsre 2 小时 36 分钟前 微服务/云原生指 K8s ？单体架构指传统裸机部署？真的会有这种回退操作吗。。表示很怀疑
|
 |
siweipancc 2 小时 32 分钟前 via iPhone 压力大了怎么办？横向扩展啊。
你见过一大堆因为微服务产生的业务锁跟事务脏数据的吗，太爽了 |
 |
tomczhen 2 小时 30 分钟前 via Android 建议读一下串口并口发展历史。
|
 |
vjnjc 2 小时 28 分钟前 微服务是为了你有一堆人，防止各团队互相冲突的，现在不需要那么多人和业务了
|
 |
Gress 2 小时 25 分钟前 微服务跟性能没什么关系，甚至会降低性能，只要写的服务是无状态的能横向扩展，单体项目也能通过加机器应对很大的流量。微服务其实是解决多人协作的解耦问题，以及缩小发版时变更影响范围。对于一些团队就几个十个人的来说，上个🔨的微服务。
|
 |
RightHand 2 小时 16 分钟前 via Android 没微服务的概念之前就不发展了吗？
|
|
QlanQ 2 小时 6 分钟前 @lsk569937453 业务稳定，重构本来就不是必须的，只是没有新的需求和功能，不能让开发天天摸鱼而已
|
 |
konakona 2 小时 2 分钟前 说白了就是业务规模与预期相差甚远，收益不佳，需要缩紧预算。
成本意识强的公司，在 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 ）一起加入讨论，让每个人都意识到问题的严重性和必要性。 |
|
konakona 2 小时 0 分钟前 @Gress #28 现在很多都是众包的项目，Final 的甲方提出的运营 Request 可能就是要求微服务，方便扩展和运维管理之便。虽然拿到项目的每个乙方都只负责一小点儿，投入的人数也就是个位数。
|
 |
fkdog 1 小时 59 分钟前 前几年微服务弄的太火了，一堆菜鸡为了刷简历把项目改造成微服务，结果水平不够微服务不像微服务，单体不像单体。线上问题一堆。
|
|
me1onsoda 1 小时 55 分钟前 @bianhui 立场不同，不必说谁格局小。程序员的立场：给自己简历造料，提高身价或者不可替代性又或者是 kpi 。都是身在江湖身不由己。中层管理把公司当自己家，员工调个休都要问清楚干什么去，格局大吗？
|
 |
pengtdyd 1 小时 50 分钟前 这是因为很多人放大了宕机带来的影响，就算是阿里这样的公司宕机几个小时也无所谓，事实上对与一家商业公司别说是宕机几个小时，就算是这家公司没了，对整个市场也没啥影响，很多人是杞人忧天，害怕自己的 KIP 罢了。
|
 |
lujiaxing 16 分钟前 @me1onsoda 问了一个前同事 (现项目经理), 人家的原话是说:
"缩减服务器成本只是一部分目的. 更重要的是缩减人力成本... 原本微服务开发虽然可伸缩了灵活了但是开发团队却过于臃肿. 一个不算很复杂的项目, 开发团队却有几十号人. 其中还有好几个负责专门维护 CI/CD, K8S 的人... 改成单体之后, 一堆微服务聚合成一个服务, 原本的 K8S 不再需要可以直接停, CI/CD 可以改手动. 等全部改完之后, 原本的那几个 DevOps 可以裁掉了, 开发团队可以裁一半. 原来的运维任务, 技术经理负责就行了" 听完感觉一阵恶寒 |
 |
imzhoukunqiang 13 分钟前 via Android devops 和微服务有啥必然联系吗？单体应用一样可以做 cicd 。
|
 |
liqiqiqi1995 5 分钟前 改了一个公司内部应用，微服务转单体，生产环境 3 台物理机降到 1 台。一个月省了几百刀，给涨了点工资。
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK