一名全棧工程師Node.js之路－轉

時間 2019-11-12

標籤一名工程師 node.js node 之路欄目 Node.js 简体版

原文原文鏈接

Node.js 全球現狀

雖然 Node.js 在國內沒有盛行，但據 StackOverflow 2016 年開發者調查，其中 node.js 、全棧、JavaScript 相關的技術在多個領域（包括全棧、後端）都有排名領先。 javascript

（ http://stackoverflow.com/research/developer-survey-2016 ）php

後端分佈css

（ http://stackoverflow.com/research/developer-survey-2016 ）html

Node.js 與生俱來的 2 個特性：前端

event-driven
non-blocking I/O

之前總強調的異步特性，到今天異步已經不是明顯優點。所以除了性能，其餘都是病（不足）？vue

一、Callback hell 問題html5

目前已經很好的解決了。promise / generator / async 後面會講。java

二、包管理node

npm 已是開源世界裏最大的包管理器了，模塊很是豐富（25.6萬）。mysql

Node.js’ package ecosystem, npm, is the largest ecosystem of open source libraries in the world.

之前咱們老是喜歡拿異步說事兒，如今咱們拿 Node.js 的強大的生態來炫耀。

爲何選擇 Node.js？

空弦科技作的是基於雲倉儲的 SaaS 服務，給中小賣家提供服務，核心系統是進銷存、訂單池、WMS。

先看一下咱們的瓶頸在哪裏

人（天津很差招人）。Node.js 招不到，好多都是從 Java 轉的，前端也很差找，好多也是從 Java 轉的，咱們至關於從 0 開始組建團隊
開發速度。創業公司 5 分鐘要造火箭，你們都懂。因此讓開發快速進入狀態，提升開發速度，對咱們來講相當重要。
穩定。在沒有專業運維人員的狀況下，如何保證系統可用、穩定。

因而就引出了我認爲的 Node.js 好處

一樣不優化，性能比大部分語言好。即便優化，也比其餘語言簡單，好比Java。
有足夠多的選擇和架構的平衡。
如實在不夠，Java 補。

Node.js 給了咱們足夠的選擇工具

能夠採用面向過程
能夠面向對象
能夠函數式

甚至能夠用各類編譯器 coffee、typescript、babel（es）等。對於從 0 開始的團隊來說，能夠先面向過程、而後隨着團隊的成熟度，一點一點增長難度。

提供好的基礎和包管理工具

測試相關 tdd / bdd 測試覆蓋率
規範化 standard、各類 lint、hint
構建相關 gulp、grunt、webpack，大量插件
生成器 yo 等
包管理工具 npm 足夠簡單易用

以上這些都作大型軟件的基礎，Node.js 在這方面作得很是好

特定場景的快速

不少人把 MEAN 組合（好比 mean.io）起來，這樣作的好處是若是熟悉，開發速度確實會很是快，可是難度太大，不多有人能搞的定。metetor 模糊了服務端和客戶端，是同構的典型應用，對於實時場景是很是高效的。這種東西都算特定場景的快速，通常不敢輕易上，調優難度很是大，若是有人能 cover 的住，在初期是很是高效的。

總結需求：能夠簡單，能夠難；能夠快、也能夠慢；能夠開發大型軟件

若是以上不知足咋辦？這時就須要架構平衡了。

架構平衡

在架構中各自作各自合適的事兒就好，咱們很坦然的面對 Node.js 的優勢和缺點，作好架構平衡。

一、在語言層面能夠作，那語言層面作

已有大量 npm 上的模塊 ( 目前在 25.6 萬個以上 )
本身造輪子 ( 站在海量包上簡單語法 npm = 快速 )
使用 Node.js 裏的（nan https://github.com/nodejs/nan ）本身包裝 C/C++ 輪子

從上面看，絕大部分需求均可以知足了

二、若是語言層面搞不定，那就架構層面作

業務邊界、模塊拆分、面向服務
MQ、RPC、cache
運維、監控、自動化

稍微解釋一下，首先，架構與 Node.js 沒直接關係。其次，架構師經常使用的東東有足夠的 Node.js 模塊支持，好比 MQ，像 Rabbitmq 有比較好的 Node 模塊支持，RPC 裏 Thrift、Grpc、Tchannel 支持的都不錯，咱們使用的 senecajs，Redis，ioredis 等軟件，後面作 HA 都是同樣的。

