暢想 Serverless 新托管時代，2020 年迎來哪些新機會？

作者 | 狼叔

由于BFF更新到SFF，除了享受Serverless基建的好處外，并沒有任何業務價值的改變，是以核心隻能在提效上發揮。提效第一點是開發者體驗，這是Serverless托管前端所有場景的核心提效點。其次是搭建，搭建和Serverless托管、前端工作台集合，可以讓SFF提效更容易。中間對流程編排、智能化也有結合，相信大家能夠了解它們的價值和應用場景。

搭建、流程編排、智能化組合提效，簡化Serverless托管提效，讓前端進入輕研發時代，我相信已經不遠了。下面分享一下我關于Serverless新托管時代的暢想。

JAMS

從lamp到mean架構更新，之後就沒啥新東西了。在Egg穩定之後，也是沒有啥新意了，就算Fastify也不夠亮眼，實話講，那點性能優化不過錦上添花，還不一定趕上Node sdk更新的優化呢。

JAMstack算是一個比較新的概念，JAM是JavaScript、API和Markup的簡稱，前面第一個字母縮寫，JAMstack一種基于用戶端JavaScript，可重用API和預建構Markup的現代Web開發架構，這個價值在業界已經證明了，那麼基于serverless的JAM，應該也是值得想象的。

本節核心内容是把JAM進行延展并推到JAMS的可能性。

什麼是 JAMstack

JAMstack是指使用JavaScript、API和Markup建構的技術堆棧，需要符合下面三個标準：

• JavaScript：請求/響應周期中的任何動态程式設計都由JavaScript處理，完全在用戶端上運作。這可以是任何前端架構，庫，甚至是輕量JavaScript。
• API：所有伺服器端程序或資料庫操作都被抽象為可重用的API，使用JavaScript通過HTTPS通路。這些可以是定制的或利用第三方服務。
• Markup：模闆化标記應該在部署時預先建構，通常使用内容站點的站點生成器或Web應用程式的建構工具。

當我們談論“堆棧”時，我們不再談論作業系統，特定Web伺服器，後端程式設計語言或資料庫。JAMstack與特定技術無關。這是一種建構網站和應用程式的新方法，可提供更好的性能，更高的安全性，更低的擴充成本以及更好的開發人員體驗。

為何選擇JAMstack？

• 更好的性能：為什麼要在部署時生成頁面時等待頁面動态建構？當談到最小化第一個位元組的時間時，沒有什麼能比通過CDN提供的預建構檔案更好。
• 安全性更高：将伺服器端程序抽象為微服務API，可以減少攻擊的表面區域。您還可以利用專業第三方服務的專業知識。
• 更便宜，更容易擴充：當您的部署相當于可以在任何地方提供服務的一堆檔案時，擴充就是在更多地方提供這些檔案的問題。CDN是完美的，通常包括擴充他們的所有計劃。
• 更好的開發者體驗：松散耦合和控制分離允許更有針對性的開發和調試，并且為站點生成器擴充選擇CMS選項消除了為内容和營銷維護單獨堆棧的需要。

redwood.js

Redwood是一個全棧、無伺服器的Web應用程式架構，它使您可以輕松地建構和部署JAMstack應用。

https://redwoodjs.com/tutorial/redwood-file-structure

很明顯，這是一套很潮的技術棧，但問題是元件的ui和邏輯如何抽離？這個問題依然沒有解決。

對于GraphQL真是又愛又恨，基于模型（實體）和查詢（Query）的方式，很好的做到了解耦，但這東西基于約定寫法，必然會像Restfull api一樣，都是好東西，但在落地方面不會很理想。

GraphQL如何能夠和Formily進行內建，在模型和Schema/Form之間互轉，可以想象的空間會尤其大。

重新定義 JAMS

之前JAMStack缺點

• 缺乏對較重和動态功能的良好支援：使用 JAMStack 的主要限制之一是它不能很好地處理電子商務購物和登入等更加動态的功能。這是因為這些功能需要資料庫才能管理交易。
• 高度依賴第三方系統：高度依賴第三方系統意味着如果這些系統崩潰，那麼 JAMStack 也會崩潰。

如果把CDN換成Serverless呢？将Serverless作為托管環境，API和頁面都以函數的粒度放到Serverless上進行托管，是不是很好？

