前言：

ThoughtWorks人酷愛技術。我們對技術進行構建、研究、 測試、開源、記述，並始終致力於對其進行改進-以求造福 大眾。我們的使命是支持卓越軟件並掀起IT革命。我們創建 並分享ThoughtWorks技術雷達就是為了支持這一使命。由 ThoughtWorks中一群資深技術領導組成的ThoughtWorks 技術顧問委員會(TAB)創建了該雷達。他們定期開會討論 Thoughtworks的全球技術戰略以及對行業有重大影響的 技術趨勢。

這個雷達以獨特的形式記錄技術顧問委員會的討論結果, 為從開發人員到CTO在內的各路利益相關方提供價值。這 些內容只是簡要的總結,我們建議您探究這些技術以了解 更多細節。

這個雷達是圖形性質的,把各種技術項目歸類為技術、工具、平臺和語言及框架,如果某個條目可以出現在多個象 限,我們選擇看起來最合適的象限。我們還進一步將這些技 術分為四個環以反映我們目前對其的態度。

要了解關於雷達的更多背景,請點擊:https://www. thoughtworks.com/radar/faq

關於技術：

相關解讀：

很多文檔都可以被高度可讀的代碼和測試取代。然而對於演進式架構來說，記錄某些設計決策非常重要，這不僅有利於未來的團隊成員理解，也有利於外部監督。輕量級架構決策記錄是一種用於捕獲重要的架構決策及其上下文和結果 的技術。我們建議將這些詳細信息進行版本化，而不是wiki 或網站，這樣所記錄的內容就可以和代碼保持同步。對於大 多數項目，我們沒有理由不采用這種技術。

過去12個月裏，我們註意到對數字化平臺這個主題的關註 發生了急劇的增長。希望快速有效推出新數字解決方案的公司，正在建立內部平臺，為交付團隊提供自助服務，從而訪問那些構建和運營自己的解決方案所必需的業務API、工 具、知識和支持。我們發現當這些平臺得到跟外部產品同等的重視時，它們的效率是最高的。將產品管理思維應用於內部平臺，意味著與內部消費者（開發人員）建立共情，並在設計上彼此協作。平臺的產品經理要建立路線圖，確保平臺為業務交付價值，為開發者改善體驗。一些企業甚至為內部 平臺創建了品牌標識，並向同事推銷平臺的優勢。平臺產品 經理將負責平臺的質量、收集使用指標，並持續改進平臺。 將平臺作為產品來處理，有助於創造一個蓬勃發展的生態系統，避免構建另一個停滯不前的、未充分利用的面向服務 架構。

適應度函數借鑒自進化計算，被用來衡量方 案對滿足目標的適合度。

適應度函數借鑒自進化計算，被用來衡量方案對滿足目標 的適合度。當定義演進式算法時，算法設計者會尋求更優 解，而適應度函數則定義了在此上下文中“更優”的含義。 《演進式架構》一書定義了架構適應度函數的概念，為衡量架構特征提供了一個客觀全面的方法，包括已有的驗證 標準，比如單元測試、業務指標、監控等等。我們相信架構 師能夠驗證並維持一套自動化的可持續的架構標準，這是 演進式架構的關鍵。

CI和CD工具可以用來測試服務配置、服務鏡 像構建、環境準備以及環境的集成。（為基礎設施即代碼使用流水線）

　　在早期的技術雷達中，我們討論了Netflix的（Chaos Monkey）。 混沌猴可以隨機終止生產系統中的運行實例，並對結果進 行度量，從而幫助驗證系統在運行時對生產中斷的應對能 力。今天，人們有了一個新興術語來描述這一技術的廣泛應 用：混沌工程。在生產環境的分布式系統中運行這些試驗， 可以幫助我們建立系統在動蕩環境下依舊能夠按預期工作 的信心。如果想要更好地理解這個技術方向，請參閱混沌工程原則。

　　受DevOps運動的啟發，DESIGNOPS是一種文化上的轉 變，同時包含了一系列的實踐。DesignOps可以幫助組織不 斷地重新設計產品，而又無需在質量、服務連貫性和團隊 的自主性上妥協。DesignOps提倡創建並演進設計的基礎 設施，最大限度降低創造新的UI概念及其變體的工作量， 並與最終用戶建立快速且可靠的反饋機制。通過使用諸如 Storybook這樣促進緊密協作的工具，對前期分析和規範交 接的需求可以被降至最低。使用DesignOps，設計正在從一 種具體的實踐演變成每個人工作的一部分。

我們已經從引入微服務架構中獲得了明顯的好處，微服務 架構可以讓團隊裁剪出獨立部署的交付物以及可維護的服務。不幸的是，我們還看到許多團隊在後端服務之上創建了 前端單體——一個單一，龐大和雜亂無緒的瀏覽器應用。我 們首選的（經過驗證的）方法是將基於瀏覽器的代碼拆分成 微前端。在這種方法中，Web應用程序被分解為多個特性， 每個特性都由不同的前後端團隊擁有。這確保每個特性都 獨立於其他特性開發，測試和部署。這樣可以使用多種技術 來重新組合特性——有時候是頁面，有時候是組件——最終 整合成一個內聚的用戶體驗。

使用持續交付流水線來編排軟件的發布流程，已經成為了 主流概念。不過，對基礎設施代碼進行自動化測試還沒有被 廣泛理解。CI和CD工具可以用來測試服務配置（如Chef的 cookbook，Puppet的模塊，Ansible的playbook）、服務鏡像 構建（如Packer）、環境準備（Terraform，CloudFormation 等）以及環境的集成。對基礎設施即代碼使用流水線可以讓 錯誤在進入運維環境，包括開發和測試環境之前就被發現。 這些流水線還能確保基礎設施工具能始終如一地運行在CI / CD的Agent上，而不是在特定的工作站上。挑戰仍然存在，比 如與容器和虛擬機相關的更長的反饋周期，但我們認為這是 一個有價值的技術。

無服務器架構迅速得到了需要部署雲端應用的組織的認 可，並且有著大量可供選擇的部署方式。即便是相對傳統 和保守的組織，也在使用一部分無服務器技術。雖然可以 使用的合適的模式仍在不斷湧現，但大多數時候我們的討 論都會走向函數即服務(Functions as a Service)（例 如 AWS Lambda，Google Cloud Functions，Azure Functions）。部署無服務器函數毫無疑問能夠減少大量傳 統方式特有的，涉及服務器和操作系統配置和編排的工作 量。然而serverless也並不是百試不爽的萬金油。當前這個 階段，因為一些特別的需求，你必須做好能回退至容器化， 甚至是實例化部署的準備。與此同時，無服務器架構的其他 組件，比如後端即服務（Backend as a Service），幾乎成為 了默認的選擇。

