这是一个创建于 630 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
seakingii 2023-03-12 15:06:30 +08:00
微服务,又不是只运行一个实例,会运行 N 多个实例,挂了一个,其它的先撑住,挂掉的自动修复
微服务需要一整套的工具来辅助服务治理的,包括部署,监控等等 最大的好处,在我看来是职责单一,以及由职责单一带来的附加好处,比如小团队,易扩展,多语言等等 |
 |
2
hyuka 2023-03-12 15:08:34 +08:00 via iPhone
1.如果是支付挂了，这种应该只是支付不了其它不影响
2.微服务单个服务出问题只需要解决这一个服务的问题，重启回退修 bug,整个服务分成若干服务后肯定比回退重启整个服务要好 3.不同人负责不同微服务，不用关注整个项目的细节，只需关注自己负责的部分的细节以及相关交互 大概想到这些。 工作中，尤其线上的服务都是=(不让随便动的，服务不划分全扔一块，出问题了重启或者部署整个大服务，想想就头大。改动越小越好。 |
|
4
hyuka 2023-03-12 15:11:03 +08:00 via iPhone
服务挂了，也是
多个实例，单个挂了其他可以先撑住，要是因为请求多还可以通过添加实例的方式暂时处理 |
 |
5
lhx2008 2023-03-12 15:13:59 +08:00
从开发角度来说，一两个人开发只需要单体，十个人开发就要微服务了，要不然怎么调怎么发版
|
|
6
hyuka 2023-03-12 15:14:00 +08:00 via iPhone
|
 |
7
chloerei 2023-03-12 15:15:04 +08:00
可以增加工作岗位。
|
 |
8
qiyuey 2023-03-12 15:18:19 +08:00
领域隔离，控制整体的熵，避免软件危机
|
 |
9
hhjswf 2023-03-12 15:20:49 +08:00 via Android
重点是微。相比单体，业务模块粒度更小，拓展更方便。比如秒杀这样负载比较大的，可以多部署几个，负载小的少部署几个
|
 |
10
nullpoint007 2023-03-12 15:21:50 +08:00
微服务化应对海量并发的, 你说的单点故障也可以通过微服务的多副本解决, 微服务部署的话也不用担心, 现在的 CICD 技术已经很多开源成熟系统
|
 |
13
leonard916 2023-03-12 15:23:59 +08:00
微服务是为了高可用提出的，也是因为有些项目过大，维护和启动都很麻烦，而且过于吃资源，不方便扩展等。
|
 |
14
sujin190 2023-03-12 15:26:45 +08:00 via Android
真正的大型电商系统，获取商品信息和处理支付就已经 n 个微服务了，然后并不会一起挂，也并不会是同一个部门维护，你说有用没用
|
 |
16
wangxiaoaer 2023-03-12 15:46:15 +08:00
微服务容易走火入魔，瞎捷豹分，不要为了微而微，然后原本事务性质的内容再通过微服务通信绕一圈，给部署带来了很大复杂度，尤其是业务量本身 不大的情况。比如网上很多例子商品、订单、库存等等，这几类量上去了才有分的必要。
而支付、用户体系等本身就是业务相对独立，采用微服务是比较合理的。 |
 |
17
kaedea 2023-03-12 16:14:13 +08:00 via Android
一座大💩山 vs 一堆小💩山堆叠的大💩山
|
 |
18
dqzcwxb 2023-03-12 16:22:23 +08:00
分而治之
|
 |
19
AyaseEri 2023-03-12 17:47:03 +08:00
分治之后维护与扩张起来方便啊，而且团队扩张也方便，还能成立更多的开发组，任命更多的组长。
|
 |
20
byte10 2023-03-12 18:02:13 +08:00  1
基本概念不扎实：
1 、楼上还有说集群、多实例。 2 、还有说为了 高可用提出的。 分布式服务跟集群多实例 没有必然的关系。高可用方案一般是多实例的方式解决，多实例也可以提升系统的吞吐量。 关于微服务其中一个挂了，并不是整个商城都无法使用的。比如支付服务挂了，那么整个系统就会出现 服务降级，但是你还是可以继续加入购物车，可以继续浏览商品，继续给商品评价等。其实字面意思都是很简单的，语文的阅读理解是一个非常重要的能力，不然很难理解 服务降级是什么意思。 比如：你去饭店，你可以体验饭店 美甲的服务。但是口罩的问题，你只能打包走人，那么整个饭店服务就降级了，没啥特别难搞。 当然微服务的好处还是很多的，楼上很多回答都描述到了。 |
 |
21
dobelee 2023-03-12 18:19:50 +08:00
有没有一种可能，支付服务挂了，还可以搜索和查看商品。
而一座屎山挂了... |
 |
22
v2lf 2023-03-12 18:24:17 +08:00
业务隔离，弹性伸缩
|
 |
23
nvideo 2023-03-12 20:31:59 +08:00
高并发
|
 |
24
laravel 2023-03-12 20:44:12 +08:00
挂的概率比起单体程序来如何？
|
 |
25
ch2 2023-03-12 21:05:49 +08:00
鸡蛋不放在一个篮子里的道理
|
 |
27
tohuer00 2023-03-12 22:06:17 +08:00 1
纠正一个错误观念，微服务不是用来解决高业务量的，是用来解决高业务复杂度的。
|
 |
28
copper20 2023-03-12 22:12:31 +08:00
从开发的角度来说，如果你见过光 bean 就有十几万个，连编译脚本都需要专人维护的大屎山，那微服务存在的必要性应该也不用解释了。
至少你一次吃的是一个小山包，而不是一次得吃一座山脉 |
 |
29
panxiuqing 2023-03-12 22:34:08 +08:00 via Android
是为了解决软件工程的问题。
我觉得服务降级也不是微服务相对单体有明显区别的地方，除非有问题会导致所有实例同时异常且无法重启，但是这种故障对于无状态服务不应发生。 |
 |
30
xiaop1ng 2023-03-12 23:45:30 +08:00
说一个我实际工作中的应用场景，将并发要求更高的接口剥离出来为一个单独的微服务，在部署的时候该服务可以部署更多的副本
|
 |
31
yagamil 2023-03-13 03:01:12 +08:00
我的理解是 把系统拆分成一个个的 HTTP API 接口？
之前所呆的企业业务并不是太复杂，而且项目也是一次性的，不会被别人或者其他项目调用。 而参与的开发也就几个人。 没有必要为了微服务而微服务。 |
 |
33
WashFreshFresh 2023-03-13 10:21:42 +08:00
支付挂了，还能查看商品信息，商品信息也挂了，还能查看订单状态喝物流信息。
大致就是这么个意思。 |
 |
34
nothingistrue 2023-03-13 11:17:58 +08:00
微服务下，商品信息挂了就是商品信息挂了，支付挂了就是支付挂了。非微服务下，哪里挂了都是商城挂了。当你的目标是解决问题——首先找出那里出了问题（进而解决问题），而不是没有问题——首先保证不出问题（为此将锅甩给全员，甚至掩盖问题），的时候，微服务就是有意义的。反之自然无意义。
技术不是脱离于生活的，微服务、敏捷开发、Scrum 、看板、Issue 方式的任务 /缺陷跟踪方式，等等老外传过来的东西，你得结合老外的办事风格，才更容易理解。一个比较经典的就是 ISO9001 质量体系当中的 BUG 数量，你如果不知道老外更看重发现和解决 BUG 的能力，而不是零 BUG 的能力，就很难理解老外为啥会把 BUG 数量当作质量体系的正向指标。 |
 |
35
yc8332 2023-03-13 14:24:03 +08:00
微服务可能对大厂有用。小厂纯纯浪费钱，也没那么多人
|
Select Language