• 動态功能完美解決
• 依賴第三方系統也可以通過baas來解決

JAMStack on Serverless可以是JAMS，核心内容如下

• JavaScript：基于 JavaScript 建立動/靜态 Web 應用。
• APIs：所有的資料行為通過可複用的 HTTP 接口（RESTFul 或者 GraphQL）完成。
• Mockup：使用建構工具 prebuilt 前端應用，部署到 Serverless 環境，能夠同時支援csr和ssr。
• Serverless：利用Serverless基建優勢，提供自動擴縮容零運維的Api和頁面托管服務。

Jeff Atwood發表于2007年的這篇部落格裡，他提出了著名的“Atwood定律”，即”任何能夠用JavaScript實作的應用系統，最終都必将用JavaScript實作。

在JAMS世界裡，Atwood定律又一次完美的被證明了。

應用場景

JAMS是面向函數的Fullstack架構。它的應用場景包含了前端和sff的所有場景。

1、Zeit應用場景

2、Serverless CMS

https://github.com/webiny/webiny-js

Serverless CMS (GraphQL + React + Node.js + AWS Lambda)

More Than “Just” a CMS：Build Websites, Apps and APIs With Webiny

As a Developer You Will Benefit From Several Features

• Comes with an admin theme with over 30 React components
• Built-in server side rendering
• CSS-in-JS via Emotion
• Deployment CLI with support for multiple environments
• Foundation for building dynamic serverless sites and apps
• Designed and optimized to run inside AWS Lambda

總結一下，整體上大家除了對CSR和SSR做同構上，沒有做到極緻外，這套方案還是非常ok的。接下來，基于Serverless，補足托管能力，JAMS會有更好的發展。

Serverless 新托管時代

類似于surge.shgit pages類似的托管服務很多，那麼基于Serverless如何做托管呢？筆者如何定義Serverless新托管時代便是本節要重點聊的内容。

從 BFF 之痛到 SFF 收斂

了解托管之前，我們先看一下架構更新，從BFF到SFF的演進過程。

BFF即 Backend For Frontend（服務于前端的後端），也就是伺服器設計 API 時會考慮前端的使用，并在服務端直接進行業務邏輯的處理，又稱為使用者體驗擴充卡。BFF 隻是一種邏輯分層，而非一種技術，雖然 BFF 是一個新名詞，但它的理念由來已久。

在Node.js世界裡，BFF是最合适的應用場景。常見的API、API proxy、渲染、SSR+API聚合，當然也有人用來做網關。

從Backend For Frontend更新Serverless For Frontend，本質上就是利用Serverless基建，完成之前BFF的工作。那麼，差異在哪裡呢？

核心是從Node到FaaS，本質上還是Serverless，省的其實隻是運維和自動擴縮容的工作，一切看起來都是基建的功勞，但對于前端來說，卻是極為重大的痛點解決方案，能夠滿足所有應用場景，基于函數粒度可以簡化開發，乃生死必争之地。

Serverless簡單了解是FaaS+BaaS。FaaS是函數即服務，應用層面的對外接口，而BaaS則是後端即服務，更多的是業務系統相關的服務。當下的FaaS還是圍繞API相關的工作為主，那麼，前端如何和Serverless綁定呢？

Serverless For Frontend（簡稱SFF）便是這樣的概念，基于Serverless架構提供對前端開發提效的方案。

下面看一下SFF分工，這張圖我自認為還是非常經典的。首先将Serverless劈成2半，前端和後端，後端的FaaS大家都比較熟悉了，但前端頁面和FaaS如何內建還是一片待開發的新領域。

舉個例子，常見BFF的例子，hsf調用獲得服務端資料，前端通過ctx完成對前端的輸出。這時有2種常見應用場景

1. API，同後端FaaS（RPC居多）
2. 頁面渲染（http居多）

基于FaaS的頁面渲染對前端來說是必須的。從beidou、Next.js、egg-react-ssr到Umi SSR，可以看出服務端渲染是很重要的端側渲染組成部分。無論如何，React SSR都是依賴Node.js Web應用的。那麼，在Serverless時代，基于函數即服務（Functions as a Service，簡寫為FaaS）做API開發相關是非常簡單的，

• 1）無服務，不需要管運維工作
• 2）代碼隻關系函數粒度，面向API變成，降低建構複雜度
• 3）可擴充

