如何快速搭建开放、多租户的电商云平台
起源于20世紀(jì)70年代的電子商務(wù)，如今在全世界的發(fā)展可以說如火如荼，不斷推陳出新;當(dāng)下國內(nèi)家居、零售、餐飲等傳統(tǒng)行業(yè)也相繼搭建自己的電商平臺(tái)，憑借著多年積累的扎實(shí)的資金與地面部隊(duì)、線下運(yùn)營推廣的實(shí)力，結(jié)合O2O模式，逐步在電商領(lǐng)域發(fā)力!
隨著越來越多的實(shí)力派企業(yè)向電商領(lǐng)域進(jìn)軍，技術(shù)上如何快速搭建符合行業(yè)特點(diǎn)，有利于企業(yè)快速試水，同時(shí)便于后續(xù)可持續(xù)發(fā)展的電商平臺(tái)，成為了關(guān)鍵的技術(shù)支撐需求。
如何在兩個(gè)月時(shí)間內(nèi)，迅速搭建類似京東、亞馬遜、淘寶、卓越、當(dāng)當(dāng)?shù)碾娚唐脚_(tái)?需要從繁雜的電商業(yè)務(wù)系統(tǒng)中找到主流，需要借助開放的力量快速豐富和完善功能;而且，我們不能陷入為每家企業(yè)單獨(dú)打造獨(dú)立平臺(tái)的泥潭，這就需要多租戶與定制化。
要實(shí)現(xiàn)B2C電商平臺(tái)必須具備的所有功能，包括賣場(chǎng)、商品、用戶、社區(qū)、基礎(chǔ)設(shè)施、促銷價(jià)格、交易、訂單、支付、虛擬資產(chǎn)、供應(yīng)鏈、倉儲(chǔ)、配送、財(cái)務(wù)、客服售后以及移動(dòng)App等系統(tǒng)，還要滿足一定的性能要求，使系統(tǒng)具備一定量級(jí)的用戶服務(wù)能力，防攻擊能力和內(nèi)容分發(fā)效率，同時(shí)還要具備一定的可擴(kuò)展性，為將來的升級(jí)擴(kuò)容做準(zhǔn)備。
從尋找產(chǎn)品、各種信息比較、訂購、付款、送貨到消費(fèi)者服務(wù)和支持，構(gòu)成電子商務(wù)的基本流程，我們需要根據(jù)必須的信息流、資金流和物流，對(duì)必須實(shí)現(xiàn)的模塊進(jìn)行篩選，以滿足基本可用的電商平臺(tái)需求。以賣場(chǎng)、移動(dòng)、商品和用戶系統(tǒng)為例，電商平臺(tái)基本的業(yè)務(wù)架構(gòu)見圖1;抓主“流”，無招勝有招，不受常規(guī)完整性限制，就大膽邁出了快速搭建電商云平臺(tái)的第一步。
圖1 電商平臺(tái)業(yè)務(wù)架構(gòu)
即便如此，要做到這些基本的功能模塊，不僅需要對(duì)電商業(yè)務(wù)非常熟悉，包括訂單管道、拆分、暫停、轉(zhuǎn)移、鎖定、下傳等正向流程，訂單取消、重拆分、病單拉回、退款等逆向流程，以及開票業(yè)務(wù)、供應(yīng)鏈業(yè)務(wù)、銷售、支付處理、出入庫等流程，還需要在技術(shù)上設(shè)計(jì)出一套綜合考慮各種因素的，非常合理的技術(shù)架構(gòu)，使得整個(gè)電商平臺(tái)具備良好的技術(shù)指標(biāo)，滿足高性能、高可用、高并發(fā)、低成本的要求，還具備良好的可擴(kuò)展性，這一點(diǎn)很重要，否則就是不計(jì)后果的野蠻開發(fā)。
首先，綜合業(yè)務(wù)與技術(shù)方面的考慮，這個(gè)平臺(tái)必須是開放的。
業(yè)務(wù)上，開放，可以借力ISV和有開發(fā)能力的租戶。每個(gè)企業(yè)都有自己的ERP系統(tǒng)，要實(shí)現(xiàn)最后一公里的無縫對(duì)接，完全依靠平臺(tái)的技術(shù)力量是不夠的。這個(gè)時(shí)候如果把平臺(tái)的業(yè)務(wù)能力開放出來，提供足夠細(xì)粒度的API，ISV或有開發(fā)能力的租戶就可以自行實(shí)現(xiàn)業(yè)務(wù)對(duì)接，并持續(xù)更新。隨著業(yè)務(wù)的復(fù)雜，越來越多的需求會(huì)使平臺(tái)開發(fā)者難以應(yīng)對(duì)，而ISV和租戶本身對(duì)自己的需求的理解是最貼切的，可以利用他們的力量，同時(shí)并行開發(fā)多個(gè)服務(wù)，只有這樣才能快速豐富電商平臺(tái)的服務(wù)，并確保這些服務(wù)的實(shí)用性。
技術(shù)上，完全依靠平臺(tái)開發(fā)者的力量，初期維護(hù)幾十上百個(gè)接口還可以，隨著服務(wù)的增加，就只有依賴一套自動(dòng)化的工具和平臺(tái)，實(shí)現(xiàn)服務(wù)的輕量化。
眾多服務(wù)的穩(wěn)定性問題必然在服務(wù)輕量化以后對(duì)整個(gè)平臺(tái)的穩(wěn)定性問題帶來明顯的影響，這就需要從服務(wù)入手解決平臺(tái)的穩(wěn)定性問題。包括將Http服務(wù)異步化，使用事件驅(qū)動(dòng)減少線程等待，通過虛擬隔離線程池將過度占用資源的業(yè)務(wù)排隊(duì)，從而限定不同的業(yè)務(wù)所占用的資源等。
與此同時(shí)，還需要解決質(zhì)量保障的問題。眾多的ISV開發(fā)能力參差不齊，項(xiàng)目管理能力和開發(fā)風(fēng)格也不盡相同，我們不僅需要制定一批規(guī)范，約定服務(wù)展現(xiàn)方式，包括窗口大小、ICON大小，顏色風(fēng)格等;還需要制定完善的評(píng)審與上線流程，對(duì)于不同的服務(wù)，要求提交不同級(jí)別的測(cè)試報(bào)告。我們鼓勵(lì)所有ISV服務(wù)都布署到云鼎或云擎平臺(tái)，以便更好的管理并保障服務(wù)的穩(wěn)定性和可用性。
以上這些都是根據(jù)用戶需求和技術(shù)的需要，順理成章。在解決了API的開放可用，以及基于開放API開發(fā)的服務(wù)的正確性和穩(wěn)定性之后，我們需要一個(gè)服務(wù)市場(chǎng)供用戶挑選和定制。隨著服務(wù)的日益增多，我們的平臺(tái)用戶可能不知道自己已經(jīng)購買的服務(wù)放到哪里去了，對(duì)于同一類服務(wù)，比如賣場(chǎng)、購物車、商品管理或交易管理，有多家ISV開發(fā)的多個(gè)服務(wù)，用戶不知道該選用哪一個(gè)。這個(gè)時(shí)候就需要把這些服務(wù)在用戶的桌面上聚合起來，便于用戶查找和使用服務(wù)，引導(dǎo)用戶使用更優(yōu)秀的服務(wù)。尤其對(duì)于租戶，可以提供Mobile Phone、Pad、WebBrowser、PC，包括Windows、Linux、MacOS、Android、iOS全平臺(tái)跨OS的開放系統(tǒng)(架構(gòu)見圖2)。
圖2 開放系統(tǒng)架構(gòu)圖
對(duì)于商家，可以通過Web、PC和移動(dòng)端訪問開放系統(tǒng)和其中由ISV開發(fā)的商品、交易、數(shù)據(jù)分析類應(yīng)用;對(duì)于ISV可以通過Web訪問管理站點(diǎn);對(duì)于開放系統(tǒng)運(yùn)營商則可以通過Web訪問運(yùn)營后臺(tái)，進(jìn)行ISV注冊(cè)用戶的維護(hù)、服務(wù)的審核等。
在Web、PC與移動(dòng)端，開放系統(tǒng)通過一個(gè)殼將ISV開發(fā)的各類插件性質(zhì)的服務(wù)聚合到一起實(shí)行統(tǒng)一管理和消息傳遞;這個(gè)殼和各個(gè)服務(wù)將調(diào)用服務(wù)器API，通過官方SDK、第三方SDK或直接調(diào)用開放系統(tǒng)API、第三方API，并在規(guī)范的開發(fā)框架下完成服務(wù)功能的實(shí)現(xiàn)。
所有API依賴于平臺(tái)運(yùn)營商和第三方提供的數(shù)據(jù)，建立在云平臺(tái)基礎(chǔ)之上。
接著，多租戶模型的設(shè)計(jì)是必須面臨的技術(shù)問題。不是說如何實(shí)現(xiàn)多租戶，多租戶模型已經(jīng)是非常成熟的技術(shù)，已經(jīng)有類似Salesforce這類的成熟應(yīng)用將其實(shí)踐到極致;這里面臨的是如何在短時(shí)間內(nèi)，快速搭建的電商平臺(tái)中設(shè)計(jì)多租戶模型，兼顧系統(tǒng)功能與開發(fā)效率，同時(shí)具備良好的系統(tǒng)可擴(kuò)展性。
通常，多租戶模型，一個(gè)實(shí)例服務(wù)一個(gè)租戶(企業(yè)用戶)，通過創(chuàng)建不同的實(shí)例來實(shí)現(xiàn)服務(wù)的虛擬和自動(dòng)擴(kuò)展。與虛擬化技術(shù)最大的不同在于，虛擬化主要是指虛擬主機(jī)、內(nèi)存等資源。
按照多租戶模型，如圖3所示，我們應(yīng)該在AppLayer動(dòng)態(tài)創(chuàng)建多個(gè)實(shí)例，分別服務(wù)于不同的租戶;如果是單實(shí)例同時(shí)服務(wù)于多個(gè)企業(yè)用戶，可以稱之為多用戶模式，在這種模式下，用戶登錄時(shí)通常需要選擇企業(yè)名稱或ID;在DataLayer通常采用共享數(shù)據(jù)庫實(shí)例、共享表的方式存儲(chǔ)多租戶的數(shù)據(jù)。
圖3 多租戶網(wǎng)絡(luò)架構(gòu)
應(yīng)用層如圖4所示，通常在一個(gè)應(yīng)用集群運(yùn)行著多個(gè)應(yīng)用實(shí)例，應(yīng)用的實(shí)例將根據(jù)租戶注冊(cè)情況動(dòng)態(tài)創(chuàng)建，根據(jù)用戶使用情況動(dòng)態(tài)調(diào)整和管理資源使用。
圖4 多租戶應(yīng)用層架構(gòu)
多租戶模型所創(chuàng)建的多個(gè)實(shí)例是需要自動(dòng)部署的，這就對(duì)系統(tǒng)的自服務(wù)能力提出了要求，在短期內(nèi)有兩種方案可以考慮。
一種是依賴云鼎、云擎平臺(tái)，先實(shí)現(xiàn)多用戶的方案，利用云鼎、云擎平臺(tái)自動(dòng)生成數(shù)據(jù)庫實(shí)例。在企業(yè)用戶少的情況下，是有利于快速搭建電商平臺(tái)的。結(jié)合開放的需求，需要實(shí)現(xiàn)并開放基礎(chǔ)的API、定制功能的API以及由定制功能生成的API(可分步驟實(shí)施)。
一種是暫時(shí)多租戶共用實(shí)例。
如圖5到圖8所示，數(shù)據(jù)層通常有A、B、C、D四種架構(gòu)，實(shí)現(xiàn)難度逐步增加，對(duì)開發(fā)團(tuán)隊(duì)的技術(shù)要求越來越高，租戶定制功能的靈活度也由低到高。
圖5 多租戶數(shù)據(jù)層架構(gòu)A
在私有庫模式下，為每個(gè)租戶單獨(dú)創(chuàng)建一個(gè)數(shù)據(jù)庫實(shí)例(或在一個(gè)數(shù)據(jù)庫實(shí)例中創(chuàng)建多個(gè)數(shù)據(jù)庫，這里將這種折中的模式歸入此類)，每個(gè)實(shí)例中運(yùn)行著一套完整的業(yè)務(wù)表，在數(shù)據(jù)庫內(nèi)部，跟單租戶系統(tǒng)沒有任何區(qū)別。
圖6 多租戶數(shù)據(jù)層架構(gòu)B
在私有表的模式下，每個(gè)租戶將共享一個(gè)數(shù)據(jù)庫實(shí)例，但在數(shù)據(jù)庫實(shí)例內(nèi)部，為每個(gè)租戶創(chuàng)建一套完整的業(yè)務(wù)數(shù)據(jù)表。
圖7 多租戶數(shù)據(jù)層架構(gòu)C
在擴(kuò)展表模式下，基本表將負(fù)責(zé)每個(gè)租戶獨(dú)立數(shù)據(jù)的獨(dú)享存儲(chǔ)，擴(kuò)展表將使用租戶ID共享存儲(chǔ)所有租戶的定制數(shù)據(jù)，擴(kuò)展表的字段類型通常是固定的。這種模式通常也采用私有元數(shù)據(jù)表、共享擴(kuò)展表的方式來存放數(shù)據(jù)。
圖8 多租戶數(shù)據(jù)層架構(gòu)D
在共享表(通用表或公有表)模式下，大量的表中存放著多個(gè)租戶的數(shù)據(jù)，通過租戶ID來區(qū)分和隔離，對(duì)于定制化的信息通常采用統(tǒng)一類型(如varchar)的稀疏列;由于存放了所有租戶的數(shù)據(jù)，數(shù)據(jù)表和數(shù)據(jù)庫的數(shù)據(jù)量都會(huì)很大，通常需要使用散列分區(qū)技術(shù)的大數(shù)據(jù)庫系統(tǒng)。
從實(shí)現(xiàn)角度，實(shí)現(xiàn)最快的模式是應(yīng)用層多用戶+數(shù)據(jù)層A架構(gòu)，次快的模式是應(yīng)用層多租戶+數(shù)據(jù)層A架構(gòu)，效果最理想的是應(yīng)用層多租戶+數(shù)據(jù)層D架構(gòu)。
數(shù)據(jù)庫表的設(shè)計(jì)時(shí)，租戶ID的設(shè)定，要有全局唯一的ID，每個(gè)租戶的數(shù)據(jù)ID(如訂單ID)要能夠獨(dú)立從1開始展現(xiàn)。
如果為了避免聯(lián)合主鍵(聯(lián)合查詢，SQL語句會(huì)非常麻煩)，可以考慮“7位租戶ID+11位數(shù)據(jù)ID”(數(shù)字或字符)，展現(xiàn)時(shí)取出后面11位的展現(xiàn)，同時(shí)存放租戶ID方便應(yīng)用使用。
如果更多的照顧到使用方便，可以使用租戶ID與數(shù)據(jù)ID分開設(shè)計(jì)，以SKU-Price為例，如圖9所示。
圖9 租戶ID的設(shè)計(jì)實(shí)例
定制可以先支持Logo、首頁商品推薦區(qū)名稱的設(shè)置、推薦商品的設(shè)置等，后期逐步結(jié)合模板實(shí)現(xiàn)復(fù)雜的UI(顏色、字體、布局等)、表格、業(yè)務(wù)流程和權(quán)限定制。
不同租戶的定制功能涉及到開發(fā)量，不可能做到極致，解決的辦法，一方面是依賴租戶自身的開發(fā)力量，一方面是依賴ISV的力量，結(jié)合開放的需求，需要開放元數(shù)據(jù)表、數(shù)據(jù)表、透視表組合邏輯等(可分步驟實(shí)施)。
解決了基礎(chǔ)數(shù)據(jù)問題，在UI和流程定制方面，需要制定一套完善的依賴模板的定制方案，如圖10所示，是以Android系統(tǒng)為例的定制流程。
圖10 模板定制流程
不妨自定義一套URI格式協(xié)議，包括協(xié)議頭、host和activity名稱和參數(shù)等信息，比如：“ecc://com.jd.eCloud/index=activityName?p1=v1&p2=v2”，在URIRequest中，與ISV約定根據(jù)協(xié)議寫死地址，客戶端只保留一套模板html頁，從而實(shí)現(xiàn)不同的租戶看到不同的展現(xiàn)。
另外，在開發(fā)組織與項(xiàng)目團(tuán)隊(duì)的管理方式上也需要輔助使用一定的方法和技巧。傳統(tǒng)的走正步形式的瀑布開發(fā)模型一定不適合快速搭建的需要。
看板方式，把工作細(xì)分成任務(wù)，寫在卡紙上，貼在墻上，把欄命名好，來顯示任務(wù)在工作流程中的狀況。
XP敏捷開發(fā)的Scrum模型兼具了多重優(yōu)點(diǎn)，是比較常用的方法。
把來自各個(gè)職能部門的產(chǎn)品、開發(fā)和測(cè)試人員聚到一起，分成不同的開發(fā)小組，把工作細(xì)分成細(xì)小、實(shí)在的交付成果，安排人員負(fù)責(zé)需求清單以及跟據(jù)重要性排優(yōu)先級(jí)別，由團(tuán)隊(duì)估算每個(gè)項(xiàng)目相對(duì)工量。
把整個(gè)開發(fā)時(shí)間分成固定時(shí)長的短迭代(通常一至四周)，在每個(gè)迭代后演示新增可發(fā)布功能。
每個(gè)迭代中，ScrumMaster負(fù)責(zé)召開PlanMeeting，按照PO提出的優(yōu)先級(jí)制定Sprint目標(biāo)，創(chuàng)建SprintBacklog，以UserStory的方式分解成MVP功能點(diǎn)，估算工作量，承諾，生成故事卡、任務(wù)卡并上墻，開始維護(hù)BurndownChart，并定期召開SOS。
每個(gè)迭代發(fā)布后，經(jīng)過評(píng)審，優(yōu)化發(fā)布以及跟產(chǎn)品一起更新優(yōu)先級(jí)別。
每個(gè)迭代發(fā)布后，進(jìn)行回顧，優(yōu)化過程。選用vagrant開發(fā)環(huán)境，可選ci/svn版本控制，通過cctray持續(xù)集成，通過代碼賭場(chǎng)等活動(dòng)提高代碼質(zhì)量。
如此快速搭建的電商平臺(tái)，這里就關(guān)鍵幾個(gè)架構(gòu)問題和項(xiàng)目問題以及業(yè)務(wù)問題進(jìn)行了討論，具體在實(shí)施中如何在基礎(chǔ)設(shè)施到網(wǎng)絡(luò)架構(gòu)方面做到高性能、高并發(fā)、高可用、高擴(kuò)展、低成本，可以在單獨(dú)的主題中進(jìn)一步詳細(xì)討論。
http://www.csdn.net/article/a/2014-01-02/15817757
轉(zhuǎn)載于:https://www.cnblogs.com/heidsoft/p/3511493.html
總結(jié)
以上是生活随笔為你收集整理的如何快速搭建开放、多租户的电商云平台的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Vue学习笔记（2）（组件化开发）
- 下一篇： spring Quartz cron表达