转载

演化架构的特点

来自Thoughtworks的 Rebecca Parsons 和 Neal 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 )关注我们。

原文  http://www.infoq.com/cn/news/2016/04/evolutionary-architectures
正文到此结束
Loading...