三、若是架構層面也解決不了……

合適的場景用合適的東西。有不少東西是 Node.js 不擅長，又不在架構範疇裏的，咋辦？如實在不夠，Java 補（嚴格點，應該叫其餘語言補）

好比複雜 excel 生成
好比 apns 推送（Go 作其實也很好，不過除了我，沒人能維護）

但凡是 Java 或其餘語言裏比較成熟的庫，能夠做爲獨立服務使用的，均可以作 Node.js 的支持。避免過多的時間用在造輪子上，影響開發進度。

四、Node.js 優劣分析

執行效率，一樣不優化，性能比大部分語言好。
開發效率，Node.js 自己比較簡單，開發效率仍是比較高的。完善的生態，好比測試、工具、npm 大量模塊。
缺乏 Rails 同樣的大殺器，scaffold 腳手架，ORM 太弱。

Node.js 的 Web 開發框架 Express、Koa 等，簡單，小巧，精緻，缺點是集成度不夠，目前已有的 MEAN 或 yo 或 sails 等總有某種方面的不滿意

團隊 Node.js 使用現狀

選擇 Node.js 咱們須要作的包括：固化項目結構；限定 ORM；自定義腳手架。

因爲 Node.js 已經提供如下特性，所以你能夠在 30 分鐘完成一個腳手架。

cli 命令模塊，編寫很是容易
基於 JavaScript 的模板引擎（知名的 30 ）

咱們用Node.js作什麼？

API 服務
前端（moa-frontend）
SDK（OAuth Provider）
輔助開發 cli 工具

目前進度

使用 0.10.38，開發 Moajs 框架，Express / MongoDB
pm2 部署, 先後端分離，阿里雲的 slb 負載，alinode 監控
moa-api, moa-frontend, moa-h5 (未能用)
使用 Redis 緩存，Rabbitmq，senaca 做爲 RPC

一些正在建設的方面

使用 kong 做爲 API gateway
consul 作服務發現和配置
上 elk 做爲日誌分析處理
使用 docker compose 做爲本地開發環境
線上 docker

打算進行技術棧更新，包括Nodejs 4.x（預計今年 6 月份；Koa（generator/co）；es6/es7 ( babel )。

4.x 在內存和性能上都有很是大的提高，新的語言特性上，異步流程和語法上都須要學習，故不急於升級，待人才梯隊完善。

目前的作法是小步快走，一次只上同樣新技術；另外造成梯隊，便可準備上新東西；善用 npm，實現 3 化：模塊化、最小化、服務化

爲何選擇 MEAN 架構

MEAN 架構

MEAN 是目前最潮的全棧 JavaScript 架構。MEAN 是一個 JavaScript 平臺的現代 Web 開發框架總稱，它是 MongoDB Express AngularJS Node.js 四個框架的第一個字母組合。它與傳統 LAMP 同樣是一種全套開發工具的簡稱。

從個人角度看

MySQL 用 MongoDB 替換，NoSQL 裏最像 rdbms 的，從開發和性能都是有優點的（參看老畢在高可用架構羣分享文章：MongoDB 2015回顧：全新里程碑式的WiredTiger存儲引擎）。
Angular 的出現是一個時代，IoC，雙向綁定，指令等都曾讓無數熱血沸騰。
Node.js 提供了徹底的生態和工具鏈，你要的它基本都有，感謝 npm，早些年 Node.js 的性能甩 php 幾條街的。
Express 做爲 Node.js 示範項目，它很是精簡，是比較合適的 Web 框架

我爲何選擇 MEAN 架構？

成熟、穩定，簡單，有問題咱們能 cover 住，因此咱們選了 Node.js。
把握趨勢，之後 Node.js 的前景很是看好，尤爲先後端統一，全棧方向。
在架構上能夠屏蔽可能風險，不背注一擲，也不會一葉障目，合理的使用其餘語言，只要每一個功能都以服務出現，至於它是什麼語言寫的，並不重要。
招人成本的性價比相對較高，技術棧新，容易吸引人才。

最重要的一件事兒，是當有問題的時候，有人能 cover 住，在創業初期這是最最重要的事兒。

Node.js最新Web技術棧https://cnodejs.org/topic/55651bf07d4c64752effb4b1

Node.js 異步流程

異步流程控制