大概三國演義對我來說印象最深的一句話估計就是分久必合，合久必分。本質上sff和bff做的事兒是一樣的，如果說非要去掰扯出點東西，我想分久必合也算是一種吧。

通過 Fab 看托管

FABs（Frontend Application Bundles）是一種前端應用的bundle格式。

因為 FABs 包含了 server-side JavaScript 相容能力，但可以非常簡單的同構上傳一個zip封包件就完成部署。你可以随意增加server-side 邏輯且不需要關注伺服器運維相關的複雜性。它适合如下場景。

• 釋出 server-rendered NextJS 應用到Cloudflare workers上
• 給cra建立react項目 增加 redirect 規則 ，不需要eject就能做到
• 使用 Gatsby 來生成logged-in 和 logged-out 首頁，并且可以cookie來切換登入狀态。
• 保護你的應用，防止未授權使用者操作
• 釋出每個送出到一個唯一的URL來分享協作進度
• ...等等

它原理很簡單。FABs是一個特殊的zip檔案，保護了1個元件和一個server-side JavaScript檔案，以及靜态資源assets目錄。

對于純靜态站點，spa，或一個完全的伺服器端渲染的js網站，FAB會幫你編譯你的應用到這2個檔案。

看一下寫法

const getProdSettings = () => {
  return {
    // All production settings are bundled into the FAB here,
    // ensuring predictable behaviour regardless of host.
    // These are returned as a separate entry point, however,
    // so that any encrypted variables can be decrypted
    // by the host before being passed through to the render.
  }
}

const render = async (request, settings) => {
  // request: a fetch.Request object
  // settings: your production settings plus any
  //           environment-specific overrides
  const { body, statusCode, headers } = await myApp.render(request, settings)
  // return a fetch.Response object with the full data.
  // Streaming responses not yet supported, but will be in future.
  return new Response(body, { statusCode, headers })
}

module.exports = { render, getProdSettings }           

和我們定義的ssr規範的中寫法很像，原理上并沒有本質差別。

我們再來歪歪一下。一個server.js和assets目錄就可以滿足所有的前端場景。

• 純前端assets就夠了。
• server.js可以滿足所有bff應用場景，無論渲染，還是api proxy。server.js 是一個faas函數，可以随時釋出到Serverless環境上。

相當于

• Serverless做了托管環境，幾乎不用管運維
• 開發時用法，如now.sh或surge.sh，絲般順滑
• 把ci/cd也接入進來，那麼linc.sh做的就是這個事兒

FAB的核心難點是打包。

FAB可以在任何地方建構，并且産出獨立的結果檔案，可以有輸入集合，fab.zip是一個每個位元組都相同的包，無論何時何地都可以使用。這是因為包含了deterministic-zip子產品，它從檔案中删除修改時間戳，這樣fab就會産生一緻的結果了。

這意味着，在編譯FAB之後，包含内容用于釋出的Fab包擁有一樣的MD5/SHA 哈希值。不需要引入新的釋出，這是因為内容授權是一樣的。不需要觸發重新釋出，當修改README.md 或端到端測試的時候。

這是很hack的技巧，但用起來确實會簡單。但還有一個問題沒解，就是node_modules是否需要打包的問題。打包到一個檔案，會有加載性能問題，不打包就需要放到faas runtime裡。各有利弊。

按照fab的玩法，node_modules放到faas runtime裡，loader部分解析一下fab.zip執行就好了。這也是一個很好的做法。

抽象一個中間格式，做到部署無關，确實是一個很棒的做法，示例如下圖。

我不管你用什麼技術棧，一個server.js和assets足夠用了，編譯你自己做，然後按照我的方式達成fab包。這就是你釋出時需要用的。剩下的就是釋出到faas環境即可。

我們一直在追求Serverless在提效領域的極緻。當所有前端場景都可以做到極簡托管，在配套各種基建，輕開發模式，難道不值得當成夢想嗎？

來自競品的壓力和啟示

騰訊雲Serverless的做法，投資serverless.com，筆者以為是挾天子以令諸侯的感覺。站在标準之上，有意思的很。投資coding.net，我了解是對WebIDE等輕量級開發方面做資源整合，也是一步好棋。

這些都不重要，我們要看的是它的托管能力擴充實作。

它的component做法

https://serverless.com/components/

很一般，但很實用。

