第 62 屆早早聊大會將于 2023 年 4 月 8 日（本周六）舉辦 - Node.js｜前后都干 加薪神棧，6 位講師全天直播，關(guān)鍵詞：異常定位/海量日志/創(chuàng)業(yè)落地/V8 Worker/RPC 服務(wù)。 上車鏈接：https://www.zaozao.run/conf/c62

本文是 2021 年 12 月 26 日，第三十五屆 - 前端早早聊【前端搞 Node.js】專場，來自阿里巴巴的終端高級技術(shù)專家 —— 秦粵的分享。感謝 AI 的發(fā)展，借助 GPT 的能力，最近我們終于可以非常高效地將各位講師的精彩分享文本化后，分享給大家。（完整版含演示請看錄播視頻和 PPT）：https://www.zaozao.run/video/c35

正文如下

大家好，今天給大家分享的主題是《浮華過后的 Node.js》。我先簡單介紹一下自己：我是極客時間《Serverless 入門課》專欄講師，同時，我擔(dān)任阿里巴巴前端委員會-標(biāo)準(zhǔn)化方向的負(fù)責(zé)人，參與低代碼和 Node.js 方向的共建，也是阿里設(shè)計(jì)效率中臺 D-One 的負(fù)責(zé)人，并且還是 W3C、ECMA-TC39、JSCIG 的成員。

前言

大家可以看到，我所從事的工作范圍非常廣泛，準(zhǔn)確來說，我是一名全棧工程師。但現(xiàn)在，我開始轉(zhuǎn)向管理方向。因?yàn)槲也淮_定大家的認(rèn)知基礎(chǔ)如何，所以在介紹今天的內(nèi)容之前，我會先分享一些共識，以確保大家都能理解。

第一，我想分享的是關(guān)于 Node.js 在服務(wù)端運(yùn)行的場景。此部分內(nèi)容將不涉及 Node.js 用于 CLI 工具或開發(fā)端工具的方面。

第二，我想討論的是企業(yè)級應(yīng)用的定義。企業(yè)級應(yīng)用通常是指為大型企業(yè)或商業(yè)組織創(chuàng)建和部署的解決方案和應(yīng)用。在設(shè)計(jì)企業(yè)級應(yīng)用時，需要考慮到可能訪問的 PV/UV 比較大、事務(wù)密集、數(shù)據(jù)量大、用戶多以及安全性等方面。

第三，我想分享的是鄧寧-克魯格效應(yīng)，它是人類學(xué)習(xí)新事物或認(rèn)知新事物時的一種認(rèn)知偏見，分為五個階段：

• 第一個階段是一無所知

• 第二個階段是愚民之峰

• 第三個階段是絕望之谷

• 第四個階段是啟蒙爬坡

• 第五個階段是持續(xù)平原

人在認(rèn)知一個新的事物或?qū)W習(xí)過程中，通常都會經(jīng)歷一個類似曲線的過程。比如，當(dāng)你開始學(xué)習(xí) Node.js 時，剛開始的時候你對它會有很高的期望，但實(shí)際情況可能與你的預(yù)期相差很大，可能會發(fā)現(xiàn)有些東西 Node.js 做不了，或者需要很復(fù)雜的操作。這時候可能會感到一種低谷，但是隨著不斷的學(xué)習(xí)和投入，你會出現(xiàn)一個比較高速的爬升過程，也就是啟蒙爬坡。當(dāng)你掌握 Node.js 的能力越來越熟練時，如果想要將其應(yīng)用于生產(chǎn)環(huán)境中，你會發(fā)現(xiàn)這中間還存在很大的跨度，這時候需要花費(fèi)很長時間才能緩慢提升。這種過程就像是絕望之谷中的及格線 60 分，從 0 分到 60 分相對較容易。但是要從 90 分到 100 分，你可能需要花費(fèi)更多的時間去學(xué)習(xí)和彌補(bǔ)自己的知識盲區(qū)。

