架構和設計領域技術演變詳解

作者 | InfoQ 英文站

譯者 | 無明

本文概述了我們對當前「架構和設計」領域的看法，這個領域側重於基礎設施模式、技術框架模式的實現，以及軟體架構師必須掌握的設計流程和技能。

關鍵要點

我們看到了「演化式架構」設計需求的增長，這種架構建立在可替換性設計和關注「膠水」組件的基礎之上。演化式架構支持功能性和跨功能性需求和約束的未來變化。

「微服務」架構可能會進入晚期大眾階段，但與「正確設計分散式系統」相關的主題以及反應式和容錯式設計將越來越靠近採用曲線。

我們預測有些架構主題永遠不會轉移到早期大眾或晚期大眾階段，但它們當中有一些高效的針對特定用例的模式，如基於事件溯源 /CQRS 或基於 Actor 模型的系統。

我們看到「架構師」這個角色越來越多地偏向於技術領導力、架構模式識別和框架意識以及橫切關注點設計。

雖然我們認為「serverless」這個術語有點含糊不清，但我們很欣賞 serverless 將重點放在設計事件驅動的系統以及自動消除某些平台問題的可能性上。

InfoQ 和 QCon 都關注處於「創新者、早期採用者和早期大眾」階段的主題。我們嘗試找出符合 Geoffrey Moore 所謂的早期市場的想法。早期市場「客戶群由技術愛好者和有遠見的人組成，他們希望走在機遇前面，解決迫在眉睫的問題」。我們也在尋找可能會「跨越鴻溝」以便得到更廣泛採用的想法。值得一提的是，技術在採用曲線上的確切位置可能會有所不同。例如，灣區公司目前廣泛採用微服務架構，但在其他地方可能不是這種情況，而且對他們來說採用微服務也許不太合適。

本文概述了我們對當前「架構和設計」領域的看法，這個領域側重於基礎設施模式、技術框架模式的實現，以及軟體架構師必須掌握的設計流程和技能。

從上次評審這個主題以來發生的顯著變化是「微服務」已進入到後期大眾。同時，根據我們內部的討論，與「正確設計分散式系統」相關的主題以及反應式和容錯式設計離採用曲線已經不遠了。在 Gartner 炒作周期中，微服務可能正在接近「幻滅低谷」的底部。

我們預測，有些架構主題永遠不會沿著採用曲線走向早期大眾或晚期大眾，但它們當中包含了幾種高效的架構模式——例如基於事件溯源 /CQRS 或基於 Actor 模型的系統——可以為某些組織和業務問題提供高效的解決方案。

雖然我們認為「serverless」這個術語有點含糊不清，但我們很欣賞serverless 將重點放在設計模塊化、事件驅動的系統以及自動化一些底層操作平台的可能性上。我們還看到了圍繞演化式架構的討論，演化式架構將為需求和約束的未來變化提供支持。

除了技術技能（如架構模式識別和框架意識）和處理橫切關注點設計的能力，我們看到「架構師」這個角色正在變得更加專註於軟技能，例如技術領導力。

下圖是 2018 年下半年的趨勢圖，2019 版位於文章的開頭。

以下是 InfoQ 的三位架構和設計（AD）主題編輯之間的內部聊天記錄（內容經過輕微的編輯），為圖中的技術定位提供了更多相關信息。

Daniel Bryant，獨立技術顧問、Datawire 產品架構師、InfoQ 新聞經理：

我認為 HTTP2 將進入早期採用者階段，而 HTTP3 則進入創新者階段。GraphQL（可能也包括 gRPC）可能會進入早期採用者階段（或創新者？）。我認為混沌工程應該加入 DevOps 的行列。微服務進入晚期大眾，BDD、DDD 和 TDD 也是。

我很想看到「演化式架構」出現在某個地方——可能是早期採用者？那麼「架構師即技術領導者」（強調角色的非技術演變）呢？

我很想聽聽你們的想法，我們是否需要移動、添加或刪除某些主題？

Jan Stenberg，IT 顧問，在.Net/C# 和 JVM/Java 方面擁有超過 25 年的經驗：

我認為 AD 在某種程度上與 InfoQ 報道的其他主題不同。

