这是一个创建于 1857 天前的主题，其中的信息可能已经有所发展或是发生改变。
我的观点是微服务从技术上使得每个服务不在和其他服务分享资源，所以更加独立和健壮一点（更分布式一点）
但是，只要有依赖关系我看不出来通过 rpc 调用和直接方法调用有什么区别
诸如吐槽单体应用存在 业务边界模糊，调用关系复杂，难以重构等等问题 难道一个治理的不好的微服务里就不会发生了？ 我们不可以在单体应用中分模块来解决吗？
我们可以在代码层面依然分出来不同的服务在不同的目录下 只是不用 rpc 还按照领域驱动模型拆分出来子模块 按照微服务的思路去治理这个大的单体应用（权限验证 调用关系等等） 每个模块也可以有自己的数据库 而不是一个公用的数据库等等
每个子模块就相当于一个微服务 这样的思路会有什么问题？
但是，只要有依赖关系我看不出来通过 rpc 调用和直接方法调用有什么区别
诸如吐槽单体应用存在 业务边界模糊，调用关系复杂，难以重构等等问题 难道一个治理的不好的微服务里就不会发生了？ 我们不可以在单体应用中分模块来解决吗？
我们可以在代码层面依然分出来不同的服务在不同的目录下 只是不用 rpc 还按照领域驱动模型拆分出来子模块 按照微服务的思路去治理这个大的单体应用（权限验证 调用关系等等） 每个模块也可以有自己的数据库 而不是一个公用的数据库等等
每个子模块就相当于一个微服务 这样的思路会有什么问题？
第 1 条附言 · 2019-10-14 10:54:25 +08:00
总结一下大佬的意见
本质就是我理解的将一段代码的逻辑在多台服务器上执行
为什么要把一段代码拆开到不同的机器上？因为单体应用如果膨胀起来会有单机加载代码太大 部署成本太高 打包速度慢 启动速度等问题（换句话说如果你集群服务器没个上百台，所有代码没有几十上百 G 可以仔细考虑是不是可以不用微服务）
像一些吹逼文章里写的什么测试更方便 我觉得就是错的 什么时候分布式会比单体容易测试了？还有写代码更简单这一点，分布式整体的难度是增加的，自己的业务逻辑是不是清晰和是不是用微服务微乎其微，，，等等
我觉得自己想清楚这个事情了，谢谢大佬
本质就是我理解的将一段代码的逻辑在多台服务器上执行
为什么要把一段代码拆开到不同的机器上？因为单体应用如果膨胀起来会有单机加载代码太大 部署成本太高 打包速度慢 启动速度等问题（换句话说如果你集群服务器没个上百台，所有代码没有几十上百 G 可以仔细考虑是不是可以不用微服务）
像一些吹逼文章里写的什么测试更方便 我觉得就是错的 什么时候分布式会比单体容易测试了？还有写代码更简单这一点，分布式整体的难度是增加的，自己的业务逻辑是不是清晰和是不是用微服务微乎其微，，，等等
我觉得自己想清楚这个事情了，谢谢大佬
第 2 条附言 · 2019-10-14 11:10:53 +08:00
粘一篇刚找到的文章, 我和他的观点一样
https://www.infoq.cn/article/monolith-defense-part-1
> 这篇文章要为单体打一场保卫战。不过事先声明，我所说的单体并不是指那种堆砌了大量代码的单体应用，而是指由多个模块组成的应用。这类应用通常由第三方的开源组件和自己开发的组件组成。这篇文章不打算为老旧的单体撑腰，而是为“模块化单体”打一场保卫战
https://www.infoq.cn/article/monolith-defense-part-1
> 这篇文章要为单体打一场保卫战。不过事先声明，我所说的单体并不是指那种堆砌了大量代码的单体应用，而是指由多个模块组成的应用。这类应用通常由第三方的开源组件和自己开发的组件组成。这篇文章不打算为老旧的单体撑腰，而是为“模块化单体”打一场保卫战
 |