第四，我分享的內(nèi)容是關(guān)于 Gartner 這家著名的技術(shù)咨詢公司。他們每年都會提供很多技術(shù)方案，其中包括一個我們很關(guān)注的技術(shù)成熟度曲線。這個曲線實(shí)際上來自于鄧寧-克魯格效應(yīng)，用于描述新技術(shù)的發(fā)展過程，包括從啟動期到高峰期再到低谷期，最后進(jìn)入產(chǎn)品化的平緩期。他們每年都會發(fā)布這樣的技術(shù)成熟度曲線，以便大家了解當(dāng)前技術(shù)處于哪個階段。

Scott 讓我分享關(guān)于 Node.js 的內(nèi)容，起初我是有所拒絕的。但是當(dāng)我看到知乎上的這篇文章《2021 Node.js 涼透了嗎？》時，我非常氣憤，所以我決定做此次分享。實(shí)際上，Node.js 并沒有失去它的魅力。雖然它現(xiàn)在處于產(chǎn)品化的平緩期，就像我們之前提到的那張圖所展示的那樣。可能許多人感覺近些年來沒有什么新的進(jìn)展和消息，這讓一些人覺得 Node.js 的存在感變得有些弱，但事實(shí)并非如此。

目前 Node.js 處于產(chǎn)品化的平緩期，主要在做底層穩(wěn)定性的改進(jìn)，使其更適用于企業(yè)級應(yīng)用開發(fā)。此外，還有很多基礎(chǔ)建設(shè)正在進(jìn)行中。 Node.js 技術(shù)的歷程可以追溯到 2009 年 Ryan 發(fā)布，2010 年到達(dá)高峰，包括 Express 等框架的推出讓其大火一把。在 2012 年 Ryan 離開后，到 2014 年 IO.js 出現(xiàn)，整個生態(tài)處于低谷。但是在 2015 年，ES6、IO Merge 的回歸，以及 Node FA 的成立，讓整個生態(tài)經(jīng)歷了快速提升。近年來增長速度有所減緩，但整個 Node.js 生態(tài)依然非常良好。之所以進(jìn)入平緩期，待會會講到。

在 2018 年，有一個叫做 Node.js 地下鐵沙龍的活動，很多 Node.js 的從業(yè)者都參加了。在成都站時，現(xiàn)場提出了一個問題，「Node.js 是否具備企業(yè)級能力」。當(dāng)時，我分享了一些關(guān)于 Node.js 做后端微服務(wù)的經(jīng)驗(yàn)，我是感覺到 Node.js 和 Java 相比還存在一些差距。在 SDK 層面，Node.js 和 Java 相比，在中間件等方面還有很大的差距。三年后的今天，「Node.js 是否具備企業(yè)級能力」，仍是大家討論話題。第 62 屆早早聊大會 - Node.js 專場，也將于 2023 年 4 月 8 日（本周六）舉辦，歡迎小伙伴一起來討論 Node.js，上車鏈接：https://www.zaozao.run/conf/c62

在 2019 年，阿里的 Node.js 小組 - NASA 開始進(jìn)行 All-in-Serverless 的基礎(chǔ)建設(shè)，這件事情也非常受歡迎，很多 Node.js 人都參與進(jìn)去了，大家的參與度非常高。

Node.js 在現(xiàn)在的發(fā)展中處于怎樣的狀態(tài)？為什么大家很少聽到阿里的一些 Serverless 方向建設(shè)的消息呢？希望大家能夠帶著這些問題來參加今天的分享。

今天的分享主要分為三個部分：

• 第一部分是關(guān)于 Node.js 企業(yè)級應(yīng)用賽道的講解

• 第二部分是關(guān)于 CNCF 的 Game Changer

• 第三部分則是關(guān)于生態(tài)的穩(wěn)定與繁榮

Node.js 企業(yè)級應(yīng)用賽道

首先，我們進(jìn)入第一個部分，即 Node.js 企業(yè)級應(yīng)用賽道。這個賽道已經(jīng)非?；馃崃耍偁幏浅＜ち?，可以說已經(jīng)進(jìn)入了白熱化的狀態(tài)。如果要做一個企業(yè)級應(yīng)用，我們首先需要看一下框架生態(tài)與語言。

