掘金 AMA：聽阿里 Node 基礎框架 EggJS 的核心開發者--天豬講 EggJS 和 Node 那些事

第十期 AMA，掘金團隊請來了阿里 Node 基礎框架 EggJS 的核心開發者 -- 天豬 作了爲期三天的 Ask Me Anything (AMA) 活動（已結束）。

咱們在此精選了一些來自用戶的提問及天豬的回答。

關於天豬

• 我的 GitHub：github.com/atian25
• 我的知乎：www.zhihu.com/people/liuy…
• 我的掘金主頁：juejin.im/user/577753…
• 我的微博：weibo.com/liuyong25?i…

社區小夥伴精選提問

Egg 的最大的亮點是什麼？ ─ @Lanwy

圍觀大佬，能夠說下你以爲 Egg 的最大的亮點是什麼嗎？😃只能說一點

最大的亮點是定位吧，Egg 的定位是框架的框架，在 Koa 的基礎上提供了一套加載規範，從而延伸出插件和上層框架的概念，達到生態共建和差別化定製的平衡點，助力不一樣團隊的架構師孵化出適合自身業務場景的上層框架。

過多約束是否阻礙 egg 的大規模推廣─ @託尼的夏天

egg 相比其餘 node 框架，約束太多了，這是否阻礙了它的大規模推廣

首先，Egg 是很輕量的，它的約束其實不多，就寥寥幾個擴展點，比起 sails loopback 等上層框架可謂極簡了，它專一於提供這些上層框架的最核心的共性 - 一套加載器。你以爲太多，多是咱們官網文檔的問題，不少都是插件提供的，並無集成。

其次，Egg 並不太須要推廣，它最初是爲了支撐阿里內部各大 BU 之間的協做問題，涉及到各行各業，譬如電商，自媒體，遊戲，金融等等千差萬別的業務場景，所以咱們的定位是專一於作框架的框架。以下圖所示

另外，咱們這幾我的一直都受益於開源，所以一開始的目標就肯定要開源出來。至於推廣，老實說，不是咱們的 KPI。

hapi 和 egg 的差別在哪？ ─ @chenchao

都是配置優先，請問，hapi和egg的差別在哪？在企業開發中，如何抉擇？二者有沒有哪些對比express凸顯出來的劣勢？

hapi 並無配置優先吧，它跟 Express，Koa 是差很少層次的，都在微框架這一層。Egg 是在它們之上加了一層 Loader 機制。通常咱們基於 Express 或 Koa 開發的時候，團隊裏面每每都會在上面封裝一層業務框架，Egg 的定位就是抽象出這一層的一些通用能力，讓你們基於同一套基礎規則來封裝上層業務框架，達成生態共享的狀態。

Express 的侷限性，恰好最近個人一本書中有總結了下，主要在於：

• 只是對 Node 的 HTTP API 作了一層很薄的封裝，暴露給開發者的 API 抽象程度不夠，不便管控。
• 中間件模型是線性的，管進無論出，只是處理了 req 進來那條鏈路，而沒有管 res 出去那條。
• 基於 Callback 的中間件模型，不可避免的受到回調地獄的影響。

egg的擴展中help.js和app.js哪一個更適合擴展工具方法？ ─ @magican

egg 的擴展中 help.js 和 app.js 哪一個更適合擴展工具方法？就約定來講適合 help，可是 help 是綁定到上下文的，就內存佔用是否是 app 更好？

內存這個不要去過多考慮，基本上按你們的業務量級，不會有什麼問題的。在咱們的定位裏面，helper 是給到模板來作局部的 formatter 的。擴展方法，看你具體的場景，甚至能夠放到 ctx.service.xxUtils 上

國內用node作後端的狀況還多嗎？職業發展要怎麼規劃？─ @gea

天豬大佬，如今國內用 node 作後端的狀況還多嗎？職業發展要怎麼規劃？ 由於我是一個兩年多工做經驗 noder，開始工做的時候是作前端，我本身轉型作後端，如今作了接近兩年的純 node 後端工做，最近感受大多數企業把 node 的場景都開始向前偏移了，我我的以爲 node 用來作後端是足夠的，性能方面也不是那麼大的硬傷，能夠經過 k8s 等一系列的架構和方式去消除減弱性能的缺點，可是 node 後端愈來愈少，要轉向前端仍是轉向其它語言呢？

微服務化其實給 Node 帶來的是利好，提供服務便可，不關注後面的語言。目前國內用 Node 的團隊，我以爲是兩極分化：

• 阿里這樣的大公司，有完善的基建和中間件支撐，所以能夠大放異彩。
• 創業小公司，追求速度和效率，因此也能放手實踐。
• 反而是中間的中小公司，包括一些大公司裏面的團隊，受限於運維基建和話語權，推起來比較痛苦。