JavaScript 流程控制的演進過程，分如下 5 部分：

回調函數Callbacks
異步JavaScript
Promise / a+ 規範
生成器Generators/ yield ( es6 )
Async/ await ( es7 )

目前全部版本都支持 Promise / a+ 規範
目前 Node.js 4.0 支持 Generators/ yield
目前不支持 es7 裏的 Async/await，但能夠經過 babel 實現

總體來講，對異步流程控制解決的仍是比較好的。

Node.js 最新技術棧之 Promise 篇https://cnodejs.org/topic/560dbc826a1ed28204a1e7de

快速開發實踐

業務邊界優化

創業公司有不少可變性，要作的系統也無數，如何保證業務系統的邊界是很是難的，咱們其實走了不少彎路。

靜態 API 理論

當需求和 UE 定下來以後，就開始編寫靜態 API，這樣 APP、H五、前端就可使用靜態 API 完成功能，然後端也能夠以靜態 API 爲標準來實現，總體效率仍是比較高的。

API 的最佳實踐

http://developer.github.com/v3/ （嚴格的restful）

微博 API (可讀性強，相對比較傳統)，咱們採用的微博 API 相似的，約定結構也是相似的。

res.api is an express middleware for render json api , it convention over api format like this :{ data : {}, status: { code : x, msg : "some message" }}

客戶端 API 開發總結https://cnodejs.org/topic/552b3b9382388cec50cf6d95

約定結構

和 Java 開發裏的目錄結構相似，該分層的分層，適當的按照 Express/Koa 增長中間件、路由等目錄，便於開發。

使用 npm 模塊化

使用 npmjs 的 private 私有模塊（目前作法）
使用 npm 的本地模塊開發方法（測試和部署都很是快）
搭建 npm 私服（todo）

編寫生成器

在 Web 開發裏，寫了 Moajs 生成器，相似於 rails

moag order name:string password:string

其餘開發，如 iOS 開發裏模型校驗很是煩,因而寫了一個 json2objc 命令行工具，讀取 json，生成 oc 代碼，能夠節省很多時間

Moajs 框架和先後端分離

前端（moa-frontend https://github.com/moajs/moa-frontend ）
public下面的採用 Nginx 作反向代理
其餘的採用 Express Jade 精簡代碼（ajax與後端交互）
後端（moa-api https://github.com/moajs/moa-api ）

moa 生成器，即上面講的生成器 scaffold。

moa-frontend 技術棧：Express / Jade / bootstrap、bootstrap-table / jQuery / gulp / Nginx

moa-api 技術棧：

base2(mirco kernel) https://github.com/base-n/base2-core
mongoose https://github.com/Automattic/mongoose
bluebird https://github.com/petkaantonov/bluebird
res.api https://github.com/moajs/res.api

Features

自動加載路由，自帶用戶管理，使用 jsonwebtoken 作用戶鑑權
支持 MongoDB 配置，集成 mongoosedao，快速寫 CRUD 等 dao 接口
支持 migrate 測試，Mocha 測試
默認集成 res.api，便於寫接口
集成 supervisor，代碼變更，自動重載，gulp 自動監控文件變更，跑測試
gulp routes 生成路由說明
使用 log4js 記錄日誌

從開發效果上看，仍是很是快的，很是穩定的。

Moajs框架演進之路https://cnodejs.org/topic/567e2388aacb6923221de469

全棧 or 全爛？

Node.js 相關工具

grunt/gulp/fis/webpack
bower/spm/npm
tdd/bdd cucumber/mocha
standard
babel/typescript/coffee

前端開發四階段

Html/css/js（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone（mvc），Angularjs、Vuejs（當前流行）
React組件化（將來趨勢）、Vuejs

Vuejs 綜合 Angular 和 React 的優勢，應該是下一個流行趨勢。

Hybrid 開發

Hybrid 混搭開發是指使用 H5 技術開發的跨瀏覽器應用，並最終能夠將 HTML5/js/css 等打包成 apk 和 ipa 包的開發方式。它也能夠上傳到應用商店，提供給移動設備進行安裝。它最大的好處是經過 H5 開發一次，就能夠在多個平臺上安裝。

將來將會是 JavaScript 一統天下（Node.js 作後端，傳統 Web 和 H5 使用 Javasctipt，更智能的工具如 gulp，更簡單的寫法如 coffeescript 等）。H5 大行其道（網速變快，硬件內存增加）。

