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

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

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

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

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

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

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

你的思路是没有问题的

适合的场景用适合的方式

面试要用

@jimages 同意

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

@murmur 雄猫

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

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

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

成本低的制一定被用，跨服的成本高一

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

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

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


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

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

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

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

楼主工作经验不长吧

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

非常正确，微服务只是属于抽象解耦的一个层面: 部署。
解耦分三个层面: 代码，类库，部署。

Robert C. Marti 专家对此有明确的建议: 做好逻辑上的解耦，这样，(如果有必要，比如人员过多，单一部署不便管理)即使(将解耦)从代码层面上升到部署层面，也是非常轻松的。

所以软件质量的核心全在业务的抽象解耦划分上，而不要纠结在所谓微服务什么乱七八糟的东西上面。

具体可参考阅读 <Clean Architecture A Craftsman's Guide to Software Structure and Design>

发明新的名词，大家一拥而上，干的热火朝天，不好吗？否则，老板们会说: IT 部门看不到产出，该节省点了，裁员？

理解不了是因为你没接触到这个量级的业务

还有一个重要的优势：
每个服务可以选择最适合本业务的技术栈，比如编程语言方面有的用 Go、有的用 Java。
单体模式一般都要保持统一的技术栈。
就算是统一的技术栈里面已经有多种编程语言，如果新上的服务想引入新的编程语言也会遇到比较大的阻力。

单体架构的服务小一点还好，如果较大，会有很多问题，比如某个模块使用了老的依赖，升级或替换是个问题；模块太多，对于新员工熟悉业务，心智负担也会很重；引入新框架，依赖冲突，需要升级也可能会有问题；启动速度更慢，debug 都烦；这些都还只是开发上的，部署时也不灵活，运行时的监控等，都不如分布式方便。

然后呢，你因为改了一个模块的内容，所有服务器都编译个新版本部署一次？

crossbar.io 一样的概念。就是业务的拆分。方便管理多人维护自己的开发模块。负载方面不是主要的，豆瓣早年的技术文章里讲过，他们用一台服务器扛全国流量的事情。后来 python 就开始流行了。

你想想 08 年豆瓣，好像是双核 amd 服务器一台。那个服务器可能比现在手机速度还慢很多好不好（笑）

假如你把阿里所有业务写到一个项目里，项目大小 300G，项目占用内存 300G，加载字节码时间 1 小时。。。你感觉吓人不。
还有随着项目规模增大，人员投入和项目效率会呈现反比，划分微服务有利于扩容、维护、和推迟这种情况到到来。当然这是建立在你项目复杂，并且开发人员很多的情况，要是外包或者很少开发人员，就是应该写在一个项目里。

@whp1473 应用拆解这个事情和微服务并没有直接关系，在微服务概念提出之前 BAT 已经有十万级别的项目、应用、git 仓库了。
相反微服务在当前情况下还有副作用需要考虑。服务拆解可以无限细分，但是部署能力的细分是有限度的，管理成本也是有限的，可能造成了机器资源浪费，也增加了管理成本。目前在拆解的粒度上还没有一个统一的指导思想。
比如一个业务拆成了 20 个微服务，这个业务在试跑阶段，可能 2 台 4C8G 的服务器就足够负载了。可当我们设计微服务的部署资源时，我们发现目前成熟的最小微服务部署资源 * 20 份之和，远远大于 2 台 4C8G。这个业务的支撑开发团队可能也只有不到 10 个人，平均每个人要至少负责 2 个微服务，对于人员之间信息互备和管理稳定性也有很大风险。

工作多久了，，有一年了吗？

？？？建议楼主增加工作经验，或者随便把这两本书看任意一本 ：
《微服务架构设计模式》 https://book.douban.com/subject/33425123/
《微服务设计》 https://book.douban.com/subject/26772677/

monorepo 和 multirepo
各有各的

做开发的，不要拘泥于名字
重要原理相通，可以理解为差不多的东西
我觉得微服务体现的更多的就是系统分拆，分开部署
各个服务之间如何通讯什么的，根据实际情况来
现在太多公司，所有服务在一个 war 里，或者在一个 tomcat 里
然后要重启或者重新部署一个服务。。。你懂的。。。
老外经常猛推一些概念什么的，那个是有利益在里面的
做 java 的，了解微服务最多的就是 spring cloud 那一套
别人搞这一套，不吃饭的么。。。

