• 为什么基于 Spring Boot 的项目大多采用微服务架构,而较少用于单体应用开发?
  • 发布于 8小时前
  • 14 热度
    4 评论
做了这么多年的项目,发现 Java 开发人员基于 Springboot 开发的项目,基本上都是微服务架构的居多,而使用它构建单体应用的案例却不多见。什么原因?一起探讨一下。
用户评论
  • 一饮茶尽
  • 你们不需要维护企业网站的吗?都这么幸福的吗?为了提高企业形象、给用户增加新鲜感,现在决定给网站改头换面弄个时髦的新样式。几个开发老哥一合计,老网站用了这么多年的 jsp ,咱们是不是也得与时俱进一下,这样万一哪天公司混不下去了也不至于找不到工作不是》


    按照目前公司的人员配置,java 这语言是肯定不能换的,不然出问题搞不定大家一窝端。说是做新网站,但一直有需求在提,停下来不改是不可能的,而且老站五六七八年下来,代码结构早就混乱不堪,趁这机会整理一下,但等新站做好,需求早就不知道变了多少版本了,到时候怎么把业务功能同步过去也是个大问题。


    这时候,如果搜索功能是一个微服务,那是不是需求变更相当于新老网站同时被修改了?
    如果用户相关的功能同样如此呢?
    那订单系统是不是也能通过这种方式受益呢?
    原本客户信息的查询只能在网站后台进行,同样的功能在报表系统中需要把代码复制过去
    拆分成微服务之后,发现直接调用 api 就好,再也不用两边改代码了,那这是不是优点?

    微服务这东西确确实实的解决了需要长期运维项目的维护痛点,如果你觉得它仅仅是个水工作量的玩意那就是你对,层次没到懒得逼逼。
  • 2025/10/30 8:44:00 [ 0 ] [ 0 ] 回复
  • 笑眼深邃
  • 因为很难对单体服务划分职责,你可能没在大公司干过,无法理解跨部门、跨公司在超大型项目协作上会遇到什么难题。代码没写几行,整天就在分锅扯头皮了,比菜市场还乱。微服务可以明确划分物理与逻辑边界,减少人员摩擦与管理成本。不过微服务被大量滥用就是另一回事了。一切都是有代价的,微服务的几百字营销用语懒得复述,缺点是性能差、请求时间长,光是链路追踪、海量日志处理、分布式事务就带来无穷隐患,中小厂基本只能买现成服务。


    如果把`微服务`当做一件商品,那许多事情就会有合理的解释。一件商品自然会有适合的用户,但为了赚取更多利润,销售们会把它强硬推销给不适合的用户,包装上好看的外观,精心润笔,夸张地讲述好处,对坏处闭口不谈,与卖保险的没有区别。拿你经常推销的 thinystruct 举例,你认为它适合所有用户吗,假如推广这个框架有利可图,你会做相同的选择吗?
  • 2025/10/30 8:41:00 [ 0 ] [ 0 ] 回复
  • 长夜漫漫
  • 其实很多项目是不需要微服务架构的,但中层领导想做出政绩,高层领导又喜欢听一些装逼的名词,所以就形成了 "万物皆微服务架构" 的局面。比如:把几个人使用的后台管理系统拆成了 6 个微服务模块,然后把模块拆分取个装逼的名字,叫 "达芬奇架构",把集群部署取个装逼的名字,叫 "多副本矩阵集群"......
  • 2025/10/30 8:31:00 [ 0 ] [ 0 ] 回复