因為測試驅動開發自身的優勢，許多開發團隊會在編寫代 碼時采用這一實踐。也有一些團隊開始使用容器來打包和部署軟件，而通過自動化腳本來構建容器已經是被廣為接受的實踐。但迄今為止，我們很少看到有團隊能將這 兩種趨勢結合，通過測試來驅動容器腳本的編寫。借助 ServerSpec和Goss這樣的框架，你可以為獨立的或編排 的容器呈現預期的功能，並得到快速反饋。這意味著我們 可以尋求用TDD開發容器腳本。我們在這方面得到的初步體驗是十分積極的。

近年來IT運維所收集到的數據量一直在增加。例如，微服 務的迅速發展意味著更多的應用程序正在生成自己的操作 數據；而像Splunk，Prometheus或ELK堆棧這樣的工具讓 數據存儲和後續處理變得更容易，從而獲得運營洞見。毋庸 置疑，隨著機器學習工具的普及，運營人員已經開始將統計 模型和經過訓練的分類算法納入其工具包中。雖然這些算 法並不新穎，而且人們已經進行了各種嘗試來自動化服務管 理，但是在了解機器和人員如何協作以便早期識別異常和確 定故障來源這個方向，我們還是先行者。盡管基於算法的IT運維（Algorithmic IT Operations）有過度炒作的風險， 但毫無疑問，機器學習算法的穩步提升將改變未來的數據 中心運營中人類所起到的作用。

在銀行、數字貨幣、供應鏈透明化等多個金融科技領域，區 塊鏈技術已經被炒作成“靈丹妙藥”。我們曾經在過去的雷 達中推薦過帶有智能合約功能的Ethereum，而最近已經看 到Ethereum在去中心化應用的其他領域中得到更多的發展。盡管這一技術非常年輕，我們仍然鼓勵你在加密貨幣和 銀行之外的領域，使用它構建去中心化應用。

在銀行、數字貨幣、供應鏈透明化等多個金 融科技領域，區塊鏈技術已經被炒作成“靈 丹妙藥”。

隨著事件流（event streaming）平臺（如Apache Kafka）的 興起，很多人將它們視為消息隊列的高級形態，僅用來傳輸 事件。即便按這種方式使用，事件流仍然具有傳統消息隊列 無法比擬的優勢。然而我們更感興趣的是，人們如何通過 把平臺（特別是Kafka）作為主要存儲，把數據保存為不可 變事件，從而將事件流作為正確數據之源。例如，以Event Sourcing方式設計的服務，可以使用Kafka作為事件存儲工 具（event store），其他服務可以消費這些事件。這一技術能 夠減少本地持久化和集成之間的重復工作。

主要的雲服務提供商(Amazon、Microsoft和Google)正 陷入一場激烈的競爭中，以保持核心能力的均勢，雖然 他們的產品只是略有差異。這導致一些組織采用多雲 （POLYCLOUD）策略，而不是與一個提供商“全面”合作， 他們正在以最佳組合的方式，將不同類型的工作負載交由不 同的供應商。例如，這可能包括將標準服務放在AWS上，使 用Google進行機器學習，把采用SQL Server的.NET程序部 署在Azure，或者可能使用Ethereum Consortium的區塊鏈 解決方案。這並不等同於致力於供應商間可移植性的“跨雲 策略”，後者價格昂貴且會導致迎合大眾的想法。多雲策略 則專註於使用每個雲能提供的最好的服務。

服務嚙合(service mesh)在服務發現、安全、 跟蹤、監控與故障處理方面提供了一致性，且 不需要像API網關或ESB這樣的共享資產。

現在越來越多的大型組織在向更加自組織的團隊結構轉 型，這些團隊擁有並運營自己的微服務，但他們如何在不依 賴集中式托管的基礎架構下，確保服務之間必要的一致性與 兼容性呢？為了確保服務之間的有效協作，即使是自組織的 微服務也需要與一些組織標準對齊。服務嚙合(SERVICE MESH)在服務發現、安全、跟蹤、監控與故障處理方面提供 了一致性，且不需要像API網關或ESB這樣的共享資產。服務 嚙合的一個典型實現包含輕量級反向代理進程，這些進程 可能伴隨每個服務進程一起被部署在單獨的容器中。反向 代理會和服務註冊表、身份提供者和日誌聚合器等進行通 信。通過該代理的共享實現（而非共享的運行時實例），我 們可以獲得服務的互操作性和可觀測性。一段時間以來，我 們一直主張去中心化的微服務管理方法，也很高興看到服務 嚙合這種一致性模式的出現。隨著linkerd和Istio等開源項 目的成熟，服務嚙合的實現將更加容易。

微服務架構中，眾多服務將其資產和功能都通過API暴露出 來，同時也擴大了系統的被攻擊面。因此一個零信任—— “永不信任，始終驗證”的安全架構勢在必行。然而，由於 服務代碼復雜性的增加以及在多語言環境中缺少庫和語言 的支持，服務之間的安全控制往往會被忽略。為了解決這 個復雜性，我們已經看到將安全性委托給進程外Sidecar的 做法，Sidecar是一個獨立的進程或一個容器，它與每個服 務一起部署和調度，並共享相同的執行上下文、主機和身 份。Sidecar實現了安全功能，如對服務間的通信作透明加 密、TLS終止，以及對調用方服務或最終用戶的鑒權機制。在 實現自己的用於端點安全的SIDECAR之前，我們推薦你先 研究一下Istio、linkerd或者Envoy。

傳統的企業安全方法往往強調鎖定事物並減慢變革的步 伐。但眾所周知，攻擊者對系統實施攻擊的時間越長，造成 的損失也就越大。3Rs企業安全：輪換、修復、重建，利用基 礎設施自動化和持續交付來消除攻擊機會。輪換憑證，一旦 有可用的補丁就立即應用補丁，並且在幾分鐘或幾小時內完 成從已知的安全狀態重建系統，這會使攻擊者更難獲得立 足點。隨著現代原生雲架構的出現，3RS安全技術變得可 行。當應用程序部署為容器，並通過完全自動化的流水線進 行構建和測試時，安全補丁只不過是又一次通過一個點擊， 就可以通過流水線發布的小版本而已。當然，為了保持良 好的分布式系統實踐，開發人員需要設計應用以適應意外 的服務器中斷。這就和在環境中實施混沌猴所造成的影響 相似。

