写点什么

ThoughtWorks CTO:2025 年之前,我们会看到架构的演进,但不会看到革命

  • 2023-04-11
    北京
  • 本文字数:1566 字

    阅读完需:约 5 分钟

ThoughtWorks CTO:2025年之前,我们会看到架构的演进,但不会看到革命

QCon伦敦会议的第二天,ThoughtWorks 的 CTORebecca Parsons重新审视了演进式架构(evolutionary architecture)的理念并设想了在2025年前它将会出现的变化。她从演进式架构的定义开始,回顾了每项“能力”和属性,预测了在下一个阶段将会发生的变化。她的结论是,我们会看到演进,但不会看到革命。


演进式架构支持在多个维度上有指导性的、渐进式的变化。


Parsons 解释了为何采用演进这个词而不是敏捷或涌现。在与“演进式架构”一书的合著者 Neil Ford 进行了一次建设性、强有力的对话后,这个名字被确定了下来。最初,Ford 将这种做法称为“涌现式(emergent)”架构。虽然在代码方面,“好”与“坏”相对比较容易达成一致,但在架构方面就并非如此了。定义的指南部分指出了好的架构要有哪些部分组成。


这就是我们引入适应度函数(fitness function)的原因。适应度函数是一个特定的系统在多大程度上反映所需的行为特征的客观描述。


随后,Parsons 着重强调了可执行的重要性:在通往生产化的道路上,如何渐进式地增加新的特性并提供可行的机制?


演进式架构的重要实践和推动力之一就是与持续交付和最终的持续部署一同实现严谨性和自动化。


这些适应度函数应该被纳入到部署流水线中。


定义的最后一部分强调的是多维度方面。她使用一张幻灯片展示了几年前维基百科上的“能力(-ilities)”列表。这个列表后来有了一些变化,例如,更加注重可观测性。列表中的一个谬误是,我们无法最大化所有的能力,因为其中有些能力是互斥的:“有些系统是一次性的,不关心可演进性”。



接下来,Parsons 谈到了如今演进式架构的原则,并预测了它们在未来两年的发展。


个人认为,我们第一次尝试 SOA 的失败原因之一就是我们在系统周围画了边界。比我们围绕概念画出的边界更多。


最后的责任时刻:为了尽可能多地掌握系统的信息,我们想把决定推迟到最后的责任时刻(responsible moment)。需要做的权衡转换成了“能力”和适应度函数。


为可演进性而设计和开发:如果可演进性对你的系统很重要,那么它不仅对你如何编写代码很重要,而且对你如何结构化代码也很重要。


可读性是关键,这就是优质软件指标的作用所在。[...]这就是我们谈论边界、耦合和内聚的时候。


Postel 定律:对收到的东西要慷慨,对发送的东西要谨慎。


如果你只需要一个邮政编码,就不要验证收到的地址。这样,如果我决定把它分成两行,你就不需要在意它了


可测试性架构:测试某项功能的能力以及某项功能的可测试性如何,很好地说明了你的边界划分是否合理。如果你专注于测试金字塔的所有层次,你就会有更好的系统架构。


康威定律:可怕的人的问题。任何系统都会反映出所有组织的沟通情况。


如果你想要一个三阶段的流水线,你必定有三个小组。


最后,她谈到了这些原则在未来两年内会受到怎样的影响。根据 Parsons 的说法,“最后的责任时刻”和 Postel 定律都不会受到影响。


即使这些原则保持不变,但会有更多的创新,从而能够建立起更强大、更具“免疫性”的系统。不仅仅物联网、增强或虚拟现实等系统的复杂性中会融入创新,更多的创新将发生在机器学习模型的测试方式上。人工智能辅助开发会促进不同类型的开发技术的发展,如测试优先开发(Test First Development),即开发人员编写测试,人工智能生成代码,或其他方式。


所有这些都将通过增强持续部署流水线、增加对生产中测试的依赖以及扩大适应度函数和方法套件来实现。


她在演讲结束时这样总结说:


这些原则自始至终都是不变的,目前还没有迹象表明我们遗漏了什么原则。实践会不断发展,但不会有根本性的改变[......]即使创新会改变工具,但原则是不变的。演进式架构会继续发展,但不太可能会迎来一场革命。


