京東商城活動頁面構建系統——通天塔
一、背景
通天塔是京東商城內部提供給運營，用以快速搭建活動頁面的平臺，自2015年***版上線以來，已歷經多個618和雙十一的考驗。通天塔的誕生是歷史的必然，當業務發展到某一程度，有限的開發人力和冗長的開發流程已無法滿足蓬勃發展的業務需求，而這對電商企業來說尤為明顯，根據部分數據統計，2017年11月JD APP內的日均活動在線量達4000多，雙十一期間日均活動量達到5000~6000，如果完全依靠傳統的開發模式，唯有通過加班來解決。
接下來，我們一起來看看，JD商城體系對于活動搭建平臺的訴求是什么?
二、起點和方向
我們從產品和交互的角度概括的來看下平臺的設計：
- 從產品角度，它的目標用戶是各個事業部的運營，其中也包括事業部中具有開發能力的前端。搭建頁面的操作應該是“傻瓜式”的，即不用懂任何技術相關的知識就能完成一個頁面的搭建，同時我們又不能把系統做的過于封閉，系統仍需開放出一定的入口去支持擴展的功能實現。
- 從交互角度上看，提供一個可視化的頁面編輯平臺是目前比較理想的方案。因為目標用戶大部分是沒有編程基礎的運營，所以整個界面的核心操作就是拖拉和填表，系統底層封裝和實現了模板的拼裝和渲染，數據分發和功能邏輯等，對使用者來說，整個系統是一個黑盒，用戶和系統之間的橋梁就是可視化的操作界面。這種模式的優勢就是保證了系統是穩定且可控的，所有的系統模版都是經過嚴格測試的。
之前有提到過系統不能是封閉的，因為運營會時不時的提出一些個性化的需求，小到某些樣式的更改，大到新功能的實現。一方面部門的開發人力有限，另一方面不是所有的需求都要做進系統內部。
為了滿足這類的需求，系統內要開放出一定的入口，從可視化界面的角度，目前主要是通過自定義模板的方式來實現。因為某些因素(技術棧不統一，外包項目等)，我們向編程人員提供了富裕的自由度，我們沒有限制技術棧的使用，也沒有標準化的接口，系統只負責加載用戶編寫的模塊。當然這種自由度，會帶來一定的風險，據以往使用情況來看，頁面出問題絕大部分的原因是因為自定義代碼導致的。
通天塔是一個頁面搭建平臺，同時也是一個活動發布平臺，用戶可以便捷地點擊發布按鈕更新頁面，那么如何保證頁面上線后的質量和可靠性是需要考慮的問題，包括降低自定義代碼導致的錯誤。
質量包括頁面的內容是否完整，樣式是否正常，數據是否有效等，而可靠性包括頁面不能有白屏，鏈接是否有效，點擊位是否符合預期等。這里面涉及的細節非常多，解決方案概括下來可以歸納以下幾點：
- 保存、發布前檢驗配置信息是否完整、有效(鏈接地址是否可達，優惠券id是否可用等)
- 提供真實的預覽頁面供用戶檢查
- 數據不完整導致樣式受影響時，會過濾相應的樓層
- 靜態降級H5頁用作兜底頁面
- 頁面測速平臺，異常監控平臺提供質量服務
縱觀整個平臺的藍圖，實現開放化是平臺的最終目標。需要開放些什么，怎么開放是我們一直以來思考的問題。目前，我們正在做的是將模板依賴的數據可配置化，第三方數據服務的注冊與接入，制定DSL統一模板定義，封裝基礎組件和基礎服務可供調用，以及JD React的深度集成等。
三、技術詳解
1. 技術選型
可視化的技術選型算中規中矩，用了React相關的全家桶。選用React，一方面是看好社區的發展，一方面也為了能與JD React進行深度集成。
從層次上講，整個系統劃分為Store、UI層、數據處理層、控制層、Service層。UI層是比較輕量的，理想的UI層只需負責界面的顯示，而大部分的業務邏輯我們剝離到了Service層，其中控制層主要負責邏輯的流程控制。
雖然編寫代碼的時候會比較繞，但整個項目的結構會變得非常清晰，對功能進行擴展的時候也非常方便。(備注：圖片源自我在京東Tech Day分享的通天塔平臺重構之思考與架構設計，完整版PPT請戳閱讀原文)
2. 組件結構
整體的結構還是比較簡單的，對于配置面板，我們劃分成通用面板和自定義面板。稍后我們可以看到，對于簡單的配置信息是可以轉化成配置表的形式，配置表的好處是可以通過接口下發，與系統是解耦的。
通用面板負責解析這份配置表，而自定義面板處理復雜業務，實際使用的時候，我們在自定義面板中也會復用通用面板的能力。
3. 模版定義
可視化平臺的基本單位是模板，模板又涉及三個維度：布局，樣式和數據。在可視化層，我們把這三個維度定義成了三份描述文件：
這三份文件最終會被編譯成一個描述模板的json對象，并隨接口下發：
需要說明的是可視化所用的模板和樣式與生成端M頁所用的模板和樣式，不是同一套，目前還是由兩個團隊分別去開發和維護的。目前我們正計劃整合一套模板組件，每個組件內部維護2個狀態(預覽態和真實態)。預覽態用于配置時展示的界面，它不需要事件綁定和復雜的交互，而真實態則對應線上環境。
現在我們來看下模板的三個維度在可視化中是如何處理的：
(1) 布局
布局需要考慮的是與數據的綁定，預覽區對于用戶的輸入需要有反饋，比如更改了一個標題顏色，預覽區是要能夠體現出顏色的變化，這種交互對用戶來說是友好的。
我們設定預覽區的模板是獨立且無交互的，從實現方案來說選擇有很多，考慮開發簡單，且與React融合度好，我們選擇用JSX來寫布局。性能上，我們在包裝組件(viewInstance)中，判斷了數據是否變化，減少了不必要的更新操作。
(2) 樣式
樣式的處理比較簡單，這里就直接貼代碼了。
(3) 數據
數據是可視化平臺的核心，數據層面要考慮的問題主要有以下幾點：
- 配置面板與模板數據之間的關系是什么?
- 數據更新如果實現?
- 數據驗證如何實現?
以往的配置面板都是依靠人力去開發的，即使有健全的組件庫支持，也需要花精力去組裝和調試。我們可以站在更高的層次，把共性的東西抽象出來，比如表單組件與數據的綁定關系，數據更新的邏輯，驗證的邏輯等等，最終的產物就是一份配置描述文件(下右圖)。
有了配置文件，我們還需要一個解析器去實現表單項的生成，這個解析器就是上文中提到的通用面板。
整個數據的更新和驗證也是自動完成的：
四、結論與展望
要真正做好這個系統不易，從系統上線以來，已歷經一次大的技術改版，本文介紹的是改版之后的內容。通過改版，我們解決了一部分的問題，為未來的發展鋪平了道路，但距離期望還有段距離，這里我列舉出未來的規劃方向以供參考：
- 復用模板組件，在組件內部實現預覽態與真實態的切換。
- 模板與可視化系統的解耦
- 建立模板市場
- 依賴jdReact實現一份代碼多端復用
田盛：目前就職于京東，主要從事京東商城運營活動搭建平臺(通天塔)可視化配置層的架構設計與開發工作。熟悉前端多種開發框架，對大型軟件及平臺的設計和開發之道有一定的認識，在Web開發，架構優化，工程質量及可持續建設有較豐富的實戰經驗。目前主要致力于平臺的優化及新技術的探索運用等工作。
【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】
