作者 | ThoughtWorks

編輯 | 小智

ThoughtWorks 每年都會出品兩期技術雷達，這是一份關于技術趨勢的報告，由 ThoughtWorks 技術戰略委員會（TAB）經由多番正式討論給出，它以獨特的雷達形式對各類最新技術的成熟度進行評估并給出建議，為從程序員到 CTO 的利益相關者提供參考。

本期主題

粘性十足的云平臺?

云提供商知道他們正在嚴峻的市場中進行競爭。為了獲勝，他們需要吸引用戶注冊并長期留住他們。因此，為了保持競爭力，他們在新增產品特性上你爭我搶，使得彼此不相上下。這一點可以從本期雷達試驗環中以下云提供商的排名看出： AWS、 Google Cloud Platform 和 Azure 。然而，一旦用戶注冊，這些云提供商就傾向于與用戶建立盡可能高的粘性，以阻止他們使用其他提供商的服務。這通常表現為其云服務會與其服務和工具套件緊密集成。用戶只有繼續使用其云服務，才能獲得更好的開發者體驗。

通常在用戶決定是否將其部分或全部工作負載移動到另一朵云上，或發現云服務的使用和賬單多到失控時，就能明顯感覺到這種粘性。我們鼓勵客戶使用 架構適應度函數度量成本 的技術來監控運維成本，并將其作為衡量云供應商粘性的指標。或者使用 Kubernetes 和容器，并通過運用基礎設施即代碼來提升工作負載的可移植性，降低切換到另一個云提供商的成本。在本期雷達中，我們還會介紹兩個新的云基礎設施自動化工具：Terragrunt 和 Pulumi。雖然我們支持通過粘性的高低來評估云提供商的新產品，但提醒你不要落入只使用通用云服務功能的陷阱。根據我們的經驗，創建和維護與云無關的抽象層的開銷，會超出退出某個特定云提供商的花費。

?

揮之不去的企業級應用反模式

無論技術如何快速變化，一些企業仍然想方設法地重新實現過去的反模式。雷達中的許多暫緩條目都在揭穿一些“新瓶裝舊酒”的老把戲。比如：用 Kafka 重新創建 ESB 的反模式、分層式微服務架構、Data-hungry packages、過度龐大的 API 網關、Low-code 平臺和一些其他有害的舊實踐。一如既往的根本問題，是如何在隔離和耦合之間取得平衡：我們隔離組件，使其在技術角度便于管理。但是我們也需要協調組件，使其有助于解決業務問題。這就產生了某種形式的耦合。因此，上述舊模式就不斷重新冒出來。新的架構和工具為解決這些問題提供了適當的方法，但這需要刻意去理解如何正確地使用它們，而不僅僅是使用嶄新的技術去重新實現舊模式。

?

持之以恒的工程實踐

隨著技術創新步伐加快，新技術的發展呈現出一種從爆發到沉淀不斷循環的模式。每當能夠顛覆我們對軟件開發固有認知的新技術出現時，都會引起業界的爭相追捧，容器化、響應式前端和機器學習都是很好的例子。這時技術處在爆發階段。然而，只有在明確如何與長期以來的工程實踐（持續交付、測試、協作等）相結合之后，新技術才能真正的發揮功效，并進入沉淀階段，為下一次爆發性擴張打下堅實的基礎。在沉淀階段，我們嘗試在新技術的背景下應用實踐，比如進行全面的自動化測試以及創建腳本代替重復操作，通常也會創造出新的開發工具。雖然表面看來技術創新是行業發展的唯一驅動力，但事實上，創新與持之以恒的工程實踐相結合才是我們不斷進步的基礎。

?

速度 = 距離 / 時間

