为什么基于 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 所以具体是哪个开源项目 方便介绍下吗？对这个比较感兴趣。