如何快速搭建開放、多租戶的電商雲平臺

起源於20世紀70年代的電子商務，現在在全世界的發展能夠說如火如荼，不斷推陳出新;當下國內家居、零售、餐飲等傳統行業也相繼搭建本身的電商平臺，憑藉着多年積累的紮實的資金與地面部隊、線下運營推廣的實力，結合O2O模式，逐步在電商領域發力!

隨着愈來愈多的實力派企業向電商領域進軍，技術上如何快速搭建符合行業特色，有利於企業快速試水，同時便於後續可持續發展的電商平臺，成爲了關鍵的技術支撐需求。

如何在兩個月時間內，迅速搭建相似京東、亞馬遜、淘寶、卓越、噹噹的電商平臺?須要從繁雜的電商業務系統中找到主流，須要藉助開放的力量快速豐富和完善功能;並且，咱們不能陷入爲每家企業單獨打造獨立平臺的泥潭，這就須要多租戶與定製化。

要實現B2C電商平臺必須具有的全部功能，包括賣場、商品、用戶、社區、基礎設施、促銷價格、交易、訂單、支付、虛擬資產、供應鏈、倉儲、配送、財務、客服售後以及移動App等系統，還要知足必定的性能要求，使系統具有必定量級的用戶服務能力，防攻擊能力和內容分發效率，同時還要具有必定的可擴展性，爲未來的升級擴容作準備。

從尋找產品、各類信息比較、訂購、付款、送貨到消費者服務和支持，構成電子商務的基本流程，咱們須要根據必須的信息流、資金流和物流，對必須實現的模塊進行篩選，以知足基本可用的電商平臺需求。以賣場、移動、商品和用戶系統爲例，電商平臺基本的業務架構見圖1;抓主「流」，無招勝有招，不受常規完整性限制，就大膽邁出了快速搭建電商雲平臺的第一步。

圖1 電商平臺業務架構

即使如此，要作到這些基本的功能模塊，不只須要對電商業務很是熟悉，包括訂單管道、拆分、暫停、轉移、鎖定、下傳等正向流程，訂單取消、重拆分、病單拉回、退款等逆向流程，以及開票業務、供應鏈業務、銷售、支付處理、出入庫等流程，還須要在技術上設計出一套綜合考慮各類因素的，很是合理的技術架構，使得整個電商平臺具有良好的技術指標，知足高性能、高可用、高併發、低成本的要求，還具有良好的可擴展性，這一點很重要，不然就是不計後果的野蠻開發。

首先，綜合業務與技術方面的考慮，這個平臺必須是開放的。

業務上，開放，能夠借力ISV和有開發能力的租戶。每一個企業都有本身的ERP系統，要實現最後一千米的無縫對接，徹底依靠平臺的技術力量是不夠的。這個時候若是把平臺的業務能力開放出來，提供足夠細粒度的API，ISV或有開發能力的租戶就能夠自行實現業務對接，並持續更新。隨着業務的複雜，愈來愈多的需求會使平臺開發者難以應對，而ISV和租戶自己對本身的需求的理解是最貼切的，能夠利用他們的力量，同時並行開發多個服務，只有這樣才能快速豐富電商平臺的服務，並確保這些服務的實用性。

技術上，徹底依靠平臺開發者的力量，初期維護幾十上百個接口還能夠，隨着服務的增長，就只有依賴一套自動化的工具和平臺，實現服務的輕量化。

衆多服務的穩定性問題必然在服務輕量化之後對整個平臺的穩定性問題帶來明顯的影響，這就須要從服務入手解決平臺的穩定性問題。包括將Http服務異步化，使用事件驅動減小線程等待，經過虛擬隔離線程池將過分佔用資源的業務排隊，從而限定不一樣的業務所佔用的資源等。

與此同時，還須要解決質量保障的問題。衆多的ISV開發能力良莠不齊，項目管理能力和開發風格也不盡相同，咱們不只須要制定一批規範，約定服務展示方式，包括窗口大小、ICON大小，顏色風格等;還須要制定完善的評審與上線流程，對於不一樣的服務，要求提交不一樣級別的測試報告。咱們鼓勵全部ISV服務都佈署到雲鼎或雲擎平臺，以便更好的管理並保障服務的穩定性和可用性。