1
petelin OP 我的疑问在于 除了把不同的服务拆分到不同的机器上这件事以外 还有什么是单体应用实在是解决不了的？
如果只有这一个缺点，那大量的博客文章去扯乱七八糟的东西干什么？ |
 |
2
artandlol 2019-10-13 22:02:57 +08:00 via Android
你无非是无聊找个人辩论下罢了。我也觉得 email 也没有比写信更有优势，我的观点是，xxx，请反驳我要铜币
|
 |
3
casparchen 2019-10-13 22:11:33 +08:00  4
一切比较在脱离了上下文的前提下都是毫无意义的，一切优势在不同的环境下都是不确定的。
孙子兵法云：地形有通者，有挂者，有支者，有隘者，有险者，有远者。又云：将通于九变之利者，知用兵矣;将不通于九变之利者，虽知地形，不能得地之利矣。 讲的就是要因地制宜，懂得变通，只有根据环境选择最合适的策略，而不是一成不变。 |
 |
4
murmur 2019-10-13 22:12:31 +08:00
微服务（对于 java ）来说给我的感觉就是拆的更散了，部署的时候可以只重启一部分汤姆猫
|
 |
5
jimages 2019-10-13 22:15:34 +08:00
对于一个具有千人团队的系统，职责的划分可以将更大的团结解构成一个个更小的团队。对于企业级的开发，完全不需要这个东西。但是对于 bat 级别的，需要的。
|
 |
6
Humorce 2019-10-13 22:16:35 +08:00 via iPhone
你的思路是没有问题的
适合的场景用适合的方式 |
 |
7
aaahhh123 2019-10-13 22:25:12 +08:00
面试要用
|
 |
9
est 2019-10-13 22:28:20 +08:00
微服务是大企业用来刷 KPI 的。你以前写我改了一行代码，现在可以写我改了一个微服务模块。。。。
|
|
11
petelin OP @artandlol email 比写信快啊，email 又比微信短信组织形式好更正式一点。这个例子一点水平都没有。
我是想要有个大佬像上面我给你举 email 的优势一样能告诉我除了拆分到机器上。剩下的那些确实在扯淡 |
|
12
petelin OP @est 明白你的意思，那可以确定面经和很多小白文章里写的那些其实是没道理的吗，比如我今天看到的一篇
在分析单体应用缺陷的时候 有种欲加之罪何患无辞的感觉，面试问我这些我真答不上来啊 https://www.zhihu.com/question/65502802/answer/802678798?hb_wx_block=0 |
 |
13
cyaki 2019-10-13 22:33:53 +08:00 via Android 1
更新迭代部署独立出来了，提高了开发效率的嘛
|
 |
14
momocraft 2019-10-13 22:35:01 +08:00 2
成本低的機制一定會被濫用，跨服務亂寫的成本高一點
|
 |
15
lawler 2019-10-13 22:35:20 +08:00 3
前置条件：系统规模！！！
我们业务 300+子系统，少的 2 个人维护，多的上百号人。 例如，用户系统会被其他所有系统使用，这个适合用户系统某个功能出现了 BUG，是不是修复后其余 300+子系统都要更新用户系统模块，打包再部署？牵一发而动全身？ 微服务如其名，分而治之。 关键字：业务，系统群，分而治之。 |
 |
17
YUyu101 2019-10-13 23:47:48 +08:00
本来 1 个人干一个月的活，变成了 10 个人每人干一个礼拜的活，如果你只有一个人当然没必要这样，不然你会干 10 个礼拜的活
|
 |
18
zappos 2019-10-14 00:04:13 +08:00 via Android 1
单机就是有瓶颈啊，一般人的思路是造个更好的机器，但是服务端的最优解是让几个机器像一个机器那样工作。
|
 |
19
nvioue 2019-10-14 00:15:57 +08:00 via Android 2
楼主工作经验不长吧
|
 |
