2020 國內公司前端團隊都在搞些什麼?

這個問題要強答一波，好多開發不知道自己要幹什麼，視野打不開，以下有的是在工作中看到同事在做的，有的是自己參與的，列舉出來，大家可以看看，擴展下思路

建立開發規範，最重要的就是 git 分支使用規範，至少有個 release 分支對應生產環境，pre 對應預發，qa 對應測試環境
建立統一的項目模版，比如單頁，多頁，後台管理，組件開發，小程序，Nodejs 項目，然後通過 cli 來選擇項目模版，模版選擇後，直接生成項目，然後把調用 gitlab 的 api，在 gitlab 上創建項目，push項目，這樣就收攏了大家創建項目的方式，自動統一了代碼規範
基於上面這個，就可以做基於 gitlab ci/cd，阿里雲 oss 的持續集成，完成 push =&> 構建 =&> 上傳oss（或者靜態資源伺服器,自動綁定域名，接 cdn，這樣一條龍的服務，人手夠的話也可以把 2，3結合一起做成基於 GUI 網頁的創建，因為這裡接管了大家發布代碼的規範，後面就可以干很多事了
把內部的 npm 私服搭建起來，做一套內網的 npm 組件開發構建 publish 一條龍服務，建一個組件展示平台，這樣人多了，大家接可以互相用起來，方便的很
因為有了上面 3 的收攏，我們就可以上線代碼風格校驗，檢測線上發布是否包含了 sourcemap文件，接著人手夠，老闆支持的話，可以統計每個項目的依賴，存儲到資料庫，這樣某天某個第三方出了問題（比方包含了挖礦腳本），就能立馬找到那個項目依賴了，對於內部 npm 組件，誰使用了，也是很清晰，這樣組件更新了，也可以企微，釘釘，郵件的方式自動通知到使用方，再大膽些，還可以每次發布前通過 puppeteer 跑下項目，統計了性能數據，和之前的數據對比下，偏差太大也可以通知到對應負責人，讓他檢查下
建立監控體系，監控體系可以簡單，可以複雜，看領導的支持度，最基礎的功能是，做 pageLoader 監控，意思是頁面載入成功後上報下數據，表明當前頁面是正常的，這樣每次上線後，就通過消息通知到開發去觀察 pageLoader 曲線的變化，這樣就不會發布後， 2 眼一抹黑，也不知道線上是個什麼情況，出了問題，也可以通過 gitlab ci/cd 立馬回滾代碼，這個是個很強的需求，基本上老闆肯定是支持的，那線上出了錯也不知道是啥子錯，咋辦，那我們把線上錯誤上報上來，就很直觀了，還可以結合 sourcemap 把錯誤和打包前的文件映射起來，便於定位問題，沒人手就用開源的有 sentry，有人手的就自己開發
監控建立起來了，是不是得做個報警機制啊，比方某個橋接更新了，和之前的不兼容，之前運行好好的的頁面一直報錯，錯誤上報達到一定量就報警起來，那就去把上報的數據撈起來做個統計分析，還可以結合 prometheus，做個好看展示曲線
既然錯誤監控都做了，那把頁面性能監控也做了吧
哎，咋監控後性能數據這麼差，是哪裡出了問題，哦，打包文件太大，那 Webpack 得好好學習下，怎麼拆分，啊，發現 http 請求時間太常，是不是 CDN 哪裡出了問題，是不是資源沒開啟壓縮，那這個鏈路還不熟，得好好學習下
什麼前端的監控都給做了，能不能協助下客戶端的同學，把他們的 crash 上報，冷啟監控都給做下
要做上面這些，至少需要會門後端語言，會資料庫啊，我擦，剛好上手 Egg.js Mysql 開發啊，之前不是學習 Node.js 沒有場景使用么，一下子這麼多場景來了，剛好帶薪學習
我擦，接了前端，客戶端上報，請求數量一下子上來了，隨手寫的垃圾 Egg 代碼，性能跟不上了，加班優化吧，不然不被罵死，還不行，加機器吧，加機器要做負載均衡啊，這個不會啊，趕緊學習去，是不是還需要做緩存，那還得學習下 Redis
活動頁天天寫，可是有很多落地頁都是非常簡單的，每次都得 copy 個項目，然後改改圖片，改改樣式，太煩了，沒有成長啊，那要不我來整個托拉拽生成頁面，把這些頁面元素都獨立成組件，讓運營自己去拖動，生成她需要的，這不就是個就是時髦的「可視化搭建么」把自己解放出來
簡單的落地頁可以這樣整，那難的活動頁咋辦，比如大轉盤，紅包雨，發現這些活動複雜些，簡單的搭建不好解決，但是發現，這些好像也可以抽象，抽象成玩法的概念，那得加個配置中心來配置玩法
發現每個項目組活動頁有自己不同的 api，還有些活動會用相同的api，怎麼辦，每個人還不一樣，我擦，這樣配置中心用起來太麻煩了，是不是做個服務平台，把這些 API 都包成 BaaS，然後想用的人自己謝謝代碼來組合 api ，那這個要用 Fass 了，額，一步小心，做了個粗糙版的 Serverless