以上這些都是根據用戶需求和技術的須要，瓜熟蒂落。在解決了API的開放可用，以及基於開放API開發的服務的正確性和穩定性以後，咱們須要一個服務市場供用戶挑選和定製。隨着服務的日益增多，咱們的平臺用戶可能不知道本身已經購買的服務放到哪裏去了，對於同一類服務，好比賣場、購物車、商品管理或交易管理，有多家ISV開發的多個服務，用戶不知道該選用哪個。這個時候就須要把這些服務在用戶的桌面上聚合起來，便於用戶查找和使用服務，引導用戶使用更優秀的服務。尤爲對於租戶，能夠提供Mobile Phone、Pad、WebBrowser、PC，包括Windows、Linux、MacOS、Android、iOS全平臺跨OS的開放系統(架構見圖2)。

圖2 開放系統架構圖

對於商家，能夠經過Web、PC和移動端訪問開放系統和其中由ISV開發的商品、交易、數據分析類應用;對於ISV能夠經過Web訪問管理站點;對於開放系統運營商則能夠經過Web訪問運營後臺，進行ISV註冊用戶的維護、服務的審覈等。

在Web、PC與移動端，開放系統經過一個殼將ISV開發的各種插件性質的服務聚合到一塊兒實行統一管理和消息傳遞;這個殼和各個服務將調用服務器API，經過官方SDK、第三方SDK或直接調用開放系統API、第三方API，並在規範的開發框架下完成服務功能的實現。

全部API依賴於平臺運營商和第三方提供的數據，創建在雲平臺基礎之上。

接着，多租戶模型的設計是必須面臨的技術問題。不是說如何實現多租戶，多租戶模型已是很是成熟的技術，已經有相似Salesforce這類的成熟應用將其實踐到極致;這裏面臨的是如何在短期內，快速搭建的電商平臺中設計多租戶模型，兼顧系統功能與開發效率，同時具有良好的系統可擴展性。

一般，多租戶模型，一個實例服務一個租戶(企業用戶)，經過建立不一樣的實例來實現服務的虛擬和自動擴展。與虛擬化技術最大的不一樣在於，虛擬化主要是指虛擬主機、內存等資源。

按照多租戶模型，如圖3所示，咱們應該在AppLayer動態建立多個實例，分別服務於不一樣的租戶;若是是單實例同時服務於多個企業用戶，能夠稱之爲多用戶模式，在這種模式下，用戶登陸時一般須要選擇企業名稱或ID;在DataLayer一般採用共享數據庫實例、共享表的方式存儲多租戶的數據。

圖3 多租戶網絡架構

應用層如圖4所示，一般在一個應用集羣運行着多個應用實例，應用的實例將根據租戶註冊狀況動態建立，根據用戶使用狀況動態調整和管理資源使用。

圖4 多租戶應用層架構

多租戶模型所建立的多個實例是須要自動部署的，這就對系統的自服務能力提出了要求，在短時間內有兩種方案能夠考慮。

一種是依賴雲鼎、雲擎平臺，先實現多用戶的方案，利用雲鼎、雲擎平臺自動生成數據庫實例。在企業用戶少的狀況下，是有利於快速搭建電商平臺的。結合開放的需求，須要實現並開放基礎的API、定製功能的API以及由定製功能生成的API(可分步驟實施)。

一種是暫時多租戶共用實例。

如圖5到圖8所示，數據層一般有A、B、C、D四種架構，實現難度逐步增長，對開發團隊的技術要求愈來愈高，租戶定製功能的靈活度也由低到高。

圖5 多租戶數據層架構A

在私有庫模式下，爲每一個租戶單首創建一個數據庫實例(或在一個數據庫實例中建立多個數據庫，這裏將這種折中的模式納入此類)，每一個實例中運行着一套完整的業務表，在數據庫內部，跟單租戶系統沒有任何區別。

圖6 多租戶數據層架構B

在私有表的模式下，每一個租戶將共享一個數據庫實例，但在數據庫實例內部，爲每一個租戶建立一套完整的業務數據表。

