作者 | ThoughtWorks

編輯 | 小智

ThoughtWorks 每年都會(huì)出品兩期技術(shù)雷達(dá)，這是一份關(guān)于技術(shù)趨勢(shì)的報(bào)告，由 ThoughtWorks 技術(shù)戰(zhàn)略委員會(huì)（TAB）經(jīng)由多番正式討論給出，它以獨(dú)特的雷達(dá)形式對(duì)各類(lèi)最新技術(shù)的成熟度進(jìn)行評(píng)估并給出建議，為從程序員到 CTO 的利益相關(guān)者提供參考。

本期主題

粘性十足的云平臺(tái)?

云提供商知道他們正在嚴(yán)峻的市場(chǎng)中進(jìn)行競(jìng)爭(zhēng)。為了獲勝，他們需要吸引用戶(hù)注冊(cè)并長(zhǎng)期留住他們。因此，為了保持競(jìng)爭(zhēng)力，他們?cè)谛略霎a(chǎn)品特性上你爭(zhēng)我搶，使得彼此不相上下。這一點(diǎn)可以從本期雷達(dá)試驗(yàn)環(huán)中以下云提供商的排名看出： AWS、 Google Cloud Platform 和 Azure 。然而，一旦用戶(hù)注冊(cè)，這些云提供商就傾向于與用戶(hù)建立盡可能高的粘性，以阻止他們使用其他提供商的服務(wù)。這通常表現(xiàn)為其云服務(wù)會(huì)與其服務(wù)和工具套件緊密集成。用戶(hù)只有繼續(xù)使用其云服務(wù)，才能獲得更好的開(kāi)發(fā)者體驗(yàn)。

通常在用戶(hù)決定是否將其部分或全部工作負(fù)載移動(dòng)到另一朵云上，或發(fā)現(xiàn)云服務(wù)的使用和賬單多到失控時(shí)，就能明顯感覺(jué)到這種粘性。我們鼓勵(lì)客戶(hù)使用 架構(gòu)適應(yīng)度函數(shù)度量成本 的技術(shù)來(lái)監(jiān)控運(yùn)維成本，并將其作為衡量云供應(yīng)商粘性的指標(biāo)。或者使用 Kubernetes 和容器，并通過(guò)運(yùn)用基礎(chǔ)設(shè)施即代碼來(lái)提升工作負(fù)載的可移植性，降低切換到另一個(gè)云提供商的成本。在本期雷達(dá)中，我們還會(huì)介紹兩個(gè)新的云基礎(chǔ)設(shè)施自動(dòng)化工具：Terragrunt 和 Pulumi。雖然我們支持通過(guò)粘性的高低來(lái)評(píng)估云提供商的新產(chǎn)品，但提醒你不要落入只使用通用云服務(wù)功能的陷阱。根據(jù)我們的經(jīng)驗(yàn)，創(chuàng)建和維護(hù)與云無(wú)關(guān)的抽象層的開(kāi)銷(xiāo)，會(huì)超出退出某個(gè)特定云提供商的花費(fèi)。

?

揮之不去的企業(yè)級(jí)應(yīng)用反模式

無(wú)論技術(shù)如何快速變化，一些企業(yè)仍然想方設(shè)法地重新實(shí)現(xiàn)過(guò)去的反模式。雷達(dá)中的許多暫緩條目都在揭穿一些“新瓶裝舊酒”的老把戲。比如：用 Kafka 重新創(chuàng)建 ESB 的反模式、分層式微服務(wù)架構(gòu)、Data-hungry packages、過(guò)度龐大的 API 網(wǎng)關(guān)、Low-code 平臺(tái)和一些其他有害的舊實(shí)踐。一如既往的根本問(wèn)題，是如何在隔離和耦合之間取得平衡：我們隔離組件，使其在技術(shù)角度便于管理。但是我們也需要協(xié)調(diào)組件，使其有助于解決業(yè)務(wù)問(wèn)題。這就產(chǎn)生了某種形式的耦合。因此，上述舊模式就不斷重新冒出來(lái)。新的架構(gòu)和工具為解決這些問(wèn)題提供了適當(dāng)?shù)姆椒?#xff0c;但這需要刻意去理解如何正確地使用它們，而不僅僅是使用嶄新的技術(shù)去重新實(shí)現(xiàn)舊模式。