上面的 1 ～ 6 條是超過 6個人前端組都可以乾的事，大大節省人力，到現在我發現還有人，是把打包好的文件，拖動伺服器上去了，人肉打包機

7 ～ 12 15人左右的團隊必須上了

13 ～ 15 每個單拎出來都是亮點項目，非常提升人效，也是晉陞，跳槽很好吹水的點

上面這些聽起來沒有大家常聽的那些時髦，比如 SSR，微前端這些，很多開發者總想著搞些時髦的技術，實際上解決公司當下的一些同事常常抱怨，經常重複的地方，更是我們應該做的，圍繞當下業務，解決當下問題

如果覺得有幫助，點個贊伐

---------------------------------------- 分割線 ------------------------------------------

修改於：2020.10.23

額，另外，我最近加入螞蟻花唄借唄前端 RichLab 團隊，和樓下是個大BU下面的（^_^），如果你對我們團隊感興趣也可以加我微信聊聊，發展迅速，人員缺口非常大，不感興趣也可以加呀，我們可以聊聊職場困惑，發展方向,

我微信base64：aGM5MzE2NDE1OTk= ，郵箱：[email protected]

我們在前端這個大方向設置了幾個領域，總有一個適合你，如果你多這些都感興趣

如果你想了解下怎麼準備面試，我們需要什麼樣的人，看，我們老闆完顏把這麼準備面試都給寫好了，真的是誠意滿滿的招人！！

ScottZao：前端搞面試 | 完顏 - 如何考察候選人的能力與潛力?

zhuanlan.zhihu.com

也可以看看我對入職我們團隊的一些感受：

hucheng91：入職花唄借唄前端一個月感受?

zhuanlan.zhihu.com

我們團隊介紹:

ulivz：螞蟻金服 RichLab 團隊邀你來聊一聊?

zhuanlan.zhihu.com

2020年馬上就結束了，所以這個問題可以來回答一波了。

真2020年，我的前端團隊都在搞些什麼。

1，年初搞疫情。

在微博和新浪新聞客戶端內的，疫情期間大家每天都看的，現在線上還在跑的，新浪全網在投的那個全國和世界疫情專題是我這邊開發的，主要是圖表可視化展示，二級頁，涉及到了很多 echart 的二次開發，使用的技術比較 low，vue 配合 zepto……我們用 vue 開了一個動態模板在我們的後台裡面再用 zepto 配合 echart 手寫了很多圖表組件，經歷了多次性能優化，監控補點，包括 echarts 的 map 部分的很多省份，國家的數據修改等。經歷過多次故障，兼容性的，性能的，數據的，最後又補了一套前端監控體系來保證這一坨（自己發揮想像）代碼，因為那時候疫情遠程在家，多個團隊一起配合，而且一直以為是個臨時活動需求而已，沒想到一直堅持到了現在。

2，做了很多和 puppeteer 無頭瀏覽器相關的工作。

我們開發了內部的一套無頭瀏覽器集群，可以快速編排一些簡單指令，封裝成任務去做一些事情，什麼事情都有，比如幫助編輯做文章二次排版美化，抓取排版，格式化等，網頁截圖，還有一些自動化的測試，爬蟲等等都有涉及。核心還是在於把任務分發和任務算力與 worker 解耦後做的一套分散式的puppeteer 集群，可以智能控速，感知進度，發現異常，實時報警等等，真正的把技術轉化成了公司生產力。

3，做了一個 electron 的在線會議客戶端

系統的搭建了一套 electron 的集成構建環境，包括環境隔離，打包部署，代碼簽名，mac 和 windows 的代碼驗證，自動更新，異常抓取以及搞明白了怎麼和 c++配合實現一些 electron 自身無法實現的功能，我們這邊採用ffi-napi來調用c++編寫跨系統的 DLL實現的部分會議功能，然後又擼了個 mqtt 的 IM。