20
1490213 2019-10-14 00:30:52 +08:00 via Android
用一个东西之前可以先了解一下：它是要解决什么样的问题，那些条件下会产生这个问题，在多大程度上解决了这个问题，它的 trade off 是怎么样的，而不是直接脑补有没有优势。
|
 |
21
fox1955 2019-10-14 01:52:10 +08:00
非常正确，微服务只是属于抽象解耦的一个层面: 部署。
解耦分三个层面: 代码，类库，部署。 Robert C. Marti 专家对此有明确的建议: 做好逻辑上的解耦，这样，(如果有必要，比如人员过多，单一部署不便管理)即使(将解耦)从代码层面上升到部署层面，也是非常轻松的。 所以软件质量的核心全在业务的抽象解耦划分上，而不要纠结在所谓微服务什么乱七八糟的东西上面。 具体可参考阅读 <Clean Architecture A Craftsman's Guide to Software Structure and Design> |
 |
22
qqxx520 2019-10-14 07:20:18 +08:00 via iPhone
发明新的名词，大家一拥而上，干的热火朝天，不好吗？否则，老板们会说: IT 部门看不到产出，该节省点了，裁员？
|
 |
23
whileFalse 2019-10-14 07:58:23 +08:00 via iPhone 2
理解不了是因为你没接触到这个量级的业务
|
 |
24
sanmaozhao 2019-10-14 08:52:30 +08:00
还有一个重要的优势：
每个服务可以选择最适合本业务的技术栈，比如编程语言方面有的用 Go、有的用 Java。 单体模式一般都要保持统一的技术栈。 就算是统一的技术栈里面已经有多种编程语言，如果新上的服务想引入新的编程语言也会遇到比较大的阻力。 |
 |
25
MoHen9 2019-10-14 09:04:24 +08:00 via Android
单体架构的服务小一点还好，如果较大，会有很多问题，比如某个模块使用了老的依赖，升级或替换是个问题；模块太多，对于新员工熟悉业务，心智负担也会很重；引入新框架，依赖冲突，需要升级也可能会有问题；启动速度更慢，debug 都烦；这些都还只是开发上的，部署时也不灵活，运行时的监控等，都不如分布式方便。
|
 |
26
huijiewei 2019-10-14 09:08:32 +08:00
然后呢，你因为改了一个模块的内容，所有服务器都编译个新版本部署一次？
|
 |
27
areless 2019-10-14 09:20:14 +08:00 via Android
crossbar.io 一样的概念。就是业务的拆分。方便管理多人维护自己的开发模块。负载方面不是主要的，豆瓣早年的技术文章里讲过，他们用一台服务器扛全国流量的事情。后来 python 就开始流行了。
|
|
28
areless 2019-10-14 09:25:12 +08:00 via Android
你想想 08 年豆瓣，好像是双核 amd 服务器一台。那个服务器可能比现在手机速度还慢很多好不好（笑）
|
 |
29
whp1473 2019-10-14 09:26:40 +08:00
假如你把阿里所有业务写到一个项目里，项目大小 300G，项目占用内存 300G，加载字节码时间 1 小时。。。你感觉吓人不。
还有随着项目规模增大，人员投入和项目效率会呈现反比，划分微服务有利于扩容、维护、和推迟这种情况到到来。当然这是建立在你项目复杂，并且开发人员很多的情况，要是外包或者很少开发人员，就是应该写在一个项目里。 |
 |
30
suikatw 2019-10-14 10:13:44 +08:00
@whp1473 应用拆解这个事情和微服务并没有直接关系，在微服务概念提出之前 BAT 已经有十万级别的项目、应用、git 仓库了。
相反微服务在当前情况下还有副作用需要考虑。服务拆解可以无限细分，但是部署能力的细分是有限度的，管理成本也是有限的，可能造成了机器资源浪费，也增加了管理成本。目前在拆解的粒度上还没有一个统一的指导思想。 比如一个业务拆成了 20 个微服务，这个业务在试跑阶段，可能 2 台 4C8G 的服务器就足够负载了。可当我们设计微服务的部署资源时，我们发现目前成熟的最小微服务部署资源 * 20 份之和，远远大于 2 台 4C8G。这个业务的支撑开发团队可能也只有不到 10 个人，平均每个人要至少负责 2 个微服务，对于人员之间信息互备和管理稳定性也有很大风险。 |
 |