核心要點：

• 指定website目錄
• 提供一個函數

Serverless Components 是面向資源的設計，可擴充性極強。想AWS Lambda, AWS S3, Azure Functions, Google Big Query, Twilio, Stripe, Algolia, Cloudflare Workers 等都可以使用。大多數 Serverless Components 部署要傳統雲部署要快上 20倍。他們的意圖是設計Serverless Components 來做到最大程度的快速部署，移除本地對模拟網絡應用的依賴。

從這點上看，Serverless Components和fab的做法是一緻的，都是把Serverless當做托管環境。不同的是fab要更極緻一點。

接下來，集團内的Serverless也會圍繞托管做，推進的2個核心點。

• http serve實作，基于midway-faas很容易
• serverless-side render實作，基于egg-react-ssr設計，已開源

對于BFF裡的API、API Proxy這些都很容易基于FaaS搞定，對于前端關心的點，我的看法

• CSR要支援。把faas當cdn用，雖然Dirty，但對于中背景或外包來說是有積極意義的。
• SSR必要時能支援。把FaaS當Node用。
• 如果能随便切換更好。既要也要還要。

當然，ToC的場景和ToB的場景是有差别的，流量和成本成正比，必然會導緻實作上的差别，這點在下一小結會講。

除此之外，now.sh或surge.sh，linc.sh這些在易用性上做的實踐是非常值得借鑒的。

Serverless-side render 會火

裕波曾在2017年問我，為何如此鐘愛SSR？我的回答如下。

從前端的角度看，它是一個相對小的領域。PC已經非主流，H5想争王者，卻不想被 React-native、Weex 中間截胡。無論怎麼看，SSR能做的似乎都有限。但是，使用者體驗提升是永遠的追求，另外Web标準化是正統，在使用者體驗和Web标準之間，又要和 Node.js 做結合，除了SSR，想不到更好的解法。

貼着C端業務，從後端手裡接過來PC、H5，通過 Node.js 建構自己的生存之地是必然的選擇。活下來之後，就開始有演進、沉澱，通過C端業務和 egg-react-ssr 開源項目的沉澱，我們成功的打通2點。

1. 寫法上的統一：CSR和SSR可以共存，繼而實作二種模式的無縫切換
2. 容災降級方案：從Node SSR無縫切換到Node的CSR，做到第一層降級，從Node CSR還可以繼續降到CDN的CSR

2019年，另外一個風口是 Serverless，前端把 Serverless 看成是生死之地，下一代研發模式的前端價值證明。那麼，在這個背景下，SSR能做什麼呢？基于FaaS的SSR如何做呢？繼續推演，支援SSR，也可以支援CSR，也就是說基于FaaS的渲染都可以支援的。于是和風馳商量，做了Serverless端側渲染方向的規劃。

本來SSR是Server-side render，演進為Serverless-side render。元彥給了一個非常好概念命名，Caaf，即Component as a fuction。渲染層圍繞在以元件為核心，最終統統簡化到函數層面。

在今天看，SSR是成功的，一個曾經比較偏冷的點已經慢慢變得主流。

集團中，基于React/Rax的一體化開發，可以滿足前端所有開發場景。優酷側的活動搭建已經更新到Rax 1.0，對外提供SSR服務。在UC裡，已經開始要将 egg-react-ssr 遷移到FaaS上，代碼已經完成遷移。

• PC/中背景，使用基于React的CSR和SSR可以滿足所有場景。
• 移動端/H5，基于 Rax 的CSR和SSR可以滿足所有場景。尤其是Rax SSR給站外H5提供了非常好的首屏渲染時間優化，對C端或活動支援是尤其有用的。

還有一個命題是值得聊聊的，即如何在Faas函數還不能保證4個9的情況下接入？

直接接入FaaS，依賴的Serverless的基建穩定性，目前應該還沒人敢保證4個9以上的穩定性。一個比較好的辦法是自建網關，好處有2。

• 對于曆史遺留問題，域名接入，反向代理等非常友善
• 在FaaS函數挂掉的情況下，可以降級到CDN托管

同一種寫法，既可以支援CSR和SSR，同時釋出到FaaS和CDN上，在網關上配置化容災政策，這樣做到3個9或4個9是很容易的事兒。

上圖右側是我們實作的新的基于ssr-spec和midway-faas的faas ssr實作

