ThoughtWorks在每年都會出品兩期技術雷達，這是一份關於技術趨勢的報告，它比起一些我們能在市面上見到的其他各種技術行情和預測報告，更加具體，更具可操作性，因為它不僅涉及到新技術大趨勢，比如雲平臺和大資料，更有細緻到類庫和工具的推介和評論，從而更容易落地。

不管你是個人開發者，對於新工具和技術有執著的追求，寄希望於從新工具和技術那裡獲取改進每日工作的靈感，或者你是技術領導者需要針對自己的系統做技術選型，以及對未來技術趨勢的把握，技術雷達都會是一份很好的參考。

在本次分享中，ThoughtWorks中國區CTO、也是技術雷達建立者之一的徐昊將與大家分享最新期（第十九期）技術雷達的主題趨勢與解讀技術雷達的正確姿勢。

ThoughtWorks 每年都會出品兩期技術雷達，這是一份關於技術趨勢的報告。對於不同層級和水平的技術從業者，可以從不同角度和分類進行解讀，因此如何解讀技術雷達就是變成一件很有意思的事情。不管你是個人開發者，對於新工具和技術有執著的追求，寄希望於從新工具和技術那裡獲取改進每日工作的靈感；或者你是技術領導者需要針對自己的系統做技術選型，以及把握未來技術趨勢，技術雷達都會是一份很好的參考。

在技術雷達的四個象限（技術、工具、平臺、語言 & 框架）中，佈滿了大量由 ThoughtWorks 技術專家們發現的、可以極大改善開發效率和品質的條目。它們大多數會分佈在每個象限的試驗和評估區域。這些條目具備創新和極客精神，可以很大程度上改善個人開發者的開發興趣，保持對於新技術和技能的敏感度。

本文簡單介紹了最新一期（Vol.19）技術雷達的四大主題趨勢和部分 blip（技術點），在後續的直播中，筆者也會結合本期雷達聊一聊技術領域的最新趨勢，以及 ThoughtWorks 在這方面的實踐與教訓。

粘性十足的雲平臺

雲提供商知道他們正在嚴峻的市場中進行競爭。為了獲勝，他們需要吸引使用者註冊並長期留住他們。因此，為了保持競爭力，他們在新增產品特性上你爭我搶，使得彼此不相上下。這一點可以從本期雷達試驗環中以下雲提供商的排名看出： 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 出品。該平臺仍在開發中，有些功能尚需完善，也缺少一些特性（比如與私有容器註冊服務協同工作）。但是目前的特性集 (包括從 Web 門戶使用 SSH 訪問一個裝置上的容器) 表明了它的未來充滿希望。

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 能支援不同大小的資料集。大多數時候我們使用 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，令人驚喜的是，我們可以測試驅動配置，注入和修復故障，驗證系統恢復後的狀態。

以上是從最新期技術雷達中隨機摘取的幾個 blip，這裡有完整版《Technology Radar 技術雷達》，可以提前一探。剩下的內容我們直播再聊～

相關連結：

• 官網下載

本文首發於GitChat，未經授權不得轉載，轉載需與GitChat聯絡。

閱讀全文: http://gitbook.cn/gitchat/activity/5bebe483e6576d097bf9184c

一場場看太麻煩？成為 GitChat 會員，暢享 1000+ 場 Chat ！點選檢視