从微服务走向单体化

[xhwdy26]

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

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

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

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

[whusnoopy]

@xhwdy26 #42

提的这三个问题，单体和微服务都没有本质区别，Google Meta 这些还全公司一个 repo 呢

1. 几个人同时在一个项目上开发的冲突怎么解决。如果几个人开发的是项目的不同模块（之前的不同微服务），那代码就是不会存在冲突的，如果会冲突，说明之前也在同一个微服务内，之前怎么解决冲突的现在就怎么解决

2. 合并成单体为什么就一定会启动时间增加？能加多少？原来启动一大堆微服务不也要时间？还是说分拆得够好只用重启自己改的这一个？一两分钟的话那就刚好站起来去喝口水活动一下。而且很多东西就应该先想好再写，写好一次过

3. 某个模块拉分支，和把全局拉分支然后合回去也没区别啊，同问题一，如果是各改各的，合回去其他人有冲突的直接接受，自己改的用自己的覆盖。或者更极端一点，就不该有分支，Google 那么大个公司都不拉分支，开发过程中用参数做好隔离，旧的依然跑，新的只在参数开关打开的情况下生效，等新的全量部署后再清旧代码

[KongLiu]

我们之前有个项目，就是通过负载均衡实现单体水平扩展的，也不是不能用

[sagaxu]

@mooyo 32#
单体的 interface 替换 implementation 有何不便？单体和微服务，只是调用方式不同，在模块划分和抽象封装上并没有什么不同。

@yinmin 51#
我干过的所有单个 jar 包的服务，都有 mq ，都有 redis ，甚至有专门的配置中心。单体在设计的时候，也是按照集群设计的，一般至少部署 2-3 台，并假定其中一台随时会挂，所以基本上也会按照无状态设计。我还遇到过那种大单体，但每个部门只负责其中 1-2 个 jar ，以插件形式发布，只有核心 team 有完整代码库权限。

@0xD800 57#
1. 耗时长的和耗时短的，可以用不同的线程池。
2. 单体也可以模块化，部署的时候只启用部分模块。

@Genshin2020 59#
崩一个怎么会所有服务都噶？负载均衡网关不能自动从集群中拆除？服务监控不能自动重启？银行交易接口延迟大，改成异步，就算单机处理 10 万并发交易也 boom 不了。

[IamUNICODE]

降本增效+1

[xiyy02]

微服务更像是「鸡蛋不放一个篮子里」，各种服务不会一起挂，局部服务挂了直接熔断降级，不影响其他 p0 服务正常就行；但是单体应用就会受木桶理论影响，一堆的服务要为某一个短板服务买单。
但本着「又不是不能用」的原则，看你们的取舍咯

[Genshin2020]

@sagaxu 我去的时候，整个项目的服务只有一个入口，大概只能这么解释了，如果有你说的这些，这个项目也不会节假日人流高的时候就崩一下。

崩一个就全崩的描述不准确，但是你可以理解为所有的车辆进城的时候都走的是一个主干道，但是西城那边没有停车位了，导致去西城的车把所有的车道都占满了，去其他城区的车进都进不来，所以看起来就是全崩了。

已经是一个很早的项目的，可能当时的架构设计没到位，也没有想到公司会因为那三年突然发展起来。

导致技术债太多了。

我去的小 2 年也没有完全解决技术债，我的反感都是治标不治本，核心还是基础架构问题。

[IamUNICODE]

我的建议是，按照功能分出去一部分服务，但是千万不要搞得满地都是，摊子铺越大危险越多

[keller]

很多人是不是对单体应用有什么误解？认为单体应用只能运行一个实例吗？

[a398058068]

单体服务不一定是字面意思 好多公司转单体是因为微服务理念拆分的的太开，难于管理 最终合成几个大单体 然后 云原生网关托底 保留微服务架构功能的同时 应用也更易于开发了， 比如 istio + spring boot 单体

[LPJD]

1. 几个人同时在一个项目上开发的冲突怎么解决？
使用 git merge 方式合并，代码冲突了，两个开发人员一起解决问题。避免干掉别人代码。

2. 启动时间会增加
Idea 使用 Jrebel 热更新，避免了频繁重启。

3. 如果合并成单体，某个模块要拉分支，应该怎么处理这个问题
单体应用代码在同一个仓库
---
1 、3 问题是 git 使用问题。
---
单体和微服务看应用场景使用。需要综合考虑项目预算、业务量、硬件资源。就像通行工具也分自行车和汽车，选错了，整个团队都得加班加点，产出效率还低

[kenvix]

迷信微服务本来就不可取。低成本小微企业完全不该考虑这种东西

[hxndg]

不提本质区别，天天就是某种技术手段就是微服务，不这种技术就是单体。

而且最荒谬的是，为了解决问题而选择技术手段和体系架构，而不是因为用了某种技术手段，选择了微服务

如果连有状态，无状态，同步，异步还有微服务，单体的认识不到位。建议看看“凤凰架构”这本书

[akira]

大部分公司的 业务体量，其实 单体更合适

[zhywang]

业务量不大，团队也不大的情况下，确实单体比微服务更合适，技术是手段，业务是目的

[error0]

自动化部署啊

[HaibaraDP]

nacos 、mq 、redis 这些基础设施业务上需要的话改成单体也要部署吧

[shmilypeter]

你这个微服务拆得也不多啊，我以为是跟以前一样过度拆分呢。

事实上拆分几个微服务，nacos 注册中心，mq 消息队列，redis 做缓存，然后上 gitlab 管理代码，还是有道理的。

像过去一样就一个工程，前端放在 resource 里，然后打 war 包丢服务器里直接启动 tomcat ，首先配置文件得一个一个改并且有泄漏的风险，第二就是万一日志级别调错或者内存泄漏，那么一挂全挂。第三就是别人可以一键删库也可以一 U 盘拷走所有工程直接在自己服务器跑起来。如果是微服务，不太可能一挂全挂，并且只给相应仓库的权限就行了，不太可能一下子拷走你的全部工程，即便是拷走了也不可能自己服务器直接跑起来。

[coala]

这玩意还是看需求， 可靠性要求高又迭代频繁的话单体就是找死....

[000sitereg]

套用黑猴的话 要我说都是屁。 而且是彩虹屁。 都是为了绩效，为了就业。
我现在的外包项目，8 小时请求量一两百左右。 大概拆了 6 个微服务。哈哈。理由当然是楼上各位说的，职责，扩展，健壮....嘿嘿

[wangxiaoer]

@yinmin #11 单体或者微服务的选择重点并不是简单看并发数，因为单体也可以用集群的模式。我的理解是拆不拆分还是看业务之间关联度。