原文链接:

Rebecca Parsons - ThoughtWorks CTO: By 2025 We'll See Evolution in Architecture, But Not Revolution


相关阅读:

架构师(2023 年 4 月)

浅析三款大规模分布式文件系统架构设计


2023-04-11 08:006459

评论

发布
暂无评论
发现更多内容

IM通讯协议专题学习(九):手把手教你如何在iOS上从零使用Protobuf

JackJiang

转角遇到爱,资源中心系统和图数据库

鲸品堂

技术 图数据库 企业号 2 月 PK 榜

GaussDB(DWS)性能调优:indexscan导致的性能问题识别与优化

华为云开发者联盟

数据库 后端 华为云 企业号 2 月 PK 榜 华为云开发者联盟

设计模式第五讲-装饰器模式和代理模式详解

C++后台开发

数据结构 设计模式 后端开发 Linux服务器开发 C++开发

从源码角度看React-Hydrate原理

flyzz177

React

【等保要求】等保要求堡垒机审计日志保留多久?

行云管家

等保 堡垒机 等级保护

阿里IM技术分享(十):深度揭密钉钉后端架构的单元化演进之路

JackJiang

Cloud Kernel SIG月度动态:发布ANCK 5.10-013版本、完整支持Intel SPR处理器

OpenAnolis小助手

开源 版本 内核 龙蜥社区 sig

2023最新Java面试手册(性能优化+微服务架构+并发编程+开源框架)

小小怪下士

Java 程序员 面试 金三银四

倒带ChunJun,同心前行|2022年度回顾&2023年共建规划

袋鼠云数栈

开源

喜讯:行云绽放荣获国家高新技术企业证书

行云管家

高新企业 高新技术 高新

StarRocks获评「2022 中国开源社区健康案例」!

StarRocks

数据库 开源

前端工程师leetcode算法面试必备-二叉树的构造和遍历

js2030code

JavaScript LeetCode

熊猫小说家功能升级:支持阅读原文+更多功能等你解锁

澜舟孟子开源社区

NLP 大模型 AIGC 澜舟科技

详解Redisson分布式限流的实现原理

华为云开发者联盟

后端 开发 华为云 企业号 2 月 PK 榜 华为云开发者联盟

企业级数据平台为什么要“可观测”? | StartDT Hackathon

奇点云

数据平台 可观测 云数据 黑客马拉松 奇点云

一文盘点,ZBC的应用场景与通缩场景

股市老人

用javascript分类刷leetcode22.字典树(图文视频讲解)

js2030code

JavaScript LeetCode

镜舟城市行|镜舟联手永洪科技共话数智运营

镜舟科技

数据库

为实现跨境文件高速传输,镭速传输都用了哪些技术

镭速

StarRocks 企业行|走进 58 同城,探索极速统一 3.0 时代的企业实践

StarRocks

数据库

前端工程师leetcode算法面试必备-二叉树深度广度遍历

js2030code

JavaScript LeetCode

三十分钟入门基础Go(Java小子版)

京东科技开发者

Java php Go nil 企业号 2 月 PK 榜

大咖说·图书分享|狼书(卷3):Node.js高级技术

大咖说

node.js 阿里云 开发者

深入react源码看setState究竟做了什么?

flyzz177

React

为什么西门子、美的等企业这样进行架构升级,看看改造效果就知道了

TDengine

数据库 tdengine 开源 时序数据库

PMR 提取视频特征,理解上下文

Zilliz

Flink X Hologres构建企业级Streaming Warehouse

阿里云大数据AI技术

大数据 数仓 企业号 2 月 PK 榜 分层技术

云小课|使用SpringBoot快速构建FunctionGraph HTTP函数

华为云开发者联盟

开发 HTTP 华为云 企业号 2 月 PK 榜 华为云开发者联盟

如何快速实现多指标计算

jiangxl

ThoughtWorks CTO:2025年之前,我们会看到架构的演进,但不会看到革命_架构_Olimpiu Pop_InfoQ精选文章