2019年TW的技术雷达
18年的開始了解TW公司，看到在2018年11月發布的技術雷達，感覺和自己一直以來想做的事情是非常相關，就是在不斷地構建自己的知識技能圖譜，能夠在未來清晰的看到自己的技術路線。 未來彌補個人視角的技術局限性，所以TW的技術雷達從多個優秀的項目中總結而來，對比于TW的技術雷達路線，我覺得對自己（或者說是每個互聯網的技術人員），都是非常的具有指導性的。
TW 從全球技術熱點技術出發，從多個角度解讀現有的一些熱門技術。敏感的捕捉技術發展中的一些變化，并且圖形化的展示出來。TW 的全球軟件開發視角，無疑給我們帶來了一個全新的技術觀視角。
就如技術雷達的出發點：洞察構建未來的的技術和趨勢
先打一個預防針，技術雷達只是一個增加了解技術視角的方式，而不應該被視為絕對的圣經。
TW 從技術、工具、平臺、語言&框架 四個象限來解讀
技術雷達持續更新網址 https://www.thoughtworks.com/cn/radar
- 采用：強烈建議采用的技術，如何適合項目使用，毫不猶豫的采用。
- 實驗：值得追求，重要的是如何理解這種能力。企業應該在風險可控的項目中嘗試這種技。
- 評估：值得研究一番的技術，以確認它將對你產生何種影響。你應該投入一些精力來確定，它是否會對你所在的組織產生影響。
- 暫緩：別用這項技術啟動任何新項目。在已有項目上使用它沒有壞處，但是想在新開發的項目上使用這個技術的話需要三思而行。
圖中的三角形圖標表示新出現的位置出現了_顯著變化的條目_。圖形表示還沒有發生變化的部分。
技術雷達中的技術很多是在原有雷達上比較的，很多技術也很重要，但是新技術出現很多，為了避免新老技術標記混亂，所以將很多沒有發生變化的老技術在技術雷達上給省略了標記。
技術雷達的英文版鏈接 https://www.thoughtworks.com/cn/radar/techniques
技術
以下部分為強烈建議在項目中采用的技術
快速市場響應能力是組織進行微服務轉型的主要驅動之一。然而只有沿長期業務領域邊界對服務（及其支持團隊）進行清晰劃分時，這種期望才可能實現。否則，現實需求只有在跨組織和跨服務的通力合作才下能完成，這自然會在規劃產品路線圖時產生沖突。良好的領域模型設計是解決此問題的方案，**事件風暴（EVENT STORMING）**也迅速成為我們最喜愛的方法之一，它使我們能夠迅速識別問題領
域中的關鍵概念，并用最好的方式與各方利益相關人制定解決方案。
以下部分為強烈建議在項目中嘗試的技術
快速反饋是我們構建軟件的核心價值之一。很多年來，我們使用金絲雀發布來鼓勵對于新版本軟件要盡早反饋，同時對選定用戶做增量發布以降低風險。與這個技術相關的問題之一就是如何劃分用戶。對非常小的一部分用戶（比如1%）作金絲雀發布是變更的催化劑。從一小部分用戶開始可以讓團隊逐漸熟悉這項技術，而快速捕獲用戶反饋可以讓不同團隊觀察新發布的影響，從中學習并按照需要調整方向——這是工程師文化里很寶貴的變化。我們稱之為萬能的1% 金絲雀（1% CANARY）。
大多數沒有足夠資源進行軟件定制化開發的組織，通常會選擇一些“開箱即用”的或基于SaaS平臺的解決方案來直接滿足需求。但是最近我們注意到，這些解決方案的范圍正在急劇擴張，與業務的各個環節糾纏在一起。這種擴張模糊了集成邊界，導致越來越難以估計軟件變更的復雜度，變更速度也越來越慢。為了降低這種風險，我們建議這些組織首先要設計出清晰的目標能力模型，然后使用被稱為限界購買的策略(BOUNDED BUY)，即只選擇模塊化、解耦的，且只包含于單一業務能力（Business Capability）的 限界上下文（Bounded Context）中的廠商產品。我們應該將這種對模塊化和獨立交付能力的要求，加入對供應商選擇的驗收標準中去。
對敏感數據保持適當的控制是相當困難的，尤其是在出于對數據備份和恢復的目的而將數據復制到主數據系統之外的時候。**密鑰粉碎（CRYPTO SHREDDING）**是通過故意覆蓋或刪除用于保護該數據的加密密鑰來使敏感數據無法讀取的做法。例如，可以使用隨機密鑰對數據庫中客戶個人詳細信息表的所有記錄進行一對一加密，然后使用另一張表來存儲密鑰。如果客戶行使了“被遺忘的權利”，我們可以簡單地刪除相應的密鑰，從而有效地“粉碎”加密數據。 當我們有信心對小規模加密密鑰集合維持適當控制，但對較大數據集的控制信心不足時，此項技術非常有效。
2014年首次發布的DevOps狀態報告指出，高效團隊創造了高效的組織。最近，該報告背后的團隊編寫了Accelerate一書，描述了他們在報告中使用的科學方法。兩份材料的核心點都支持了軟件交付性能的四個關鍵指標（FOUR KEYMETRICS）：前置時間，部署頻率，平均恢復時間（MTTR）和變更失敗百分比。作為幫助許多組織轉型的咨詢公司，反復使用這些指標測量，可以幫助組織確定他們是否在提高整體效能。每個指標都創造了一個良性循環，并使團隊專注于持續改進：縮短交付周期，減少浪費的活動，從而使你可以更頻繁地部署；部署頻率迫使你的團隊改進他們的實踐和自動化流程；通過更好的實踐，自動化和監控可以提高你從故障中恢復的速度，從而降低故障頻率。
自助使用、按需付費是當代云計算重要的特性（和優勢）。但是，當使用單個賬號去部署大規模的服務時，事情就變得非常復雜。我們必須為該賬戶設置使用規則和流程，往往這些流程包含大量的審批步驟，從而降低我們的效率。設置**多云賬號（MULTI-ACCOUNT CLOUD SETUP）**是一個不錯的方案，我們可以申請多個賬號，并且為每個團隊指定一個賬號。當然這個方案增加了其他方面的復雜度，例如共享計費、不同 VPC 之間的通信、與云供應的關系管理等。但是，也會提高我們的開發效率與安全性，審計只用于單服務的賬號相對容易，在發生數據泄漏時，我們所受到的影響也相對較小。設置多云賬號可以降低我們對云供應商的粘性，因為單服務賬號能提供清晰的邊界，所以便于整體遷移到另一個云提供商。
可觀測性是運轉分布式系統與微服務架構必不可少的一部分。我們依賴不同的系統輸出來推斷分布式組件的內部狀態，比如分布式追蹤、日志聚合、系統指標等，進而診斷問題所在，并找到根本原因。可觀測性生態系統的一個重要方面就是監控——可視化以及分析系統的輸出——并且在檢測到異常時報警。傳統的監控報警配置，都是通過圖形界面的操作完成。這種方法導致控制面板頁的配置不可重復，從而無法持續測試和調整報警，來避免報警疲勞或錯過重要的報警，進而偏離組織的最佳實踐。我們強烈建議使用代碼來配置可觀測性生態系統，稱為可觀測性即代碼（OBSERVABILITY AS CODE），并且采取基礎設施即代碼的方式搭建其基礎設施。因此，在選擇提供可觀測性的工具時，要選擇支持通過代碼版本控制進行配置，并能通過基礎設施持續交付流水線執行API或命令行的產品。可觀測性即代碼，是基礎設施即代碼中經常被遺漏的一部分，我們認為這一點非常重要，需要明確指出。
通常，為了將風險外包給供應商，企業在其最關鍵和風險最高的系統上往往鎖定某個特定供應商，以求風險最低。不幸的是，這會讓企業可以選擇的解決方案變得更少，靈活性也更低。相反，企業應該在業務風險最高的地方保持最大的供應商獨立性。我們看到一種新的**風險相稱的供應商策略（RISK-COMMENSURATE VENDOR STRATEGY）**正在興起，它鼓勵在高度關鍵系統中維持其供應商的獨立性。而那些相對不太重要的業務可以利用供應商提供的成熟解決方案，這可以讓企業更容易承受失去該供應商所帶來的影響。隨著主流云提供商擴展其服務范圍，這種權衡變得愈發重要。例如，在開發工作開始時，使用AWS SecretManagement Service可以提高效率，并且還有易于集成AWS云生態的好處。但相比于自己實現密鑰管理解決方案，例如使用Vault時，AWS的方案難以遷移到不同的云供應商。
隨著軟件架構及其業務的演進，我們理應密切關注應用的運行成本，但發現并非所有的組織都如此。尤其是在使用無服務器架構時，開發者們認為無服務器架構會更便宜，因為他們只需按消耗的計算時間付費。然而幾家主要的云服務提供商在熱門的無服務器函數上定價十分精明，雖然無服務器在快速迭代上很有優勢，但與專屬云（或內部私有云）相比，它的開銷可能隨著使用量迅速增長。我們建議團隊將**應用的運行成本納入架構適應度函數（RUN COST ASARCHITECTURE FITNESS FUNCTION）**來考量，這意味著：追蹤并權衡應用的運行成本與交付價值；當它們之間產生較大出入時，就需要考慮改進軟件架構了。
我們長期以來都警示人們，要抵制在代碼倉庫中保存密鑰信息的誘惑。在往期雷達中，我們曾推薦了將代碼和密鑰管理解耦，但如今我們發現了一系列提**供密鑰即服務（SECRETS AS A SERVICE）**的好工具。通過這些工具，系統能夠從外部服務中獲取秘密信息，而不是使用硬編碼或將其配置在運行環境中的方式。例如來自HashiCorp的Vault這樣的工具幫助你將密鑰與應用程序分開管理，同時有助于你強制實施一些安全政策，例如周期性密鑰輪換。
雖然在本期雷達中大部分條目都是全新的，但我們認為依然值得繼續為**安全混沌工程（SECURITY CHAOSENGINEERING）**的實用性提名。本期雷達中我們將其移動到了試用階段，因為使用此技術的團隊確信他們的安全策略足以應對常見的安全故障模式。不過，在使用這種技術時需要謹慎，我們不希望我們的團隊對安全問題變得不再敏感。
當涉及到大規模數據分析或機器智能問題，基于不同數據集合和參數進行可重復性分析就變得非常有價值。為了實現可重復性分析，數據和模型（包括算法方案，參數和超參數）需要進入版本控制。因為數據量的緣故，**可重復性分析的版本化數據（VERSIONING DATA FORREPRODUCIBLE ANALYTICS）**比起版本化模型更加棘手。一些像DVC這樣的工具采用類似git工作流的方式，讓用戶提交和推送數據文件到遠程的云存儲，從而實現數據的版本化。這極大方便了協作者拉取特定版本的數據來進行可重復性分析。
以下部分為強烈建議在項目中評估的技術
CHAOS KATAS是一項為基礎設施和平臺工程師提供技能培訓和提升的技術。它將Kata的方法論與ChaosEngineering的相關技術（具體指在受控環境中模擬故障和停機）進行結合，對工程師進行系統化教學和培訓。這里的Kata是指觸發受控故障的代碼模式，它允許工程師發現問題，恢復故障，開展事后分析并找到根本原因。工程師通過重復執行Kata能幫助他們真正掌握新的技能。
當為我們的應用構建Docker鏡像的時候，我們常常會考慮兩件事情：鏡像的安全性和大小。通常情況下我們使用容器安全掃描工具來檢測和修復常見的漏洞和風險 ，以及使用Alpine Linux來解決鏡像大小和分發性能問題。在此期雷達中，我們欣喜地發現了一個由Google開發，用來解決容器安全性和大小問題的技術，名叫DISTROLESS DOCKERIMAGES。通過這項技術，鏡像占用的空間只包含應用本身以及它的資源和語言運行時依賴，而不包含操作系統。它的優勢包括減少其它因素對應用安全掃描的干擾、減小安全攻擊面、降低漏洞修復開銷，以及減小鏡像大小以獲得更高性能。Google 已經為不同的語言發布了一系列的distroless容器鏡像。你可以通過 Google 的構建工具Bazel來創建distroless 應用鏡像，它支持使用Distroless的語法規則或者簡單地采用多階段Dockerfiles的方式來創建Distroless 容器。值得注意的是 Distroless 容器默認情況下不提供 shell來進行調試，但你能很方便地在網上找到包含 busyboxshell 的 distroless 容器可調試版本。
作為敏捷領域的先驅和領導者，ThoughtWorks一直以實際行動踐行增量交付實踐，同時建議我們的客戶從“增量交付”的視角來審視他們已有的軟件。但是這個過程通常很困難，因為大多數供應商都采用一次性交付的方式，這就會涉及到大量的數據遷移。然而最近我們成功的實踐了與供應商一起增量交付(INCREMENTAL DELIVERY WITH COTS(commercial off-the-shelf))，以增量的方式向較小的用戶群發布特定的業務流程。我們建議您評估是否可以將此實踐應用于您選擇的供應商軟件，以幫助減少一次性交付的風險。
很長時間以來，我們一直在建議交付團隊對整個技術棧負責，其中也包括對基礎設施負責。 這意味著，在以安全可靠、合規的方式配置基礎設施這方面，交付團隊需要承擔起 更多的責任。 為了降低風險，采用云策略時大多數組織都 默認采用嚴格的、集中式的配置管理方式，但這也導致了嚴重的生產力瓶頸。 另外一種做法則是允許團隊自己管理自己的配置，并使用INFRASTRUCTURE CONFIGURATIONSCANNER這種方式來確保配置的安全性。Watchmen是個很有意思的工具，它旨在為由交付團隊自主擁有和運營AWS 賬戶配置提供基于規則驅動的掃描。Scout2是另一個配置掃描的例子，它可以提供安全合規的支持。
在更復雜的架構和部署中，可能并不能容易立即發現某個依賴正在檢入的代碼的構建已經損壞。開發人員在嘗試修復已損壞的構建時，會發現自己就像在打移動靶，因為該構建會不斷被其上游依賴所觸發。下游構建的提交前檢查（PRE-COMMIT DOWNSTREAM BUILD CHECKS） 是一個很簡單的技術：用一個提交前（pre-commit）或推送前（pre-push）腳本來檢查這些下游構建的狀態，并事先警告開發人員某個構建已經壞掉了。
隨著大型組織向擁有和運營自己的微服務的更自主的團隊過渡，他們如何在不依賴集中托管基礎架構的情況下確保這些服務之間的必要一致性和兼容性？為了有效地協同工作，即使是自主的微服務也需要與一些組織標準保持一致。SERVICE MESH 提供一致的發現、安全性、跟蹤、監控和故障處理，而無需共享API網關或ESB等設施。典型的實現是將每個服務進程和輕量級反向代理進程一起部署，反向代理進程可能在單獨的容器中。這些代理與服務注冊表，身份提供者，日志聚合器和其他服務進行通信。服務互操作性和可觀測性是通過此代理的共享實現而不是共享運行時實例獲得的。我們提倡采用去中心化的微服務管理方法已經有一段時間了，并很高興看到這種一致模式的出現。Linkerd 和 Istio 等開源項目將逐步成熟，這使得service mesh 更容易實現。
當組織選擇 vanilla Hadoop 或Spark 發行版而不是某個供應商的發行版時，他們必須決定如何配置和管理集群。 有時，我們會看到使用配置管理工具進行**“手搖式”啟動的 Hadoop 集群（“HANDCRANKING” OF HADOOPCLUSTERS USING CONFIG MANAGEMENT TOOLS）**，這些工具有 Ansible ， Chef 等。 雖然這些工具非常適合整備不可變的基礎設施組件，但是對于管理有狀態的系統，它們并不太管用，而且嘗試使用這些工具管理和演進集群通常會導致大量的工作。所以，我們建議使用 Ambari 等工具來配置和管理有狀態的Hadoop或Spark群集。
主流云供應商在定價和快速發布新特性方面的競爭日益激烈，這使得消費者難以抉擇和保持粘性。我們越來越多地看到組織準備使用“任意云”，并不惜一切代價避免被單一供應商鎖定。當然，這就導致了只使用通用云服務功能（GENERIC CLOUD USAGE） 。我們發現，有的組織對云的使用僅限于所有供應商都有的特性，而忽略供應商提供的獨特能力；有的組織為了保持云無關性，斥巨資開發復雜且難以維護的抽象層。供應商鎖定的問題是真實存在的。對此，我們建議采用多云策略，評估從一個云到另一個云的功能遷移成本及工作量，抵制使用特定云特性的好處。我們推薦將應用程序置于廣泛采用的 Docker 容器中以提高工作負載的可移植性；使用開源的安全和身份協議以輕松遷移工作負載的身份；使用風險相稱的供應商策略，僅在必要時維持云獨立性；在合適之處使用 Polycloud 混合匹配不同供應商的服務。簡而言之，請用合理的多云策略，避免只使用通用云服務
微服務架構的一個顯著特征是系統組件和服務是圍繞業務能力進行組織的。無論系統規模大小，微服務都需要將系統功能和信息進行有意義的分組和封裝，以便拆分后的微服務能彼此獨立地交付業務價值。而以前的服務架構方式會根據技術特性組織服務。我們觀察過很多采用**分層式微服務架構（LAYERED MICROSERVICES ARCHITECTURE）**的組織，他們在某些方面存在著明顯的矛盾。這些組織都陷入了以技術角色為主來劃分服務的誤區，比如，用戶體驗API、進程 API 或系統 API等。我們會很自然地將技術團隊按層劃分，這會導致想要交付任何有價值的業務變更，都需要緩慢而昂貴的多團隊合作。請務必小心這種分層方式帶來的影響，我們更推薦根據業務能力來劃分服務和團隊。
主數據管理 (MASTER DATA MANAGEMENT (MDM)) 是一個典型的企業“銀彈”解決方案：它聲稱可以將表面上相關的問題一次性解決，但它創建集中的單點來進行統一的變更、協調、測試和部署，極大地降低了組織響應業務變化的能力。在將MDM方案集成到不同消費和生產系統的過程中，組織往往嘗試捕捉到所有的“主”數據并將它們映射到MDM中，這讓整個實施過程變得漫長而復雜。
微服務已成為現代云計算系統中的領先的架構模式，但我們依舊認為團隊在使用該架構時應謹慎。 MICROSERVICEENVY特指那些盲目追趕微服務潮流的現象，很多團隊在實踐微服務時并沒有簡化其系統架構，大多數的實踐方案只是將一些簡單的服務聚合在一起而已。目前， Kubernetes等平臺簡化了復雜的微服務系統的部署問題，其他服務提供商們也正在推進他們的微服務治理方案，這些強大的工具都可能裹挾團隊走上微服務之路。 但請千萬謹記，微服務是通過開發復雜度來換取運維復雜度，并需要自動化測試、持續交付和DevOps文化提供堅實的支撐。
我們經常看到在面向用戶的工作流中**使用請求 — 響應事件 (REQUEST-RESPONSE EVENTS IN USER-FACINGWORKFLOWS)**的系統設計。這樣一來，要么UI被阻塞，要么用戶就必須等頁面收到響應消息后重新加載。做出這類設計的主要依據往往是為了性能或是為了用統一的方式來處理后端之間的同步和異步通信。我們認為這樣做會在開發、測試和運維上所增加不必要的復雜度，遠遠超過了采用這種統一方式帶來的好處，我們強烈建議直接使用同步HTTP請求來處理后端服務之間的同步通信，而不必改成事件驅動的設計。如果做得好，使用HTTP通信很少會成為分布式系統的瓶頸
**機器人流程自動化（RPA）**是許多數字化轉型計劃的關鍵部分，因為它有望在不必對底層架構和系統進行現代化改造的情況下節省成本。 這種僅關注自動化業務流程而不解決底層軟件系統或功能的方法的問題在于，引入額外的耦合會使底層系統更改起來更加困難。 這也會讓未來任何解決遺留IT環境的嘗試都變得更加困難。 很少有系統能夠忽視變化，因此RPA的進展需要與適當的遺留系統現代化戰略相結合。
平臺
采用
試驗
隨著企業數據需求的不斷增長和多樣化，對元數據管理的需求也在不斷地增長。**APACHE ATLAS 是一款用于滿足企業數據治理需求的元數據管理框架。**Atlas支持元數據類型建模、數據資產分類、數據來源追蹤和數據發現。但是，在搭建元數據管理平臺的時候，我們也必須小心避免重蹈主數據管理的覆轍。
我們在7年前首次將AWS移到“采納”環，其服務的廣度、深度和可靠性從那時起就已獲得長足進步。然而，我們現在又將AWS移回“試驗”環。這不是因為其產品存在缺陷，而是因為其競爭對手。它的 GCP 和 Azure 這兩個競爭對手已經相當成熟，這使得選擇云提供商變得越來越復雜。 所以我們會把“采納”環留給該領域未來的大贏家。多年來，AWS一直是該領域的默認選擇。但是考慮到組織自身的地理位置和監管范圍，以及同云提供商之間戰略的一致性（或者缺乏一致性），當然還包括組織最重要的需求和云供應商差異化產品之間的契合度。所以，我們認為組織是時候應該在云供應商之間做出權衡了。
Microsoft已經在穩健地改進AZURE，如今大型云提供商Amazon、Google和Microsoft在核心云體驗上并沒有太大的差別。這些云提供商似乎都在追求其他方面的差異性，比如功能、服務和成本結構。Microsoft 對歐洲公司在法務上的需求表現出了真正的興趣。對此，他們有一個細致且合理的策略，比如提供了像Azure Germany和Azure Stack這樣各具特色的產品。這個策略為歐洲公司在預測GDPR
Headless CMS （Content Management Systems, 內容管理系統） 正在成為數字化平臺的常見組件。CONTENTFUL是一個現代化的 headless CMS。我們的團隊已經成功把它集成到開發工作流中。我們特別喜歡其“API 優先”的特點，及其CMS as Code的實現。它支持強大的內容建模原語代碼和內容模型演化腳本，并允許將其視為其他數據存儲的schema，并將演進式數據庫設計實踐應用到 CMS 開發中。我們所喜歡的其他特性包括：默認包含兩個 CDN以提供多媒體資源和 JSON文檔，本地化的良好支持和與Auth0集成的能力（盡管需要做出一些努力）。
隨著GOOGLE CLOUD PLATFORM (GCP)在可用地理區域和服務成熟度方面的擴展，全球的客戶在規劃云技術策略時可以認真考慮這個平臺了。與其主要競爭對手AmazonWeb Services相比，在某些領域， GCP 所具備的功能已經能與之相媲美。而在其他領域又不失特色—尤其是在可訪問的機器學習平臺、數據工程工具和可行的 “Kubernetes即服務解決方案”（GKE）這些方面。在實踐中，我們的團隊對GCP工具和API良好的開發者體驗也贊賞有嘉。
我們在大大小小的組織中積累了豐富的公共云經驗，一些公有云模式也隨之出現。其中一種模式是將組織級別管理的虛擬私有云，拆分為眾多較小的由團隊自治的子網。這個想法與設置多云賬號類似，它有助于將基礎設施按照團隊邊界進行分隔。**按照傳統的方式，我們需要反復為每個團隊配置VPC、子網、安全組和網絡訪問控制列表，與此相比，我們更推崇Google的共享VPC （SHARED VPC） 這一概念。共享VPC使組織、項目、VPC和子網成為網絡配置中的一級實體。**VPC可由組織的系統管理員管理，然后管理員可以將子網管理的權限委派給項目，項目與VPC中的子網一一對應。這樣的方式簡化配置，同時使安全性和訪問控制更加透明。
TICK Stack 是一些開源組件的組合。這些組件組合成了一個平臺，以便人們存儲、可視化和監控諸如指標和事件這樣的時間序列數據。這些組件包含了 Telegraf（用于收集和報告指標的服務器代理）、 InfluxDB（ 高性能的時間序列數據庫）、 Chronograf（提供平臺用戶界面），以及 Kapacitor（能對來自 InfluxDB 的數據進行處理、流傳輸和批處理操作的數據處理引擎）。與基于拉模式的 Prometheus 不同，該平臺是基于推模式來收集數據的。InfluxDB是該平臺的核心組件，它是目前最優秀的時間序列數據庫。該技術棧目前由InfluxData提供支持。雖然需要升級到該平臺的企業版才可以使用數據庫集群等功能，但將該平臺用做監控仍然是相當不錯的選擇。我們當前在一些生產環境中使用了這一技術棧，并獲得了很好的體驗。
評估
已取代 Visual Studio Team Services 的 AZURE DEVOPS服務，包括一組托管服務，如Git倉庫、CI和CD流水線以及制品庫等。當使用Azure DevOps服務快速啟動項目時（即在 Azure 平臺上管理、構建和發布應用程序），我們獲得了良好的體驗。 但同時也遇到了一些挑戰，如該平臺對CI和CD的“流水線即代碼”缺乏全面的支持，構建代理在啟動時速度很慢，構建和發布被分離到不同的流水線上來進行等，另外在使用該平臺時還遭遇了幾次停機。我們希望AzureDevOps服務能夠隨著時間的推移得以改進，以便為在Azure上托管應用程序的開發人員提供良好的體驗，并與其他 Azure 服務無縫集成。
COCKROACHDB是一個開源分布式數據庫，其設計思路源自白皮書Spanner：谷歌的分布式數據庫。在CockroachDB中，數據自動按照區間進行切分，通常以64MB為單位，被分布到集群中的不同節點上。每一個區間都有一個共識組。由于使用了Raft共識算法，所以這些數據總是能夠保持同步。憑借這種獨特的設計，CockroachDB提供分布式事務和地理分區的功能，并支持SQL。不像依賴TrueTime（用原子時鐘進行線性化）的 Spanner，CockroachDB使用 NTP 進行時鐘同步，并且提供序列化功能（作為默認隔離級別）。如果所處理的是適合單個節點的結構化數據，那么可以選擇傳統的關系型數據庫。但如果數據需要跨節點進行容量伸縮、保持一致并且能夠在系統故障時保存下來，那么我們建議可以仔細研究一下CockroachDB。
DEBEZIUM是一個change data capture (CDC)平臺，可以將數據庫的變更以流的形式傳入 Kafka 主題中。CDC是一種流行的技術，具有多個使用場景，包括將數據復制到其他數據庫中，為分析系統提供數據，從單塊系統中提取微服務，以及令緩存數據無效等。**我們一直在尋找這個領域的工具或平臺（包括在之前的技術雷達中討論過的 BottledWater），而 Debezium 是一個極佳的選擇。它使用了基于日志的CDC方法，意味著能以對數據庫日志文件的變更進行響應的方式進行工作。**Debezium使用了Kafka連接，這使得它具有高度的容量伸縮性，以及對故障的系統韌性。它擁有包括Postgres、Mysql和MongoDB在內的多個數據庫的CDC連接器。目前，我們正在一些項目上使用該平臺，并取得了很好的效果。
我們對 GLITCH 很感興趣。這是一個在線協作開發環境，允許用戶輕松復制和調整（或“重新混合”）現有的Web應用程序，或者創建自己的Web應用程序。該平臺源于“修補匠”精神，對于編程初學者是一個理想的選擇，同時也能夠支持更加復雜的應用的開發。它主要關注JavaScript和 Node.js，對其他語言也提供有限的支持。通過集成實時編輯、托管、共享和自動化版本控制等功能，Glitch提供了一種令人耳目一新的獨特的協作編程方式。
谷歌云數據流（GOOGLE CLOUD DATAFLOW） 在傳統的ETL場景中非常有用。它可以從數據源讀取數據、轉換數據并將轉換后的數據存儲到接收器中。整個過程的配置和容量伸縮都是由該平臺進行管理。該平臺支持Java、Python和Scala，并提供連接各種數據源的包裝器。然而，該平臺的當前版本并不允許用戶添加其他庫，所以可能會導致它不適合進行某些類型的數據操作。同時用戶也無法動態地更改數據流的DAG（Directed Acyclic Graph，有向無環圖）。因此，如果用戶的ETL有基于參數的條件執行流程，就可能需要做一些變通才能使用該平臺。
GVISOR是一個容器內的user-space內核。它不允許應用程序訪問主機內核的所有功能，只能訪問主機內核的表層。不同于現有通過虛擬化硬件實現的沙盒技術 KVM 和 Xen 或者基于規則執行的方式實現的沙盒技術seccomp, SELinux和 AppArmor ，gVisor通過攔截應用程序的系統調用這種特殊的方式來實現容器沙盒，并且不需要虛擬化硬件的轉換就能夠實現訪問層內核。gVisor包含一個名為runsc的Open Container Initiative（OCI） 運行時，它集成了Docker和Kubenets（實驗性支持） 。gVisor是一個相對較新的項目，所以我們建議您根據自身容器安全狀況對其進行評估。
在多數情況下，區塊鏈不適合存儲 blob 文件 (例如：圖像，音頻)，當人們開發 DApp 時，一種選擇是將blob文件存放在一些鏈下的集中式數據存儲中，這種做法通常會導致信任缺失，另一種選擇是將它們存儲在星際文件系統 IPFS上，這是一種內容可尋址、版本化、點對點的文件系統。它旨在高效地分發大規模數據，并能阻止任何中心化機構刪除數據，文件存儲在不需要相互信任的對等節點上。IPFS 保存文件的每一個版本，這樣你將永遠不會丟失重要文件，我們將IPFS視為區塊鏈技術的好的補充。除了區塊鏈應用程序外，IPFS還有一個愿景是對現有的網絡基礎設施進行去中心化重塑
構建和運維微服務生態系統的一個老問題，是如何實現些橫切關注點，例如服務發現、服務到服務的安全性、原始服務到其它服務的安全性、可觀測性（包括遙測和分布式跟蹤）、滾動發布和系統韌性。在過去幾年中， service mesh 技術已經成為我們對這個問題的默認答案。Service mesh 以配置為代碼的方式，在基礎設施層實現了這些橫切關注點。策略配置可以一致地應用于整個微服務生態系統。這些策略可以在 serivice mesh 流量內外（通過將 service mesh代理作為網關的方式）以及每個服務的流量（通過將相同的service mesh 代理作為 sidecar 容器的方式）上強制執行。在密切關注不同開源 service mesh 項目 Linkerd 的進展的同時，我們已經成功地在生產環境中使用了 ISTIO 。Istio易于配置的操作模型令人驚嘆。
作為應用開發者，我們喜歡專心解決核心業務問題，而讓底層平臺來處理那些枯燥且困難的任務（如部署、容量伸縮及應用程序管理）。雖然無服務器架構往這個方向邁出了一步，然而大多數流行的產品都會與某個專有實現綁在一起。而這意味著供應商綁定。KNATIVE試圖以開源無服務器平臺的方式來解決此問題。它良好地集成了流行的Kubernetes生態系統。利用 Knative ，可以對隨時請求的計算進行建模（其間可以從一些框架中進行選擇，如 Ruby onRails、Django和Spring 等），可以訂閱、交付和管理事件，可以集成用戶所熟悉的 CI和CD 工具，可以從源代碼構建出容器。該平臺提供一組中間件組件，來構建以源代碼為中心且基于容器（能夠實現資源伸縮性）的應用。這使得它成為一個頗有吸引力的平臺，當有無服務器需求時，值得對其進行評估。
我們對 PULUMI 非常感興趣。**它是云基礎設施自動化領域很有前途的新星。其優勢在于，允許使用 TypeScript/JavaScript、 Python 和 Go 語言（無需YAML配置）來編寫配置。**Pulumi 專注于云原生架構（包括容器、無服務器函數和數據服務），并為 Kubernetes 提供了良好的支持。
在區塊鏈技術領域， Ethereum(以太坊)是一個領先的開發者生態系統。我們看到了一些新興的解決方案，它們旨在將Ethereum這項技術傳播到一些企業環境中。這些企業通常需要網絡權限和交易隱私管理，另外還需要更高的吞吐量和更低的延遲。 QUORUM 就是其中的一個解決方案。Quorum最初由J.P. Morgan開發，其定位是“企業版的Ethereum”。與創建了新的以太坊虛擬機（EVM）的Hyperledger Burrow 節點不同，Quorum的代碼源自以太坊官方客戶端的一個分支，所以能與以太坊一起進化。在保留了以太坊賬本的大多數功能的前提下，Quorum將共識協議從工作量證明機制更改為更高效的協議，并增加了私有交易支持。使用Quorum，開發人員可以使用他們的以太坊知識來構建企業級的區塊鏈應用，這些知識包括 Solidity語言和 Truffle 合約。然而根據我們的經驗，Quorum還沒有為應用于企業做好充足的準備；比如：它缺乏針對私有合約的訪問控制機制，無法用于負載均衡，并且只支持部分數據庫。所有的這些限制都為用戶的部署與設計帶來顯著的負擔。我們建議在使用Quorum的時候保持警惕，同時密切關注它的后續發展。
RESIN.IO 是一個物聯網（IoT）平臺。雖然只做把容器部署到設備中這一件事，但它做得很好。開發人員使用一個軟件即服務（ SaaS）的門戶來管理設備，并為這些設備分發由 Dockerfile 定義的應用。該平臺可以為多種硬件類型構建容器，并通過無線的方式部署容器鏡像。Resin.io 使用balena 來管理容器。而balena是一個基于 Mobby 框架的容器引擎，由 Docker 出品。該平臺仍在開發中，有些功能尚需完善，也缺少一些特性（比如與私有容器注冊服務協同工作）。但是目前的特性集（包括從 Web 門戶使用 ssh 訪問一個設備上的容器）表明它的未來充滿希望。
ROOK是一款運行在Kubernetes集群中的開源云原生存儲編排工具。與Ceph集成之后的Rook，能將文件、塊和對象存儲系統引入到Kubernetes集群中，并能與使用這些存儲的其他應用和服務一起無縫地運行。通過使用一些Kubernetes operator，Rook可以在控制層上編排Ceph，這樣就可以避免擠占應用程序和Ceph之間的數據通道。存儲是云原生計算中的重要組件，雖然Rook現在仍然在CNCF進行孵化，但是我們相信，它將引領我們向著自給自足和跨公有云和本地化部署的可移植性更進一步。
利用谷歌具有開創性的高容量平臺的關鍵組件來構建開源產品，似乎已成為一種趨勢。如同HBASE利用了谷歌的BigTable， Kubernetes 利用了谷歌的Borg， SPIFFE 正在利用谷歌的LOAS，來將一種稱為工作負載標識的關鍵云原生概念轉化為現實。 SPIFFE標準由開源軟件 SPIFFERuntime Environment (SPIRE) 提供支持，該軟件可自動為軟件工作負載提供加密且可證明的身份。雖然SPIRE還沒有為在生產環境使用做好準備，但我們看到了其在以下場景中的巨大價值：以平臺無關的方式，在現代分布式IT基礎設施中的工作負載之間，進行強身份驗證。 SPIRE支持許多用例，包括身份轉換、OAuth客戶端身份驗證、mTLS“無處不在的加密”和工作負載可觀察性。本期雷達所介紹的 Istio默認就使用SPIFFE。
暫緩
**數據饑餓軟件包(DATA-HUNGRY PACKAGES)**是一種解決方案，它需要將數據吸附到自身才能運行。在某些情況下，它們甚至可能需要成為這些數據的“主人”。一旦這種軟件包擁有了數據，它就成為更新、修改或訪問這些數據的唯一方法。這種軟件包可能會解決諸如ERP這樣特定的業務問題。但是，組織的有關庫存或財務的“數據需求”，通常需要復雜的集成和對位于原始范圍之外的系統的更改。
低代碼平臺（LOW-CODE PLATFORMS） 使用圖形化用戶界面與圖形化配置來創建應用程序。然而不幸的是，該平臺的推廣理念卻是軟件開發不再需要有經驗的開發團隊。這種理念忽視了這樣的事實，即在創建高質量軟件所需要的所有實踐中，編寫代碼僅僅是其中的一小部分，而諸如控制源代碼、測試和精心設計解決方案這些實踐，也同樣重要。盡管這種平臺有時也是有用的，但我們仍建議要小心對待，特別是當他們肆無忌憚地宣稱其能實現更低成本和更高產出的時候。
工具
采用
試驗
Azure Container Service Engine (ACS-ENGINE) 是用于 Azure Resource Manager (ARM) 的模版生成器。aceengine 使用一個 JSON 文件進行集群配置，并生成 ARM所需的一系列文件。該工具可以靈活選用不同的容器編排工具，包括 Kubernetes 、 DC/OS 、 OpenShift 、 Swarmmode 與 Swarm ，也可以靈活配置集群的特征及代理。我們已經在多個項目中應用了 acs-engine，并推薦用它來管理 Azure Container Service 中的集群
我們看到安全工具與現代軟件交付過程的集成有了顯著進步。ARCHERY 是一個開源的安全工具，它的社區活躍，并正在將其與其他工具（包括 Zap ）相結合。Archery 主要用于 Web 應用程序，可以輕松地將安全工具集成到構建與部署系統中。也可以通過 Archery 的工作面板，跟蹤漏洞及應用程序和網絡的安全掃描結果。
ARCHUNIT是一個基于 Java 的測試庫，用于檢查代碼的結構特性，如包和類的依賴關系、注解驗證，甚至還能檢查代碼分層是否一致。我們很喜歡 ArchUnit 的地方是，它可以在現有的測試環境中以單元測試的方式運行，盡管只支持基于 Java 的架構。在CI環境或部署流水線中集成ArchUnit 測試套件，可以方便地在演進式架構中實現架構適應度函數。
運行端到端測試時經常會遇到一些棘手的問題，比如運行時間過長，測試過于零碎，還需要修復無頭模式下運行的測試所導致的 CI 失敗。我們的團隊借助 CYPRESS 很好地解決了性能差、響應時間長、資源加載慢等常見問題。Cypress 是一款很有用的工具，可以幫助開發者構建端到端測試，還可以將所有測試步驟保存為 MP4 視頻，便于檢查錯誤。
安全性仍然至關重要，而粗心地將安全憑據或其他機密提交到源代碼倉庫是一個主要的攻擊向量。 GIT-SECRETS是防止將密碼或其他敏感信息提交到 git 倉庫的小工具。也可以在公開代碼庫之前使用 git-secrets 掃描全部歷史提交，以確保沒有意外地提交憑據。git-secrets 內建支持常見的 AWS 密鑰和憑據，也可以為其他的提供商進行快速配置。
Firefox 無頭模式(HEADLESS FIREFOX)與用于前端測試的 Chrome 無頭模式一樣成熟。 與 Chrome 無頭模式類似，在 Firefox 無頭模式下運行瀏覽器測試時無需渲染 UI組件，因此大大加快了 UI 測試的速度。
使用云服務時面對的一個挑戰是如何在本地進行開發和測試。 LOCALSTACK 為 AWS 解決了這個問題。它提供了各種 AWS 服務的本地測試替身實現，包括 S3 、 Kinesis 、Dynamodb 和 Lambda 等。它基于現有的最佳工具如Kinesalite 、 Dynalite 、 Moto 等構建，并增加了進程隔離與錯誤注入的功能。 LocalStack 的使用很簡單，并附帶了一個簡單的 JUnit 運行器以及 JUnit 5擴展。我們在一些項目中使用過 LocalStack ，并對它印象深刻。
MERMAID 使用類似 markdown 的標記語言來生成圖表。Mermaid 為簡化文檔編寫而生，并且發展迅速。目前已經為許多工具提供了插件支持，比如 Confluence 、 VisualStudio Code 和 Jekyll 。 可以試用一下 GitHub 上的在線編輯器。此外， Mermaid 還提供了很好用的命令行，可以使用圖表定義文件生成 SVG/PNG/PDF 。我們已經在許多項目中使用了 Mermaid ，尤其欣賞的是，它可以用 markdown簡潔地描述圖形和流程圖，同時也可以將圖表定義文件存儲在代碼倉庫中。
PRETTIER 是一個頗有主張的 JavaScript 代碼自動格式化工具（也在逐漸支持其它語言）。它通過強制實施自己主張的代碼風格，增強了代碼的一致性和可讀性，并減少了開發人員在格式化上的工作量，以及團隊在代碼風格大討論上浪費的工作量。雖然你可能不同意 Prettier 所強制選擇的風格，不過我們發現它給團隊帶來的好處通常會大于這些風格方面的小問題。 Prettier 可以與版本管理系統的“提交前鉤子”或 IDE 插件一起使用。與任何格式化工具一樣，一次性地格式化整個代碼庫可能會給版本控制歷史帶來混亂，不過我們覺得這只是一個小問題。我們特別欣賞的是Prettier 不再使用基于 linter 的方法。借用來自 gofmt 的一句話：不僅驗證代碼，更保持它始終有效！
技術雷達在2015年引入了 Visual Studio Code ，而如今它已不再是唯一基于 .NET Core 的跨平臺 IDE 。最近，作為JetBrains 開發的 IDEA 平臺的一員， RIDER 已經被廣泛使用。 Rider 的重構功能是基于 ReSharper 實現的，因此那些習慣于 ReSharper 快速靈巧的開發人員對其情有獨鐘。不僅如此， Rider 還為 .NET 帶來了完整的 IDEA 平臺，大大提升了開發效率。不管你喜歡哪個平臺，都有必要嘗試一下Rider ，它現在比 Visual Studio Code 更有優勢。活躍的生態和強有力的競爭使這些工具能夠持續改進，對整個社區來說是件好事。
SNYK 可以查找、修復及監控 npm 、 Ruby 、 Python 、Scala 、 Golang 、 .NET 、 PHP 、 Java 與 Docker 依賴樹中的漏洞。將 Snyk 加入構建流水線后，它會基于一個托管的漏洞數據庫，持續地監控和測試你的庫依賴樹。在發現漏洞時，還可以給出可以解決該安全問題的最小的依賴版本。
隨著越來越多的團隊接受DesignOps，這個領域的實踐和工具也日漸成熟。 我們的許多團隊都在使用一整套支持UI組件快速迭代的環境（也稱為UI DEVENVIRONMENTS），以專注于用戶體驗設計人員與開發人員之間的協作。目前可用的環境有：Storybook ， reactstyleguidist， Compositor 及 MDX。 這些工具既可以在組件庫或設計系統的開發過程中單獨使用，也可以嵌入到Web應用項目中使用。 如果只是為了向組件中添加新功能，你可以只啟動Storybook dev服務器，而不需要啟動應用、 BFF 或其他服務.
VISUAL STUDIO CODE 是微軟推出的免費 IDE 編輯器，可以跨平臺使用。我們曾用它同時進行前端 React、TypeScript 和后端 GoLang 的開發，而無需在不同的編輯器之間切換，體驗很好。 Visual Studio Code 中的工具、語言支持和擴展插件數量都在迅猛增長，也越來越好用。我們要特別推薦在實時協作及遠程結對編程時使用 VS LiveShare 。固然微軟或 Jetbrains 成熟的 IDE 對使用靜態類型語言（如 Java 、 .NET 或 C++ ）的復雜項目支持得更好，但我們也發現 Visual Studio Code 正逐漸成為基礎設施開發組和前端開發組的首選工具。
VS LIVE SHARE 是用于 Visual Studio Code 與 Visual Studio 的插件，提供實時合作編輯與調試代碼、語音通話、共享終端和暴露本地端口等功能，能夠減少遠程結對編程時遇到的障礙。我們特別欣賞的是，開發人員可以在使用Live Share 協作時沿用自己的編輯器配置，包括主題、快捷鍵和擴展。
評估
構建、測試和部署移動應用，尤其是由一條流水線從代碼倉庫打通到應用商店的時候，會涉及許多復雜的步驟。雖然這些步驟可以由腳本或普通 CI/CD 工具提供的流水線自動完成，但對于專注移動應用開發，而不需要與后端的構建流水線做集成的小組來說，使用專用工具可以降低復雜度和維護開銷。 BITRISE 配置簡單，并預置了一組完整的步驟，可以滿足絕大多數移動應用開發所需。
CODEFRESH 是類似于 CircleCI 與 Buildkite 的托管型持續集成服務器。它以容器為中心，并將 Dockerfile 文件和容器托管集群視為一等公民。我們十分欣賞的是， CircleCI鼓勵流水線式的交付方式，并且支持分支與合并。我們的團隊對 CircleCI 的前期反饋良好，但還沒有驗證在大型項目及復雜流水線上的使用效果。
我們一直在尋找一些工具和技術，使大型組織內的交付團隊能夠獨立于其他部門工作，同時滿足安全與風險管控的要求。GRAFEAS 就是一個這樣的工具。組織可以使用它發布軟件工件（Docker鏡像、庫及軟件包）的權威元數據，并在構建腳本或其他自動化的合規性控制過程中使用這些元數據。 通過訪問控制機制，可以將發布審核或漏洞信息的團隊與構建、部署軟件的團隊間的職責劃分清楚。請注意，雖然包括 Google 與 JFrog 在內的多個組織已經在工作流程中使用了 Grafeas ，但它目前仍處于 alpha 階段。
**HEPTIO ARK 是用于 Kubernetes 集群和持久化卷的災難恢復管理工具。 Ark 使用一系列檢查點備份與恢復集群，配置使用簡單。**使用 Ark 可以顯著縮短基礎架構發生故障時的恢復時間，還能輕松地將 Kubernetes 資源從一個集群遷移到另一個集群，或者復制生產環境用于測試和排錯。 Ark支持主流的云存儲提供商（包括 AWS ， Azure 和 GoogleCloud ），并且從版本0.6.0開始，提供了插件系統用于兼容其他備份與卷存儲平臺。雖然 GKE 等 Kubernetes 托管環境已經提供了這類服務，但如果需要自行運維 Kubernetes ，不論是在本地還是云端，都請仔細考慮使用 Heptio Ark 進行災難恢復。
JAEGER 是一個開源的分布式追蹤系統。與 Zipkin 類似， Jaeger 的設計靈感來源于谷歌的 Dapper，并遵循 OpenTracing 。 Jaeger 的誕生晚于 Zipkin 但普及迅速。這是因為 Jaeger 支持更多種語言的客戶端庫，并且在 Kubernetes 集群中安裝它也很簡單。我們已經成功將Jaeger 與 Istio 配合使用，在 Kubernetes 集群中與 Envoy集成進行應用程序追蹤。我們也很喜歡 Jaeger 的UI。隨著Jaeger 加入 CNCF ，我們預計 Jaeger 會在社區工作上投入更多的精力，同時也會與 CNCF 內的其他項目產生更深度的融合。
KUBE-BENCH 是一款基礎設施配置掃描工具，基于 K8S的 CIS 評分自動檢查 Kubernetes 配置，涵蓋用戶身份驗證，權限控制和數據安全等方面。 我們的團隊發現 kubebench 識別易受攻擊的配置方面很有價值。
OCELOT是基于.NET Core實現的輕量級API網關項目，它可以通過輕松的配置來實現路由轉發、請求聚合、服務發現、認證授權、限流熔斷、負載均衡等特性，它還集成了Service Fabric、Consul、Eureka等功能。目前Ocelot的功能已經相當完整，它在.NET Core社區的活躍度也很高，.NET社區的開發者已經對 Ocelot 進行了很多擴展，以支持gRPC 、 Orleans與 WebSocket 等通信協議。盡管市面上不乏優秀的 API Gateway(如 Kong )，但 .NET 社區在構建微服務時還是更青睞 Ocelot 。一方面是由于 Ocelot 能夠更好的與 .NET生態(如 IdentityServer4 )集成，另一方面騰訊已經將其用于生產環境來構建網關，這無疑是給Ocelot在可用性方面注入了一劑強心劑。
暫緩
在調研用戶體驗時，往往需要收集并分析數據，以便在設計產品時做出更好的決策。 OPTIMAL WORKSHOP 是一套數字化的調研工具。它提供了首次點擊、卡片分類等功能，可以幫助驗證原型以及改進網站導航和信息展示。OptimalWorkshop 還可以協助組織遠程調研，對于分布式的團隊特別有用。
越來越多的項目需要處理非結構化的數據，而從文本中提取出有意義的業務信息是一項關鍵技術。 STANFORDCORENLP 是一組基于 Java 的自然語言處理（NLP）工具集，支持英語、漢語和阿拉伯語等多種語言的命名實體識別、關系抽取、情感分析與文本分類，也提供了用于標記語料庫和訓練模型的工具。 Stanford CoreNLP 協助我們使用NLP 領域的最新研究成果來解決各種業務問題。
我們廣泛的應用 Terraform 來實現代碼化配置（as-code）云基礎設施。TERRAGRUNT 是 Terraform 的一個輕量級的封裝，用來落地《Terraform: Up and Running 》 書中主張的實踐。我們發現 Terragrunt 很有幫助，因為它通過一些便利的特性來促進版本化模塊和不同云環境的復用性，這些功能包括遞歸執行子目錄下的代碼。我們希望Terragrunt 能再進化一些，能夠原生地支持持續交付的實踐，我們希望在持續交付的流水線上所有基礎設施的代碼都能被打包、版本化并能在不同環境下復用（我們團隊已經通過替代方案實現了這些功能）。
我們團隊對 TESTCAFE 的反響很好。這是一個基于 JavaScript 的自動化瀏覽器測試工具，可以使用JavaScript 或 TypeScript 編寫測試，并在任何支持JavaScript 的瀏覽器中運行測試。 TestCafe 提供了開箱即用的并行執行、HTTP請求模擬等有用的功能。 TestCafe 使用異步執行模型而無需指定等待時間，有效提升了測試套件的穩定性。
TRAEFIK 是一款開源的反向代理及負載均衡器。 如果只是需要具有簡單路由功能的邊緣代理，而非 NGINX 、HAProxy 這樣的重量級產品，就可以考慮 Traefik 。它提供了微服務所必不可少的免重載更新配置、度量、監控與斷路器等功能，同時也很好地集成了Let’s Encrypt 以支持 SSL 。相比于 Traefik ，為了擴展、添加或移除微服務， NGINX 、HAProxy 等工具可能需要額外的工具進行模板化配置；有時還需要重啟，給生產環境造成很大麻煩。
我們非常關注測試驅動開發過程中的快速反饋，并一直尋找新方法使它變得更快。 WALLABY.JS 是一款支持主流編輯器的商用擴展，可以持續運行 JavaScript 單元測試，并在代碼旁高亮顯示測試結果。它還可以識別及運行每項代碼改動所影響的最小測試集，并在代碼錄入的同時持續運行測試。
語言 & 框架
采用
試驗
隨著 微服務 架構越來越多地被采用，相比以前，我們構建了更多的分布式應用程序。盡管解耦架構帶來了許多好處，但證明整個系統正確性所需的工作量和復雜程度正急劇增加。 JEPSEN 提供了許多我們所需要的工具，來幫助我們驗證協調任務調度程序的正確性，測試分布式數據庫的最終一致性、 線性一致性（Linearizability）和 可串行性（Serializability）。我們在一些項目中使用了 Jepsen，令人驚喜的是，我們可以測試驅動配置，注入和修復故障，驗證系統恢復后的狀態。
MMKV 是微信開發的開源框架，為移動應用提供高速的鍵值對存儲。 它利用 iOS 的內存映射功能來避免直接保存修改，因此性能極高。 MMKV 也能夠在應用程序異常崩潰時保存并快速恢復數據。
MOCKK 是用 Kotlin 編寫的模擬庫。它的核心理念是像 Coroutines 和 Lambda 表達式一樣，為 Kotlin 提供一等公民級別的語言特性支持。不同于 Mockito 或PowerMock 的蹩腳封裝，作為原生的開發庫，它能幫助開發團隊在測試 Kotlin 應用時編寫干凈、簡潔的代碼。
TYPESCRIPT 是一門嚴謹的語言。一直以來，它不斷改進的開發工具和IDE支持給我們留下了深刻的印象。隨著基于瀏覽器的代碼庫數量不斷增長，類型安全變得尤為重要，而使用此 TypeScript 類型定義庫，可以讓我們在保證類型安全的同時從豐富的 JavaScript 庫中受益。TypeScript 的類型安全特性讓我們在使用 IDE 或其他工具進行代碼開發時獲得了更詳盡的上下文，從而保障了代碼修改和重構的安全性。作為 JavaScript 的超集，TypeScript 的文檔和社區使學習曲線變得平緩。
評估
**Apache Beam 是個開源的統一編程模型，用于定義和運行批量/流式的并行數據處理流水線。**Beam 提供了可移植的 API 層，可以直接定義流水線，而不依賴于具體的執行引擎（也稱為 runner）如 Apache Spark、 Apache Flink或 Google Cloud Dataflow。這些引擎的功能不盡相同，因此提供可移植的 API 是項艱巨的任務。Beam 積極地嘗試將各引擎的創新功能加入 Beam 模型，同時通過社區合作的方式，影響這些引擎的產品規劃，以達到微妙的平衡。Beam 提供了豐富的內置I/O轉換器，以滿足大多數數據流水線的需求。如有特殊需求，也可以在 Beam 中實現自定義轉換器。可移植 API 以及可擴展 I/O 轉換器，是評估是否將 Apache Beam 用于處理數據流水線業務時最值得注意的地方。
我們常常對業務流程模型和標記法（BPMN）工具持懷疑態
度，因為它們普遍表現出低代碼環境相關的缺點。然而 OSS
BPMN 框架 CAMUNDA 不僅提供了一些這方面的創新，還
支持在 Java 代碼中以庫的方式直接集成它的工作流和決
策引擎，從而簡化了測試、版本管理和工作流重構方面的工
作。不僅如此，Camunda 還可以與 Spring、Spring Boot 以及其他框架集成，這使它成為了我的不二之選。
FLUTTER是一個跨平臺的框架，可以使用Dart語言編寫原生 Mobile 應用。借助 Dart，它能夠編譯成原生代碼，并直接 和目標平臺通訊，而不必借助橋接和上下文切換—這些可能導致框架中出現性能瓶頸，就像 React Native 或Weex 那樣。Flutter的熱重載（hot-reload）特性讓人驚嘆，它能在編 碼時為你提供超快的視覺反饋。目前，Flutter 仍在 Beta 階段，不過我們會持續關注它，了解其生態系統的成熟度
Kotlin 語言已不僅僅適用于移動應用開發。新工具和框架的出現證明了其在 web 應用程序開發上的價值。KTOR 就是其中之一。與其它支持 Kotlin 的 web 框架相比，Ktor 本身就是用 Kotlin 編寫的，并運用了諸如 coroutines 等語言特性來支持異步非阻塞的實現。除了具有輕量級架構外，它還能靈活的與各種不同的日志、依賴注入和模板引擎工具結合使用，這讓 Ktor 成為了我們團隊在創建 RESTful 服務時一個有趣的選項
我們在與團隊的交流中了解到 Python 卷土重來并席卷了多個技術領域。事實上，它正成為最常用的編程語言。這一方面得益于數據科學家和機器學習領域推動了它的應用，另一方面我們也看到有團隊正將其運用于微服務的構建。NAMEKO 就是這樣一個超輕量級的微服務框架，也是Flask的 替代方案。與 Flask 不同的是，Nameko 只包含了WebSocket、HTTP、AMQP 支持等有限功能。它對可測試性的重視也得到我們的欣賞。如果你不需要 Flask 提供的模板等功能，那么 Nameko 值得一瞧。
POLLY.JS 是個用于測試 JavaScript 網站和應用程序的簡單工具。它可以攔截和模擬 HTTP 交互，從而簡單快速地測試 JavaScript 代碼而無需啟動其依賴的服務或組件，我們的團隊對這一點情有獨鐘。
**PREDICTIONIO 是開源的機器學習服務框架。**無論是普通開發者還是數據科學家，都可以利用它創建用于預測的智能應用。和所有其他智能應用類似，**PredictionIO 由三個部分組成：數據收集和存儲、模型訓練以及模型部署和服務暴露。**開發者只需要基于它提供的相應接口實現數據處理邏輯、模型算法和預測邏輯，無需在諸如存儲數據以及訓練模型之類的事情上投入額外精力。從我們的經驗來看，在不要求高并發處理的情況下，PredictionIO 能支持不同大小的數據集。大多數時候我們使用 PredictionIO 來為中小企業構建預測類智能服務，或者在構建復雜定制化預測引擎的過程中進行概念驗證。
在之前的技術雷達中，我們提到了使用 Headless Chrome進行前端測試。如今，隨著其他瀏覽器對 ChromeDevTools 協議（CDP）的引入，出現了一系列針對這些瀏覽器的自動化和測試相關支持庫。即使在無頭模式下，CDP 也支持對瀏覽器的細粒度控制?；?CDP 協議，一些高級自動化測試框架被陸續創造出來，而 PUPPETEER 正是其中之一。它可以通過單頁應用程序驅動 Headless Chrome 模式，從而實現基于時間追蹤的性能診斷等功能。我們的團隊在使用過程中發現它比基于 WebDriver 的其它工具更快，也更靈活。
量子計算目前已經可供測試，但何時真正到來尚未明確。在硬件到位之前，我們已經可以通過語言和模擬器來實驗和學習它。盡管IBM等公司已經取得了不錯的進展，我們對微軟在 Q＃ 語言及其模擬器（本地32量子比特，Azure云上40量子比特）方面的工作更加關注。如果你想開始了解這項編程的前景，請查看他們在 GitHub 上的范例。
SAFE 技術棧是 Suave、 Azure、 Fable 和 Elmish 的簡稱。SAFE 囊括了一系列技術，形成了前后端一致的 Web開發技術棧。SAFE 在服務端和瀏覽器端都使用了 F# 語言，因此注重于異步函數式類型安全的編程機制。它不僅提供了一些提高開發效率的功能比如熱加載；還允許我們替換技術棧里的某些模塊，例如服務器端 Web 框架或云提供商。
新編程語言的廣泛使用往往會催生支持成熟工程實踐的新工具，例如自動化測試， Kotlin 也不例外。Cucumber、 RSpec 和 Jasmine 這些測試工具廣為人知，它們采用 Gherkin 語言和需求規范（Specification）來編寫測試。在以上幾個工具啟發下誕生的測試框架 SPEK能讓開發團隊把像行為驅動開發這樣的成熟實踐帶到Kotlin 世界來。
在那些使用了AWS CloudFormation（而非Terraform）的項目中，我們嘗試了用 TROPOSPHERE 作為在AWS上定義基礎設施即代碼的方式。Troposphere 是一個Python 庫，可以使用 Python 代碼生成 JSON 格式的CloudFormation 描述。我們喜歡 troposphere 是因為它很容易發現 JSON 錯誤，同時它也有類型檢測、單元測試以及 DRY 組合 AWS 資源等功能。
**WEBASSEMBLY 將“瀏覽器作為代碼執行環境”向前推進了一大步。它是一種二進制編譯格式，幾乎以原生速度 跑在瀏覽器中，已經獲得所有主流瀏覽器的支持并向后兼容。**它拓展了編寫前端功能的語言范圍，早期集中在C、C++ 和 Rust，并且也可以作為 LLVM 的編譯目標。在沙盒中執 行時，它可以和 JavaScript 交互并且共享相同的權限和安全模型。當和Firefox 最新的流式編譯器一起使用時，也可 以提升頁面初始化速度。盡管還處在早期階段，但是這個 W3C 標準絕對值得研究。
Spring Framework 5 已發布一年有余，它采用了響應式流 — 一套非阻塞背壓（backpressure）式異步流式處理標準。在傳統的 Spring MVC 模塊之外， WEBFLUX 為在Spring 生態下編寫 Web 應用提供了一個響應式替代品。經過一系列應用的試用，WebFlux 給我們的團隊留下了深刻的印象，并匯報說這種響應式（函數式）實現增強了代碼的可讀性和系統的吞吐量。但他們也確實注意到，采用 WebFlux 需要在思維方式上做出一些重大轉變，建議在WebFlux vs. Spring MVC 的技術選型中考慮這一點。
暫緩
總結
以上是生活随笔為你收集整理的2019年TW的技术雷达的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 电脑爱好者 2008年第23期（12月上
- 下一篇： C语言程序设计中十全十美,21世纪高校计