Kafka已經是流行的消息解決方案，同時，Kafka Streams也 站到了流式架構的最前沿。不幸的是，隨著人們將Kafka作 為數據和應用平臺的核心，我們看到一些組織沒有將Kafka 的生態組件（如連接器、流處理器等）按產品和服務團隊劃 分，而是將它們集中管制，這用KAFKA重現了ESB反模式。 這一反模式具有很嚴重的問題，過多的邏輯、編排、轉換被 插入到集中管理的ESB中，使得系統嚴重依賴於一支中心化 團隊。我們特此提出這個問題，希望勸阻這種反模式的更多 實現。

關於平臺：

內容解讀：

自我們上次在技術雷達中提到KUBERNETES至今，它已經 成為我們大部分客戶將容器部署到服務器集群的默認解決 方案。而能替代它的其他產品不但沒有獲得如此的客戶認 同度，甚至在某些場景中，我們的客戶會將他們的“引擎” 都更換成 Kubernetes。Kubernetes已經成為主流公有雲平 臺上的首選容器編排平臺。這些主流公有雲平臺包括微軟的 Azure 容器服務以及 Google Cloud（參見GKE）。此外市面上 還有很多好用的產品，來不斷豐富快速擴大的Kubernetes 生態圈。與此同時，那些試圖用一層抽象將Kubernetes隱藏 起來的平臺尚未成功地證明自己的價值。

作為一個開源的跨平臺軟件開發框架，.NET CORE被 越來越多地運用到實際項目中。該框架令 .NET 應用能在 Windows、macOS 以及 Linux 系統上進行開發和部 署。.NET Standard 2.0 的發布增加了跨多個 .NET 平臺的標準 API 的數量，這使得往.NET Core遷移的路徑變得更為 清晰。有關.NET Core對其上類庫的支持性問題正在逐漸減 少。一流的跨平臺工具已經湧現出來，用於在非 Windows 平臺上進行高效的開發工作。運用Docker鏡像，能讓.NET Core 服務可以輕松地集成到容器環境中。其社區發展的積 極方向以及來自我們實際項目的反饋，都表明.NET Core現 在已經可以廣泛地運用了。

隨著Gatling和Locust等工具的日益成熟，壓力測試變得越 來越容易。與此同時，彈性雲平臺基礎設施可以模擬大量客 戶端實例來進行壓力測試。我們欣喜地看到像 Flood IO 這 樣的雲平臺能越來越深入地應用此類技術。FLOOD IO是一個基於SaaS的壓力測試服務。它可以用來向數百臺雲端 服務器分發測試腳本並在其上執行。我們的團隊發現，通過 重用現有的Gatling測試腳本能很簡單地將性能測試遷移到 Flood IO。

隨著GOOGLE CLOUD PLATFORM（GCP）在可用地理區 域和服務成熟度方面的擴展，全球的客戶在規劃雲技術策 略時可以認真考慮這個平臺了。與其主要競爭對手Amazon Web Services相比，在某些領域， GCP 所具備的功能已經 能與之相媲美。而在其他領域又不失特色——尤其是在可訪 問的機器學習平臺、數據工程工具和可行的 “Kubernetes 即服務解決方案”（GKE）這些方面。在實踐中，我們的團隊 對GCP工具和API良好的開發者體驗也贊賞有嘉。

隨著Google Cloud Platform在可用地理區 域和服務成熟度方面的擴展，全球的客戶在 規劃雲技術策略時可以認真考慮這個平臺了。

在微服務或任何其他分布式架構中，最常見的一個需求 是通過身份驗證和授權功能來保護服務或 API。 這正是 Keycloak 所解決的問題。KEYCLOAK是一個開源的身份和 訪問管理解決方案，它讓保障應用程序和微服務的安全變 得如此簡便，以至於幾乎不需要編寫什麽代碼。它提供了單 點登錄、社交網絡登錄和一些開箱即用的標準協議——如 OpenID Connect、OAuth 2.0 和 SAML。我們的團隊一直在 使用這個工具，並計劃繼續使用。不過這個平臺在安裝時需 要做一些工作。由於在初始化和運行時需要通過 API 對其 進行配置，因而必須編寫腳本以確保部署是可重復的。

在之前的雷達中，我們提到由於Unity在一個成熟平臺上 提供了一些抽象和工具，因此它已經成為VR和AR應用程 序開發的首選平臺。與它的主要替代品Unreal Engine相 比，Unity更容易訪問。隨著它最近推出的針對iOS平臺的 ARKit 和針對安卓平臺的 ARCore，這兩個主要的移動平臺 都已擁有強大的原生SDK，用來構建增強現實應用。但是， 我們覺得很多團隊，特別是那些在構建遊戲方面沒有豐富 經驗的團隊，都能從利用類似Unity這樣的抽象中受益。這 就是為什麽我們要提出超越遊戲的UNITY。這使得不熟悉 上述開發技術的開發人員可以專註於這個SDK，來進行相 關開發。它還為多設備提供了解決方案，特別是在原生SDK 不支持的安卓端。

常與WhatsApp被相提並論的微信，在中國正在成為名副其 實的商業平臺。很多人可能還不知道，微信還是最流行的線 上支付平臺之一。借助微信內置的內容和會員管理系統，一 些小型企業現已完全依賴微信開展其業務。大型組織可以 通過微信的一些功能把內部系統對接給員工使用。作為覆 蓋七成以上中國人的平臺，微信是每一個想開辟中國市場的 企業都需要考慮的重要商業因素。

AZURE SERVICE FABRIC是為微服務和容器打造的分布 式系統平臺。它不僅可以與諸如Kubernetes之類的容器編 排工具相媲美，還可以支持老式的服務。它的使用方式花樣 繁多，既可以支持用指定編程語言編寫的簡單服務，也可以 支持 Docker 容器，還可以支持基於 SDK 開發的各種服務。 自幾年之前發布以來，它不斷增加更多功能，包括提供對 Linux 容器的支持。盡管 Kubernetes 已成為容器編排工具的主角，但 Service Fabric 可以作為 .NET 應用程序的首選。 我們正在 ThoughtWorks 的一些項目中使用這個平臺，迄今 為止感覺不錯。

CLOUD SPANNER是一個完全托管的關系型數據庫服務。 它在提供高可用性和強大的一致性的同時又不會對延遲做 出妥協。Google 在一個名為 Spanner 的全球分布式數據庫 上投入了大量時間之後，最近以 Cloud Spanner 的名稱將這 個服務對外發布。 這個平臺可以將數據庫實例在全球範圍 從單個節點規模化到數千個節點，而不必擔心數據一致性問 題。 Cloud Spanner 通過高可用的分布式時鐘 TrueTime，為讀取和快照功能提供了強大的一致性。從 Cloud Spanner 讀取數據時可以使用標準 SQL，但是在做寫入操作時必須 使用其提供的 RPC API。 盡管並不是所有的服務都需要全球範圍規模的分布式數據庫，但 Cloud Spanner 的對外發 布極大地改變了我們對數據庫的認知。其設計正在影響像 CockroachDb 這樣的開源產品。

