ThoughtWorks每年都會出品兩期技術雷達，這是一份關於技術趨勢的報告，由 ThoughtWorks 技術戰略委員會（TAB）經由多番正式討論給出，它以獨特的雷達形式對各類最新技術的成熟度進行評估並給出建議，為從程式設計師到CTO的利益相關者提供參考。
它比那些我們能在市面上見到的其他技術行情和預測報告更加具體、更具可操作性，因為它不僅涉及到新技術大趨勢，更有細緻到類庫和工具的推薦和評論，因此更容易落地。經過半年的追蹤與沉澱，ThoughtWorks TAB（ThoughtWorks技術諮詢委員會）根據我們在多個行業中的實踐案例，為技術者產出了第十八期技術雷達，對百餘個技術條目進行分析，闡述它們目前的成熟度，並提供了相應的技術選型建議。
本期四大主題
瀏覽器增強，服務端式微
為了實現應用邏輯，瀏覽器在持續擴充套件成為部署目標的能力。當平臺能照顧好橫切關注點和非功能性需求的同時，我們注意到後端邏輯的複雜性有逐步降低的趨勢。 WebAssembly 的引入為web應用建立邏輯提供了新的語言選擇，同時把處理過程更加推向金屬側（以及GPU）。 Web Bluetooth讓瀏覽器能夠處理那些原本是本地應用才能處理的功能，而且我們看到越來越多像 CSS Grid Layout和 CSS Modules這樣的開發標準正在替換掉自定義的庫。對更好使用者體驗的追求，正在持續地把功能裝進瀏覽器裡，許多後端服務因此變得越來越薄，複雜性也因而降低。
不斷蔓延的雲環境複雜性
雖然AWS繼續憑藉令人眼花繚亂的新服務保持領先，但我們逐漸看到 Google Cloud Platform （GCP）和 Microsoft Azure 已經成為可行的替代方案。像 Kubernetes 這樣的抽象層以及持續交付和基礎設施即程式碼這樣的實踐，能支援更容易的演進式變化，從而促進雲環境之間的過渡。但隨著 PolyCloud （這允許組織根據差異化的功能在多個供應商之間進行挑選）以及越來越多的監管和隱私問題的出現，雲策略必然會變得更加複雜。例如，許多歐盟國家現在依法對資料所在地做出要求。這使得資料儲存的管轄權和其主機的管理策略成為評估雲端計算環境的新維度。雲端計算環境的可選範圍也在擴大，比如在“函式即服務”和“管理更長壽命叢集”這兩者之間，就可以選擇提供了“容器即服務”（CaaS） 的 AWS Fargate 這個有趣的選項。雖然各個組織對雲技術的應用日臻成熟，但伴隨使用這些新技術構建真實解決方案的，是逐漸蔓延又無法避免的複雜性。
信任但要驗證
對於幾乎所有的軟體開發來說，安全問題仍然是至關重要的。當前我們觀察到傳統的“全域性許可權管理”的安全策略正在轉變為更為細緻的本地化方法。現在許多系統會在更小的領域內管理信任，並在不同系統之間使用一些新的機制建立可傳遞的信任。其理念正在由“永遠不信任領域外所有東西”以及“從不驗證領域內任何東西”轉變為“信任但是需要驗證領域內外任何東西”——也就是說可以假設和系統其它部分有本意良好的互動，但一定要在本地驗證這份信任。這使得團隊可以對自己的基礎設施、裝置和應用程式棧有高度的許可權控制，從而實現高度視覺化，並可以在必要時候提供高階訪問護欄。類似 Scout2的工具以及 BeyondCorp 這樣的技術反映了關於信任更成熟的視角。我們歡迎這種向本地化管理的轉變，特別是當工具和自動化策略可以確保同等或更好的合規性時。
物聯網的發展
物聯網（IoT）生態系統持續穩步發展，關鍵成功因素包括安全和成熟的工程實踐。我們看到了整個物聯網生態系統的增長，從裝置上的作業系統到連線標準，尤其是基於雲服務的裝置管理和資料處理。我們看到了一些成熟的工具和框架，支援良好的工程實踐，比如持續交付、部署以及為實現最終廣泛使用的大量其他必要實踐。除了主要的雲服務提供商——包括 Google IoT Core ，AWS IoT 和 Microsoft Azure IoT Hub ——像阿里巴巴和阿里雲這樣的公司也在大力投資物聯網 PaaS 解決方案。可以從我們的 EMQ 和Mongoose OS 條目一瞥當今物聯網生態系統的主流功能，它們也例證了 物聯網 的良好的發展狀態。
象限亮點搶先看
要記住，就像適用於其他軟體領域一樣，封裝也同樣適應於事件和事件驅動的體系結構。特別是，我們需要考慮一個事件的範圍，以及我們是否期望它在同一個應用程式、同一個領域或整個組織中被消費。DOMAIN-SCOPED EVENT將在其釋出的同一個領域內被消費，因此我們期望消費者能夠訪問特定的上下文、資料或引用，進而對事件進行處理。如果這個事件的消費在組織內更廣泛地發生，且事件的內容需要有所不同，我們就要注意不要“洩漏”其他依賴領域的實現細節。
身份管理是平臺的關鍵元件之一。外部使用者在使用移動應用的時候，需要對其身份進行驗證，開發人員需要被授權才能訪問基礎設施元件，而微服務也需要向彼此證明自己的身份。你應該考慮的是，身份管理是否真的有必要自己來搭建和維護。根據我們的經驗，HOSTED IDENTITY MANAGEMENT AS A SERVICE（ SaaS）這種解決方案更為可取。我們相信，像Auth0和Okta這樣的頂級託管商可以在“正常執行時間”和“安全”兩方面提供更好的SLA。也就是說，雖然有時候自行搭建和維護身份管理解決方案是一個現實的選擇，特別是對於那些有操作規範和資源的企業來說，這個選擇更為安全。但大型企業的身份解決方案通常包含更廣泛的功能，例如集中授權、治理報告和職責分離管理等等。不過，這些擔憂通常與員工身份更相關，特別是那些受遺留系統限制的企業，尤其如此。
在實踐微服務的過程中，為了將後端資源進行聚合，我們實踐了一個又一個的模式。之前，我們經常使用類似於Netflix Falcor這樣的工具幫助我們實現BFF（Backend for Frontend ），現在很多專案已經開始使用GRAPHQL FOR SERVER-SIDE RESOURCE AGGREGATION。GraphQL可以讓客戶端直接使用特定的查詢語句去訪問BFF以獲取資料。使用這項技術時，後端服務可以繼續暴露 RESTful API，而GraphQL可以輕易的將這些服務所提供的資源聚合在一起，並且對客戶端十分友好。我們推薦GraphQL是因為其簡化了BFF和其他聚合服務的實現。
在高度分散式的微服務架構中，其可觀察性有一個兩難問題 —— 要麼記錄一切，代價是巨量的儲存空間；要麼隨機抽樣記錄，代價是有可能丟失某些重要事件。最近我們注意到一項技術，它在這兩種方案之間提供了一個折衷方案。通過跟蹤請求頭中傳入的某個引數來LOG LEVEL PER REQUEST。使用跟蹤框架（可能基於OpenTracing標準），你可以在一次事務中的多個服務之間傳遞一個相關的ID。還可以在開始事務時注入其它資料（比如期望的日誌級別），並且與跟蹤資訊一起傳遞它。這樣可以確保這些額外資料在系統中總是和相應的單個使用者事務一起流動。這在除錯時也是個很有用的技巧，因為服務可能會暫停或以逐個事務的方式進行修改。
Headless CMS（ Content Management Systems, 內容管理系統） 正在成為數字化平臺的常見元件。CONTENTFUL是一個現代化的 headless CMS。我們的團隊已經成功把它整合到開發工作流中。我們特別喜歡其“API 優先”的特點，及其CMS as Code的實現。它支援強大的內容建模原語程式碼和內容模型演化指令碼，並允許將其視為其他資料儲存的schema，並將演進式資料庫設計實踐應用到 CMS 開發中。我們所喜歡的其他特性包括：預設包含兩個 CDN以提供多媒體資源和 JSON文件，本地化的良好支援和與Auth0整合的能力（儘管需要做出一些努力）。
EMQ是一個可伸縮的開源多平臺 MQTT代理。為了追求高效能，它使用Erlang/OTP語言編寫，能處理數百萬的並行連線。它能支援多種協議，包括MQTT、MQTT感測器網路、CoAP以及WebSockets，使其適用於物聯網和移動裝置。我們已經開始在專案中使用 EMQ，很享受其安裝以及使用的便捷性，以及它能將訊息路由到不同目的地（包括Kafka和PostgreSQL）的能力，還有它在監控和配置上所採用API驅動的策略。
TICK STACK是一個由開源元件組成的平臺。使用它就可以輕鬆地收集、儲存、繪製基於時間序列的資料（如度量和事件）來觸發告警。TICK Stack 的元件包括：收集和報告各種指標的伺服器代理telegraf、高效能時間序列資料庫InfluxDB、平臺的使用者介面 Chronnograf，以及可以處理來自 InfluxDB 資料庫的流式資料和批量資料的資料處理引擎Kapacitor。不像基於“拉”模型的Prometheus，TICK Stack是基於“推”模型來收集資料的。InfluxDB 元件是該系統的核心，同時也是目前最好的時間序列資料庫。雖然這套元件棧基於 InfluxData ，而且需要使用諸如資料庫叢集這樣的 InfluxData 企業版的功能，但在監控方面它仍然是一個不錯的選擇。我們正在一些生產環境上使用該平臺，並且獲得了一些很好的體驗。
WEB BLUETOOTH能夠直接從瀏覽器控制任意低功耗藍芽裝置。這樣以前只能通過原生手機應用來處理的場景，現在也可以適用了。該規範由 Web Bluetooth Community Group 釋出，並且定義了一個 API，通過藍芽 4.0 無線標準發現裝置並在裝置間通訊。 當前，Chrome 是唯一支援這個規範的主流瀏覽器。藉助Physical Web和 Web Bluetooth,現在有了其他途徑來讓使用者與裝置進行互動, 且無需讓他們在手機上安裝另一個應用。這是一個令人興奮的領域, 值得密切關注。
我們很開心使用 BACKSTOPJS 來做 web 應用的視覺化迴歸測試。作為視覺化比較工具，它的可配置視窗和可調節容錯能力可以很容易定位到細微差別。它有很優秀的指令碼功能，並且可以選擇在無介面Chrome、PhantomJS 和SlimerJS 中執行。我們還發現，它在實時元件樣式規範的基礎上執行時尤其有幫助。
世界上有數不清的問題都可以用數學優化問題來表達，而其中可以用凸問題來描述的那部分常常能夠得到有效解決。CVXPY便是一種針對凸優化問題所開發的開源Python嵌入式建模語言。它由史丹佛大學的學者維護，已經為數個開源和商業解決方案提供了功能齊備的安裝套件。它的文件中也包含了許多能夠引起開發者使用興趣的例子。儘管有些時候，我們仍然需要類似Gurobi和IBM CPLEX這類商業解決方案，但CVXPY在原型設計階段可以說所向披靡。在多數情況下，有CVXPY就足夠了。同時，基於最近的優化進展，其開發者一直在為我們提供更多的擴充套件包（例如DCCP）和相關軟體（例如CVXOPT）。
HELM是Kubernetes的包管理器。共同定義某個應用的Kubernetes資源集合被打包成圖表。這些圖表可以描述單個資源，例如Redis pod，或者全棧的Web應用程式：HTTP伺服器、資料庫和快取。Helm 預設帶有一些精選的 Kubernetes應用，維護在官方的圖表倉庫裡。想要為內部用途搭建私有的圖表倉庫也很容易。Helm有兩個元件：一個是稱為Helm的命令列工具，另一個是稱為Tiller的叢集元件。保護Kubernetes叢集是一個寬泛而微妙的話題，但我們強烈建議在基於角色的訪問控制（RBAC）環境中搭建Tiller。我們在很多客戶的專案中使用了Helm，它的依賴管理、模板和鉤子機制極大地簡化了Kubernetes中應用程式的生命週期管理。
ARCHUNIT是用來檢查架構特徵的Java測試庫，比如包與類的依賴關係、註解驗證、甚至層級一致性。它可以在你現有的測試方案中，以單元測試的方式執行，但目前只能用於Java架構。ArchUnit測試套件可以合併到C（I 持續整合）環境或部署流水線，使我們很容易地以演進式架構的方式實現適應度函式。
Hyperledger專案現在已經發展成包含一系列子專案的大工程。針對不同業務需求，可以支援不同的區塊鏈實現方式。例如，Burrow專門用來實現帶許可權控制的Ethereum，而Indy更專注於數字身份。在這些子專案中，Fabric是最成熟的一個。當開發者們談到使用 Hyperledger 技術時，實際上大多數時候是在考慮 Hyperledger Fabric。然而，chaincode的程式設計抽象相對底層，因為它直接處理賬本的狀態資料。此外，在編寫第一行區塊鏈程式碼之前，搭建基礎設施也經常耗去很多時間。HYPERLEDGER COMPOSER 構建於Fabric基礎之上，加速了將想法實現為軟體的過程。Composer 提供 DSLs 來建立業務資源模型、定義訪問控制和構建業務網路。使用 Composer，可以在不搭建任何基礎設施的情況下，僅通過瀏覽器來驗證我們的想法。需要明確的是，Composer 本身並不是區塊鏈，仍然需要把它部署在 Fabric 上。
RASA是聊天機器人領域的新成員。 它並非使用簡單的決策樹，而是通過神經網路將使用者意圖和內部狀態對映到迴應上。Rasa 整合了自然語言處理解決方案（spaCy）。與技術雷達中的其他同類工具不同，Rasa是開源軟體，可以自行託管，對於擔心資料所有權的使用者來說 Rasa 是一個可行的方案。我們在內部應用中使用了Rasa Stack，效果良好。
RIBs即路由器（Router）、互動器（Interactor）和構建器（Builder）的縮寫， 是來自 Uber 的跨平臺移動架構框架。RIBs的核心思想是將業務邏輯從檢視樹中分離出來，從而確保應用程式由業務邏輯驅動。 可以將其看作是Clean Architecture模式在移動應用程式開發領域的一次應用。通過在原生 Android 和 iOS 應用上使用一致的架構模式，RIBs為應用提供了清晰的狀態管理模式和良好的可測試性。儘管我們一直建議儘量將業務邏輯放在後端服務，不要將其洩漏到前端檢視中，但移動應用程式非常複雜，RIBs可以幫助管理這種複雜性。
REACTOR是一個基於Reactive Streams規範的、用於開發非阻塞式應用程式的 JVM 庫，支援 JVM 8 及以上版本。響應式程式設計強調將命令式邏輯轉換成非同步、非阻塞和函式式風格的程式碼，特別是在處理外部資源時。Reactor 實現了 Reactive Streams 規範，並且提供了兩個不同的釋出者API：Flux (0 到 N 個元素) 和 Mono（ 0 或 1 個元素），可以高效地對基於推送的流處理進行建模。Reactor 專案非常適合微服務架構，並且為HTTP、WebSockets、TCP和UDP等提供了支援背壓（backpressure）的網路引擎。
以上是我們在最新一卷技術雷達中隨機摘取的幾個Blips，欲獲取整版技術雷達，請點選這裡！