在 AD 方面，我們沒有新的或更新的架構常規基礎。相反，由於新的工具、框架或智能架構的出現，已有的想法會再次流行起來，並且可能被包裝和品牌化。

有一些領域可以被納入到兩個隊列中。從高層面來看，它們可以被納入到 AD 中，而技術性部分則應該被納入到另一個隊列。我認為 serverless 就是這樣的一個例子，從高層面來看，它是 AD 的一個重要領域，而技術性部分則屬於雲隊列。微前端和類似的技術則是另外一個例子，它應該屬於 AD 還是 HTML5 和 JavaScript？

我認為有一些領域或架構永遠不會出現在早期大眾或晚期大眾階段，但它們當中卻有一些我最喜歡的架構，比如基於事件溯源 /CQRS 或基於 Actor 模型的系統。我認為，在可預見的未來，它們將是少數人使用的利基架構。我不確定我們應該如何看待這些主題，或許當架構師和開發人員不再談論它們時，它們就會消失？

以下是我對 AD 未來的看法（或許我希望這樣）：

serverless。去年我聽過這方面的演講，它們給我的印象是這一領域將越來越自動化，底層基礎設施的工作量將越來越少。

工作流平台（如 Camunda）。我認為它們對於具有複雜業務邏輯的微服務或分散式系統來說非常重要。

事件溯源 /CQRS。我希望它會變得更加主流，可能會進入早期採用者或早期大眾階段。

事件驅動的架構，進入早期採用者或早期大眾階段。

Actor 模型 / 反應式。去年我和 Vaughn Vernon 討論了這件事，他認為有一天它們會成為主流，但我對此持懷疑態度。

演化式架構很有趣，我認為它進入早期採用者階段是對的。

混沌工程。是的，它應該屬於 DevOps，從 AD 角度討論這個主題可能是一個例外。

GraphQL 和類似的工具應該屬於創新者或早期採用者，它將取代 REST。

架構師即技術領導者。我在家中與各種各樣的架構師會面，他們大部分人的主要工作是讓商業 / 政府領域專家了解他們自己的領域，所以架構師更應該被納入到敏捷隊列中？

微服務進入晚期大眾。我認為微服務很快將成為「今天的 SOA」。很多人用對了，也有很多人將它實現成了分散式單體。

DDD 進入晚期大眾，但我希望它仍然會是 InfoQ 的一個有趣的主題。

BDD 進入晚期大眾，或「晚期少數派」。

關於 TDD，仍然或多或少會有一些討論。單元測試或黑盒測試或者其他，但至少會進入晚期大眾。

當我在日常生活中（不是在技術大會和類似的活動中）遇到架構師、開發人員和領域專家時，我意識到，我們在這裡討論的很多概念對於他們來說是未知或非常彌散的，這也使得他們很難看到 InfoQ 的好處。大約兩年前，我在開發者大會（應該是在加拿大）上聽過一個演講，Vaughn Vernon 問有多少人對 DDD 有所了解，大約有一半的觀眾舉起了手。

當我開始成為 InfoQ 編輯時，我寫了一些有關框架和庫的文章，我認為這些框架和庫新增的功能可能會影響架構，但隨著時間的推移，我寫的東西越來越關注有趣的博文和演示文稿上，只有一小部分是關於與特定架構密切相關的框架，如 Axon、Akka。

在 QCon 大會期間進行這種討論會很棒。

Charles Humble，InfoQ 主編：

我和 Vaughn Vernon 都認為 Actor 模型很可能會成為主流——無論是直接地還是通過消息傳遞來實現。在 JVM 領域，Akka 在這方面做得很好，而在金融領域，基於消息傳遞的系統長期以來一直是實現 Actor 模型的一種流行的方式。

Actor 似乎很容易掌握和理解，也是處理大規模並行工作的一種很好的方法。我希望看到在 Pony 之上構建基於 Actor 模型的現代系統，並成為一個榜樣，但我不得不說，我個人認為這不太可能。

關於演化式架構，Martin Fowler 去年在播客上談到了這個問題。我很期待 Thoughtworks 的這本書。

Thomas Betts，IHS Markit 首席工程師和 InfoQ Architecture Queue 負責人：

