ThoughtWorks技術雷達：2021年一定要關注的技術趨勢和選型建議

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"技術雷達是 ThoughtWorks 每半年發佈一次的技術趨勢報告，它持續追蹤有趣的技術是如何發展的，我們將其稱之爲條目。技術雷達使用象限和環對其進行分類，不同象限代表不同種類的技術，而環則代表我們對其作出的成熟度評估。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"經過半年的追蹤與沉澱，ThoughtWorks TAB（ThoughtWorks 技術諮詢委員會）根據我們在多個行業中的實踐案例，爲技術者產出了第 24 期技術雷達。對百餘個技術條目進行分析，闡述它們目前的成熟度，並提供了相應的技術選型建議。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/wechat\/images\/65\/6540a86403958205ad03fb225cebb9a9.png","alt":null,"title":null,"style":null,"href":null,"fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"本期四大主題"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"加速產品上市的平臺團隊"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"越來越多的組織正在採用平臺團隊的理念來開發產品，即成立一個專門團隊，來創建和支持內部平臺功能，並使用這些功能來加速應用程序開發，降低運維複雜性，並縮短產品上市時間。這種日趨成熟的做法值得歡迎，所以我們早在 2017 年，就將該技術引入技術雷達。但是隨着成熟度的提高，我們發現組織在應用這項技術時，應避免使用一些反模式。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"例如，“用一個平臺來統治一切”，可能並不是最佳選擇。“構建一步到位的大平臺”，可能要過數年後才能交付價值。本着“一旦建好，就有人用”的初衷，到頭來可能卻是巨大的浪費。相反，使用產品思維，有助於根據產品客戶的需求，來弄清每個內部平臺所應提供的服務。但如果讓平臺團隊只解決技術支持工單系統中所提交的問題，那麼這種做法就又產生了老式的運維孤島團隊，出現相應的需求優先級失調的弊端，如反饋和響應緩慢，以及爭奪稀缺資源等的問題。此外，我們還看到一些新工具和集成模式湧現出來，以有效劃分團隊和技術。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"整合的便利性蓋過單項最佳方案"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我們在許多平臺（特別是在雲領域）上看到了相應的面向開發者的工具集成。例如，工件庫、源碼控制、CI\/CD 流水線、wiki 以及類似的工具，開發團隊通常會手工挑選這些工具並按需拼接在一起。擁有合併的工具棧可以爲開發人員帶來更多的便利和更少的工作，但這套工具集卻很少能代表最佳的解決方案。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"太複雜以至於無法進入雷達"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在技術雷達的命名法則裏，對許多複雜主題的討論，最終狀態都會是“TCTB——太複雜以至於無法進入雷達（too complex to blip）”。這意味着那些條目無法被分類，因爲它們呈現出太多正反兩面的特性，以及大量關於建議、工具的適用性和其他原因上的細微差別，這讓我們無法用短短几句話總結它們。這些主題通常每年都會出現，包括 monorepos，分佈式架構的編排指南以及分支模型等等。就像軟件開發中的許多主題一樣，那裏存在太多權衡，難以提供清晰明確的建議。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"識別架構耦合上下文"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在軟件架構中，如何在微服務、組件、API 網關、集成中心、前端等等之間確定一個適當的耦合級別，是幾乎每次會議都會討論的話題。隨處可見的情況是，當兩個軟件需要連接在一起時，架構師和開發人員都在努力地尋找正確的耦合級別。我們需要花時間和精力去理解這些因素，然後因地制宜地做出這些決定，而不是寄希望於找到一個通用卻並不恰當的解決方案。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"部分象限亮點搶先看"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/wechat\/images\/af\/af0197c1118d42d2be3f4dfced1dd69c.png","alt":null,"title":null,"style":null,"href":null,"fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"平臺工程產品團隊（採納）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"正如本期雷達主題之一所指出的那樣，業界在創建和支持內部平臺的“平臺工程產品團隊”中積累了越來越多的經驗。組織中的團隊使用這些平臺，可以加速應用程序開發，降低運營複雜性並縮短產品上市時間。隨着採用率的提高，我們對於這種方法的好和壞的模式也越來越清楚。創建平臺時，至關重要的是要明確定義可以從中受益的客戶和產品，而不是憑空建立。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我們不僅要謹防分層平臺團隊，它保留了現有技術孤島，只是貼上了“平臺團隊”的標籤而已，還要小心工單驅動的平臺運營模型。當考慮如何最好地組織平臺團隊時，我們仍然是團隊拓撲概念的忠實擁護者。我們認爲平臺工程產品團隊是一種標準方法，並且是高性能 IT 的重要推動者。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"雲沙箱（試驗）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"由於雲服務變得越來越常見，並且創建雲沙箱變得更加容易且可大規模應用，我們的團隊因此更傾向於使用完全基於雲（相對本地而言）的開發環境，並以此來減少維護複雜度。我們發現用於本地模擬雲原生服務的工具限制了開發者對構建和測試周期的信心，所以我們將重點放在標準化雲沙箱上，而不是在開發機器上運行雲原生組件。這樣的方式可以使基礎設施即代碼實踐得到更好的強制應用，併爲開發人員提供沙箱環境良好的適應過程。當然這種轉變也存在風險，因爲它假定開發人員將完全依賴於雲環境的可用性，並且可能會減慢開發者獲得反饋的速度。我們強烈建議您採用一些精益治理的實踐來管理這些沙箱環境的標準化，尤其是在安全、訪問控制和區域部署方面。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"同態加密（評估）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"完全的同態加密 (Homomorphic encryption) 是指一類允許在加密數據上直接進行計算操作（如搜索和算數運算）的加密方法。同時計算的結果仍然以加密的形式存在，並且稍後可以對其進行解密和顯示。雖然同態加密問題早在 1978 年就被提出來了，但直到 2009 年纔出現解決方案。隨着計算機算力的提升，和諸如 SEAL, Lattigo, HElib 和 Python 中的部分同態加密之類易於使用的開源庫的出現，同態加密在現實世界的應用程序中的應用才真正地變得可行。那些令人振奮的應用場景包括在將計算外包給一個不受信的第三方時的隱私保護，例如在雲端對加密數據進行計算，或使第三方能夠聚合同態加密後的聯邦機器學習的中間結果。此外，大多數的同態加密方案被認爲是對量子計算機安全的，並且標準化同態加密的努力也正在進行之中。儘管同態加密目前在性能和可支持的計算類型上還存在諸多侷限，但是它仍然是一個值得引起我們注意的技術。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/wechat\/images\/8d\/8d7c7d9a71a6467e6dd17a13c01ce6a5.png","alt":null,"title":null,"style":null,"href":null,"fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"Sentry（採納）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Sentry 已經成了許多團隊的默認選項。Sentry 提供了一些便利的功能，比如錯誤分組，以及使用適當的參數定義錯誤過濾規則，可以極大地幫助處理來自終端用戶設備的大量錯誤。通過將 Sentry 集成到持續交付流水線中，你可以上傳源碼映射文件，從而更高效地調試錯誤，並能很容易追蹤到是在哪個版本的軟件中產生了這些錯誤。我們很欣賞儘管 Sentry 是一個 SaaS 產品，但它的源代碼是公開的，這樣就可以免費用於一些較小的用例和自託管中。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"imgcook（評估）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"imgcook 是阿里巴巴旗下的軟件即服務產品。它可以通過智能化技術把不同種類的視覺稿 (Sketch\/PSD\/ 靜態圖片) 一鍵生成前端代碼。imgcook 可以生成靜態代碼，如果你定義了領域專用語言，它也可以生成數據綁定模塊代碼，該技術還沒達到完美的程度，設計人員需要參考某些規範，以提高代碼生成的準確性（此後仍需開發人員的調整）。我們對於魔術代碼生成一直十分謹慎，因爲從長遠看，生成的代碼通常很難維護，imgcook 也不例外。但是如果你限定它用於特定的上下文，例如一次性活動廣告頁，這項技術值得一試。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"AWS CodePipeline（暫緩）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"根據 ThoughtWorks 多個團隊的使用經驗，我們建議你謹慎使用 AWS CodePipeline。具體來說，我們發現一旦團隊的需求超出簡單的流水線範疇，此工具就會變得難以使用。儘管初次使用 AWS 時，像是贏得了“快速的勝利”，但我們建議你後退一步，評估 AWS CodePipeline 是否可以滿足你的長期需求，例如流水線的 fan-out 和 fan-in，或者是更復雜的部署，以及具有特殊依賴關係及觸發條件的測試場景。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/wechat\/images\/28\/28c9dfcf40e456e8f54a3c4073ae5fa1.png","alt":null,"title":null,"style":null,"href":null,"fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"Snowflake（試驗）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"自從上次在雷達上提到 Snowflake 以來，對於它的使用，以及作爲數據倉庫和數據湖的替代方案的 data mesh，我們都獲得了更多經驗。Snowflake 在時間旅行、零拷貝克隆、數據共享及其應用市場等功能方面，繼續給人留下深刻印象。Snowflake 至今還沒出現任何令我們不喜歡的地方，所以相較於其他選擇來說，我們的顧問會更偏愛使用它。亞馬遜的數據倉庫產品 Redshift 正在朝着將存儲和計算進行分離的方向發展，而這一直都是 Snowflake 的強項。如果使用 Redshift 產品中的 Spectrum 特性進行數據分析，就會感覺它並非那麼方便和靈活，部分原因是它受到了 Postgres 的約束（雖然我們也喜歡用 Postgres ）。而進行聯合查詢（federated queries）可能是使用 Redshift 的原因。在操作方面，Snowflake 的操作會更簡單。雖然 BigQuery 是另一種選擇，且非常易於操作，但在多雲的場景下，Snowflake 是更好的選擇。我們已經在 GCP、AWS 和 Azure 上成功地使用了 Snowflake。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"Feature Store（評估）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Feature Store 是一個服務於機器學習的數據平臺，可以解決當前我們在特徵工程中所遇到的一些關鍵問題。它提供了三個基本功能：（1）使用託管的數據管道，以消除新數據與數據管道之間的衝突；（2）對特徵數據進行編目和存儲，從而促進跨模型的特徵的可發現性和協同性；（3）在模型的訓練和干擾過程中，持續提供特徵數據。自從 Uber 公開了 Michelangelo 平臺以來，許多組織和初創企業都建立了自己的特徵庫；例如 Hopsworks、Feast 和 Tecton。我們看到了 Feature Store 的潛力，並建議仔細對其進行評估。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"自研基礎設施即代碼 (IaC) 產品（暫緩）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"那些由公司或社區所支持的（至少在業界引起關注的）產品，正在不斷髮展。但有時組織會傾向於在現有的外部產品之上，構建框架或抽象，來滿足組織內非常特定的需求，並認爲這種適配會比其現有的外部產品具備更多好處。我們發現一些組織試圖基於現有外部產品，創建自研基礎設施即代碼 (IaC) 產品。他們低估了根據其需求不斷演進這些自研解決方案而所需投入的工作量。很快他們就會意識到，所基於的外部產品的原始版本要比他們自己的產品好得多。在有些情況下，構建在外部產品之上的抽象，甚至削弱了外部產品的原始功能。雖然目睹過組織自研產品的一些成功案例，但是我們仍然建議要審慎地考慮這種方式。因爲這會帶來不可忽視的工作量，並且需要確立長期的產品願景，才能達到預期的結果。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/wechat\/images\/35\/359b729bc41cb5f3cc6f56acb6212218.png","alt":null,"title":null,"style":null,"href":null,"fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"Combine（採納）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我們幾年前把 ReactiveX（反應式編程開源框架中的一個系列）移到了技術雷達的“採納”環中。2017 年，我們提到了 RxSwift，它可以將反應式編程應用到基於 Swift 的 iOS 開發中。此後，Apple 以 Combine 的形式推出了自己的反應式編程框架。對於僅支持 iOS 13 及更高版本的 App 而言，Combine 已經成爲默認的選擇。它比 RxSwift 更容易學習，並且與 SwiftUI 集成得很好。如果您想要將現有項目框架從 RxSwift 轉換爲 Combine，或者在一個項目中同時使用兩者，可以瞭解一下 RxCombine。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"Kotlin Flow（試驗）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Kotlin 協程的引入爲 Kotlin 的創新打開了一扇大門——直接集成到協程庫中的 Kotlin Flow 就是其中之一。Kotlin Flow 是一種基於協程的響應式流的實現。與 RxJava 不同的是，流是 Kotlin 原生的 API，與熟悉的序列 API 類似，包括 map 和 filter 方法。跟序列一樣，流是“冷”的，這就意味着只有當需要使用的時候才構造序列的值。所有這些特性使多線程代碼的編寫比其他方法更加簡單和易於理解。可以預見，通過 toList 方法將流轉換成列表將會成爲測試中的一種常見模式。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"River（評估）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"衆多機器學習方法的核心皆在於從一組訓練數據創建一個模型。一旦創建了模型，就可以反覆使用它。然而世界並不是靜止的，通常模型需要隨着新數據的出現而改變。單純地重新訓練模型可能會非常緩慢和昂貴。增量學習解決了這個問題，它使從數據流中增量地學習成爲可能，從而更快地對變化做出反應。作爲額外的好處，計算和內存需求更低，而且是可預測的。我們在基於 River 框架的實現中積累了良好的經驗，但到目前爲止，我們需要在模型更新後增加校驗，有時要手動進行。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"strong"}],"text":"完整版技術雷達可點擊以下鏈接："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"strong"}],"text":"https:\/\/www.thoughtworks.com\/cn\/radar"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}