A. 淘寶首頁的基礎知識
有關淘寶首頁的基礎知識
很多人都用淘寶，但是對淘寶首頁並不了解，我這里帶來一位淘寶首頁的設計師的講解，希望可以讓你對淘寶首頁有一個基本的認識。
一、相關背景介紹
淘寶首頁是淘寶的門面，承載著幾乎淘系所有業務的入口，流量很大，量級單位為億。近幾年無線端崛起，業務重點開始向無線終端偏移(目前不能叫偏移，基本以無線為主了)，所以淘寶 PC 端首頁的流量也有削減，不過即便如此，它的日均 PV 依然相當高。
淘寶首頁一向是內部平台和技術的試驗田，它一直在變化著。最新的框架和系統都會找淘寶首頁試點，可以試想下，如果某一項需要推動的升級或者優化措施在淘寶首頁已經上線，並且拿到了良好的數據和穩定性，其他業務還有什麼理由不去嘗試和更迭呢?同時，去年一年身在淘寶前端的技術架構組，自然而然也會主動去 push 一些實驗性的內容到業務上。
淘系的站點頁麵包括首頁、其他頻道頁和活動頁等，這些頁面並不都由淘寶前端一行一行的代碼碼出來，業務如此之多，這種玩法即便人數 double 也忙不過來。事實上，大多數頁面都是依託內部的搭建平台——運營或者前端通過模塊搭建的方式——構建的，而前端 focus 的重點在於搭建平台的建設自身以及模塊的通用性和復用率的保障，當然，還有一些工程化的東西。
使用搭建平台搭建的頁面，前端只需要考慮組成頁面的原子模塊的開發，整體的渲染由搭建平台提供的統一腳本全權負責。而在淘寶首頁上，考慮到頁面模塊數量巨多，加上還有少量跨部門、跨團隊的溝通，渲染模型略微不同。
二、淘寶首頁的整體變遷
背景中提到，淘寶首頁依託於內部搭建平台，它的變遷自然也是跟著搭建系統的變化而變化的。
1、PHP 下的淘寶首頁
接手淘寶首頁不久，便遇到了一年一度的改版，那時它還運行在 PHP 環境中。這里需要說明的是，淘寶首頁的所有代碼完全由前端掌控，前端不會直接跟資料庫打交道，其數據來源分為兩部分。
數據來源
一是運營填寫的數據。 採用前端挖坑的形式，預留坑位讓運營獲取填寫數據，
運營填寫這些坑位就會產生這份 PHP 模板對應的數據，最後渲染出來就是一個完整的 HTML 片段(實時性渲染)。
舊版搭建系統中就是通過這種方式構造一個子模塊。我描述得十分簡單，但作為一個平台它需要考慮的東西還有很多，比如數據順序的控制、定時發布、回滾機制、過濾機制、篩選機制、數據的同步、數據的更新、版本控制、許可權控制、其他系統的引用等等。
二是後端或者個性化平台提供的數據。 不同的業務有不同的訴求。一些業務有自己的後端，他們要求使用自己業務產出的數據;有的業務希望用戶看到的內容不一樣，千人千面，期望接入演算法;一些業務跟賣家直接打交道，期望使用招商數據;而有些業務期望採用運營從數據池篩選出來的數據……總之，淘寶首頁需要對接形形色色的系統，介面繁多。後面會提到對動態數據源的整合。
並且這些系統對應的域名是不一樣的，JSONP 格式自然也就成了首選。但一些特殊的系統，比如廣告，它的渲染並不是一個簡單的 JSONP 請求，可能它還要干預整個廣告的渲染流程，比如載入他們的 JS，把渲染的控制權交過去。
頁面的架構
上面介紹了數據的來源和子模塊的結構，那麼整個頁面又是如何構成的呢?模塊的搭建分為兩種，一種是可視化搭建，運營或者前端可以將開發好的模塊(或者模塊庫中選取的模塊)拖拽到容器內，形成一個頁面：
當然，上圖也只是一個模型，作為一個系統需要考慮的問題還有很多很多，如頁面的布局、多終端適配、模塊的臨時隱藏、位置調整、皮膚選擇、模塊的復制等等。
通過模塊 id 將模塊引入，並且添加一些類似 lazyload 的標記，方便控制渲染節奏和數據入口。源碼搭建和模塊搭建的區別在於，前者更易於控制模塊的結構以及模塊的渲染順序。
動態數據源
首頁面對一大堆介面和平台，對接幾十個業務方，介面是個很大的問題，由於後台系統的差異，基本沒有辦法統一數據源的格式，一旦運營哪天心血來潮要換一個他自己覺得用的更爽的或者數據更好的系統，前後端估計又得溝通和對接幾次。
平台具備數據源接入的能力，也就是說我們挖的坑不僅僅可以讓運營填數據，還可以從各種數據源中直接導入數據，當然，這里需要進行一次數據欄位的映射轉換。
綁定之後，數據既可以同步輸出，也可以非同步輸出，這些都是平台提供的能力。這個方案基本上解決了後端系統/介面變化的問題，並且減少了前後端之間的溝通成本。
不過這里需要注意的是，雖然頁面上的介面都通過平台統一梳理了一次，這也意味著，頁面所有的請求會先流經平台，然後分發到各個後端，平台的抗壓能力要求很高。
2、PHP 到 Node 的變遷
淘寶首頁日均請求的這個量級，不可能是十幾二十台台伺服器抗得住的，支撐它必須有一個服務集群。
每一個 CDN 節點上都具備 PHP 渲染的能力，當頁面發布時，我們把該頁面所有的模塊和數據同步到全部 CDN 節點上，基本模式大概就是如此了。看起來還挺不錯，但是經過一段時間的運維，很多安全、性能問題都慢慢浮現出來了：
性能問題。 每個 PHP 頁麵包含多個子模塊，而子模塊也有可能引用了其他的子模塊，PHP 的 include 操作是存在消耗的，每一次引用都是一次磁碟 IO，一個渲染節點上跑了成千上萬個類似淘寶首頁的 PHP 頁面，並發一高其效率可想而知。
推送機制問題。 文件同步是一種比較惡心的機制。首先，時間上沒法控制，一個文件同步到所有的節點，快則幾秒鍾，慢的話耗時會超過一兩分鍾;並且同步過程還有可能失敗，健康檢測的成本也是相當高的。發布比較緊湊時，需要同步的文件也很多，很容易造成隊列堆積，加劇同步差的體驗。
實時性強需求問題。 文件在推送之前，還可能經過一些前置系統，發布鏈路越長，線上生效時間越慢，慢的時候大約五分鍾才生效，這樣的延時對於實時性要求很高(如秒殺)的需求來說是完全不能接受的。
當然，還有很多其他問題，如運維成本增高、安全風險增高、PHP 資深人才儲備不足等等。所以 PHP 渲染容器的命運，就是，被幹掉。
服務集群為 Cache CDN，它只有靜態文件處理能力，沒有 PHP/Node 的渲染能力，所以處理效率高，性能也好，抗壓能力相當強，並且扛不住的時候還可以花錢買服務，拓展 Cache 集群。
用戶訪問時，Nginx 轉到 Cache CDN，如果命中緩存則直接返回，沒有命中便回源到源站伺服器。源站伺服器是具備模塊渲染能力的 Node 服務，它可以做很多事情：
· 控制 Cache 響應頭，通過 max-age 和 s-maxage 控制頁面在客戶端的緩存時間以及在 Cache 上的緩存時間，這個緩存時間可以根據需求隨時做調整，比如大促的時候調長一些;
· 控制內外網環境，和 AB 測試狀態;
· 融合前端相關的工具鏈，比如檢測、壓縮、過濾等等。
它的優勢有很多，這里不一一列舉了。這個模式中還添加了一層容災，源站伺服器每隔一段時間將數據推送到於 Cache 同機房的備份伺服器，一點源站掛了，還能夠自動容災到備份數據上。
模式的變化不僅在運維上有了突破，CDN 被攻擊時的安全風險也低了很多，同時也省卻了 sync 所需的各種檢測機制，每年節約成本也是百萬以上，優勢還是相當明顯。
3、Node，不一樣的模式
上面 PHP 模塊中，我們只說了 HTML 和數據部分，用心的讀者應該已經發現，CSS 和 JS 這些靜態資源都沒提到，那頁面是如何渲染的呢?
舊版 PHP 頁面中，我們是直接引入了一個 CSS 和一個 JS，淘寶這邊採用的是 git 版本迭代發布，這些靜態資源都是直接放在一個 git 倉庫中。也就是這樣：
每次發布完 git 文件，再修改 PHP 的.版本號，然後發布 PHP 代碼。當然，也做了相關的優化，比如發布 git 時自動更新版本號等。
一個模塊的 CSS/JS 和模板放在一起，CSS/JS 與頁面其他模塊的靜態資源是相互獨立的，目的就是希望單個模塊也能夠完整的跑起來，更加利於模塊的復用。
而模塊的挖坑，也從模板中獨立了出來，採用 JSON Schema 的形式定義數據格式：
模塊之間相互獨立隔離，所以會存在一定程度的冗餘，不過模塊解偶帶來的收益要比這點冗餘要多得多。事實上，我們是通過一個倉庫去管理單個模塊的。頁面的渲染就比較簡單了，源站 Node 容器會將所有的 index.xtpl 合並成一個 page.xtpl，為減少頁面請求，css 和 js 也會 combo 成一個文件。
任何模塊的更新，頁面都會有感知，下次進入系統時，就會提示是否需要升級模塊和頁面。
三、淘寶首頁的性能優化
首頁模塊眾多，如果一口氣吐出來，DOM 數量必然超過 4k 個，其結果就是首屏時間極長。按照 TMS 的開發規范，每個 TMS 模塊都包含一個 index.js 和 index.css，最後展示出來兩個 combo 的 js 和 css。首頁載入的時候也不會一口氣執行所有 index.js，否則剛開始頁面阻塞會十分嚴重。
頁面的渲染邏輯
· 遍歷所有 TMS 模塊(包含一個 J_Mole 的鉤子);
· 部分 TMS 模塊無 JS 內容，但是載入了一個 index.js，為模塊添加 tb-pass 的 class，用於跳過該模塊 JS 的執行;
· 將頁面分為兩塊，首屏為一塊，非首屏整體為第二塊，先將首屏模塊加入到懶載入監控;
· 待首屏模塊載入完成，或者用戶處理了頁面交互時(滾動、滑鼠移動等)，將非首屏模塊加入到懶載入監控;
· 處理一些特殊模塊，它們會在進入視窗之前幾百像素就開始載入;
· 監控滾動，按照以上邏輯，渲染模塊;
· 部分模塊即便是被執行了，也不一定渲染出來，因為它的優先順序不高，在模塊內部加了事件監聽，比如等到 mouseover/onload 事件觸發的時候再渲染這些內容。
代碼的性能優化是一個精細活，如果你要在一個龐大的未經優化的頁面上做性能優化，可能會面臨一次重構代碼。上面的文章提到的是頁面內部的細節優化，但是在開發流程中做的規范化、標准化，以及線上訪問通路中的各個環節優化還沒有提及。
四、淘寶首頁的穩定性保障
在大流量下，任何小問題都會被放大成大問題，所以開發環節遇到的任何偶發性問題都需要引起重視。不過很多偶發性問題在我們的測試環境中是找不到的，比如與地域相關的問題(如上海的某個 CDN 節點掛了)，用戶屬性問題(如 nickname 最後一個為字母 s 的用戶頁面天窗)，瀏覽器插件問題，運營商廣告注入問題等等。
難以在上線之前把所有問題考慮周全，但是有兩點是必須做好的：兜底容災 + 監控預警。
1、兜底容災機制
兜底容災有兩個層面的考慮：
· 非同步介面請求錯誤，包括介面數據格式錯誤，介面請求超時等;
· 同步渲染，源站頁面渲染出錯。
非同步介面請求，主要涉及到的是後台系統，對接系統較多，各個系統的穩定性和抗壓能力各不相同，這方面的保障有多種方案。
每次數據請求都緩存到本地，並且為每個介面都提供一個硬兜底。還有一種方案是「重試」，請求一次不成功那就請求第二次。
對於同步渲染，它只需要頁面模板和同步數據，兩者中任一種存在錯誤，源站都會報錯，此時回源返回的內容就是一個 error 頁面，狀態碼為 5xx。這個錯誤不一定是開發者造成的，有可能是系統鏈路出現同步異常或者斷路問題。
一旦源站任何異常，Nginx 都會轉到與 Cache CDN 同機房的首頁鏡像上去，這個鏡像內容就是淘寶首頁的 HTML 備份源碼。
2、監控預警機制
監控也有兩個層面：
· 模塊級別的監控，介面請求布點、模塊天窗檢測等;
· 頁面的監控，在頁面上添加特殊標記，定時回歸所有 CDN 節點，查看特殊標記是否存在。
模塊層面的監控，內容還是相當多的，監控的點越多越詳細，到最後定位問題的效率就會越高，比如在一個稍微復雜的模塊上，我會埋下這些監控：
· 介面請求格式錯誤、請求失敗、請求超時，至少三個埋點;
· 硬兜底數據請求失敗埋點;
· 模塊 5s 內沒有渲染完成統計埋點;
· 模塊內鏈接和圖片黑白名單匹配埋點。
其中部分監控還會自動處理明確的錯誤，比如 https 頁面下出現了 http 的圖片，會立即自動處理掉這些問題。
3、上線前的自動化檢測
這屬於淘寶整個工程化環境的一部分，前端自動化測試。一般會在上線之前處理這些問題：
· 檢測 HTML 是否符合規范
· 檢測 https 升級情況
· 檢測鏈接合法性
· 檢測靜態資源合法性
· 檢測 JavaScript 報錯
· 檢測頁面載入時是否有彈出框
· 檢測頁面是否調用 console.*
· 頁面 JS 內存記錄
當然，也可以自己添加測試用例，比如檢測介面數據格式、模塊天窗問題等。自動化檢測也可以設定定時回歸，還是比較有保障的。
五、淘寶首頁的敏捷措施
1、健康檢查
頁面模塊眾多，為了能夠追蹤頁面上每一個小點的變化，我在請求、渲染的每一個環節都做了詳細的統計。
一旦介面請求失敗，或者介面走了容災邏輯，或者模塊渲染超過 5s，控制台都會有黃色警報，當然此時，也已經向伺服器發送了警報統計。
2、介面 Hub
介面 Hub 是對數據請求的管理工具。
頁面很多模塊的渲染都需要一個以上的數據源，一旦運營反饋頁面渲染數據異常，可以直接通過 Hub 找到數據，加速 Bug 定位效率。同時 Hub 也可以用來切換環境，將一個介面的請求切換到日常或者預發環境的介面之中，它是調試的利器。
3、快捷通道
我在頁面腳本執行前後都放了一個快捷操作通道，一旦遇到緊急線上問題，比如樣式錯亂溢出、介面報錯導致天窗等，可以通過快捷通道直接修改頁面的 CSS 和 JS，兩分鍾內上線。
不過這類通道只適合緊急問題的修復，畢竟隨意插入 JS 代碼是存在很大風險的。
;B. 淘寶模版的模板來源
淘寶模板主要來自以下幾個方面： 一、免費模板 很多電子商務提供商提供的網店系統（比如XpShop網店系統）都是可以換模板的，這類產品通過後台一鍵切換就可以達到更換網店風格的效果。這類公司為了增加系統的流行度和通用性，本身會組織人力針對產品開發一些免費的網店模板跟系統配合發布出去。其它一些模板設計愛好者，他們出於學習交流的目的，往往把自己的模板貢獻出來給大家使用。這類模板由於是免費，在模板的裝載速度方面，往往比不上系統官方提供的的商業模板。 二、買家與人共享的模板 網上的開店的用戶一般裝修了模板，但是他們往往會購買多套模板，對於不用的模板，他們往往會拿出來和大家分享。 三、專業公司提供的商業模板 有一些公司為了增加服務價值，往往會提供一些免費的模板，這些模板是包涵在其他的服務之中的，例如：像有照片網就是提供網路存儲空間的網路服務商，通過使用免費模板來吸引顧客訪問其網站。 這里建議開展電子商務的個人和企業，最好選擇第三類模板，不僅高效、安全，同時也沒有版權的紛爭，而且有穩定的售後服務，出現問題，能及時得到維護。
C. 哪裡去找淘寶詳情頁模板
您好，淘寶詳情頁你在發布寶貝的時候，
在選擇產品類目的時候，
右邊就可以看到模板，
但是這個是別人的模板，
並不適合你，
所以淘寶詳情頁建議還是自己弄，
望採納，謝謝
D. 這種淘寶賣家店鋪首頁模板怎麼弄的
可以直接在淘寶購買的，我現在用的是藝灣的，直接包年，有300多款模板可以隨便用，比單獨買一個省事很多。你可以參考一下
淘寶的模板分為描述模板，分類模板，公告模板，旺鋪模板。其中除了旺鋪模板外，其他的模板都是普通店鋪可以用的。以上這些模板都可以在淘寶找到人購買，或者比如藝灣這類網站都有提供。如果希望自己動手也是可以完成的，只是要花費些時間
E. 如何評價淘寶 UED 的 Midway Framework 前後端分離
【賀師俊的回答(17票)】:
瀉葯。
1. 這系列文章寫得很好。
【注意，熟悉我的同志應該知道，我極少給出「很好」的評價。】
2. 這系列文章以及其背後的實踐重新樹立了淘寶系前端工程水準的領先地位。
【在此之前的一段時間內，至少從外部來看，淘寶已經落後於狼系和企鵝系了。】
3. 這系列文章及其背後的實踐也證明了nodejs對於前端來說不僅在工具鏈而且在架構層面的意義。
【注意，這系列文章中的思路其實並不新鮮，但是在淘寶這樣規模而且業已非常成熟的產品中實施這樣的轉變，我認為是具有標志意義的。】
4. 具體細節上仍有許多改善空間，如此系列的第4篇《前後端分離的思考與實踐（四）》在防禦XSS時還是存在一些傳統問題。這方面在參加杭JS的時候，我跟淘寶的herman同學有過溝通，具體就不在本問題展開了。因為這是局部問題，對整體架構影響不大。
5. 注意，以上評價的都是架構，或者說是思路。實施效果是不是好，我相信他們自己的說法。但Midway框架本身因為沒有看到具體文檔和代碼，而且其開發的目的首要是滿足淘寶的需求，因此其本身或其具體組件是否在普遍意義上適用和優秀，無法作出判斷。
【徐飛的回答(19票)】:
早上看到賀老出馬，也忍不住寫了一篇來談一下蘇寧這樣的公司對這方面的考慮。
近兩年來，我一直在思考如何改進前端體系的開發模式，這裡面最基礎的一點就是前後端的分離。談到前後端分離，也有一個誤區，認為僅僅是以瀏覽器作分界，把這兩部分的代碼分離出來。但其實是，做這件事情的本意，是要解決開發模式的問題，也就是要分離前後端開發人員的職責。
針對不同類型的Web產品，這個分離方式是有所不同的。對於Web應用，因為它跟服務端的交互基本就是AJAX或者WebSocket介面，所以這個分離是天然的，整個前端基本都是靜態HTML模板，JavaScript模塊，以及CSS和相關靜態資源，但是對於網購產品這樣的形態，它的做法就不一樣。
## 展示佔主要部分的產品
網購產品的展示需求很重要，圖片等資源載入非常多，但相對的操作卻很少，基本只有搜索商品，加購物車，結算這樣的環節。傳統這樣的產品，多半是這么個工作流程：
交互出高保真圖，前端去切圖，生成靜態HTML加展示效果，然後，注意，他不是自己接著往下做，而是交給另外一群開發人員，把它轉換成服務端模板，比如freemarker或者velocity之類，或者是smarty，為什麼要這么做呢？因為這類產品講究一個首屏優化，是首屏而不是首頁，這就意味著對於首屏來說，經過的環節應當盡可能少，比如說，就不能先載入客戶端模板，再AJAX一個數據，然後去渲染一下。這么做的性能肯定是不如服務端把HTML生成好，然後一次請求載入的。
這個過程肯定是有一些問題的，比如說，如果開發人員B在套模板的過程中，發現原先的靜態HTML部分有問題，應該怎麼辦？大家知道，一個對HTML和CSS都很熟悉，同時又可以寫業務邏輯的前端開發人員是很稀缺的，所以，多數情況下，這兩邊的技能是不同的，如果是簡單的頁面問題，這個開發人員可能自己也就解決了，如果他解決不了，怎麼辦？
如果B自己不改，把他已經搞成服務端模板的代碼返回給前端人員A，A也沒法下手，因為已經是服務端模板，A手裡沒有環境，改了之後不知道對不對，不能預覽。那麼，B把問題告訴A，A修改他的原始版本，然後再拿給B又怎樣呢？這時候B又麻煩了，他要對比兩次修改的部分，把自己前一陣的修改合並進去。
所以，不管怎麼搞，這裡面都很折騰。
Midway這個產品，他想要解決什麼問題呢？既然說前端人員沒法預覽模板的原因是，後端在使用服務端模板，那麼，我能不能找一種兩邊都可用的模板，你能在服務端渲染，我也能在客戶端預覽？服務端跟瀏覽器端同時都能運行的語言是什麼？只有JavaScript。
所以，大家就往nodejs裡面去發掘了，一個普通的JavaScript模板庫，它在瀏覽器端也可以渲染，在nodejs端也可以輸出成HTML，這時候，那些原來負責整合模板和邏輯的人員改用nodejs，是不是就解決這問題了？
想像一下這個場景多麼美好：前端來決定某個模板是服務端渲染還是客戶端渲染，當首屏的時候，就在nodejs裡面生成HTML，不是首屏的時候，就AJAX過來在瀏覽器端渲染展示。
從技術方案上看，這么做很好了，工程上又帶來另外一些問題，那就是對熟練JavaScript開發人員的需求量大增。對阿里這樣的公司來說，前端有大幾百人，別的公司只能仰望，所以他當然可以放手一搞，但對我們蘇寧這樣，前端人數不大的，就麻煩了。如果我們也引入這樣的方案，就面臨把很大一部分Java開發人員轉化成JavaScript開發人員這么一個問題，這個事情短期內肯定是無法解決的，所以反過來會增加前端這邊的壓力。所以暫時還用不了阿里這樣的方案，只能努力先提高人員水平再看情況。
服務端引入nodejs還有別的優勢，比如說請求合並等等，這個也可以用其他方式變通解決，比如加一個專門的跟現有後端同構的Web伺服器，在那邊干這些事。
## 展示和業務邏輯較均衡的產品
對於另外一些場景，也有類似的問題，比如支付產品，展示相對沒那麼重，但是又算不上Web應用，它面臨另外一種情況的前後端分離。這種場景下，前端的出靜態HTML和DOM操作類的JavaScript，業務開發人員負責寫後端，還有另外一部分業務邏輯的JS。
這里的問題是什麼呢？是jQuery式代碼造成的協作問題。比如說：
$(".okBtn").click(function() { $.ajax(url, data) .success(function(result) { $("someArea").html(_.template("tpl", result)); });});
因為前端人員的稀缺，所以他不可能幫你把業務邏輯寫出來，所以說，這裡面$.ajax往裡的部分，要業務人員自己寫。然後，數據得到之後，又要去處理界面部分。
很多場景下，處理界面遠不是這么搞個模板放上去就完事的，所以業務開發人員感到很煩悶，為了這么一點小問題，反復去找前端的人來搞，很麻煩，自己搞又特別花時間，所以都很苦悶。
這同樣是一種前後端的分離，只是這個分界線不在瀏覽器，而在於：是否寫業務邏輯。對付這種場景，解決辦法就是加強JavaScript代碼的規劃。現在流行那麼多在前端做MV*的框架，不考慮Angular這類太重量級的，來看看Backbone這樣的，它到底解決了什麼問題？
很多人說，Backbone雖然小，但根本不解決問題。這句話有一定道理，但前提條件是你自己的JavaScript代碼分層已經做得很好了。如果做得不好，它就可以協助你解決分層的問題。
剛才那段代碼，它的問題在哪裡呢，在於職責不清晰。一個函數只能做一件事，這是共識，但由於回調等方式，所以不經意就破壞了函數的單一性、完整性。我們試試來拆開它。
對於一個後端開發人員來說，他為什麼常常害怕寫前端代碼？是因為JavaScript語言嗎？其實不是，我們用來寫業務邏輯的時候，只會使用JavaScript一個很小的子集，對於這個子集來說，它並不存在多大的學習困難，最麻煩的地方在於DOM、BOM等東西，對於一個後端開發人員來說，如果要求他在掌握服務端代碼編寫的同時，還要去學這些，那真是有些不容易，所以，我們來給他省點事。
現在我們的出發點是，把這段代碼拆給兩個不同的人寫，一個人操作DOM，另外一個人只寫邏輯，絕對不操作DOM。前面這個代碼拆給前端維護，後面這個拆給業務開發人員。
最老圡的方式：
a.js
$(".okBtn").click(function() { b1(data);});function a1(result) { $("someArea").html(_.template("tpl", result));}
b.js
function b1(data) { $.ajax(url, data) .success(a1);}
現在大家是不是相安無事了？
如果這么做的話，AB雙方要做很多約定，也就是說，這個過程仍然是一個螺旋鏈。比如說，A先寫點擊事件的綁定，然後想起來這里要調用一個請求，就去找B寫b1方法。B在寫b1的時候，又想到他要調用一個界面展示方法a1，然後又來找A寫，來回也挺折騰。
況且，有這么一天，A在另外一個地方也想調用b1了，但是由於b1的回調已經寫死了，比較蠢的辦法就是在a1裡面再判斷，這是什麼東西點擊造成的，然後分別調用不同的回調。如果情況復雜，那這個代碼寫出來真是沒法看。
如下：
a.js
var type = 0;$(".okBtn").click(function() { type = 1; b1(data);});$(".okBtn1").click(function() { type = 2; b1(data);});function a1(result) { if (type1) { $("someArea").html(_.template("tpl", result)); } else if (type2) { // ... } type = 0;}
b.js
function b1(data) { $.ajax(url, data) .success(a1);}
稍微好一些的辦法是，在b1中，直接返回這個請求的promise，這樣可以由調用方決定到底該干什麼。
如下：
a.js
$(".okBtn").click(function() { b1(data).success(function(result) { $("someArea").html(_.template("tpl", result)); });});$(".okBtn1").click(function() { b1(data).success(function(result) { // ... });});
b.js
function b1(data) { return $.ajax(url, data);}
如果要對返回數據作統一處理，也可以很容易地在b1中，用promise重新封裝了返回出來，只不過這樣在a.js裡面，直接調用的就不是success，而是then了。
注意到這樣的代碼還有問題，比如說大量的全局函數，不模塊化，容易沖突。此外，沒有一個地方可以緩存一些共享數據，比如說這么一個場景：
界面上兩個塊M和N，其中，M初始載入並載入數據，N在初始的時候不載入，而是在某個按鈕點擊的時候載入，而M和N中各有一個列表，數據來源於同一個服務端請求。
現在就有個問題，當N載入的時候，它的數據怎麼來？比較老土的方式，肯定是載入N的時候，同時也再去請求一下數據，然後渲染到N上。
從一個角度看，如果說不重新請求，N的這個數據應當從哪裡來？從另外一個角度看，如果重新請求了，發現數據跟之前的產生了變更，是否要同步給M，怎麼同步給它？
我們看看類似Backbone這樣的框架，它能提供怎樣的機制呢？或者如果我們不用它，怎麼自己把這個分層封裝得更好一些？
首先，是建立一個數據模型，在它上面添加數據的緩存：
define("model", [], function() { var Model = { data: null, queryData : function(param, fromCache) { var defer = q.defer(); if (fromCache || this.data) { defer.resolve(this.data); } else { var self = this; this.ajax(url, param).success(function(result){ self.data = result; defer.resolve(result); }); } return defer.promise; } }; return Model;});
這么一來，我們在模型上作了數據的緩存，如果調用的時候加fromCache參數，就從緩存讀取，否則就請求新的。為了在兩種情況下，調用方介面能保持一致，把整個函數封裝成promise，以便接著調用。這里的模型定義成單例了，假定是全局唯一的，可以根據需要調整成可實例化的。
這個時候，視圖層就要封裝DOM和事件的關聯關系：
define("view", ["model"], function(Model) { function View(element) { this.element = element; this.element.selector(".okBtn").click(function() { var self = this; var fromCache = true; Model.queryData({}, false).then(function(result) { self.renderData(result); }); }); } View.prototype = { renderData: function(data) { this.element.selector("someArea").html(_.template("tpl", result)); } };});
這個時候，多個視圖實例的情況下，數據也能夠較好地利用。
這樣，前端寫這個View，後端寫Model，可以作這么個分工。
這個只是很簡陋的方式，在復雜場景下還有很多不足，在這里先不展開了。更復雜的場景也就是類似Web應用那種方式，稍後專門寫一篇來展開。
## 小結
我們再來回顧前後端分離所要解決的問題，是分離前端和業務開發人員的職責，這個方案怎麼定，是應當隨著團隊狀況來確定的。比如阿里前端厲害，人多勢眾，他的前端就要往後推，去佔領中間層。我們蘇寧這樣的公司，前端比較薄弱，只能在很多場景下，讓出中間層，否則戰線鋪太廣只能處處被動。
同一個中途島，在不同的形勢下，占還是不佔，是很考驗前端架構師的一個問題。
對阿里的這種實踐，我們會持續圍觀，尋找並創造合適的出手時機。
【rank的回答(4票)】:
簡單說下自己的看法。
前端不再繼續「單純」在 kissy 上下功夫，而可以考慮向後的延伸架構是一種前端的進步，這種前端架構將重定義阿里的前端工程師工作，很多互聯網公司比阿里先行一步。
這個思路與與最早阿里很多前端沒有碰後端（例如模板）有很大的關系，用 NodeJS 作中間層能解決現面臨的問題，是一種不限於解決當前問題的長遠解決方案。
具體是否能解決和解決得好，在於細節，不在新，而在過渡。如，如何過渡目前 NodeJS 與原來的數據交互，如何灰度過渡，工作量等。
平台化與介面化思路（後端數據介面以 Services 存在）讓 amazon 收益非淺，現在後端平台化介面化在大公司趨勢明顯。
平台化需要更多更快的應用層開發選型，NodeJS 是不錯的一種。NodeJS 雖然還是有些問題，但從信息面與我們自己的應用經驗來看，已有慢慢成為後端 WebApplication 的一種很好的選型方案的趨勢。
總的來說，是個趨勢。
【Hex的回答(1票)】:
我認為這就是所謂的大前端開發模式。模式確實是好模式，但是真正實踐起來，和後端工程師的溝通和協調也會遇到很多問題。
我做過的幾個項目都是採用這種大前端的開發模式，前端基於Transformers框架+CodeIgniter組成大前端，這樣確實可以很好的隔離前後端，項目可維護性大大提高。
【鄧欣欣的回答(1票)】:
上周去杭州玩了下，和之前的阿里同事做了些技術交流，發現這一年，阿里的前端在流程改進上下了很大功夫； 題主所說的中途島應該是 UDC 團隊做的，應該說思路不是很新鮮，國外有 ebay 向 nodejs 的轉型案例，國內之前也有網路音樂移動端的案例;
但對阿里前端來說，意義確是很重大，解決了合作流程中的一個很大問題：之前阿里的前端是只寫靜態 demo，寫完給開發套模板，開發不太懂 html，漏寫個標簽，然後找前端調試，一來一去很折騰，是個必須干但又是個沒啥技術含量的事； 中途島可以很好的解決這類蛋疼事，但是請不要認為前端就因此會後端了，無非是之前瀏覽器用 ajax 請求介面，現在咱用 node http去請求唄，框架做得牛逼點，統一適配出前端的ajax 介面也不是不可能呀~~，想想嘛，為啥要用 node 呢？ 牛逼直接寫 java 啊。。哈哈哈~
其他的 F2E 團隊也做些很不錯的流程改進工具，同樣不是很新鮮，但對阿里前端都是比較有意義的工具：
def： 項目構建與發布工具，與阿里的 gitlab， scm 整合，各種 腳手架，build，combo，發布，一條命令搞定，確實很方便；
dip：數據介面平台，定義業務線前後端數據格式的一個內部公共平台，基於 json-schema，好像也可以給你提供 mock 介面；
uitest：前端持續集成平台；之前這東西我是邊做邊吐槽的，似乎剛上線，類似 jenkis 這些，提交或者發布代碼時，先幫你跑一次測試用例；目前通用測試庫比較少。
Trace：好像是叫這個名字吧，監控平台，這個比較早就有了，用來監控各個業務線頁面的運行狀況並搜集各種用戶數據，如解析度，UA
我看來 def 和 dip 對阿里前端的作用會更大些，uitest 估計作用一般，阿里前端是不注重代碼質量的，測試用例也僅在幾個重要的直接影響交易的業務線會寫。
【許文敏的回答(0票)】:
確實不錯，從職責上來區分前後端分離才是王道，nodejs將成為前端工程師的基礎技能
【獵人豆豆的回答(0票)】:
不要把簡單的問題搞復雜，對於淘寶這樣規模的公司，有些牽一發而動全身的改動，最好是在權衡風險和收益後再決定，我們是技術的使用者，而不要被技術牽著鼻子走.
【羅正燁的回答(2票)】:
前面前端的大牛們都說了，我換個角度聊聊。
這么講吧，阿里的前端為什麼比其它公司走的遠，是因為他們有很多前端，還有很多不用寫大量業務邏輯的前端大牛。大牛的作用，就是折騰。阿里的前端工程師水平在自身領域實踐上已經跟得上後端。
但這個架構所謂的分離，其實是把很多原來前端不需要做的事攬到了自己的手上，增加前端架構師的KPI，讓前端做了更多的事，周報好寫。因為nodejs和前端都是js，所以學習成本並不算高，但是對一個技術人員的要求是比原來更高了。
但是，他們團隊有很多HC，有很多錢。。所以像我這種一個產品線只有一二個前端的，要是這么玩兒，招人跟不上不說，然後還可以把自己累死。
所以技術選型和架構這種事，還是要根據自己團隊的能力和招人啊。
F. 淘寶網上的主頁模板怎麼做
淘寶網 旺鋪模板 分很多種 不知道你說的是一下那種？
1.描述模板
2.店招模板
3.分類模板
4.促銷區模板
5.公告模板
製作這些模板需要使用平面設置軟體！
而且需要把製作好的模板轉換成HTML源文件才可以使用！
G. 淘寶的寶貝詳情頁面的模板怎麼製作，
做好圖片到
DW軟體做代碼生成，填到詳情頁後台ok
H. 淘寶店鋪什麼是模板
模板就是一系列裝飾模板素材等，讓店鋪裝扮的更加專業大方美觀，從而能夠增加客戶的購買欲，裝修模板主要分為：店招模板、導航欄模塊、輪播、右側模板、自定義模板、寶貝推薦模板、 左側模板、 寶貝描述模板和其他的功能模塊。
I. 什麼是淘寶SDK模板
目前所說的SDK模板主要是針對淘寶店鋪裝修的一種高級模板的統稱，是有別於CSS模板的，基於淘寶提供給設計師一個sdk()，設計師在這個開發包上設計出的模板，就是淘寶Sdk高級模板。
SDK模版不足之處
1、高級模板呈現出來的界面，是由專業前端設計師設計的，賣家不能自由布局。
2、模板升級的時候，模板有時會部分初始化，初始化是什麼意思呢？就是升級後有的放好圖片和商品的地方，又變回了沒裝修時的樣子！
3、有些情況下由於設計師的考慮不足，會導致在某些瀏覽器中頁面模塊變形、錯亂等問題。賣家在使用新模板的時候需要注意做好當前數據備份，以免發生意外情況。
J. 淘寶模板如何使用
淘寶店鋪想要在銷售方面做到更好，那對於店鋪裝修來說是非常有必要的，其中淘寶模板對店鋪設置來說是其中關鍵的重要因素之一，本身在淘寶上面的網店購物過程就是一個比較虛擬的過程，所以我們在開網店的時候更要注意直觀感受。那麼淘寶模板的使用方式是怎樣的?下面魚爪網小編和大家了解一下。
淘寶模版的使用方式是怎樣的?
1、淘寶模版可以自行從網上下載，也可以自己設計，這里演示的模版來源於網路，淘寶店鋪是專門版，基礎版的用戶可能不能實現某些功能。可以通過查看店鋪裝修裡面左上角來獲取自己店鋪的版本。
2、使用PS打開下載來的模版，修改裡面的圖片，將自己產品的圖片替換掉模版里的圖片，然後使用切片工具對模版進去裁剪。
3、打開淘寶「賣家中心」里的「圖片空間」，將之前切片的圖片上傳到圖片空間，並將圖片鏈接復制下來。
4、打開dreamweaver，使用插入圖片打開之前切片的圖片，在「設計頁面」使用左下角的矩形熱點工具在合適的位置繪制矩形框，在「代碼頁面」修改圖片的地址為之前圖片空間復制來的鏈接地址。然後復制代碼。
5、進入「賣家中心」的「店鋪裝修」，將左邊的「自定義模塊"拉到右邊，並添加代碼。在dreamweaver那復制的代碼前面添加下面的代碼可以實現全屏效果。
6、貼好代碼後，選擇「使用編輯器」，返回到編輯模式，這個時候，整個寶貝模版就出現了。 注意：在編輯模式中，寶貝模版可能顯示不正確，比如有走形，裂縫等等，這些都不要緊，在發布之後顯示出來就不會這樣。
7、關於文字輸寫比如現在我們要編輯寶貝描述，將滑鼠點擊寶貝展示下面的空白區域，將會出現游標，這個時候你就可以進行編輯寫入了。其他如寶貝詳情，等等也是如此編輯，依樣畫葫蘆就可以。
以上是魚爪網小編和大家分享淘寶模版的使用方式是怎樣的相關內容，可見淘寶模板的使用方式非常簡單，可以從模板上自行下載也可以自己設計，但是在這方面也需要有一定經驗，才可以做到更好的效果。如果商家在這方面並不是特別精通，可以選擇專門代理公司進行處理。有相關問題可以來魚爪網咨詢我們。