转载

演化架构的特点

来自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

正文到此结束