?

持之以恒的工程實(shí)踐

隨著技術(shù)創(chuàng)新步伐加快，新技術(shù)的發(fā)展呈現(xiàn)出一種從爆發(fā)到沉淀不斷循環(huán)的模式。每當(dāng)能夠顛覆我們對(duì)軟件開(kāi)發(fā)固有認(rèn)知的新技術(shù)出現(xiàn)時(shí)，都會(huì)引起業(yè)界的爭(zhēng)相追捧，容器化、響應(yīng)式前端和機(jī)器學(xué)習(xí)都是很好的例子。這時(shí)技術(shù)處在爆發(fā)階段。然而，只有在明確如何與長(zhǎng)期以來(lái)的工程實(shí)踐（持續(xù)交付、測(cè)試、協(xié)作等）相結(jié)合之后，新技術(shù)才能真正的發(fā)揮功效，并進(jìn)入沉淀階段，為下一次爆發(fā)性擴(kuò)張打下堅(jiān)實(shí)的基礎(chǔ)。在沉淀階段，我們嘗試在新技術(shù)的背景下應(yīng)用實(shí)踐，比如進(jìn)行全面的自動(dòng)化測(cè)試以及創(chuàng)建腳本代替重復(fù)操作，通常也會(huì)創(chuàng)造出新的開(kāi)發(fā)工具。雖然表面看來(lái)技術(shù)創(chuàng)新是行業(yè)發(fā)展的唯一驅(qū)動(dòng)力，但事實(shí)上，創(chuàng)新與持之以恒的工程實(shí)踐相結(jié)合才是我們不斷進(jìn)步的基礎(chǔ)。

?

速度 = 距離 / 時(shí)間

通常，我們會(huì)選取本期雷達(dá)中部分共性條目的精彩集錦展現(xiàn)在雷達(dá)主題中，但本主題涉及自技術(shù)雷達(dá)誕生以來(lái)出現(xiàn)過(guò)的所有條目。我們發(fā)現(xiàn)（并通過(guò)一些調(diào)研證明）雷達(dá)條目停留在雷達(dá)上的時(shí)間正在縮減。當(dāng)我們?cè)?10 年前啟動(dòng)技術(shù)雷達(dá)時(shí)，如果某個(gè)條目在雷達(dá)上的位置不再移動(dòng)，它依然會(huì)保留兩期（大約一年）時(shí)間，之后才會(huì)自動(dòng)移出雷達(dá)。然而正如標(biāo)題中的公式所說(shuō)，速度 = 距離 / 時(shí)間：軟件開(kāi)發(fā)生態(tài)系統(tǒng)中的變化一直在持續(xù)加速。在時(shí)間保持不變（依然是每年發(fā)布兩次）的前提下，雷達(dá)中技術(shù)創(chuàng)新所跨越的距離明顯地增大了。這為精明的讀者提供了顯著的證據(jù)：技術(shù)變革的步伐正在不斷加快。我們不僅看到雷達(dá)中的各個(gè)象限在加速變化，也看到了客戶(hù)對(duì)新興的及多樣化的技術(shù)選擇所表現(xiàn)出的興趣。因此我們將改變傳統(tǒng)的默認(rèn)模式：雷達(dá)不再默認(rèn)保留其上的條目，它們是否出現(xiàn)在雷達(dá)上完全取決于它們當(dāng)前的價(jià)值。我們?cè)谏钏际鞈]后做出了這項(xiàng)改變，并認(rèn)為只有這樣才能更好地跟上技術(shù)生態(tài)系統(tǒng)中前所未有的狂熱變化節(jié)奏。

?

象限亮點(diǎn)搶先看

Event Storming（事件風(fēng)暴）?

