仔细想想，微服务架构相比于单体服务架构来讲优势也没有很大

[petelin]

我的观点是微服务从技术上使得每个服务不在和其他服务分享资源，所以更加独立和健壮一点（更分布式一点）

但是，只要有依赖关系我看不出来通过 rpc 调用和直接方法调用有什么区别
诸如吐槽单体应用存在 业务边界模糊，调用关系复杂，难以重构等等问题 难道一个治理的不好的微服务里就不会发生了？ 我们不可以在单体应用中分模块来解决吗？

我们可以在代码层面依然分出来不同的服务在不同的目录下 只是不用 rpc 还按照领域驱动模型拆分出来子模块 按照微服务的思路去治理这个大的单体应用（权限验证 调用关系等等） 每个模块也可以有自己的数据库 而不是一个公用的数据库等等

每个子模块就相当于一个微服务 这样的思路会有什么问题？

[petelin]

我的疑问在于 除了把不同的服务拆分到不同的机器上这件事以外 还有什么是单体应用实在是解决不了的？

如果只有这一个缺点，那大量的博客文章去扯乱七八糟的东西干什么？

[artandlol]

你无非是无聊找个人辩论下罢了。我也觉得 email 也没有比写信更有优势，我的观点是，xxx，请反驳我要铜币

[casparchen]

一切比较在脱离了上下文的前提下都是毫无意义的，一切优势在不同的环境下都是不确定的。
孙子兵法云：地形有通者，有挂者，有支者，有隘者，有险者，有远者。又云：将通于九变之利者，知用兵矣;将不通于九变之利者，虽知地形，不能得地之利矣。
讲的就是要因地制宜，懂得变通，只有根据环境选择最合适的策略，而不是一成不变。

[murmur]

微服务（对于 java ）来说给我的感觉就是拆的更散了，部署的时候可以只重启一部分汤姆猫

[jimages]

对于一个具有千人团队的系统，职责的划分可以将更大的团结解构成一个个更小的团队。对于企业级的开发，完全不需要这个东西。但是对于 bat 级别的，需要的。

[Humorce]

你的思路是没有问题的

适合的场景用适合的方式

[aaahhh123]

面试要用

[petelin]

@jimages 同意

[est]

微服务是大企业用来刷 KPI 的。你以前写我改了一行代码，现在可以写我改了一个微服务模块。。。。

[fff333]

@murmur 雄猫

[petelin]

@artandlol email 比写信快啊，email 又比微信短信组织形式好更正式一点。这个例子一点水平都没有。
我是想要有个大佬像上面我给你举 email 的优势一样能告诉我除了拆分到机器上。剩下的那些确实在扯淡

[petelin]

@est 明白你的意思，那可以确定面经和很多小白文章里写的那些其实是没道理的吗，比如我今天看到的一篇
在分析单体应用缺陷的时候 有种欲加之罪何患无辞的感觉，面试问我这些我真答不上来啊
https://www.zhihu.com/question/65502802/answer/802678798?hb_wx_block=0

[cyaki]

更新迭代部署独立出来了，提高了开发效率的嘛

[momocraft]

成本低的機制一定會被濫用，跨服務亂寫的成本高一點

[lawler]

前置条件：系统规模！！！

我们业务 300+子系统，少的 2 个人维护，多的上百号人。
例如，用户系统会被其他所有系统使用，这个适合用户系统某个功能出现了 BUG，是不是修复后其余 300+子系统都要更新用户系统模块，打包再部署？牵一发而动全身？

微服务如其名，分而治之。


关键字：业务，系统群，分而治之。

[petelin]

@cyaki 嗯嗯 这个是优点 记下了

[YUyu101]

本来 1 个人干一个月的活，变成了 10 个人每人干一个礼拜的活，如果你只有一个人当然没必要这样，不然你会干 10 个礼拜的活

[zappos]

单机就是有瓶颈啊，一般人的思路是造个更好的机器，但是服务端的最优解是让几个机器像一个机器那样工作。

[nvioue]

楼主工作经验不长吧

[1490213]

用一个东西之前可以先了解一下：它是要解决什么样的问题，那些条件下会产生这个问题，在多大程度上解决了这个问题，它的 trade off 是怎么样的，而不是直接脑补有没有优势。