通常，我們會選取本期雷達中部分共性條目的精彩集錦展現在雷達主題中，但本主題涉及自技術雷達誕生以來出現過的所有條目。我們發現（并通過一些調研證明）雷達條目停留在雷達上的時間正在縮減。當我們在 10 年前啟動技術雷達時，如果某個條目在雷達上的位置不再移動，它依然會保留兩期（大約一年）時間，之后才會自動移出雷達。然而正如標題中的公式所說，速度 = 距離 / 時間：軟件開發生態系統中的變化一直在持續加速。在時間保持不變（依然是每年發布兩次）的前提下，雷達中技術創新所跨越的距離明顯地增大了。這為精明的讀者提供了顯著的證據：技術變革的步伐正在不斷加快。我們不僅看到雷達中的各個象限在加速變化，也看到了客戶對新興的及多樣化的技術選擇所表現出的興趣。因此我們將改變傳統的默認模式：雷達不再默認保留其上的條目，它們是否出現在雷達上完全取決于它們當前的價值。我們在深思熟慮后做出了這項改變，并認為只有這樣才能更好地跟上技術生態系統中前所未有的狂熱變化節奏。

?

象限亮點搶先看

Event Storming（事件風暴）?

快速市場響應能力是組織進行微服務轉型的主要驅動之一。然而只有沿長期業務領域邊界對服務（及其支持團隊）進行清晰劃分時，這種期望才可能實現。否則，現實需求只有在跨組織和跨服務的通力合作才下能完成，這自然會在規劃產品路線圖時產生沖突。良好的領域模型設計是解決此問題的方案，事件風暴（EVENT STORMING）也迅速成為我們最喜愛的方法之一，它使我們能夠迅速識別問題領域中的關鍵概念，并用最好的方式與各方利益相關人制定解決方案。

?

Microservice Envy

微服務已成為現代云計算系統中的領先的架構模式，但我們依舊認為團隊在使用該架構時應謹慎。 MICROSERVICE ENVY 特指那些盲目追趕微服務潮流的現象，很多團隊在實踐微服務時并沒有簡化其系統架構，大多數的實踐方案只是將一些簡單的服務聚合在一起而已。目前，Kubernetes 等平臺簡化了復雜的微服務系統的部署問題，其他服務提供商們也正在推進他們的微服務治理方案，這些強大的工具都可能裹挾團隊走上微服務之路。 但請千萬謹記，微服務是通過開發復雜度來換取運維復雜度，并需要自動化測試、持續交付和 DevOps 文化提供堅實的支撐。

?

Observability as Code（可觀測性即代碼）

可觀測性是運轉分布式系統與微服務架構必不可少的一部分。我們依賴不同的系統輸出來推斷分布式組件的內部狀態，比如分布式追蹤、日志聚合、系統指標等，進而診斷問題所在，并找到根本原因。可觀測性生態系統的一個重要方面就是監控——可視化以及分析系統的輸出——并且在檢測到異常時報警。傳統的監控報警配置，都是通過圖形界面的操作完成。這種方法導致控制面板頁的配置不可重復，從而無法持續測試和調整報警，來避免報警疲勞或錯過重要的報警，進而偏離組織的最佳實踐。我們強烈建議使用代碼來配置可觀測性生態系統，稱為可觀測性即代碼（OBSERVABILITY AS CODE），并且采取基礎設施即代碼的方式搭建其基礎設施。因此，在選擇提供可觀測性的工具時，要選擇支持通過代碼版本控制進行配置，并能通過基礎設施持續交付流水線執行 API 或命令行的產品。可觀測性即代碼，是基礎設施即代碼中經常被遺漏的一部分，我們認為這一點非常重要，需要明確指出。

?

Four key metrics（四個關鍵指標）

2014 年首次發布的 DevOps 狀態報告指出，高效團隊創造了高效的組織。最近，該報告背后的團隊編寫了 Accelerate 一書，描述了他們在報告中使用的科學方法。兩份材料的核心點都支持了軟件交付性能的四個關鍵指標（FOUR KEY METRICS）：前置時間，部署頻率，平均恢復時間（MTTR）和變更失敗百分比。作為幫助許多組織轉型的咨詢公司，反復使用這些指標測量，可以幫助組織確定他們是否在提高整體效能。每個指標都創造了一個良性循環，并使團隊專注于持續改進：縮短交付周期，減少浪費的活動，從而使你可以更頻繁地部署；部署頻率迫使你的團隊改進他們的實踐和自動化流程；通過更好的實踐，自動化和監控可以提高你從故障中恢復的速度，從而降低故障頻率。