在左邊是我們的研發(fā)態(tài)，在右邊則是我們的運(yùn)行態(tài)。對于大部分的前端同學(xué)來說，他們在前端領(lǐng)域工作，而對于后端同學(xué)來說，則需要關(guān)注 Node.js 在服務(wù)端的運(yùn)行情況。在研發(fā)過程中，我們會有一些腳手架、類型約束、業(yè)務(wù)邏輯 Code、生態(tài)包依賴、依賴框架、工程單測規(guī)范等等。

在運(yùn)行企業(yè)級應(yīng)用時，我們需要考慮的主要是變動層和語言層。變動層是指包括框架和第三方依賴等在內(nèi)的運(yùn)行態(tài)，而語言層則指編程語言本身。實(shí)際上，在運(yùn)行時我們并不需要太多的東西，因?yàn)槲覀冏约壕帉懙拇a只占很少的一部分，往往不到整個源代碼的 20%。大部分的代碼都來自于我們引入的框架和第三方依賴。因此，我們自己的代碼量相對較少，也只會對變動層產(chǎn)生影響。

變動層是一個高頻迭代的語言 SDK，因?yàn)樗枰l繁更新以適應(yīng)業(yè)務(wù)變更。相反，語言層的更新相對較少，通常只是為了跟 JavaScript 語言對齊或升級 V8 引擎，且是向下兼容的，不會帶來太多的問題，因此你不用擔(dān)心語言升級以后會出現(xiàn)斷崖式的更新，雖然也有，但是這個是非常少的。

在部署 Node.js 服務(wù)端運(yùn)行環(huán)境或企業(yè)級應(yīng)用時，我們最關(guān)心的是變動層，即我們自己編寫的代碼以及引入的生態(tài)依賴和框架。對于語言層，我們則相對放心一些。這是在企業(yè)級應(yīng)用中需要非常關(guān)注的兩個方面，即研發(fā)和運(yùn)行。然而，如果將 Node.js 放到后端運(yùn)行并放在整個企業(yè)級架構(gòu)中，我們需要與 Java 進(jìn)行對齊，這時會發(fā)現(xiàn)我們與 Java 之間的差距非常大。

當(dāng)我們在部署 Node.js 服務(wù)端應(yīng)用程序時，我們最擔(dān)心的是變動層，也就是我們自己編寫的代碼、生態(tài)和框架。相對而言，我們對語言更加放心，因?yàn)樗€(wěn)定。在企業(yè)級應(yīng)用程序中，我們需要非常關(guān)注開發(fā)和運(yùn)行兩個方面。如果將其放置于后端并放置在整個企業(yè)級架構(gòu)中，我們發(fā)現(xiàn)與 Java 相比還存在很大的差距和跨度。

Java 的生態(tài)能力非常強(qiáng)大，幾乎涵蓋了所有藍(lán)色方框中的服務(wù)。當(dāng)我們使用 Node.js 進(jìn)行開發(fā)時，我們需要追趕 Java 的 SDK。阿里招募了一些 Node.js 方面的專家來做這個事情，包括 Egg.js 框架和插件，以及為了追趕 Java 的能力而編寫的大量 SDK。

2023 年 4 月 8 日（本周六）將會舉辦第 62 屆早早聊大會 ?- Node.js 專場，6 位講師全天直播，為大家?guī)砀?Node.js 的應(yīng)用實(shí)戰(zhàn)，上車鏈接：https://www.zaozao.run/conf/c62

The Game Changer CNCF

我們看一下 The Game Changer CNCF。CNCF 的誕生是從 Docker 開始的，從研發(fā)階段到運(yùn)行階段，我們在之前的源代碼開發(fā)過程中，實(shí)際上缺少了很多重要信息。例如，進(jìn)程狀態(tài)，內(nèi)存狀態(tài)，是否會崩潰，而且如果崩潰了，誰來負(fù)責(zé)重啟它？因此，像 Egg.js 這樣的框架，作為框架本身，會單獨(dú)提供進(jìn)程模型，包括 worker、master 和 agent。因此，在原生狀態(tài)下，仍然需要擔(dān)心進(jìn)程問題。