4，正在準備升級一套新的 hybrid 架構升級

之前的離線包技術我們用了很多年，遇到一些瓶頸，目前正在做計劃優化，比如之前每個 bundle 都是一個獨立 zip 下發的，我們目前打算為了解決靈活更新的問題，加入了基礎共享包的概念，想把一些模塊化的方案帶入到 native 本地去，這樣共享包實現後，可以實現公共模塊的更新讓整個系統都能有收益，而且不需要頻繁發版本，設計了版本控制，新的 ci/cd 依賴流程，app 新老版本兼容方案，以及本地開發調試的方法還有配合客戶端做依賴檢查，deps配置下發等。

之前我們的 app 內每個 hybrid 都是一套獨立的 repo 倉庫，今年也做了很長一段時間整合把 multi repo 改寫成了 single repo，也是為了配合上面說的優化和靈活更新的問題而設計的，對此把相關的腳手架，上線流程又做了很大和之前不一樣的調整。

5，Daruk 發布了2.0 作為一個跨年項目，從19年中開始，終於畫了一個還不錯的句號。

Daruk?

darukjs.com

6，新浪新聞終於開始嘗試在主端試用 flutter 開發部分功能，我們這邊也參與進來，最近在學 dart 語法和 flutter 的 api，主要負責和客戶端一起配合調 channel，坑還很多，沒有踩完。

7，調研過一陣新技術，比如 AR，webassembly，tensorflow啥的，最終結論暫時都還用不上……

8，搞了短時間的 faas，內部和運維一起搭建的，最終結論還是用不上……

9，搞了搞 DCG，做了幾個小遊戲來封熱榜投票的，如果你玩微博給新浪愛豆投票的功能，應該遇到過。

10，部分業務前端接入了protobuf來開發。

11，做的事情挺多的，和業界時髦技術相關的一樣沒有，也不知道是不是掉隊了。就這技術棧很怕35歲失業，焦慮中。

12，學了一些客戶端的黑科技，比如用adb配合appuim寫腳本去監控一些功能，最近打算升級到公司自己搭的stf上去，之前是找了個物理機弄了個簡易機架，能幹的事挺多的，不能細說。（狗頭

喜歡的話可以轉發讓更多人看到。

這個問題的背後其實是好多前端同學對未來的迷茫。在前幾年，前端突飛猛進，很多新技術接踵而至。雖然大家口口聲聲說學不動了學不動了，但大家至少有個目標可以去學。

五六年前，學個React或Vue，再引入到項目中。用ES6開發，配合gulp或grunt，搞個前後端分離的工程，那就很牛逼了，簡直就是帶著團隊從石器時代邁入了工業時代。

然後過個一兩年，再學個webpack，搭個更好的研髮腳手架，再配合打包分析，做做性能優化。在團隊內做個分享並推廣下，又是很不錯的技術產出了。

又過個一兩年，再學學Node，有了服務端能力，配合gitlab、jenkins這些，前端可以自己搞個好用的發布系統、迭代系統，再引入前端監控服務等等，一套完成的前端基建就做的很完善了。又能繼續成長、升職、加薪了。

問題來了，現在要做什麼，現在能學什麼？

去年阿里前端委員會主席圓心，《在未來前端的機會在哪裡中》指出四大方向：

搭建服務
Serverless
智能化
IDE

但這對於大部分前端來說，這顯得過於方向性，牽扯的東西太多了。它不像是一兩個知識點，照著教程文檔學一學，再看看源碼什麼的，就掌握的差不多了。而且很多似乎還超綱了，網上搜一下智能化、serverless，很多領域外的名詞映入眼前，不知從哪學習。最最最為要命的是：我就算學會了，我的公司、我的業務，似乎也用不著這些知識點。

所以，很多同學開始焦慮、不知道該學什麼，更不知道該做什麼。基礎技術基本成熟，業務上，前端似乎也就只能糊糊頁面，很難再有發力點。

說了這麼多，其實我也提不出什麼非常好的方法論，但我覺得我們保險前端大團隊整體做的還算不錯，在這裡介紹一下，看看能不能給其他同學多一些輸出。

業務情況

首先還是簡單介紹下我們這邊的業務，空講技術，沒有任何背景。

