微服务即演进式架构

微服务架构风格正在席卷全球。去年三月,O’Reilly举办了他们的第一届软件架构大会,提交的话题中与微服务相关的占绝大部分。那么为什么这种架构风格会突然如此流行了呢?

微服务是后DevOps革命时代出现的第一种全新架构风格。它第一个全面拥抱持续交付的工程实践,也是演进式架构家族的一员。演进式架构以支持增量的、非破坏的变更作为第一原则,同时支持在应用程序结构层面的多维度变化。不过,微服务仅仅是支持某些演进行为的众多架构之一。本文分享了演进式架构风格的一些特点和原则。

演进式架构

软件行业曾经有这样一个共识,架构一旦确定,“日后很难改变”。演进式架构将支持增量式变更作为第一原则。由于历来变更都是很难预测的,改造的成本也极其昂贵,所以演进式架构听上去很吸引人。如果真的可以在架构层次做到演进式地变更,那么变更就会更容易、成本更低,也能发生在开发实践、发布实践和整体敏捷度等多个地方。

微服务满足这一定义,因为它遵循强边界上下文的原则,从而使得Evan的领域驱动设计中描述的逻辑划分变成物理上的隔离。微服务能够通过采用自动化基础设施建构、测试、自动化部署等先进的DevOps实践,获得这种分离。因为每个服务在结构层面与其他服务都是解耦的,替换服务就像替换乐高积木一般。

演进式架构的特点

不同的演进式架构展示了一些共同的特点,我们已经识别了很多特点,并收录进即将出版的《演进式架构》一书里。本文将分享其中的几个特点。

模块化和耦合

边界划分明确的组件,显然可以给希望做出非破坏性变更的开发人员以更大的便利。而毫无架构元素的大泥球架构就无法做到演进式变更,因为它缺少模块化。

[在一个大泥球项目中类(图中圆边上的点)与类之间的耦合度 – 来自一个不愿透漏名字的项目]

不适当的耦合将变更导向难以预料的方向,从而阻碍演化。而演进式架构都支持一定程度的模块化,这种模块化通常体现在技术架构层面(例如经典的分层架构)。

围绕业务能力组织

受领域驱动设计的启发,越来越多的成功架构都以在领域架构层的模块化为特色。基于服务的架构与传统的SOA主要区别在于模块划分的策略,SOA是严格按照技术层进行模块划分,而基于服务的架构则倾向于按业务领域划分。

试验

试验(experimentation)是演进式架构给商业交付带来的最大价值之一。从操作角度来讲,可以采用A/B测试、金丝雀发布等常见的持续交付实践对应用进行低成本的、微小的变更。微服务架构常常是围绕服务之间的路由来定义应用程序的。通常,微服务架构围绕服务之间的路由来定义应用程序,允许同一个服务的多个版本同时运行。这反过来也使得试验和现有功能的逐步替换成为可能。最终,这使得你的业务可以花更少的时间去猜测待办故事项,从而投入到假设驱动开发中。

演进式架构的原则

思考演进式架构的另一个方法就是通过考察它的原则。原则描述了架构本身的不同特点或者设计架构的方法,其中一些原则专注在特定的架构决策的过程。

适应度函数

我们将浮现式和演进式架构区别对待,并且认为这种区分是很重要的。就像在进化计算技术中的遗传算法一样,一个架构级别的适应度函数指明了我们的目标架构是什么样子,其中一些系统关注高运行时间,而其他一些系统则会更关注吞吐量或者安全。

[这张雷达图展示了适用于软件系统的几个重要的适应度函数]

在项目前期思考一个特定系统的适应度函数,可以对决策的制定和决策的时机提供指导。适应度函数是对架构决策的衡量,通过适应度函数,我们可以预见架构是否在向正确的方向演进。

痛苦的事提前做

受极限编程社区的启发,许多持续交付和演进式架构的实践都体现了“痛苦的事提前做”的原则。在做一个项目的时候,如果一些事情可能会很痛苦,那么你需要强迫自己更早更频繁地去做这些事情。这反过来会鼓励你用自动化的手段消除这些痛苦并能提前识别问题。那些基础的持续交付实践,如部署流水线、自动化基础设施建构、数据库迁移,就是这一原则的应用,它们会提早解决变更带来的常规问题,从而使架构的演进更容易。

最后责任时刻

决策的时机是传统架构和演进式架构的最主要区别。这些决策可以是围绕应用程序的结构、技术栈、特定的工具或通信模式。在传统的架构中,这些决策发生在早期写代码之前。而在演进式的架构中,它们发生在最后责任时刻。延迟决策的好处是有更多可用的信息来辅助决策。其成本是在做出决定后任何可能出现的重复工作,这些工作可以通过合适的抽象得到减轻,但成本仍然是实打实存在的。相比而言,决定太早的成本也是很明显的。比如一个通讯工具的选择,不同的工具有不同的特性。如果我们选择一个可能最终也不会用到的重量级工具,那就是在项目中引入了技术债。这个技术债是由于使用了错误的工具导致开发进度延缓而出现的。你不能拿事先“抽象一切”作为借口。我们仍然支持敏捷YAGNI(You Ain’t Gonna Need It,你不会需要它)的原则,但会更倾向于在合适的时候做出决策。

当然,我们在考虑最后责任时刻的一个最直接的问题就是,什么时刻是最后责任时刻。适应度函数对这个问题提供了指导建议。那些会对架构、设计选型或者项目的关键成功有重大影响的决策,都必须尽早做出,延缓这些决策往往得不偿失。

总结

软件架构师常常用画图的方式来解释系统之间的适配,然而太多的架构师并没有意识到,一个静态的二维架构图的生命是很短暂的。软件世界是不断变化的,它是动态的而不是静态的存在。而架构也并不是一个等式,它是持续过程的快照。

持续交付和DevOps运动都诠释了一个问题,即由于忽略实现架构并使之保持常新所要付出的精力。其实架构建模和付出这些精力本没有什么问题,但是架构的实现仅仅是第一步。架构只是抽象,直到真正投入运维。换句话说,如果你没有实现并升级过一个架构,甚至帮它度过难关,那么你就无法真正判断架构的长期生命力。

架构师的运维意识是演进式架构的关键。演进会影响具体的实现,因此这些实现细节是不能忽略的。持续交付在架构层面的要求,使得实现更可视化,演进更简单化。因此,持续交付是所有演进式架构重要的助力。

其他资源:

在这期ThoughtWorks技术领袖播客中,Rebecca和Neal讨论了演进式架构的含义,以及组织如何将它作为商业优势加以使用。

作者:Neal Ford & Rebecca Parsons
译者:禚娴静
原文链接:Microservices as an Evolutionary Architecture

1 1 收藏 1 评论

关于作者:ThoughtWorks

ThoughtWorks是一家全球IT咨询公司,追求卓越软件质量,致力于科技驱动商业变革。擅长构建定制化软件产品,帮助客户快速将概念转化为价值。同时为客户提供用户体验设计、技术战略咨询、组织转型等咨询服务。 个人主页 · 我的文章 · 60 ·   

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部