如果你在服務(wù)端運(yùn)行復(fù)雜的 Node.js 應(yīng)用，你可能會擔(dān)心環(huán)境；如果你運(yùn)行的是復(fù)雜的 Node.js 包，你可能會擔(dān)心應(yīng)用對操作系統(tǒng)的底層包的依賴；如果操作系統(tǒng)升級或者更換，你可能會擔(dān)心應(yīng)用是否會崩潰。此外，使用 Node.js 很難引用其他語言的功能。Docker 的出現(xiàn)解決了這些問題，它可以提供一個獨(dú)立的運(yùn)行環(huán)境，使應(yīng)用與操作系統(tǒng)和其他依賴之間解耦，從而增加應(yīng)用的可靠性和可移植性。

在 Docker 出現(xiàn)之前，服務(wù)端部署的應(yīng)用都存在著環(huán)境差異、調(diào)試問題、擴(kuò)縮容困難等諸多難題，包括 Node.js。但是 Docker 的出現(xiàn)徹底改變了這一局面，Docker 是一個進(jìn)程模型，把運(yùn)行時環(huán)境隔離起來。

Docker 解決了一些重要的問題。首先，它讓本地和服務(wù)器端的環(huán)境一致性更強(qiáng)了，因?yàn)?Docker 的容器可以在不同的地方運(yùn)行。這解決了 Node.js 調(diào)試問題，因?yàn)椴挥脫?dān)心服務(wù)器端的環(huán)境是否和本地一樣。其次， Docker 的容器是一個進(jìn)程模型，擴(kuò)展和縮小非常簡單，你可以根據(jù)進(jìn)程的需求來調(diào)整容器，而不需要擔(dān)心 Node.js 如何去搶資源。并且，你可以在一臺計(jì)算機(jī)上部署多個容器。

Docker 的出現(xiàn)對服務(wù)端應(yīng)用開發(fā)帶來了重大變化，消除了許多心理負(fù)擔(dān)。此外，「邊車」也是一個相對容易理解的概念。在 Docker 中，我們只是將應(yīng)用程序放在容器中運(yùn)行，但是我們發(fā)現(xiàn)多種語言之間可以共享很多東西，不需要重復(fù)開發(fā)。例如，Java生態(tài)已經(jīng)非常豐富，而如果我們要將 Node.js 與 Java 在語言層面上對齊，需要編寫大量代碼。但是，如果我們直接調(diào)用 Java 語言，就會變得非常簡單。「邊車」的概念就是在 Docker 容器中部署一個 SideCar 進(jìn)程，它將 Docker 視為宿主，將 SideCar 部署在其中。

進(jìn)程提供各種能力，包括現(xiàn)在流行的 Dipper 也是這個概念。它將另一個進(jìn)程部署在容器中，除了你的 Node.js 應(yīng)用之外，同一個進(jìn)程還可以調(diào)用服務(wù)端的其他能力。這使得你的應(yīng)用更加簡單，只需要通過進(jìn)程間調(diào)用調(diào)用編車的能力。編車將提供流量控制和各種服務(wù)端能力，并通過轉(zhuǎn)發(fā)流量將其引入。因此，這里會產(chǎn)生一些概念，例如控制面板和數(shù)據(jù)面板。

使用 Docker 和 SideCar 的一個重要優(yōu)勢是可以讓原本的 Node.js 框架或者 SDK 變得更加簡單，只需要處理進(jìn)程間通信。此外，語言之間很多同質(zhì)化的工作也可以互相利用，比如利用 Java 的生態(tài)，只需將其部署到一個額外的進(jìn)程中。 Docker 和 SideCar 在 CNCF 中都是很重要的概念，Docker 是 CNCF 的基礎(chǔ)，但在 Docker 容器非常多時，就需要解決多容器管理的問題。Docker 公司自己推出了一些容器管理方案，例如 Docker Swarm 和 Docker Kube 之類的方案。

但真正讓整個格局產(chǎn)生改變，是谷歌推出的 Kubernetes，它把谷歌在服務(wù)器調(diào)度控制方面的能力進(jìn)行了抽象化，并且使用一種叫做 Pod 的概念來管理 Docker 容器，每個節(jié)點(diǎn)上的 Kubelet 有一堆的 Pod，Pod 里面再管理多個 Docker 容器。這樣，K8s 可以管理整個應(yīng)用的生命周期，包括應(yīng)用的生老病死。