?

Run cost as architecture fitness function（架構適應度函數）

隨著軟件架構及其業務的演進，我們理應密切關注應用的運行成本，但發現并非所有的組織都如此。尤其是在使用無服務器架構時，開發者們認為無服務器架構會更便宜，因為他們只需按消耗的計算時間付費。然而幾家主要的云服務提供商在熱門的無服務器函數上定價十分精明，雖然無服務器在快速迭代上很有優勢，但與專屬云（或內部私有云）相比，它的開銷可能隨著使用量迅速增長。我們建議團隊將應用的運行成本納入架構適應度函數（RUN COST AS ARCHITECTURE FITNESS FUNCTION）來考量，這意味著：追蹤并權衡應用的運行成本與交付價值；當它們之間產生較大出入時，就需要考慮改進軟件架構了。

?

Debezium?

DEBEZIUM 是一個 change data capture (CDC) 平臺，可以將數據庫的變更以流的形式傳入 Kafka 主題中。CDC 是一種流行的技術，具有多個使用場景，包括將數據復制到其他數據庫中，為分析系統提供數據，從單塊系統中提取微服務，以及令緩存數據無效等。我們一直在尋找這個領域的工具或平臺（包括在之前的技術雷達中討論過的 Bottled Water），而 Debezium 是一個極佳的選擇。它使用了基于日志的 CDC 方法，意味著能以對數據庫日志文件的變更進行響應的方式進行工作。Debezium 使用了 Kafka 連接，這使得它具有高度的容量伸縮性，以及對故障的系統韌性。它擁有包括 Postgres、Mysql 和 MongoDB 在內的多個數據庫的 CDC 連接器。目前，我們正在一些項目上使用該平臺，并取得了很好的效果。

?

Quorum

在區塊鏈技術領域，Ethereum(以太坊) 是一個領先的開發者生態系統。我們看到了一些新興的解決方案，它們旨在將 Ethereum 這項技術傳播到一些企業環境中。這些企業通常需要網絡權限和交易隱私管理，另外還需要更高的吞吐量和更低的延遲。

QUORUM 就是其中的一個解決方案。Quorum 最初由 J.P. Morgan 開發，其定位是“企業版的 Ethereum”。與創建了新的以太坊虛擬機（EVM）的 Hyperledger Burrow 節點不同，Quorum 的代碼源自以太坊官方客戶端的一個分支，所以能與以太坊一起進化。在保留了以太坊賬本的大多數功能的前提下，Quorum 將共識協議從工作量證明機制更改為更高效的協議，并增加了私有交易支持。使用 Quorum，開發人員可以使用他們的以太坊知識來構建企業級的區塊鏈應用，這些知識包括 Solidity 語言和 Truffle 合約。

然而根據我們的經驗，Quorum 還沒有為應用于企業做好充足的準備；比如：它缺乏針對私有合約的訪問控制機制，無法用于負載均衡，并且只支持部分數據庫。所有的這些限制都為用戶的部署與設計帶來顯著的負擔。我們建議在使用 Quorum 的時候保持警惕，同時密切關注它的后續發展。

?

IPFS

在多數情況下，區塊鏈不適合存儲 blob 文件 (例如：圖像，音頻)，當人們開發 DApp 時，一種選擇是將 blob 文件存放在一些鏈下的集中式數據存儲中，這種做法通常會導致信任缺失，另一種選擇是將它們存儲在星際文件系統 IPFS 上，這是一種內容可尋址、版本化、點對點的文件系統。它旨在高效地分發大規模數據，并能阻止任何中心化機構刪除數據，文件存儲在不需要相互信任的對等節點上。IPFS 保存文件的每一個版本，這樣你將永遠不會丟失重要文件，我們將 IPFS 視為區塊鏈技術的好的補充。除了區塊鏈應用程序外，IPFS 還有一個愿景是對現有的網絡基礎設施進行去中心化重塑。

