- 服务粒度
整体上来说，SOA的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，“员工管理系统”就是一个SOA架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”“员工福利管理”等更多服务。
- 服务通信
SOA采用了ESB作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful协议、RPC协议，无须ESB这样的重量级实现。Martin Flower将微服务架构的服务通信理念称为“Smart endpoints anddumb 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那样的处理。
综合上述分析，我们将SOA和微服务对比如下表所示。
对 比 维 度 |
SOA |
微 服 务 |
服务粒度 |
粗 |
细 |
服务通信 |
重量级，ESB |
轻量级，例如HTTP/ RESTful |
服务交付 |
慢 |
快 |
应用场景 |
企业级 |
互联网 |
因此，我们可以看到，SOA和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已，因此两者的关系应该是第三种模式。
其实，Martin Fowler在他的微服务文章中，已经做了很好的提炼：
| In short, the microservice architectural style is an approach to developing asingle application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These servicesare built around business capabilities and independently deployable by fully automated deployment machinery. |
上述英文的三个关键词分别是：small、lightweight、automated，基本上浓缩了微服务的精华，也是微服务与SOA的本质区别所在。
通过前面的详细分析和比较，似乎微服务本质上就是一种比SOA要优秀很多的架构模式，那是否意味着我们都应该把架构重构为微服务呢？
其实不然，SOA和微服务是两种不同理念的架构模式，并不存在孰优孰劣，而只是应用场景不同而已。我们介绍SOA时候提到其产生历史背景是因为企业的IT服务系统庞大而又复杂，改造成本很高，但业务上又要求其互通，因此才会提出SOA这种解决方案。如果我们将微服务的架构模式生搬硬套到企业级IT服务系统中，这些IT服务系统的改造成本可能远远超出实施SOA的成本。
曾经SOA架构下迷途
在技术上，ESB 架构虽然实现了业务逻辑与服务集成的解耦，可以更好地进行中央化的服务治理，也暴露出一些问题：
由于过度强调业务系统的可复用性，而不是对企业 IT 架构的治理和重构。大量服务集成的实现逻辑被下沉到 ESB 内部；而微服务/服务化架构下的注册中心是单纯的注册机制。
ESB 基于一个中心化的消息处理系统，集中式EAI的模式，本身会成为一个单点，可扩展性和性能的挑战。
另，EAI模式下的SOA，实施过程中服务的定义往往没有站在全局架构下思考，宏观未有企业信息架构指导、微观未有类似DDD的指引，协议翻译和集成终于服务的合理抽取。
