理解微服务

开头

DHH 的问题在于没有到有复杂业务、流量洪峰的公司做事情，所以拿着单体架构沾沾自喜。单体架构是一个极低成本，实现软件功能的途径，虽然大公司会搞很多微服务，但是像后台系统这种在大公司也是单体存在的，选择是基于场景的。这扯出了第二个问题，大部分在谈微服务的人都在出的问题。

没有基于实际需要、场景分析，就对微服务一顿狂喷，或者不限制地吹捧。

你看看发表评论的人是不是这样？一会儿分山头、势力范围、政治斗争、我觉得 XX 好，尽喷些滑稽的话，丝毫没有从业务、实际问题、解决方案、解决成本、实际场景去分析问题，然后基于问题对微服务、单体等架构模式发表观点。

举个例子，假设某人有一笔钱，问该怎么处理好呢？是放保险柜、交给老婆管、放银行、买股票基金、黄金、国债？选哪个好，有很多人就开始说了，国债稳定低风险、股票能赚钱、银行最保险还能取··· 就差有人问“你的钱金额多大，你对现金需求是怎样的，你对增值风险的期望是？···”

业界对微服务早就有极其明确的观点：不要轻易使用，但也是复杂场景下唯一的选择。

假设就做个后台系统，逻辑简单，QPS 不足一千，对稳定性要求不高。这在哪家大公司我像都更容易选择单体结构，但现实是，大公司微服务构建成本、基础设施极为健全，所以可能会往拆分上靠，但目标是怎么快怎么来。

但是你有月活 1 亿，甚至日活 1 亿呢？用单体架构就是找死，在研发效率、硬件成本、稳定性、鲁棒性、问题分析···等各个方面都是致命的问题。微服务架构是唯一的路，虽然成本高，但只要基础设施健全，好处是极为明显的。

很多人就喜欢盯着某的小业务需求，去分析思考用什么架构，一个小的或者独立的功能需求，不管怎么看，单体架构都和合适，也简单。但把眼光稍微抬高一点点看，假设公司有上百个这种业务呢？各个业务间都关联，有层次之分呢？有流量洪峰呢？怎么做让整体架构的熵最低，理解成本最低，互相调用成本最低，迁移成本最低等等 N 多种成本考量呢？

微服务架构是一种基于全局的考量，不是基于单个业务、单个功能的。也只是一种解决问题的途径和思维方式。

招更多的人、用复杂的架构，都是为了解决实际的问题。

任何工具，都需要思考对应的场景、需求、成本，然后才做出考量和选择。

用一句话总结：小公司用微服务的是 sb，大公司不用微服务是找死。

微服务主要解决的是系统复杂度的问题。而解决量的问题，是分布式系统的事

https://www.v2ex.com/t/960595#reply51

微服务从来没有说要多少用户量才值得上，微服务主要解决的是系统复杂度的问题。解决量的问题，是分布式系统的事，只不过微服务天然就支持分布式而已。

所以，只要系统比较复杂，哪怕只是为了能够方便维护和扩展功能，只要会用一些 devOps 工具，譬如会简单使用 k8s 来解决运维领域的问题的话，微服务就是最好的解决方案，没有之一。

比如定了个用户数或者交易量一年冲千万、三年破亿的指标，不搞服务拆分可能才是架构失职。

如果您是面试官，在现在这个大环境下没有微服务、注册中心应用经验的中高年资员工您会考虑录用么？如果大多数面试官都不考虑的话，那也别奇怪大家为啥要往微服务、注册中心上靠拢了。

很多业务开发，只是习惯与在某个框架下开发。 比如习惯了使用（甚至只使用过） spring cloud 的框架，然后各种组件都是用现成的。 你让他去写单机，他不一定能很快适应。

微服务不是啥高阶功法，只是一种技术方案而已，过度仰视或鄙视一种技术方案，都是不合理的心态。 只有当一个技术人员，可以游刃有余的使用任何一种技术方案完成业务时，他才能真正的根据业务需求，选择最合适的技术方案。