从微服务走向单体化

系统架构本质是组织架构的表现。

降本增效

挺好的，崩溃无非就是某段代码 cpu 或内存占用过高，然后 boom 。微服务崩了也没啥差别。

2020 年之后，确实涌现出一堆从微服务回归单体的尝试，其中包括 amazon 这样的微服务先锋大厂。在提出微服务概念之前，就有大量比你们系统复杂十倍甚至一百倍以上的单体系统，一个单体程序几个 GB ，启动时间按十分钟为基本单位，他们崩溃了吗？

看用户量和并发量，如果用户量在几百万量级，每秒并发在 1000 以下，单体还是很好用的。

如果找网红直播，同一时间突发上万人在线，单体大概率会崩溃。因为，单体通常不会用消息队列，高并发无法转化为队列依次处理，然后就堵塞崩溃了。

提供一个思路，你建立一个独立 moduel 把所有模块都引了，然后 scan 里扫所有子模块的包，这样就可以快速实现“单体服务”，并且在想要水平扩容时仍可以模块独立打包

@yinmin 几百万，单体扛不住吧

微服务的两个最大的意义：独立发布和独立伸缩

你们如果不需要，就可以不搞微服务呗

不过我觉得你们 CEO 大概率只是因为“零几年的开发一条龙”是他认知的舒适区，而你们没有一个有能力的 CTO 或者架构师来把 DevOps 和基础设施做起来？

@xhwdy26 你问问领导： (1) 会不会找网红直播 (2) 会不会同一时间突发上万人在线下单 (3) 要不要用消息队列应对高并发。如果都是 NO ，改单体问题不大。

等等

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

???是字面意义的一台机器吗？

我以为是要从微服务转向分布式同构单体，合着你们是直接退分布式回归单机吗？啥业务啊，这么不要求可用性的

@mbeoliero123 #7 单体是否能扛住，主要看每秒并发，用户总量百万只是参考值。每秒并发 1000 以下，大致上限是 5000-1 万人同时在用系统，单体大致也就这个量级了，并发再上一个量级，就需要用消息队列 mq 将并发事务转换成队列，而单体基本上是不太会用 mq 的。

@yinmin 这跟单体微服务有什么关系？会不会崩溃取决于内存，配置不够微服务也崩给你看

@yinmin #11 单体服务怎么部署？还是走 k8s 那套吗？好像没有必要？

单体部署就是一个超级 jar 包加启动脚本加大内存

我觉得苦了开发人员，因为每个人都负责不同的模块，有的负责订单，有的负责后台等等

Java 搞微服务是最傻 X 的，本身就重再加上 spring 这个庞然大物，还要分开搞微服务，每一个服务冗余了这么重基础设施，浪费了不知道多少内存。历史问题属于没办法，现在还这么干真是没苦硬吃

1. IO 或 CPU 扛不住
2. 服务器硬件问题
3. 网络问题
4. 受到攻击

@me1onsoda #12 微服务有同步通讯(API)和异步通讯(MQ)，如果在高并发下使用异步通讯(MQ)，系统是不会崩溃的，通过微服务伸缩机制能够在秒级快速克隆出几十/上百个容器(微服务)去处理队列，最坏情况就是队列过长 timeout 直接抛弃掉部分。如果微服务使用同步通讯(API)，就和单体区别不大了，高并发延时导致雪崩，重启服务引发更高并发再次崩溃。

朋友公司就是，单体转分布式又转回单体，垂直扩展转水平又转垂直，代码从集中到分开又集中。

不同时期有不同需求，分久必合合久必分。

你们并发多少？

@xhwdy26 #15 CEO 又不会上机直接操刀，“简化部署，只一台机器搞定”，你就一台机器装 docker ，为每个微服务写一个 compose file ，汇报的时候说：已经微服务改成子系统模块了，程序基本不用改。