跨平臺

C/S 架構到 B/S 架構，這個大部分都清楚，很少說。

移動端加殼，在瀏覽器上作文章，把頁面生成各個移動端的 app 文件。

PC 端加殼，同樣是延續瀏覽器作文章，不過此次把頁面生成各個 PC 平臺的可執行文件。

node-webkit is renamed （ NW.js ）
Electron - Build cross platform desktop apps with web technologies

目前比較火的編輯器都是基於 Electron 打包：

Atom
vscode

組件化：統一用法

react 的出現影響最大的是 JSX 的出現，解決了長久以來組件化的問題：

咱們反覆的折騰 JavaScript ，依然沒法搞定
咱們嘗試 OO，好比 extjs
咱們最終仍是找個中間格式 JSX

單純的 React 只是 view 層面的，還不足以應用，因而又有 Redux。核心概念：Actions、Reducers 和 Store，簡單點說就是狀態控制，而後再結合打包加殼，變成 app 或可執行文件。ios、Android 上用 Cordova，PC 上使用 Electron。

總結

組件定義好（React）
控制好組件之間的狀態切換（Redux）
打包或加殼（Cordova or Electron）

這部分其實組件化了前端，那麼可否用這樣的思想來組件化移動端呢？

react-nativehttps://github.com/facebook/react-native)A framework for building native apps with React. http://facebook.github.io/react-native/

簡單點說，就是用 React 的語法來組件化 iOS 或 android SDK。它們都在告訴咱們，大家之後就玩這些組件就行了，你不須要知道複雜的 SDK 是什麼。

當下流行玩法

Medis is a beautiful, easy-to-use Redis management application built on the modern web with Electron, React, and Redux. It’s powered by many awesome Node.js modules, especially ioredis and ssh2. https://github.com/luin/medis

技術點

使用 Node.js 模塊
使用 Webpack 構建
使用 React（視圖） Redux（控制邏輯）
使用 Electron 加殼打包

親，你看到將來了麼？

如何全棧？

講了 Node 工具，前端 4 階段，hybrid，各類跨平臺，目前就是爲了介紹 Node 全棧的各類可能，下面講一下如何能作到 Node 全棧？

全棧核心，後端不會的 UI（界面相關），前端不會的 DB（業務相關），只要打通這 2 個要點，其餘就比較容易了。

一、從後端轉

作後端的人對數據庫是比較熟悉，不管 mongodb，仍是 MySQL、Postgres，對前端理解比較弱，會基本的Html，Css，模板引擎等比較熟悉。

4 階段按部就班，build 與工具齊飛，前端開發 4 階段，個人感受是按照順序，按部就班。

Html / Css / JavaScript（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone，Angularjs（當前流行）、Vuejs
React（將來趨勢）、Vuejs

Vuejs 綜合 Angular 和 React 的優勢，應該是下一個流行趨勢

二、從前端轉

從前端日後端轉，API 接口很是容易學會，像 Express、Koa 這類框架大部分人一週就能學會，最難的是對 DB、ER 模型的理解，說直白點，仍是業務需求落地的理解

咱們來想一想通常的前端有什麼技能？

Html
Css（兼容瀏覽器）
JavaScript 會點（可能更多的是會點 jQuery）
PS切圖
Firebug 和 Chrome debuger會的人都不太多
用過幾個框架，大部分人是僅僅會用
英語通常
Svn / Git 會一點

那麼他們若是想在前端領域作的更深有哪些難點呢？

基礎：OO，設計模式，命令，Shell，構建等
編程思想上的理解（MVC、IoC，規約等）
區分概念
外圍驗收，如 H5 和 hybird 等
追趕趨勢，如何學習新東西

以上皆是痛點。因此比較好的辦法：

玩轉 npm、gulp 這樣的前端工具類（此時仍是前端）
使用 Node 作先後端分離（此時仍是前端）
Express、Koa 這類框架
Jade、ejs 等模板引擎
Nginx
玩轉【後端】異步流程處理 promise / es6 的 ( generator | yield) / es7 ( async|await )
玩轉【後端】MongoDB、Mysql 對應的 Node 模塊

從咱們的經驗看，這樣是比較靠譜的。 Moa FrontEnd 就是最簡單先後端分離，裏面沒有任何和 DB 相關。

