技術(shù)雷達(dá)是ThoughtWorks每半年發(fā)布一次的技術(shù)趨勢(shì)報(bào)告，它持續(xù)追蹤有趣的技術(shù)是如何發(fā)展的，我們將其稱之為條目。技術(shù)雷達(dá)使用象限和環(huán)對(duì)其進(jìn)行分類，不同象限代表不同種類的技術(shù)，而環(huán)則代表我們對(duì)其作出的成熟度評(píng)估。
經(jīng)過(guò)半年的追蹤與沉淀，ThoughtWorks TAB(ThoughtWorks技術(shù)咨詢委員會(huì))根據(jù)我們?cè)诙鄠€(gè)行業(yè)中的實(shí)踐案例，為技術(shù)者產(chǎn)出了第23期技術(shù)雷達(dá)。對(duì)百余個(gè)技術(shù)條目進(jìn)行分析，闡述它們目前的成熟度，并提供了相應(yīng)的技術(shù)選型建議。
本期五大主題
GraphQL 浮夸風(fēng)
我們看到 GraphQL 在很多團(tuán)隊(duì)中的采納率激增，同時(shí)其支撐生態(tài)也在蓬勃發(fā)展。它解決了現(xiàn)代分布式架構(gòu)(如微服務(wù))中的一些共性問(wèn)題：當(dāng)開發(fā)人員把系統(tǒng)分解成很多小塊時(shí)，他們通常還要把信息重新聚合起來(lái)才能解決業(yè)務(wù)需求。GraphQL提供了一些功能，可以方便地解決這類日漸普遍化的問(wèn)題。就像所有強(qiáng)大的抽象一樣，它提供的是一種折衷方案，團(tuán)隊(duì)要認(rèn)真考慮，以避免長(zhǎng)線上的負(fù)面影響。比如，我們已經(jīng)看到有團(tuán)隊(duì)通過(guò)聚合工具暴露了過(guò)多的底層實(shí)現(xiàn)細(xì)節(jié)，導(dǎo)致架構(gòu)出現(xiàn)了不必要的脆弱性。當(dāng)團(tuán)隊(duì)試圖借助聚合工具來(lái)創(chuàng)建規(guī)范化的、通用的、中心化的數(shù)據(jù)模型時(shí)，就會(huì)把短線上的便利變成長(zhǎng)線上的麻煩。我們鼓勵(lì)團(tuán)隊(duì)使用 GraphQL 及其迅速成長(zhǎng)的周邊工具，但是，要小心別過(guò)度追求技術(shù)通用性，不要試圖用一項(xiàng)技術(shù)解決很多問(wèn)題。
與瀏覽器的斗爭(zhēng)仍在繼續(xù)
網(wǎng)頁(yè)瀏覽器原本是被設(shè)計(jì)用來(lái)瀏覽文檔的，但現(xiàn)在主要用來(lái)承載應(yīng)用程序，這種抽象的不匹配一直困擾著開發(fā)人員。為了克服這種不匹配所帶來(lái)的諸多問(wèn)題，開發(fā)人員一直在重新審視和挑戰(zhàn)那些公認(rèn)的用于瀏覽器測(cè)試、狀態(tài)管理和構(gòu)建快速且豐富的瀏覽器應(yīng)用程序的方法。我們?cè)诩夹g(shù)雷達(dá)上可以看到這一類的趨勢(shì)。第一，自從2017年 Redux 作為管理 React 應(yīng)用狀態(tài)的默認(rèn)方法被移到“采納”環(huán)以來(lái)，我們看到開發(fā)人員要么仍在嘗試其他的方法(Recoil)， 要么推遲對(duì)狀態(tài)管理庫(kù)的選型決策。第二，人們對(duì) Svelte 越來(lái)越感興趣，而它正在挑戰(zhàn)虛擬 DOM 的概念， 后者則正是 React 和 Vue.js 等流行的程序開發(fā)框架所遵循的概念。第三，用于處理瀏覽器端測(cè)試的新工具不斷涌現(xiàn)：Playwright 是改進(jìn) UI 測(cè)試的又一個(gè)新嘗試，而 Mock Service Worker 則是一種將測(cè)試與后端交互分離的新方法。第四，平衡開發(fā)人員的開發(fā)效率與應(yīng)用性能一直都是我們需要面對(duì)的一個(gè)挑戰(zhàn)，瀏覽器定制的膩?zhàn)幽_本的目的就是改變這個(gè)權(quán)衡的范圍。
可視化一切
這一期技術(shù)雷達(dá)中，有幾個(gè)條目來(lái)自不同技術(shù)領(lǐng)域但卻擁有一個(gè)共性，即可視化。你會(huì)發(fā)現(xiàn)很多關(guān)于基礎(chǔ)設(shè)施、數(shù)據(jù)科學(xué)、云資源，以及很多其他極富創(chuàng)新性的可視化工具，其中不乏一些可以有效可視化復(fù)雜抽象的方法。也有一些交互式的數(shù)據(jù)可視化工具和控制面板工具，如 Dash, Bokeh 和 Streamlit，還有一些基礎(chǔ)設(shè)施的可視化工具，例如微服務(wù)架構(gòu)中的服務(wù)網(wǎng)格可視化工具 Kiali。隨著開發(fā)人員的生態(tài)環(huán)境變得越來(lái)越復(fù)雜，一幅能清晰地解釋問(wèn)題的圖像對(duì)減輕大家的心智負(fù)擔(dān)無(wú)疑是大有裨益。
基礎(chǔ)設(shè)施即代碼的青春期
隨著組織看到自動(dòng)化基礎(chǔ)設(shè)施所帶來(lái)的好處，管理基礎(chǔ)設(shè)施即代碼變得越來(lái)越普遍。這為創(chuàng)新型的工具和框架的創(chuàng)建者們提供了反饋。諸如CDK和Pulumi之類的工具，提供了遠(yuǎn)遠(yuǎn)超過(guò)第一代工具的功能。其改進(jìn)如此之大，以至于我們相信基礎(chǔ)設(shè)施即代碼已經(jīng)進(jìn)入了積極與消極因素共存的“青春期”。我們驚喜地看到在所有象限中，都有相關(guān)雷達(dá)條目，從積極的方面反映了相關(guān)生態(tài)系統(tǒng)日益成熟。但是，我們還討論了該領(lǐng)域因?yàn)槿狈Τ墒炷Ｊ蕉媾R的挑戰(zhàn)，以及許多公司在嘗試用最佳方式利用此功能時(shí)所面臨的挑戰(zhàn)。所有這些都表明，該領(lǐng)域在持續(xù)增長(zhǎng)，但尚未成熟。我們希望基礎(chǔ)設(shè)施社區(qū)，繼續(xù)從軟件設(shè)計(jì)中汲取教訓(xùn)，尤其要關(guān)注創(chuàng)建松散耦合的可部署基礎(chǔ)設(shè)施
編程大眾化
讓非程序員能夠執(zhí)行以往只有程序員才能做到的任務(wù)，我們圍繞這個(gè)促進(jìn)編程大眾化的工具和技術(shù)進(jìn)行了一些討論。而諸如IFTTT和Zapier之類的解決方案在該領(lǐng)域已長(zhǎng)期流行。我們發(fā)現(xiàn)，人們開始越來(lái)越多地使用諸如Amazon Honeycode這樣的低代碼環(huán)境，以創(chuàng)建簡(jiǎn)單的業(yè)務(wù)應(yīng)用程序。盡管此類工具提供了適合其目的的編程環(huán)境，但將其產(chǎn)出移至規(guī)?；纳a(chǎn)環(huán)境時(shí)仍會(huì)遇到挑戰(zhàn)。開發(fā)人員長(zhǎng)期以來(lái)一直設(shè)法利用電子表格向?qū)Чぞ?，在特定領(lǐng)域和傳統(tǒng)編碼環(huán)境之間找到折衷方案。越來(lái)越多的現(xiàn)代工具的問(wèn)世，在更廣泛的領(lǐng)域重新激起了大家的討論。但取舍的原則，依舊未變。
部分象限亮點(diǎn)搶先看
定制化服務(wù)模板
采納
自從定制化服務(wù)模板在雷達(dá)中出現(xiàn)以來(lái)，這個(gè)模式已經(jīng)被廣泛采用以幫助組織向微服務(wù)過(guò)渡。伴隨著可觀察性工具、容器編排和服務(wù)網(wǎng)格邊車的不斷進(jìn)步，服務(wù)模板可以通過(guò)精心挑選的默認(rèn)值，減少服務(wù)與基礎(chǔ)設(shè)施配合所需的大量設(shè)置，從而幫助快速建立新服務(wù)。對(duì)定制化服務(wù)模板應(yīng)用產(chǎn)品管理原則也取得了成功。以內(nèi)部開發(fā)者作為客戶，定制化服務(wù)模板可以幫助開發(fā)者將代碼發(fā)布到生產(chǎn)環(huán)境，并提供合適的可觀察性以進(jìn)行操作。定制化服務(wù)模板帶來(lái)的另一個(gè)好處，是可以作為輕量級(jí)的治理機(jī)制，對(duì)技術(shù)選型的默認(rèn)項(xiàng)進(jìn)行集中管理。
限界低代碼平臺(tái)
評(píng)估
現(xiàn)在很多公司正在面臨的一個(gè)最微妙的決定便是是否要采納低代碼平臺(tái)或無(wú)代碼平臺(tái)，這些平臺(tái)可以被用來(lái)在非常特定的領(lǐng)域里解決一些特定的問(wèn)題。限界低代碼平臺(tái)這一領(lǐng)域的供應(yīng)商也有如過(guò)江之鯽?，F(xiàn)在看來(lái)，這類平臺(tái)的一個(gè)突出的問(wèn)題，便是很難應(yīng)用一些諸如版本控制之類的優(yōu)秀的工程實(shí)踐。而且這類平臺(tái)上的測(cè)試也非常的困難。然而我們還是注意到了這個(gè)市場(chǎng)里的一些有趣的新兵，例如 Amazon Honeycode 可以被用來(lái)創(chuàng)建一些簡(jiǎn)單的任務(wù)和事件管理應(yīng)用，還有 IFTTT(類似于云工作流)領(lǐng)域的 Parabola，這也是為何我們會(huì)將 限界低代碼平臺(tái) 納入這個(gè)部分的原因。但是我們?nèi)匀粚?duì)它們更廣泛的適用性深表懷疑，因?yàn)檫@些工具，如日本 Knotweed，非常容易超出它們?cè)镜南藿缍环夯糜谄渌麍?chǎng)景，這也是為什么我們對(duì)采納這種技術(shù)持強(qiáng)烈的謹(jǐn)慎態(tài)度。
去中心化身份
評(píng)估
SSL/TLS 的核心貢獻(xiàn)者 Christopher Allen 在2016年給我們介紹了一種用于支撐新型數(shù)字化身份的10個(gè)原則，以及實(shí)現(xiàn)這一目標(biāo)的途徑：通往自主身份之路。自主身份也被稱為 去中心化身份 ，按照基于IP協(xié)議棧的信任標(biāo)準(zhǔn)，是一種“不依賴任何中心化權(quán)威并且永遠(yuǎn)不能被剝奪的任何人、組織或事物的終身可轉(zhuǎn)移身份”。采納和實(shí)現(xiàn)去中心化身份正在逐漸升溫并變得可能。我們看到了它在隱私方面的應(yīng)用：客戶健康應(yīng)用、 政府醫(yī)療基礎(chǔ)設(shè)施 和 公司法律身份。如果想快速地應(yīng)用去中心化身份，你可以評(píng)估 Sovrin Network，Hyperledger Aries 和 Indy 等開源軟件，以及去中心化身份 和 可驗(yàn)證憑證 標(biāo)準(zhǔn)。我們正在密切關(guān)注這個(gè)領(lǐng)域，并幫助我們的客戶在數(shù)字信任的新時(shí)代進(jìn)行戰(zhàn)略定位。
Apollo Federation
暫緩
我們首次在技術(shù)雷達(dá)中介紹 GraphQL 時(shí)，曾提醒誤用它會(huì)導(dǎo)致反模式，從長(zhǎng)遠(yuǎn)來(lái)看弊大于利。盡管如此，我們發(fā)現(xiàn)團(tuán)隊(duì)對(duì) GraphQL 越來(lái)越感興趣，因?yàn)樗軌?聚合來(lái)自不同資源的信息。這次我們想提醒你謹(jǐn)慎使用Apollo Federation和它對(duì)公司統(tǒng)一數(shù)據(jù)圖的強(qiáng)大支持。即便乍看之下，有跨組織的普適概念這種想法是具有吸引力的，但是我們必須考慮之前業(yè)界做過(guò)的類似嘗試——如 MDM 和規(guī)范數(shù)據(jù)模型等，這些嘗試暴露了這種方法的缺陷。挑戰(zhàn)會(huì)是巨大的，特別是當(dāng)我們發(fā)現(xiàn)所在的領(lǐng)域要?jiǎng)?chuàng)建一個(gè)獨(dú)特統(tǒng)一的模型非常復(fù)雜的時(shí)候。
Debezium
試驗(yàn)
Debezium 是一個(gè)變更數(shù)據(jù)捕獲(Change Data Capture, CDC) 平臺(tái)，可以將數(shù)據(jù)庫(kù)變更流式傳輸?shù)終afka 的 topics。CDC是一種流行的技術(shù)，具有多種應(yīng)用場(chǎng)景，例如：將數(shù)據(jù)復(fù)制到其他數(shù)據(jù)庫(kù)、輸送數(shù)據(jù)給分析系統(tǒng)、從單體中提取數(shù)據(jù)至微服務(wù)以及廢除緩存。Debezium對(duì)數(shù)據(jù)庫(kù)日志文件中的變更做出反應(yīng)，并具有多個(gè)CDC連接器，適用于多種數(shù)據(jù)庫(kù)，其中包括Postgres、MySQL、Oracle 和 MongoDB。我們?cè)谠S多項(xiàng)目中都使用了Debezium，它對(duì)我們來(lái)說(shuō)非常有效。
JupyterLab
試驗(yàn)
在上一期雷達(dá)中，JupyterLab 還處于評(píng)估象限，作為項(xiàng)目 Jupyter 基于 web 的用戶界面，現(xiàn)在它已經(jīng)成為許多數(shù)據(jù)從業(yè)者的首選。JupyterLab的使用正在迅速超越 Jupyter Notebooks，且終將取而代之。如果你仍在使用 Jupyter Notebooks，去嘗試一下 JupyterLab 吧。JupyterLab 的交互環(huán)境是對(duì) Jupyter Notebook 的改進(jìn)：通過(guò)單元格拖拽、tab 自動(dòng)補(bǔ)全等新特性對(duì)原有的功能進(jìn)行了擴(kuò)展。
K3s
評(píng)估
K3s 是一個(gè)輕量級(jí)的用于物聯(lián)網(wǎng)和邊緣計(jì)算的 Kubernetes 發(fā)行版。K3s被打包成一個(gè)單獨(dú)的二進(jìn)制文件，對(duì)于操作系統(tǒng)的依賴性微乎其微，這使得它非常易于運(yùn)維和使用。K3s 使用 sqlite3 而非 etcd 作為默認(rèn)的存儲(chǔ)后端。由于所有相關(guān)的組件都運(yùn)行在同一個(gè)進(jìn)程里，這使得 K3s 的內(nèi)存占用非常低。通過(guò)剝離不相關(guān)的第三方存儲(chǔ)驅(qū)動(dòng)和云提供商，K3s 的二進(jìn)制文件得以控制得非常小。在資源受限的環(huán)境中，K3s 是一個(gè)值得考慮的非常不錯(cuò)的選擇。
Pulumi
評(píng)估
我們已經(jīng)看到人們對(duì)Pulumi的興趣正在緩慢且穩(wěn)步地上升。雖然Terraform 在基礎(chǔ)設(shè)施編程世界中地位穩(wěn)固，但Pulumi卻填補(bǔ)了其中的一個(gè)空白。盡管 Terraform 是一個(gè)久經(jīng)考驗(yàn)的常備選項(xiàng)，但其聲明式編程特質(zhì)，深受抽象機(jī)制不足和可測(cè)試性有限的困擾。如果基礎(chǔ)設(shè)施完全是靜態(tài)的，那么 Terraform 就夠用了。但是動(dòng)態(tài)基礎(chǔ)設(shè)施但定義，要求使用真正的編程語(yǔ)言。Pulumi 允許以 TypeScript/ JavaScript、Python和Go語(yǔ)言(無(wú)需標(biāo)記語(yǔ)言或模板)編寫配置信息，這使其脫穎而出。Pulumi 專注于原生云架構(gòu)，包括容器、無(wú)服務(wù)器函數(shù)和數(shù)據(jù)服務(wù)，并為Kubernetes 提供了良好的支持。最近，AWS CDK 的推出對(duì)其形成了挑戰(zhàn)，但 Pulumi 仍然是該領(lǐng)域唯一的能獨(dú)立于任何云平臺(tái)廠商的工具。我們期望將來(lái)人們能更廣泛地采用 Pulumi，并期待出現(xiàn)能對(duì)其提供支持的可行的工具和知識(shí)生態(tài)系統(tǒng)。
Trivy
采納
用來(lái)創(chuàng)建和部署容器的流水線，應(yīng)該包含容器安全掃描這個(gè)步驟。我們的團(tuán)隊(duì)尤其喜歡Trivy——一個(gè)針對(duì)容器的漏洞掃描器。在這個(gè)領(lǐng)域的工具中，我們嘗試過(guò) Clair 和 Anchore Engine。跟 Clair 不一樣，Trivy 不止會(huì)檢查容器，而且會(huì)檢查代碼庫(kù)中的依賴。同時(shí)，由于它是一個(gè)獨(dú)立的二進(jìn)制包，所以更容易在本地設(shè)置和運(yùn)行。Trivy 的其他好處還有，它是開源軟件，并支持 distroless containers 容器。
MLflow
試驗(yàn)
MLflow 是一款用于機(jī)器學(xué)習(xí)實(shí)驗(yàn)跟蹤和生命周期管理的開源工具。開發(fā)和持續(xù)進(jìn)化一個(gè)機(jī)器學(xué)習(xí)模型的工作流包括，一系列實(shí)驗(yàn)(一些運(yùn)行的集合)，跟蹤這些實(shí)驗(yàn)的效果(一些指標(biāo)的集合)，以及跟蹤和調(diào)整模型(項(xiàng)目)。MLflow可以通過(guò)支持已有的開源標(biāo)準(zhǔn)，以及與這個(gè)生態(tài)中許多其他工具的良好集成，來(lái)友好地輔助這個(gè)工作流。在 AWS 和 Azure 中，MLflow 作為云上 Databricks 的受管服務(wù)，正在加速成熟，我們已經(jīng)在我們的項(xiàng)目中成功使用過(guò)它。我們還發(fā)現(xiàn) MLflow 是一個(gè)模型管理，以及跟蹤和支持基于 UI 和 API 交互模型的很棒的工具。唯一的擔(dān)憂在于，MLflow 作為單一平臺(tái)，一直在嘗試交付太多的混淆關(guān)注點(diǎn)，比如模型服務(wù)和打分。
Jscodeshift
試驗(yàn)
維護(hù)大規(guī)模的 JavaScript 代碼庫(kù)從來(lái)不是一件容易的事情，而遷移重大的變更更是極具挑戰(zhàn)。在簡(jiǎn)單的場(chǎng)景中，帶有重構(gòu)能力的 IDE 也許能幫得上忙。但是，如果代碼庫(kù)依賴廣泛，每次想要做出重大的變更時(shí)，你都不得不遍歷客戶端代碼庫(kù)，才能做出合適的更新。這需要人工的監(jiān)管并手工完成。jscodeshift，一個(gè)可以重構(gòu) JavaScript 和 TypeScript 的工具，能幫助減輕這種痛苦。它能把你的代碼分析成抽象語(yǔ)法樹(AST)，并提供 API 通過(guò)不同的變換(也就是在既有的組件上添加、重命名以及刪除屬性)操作這棵樹，然后把這棵樹導(dǎo)出成最終源代碼。jscodeshift還附帶一個(gè)簡(jiǎn)單的單元測(cè)試程序，它能用測(cè)試驅(qū)動(dòng)開發(fā)的方法編寫遷移 codemods。我們還發(fā)現(xiàn) jscodeshift 對(duì)于維護(hù)設(shè)計(jì)系統(tǒng)尤其有效。
Katran
評(píng)估
Katran 是一款高性能的 layer 4 負(fù)載均衡器。它并不適合所有人，但如果你需要 layer 7負(fù)載均衡器(比如 HAProxy 或者 NGINX)的替代品，或者你想要伸縮負(fù)載均衡器到兩臺(tái)及更多的服務(wù)器上，那我們推薦你評(píng)估一下Katran。相對(duì)于 L7 負(fù)載均衡器上的循環(huán) DNS 技術(shù)，或者網(wǎng)絡(luò)工程師通常用于解決類似挑戰(zhàn)的 IPVS 內(nèi)核模型，我們把 Katran 看作一個(gè)更靈活和有效的選擇。
Redux
試驗(yàn)
Redux 已被移回試驗(yàn)環(huán)，因?yàn)槲覀儾辉賹⑵湟暈?React 應(yīng)用程序默認(rèn)的狀態(tài)管理方式。經(jīng)驗(yàn)表明，在許多情況下 Redux 框架仍然具有一定的價(jià)值。但是與其他方法相比，Redux會(huì)導(dǎo)致代碼冗長(zhǎng)難讀。而引入 Redux Sagas 通常更會(huì)加劇這個(gè)問(wèn)題。相對(duì)的，React 最新版本中的功能已經(jīng)可以有效地管理狀態(tài)，而無(wú)需引入其他框架。但需要著重強(qiáng)調(diào)的是，當(dāng)簡(jiǎn)單的狀態(tài)管理解決方案開始變得復(fù)雜時(shí)，仍然可以考慮使用 Redux，或者是 Facebook 最近發(fā)布的 Recoil。
Babylon.js
評(píng)估
在幾年前我們寫到超越游戲的VR時(shí)，我們沒有預(yù)見到 VR 解決方案會(huì)以多快以及多深的程度進(jìn)入到除了視頻游戲之外的領(lǐng)域。事后看來(lái)，我們當(dāng)然看到了一些興趣和采納的增長(zhǎng)，但人們對(duì)它的理解卻比我們預(yù)期的要慢得多。原因之一可能是工具。Unity 和 Unreal 是兩個(gè)用于開發(fā) VR 應(yīng)用的成熟又強(qiáng)大的引擎。我們還特別提到 Godot。然而，這些引擎跟大多數(shù) web 和企業(yè)團(tuán)隊(duì)熟悉的那些工具很不同。隨著我們繼續(xù)探索，我們意識(shí)到基于 web 的 VR 方案已經(jīng)取得巨大進(jìn)展，其中對(duì)Babylon.js我們有相當(dāng)積極的經(jīng)驗(yàn)。Babylon.js 是用 TypeScript 編寫并在瀏覽器中渲染出它的應(yīng)用，這為許多開發(fā)團(tuán)隊(duì)提供了熟悉的開發(fā)體驗(yàn)。此外，Babylon.js 也是開源軟件，成熟而且資金充足，這讓它足具吸引力。
XState
試驗(yàn)
在之前的雷達(dá)中，我們?cè)?jīng)提及多個(gè)狀態(tài)管理的類庫(kù)，但XState在其中顯得與眾不同。它是個(gè)簡(jiǎn)單的 JavaScript 和 TypeScript 框架，可以創(chuàng)建有限狀態(tài)機(jī)并可視化為狀態(tài)圖。它可以跟最流行的響應(yīng)式 JavaScript 框架(Vue.js，Ember.js，React.js 以及 RxJS)集成，并基于 W3C 標(biāo)準(zhǔn)來(lái)創(chuàng)建有限狀態(tài)機(jī)。另外一個(gè)值得留意的特性是它可以序列化狀態(tài)機(jī)的定義。在其他的上下文中(尤其在編寫游戲邏輯時(shí))創(chuàng)建有限狀態(tài)機(jī)時(shí)，我們發(fā)現(xiàn)一件很有幫助的事情，是 XState 對(duì)狀態(tài)以及可能的轉(zhuǎn)換的可視化能力，通過(guò)它的 visualizer 實(shí)現(xiàn)起來(lái)是如此容易。
Streamlit
評(píng)估
Streamlit 是 Python 編寫的開源應(yīng)用框架，數(shù)據(jù)科學(xué)家用其來(lái)構(gòu)建好看的數(shù)據(jù)可視化應(yīng)用。Streamlit專注于快速原型設(shè)計(jì)，并且支持各種不同的可視化庫(kù)(包括 Plotly和Bokeh)，因此在Dash等競(jìng)品中脫穎而出。對(duì)于需要在實(shí)驗(yàn)周期中快速展示的數(shù)據(jù)科學(xué)家來(lái)說(shuō)，Streamlit 是一個(gè)可靠的選擇。我們?cè)谝恍╉?xiàng)目中使用它，并且只需要花費(fèi)很少的工作量就能把多個(gè)交互式可視化放在一起。
以上是我們?cè)谧钚乱痪砑夹g(shù)雷達(dá)中隨機(jī)摘取的幾個(gè)Blip
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
