SOA架构 ####### SOA架构有完善的理论和工具，可以说，它解决了分布式系统中，几乎所有主要的技术问题。但遗憾的是，虽然 SOA 架构曾经被视为更大规模的软件发展的方向，但它最终还是没能成为一种普适的软件架构。 烟囱式架构(Information Silo Architecture) ========================================= * https://en.wikipedia.org/wiki/Information_silo 信息烟囱也被叫做信息孤岛（Information Island），使用这种架构的系统呢，也被称为孤岛式信息系统或者烟囱式信息系统。这种信息系统，完全不会跟其他相关的信息系统之间进行互操作，或者是进行协调工作。 微内核架构(Microkernel Architecture) ==================================== 它也被称为插件式架构（Plug-in Architecture）。把这些主数据，连同其他可能被各个子系统使用到的公共服务、数据、资源，都集中到一块，成为一个被所有业务系统共同依赖的核心系统（Kernel，也称为 Core System）。微内核架构也可以嵌入到其它架构模式之中，通过插件的方式，来提供逐步演化的功能和增量开发。 微内核架构也有它的局限和使用前提，它会假设系统中各个插件模块之间是互不认识的（不可预知系统会安装哪些模块），这些插件会访问内核中一些公共的资源，但不会发生直接交互。 事件驱动架构(Event-Driven Architecture) ======================================= 为了能让子系统之间互相通讯，事件驱动架构就应运而生了。 这种架构模式的运作方案是:: 在子系统之间建立一套事件队列管道（Event Queues） 来自系统外部的消息将以事件的形式发送到管道中 各个子系统可以从管道里获取自己感兴趣、可以处理的事件消息 也可以为事件新增或者是修改其中的附加信息，甚至还可以自己发布一些新的事件到管道队列中去 每一消息的处理者都是独立的、高度解耦的 但它又能与其他处理者(如果存在该消息处理者的话)通过事件管道来进行互动。 SOA 架构时代的探索 ================== * “面向服务的架构”（Service Oriented Architecture，SOA） * 服务之间的松散耦合、注册、发现、治理、隔离、编排等概念、思想开始成型。 更具体:: 尽管 SOA 本身还是属于一种抽象概念，而不是特指某一种具体的技术 但它比之前介绍的架构，都要更具可操作性，细节也充实了很多 不能简单的把 SOA 看作是一种架构风格了，而是可以称之为一套软件架构的基础平台 基础平台是指: 1. SOA 拥有领导制定技术标准的组织 Open CSA 2. SOA 具有清晰的软件设计的指导原则 比如服务的封装性、自治、松耦合、可重用、可组合、无状态，等等 3. SOA 架构明确了采用 SOAP 作为远程调用的协议 依靠 SOAP 协议族（WSDL、UDDI 和一大票 WS-\* 协议）来完成服务的发布、发现和治理 4. SOA 架构用一个被称为是ESB的消息管道，来实现各子系统间的通讯交互 这就让各个服务间在 `ESB` 的调度下，不需要相互依赖就可以实现相互通讯 既带来了服务松耦合的好处，也为以后进一步实现 `BPM` 提供了基础 5. SOA 架构使用了 `SDO` 来访问和表示数据 使用 `SCA` 来定义服务封装的形式和服务运行的容器 ESB: 企业服务总线（Enterprise Service Bus，ESB） BPM: 业务流程编排(Business Process Management，BPM) SDO: 服务数据对象（Service Data Object，SDO） SCA: 服务组件架构（Service Component Architecture，SCA） 更系统:: SOA 最根本的目标: 希望能够总结出一套自上而下的软件研发方法论， 让企业只需要跟着它的思路，就能够一揽子解决掉软件开发过程中的全套问题 比如，如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发测试部署新的功能，等等 SOA 最终没有获得成功的致命伤，其实跟当年的 EJB（Enterprise JavaBean，企业级 JavaBean）的失败如出一辙。