商業險業務：其實基本涵蓋各位認知的全部險種，壽險、健康金、財產險、意外險等等。還有你可能想不到的，比如退運費險、寵物險等等
相互寶業務：相互寶是我們這兩年的明星產品，具體我也不多介紹了，總之是螞蟻與集團重點事項。支付寶搜索相互寶可多了解
圍繞保險產品的公估、理賠等各環節產生的B端服務：螞蟻保險作為一個平台服務，會對接各類保司以及其他相關公司，同時也會給他們提供很多相應服務。

大致可以了解到，螞蟻保險是一個同時面向BC端提供服務的平台級業務。下面正式說說我們前端現在在搞些什麼。

技術事項

營銷與運營體系

我先說我自己負責的部分吧。我目前負責保險用戶增長相關的前端事項，所以圍繞的是營銷與運營體系。

智能組件

組件化想必都是所有的團隊都會做的事情。除了類似antd、element這些基礎UI組件之外，一般也會沉澱一些基礎的業務組件，便於不同產品做類似功能復用。

一個C端頁面，往往是由好多組件組成的。Page = ComponentA + ComponentB + .....。而一個組件的UI = Fn(props, state)，Fn就是組件本身代碼。而保險的頁面基本都是千人千面輸出的，尤其是其中一些運營類模塊，如紅包彈屏、營銷banner等等。

一般來說，組件的state往往是處理一些業務邏輯的內部狀態，核心決定組件UI的就是組件props。所以大部分套路就是：頁面的根節點組件，從某一個千人千面的數據服務獲取各個組件的配置化props，再分配注入到各個組件，最終渲染出千人千面的頁面。

那麼問題來了，對於這類需要千人千面運營的頁面，如何去抽象組件，如何跟某個數據服務關聯，如何做到跨頁面快速復用與投放？

最終我們這邊實現了一套智能組件方案，在傳統組件之上融合了千人千面的數據推薦服務，實現組件的可視化運營配置與快速投放。

智能組件演示

智能搭建

很多公司都有自己的搭建服務，螞蟻也有一個建站服務-雲鳳蝶。其對內支持移動建站的版本叫閃蝶。它支持開發組件與模板，然後運營在模板中選擇自己想要的組件，再配置組件需要的props，最後構建出自己的移動站點。保險基於這套能力，也輸出了大量的營銷站點。

但這裡存在一個問題，用閃蝶服務去配置的props，是靜態寫死的。沒法像我上面智能組件中提到，可以根據不同人群等規則去做千人千面的數據配置。

所以我們又基於閃蝶底層服務，融合我們智能組件的能力，實現了一套千人千面的搭建服務。

有了這樣的能力以後，我們的運營就能直接搭建出精細化運營的營銷頁面了。

智能相機

相機在前端領域，大部分功能就是用於拍攝用戶的一些信息材料，獲取後上傳。而在保險業務，這樣的場景有非常多。比如：

車子受損了要定損，通過相機拍取車損畫面，簡單判斷車損級別。
理賠服務時，通過相機拍取病例、醫療費用單等信息。
寵物險，通過拍取寵物狗鼻紋，獲取寵物唯一標識，做寵物核身。

但這些畫面的獲取其實沒那麼簡單的，用戶拍上來的信息大部分情況質量很差，這就需要在端上做智能引導，這就涉及一些機器學習跟相關演算法。在之前，演算法引擎這塊都是客戶端團隊來做的，但是嚴重依賴於客戶端發版，而且跨端能力弱。從19年開始，我們基於Tensorflow.js，把演算法引擎跑在瀏覽器端，並做了大量性能優化工作以及配套的中台服務，最終實現一套支持跨端與快速迭代的智能相機研發體系。

智能相機演示

工程效能

小程序React研發框架-Remix

Remax 可能大家有聽過了，其實在同一時期，我們的相互寶業務線，也誕生了一款支付寶小程序React研發框架-Mars。相互寶是保險第一款支付寶小程序，但確實研發範式上，跟螞蟻的React體系顯得略有偏差。為了提升研發效能，我們的技術同學也研發了一款更面向內部的研發框架。當然跟Remax確實還是有不少重複，所以目前我們的Mars跟Remax進行了合併，合併後對外品牌名依舊為Remax，對內為Remix。現在保險的支付寶小程序已經可以基於React去愉快的開發並耍起hooks了。

Cod：BFF體系下的LowCode解決方案

