本文要點：
-
我們關注的新軟件架構趨勢包括微前端、數據網格、AsyncAPI以及策略即代碼（Policy as Code）。各種各樣的跡象表明，在架構的很多不同領域中，創新正在不斷涌現。
-
微服務變得越來越普遍，但使用微服務架構的阻力卻越來越大。越來越多的公司正在研究正確地構建分佈式系統的基礎原理，或者是創建現代化的、模塊化的單體應用，以方便將來將它們拆分爲微服務。
-
GraphQL顯然已經跨過了鴻溝，唯一尚有爭論的地方是它的採用到了何等廣泛程度。在GraphQL的擴展性方面，依然還有一些創新，以使其能夠在大型企業中普遍適用。
-
人們對於low-code/no-code平臺越來越感興趣，藉助它們，非開發人員也能對系統進行定製。
-
我們所跟蹤的一些架構理念只能適用於特定的場景。因此，在採用曲線上沒有太多進展。這方面的示例包括函數式編程和事件驅動架構。
![]()
好的軟件架構的目標是幫助管理複雜的系統。爲了應對分佈式系統、事件驅動架構和大數據，軟件架構方面的最新創新希望能夠利用正在出現的最佳實踐，並且指導工程師遠離常見的陷阱。
InfoQ架構和設計的概覽圖關注主要的軟件架構概念及其當前在行業中的採用現狀。InfoQ和QCon會關注圖片左側的內容，主要涵蓋創新者（Innovators）和早期採用者（Early Adopters）的軟件趨勢狀態。同時，我們也會尋找那些最終“跨越了鴻溝”並被大多數公司所採用的理念。
負責架構與設計（Architecture and Design，A&D）的InfoQ編輯會定期討論這個概覽圖，識別我們應該關注的新趨勢，並且指出現有條目的重要變化。本文提供了我們內部討論的一些重點，併爲概覽圖中所顯示的內容添加了必要的註釋。
本次討論的貢獻者包括：
- Charles Humble：InfoQ的總編；
- Daniel Bryant：InfoQ的新聞主管；
- Thomas Betts：InfoQ軟件架構和設計的主編；
- Jan Stenberg：InfoQ架構和設計的編輯。
在過去的一年中，我們在架構與設計領域看到了一些值得注意的新想法，其中每種想法都對應了一組不同的軟件趨勢。例如，隨着微服務被越來越廣泛地採用，實踐者發現了它的更多優點和缺點，於是出現了一些模式，幫助我們強化那些運行良好的方面，並使下一代微服務更加成功。
創新者
在創新者方面包括四個新的趨勢：微前端（Micro frontends）、AsyncAPI、數據網格（AsyncAPI）和策略即代碼（Policy as Code）。
微前端
微前端將微服務能夠帶來的收益引入到UI層。通過將複雜的系統拆分爲更小、更易管理的部分，團隊可以更快地開發和發佈新特性和新功能。
繼出現在InfoQ Podcast上之後，我們再次聯繫到了Building Micro Frontends一書的作者Luca Mezzalira，瞭解他對未來一兩年內的展望。
Luca Mezzalira：微前端並不是一個新的趨勢，但是在2019年它的發展很迅速。
目前，依然有很多最佳實踐需要去發掘，而且社區非常活躍。在過去的8-10個月中，我們開發出了新的框架、技術和文檔，使得微前端技術對所有開發人員更加友好。
我並不認爲微前端會是前端開發的銀彈，但是我確實希望它能成爲單頁應用和服務器端渲染架構的一個很好的補充。
在項目中，如果有數十個開發人員在一個大型的業務領域中一同工作的話，我們希望能夠劃分多個子域來降低複雜性，獨立地部署應用的各個組成部分，減少跨團隊創建通信和協調的開銷，那麼微前端就用了用武之地。
有很多組織已經開始接受這項技術，在2020年，我希望能夠看到更多的案例研究，闡述這些公司如何使用該範式的以及他們發現了哪些優點和缺點。
我相信在2020年，微前端會成爲一個被認可的架構並且能夠被前端社區瞭解，我並不期望微前端用到所有的前端項目中，但是確實有很多公司能夠從這種架構範式中收益。
AsyncAPI
AsyncAPI解決了restful API和事件驅動架構（EDA）與事件溯源之間的不一致性。隨着微服務採用的不斷增多，更多的公司實現了EDA，從而出現了關於EDA的改進。但是，這些改進需要將同步的、請求/響應的API轉換成專門爲異步通信構建的API。
Daniel Bryant說到：“在一次與客戶聊天的時候聽說了這件事情，幾乎所有采用了Swagger/OpenAPI的人都在關注像AsyncAPI這樣的技術”。
數據網格
數據網格的概念最初由ThoughtWorks的Zhamak Dehghani在一篇文章中首先引入。這個值得思考的理念認爲通過採用面向領域的數據所有權，可以避免傳統數據倉庫和單體數據湖的缺陷。
Thomas Betts說，“我們過去沒有跟蹤過數據架構，但是我很感興趣的是，爲了增強大數據系統的敏捷性，我們是否會遵循將單體分解爲微服務的趨勢。”
就數據網格的現狀和未來狀態的問題，InfoQ徵詢了Dehghani的想法。
Zhamak Dehghani：連接的去中心化是數字經濟、社會和組織的潛在趨勢。在過去的十多年中，像雲、微服務、API、容器化以及領域驅動設計等技術使運維領域的去中心化成爲可能。但令人遺憾的是，數據領域還被過時的集中式範式主導。數據網格是對分析型數據管理失敗模型的直接回應，目標是讓組織在數據驅動方面實現跨越式發展，與連接去中心化的趨勢保持一致。
在未來的一兩年中，我希望看到數據網格被更廣泛採用，有更多的實現案例研究分享。我預期很多的早期實現將會創建定製的工程工具和技術，我希望這能導致開源工具的蓬勃發展或雲供應商產品的擴展，從而滿足數據網格的技術需求。
在新的一年中，我發現行業中的問題已經從數據網格是什麼變成了如何實現數據網格，當然隨着採用的不斷增加，未來幾年的問題將會變成如何正確地實現數據網格。
鑑於數據網格需要圍繞數據的所有權和治理進行組織上的變更，那些高管強力支持的面向工程的組織可以真正實現這種範式。
策略即代碼
在軟件開發生命週期的管理方面，我們也看到了創新。策略即代碼（Policy as Code）是一個很顯著的趨勢，它有助於爲系統所需的狀態構建結構。它建立在基礎設施即代碼的思想之上，在架構級別能夠帶來類似的好處。Bryant看到KubeCon和雲供應商都在討論策略即代碼的話題。
早期採用者
Serverless
有一個話題總能激發有益的討論，那就是Serverless。InfoQ的編輯們認爲Serverless還沒有跨越鴻溝，而且這個想法也遇到了一些反對的聲音。這與對微服務的反對有關，因爲越來越多的團隊意識到，Serverless和微服務架構並不是所有問題的正確解決方案。
Jan Stenberg觀察到在最近的DDD歐洲會議上討論了Serverless和分佈式系統：
Stenberg：對我來說，很有趣的一點在於Gojko Adzic非常熱情地談到了Serverless，但是他指出，即便是一個非常簡單的“Hello World”應用也是高度分佈式的。這需要非常專業開發人員，這會影響到Serverless的成本效益嗎？
Vladik Khononov推薦閱讀組合/結構化設計，這是Glenford J. Myers在上世紀70年代所寫的，適用於每個對微服務感興趣的人。他說，儘管這本書沒有提到微服務這個術語，但是書中討論的基本設計理念是與微服務相同的。
Stenberg還認爲模塊化單體應該添加到早期採用者中：
Stenberg：請參考Kamil Grzybek、Randy Shoup以及其他人的觀點，另外還有Stefan Tilkov早在2015年就聲稱構建模塊化單體非常困難，如果需要的話，推薦直接採用微服務。
但是，這有點奇怪。構建設計良好的模塊化應用程序怎麼會成爲早期採用者呢？有沒有“新一代”的早期採用者?
Humble：我並不認爲Serverless已經跨越了鴻溝，實際上我聽到了一些反對它的聲音。從大處着眼，我認爲這是對微服務的反對（或者，更精確的說，人們意識到微服務並不是所有問題的答案），我們在QCon倫敦上針對這個話題有個討論。我認爲這還是一種有利的方式。我們應該跟蹤或者討論重回單體的方式嗎？有待進一步探討。
Bryant：我最初確實想知道Serverless是否已經跨越了鴻溝，但是我現在認爲它並沒有。有大量的報告（樣例）指出這個領域有巨大的增長機會，這也讓我認爲它依然處於早期採用者狀態。
Betts：一年前，人們還在談論構建完全Serverless的系統，現在這種炒作已經減弱了。單獨的Serverless特性，如AWS Lambda或Azure Functions，可能已經跨過了鴻溝，但是完全的Serverless架構還沒有，甚至可能永遠不會被大面積採用。
Low-Code和No-Code
Low-code和no-code方案承諾將更多的功能交付給最終用戶，並且不需要開發人員參與。雖然業界資深人士可能會對廠商的背後推動力表示懷疑，但使用這些平臺進行試驗的開發人員已經明顯增多。
Humble：我對low-code平臺持懷疑態度，我認爲和以往我看到的東西一樣，這是廠商的另一波推廣。我希望看到更多的開發人員嘗試low-code平臺，這很大程度上是微軟對其PowerApps、Flow、Power BI和Power Platform產品的新一輪推廣。我還發現谷歌收購AppSheet是一件很有意思的事情。這些平臺正在成爲很大的一項事業，我認爲這是應該關注的一個趨勢。
Betts：（輕量級）工作流和決策自動化平臺應該依然處於早期採用者階段。這與low-code/no-code有很強的相關性，對於概覽圖來說，這可能是更全面的一個術語。這些平臺的目標是非開發者，因此它們屬於購買而不是構建的範疇。它的挑戰在於集成，而不是在某個平臺上構建主要的系統。
Stenberg：Low code讓我想起了年輕的同事，他們在90年代的大學裏只學習第四代編程語言，因爲面向對象已經過時了。
我並不認爲現代工作流引擎（如Zebee）屬於low code，（但是它們可能屬於“工作流和決策自動化平臺”）。它們處理核心業務工作流，我需要知道在這些地方核心業務正在平穩運行，而不用通過監控發現問題。
GraphQL
很明顯，GraphQL已經跨越了鴻溝，但是InfoQ編輯們的問題是它屬於早期大衆還是晚期大衆。雖然GraphQL作爲一項技術可能已經達到了晚期大衆階段，但是我們仍然可以看到在可擴展性和跨系統創建內聚的語言方面，GraphQL的創新依然在影響着架構決策。
Humble：我認爲GraphQL肯定已經跨過了鴻溝。Dylan在最新的Web趨勢報告中將其列到了晚期大衆階段。
Betts：我認爲GraphQL已經跨越了鴻溝。它的採用程度已經使其從單純地實現API層，變成了系統設計的核心。這與TypeScript的採用情況非常類似，大衆已經認識到在整個系統中採用強類型構造的好處。
軟件架構中的道德規範
Bryant提出了一個問題，我們是否應該在這條話題中跟蹤道德準則。“我越來越多地看到在SACON和QCon上關於倫理的演講和話題。”我們最終決定不在生命週期概覽圖中包含道德規範，而將其包含到文化與方法的概覽中。
Humble提到了QCon和InfoQ幾年來一直是如何討論道德規範的：
Humble：我認爲我們傾向於將道德作爲一個文化話題，但這是一件臨時插入的話題。我們絕對應該繼續跟蹤這一話題並就此進行報道。我很自豪我們在QCon倫敦和相關的eMag上涵蓋了這一點，我認爲考慮到軟件在每個人生活中的普及程度，繼續討論它是非常重要的。
Betts將道德視爲架構師作爲技術領導者的一個重要方面：
Betts：雖然我很讚賞人們對道德的關注和討論，但我不確定道德是否應該出現在本概覽圖上。但是，我認爲技術領導者必須考慮道德規範的許多方面，我希望能夠在InfoQ的架構與設計欄目中看到道德規範方面的文章。我始終認爲，在這一領域提供指導的人是真正理解這一領域的實踐者。如果沒有積極主動的領導，設計最終將是被動的，並且會被迫遵守不可避免的政府規定，如GDPR和CCPA。
其他話題
概覽圖的其餘部分基本沒有變化。反應式編程、HTTP/2和gRPC已經跨越了鴻溝，其他項目都沒有變化。這恰好也是架構與設計領域所期望的，因爲與編程語言趨勢相比，好的思想需要時間成長和更長的生命週期。
作爲參考，2019年初的概覽圖如下圖所示。2020年的版本在本文的頂部。
作者簡介：
Thomas Betts 是InfoQ軟件架構和設計的主編，同時是IHS Markit的首席軟件工程師，目前該公司是Informa Tech的一部分。二十多年來，他一直致力於提供令客戶滿意的軟件解決方案。他曾在多個行業工作，包括零售、金融、醫療、國防和旅遊。Thomas與妻子和兒子住在丹佛，他們喜歡徒步旅行，也喜歡探索美麗的科羅拉多州。
Charles Humble於2014年3月開始擔任InfoQ.com的主編，指導我們的內容創作，包括新聞、文章、書籍、視頻演示和訪談。在擔任InfoQ的全職工作之前，Charles負責我們的Java報道，並擔任PRPi諮詢公司的首席技術官，PRPi諮詢公司是一家評估研究公司，於2012年7月被普華永道收購。他全面負責 PRPi公司內部使用的定製軟件的開發。他在企業軟件領域工作了大約20年，曾經擔任開發人員、架構師和開發主管。在業餘時間，他爲倫敦的Twofish創作音樂，首張專輯於2014年2月發行，他希望自己的時間能夠儘可能多地與妻子和孩子在一起度過。
Daniel Bryant是Datawire的產品架構師，並且擔任InfoQ的新聞主管和QCon倫敦的主席。Daniel 目前專注於“DevOps”工具、雲/容器平臺和微服務實現。他還是倫敦Java社區（LJC）的負責人，爲多個開源項目做出貢獻，爲 InfoQ、DZone 和 Voxxed 等知名技術網站撰寫文章，並定期出席QCon、JavaOne和 Devoxx等國際性會議。
Jan Stenberg是居住在瑞典北部的一名IT顧問，工作超過25年，他在.Net/C#和 JVM/Java 方面有着豐富的經驗。他的經驗範圍從大型分佈式和基於服務的系統到基於Web和富客戶端應用程序，甚至包括硬件相關的軟件。
原文鏈接：
Software Architecture and Design InfoQ Trends Report—April 2020