技術棧

Express
Jade
bootstrap，bootstrap-table
jQuery
gulp
Nginx

通常的前端都很是容易學會，基本 2 周就已經很是熟練了，個人計劃是半年後，讓他們接觸【異步流程處理】和【數據庫】相關內容，學習後端代碼，就能夠全棧了

三、從移動端轉

移動端分：native 原生開發，hybrid 混搭式開發。原生開發就是 iOS 用 oc/Swift，Android 用 Java 或 Scala 等，就算偶爾嵌入 webview，能玩 JavaScript 的機會也很是好少。因此移動端轉全棧的方法，最好是從 cordova（之前叫 phonegap）開始作 hybrid開發。只要關注 www 目錄裏的 H5 便可，比較簡單。若是 H5 不足以完成的狀況下，能夠編寫 cordova 插件，即經過插件讓 JavaScript 調用原生s dk 裏功能。cordova 的 cli 能夠經過 npm 安裝，學習 npm 的好方法，學習 gulp 構建工具。

只要入了 H5 的坑，其實就很是好辦了。

而後 H五、Zeptojs、iScroll、fastclick 等
而後微信經常使用的，如weui、vux（vue weui）、jmui（react weui）
而後能夠玩點框架，好比 jQuery mobile，Sencha touch
而後能夠玩點高級貨，ionicframework（基於Angularjs、cordova）
而後前端 4 階段，依次打怪升級
而後 Node.js

這個基本上是我走的路，從 2010 年寫 IOS、作 phonegap（當時是0.9.3）一路走到如今的總結吧。

展望 Node.js 技術將來

Node.js 多是一場春夢，

也可能一個變革機遇；

咱們更相信它是變革機遇，

請拭目以待！

附：Node.js 2015 發展歷史

Q1 第一季度

IO.js 1.0.0 發佈
Joyent 推動創建 Node.js 基金會
Joyent，IBM，Microsoft，PayPal，Fidelity，SAP and The Linux Foundation Join Forces to Support Node.js Community With Neutral and Open Governance
IO.js 和 Node.js 和解提案

Q2 第二季度

npm 支持私有模塊
Node 項目領導人 TJ Fontaine 逐步解除核心身份並離開 Joyent 公司
A changing of the guard in Nodeland
Node.js 和 IO.js 在 Node 基金會下合併狀況

Q3 第三季度

4.0 版本發佈，即新的 1.0 版本

Q4 第四季度

Node v4.2.0，首個長期支持版本（LTS）
Apigee，RisingStack 和 Yahoo 加入 Node.js 基金會
Node Interactive
The first annual Node.js conference by the Node.js Foundation

版本帝？去年從 v0.10.35 開始

2015-01-14 發佈了 v1.0.0 版本（IO.js）
2.x（IO.js）
3.x（IO.js）
2015 年 09 月 Node.js 基金會已發佈 Node.js v4.0 版與 IO.js 合併後的第一個版本
2015 年 10 月 Node.js v4.2.0 將是首個 LTS 長期支持版本
年末發佈到 4.2.4 && 5.4.0

目前（2016 年 3 月 20 日）的 2 個版本

v4.4.0 LTS（長期支持版本）
v5.9.0 Stable（穩定版本）

總體來講趨於穩定。

成立了 Node 基金會，可以讓 Node.js 在將來有更好的開源社區支持。
發佈了 LTS 版本，意味着 API 穩定。
快速發版本，不少人吐槽這個，其實換個角度看，這也是社區活躍的一個體現，但若是你們真的看 CHANGELOG，其實都是小改進，並且是邊邊角角的改進，也就是說 Node.js 的 core（核心）已經很是穩定了，能夠大規模使用。

