目录
参考*，简单梳理一下微服务的历史
- 2005 年：Dr. Peter Rodgers 在 Web Services Edge 大会上提出了“Micro-Web-Services”的概念;
- 2011 年：一个软件架构工作组使用了“microservice”一词来描述一种架构模式;
- 2012 年：同样是这个架构工作组，正式确定用“microservice”来代表这种架构;
- 2012 年：ThoughtWorks 的 James Lewis 针对微服务概念在 QCon San Francisco 2012 发表了演讲;
- 2014 年：James Lewis 和 Martin Fowler 合写了关于微服务的一篇学术性的文章，详细阐述了微服务
微服务与SOA的关系
关于 SOA 和微服务的关系和区别，大概分为下面几个典型的观点：
-
微服务是 SOA 的实现方式(X)
如图这种观点认为 SOA 是一种架构理念，而微服务是 SOA 理念的一种具体实现方法。例如，微服务就是使用 HTTP RESTful 协议来实现 ESB 的 SOA -
微服务是去掉 ESB 后的 SOA(X)
如图这种观点认为传统 SOA 架构最广为人诟病的就是庞大、复杂、低效的 ESB，因此将 ESB 去掉，改为轻量级的 HTTP 实现，就是微服务 -
微服务是一种和 SOA 相似但本质上不同的架构理念（✓）
如图这种观点认为微服务和 SOA 只是有点类似，但本质上是不同的架构设计理念。相似点在于图中交叉的地方，就是两者都关注服务，都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有 ESB、服务的粒度、架构设计的目标等。
服务粒度
整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，员工管理系统就是一个 SOA 架构中的服务；而如果采用微服务架构，则员工管理系统会被拆分为更多的服务，比如员工信息管理、员工考勤管理、员工假期管理和员工福利管理等更多服务。
服务通信
SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现。
服务交付
SOA 对服务的交付并没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；微服务的架构理念要求快速交付，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。
应用场景
SOA 更加适合于庞大、复杂、异构的企业级系统，这也是 SOA 诞生的背景；
微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；
总结
SOA 和微服务本质上是两种不同的架构设计理念，只是在服务这个点上有交集而已，且两者并不存在孰优孰劣，只是应用场景不同而已
微服务的陷阱
服务划分过细，服务间关系复杂
服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。
从理论的角度来计算，n 个服务的复杂度是 n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的，如下图：
服务数量太多，团队效率下降
一个简单的需求开发需要涉及多个微服务，微服务之间的接口很多，无论是设计、开发、测试、部署，都需要工程师不停地在不同的服务间切换。
对于必须要拆分的情况，在服务数量增多后，需要基础设施跟上，如持续继承，自动化测试，自动化部署等服务治理，否则还不如不拆分来的更可靠。
调用链太长，性能下降
微服务之间一般是通过 HTTP 或者 RPC 调用的，每次调用必须经过网络，一个请求经过过多服务调用会增加响应时间，对于高性能场景可能就不好满足，通过改善硬件设施，又会增加成本。
调用链太长，问题定位困难
系统拆分为微服务后，一次用户请求需要多个微服务协同处理，任意微服务的故障都将导致整个业务失败。然而由于微服务数量较多，快速定位到底是哪个微服务故障是一件复杂的事情。
如果多个微服务同时发生不同类型的故障，则定位故障更加复杂。
没有自动化支撑，无法快速交付
如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。
- 没有自动化测试支撑，每次测试时需要测试大量接口；
- 没有自动化部署支撑，每次部署 6 ~ 7 个服务，几十台机器，运维人员敲 shell 命令逐台部署…
- 没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件
没有服务治理，微服务数量多了后管理混乱
随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的 lightweight 就会变成问题:
- 服务路由：假设某个微服务有 60 个节点，部署在 20 台机器上，那么其他依赖的微服务如何知道这个部署情况呢？
- 服务故障隔离：假设上述例子中的 60 个节点有 5 个节点发生故障了，依赖的微服务如何处理这种情况呢？
- 服务注册和发现：同样是上述的例子，现在我们决定从 60 个节点扩容到 80 个节点，或者将 60 个节点缩减为 40 个节点，新增或者减少的节点如何让依赖的服务知道呢？
如果以上场景都依赖人工去管理，整个系统将陷入一片混乱，最终的解决方案必须依赖自动化的服务管理系统。
总结
- 微服务拆分过细，过分强调small；
- 微服务基础设施不健全，忽略了automated；
- 微服务并不轻量级，规模大了后，lightweight不再适应；
--------来源《极客课程》∙ 学习摘要