从微服务走向单体化

276 天前
 xhwdy26

CEO 觉得微服务部署极其繁琐,什么 nacos 、mq 、redis 都好复杂,远不如零几年的开发一条龙从后台到前端那么简单。

要求把十来个微服务(用户、订单、后台、网关等)合并成一个。

简化部署,只一台机器搞定。

试问,这种单体程序最后以怎样的方式崩溃。

15016 次点击
所在节点    程序员
165 条回复
NotLongNil
276 天前
抛开具体场景,谈架构,就是刷流氓
cj323
276 天前
@me1onsoda 微服务确实浪费计算机资源,但是可以分散团队各自独立开发微服务。当然后续也有各自独立开发不好集中管理的问题。
soap0X
276 天前
我是企业项目没搞过互联网。该看并发量评估,单体可以集群啊。
ZRS
276 天前
技术选型取决于你们的业务
Perry
276 天前
不要最后楼主说他们公司用户量在十万以内,并发 100 以下
yinmin
276 天前
@cobbage #23 企业项目不会出现突发高并发,单体可以集群(多服务器负载均衡),应付企业项目绰绰有余。

互联网项目不一样,一个朋友的商城平时最多就几百人同时在线,有一次老板做推广,花了几十万请大网红做直播,然后 5 万多人同时涌入系统直接宕机,几十万软妹币打水漂了。

高并发的架构是不一样的,微服务是独立的,通过消息队列异步通讯,会根据消息队列情况自动伸缩微服务,消息队列过长超阈值直接抛弃掉,保证系统不崩溃。单体用集群就有点力不从心了。
beneo
276 天前
世界微服务的爆发,说实话,最经典、最具代表性的例子就是淘宝的“五彩石”项目。在五彩石之前,有多个团队共享一个 Tomcat 环境进行发布,硬是支撑起了一年 1000 亿 GMV 的业务量。所以,实话实说,CEO 这样做的原因,估计是是商业行为而不是技术思考,也就是单体应用架构并没有限制了你们的发展,而是对公司未来的不确定性,而产生了强烈的降本需求
sagaxu
276 天前
@yinmin 5# 你这看法跟现实不符,单体不是单机,早在 Nginx 开源之前的上个世纪末,F5 的 Big IP 就支持负载均衡了,当时就有一些公司用上单体集群部署。在 Redis 开源之前,单体服务早就用上 memcached 了,当年做 Web 的那波人,人均读过 memcached 源码和 C10K 论文。

单体其实也用消息队列,ActiveMQ 是二十年前的东西了,之后还有 qpid ,都是微服务兴起之前就有的。十多年前,还有很多现在很少人提及的常用组件,比如 Beanstalkd ,Tokyo Tyrant 等等。

在微服务兴起之前,把大单体部署很多份,然后从网关做负载均衡是很普遍的事情,性能扩展性是不如微服务,但是不至于性能跟单机划等号。
yinmin
276 天前
@sagaxu #28 我同意你的看法。只是技术发展到现在,如果需要用到消息队列,优选微服务;如果单体用消息队列,开发复杂性、部署复杂性、伸缩性都不如微服务。
soap0X
276 天前
@yinmin 这个事情怎么看的成本问题,流量不是经常性的。我刚工作时候遇到过类似的事情,提前准备应对了,当时好像是有部分网络没切过去。
sagaxu
276 天前
@yinmin 29# 单体的伸缩性肯定不如微服务,微服务可以很方便的实现根据负载动态扩容,单体就比较费力,最多用脚本临时租 VM 自动部署。但微服务设施是有附加成本的,无论是自建还是租 IaaS 都价格不菲,面对偶尔扩容这种事情,老板更希望员工加加班哪怕手动完成。
mooyo
276 天前
微服务最大的好处是提高了服务的可维护性,划分合理的话可以直接把过于老旧的服务 drop 掉对照接口重写一个。
v1
276 天前
讲个笑话,
----
快 10 年前,在卫浴厂子写的 CRM ,一梭子原生 PHP 直接放在办公室的 dell 工作站上(印象里是 4 核 8G ),全国几百家代理商、服务点,每天集中并发至少上万,从来没崩过(也可能不知道,毕竟 F5 就能重试,还能甩锅网络问题)。
----
前年副总找人搞的微服务,接入抖音和微信,一天崩 30 次,老同事又联系我,说副总让他从仓库把那台 dell 又拿出来了,但是不知道怎么把新数据导入,哈哈哈,真自豪
IvanLi127
276 天前
你们这套微服务全部部署到一台机器上,能有多少种崩溃的姿势,那单体程序能命中其中一部分,不会超过的,放心。

单体应用很好,就是单台机器配不上它,只能拆掉跑。至于高可用,这和单不单体没太大关系。单体应用也能互连成集群。
silentsky
276 天前
上面很多人提到单体不能用 mq 不懂瞎说?
qinxi
276 天前
我们就是百万用户的单体应用。单体跟异步和队列又不冲突。不考虑团队后端开发才几个人,把后端拆得比员工数还多,天天净在那切换项目了。
miscnote
276 天前
早些年没有微服务,同一个服务部署多个实例,简单的做 scaling out ,也能过的不错。比如某邮箱的 webmail ( java 写的,里面集成了很多功能,按现在观点看,都可以拆成 micro service ),就是几百个物理实例,靠 dns 做的 scailing out ,照样撑起数千万用户并发。
seansong
276 天前
微服务在目前大部分场景里面,属于政治 kpi 吧,其实技术层面的需求并不大
jeffw
276 天前
我觉得单体应用挺好的,一直比较反感微服务。
irisdev
276 天前
单体挺好的,单机顶不住吧

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

https://www.v2ex.com/t/1106152

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

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

© 2021 V2EX