从微服务走向单体化

[xhwdy26]

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

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

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

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

[javalaw2010]

我觉得一家公司如果在技术架构上使用单体还是使用微服务有争议，那大概率就不必使用微服务。

[guotie]

毫无问题

单体为啥不能扩展？？？？

[zen1]

先搞懂什么是单体，什么是微服务吧。微服务不是银弹，单体也不是什么 low 货！

[xuelu520]

看着我 source tree 里面的 20 多个微服务项目，开发一个需求涉及 N 个服务，太鸡儿麻烦了
我司部门什么东西搞个微服务，有点为了微而微的感觉了。

[Pdk5a8759cbeD6CH]

@mbeoliero123 单体是指把所有服务揉进一个项目吧，又不是单机不能搞负载均衡。你微服务不搞多台机子 流量大的时候也扛不住啊。

[Gll910802]

@lqw3030 的确，我们目前就这么处理的。想 all in one ，就单独启动一个 jvm 引入所有包的那个工程。想微服务，就各自模块单独工程单独 jvm 启动

[ciki]

@yinmin #5 单体和用不用消息队列没关系，消息队列只是个中间件

[ciki]

@yinmin #29 看你上面疯狂回复一堆，我建议你重新学习下基本概念吧

[tongqe]

要看自己的系统是否是复杂系统，复杂系统中的每个元素的行为和关系是不一致的，比如几个关键指标，高可用，高吞吐，高扩展花成一个三维坐标轴，比如银行的交易服务，对高可用，高吞吐要求极高，而一些统计模块的实时性要求没那么高。这种元素之间的差异性是天然存在，无法避免的，自然要拆分。如果再带入组织架构和人类协作的方式上，拆分微服务是当下比较合适的方案。至于楼上一些帖子说，spring 和 Java 作为基础设施占用内存的问题，其实是优先级非常低的问题

[runlongyao2]

docker 把服务部署到一台机器，这样要改的少点

[runlongyao2]

@yinmin 哪儿那么多百万级的业务...如果有，迁出来这一个单独部署和维护就好

[Pdk5a8759cbeD6CH]

@hdfg159 # 90 这种情况微服务和单体没任何区别，我们的微服务的数据库、proto 文件，项目地址都拆分开的，负责用户服务的就拉用户服务的代码。

[runlongyao2]

@xhwdy26
把原本部署方案改成用 docker 容器部署，每个项目都是一个镜像就行，这些镜像都部署到一台机器上，
源码层面不需要动

[Pdk5a8759cbeD6CH]

@yinmin 单体和用不用消息队列有啥关系？难道单体的都没有处理过购买未付款，然后等 20 分钟自动取消订单然后归还库存的业务吗？

[fcten]

如果这些功能只要 3 ～ 5 人一个团队就能维护，单体服务并没有什么问题

[runlongyao2]

@keller 老兄明白人

[uRQDd07Pt2UWOtOF]

单体系统为了解决自身的各种内部问题，分化为多个微服务系统，当各个问题解决解决后，又合并为一个新的单体系统，螺旋型进化，往复这个循环

[lvlongxiang199]

shopify 也用单体. 贵司的业务比 shopify 更复杂 ? 为啥他们的单体没崩 ?
https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
https://shopify.engineering/shopify-monolith

[harry90]

业务量如何 增长如何 多大规模 未来预期如何 什么样的团队 任何架构选择都可以考虑实际情况

[runlongyao2]

@ryalu 微服务最大问题就是，容易导致成本失控，这种失控不像项目失败一样，它是隐形的。