体系架构的生命期:对业务的影响以及如何构建更持久的体系架构

  • Sadek Drobi
  • 张兵

2008 年 10 月 6 日

话题:架构

什么是体系架构的生命期?应该考虑到何种程度?它对业务可能有何影响?为了回答这些问题,Dan Pritchett 引入了“体系架构保质期”的概念,他将其定义为“开始设计新的系统时,一组模式和技术的适用期限”。他认为体系架构保质期能持续 5 年左右,经过两到三代以后,任何体系架构至少会有部分的改变。否则,该体系架构就会很陈旧,而且在适应业务需求发展时会引起成本的增加。基于此,Pritchett 认为“体系架构通常有 10 到 15 年的有效期”。为了支持自己的论点,他给出了自 1990 年以来发生的技术、体系架构演进的一系列例证。

Pritchett 主张,如果没有在体系架构生命期结束的时候更新体系架构,可能会对业务有重大的影响。但他也承认,改变主要的体系架构会导致可观的成本,尤其是“你在供应链里已经拥有了坚实的客户基础,以及超值的业务特性”。正如争论:是否应该避免架构重写?中涉及的几个作者所强调的一样,改变甚至是破坏性的。不过 Pritchett 认为,不采用新的模式和技术会带来更大的成本。这些技术和模式通常有助于提高开发者的效率、降低部署的成本。拒绝利用这一潜在的竞争优势相当于让竞争对手占尽先机,对业务来说这可是致命的:

被忽略的是,新的模式和平台无论如何都能用来破坏你的业务。如果你拥有成功的业务,许多人也会想分一杯羹。技术就成了他们追赶你业务的工具。他们会以更低的成本或者更具竞争力的特性提供和你一样的服务,这引起的破坏可要远甚于内部体系架构改变所引起的破坏。

在他第一篇文章的续作中,Pritchett 提出随着新模式和技术的涌现,主要体系架构改变的必然性上存在一些细微的差别。他曾经讲过,体系架构的生命期依赖于其轻松扩展以适应演进业务需求的能力,他将这一点转换为技术术语,解释为“随着不断风行的新技术而被更新”的能力。“遵循优良构件设计的标准体系架构原则,保持组件间最大限度的松耦合度”能强化这一能力,使得这些构件可以相互独立地实现和演进。基于识别的一些常见错误,Pritchett 提取出了一 些要构建更持久的体系架构可采纳的原则

1. 接口协议和实现策略之间的解耦。这将增加“构件在可选实现技术之间移植的灵活性”。Pritchett 建议,构件之间定义像 XML 或 JSON 之类的、基于文本的接口可以达到这个目的。

2. 注重关注点分离,即使两个关注点的初始大小差别很大。这可以避免如下情形:为现有构件增加一个新特性,随着该新特性逐渐发展,你最终等于把两个组件实现成一个严重耦合、相互纠缠、难于解耦的组件,特别是当“解耦后无法保持客户已经习惯的旧有行为”,更加难以解耦。

3. 避免无意识的供应商依赖,这种依赖需要深入理解供应商的产品、它们对体系架构及其含义的影响。

4. 最小化持久化绑定,避免数据库依赖。对实体的关键访问路径应该仅通过主键,其它访问路径则应该在资源层进行分离,以便将来在其它形式的持久化中能处理这些可选路径。

遵循以上尽可能降低耦合度的规则可以让我们构建灵活的体系架构,这样的体系架构更容易与新技术和新模式集成,从而降低改变的成本、延长体系架构的生命期。

查看英文原文:Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture


译者简介: 张兵,有 Web 应用开发、XML 技术、消息中间件和企业服务总线等方面的开发经验,对 SOA 领域比较熟悉,关注软件架构技术和有效的项目管理。
架构