性能其實各大語言發展到今天，對於絕大部分業務場景來講，輪不到拼這個天賦的時候。選擇一個技術，更多的是看團隊的技術棧 + 運維基建 + 中間件服務支撐程度 + 話語權。

就 Node 發展的話，建議仍是進阿里體驗一下，在國內阿里的 Node 和其餘公司，是徹底兩個不一樣的階段。或者至少了解下阿里 Node 在這個過程當中的實踐，踩坑經驗，將來方向，從而有的放矢。

點評下nest，說說您或者egg團隊對他的見解？─ @鯨吃瓜

請問天豬大哥可否簡單的點評下nest，說說您或者egg團隊對他的見解，以及他的優缺點🙃

nest 是近年來新出的一個框架，比較亮眼的是 TypeScript 和從 Spring 過來的一些概念。

從咱們的角度來看，企業級應用有不少要素，包括編程模型約束、擴展點、多進程管理、日誌、安全、RPC 等等很是多的方面，TypeScript 靜態類型帶來的好處，是其中的一小點，但並非所有。裝飾器等特性，目前還在 Stage 階段，並無落地到 Node LTS 版本中。在咱們看來，靜態類型帶來的好處，還不如把單元測試覆蓋率作上去更實際。

TypeScript 也並非某個框架獨有的，就像螞蟻鳳蝶團隊就有在用 TS 開發 Egg 應用（據說他們作了個 tegg 框架，後面也許會放出來）。

順便重提下框架對比，從咱們的角度看來，框架有三層：

• 基礎框架：Express，Koa
• 框架的框架：Egg
• 上層業務框架：tegg，chair，sofa-node，ThinkJS，Sails，Loopback，Nest

它們的定位：

• 微框架專一於底層中間件模型，是 Node HTTP 之上很薄的一層。
• 上層業務框架，是針對某個領域和業務場景定製的業務框架，針對團隊自身的業務場景和技術選型下的組合。（固然也有一些大教堂式的大而全框架）
• 上層業務框架通常每一個團隊都會封裝一個，就像當年阿里各大 BU 那樣，而 Egg 就定位介於前面二者之間，抽象出上層框架的一些共性 -- 一套加載規範，一方面提供插件能力來複用，一方面提供框架定製能力供團隊架構師定製本身的上層業務框架。

Node 新人如何成長？─ @L丶q

一直混跡於創業公司，致力於各類業務以及解決問題，有時候特別基礎的知識都要去查一下才能肯定，我的技能也是層次不齊，感受迷茫了怎麼辦

關鍵仍是總結，遇到問題後，多思考，遇到了什麼問題，解決了什麼問題？同類場景是如何解決這個問題的？他們之間的對比是怎麼樣的？誰優誰劣？若是他們的方案各自優勢結合起來，又會怎麼樣？

或者這麼說，將來你參與面試的時候，面試官但願聽到你說 「我用過 xx 框架」，仍是但願聽到你說：「我在作 XX 項目的時候，預研過 XX 和 YY 框架，最終由於 XX 等緣由，我選擇了 XX 框架。在這過程當中，我遇到了 XX 問題，爲此我去看了 XX 源碼，發現他們是基於 XX 原理的，還有優化的空間，因而本身嘗試了 XX，解決後寫了 XX 總結文章，甚至嘗試給 XX 框架提了一個 PR 解決了這個問題」 -- 這句話好像是小芋頭說的。

對話：天豬 & 楊雪晉 & 字字珠璣關於開源、egg.js 社區的見解

楊雪晉：我在公司的技術選型中 Node 一塊使用了 Egg，兩期下來發現開發沒問題但體驗很通常。錯誤提示很不明確，官方文檔華而不實，三方模塊濫竽充數，框架約束邯鄲學步。錯誤提示方面您能夠說是 Nodejs 異步緣由很差定位錯誤，官方文檔只是好看但業務開發中咱們發現不少地方文檔沒有詳細說明，第三方模塊諸如 egg-jwt 典型的 npm copy 過來改改充數的也能被官方推薦使用，egg 的框架約束對比一下 Laravel，目錄和模塊名做爲類，大寫後，路由卻必須小寫！並且關於模塊的引入 ES6 提供了兩三種方法，官方文檔和大家開發的 cnode 社區源碼上用的是代碼重複量多的那種，關於 Controller 層有個 egg-validate 插件的使用也能夠獨立出來文件中，也能夠放構造函數中，這些官方文檔都沒有說明，自定義參數檢驗和定時器這些更不那麼重要可是簡單的確說明過分了。

天豬 ：

