我们已经准备了Neil Ford的文章翻译，该思想是软件开发公司ThoughtWorks的系统架构师和意识形态策划者，该公司将软件测试和部署过程自动化。
Neil是一位公认的软件开发专家，致力于敏捷设计和系统架构的十字路口。 他是许多文章，书籍和数十个视频演示的作者，并在领先的开发者大会上发表演讲。 您可以在
nealford.com上看到他的作品。
微服务作为进化架构
微服务架构正在迅速征服世界。 3月，O'Reilly出版公司组织了首届O'Reilly软件体系结构会议。 几乎60％的报告都致力于微服务使用的某些方面。 为什么这种特殊的建筑风格突然变得如此流行？
微服务架构是在DevOps之后出现的一种新的架构设计风格，它包含了连续的软件交付实践。 它也是一个演化体系结构的示例，该体系结构在应用程序的结构级别遵循几个维度上的逐渐，连续变化的原理。 本文讨论了该系列建筑风格的一些显着特征和原理。
进化架构
以前，人们认为建筑元素“在创建后很难改变”。 逐渐变化是进化架构的主要原理。 正是由于架构变更一直很难预见且制造成本高昂，它才引起了普遍的关注。 如果在架构本身中内置了进行演化更改的可能性，那么它们的实现将变得更加简单和廉价，从而有助于软件开发和发行实践的变化，并提高总体流程的灵活性。
微服务架构完全符合此想法，因为它具有
绑定上下文 ，该
绑定上下文根据Eric Evans的域驱动设计在逻辑上进行分配，并实现为物理上独立的组件。 通过实现DevOps实践（例如虚拟机配置，测试和自动部署）可以实现这种分离。 由于每个服务都与所有其他服务（在结构级别上）分开，因此用另一个微服务替换一个微服务就像交换lego多维数据集一样容易。
进化架构的特征
演化架构具有许多共同的特征。 所有这些功能将在即将出版的有关进化体系结构的书中进行描述。 在本文中，我们仅提供其中一些。
模块化和连通性
在定义明确的边界内共享组件的能力使开发人员在必要时可以不断进行更改。 如果没有设计该体系结构，并且该系统看起来像一个泥泞的大球（“泥浆
大球”体系结构 ），那么就不可能进行进化更改，因为这种结构中没有明显的部分。
[来自未命名客户项目的一大堆污垢中的类之间的关系（周围的点）。]由于进行更改可能会不可预测地影响系统的其他部分，因此错误的组件互连会阻碍系统的发展。 所有的演化架构都提供某种程度的模块化，通常是在技术架构（例如分层架构）的层次上。
围绕商机进行组织
在现代成功的体系结构中，受面向主题设计原则的影响，领域级别的模块化被越来越多地使用。 基于服务的体系结构与传统的面向服务的体系结构（SOA）的主要区别在于其服务分配策略。 面向服务的体系结构严格按技术级别划分，而基于服务的体系结构则主要构建在微服务定义的主题区域的某些部分中。
实验
进行实验是进化架构为业务带来的重要优势之一。 可以轻松地对应用程序进行小的更改的功能提供了常用的连续部署实践的使用，例如A / B测试，针对一组有限用户的测试（Canary版本）以及其他。 微服务架构通常基于路由服务调用而构建，这使得在整个生态系统中使用服务的多个版本成为可能。 反过来，这为试验和更改现有功能提供了巨大的机会。 最终，在开发业务应用程序时，花在讨论计划和待办事项上的时间更少，并且开发主要以快速假设检验的模式进行。
进化架构原理
通过了解其基本原理，可以获得更完整的进化架构图。 这些原则涉及架构本身及其设计方法的各种特征。 这些原则的一部分与在系统设计过程中做出体系结构决策时的选择有关。
健身功能
有必要区分紧急情况（由设计过程形成）和演化架构-这是非常重要的。 像进化计算方法（例如遗传算法）一样，建筑适应性函数为建筑设计设定了目标。 对于某些系统，主要要求是较长的正常运行时间，而对于其他系统，则是高性能或安全性。
[用于突出显示与此软件系统相关的重要适应性功能的雷达图。]
如果您预先确定特定系统的适应性功能，这将有助于将来及时做出正确的决定。 对于不同的体系结构解决方案，您可以计算适应度函数，如果适应度函数的值变得更好，则表明体系结构正在朝着正确的方向发展。
注意痛点
持续提供软件和开发不断发展的体系结构中使用的许多工作方法都是基于eXtreme编程社区制定的“注意痛点”的原则。 当设计工作中出现可能成为问题根源的时刻（痛点）时，有必要尽快加以注意。 这将有助于提前发现潜在问题并按工作顺序消除它们。 在设计演进式体系结构时，常见的连续交付实践（例如部署管道，虚拟机的自动配置和数据库迁移）可以极大地简化在变更阶段消除痛点的过程。
决策点
传统架构与进化架构之间的主要区别在于做出重大决策的时间。 这些决定可能与应用程序结构，技术堆栈，单个工具或通信模式有关。 在设计传统体系结构的情况下，此类决策是在编写代码之前的初始阶段做出的。 在开发演化体系结构的过程中，任何决定都应尽可能晚地做出，直到最后一刻仍然可以接受。 以后做出决策的好处是，此时可能会提供其他信息。 这种方法的成本包括在做出决定后可能对体系结构进行改进的成本。 可以使用适当的抽象来减少这些成本，但是仍然可以发生。 但是，在初始阶段做出决策的成本也是相当现实的。 例如，做出选择消息传递工具的决定。 不同的工具支持不同的功能。 如果我们选择了比必要的功能更强大的工具，那么我们将得到一个构想不周的架构，这将不可避免地需要进一步的开发。 由于选择了错误的工具而产生的“技术债务”将给开发人员带来额外的负担。
当然，最后可能做出决定的主要问题是确定何时到来。 为此，请着重健身功能。 首先，必须做出对体系结构或设计元素的选择有重大影响的决策，以及对项目的总体成功有重大影响的决策。 推迟做出这样的决定所带来的负面影响往往超过了以后做出决定所带来的好处。
结论
通常，软件架构师应使用各种图表来说明有关正在开发的系统设计的决策。 架构开发人员经常陷入呈现软件架构作为他们需要解决的方程式的陷阱。 软件架构师提供的许多商业工具允许您以正方形，直线和箭头的形式正式描述架构。 尽管这样的图可能有用，但是它们仅提供二维显示，是理想世界的快照，但是我们生活在二维现实中。
为了用生命填充这样的二维图，必须对其进行指定。 二维图中的
ORM标签变为
Hibernate v4.2.17 ，使所涉及的世界变为三维。 当您有一个计划在生产中实施并在六个月后更新到必然版本的
Hibernate v4.3.0.1时 ，您就可以为三维世界做好准备了。 许多建筑师没有意识到静态的架构视图寿命很短。 软件世界以流状态存在；它是动态的，而不是静态的。 体系结构不是方程式，而是正在进行的过程的快照。
连续软件交付和DevOps的实践表明，由于缺乏对实现和支持体系结构所需的努力的了解，问题变得越来越严重。 实施体系结构只是第一步。
在将其付诸实践之前，体系结构一直是一种抽象。 换句话说，只有当您不仅实施而且至少修改了一次之后，才能判断任何体系结构的长期生存能力。 也许他们在此过程中设法应付了意外。
软件架构师对操作能力的理解对于开发演化架构至关重要。 体系结构的演进发展会影响其实现的功能，因此在完成过程中必须将它们考虑在内。 该体系结构的持续交付过程的要求旨在改善其可视化并简化更改。 这样，连续交付可增强演化架构的功能。
11月19日，尼尔·福特（Neil Ford）抵达莫斯科，参加了
关于创建演化软件体系结构的大师班。