ThoughtWorks 2017技術雷達

前言：

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 第五、第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