快速市場(chǎng)響應(yīng)能力是組織進(jìn)行微服務(wù)轉(zhuǎn)型的主要驅(qū)動(dòng)之一。然而只有沿長(zhǎng)期業(yè)務(wù)領(lǐng)域邊界對(duì)服務(wù)（及其支持團(tuán)隊(duì)）進(jìn)行清晰劃分時(shí)，這種期望才可能實(shí)現(xiàn)。否則，現(xiàn)實(shí)需求只有在跨組織和跨服務(wù)的通力合作才下能完成，這自然會(huì)在規(guī)劃產(chǎn)品路線(xiàn)圖時(shí)產(chǎn)生沖突。良好的領(lǐng)域模型設(shè)計(jì)是解決此問(wèn)題的方案，事件風(fēng)暴（EVENT STORMING）也迅速成為我們最喜愛(ài)的方法之一，它使我們能夠迅速識(shí)別問(wèn)題領(lǐng)域中的關(guān)鍵概念，并用最好的方式與各方利益相關(guān)人制定解決方案。

?

Microservice Envy

微服務(wù)已成為現(xiàn)代云計(jì)算系統(tǒng)中的領(lǐng)先的架構(gòu)模式，但我們依舊認(rèn)為團(tuán)隊(duì)在使用該架構(gòu)時(shí)應(yīng)謹(jǐn)慎。 MICROSERVICE ENVY 特指那些盲目追趕微服務(wù)潮流的現(xiàn)象，很多團(tuán)隊(duì)在實(shí)踐微服務(wù)時(shí)并沒(méi)有簡(jiǎn)化其系統(tǒng)架構(gòu)，大多數(shù)的實(shí)踐方案只是將一些簡(jiǎn)單的服務(wù)聚合在一起而已。目前，Kubernetes 等平臺(tái)簡(jiǎn)化了復(fù)雜的微服務(wù)系統(tǒng)的部署問(wèn)題，其他服務(wù)提供商們也正在推進(jìn)他們的微服務(wù)治理方案，這些強(qiáng)大的工具都可能裹挾團(tuán)隊(duì)走上微服務(wù)之路。 但請(qǐng)千萬(wàn)謹(jǐn)記，微服務(wù)是通過(guò)開(kāi)發(fā)復(fù)雜度來(lái)?yè)Q取運(yùn)維復(fù)雜度，并需要自動(dòng)化測(cè)試、持續(xù)交付和 DevOps 文化提供堅(jiān)實(shí)的支撐。

?

Observability as Code（可觀測(cè)性即代碼）

可觀測(cè)性是運(yùn)轉(zhuǎn)分布式系統(tǒng)與微服務(wù)架構(gòu)必不可少的一部分。我們依賴(lài)不同的系統(tǒng)輸出來(lái)推斷分布式組件的內(nèi)部狀態(tài)，比如分布式追蹤、日志聚合、系統(tǒng)指標(biāo)等，進(jìn)而診斷問(wèn)題所在，并找到根本原因。可觀測(cè)性生態(tài)系統(tǒng)的一個(gè)重要方面就是監(jiān)控——可視化以及分析系統(tǒng)的輸出——并且在檢測(cè)到異常時(shí)報(bào)警。傳統(tǒng)的監(jiān)控報(bào)警配置，都是通過(guò)圖形界面的操作完成。這種方法導(dǎo)致控制面板頁(yè)的配置不可重復(fù)，從而無(wú)法持續(xù)測(cè)試和調(diào)整報(bào)警，來(lái)避免報(bào)警疲勞或錯(cuò)過(guò)重要的報(bào)警，進(jìn)而偏離組織的最佳實(shí)踐。我們強(qiáng)烈建議使用代碼來(lái)配置可觀測(cè)性生態(tài)系統(tǒng)，稱(chēng)為可觀測(cè)性即代碼（OBSERVABILITY AS CODE），并且采取基礎(chǔ)設(shè)施即代碼的方式搭建其基礎(chǔ)設(shè)施。因此，在選擇提供可觀測(cè)性的工具時(shí)，要選擇支持通過(guò)代碼版本控制進(jìn)行配置，并能通過(guò)基礎(chǔ)設(shè)施持續(xù)交付流水線(xiàn)執(zhí)行 API 或命令行的產(chǎn)品。可觀測(cè)性即代碼，是基礎(chǔ)設(shè)施即代碼中經(jīng)常被遺漏的一部分，我們認(rèn)為這一點(diǎn)非常重要，需要明確指出。

