Node.js 框架设计及企业 Node.js 基础建设相关讨论
大家好，我是若川。19年我寫的?lodash源碼?文章投稿到海鏡大神知乎專欄竟然通過了，后來20年海鏡大神還star了我的博客，同時(shí)還轉(zhuǎn)發(fā)了我的微博。時(shí)間真快啊。今天分享這篇Node.js的討論。
2021 年上半年早已過去，回顧 Node.js 在國內(nèi)的發(fā)展和生態(tài)建設(shè)，我們積累了一些經(jīng)驗(yàn)，摸清了一些方向。在所謂的「Node.js 后框架時(shí)代」，其技術(shù)發(fā)展將隨著語言演進(jìn)和整體前后端技術(shù)架構(gòu)的升級，將會搭上高速快車。
這篇文章，我們采用實(shí)錄（AMA）的方式，就和?@天豬?關(guān)于「Node.js 框架設(shè)計(jì)及企業(yè) Node.js 基礎(chǔ)建設(shè)」相關(guān)話題的討論內(nèi)容進(jìn)行總結(jié)。接近 90mins 的線上討論，這篇文章相信對前端開發(fā)者，尤其是 Node.js 開發(fā)者會有所啟示。
交流概覽
EggJS 官方站點(diǎn)
分享人介紹：阿里-天豬
相關(guān)周邊：
如何評價(jià)阿里開源的企業(yè)級 Node.js 框架 EggJS？
EggJS 一個(gè)討論
Egg & Node.js 從小工坊走向企業(yè)級開發(fā)
分享人介紹
天豬，Egg 開源接口人，cnpm 接口人。隸屬于螞蟻體驗(yàn)技術(shù)部 - 廣州分部，負(fù)責(zé)螞蟻 Node.js 基礎(chǔ)設(shè)施建設(shè)，包括 Chair、TNPM、BaaS 服務(wù)等。日常工作比較跨界，涉及到研發(fā)平臺，PaaS，框架，包管理。
分享內(nèi)容介紹
分享內(nèi)容我們按照：
Node.js 框架設(shè)計(jì)相關(guān)
Node.js 方向相關(guān)
生態(tài)發(fā)展和開源社區(qū)相關(guān)
三大方向展開，每一個(gè)方向?qū)?yīng)若干討論話題/問題。下面展現(xiàn)部分交流內(nèi)容。
Node.js 框架設(shè)計(jì)相關(guān)
話題一，關(guān)于 Node.js 框架設(shè)計(jì)
如何看待其他 Node.js 框架，如 ThinkJS, fastify 等？如何看待和對比 farrow-js，函數(shù)式風(fēng)格的 Node.js 框架，相比較而言設(shè)計(jì)理念上差異還是很大的。
天豬認(rèn)為，
定位不一樣， Egg 的定位是框架的框架，面向的目標(biāo)用戶是團(tuán)隊(duì)的架構(gòu)師或技術(shù)負(fù)責(zé)人，幫助他們來定制適合特定的業(yè)務(wù)場景的上層業(yè)務(wù)框架。解決的是大規(guī)模企業(yè)級開發(fā)時(shí)的生態(tài)共建 + 差異化定制問題。
像 Chair， Midway，beidou 這些才是面向一線應(yīng)用開發(fā)者的上層框架，我們今年也會開源一個(gè) TEgg 方案，提供官方的 TS 方案，以及業(yè)務(wù)邏輯復(fù)用能力。
從天豬的角度看，完全可以用 Egg 封裝出一個(gè) ThinkJS 類似風(fēng)格的框架。
編者按，
不管是 koa 還是 express，它們都屬于輕量級的 Node.js 框架，它們使用起來優(yōu)點(diǎn)明顯：使用簡單，中間件機(jī)制靈活，社區(qū)生態(tài)完善。
但是在實(shí)際使用中，隨著業(yè)務(wù)復(fù)雜度上升，以及不同場景下對于 Node.js 框架的不同訴求，在直接依賴 koa 或 express 的實(shí)踐中我們發(fā)現(xiàn)了一些痛點(diǎn)，包括但不限于：
需要業(yè)務(wù)手動配置各種中間件
在上一條條背景下，一些基礎(chǔ)通用的中間件缺少統(tǒng)一抽象和維護(hù)
容易出現(xiàn)重復(fù)代碼以及各造輪子（重復(fù)中間件邏輯）現(xiàn)象
koa 和 express 并不約束項(xiàng)目規(guī)范（比如目錄結(jié)構(gòu)等），不同水平程序員搭建的 Node.js 項(xiàng)目風(fēng)格不統(tǒng)一，質(zhì)量參差不齊
koa 和 express 并不直接解決 Node.js 項(xiàng)目的基建部分，不解決調(diào)試、開發(fā)配置等關(guān)鍵環(huán)節(jié)，使得生成效率難以最大化提升
為了解決上述問題，社區(qū)上出現(xiàn)不少基于 koa 和 express 的上層 Node.js 框架，比如：
阿里體系基于 EggJS 之上的 Chair、Midway 等框架。
Spring 風(fēng)格的?NestJS
360 奇舞團(tuán)的?ThinkJS
這些框架在不同程度上封裝了 koa 和 express，并給出了各自風(fēng)格的上層方案，但都也不完全是一個(gè)開箱即用的企業(yè)級 Node.js 框架，不能直接滿足 XX 企業(yè)內(nèi)場景，難以直接融入已有 Node.js 項(xiàng)目，理想情況下，仍需一道封裝。
此外，社區(qū)上還活躍著著：fastify，farrow-js，restify，hapi，sails 等 Node.js library/framework，各自側(cè)重點(diǎn)（性能優(yōu)先/易用性優(yōu)先等）和分層領(lǐng)域（low level/high level 等）各不相同。
對于一套企業(yè)級 Node.js 框架來說，設(shè)計(jì)一套 Node.js MVC 開發(fā)框架，或在 Egg 之上再封裝，其目的是保障易用性、穩(wěn)定性的基礎(chǔ)上，提升 Node.js 項(xiàng)目開發(fā)的效率及服務(wù)性能。
話題二，一個(gè)關(guān)于 Node.js 框架性能的討論
EggJS 文檔中關(guān)于特性描述，提到了「基于 KoaJS 開發(fā)，性能優(yōu)異」。其中，前半句「基于 KoaJS 開發(fā)」和后半句「性能優(yōu)異」構(gòu)成因果關(guān)系嗎？如果構(gòu)成，KoaJS 帶來的性能收益體現(xiàn)在哪里？如果不構(gòu)成，那么 EggJS 關(guān)于性能方面做了哪些事情？（除了 co 升級為 async/await 之外）
天豬認(rèn)為，
沒有因果關(guān)系，這里當(dāng)時(shí)只是陳述 Egg 的 2 個(gè)特點(diǎn)，在那個(gè)時(shí)間點(diǎn)來說，Koa 在社區(qū)的認(rèn)知里面還是屬于先進(jìn)的（那時(shí)候還是 Express 的中期）。
其實(shí)對于大部分的應(yīng)用來說，框架遠(yuǎn)遠(yuǎn)不會是性能的影響因素，性能更多可能出現(xiàn)在和后端通訊的序列化/反序列化，不合理的調(diào)用鏈，耗時(shí)的 CPU 操作等等。
Egg 宣稱自己有優(yōu)異的性能的底氣在于：在過去 9 年來在線上雙十一量級的壓力場景下的穩(wěn)定表現(xiàn)，絕大部分性能問題都能被發(fā)現(xiàn)并逐一解決（AliNode 利器），舉個(gè)例子，最近語雀居然發(fā)現(xiàn) Router 成為了性能瓶頸之一（1000+ 路由，20ms）。
同時(shí)豐富的實(shí)踐也讓我們很清楚一個(gè)事實(shí)，就是大部分的性能問題，都輪不到框架來背鍋，很多都是業(yè)務(wù)不合理使用。因此我們在性能上優(yōu)化主要不體現(xiàn)在 Egg 框架本身。比如，fasitfy 基于 Schema 來優(yōu)化序列化的性能，這些好的社區(qū)實(shí)踐我們也一直在吸收，如 sofa-hessian-node 針對復(fù)雜對象場景的性能有明顯的提升。
編者按，
Egg 方面通過相關(guān) benchmark，發(fā)現(xiàn)去除 co 后堆棧信息更清晰，能帶來 30% 左右的性能提升（不含 Node 帶來的性能提升），但對于 Egg 本身來說，框架并沒有著重發(fā)力性能細(xì)節(jié)，沒有像 fasitfy 等框架內(nèi)置性能機(jī)制優(yōu)化操作，對 perf friendly 錙銖必較。
事實(shí)上，對于一個(gè) Node.js 服務(wù)來說，服務(wù)的響應(yīng)性能瓶頸往往在業(yè)務(wù)工程當(dāng)中，在框架設(shè)計(jì)方面，使用便利性和性能的平衡是一個(gè)永恒的話題。當(dāng)然，社區(qū)上也鼓勵(lì)和歡迎任何一性能為「賣點(diǎn)」的框架。
這里希望大家注意的是，脫離業(yè)務(wù)的性能優(yōu)化——只會是框架本身的「自嗨」。像 sofa-hessian-node 案例一樣，由業(yè)務(wù)中發(fā)現(xiàn)性能痛點(diǎn)（后端交互的序列化性能瓶頸），再去借鑒業(yè)界的相關(guān)實(shí)踐，最終業(yè)務(wù)和技術(shù)相互促進(jìn)，框架在各個(gè)層面也會得到更多發(fā)展，是一個(gè)非常可貴的相互促進(jìn)結(jié)果。
話題三，仍然是一個(gè)關(guān)于 Node.js 框架性能的討論
EggJS 加載器的設(shè)計(jì)，看上去在啟動時(shí)并不很性能友好（比如 Egg 會遍歷項(xiàng)目中的 loadUnit，再比如插件的加載過程）？這方面有相關(guān)的設(shè)計(jì)考慮嗎？
天豬認(rèn)為，
在 Egg 發(fā)起時(shí)那個(gè)時(shí)間點(diǎn)，甚至包括現(xiàn)在，啟動的時(shí)間其實(shí)沒那么重要，因?yàn)槎际羌翰渴鸬姆绞絹矸峙鷿L動升級的。
一般應(yīng)用插件也不會太多，我們最復(fù)雜的場景 Chair 內(nèi)置的插件近百個(gè)，讀取文件的耗時(shí)其實(shí)占比很小，更多的啟動耗時(shí)在于某些插件需要和后端中間件服務(wù)建聯(lián)，拉取配置等等初始化上。所以上面提到的『遍歷目錄』這個(gè)其實(shí)不會對性能有影響，而要看插件本身的自有邏輯復(fù)雜度。
Serverless 時(shí)代，做極速啟動時(shí)可能就會有一定的影響，這塊可以通過構(gòu)建期的預(yù)分析，來幫助框架減少文件系統(tǒng)的遍歷，但收益不一定大。
編者按，
Node.js 框架啟動性能往往是一個(gè)被忽略的話題，但在容器化和 Severless 大勢發(fā)展下，啟動速度逐漸被開發(fā)者所關(guān)心。這一方面，我們將會持續(xù)關(guān)注相關(guān)話題。
話題四，一個(gè)關(guān)于框架漸進(jìn)式設(shè)計(jì)/發(fā)展的討論
EggJS 內(nèi)置了 static 服務(wù)插件，在 EggJS 內(nèi)置哪些插件/能力的設(shè)計(jì)上，考慮有哪些？（比如為什么 static, i18n, logger 作為內(nèi)置插件出現(xiàn)，這些能力像其他插件一樣做成可插拔的不更好么？
天豬認(rèn)為，
由于歷史原因，當(dāng)時(shí) Egg 開源的時(shí)候沒有拆的很干凈。其實(shí)可以看下 egg-core，它其實(shí)才是 egg 的最核心部分：
Koa 在 Node HTTP 之上提供了一層很薄的語法糖封裝，并提供了洋蔥模型。
egg-core 在 Koa 之上，提供了一套 Loader 機(jī)制，并基于它延伸出了插件和上層框架。
特定場景框架：chair-serverless | midway-faas | ↑ ↑ 團(tuán)隊(duì)業(yè)務(wù)框架：chair | midway | nut | ... ↑ ↑ ↑ ↑ 阿里統(tǒng)一框架：@ali/egg ↑ ↑ ↑ ↑ 開源社區(qū)框架：egg
事實(shí)上，Egg 的應(yīng)用、插件、框架的目錄結(jié)構(gòu)幾乎一模一樣。
實(shí)際開發(fā)過程中，我們也有一套?漸進(jìn)式的演進(jìn)方式，分享給大家：
實(shí)驗(yàn)性的功能，可以先在應(yīng)用里面實(shí)現(xiàn)，作為 inline plugin 通過 path 方式來掛載。
功能穩(wěn)定后，就抽出來變?yōu)楠?dú)立的插件，應(yīng)用再通過 npm 依賴方式引入，只需改兩行代碼即可。
當(dāng)該功能成熟后，成為團(tuán)隊(duì)的統(tǒng)一規(guī)范時(shí)，直接把這個(gè)插件集成到 Framework 中，所有應(yīng)用只需重新安裝下依賴，即可立刻享受到。
這個(gè)過程是閉環(huán)的，是漸進(jìn)式，而且升級過程幾乎無痛。
編者按，
對于任何一個(gè)框架的設(shè)計(jì)來說，漸進(jìn)式是一個(gè)重要的課題。
比如 Vue.js，比如 React.js，漸進(jìn)式的設(shè)計(jì)能夠保證業(yè)務(wù)開發(fā)者更敏捷地迭代，更方便快捷地使用框架，同時(shí)依然保留有對架構(gòu)進(jìn)行優(yōu)化、基礎(chǔ)能力進(jìn)行下沉的能力。對框架設(shè)計(jì)者來說，漸進(jìn)式的設(shè)計(jì)，更是保障框架本身進(jìn)步發(fā)展的關(guān)鍵。
話題五，一個(gè)關(guān)于框架的上層封裝討論
關(guān)于基于 EggJS 的上層框架方案，有沒有 Best pratice 建議？比如，Chair 基于 EggJS 的封裝，做了哪些「有趣、不一樣」的事情嗎，有哪些值得借鑒的嗎？
天豬認(rèn)為，
上層框架是針對特定的業(yè)務(wù)場景 或 特定的基礎(chǔ)設(shè)施 的封裝，而隨著一波又一波的需求過來，各種階段性的妥協(xié)，基礎(chǔ)設(shè)施的演進(jìn)，它注定是維護(hù)和治理的重災(zāi)區(qū)。
一個(gè)新的插件，該不該內(nèi)置，如何漸進(jìn)式的推進(jìn)，又如何在它被另一個(gè)插件替代時(shí)，推動下線。業(yè)務(wù)場景變化的時(shí)候，框架該不該多套娃一層。鎖不鎖版本，如何推動更新，出現(xiàn)問題如何快速止血，等等對于這些問題，框架的應(yīng)用規(guī)模是 10 和 1000 時(shí)的思考點(diǎn)是不一樣的。
話題六，關(guān)于設(shè)計(jì)遺憾和未來計(jì)劃的討論
關(guān)于 EggJS 的進(jìn)程管理問題，以及相關(guān)部署、重啟等環(huán)節(jié)，在容器化 docker 化的背景下，EggJS 的相關(guān)設(shè)計(jì)是否需要跟進(jìn)和調(diào)整？
天豬認(rèn)為，
Egg 的 agent 提出的背景，是后端中間件服務(wù)曾經(jīng)被我們 ddos 了，當(dāng)時(shí)好像是 diamond 這個(gè)遠(yuǎn)程配置服務(wù)，我們每一個(gè)進(jìn)程，都會在啟動的時(shí)候向它拉取配置，所以需要有個(gè) agent 來統(tǒng)一做這事，拉取完后再共享給 workers。
在 Serverless 的大背景下，類似的配置拉取其實(shí)有云原生的內(nèi)置方案，不需要框架層過多考慮。我們也確實(shí)有考慮單進(jìn)程模型，并在內(nèi)部也有一些實(shí)踐，但目前沒有看到特別的收益。
在 Egg 3.0 里面，cluster 不會內(nèi)置，單進(jìn)程模式也能對 mock 和單測這塊帶來更清晰的邏輯。
EggJS 有不適用的場景嗎？是否有在設(shè)計(jì)上的一些遺憾？未來有哪些計(jì)劃？
天豬認(rèn)為，
受限于 Koa，目前更適合于 Web 框架。在 3.0 Context 模型后，這塊應(yīng)該會更靈活，不再受限。據(jù)我所知，有不少開發(fā)者用來當(dāng)隊(duì)列處理器，或者任務(wù)執(zhí)行器。前者不是不可以用，只是總會覺得有一點(diǎn)別扭。后者其實(shí) FC 這類函數(shù)計(jì)算會更合適。
Egg 3.0（egg-core） ：
會更純粹，一套 Loader 機(jī)制 + 洋蔥模型，面向未來。
Loader 的生命周期支持異步（從而可以支持異步配置）
不依賴于 Koa，可以脫離 Web 框架這個(gè)局限，我們需要的只是洋蔥模型，可以自行實(shí)現(xiàn)，核心是一個(gè) Context，根據(jù)不同的流量入口，實(shí)例化為 HttpContext、RPCContext、WSContext 等。（我們對 socket.io 等的支持就不會看起來太別扭。）
以上是 Egg 的后續(xù)規(guī)劃
編者按，
很少有一種技術(shù)設(shè)計(jì)，能夠完全開啟「我在 XX 年后等你」的視角，關(guān)于 Node.js 的單進(jìn)程/多進(jìn)程模型等諸多話題的背后，其實(shí)是基礎(chǔ)服務(wù)設(shè)施的變遷，編程模型趨勢的演進(jìn)浪潮。這一方面，前端開發(fā)者將會越來越多的「跨界」，也只有邁出更多步，才能發(fā)揮更大的價(jià)值。?一個(gè) Node.js 框架設(shè)計(jì)實(shí)在是整個(gè)技術(shù)鏈條上的微觀的小環(huán)節(jié)，但管中窺豹，我們的邊界在更遠(yuǎn)方。
下面，我們進(jìn)入整個(gè) Node.js 方向上的討論。
Node.js 方向相關(guān)
話題一，關(guān)于下一代 Node.js 框架和 Node.js 趨勢
未來（下一代） Node.js 框架會有什么樣的發(fā)展趨勢？你們團(tuán)隊(duì)目前探索的方向是？（比如 BFF -> SFF？）
天豬認(rèn)為，
框架主要體現(xiàn)在研發(fā)模式這塊，涉及到用戶編程界面層。框架是一個(gè)重要的點(diǎn)，但不是全部，藏在冰山之下的還有整個(gè)研發(fā)生命周期（研發(fā)平臺、迭代模型、部署、前后端研發(fā)模式、監(jiān)控體系等等）。
Node SDK 這塊未來會 ServiceMesh 化掉，它們應(yīng)該回歸后端中間件團(tuán)隊(duì)的工作范疇，畢竟由后端來維護(hù)自己的服務(wù)對應(yīng)的 SDK 才是最合理的分工。
一個(gè)團(tuán)隊(duì)的業(yè)務(wù)，可能一下子不需要 Node.js，可以不用，但團(tuán)隊(duì)必須具備隨時(shí)可以有的準(zhǔn)備，沒有這個(gè)儲備，你們的技術(shù)選型視角和話語權(quán)會完全不一樣。Node.js 是前端的一個(gè)可選能力，也是一個(gè)必要的儲備。
如上圖，Node 的一部分場景是聚合邏輯層，會往云端一體化方向發(fā)展，另一部場景是會走微服務(wù)方向，跟后端的框架沒啥區(qū)別，當(dāng)今的業(yè)界認(rèn)知是跨語言方向。
話題二，關(guān)于 APM
關(guān)于 APM，我們知道 AliNode，除此之外還有其他建議或者經(jīng)驗(yàn)嗎？關(guān)于 AliNode 目前發(fā)展情況，比如 runtime 替換掉 Node.js runtime，這種方式是否會成為趨勢，阿里之外有比較成熟的應(yīng)用嗎？
天豬認(rèn)為，
可以考慮用一君的 easy-monitor，優(yōu)點(diǎn)是：
比 AliNode 更低的維護(hù)成本，通過 Addon 方式，而不是 Runtime 方式，從而不綁定 Node Runtime 升級，更快的適配。
支持私有化部署。（雖然 AliNode 的 agent 上報(bào)是開源的，但人與人的信任還是很難的）
開源。
說到 APM 這里，其實(shí)我們內(nèi)部曾經(jīng)有過一個(gè)有趣的討論：Serverless 后， APM 還重要么？反方觀點(diǎn)：內(nèi)存泄露就內(nèi)存泄露唄，小的泄露無所謂，到了閥值，直接動態(tài)騰挪換機(jī)器。我個(gè)人認(rèn)為 APM 還是很重要的，工具本身很重要，它是查問題的利器和底氣。直接騰挪是實(shí)際運(yùn)維的 ROI，只是代表了某個(gè)時(shí)刻，暫時(shí)可以不用費(fèi)精力查問題，但不代表問題不應(yīng)該被解決。
編者按，
重點(diǎn)再聊聊 APM，上面的辯論（「Serverless 后， APM 還重要么？」），反方其實(shí)是在靠中臺能力來降維規(guī)避問題，這背后其實(shí)是一個(gè)技術(shù)態(tài)度問題。
Node.js 服務(wù)自己的問題，還需要自己來解決。那么出現(xiàn)了 Node.js 方面的問題，如何借助 APM 來進(jìn)行調(diào)試，發(fā)現(xiàn)并解決問題呢？我們又積累了哪些實(shí)戰(zhàn)場景經(jīng)驗(yàn)?zāi)?#xff1f;請關(guān)注我們，后續(xù)會帶來更多線上真實(shí)案例。
話題三，關(guān)于 Node.js 原生 http 模塊的一個(gè)討論
EggJS 基于 urllib 實(shí)現(xiàn)了一個(gè) httpclient，這個(gè)考慮是什么，性能嗎？接上問，EggJS 既然實(shí)現(xiàn) httpClient，那么如何看待 Node.js undici，似乎是一個(gè)更貼近官方的方案？fastify 一開始就在使用 undici, 如何看待主打性能的 fastify，Node.js 實(shí)踐經(jīng)驗(yàn)上，性能是否是比較棘手的一環(huán)？
天豬認(rèn)為，
因?yàn)?urllib 是我們實(shí)現(xiàn)的，在這么多年的實(shí)踐中，踩了 http 的無數(shù)坑，跨過之后沉淀到 urllib 里了，多年后它的穩(wěn)定性我們無比相信。所以目前重度使用了 urllib。undici 最近也有關(guān)注到，也稍微用了下。從現(xiàn)在這個(gè)時(shí)間點(diǎn)來看， urllib 的代碼確實(shí)有點(diǎn)亂，我也兩度想重構(gòu)它，但 ROI 不是很高，就沒下手。未來也許有機(jī)會把它重構(gòu)掉。
編者按，
Node.js 及其相關(guān)的基礎(chǔ)建設(shè)決定著 Node.js 落地情況，也決定了 Node.js 最終價(jià)值。這主要可以分為兩個(gè)方向：
Node.js 本身語言演進(jìn)
Node.js 對接中臺基礎(chǔ)
其一 Node.js 本身語言的演進(jìn)，
比如，undici 提供了 Node.js core http 模塊的代替方案，帶來了性能和穩(wěn)定性的提升，解決了 Node.js core http client 歷史的重大技術(shù)債務(wù)。
另外 Node.js 對接「更后的后端體系」，是基礎(chǔ)建設(shè)的重要一環(huán)，比如 ServiceMesh 生態(tài)。
舉個(gè)例子，通過 Sidecar 模式我們可以在 Kubernetes Pod 中，在原有應(yīng)用容器旁邊運(yùn)行一個(gè)伴生容器，由 Sidecar 接管進(jìn)出應(yīng)用容器的所有流量，實(shí)現(xiàn) just work 的應(yīng)用容器監(jiān)控。
但應(yīng)用容器本身的運(yùn)行細(xì)節(jié)，如 CPU Profile，Memory usuage 等依然需要 Node.js 開發(fā)者給出答案，因此有了 AliNode，也有了不侵入 Node.js runtime 的 Easy-monitor。
對于企業(yè)級 Node.js 解決方案來說，不妨經(jīng)常反問自己：「我們還缺什么，我們還能做些什么」。畢竟 Node.js 基礎(chǔ)建設(shè)的發(fā)展始終在探索中前進(jìn)，在這方面，希望每一名開發(fā)者貢獻(xiàn)力量。
生態(tài)發(fā)展和開源社區(qū)相關(guān)
話題一，鎖/不鎖版本，ESM 和前端生態(tài)協(xié)作鏈
2021 年，對于版本管理和 Node.js ESM 有哪些新的看法？（比如鎖版本，Node.js package 對 ESM 的支持程度)
天豬認(rèn)為，
鎖版本 vs 不鎖版本，一個(gè)永恒的話題。天豬的觀點(diǎn)是，
不同團(tuán)隊(duì)基礎(chǔ)能力下的權(quán)衡，沒有銀彈。
鎖版本是一個(gè)保守的方案，擊鼓傳花，把炸彈留給后人。
前端依賴和后端依賴是 2 個(gè)話題。
事實(shí)上：等有空了再統(tǒng)一升級，往往是一個(gè)美麗的謊言，這個(gè)在工程上的可執(zhí)行性不是很看好。
這里附上舊文一篇：為什么我不使用 shrinkwrap（lock）?，后面天豬會寫一篇新的。
繼續(xù)這個(gè)話題，在職責(zé)分離維度，
框架層面可以考慮鎖自己的子依賴，框架維護(hù)者來負(fù)責(zé)推動升級，應(yīng)用開發(fā)者鎖自己引入的依賴，職責(zé)分離。但這一點(diǎn)上，需要 npm 工具和研發(fā)平臺上的緊密配合。
給框架維護(hù)者提供一種鎖內(nèi)部版本的機(jī)制，且能由框架維護(hù)者來主導(dǎo)應(yīng)用的框架版本升級
當(dāng)然提供 CITGM 機(jī)制來幫助框架維護(hù)者回歸，也是很有必要的。
這里附一個(gè)「彩蛋圖」——「研發(fā)平臺」中關(guān)于版本和生態(tài)的「儀表盤」：
我們不妨繼續(xù)探索「研發(fā)平臺」，即基于研發(fā)平臺的依賴生態(tài)解決方案：我們給出設(shè)計(jì)如下，
本地、開發(fā)環(huán)境，不鎖版本。
信息公開，每次迭代構(gòu)建后，依賴的更新情況要讓開發(fā)者清晰。
配套的止血機(jī)制，未來需要更智能化。
緊急迭代，測試 → 預(yù)發(fā)階段，允許開發(fā)者在平臺鎖版本。
更多信息：
編者按，
在生態(tài)發(fā)展和開源社區(qū)相關(guān)部分，我們和天豬重點(diǎn)聊了「鎖/不鎖版本」的問題。
這個(gè)問題雖然老生常談，但他絕不是一個(gè)包管理方案選型的問題，「鎖/不鎖版本」的背后，何嘗不是整個(gè)前端社區(qū)生態(tài)。這方面，不同團(tuán)隊(duì)給出的不同答案，都在詮釋著對前端社區(qū)生態(tài)的不同理解。
同時(shí)，我們也期待?關(guān)于現(xiàn)代包管理器的深度思考——為什么現(xiàn)在我更推薦 pnpm 而不是 npm/yarn?之后的 TNPM，以及不斷進(jìn)化的前端技術(shù)潮流。
話題二，關(guān)于項(xiàng)目開源和普及度
EggJS 在阿里內(nèi)部是如何推行的？推行當(dāng)中遇到的最大困難是什么？（可以再透露下目前內(nèi)部哪些系統(tǒng)使用了 EggJS 嗎）
天豬，
好像沒怎么推行，就普及的，天時(shí)地利人和吧（編者按，好凡爾賽！手動狗頭）
2015.10.13 內(nèi)部拉通 Node 工作組，閉關(guān)一周，產(chǎn)出一份 RFC，基于 RFC 產(chǎn)出 @ali/egg 1.0
2016 年 JSConf 開源，年底的時(shí)候差不多幾個(gè)大的 BU 的上層框架都重構(gòu)為基于 egg 了。
目前你能看到的阿里系的頁面，絕大部分都是基于 Egg 的，像螞蟻大部分流量入口都是基于 render 這個(gè)高性能的渲染服務(wù)（螞蟻森林），天貓那邊的斑馬，還有財(cái)富的好幾個(gè)大的 BFF 有數(shù)千個(gè) POD
Node 是阿里的第二大語言，而 Egg 是唯一的官方框架，不是基于 Egg 的框架，無法跟內(nèi)部的各大中間件交互，也無法很好地被研發(fā)平臺和監(jiān)控平臺等支持。阿里有數(shù)千個(gè) Node 應(yīng)用。
語雀 - 可能是西湖區(qū)最大的 Node 全棧應(yīng)用。
目前這個(gè)時(shí)間點(diǎn)會遇到一些問題，整個(gè)大環(huán)境變了，所以 BFF → SFF
總結(jié)
不管是 Node.js 還是其他前端技術(shù)方案，我們都期待著一個(gè)更友好開闊、更互動交流的氛圍。我們和?@天豬?的交流，名義上是「 Node.js 框架」，其實(shí)更是對 Node.js 甚至前端未來發(fā)展的討論。
個(gè)人力量太過有限，但我們對技術(shù)抱有理想，也尋求更多的交流、共創(chuàng)。????
關(guān)注我們，后面將會有更多前端技術(shù)方面的想法和積淀產(chǎn)出！
Happy coding!
最近組建了一個(gè)江西人的前端交流群，如果你是江西人可以加我微信?ruochuan12?私信 江西?拉你進(jìn)群。
推薦閱讀
我在阿里招前端，該怎么幫你（可進(jìn)面試群）
畢業(yè)年限不長的前端焦慮和突破方法
前端搶飯碗系列之Vue項(xiàng)目如何做單元測試
老姚淺談：怎么學(xué)JavaScript？
·················?若川簡介?·················
你好，我是若川，畢業(yè)于江西高校。現(xiàn)在是一名前端開發(fā)“工程師”。寫有《學(xué)習(xí)源碼整體架構(gòu)系列》多篇，在知乎、掘金收獲超百萬閱讀。
從2014年起，每年都會寫一篇年度總結(jié)，已經(jīng)寫了7篇，點(diǎn)擊查看年度總結(jié)。
同時(shí)，活躍在知乎@若川，掘金@若川。致力于分享前端開發(fā)經(jīng)驗(yàn)，愿景：幫助5年內(nèi)前端人走向前列。
點(diǎn)擊上方卡片關(guān)注我、加個(gè)星標(biāo)
今日話題
略。歡迎分享、收藏、點(diǎn)贊、在看我的公眾號文章~
總結(jié)
以上是生活随笔為你收集整理的Node.js 框架设计及企业 Node.js 基础建设相关讨论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 前端学习（3137）：react-hel
- 下一篇： 我读源码的经历~