螞蟻大部分C端業務目前基本都是基於BFF（backend for frontent）體系。bff這套體系，讓前端可以掌控controller層，使得後端可以專註於領域模型，前端可以更好地面向頁面端提供數據。但也存在一些問題，很多場景下，數據流轉與處理其實沒那麼複雜，bff變成了一個透傳層，但是配套的要寫很多模板代碼，如一些基礎的單測、監控等等，這反而是降低了整體效能。

那有沒有辦法進一步提效呢？Cod應運而生，我們做了一套代碼編排與服務編排的能力，可以在C端通過類似GraphQL的方式直接消費與編排後端提供的遠程服務。

小結

除了上面提到的，我們業務上還有商業險中台體系、技術上還有基於Electron實現的聯調工具等等，具體就不多細講了。

整體而言，保險還是緊貼業務訴求跟工程效能，做了不少技術建設，基本involve了所有的前端同學。大部分同學都能隨著業務發展有自己的技術成長。然後這些技術建設，確實也比較貼進阿里經濟委員會提出的一些方向。如智能化領域，我們有端智能上的建設；搭建領域我們有精細化營銷頁的搭建建設；cod帶來的服務編排與代碼編排能力，廣義上說也是屬於serverless領域等等。

說實話，我們做這些事的時候，確實也沒想著貼著什麼方向，不過走著走著確實也是這幾條路。不得不說，大佬們還是非常的高屋建瓴的。

招聘

說了這麼多，一小方面是給大家提供一些參考，更大一方面還是希望能吸引到業界的優秀人才。

目前螞蟻保險業務上，發展勢頭強勁，是未來螞蟻增長的新一代發動機。而且互聯網保險依舊處在較為藍海的階段，很多事項都還在0-1建設，存在非常多的機會與可能，亟需優秀的前端人才

技術團隊上，目前團隊規模40人+，含若干個前端小組。縱向上，進行業務規模化、專業領域化小組分工，如我這邊是用戶增長小組。橫向上，成立各類虛擬技術小組，大家可以挑選感興趣的技術方向深入學習與探索。

整體而言，業務發展好、技術牛人多，未來清晰、成長可期~

具體招聘要求，也不長篇大論了。總體而言：技術上基礎紮實、某領域深入（Node/互動營銷/搭建/端智能等等）；學習上善於沉澱、持續學習；性格上樂觀開朗、活潑外向。

招聘層級：P6-P8

如有想法，可投遞簡歷到郵箱：[email protected]

也可以先發個微信過來，我加你再做細聊~

團隊照片

最後補一些我們日常的一些學習、生活、娛樂照片。

周會討論與分享

偶合喝喝小酒

遇到開心事去城市陽台體驗下Expensive Life

可愛的妹子們

喜歡結對編程

沒事兒玩玩密室

最後帥哥鎮樓，希望再多吸引點兒妹子

坐標天津，小公司，目前前端團隊只有 3 人。

19 年剛來公司的時候，當時前端只有一個人，而且還是用 JSP 寫頁面。所以我當時的目標是要把前端往工程化方向發展。雖然前端團隊沒幾個人，但還是希望團隊能跟上時代的發展，別落後太多。

截止到目前，我到公司已經一年了，這一年我們的前端團隊做了以下事情：

徹底拋棄 JSP，所有的項目都是前後端分離。
統一開發工具，統一編碼規範（利用 VSCode + ESlint 自動格式化代碼），統一項目規範，統一 UI 規範，統一 GIT 規範（分支管理、commit 規範等等）。
使用 Vue 技術棧。
所有的公共組件，工具函數必須寫單元測試。
由於公司的主要業務是寫後台管理系統，業務頁面大部分都有相似之處。為了提高開發效率，開發了一個業務頁面模板生成器，可以根據配置文件生成半成品業務頁面，在此基礎上再進行二次開發，大大提高了業務頁面開發速度。
性能優化。
鼓勵技術分享，公司內部有專門的 wiki 知識庫，鼓勵大家將一些心得、經驗寫成文章分享。
有空時研究新技術，看是否能在公司項目上落地，例如最近研究的前端可視化開發。

雖然這一年做的事情不怎麼高大上，都是很基礎的事。但是切切實實地提高了前端開發效率以及前端標準。尤其是在規範化這一塊上，作了很大的努力和改進，對我們的幫助非常大。

今年要做的事情：