在經過了徹底探索之後，區塊鏈領域的重要參與者R3意識 到區塊鏈並不契合他們的目的，所以他們創造了CORDA。 Corda是專註於金融領域的分布式賬本技術（distributed ledger technology, DLT）平臺。 R3具有非常明確的價值主 張，並且知道他們的問題需要務實的技術方法。 這和我們 的經驗相符——由於采礦成本較大和運營效率低下，對於某 些商業案例，目前的區塊鏈解決方案可能不是合理的選擇。 盡管我們目前在Corda上的開發體驗並不非常流暢，而且 v1.0發布後其API並不穩定，我們還是期望看到 DLT 領域能 進一步成熟。

COSMOS DB是微軟於年初發布的全球分布式與多模型數據庫服務。雖然大多數新型 NoSQL 數據庫都提供可調節 的一致性，但Cosmos DB 卻將一致性作為首要特性予以支 持。它提供五種不同的一致性模型。值得強調的是，它還支 持多種數據模型——鍵值、文檔、列族和圖——所有這些數 據模型都映射到其內部數據模型，即原子記錄序列（atomrecord-sequence, ARS）。Cosmos DB 有趣的一個特點是 能針對其延遲、吞吐、一致性和可用性來提供服務級別協議 （service level agreement, SLA）。其適用性廣的特點，給 其他雲廠商設置了一個很高的追趕標準。

隨著近來聊天機器人與語音平臺的爆發，湧現出一批工具和 平臺——它們能夠提供一些服務，從文字中挖掘意圖，並管 理會話流，以供人使用。Google所收購的DIALOGFLOW （原名為API.ai），就是一種這樣的”自然語言理解即服務” 的平臺。它在該領域中與Facebook的wit.ai以及Amazon Lex等平臺展開了競爭。

盡管以Kubernetes作為容器編排平臺正成為軟件開發生 態的主流，但從運維角度看，運行 Kubernetes 集群仍然 很復雜。GKE（Google Container Engine）是一個托管Kubernetes解決方案，用來部署容器化應用程序。它能降 低運行和維護Kubernets集群的運維成本。我們的團隊在使 用GKE獲得了良好的體驗。平臺能完成許多繁重的工作，例如安裝安全補丁，監控和自動修復節點，以及管理多集群和 多區域網絡。根據我們的經驗，Google采用了API優先的方 式來開放平臺功能，並使用了諸如用OAuth進行服務授權的 行業標準。這些都能夠改善開發人員的體驗。盡管其開發團 隊已經盡力隔離底層變更對使用者的影響，但要意識到GKE 仍在快速開發中。在過去一段時間裏我們還是會時不時地 受到變更所帶來的影響。我們期待隨著Terraform on GKE 及類似工具的出現，“基礎設施即代碼”這一實踐的成熟度 會不斷提高。

Language Servers將代碼補全、調用分析和 重構等能力提取為一種 API，從而讓任何編 輯器都能與編程語言的抽象語法樹交互。

KAFKA STREAMS是一個用於構建流式應用的輕量級庫。 它的設計目標在於簡化流式處理，讓它像為異步服務設計 的主流應用編程模型一樣易於訪問。當需要應用流式處理 模型來解決問題，又不想陷入運行集群（通常會隨著功能完 備的流處理框架而引入）的復雜性時，它會是一個很好的選 擇。 新的功能包括在Kafka集群中的“恰好一次”（exactly once）流處理。實現方式是在Kafka生產者端引入冪等性， 並且使用新的事務API跨多個分區實現原子寫入。

大型 IDE 的威力很大程度上源於利用源代碼分析出的抽象 語法樹（AST）來進一步分析和操作源代碼的能力，比如代 碼補全，調用分析和重構。語言服務器將這種能力提取到單 獨的進程中，從而讓任意文本編輯器都可以通過 API 來使 用 AST。微軟從他們的 OmniSharp 和 TypeScript 服務器 項目中，提煉並引領了語言服務器協議（Language Server Protocol, LSP）的擬定。編輯器只要使用LSP 協議就可用於 任何具備 LSP 兼容服務器的編程語言的開發。這意味著我 們可以繼續使用自己喜愛的編輯器，同時也不必放棄各種編 程語言的高級編輯功能——這對於很多 Emacs 癮君子來說 尤其利好。

LORAWAN是一種低功耗廣域網，專為低功耗、遠距離和 低比特率的通信場景而設計。它提供了邊緣設備與網關設 備之間的通信能力，能夠通過後者將數據轉發至應用程序 或者後臺服務。LoRaWAN通常用於分布式傳感器組或物聯 網這些必須具備長電池壽命和遠距離通信能力特點的設備 上。它解決了在使用一般的WiFi進行低功耗廣域網通信時 的兩個關鍵問題：通信距離和功耗。LoRaWAN已有若幹實 現，其中值得註意的是一個免費的開源實現——The Things Network。

隨著機器學習從試驗性使用轉向生產環境， 需要一種可靠的方式來托管和部署這些可遠 程訪問的模型，並能隨著消費者數量的增加 而進行擴展。 (TensorFlow Serving)

MAPD是一個支持SQL的運行在GPU 上的內存列式分析性 數據庫。我們對於數據庫負載到底是I/O密集所致還是計算 密集所致有過爭論。不過GPU的並行能力，結合 VRAM 的充 足帶寬，在某些場景下非常有用。MapD可以透明地將最頻 繁使用的數據（比如在group-by、過濾、計算操作以及 join 條件中所涉及的列）存放在VRAM中，而將其余的數據存放 在主內存中。通過這種內存管理方式，MapD無需索引即可 達到相當好的查詢性能。盡管還有其他GPU數據庫提供商， 隨著MapD近期開源了其核心數據庫，以及通過GPU開放分 析計劃（GPU Open Analytics Initiative）的推廣，MapD在 這個領域處於領先地位。如果你的分析任務是計算密集型 的，並能夠利用GPU的並行性進行加速，且能納入主內存 中，我們建議評估MapD。

我們很喜歡那些能很好地解決單個問題的簡單工 具。NETLIFY正是這樣一個工具。用它可以創建靜態網站內容，提交到GitHub，然後網站就能快速、輕松地上線可用了。Netlify提供命令行工具來控制流程，支持 CDN（內容分發網絡），可以與Grunt這樣的工具協同工 作。更重要的是Netlify支持HTTPS。