https://github.com/ykfe/ssr

。核心在Web目錄，同時支援多個頁面，且可以做到SPA和MPA在建構層做不同定制。目前Umi SSR、Ice SSR、Egg-react-ssr都是基于這套機制建構的，整體上看，這個方案是得到大家一緻認可的。在FaaS SSR裡，會有更加極簡的用法，在降低開發難度上會進一步壓榨，期望能夠達到落地成本減半的目标。

在2020年，基于FaaS之上的渲染已經獲得大家的認可。另外大量的Node.js的BFF（Backend for frontend）應用已經到了需要治理的時候，BFF感覺和當年的微服務一樣，太多了之後就會牽扯到管理成本，這種情況下Serverless是個中台内斂的極好解決方案。對前端來說，SSR讓開發變得簡單，基于FaaS又能很好的收斂和治理BFF應用，結合WebIDE，一種極其輕量級基于Serverless的前端研發時代已經來臨了。省了流程，少了運維，以後可以招人能降低，甚至外包，如果想做，後端的事兒也是能夠完成的，可以消掉前後端開發的開發分工。

自建 SFF 管理背景會流行

針對于FaaS，前端能有的玩法。

• 函數管理，為ginkgo自帶功能，可以略微擴充，比如自定義網關內建中的path，url rewrite。
• 通用模闆支援，由于場景不一樣，是以會提供serve，rpc/http，ssr，mock等多種類型的模闆，對于開發者更加友好。
• 對外服務注冊。主要是來自服務市場的概念，很多函數如果想對外提供通用服務，通過設定，可以變為對外公共服務，可以變成其他函數的依賴，并在layer中可以按需注入。
• 快速場景定制，讓開發者感覺不到函數的存在，比如mock個json，那就直接輸入json和想通路的位址，然後自動建立函數，釋出，通路就好。
• 業務支援，基于以上4種細化的方案，做業務相關的開發。

當然，模式上也要考慮，比如c端和b端是不一樣的，主要差别在流量上（基建還不夠智能導緻的）。一個典型的場景，在對内的bff裡，10個函數部署在一台機器上會更劃算，這時候除了樵楓大大的 EaaS（egg as a service：一個是機器成本的考慮，另一個是存量的大量Egg應用更平滑遷移到Serverless體系）這種Layer層面的定制外，能夠在平台側提供聚合并釋出的能力也是非常務實的功能。

講完FaaS玩法，你會發現所有的功能需要定制的還是非常多的，此時自建SFF管理背景是非常必要的。

• 定制性更好，各個BU業務和研發習慣模式等都有不同
• 基于集團的Serverless基建，不需要考慮運維問題，有問題還是可以提需求
• 便于創新，目前基建已經提供了足夠的支援，讓開發更專注于開發

Serverless是風口，提效是有的，但業務價值沒有根本改變，是以圍繞開發者提效和創新才是核心。各個BU不去定制才是奇怪的事兒。

接下來大家發力的點，可能是下面這些。

• 圍繞網關做好穩定性，平台基石
• 将Serverless做成托管容器，讓頁面托管/api托管更容易，目前看全場景落地沒問題的
  • 内部bff應用，需要考慮流量問題，多函數一台機器是強訴求，樵楓那邊的eaas，另外多函數如何compose成一個，類似于koa-compose這種，也是一個方向
  • ssr和csr現有方案足夠，ice和umi都采用是這套
  • 對于c端頁面，自建網關，在Faas函數挂掉的情況下，可以降級到CDN托管
  • 關于函數的ctx，早晚還是要回歸到koa上，需求都上來，還是要通用，不然無法滿足，所有bff場景出現的問題都一定會在faas上出現。插件化也是faas的強訴求。
• 服務市場，現在實際已經成熟了。服務和路由要分開處理，讓沉澱服務變得更容易。
• 讓前端感覺不到函數的存在，ui化，可視化，內建現在有的前端方案，做好生态

前端工作台

前面講了，now.sh或surge.sh，linc.sh這些在易用性上做的實踐是非常值得借鑒的。這些所謂的易用性上的實踐集合在一起，你需要的其實就是前端工作台。

Backstage is an open platform for building developer portals

https://github.com/spotify/backstage

理想麼？developer portals，不是frontend developer portals。這才是最重要的。

