D2 前端技術論壇流水帳

本博客同步自個人GitHub博客

一直想去阿里看看，此次成行，至少 BAT 三總部簽到成就是 get 了。經歷了多日的降溫降水，初到杭州，就遇上了升溫，即便穿短袖在陽光下走走也會微微流汗。一大早出門前往阿里西溪園區，擔憂坐公交來不及，就打車過去，在車上就感嘆——阿里的位置真是偏啊，離城區太遠了，杭州的地鐵只有一條線，像我這種在南京工做，天天地鐵穿城而過去上班的方案放在杭州確定是行不通了。不過由於遠離城區，地廣人稀，阿里園區也是足夠大，不過好在園區內有不少公用自行車能夠隨便騎，反而十分方便。

園區的環境也是不錯的，有不少植物，一些植物上還掛上了介紹的牌子，就像植物園同樣。建築的裝飾風格也比較活潑，牆上有壁畫，融合了阿里各產品的元素在裏面，相似淘公仔和天貓吉祥物的大玩偶也隨處可見，看了能讓人會心一笑，這點比起我廠過於商務的生硬風格更讓我喜歡一點，也有互聯網風格。

好了，免費廣告不能打太多，下面進入正題。此次是我第一次參加 D2 這個活動，以前有據說過，不過由於還在上學，沒有足夠的盤纏，也就沒能參加。因此這第一次參加在國內能夠算得上是影響力首屈一指的前端論壇，也是挺興奮的。到了論壇現場，發現到的還算比較早，主會場人還不多，分會場幾乎尚未人到。值得一提的是，在簽到的人羣中，我看到了張鑫旭大神，他的博客我看過很多，大活人仍是第一次見，瘦瘦高高的，皮膚有點黑。

同部門的小夥伴們當天上午才從南京出發，而我是頭天晚上就到的急先鋒，所以我到的時候大部隊還在路上，因此我乾脆就單獨行動了。第一場的分享在兩個會場分別是來自百度 FEX 的前端工程師的《指尖上的數據》和支付寶蘇千的《支付寶先後端分離的思考與實踐》。蘇寧易購在不久以前剛剛有一次 node.js 的實踐，算是對先後端分離的一次探索，支付寶在這方面算是走在前面的公司，因此我絕不猶豫的選擇了這場分享。圓心的開場講話一結束，我就衝出門直奔分會場。同時我也發現，不少朋友們的選擇也和我同樣啊，幸好個人動做快，竟然還搶到了一個前排的座位，要是慢上五秒，就連地板都沒得坐了。（一樣值得一提的是，玉伯後來就坐在個人前面一排啊，終於得以一睹大神風采~）。

Node.js部分

《支付寶先後端分離的思考與實踐》蘇千（袁鋒）

蘇千的廣東口音聽起來挺喜感，人也是圓圓的挺可愛，不過我可管不上這些，忙着邊聽邊記筆記呢。蘇千說到，先後端分離在實現以前，主要由如下兩個痛點：

• 設計離技術比較遠，產品交互體驗不佳

• 先後端職責不清晰，研發體驗很差

這兩點中，第一點相對的偏向用戶一些，從用戶層面對交互設計是否合理會體驗更加直觀。而第二點，就是對咱們開發者說的。的確，傳統的前端製做靜態頁面，再由後端套模板，而後先後端聯調，改bug，測試，上線，再回測。。。這樣的流程延續了好久，也被詬病了好久，在這種流程下，先後端的工做有了很大的耦合，不利於提升研發的效率，改善研發體驗。

Node.js 在先後端分離中扮演的角色應該是一箇中間層，在這方面，除了支付寶外，淘寶的中途島項目有不一樣的側重點。中途島項目中，Node.js 層在職責上依然屬於前端，並無搶後端的飯碗，而是將通常先後端職責劃分模糊的地方進行了分割，後端再也不插手前端 UI 層的工做，不在模板上插入各類複雜的邏輯，只負責提供數據，提供服務化的數據接口。Node.js 層要作的就是路由共享，對請求進行分發，固然，路由的工做還能夠再加一層 nginx，這點在騰訊的實踐中有所體現，這個後文會說。Node.js 層的另外一職責即是模板的共享，根據不一樣的業務場景，選擇模板渲染是在服務端完成仍是瀏覽器端完成。例如淘寶的首頁渲染是服務端完成，而一些詳情頁或其餘模塊就是交由瀏覽器端渲染了。