機器學習模型已經開始滲入到日常的商業應用中。當有足夠 的訓練數據可用時，這些算法可以解決那些以前可能需要 復雜的統計模型或試探法的問題。隨著機器學習從試驗性 使用轉向生產環境，需要一種可靠的方式來托管和部署這 些可遠程訪問的模型，並能隨著消費者數量的增加而進行 擴展。TENSORFLOW SERVING通過將遠程gRPC接口暴 露給一個被導出來的模型，解決了上述部分問題。這支持以 多種方式部署訓練完成的模型。TensorFlow Serving也接 受一系列的模型來整合持續的訓練更新。其作者維護了一 個Dockerfile來簡化部署過程。據推測，gRPC 的選擇應與 TensorFlow 執行模型保持一致。但是，我們通常都會對需 要代碼生成和本地綁定的協議保持警惕。

憑借WINDOWS CONTAINERS，微軟正在容器化的道路上 奮起直追。截至本期雷達，微軟提供了2個可以在Docker容 器中運行的Windows OS的鏡像——Windows Server 2016 Server Core和Windows Server 2016 Nano Server。盡管 Windows Container還有提升的空間，比如縮減鏡像文件大 小，增強對生態系統的支持，以及完善相關文檔，我們的團 隊已經開始在其他容器化技術已經成功應用的場景（如構 建代理）中使用它們了。

在中間件中實現業務邏輯和流程編排，特別是要在其中運 用專業技能和專用工具來將中間件作為一個單點來創建，以 實現規模化和控制，對此我們還是心懷顧慮的。API網關市 場競爭十分激烈，那些供應商們持續地向其產品中添加新 的功能，從而體現產品之間的差異化。這一點令上述趨勢得 以持續。但這樣會產生出過度龐大的API網關產品。其功能 在本質上就是反向代理，這助長了難以測試和部署的系統 設計。API網關確實可以提供一些處理某些特定問題的實用 程序——例如身份驗證和速率限制——但是任何領域業務 邏輯都應該僅出現在應用程序或服務中，而不是網關中。

關於工具：

內容解讀：

我們的團隊非常喜歡托管的 CI / CD工具——BUILDKITE， 因為它既簡單，搭建速度又快。只需要安裝一個輕量級的代 理應用程序來連接構建代理與在Buildkite上所托管的構建 服務，就可以使用私有或雲端的機器來執行構建。與使用托 管的代理相比，能在這種級別上對構建代理的配置進行控 制，在多數情況下都是一個優勢。

CIRCLECI是一個持續集成引擎，它既可以在SaaS雲服務上 使用，又可以私有部署使用。它已經被我們很多開發團隊在 SaaS平臺上當作常用CI工具。這些團隊需要低摩擦（lowfriction）和易於搭建的構建與部署流水線。CircleCI 2.0的 版本支持構建任務的工作流，並具備扇入（fan-in）和扇出 （fan-out）流模式和手動觸發模式，且支持移動開發。它也 允許開發者在本地運行流水線。另外 CircleCI 能很容易地與 諸如Slack及其他通知和報警系統進行集成。就像使用任何 其他承載公司資產的SaaS產品一樣，我們建議用戶仔細查 看CircleCI的安全實踐。

Gopass增加了諸如多用戶密碼管理、層級式 密碼存儲、交互式查找、基於時間的一次性 密碼（TOTP）,以及二進制存儲格式等功能.（gopass）

GOPASS是一個基於GPG和Git的團隊密碼管理解決方案。 它的前身是pass，並在此基礎上增加了諸如多用戶密碼管 理、層級式密碼存儲、交互式查找、基於時間的一次性密碼 （TOTP）,以及二進制存儲格式等功能。由於它的存儲格式 與pass基本兼容，因此可以直接從pass遷移過來。這意味 著只需調用一次存儲密鑰就能將其集成到遷移的整備工作 流中。

從2017年中開始，Chrome 用戶有了一個在Headless模式 下運行瀏覽器的新選擇。這非常適合執行那些依賴瀏覽器 的前端測試，而不必在屏幕上顯示操作的結果。而在此之前，這屬於 PhantomJS 的地盤，但Headless Chrome正在迅速取代那種用 JavaScript 驅動 WebKit 引擎的方法。測試在 Headless Chrome 瀏覽器中的運行速度要快得多，而且在行為上更貼近真實的瀏覽器，但我們的團隊也發現它 比 PhantomJS 要占用更多內存。 基於上述優點，針對前端測試的HEADLESS CHROME 很可能成為這個領域的事 實標準。

如果正在尋找用Go和Java編寫的高性能 JSON 編碼/解碼 工具，那就試試開源庫JSONITER，它與Go語言中的標準 JSON編碼包相兼容。

最初由Soundcloud開發的監控和時序數 據庫工具Prometheus，不僅在進行持續 改進，而且其使用率也獲得了一些提升。 （Prometheus）

最初由Soundcloud開發的監控和時序數據庫工具 Prometheus，不僅在進行持續改進，而且其使用率也獲 得了一些提升。PROMETHEUS主要支持基於“拉動” 的HTTP模型，同時也能支持告警，這令其能夠成為運維 工具箱中經常得到使用的工具。在本期技術雷達編撰過 程中，Prometheus 2.0正處於預發布階段，並且還在不 斷演進。Prometheus的開發者們正專註於核心時序數 據庫以及各種可用的度量指標之上。對於Prometheus 用戶來說，Grafana已成為首選的儀表板可視化工具，且 可以購買該工具的技術支持服務。我們的技術團隊還發 現，Prometheus在索引和搜索能力上能夠作為Elastic Stack很好的補充。

APEX是一個能夠輕松構建、部署和管理AWS Lambda 函 數的工具。有了Apex，就能使用AWS尚未原生支持的包括 Golang、Rust等在內的編程語言來編寫函數。這一點是通過 Node.js shim來實現的。它會創建一個子進程，並通過標準 輸入和輸出來處理各種事件。Apex還有很多不錯的特性，可 以改善開發者的體驗。我們特別欣賞它能在本地測試函數 的能力，以及在將變更運用到AWS資源之前能對其進行預 演的能力。

ASSERTJ-SWAGGER 是一個 AssertJ 工具庫，能夠用來驗 證API的實現是否符合其契約規格。當 API 端點的實現發生 了更改但未更新其 Swagger 規格，或未能發布更新後的文 檔時，我們的團隊就能通過使用 assertj-swagger 來捕獲這 些問題。