Backstagez已經在Spotify建立4年了。開源版本3個階段：

We created Backstage about 4 years ago. While our internal version of Backstage has had the benefit of time to mature and evolve, the first iteration of our open source version is still nascent. We are envisioning three phases of the project and we have already begun work on various aspects of these phases:

• 階段1: 擴充前端平台 (正在做) - 讓你能夠簡單的為你的内部基建或工具建立一個一個單一的持久化UI層。可複用的UX模式群組件集有助于在工具之間保證一緻的體驗。
• 階段2: 員工管理 (next 2-3 months) - Manage anything from microservices to software components to infrastructure and your service catalog. Regardless of whether you want to create a new library, view service deployment status in Kubernetes, or check the test coverage for a website -- Backstage will provide all of those tools - and many more - in a single developer portal.
• 階段3: 生态 (later) - Everyone's infrastructure stack is different. By fostering a vibrant community of contributors we hope to provide an ecosystem of Open

https://github.com/spotify/backstage/blob/master/docs/getting-started/create-an-app.md

app
├── README.md
├── lerna.json
├── package.json
├── prettier.config.js
├── tsconfig.json
├── packages
│   └── app
│       ├── package.json
│       ├── tsconfig.json
│       ├── public
│       │   └──  ...
│       └── src
│           ├── App.test.tsx
│           ├── App.tsx
│           ├── index.tsx
│           ├── plugins.ts
│           └── setupTests.ts
└── plugins
    └── welcome
        ├── README.md
        ├── package.json
        ├── tsconfig.json
        └── src
            ├── index.ts
            ├── plugin.test.ts
            ├── plugin.ts
            ├── setupTests.ts
            └── components
                ├── Timer
                │   └──  ...
                └── WelcomePage
                    └──  ...           

目前能看到的是大型應用插件化，具體和portal做的內建度有多高，還沒有簡單。

前端工作台：集前端現有功能，建構好用的前端門戶。核心技術應該是：微前端 + JAMS + 搭建。

• JAMS：基建，當下最潮的解決方案
• 微前端：在工作台建構上擁有絕對重要性。Web 技術發展到今天，已經有大量存在時間數年乃至十年以上的巨石應用出現，技術的疊代往往導緻技術債過高，拖累研發效率，貿然追進最新技術棧又會導緻技術稅的繳納。微前端的出現給了這些項目一個進化和保持不進化的可能性。在 SPA 這一政治正确的技術方案外打開了一個新領域，也在這個領域相應開源了 qiankun 和 icestark 等項目。
• 搭建：最容易落地的提效手段
• 智能化：imgcook從d2c，到資料綁定，到p2c，能做的事兒其實也是為搭建服務的。未來可以想象的空間很大，是創新，結合搭建最容易落地，但不是必選項。

總結

FaaS場景下的SSR架構已經添加到阿裡雲雲開發平台的預設解決方案當中。結合阿裡雲的CloudIDE功能，我們可以所有的開發，釋出操作都在雲上完成無需本地配置開發環境，使用起來十分的友善。

我姑且說之，你姑且聽之。如果說某些觀點能夠有點啟發，一起交流。對于未知的探索，需要有更多人一起來。

最後，分享一首我非常喜歡的舒婷《獻給我的同代人》，共勉。

他們在天上

願為一顆星

他們在地上

願為一盞燈

不怕顯得多麼渺小

隻要盡其可能

唯因不被承認

才格外勇敢真誠

即使像眼淚一樣跌碎

敏感的大地

處處仍有

持久而悠遠的回聲

為開拓心靈的處女地

走入禁區，也許——

就在那裡犧牲

留下歪歪斜斜的腳印

給後來者

簽署通行證

1980.4

文末福利

玩轉雲端開發 7 天訓練營

提前享受雲時代的原生開發環境，Serverless 研發從入門到精通，連續 7 天，每天一個直播，阿裡專家手把手教你利用阿裡雲雲開發平台 get 雲端開發新技能。0 門檻打開浏覽器就可以開發，最快 1 分鐘搭建個人網站，免費開發還送代金券、天貓精靈等多重好禮！

識别下方二維碼馬上入群學習，或點選

連結

馬上參加：

等等，福利還沒停！關注下方公衆号轉發文章即參與抽取天貓精靈！

關注「Alibaba F2E」

把握阿裡巴巴前端新動向