31
fcoolish 2019-10-14 10:16:44 +08:00 1
工作多久了，，有一年了吗？
|
 |
32
maemual 2019-10-14 10:19:19 +08:00 2
？？？建议楼主增加工作经验，或者随便把这两本书看任意一本 ：
《微服务架构设计模式》 https://book.douban.com/subject/33425123/ 《微服务设计》 https://book.douban.com/subject/26772677/ |
 |
33
HowardTang 2019-10-14 10:25:56 +08:00
monorepo 和 multirepo
各有各的優勢 |
 |
34
NoKey 2019-10-14 10:26:05 +08:00
做开发的，不要拘泥于名字
重要原理相通，可以理解为差不多的东西 我觉得微服务体现的更多的就是系统分拆，分开部署 各个服务之间如何通讯什么的，根据实际情况来 现在太多公司，所有服务在一个 war 里，或者在一个 tomcat 里 然后要重启或者重新部署一个服务。。。你懂的。。。 老外经常猛推一些概念什么的，那个是有利益在里面的 做 java 的，了解微服务最多的就是 spring cloud 那一套 别人搞这一套，不吃饭的么。。。 |
 |
35
optional 2019-10-14 10:30:23 +08:00
代码 /人员解耦，状态监控，隔离部署，自动发现都是要优点。
你可以把微服务想象成一个分布式的 ioc, 可以在大部分模块不重启的情况下替换某一个模块。 |
 |
36
sujin190 2019-10-14 10:41:59 +08:00
微服务提高的是开发维护效率，伸缩性提高，业务快速变更适应性明显增强，运行效率必定是降低的，稳定性要求必定更复杂，这不用说啊
|
|
37
petelin OP @optional 最后 ioc 的比喻很好，可是代码人员的解耦难道不做微服务就实现不了了吗？比如我可以采用代码层面的解耦，一个目录就是一个微服务，交由一个团队来管理
状态监控也是可以做的 自动发现如果没有微服务根本不用引入 |
|
38
petelin OP @sujin190 能解释一下相比于多个模块组成的单体应用
"开发维护效率，伸缩性提高，业务快速变更适应性明显增强" 是怎么得出的结论吗? |
|
40
est 2019-10-14 11:18:55 +08:00
@fox1955 其实 monolith 可以单独部署的。。比如 /api/thing/update 和 /api/author/update 两个 api，如果你要单独更新 author，那么新起一个 web 逻辑的进程，然后 nginx 新增加一个路由过去到新进程就行了。
如果有代码调用依赖，也有办法解决。。。 （虽然其实这样其实离微服务就差最后一步 服务化了。。。 |
 |
42
dandycheung 2019-10-14 11:26:53 +08:00 via iPhone 1
@petelin 你的思考精神不错，但到这层楼开始想偏了。不使用微服务当然也可以解耦、分拆、部署、迭代，但是这样的通用需求最后总要落实到某种实现上，而眼下最靠近的技术实践就是微服务架构。当你自己实现了一套体系时，你可以挑战它，而不是以零散的见招拆招式的思维来质疑它。类、库、框架，这些的抽象和构建都是这样的，你当然问出说不调用 strlen 就无法计算字符串长度了吗这样的问题，但是那不是常规理解和思辨的方向。
|
 |