從高層面來看，我同意 Daniel 的大部分觀點。Jan 是對的，一些架構模式順著圖中的趨勢自然演進，而其他一些則可能永遠不會超過早期採用者階段，因為它們並不會被廣泛採用。

有時候，我會對 AD 與 InfoQ 其他主題之間的重疊部分感到困惑，尤其是文化與方法論（CM）。我想這與康威定律有關。架構的很多內容都歸結為通信——進入和離開系統的外部通信點是什麼？內部服務是如何相互通信的？如何保存和訪問數據？

在很多方面，公司解決這些問題的方式以及他們可以選擇的選項將基於它們在 AD 和 CM 採用生命周期曲線上的位置。我認為 AD 是這個等式的技術端，而 CM 是非技術端，但這樣的比喻似乎過於簡單化了。此外，技術實現可能應該屬於開發和 / 或語言隊列。AD 處於兩者之間的軟弱處，處理橫切面關注點，為如何實現系統提供指導。

我想添加一些具體的討論點。

serverless——雖然我個人不喜歡這個術語，因為它似乎沒有任何特定的含義，它或許應該在早期採用者階段。

反應式——可能應該屬於早期採用者。我認為反應式架構會變得更加普遍，因為開發人員越來越熟悉反應式編程，特別是在使用 JavaScript 時。

DDD——雖然 DDD 本身可能會進入晚期大眾，但仍然會有很多與 DDD 密切相關的衍生想法，這些想法會在創新者或早期採用者中。例如，事件溯源可以進入早期採用者或早期大眾。但是，我不認為很多子主題應該被包含在 AD 主題圖中。

微服務——與「serverless」一樣，它是一個容易被濫用或誤解的術語。我認為隨著它被廣泛採用，將進入晚期大眾，但可能在分散式架構方面處於早期採用者階段。

分散式系統——我認為把它放在主題圖中並不合適，因為這個概念太寬泛了。但我希望我們在談論系統設計時可以考慮到分散式。像反應式和容錯這樣的想法對於構建健壯的分散式系統來說至關重要，而它們在單體系統中可能沒有那麼重要。這就是為什麼要在 AD 主題圖中加入混沌工程。

我完全支持在 QCon 大會上討論這些話題！

關於作者

Thomas Betts 是 IHS Markit 的首席軟體工程師，擁有 20 年的專業軟體開發經驗。他一直致力於提供令客戶滿意的軟體解決方案。他曾在多個行業工作，包括零售、金融、醫療、國防和旅遊。Thomas 與妻子和兒子住在丹佛，他們喜歡徒步旅行，也喜歡探索美麗的科羅拉多州。

Daniel Bryant 正在引領組織和技術變革。他目前的工作包括通過引入更好的需求收集和規劃技術來實現組織敏捷性，重點關注敏捷開發中的架構相關性，以及促進持續集成 / 交付。Daniel 目前專註於「DevOps」工具、雲 / 容器平台和微服務實現。他還是倫敦 Java 社區（LJC）的負責人，為多個開源項目做出貢獻，為 InfoQ、DZone 和 Voxxed 等知名技術網站撰寫文章，並定期出席 QCon、JavaOne 和 Devoxx 等國際性會議。

Charles Humble 於 2014 年 3 月接任 InfoQ.com 的主編，指導我們的內容創作，包括新聞、文章、書籍、視頻演示和訪談。在擔任 InfoQ 的全職工作之前，Charles 負責我們的 Java 報道，並擔任 PRPi 諮詢公司的首席技術官，PRPi 諮詢公司是一家名譽研究公司，於 2012 年 7 月被普華永道收購。他全面負責 PRPi 公司內部使用的定製軟體的開發。他在企業軟體領域工作了大約 20 年，曾經是開發人員、架構師和開發經理。在業餘時間，他為 Twofish 創作音樂，首張專輯於 2014 年 2 月發行，並儘可能多地與妻子和孩子在一起度過。

Jan Stenberg 在瑞典北部的一名 IT 顧問，工作超過 25 年，在.Net/C# 和 JVM/Java 方面有著豐富的經驗。他的經驗範圍從大型分散式和基於服務的系統到基於 Web 和富客戶端應用程序，再到硬體相關的軟體。

英文原文

https://www.infoq.com/articles/architecture-trends-2019

點個好看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！