起源于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持續集成，通過代碼賭場等活動提高代碼質量。

 

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