?

Four key metrics（四個(gè)關(guān)鍵指標(biāo)）

2014 年首次發(fā)布的 DevOps 狀態(tài)報(bào)告指出，高效團(tuán)隊(duì)創(chuàng)造了高效的組織。最近，該報(bào)告背后的團(tuán)隊(duì)編寫(xiě)了 Accelerate 一書(shū)，描述了他們?cè)趫?bào)告中使用的科學(xué)方法。兩份材料的核心點(diǎn)都支持了軟件交付性能的四個(gè)關(guān)鍵指標(biāo)（FOUR KEY METRICS）：前置時(shí)間，部署頻率，平均恢復(fù)時(shí)間（MTTR）和變更失敗百分比。作為幫助許多組織轉(zhuǎn)型的咨詢(xún)公司，反復(fù)使用這些指標(biāo)測(cè)量，可以幫助組織確定他們是否在提高整體效能。每個(gè)指標(biāo)都創(chuàng)造了一個(gè)良性循環(huán)，并使團(tuán)隊(duì)專(zhuān)注于持續(xù)改進(jìn)：縮短交付周期，減少浪費(fèi)的活動(dòng)，從而使你可以更頻繁地部署；部署頻率迫使你的團(tuán)隊(duì)改進(jìn)他們的實(shí)踐和自動(dòng)化流程；通過(guò)更好的實(shí)踐，自動(dòng)化和監(jiān)控可以提高你從故障中恢復(fù)的速度，從而降低故障頻率。

?

Run cost as architecture fitness function（架構(gòu)適應(yīng)度函數(shù)）

隨著軟件架構(gòu)及其業(yè)務(wù)的演進(jìn)，我們理應(yīng)密切關(guān)注應(yīng)用的運(yùn)行成本，但發(fā)現(xiàn)并非所有的組織都如此。尤其是在使用無(wú)服務(wù)器架構(gòu)時(shí)，開(kāi)發(fā)者們認(rèn)為無(wú)服務(wù)器架構(gòu)會(huì)更便宜，因?yàn)樗麄冎恍璋聪牡挠?jì)算時(shí)間付費(fèi)。然而幾家主要的云服務(wù)提供商在熱門(mén)的無(wú)服務(wù)器函數(shù)上定價(jià)十分精明，雖然無(wú)服務(wù)器在快速迭代上很有優(yōu)勢(shì)，但與專(zhuān)屬云（或內(nèi)部私有云）相比，它的開(kāi)銷(xiāo)可能隨著使用量迅速增長(zhǎng)。我們建議團(tuán)隊(duì)將應(yīng)用的運(yùn)行成本納入架構(gòu)適應(yīng)度函數(shù)（RUN COST AS ARCHITECTURE FITNESS FUNCTION）來(lái)考量，這意味著：追蹤并權(quán)衡應(yīng)用的運(yùn)行成本與交付價(jià)值；當(dāng)它們之間產(chǎn)生較大出入時(shí)，就需要考慮改進(jìn)軟件架構(gòu)了。

?

Debezium?

DEBEZIUM 是一個(gè) change data capture (CDC) 平臺(tái)，可以將數(shù)據(jù)庫(kù)的變更以流的形式傳入 Kafka 主題中。CDC 是一種流行的技術(shù)，具有多個(gè)使用場(chǎng)景，包括將數(shù)據(jù)復(fù)制到其他數(shù)據(jù)庫(kù)中，為分析系統(tǒng)提供數(shù)據(jù)，從單塊系統(tǒng)中提取微服務(wù)，以及令緩存數(shù)據(jù)無(wú)效等。我們一直在尋找這個(gè)領(lǐng)域的工具或平臺(tái)（包括在之前的技術(shù)雷達(dá)中討論過(guò)的 Bottled Water），而 Debezium 是一個(gè)極佳的選擇。它使用了基于日志的 CDC 方法，意味著能以對(duì)數(shù)據(jù)庫(kù)日志文件的變更進(jìn)行響應(yīng)的方式進(jìn)行工作。Debezium 使用了 Kafka 連接，這使得它具有高度的容量伸縮性，以及對(duì)故障的系統(tǒng)韌性。它擁有包括 Postgres、Mysql 和 MongoDB 在內(nèi)的多個(gè)數(shù)據(jù)庫(kù)的 CDC 連接器。目前，我們正在一些項(xiàng)目上使用該平臺(tái)，并取得了很好的效果。

