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