代码 /人员解耦，状态监控，隔离部署，自动发现都是要优点。

你可以把微服务想象成一个分布式的 ioc, 可以在大部分模块不重启的情况下替换某一个模块。

微服务提高的是开发维护效率，伸缩性提高，业务快速变更适应性明显增强，运行效率必定是降低的，稳定性要求必定更复杂，这不用说啊

@optional 最后 ioc 的比喻很好，可是代码人员的解耦难道不做微服务就实现不了了吗？比如我可以采用代码层面的解耦，一个目录就是一个微服务，交由一个团队来管理
状态监控也是可以做的
自动发现如果没有微服务根本不用引入

@sujin190 能解释一下相比于多个模块组成的单体应用
"开发维护效率，伸缩性提高，业务快速变更适应性明显增强" 是怎么得出的结论吗?

@cyaki monolith monorepo 都可以单模块部署、单独更新。

@fox1955 其实 monolith 可以单独部署的。。比如 /api/thing/update 和 /api/author/update 两个 api，如果你要单独更新 author，那么新起一个 web 逻辑的进程，然后 nginx 新增加一个路由过去到新进程就行了。

如果有代码调用依赖，也有办法解决。。。

（虽然其实这样其实离微服务就差最后一步 服务化了。。。

@petelin 不仅仅是开发，还有上线、测试流程的解耦， 如果在一个大程序里，只能依赖固定的部署周期来解决上线问题。

@petelin 你的思考精神不错，但到这层楼开始想偏了。不使用微服务当然也可以解耦、分拆、部署、迭代，但是这样的通用需求最后总要落实到某种实现上，而眼下最靠近的技术实践就是微服务架构。当你自己实现了一套体系时，你可以挑战它，而不是以零散的见招拆招式的思维来质疑它。类、库、框架，这些的抽象和构建都是这样的，你当然问出说不调用 strlen 就无法计算字符串长度了吗这样的问题，但是那不是常规理解和思辨的方向。

为什么卡车 客车 轿车 跑车 不做成一个车里面，让车有所有的功能。现在生产真多型号也是浪费。

所以实质就是组合比继承好。但是分散有通讯的代价。这其实又回到了微内核 宏内核一样的问题 微内核更好，但是通讯代价太大了平衡是关系

@petelin #38 这不用想吧，多人协作中，至少各业务是分开的微服务组件，修改更新的至少不需要整体等着大半夜统一重启更新吧，单个项目结构更简单，新人来了熟悉难道不更快，反正你又不是大佬一来就负责所有业务
伸缩性更不用说了，那个服务性能不够了，再加几台机器就是了，多简单
业务适应性更新更不用说了，就现在这行情，上个月卖水果，这个月就可能想着做金融的，微服务化的至少你不用担心做新项目的时候还不知哪把老项目改出 bug 来了吧，老的项目或者直接废弃或者只要不挂扔在那不管就是了，这还不比你单个复杂项目适应性更强？

@suikatw 以前一般用服务总线，其实就是现在微服务的雏形。你说 BAT 大项目，在洪荒时代，也不是一个项目跑的。。。他们也会划分项目的，那时候一般比较粗糙，没有注册中心、调用链监控、RPC 模块、协议一般也都是 HTTP，关于重试和降级策略一般都是自己写在项目里，把这些抽离出来就是 RPC 框架。有些说的也对，最最开始的确一个项目，京东以前还是 Asp.net 。。。然后前面挂负载均衡，报错有时候你还能看到 Asp.net 把异常堆栈抛到前端。。。