感謝反饋，社區這塊確實有挺大的進步空間。你指的濫竽充數是 awsome-egg 那個吧？那個目前只要是提 PR 就能合併的，目前只做爲一個索引，咱們並無精力去逐個分析源碼和評價方案，這塊若是社區有同窗有興趣，能夠考慮參與進來接管。

jwt 那個是社區插件，不是官方維護的。 validate 那個不是內置插件，因此沒有寫入文檔。cnode 那個其實也不是官方重寫的，是樸老師以前召集社區重構的，第一期只專一於遷移，並無優化。

楊雪晉：多謝解釋了，抱歉個人態度可能稍微激動了點，實在但願 Node 社區也能有相對完美的 web 框架和生態系統。

天豬 ：

沒事的，咱們每一個人在社區都是有多重角色的。就像蘇千他們也是 Koa 的核心開發者，而 Koa 自己也已經完成了本身的核心目標了。而後上一層的封裝，他們是做爲 Egg 的核心開發，輸出到 Egg 裏面的。一樣，更上層的業務框架輸出，咱們是以另外一個角色，在其餘項目裏面輸出的，能夠關注下螞蟻最近開源的 sofa-node 。

也能夠看看咱們這篇專欄《InfoQ 專訪死馬：爲何說Egg.js是企業級Node框架》zhuanlan.zhihu.com/p/36240171

楊雪晉：請大家在公司項目中使用下 egg，碰到問題在 github 提交 issue。確實官方回覆很快，基本上是天豬回覆的多，並且是回覆後即使沒解決問題也馬上關閉 issue，即便如此 egg 項目的 issue 依舊存在不少問題爲明顯的不足之處，我感受不到官方團隊有對 egg 技術創新上作追求

天豬 ：

1. 若是沒有解決能夠從新 open 的，這是社區，不要有負擔。
2. 老實說，egg 自己的職責基本上已經完成了，它就是一個加載規範，核心已經很穩定了。
3. 剩下的，咱們其實跟大家沒啥區別，都是社區的一分子的身份，去完善生態。
4. 而平常開發中咱們沒用到的模塊和實踐，咱們真的沒能力也沒辦法花時間去專門研究，畢竟咱們只是一個虛擬團隊，咱們主要是爲了支持各自部門的 Node 演進。
5. 阿里的不少後端和運維基建和社區不同，(固然咱們在儘可能擁抱)，故開源的插件都是咱們在內部實踐成熟後，纔有可能做爲社區的角色分享出來。

字字珠璣：請問下大佬們這麼擁抱社區有基於KPI考覈的部分在驅動嗎?而後有新的項目直接上node的嗎?仍是就是用node替換原來成熟的體系?

天豬 ：

1. 擁抱社區一直都是阿里的傳統，咱們有阿里開源小組。
2. 咱們本身自己就很受益於開源社區，回饋是理所固然的。甚至咱們不少人都是從社區招募進來的。
3. 開源其實有好處的，就好像咱們如今招人，不少已經具有 egg，ant design 的能力，有效的下降了人員招聘篩選和培養成本。
4. 開源歷來都不多是 KPI。咱們的 KPI 之一是各自團隊的工程基建，只是爲了更好的完成這一目標，咱們會考慮協做和創建生態，而後順便分享出去。
5. Egg 也歷來不是一個實體團隊，咱們都是分佈在不一樣部門不一樣城市的，不可能有同樣的 KPI。

『替換體系』這事情真的很難，不是說說就能夠的，涉及到生態，運維基建，中間件 SDK ，監控，應用治理等等很是多的領域。Node 的目標歷來就不是替代 Java，它們的定位是不同的，是互補的。阿里的 Node.js 也是蘇千樸靈等前輩們足足經歷了 8 年的開荒，才衝出一條血路，有了今日的開花結果。

皮一下很開心的問題

請問你爲何叫天豬…？ ─ @諾墨

請問你爲何叫天豬……

大學時暱稱是阿天，咱們那個時代流行加個豬後綴做爲暱稱，所以。。。

天豬和飛豬有啥關係？ ─ @bearever

天豬和飛豬有啥關係?

他們給我發過一枚飛豬天使用戶勳章。

---

本期 AMA 社區小夥伴提了許多實用問題，感謝天豬認真地爲掘金小夥伴解答了很多疑問。瀏覽更多的問答，能夠到天豬的 AMA 進行閱讀和討論。

---

本週 AMA：《開發者必備的 Docker實踐指南》小冊做者--有明

本週 AMA 正在進行 時間：2018.11.13 - 2018.11.15，活動傳送：👉戳這裏

本週 AMA 嘉賓爲《沒什麼難的 Docker》書籍、《開發者必備的 Docker實踐指南》小冊做者--有明，你們有任何關於 Docker 、虛擬化、容器技術、我的成長、團隊管理問題均可以找他交流技術~