希望在一些長期項目上實行前端監控（性能監控和錯誤監控）。
使用多個技術棧，考慮 React 或 Angular。
推行 TS。
推行 mock。

最後，推薦一下自己，北京或天津有缺前端的嗎？

從另一個問題過來（2020年前端最火的技術是什麼？），發現很多答主都提名了「Serverless」。如今的 Serverless 可以說是一大有潛力的新技術方向，尤其在當下上雲的熱潮中，Serverless 因其免運維、自動擴容、支持多種編程語言等優勢，對前端來說，是一大提升服務開發、維護效率的利器，也是可嘗試全棧發展的方向。

但也因為其新，對落地到團隊開發中，結合團隊開發流也是遇到了一些挑戰，恰巧 IMWeb 也在這方面有過嘗試，遂分享。本文作者： @Enjoy Chan

一、IMWEB 團隊 Serverless 研發模式的演進與思考

在過去一、兩年，我們團隊在多個服務項目中嘗試使用 serverless，騰訊雲 Serverless 提供了一站式服務，通過使用該服務，前端可獨立完成介面服務開發，對前端個人而言可往全棧發展，也因此可緩解團隊後台人力緊張問題

在開發 Serverless 雲函數的過程中，我們也遇到了對比傳統服務，雲函數開發的一些挑戰點

（1）雲函數開發特點

前端傳統項目的開發流模式相對已經比較成熟，通過 git 協同管理代碼，再通過 CI 來規範項目的部署流程，整個工作流可以查看、回滾代碼，部署也做到了自動化

再來看雲函數的開發特點：

雲函數獨立的賬號和許可權管理
以函數為單位進行創建、更新和部署
創建網關 API 與函數關聯，藉此可通過網關 API 訪問到雲函數

以上是最基礎的開發雲函數三個基礎

而雲函數的創建、更新有兩種方式：

騰訊雲官網雲函數控制台，可視化的操作界面，點擊按鈕即可創建、更新
通過 CLI 創建，SERVERLESS 提供 SDK，調用 SDK 可完成自定義創建、更新操作，其優點為靈活編寫，也易於做成工程化

考慮團隊的協作，第二種方式通過調用 SDK 的方式因其靈活更適合定製為團隊規範

總結下來可以看到雲函數開發的三個特性：

因其有獨立於 git 賬號的雲函數賬號，導致了雲函數的代碼缺乏像 GIT 一樣可以查看歷史代碼版本，代碼修改記錄等
因其有多重方式可以用來創建、更新函數，導致多人協作時，有互相覆蓋雲函數的風險
提供的雲函數網關，可幫助快速配置訪問雲函數，而無需運維同學幫忙做域名指向，機器申請等

（2）團隊協作上手雲函數開發問題

在初期團隊探索嘗試雲函數開發時，對比傳統項目的開發流，雲函數的開發步驟更多，也暴露出了一些缺點：

1) 上手成本高

首先有不小的學習成本，像雲函數配置文件，雲函數官網界面操作學習成本，實際使用時，由於雲函數網關 API 鏈接過長、域名限制等，需要配置 nginx，用特定域名訪問雲函數網關 API，因為多數前端對 nginx 部署，導致有了 nginx 學習成本

2) 調試雲函數效率低

因為雲函數是部署在雲端的，Serverless 有其獨特的環境，context、event 等，有別於 NODE 服務的請求體等，本地要完全模擬 serverless 請求比較困難，導致開發想要調試定位問題時，只能先將代碼部署到 serverless 上，這裡就需要等待部署了，由於 serverless 是外網的，部署時間就更長了

3) 開發流困惑

由於雲函數直接就是部署在雲端，沒有我們傳統的機器用於做環境區分，對團隊協作保證部署質量來說並不友好
上述也有提到的，往往因為想要自己業務域名訪問服務介面，而雲函數網關 API 是比較長的缺乏語義化的鏈接，通常使用時會想配置 nginx 去通過自定義域名訪問雲函數，不止是成本問題也有容易配置錯誤的風險問題

4) 管理困難，存在質量問題

因雲函數獨立的賬號管理，沒有 git 進行管理，導致無法追蹤代碼記錄，甚至任何有許可權的人創建同名函數進行部署都會導致函數莫名被覆蓋，同理雲函數網關 API 也可以隨意更改指向其它雲函數

總結下來，在團隊協作 SCF 開發的時候，遇到的挑戰點如下：

二、IMFLOW 一站式 Serverless 開發解決方案的破局與落地