說完淘寶，仍是說回支付寶。蘇千的整個分享過程當中，有 70% 的時間都是在說他們的 Chair 應用。它是支付寶先後端分離中的關鍵環節，它的主要特色是對邏輯的複用，對阿里內部系統的融合，以及統一的安全策略。不過這個系統跟支付寶的不少核心業務相關，所以沒有開源，更多的細節也就無從知曉。從蘇千所說的話來看，Chair 能夠說就是一個完整的 web app。它有路由，有各類中間件，有 C 和 V 之間的協做，以及對支付寶各個服務接口調用的統一管理。能夠說，有了 Chair 的服務，前端同窗的開發能夠想象，應該會很爽。

不過我我的對 web 服務的研究還很淺，蘇千的分享在各方面也是走馬觀花，更深的理解也沒有了，總結成一點，就是後端必定要服務化，不少的數據接口要進行改造或是管理。聯想到蘇寧幾個月前的門店頻道項目，其實前臺和 Node.js 部分的實現已經沒有什麼大問題的，就是由於後端的服務不能統一，致使最後沒有徹底成功，有些遺憾。

在最後的 QA 中，蘇千針對一些問題的回答也有些有價值的地方：

• 支付寶前端團隊的分工，力求成爲多面手，各類工做都要作，甚至可以接手一部分的後端工做。

• 對於一些包含了不少原子接口的大接口，併發請求，這方面由前端來完成

• 後端提供的接口，主要爲 RPC，少許 RESTful（支付寶）

• UI 測試在實際瀏覽器中跑

• controller 控制全部的數據邏輯，並提供給 view 層，視圖層只負責渲染。

• 支付寶的先後端分離之路也很曲折，最初是由玉伯在兩年多之前發起，也經歷了一些失敗。聽到這我卻是有些安慰，技術之強如阿里，在這方面也是經歷了不少困難，咱們經歷的一些失敗也算不上什麼，要相信將來是美好的。

《nodejs一小步 前端開發一大步》林楠

下午的第一場分享也是跟 Node.js 有關，是由來自騰訊雲的 BrianLin（林楠）帶來的 Node.js 在騰訊雲的實踐。從他的整個分享內容來看，騰訊雲對於 Node 的應用更偏後一點，不只僅是擔任中間層的工做，更多的會接管一些後臺的邏輯，好比原來由 php 完成的工做。經過一系列對 php 和 Node.js 性能的比較，最終得出的結論是在騰訊雲的業務場景下，Node.js 的綜合性能會更高一些。

Node.js 和 php 的性能比較，各類論據我就不羅列了，林楠說的沒有什麼特別讓人意外的地方，上網搜搜也能找獲得。比較有價值的應該是在應用過程當中，使用 Node 會遇到的一些問題以及解決辦法。首先是 Node 和 nginx 的協做，在實際的應用中，Node 通常都會和 nginx 搭配，由 nginx 發揮特長，進行一些請求的分發，尤爲是靜態資源的請求分發。騰訊有本身改造過而成的 tnginx，它的主要工做就是動靜態資源的分離，靜態頁面由 tnginx 直接處理，動態頁面由 Node 處理。nginx 的職責主要有三點：

• 域名收歸，由 nginx 進行路由分發。

• 灰度發佈，應該是相似於 A/B test，由 nginx 進行代理。

• 配置化支持 https 的能力。經過 nginx 配置項實現 https 的支持相對用 Node 來實現要方便得多，客戶端和 nginx 的鏈接使用 https 協議，nginx 和後端各服務之間的通訊依然使用 http 協議。

另外林楠還提到了數據存儲方面的一些問題，我沒太聽懂，就很少說了。他還提到一個問題，就是發佈時的性能抖動問題，在每次發佈事後，性能總會有一段降低的過程，這主要是因爲在發佈過程當中，服務須要重啓，在每次重啓時，服務請求隊列中會有一部分請求沒有處理，在新的服務啓動時，這部分未處理的請求會對整個服務的性能形成影響，不過具體是怎麼形成影響的呢，我不太清楚。就這個問題，我和身邊的來自孢子社區的小夥伴交流了一下，孢子社區使用的是 fib.js，它使用了協程，它是一種多現場單線程，每一個協程自行創建堆棧，共用一個線程。封裝後的 v8 不會感知到協程的存在。徹底非阻塞，由纖程驅動，沒有 Node 特有的回調模式。JavaScript 線程內會運行多個纖程，在發佈方面，每次發佈會啓動新的纖程，不會影響到原來鏈接狀態中的各類請求，新的請求所有切到新的纖程上，舊的纖程上的鏈接只要不斷開，仍是請求舊的服務，一旦全部鏈接斷開，則自動回收舊纖程，達到無縫切換。更多關於 fib.js 的介紹，能夠看它的做者孢子響馬的分享pdf。這種發佈方式在技術上非常新穎，不過可能還只適合孢子這樣類型的團隊，對於蘇寧的實踐，暫時只能提供必定的參考價值吧。

