作者 | 張挺
Github:
https://github.com/midwayjs/midway， 開源為了前端和 Node.js 的發展，
點選直接跳轉點 Star。
去年阿裡提出 Serverless 架構，并利用其新一代研發架構，減少了大量研發人員對基礎設施和運維的關注。對前端開發者而言，他們隻需寫幾個函數即可實作後端業務邏輯，推動業務快速上線，讓整個前端研發效能提升 50%。
在過去的半年裡，Midway FaaS 收獲了很多同學的關注，也有不少大企業已經直接開始使用，在此感謝你們。今天，Midway FaaS 将演進為 Midway Serverless，并正式成為 Midway 體系的核心場景，同時正式釋出 v1.0 版本。
v1.0 版本代表着一個正式的版本，可以放心的使用。通過整個 Midway Serverless 新體系，我們将阿裡的 Serverless 能力逐漸開放，前端将進入一個嶄新的時代。就像兩年前說的一樣，開源隻是開始，終态遠沒有到來。
如今的 Serverless，是雲廠商各自開疆拓土的黃金時代，也是各位嘗試的最好年代，如今 Node.js 在這個時候成為了最佳選擇，Midway 體系也當仁不讓地站在這十字路口，去朝着引領的方向去行。
什麼是 Midway Serverless
就像前面提到的一樣，Midway Serverless 是套面向 Serverless 的解決方案，它包括架構，運作時，工具鍊，配置規範幾個部分，這幾部分的組合之後，提供了一些面向 Serverless 體系的特有能力：
- 平台間遷移更容易
- 通過提供統一的配置規範以及入口抹平機制，讓代碼在每個平台基本相同；
- 擴充不同雲平台的運作時 API，不僅能加載通用的平台間擴充，也能接入公司内部的私有化部署方案；
- 讓應用更易維護和擴充
- 提供了标準的雲平台函數出入參事件定義；
- 提供了多套和社群前端 React、Vue 等融合一體化開發的方案；
- 使用了 TypeScript 作為基礎語言，友善應用擴充和定義；
- 提供了完善的 Midway 體系标志性的依賴注入解決方案；
- 生态更輕量和自由
- 函數體系複用 koa 的生态和 Web 中間件能力，在處理傳統 Web 時更加得心應手；
- 提供 egg 元件複用 egg 插件的生态鍊，企業級開發鍊路更簡單順暢；
- Midway 體系的裝飾器能力統一，讓傳統 Web 遷移到 Serverless 體系更快更好；
上面提到的全部能力，都已經在 Midway Serverless 倉庫開源，歡迎
Serverless 和 FaaS
FaaS是 Serverless 架構的其中一種形态，也是這一次 Midway 希望解決的場景，在 v1.0 之前，我們在 FaaS 上投入了許多，但是事實上 Serverless 架構非常龐大，FaaS 隻是其中的一小部分，基于事件驅動的模型，從微服務（MicroService）這種專注于單一職責與功能的小型功能塊演進而來。如今這種更加“代碼碎片化”的軟體架構範式，相比微服務更加細小的程式單元，給業務代碼提供了無與倫比的靈活性。
今天按照《福布斯》雜志的統計，在商業和企業資料中心的典型伺服器僅提供 5%～15% 的平均最大處理能力的輸出，這無疑是一種資源的巨大浪費。而随着 Serverless 架構的出現，讓服務提供商提供我們的計算能力最大限度滿足實時需求，這将使我們能更有效地利用計算資源。
彈性容器，能夠滿足目前的對資源利用全部憧憬，也是雲平台不斷追求的目标之一，而對于開發者，不管是彈性的容器，還是彈性的函數，隻要有一套代碼能都運作其中，滿足業務的需求即可。Midway Serverless 的目标由此而來，從原來的 FaaS 場景開拓到了其他領域，不管是函數還是新的架構，我們都将一一滿足，并落地業務、反哺社群。
防平台鎖定
Vendor Lock-in 是每個使用雲平台的的人都會拷問靈魂的問題，Midway Serverless 一開始的初衷就是讓一套代碼能夠運作在不同的平台和運作時之上，我們不建議在不了解全貌時去自定義運作時，那非常的危險。事實上，官方的運作時是運作最穩定，也一定是性能最好的，所有的基準跑分都是基于此。
我們了解的大多數企業在面對 Serverless 的第一個問題就是，我的代碼是不是一定得綁死到阿裡雲，或者騰訊雲，aws 等等。
面對這個問題，Midway Serverless 提供了一套 “隐藏式” 入口加上通用化定義來解決這個問題。
針對每個平台，Midway Serverless 提供了不同的運作時啟動器，用于抹平各個平台的差異，并且通過這些啟動器，将各個平台的出入參，以及各個 event 結構，網關的傳回格式進行規則化，讓使用者盡可能不感覺底層容器以及協定的差異。
除此之外，Midway Serverless 提供了一套 Spec 定義，來抹平多個平台的差異，同時也能友善的在多個平台間複用相同的工具鍊和函數邏輯。
這樣，不管是 API Gateway，還是普通的 HTTP 觸發器，都能在統一的程式設計平面中提供 API，讓編寫代碼變的簡單。
TS 與裝飾器
函數的寫法是十分靈活的，靈活帶來了簡便，同時也帶來了維護成本。由此在函數中引入了 TS，引入了标準和擴充性。
下面的代碼，看起來似乎是 koa 的标準文法，其實是函數中面向 HTTP 觸發器的 API，為了和 Web 棧文法保持一緻，通過一些轉變，使得參數的擷取，調用都盡可能無縫銜接，也減少了學習的成本，原有的代碼也能更好的遷移過來。
另一邊，通過裝飾器修飾的方法都将變為函數入口，讓整個函數的結構變得自由。通過建構的方式，讓真實的入口隐藏起來，不僅讓函數跨多個平台調用，也可以适配到不同的路由。如上面的示例，在一個檔案中入口有多個，可以共享同一份代碼，但是實際上每個函數的調用又是獨立的，在管理和後期維護上都提供了便利。
不同雲平台的實際結構是不同，如果使用者需要使用到傳統的 event、context 結構， 我們也給不同平台觸發器提供了不同的定義，友善代碼編寫，如下圖。
複用社群生态
上面提到，Midway Serverless 體系的設計的初衷就是複用現有 koa 生态，将多個平台的底層 event 規則化成統一的類 koa API。API 相似的目的是為了整個 koa 的 web 生态，我們同時也希望整個 koa 的 middleware 生态都可以複用。如下圖，引入了
@koa/cors
。
另一面，Midway 由于出色的 IoC 元件化能力，提供了上層的 egg 基礎組建，同時也能複用現有的 egg 插件，讓傳統企業級開發的能力得以延續，比如下圖就是使用
egg-mysql
插件的示例。
前端賦能
雲 + 端的開發體驗是 Midway Serverless 目标之一，傳統應用的開發，前端和後端分離，多倉庫開發，部署分離。就算使用了 Node.js 的膠水層，也無法避免人員開發體感上的割裂。而在 Serverless 體系下，這不是什麼問題。
由于後端的大幅簡化，再加上雲服務的 BaaS 化，讓資料聚合，頁面渲染變的更容易，也能更快的讓前端上手和開發。
一體化慢慢成為了這一塊的前端訴求，所謂的一體化，不僅僅是傳統倉庫的融合，也是整個開發模式的演進，從工程體系加上代碼，CI/CD 的整套體系重塑的機會。
如今的 Midway Serverless，提供了和前端一體的開發方案，囊括了社群現有的 React、Vue 等生态，也對整個工具鍊（Webpack，ice scrips，umi 等）做了定制化方案，對不同的場景，比如部落格等也提供了開箱即用的解決方案。
至于詳細的前後端一體化能力，我們後續将單獨開一篇文章來介紹前端一體化的細節和思考。
應用和函數
Serverless 是未來一段時間的方向，也是前端邁向更高層次的鋪路磚。
之前一直在思索，如今的函數式開發的終态和應用的關系到底是什麼？
現階段，我們的答案是趨于統一，在被無數次的靈魂拷問和使用者需求的追問中，我們得出了這個答案，函數即是應用在目前業務中的最小展現，更簡單的來說，是在最小規格容器中運作應用的部分代碼。
之後的一段時間，我們将聚焦于更多平台的接入，以及傳統應用的遷移方案上，讓之前的使用者也能享受到 Serverless 彈性的紅利，讓企業成本更低，業務上線更容易。
最後
在集團大中台、小前端業務架構日趨深化的背景下，借助集團雲原生 Serverless 的發展，去年 Node.js 在業務端到端傳遞場景上看到了未來。
新一代雲 + 端的前台業務傳遞模式逐漸成為現實，這可以幫助技術團隊塑造有業務整體傳遞能力的特種兵，幫助業務快赢。但其路漫漫仍諸多不完善，為了盡早達到這一步，需要高度聚焦在兩個核心問題上：1. 規模化成本、2. 傳遞速度。
期望在未來透過我們對規模化成本、傳遞速度的持續投入，Node.js/Serverless 體系可以展現出全面的先進性。
Midway Serverless，Go!
關注「Alibaba F2E」
把握阿裡巴巴前端新動向