SOA 参考架构

46 阅读 0 评论 31 点赞

我是靠谱客的博主迷你鱼，最近开发中收集的这篇文章主要介绍SOA 参考架构，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

SOA 参考架构 (Reference Architecture) 是一个框架，使各个项目都有一个遵从的依据，借以促进一致性、最佳实践典范，和标准化。参考架构并不受限于目前的 IT 现况，而应该针对一个经过深思熟虑的愿景目标，可以说是 IT 指导未来所有的新开发工作，借以实现该目标的参考依据。一般来说，2-3 年的规划，是一个比较合适的涵盖范围，既能提供足够的时间来达成面向服务的转型，而又不至于过于长远而虚幻。因此，参考架构提供了一个沟通目标愿景的方法，协助部门和角色各异的 IT 人员，逐渐朝向该目标会合。

高效的 SOA 需要采用新的方法来对待 IT 基础设施，并且根据个别企业的需求来量身定做，并将服务基础架构、共享的技术服务、安全服务，以及信息／数据、和遗留系统访问服务等，全部定义在内。

为了满足 SOA 的要求，所有公司都需要 SOA 参考架构和路线图，来指导部署一套能随时间演进、而逐渐丰富的工业级服务基础设施，同时指导对面向服务应用的开发和管理。
此外，企业也需要对参与 SOA 架构的各个个别系统的设计，进行监管，并在适当的地方，建立通用服务，透过协作来发挥更高的效率。对于这些举措，连接端点的标准化（通过建立定义清晰的契约和接口），是达成 IT 系统一致性的先决条件。

SOA 参考架构指导所有实施 SOA 的各个项目，能共同朝向企业级服务，和 SOA 基础架构标准方向的集中发展，尽早使企业从中获益。换句话说，参考架构规划的重点，在于开发一个特定于某个企业需要、切实可行的路线图，以填补当前和愿景目标之间的鸿沟；评估用于开发、部署和管理、监控的现有系统和技术，定义目标状态愿景，目标参考架构模型。

SOA 参考架构可说是指导 SOA 成功的蓝图，其作用包括：

促进 IT 与业务的紧密配合：参考架构的制定，以业务驱动力和 IT 目标为出发点，分析 SOA 解决方案能对这些驱动力带来多大的正面影响，进而为从目前 IT 现况演化到愿景架构，定出实现架构、相关规范及路线图。参考架构因此提供了从业务和 IT 目标，到实现架构间的可跟踪性，是业务与 IT 之间进行沟通的重要媒介，是企业实现业务灵活性、可管理性和变更规划的基础。
协助企业向重用、团队协作和资源共享的文化迁移：参考架构确立了 SOA 架构标准和技术部署的最佳实践，为日后各个 SOA 的实施项目，订立架构遵从性的度量标准和指标。

参考架构并非一成不变。在一个新的 SOA 策略与规划迭代中，SOA 的参考架构和规范标准，可能需要针对新的业务、IT 情况，和已实施的 SOA 项目中得到的反馈，进行调整，因此，SOA 参考架构不仅是 IT 模板，也是也描述 SOA 原则和标准的活文档。

我们可以将参考架构的内容，粗分为两大部分：

对服务建立一套共同的词汇和做法，包括：
- 服务的正式定义 – 例如服务必须由契约 (contract)、接口 (interface)，和实现 (implementation) 所组成
- 服务的分类（核心业务功能服务，数据服务，展现服务等），以及各类服务的设计原则和建议
- 接口标准 (JMS, RMI, HTTP 等)，建议的接口样式（例如：尽量采用粗粒度、异步的服务调用模式），可靠性要求等
- 需要遵从的 WS-* 标准
- 安全策略
- 服务版本控制策略
- 服务和数据模型采用规范
- 服务生命周期定义
与服务基础设施，例如企业服务总线 (ESB)、业务流程管理 (BPM)、注册库 (Registry)、资产库 (Repository) 等相关的规范，包括：
- 必须支持什么样的部署配置
- 必须具备什么样的能力
- 各个部件的责任
- 部件之间的耦合关系和原则，应避免的事项，例如，展现服务和业务流程服务不可直接调用数据服务，而必须通过核心业务服务；换句话说，数据服务不可直接与展现服务和业务流程服务有耦合关系
- 各个部件应支持那些科技和标准（例如：SCA, SDO…）
- 有哪些安全顾虑需要考虑，如何管理权限
- 要采用哪些产品