前端工程化架構部分

《面向多端的蘑菇街前端技術架構》貝勒（李振強）

我跳過了中間周杰的《第三方開發前端實踐》這部分。緣由是他的分享我感受實在是不知所云啊，也不知道是否是個人水平太差，徹底聽不進去，倒以爲他是在推廣本身公司的各項產品。沒有參考價值，那麼略過不表。

原本，看貝勒分享的標題，感受他會講一些多終端適配甚至是 hybrid 開發方面的東西，實際上不是，主要內容也就是蘑菇街一路之前的前端技術架構的演變。卻是和後面京東的分享很類似，正好我此行的目的就是爲了聽先後端分離和前端架構方面的東西，正合我意，所以我也就把這個分享劃分到前端工程化的主題之下了。

蘑菇街做爲一個當初的創業公司，在初期技術方案也的確是十分原始的，整個前端部分一句話總結就是 jQuery + base.js。jQuery 是 JS 庫，base.js 是對業務開發中經常使用方法的封裝，這樣的技術選型根本談不上什麼架構的思想。隨着蘑菇街業務的不斷擴大，複雜性的增長，過去簡單的套用 jQuery 的方案已經不合適了，所以他們開始探索本身的前端工程化架構方式。

目前，蘑菇街採用的前端技術架構爲：webdemo做爲本地開發環境的名稱（這個名字起的很奇怪啊），其中包含兩個方面，一個叫 walkman，是前端自動化工具，另外一個叫 magpie，做爲前端的底層，至關因而將以前的 base.js 進行了升級。

webdemo 這個東西，主要是用來解決一個代碼的管理問題。過去蘑菇街的代碼是託管在 svn 上，svn 有什麼弊端已經不用多說了，龐大的代碼量給代碼管理帶來了很大的困難。還記得在人人網實習的時候，代碼庫包括靜態文件都是用 svn 管理，checkout 一次好像有 5G 的數據量，一旦本地維護出點問題，代碼衝突什麼的，svn 用的不熟練的人就會苦不堪言，我就是受害者之一。webdemo 這個東西實際上就是一套解決方案，針對代碼管理的問題，對後端服務的調用，採用了 nginx + php 的方式，代碼託管平臺也遷移到了git上，而且提出一種子模塊（submodule）的概念，將pc端、h五、pad 和 im 的代碼分別管理，我想應該是用 git 切了不一樣的分支。在開發環境上，使用 require.js 進行模塊化開發，預編譯 css 採用 less，對 less 的處理用了 php 的 lessc 模塊在服務器端進行編譯，同時使用 sourcemap 對源文件進行引用，便於開發調試。

前端底層名爲 magpie，它的一大做用是統一了各終端的開發方式，提供了一些全局變量，具體是什麼我忘了，就記得名字是 MoGu，我想應該是提供了一些全局的配置信息，好比多種端適配要用的一些東西，或者是一些公用的方法吧。開發模式上，採用了一種類 backbone 的方式，將頁面單頁應用化，以便於模塊化開發，減小各模塊的耦合度，提升開發效率，這種方式在中型公司中彷佛比較常見。base.js 這個庫有什麼變化我記不清了，不過因爲它是針對蘑菇街的業務高度定製化的，因此參考價值應該不大。

值得一提的是蘑菇街的前端自動化系統 walkman，包括後面京東的 jdf，和咱們的 fas 都有高度的類似性，有很大的參考價值。在流程構建方面，walkman 採用了 grunt，在發佈階段，用 r.js 進行打包，開發階段的模塊化異步加載沒有必要帶到生產上去，所以，自動解析依賴，打包 js 也是不錯的方式。孢子的小夥伴給我看了他本身實現的一套打包腳本，不過因爲是基於孢子的開發框架，不能直接移植，並且實現上好像還有些不完善。對於 css 的打包，採用 lessc 來完成。我以爲這部分功能其實徹底能夠集成，不過這還牽扯到一個統一團隊開發方式的問題，京東用的 scss 也是同樣的。項目腳手架採用 yeoman 來生成，配置方式固然根據蘑菇街的業務形態進行了定製，這點在fas中也有體現，雖然還比較初步。