?

Quorum

在區(qū)塊鏈技術(shù)領(lǐng)域，Ethereum(以太坊) 是一個(gè)領(lǐng)先的開(kāi)發(fā)者生態(tài)系統(tǒng)。我們看到了一些新興的解決方案，它們旨在將 Ethereum 這項(xiàng)技術(shù)傳播到一些企業(yè)環(huán)境中。這些企業(yè)通常需要網(wǎng)絡(luò)權(quán)限和交易隱私管理，另外還需要更高的吞吐量和更低的延遲。

QUORUM 就是其中的一個(gè)解決方案。Quorum 最初由 J.P. Morgan 開(kāi)發(fā)，其定位是“企業(yè)版的 Ethereum”。與創(chuàng)建了新的以太坊虛擬機(jī)（EVM）的 Hyperledger Burrow 節(jié)點(diǎn)不同，Quorum 的代碼源自以太坊官方客戶(hù)端的一個(gè)分支，所以能與以太坊一起進(jìn)化。在保留了以太坊賬本的大多數(shù)功能的前提下，Quorum 將共識(shí)協(xié)議從工作量證明機(jī)制更改為更高效的協(xié)議，并增加了私有交易支持。使用 Quorum，開(kāi)發(fā)人員可以使用他們的以太坊知識(shí)來(lái)構(gòu)建企業(yè)級(jí)的區(qū)塊鏈應(yīng)用，這些知識(shí)包括 Solidity 語(yǔ)言和 Truffle 合約。

然而根據(jù)我們的經(jīng)驗(yàn)，Quorum 還沒(méi)有為應(yīng)用于企業(yè)做好充足的準(zhǔn)備；比如：它缺乏針對(duì)私有合約的訪(fǎng)問(wèn)控制機(jī)制，無(wú)法用于負(fù)載均衡，并且只支持部分?jǐn)?shù)據(jù)庫(kù)。所有的這些限制都為用戶(hù)的部署與設(shè)計(jì)帶來(lái)顯著的負(fù)擔(dān)。我們建議在使用 Quorum 的時(shí)候保持警惕，同時(shí)密切關(guān)注它的后續(xù)發(fā)展。

?

IPFS

在多數(shù)情況下，區(qū)塊鏈不適合存儲(chǔ) blob 文件 (例如：圖像，音頻)，當(dāng)人們開(kāi)發(fā) DApp 時(shí)，一種選擇是將 blob 文件存放在一些鏈下的集中式數(shù)據(jù)存儲(chǔ)中，這種做法通常會(huì)導(dǎo)致信任缺失，另一種選擇是將它們存儲(chǔ)在星際文件系統(tǒng) IPFS 上，這是一種內(nèi)容可尋址、版本化、點(diǎn)對(duì)點(diǎn)的文件系統(tǒng)。它旨在高效地分發(fā)大規(guī)模數(shù)據(jù)，并能阻止任何中心化機(jī)構(gòu)刪除數(shù)據(jù)，文件存儲(chǔ)在不需要相互信任的對(duì)等節(jié)點(diǎn)上。IPFS 保存文件的每一個(gè)版本，這樣你將永遠(yuǎn)不會(huì)丟失重要文件，我們將 IPFS 視為區(qū)塊鏈技術(shù)的好的補(bǔ)充。除了區(qū)塊鏈應(yīng)用程序外，IPFS 還有一個(gè)愿景是對(duì)現(xiàn)有的網(wǎng)絡(luò)基礎(chǔ)設(shè)施進(jìn)行去中心化重塑。

?

Resin.io

