主页

索引

模块索引

搜索页面

SOA架构

SOA架构有完善的理论和工具,可以说,它解决了分布式系统中,几乎所有主要的技术问题。但遗憾的是,虽然 SOA 架构曾经被视为更大规模的软件发展的方向,但它最终还是没能成为一种普适的软件架构。

烟囱式架构(Information Silo Architecture)

信息烟囱也被叫做信息孤岛(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)的失败如出一辙。

主页

索引

模块索引

搜索页面