在數據模擬方面，蘑菇街用的是 lotus，在介紹 lotus 的時候，貝勒還提到了一個叫 mean.io 的東西，據我在 github 上的搜索結果，他指的多是 mean.js 這個東西，先後端開發先定好開發所需接口和數據格式，達成一致之後前端便脫離後端，徹底使用 lotus 進行數據模擬在本地開發，lotus 還能夠根據數據接口直接生成文檔，便於後期維護和二次開發使用。

對於我比較關心的 hybrid 的內容，貝勒只提到了一個 jsbride，說是一個 hybrid 的開發環境，不過看來蘑菇街的 hybrid 之路也纔剛剛開始，尚未什麼能夠分享的東西，貝勒也沒有再多說。

《京東前端工業化實踐之路》劉威

這個算是 D2 的全部分享中我最關注的分享之一了，另外一個是淘寶的前端工程與自動化體系，無奈兩個分享同時開始，分身乏術，考慮到京東的現狀相對於淘寶應該跟蘇寧更類似，我便選擇了這場分享。

來自京東的是一位前端架構師，以前曾就任於百度和新浪。他就京東目前的前端工業化進行了一些分享。總結起來，我以爲京東的前端現狀實際上跟蘇寧仍是很類似的。

京東的前端工具集名爲 jdf，在 npm 上提供了模塊的下載，github上的倉庫能夠點擊這裏，這個工具提供了多種命令行指令，可以完成一系列前端開發過程當中可能須要的各類構建工做。京東的開發對模塊進行了劃分，每一個模塊能夠獨立維護，模塊有符合規範的目錄結構，引用方式相似於{%widget name=""}，模塊的配置文件符合 common 規範。js 的模塊化方面採用了一樣兼容 commonjs 規範的 seajs 進行模塊的加載管理。預編譯 CSS 選擇了 SCSS，每一個文件的命名方式以模塊名開頭，避免衝突。後端模板用了 velocity 語法，作到了先後端公用。jdf 提供了模塊的新建，安裝，發佈和預覽等一系列指令，便於單個模塊的調試。內部有模塊雲平臺對模塊進行管理，使用 FTP 控制權限，有權限的人能夠進行模塊的發佈，任何人均可如下載模塊，模塊的版本識別依賴 json 配置項中的 version。

模塊方面大體是以上這些。在靜態資源輸出方面，經過發佈至 cdn 而後在資源路徑前加 cdn 前綴的方式進行非覆蓋式發佈，以版本號進行區分。js 資源方面的輸出我有點記不清，他好像提到了一個 cmd 模塊自動提取文件 id 和 dependencies 的機制。在字符編碼方面，由工具進行統一化。性能優化方面，jdf 工具集成了 js, css 和 png 的壓縮，js/css 和 css/sprite 的合併，以及 combo 請求的功能。其中對 sprite 的壓縮怎麼實現我還想象不出來，好在 jdf 代碼開源，能夠研究一下。

聯調的實現主要是靜態資源上傳至聯調服務器，html 上傳至另外一個聯調/預覽服務器，沒什麼特別的。上線過程也比較常規，編譯系統去靜態資源 svn 上取代碼進行編譯（他所說的編譯應該是至 SCSS 預處理，js 壓縮合並這方面的意思），而後發佈至cdn。

輔助功能簡單羅列一下：

• 本地 serve

• 錯誤提示

• 自動刷新

• 自動監聽

• 代碼質量檢查：jslint, csslint, htmllint

• 根據配置文件，統一編譯，輸出

一點想法

總結起來就是以上這些。回顧整個 D2 我所聽到的分享內容，結合我對蘇寧網購業務的一些瞭解，我以爲目前最有價值去發展的就是 fas 這套系統，fas 若是有競品的話，就是京東的 jdf，若是咱們有足夠的時間和人力投入的話，超越京東不是不可能的事情。對於先後端分離的實踐，我還須要多學習，多瞭解一些相關的知識，怎麼去實現這個東西，蘇寧有在這方面有實際經驗的開發者，要向他們學習一下。

D2 上聽到了也只是其餘公司相關技術的冰山一角，只有有了雄厚的技術積累才能夠從容的進行技術分享，對於咱們來講，先作好第一步吧。