从SOA到MSA（上）

纵览云计算与大数据时代的各类技术框架与系统体系架构，它们的共同特征是注重可扩展性、敏捷性与弹性，以集群的整体业务（数据）处理能力及综合服务提供的能力来弥补单一节点的性能劣势，以及对因节点故障、上下线等因素的抗干扰能力强。

如果我们再结合各种XaaS平台以及SDX（软件定义的一切）框架，它们的共性可以简单归纳为：分层抽象化架构，层与层之间通过服务来通信，底层向上提供可被调用的服务接口。

以上两段话高度概括起来其实就是SOA（面向服务的架构=Service-Oriented Architecture）。

SOA可以看作计算机软件设计中的体系架构设计模式（Architectural Design Pattern），类似于面向对象的编程语言的设计模式（OO Design Pattern）。标准化组织The Open Group对SOA有明确的定义：SOA是一种面向服务的架构设计风格。而面向服务是一种以服务开发、服务结果为导向的思维模式。所谓服务通常有如下特点：

·自包含的（Self-Contained）；

· 对服务的消费者是黑盒的（Black-Box to Consumer of the Service）；

·是有明确输入/输出的可重复商业活动的逻辑表示（Logical Presentation of Repeatable Business Activity that has Specific Outcome）；

·可由其他服务构成（May be Composed of Other Services）。

在下图中展示了典型的SOA的三层架构：

· 组件架构：作为最底层的组件架构，它向上提供可调用的编程接口。典型的如虚拟机、容器、IaaS、SDS、SDN等都会在这一层工作，它们直接与各种物理组件实现对接。

·服务架构：这一层承上启下，对下层组件提供的API进行抽象化、虚拟化，使得上层架构不需要关心下层的实现细节，并提供通用的接口、可管理架构以及系统的逻辑视图给上层应用。

·应用架构：应用层调用与集成底层提供的服务接口并专注于实现业务逻辑。

需要指出的是，SOA的概念是在第二平台的时代所提出的，但其理念在第三平台（大数据、云、移动互联、社交）中依然适用。SOA系统通常需要兼顾第二、第三平台的需求，因此在体系架构设计上往往采用进化的方式。

图：SOA的三层架构：组件、服务及应用

下面，我们来看一个直观一点的例子，如下图所示，一个典型的基于云架构的可扩展Web类应用的SOA三层架构。

自上而下分别是：

最上层提供了移动或Web端的用户界面与接口实现； 中间层提供了应用所需要的各种服务，如缓存服务、NoSQL数据库服务、消息队列或企业服务总线、聚集服务等； 最底层的则是实现各种特定领域业务功能与逻辑的具有领域特定性（Domain-Specific）服务器，例如CRM系统、采购系统、预约系统等，我们称之为SoR（System-of-Record）。

很显然最底层的Systems of Record通常会包含第二平台的系统（Monolithic Enterprise Servers），而SOA所要解决的问题就是让这些第二平台系统可以与第三平台的应用与服务对接。如下图所示，主要有两大组件来帮助实现这种对接。

图4-20 可扩展云应用的典型三层架构

· Aggregate Services（聚集服务）：对SoR的任何改动（写或更新、删除等相对昂贵的操作）通过聚集服务来完成。而只读类服务则通过实现缓存、索引、信息推送或轮询等服务来实现（这样做的一个最大优点是让底层的传统SoR类系统可以免受直接的Web负载冲击）。

· Event-Driven Architecture（事件驱动的架构）：通常有两种EDA的实现方法，ESB（企业服务总线）或AtomPub。ESB是基于服务者消息推送（Message Push）的设计理念，而AtomPub则是基于消费者消息轮询（Message Poll）的设计理念。两者适用的应用场景不同，ESB更适用于低延迟应用而AtomPub则对延迟有更高的容忍度。

上图展示的是如何通过SOA架构设计来对第二平台的紧耦合企业级业务进行扩展与改造以服务于高度可弹性扩展的第三平台应用。这种改造过程（SOA化）中通常通过SOAP或REST来实现应用的逻辑分层，并且由于REST协议具有比SOAP协议更好的可扩展性，云化的应用通常选用RESTful协议来实现服务间通信。这也是多数Web应用实现云化、高可扩展性的主要方法。

·本节未完待续·

标签：SOA,架构,平台,应用,组件,服务,MSA
来源： https://blog.csdn.net/Ultipa/article/details/120177097