本系列文章通过逐章回答《Fundamentals of Software Architecture》(下文简称 FOSA)一书中的课后思考题,来深入理解书中的核心概念和理论,从而提升我们的软件架构设计能力。本篇为第十六章内容。
本章的课后题是:
-
What was the main driving force behind service-oriented architecture?
SOA 的主要驱动力是什么?
-
What are the four primary service types within a service-oriented architecture?
SOA 的四种主要服务类型是什么?
-
List some of the factors that led to the downfall of service-oriented architecture.
列举一些导致 SOA 衰落的因素。
-
Is service-oriented architecture technically partitioned or domain partitioned?
SOA 是技术分层还是领域分层?
-
How is domain reuse addressed in SOA? How is operational reuse addressed?
SOA 中如何解决领域复用和操作复用问题?
背景
What was the main driving force behind service-oriented architecture
SOA 的主要驱动力是什么?
Is service-oriented architecture technically partitioned or domain partitioned?
SOA 是技术分层还是领域分层?
编排驱动的面向服务架构(Orchestration-Driven Service-Oriented Architecture,简称 SOA)是一种在特定时代背景下演变而来的软件架构风格。它在 20 世纪 90 年代末企业快速扩张、需要更复杂的 IT 系统来适应增长的背景下出现。
- 资源稀缺性:在开源操作系统尚未被认为足够可靠用于严肃工作之前,操作系统和商业数据库服务器的许可费用昂贵且按机器收费。这导致架构师们被要求尽可能地实现重用,以优化成本。
- 企业级重用:SOA 的一个主要目标是实现服务层面的重用,即逐步构建可随时间增量重用的业务行为。大型公司厌倦了重复编写软件,因此采取了逐步解决这个问题的策略。
- 技术分层:这种架构风格也将技术分层理念推向了极致。其驱动哲学围绕着企业级的重用展开。
拓扑
What are the four primary service types within a service-oriented architecture?
SOA 的四种主要服务类型是什么?
围绕企业级复用的目标,SOA 定义了以下几种服务类型:
- 业务服务(Business Services):位于架构顶层,提供入口点,代表领域行为(例如 ExecuteTrade 或 PlaceOrder)。这些服务定义通常不包含代码,只包含输入、输出和模式信息,并由业务用户定义。
- 企业服务(Enterprise Services):包含细粒度的共享实现,是构成粗粒度业务服务的构建块,并通过编排引擎连接起来(例如 CreateCustomer、CalculateQuote)。其目标是构建可复用的原子行为,从而逐步建立可复用的企业资产集合。
- 应用服务(Application Services):一次性、单一实现的服务,不要求与企业服务同等程度的复用和粒度。通常由单一应用团队拥有,用于解决特定应用需求。
- 基础设施服务(Infrastructure Services):提供操作层面的关注点,如监控、日志记录、身份验证和授权。这些服务通常是具体的实现,由共享的基础设施团队与运维团队紧密协作拥有。
- 编排引擎(Orchestration Engine):作为分布式架构的核心,负责将业务服务实现通过编排串联起来,包括事务协调和消息转换等功能。它还充当集成中心,允许集成自定义代码、软件包和传统软件系统。由于这个机制是架构的核心,负责这个引擎的集成架构团队往往会成为组织内部的政治力量和官僚瓶颈**…**。
失败原因
List some of the factors that led to the downfall of service-oriented architecture.
列举一些导致 SOA 衰落的因素。
How is domain reuse addressed in SOA? How is operational reuse addressed?
SOA 中如何解决领域复用和操作复用问题?
这个架构在历史进程中是一个反面教材,它是核心思想就俩字:复用!reuse。
失败的最核心原因:过度重视技术,以技术为导向进行模块划分和复用尝试,而业务是不断演进变化的,最终技术与业务之间的隔阂无法弥补,功亏一篑。其他原因还有:
- 过度追求复用导致的高度耦合
- 编排引擎成为巨大的耦合点和瓶颈
- 技术分区带来的业务流程碎片化
这里谈到了一对矛盾:复用和耦合。复用必定会带来耦合,解耦,会带来更多的重复。
在 SOA 中,复用是其核心目标,但其实现方式也导致了架构的显著副作用:紧密耦合。
- 领域复用(Domain Reuse):SOA 通过抽象共享的业务概念(例如
Customer
客户)为可重用服务来解决领域重用问题。其他服务会引用这些"规范的(canonical)"客户服务。 - 操作复用(Operational Reuse):通过基础设施服务(Infrastructure Services)尽可能地重用所有功能,无论是领域功能还是操作功能。
然而,这种设计也带来了负面影响:当一个系统主要围绕重用构建时,组件之间也会产生大量的耦合。例如,对规范客户服务的更改可能会波及到所有其他引用该服务的服务,使得变更变得高风险和复杂。