阿里 Midway 正式釋出 Serverless v1.0，研發提效 50%

Github: https://github.com/midwayjs/midway， 開源為了前端和 Node.js 的發展，請到 Github 點 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 體系的特有能力：

1. 平臺間遷移更容易

   • 透過提供統一的配置規範以及入口抹平機制，讓程式碼在每個平臺基本相同；

   • 擴充套件不同雲平臺的執行時 API，不僅能載入通用的平臺間擴充套件，也能接入公司內部的私有化部署方案；

2. 讓應用更易維護和擴充套件

   • 提供了標準的雲平臺函式出入參事件定義；

   • 提供了多套和社群前端 React、Vue 等融合一體化開發的方案；

   • 使用了 TypeScript 作為基礎語言，方便應用擴充套件和定義；

   • 提供了完善的 Midway 體系標誌性的依賴注入解決方案；

3. 生態更輕量和自由

   • 函式體系複用 koa 的生態和 Web 中介軟體能力，在處理傳統 Web 時更加得心應手；

   • 提供 egg 元件複用 egg 外掛的生態鏈，企業級開發鏈路更簡單順暢；

   • Midway 體系的裝飾器能力統一，讓傳統 Web 遷移到 Serverless 體系更快更好；

上面提到的全部能力，都已經在 Midway Serverless 倉庫開源，歡迎 Star。
Github: https://github.com/midwayjs/midway

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!