RESIN.IO 是一個(gè)物聯(lián)網(wǎng)（IoT）平臺(tái)。雖然只做把容器部署到設(shè)備中這一件事，但它做得很好。開(kāi)發(fā)人員使用一個(gè)軟件即服務(wù)（ SaaS）的門(mén)戶(hù)來(lái)管理設(shè)備，并為這些設(shè)備分發(fā)由 Dockerfile 定義的應(yīng)用。該平臺(tái)可以為多種硬件類(lèi)型構(gòu)建容器，并通過(guò)無(wú)線(xiàn)的方式部署容器鏡像。Resin.io 使用 balena 來(lái)管理容器。而 balena 是一個(gè)基于 Mobby 框架的容器引擎，由 Docker 出品。該平臺(tái)仍在開(kāi)發(fā)中，有些功能尚需完善，也缺少一些特性（比如與私有容器注冊(cè)服務(wù)協(xié)同工作）。

?

Knative

作為應(yīng)用開(kāi)發(fā)者，我們喜歡專(zhuān)心解決核心業(yè)務(wù)問(wèn)題，而讓底層平臺(tái)來(lái)處理那些枯燥且困難的任務(wù)（如部署、容量伸縮及應(yīng)用程序管理）。雖然無(wú)服務(wù)器架構(gòu)往這個(gè)方向邁出了一步，然而大多數(shù)流行的產(chǎn)品都會(huì)與某個(gè)專(zhuān)有實(shí)現(xiàn)綁在一起。而這意味著供應(yīng)商綁定。KNATIVE 試圖以開(kāi)源無(wú)服務(wù)器平臺(tái)的方式來(lái)解決此問(wèn)題。它良好地集成了流行的 Kubernetes 生態(tài)系統(tǒng)。利用 Knative ，可以對(duì)隨時(shí)請(qǐng)求的計(jì)算進(jìn)行建模（其間可以從一些框架中進(jìn)行選擇，如 Ruby on Rails、Django 和 Spring 等），可以訂閱、交付和管理事件，可以集成用戶(hù)所熟悉的 CI 和 CD 工具，可以從源代碼構(gòu)建出容器。該平臺(tái)提供一組中間件組件，來(lái)構(gòu)建以源代碼為中心且基于容器（能夠?qū)崿F(xiàn)資源伸縮性）的應(yīng)用。這使得它成為一個(gè)頗有吸引力的平臺(tái)，當(dāng)有無(wú)服務(wù)器需求時(shí)，值得對(duì)其進(jìn)行評(píng)估。

?

Apache Atlas

隨著企業(yè)數(shù)據(jù)需求的不斷增長(zhǎng)和多樣化，對(duì)元數(shù)據(jù)管理的需求也在不斷地增長(zhǎng)。APACHE ATLAS 是一款用于滿(mǎn)足企業(yè)數(shù)據(jù)治理需求的元數(shù)據(jù)管理框架。Atlas 支持元數(shù)據(jù)類(lèi)型建模、數(shù)據(jù)資產(chǎn)分類(lèi)、數(shù)據(jù)來(lái)源追蹤和數(shù)據(jù)發(fā)現(xiàn)。但是，在搭建元數(shù)據(jù)管理平臺(tái)的時(shí)候，我們也必須小心避免重蹈主數(shù)據(jù)管理的覆轍。

?

Cypress?

運(yùn)行端到端測(cè)試時(shí)經(jīng)常會(huì)遇到一些棘手的問(wèn)題，比如運(yùn)行時(shí)間過(guò)長(zhǎng)，測(cè)試過(guò)于零碎，還需要修復(fù)無(wú)頭模式下運(yùn)行的測(cè)試所導(dǎo)致的 CI 失敗。我們的團(tuán)隊(duì)借助 CYPRESS 很好地解決了性能差、響應(yīng)時(shí)間長(zhǎng)、資源加載慢等常見(jiàn)問(wèn)題。Cypress 是一款很有用的工具，可以幫助開(kāi)發(fā)者構(gòu)建端到端測(cè)試，還可以將所有測(cè)試步驟保存為 MP4 視頻，便于檢查錯(cuò)誤。

?

VS Live Share

