演化架构的特点

  • Jan Stenberg
  • 刘嘉洋

2016 年 4 月 11 日

话题:语言 & 开发架构

来自 Thoughtworks 的Rebecca ParsonsNeal Ford在描述演化架构特点和原则时声称:演化架构的首要原则是支持增量的、非破坏性的变更。微服务架构就是这种架构的一个很好的例子。由于使用了来自领域驱动设计(Domain-Driven Design,DDD)的强有界的上下文,他们相信微服务架构符合演化架构的原则。

Ford 和 Parson 一样来自 Thoughtworks,他指出,他们定义“演化架构”的工作还在进行中,但是“演化架构”目前被如下定义。

演化架构,以多维度支持连续、增量的变更作为首要原则。

演化构架有许多特点,Ford 和 Parsons 只介绍了其中一部分:

  • 模块化与耦合:支持模块化,在技术架构层面,意味着划分边界明确的组件。反过来,这也简化了非破坏性变更,给需要做这些改变的开发者带来了很大的便利。相比之下,他们发现大泥球架构就缺少模块化,因此不支持演化。
  • 以业务能力来组织:在领域层面,模块化越来越多地通过 Domain-Driven Design (DDD) 来实现。微服务中以业务领域划分模块,这与 SOA 中严格以技术层次划分模块大相径庭。
  • 实验:Ford 和 Parsons 指出这是给商业带来的非常有效的手段。允许以A/B 测试金丝雀发布(Canary releases)方式对应用进行的变更,相对于其他事情相比,微不足道。另外,微服务架构可以被设计成允许相同服务的多个版本同时运行。这使得做实验是允许的,并会最终导致假设驱动开发(Hypothesis-Driven Development)的使用。

另外一种观察演化架构的方法是通过原则。这些原则描述了架构或设计架构的方法的特点。专注于架构决策的原则包括:

  • 适应度函数:一个架构级别的适应度函数指明系统的许多重要特点。例如,正常运行时间的等级、吞吐量、可用性以及安全需要。其中一种可视化方式是通过雷达图展示不同函数的使用。
  • 提前做让你感到痛苦的事:在做某个项目的时候,越早、越多地出现“痛苦”就能越快地识别出导致这些“痛苦”的问题并鼓励自动地消除这些“痛苦”。持续交付,比如说部署流水线、数据库迁移可以让演化架构变得更简单。
  • 最后责任时刻:传统架构和演化架构的最大不同是何时做出决策。在传统架构中,例如说有关结构、技术堆栈和通信模式方面的决策做得很早,要先于写代码。而在演化架构中,我们要等到最后责任时刻才能做决策。此时做决策是非常困难的,这时适应函数就可以给我们提供指导建议。对架构或者项目的关键成功因素有重大影响的决策必须提前做出。

Ford 和 Parsons 最后指出架构不是一个等式,而是持续过程的快照,参照持续交付DevOps运动,他们强调了运营意识对演化架构非常重要。

Ford 最近在一个网络研讨会上谈到了有关演化架构的内容。

QCon London 2015会议上 Parsons关于这个主题做了演讲

Jimmy Bogard 曾在 2010 年发表有关演化架构的博文。

查看英文原文Characteristics of Evolutionary Architectures


感谢丁涛对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

语言 & 开发架构