田盛：目前就職于京東，主要從事京東商城營運活動搭建平台（通天塔）可視化配置層的架構設計與開發工作。熟悉前端多種開發架構，對大型軟體及平台的設計和開發之道有一定的認識，在Web開發，架構優化，工程品質及可持續建設有較豐富的實戰經驗。目前主要緻力于平台的優化及新技術的探索運用等工作。
一、背景
通天塔是京東商城内部提供給營運，用以快速搭建活動頁面的平台，自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實作一份代碼多端複用