基于 K8s 的服務(wù)端架構(gòu)能力解決了服務(wù)端部署的問題，并建立了一個龐大的生態(tài)系統(tǒng)?，F(xiàn)在 K8s 已經(jīng)成為了企業(yè)級應(yīng)用架構(gòu)的必備基礎(chǔ)設(shè)施，被稱為云端的操作系統(tǒng)。并且 K8s 支持組件插件的能力，也就是所謂的component。

目前，已經(jīng)出現(xiàn)了許多不同的解決方案，這些方案在 Docker 中是與編程語言無關(guān)的。不管你是用 Node.js、Java、PHP、Python 或其他語言編寫應(yīng)用，都可以通過這些方案進(jìn)行部署。因此，在 CNCF 的生態(tài)系統(tǒng)中，所有的開發(fā)語言都可以參與到共同建設(shè)中。雖然是針對某些開發(fā)語言，提供的是不同的邊車能力，但整個 CNCF 生態(tài)系統(tǒng)已經(jīng)具備了在服務(wù)端架構(gòu)方面所需的所有能力。

現(xiàn)在在服務(wù)端架構(gòu)中，各種問題的解決方案已經(jīng)應(yīng)運(yùn)而生，例如流量的限制、降級、壓測、灰度等等。這些解決方案都是開源的，所以無論是 Node.js 還是 Java 等應(yīng)用架構(gòu)，不再需要擔(dān)心這些問題。事實(shí)上，整個 Java 的生態(tài)也被徹底改變了。如果你仍在吹捧 Java，那說明你的視野太狹窄了。

CNCF 已經(jīng)成為企業(yè)級應(yīng)用架構(gòu)的最終目標(biāo)，但它唯一的缺點(diǎn)是太龐大且學(xué)習(xí)成本較高。如果你熟悉服務(wù)端的架構(gòu)設(shè)計(jì)和部署，只需要找到對應(yīng)的 CNCF 開源解決方案即可。在 CNCF 之上，一個問題是在服務(wù)端部署時，應(yīng)用需要有自己的生命周期視角。比如高流量進(jìn)入或高并發(fā)場景下，如何擴(kuò)容或縮容應(yīng)用。雖然 CNCF 提供了相關(guān)解決方案，但是它太復(fù)雜且不是從應(yīng)用視角出發(fā)的。因此，「Serverless」的概念應(yīng)運(yùn)而生。

在服務(wù)端架構(gòu)領(lǐng)域，Serverless 的概念比 CNCF 更早出現(xiàn)，但它們的視角不同。CNCF 正在建設(shè) Serverless 能力，將很多復(fù)雜的東西簡化，并提供一個應(yīng)用視角。阿里和微軟正在共建的 Knative 就是這樣一個方案，它具備應(yīng)用視角，同時可以依賴底層 Kubernetes 提供的能力。Knative 目前已經(jīng)進(jìn)入到 1.0 階段，并有望被 CNCF 采納。

隨著復(fù)雜度的進(jìn)一步下沉，其實(shí)框架的 SDK 變得更薄，Serverless 也處于穩(wěn)步快速爬升期，大家仍然可以參與共建。如果 Serverless 底層放在 CNCF 上面，那就會發(fā)現(xiàn)很多基礎(chǔ)建設(shè)都已經(jīng)被 CNCF 干掉了。CNCF 是一個強(qiáng)大的生態(tài)聯(lián)盟，企業(yè)級應(yīng)用架構(gòu)的基礎(chǔ)建設(shè)已經(jīng)被 CNCF 所覆蓋。CNCF 是基于 Docker 容器的，因此它與編程語言無關(guān)，這讓服務(wù)端部署應(yīng)用程序變得更加方便了，即使像 Java 這樣的語言也可以很方便地部署在 CNCF 上。

CNCF 是個 Linux 操作系統(tǒng)，與具體編程語言無關(guān)。它可以支持 PHP、Node.js、Java 等多種編程語言，逐漸取代了 Java 等過去自帶豐富語言生態(tài)的方案。如果想在這個生態(tài)中生存，你需要貢獻(xiàn)出你的開源解決方案，或者適應(yīng)其他語言的解決方案。每個解決方案中都有大量選擇，因此你需要學(xué)會擁抱 CNCF，而不僅是綁定在某種編程語言上。在企業(yè)級應(yīng)用架構(gòu)中使用 Node.js 時，不應(yīng)只局限于這種編程語言，而應(yīng)該學(xué)習(xí)和使用 CNCF 提供的能力和解決方案。