修復 CI 上失敗的端到端自動化測試會是一段痛苦的經歷， 尤其是在 headless 模式下。而CYPRESS是一個很有用的 工具，它能幫助開發人員輕易地構建端到端自動化測試，並且把測試的步驟錄制在一個 MP4 文件裏。這使得開發者可 以通過查看測試視頻來修復測試，而不是在headless模式 下去重現問題。Cypress 不僅是一個測試框架，更是一個強 大的測試平臺。當前我們已經把其 CLI 集成到了我們項目的 headless CI 裏。

FLOW是一個針對 Javascript 的靜態類型檢查工具，它可 以為整個代碼庫逐步增加類型檢查。不同於通過定義另一 種語言來實現靜態類型檢查的 Typescript 語言，Flow 可以 被逐步添加到支持 ECMAScript 第5、第6 以及 第7版的已有 Javascript 代碼庫中。我們建議把 Flow 添加到持續集成部 署流水線中，並從最關註的代碼開始做靜態類型檢查。使用 Flow 能使代碼更清晰，重構更可靠，並在構建過程的早期 就捕獲到類型相關的代碼缺陷。

過去幾年間，我們註意到分析筆記本應用（analy tics notebooks）的流行度在持續上升。這些應用都是從 Mathematica應用中獲得靈感，能夠將文本、數據可 視化和代碼活靈活現地融入到一個具備計算能力的文檔 中。在上個版本的技術雷達中我們所提到的基於Clojure 的GorillaREPL，就屬於此類工具。但隨著人們對機器 學習的興趣不斷增加，以及該領域中的從業者們逐漸將 Python作為首選編程語言，大家開始集中關註Python分 析筆記本了。其中JUPYTER看起來在ThougthWorks團隊 中格外引人註目。

Kong是一個由Mashape公司搭建和支持的開源API網關。該 公司也提供企業級產品，來將Kong與其專有的 API 分析和開 發者門戶工具相結合。它們能以各種配置進行部署，來作為 邊緣API網關或內部 API 代理。Kong 所基於的 OpenResty 通過其Nginx模塊和用於擴展的Lua插件，為其強大和高效 的功能奠定了基礎。Kong 既可以使用PostgreSQL進行單一 區域部署，也可以使用 Cassandra 進行多區域配置。我們的 開發人員已經享受到 Kong 的高性能、API 優先的方式 （能使其配置自動化）以及易於容器化部署的種種好處。不 像過度龐大的API網關那樣，KONG API 網關只擁有更少的 功能，但實現了關鍵的API網關功能，如流量控制、安全性、 日誌記錄、監控和身份驗證。 我們很高興能在不久的將來 以一個 sidecar 配置的方式對 Kong 進行評估。

KOPS是用於在生產環境上創建和管理高可用性 Kubernetes集群的命令行工具。 最初它針對AWS，但現在 已經對其他供應商提供了試驗性支持。它可以快速地啟動並 運行。雖然某些功能（如滾動升級）尚未開發完畢，但其社 區令人印象深刻。

谷歌編寫的LIGHTHOUSE工具可用於評估Web應用程 序是否遵守Progressive Web App標準。今年，新發布的 Lighthouse 2.0 向其基本工具集中新增了性能指標和可訪 問性檢查這些功能。這些新增功能現在已經被納入 Chrome 標準開發者工具的 audit 選項卡下。Lighthouse 2.0 也是 Chrome headless 模式的另一個受益者。 鑒於該工具可以 由命令行直接執行，或作為Node.js應用程序獨立運行，因此 Pa11y及類似工具提供了一種能在持續集成流水線中運行可 訪問性檢查的替代方案。

JavaScript Web 富應用的一個老問題是如 何使這些頁面的動態渲染部分可供搜索引擎 檢索。無法渲染JavaScript的爬蟲機器人可 以被路由到Rendertron服務器來進行渲染。 （Rendertron）

JavaScript Web 富應用的一個老問題是如何使這些頁面 的動態渲染部分可供搜索引擎檢索。為此開發人員采用了 各種各樣的技巧，包括使用React.js的服務端渲染，外部服 務或預渲染內容。現在谷歌 Chrome 新的 headless 模式 又貢獻了一個新的技巧—— RENDERTRON，即 Chrome 的headless 渲染解決方案。它在一個 Docker 容器中封裝 了一個 headless 的 Chrome 實例，可以作為獨立的HTTP 服務器來部署。無法渲染JavaScript的爬蟲機器人可以被 路由到此服務器來進行渲染。 雖然開發人員也可以部署 自己的 headless Chrome代理並配置相關的路由機制，但 Rendertron 簡化了配置和部署過程，並提供了令爬蟲機器 人進行檢測和路由的中間件示例代碼。

SONOBUOY是一個以非破壞性的方式在任何Kubernetes 群集上運行端到端“合規性測試”的診斷工具。由兩位 Kubernetes項目發起者創辦的Heptio公司的團隊構建了這 個工具，來確保各種Kubernetes發行版和配置都符合最佳 實踐，同時遵循開源標準化原則以實現集群互操作性。我們 正在嘗試使用Sonobouy作為“基礎設施即代碼”構建流水 線的一部分，並對Kubernetes安裝進行持續監控，以驗證整 個集群的行為和健康狀況。

如果用Spring框架來實現Java服務，那麽可以考慮用 SPRING CLOUD CONTRACT來進行消費者驅動的契約測 試。目前，該工具的生態系統支持根據契約來驗證客戶端的 調用以及服務器端的實現。與Pact （一個開源的消費者驅 動契約測試工具集）相比，它不支持契約代理，也不支持其它編程語言。不過它能與Spring生態系統完美集成，比如使 用Spring Integration進行消息路由。

關於語言和框架：

內容解讀：

在往期的雷達中，我們不確定是否應該強烈推薦 ANGULAR，因為從本質上來說，它是一個新的、整體上 沒那麽讓人興奮的框架，僅僅是和那個我們曾經喜愛過 的 AngularJS 同名而已。目前已經進化到第5個版本的 Angular，在提供向後兼容性的同時，有了穩定的改進。我 們的一些團隊已經在生產環境上應用 Augular，他們很滿 意最終的效果。基於這個原因，在這一期雷達中，我們把 Angular 移到了“試驗”階段，來表示我們的一些團隊現在 把它當作不二之選。然而我們的大多數團隊，仍然會更傾向 於選擇React, Vue 或者Ember。

ASSERTJ是一個提供流式斷言接口的Java庫，可以很容易 在測試代碼中傳達測試的意圖。AssertJ提供了可讀的錯誤 信息、軟斷言以及改進過的對集合和異常支持。我們看到一 些團隊默認選擇使用它，而不是JUnit和Hamcrest組合。

