技術雷達是 ThoughtWorks 每半年釋出一次 的 技術趨勢報告，它持續追蹤有趣的技術是如何發展的。經過半年的追蹤與沉澱，ThoughtWorks TAB（ThoughtWorks 技術諮詢委員會）根據在多個行業中的實踐案例，為技術者產出了第 23 期技術雷達。對百餘個技術條目進行分析，闡述它們目前的成熟度，並提供了相應的技術選型建議。
技術雷達是 ThoughtWorks 每半年釋出一次的技術趨勢報告，它持續追蹤有趣的技術是如何發展的，我們將其稱之為條目。技術雷達使用象限和環對其進行分類，不同象限代表不同種類的技術，而環則代表我們對其作出的成熟度評估。
經過半年的追蹤與沉澱，ThoughtWorks TAB（ThoughtWorks 技術諮詢委員會）根據我們在多個行業中的實踐案例，為技術者產出了第 23 期技術雷達。對百餘個技術條目進行分析，闡述它們目前的成熟度，並提供了相應的技術選型建議。
本期五大主題
1、GraphQL 浮誇風
我們看到 GraphQL 在很多團隊中的採納率激增，同時其支撐生態也在蓬勃發展。它解決了現代分散式架構 (如微服務) 中的一些共性問題：當開發人員把系統分解成很多小塊時，他們通常還要把資訊重新聚合起來才能解決業務需求。GraphQL 提供了一些功能，可以方便地解決這類日漸普遍化的問題。就像所有強大的抽象一樣，它提供的是一種折衷方案，團隊要認真考慮，以避免長線上的負面影響。比如，我們已經看到有團隊透過聚合工具暴露了過多的底層實現細節，導致架構出現了不必要的脆弱性。當團隊試圖藉助聚合工具來建立規範化的、通用的、中心化的資料模型時，就會把短線上的便利變成長線上的麻煩。我們鼓勵團隊使用 GraphQL 及其迅速成長的周邊工具，但是，要小心別過度追求技術通用性，不要試圖用一項技術解決很多問題。
2、與瀏覽器的鬥爭仍在繼續
網頁瀏覽器原本是被設計用來瀏覽文件的，但現在主要用來承載應用程式，這種抽象的不匹配一直困擾著開發人員。為了克服這種不匹配所帶來的諸多問題，開發人員一直在重新審視和挑戰那些公認的用於瀏覽器測試、狀態管理和構建快速且豐富的瀏覽器應用程式的方法。我們在技術雷達上可以看到這一類的趨勢。第一，自從 2017 年 Redux 作為管理 React 應用狀態的預設方法被移到“採納”環以來，我們看到開發人員要麼仍在嘗試其他的方法 (Recoil)， 要麼推遲對狀態管理庫的選型決策。第二，人們對 Svelte 越來越感興趣，而它正在挑戰虛擬 DOM 的概念， 後者則正是 React 和 Vue.js 等流行的程式開發框架所遵循的概念。第三，用於處理瀏覽器端測試的新工具不斷湧現：Playwright 是改進 UI 測試的又一個新嘗試，而 Mock Service Worker 則是一種將測試與後端互動分離的新方法。第四，平衡開發人員的開發效率與應用效能一直都是我們需要面對的一個挑戰，瀏覽器定製的膩子指令碼的目的就是改變這個權衡的範圍。
3、視覺化一切
這一期技術雷達中，有幾個條目來自不同技術領域但卻擁有一個共性，即視覺化。你會發現很多關於基礎設施、資料科學、雲資源，以及很多其他極富創新性的視覺化工具，其中不乏一些可以有效視覺化複雜抽象的方法。也有一些互動式的資料視覺化工具和控制皮膚工具，如 Dash, Bokeh 和 Streamlit，還有一些基礎設施的視覺化工具，例如微服務架構中的服務網格視覺化工具 Kiali。隨著開發人員的生態環境變得越來越複雜，一幅能清晰地解釋問題的影像對減輕大家的心智負擔無疑是大有裨益。
4、基礎設施即程式碼的青春期
隨著組織看到自動化基礎設施所帶來的好處，管理基礎設施即程式碼變得越來越普遍。這為創新型的工具和框架的建立者們提供了反饋。諸如 CDK 和 Pulumi 之類的工具，提供了遠遠超過第一代工具的功能。其改進如此之大，以至於我們相信基礎設施即程式碼已經進入了積極與消極因素共存的“青春期”。我們驚喜地看到在所有象限中，都有相關雷達條目，從積極的方面反映了相關生態系統日益成熟。但是，我們還討論了該領域因為缺乏成熟模式而面臨的挑戰，以及許多公司在嘗試用最佳方式利用此功能時所面臨的挑戰。所有這些都表明，該領域在持續增長，但尚未成熟。我們希望基礎設施社群，繼續從軟體設計中汲取教訓，尤其要關注建立鬆散耦合的可部署基礎設施
5、程式設計大眾化
讓非程式設計師能夠執行以往只有程式設計師才能做到的任務，我們圍繞這個促進程式設計大眾化的工具和技術進行了一些討論。而諸如 IFTTT 和 Zapier 之類的解決方案在該領域已長期流行。我們發現，人們開始越來越多地使用諸如 Amazon Honeycode 這樣的低程式碼環境，以建立簡單的業務應用程式。儘管此類工具提供了適合其目的的程式設計環境，但將其產出移至規模化的生產環境時仍會遇到挑戰。開發人員長期以來一直設法利用電子表格嚮導工具，在特定領域和傳統編碼環境之間找到折衷方案。越來越多的現代工具的問世，在更廣泛的領域重新激起了大家的討論。但取捨的原則，依舊未變。
部分象限亮點搶先看
1、定製化服務模板
採納
自從定製化服務模板在雷達中出現以來，這個模式已經被廣泛採用以幫助組織向微服務過渡。伴隨著可觀察性工具、容器編排和服務網格邊車的不斷進步，服務模板可以透過精心挑選的預設值，減少服務與基礎設施配合所需的大量設定，從而幫助快速建立新服務。對定製化服務模板應用產品管理原則也取得了成功。以內部開發者作為客戶，定製化服務模板可以幫助開發者將程式碼釋出到生產環境，並提供合適的可觀察性以進行操作。定製化服務模板帶來的另一個好處，是可以作為輕量級的治理機制，對技術選型的預設項進行集中管理。
2、限界低程式碼平臺
評估
現在很多公司正在面臨的一個最微妙的決定便是是否要採納低程式碼平臺或無程式碼平臺，這些平臺可以被用來在非常特定的領域裡解決一些特定的問題。限界低程式碼平臺這一領域的供應商也有如過江之鯽。現在看來，這類平臺的一個突出的問題，便是很難應用一些諸如版本控制之類的優秀的工程實踐。而且這類平臺上的測試也非常的困難。然而我們還是注意到了這個市場裡的一些有趣的新兵，例如 Amazon Honeycode 可以被用來建立一些簡單的任務和事件管理應用，還有 IFTTT（類似於雲工作流）領域的 Parabola，這也是為何我們會將 限界低程式碼平臺 納入這個部分的原因。但是我們仍然對它們更廣泛的適用性深表懷疑，因為這些工具，如日本 Knotweed，非常容易超出它們原本的限界而被泛化用於其他場景，這也是為什麼我們對採納這種技術持強烈的謹慎態度。
3、去中心化身份
評估
SSL/TLS 的核心貢獻者 Christopher Allen 在 2016 年給我們介紹了一種用於支撐新型數字化身份的 10 個原則，以及實現這一目標的途徑：通往自主身份之路。自主身份也被稱為 去中心化身份 ，按照基於 IP 協議棧的信任標準，是一種“不依賴任何中心化權威並且永遠不能被剝奪的任何人、組織或事物的終身可轉移身份”。採納和實現去中心化身份正在逐漸升溫並變得可能。我們看到了它在隱私方面的應用：客戶健康應用、 政府醫療基礎設施 和 公司法律身份。如果想快速地應用去中心化身份，你可以評估 Sovrin Network，Hyperledger Aries 和 Indy 等開源軟體，以及去中心化身份 和 可驗證憑證 標準。我們正在密切關注這個領域，並幫助我們的客戶在數字信任的新時代進行戰略定位。
4、Apollo Federation
暫緩
我們首次在技術雷達中介紹 GraphQL 時，曾提醒誤用它會導致反模式，從長遠來看弊大於利。儘管如此，我們發現團隊對 GraphQL 越來越感興趣，因為它能夠 聚合來自不同資源的資訊。這次我們想提醒你謹慎使用 Apollo Federation 和它對公司統一資料圖的強大支援。即便乍看之下，有跨組織的普適概念這種想法是具有吸引力的，但是我們必須考慮之前業界做過的類似嘗試——如 MDM 和規範資料模型等，這些嘗試暴露了這種方法的缺陷。挑戰會是巨大的，特別是當我們發現所在的領域要建立一個獨特統一的模型非常複雜的時候。
1、Debezium
試驗
Debezium 是一個變更資料捕獲（Change Data Capture, CDC） 平臺，可以將資料庫變更流式傳輸到 Kafka 的 topics。CDC 是一種流行的技術，具有多種應用場景，例如：將資料複製到其他資料庫、輸送資料給分析系統、從單體中提取資料至微服務以及廢除快取。Debezium 對資料庫日誌檔案中的變更做出反應，並具有多個 CDC 聯結器，適用於多種資料庫，其中包括 Postgres、MySQL、Oracle 和 MongoDB。我們在許多專案中都使用了 Debezium，它對我們來說非常有效。
2、JupyterLab
試驗
在上一期雷達中，JupyterLab 還處於評估象限，作為專案 Jupyter 基於 web 的使用者介面，現在它已經成為許多資料從業者的首選。JupyterLab 的使用正在迅速超越 Jupyter Notebooks，且終將取而代之。如果你仍在使用 Jupyter Notebooks，去嘗試一下 JupyterLab 吧。JupyterLab 的互動環境是對 Jupyter Notebook 的改進：透過單元格拖拽、tab 自動補全等新特性對原有的功能進行了擴充套件。
3、K3s
評估
K3s 是一個輕量級的用於物聯網和邊緣計算的 Kubernetes 發行版。K3s 被打包成一個單獨的二進位制檔案，對於作業系統的依賴性微乎其微，這使得它非常易於運維和使用。K3s 使用 sqlite3 而非 etcd 作為預設的儲存後端。由於所有相關的元件都執行在同一個程式裡，這使得 K3s 的記憶體佔用非常低。透過剝離不相關的第三方儲存驅動和雲提供商，K3s 的二進位制檔案得以控制得非常小。在資源受限的環境中，K3s 是一個值得考慮的非常不錯的選擇。
4、Pulumi
評估
我們已經看到人們對 Pulumi 的興趣正在緩慢且穩步地上升。雖然 Terraform 在基礎設施程式設計世界中地位穩固，但 Pulumi 卻填補了其中的一個空白。儘管 Terraform 是一個久經考驗的常備選項，但其宣告式程式設計特質，深受抽象機制不足和可測試性有限的困擾。如果基礎設施完全是靜態的，那麼 Terraform 就夠用了。但是動態基礎設施但定義，要求使用真正的程式語言。Pulumi 允許以 TypeScript/ JavaScript、Python 和 Go 語言（無需標記語言或模板）編寫配置資訊，這使其脫穎而出。Pulumi 專注於原生雲架構，包括容器、無伺服器函式和資料服務，併為 Kubernetes 提供了良好的支援。最近，AWS CDK 的推出對其形成了挑戰，但 Pulumi 仍然是該領域唯一的能獨立於任何雲平臺廠商的工具。我們期望將來人們能更廣泛地採用 Pulumi，並期待出現能對其提供支援的可行的工具和知識生態系統。
1、Trivy
採納
用來建立和部署容器的流水線，應該包含容器安全掃描這個步驟。我們的團隊尤其喜歡 Trivy ——一個針對容器的漏洞掃描器。在這個領域的工具中，我們嘗試過 Clair 和 Anchore Engine。跟 Clair 不一樣，Trivy 不止會檢查容器，而且會檢查程式碼庫中的依賴。同時，由於它是一個獨立的二進位制包，所以更容易在本地設定和執行。Trivy 的其他好處還有，它是開源軟體，並支援 distroless containers 容器。
2、MLflow
試驗
MLflow 是一款用於機器學習實驗跟蹤和生命週期管理的開源工具。開發和持續進化一個機器學習模型的工作流包括，一系列實驗（一些執行的集合），跟蹤這些實驗的效果（一些指標的集合），以及跟蹤和調整模型（專案）。MLflow 可以透過支援已有的開源標準，以及與這個生態中許多其他工具的良好整合，來友好地輔助這個工作流。在 AWS 和 Azure 中，MLflow 作為雲上 Databricks 的受管服務，正在加速成熟，我們已經在我們的專案中成功使用過它。我們還發現 MLflow 是一個模型管理，以及跟蹤和支援基於 UI 和 API 互動模型的很棒的工具。唯一的擔憂在於，MLflow 作為單一平臺，一直在嘗試交付太多的混淆關注點，比如模型服務和打分。
3、jscodeshift
試驗
維護大規模的 JavaScript 程式碼庫從來不是一件容易的事情，而遷移重大的變更更是極具挑戰。在簡單的場景中，帶有重構能力的 IDE 也許能幫得上忙。但是，如果程式碼庫依賴廣泛，每次想要做出重大的變更時，你都不得不遍歷客戶端程式碼庫，才能做出合適的更新。這需要人工的監管並手工完成。jscodeshift，一個可以重構 JavaScript 和 TypeScript 的工具，能幫助減輕這種痛苦。它能把你的程式碼分析成抽象語法樹（AST），並提供 API 透過不同的變換（也就是在既有的元件上新增、重新命名以及刪除屬性）操作這棵樹，然後把這棵樹匯出成最終原始碼。jscodeshift 還附帶一個簡單的單元測試程式，它能用測試驅動開發的方法編寫遷移 codemods。我們還發現 jscodeshift 對於維護設計系統尤其有效。
4、Katran
評估
Katran 是一款高效能的 layer 4 負載均衡器。它並不適合所有人，但如果你需要 layer 7 負載均衡器（比如 HAProxy 或者 NGINX）的替代品，或者你想要伸縮負載均衡器到兩臺及更多的伺服器上，那我們推薦你評估一下 Katran。相對於 L7 負載均衡器上的迴圈 DNS 技術，或者網路工程師通常用於解決類似挑戰的 IPVS 核心模型，我們把 Katran 看作一個更靈活和有效的選擇。
1、Redux
試驗
Redux 已被移回試驗環，因為我們不再將其視為 React 應用程式預設的狀態管理方式。經驗表明，在許多情況下 Redux 框架仍然具有一定的價值。但是與其他方法相比，Redux 會導致程式碼冗長難讀。而引入 Redux Sagas 通常更會加劇這個問題。相對的，React 最新版本中的功能已經可以有效地管理狀態，而無需引入其他框架。但需要著重強調的是，當簡單的狀態管理解決方案開始變得複雜時，仍然可以考慮使用 Redux，或者是 Facebook 最近釋出的 Recoil。
2、Babylon.js
評估
在幾年前我們寫到超越遊戲的 VR 時，我們沒有預見到 VR 解決方案會以多快以及多深的程度進入到除了影片遊戲之外的領域。事後看來，我們當然看到了一些興趣和採納的增長，但人們對它的理解卻比我們預期的要慢得多。原因之一可能是工具。Unity 和 Unreal 是兩個用於開發 VR 應用的成熟又強大的引擎。我們還特別提到 Godot。然而，這些引擎跟大多數 web 和企業團隊熟悉的那些工具很不同。隨著我們繼續探索，我們意識到基於 web 的 VR 方案已經取得巨大進展，其中對 Babylon.js 我們有相當積極的經驗。Babylon.js 是用 TypeScript 編寫並在瀏覽器中渲染出它的應用，這為許多開發團隊提供了熟悉的開發體驗。此外，Babylon.js 也是開源軟體，成熟而且資金充足，這讓它足具吸引力。
3、XState
試驗
在之前的雷達中，我們曾經提及多個狀態管理的類庫，但 XState 在其中顯得與眾不同。它是個簡單的 JavaScript 和 TypeScript 框架，可以建立有限狀態機並視覺化為狀態圖。它可以跟最流行的響應式 JavaScript 框架（Vue.js，Ember.js，React.js 以及 RxJS）整合，並基於 W3C 標準來建立有限狀態機。另外一個值得留意的特性是它可以序列化狀態機的定義。在其他的上下文中（尤其在編寫遊戲邏輯時）建立有限狀態機時，我們發現一件很有幫助的事情，是 XState 對狀態以及可能的轉換的視覺化能力，透過它的 visualizer 實現起來是如此容易。
4、Streamlit
評估
Streamlit 是 Python 編寫的開源應用框架，資料科學家用其來構建好看的資料視覺化應用。Streamlit 專注於快速原型設計，並且支援各種不同的視覺化庫 (包括 Plotly 和 Bokeh)，因此在 Dash 等競品中脫穎而出。對於需要在實驗週期中快速展示的資料科學家來說，Streamlit 是一個可靠的選擇。我們在一些專案中使用它，並且只需要花費很少的工作量就能把多個互動式視覺化放在一起。