應(yīng)用的開發(fā)部署其實(shí)應(yīng)該優(yōu)先考慮 Serverless。這是因?yàn)?CNCF 是相對比較重的一個東西，引入它可能需要至少啟動三臺服務(wù)器或虛擬機(jī)，而這對于一些規(guī)模較小的應(yīng)用來說可能過于冗余。同時，框架層的設(shè)計(jì)也會變得越來越薄，因?yàn)槲覀冃枰幼⒅貞?yīng)用的開發(fā)和部署。

生態(tài)的繁榮與穩(wěn)定

最后我們來談一下生態(tài)的繁榮與穩(wěn)定。雖然我們引入了 CNCF，但是其中還存在一個潛在風(fēng)險，即 Node.js 代碼中經(jīng)常會引入生態(tài)包的依賴。在最近幾年，尤其是 Node.js 全球有這么多的開發(fā)者，它現(xiàn)在是一個受到黑客特別關(guān)注的語言，尤其是 npm 包，其整個安全事故處于一個高發(fā)階段。我們常見的一種情況是，原作者不想繼續(xù)維護(hù)一個庫，于是公開呼吁其他人接手。這時，惡意作者就會接手這個項(xiàng)目，并將自己的惡意代碼放入其中進(jìn)行發(fā)布。由于 Node.js 的代碼都是相互依賴和引用的，所以惡意代碼會快速傳播。

最近幾年，Node.js 的生態(tài)包的依賴和安全性問題一直存在，全球有很多開發(fā)者在使用，但同時也容易受到黑客的攻擊。例如，replicate.npmjs.com 鏡像站點(diǎn)在 2021 年 10 月發(fā)現(xiàn)了漏洞，導(dǎo)致私有包被泄露； 2021 年 12 月發(fā)現(xiàn)漏洞，攻擊者可以任意發(fā)布 npm 包，而不需要鑒權(quán)。這些問題對整個 Node.js 生態(tài)系統(tǒng)構(gòu)成了極大的威脅。Java 也不例外，比如 log4j2 事件。

事實(shí)上，只要你依賴于第三方或第二方，所有語言都可能會遇到這個供應(yīng)鏈的安全問題。對于開發(fā)者來說，引入每個供應(yīng)鏈?zhǔn)欠癜踩欠浅o解的。為了保障安全，阿里內(nèi)部對所有框架提出了維護(hù) 2 年的要求。此外，GitHub 和 npm 的團(tuán)隊(duì)已被微軟收購，并設(shè)立了專門的安全團(tuán)隊(duì)來負(fù)責(zé)生態(tài)系統(tǒng)的安全?，F(xiàn)在整個 npm 生態(tài)的安全性已經(jīng)做得非常好了，惡意代碼檢測和預(yù)警尤其是針對公共包的，10 分鐘就可以修復(fù)。GitHub 上的依賴樹和安全告警也已更新，并引入了 2FA 的鑒權(quán)。cnpm 團(tuán)隊(duì)在國內(nèi)也為 Node.js 的發(fā)展做出了很多貢獻(xiàn)，提供免費(fèi)高速的下載 npm 包、預(yù)編譯系統(tǒng)二進(jìn)制，以及安全的版本列表等。

我覺得所有做開源的工作者都是值得點(diǎn)贊的，尤其是負(fù)責(zé)任的這些開源的包 owner，Node.js 生態(tài)現(xiàn)在已經(jīng)非常穩(wěn)定繁榮，其背后離不開這些團(tuán)隊(duì)默默的付出。

在國內(nèi)，有很多人為 Node.js 生態(tài)系統(tǒng)做出了杰出的貢獻(xiàn)，如樸靈老師、蘇千、七念、狼叔、九十、天豬等。這些人中的大部分已經(jīng)加入了阿里。當(dāng)一個人深入?yún)⑴c一個生態(tài)系統(tǒng)的發(fā)展并伴隨其歷史做出貢獻(xiàn)時，這個人的個人提升是非?？斓?。因此，我們應(yīng)該盡可能地參與其中，而不是做一個旁觀者。