CSS網絡布局（CSS Grid Layout）是一個二維（two-dimensional）的基於網格的布局系統, 它所提供的機制使用了一組可預測的尺寸調整行為，將布局的可用空間劃分為行和列

即使CSS沒有為創建布局提供明確的支持，但它依然是 網頁布局的首選。Flexbox提供了更簡單的，一維（onedimensional）的布局, 但開發人員通常還是會采用一些 庫和工具包實現更復雜的布局。CSS網格布局（CSS Grid Layout）是一個二維（two-dimensional）的基於網格的布局 系統, 它所提供的機制使用了一組可預測的尺寸調整行為， 將布局的可用空間劃分為行和列。它不需要任何額外的庫, 並能與Flexbox和其他CSS元素集成得很好。然而, 由於IE11 僅支持其部分規範, 所以目前仍然依賴 Windows 7上IE瀏覽 器的用戶需求會被忽略。

大多數大型CSS代碼庫都需要復雜的命名機制來避免全局 命名空間中的沖突。CSS MODULES通過為每個CSS文件中 的所有class創建局部作用域來解決這些問題。當這個文件 被導入到一個JavaScript模塊，其中的CSS class可以通過名 稱字符串來引用。然後，在構建工具（Webpack，Browserify 等）中，class名稱被替換為自動生成的全局唯一字符串。這 是一個重大的職責轉換。以前，人們不得不通過管理全局命 名空間來避免class命名沖突的問題，現在這個職責移交給 構建工具。我們在CSS Modules遇到了一點小麻煩：功能測 試經常會超出局部作用域，因此不能通過CSS文件中定義的 名稱來引用class。針對這個問題，我們建議使用ID或是data 屬性作為替代方案。

Jest是一個“零配置”的前端測試工具，具有 諸如模擬和代碼覆蓋之類的開箱即用特性， 主要用於React和其他JavaScript框架。

我們團隊對采用JEST做前端測試的結果非常滿意。它提 供了一種“零配置”的開發體驗，並具備諸多開箱即用的功 能，比如 mock 和代碼覆蓋率。你不僅可以將此測試框架 應用於React.js應用程序，也可以應用於其他 JavaScript 框 架。Jest 經常被誇大的特性之一是 UI 快照測試。快照測試 可以作為測試金字塔上層一個很好的補充，但請記住，單元 測試仍然是堅實的基礎。

Jest系列教程

對Android的完美支持為迅速發展的KOTLIN語言提供了 額外的推動力，我們也正在密切關註Kotlin / Native（基於LLVM，可以將Kotlin代碼編譯為原生可執行文件）的進展。在 使用Anko庫開發Android應用時，我們已經嘗到了空指針安 全、數據類和易於構建DSL的甜頭。盡管初始編譯速度慢， 且只有IntelliJ才提供一流的IDE支持，但我們仍然建議嘗試 一下這種新穎簡潔的現代語言。

SPRING CLOUD在持續演進的過程中增加了許多有趣的 新特性。例如在spring-cloud-streams項目中，對Kafka Streams綁定的支持讓采用Kafka和RabbitMQ通過連接 器構建消息驅動的應用變得相對容易。正在使用該特性的 ThoughtWorks的團隊都認同它能在使用像Zookeeper這樣 的復雜基礎設施時提供便捷性，也對構建分布式系統時需 要解決的常見問題提供支持，例如使用spring-cloud-sleuth 進行跟蹤。目前我們已成功將它應用在多個項目中，不過大家仍然需要註意其適用場景。

一直以來，Google的Android文檔實例缺乏架構和結構。 隨著ANDROID架構組件的發布，這種狀況有所改善，這 是一組有主見的庫，它們幫助開發者用更好的架構創建 Android 應用程序。 它們解決了Android開發的長期痛點： 處理生命周期，分頁，SQLite數據庫以及配置變更時的數據 持久化。這些庫無須一起使用，你可以選擇最需要的集成到 現有項目中。

我們在移動增強現實中看到了很多令人激動的活動，其中 大部分來自ARKIT（Apple提供的原生AR庫）/ARCORE （Google提供的原生AR庫）的加持。 這些庫將移動AR技術 帶入主流，讓後者得到大量采用。盡管如此，各大公司在尋 找真實的用戶場景（而非一些花哨的Demo）和真正增強用 戶體驗的解決方案方面還是面臨挑戰。

多應用策略備受爭議，尤其現在越來越少的用戶願意再下 載新的應用程序。不同於推出一個新的應用然後為下載量 而努力，許多團隊必須通過一個已經被廣泛安裝的應用來 發布新的功能，這給應用程序的架構帶來了挑戰。ATLAS 和BEEHIVE是分別用於Android和iOS的模塊化解決方案。 它們能讓多個團隊工作於物理隔離的不同模塊，並且從一 個門面應用中重新組裝或者動態加載這些模塊。它們都是 Alibaba的開源項目，因為Alibaba也曾面臨同樣的下載量減 少和單個應用架構挑戰的問題。

“你並不需要一個規則引擎”，這常常是選擇規則引擎時的 首要法則，因為我們已經見到太多的人基於一些臆想的理 由，將自己綁定在難以測試的黑盒的的規則引擎上——原本 定制化應該是更好的解決方案。雖說如此，在一些規則引擎 確實適用的場合，我們采用 CLARA RULES 取得了很好的 成功。不同於其他的規則引擎，它使用簡單的 Clojure 代碼 來表達和執行規則，這意味著規則可以被很好地重構、測試 和版本化。比起追求“業務人員可以直接編輯業務規則”的 錯覺，Clara Rules 能夠很好地驅動業務專家和開發人員之 間的合作。

CSS IN JS是一種用JavaScript編寫CSS樣式的技術，通 過鼓勵采用一種通用模式，編寫樣式以及應用樣式的 JavaScript組件，使樣式和邏輯的關註點得到統一。該領域 中的新秀——諸如JSS，emotion和styled-components，依 靠工具來將CSS-in-JS代碼轉化成獨立的CSS樣式表，從而 適合在瀏覽器裏運行。這是在JavaScript中編寫CSS的第二 代方法，與以前的方法不同，它不依賴於內聯樣式，這意味 著它能支持所有CSS特性，使用npm生態共享CSS以及跨 平臺使用組件。我們的團隊發現styled-components很適 合像React這樣基於組件的框架，並且可以使用jest-styledcomponents做CSS的單元測試。這是個新興的領域且變化 迅速。用該方法時，在瀏覽器裏人工調試生成的class名稱會 需要費些功夫，並且可能不適用於那些前端架構不支持重用 組件並需要全局樣式的項目。

