![1.23.png](https://ucc.alicdn.com/pic/developer-ecology/2438ee2d494041e684f6234971206dd5.png)
作者 | 杜歡（阿里巴巴高階前端技術專家）、王文婧<br>

> 導讀：雲 + 端模式成為當前前端開發的新風向，由此而來的 Serverless 正幫助前端工程師提升開發能力和效率。近日在 2019 ArchSummit 全球架構師峰會北京站，阿里巴巴高階前端技術專家杜歡（風馳）接受了 InfoQ 記者的採訪，為我們詳細梳理了阿里巴巴近兩年使用雲 + 端的 Serverless 來探索前端演進過程的經驗和體會。

**Question：杜老師，您好！請您介紹一下您的從業經歷，以及目前在阿里雲戰略 & 合作部負責的工作。**

**杜歡（風馳）：**目前我在阿里雲戰略合作部，負責阿里雲的開發者業務，更多的是在考慮怎麼在雲的時代幫助整個廣大的開發者社群和生態能夠在成為雲時代原住民開發者的狀態下，有個更好的開發環境。

**Question：您從事前端工作多久了？對這個行業有過哪些困惑與思考？**

**杜歡（風馳）：**我其實進入到前端行業還是很有趣的一個過程，我最早是在 2001 年左右開始接觸到 Web 開發。那個時候，就是做網站，做網站前端、後端、資料庫，然後釋出運維都要做。那個時候其實也沒有現在這麼多崗位，基本上就一個崗位——開發，所有的事情都做。

後來隨著公司業務的擴充，開始去接一些 Browser 端的工作，當時有一個詞叫做 BS，它和 CS 是對應的，CS 叫 Client Side，就是客戶端。Client 和 Server，就是客戶端和 Server。BS 是 Browser 和 Server。從那個時候開始，這種 BS 結構的應用出現，這種結構的出現其實當時是為了解決開發成本和部署成本的問題。就是有些企業想做一個系統，這個系統可以很容易地讓整個企業內部不同的團隊、不同的角色很好地利用，部署的成本不要那麼高，開發成本也不要那麼高。

所以那個時候開始有這種業務型別出現，這種業務型別操作的主要介面就在 Browser 端，那 Browser 端就會遇到一個很大的挑戰，也就是說，你的操作行為、表現、習慣跟原來傳統的客戶端軟體開發的那種操作體驗是不太一樣的。因為 Browser 是瀏覽器。瀏覽器裡邊就是很有限的幾個元素 API。然後主要客戶就會提一些要求說，你需要幫我把傳統的那種體驗互動保留下來。因為對我而言，我只是換了一個軟體提供商，但是我和我的同事在使用的時候不能有什麼感知，對他們來講應該是一樣的。

那個時候遇到的挑戰是，在瀏覽器裡如何實現和傳統的開發軟體裡的 UI、元件一樣的行為。舉個例子，比如說你在搜尋框裡輸入任何一個字元，它會有下拉提示，這是非常常見的一個 UI，但在那個時候是沒有的。這個 UI 至今也是沒有原生提供的，都是前端去模擬出來的。

所以那個時候我做的就是這些事情。做著做著，我發現挑戰非常大，相當於你要完全模擬出一套傳統的開發體系裡的整個 UI 體系。那個時候就想，我能不能把這個做得更好一點。所以慢慢地開始加入到前端的一些社群。認識了當時的一些朋友。就這樣進入到前端行業，一直做到今天。

**Question：前端的發展很快，在研發體系的升級上，阿里雲是如何部署的？**

**杜歡（風馳）：** 前端升級確實是讓人又愛又恨的。而且這種升級，在我看來，比如說框架層，它可能要解決的是一些新的研發形態，但是對業務而言，它其實並沒有很大規模地解決上一個階段遇到的問題。

舉個研發效率的例子，比如我們現在做工程化、框架的演進，和最早用 jquery 的時候，相對業務而言，有什麼變化嗎？沒有什麼變化。而且有時候反而使你的整個協同成本、交付成本、人力成本在一定程度上變高了。因為你引入了工程的概念，你就要去做工程化，工程化不是所有人都能做得很深入。因為工程化本身就是一個領域，所以你又得為了把工程化做好去準備一些特定的侯選人，組建一個團隊。相對來講，你又多了一批做業務的人，業務流程又要變慢。原來可能你在 UI 上做完，JS、HTML、CSS，你怎麼做馬上就可以看到。現在你是看不到的，你寫完之後要編譯，工程化和編譯完之後，你可能才能看到。

我想表達的是，前端不斷地在演進，它其實是更精細化了，質量更有保障，在一定程度上效率可能也有提升。但是從更宏觀的角度，從業務的角度來看，它可能不一定真正解決了業務痛點。就比如說今天我們提到，有的業務期望是，人一進來馬上就能幹活，幹完活馬上就能上線。從業務的視角來看，前端這幾年的演進可能還不是一個終態，它處在一個摸索的階段。

**Question：所以就像您說的，工程化現在還沒有達到它的預期效果？**

**杜歡（風馳）：** 我們認為，工程化的出現和持續演進未來一定是能幫到業務的，但是它還在摸索的階段。本身做工程化需要消耗人力、資源，包括流程的新增，這些其實在這個階段是會降低業務交付效率的。所以我們也不能說它不對，因為它畢竟有一個發展的過程。只是在它還沒有到達終態之前，不管是框架還是這種工程化的這種演進，相對來講都是比較痛苦的。

但是未來如果終態來臨，隨著未來結合雲原生 Serverless，從寫程式碼到最終釋出一體化的時代來臨，可能所有的問題就迎刃而解了。

**Question：我之前採訪過一個專家，他說，前端工程化就是在做“消滅”自己的工作，您怎麼看？**

**杜歡（風馳）：**我是這麼理解，如果是消滅自己，那意味著，前端這個崗位目前做的事情未來會有一個東西替代它。<br>那今天前端的崗位在做什麼事情呢？核心是在做使用者互動行為的開發，在普遍的基礎上，如果加上業務的特性，使用者互動行為就會有很多定製化的東西。再加上，因為每一個業務都要差異化才能生存，尤其是 to C 的產品型別，它一定會在使用者側尋找和競品的差異化，使用者側更多的表現就是怎麼讓使用者看起來更舒服，操作起來更舒服，整個體驗更好。這些往往會表現在真正的使用者互動行為上的差異。

這裡有一個矛盾的點，抽象出來的那些東西，透過工程化確實能以一定的手段來替代，但是差異化的東西怎麼來做，是不是能夠完全替代，這個還很難說，至少今天還沒有一個大家都覺得可信的方案說能夠替代掉。就像今天的企業級定製開發也是類似，之所以叫定製開發，就是它至少在提定製的這個時間點，沒有一個可抽象、可覆蓋它的一個通用的東西，要不然它就不需要定製了，就用通用的就好了。

所以我覺得工程化能夠消滅那種通用抽象的東西，但是定製的東西至少目前來看還不能，除非未來機器學習演進到能夠理解真正不同的需求，並且能夠把這種需求跟現有的技術體系、科學體系完整地連結起來的時候，那我覺得是有機會的。

**Question：阿里經濟體的前端技術架構是什麼樣的？它經歷了哪些發展階段，可否提取幾個重要的時間節點談談？**

**杜歡（風馳）：**阿里經濟體的前端在一定程度上，至少能代表國內的前端行業發展的階段。首先，據我所知，在國內，前端這個崗位最早就是在阿里出現的。那個時候為什麼會出現前端？已經從原來的所有的應用由一個人開發變成一種使用者需求導向，使用者覺得你這個應用雖然好，但是操作起來很差，或者整個體驗不好，所以能不能有人把這塊做得更好？所以在業務的需求下產生了職業精細化的要求。這個精細化的需求在前端崗位誕生的時候，它的核心是把結構、表現、行為這三者做精細化的處理或演進。這是這個崗位誕生之初阿里前端在做的事情。

後來隨著業務體量逐漸增大，開始覆蓋到的人群，以及人群所在的地理位置都不太一樣的時候，越來越多的來自網路比較差的環境的使用者會說，開啟特別慢，體驗不好，那個時候又經歷了做效能最佳化的時代。效能最佳化主要的目的是，讓不同的地理位置的使用者都能夠以最好的速度訪問到我們的業務，讓大家的體驗儘量是最好的。

第三個階段，Node.js 的出現，為我們前面談到的工程化提供了基礎。因為做工程化意味著你要去做編譯、檔案處理，操作一些事情，這些東西需要有一種能力讓它能夠跑在本地，跑在系統裡面，不只是在 Web 頁面上。Node.js 當時幫助前端有能力做這件事情，然後開始演進出前端如何進一步地把行為、樣式、結構分離，如何做模組化的設計、模組化的開發。拆開之後，這個頁面你就看不到了，你想看到，怎麼把拆開的東西重新聚合起來？那個時候就是透過 Node.js 做這種整體的工程化。

第一更精細化，第二更精細化之後，能夠把它編譯在一起，能夠看到，同時去解決或最佳化和原來後端的協同方式。其實在這個階段之前，前端和後端的協同方式是比較粗暴的，是那種交接式的。就是前端做完頁面，然後把產物交接給後端，後端拿著前端做的頁面，在那些特定的區域操作，比如說一個表格，表格裡面應該有資料，前端會填一些假的資料在裡面佔位，後端再把真實的資料塞在裡面，那是最早的階段。有了工程化體系之後，前端和後端的銜接就可以透過 API 的方式來做。在有 API 之前，前端可以去模擬這個假資料，透過約定的 API 規範之類。這是第三個階段，就是工程化帶來的這種更精細化的設計、模組化的設計，以及這種前後端協同的演進。

再往後的演進就是無線時代，前端開始向混合開發模式演進，比如幾個框架的誕生。阿里內部也誕生了一些框架，比如大家知道的 Weex，最近的 Rax 等等。這是在 all in 無線業務背景下前端的演進。阿里內部有很多中後臺的業務，它有很多相對固定的結構形態，其實我們在工程化上又進一步演進了，就是誕生了這種中後臺的研發模式。這種低程式碼的研發模式，更多地體現在頁面的搭建，當我們有足夠多的設計資源，已經抽象好的、比較通用的、設計好的模組，那麼就可以簡單地透過一些框架，把這些模組組裝在一起，而不用寫程式碼，或者寫很少的程式碼。這是中後臺的演進。

現在，結合雲的到來，企業希望透過雲去提高效率。這只是一個願望，一定要經過一個技術的演進才能落地。相應地，從今年年初到“雙 11”，我們整個阿里再一次演進了自己的技術體系，升級到了 Serverless 的研發體系。它不僅可以幫助前端完成面向使用者互動的開發，還能夠完成整個應用的開發，整個應用的開發基於雲端計算的實時彈性的能力能夠快速做好，並且能夠真實地線上上服務好“雙 11”這麼大的流量，真正幫助企業實現用雲來快速商業化、節約成本的初衷。

**Question：阿里是什麼時候開始採用 Serverless 的？**

**杜歡（風馳）：**2017 年，阿里就開始討論這個事情，正式啟動是在 2018 年。阿里內部由於開發環境、網路的客觀原因，暫時不能直接使用阿里雲的公共資源，所以我們要內部實現一套公共雲上有的 Serverless 的能力，所以我們在 2018 年自己建設了這麼一套能力。2019 年，我們開始做上層研發的架構和模型，到今年“雙十一”我們正式投入使用。

**Question：雲 + 端是一個老生常談的話題，阿里雲的雲 + 端和其他企業的雲 + 端有哪些不同之處？**

**杜歡（風馳）：**為什麼今天雲出現了這麼久，大家提雲 + 端也提了這麼久，提 Serverless 也提了有一段時間，但是真正的實踐那麼少呢？因為在研發實踐當中還是需要很挑戰的一些東西去幫助它推動。

第一個是頂層的設計，因為你是研發生態，而不是簡單地利用雲的能力去做一個任務，這是不一樣的兩件事情。如果是利用雲的能力去完成一個任務，這個很簡單，很多人都在用。但是現在真正利用雲 + 端，利用 Serverless 的能力去幫助自己提升研發能力是沒有的。問題就在於大家都缺乏對整個研發架構的改變。因為你要真正利用它，研發模型要發生改變，研發的流程鏈路也要發生改變，這個大家沒有參考。

今天阿里作為前期的實踐者，願意分享自己的設計，為大家提供參考，未來真正要在自己的研發體系裡實踐，大概要怎麼設計，有哪些環節，哪些關鍵節點，哪些特徵等等。第二個是真正的實踐，如果阿里巴巴也只是停留在設計上，沒有拿自己的業務去實踐，我相信大家也缺乏信心，也可能會認為這只是我們的想象，但是今天我們真正地透過“雙十一”這個很大的場景來考驗。

其實我相信這能夠給到整個行業一些資訊，我們不僅在思考和設計整個 Serverless，整個雲 + 端落到真正的研發模式上，同時我們也透過自己的業務去驗證了我們的設計是可行的。最後我們也希望，不僅是分享我們的架構設計，未來我們自己內部的整個研發平臺能有機會透過阿里雲開放給整個行業，讓外面整個開放的生態也能夠使用。大家都使用一樣的方式、一樣的平臺、一樣的架構。

**Question：正如您所說，今年“雙 **11**”是 Serverless 在阿里的第一次大檢驗，取得了振奮人心的效果，但是這個過程當中肯定會有一些坎坷，您能分享一下這方面的經驗嗎？**

**杜歡（風馳）：**最痛苦的還是 Serverless 底座的建設。我花了比較多的時間和大家講為什麼不要去自建這一層的原因是，因為落地和實踐 Serverless，不是一個技術訴求，而是一個業務訴求。為什麼？因為雲本身是幫助企業用低成本高效快速地實現商業化，技術只是為了讓這個業務訴求落地，是這樣的一個關係，所以說如果沒有 Serverless 底座是很痛苦的一件事。並且如果它的能力不行，基本上也是不可用的，因為落地 Serverless 意味著你的所有服務都是跑在上面的。如果它掛了，你的業務也掛了，沒有人願意這樣。

**Question：所以說，小企業可能不太適合做 Serverless？**

**杜歡（風馳）：**小企業最好不要自己去建設 Serverless 底座資源能力。第一，存在技術上的挑戰；第二，存在資源規模化的挑戰。因為 Serverless 的核心要素是，它是按量使用的，按量使用意味著如果今天的量很小，你就用很少的資源；如果今天的量很大，就會給你調很多資源。“雙十一”的時候，流量都是億級的流量，如果你的企業內部沒有按億級做單位的這種流量的機器資源，你怎麼去排程這些資源給他人使用呢？你沒辦法實現按量排程。所以小企業，或者不具備這種資源規模化的企業，不需要去自建 Serverless 能力，不是說不能去實踐 Serverless，可以用公共雲，比如說用阿里雲或其他的雲。

我們遇到的最困難的也是這個事情，就是內部研發網路環境和生產執行網路的問題。我們也是不互通的，我們內部也很難直接在公共雲環境去使用阿里雲這些已有的能力。我們其實花了一年的時間，在阿里內部推動不同的團隊去建設 Serverless 底座。這是第一個我認為比較挑戰的點。

第二，整個研發模型對研發體系帶來了挑戰。其實很多時候這種東西一出來，看起來是幫助前端擴充了邊界，擴充了價值能力，但是相應來講，後端同學可能第一反應就是，那這是不是把我革命了？我就不需要幹活了？其實不是這樣的。比如阿里的導購業務就是取資料展示的場景。這種事情讓一個後端來做，沒有任何技術價值、技術沉澱、技術成長，但是現有的研發模式就是需要有後端同學進來開發。所以其實對他們來講，Serverless 研發模式的演進有助於幫助他們往更底層演進，讓他們聚焦於真正需要做技術研究的部分。比如，這些資料的能力、服務的能力，怎麼做得更好、更紮實，這是我們期望看到的。但是這個研發模式乍一看，如果大家沒有深入瞭解的話，就會認為對整個研發模式、研發流程挑戰很大，那麼就需要去和大家溝通、佈道，講它對每個崗位會帶來的價值。

第三，回到前端來講，這個東西雖然看起來很美好，但如果你真正下決心要進去，對每一個前端來講，是撕裂的成長。因為我們要開始知道這個業務是什麼，為什麼要做這個業務，這個業務到底服務誰，關鍵的指標是什麼，怎麼做。這個時候他已經從前端變成一個業務的功能，整個業務都是他去開發、交付。

這是從技術準備、研發體系的協同，到前端崗位的挑戰三個層面的難點，是我覺得印象比較深刻的，可能是未來大家在實踐當中都會遇到的。

**Question：我在網上了解到，有人說 Serverless 存在不適合長時間的執行應用，完全依賴第三方服務，缺乏除錯，還有構建複雜等缺點。您認同這些觀點嗎？對於那些還沒有涉足 Serverless 的人，您可以幫助他們辨清這些概念嗎？**

**杜歡（風馳）：**我覺得沒有什麼對錯。它只是提到了一些特徵，但是我也想從特徵的角度給大家鼓鼓勁。比如說今天 CNCF，就是雲原生在推的事情，核心就是 Serverless。Serverless 的核心特徵是什麼呢？第一，按量。也就是說，先不要站在技術的角度去看，站在業務角度，它是按量的，按量就意味著，對於業務而言，它是最好的資源使用方式，既不會帶來浪費，也不會不足。第二，計費方式。現在很多的方式是你買的多浪費，買的少就不夠，而且需要再補買，很難把它和你的應用擴容上去。Serverless 的計費方式是按量走的，用多少付多少。另外，它是平臺承載的，因為平臺的實時彈性，幫助了使用者實現按量訴求。

第二，關於技術實踐上的複雜，我覺得也只是一個階段性的現狀而已。今天整個行業還沒有一個開箱即用，或者說比較成熟的研發框架或研發體系、研發平臺出來，大家都在一個摸索的階段，就包括我們自己也是剛剛摸索實踐出來，並且也還不算是成熟，我們也還遇到很多要去繼續推動解決的問題。所以我是這麼看，先從業務的角度去看，它一定是一個最佳的路徑。階段性的痛苦肯定是有的，所以沒有什麼對錯。

**Question：目前國內外 Serverless 實踐存在怎樣的差距？**

**杜歡（風馳）：**相對來講，國外的整個開發生態就時間上要比國內領先一點，原因在於國外的主流雲廠商對整個 IT 行業，對整個開發生態的佈道做了很多工作。國外的開發生態對雲原生，對 Serverless 的接受度和實踐比我們要好很多，並且也早很多。對他們而言，這是一個先發優勢。提供的早，就意味著實踐的多，然後大家對整個 Serverless 的通用性的東西，比如通用的研發環節能夠去做一些沉澱和抽象，所以誕生了一些像 Serverless.com 這些 Serverless 的開發框架。他們更多地是站在一個第三方的公共框架的角度來看，你可能既可以用這個雲廠商，也可以用那個雲廠商，基於我的框架可以快速地去做，基於我的框架，框架自然會有些約束，你跟著這個框架的要求去做一些動作，然後你可以去實踐，真正實踐這個 Serverless 在業務裡面落地，這是一些現狀。

那我們今天在做的也有點類似這個事情，但是我們可能不僅僅是一個開發框架，而是希望把整個開發平臺都開放出來。所以大家不僅僅是說雲層面，函式層面可以按照我們提的建議去做，你甚至可以直接在我們上面去做，我們希望是這樣。

**Question：明年 Serverless 有哪些更細粒度的技術值得關注？**

**杜歡（風馳）：**當 Serverless 整個研發模式大概成形之後，接下來就是實踐。在實踐的過程當中，對渲染層、服務層、函式執行時、框架這幾層可能會有一個更深入的實踐，產生更細節的一些需求。我理解從明年開始，可能就是非常 detail 的垂直分層演進了，可能會有更多的這類內容產生，比如服務編排是如何演進的，函式執行時是如何演進的，效能是怎樣提升的，穩定性是怎樣進一步保障好的，就是又會回到一個大的運維架構演進的階段。

**Question：最後一個問題，您預測未來 5 年，前端行業會有什麼變化？您所在團隊目前有沒有針對這些技術判斷做出一些佈局？**

**杜歡（風馳）：**今年阿里經濟體的其他幾個大的方向，比如前端智慧、搭建等，這些都有可能串聯起來，成為影響整個前端行業發展趨勢的一些因素。但我今天講的更多的可能是整個研發生態的變化，未來的研發模式使前端可以供整個業務，具體到每一個環節，比如前端可能透過 UI 的智慧化，讓自己釋放出來，透過一些成熟的視覺物料、前端物料，以及服務的物料，透過 AI 的輔助，快速地把一些原本需要前端去開發的一些模式化頁面模組，透過 AI 的方式自主生成。

運維這塊可能隨著雲原生能力的不斷增強，工程化能力的補充，未來有可能進入到 NoOps ，就是不需要運維，只需要關注好一些資料。因為整個彈性會跟這些資料執行的實時資料關聯起來，去做不同的變化。

所以整體而言，未來五年對前端而言是能力價值進一步放大的五年，雲上 Serverless 開發能力將成為前端的“金手指”，企業願意去組建一個由雲端的應用用開發工程師構成的研發團隊，透過研發團隊結合整個雲的研發體系，快速地交付它的業務。同時在這個過程當中，結合智慧化進一步提高生產效率，可能是這樣一個趨勢。

如果你對於 Serverless 和函式計算感興趣的話，歡迎釘釘掃碼進入交流群。
![阿里計算.png](https://ucc.alicdn.com/pic/developer-ecology/6f621d4f562d405ebd443e34256cb3d3.png)

作者介紹：<br>杜歡（風馳），阿里雲戰略 & 合作部 / 高階前端技術專家。目前在阿里雲"戰略 & 合作部"負責阿里雲開發者業務，阿里巴巴經濟體前端技術委員會委員，阿里巴巴經濟體前端 Serverless 研發升級專案負責人。此前就職於雅虎、思科等公司。

# 招聘

## TL;DR
阿里雲 - 雲原生應用平臺 - 基礎軟體中臺團隊（原容器平臺基礎軟體團隊）誠邀 Kubernetes/容器/ Serverless/應用交付技術領域專家（ P6-P8 ）加盟。

工作年限：建議 P6-7 三年起，P8 五年起，具體看實際能力。<br>工作地點：

- 國內：北京，杭州，深圳；
- 海外：舊金山灣區、西雅圖

簡歷立刻回覆，2~3 周出結果。節後入職。

## 工作內容
基礎產品事業部是阿里雲智慧事業群的核心研發部門，負責計算、儲存、網路、安全、中介軟體、系統軟體等研發。而云原生應用平臺基礎軟體終態團隊致力於打造穩定、標準、先進的雲原生應用系統平臺，推動行業面向雲原生技術升級與革命。

在這裡，既有 CNCF TOC 和 SIG 聯席 chairman，也有 etcd 創始人、K8s Operator 創始人與 Kubernetes 核心維護成員組成的、國內最頂尖的 Kubernetes 技術團隊。

在這裡，你將同來自全球的雲原生技術領域專家們（如 Helm 專案的創始人、Istio 專案的創始人）密切合作，在獨一無二的場景與規模中從事 Kubernetes、Service Mesh、Serverless、Open Application Model （ OAM ）等雲端計算生態核心技術的研發與落地工作，在業界標杆級的平臺上，既賦能阿里巴巴全球經濟體，更服務全世界的開發者使用者。

1. 以 Kubernetes 為核心，推動並打造下一代 "以應用為中心" 的基礎技術體系；在阿里經濟體場景中，研發和落地“以應用為中心”的基礎設施架構和基於 Open Application Model （ OAM ）的下一代 NoOps 體系，讓 Kubernetes 與雲原生技術棧發揮出真正的價值和能量；

2. 研發多環境複雜應用交付核心技術；結合阿里與生態中的核心業務場景，打造多環境複雜應用交付的業界標準與核心依賴（對標 Google Cloud Anthos 和 Microsoft Azure Arc ）；

3. 雲原生應用平臺核心產品及後端架構設計與開發工作；在生態核心技術與前沿架構的加持下，在世界級雲廠商的平臺場景中，用技術打造持續的雲產品生命力與競爭力；

4. 持續推動阿里經濟體應用平臺架構演進，包括 Serverless 基礎設施、標準雲原生標準 PaaS 構建、新一代應用交付體系構建等核心技術工作。

技術要求：Go/Rust/Java/C++，Linux，分散式系統

## 簡歷提交

lei.zhang AT [alibaba-inc.com](http://alibaba-inc.com/)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

2020 年，Serverless 將給大前端帶來什麼樣的變化？

相關文章