圖7 多租戶數據層架構C

在擴展表模式下，基本表將負責每一個租戶獨立數據的獨享存儲，擴展表將使用租戶ID共享存儲全部租戶的定製數據，擴展表的字段類型一般是固定的。這種模式一般也採用私有元數據表、共享擴展表的方式來存放數據。

圖8 多租戶數據層架構D

在共享表(通用表或公有表)模式下，大量的表中存放着多個租戶的數據，經過租戶ID來區分和隔離，對於定製化的信息一般採用統一類型(如varchar)的稀疏列;因爲存放了全部租戶的數據，數據表和數據庫的數據量都會很大，一般須要使用散列分區技術的大數據庫系統。

從實現角度，實現最快的模式是應用層多用戶+數據層A架構，次快的模式是應用層多租戶+數據層A架構，效果最理想的是應用層多租戶+數據層D架構。

數據庫表的設計時，租戶ID的設定，要有全局惟一的ID，每一個租戶的數據ID(如訂單ID)要可以獨立從1開始展示。

若是爲了不聯合主鍵(聯合查詢，SQL語句會很是麻煩)，能夠考慮「7位租戶ID+11位數據ID」(數字或字符)，展示時取出後面11位的展示，同時存放租戶ID方便應用使用。

若是更多的照顧到使用方便，可使用租戶ID與數據ID分開設計，以SKU-Price爲例，如圖9所示。

圖9 租戶ID的設計實例

定製能夠先支持Logo、首頁商品推薦區名稱的設置、推薦商品的設置等，後期逐步結合模板實現複雜的UI(顏色、字體、佈局等)、表格、業務流程和權限定製。

不一樣租戶的定製功能涉及到開發量，不可能作到極致，解決的辦法，一方面是依賴租戶自身的開發力量，一方面是依賴ISV的力量，結合開放的需求，須要開放元數據表、數據表、透視表組合邏輯等(可分步驟實施)。

解決了基礎數據問題，在UI和流程定製方面，須要制定一套完善的依賴模板的定製方案，如圖10所示，是以Android系統爲例的定製流程。

圖10 模板定製流程

不妨自定義一套URI格式協議，包括協議頭、host和activity名稱和參數等信息，好比：「ecc://com.jd.eCloud/index=activityName?p1=v1&p2=v2」，在URIRequest中，與ISV約定根據協議寫死地址，客戶端只保留一套模板html頁，從而實現不一樣的租戶看到不一樣的展示。

另外，在開發組織與項目團隊的管理方式上也須要輔助使用必定的方法和技巧。傳統的走正步形式的瀑布開發模型必定不適合快速搭建的須要。

看板方式，把工做細分紅任務，寫在卡紙上，貼在牆上，把欄命名好，來顯示任務在工做流程中的情況。

XP敏捷開發的Scrum模型兼具了多重優勢，是比較經常使用的方法。

把來自各個職能部門的產品、開發和測試人員聚到一塊兒，分紅不一樣的開發小組，把工做細分紅細小、實在的交付成果，安排人員負責需求清單以及跟據重要性排優先級別，由團隊估算每一個項目相對工量。

把整個開發時間分紅固定時長的短迭代(一般一至四周)，在每一個迭代後演示新增可發佈功能。

每一個迭代中，ScrumMaster負責召開PlanMeeting，按照PO提出的優先級制定Sprint目標，建立SprintBacklog，以UserStory的方式分解成MVP功能點，估算工做量，承諾，生成故事卡、任務卡並上牆，開始維護BurndownChart，並按期召開SOS。

每一個迭代發佈後，通過評審，優化發佈以及跟產品一塊兒更新優先級別。

每一個迭代發佈後，進行回顧，優化過程。選用vagrant開發環境，可選ci/svn版本控制，經過cctray持續集成，經過代碼賭場等活動提升代碼質量。

如此快速搭建的電商平臺，這裏就關鍵幾個架構問題和項目問題以及業務問題進行了討論，具體在實施中如何在基礎設施到網絡架構方面作到高性能、高併發、高可用、高擴展、低成本，能夠在單獨的主題中進一步詳細討論。

http://www.csdn.net/article/a/2014-01-02/15817757