为什么基于 Spring Boot 的项目大多采用微服务架构，而较少用于单体应用开发？

其实很多项目是不需要微服务架构的，但中层领导想做出政绩，高层领导又喜欢听一些装逼的名词，所以就形成了 "万物皆微服务架构" 的局面。

比如：把几个人使用的后台管理系统拆成了 6 个微服务模块，然后把模块拆分取个装逼的名字，叫 "达芬奇架构"，把集群部署取个装逼的名字，叫 "多副本矩阵集群"......

根本原因就是能升 title

没什么可探讨的，1 、2 楼就是正确答案，咱们就是什么热门就 All in 什么，现在就是 All in AI 。

在职场中，除了 java 的微服务可以吹一吹，其他的还有什么能吹的吗？

因为很难对单体服务划分职责，你可能没在大公司干过，无法理解跨部门、跨公司在超大型项目协作上会遇到什么难题。
代码没写几行，整天就在分锅扯头皮了，比菜市场还乱。
微服务可以明确划分物理与逻辑边界，减少人员摩擦与管理成本。

不过微服务被大量滥用就是另一回事了。
一切都是有代价的，微服务的几百字营销用语懒得复述，缺点是性能差、请求时间长，光是链路追踪、海量日志处理、分布式事务就带来无穷隐患，中小厂基本只能买现成服务。
如果把`微服务`当做一件商品，那许多事情就会有合理的解释。一件商品自然会有适合的用户，但为了赚取更多利润，销售们会把它强硬推销给不适合的用户，包装上好看的外观，精心润笔，夸张地讲述好处，对坏处闭口不谈，与卖保险的没有区别。
拿你经常推销的 thinystruct 举例，你认为它适合所有用户吗，假如推广这个框架有利可图，你会做相同的选择吗？

@midsolo #1

确实是语言的艺术，有些通俗易懂的概念换个词就感觉非常神秘。

@midsolo
是的，架构人员基本上都说了不算。一个后台管理动不动就是 VUE/react 再搞几个微服务，写的七零八落的。我倒是推荐过一个世界 500 强都在用的开源项目，最后反而被下面的一个小领导给挤掉了，搞了几年。队伍倒是挺大的。
@RightHand 嗯，也可以扩大团队规模，解决就业问题。

哥们，你不行上个班吧

@peteretep 感谢，先 block 了

你们不需要维护企业网站的吗？都这么幸福的吗？
为了提高企业形象、给用户增加新鲜感，现在决定给网站改头换面弄个时髦的新样式
几个开发老哥一合计，老网站用了这么多年的 jsp ，咱们是不是也得与时俱进一下，这样万一哪天公司混不下去了也不至于找不到工作不是
按照目前公司的人员配置，java 这语言是肯定不能换的，不然出问题搞不定大家一窝端
说是做新网站，但一直有需求在提，停下来不改是不可能的，而且老站五六七八年下来，代码结构早就混乱不堪，趁这机会整理一下
但等新站做好，需求早就不知道变了多少版本了，到时候怎么把业务功能同步过去也是个大问题
这时候，如果搜索功能是一个微服务，那是不是需求变更相当于新老网站同时被修改了？
如果用户相关的功能同样如此呢？
那订单系统是不是也能通过这种方式受益呢？
原本客户信息的查询只能在网站后台进行，同样的功能在报表系统中需要把代码复制过去
拆分成微服务之后，发现直接调用 api 就好，再也不用两边改代码了，那这是不是优点？

微服务这东西确确实实的解决了需要长期运维项目的维护痛点
如果你觉得它仅仅是个水工作量的玩意那就是你对，层次没到懒得逼逼

感谢，先 block 了

@Ketteiron 你说的有道理，一切选择背后都是有动机并牵动着各方的利益，才做出的选择。

tinystruct 框架得另当别论了，因为我没有任何想通过开源谋利的想法，只是一种个人分享而已。有的人不信，我也不必做解释。曾有海外的同事认为这个框架不错，问我为什么不在团队内部项目推荐一下这个框架，我没有同意，我觉得没有必要利用自己的权威去影响团队，在社区推广都能看到各种排斥的声音，内部团队不反对也不代表他们接受不是出于勉强的。

实在不行，找个班上。

技术架构都是组织架构的体现

真的没人管管这个人？ 发的问题全是引战贴，就为了宣传他的开源项目，不折手段，真的很影响观感，光 block 已经解决不了问题了

@moverinfo #8 我倒是推荐过一个世界 500 强都在用的开源项目

请问这个项目是 tinystruct 吗？

@crossoverJie 肯定不是啊，这里有部分人总以为我在推广，貌似我只要提个话题就是在推广，哪怕我都没有提，他的想象力都能驱使他往推广上靠，really crazy! 请不要受影响了哈！

@moverinfo #19 所以具体是哪个开源项目 方便介绍下吗？对这个比较感兴趣。

@crossoverJie Drupal ，你可以去官网上看 drupal.org ，非常棒的一个 CMF ，生态非常成熟。我们很多项目的后台都是用的这个落地的。RBAC 设计的一流，跟企业平台集成相当容易。不过国内大概不受欢迎。

康威定律：任何设计系统的组织，其产出的系统设计，必然反映出该组织的沟通结构

不是系统需要微服务，人需要

@flyqie

不是开玩笑，以前公司招了个某里系出来的 p8 ，发明了 20 多个装逼名词，把领导忽悠的一愣一愣的。

随便列出来几个：微内核悬浮架构（通过 SPI 扩展的 Plugin 工具包）、多棱镜架构（ API 网关）、达芬奇架构（单体服务拆分）、矩阵架构（多实例部署形成的集群）、DDD 乐高架构（可以自动装配的组件库）......

中华文化博大精深，同样的东西换个名字，就会显得很高端，那些不懂技术的高层领导就吃这一套。

如果你用 android 的话 你手机上肯定有一个 app 里面有不少于 5 个图片选择器

@midsolo 同在的人有跑的程多

有没有比我们更草台班子的小公司，全是单体，直接 java -jar

@abc0123xyz
要是量再大的话，就 copy 几份，然后 java -jar ......

@abc0123xyz 啥 做的多了去了

很多项目其实并不需要微服务，单体可能更适合

真的是“微”服务，而不是普通服务化吗，微服务的反面不是单体，中间还有服务化过渡呢

要说原因，项目人员多了就会拆分，而且互相之间就会有分布式调用，但不一定就是微服务

@peteretep 这家伙，天天翻墙刷 JAVA ，也是牛批。

还是看应用负责人的。 我也见过大公司里有持续迭代的巨无霸的单体应用。

@moverinfo 世界 500 强...这在 IT 领域可不是什么技术先进的代名词

因为写 java 的不这么搞 没法开发要工资 都是生意

还真不是，中小公司有几个上微服务的，有几个的业务能上微服务的，不是自己给自己找事做么？
前些年公司有个项目，技术负责人图时髦嘛，和老板吹微服务架构怎么怎么好，要让上 Spring Cloud 大全套，最后项目启动的时候配 2 个后端开发来搞，微服务个毛线

有吗？没看到数据，反正我就是单体开发，入职时整过一个，后面就没用过微服务了。就算调用也是 http

顺便说个事，我完全阻止不了同事每个项目都用 mybatis-plus ，这玩意应该已经在鄙视链底端了吧