从微服务走向单体化

[xhwdy26]

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

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

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

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

[RotkPPP]

坐标某大厂 C 端产品的开发，我们就是分布式单体应用，用户量千万级，虽然没有像淘宝那样子有几十万的并发，但是高峰的时候几万和十几万是有的。我们系统也没崩过，开发起来也没啥问题。

我觉得选什么架构，技术选什么难道不应该是应用场景决定么。

[xhwdy26]

感谢各位的回复，三个最大的疑问：

如何合并成单体，几个人同时在一个项目上开发的冲突怎么解决？

如果合并成单体，启动时间会增加，开发调试不方便，怎么面对这个问题？

如果合并成单体，某个模块要拉分支，应该怎么处理这个问题？

[henix]

我理解单体应用 vs 微服务只是部署运维的差别，跟 git 和代码怎么管理没关系
至于开发环境，可能是每个人自己电脑上 wsl2 或虚拟机？

[tonytonychopper]

@xhwdy26 #42 那就用 monorepo

[xuanbg]

但凡是微服务合并单体的，十个里面有十个，全都是因为服务没有拆分好。你想啊，重新拆分多麻烦，不如干脆就别拆啦。一锅炖不就完了吗！

啥？你说微服务更好？你就说一锅炖能不能吃吧。

[yeqizhang]

除了你说的 nacos 是微服务时出现的，其它又不是单体不能用，单体又不是不能集群负载均衡

[demoplayer88]

上面有人说的单体和 mq 有什么关系？ 我们一直都是单体 一直都用 mq 单体又不是单机 举个最简单的例子 一台跑正常请求 一台跑队列 一台跑任务 有并发就上集群 动态扩容

[Charlie17Li]

@RotkPPP 一个单体实例配置多少资源（ cpu ，内存），平均水位是多少？🤔

[guanzhangzhang]

去看看腾讯和抖音的单体化，小微服务+多机

[yinmin]

@demoplayer88 #47 OP 的单体是指一个 jar

[yinmin]

@demoplayer88 #47 OP 的单体是指一个超级 jar 包（见#14 ），一个 jar 包里跑 mq 应该不常见吧。

[jacketma]

只要把数据库单独拎出来部署，单体再克隆一个备用服务器，前端搞一个负载分流，这种架构进可攻退可守

[SageXiong]

微服务和单体都有自己的应用场景，而且架构是慢慢演变的，不是一开始就定死我要用微服务或者我只能用单体，要看具体的场合来确定。

不管是单体还是微服务都遵循康威定律，软件系统最后崩溃的根本原因是软件不匹配业务。

[qinxi]

@xhwdy26 #41
1,3 微服务都存在一样的问题。
2. 你的微服务启动比单体快多少？ 你调试的时候本地要启动多少服务？ 微服务的调试更不方便才是

[hangszhang]

这个和你们的组织架构有关系

[sk217]

@yinmin #17 这个跟微服务没啥关系，以前单体的服务也是无状态的，也可以前面用 nginx 负载均衡，后台直接扩容一堆单体实例，另外单体也可以用 MQ ，很多事务没必要立即完成，丢进 MQ 慢慢消费就好，关键在于思路，而不是微服务包打一切，不过这样搞下来，也差不多算得上是单体式微服务了，临时应对一下流量并发还是可以的

[0xD800]

遇到一个很实在的问题，系统有两大核心接口，有一个接口耗时长，有一个耗时短。

如果耗时长的接口占用了 io 线程，另一个耗时短的接口就没法处理，这时候应该把耗时长的单独部署出来

[blmdz521]

微服务做的好，合成单体也简单，配置改改，直接合并。为了微而拆，直接 boom

[Genshin2020]

我入职一家公司，干的最狠的事情就是把各种功能模块给拆成单体了，比如交易系统，订单系统，配送系统，都是独立部署的，以前都在一起，崩一个，所有服务都噶。

交易系统因为银行那边的原因，总是出现延迟问题，然后导致支付系统积压，最后内存狂增，最后 boom 。

现在合理化服务器资源，使用突发实例的运服务器支持支付系统，虽然我离职了，但是那个公司现在也没有因为支付高并发崩溃过。

[blmdz521]

@xhwdy26 1 和 3 都是 git 版本管理，微服务和单体没啥区别，严格遵守管理就行了。2 如果只是几个十几个服务，启动时间没你想象的那么差，可能原来 20 现在 2 分钟，最差拆分多包选择启动呗，这得看业务场景多模块调用，还不如等 2 分钟呢