微服务架构风格正在风靡全球。去年三月，O'Reilly举办了他们的第一次软件架构会议，并且计划委员会在微服务的某些方面获得了大量的摘要。为什么这种建筑风格突然风靡一时？

微服务是DevOps革命后的第一个建筑风格，第一个完全接受持续交付的工程实践。它也是一个演化架构的例子，它支持增量不间断变化，作为应用程序结构层面多维度的第一原则。但是，它只是支持某些进化行为的一组架构之一。本文探讨了这一系列建筑风格的一些特征和原则。

进化架构

软件中的常识曾经认为，建筑元素“以后难以改变”。作为第一原理，进化架构设计用于架构中的增量变化。进化架构很有吸引力，因为改造在历史上很难预测，而且改造成本也很高。如果体系结构中内置了渐进式变更，那么变更就会变得更容易，更便宜，从而允许更改开发实践，发布实践和整体敏捷性。

微服务因其强大的有界环境原理而符合这一定义，使得Evan的域驱动设计中描述的逻辑划分成为物理分离。微服务通过高级DevOps实践（如机器配置，测试和自动部署）实现这种分离。因为每个服务都与所有其他服务（在结构级别）分离，所以将一个微服务替换为另一个微服务类似于将一个乐高积木换成另一个。

进化架构的特征

进化架构具有几个共同的特征。我们已经为即将到来的进化建筑书确定了大量的内容;这里有几个。

模块化和耦合

如果开发人员想要进行不间断的更改，那么将组件沿明确定义的边界分离的能力就会明显受益。没有任何建筑元素，传说中的泥球大球，不支持进化，因为它缺乏区域化。

来自一个未命名的客户项目的泥球大球中的类别（周边点）之间的耦合。]

不恰当的耦合通过以难以预测的方式传播变化来抑制进化。进化架构都支持某种程度的模块化，通常在技术架构上（例如，经典的分层架构）。

围绕业务能力进行组织

现代成功的体系结构越来越多地在域架构级别上具有模块化，受域驱动设计的启发。基于服务的体系结构与传统SOA的区别主要在于分区策略：SOA严格按技术层划分，而基于服务的体系结构倾向于微服务的灵感域分区。

实验

实验是超级大国的进化架构之一，为企业提供服务。对应用程序进行操作上廉价的微不足道的改变可以实现常见的持续交付实践，如A / B测试，Canary Releases等。通常，微服务架构是围绕服务之间的路由来定义应用程序，允许在生态系统中存在特定服务的多个版本。这反过来允许实验和逐步替换现有功能。最终，这种力量使您的企业能够花更少的时间来推测故事积压，而是参与假设驱动的开发。

进化架构原理

思考进化架构的一种方法是通过原则。这些原则描述了架构本身或架构设计方法的各种特征。一些原则将注意力集中在何时在流程中做出特定的架构决策。

合适的功能

我们区分紧急和进化架构，这种区别是重要的。与遗传算法等进化计算技术非常相似，建筑适应度函数指定了我们的目标体系结构。有些系统需要很长的正常运行时间，而有些则更关注吞吐量或安全性。

[雷达图用于突出适用于该软件系统的重要适应度函数。]

关于特定系统的适应度函数的前期思考为决策制定和决策时间提供了指导。建筑决策相对于适应度函数进行评分，以便我们可以看到架构正朝着正确的方向发展。

带来痛苦

由于极限编程社区的启发，持续交付和进化架构中的许多实践都体现了带来痛苦向前的原则。当项目中的某些东西有可能引起疼痛时，强迫自己更频繁，更早地进行，这反过来又会鼓励您自动消除疼痛并尽早发现问题。通过部署管道，自动化机器配置和数据库迁移等常见的持续交付实践，通过消除常见的变更难点，可以简化进化架构。

最后的责任时刻

当决策发生时，传统架构和进化架构之间存在重大区别。这些决策可能围绕应用程序的结构，技术堆栈，特定工具或通信模式。在传统架构中，这些决策在编写代码之前就会早期出现。在进化架构中，我们等待最后一个负责任的时刻来做出决策。延迟决定的好处是可用于做出决定的额外信息。成本是一旦做出决定就必须进行的任何潜在的重新工作，这可以通过适当的抽象来减轻 - 但成本仍然是实际的。但是，过早做出决定的成本也是真实的。考虑选择消息传递工具。各种工具具有不同的支持功能。如果我们选择比我们最终需要的更重的工具，我们已经在我们的项目中引入了技术债务来源。这种债务是以使用错误工具导致的发展拖累的形式出现的。这不是先发制人地“抽象所有事情”的借口 - 我们仍然支持敏捷的YAGNI（你不需要它）原则 - 而是在适当的时候做出决定的明智尝试。

当然，在考虑最后一个负责任的时刻时，当前的问题是决定何时。适应度函数为该决定提供指导。应该更早地做出对其他架构或设计选择产生重大影响的决策，或影响项目关键成功因素的决策。延迟做出决定对项目的影响往往大于等待的好处。

结论

软件架构师有责任通过创建图表来阐明系统如何组合在一起的决策。太多的建筑师没有意识到静态的二维建筑图片的保质期很短。软件世界处于不断变化的状态;它是动态的而不是静态的。架构不是一个等式，而是一个正在进行的过程的快照。

持续交付和DevOps运动说明了忽略实施架构并保持最新状态所需工作的缺陷。建模体系结构和捕获这些工作没有任何问题，但实现只是第一步。架构在实施之前是抽象的。换句话说，除非你不仅实现了它，而且还要升级它，否则你无法真正判断任何架构的长期可行性。甚至可能使它能够承受不寻常的事件。

架构师的操作意识对于进化架构至关重要。 Evolution会影响实现的细节，因此实现细节不容忽视。持续交付对架构的要求使得实施更加明显，并使其演变变得容易。因此，持续交付是任何进化架构的重要推动因素。

其他资源：

在ThoughtWorks Tech Leaders Podcast的这一集中，Rebecca和Neal讨论了进化架构的含义以及组织如何将其用作业务优势。

原文：https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture

本文：http://pub.intelligentx.net/microservices-evolutionary-architecture

讨论：请加入知识星球或者小红圈【首席架构师圈】