学习笔记-架构的演进之面向服务架构-2月day04

引言

面向服务架构（Service-Oriented Architecture，SOA）是第一次被广泛使用过的、通过分布式服务来构建信息系统的工程实践。它有完善的理论和工具，可以说，它解决了分布式系统中，几乎所有主要的技术问题。 虽然 SOA 架构曾经被视为更大规模的软件发展的方向，但它最终还是没能成为一种普适的软件架构。

前提-服务拆分架构模式

在介绍 SOA 架构模式之前，先来介绍一下几种有代表性的服务拆分的架构模式。其中有的是 SOA 演化过程的中间产物，你也可以理解为，它们是 SOA 架构出现的必要前提。

烟囱式架构（Information Silo Architecture）

信息烟囱也被叫做信息孤岛（Information Island），使用这种架构的系统呢，也被称为孤岛式信息系统或者烟囱式信息系统。这种信息系统，完全不会跟其他相关的信息系统之间进行互操作，或者是进行协调工作。这样的系统其实并没有什么“架构设计”可言。

按照该“架构”设计，对于两个不发生交互的信息系统，让它们使用独立的数据库、服务器，就可以完成拆分了。但这也是该模式的致命问题，在一个软件中，完全不交互的子系统是不存在的！

微内核架构（Microkernel Architecture）

微内核，也被称为插件式架构（Plug-in Architecture）。在烟囱式架构中，我们说两个没有业务往来关系的系统，也可能需要共享人员、组织、权限等一些公共的主数据，那就不妨把这些主数据，连同其他可能被各个子系统使用到的公共服务、数据、资源，都集中到一块，成为一个被所有业务系统共同依赖的核心系统（Kernel，也称为 Core System），具体的业务系统就能以插件模块（Plug-in Modules） 的形式存在了，就可以为整个系统提供可扩展的、灵活的、天然隔离的功能特性。

以更高层次的抽象程度来看，任何计算机系统都是由各种架构的软件互相配合来实现各种功能的，这一讲我介绍的各种架构模式，一般都可以看作是整个系统的一种插件。对于产品型应用程序来说，如果我们想将新特性或者功能及时加入系统，微内核架构会是一个不错的选择。

微内核架构也可以嵌入到其它架构模式之中，通过插件的方式，来提供逐步演化的功能和增量开发。所以，如果你准备实现一个能够支持二次开发的软件系统，微内核就是一种良好的架构模式。

微内核架构也有它的局限和使用前提，它会假设系统中各个插件模块之间是互不认识的（不可预知系统会安装哪些模块），这些插件会访问内核中一些公共的资源，但不会发生直接交互。

有没有一种架构，它既能拆分出独立的系统，也能让拆分后的子系统之间可以顺畅地互相调用通讯。

事件驱动架构（Event-Driven Architecture）

事件驱动架构可以解决子系统之间互相通讯的问题。

这种架构模式的运作方案是，在子系统之间建立一套事件队列管道（Event Queues），来自系统外部的消息将以事件的形式发送到管道中，各个子系统可以从管道里获取自己感兴趣、可以处理的事件消息，也可以为事件新增或者是修改其中的附加信息，甚至还可以自己发布一些新的事件到管道队列中去。这样一来，每一个消息的处理者都是独立的、高度解耦的，但它又能与其他处理者（如果存在该消息处理者的话）通过事件管道来进行互动。

SOA 架构时代的探索

SOA 的概念最早是由 Gartner 公司在 1994 年提出的。当时的 SOA 还不具备发展的条件，直到 2006 年情况才有所变化，IBM、Oracle、SAP 等公司，共同成立了 OSOA 联盟（Open Service Oriented Architecture），来联合制定和推进 SOA 相关行业标准。

当软件架构发展至 SOA 时代的时候，其中的许多概念、思想都已经能在今天的微服务中，找到对应的身影了。比如说，服务之间的松散耦合、注册、发现、治理、隔离、编排等等，都是微服务架构中耳熟能详的概念了，也大多是在分布式服务刚被提出的时候，就已经可以预见到的困难。而SOA也不仅仅是一个架构风格，而是可以称之为一套软件架构的基础平台了。

1. 具有清晰的软件设计的指导原则，比如服务的封装性、自治、松耦合、可重用、可组合、无状态，等等；
2. 明确了采用 SOAP 作为远程调用的协议，依靠 SOAP （Simple Object Access Protocol）协议族（WSDL、UDDI 和一大票 WS-* 协议）来完成服务的发布、发现和治理；
3. 会利用一个被称为是企业服务总线（Enterprise Service Bus，ESB）的消息管道，来实现各个子系统之间的通讯交互，这就让各个服务间在 ESB 的调度下，不需要相互依赖就可以实现相互通讯，既带来了服务松耦合的好处，也为以后可以进一步实现业务流程编排（Business Process Management，BPM）提供了基础；
4. 使用了服务数据对象（Service Data Object，SDO）来访问和表示数据，使用服务组件架构（Service Component Architecture，SCA）来定义服务封装的形式和服务运行的容器；

在这一整套成体系、互相精密协作的技术组件的支持下，我们从技术可行性的角度来评判的话，SOA 实际上就可以算是成功地解决了分布式环境下，出现的诸如服务注册、发现、隔离、治理等主要技术问题了。

但是，SOA 架构过于严谨精密的流程与理论，导致了软件开发的全过程，都需要有懂得复杂概念的专业人员才能够驾驭。从 SOA 诞生的那一天起，就已经注定了它只能是少数系统的阳春白雪式的精致奢侈品：它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广。

这样的例子还有：

• Web Service 之所以被逐渐边缘化，最本质的原因就是过于严格的规范定义，给架构带来了过度的复杂性。
• EJB （Enterprise JavaBean，企业级 JavaBean）尽管有 Sun Microsystems和 IBM 等一众巨头在背后力挺，希望能把它发展成一套面向信息系统的编程范式，但它仍然被以 Spring、Hibernate 为代表的“草根框架”给打败了。可见，任何事物一旦脱离了人民群众，最终都会淹没在群众的海洋之中，就连信息技术也不曾例外过。

总结

现在，我们重新思考一下“如何使用多个独立的分布式服务共同构建一个更大型系统”这个问题，再回顾一下Unix DCE 提出的分布式服务的主旨：“让开发人员不必关心服务是远程还是本地，都能够透明地调用服务或者访问资源”。经过了三十年的技术发展，信息系统经历了巨石、烟囱、微内核、事件驱动、SOA 等架构模式，应用受架构复杂度的牵绊却是越来越大，距离“透明”二字已经越来越远了。这是否算不自觉间忘记了当年的初心呢？

附

此文章为2月Day4学习笔记，内容来源于极客时间《周志明的软件架构课》