尽管微服务不会替代面向服务的架构（SOA），但是二者在企业环境中可以互相补充。
整合是必要的
没有一个企业可以只用一种技术或一个系统就能满足所有计算需求。所有企业都需要由多种编程语言，多个供应商应用，多个合作系统，以及遗留应用来构成。
仅仅一种架构风格不能满足IT需求，因为我们通常需要处理遗留的各种离散技术，异构技术，不同的供应商系统，等等等等。最重要的是，每个系统都拥有不同的架构能力。
当一个新项目加入进来时，多数解决方案都会牵涉到评估系统中已存在的投入，服务种类，以及员工已具备的技能和经验集合。使用已存在的系统来设计方案是唯一可行的应用整合方式。
应用整合，用穆勒的话说，就是：
“企业内不同应用间的进程和数据共享。不论对大企业还是小企业，它已成为一个关键任务，去连接各种应用，评估跨企业的应用协作，以提升总体商业效率，增强可扩展性，以及减少IT成本。”
应用整合可以在三个层面进行：
用户接口整合（门户网站），尽管某些人可能会说这是个过期的整合风格，综合考虑应该推迟。
系统或服务整合
数据整合
软件架构
专家承认，没有一种架构是能满足所有企业的IT需求的。它依赖于你设计什么系统，以及它将在哪里使用。
一些著名的架构风格如下：
层次架构
事件驱动架构
面向服务架构
微服务架构
基于服务的架构
微内核架构
微服务和SOA
尽管了解所有架构模式很重要，但微服务架构在如今的分布式应用中引领潮流。
微服务对应用开发来说确实是一个考虑周密的架构模式，进一步的服务是通过 RESTful 接口暴露的。
图1. 微服务架构图
微服务的部分特点是，它们不共享东西，有限界上下文（bounded context），使用 RESTful 服务接口，采用直接调用和 API 层调用，相比维护旧代码更偏好重写，以及独立部署。
这些特点中的一部分可理解成原子服务，没有分布式事务，无状态（因为它们通过 REST 暴露），不太确定的是微服务的合适大小，以及幂等性。
SOA 不止是 ESB 或者一个成熟的产品。SOA 是企业层面的架构风格，带来各种服务和系统的可视化，包括REST服务，SOAP服务，以及通过服务层的遗留应用等。
图2. SOA 结构图
SOA 的特点是，它包含系统的互操作性，提供本地支持以整合、补充微服务和云，促进 IT 资产的重用，以及包含服务分类。
SOA 不会规定如何实现一个服务。这是留给每个服务设计者的事。因为 SOA 主要解决应用整合问题，所以它为大部分的整合需求而工作，如基于文件的整合，基于数据的整合，以及基于 web service（WS）的整合。这些在 SOA 中都可以通过 JCA，适配器等做到。
以下是摘自 Lucas Jellema 的 SOA 手册的涉及 SOA 的服务的一些本质特征：
只要可能，服务都应该支持原子操作。
服务应该无状态以使遗留足迹尽可能得小。
服务应该保持幂等以允许重试而不产生副作用。
服务应该大小适中。
现在，如果你稍微往回看一下，你会发现微服务的特点完美得匹配了 SOA 服务的服务定义。
SOA 架构下任意分类的服务都能被微服务具体化。或许那就是为什么每个人都说：”微服务即 SOA 使用得当！”那些做预算和项目支出的，难道你不同意企业级的任何服务都是可重用的吗？
总结一下，微服务不会替代 SOA，但是它们可以在大企业内和 SOA 形成非常完美的互补。
【基于Docker的DevOps实战培训 | 南京站】培训内容涉及容器编排框架（应用部署）、Ansible 简介、持续集成常用方式、典型案例分析、容器的选择、架构设计（百万级日活，亿级API 请求）、数据系统构建、持续集成的开发流程等，点击下面图片即可查看具体培训内容。
点击阅读原文链接可直接报名。