VISUAL STUDIO CODE 是微軟推出的免費(fèi) IDE 編輯器，可以跨平臺(tái)使用。我們?cè)盟瑫r(shí)進(jìn)行前端 React、TypeScript 和后端 GoLang 的開(kāi)發(fā)，而無(wú)需在不同的編輯器之間切換，體驗(yàn)很好。 Visual Studio Code 中的工具、語(yǔ)言支持和擴(kuò)展插件數(shù)量都在迅猛增長(zhǎng)，也越來(lái)越好用。我們要特別推薦在實(shí)時(shí)協(xié)作及遠(yuǎn)程結(jié)對(duì)編程時(shí)使用 VS Live Share 。固然微軟或 Jetbrains 成熟的 IDE 對(duì)使用靜態(tài)類(lèi)型語(yǔ)言（如 Java 、 .NET 或 C++ ）的復(fù)雜項(xiàng)目支持得更好，但我們也發(fā)現(xiàn) Visual Studio Code 正逐漸成為基礎(chǔ)設(shè)施開(kāi)發(fā)組和前端開(kāi)發(fā)組的首選工具。

?

Stanford CoreNLP

越來(lái)越多的項(xiàng)目需要處理非結(jié)構(gòu)化的數(shù)據(jù)，而從文本中提取出有意義的業(yè)務(wù)信息是一項(xiàng)關(guān)鍵技術(shù)。 STANFORD CORENLP 是一組基于 Java 的自然語(yǔ)言處理（NLP）工具集，支持英語(yǔ)、漢語(yǔ)和阿拉伯語(yǔ)等多種語(yǔ)言的命名實(shí)體識(shí)別、關(guān)系抽取、情感分析與文本分類(lèi)，也提供了用于標(biāo)記語(yǔ)料庫(kù)和訓(xùn)練模型的工具。 Stanford CoreNLP 協(xié)助我們使用 NLP 領(lǐng)域的最新研究成果來(lái)解決各種業(yè)務(wù)問(wèn)題。

?

LocalStack

使用云服務(wù)時(shí)面對(duì)的一個(gè)挑戰(zhàn)是如何在本地進(jìn)行開(kāi)發(fā)和測(cè)試。 LOCALSTACK 為 AWS 解決了這個(gè)問(wèn)題。它提供了各種 AWS 服務(wù)的本地 測(cè)試替身 實(shí)現(xiàn)，包括 S3 、 Kinesis 、Dynamodb 和 Lambda 等。它基于現(xiàn)有的最佳工具如 Kinesalite 、 Dynalite 、 Moto 等構(gòu)建，并增加了進(jìn)程隔離與錯(cuò)誤注入的功能。 LocalStack 的使用很簡(jiǎn)單，并附帶了一個(gè)簡(jiǎn)單的 JUnit 運(yùn)行器以及 JUnit 5 擴(kuò)展。我們?cè)谝恍╉?xiàng)目中使用過(guò) LocalStack ，并對(duì)它印象深刻。

?

Bitrise

構(gòu)建、測(cè)試和部署移動(dòng)應(yīng)用，尤其是由一條流水線(xiàn)從代碼倉(cāng)庫(kù)打通到應(yīng)用商店的時(shí)候，會(huì)涉及許多復(fù)雜的步驟。雖然這些步驟可以由腳本或普通 CI/CD 工具提供的流水線(xiàn)自動(dòng)完成，但對(duì)于專(zhuān)注移動(dòng)應(yīng)用開(kāi)發(fā)，而不需要與后端的構(gòu)建流水線(xiàn)做集成的小組來(lái)說(shuō)，使用專(zhuān)用工具可以降低復(fù)雜度和維護(hù)開(kāi)銷(xiāo)。 BITRISE 配置簡(jiǎn)單，并預(yù)置了一組完整的步驟，可以滿(mǎn)足絕大多數(shù)移動(dòng)應(yīng)用開(kāi)發(fā)所需。

?

PredictionIO