43
firefox12 2019-10-14 11:43:57 +08:00 via iPhone
为什么卡车 客车 轿车 跑车 不做成一个车里面，让车有所有的功能。现在生产真多型号也是浪费。
所以实质就是组合比继承好。但是分散有通讯的代价。这其实又回到了微内核 宏内核一样的问题 微内核更好，但是通讯代价太大了平衡是关系 |
|
44
sujin190 2019-10-14 11:49:22 +08:00
@petelin #38 这不用想吧，多人协作中，至少各业务是分开的微服务组件，修改更新的至少不需要整体等着大半夜统一重启更新吧，单个项目结构更简单，新人来了熟悉难道不更快，反正你又不是大佬一来就负责所有业务
伸缩性更不用说了，那个服务性能不够了，再加几台机器就是了，多简单 业务适应性更新更不用说了，就现在这行情，上个月卖水果，这个月就可能想着做金融的，微服务化的至少你不用担心做新项目的时候还不知道哪把老项目改出 bug 来了吧，老的项目或者直接废弃或者只要不挂扔在那不管就是了，这还不比你单个复杂项目适应性更强？ |
|
45
whp1473 2019-10-14 11:50:55 +08:00 4
@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 解耦合以及填谷消峰。 |
 |
46
exc 2019-10-14 11:54:44 +08:00
可能是职责更清晰、维护更方便吧。我自己做 Android 开发，兼前后端开发，Android 里面就有模块化、插件化开发这个东西，跟后端的微服务其实很像。
做后端的时候，不自觉的就把 Android 的这套开发方式拿过来用了，然后发现原来后端也有类似的概念：微服务。 其实是真的方便，我平时也写些个人 app，后端如果不用微服务，那么每个 app 都要搞一套用户系统，很麻烦的，如果用户系统独立出来作为一个服务，就非常爽了。 我觉得微服务、模块化、插件化、库、SDK 等等，概念都差不多，只是场景不同，名称各异。 站在开发的角度，同一功能编译成一个库，到处使用，能理解，那么微服务就是站在产品的角度，同一功能独立成一个服务，到处使用，感觉两者差不多。 |
 |
47
wc951 2019-10-14 12:07:01 +08:00 via Android 1
没有微服务之前也有 soa 了啊，服务化口号喊了十几年了吧
|
 |
48
uleh 2019-10-14 12:15:38 +08:00
说明你还年轻😏
|
 |
49
jadec0der 2019-10-14 13:08:09 +08:00 1
|
 |
51
jsq2627 2019-10-14 14:52:49 +08:00 1
1. 职责拆分，便于团队横向扩展
2. 部署隔离，避免改个小 bug 要重启整个巨型应用，还有给横向伸缩的提供便利 3. 技术方案隔离，A 服务可以用一种框架写，B 服务又可以用另一种框架写，甚至引入其他编程语言 4. 故障隔离，A 服务崩溃只会影响自己，一般不会导致整个应用崩溃 |
 |
52
xuanbg 2019-10-14 15:05:44 +08:00 1
我司是一家互联网小厂，业务规模也比较小。这是背景
微服务在我司的实践也有 2 年多了，和单体架构相比，好处还是不少的。最大的好处，就是业务复杂度的降低。刚入职的新人我就敢让他独立负责一个新项目，只要花几分钟了解我们的项目模板，就能直接上手，真正做到了只需要关注业务。其余的例如方便水平扩展，局部更新，项目组织灵活等等就不多说了。 在实践中，最大的问题是服务边界的界定问题。总有人见风就是雨，看问题只看表面，不能把代码写对地方。其实这个问题在单体架构中也是存在的，模块没有边界，代码到处乱写也很常见。单体架构设计不好，微服务照样搞不好。 |
 |
53
lihongjie0209 2019-10-14 15:45:22 +08:00
|
|
54
lihongjie0209 2019-10-14 15:49:14 +08:00
取决于你的团队规模和项目规模。一个小组能做完的项目搞微服务就是闲得蛋疼
|
 |
55
anmie 2019-10-14 15:56:30 +08:00
你既然叫微服务架构了，那么架构其实有一个概念：解决未来的问题。
|
 |
56
l00t 2019-10-14 17:55:15 +08:00
系统不大到一定程度是没必要用微服务的。用了微服务，也不要拆太多太碎。一个程序显然比多个程序更方便调试。微服务能让业务复杂度降低的观点简直搞笑。
|
Select Language