从微服务走向单体化

一般性来讲最佳实践是先上单体，然后在某个也许永远不会到来的节点升级成微服务。
spring 有一个 modulith 项目解决单体模块化的问题，也就是为微服务铺路。
微服务崩一个需要良好的架构设计，不然就是全都崩，没区别的。
性能问题前面讲了很多了，如果抛开软件层面的水平差异，硬件部分只是 scale up 和 scale out 的区别，注意是区别，而非高低。
开发管理（比如代码分支管理，基础设施）问题取决于你们团队的成熟度（或者说平均开发水平），自动化，devops ，devex 这些都和架构无关。
所以最根本的不是微服务架构和单体架构，而是需要一个良好的架构设计。
成功的架构是从你们团队中生长出来的，而非 copy 出来的。
真理越辩越明。

微单体？新出的照相机吗？

好奇怎么好多在说并发的？单体服务，又不是只部署一台服务器🤣🤣🤣如果业务不是特别复杂，单体没啥问题，🈶性能问题，升级服务器就行

主要是内存 爆


数据库连接也会到上限,但估算好了不多,而且这个不会奔溃,只是提示异常

确实很多业务根本没到依赖微服务才能 hold 住的地步，但你们这不是从 0 做起，为了解决发布繁琐的问题而要把微服务合并这是个昏招，不是应该优化一下你们的 cicd 流程吗

@whusnoopy 大公司的单 repo 不是一般的单 repo 啊，别人的版本管理整个从存储到网络都是自主开发的一套软件去做的

看得有点血压高, 实际上微服务并不是一个良好的架构,微服务也不是高性能的代表, 微服务纯粹增加开发复杂度,增加调试的复杂度
1,开发模块问题 6 楼已经说的很清楚了
2,扩展伸缩是 devops 的范畴, 单体也能方便的横向扩展
3,扩展的实例信号同步通过 redis 实现
4,队列使用基础设施的 mq, 楼上有人说单体不能用 mq 的情况,真的用过 mq 吗
5,有人说单体崩了就全完了, 但举的例子也只是 mq 积压导致服务不可用, 跟单体或者微服务又没关系
6,很多人说的所谓的崩溃,cpu 占用高,内存占用高,跟单体或者微服务真的没关系, 反而是依靠项目整体生命周期里的 devops 架构,运维, 跟 CICD, 测试, 实时观测, 监控关系更大点

42 楼 项目开发上的代码冲突是 git 管理的范畴,分 module 后一般不会遇到冲突. 单体会降低启动时间, 而且在 module 里可以控制启动哪些模块, 关闭哪些模块, 在调试的时候更方便. 拉分支也是 git 的范畴, 跟单体或者微服务也没关系

最后说下 OP 能遇到从微服务回归单体的项目就偷着乐吧, 不然十来个微服务(用户、订单、后台、网关等）你后面加不完的班, 线上出问题调试恶心死你

怎么组织 module 到一个项目里可以参考这个项目, https://gitee.com/zhijiantianya/ruoyi-vue-pro

如何合并成单体，几个人同时在一个项目上开发的冲突怎么解决？
按领域分目录，不同业务领域归到不同的目录和包

如果合并成单体，启动时间会增加，开发调试不方便，怎么面对这个问题？
并行启动和懒加载，优化启动时间，通过配置调试的时候按需初始化

如果合并成单体，某个模块要拉分支，应该怎么处理这个问题？
按业务分模块，然后业务只能改自己模块的，然后按协作方式和版本来管理分支

大部分公司的微服务应用都是微服务单体，都是一个实例，共用一个数据库，组件没有好可用，瞎拆分

无法理解，你这么迷信微服务，很多公司的系统，用户量不高，并发也不高，业务也不复杂，如果用微服务，简直就是给自己找麻烦。

最近遇到一个小规模系统甲方非 tm 要做成微服务,估计从哪儿听到这个名词就非要上

微服务，如果就是把服务拆一下，各部署各的，这其实还好，要真的引入网上那种概念，真正的微服务，每个微服务部署 n 个节点那种，一般的小厂抗的住么？机器，运维，开发，架构，要引入一大堆增加成本的东西。。。最后技术负责人说：我们没有那么多钱，一个服务一把梭好了。。。。

之前一直在关注 Google 搞得 Service Weaver 框架（ https://serviceweaver.dev/docs.html ），单体分模块的开发形式和项目结构，在框架内部集成分布式弹性部署以及 grpc 调用代码，可单体可分布式。可惜不维护了。。。

@extrem #86

大公司也没有那么神，比如 Google 内部用的 g4 就是 p4 魔改过的，主要改的还是性能，像 OP 提到的这些问题都不是版本管理软件能解决的问题

单一 repo 提交前需要拉主干确认没有跟其他人的冲突，用 g4 还是 git 并没有区别，这就是单一主干开发模式要求的（某种程度上这也鼓励大家积极提交，并且做好隔离，不然自己憋个大版本，提交前处理主干演进过程中带来的冲突都要合哭）

不同模块的代码修改权限和冲突后的解决办法，也是在项目管理侧做的，不是版本控制软件能管理的，最多是有分模块或文件的 owner 机制，如果 owner 不同意是合不进去的

话说天下大势 分久必合 合久必分

不要迷信微服务，现在 Java 的性能不弱，而且做水平扩展和负载均衡，跟微服务也无关。而且单体服务的性能一定是要强于微服务的，方法调用和远程调用哪个更快？

微服务的诞生和敏捷开发的模式有很强的相关性，各个团队的服务在开发层面互不干扰，至少不会天天去解冲突。但如果就你们一波人在做，核心业务也只有一个，那完全没必要为了微服务而微服务

@mbeoliero123 增加硬件，扛得住，早期 uber,几千万都是单体。

国内大部分的公司业务一个单体就搞定了，顶多搞个集群，跟风拆分就是提裤子放屁

现在很多公司之前一段搞所谓的微服务,分布式，结果用户没有微服务多。现在都来还技术债了。这玩意，看别人上，自己也上，不知道是真傻还是真坏。