转载

浅谈演进式架构(一)

本文原文发表于个人技术博客 poseiden.top/posts/41729…

最近在读书计划和软件架构咨询师必读书籍的“催促”下，我读完了2020年的第一本技术书籍 ——《演进式架构》。也正好趁着全国疫情导致的哪里都不能去的严峻形势，写下一些关于这本书或这个概念的理解和心得，也为以后对这个本书同样感兴趣并有疑惑的小伙伴提供一些参考。

演进式架构支持跨多个维度的引导性增量变更。 ——《演进式架构》

这是本书在第一章第一节对 演进式架构 的作用做出的简洁定义。而在通篇读完这本书后，发现 演进式架构 中的三个重要元素则为 “增量式变更”***，***“适应度函数” 以及 ***“适当的耦合”***。那么我们接下来将以几个问题来简要分析，何为 演进式架构

以下均为个人心得和理解，如有不同意见和观点，欢迎一起探讨

演进式架构就是一种架构风格么？（不是指具体哪种架构模式，例如微服务，SOA，单体等等）

是的，起初在我还没翻开这本书时，以为演进式架构是一种新的架构模式，它不同与微服务，单体等。但通读完本书才明白， “演进” 只是一种能力，任何架构模式都具有此种能力，（没错，就连 "Big Mud" 也不例外），区别在于能里的高低。而本书第四章，则对常见的几种架构模式的 “演进能力” 进行了详细分析。

所谓增量变更就是小步提交和持续集成/部署吗？

按照几位作者的定义，增量变更包含两方面，增量构建软件和部署。而在第一章第二节的寥寥数语中可得知，小步提交，持续集成等实践都是做增量变更的基础，而增量变更有开发级别的（如：小步提交），部署级别的（如：蓝绿部署），甚至还有架构级别的。在开发方面，可测试是一个基础要素，有了它，才可以通过下面将要提到的适应度函数保障每次提交，构建出的代码在不破坏架构特征（规范）的前提下，对系统进行增量修改。而在构建上采用持续交付/部署流水线又可以在系统执行变更时自动化适应度函数的执行与校验。

引导性变更是说变更更具引导性吗？如果是，那么是哪种变更？

不知道是否为中西方语言文化差异，还是本人理解有误，初次听闻 “引导性变更” 一词，我的第一反应是 “该变更更具引导性，而不是其他特性” （主体为“变更”），而在我仔细阅读了此标题下的正文之后发现，其实是在作者引出了 “适应度函数” 这个概念后，表示是此“函数”（而非“变更”）可以引导相关的变更更加适应业务和技术环境的变化。

适应度函数就是各种各样的测试么？

适应度函数这个概念本身来源于遗传学中，具体可参考维基百科，这里不再详细赘述。而放在软件架中，简单来说，适应度函数有很多种，单元测试，E2E测试，契约测试等都只是一种基本的表现形式。由本书第二章可知，除了各种测试，还有一系列监控，代码坏味道的报告，甚至代码风格的checkstyle等。所以这里的**“适应度函数” 只是一个“接口”（抽象概念），凡是可以验证架构特征的“功能”都被称为适应度函数**。

为什么由ESB驱动的SOA不适合构建架构适应度函数？进而致使其架构演进的能力弱

本人其实没有真正接触过基于ESB的面向服务架构，但这一点却和本书作者有些不同看法。首先在这种架构中，ESB起到的作用有时会像 “流程编排” ，整个业务流会需要 ESB 组件去调度，否则则产生不了业务价值。而原子适应度函数是针对于单一的上下文，也就是架构量子去执行。在这一点上基于ESB的SOA的能力应该是和微服务是一致的。也就是说，个人并不同意书中所说的 “为其构建原子适应度函数几乎不可能” 。倒是对于整体适应度函数而言，由于基于 ESB 的 SOA 并不像微服务那样，基于一系列合理的方法论所划分处理出的限界上下文进而划分服务，所以这种架构模式需要整体适应度函数来保证业务价值和架构特性的几率也许确实要比微服务高很多。

防腐层之于架构演进能力的意义

即便不是经常接触DDD或整洁架构的同学我想对于 **防腐层（Anti-corruption Layer）**的概念也并不陌生。简单说就是防腐层架构模式是一种保护措施，使用抽象隔离了第三方类库或集成方的具体实现。这样做的好处有很多，其中之一是避免了业务逻辑与外部系统SDK的实现有所耦合，让架构师（实际上是每个开发人员）控制关于外部系统的耦合点。由于第三方系统默认是很不稳定的，所以架构师（实际上是每个开发人员）需要考虑后期一旦有所以变动如何将修改成本降至最低，也就是对 “增量修改” 更加友好。还有一点是我很喜欢的说法是对于这种架构策略，可以使得开发人员思考他们从这些耦合点的另一边获得的是哪种能力，而不是那些 SDK/API 的特定语法。

原文 https://juejin.im/post/5e9512a251882573b2196151

正文到此结束