本文讲的是微服务和SOA：结合起来更完美【编者的话】本文分析了企业内多种架构并存及整合的现实性和合理性，并分别简单分析了微服务和 SOA 架构的特点，指出二者可以形成完美的互补，以提高企业效率，减少 IT 成本。
尽管微服务不会替代面向服务的架构（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 形成非常完美的互补。
原文链接：Microservices and SOA: Better Together（翻译：池剑锋）
原文发布时间为：2016-12-28
本文作者：池剑锋
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：微服务和SOA：结合起来更完美
