从微服务走向单体化

[xhwdy26]

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

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

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

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

[Hudiebbk]

我这边新项目如果需求那边没有明确说,我一般都是单体服务,但是提前会划分好模块,等后面真需要拆,写个 main 函数就拆出去了,前期快速上线验证业务

[forbreak]

我记得微服务刚出来是为了解决，旧的系统的技术债务，异构系统的问题。然后后面业务再慢慢迁移到一起。 但是不知道怎么就变成微服务一把梭了 。 能有人力物力把系统迁移到单体服务，肯定不需要微服务了。 单体也有负载均衡。

[LDa]

干过 ， 合成一个单体打包发布 ， 共享 tomcat session 进行集群部署
稳定的一批

[7beloved]

我们小公司没玩微服务，但是都是分布式的，简单说，开发语言比开发人员还要多。后端语言就是 py,go,java,proto,node 了，一共三套环境，玩的阿里云的 k8s ，每个月成本十分高，服务器总资源大概是 400 多 G ，3 台 64 ，6 台 32 的服务器资源，还不算其他的一些小型服务器。架构层面的定义，跟领导的能力有很大的关系，很多领导都是为了用二用，到了开发实现这里就很头痛，每个单独的服务都要对应一个 bff ，问题是 TM 的公司前端不愿意写 BFF ，我真 C 了

[Eliefly]

很多公司业务单体架构已经足够满足需求，没必要为了微服务而微服务，收益没看到成本一大堆。