PREDICTIONIO 是開(kāi)源的機(jī)器學(xué)習(xí)服務(wù)框架。無(wú)論是普通開(kāi)發(fā)者還是數(shù)據(jù)科學(xué)家，都可以利用它創(chuàng)建用于預(yù)測(cè)的智能應(yīng)用。和所有其他智能應(yīng)用類(lèi)似，PredictionIO 由三個(gè)部分組成：數(shù)據(jù)收集和存儲(chǔ)、模型訓(xùn)練以及模型部署和服務(wù)暴露。開(kāi)發(fā)者只需要基于它提供的相應(yīng)接口實(shí)現(xiàn)數(shù)據(jù)處理邏輯、模型算法和預(yù)測(cè)邏輯，無(wú)需在諸如存儲(chǔ)數(shù)據(jù)以及訓(xùn)練模型之類(lèi)的事情上投入額外精力。從我們的經(jīng)驗(yàn)來(lái)看，在不要求高并發(fā)處理的情況下，PredictionIO 能支持不同大小的數(shù)據(jù)集。

?

Q#

量子計(jì)算目前已經(jīng)可供測(cè)試，但何時(shí)真正到來(lái)尚未明確。在硬件到位之前，我們已經(jīng)可以通過(guò)語(yǔ)言和模擬器來(lái)實(shí)驗(yàn)和學(xué)習(xí)它。盡管 IBM 等公司已經(jīng)取得了不錯(cuò)的進(jìn)展，我們對(duì)微軟在 Q＃ 語(yǔ)言及其模擬器（本地 32 量子比特，Azure 云上 40 量子比特）方面的工作更加關(guān)注。如果你想開(kāi)始了解這項(xiàng)編程的前景，請(qǐng)查看他們?cè)?GitHub 上的范例。

?

MockK

MockK 是用 Kotlin 編寫(xiě)的模擬庫(kù)。它的核心理念是像 Coroutines 和 Lambda 表達(dá)式一樣，為 Kotlin 提供一等公民級(jí)別的語(yǔ)言特性支持。不同于 Mockito 或 PowerMock 的蹩腳封裝，作為原生的開(kāi)發(fā)庫(kù)，它能幫助開(kāi)發(fā)團(tuán)隊(duì)在測(cè)試 Kotlin 應(yīng)用時(shí)編寫(xiě)干凈、簡(jiǎn)潔的代碼。

?

WebFlux

Spring Framework 5 已發(fā)布一年有余，它采用了響應(yīng)式流 —— 一套非阻塞背壓（backpressure）式異步流式處理標(biāo)準(zhǔn)。在傳統(tǒng)的 Spring MVC 模塊之外，WEBFLUX 為在 Spring 生態(tài)下編寫(xiě) Web 應(yīng)用提供了一個(gè)響應(yīng)式替代品。經(jīng)過(guò)一系列應(yīng)用的試用，WebFlux 給我們的團(tuán)隊(duì)留下了深刻的印象，并匯報(bào)說(shuō)這種響應(yīng)式（函數(shù)式）實(shí)現(xiàn)增強(qiáng)了代碼的可讀性和系統(tǒng)的吞吐量。但他們也確實(shí)注意到，采用 WebFlux 需要在思維方式上做出一些重大轉(zhuǎn)變，建議在 WebFlux vs. Spring MVC 的技術(shù)選型中考慮這一點(diǎn)。

?

Jepsen

隨著 微服務(wù) 架構(gòu)越來(lái)越多地被采用，相比以前，我們構(gòu)建了更多的分布式應(yīng)用程序。盡管解耦架構(gòu)帶來(lái)了許多好處，但證明整個(gè)系統(tǒng)正確性所需的工作量和復(fù)雜程度正急劇增加。 JEPSEN 提供了許多我們所需要的工具，來(lái)幫助我們驗(yàn)證協(xié)調(diào)任務(wù)調(diào)度程序的正確性，測(cè)試分布式數(shù)據(jù)庫(kù)的最終一致性、 線(xiàn)性一致性 （ Linearizability）和 可串行性（Serializability）。我們?cè)谝恍╉?xiàng)目中使用了 Jepsen，令人驚喜的是，我們可以測(cè)試驅(qū)動(dòng)配置，注入和修復(fù)故障，驗(yàn)證系統(tǒng)恢復(fù)后的狀態(tài)。

總結(jié)

以上是生活随笔為你收集整理的从程序员到CTO都应该了解的一些技术趋势的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。