至于你说分目录，优点不说了，说缺点：
(1)随人员变动、项目扩大，你很难维持现有的结构。git 冲突 版本管理也是很难解决的问题。比如我写完了这个模块要上，但是别人需要依赖前一个版本，你需要等。你用 Dubbo 可以通过 group version 解决，可以同时支持多版本开发。
(2)只要有修改别人代码的可能，就一定会发生。所以专注自己系统，不会给多余的权限
(3)一个简单 BUG 的修改都将导致服务重新发布，并且编译和发布时间成本巨大，在发布时，容易造成故障，压力激增
(4)这种结构容易造成雪崩，一般的，比如物流系统故障，订单已经下达，可以通过 MQ 重试机制保障物流恢复后系统自动恢复。而单点一旦崩溃，将导致整个系统不可用，数据无法进入，也不可能恢复。
(5)项目实践会告诉你，随人的增加沟通成本会越来越大，最后新增加的人的效率将不足以弥补沟通成本。解决方式就是系统拆分，专注自己的系统。
(6)至于机器占有资源问题，那是因为你预估有问题，没有计算你需要的 QPS 和机器资源。估计都是差不多直接上去。另一方面，当系统使用人数增加后，比如看东西的人很多，但是买的很少，那我可以扩容商品模块，而不需要对订单系统进行扩容，系统大了资源消耗反而降低。
(7)维护成本增加是必然的，但可以通过技术去解决 HSF、Dubbo、SpringCloud，以及之后的服务网格都是在解决成本问题
(8)服务不是无限拆分的，一般系统确定时，系统设计这个阶段要占用 50%时间，划分领域。要注意事务尽量属于自己所属领域，避免跨服务的分布式事务以及跨库事务。

没有最完美的架构，具体问题具体分析，要不然要这么贵的开发和架构干嘛：
(1)你要是外包项目或者中小项目，或者人数少，那就一个项目跑呀。
(2)如果你项目开始就定位比较大，比如目标是全中国用户，那开始架构时就应该考虑到微服务的形式
也可以渐进式演化，BAT 京东 这些最初都是一个项目跑的，有钱时再慢慢变成了领域模型内切分，各个服务高内聚，低耦合，用 MQ 解耦合以及填谷消峰。

可能是职责更清晰、维护更方便吧。我自己做 Android 开发，兼前后端开发，Android 里面就有模块化、插件化开发这个东西，跟后端的微服务其实很像。

做后端的时候，不自觉的就把 Android 的这套开发方式拿过来用了，然后发现原来后端也有类似的概念：微服务。

其实是真的方便，我平时也写些个人 app，后端如果不用微服务，那么每个 app 都要搞一套用户系统，很麻烦的，如果用户系统独立出来作为一个服务，就非常爽了。

我觉得微服务、模块化、插件化、库、SDK 等等，概念都差不多，只是场景不同，名称各异。

站在开发的角度，同一功能编译成一个库，到处使用，能理解，那么微服务就是站在产品的角度，同一功能独立成一个服务，到处使用，感觉两者差不多。

没有微服务之前也有 soa 了啊，服务化口号喊了十几年了吧

说明你还年轻

软件架构是组织结构的映射，推荐阅读： http://insights.thoughtworkers.org/microservices-docker-organization-transfermation/

@jadec0der 多谢,之前听过这个观点.
ps: 想关注你的时候发现已经关注了.

1. 职责拆分，便于团队横向扩展
2. 部署隔离，避免改个小 bug 要重启整个巨型应用，还有给横向伸缩的提供便利
3. 技术方案隔离，A 服务可以用一种框架写，B 服务又可以用另一种框架写，甚至引入其他编程语言
4. 故障隔离，A 服务崩溃只会影响自己，一般不会导致整个应用崩溃

我司是一家互联网小厂，业务规模也比较小。这是背景
微服务在我司的实践也有 2 年多了，和单体架构相比，好处还是不少的。最大的好处，就是业务复杂度的降低。刚入职的新人我就敢让他独立负责一个新项目，只要花几分钟了解我们的项目模板，就能直接上手，真正做到了只需要关注业务。其余的例如方便水平扩展，局部更新，项目组织灵活等等就不多说了。
在实践中，最大的问题是服务边界的界定问题。总有人见风就是雨，看问题只看表面，不能把代码写对地方。其实这个问题在单体架构中也是存在的，模块没有边界，代码到处乱写也很常见。单体架构设计不好，微服务照样搞不好。


取决于你的团队规模和项目规模。一个小组能做完的项目搞微服务就是闲得蛋疼

你既然叫微服务架构了，那么架构其实有一个概念：解决未来的问题。

系统不大到一定程度是没必要用微服务的。用了微服务，也不要拆太多太碎。一个程序显然比多个程序更方便调试。微服务能让业务复杂度降低的观点简直搞笑。