DIGDAG是一個在雲中構建、運行、調度和監控復雜數據管 道的工具。你可以使用豐富的開箱即用操作符在YAML中定 義這些管道，也可以通過API構建屬於自己的管道。Digdag 具有數據管道解決方案中的大多數常見功能，例如依賴關 系管理、易於復用的模塊化工作流、安全的密碼管理和多語 言支持。我們最感興趣的功能是它對多種雲平臺的支持，這 允許你通過AWS RedShift，S3和Google BigQuery等服務來 移動和連接數據。隨著越來越多的雲提供商提供相互競爭 的數據處理解決方案，我們認為Digdag（以及類似的工具） 是充分利用這些平臺的最佳選擇。

DRUID是一個具有豐富的監控特性的JDBC連接池。它有一 個內置的SQL解析器，提供了對數據庫中執行的SQL語句語 義級別的監控。註入或可疑的SQL語句將被攔截，並直接在 JDBC層記錄下來。查詢也可以基於它們的語義進行合並。 這是一個阿裏巴巴開源的項目，它反映了阿裏巴巴從自己的 數據庫系統中學到的教訓。

Android架構組件是一組有主見的類庫，能 夠幫助開發者用更好的架構創建 Android 應用程序。 (Android架構組件)

ECHARTS是一個輕量級的圖表庫，對不同類型的圖表和交 互有豐富的支持。ECharts完全基於Canvas API，因此即使 處理100k +數據點也具有令人難以置信的性能，並且還針對 移動用戶進行了優化。 憑借其擴展項目ECharts-X，它還可 以支持3D繪圖。ECharts 是一個百度開源項目。

Go語言能夠被編譯為裸片上運行的目標程序，這使得嵌入 式系統開發領域對它的興趣與日俱增 。GOBOT是一個用於 機器人、物理計算和物聯網(IoT)的框架，它基於Go語言編 寫，並且支持多個平臺。我們在一個對實時性響應沒有要求 的實驗性機器人項目中使用了GoBot，並且用GoBot創建了 開源的軟件驅動。GoBot的HTTP API使其與移動設備的集 成十分容易，從而能創建更豐富的應用。

ThoughtWorks的許多移動開發團隊對一款可以檢測 Android和Java中令人討厭的內存泄漏工具LEAKCANARY 感到非常興奮。LeakCanary與App集成非常簡單，同時它也 提供能夠清晰回溯內存泄漏原因的通知。把它加到你的工 具包，它可以幫你節省在多個設備上排查內存泄漏的時間。

PYTORCH是Lua機器學習框架Torch在Python語言下的 完整重寫版。比起Tensorflow，它還很新不夠成熟，但在 程序員的眼裏它卻很好用。 因其面向對象的特性和原生 的Python實現，模型可以表達得更加清晰簡潔，並可以 在執行過程中調試。盡管最近湧現出了許多這類框架，但 PyTorch擁有Facebook和廣泛合作夥伴的支持，包括應該 會繼續支持CUDA架構的NVIDIA。ThoughtWorks的團隊發 現，PyTorch在模型的設計開發及試驗階段擁有著明顯的 優勢，但在大規模的生產環境中的訓練及實現仍然離不開 TensorFlow。

SINGLE-SPA是一個JavaScript元框架，它允許我們使用 不同的框架構建微前端，而這些框架可以共存於單個應用 中。 一般來說，我們不建議在單個應用中使用多個框架， 但有時卻不得不這麽做。 例如當你在開發遺留系統時，你 希望使用現有框架的新版本或完全不同的框架來開發新功 能，single-spa就能派上用場了。鑒於很多JavaScript框架都 曇花一現，我們需要一個解決方案來應對未來框架的變化， 以及在不影響整個應用的前提下進行局部嘗試。在這個方向 上，single-spa是一個不錯的開始。

智能合約編程需要一種比交易處理腳本更具表現力的語 言。在眾多為智能合約設計的新編程語言中，SOLIDITY是最受歡迎的。這是一種面向合約的靜態類型語言，其語法類似於JavaScript。 它抽象了智能合約中自我實現的業務邏輯。圍繞Solidity的工具鏈也在快速成長。如今，Solidity是 Ethereum平臺的首選編程語言。鑒於已部署智能合約的不 可變性，對依賴的嚴格測試和審計是至關重要的。

TENSORFLOW MOBILE使開發人員可以將各種理解和分 類技術融入其iOS或Android應用程序。 考慮到手機上可用 的傳感器數量及其可收集的數據範圍，這一點尤其有用。預先訓練好的TensorFlow模型可以加載到移動應用程序 中，並應用於實時視頻幀，文本，語音等輸入的處理中。手機 為實現這些計算模型提供了一個令人驚訝的合適的平臺。 TensorFlow模型導出和加載的文件格式都是protobuf文件， 這可能會為實現者帶來一些問題。 Protobuf的二進制格式 讓檢查模型很難，並要求你將正確的protobuf庫版本鏈接到 移動應用程序。但是，本地模型的執行，提供了一個很有吸 引力的針對TensorFlow Serving的替代方案，這可以節省遠 程執行的通信開銷。

我們在適合規則引擎的場景采用 Clara Rules 取得了很好的成功。我們喜歡通過它 用簡單的 Clojure 代碼來表達和執行規則， 這意味著規則可以被很好地重構、測試和版 本化。 (Clara rules)

TRUFFLE是一個開發框架。它將現代化的 Web 開發體驗 帶到了Ethereum平臺。Truffle 接管了智能合約編譯、庫鏈 接和部署，以及在不同區塊鏈網絡中處理制品的工作。我 們喜愛 Truffle 的原因之一就是它鼓勵開發者為智能合約編 寫測試。這一點非常值得重視，因為智能合約的編寫通常 涉及到金錢。得益於其內置的測試框架以及與TestRPC 的 集成，Truffle 可以允許我們使用 TDD 的方式來編寫智能合 約。我們期望出現更多像 Truffle 的技術能促進在區塊鏈領 域中的持續集成實踐。

WEEX是一套跨平臺移動應用開發方案，采用了Vue.js的組 件化語法。對於那些偏愛Vue.js簡潔性的開發者，Weex是 一個開發原生移動應用切實可行的選擇，但同時也能勝任 非常復雜的應用。已經有大量的復雜的應用構建於Weex框 架，其中包括中國最流行的兩款移動應用程序——天貓和淘 寶。Weex最初由阿裏巴巴開發，目前是Apache孵化項目。

寫在最後：

關於技術雷達可訪問thoughtworks官網獲取最新，也可添加訂閱：https://www.thoughtworks.com/cn/radar

ThoughtWorks 2017技術雷達