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

[edis0n0]

[dobelee]

有没有一种可能，支付服务挂了，还可以搜索和查看商品。
而一座屎山挂了...

[v2lf]

业务隔离，弹性伸缩

[nvideo]

高并发

[laravel]

挂的概率比起单体程序来如何？

[ch2]

鸡蛋不放在一个篮子里的道理

[salmon5]

@xuanbg #11 "自动化运维了解下，几百上千的服务也和一个服务一样部署。"
乱说，实际中完全不一样

[tohuer00]

纠正一个错误观念，微服务不是用来解决高业务量的，是用来解决高业务复杂度的。

[copper20]

从开发的角度来说，如果你见过光 bean 就有十几万个，连编译脚本都需要专人维护的大屎山，那微服务存在的必要性应该也不用解释了。

至少你一次吃的是一个小山包，而不是一次得吃一座山脉

[panxiuqing]

是为了解决软件工程的问题。
我觉得服务降级也不是微服务相对单体有明显区别的地方，除非有问题会导致所有实例同时异常且无法重启，但是这种故障对于无状态服务不应发生。

[xiaop1ng]

说一个我实际工作中的应用场景，将并发要求更高的接口剥离出来为一个单独的微服务，在部署的时候该服务可以部署更多的副本

[yagamil]

我的理解是 把系统拆分成一个个的 HTTP API 接口？
之前所呆的企业业务并不是太复杂，而且项目也是一次性的，不会被别人或者其他项目调用。 而参与的开发也就几个人。

没有必要为了微服务而微服务。

[acctv2]

@yagamil 单体不也是拆分 HTTP API 吗

[WashFreshFresh]

支付挂了，还能查看商品信息，商品信息也挂了，还能查看订单状态喝物流信息。

大致就是这么个意思。

[nothingistrue]

微服务下，商品信息挂了就是商品信息挂了，支付挂了就是支付挂了。非微服务下，哪里挂了都是商城挂了。当你的目标是解决问题——首先找出那里出了问题（进而解决问题），而不是没有问题——首先保证不出问题（为此将锅甩给全员，甚至掩盖问题），的时候，微服务就是有意义的。反之自然无意义。

技术不是脱离于生活的，微服务、敏捷开发、Scrum 、看板、Issue 方式的任务 /缺陷跟踪方式，等等老外传过来的东西，你得结合老外的办事风格，才更容易理解。一个比较经典的就是 ISO9001 质量体系当中的 BUG 数量，你如果不知道老外更看重发现和解决 BUG 的能力，而不是零 BUG 的能力，就很难理解老外为啥会把 BUG 数量当作质量体系的正向指标。

[yc8332]

微服务可能对大厂有用。小厂纯纯浪费钱，也没那么多人

[yagamil]

@acctv2 对，所以微服务是不是只是改个高大上的名字？？

[acctv2]

@yagamil 我的意思是 HTTP API 和微服务概念没啥太大联系，正常代码都是拆分成一个个 API 接口。

微服务和普通单体应该就是是否独立部署的区别