关于SOA与微服务的区别大多有以下几个观点：

观点1：SOA 是一种架构理念，而微服务是 SOA 理念的一种具体实现方法

例如，“微服务就是使用 HTTP RESTful 协议来实现 ESB 的 SOA”“使用 SOA 来构建单个系统就是微服务”和“微服务就是更细粒度的 SOA”。

观点2：微服务是去掉ESB（Enterprise Service Bus）的SOA

去掉沉重的ESB，用轻量的HTTP实现

观点3：微服务是一种和 SOA 相似但本质上不同的架构理念

这种观点认为微服务和 SOA 只是有点类似，但本质上是不同的架构设计理念。相似点在于下图中交叉的地方，就是两者都关注“服务”，都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有 ESB、服务的粒度、架构设计的目标等。

服务粒度

SOA粗，微服务细

服务通信

SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现。 Martin Fowler 将微服务架构的服务通讯理念称为“Smart endpoints and dumb pipes”，简单翻译为“聪明的终端，愚蠢的管道”。之所以用“愚蠢”二字，其实就是与 ESB 对比的，因为 ESB 太强大了，既知道每个服务的协议类型（例如，是 RMI 还是 HTTP），又知道每个服务的数据类型（例如，是 XML 还是 JSON），还知道每个数据的格式（例如，是 2017-01-01 还是 01/01/2017），而微服务的“dumb pipes”仅仅做消息传递，对消息格式和内容一无所知。

服务交付

SOA 对服务的交付并没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。如果没有这些基础能力支撑，微服务规模一旦变大（例如，超过 20 个微服务），整体就难以达到快速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的坑，就是系统拆分为微服务后，部署的成本呈指数上升。

应用场景

SOA 更加适合于庞大、复杂、异构的企业级系统，这也是 SOA 诞生的背景。这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB。

微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于 Web，虽然开发技术可能差异很大（例如，Java、C++、.NET 等），但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。

微服务需要注意的地方

微服务拆分过细，过分强调“small”。
微服务基础设施不健全，忽略了“automated”。
微服务并不轻量级，规模大了后，“lightweight”不再适应。

服务划分过细，服务间关系复杂

服务数量太多，团队效率急剧下降

调用链太长，性能下降

调用链太长，问题定位困难

没有自动化支撑，无法快速交付

没有服务治理，微服务数量多了后管理混乱

如果以上场景都依赖人工去管理，整个系统将陷入一片混乱，最终的解决方案必须依赖自动化的服务管理系统，这时就会发现，微服务所推崇的“lightweight”，最终也发展成和 ESB 几乎一样的复杂程度。

微服务的拆分

AFK scale cube

模块化划分，Y轴

按照DDD中与业务专家充分讨论定义上下文边界，一个微服务等于1个或多个上下文。

关注服务和数据的优先级划分，如分地域划分，z轴

场景：用户指数级快速增长。

无状态复制提升可用性及吞吐，x轴

场景：发展初期，业务复杂度低，需要增加系统容量。

按复杂度拆分

基于业务逻辑拆分

基于可扩展拆分

基于可用性拆分

避免非核心服务故障影响核心服务
核心服务高可用方案可以更简单
能够降低高可用成本
基于性能拆分

微服务的基础设施

建议按照下面优先级来搭建基础设施：

服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。

以上 3 和 4 两类基础设施，其重要性会随着微服务节点数量增加而越来越重要，但在微服务节点数量较少的时候，可以通过人工的方式支撑，虽然效率不高，但也基本能够顶住。