?

Resin.io

RESIN.IO 是一個物聯網（IoT）平臺。雖然只做把容器部署到設備中這一件事，但它做得很好。開發人員使用一個軟件即服務（ SaaS）的門戶來管理設備，并為這些設備分發由 Dockerfile 定義的應用。該平臺可以為多種硬件類型構建容器，并通過無線的方式部署容器鏡像。Resin.io 使用 balena 來管理容器。而 balena 是一個基于 Mobby 框架的容器引擎，由 Docker 出品。該平臺仍在開發中，有些功能尚需完善，也缺少一些特性（比如與私有容器注冊服務協同工作）。

?

Knative

作為應用開發者，我們喜歡專心解決核心業務問題，而讓底層平臺來處理那些枯燥且困難的任務（如部署、容量伸縮及應用程序管理）。雖然無服務器架構往這個方向邁出了一步，然而大多數流行的產品都會與某個專有實現綁在一起。而這意味著供應商綁定。KNATIVE 試圖以開源無服務器平臺的方式來解決此問題。它良好地集成了流行的 Kubernetes 生態系統。利用 Knative ，可以對隨時請求的計算進行建模（其間可以從一些框架中進行選擇，如 Ruby on Rails、Django 和 Spring 等），可以訂閱、交付和管理事件，可以集成用戶所熟悉的 CI 和 CD 工具，可以從源代碼構建出容器。該平臺提供一組中間件組件，來構建以源代碼為中心且基于容器（能夠實現資源伸縮性）的應用。這使得它成為一個頗有吸引力的平臺，當有無服務器需求時，值得對其進行評估。

?

Apache Atlas

隨著企業數據需求的不斷增長和多樣化，對元數據管理的需求也在不斷地增長。APACHE ATLAS 是一款用于滿足企業數據治理需求的元數據管理框架。Atlas 支持元數據類型建模、數據資產分類、數據來源追蹤和數據發現。但是，在搭建元數據管理平臺的時候，我們也必須小心避免重蹈主數據管理的覆轍。

?

Cypress?

運行端到端測試時經常會遇到一些棘手的問題，比如運行時間過長，測試過于零碎，還需要修復無頭模式下運行的測試所導致的 CI 失敗。我們的團隊借助 CYPRESS 很好地解決了性能差、響應時間長、資源加載慢等常見問題。Cypress 是一款很有用的工具，可以幫助開發者構建端到端測試，還可以將所有測試步驟保存為 MP4 視頻，便于檢查錯誤。

?

VS Live Share

VISUAL STUDIO CODE 是微軟推出的免費 IDE 編輯器，可以跨平臺使用。我們曾用它同時進行前端 React、TypeScript 和后端 GoLang 的開發，而無需在不同的編輯器之間切換，體驗很好。 Visual Studio Code 中的工具、語言支持和擴展插件數量都在迅猛增長，也越來越好用。我們要特別推薦在實時協作及遠程結對編程時使用 VS Live Share 。固然微軟或 Jetbrains 成熟的 IDE 對使用靜態類型語言（如 Java 、 .NET 或 C++ ）的復雜項目支持得更好，但我們也發現 Visual Studio Code 正逐漸成為基礎設施開發組和前端開發組的首選工具。

?

Stanford CoreNLP

越來越多的項目需要處理非結構化的數據，而從文本中提取出有意義的業務信息是一項關鍵技術。 STANFORD CORENLP 是一組基于 Java 的自然語言處理（NLP）工具集，支持英語、漢語和阿拉伯語等多種語言的命名實體識別、關系抽取、情感分析與文本分類，也提供了用于標記語料庫和訓練模型的工具。 Stanford CoreNLP 協助我們使用 NLP 領域的最新研究成果來解決各種業務問題。

