什么是SOA架构？

SOA 是 Service-Oriented Architecture 的简写，直译为“面向服务的架构”，从 命名上就可以看出“服务”是 SOA 架构里是非常重要的概念。SOA 的核心思想是“将 系统的功能解构为一系列服务”： 面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务） 进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方 式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件 在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。 与单体架构按照技术职责进行水平拆分不同，SOA 会按照业务领域对应用进行粗粒度 的垂直拆分，至于拆分到什么程度，哪些领域可以放在一起等类似问题，可以参考一下康威 定理。 应用从单体应用做了垂直拆分以后，就会变成一些相对独立的应用。此时，应用间的依 赖、调用等相关问题自然而然的就会浮现出来。此时就需要下面这些技术方案来解决这些问 题：

 XML - 一种标记语言，用于以文档格式描述消息中的数据。

 SOAP（Simple Object Access Protocol） - 在计算机网络上交换基于 XML 的 消息的协议，通常是用 HTTP。

 WSDL（Web Services Description Language，Web 服务描述语言） - 基于 XML 的描述语言，用于描述与服务交互所需的服务的公共接口，协议绑定，消息格式。

 UDDI（Universal Description, Discovery, and Integration，是统一描述、发现 和集成） - 基于 XML 的注册协议，用于发布 WSDL 并允许第三方发现这些服务。

 ESB（Enterprise Service Bus, 企业服务总线）- 支持异构环境中的服务、消息， 以及基于事件的交互，并且具有适当的服务级别和可管理性。

SOA 看似解决了单体架构的所有问题，世界似乎都变得更加美好了 ^_^ 但是… SOA 并不完美，他也有很多问题的或者说是场景下的不适应。首先就是对 SOA 的 解释缺乏统一标准，上文的引用的定义也只是众多解释中使用的较为通用的一种。甚至可以 这么说：一千个人眼中，有一千种 SOA 。基于此，很多厂商便借用 SOA 的大旗来推广 自己的产品和标准，这又进一步加剧了问题的严重性。 除此之外，SOA 还有很多其他的问题或不足：

 高门槛。ESB 本身就是一套非常复杂的系统，通过 ESB 落地 SOA ，对开发人员 的要求很高。甚至还会需要厂商参与；

 厂商绑定。由于缺乏统一保准，不同厂商的解决方案之间很难做切换。

 不适应云环境。在如今的互联网时代，速度就是一切。由此诞生了敏捷开发、持续集成 等在不同节点提升业务上线速度的办法。但是方向是不一致的。

 中心化。虽然应用本身实现了分布式与水平扩展，但是 ESB 却成了系统的中枢神经。