微服务的意义是什么？例如获取商品信息或者处理支付的服务挂了整个商城不照样用不了

[edis0n0]

[seakingii]

微服务,又不是只运行一个实例,会运行 N 多个实例,挂了一个,其它的先撑住,挂掉的自动修复
微服务需要一整套的工具来辅助服务治理的,包括部署,监控等等
最大的好处,在我看来是职责单一,以及由职责单一带来的附加好处,比如小团队,易扩展,多语言等等

[hyuka]

1.如果是支付挂了，这种应该只是支付不了其它不影响
2.微服务单个服务出问题只需要解决这一个服务的问题，重启回退修 bug,整个服务分成若干服务后肯定比回退重启整个服务要好
3.不同人负责不同微服务，不用关注整个项目的细节，只需关注自己负责的部分的细节以及相关交互

大概想到这些。
工作中，尤其线上的服务都是=(不让随便动的，服务不划分全扔一块，出问题了重启或者部署整个大服务，想想就头大。改动越小越好。

[edis0n0]

@hyuka #2 划分的很细的话部署起来也头大

[hyuka]

服务挂了，也是
多个实例，单个挂了其他可以先撑住，要是因为请求多还可以通过添加实例的方式暂时处理

[lhx2008]

从开发角度来说，一两个人开发只需要单体，十个人开发就要微服务了，要不然怎么调怎么发版

[hyuka]

@edis0n0 这就是度的问题了，划分的合理，部署问题就还好。我工作过的几个公司，服务都是越来越大，微服务就很有必要。

但是嘛，你说的也是存在的问题，合理划分也不容易。

[chloerei]

可以增加工作岗位。

[qiyuey]

领域隔离，控制整体的熵，避免软件危机

[hhjswf]

重点是微。相比单体，业务模块粒度更小，拓展更方便。比如秒杀这样负载比较大的，可以多部署几个，负载小的少部署几个

[nullpoint007]

微服务化应对海量并发的, 你说的单点故障也可以通过微服务的多副本解决, 微服务部署的话也不用担心, 现在的 CICD 技术已经很多开源成熟系统

[xuanbg]

@edis0n0 自动化运维了解下，几百上千的服务也和一个服务一样部署。

[hhjswf]

@seakingii 单体也可以这么做，这不是微服务的特权

[leonard916]

微服务是为了高可用提出的，也是因为有些项目过大，维护和启动都很麻烦，而且过于吃资源，不方便扩展等。

[sujin190]

真正的大型电商系统，获取商品信息和处理支付就已经 n 个微服务了，然后并不会一起挂，也并不会是同一个部门维护，你说有用没用

[seakingii]

@hhjswf 我上面说了好几项,请明确说明什么不是微服务的特权

[wangxiaoaer]

微服务容易走火入魔，瞎捷豹分，不要为了微而微，然后原本事务性质的内容再通过微服务通信绕一圈，给部署带来了很大复杂度，尤其是业务量本身 不大的情况。比如网上很多例子商品、订单、库存等等，这几类量上去了才有分的必要。
而支付、用户体系等本身就是业务相对独立，采用微服务是比较合理的。

[kaedea]

一座大💩山 vs 一堆小💩山堆叠的大💩山

[dqzcwxb]

分而治之

[AyaseEri]

分治之后维护与扩张起来方便啊，而且团队扩张也方便，还能成立更多的开发组，任命更多的组长。

[byte10]

基本概念不扎实：
1 、楼上还有说集群、多实例。
2 、还有说为了 高可用提出的。
分布式服务跟集群多实例 没有必然的关系。高可用方案一般是多实例的方式解决，多实例也可以提升系统的吞吐量。

关于微服务其中一个挂了，并不是整个商城都无法使用的。比如支付服务挂了，那么整个系统就会出现 服务降级，但是你还是可以继续加入购物车，可以继续浏览商品，继续给商品评价等。其实字面意思都是很简单的，语文的阅读理解是一个非常重要的能力，不然很难理解 服务降级是什么意思。

比如：你去饭店，你可以体验饭店 美甲的服务。但是口罩的问题，你只能打包走人，那么整个饭店服务就降级了，没啥特别难搞。

当然微服务的好处还是很多的，楼上很多回答都描述到了。