總結上面的雲函數在團隊協作中遇到的一些問題，對應地提出解決方案：

制定規範保證統一的協作，統一的規範保證統一的工作流，提升開發效率進而保證質量
優化雲函數開發體驗，通過工具去自動化完成重複冗餘的操作，並通過封裝過濾掉一些開發學習成本
根據云函數特點制定 CI 和 CD，保證流程統一，也提升部署效率；統一網關規則，減少雲函數網關 API 學習和操作

（1）制定規範，提升協作效率

1）統一雲賬號管理

對於獨立雲函數賬號，每個開發在上手開發前都需要單獨申請，同時還有開通各種許可權，快點半天，慢點一兩天，針對這個問題，考慮使用團隊公共賬號進行統一雲函數管理，工具使用公共賬號進行雲函數部署、更新，免去開發的學習成本、賬號上手成本

2）基於 GIT 管理雲函數

對於雲函數獨立的管理方式，為了能唯一追蹤雲函數，保留了原有的 git 管理項目代碼，制定一系列規範，將 git 項目與雲函數唯一關聯，保證雲函數唯一不可覆蓋

3）命名空間隔離函數環境

為提供雲函數的開發流，針對雲函數的特點，使用雲函數命名空間的概念來隔離雲函數，同時限制測試環境的網關服務只允許內網訪問，保證業務安全

4）統一雲函數規則配置

制定雲函數名、對應網關服務 API 名、環境命名空間的命名規範，以達到命名空間、函數名、網關服務 API 能一一對應，可通過其一推導其二，如知道函數名，可知其訪問 API 是什麼，對應環境命名空間是什麼

（2）自研 CLI 工具， IMFLOW 提升 SCF 研發效率

在第一項制定了規範之後，要讓規範落地，就需要使用工具來輔助，IMWEB 團隊自研了 CLI 工具 -- IMFLOW，提供 SCF 團隊開發流實踐方案，通過工具的方式提升 SCF 研發效率；諸如創建賬號、申請許可權、創建雲函數、開發雲函數調試、雲函數網關 API 關聯、函數隔離等等，通過 CLI 工具，輸入命令即可完成。

1）上手開發更快

使用了 CLI 工具來輔助之後，對比團隊過往的開發模式，通過 CLI 可達到 2 分鐘上手進入開發

2）調試體驗同傳統服務開發一致

通過同構 + 構建的方式，保留傳統服務開發體驗，工具封裝屏蔽了雲函數文件，開發者開發時可同以往一樣

3）一鍵定位調試雲函數

雲函數的真實運行環境相對複雜，若是遇到了涉及雲函數環境調試的問題，需要真實調試雲函數，此時本地即可完成調試，工具封裝了一系列操作，如實時調試、監聽文件變更等，實時部署，實現一鍵定位調試雲函數

4）極致優化雲函數部署時間

雲函數的部署是走的外網部署，而雲函數的部署時間影響到了雲函數的發布時間，甚至在做本地實時調試雲函數時，影響了雲函數的調試效率，為了極致優化雲函數部署時間，利用了雲函數的 layer 功能、項目的 node_module 變動幾率較小、同時代碼包大小會影響部署時間這些特點，對雲函數項目部署進行了拆分，當 node_modules 沒有變動時無需部署 node_modules，進而減少了了部署時間

在做了部署優化後，查看項目的部署時間，大部分時間 35s 即可完成函數部署

（3）質量保證

在質量保證方面，主要是通過 CI | CD 規範部署流程，制定網關服務規範來隔離雲函數和降低網關配置成本。

限制測試環境網關服務為內網可訪問。

另外，為了保證雲函數的運行穩定，避免因為雲函數的冷啟動導致雲函數訪問失敗，即對雲函數的容災處理，做了一層 STKE 的容災，通過代碼同構的方式，利用工具構建打包，完成一套代碼實現既可部署 serverless ，也可以部署 STKE，配合網關的處理，完成雲函數的降級容災

三、IMFLOW 使用

imflow 內置命令

至此，感謝閱讀。

Serverless 架構應用開發京東￥ 318.00去購買?

相關回答：

什麼是雲計算？?

www.zhihu.com

CDN是什麼？使用CDN有什麼優勢？?

www.zhihu.com

2020 國內公司前端團隊都在搞些什麼?

業務情況

技術事項

營銷與運營體系

智能組件

智能搭建

智能相機