由于在规划服务基础设施参考架构时，需要涵盖几类 SOA 参与者和干系人 (stakeholders) 各自不同的顾虑，包括架构师、程序员、和负责部署、运营、监控的 IT 人员，我们可以采用一个针对服务基础设施参考架构调整过的 4+1 视图（如下），来协助我们分离顾虑，来将不同层面的规范和目标架构一一制定，通过逻辑、实现、部署，和进程等四个视图，配合最佳实践典范和模式，来对参考架构的各个层面，进行描述和规范，如附图。

图说: 为 SOA 参考架构调整过的 4+1 视图，源于 Kruchten 在 1997 年发表的《Architectural Blueprints – the 4+1 view model of software architecture》

图说: 服务基础设施参考架构的逻辑视图 (Logical View)

图说: 服务基础设施逻辑视图下的功能视图 (Functional View)

图说: 服务基础设施参考架构的实现视图实例（场景为某电信客户的 provisioning service），描绘所计划采用的产品，以及如何通过这些产品间的交互，来实现解决方案

参考架构的规划过程（如下图），应先起于业务驱动力 (business drivers) 分析，可有助确保目标架构能够支持业务的发展策略和方向，展现 SOA 建设对业务的价值，彰显 SOA 投资的正当性，并获得相关业务部门的经费赞助。以金融行业为例，业务驱动力包括像是：

提升效率
借贷流程优化
呼叫中心优化
增长销售额，并显著超越同业
快速灵活地推出创新的金融商品
扩展客户关系，统合客户数据
交叉销售
依据关系定价的策略
降低成本

这一类的价值驱动。分析业务的价值驱动后，接着考虑各种 IT 目标，以及它们如何支持这些业务驱动力；例如：

从关注各业务线烟囱／竖井式的应用系统，转向专注于跨系统／业务线的流程／服务
IT 资产重用
提高跨部门协作的业务流程的透明度

并且应订立评价标准，作为日后考核实现各价值驱动力的指标。接着下来，我们可以根据业务和 IT 驱动力，进一步制定恰当的 SOA 策略，考虑采用 SOA，将对那些业务线，在那些驱动力方面，产生最大的价值，据以订立实施 SOA 项目的优先级别。

图说: 参考架构规划过程

图说: 从业务驱动力和价值链分析，来找出应优先考虑采用 SOA 来协助提升的业务和 IT 能力。
√√ 代表 SOA 项目能产生很大的正向影响，依此类推。

针对各价值驱动力，我们可以参考附图中的矩阵分析方式，从价值链或业务线中的各个主要的职能（纵向），和各个识别出来的业务和 IT 驱动力（横向），对 SOA 所可能产生的正面影响力，一一进行评估，进而挑选出面向服务解决方案最能嘉惠的业务能力，作为首期实施 SOA 项目的切入点。图中的范例只是一个三万尺高空的起点，在真实的情况下，往往会针对范例中某个或某几个得分较高的业务线，往下展开细化，对该业务线中的各个主要业务能力，进一步进行 SOA 价值驱动力分析；换句话说，价值链分析中的各个职能域，应该自粗到细，逐步钻取、drill down 到适当的深度，才能更精准地确定 SOA 能对哪些要迫切改善的业务能力，带来最大价值。

依据业务和 IT 驱动力，选定了 SOA 策略后。接着应根据企业目前的现况，和未来 2-3 年的目标，进行差距分析，并根据最佳实践典范 (best practices)，制定 SOA 发展的蓝图、路线图和指导规范，完成参考架构的规划。接着便可开始根据路线图中制定的项目，以渐进的方式，通过一致的服务工程方法，一个接一个项目去执行，并在此过程中，逐渐将蓝图中的服务基础设施搭建起来。