(參考連接： http://i5ting.github.io/history-of-node-js/ ）

Node.js 企業級大事記

Node.js 的企業級大事兒記

2014年 nearform （ Node.Js 爲何會成爲企業中的首選技術？）

2015年 IBM （收購 StrongLoop，拓展雲服務業務）

Node.js 基金會的創始成員包括 Joyent、IBM、Paypal、微軟、Fidelity 和 Linux 基金會。

對於企業級開發，Node.js 是足夠的，不管從性能、安全、穩定性等都是很是棒的。

空弦科技作的是基於雲倉儲的 SaaS 服務，給中小賣家提供服務，核心系統是進銷存、訂單池、WMS。目前來看不存在任何問題，

es && babel

2015 年 ECMA 國際大會宣佈正式批准 ECMA-262 第 6 版，亦即 ECMAScript 2015（曾用名：ECMAScript 六、ES6）的語言規範。

babel （http://babeljs.io/）做爲 es 編譯器，已經大量開始使用了，模塊作的很是棒，還有人用babel寫其餘語言編譯器。Node.js 裏在 0.12 以後才增長 es6 特性，es7 的目前還不支持。因此在 Node.js 裏使用 es 裏比較高級的特性，是須要 babel 去編譯處理的。這是 Node 追逐的標準。

2016 年 01 月 22 日，（微軟請求 Node.js 支持 ChakraCore https://github.com/nodejs/node/pull/4765 ）

將來 Node.js 不僅是基於 chrome v8 內核，它還能夠支持更多其餘瀏覽器內核，對生態、效率提高等很是有好處。

蔡偉小兄弟的查克拉 benchmark 的對比（ https://github.com/DavidCai1993/ES6-benchmark ）基本結論是 V8 ES5 > 查克拉 ES6 > 查克拉 ES5 > V8 ES6

Q & A

1. 在全棧的語言選擇上，除了 Node.js，是否還考慮過其餘語言？

桑世龍：有的，將來 swift 和 Lua 是有可能的。swift 的語法和性能上有很大優點，Lua 在 openresty 的推進下也有機會，不過沒有 swift 大。像 WebAssembly 之類的就不太看好了。

2. 請教桑老師：剛纔你說的併發開發流程中靜態 API 指的是 API 文檔？若是是的話誰負責編寫？大家目前已是一我的分模塊從前端寫到後端了嗎？

桑世龍：目前沒作到文檔即靜態 API，因此目前是直接提供 json 和部分（json-server https://github.com/typicode/json-server/ ），負責是後端開發的 leader 在寫，他的進度會比正常開發要早一週左右。目前不是一我的寫全部的先後端，團隊成立不久，天津 Node.js 會的很少，因此仍是先後端分離。可是經過 moa-frontend 可讓前端了解 Express 等後端知識，適當的時候會給予機會，前端轉後端。

3. 貴司在開發協做中提到了靜態 API，請問是否是有什麼比較好的工具能夠推薦？

桑世龍：Node.js 裏（json-server https://github.com/typicode/json-server ）比較好

我其實很想圍繞靜態 API，寫各類請求的生成器，只要 API 出來，文檔和各平臺的 HTTP 請求代碼就生成出來，同時能夠對正式 API 進行壓測，惋惜目前還沒精力寫。

4. 作 hybrid app 在移動端會遇到性能問題吧，有沒有什麼優化經驗能夠分享？

桑世龍：足夠輕量級，少選大框架，作好前端該有的優化。注意 touch 和 click 的區別，好比 fastclick 或 Zeptojs 的 tap 手勢。Chrome profile（CSS3動畫）。使用 weinre 真機測試。參考：（個人 H5實踐。

5. 若是都全棧了，當前大家團隊是如何分工的？

桑世龍：咱們團隊仍是傾向於分工專業化，各個服務粒度很是小，便於輪崗、還有就是能夠爲之後像 Google 那樣代碼開放作準備。可是有不少狀況下，是須要有機動的突擊隊的（尤爲是創業時期），這樣能夠隨便組合，另外就是全棧爲 remote 提供了更多便利性。

6. H5 在手機上用 iScroll 坑比較多啊尤爲三星打開硬件加速的時候 render 頁面，桑老師怎麼看？

桑世龍：能夠嘗試一下淘寶系的 H5 虛擬化，鬼道曾經在 as 大會上講過的，咱們目前還沒能力作這麼深層次的優化。

7. Node.js 作業務金額計算的金額性能和精度夠嗎

桑世龍：你問的不是 Node.js，而是 Node.js 要操做的數據庫。耗性能的計算能夠在架構上平衡的，若是能夠延時，MQ 就能夠了。若是是非延時狀況，能夠採用其餘語言編寫對應服務，不必非要必定要 Node.js。咱們目前的場景，尚未在計算遇到瓶頸。

8. 關於 API 返回格式那裏，對於 status 爲何不打平了把 code 和 message 放出來？這麼設定有什麼好處麼？