轉發：Midway Serverless 釋出 2.0，一體化讓前端研發再次提效
自去年 Midway Serverless 1.0 釋出之後，許多業務開始嘗試其中，並利用 Serverless 容器的彈效能力，減少了大量研發人員對基礎設施和運維的關注。對前端開發者而言，他們只需寫幾個函式即可實現後端業務邏輯，推動業務快速上線。去年我們也說，使用了 Serverless 的架構，可以讓整個前端研發效能提升。
在 2021 年 3 月，我們推出了 Midway Servereless 的第二個大版本。就像兩年前說的一樣，開源只是開始，終態遠沒有到來。Midway 體系希望能夠在當前的十字路口，不斷向前演進，讓前端可以去發展，朝著應用工程師前進。
Midway Serverless 2.0 的內部代號是 “Hercules”，是希臘神話以及漫威中的大力士，藉由半神半人的出生，初步邁向成神之路。而我們，藉由使用者在 v1.0 的使用情況，我們看到了不少問題，這一次 v2.0 的迭代重構，我們希望去解決這些問題，讓使用者體驗和開發效率更進一步。
Midway Serverless 的演進
Midway Serverless 是 Midway 產出的一套面向 Serverless 雲平臺的開發方案。其內容主要包括函式框架 @midwayjs/faas ，以及一系列跟平臺配套的工具鏈，啟動器等。
在 2020 年初發布之後，在同年 6 月，又釋出了前後端一體化方案，可以方便的在前端程式碼直接呼叫函式端程式碼，我們將這一體化方案應用到了集團的中後臺專案，效果顯著。
同年 9 月，我們釋出了全新的 midway 應用框架的第二個版本，引入了元件生態，之後 swagger，typeorm，mongo，gRPC 等元件不斷的孵化，大大擴充了 Midway 的能力。
在 2021 年 3月，我們釋出 Midway Serverless 2.0，在原有的基礎上，Midway Serverless 和 Midway 的能力將複用，有著相同的 CLI 工具鏈，編譯器，裝飾器等等。
Midway Serverless 2.0 的最大變化
就像前面提到的一樣，Midway Serverless 是一套面向 Serverless 的解決方案，它包括框架，執行時，工具鏈，配置規範幾個部分，這幾部分的組合之後，提供了一些面向 Serverless 體系的特有能力。
傳統 v1.0 時，我們主打：
- 平臺間遷移更容易，讓程式碼在不同的平臺相同
- 讓應用更易維護和擴充套件，提供了標準的雲平臺函數出入參事件定義
- 讓傳統應用無縫部署到 Serverless 環境
而 v2.0，我們主打的是應用函式一體，前端和後端一體，體驗更加，開發效率更高。
原有的 v1.0 底層是通過編譯，包含一個令人煩惱的 .faas_debug_tmp 目錄，不少開發的同學都踩過它的坑，一旦出錯，難以排查。
這本質上，是由於沒有采用和應用相同的程序重啟方案，也是因為函式開發和傳統不同，技術選型差異造成的。函式的執行和快取，造成了 v1.0 資料可能不更新，經常出現改了程式碼無效的情況。
在新的 v2.0 中，我們徹底拋棄了原有的編譯方式，採用了和應用相同的實現方式，同時又對函式場景做了優化，對使用者來說，在某些場景下（HTTP），開發函式和開發應用是相同的結構和體驗，函式和應用只有部署時有差異。
可以看看優化後的開發情況，不僅和應用一樣，速度還比較快，也不會生成臨時目錄，修改實時生效。
這是 v2.0 和 v1.0 的根本性變化，也是整體架構升級帶來的巨大優勢。
當然，這一塊並不是功能的新增，除了架構升級之外，我們還提供了更多的能力。主要分成下面四大方面。
v2.0 純函式增強
首先，我們在純函式開發的場景下，對 HTTP 場景的函式，包括（HTTP觸發器，API 閘道器等）做了額外的增強支援。
v2.0 升級 - 裝飾器統一
v1.0 時期，我們將觸發器的各個引數定義在 f.yml 中，雖然在雲原生看來是標準的，但是實際在編寫程式碼的時候，使用者覺得非常繁瑣，特別是加上我們的依賴注入容器中 @Func 裝飾器和類的命名，函式名 + handler 名 + 類名 + 方法名使用者需要命名多遍。
v2.0 版本開始，我們直接沿用應用的開發方式，使用原有的 @Controller 裝飾器應用到 HTTP 函式的開發中。
同時，原有 f.yml 裡的 functions 欄位將不再需要填寫，我們的釋出工具會自動從程式碼中分析路由，註冊函式。
除了 @Controller 裝飾器，我們也支援傳統應用的引數裝飾器，比如 @Query ， @Body 等常用的從請求中獲取引數的裝飾器，也支援例如 SetHeader ， ContentType 等對響應操作的裝飾器。
除了裝飾器統一之外，我們將原有的 @midwayjs/faas 框架也接入到了新的 Framework 體系，現在 @midwayjs/faas 成為了函式 Framework，它也擁有和應用相同的 Application ， Context 定義。比如下面的 app 方法，和應用完全一致。
為了更好的支援函式式的寫法，我們對入口的 configuration.ts 增加了函式式寫法，這樣在一體化等函式式場景也可以選擇函式是寫法來編寫。
v2.0 升級 - 工具鏈升級
從 midway v2.0 開始，我們使用 @midwayjs/cli 作為我們的基礎 cli 工具，原有的函式 cli（@midwayjs/faas-cli）將逐步完成它的歷史使命，也將統一到 @midwayjs/cli 中。
傳統的 cli 是把所有的功能都組合成一個大包，放到一個 npm 包下，這樣每個應用都要裝一份，比較佔用硬碟空間和資源。新版本我們做了一個按需載入能力，按照場景進行區分，比如函式和應用場景安裝的 cli 工具就會不同。
這樣的好處是，新版本的 cli 安裝的包比較少，自然速度就快。同時，也能夠自由的去組合其中的外掛，將其更合理的應用到不同的場景中。
v2.0 升級 - 單元測試
針對原有函式的單元測試的情況，我們也做了調整。
原來的 invoke 方法，雖然簡單，但是很難跟建立應用的流程結合，每次 invoke 都是一次完整的初始化邏輯和呼叫，而且在 HTTP 的場景下，要填寫的引數眾多，難以模擬實際的效果。
![image.png]https://gw.alicdn.com/imgextra/i4/O1CN012AmHlg1XGPfqLNKGL_!!6000000002896-2-tps-1920-1080.png)
新版本，我們沿用了應用的思路，既然能用應用模式啟動，那自然也使用應用的開發方式，使用 supertest 來做測試，比原來簡單和自然多了。
v2.0 升級 - Web 模式
在 v1.0 時期，我們針對業界常用的 egg/koa/express，做了將應用程式碼無縫遷移到 Serverless 環境的功能，這三種框架都可以在 f.yml 中增加 deployType 的方式，通過構建自動化生成入口，支援傳統應用上彈性容器的訴求。
之前也有使用者問道，如果我程式碼不希望再跑在函式環境了怎麼辦？v2.0 的答案是，你可以將那些程式碼，通過應用的模式部署到自己的傳統容器，或者 Docker。
部署的方式很簡單，由於使用了 @midwayjs/serverless-app （上面測試提到過），和應用一樣的編碼模式，就可以啟動一個 HTTP 應用了。
v2.0 一體化能力增強
去年 6 月，我們向社群開放了一體化編碼的方案，使用函式式編碼，類 React Hooks 的編碼方式，讓前端開發的同學無比熟悉。
在 v2.0 之中，我們進一步增強了這套一體化方案，讓前端開發的體驗進一步提升。從下面這四個方面，我們將一一為大家介紹。
一體化增強 - 極速啟動
首先是極速模式，傳統的 React/Vue 開發/構建的時間大家也都瞭解，Webpack 的工作時間往往接近 20s，而得益於最近新出的 vite，經過我們的測試和使用，傳統的 20s 將縮減到了 2s 以下，可以說前端再一次得以飛躍。
而 vite 良好的相容性，可以包容非常多的前端框架，雖然 vite 剛出不久，相信過不了多久，就會在全前端場景鋪開。
一體化增強 - 單元測試
第二個方面是單測，傳統的一體化，由於編譯的存在，我們的單測十分困難，有使用者不止一次的問我們，怎麼做單測，怎麼優雅的做前後端呼叫。
在新的 v2 中，我們採用了兩種方案做測試。
即可使用 supertest 來執行傳統的 HTTP 行為模擬做單測，也可以使用我們提供的 runFunction 函式來做單測。
一體化增強 - 支援應用
第三個特性是非常令人驚喜的，一體化專案除了能在函式場景下使用，如今，我們也將其沿用到了應用開發上。傳統的 Midway 專案也可以使用一體化方案開發了。
一體化增強 - 執行時升級
在 v1.0 時期，由於編譯器的限制，我們的入口函式編寫時有著諸多限制，但是在 v2.0 的時候，我們將執行時換成了原生框架以及原生的 node 模組，這樣以前的種種限制都不存在了。
同時，你也可以編寫自己的 hooks 模組，將業務邏輯輕鬆的組合到一起。
未來
Midway Serverless 2.0 提供了諸多能力的升級，但是還遠遠不夠，我們依舊在不斷提供新的能力，讓不同的場景都豐富起來，讓前端可以遊刃有餘的享受到新體系的紅利。
未來，是 Serverless 和雲的時代。