回到我之前提到的兩個問題，首先是 2018 年我們在 Node.js 地下鐵圓桌會上「Node.js 是否具備企業(yè)級能力」的問題。我認(rèn)為，雖然 Node.js 目前已經(jīng)具備企業(yè)級應(yīng)用能力，但是要達(dá)到這個水平需要借助 CNCF 的整個生態(tài)系統(tǒng)。如果我們想通過語言層面的SDK追趕企業(yè)級應(yīng)用的能力，整個 Node.js 社區(qū)里也沒有那么多人能夠長期持續(xù)地投入到這個領(lǐng)域中去。雖然人手很多，但是在開源社區(qū)中，很難保證每個人都能夠長期投入并保持持續(xù)性的貢獻(xiàn)。但是借助 CNCF 的生態(tài)系統(tǒng)，實(shí)現(xiàn)企業(yè)級應(yīng)用能力是非常容易的。

至于讓 Node.js 扛雙 11 的核心流量這個問題，我認(rèn)為這完全不是問題，因?yàn)?Node.js 已經(jīng)具備了足夠的能力。但是問題在于，是否有人敢去這么做？是否有人能夠給我們這個機(jī)會？

另外，我也提到了阿里前端共建 Serverless 的事情。當(dāng)我們最初開始做 Serverless 時，這個技術(shù)還處于比較低谷的階段，很多基礎(chǔ)設(shè)施都還在開發(fā)之中。但是現(xiàn)在，整個 Serverless 基礎(chǔ)設(shè)施已經(jīng)非常完備了。

在做 Serverless 的時候，Node.js 的優(yōu)勢并不只是基礎(chǔ)設(shè)施共建，而是在語言、框架和應(yīng)用層面都有很多機(jī)會，特別是在 ToB 的 SaaS 服務(wù)領(lǐng)域，使用 Node.js 可以非常方便，并且得到龐大的生態(tài)支持。此外，開源社區(qū)也為我們提供了很多的養(yǎng)分，不僅可以參與 Node.js 代碼的開發(fā)，也可以回饋社區(qū)。即使無法參與開發(fā)，至少也不應(yīng)該攻擊 Node.js，因?yàn)樗且粋€開源的框架。如果你覺得它不好，你可以參與共建，找到行業(yè)內(nèi)的痛點(diǎn)，成為一個核心開發(fā)者。最后提醒大家，安全性問題需要時時留意，不要陷入慣性思維。

盡管有許多人在為我們默默地?fù)踔^，但如果你不小心被石頭砸中了，那也是有可能的。你是要知道其背后還是有一些供應(yīng)鏈的問題，因?yàn)樗械恼Z言都有這個問題，不僅僅是 Node.js。希望大家能夠打造更多的企業(yè)級 Node.js 應(yīng)用的成功案例，這需要大家的努力。Node.js 的發(fā)展需要靠整個開源社區(qū)的力量。我想起魯迅說過的話：Node.js 要發(fā)展，開源社區(qū)靠大家。

第 62 屆早早聊大會將于 2023 年 4 月 8 日（本周六）舉辦 - Node.js 專場，6 位講師全天直播，帶領(lǐng)大家一起探索 Node.js 的魅力，上車鏈接：https://www.zaozao.run/conf/c62。

最后

最后，我想推薦一本書《點(diǎn)石成金》，這本書對我的前端生涯啟發(fā)很大。

此外，向大家推薦一下我的知識星球，歡迎小伙伴們一起來學(xué)習(xí)交流。

如果你也對 Node.js 感興趣，或者正在研究 Node.js，歡迎報(bào)名第 62 屆早早聊大會 - Node.js 專場，一起探索 Node.js 的魅力，一起推動 Node.js 的發(fā)展。

• 舉辦時間：2023 年 4 月 8 日 ?10:00 ~ 17:00

• 截至?xí)r間：2023 年 4 月 8 日 ?19:00

• 舉辦方式：微信群 PPT 推送 + 線上視頻實(shí)時直播 + 會后資料推送

• 報(bào)名方式：https://www.zaozao.run/conf/c62

• 大會主辦方：前端早早聊