?

LocalStack

使用云服務時面對的一個挑戰是如何在本地進行開發和測試。 LOCALSTACK 為 AWS 解決了這個問題。它提供了各種 AWS 服務的本地 測試替身 實現，包括 S3 、 Kinesis 、Dynamodb 和 Lambda 等。它基于現有的最佳工具如 Kinesalite 、 Dynalite 、 Moto 等構建，并增加了進程隔離與錯誤注入的功能。 LocalStack 的使用很簡單，并附帶了一個簡單的 JUnit 運行器以及 JUnit 5 擴展。我們在一些項目中使用過 LocalStack ，并對它印象深刻。

?

Bitrise

構建、測試和部署移動應用，尤其是由一條流水線從代碼倉庫打通到應用商店的時候，會涉及許多復雜的步驟。雖然這些步驟可以由腳本或普通 CI/CD 工具提供的流水線自動完成，但對于專注移動應用開發，而不需要與后端的構建流水線做集成的小組來說，使用專用工具可以降低復雜度和維護開銷。 BITRISE 配置簡單，并預置了一組完整的步驟，可以滿足絕大多數移動應用開發所需。

?

PredictionIO

PREDICTIONIO 是開源的機器學習服務框架。無論是普通開發者還是數據科學家，都可以利用它創建用于預測的智能應用。和所有其他智能應用類似，PredictionIO 由三個部分組成：數據收集和存儲、模型訓練以及模型部署和服務暴露。開發者只需要基于它提供的相應接口實現數據處理邏輯、模型算法和預測邏輯，無需在諸如存儲數據以及訓練模型之類的事情上投入額外精力。從我們的經驗來看，在不要求高并發處理的情況下，PredictionIO 能支持不同大小的數據集。

?

Q#

量子計算目前已經可供測試，但何時真正到來尚未明確。在硬件到位之前，我們已經可以通過語言和模擬器來實驗和學習它。盡管 IBM 等公司已經取得了不錯的進展，我們對微軟在 Q＃ 語言及其模擬器（本地 32 量子比特，Azure 云上 40 量子比特）方面的工作更加關注。如果你想開始了解這項編程的前景，請查看他們在 GitHub 上的范例。

?

MockK

MockK 是用 Kotlin 編寫的模擬庫。它的核心理念是像 Coroutines 和 Lambda 表達式一樣，為 Kotlin 提供一等公民級別的語言特性支持。不同于 Mockito 或 PowerMock 的蹩腳封裝，作為原生的開發庫，它能幫助開發團隊在測試 Kotlin 應用時編寫干凈、簡潔的代碼。

?

WebFlux

Spring Framework 5 已發布一年有余，它采用了響應式流 —— 一套非阻塞背壓（backpressure）式異步流式處理標準。在傳統的 Spring MVC 模塊之外，WEBFLUX 為在 Spring 生態下編寫 Web 應用提供了一個響應式替代品。經過一系列應用的試用，WebFlux 給我們的團隊留下了深刻的印象，并匯報說這種響應式（函數式）實現增強了代碼的可讀性和系統的吞吐量。但他們也確實注意到，采用 WebFlux 需要在思維方式上做出一些重大轉變，建議在 WebFlux vs. Spring MVC 的技術選型中考慮這一點。

?

Jepsen

隨著 微服務 架構越來越多地被采用，相比以前，我們構建了更多的分布式應用程序。盡管解耦架構帶來了許多好處，但證明整個系統正確性所需的工作量和復雜程度正急劇增加。 JEPSEN 提供了許多我們所需要的工具，來幫助我們驗證協調任務調度程序的正確性，測試分布式數據庫的最終一致性、 線性一致性 （ Linearizability）和 可串行性（Serializability）。我們在一些項目中使用了 Jepsen，令人驚喜的是，我們可以測試驅動配置，注入和修復故障，驗證系統恢復后的狀態。

總結

以上是生活随笔為你收集整理的从程序员到CTO都应该了解的一些技术趋势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。