基于微服務(wù)的手機(jī)銷售商城設(shè)計(jì)與實(shí)現(xiàn)_第1頁(yè)
基于微服務(wù)的手機(jī)銷售商城設(shè)計(jì)與實(shí)現(xiàn)_第2頁(yè)
基于微服務(wù)的手機(jī)銷售商城設(shè)計(jì)與實(shí)現(xiàn)_第3頁(yè)
基于微服務(wù)的手機(jī)銷售商城設(shè)計(jì)與實(shí)現(xiàn)_第4頁(yè)
基于微服務(wù)的手機(jī)銷售商城設(shè)計(jì)與實(shí)現(xiàn)_第5頁(yè)
已閱讀5頁(yè),還剩35頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

(基于微服務(wù)的手機(jī)銷售商城設(shè)計(jì)與實(shí)現(xiàn))(DesignandImplementationofMobileSalesMallBasedonMicroservices)內(nèi)容摘要在互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展下,線上購(gòu)物已經(jīng)成為了人們認(rèn)同并會(huì)選擇的一種購(gòu)物方式。我國(guó)的電子商務(wù)平臺(tái)也取得了令人矚目的成績(jī),不論是數(shù)家公司先后赴美上市,亦或是每年天貓雙11令人吃驚的數(shù)據(jù)記錄,都告示著在線上銷售平臺(tái)上購(gòu)物已經(jīng)逐漸成為民眾的首選消費(fèi)方式。2019年天貓雙11僅使用96秒全球成交額即破100億,這段在短暫時(shí)間下產(chǎn)生了交易巨額的描述下,隱藏著的是對(duì)阿里服務(wù)器的一次次并發(fā)請(qǐng)求。而這也是分布式集群部署微服務(wù)產(chǎn)生并且逐漸取代傳統(tǒng)SOA服務(wù)架構(gòu)的其中一個(gè)原因。微服務(wù)架構(gòu)使得系統(tǒng)的復(fù)雜度可控、易于保持高可維護(hù)性和開(kāi)發(fā)效率。而微服務(wù)架構(gòu)思想與生俱來(lái)對(duì)系統(tǒng)集群的部署具有支持性,確保了系統(tǒng)的水平拓展性以應(yīng)對(duì)高并發(fā)的請(qǐng)求。所以微服務(wù)的技術(shù)思想十分適用于本文手機(jī)銷售系統(tǒng)架構(gòu)的設(shè)計(jì)。該手機(jī)商城銷售系統(tǒng)主要由商城應(yīng)用程序、商城管理系統(tǒng)組成,主要提供完整的購(gòu)物流程和商城信息管理的解決方案。根據(jù)需求,該系統(tǒng)將會(huì)以手機(jī)作為銷售商品,基于分布式的微服務(wù)架構(gòu)而搭建。基于微服務(wù)技術(shù)思想而構(gòu)建的系統(tǒng)底層,保證了系統(tǒng)的高可用性以及拓展性。實(shí)現(xiàn)技術(shù)層面上,本系統(tǒng)可以有實(shí)現(xiàn)有多種方式,包括PHP、Java、GO語(yǔ)言等。本系統(tǒng)所需要的微服務(wù)以及分布式技術(shù),Java技術(shù)體系的解決方案會(huì)相對(duì)成熟和穩(wěn)定、快速,所以本系統(tǒng)的服務(wù)架構(gòu)將采用Java技術(shù)體系構(gòu)建。而手機(jī)銷售商城移動(dòng)應(yīng)用端的開(kāi)發(fā),將會(huì)選擇Flutter作為開(kāi)發(fā)框架,F(xiàn)lutter框架具有的快速、現(xiàn)代、漂亮特點(diǎn)都將會(huì)為該應(yīng)用程序帶來(lái)優(yōu)秀的體驗(yàn)。本文將會(huì)系統(tǒng)介紹如何設(shè)計(jì)基于微服務(wù)技術(shù)所搭建的手機(jī)銷售商城,并為相關(guān)基礎(chǔ)功能的實(shí)現(xiàn)做出論述。關(guān)鍵詞:手機(jī)銷售商稱設(shè)計(jì)與實(shí)現(xiàn);Java;微服務(wù);Flutter;電商;AbstractUnderthecontinuousbackgroundofInternettechnology,onlinesalesmallshavegraduallybeenrecognizedbypeople,andgraduallybecomethefirstconsumptionmethodofthepublic.FormobilephonesalesmerchantswhousetheInternetasthemainsaleschannel,thedesignandimplementationofagoodsalesmallsystembecomesincreasinglyimportant.China'se-commerceplatformshavealsoachievedremarkableresults.WhetherseveralcompanieshavegonepublicintheUnitedStatesortheamazingdatarecordsofTmallDouble11everyyear,theyhaveshownthatshoppingononlinesalesplatformshasgraduallyBecomethepeople'spreferredconsumptionmethod.In2019,TmallDouble11usedonly96secondstoachieveaglobalturnoverof10billion.Underthisdescriptionofahugeamountoftransactionsinashortperiodoftime,thehiddenmultiplerequestsforAliserversarehidden.ThisisalsooneofthereasonsforthedistributedclusterdeploymentofmicroservicesandgraduallyreplacingthetraditionalSOAservicearchitecture.Themicroservicearchitecturemakesthesystem'scomplexitycontrollableandeasytomaintainhighmaintainabilityanddevelopmentefficiency.Theideaofmicroservicearchitectureisinherentlysupportiveofthedeploymentofthesystemcluster,ensuringthehorizontalscalabilityofthesystemtocopewithhighlyconcurrentrequests.Therefore,thetechnicalideaofmicroservicesisveryapplicabletothedesignofthemobilephonesalessystemarchitectureinthispaper.Themobilephonemallsalessystemismainlycomposedofmallapplicationsandmallmanagementsystems,whichmainlyprovidecompleteshoppingprocessandmallinformationmanagementsolutions.Accordingtodemand,thesystemwillusemobilephonesassalesgoodsandbebuiltonadistributedmicroservicesarchitecture.Atthetechnicallevel,thissystemcanbeimplementedinavarietyofways,includingPHP,Java,GO,etc.Themicroservicesanddistributedtechnologiesrequiredbythissystemwillberelativelymature,stable,andfast.Therefore,theservicearchitectureofthissystemwillbeconstructedusingJavatechnology.Forthedevelopmentofmobileapplicationsinthemobilesalesmall,Flutterwillbeselectedasthedevelopmentframework.Thefast,modernandbeautifulfeaturesoftheFlutterframeworkwillbringanexcellentexperiencetotheapplication.Thisarticlewillsystematicallyintroducehowtodesignamobilephonesalesmallbuiltonthebasisofmicroservicetechnology,anddiscusstherealizationofrelatedbasicfunctions.Keywords:Mobilephonevendorsaysdesignandimplementation;Java;Microservice;E-commerce;廣東東軟學(xué)院本科生畢業(yè)設(shè)計(jì)(論文)目錄TOC\h\z\t"標(biāo)題1,2,標(biāo)題2,3,標(biāo)題3,4,標(biāo)題,1"1緒論 緒論國(guó)內(nèi)外發(fā)展現(xiàn)狀微服務(wù)的概念由MartinFowler與JamesLewis在2014年共同進(jìn)行全面講解,此后便得到了IT圈的廣泛關(guān)注,隨著國(guó)內(nèi)外有公司先后發(fā)布大量成功案例后,微服務(wù)思想成為了商業(yè)應(yīng)用程序開(kāi)發(fā)中最熱門的新事物。而在國(guó)內(nèi)的電商領(lǐng)域微服務(wù)概念更是得到了大范圍的支持。阿里巴巴、攜程、當(dāng)當(dāng)網(wǎng)等國(guó)內(nèi)互聯(lián)網(wǎng)領(lǐng)軍公司都在不斷為微服務(wù)發(fā)展開(kāi)源相關(guān)的工具和架構(gòu)。如阿里巴巴的RocketMQ,也已孵化成了Apache的頂級(jí)項(xiàng)目,在國(guó)際的舞臺(tái)上獲得了肯定。在互聯(lián)網(wǎng)技術(shù)發(fā)展的不同時(shí)期都誕生出了不同的熱門銷售商城網(wǎng)站,在國(guó)內(nèi)的平臺(tái)上,從當(dāng)今熱門的拼拼多、蘑菇街、京東網(wǎng)、淘寶網(wǎng)等都可以看出,一個(gè)成功的銷售商城系統(tǒng)需要具有一定的產(chǎn)品特色以及商城定位。而符合社會(huì)潮流和青睞的手機(jī)銷售系統(tǒng)將會(huì)帶來(lái)不可估量的市場(chǎng)前景。但基于微服務(wù)搭建的系統(tǒng)在電商領(lǐng)域仍處于一個(gè)開(kāi)發(fā)和運(yùn)營(yíng)成本相對(duì)高昂的情況,國(guó)內(nèi)電商的平臺(tái)依舊會(huì)依附于淘寶網(wǎng)、京東網(wǎng)。以至于商鋪對(duì)人員的管理、對(duì)商品的管理以及商品銷售的界面產(chǎn)生較大限制。研究背景與意義在互聯(lián)網(wǎng)技術(shù)的不斷的背景下,線上銷售商城逐漸得到了人們的認(rèn)可,并逐漸成為民眾的首先消費(fèi)方式。而對(duì)于以互聯(lián)網(wǎng)作為主要銷售渠道的手機(jī)銷售商家而言,一個(gè)良好的銷售商城系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)愈發(fā)顯得重要。但現(xiàn)市場(chǎng)上關(guān)于手機(jī)銷售系統(tǒng)方案還是較少,至于一套可應(yīng)對(duì)搶購(gòu)并發(fā)并具有良好的拓展性的手機(jī)銷售商城則更是難尋。所以設(shè)計(jì)與實(shí)現(xiàn)一套優(yōu)秀的商城系統(tǒng)方案是本課題的主要目的所在。以軟件工程的角度,從需求分析到設(shè)計(jì)關(guān)于該銷售商城的整體系統(tǒng),并基于SpringCloud微服務(wù)方案實(shí)現(xiàn)所設(shè)計(jì)系統(tǒng)的細(xì)節(jié)。為“微服務(wù)開(kāi)發(fā)電商銷售系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)”這方面的研究做出自己的貢獻(xiàn),并對(duì)未來(lái)銷售商城系統(tǒng)的拓展性、未來(lái)發(fā)展提出自己的期望。2系統(tǒng)開(kāi)發(fā)技術(shù)介紹2.1開(kāi)發(fā)工具與版本工具名稱工具版本IntelliJIDEA2019.3.1WebStorm2019.3.1DataGrip2019.3.12.2系統(tǒng)運(yùn)行環(huán)境中間件運(yùn)行版本JDK1.8.0_221MySQL8.0.17Redis5.0.5MinIo2019-12-30T05:45:39ZNode12.12.0Npm6.13.2Docker19.03.5Maven3.6.1Git2.22.0DartVM2.5.1Flutterv1.9.1+hotfix.6iOS13.12.3開(kāi)發(fā)工具及運(yùn)行環(huán)境相關(guān)介紹2.3.1IntelliJIDEA開(kāi)發(fā)工具IntelliJIDEA(以下簡(jiǎn)稱IDEA)開(kāi)發(fā)工具由JetBrains軟件公司開(kāi)發(fā),誕生的主要目的為一站式解決Java開(kāi)發(fā)的相關(guān)問(wèn)題,后續(xù)也為其他的編程語(yǔ)言拓展支持。該軟體集成了包括Git、Maven、Gradle等開(kāi)發(fā)中常用的工具,且支持以插件的方式拓展開(kāi)發(fā)程序,使得開(kāi)發(fā)者在該款開(kāi)發(fā)工具的幫助下,開(kāi)發(fā)效率大幅度提高,且由于JetBrains公司對(duì)開(kāi)發(fā)者進(jìn)行自定義的插件開(kāi)發(fā)并分享大力支持的緣故,使得IDEA的插件生態(tài)愈發(fā)優(yōu)秀,提高開(kāi)發(fā)效率的插件與開(kāi)發(fā)者之間形成了一個(gè)良好的開(kāi)發(fā)氛圍。IDEA能在眾多的開(kāi)發(fā)工具中脫穎而出,不僅僅是由于插件生態(tài)的良好發(fā)展,開(kāi)發(fā)工具自身的智能化程度也是擊中開(kāi)發(fā)者的一個(gè)要點(diǎn)。只需要按動(dòng)數(shù)個(gè)按鍵,IDEA便會(huì)根據(jù)當(dāng)前代碼的上下文環(huán)境演算出開(kāi)發(fā)者最有可能期待輸入的方法或是參數(shù)。這能使得開(kāi)發(fā)者可以將開(kāi)發(fā)思緒更多的集中在代碼的實(shí)現(xiàn)邏輯,開(kāi)發(fā)效率大幅度提高。2.3.2Redis隨著時(shí)代的發(fā)展,各個(gè)系統(tǒng)中的業(yè)務(wù)邏輯與并發(fā)量都在不停的發(fā)生變化,傳統(tǒng)的數(shù)據(jù)庫(kù)如MySQL、SQLServer在很多場(chǎng)景下已經(jīng)無(wú)法高效的完成相關(guān)的工作,如本系統(tǒng)中的商品秒殺功能便極容易打崩數(shù)據(jù)庫(kù),正因如此,Redis的存儲(chǔ)技術(shù)是在這大環(huán)境下愈發(fā)火熱。不同于將每一次數(shù)據(jù)都寫入硬盤的傳統(tǒng)數(shù)據(jù)庫(kù),Redis是將數(shù)據(jù)緩存于內(nèi)存當(dāng)中,這使得Redis的讀寫性能極大的超出傳統(tǒng)數(shù)據(jù)庫(kù)。Redis得以興起的原因除高性能外,它將數(shù)據(jù)持久化的方式也是開(kāi)發(fā)者對(duì)它得以信賴的原因。如上文描述一樣,Redis的數(shù)據(jù)緩存于內(nèi)存當(dāng)中,這使得在默認(rèn)的情況下,若發(fā)生服務(wù)器宕機(jī)等情況,針對(duì)數(shù)據(jù)存儲(chǔ)在內(nèi)存中的現(xiàn)象產(chǎn)生的易丟失問(wèn)題,Redis提供了兩種可將內(nèi)存中的數(shù)據(jù)持久化在磁盤的方式給開(kāi)發(fā)者,稱之為AOF與RDB,分別對(duì)應(yīng)著增量請(qǐng)求、全量數(shù)據(jù)的設(shè)計(jì)理念。開(kāi)發(fā)者僅需通過(guò)簡(jiǎn)易的配置即可在Redis中啟動(dòng)這兩種數(shù)據(jù)備份的方式,降低了Redis數(shù)據(jù)丟失的可能性與量級(jí)。2.3.3MinIo用戶量的增長(zhǎng),用戶數(shù)據(jù)的上傳和更新都將使得有一定運(yùn)行時(shí)間的系統(tǒng)需要,在對(duì)存儲(chǔ)系統(tǒng)要求的不斷增加下,出現(xiàn)了許多的優(yōu)秀存儲(chǔ)解決方案,包括有TFS、ceph、Ambry等。其中,基于Apache開(kāi)源協(xié)議的對(duì)象存儲(chǔ)服務(wù)MinIo有著許多的優(yōu)點(diǎn),也是在眾多方案中更為適合該系統(tǒng)的一套存儲(chǔ)服務(wù)。MinIo的一大特點(diǎn)既是輕量級(jí),在Docker容器的部署下,MinIo服務(wù)的啟動(dòng)僅需一行簡(jiǎn)單的代碼。簡(jiǎn)易的啟動(dòng)方式并沒(méi)有使得MinIo的配置與使用方式變得復(fù)雜,除卻MinIo客戶端的細(xì)致操作命令,MinIo的存儲(chǔ)解決方案提供了基于網(wǎng)頁(yè)的圖形化管理界面,這意味著即便是沒(méi)有編程開(kāi)發(fā)經(jīng)驗(yàn)的管理者也可以隨時(shí)隨地的在不同的設(shè)備上對(duì)MinIo存儲(chǔ)的資料進(jìn)行管理和使用。MinIo解決方案能得以青睞的原因當(dāng)然不止是在使用的角度,MinIo存儲(chǔ)服務(wù)底層基于糾刪碼和校驗(yàn)對(duì)數(shù)據(jù)進(jìn)行保護(hù)的技術(shù)也是十分的成熟可靠。并且在眾多存儲(chǔ)解決方案中,MinIo對(duì)分布式部署的支持有先天性的支持。本系統(tǒng)將運(yùn)用MinIo的存儲(chǔ)服務(wù)對(duì)用戶上傳的文件如頭像圖片、手機(jī)的詳細(xì)圖及略縮圖、商品信息的文檔附件等進(jìn)行管理。2.3.4Docker本系統(tǒng)的開(kāi)發(fā)環(huán)境依賴了十分多的中間件,例如Redis、MinIo、MySQL等。以至于系統(tǒng)在異機(jī)部署環(huán)節(jié),由于不同的運(yùn)行環(huán)境或中間件版本的差異,將極容易引發(fā)環(huán)境兼容等問(wèn)題。這也是在微服務(wù)技術(shù)帶來(lái)便利的同時(shí),帶來(lái)的一個(gè)協(xié)同開(kāi)發(fā)難題。Docker虛擬化技術(shù)對(duì)該問(wèn)題提供了一個(gè)很大的便利性。它基于Linux容器,不同于具有完整操作系統(tǒng)的虛擬機(jī)技術(shù),基于Linux容器的應(yīng)用程序們共享同一個(gè)宿主內(nèi)核,這使得容器大大輕便于傳統(tǒng)的虛擬機(jī)技術(shù),也便于開(kāi)發(fā)者之間進(jìn)行容器的一個(gè)傳輸。Docker容器不僅是輕便,還十分的迅速。虛擬機(jī)的技術(shù)需要將硬件資源虛擬化再進(jìn)行使用,而基于Docker運(yùn)行的應(yīng)用程序可以直接使用硬件資源,使得應(yīng)用程序在CPU、內(nèi)存的使用率都明顯高于虛擬機(jī),甚至可達(dá)到秒級(jí)的啟動(dòng)速度。在Docker容器化技術(shù)支撐下,本系統(tǒng)的部署和啟動(dòng)變得十分簡(jiǎn)易。3系統(tǒng)分析3.1系統(tǒng)需求分析3.1.1技術(shù)可行性本手機(jī)銷售商城的設(shè)計(jì)與實(shí)現(xiàn)圍繞著微服務(wù)的技術(shù),基于前后端分離的思想而實(shí)現(xiàn)。為了更好的支撐系統(tǒng)的服務(wù)運(yùn)行以及不同模塊間的耦合程度,本商城的架構(gòu)底層依賴了許多不同類型的中間件。如使用MySQL數(shù)據(jù)庫(kù)做系統(tǒng)數(shù)據(jù)的持久化,Redis應(yīng)對(duì)系統(tǒng)中高并發(fā)數(shù)據(jù)的臨時(shí)存取功能。使用SpringCloud的規(guī)范做本系統(tǒng)中微服務(wù)之間的版本管理,同時(shí)大部分的SpringCloud項(xiàng)目依舊基于SpringBoot做的封裝,這也使得SpringCloud的微服務(wù)技術(shù)與本系統(tǒng)中的開(kāi)發(fā)模塊設(shè)計(jì)并不產(chǎn)生沖突。前后端分離的思想是本系統(tǒng)架構(gòu)的底層設(shè)計(jì),本系統(tǒng)架構(gòu)模式采取基于微服務(wù)開(kāi)發(fā)的SOA架構(gòu),面向服務(wù)開(kāi)發(fā)。前端頁(yè)面或應(yīng)用程序通過(guò)網(wǎng)絡(luò)請(qǐng)求的技術(shù)與后端服務(wù)進(jìn)行通訊,這使得系統(tǒng)的整體架構(gòu)邏輯更加清晰。負(fù)責(zé)數(shù)據(jù)處理的服務(wù)后端僅需面向相應(yīng)的數(shù)據(jù)做處理,而不需要將前端界面的代碼整合與模塊中。前端界面或應(yīng)用程序通過(guò)rpc遠(yuǎn)程調(diào)用技術(shù)與系統(tǒng)服務(wù)進(jìn)行基于JSON格式的通訊?;谇昂蠖朔蛛x的思想,拆分開(kāi)銷售系統(tǒng)中的視圖層及業(yè)務(wù)邏輯層,保證了系統(tǒng)不同功能項(xiàng)目的功能單一職責(zé),也使得開(kāi)發(fā)人員或后期維護(hù)人員的編碼便利性。綜上所述:本基于微服務(wù)搭建的手機(jī)銷售系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)不僅具備了一定的技術(shù)可行性,且所選技術(shù)方案對(duì)系統(tǒng)的開(kāi)發(fā)、維護(hù)都預(yù)留了良好空間,系統(tǒng)開(kāi)發(fā)人員自身的技術(shù)條件也能做出對(duì)應(yīng)的滿足。所以本基于微服務(wù)的手機(jī)銷售系統(tǒng)的開(kāi)發(fā)從技術(shù)角度是具有可行性的。3.1.2操作可行性在該手機(jī)銷售系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)中,面向不同的用戶群體提供了不同的設(shè)計(jì)界面。其中面向管理人員的系統(tǒng)設(shè)計(jì)基于常見(jiàn)的頁(yè)面技術(shù)實(shí)現(xiàn)。使得系統(tǒng)的管理人員可在不同的帶瀏覽器設(shè)備上實(shí)時(shí)的進(jìn)行對(duì)系統(tǒng)的管理維護(hù)操作。該銷售系統(tǒng)的后臺(tái)管理界面使用了單頁(yè)面的設(shè)計(jì),通過(guò)路由的功能實(shí)現(xiàn)頁(yè)面直接的顯示切換,減少了因網(wǎng)絡(luò)請(qǐng)求造成的頁(yè)面顯示空白或加載的情況,對(duì)用戶體驗(yàn)有了大幅度提高。不僅如此,在系統(tǒng)的管理后臺(tái)中,實(shí)現(xiàn)了表格、窗口拖拽、日期控件等功能,使得系統(tǒng)的管理模塊上手難度并不高。對(duì)于商城系統(tǒng)的會(huì)員用戶提供了使用Flutter技術(shù)開(kāi)發(fā)的手機(jī)應(yīng)用程序,應(yīng)用程序以扁平化的卡片式設(shè)計(jì)為主,通過(guò)常見(jiàn)的手機(jī)應(yīng)用程序操作如列表滑動(dòng)、下拉刷新等操作,并對(duì)于地址的管理功能引入了省市區(qū)的界面控件,無(wú)處不在的操作優(yōu)化細(xì)節(jié)使得商城的會(huì)員用戶在應(yīng)用程序安裝完成后,無(wú)需額外的花費(fèi)時(shí)間學(xué)習(xí)即可對(duì)應(yīng)用程序進(jìn)行使用。管理系統(tǒng)的管理員可在后臺(tái)系統(tǒng)中對(duì)商品進(jìn)行上架、信息修改、價(jià)格調(diào)整等操作,而系統(tǒng)的另一使用群體,會(huì)員用戶可在應(yīng)用程序中完成對(duì)商品的查詢與購(gòu)買功能。在管理員以及會(huì)員用戶操作的過(guò)程中,由于系統(tǒng)基于前后端分離的思想而實(shí)現(xiàn)的原因,管理員將不再需要關(guān)注用戶手中的設(shè)備是否有刷新數(shù)據(jù),用戶也無(wú)需擔(dān)憂設(shè)備上的數(shù)據(jù)是否為最新版本。兩種用戶的功能操作有了隔離但卻又相互影響,系統(tǒng)的使用邏輯更加清晰。因此,該手機(jī)銷售系統(tǒng)在各方面都盡可能的將用戶、管理員的學(xué)習(xí)和使用成本降低,保證了系統(tǒng)的操作可行性。3.2系統(tǒng)功能分析系統(tǒng)的功能進(jìn)行模塊劃分如圖3-1所示圖3-1手機(jī)銷售商城系統(tǒng)模塊圖本系統(tǒng)實(shí)現(xiàn)的手機(jī)銷售商城系統(tǒng)主要使用角色分為系統(tǒng)管理員和商城會(huì)員用戶。不同的角色具有不同的服務(wù)接口,由具體的資源服務(wù)器提供客戶端所需的功能。具體的功能如下:商城管理員功能分析權(quán)限管理模塊管理員管理:可對(duì)商城的后臺(tái)管理系統(tǒng)的所有人員進(jìn)行一個(gè)查詢,并實(shí)現(xiàn)了管理員的新增、刪除功能。最高權(quán)限的管理員可賦予其他管理人員賬戶權(quán)限。角色管理:具有最高權(quán)限的管理員可在該模塊下對(duì)不同權(quán)限等級(jí)角色所具有的權(quán)限進(jìn)行調(diào)整。系統(tǒng)管理模塊日志管理:頂級(jí)管理員可在日志管理模塊中對(duì)使用AOP技術(shù)管理接口時(shí)產(chǎn)生的日志信息進(jìn)行管理,次級(jí)管理員僅可進(jìn)行查詢。令牌管理:令牌管理模塊可對(duì)所有登陸的管理員所持有的令牌進(jìn)行管理,其中頂級(jí)程序員具有該模塊的操作功能,而次級(jí)管理員并不具有這一權(quán)限。商城管理模塊手機(jī)管理:該管理模塊的功能對(duì)所有的管理員開(kāi)放,實(shí)現(xiàn)了對(duì)商城手機(jī)商品信息的基本操作。訂單管理:實(shí)現(xiàn)了管理員對(duì)訂單的查詢、狀態(tài)修改、刪除功能。用戶管理:實(shí)現(xiàn)了商城系統(tǒng)管理員對(duì)用戶信息的查詢、編輯操作。商城用戶功能分析注冊(cè)、登陸功能:實(shí)現(xiàn)會(huì)員用戶的注冊(cè)和登陸商品信息查詢功能:可通過(guò)刷新實(shí)時(shí)的獲取最新的商品信息個(gè)人購(gòu)物車功能:用戶可將感興趣的商品添加進(jìn)購(gòu)物車中收藏訂單管理功能:用戶在將購(gòu)物車中的商品進(jìn)行“結(jié)賬”處理后,會(huì)并生成相應(yīng)的待支付訂單,用戶可在該訂單模塊完成支付。并且可以在該模塊獲取用戶個(gè)人的所有訂單信息。個(gè)人中心模塊:用戶可在該模塊完成頭像的上傳更新,或進(jìn)入其他功能模塊。

4商城架構(gòu)設(shè)計(jì)4.1數(shù)據(jù)庫(kù)設(shè)計(jì)對(duì)底層的數(shù)據(jù)庫(kù)進(jìn)行合理的設(shè)計(jì),是本銷售商城系統(tǒng)架構(gòu)能進(jìn)行良好建造的基礎(chǔ)。關(guān)于本系統(tǒng)數(shù)據(jù)的設(shè)計(jì)需在符合設(shè)計(jì)范式的基礎(chǔ)上還須遵循一定的設(shè)計(jì)規(guī)則。首先是每張表在建立之初必須添加主鍵,一是為了使得數(shù)據(jù)具有唯一性,二是為了在一定程度提高數(shù)據(jù)的檢索效率,同時(shí),表的主鍵也在業(yè)務(wù)邏輯層對(duì)數(shù)據(jù)持久層的存在許多操作。其次,為了對(duì)有價(jià)值的數(shù)據(jù)信息進(jìn)行保存,也為了防止管理員對(duì)信息的誤刪,可在相關(guān)的數(shù)據(jù)表中留下名為“del_flag”字段做業(yè)務(wù)邏輯的邏輯刪除功能。最后的一條規(guī)則是表與表之間不再進(jìn)行外鍵關(guān)系的綁定,大量依賴外鍵約束而設(shè)計(jì)數(shù)據(jù)庫(kù),會(huì)成為商城系統(tǒng)在日后數(shù)據(jù)流量大,需要做拆庫(kù)拆表操作降低數(shù)據(jù)庫(kù)訪問(wèn)壓力時(shí)的一個(gè)操作約束。在本商城系統(tǒng)的設(shè)計(jì)之初不再添加外鍵約束,只在業(yè)務(wù)邏輯層中使用代碼邏輯中實(shí)現(xiàn)相應(yīng)的外鍵關(guān)聯(lián)關(guān)系。圖4-1數(shù)據(jù)庫(kù)設(shè)計(jì)E-R圖該圖主要反映數(shù)據(jù)庫(kù)中各表的字段具體設(shè)計(jì)與實(shí)現(xiàn)。其中系統(tǒng)存有的角色分成了管理員以及商城用戶,對(duì)應(yīng)著sys_user表以及phone_market_user表單,將兩種使用角色拆分成兩張表的設(shè)計(jì)保證了該商城系統(tǒng)各服務(wù)的單一職責(zé)性。商城中其余關(guān)于部分,如角色表、日志表、手機(jī)商品信息表都能在數(shù)據(jù)庫(kù)中找到對(duì)應(yīng)。由于本商城系統(tǒng)關(guān)于數(shù)據(jù)庫(kù)設(shè)計(jì)采用盡可能少外鍵約束的設(shè)計(jì)規(guī)范,所以本系統(tǒng)數(shù)據(jù)表的關(guān)鍵部分中關(guān)于用戶、部門、菜單、角色、權(quán)限之間的設(shè)計(jì),在傳統(tǒng)的RBAC權(quán)限管理設(shè)計(jì)模型上進(jìn)行了更符合本系統(tǒng)的改良設(shè)計(jì)。根據(jù)傳統(tǒng)的權(quán)限設(shè)計(jì)的思想,用戶表的職責(zé)只在于用戶信息的存儲(chǔ),而不涉及權(quán)限相關(guān),降低了表與表之間的耦合度,而在本系統(tǒng)中更是添加了部門、菜單等表單對(duì)用戶與角色的權(quán)限進(jìn)行細(xì)化。該模型同時(shí)增加了系統(tǒng)的靈活性,讓角色作為系統(tǒng)權(quán)限信息中的樞紐中心,關(guān)聯(lián)用戶及權(quán)限。系統(tǒng)后期維護(hù)若需添加新的管理員級(jí)別,僅需添加新的角色,并為該角色分配相關(guān)的權(quán)限,再賦予該管理員對(duì)應(yīng)的角色即可。無(wú)需再對(duì)系統(tǒng)數(shù)據(jù)庫(kù)進(jìn)行重新設(shè)計(jì)和遷移。4.2后端架構(gòu)設(shè)計(jì)本商城的管理系統(tǒng)基于前后端分離的思想將系統(tǒng)分成了前臺(tái)與后臺(tái),屬于傳統(tǒng)的基于B/S架構(gòu)web應(yīng)用系統(tǒng)。系統(tǒng)的管理員隨時(shí)隨地的使用帶有瀏覽器的聯(lián)網(wǎng)設(shè)備訪問(wèn)后臺(tái)管理系統(tǒng)。根據(jù)不同的業(yè)務(wù)邏輯,將系統(tǒng)拆分成了若干個(gè)模塊或服務(wù)系統(tǒng),但大致可分成權(quán)限服務(wù)、資源服務(wù)。每個(gè)服務(wù)可在不同設(shè)備上部署運(yùn)行、集群部署運(yùn)行,再交由Nacos中心進(jìn)行服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)等。服務(wù)與服務(wù)間通過(guò)RPC技術(shù)Feign,進(jìn)行輕量級(jí)的接口調(diào)用并實(shí)現(xiàn)集群部署時(shí)的負(fù)載均衡功能,調(diào)用過(guò)程中使用了Hystrix斷路器,對(duì)服務(wù)間調(diào)用產(chǎn)生的超時(shí)、錯(cuò)誤進(jìn)行降級(jí)處理,防止其中一服務(wù)或節(jié)點(diǎn)的異常導(dǎo)致整體系統(tǒng)的癱瘓異常。web前端通過(guò)網(wǎng)絡(luò)協(xié)議調(diào)用微服務(wù)的網(wǎng)關(guān)API,再由網(wǎng)關(guān)針對(duì)請(qǐng)求的路徑將請(qǐng)求進(jìn)行分發(fā)至不同的服務(wù)接口。而后端由于搭建采取微服務(wù)架構(gòu)的設(shè)計(jì)風(fēng)格,將整個(gè)系統(tǒng)根據(jù)業(yè)務(wù)邏輯、功能差異、設(shè)計(jì)思想拆分成多個(gè)小服務(wù),可降低了服務(wù)間的耦合程度,方便眾多的開(kāi)發(fā)者協(xié)同開(kāi)發(fā)。也可使得系統(tǒng)模塊化清晰,對(duì)已完成功能更容易進(jìn)行維護(hù)、保留系統(tǒng)未來(lái)功能的拓展性。對(duì)服務(wù)產(chǎn)生或依賴的相關(guān)文件,交由Minio存儲(chǔ)系統(tǒng)集中管理。本商城系統(tǒng)的系統(tǒng)數(shù)據(jù)持持久化層選用MySQL數(shù)據(jù)庫(kù)實(shí)現(xiàn),開(kāi)源免費(fèi)的MySQL可大大降低系統(tǒng)的開(kāi)發(fā)成本,其次MySQL數(shù)據(jù)庫(kù)的性能也較優(yōu)秀、開(kāi)發(fā)人員眾多。在MySQL數(shù)據(jù)庫(kù)的幫助下,可確保商城系統(tǒng)數(shù)據(jù)的準(zhǔn)確性,并位于架構(gòu)的底層確保系統(tǒng)數(shù)據(jù)的完整性、穩(wěn)定性。但傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)并不能滿足系統(tǒng)中的所有場(chǎng)景,如出現(xiàn)了商城管理系統(tǒng)中的菜單訪問(wèn)、并發(fā)對(duì)熱門商品的信息查詢等情況,都極容易發(fā)生MySQL數(shù)據(jù)庫(kù)被打崩的情況,這將會(huì)對(duì)系統(tǒng)的正常使用產(chǎn)生較大影響。這也是在系統(tǒng)底層數(shù)據(jù)支撐組件中,引入了Redis緩存中間件的其中一個(gè)原因。在分布式部署的系統(tǒng)中,關(guān)于事務(wù)問(wèn)題的處理上總是必須仔細(xì)考量,并必須做出的符合系統(tǒng)特性的方案。若沒(méi)有將系統(tǒng)中的事務(wù)問(wèn)題做出方案,則極容易出現(xiàn)重大缺陷,形成數(shù)據(jù)安全隱患。本系統(tǒng)中引入了TX-LCN框架對(duì)分布式事務(wù)進(jìn)行處理,保證了本商城系統(tǒng)的數(shù)據(jù)一致性。以上便是關(guān)于本銷售商城的系統(tǒng)架構(gòu)概述,具體的實(shí)現(xiàn)細(xì)節(jié)可繼續(xù)閱讀關(guān)于架構(gòu)實(shí)現(xiàn)的章節(jié)。NacosApplication由于系統(tǒng)被拆分成了若干個(gè)子項(xiàng)目,所以一個(gè)可零散服務(wù)零服務(wù)進(jìn)行集中管理管理的組件就顯得十分重要。在本系統(tǒng)中采取用當(dāng)下最熱門的微服務(wù)管理組件Nacos作為服務(wù)注冊(cè)中心。在Nacos組件的幫助下完成微服務(wù)設(shè)計(jì)架構(gòu)中十分重要的“服務(wù)治理”功能,另外搭配Ribbon的負(fù)載均衡算法,可輕松實(shí)現(xiàn)服務(wù)間的群集部署。不僅如此,Nacos更是集成了配置中心的功能,使得服務(wù)的模塊化格局更加清晰。GatewayApplication該模塊是商城管理系統(tǒng)的后端網(wǎng)關(guān),也是所有請(qǐng)求的入口。為了保證服務(wù)接口的安全性,外網(wǎng)是不被允許對(duì)微服務(wù)相關(guān)的接口直接進(jìn)行調(diào)用的,也因此網(wǎng)關(guān)相當(dāng)于商城系統(tǒng)的“門口”,網(wǎng)關(guān)服務(wù)的性能高低有可能對(duì)系統(tǒng)的狀況產(chǎn)生較大影響。本商城管理系統(tǒng)的網(wǎng)關(guān)模塊在SpringCloudGateway框架的基礎(chǔ)上進(jìn)行功能的開(kāi)發(fā),Gateway框架采用了非阻塞的技術(shù)實(shí)現(xiàn),不同于Zuul等阻塞型,每個(gè)請(qǐng)求對(duì)應(yīng)一線程的處理方式,Gateway基于非阻塞實(shí)現(xiàn)的網(wǎng)關(guān)單一線程即可對(duì)多個(gè)請(qǐng)求進(jìn)行處理,這將節(jié)省不少系統(tǒng)資源的占用,可明顯提高網(wǎng)關(guān)的性能。且本銷售系統(tǒng)針對(duì)系統(tǒng)中不同服務(wù)的請(qǐng)求數(shù)量情況、服務(wù)調(diào)用時(shí)間做了一定的可能性分析,并在Gateway上通過(guò)分析結(jié)論對(duì)不同的服務(wù)進(jìn)行了一個(gè)限流的配置,對(duì)超出訪問(wèn)限制的用戶給予良好的反饋提示,提高了用戶體驗(yàn)。AuthApplication該模塊屬于系統(tǒng)的權(quán)限校驗(yàn)?zāi)K,本系統(tǒng)的權(quán)限校驗(yàn)?zāi)K基于SpringSecurity技術(shù)進(jìn)行開(kāi)發(fā)。使用JWT實(shí)現(xiàn)系統(tǒng)的單點(diǎn)登錄功能,用戶登陸一次后便可獲得該系統(tǒng)的訪問(wèn)令牌,再與系統(tǒng)發(fā)生通訊時(shí),攜帶該令牌即可完成認(rèn)證,即使所訪問(wèn)的服務(wù)與用于獲取Token的機(jī)器并不相同。除了正常的完成用戶登陸并將對(duì)應(yīng)JWT標(biāo)識(shí)返回給用戶的功能外,本銷售商城的權(quán)限校驗(yàn)?zāi)K更是預(yù)留了對(duì)用戶Token的管理功能。不與傳統(tǒng)的用戶數(shù)據(jù)相同,Token數(shù)據(jù)具有查詢頻率高、變動(dòng)性較大的特點(diǎn),且每個(gè)Token具有以秒為單位的時(shí)效性,需要實(shí)時(shí)更新并校驗(yàn),存儲(chǔ)于MySQL這類傳統(tǒng)的數(shù)據(jù)庫(kù)中容易帶來(lái)較大且不必要的壓力,這時(shí)候緩存中間件就起了較大作用。本權(quán)限校驗(yàn)中心將用戶的Token數(shù)據(jù)以約定的規(guī)范作為Key值存入了Redis中,對(duì)Token的查詢等操作的性能都添上保證。AdminApplicationAdminApplication功能模塊又稱管理員權(quán)限模塊,商城系統(tǒng)在該模塊下預(yù)留了相關(guān)管理功能的接口,例如權(quán)限管理、系統(tǒng)管理等。管理員可通過(guò)調(diào)用該模塊的接口對(duì)商城系統(tǒng)的管理員、角色權(quán)限、日志、令牌等系統(tǒng)相關(guān)信息做出查詢,并根據(jù)管理員所具有的角色權(quán)限對(duì)操作進(jìn)行限制。采用SpringMVC框架作為該功能模塊的技術(shù)選型,通過(guò)對(duì)SpringMVC進(jìn)行相關(guān)配置信息的完善搭配以框架注解的使用,保證了代碼閱讀性、耦合性的同時(shí),實(shí)現(xiàn)了對(duì)由網(wǎng)關(guān)派送到的該模塊的請(qǐng)求根據(jù)請(qǐng)求路徑的不同,執(zhí)行不同的業(yè)務(wù)邏輯的功能。ManagerApplication?該管理員模塊主要向系統(tǒng)管理員提供商城管理的服務(wù)接口,商品信息、訂單信息等管理都在該模塊得以實(shí)現(xiàn)。根據(jù)系統(tǒng)的設(shè)計(jì)需求,該模塊下大部分的管理系統(tǒng)據(jù)信息會(huì)通過(guò)MySQL數(shù)據(jù)庫(kù)持久化進(jìn)行持久化的存儲(chǔ)。如何高效地對(duì)數(shù)據(jù)持久層進(jìn)行訪問(wèn)是該模塊的設(shè)計(jì)重點(diǎn)。本功能模塊引入了Mybatis-Plus的框架技術(shù)實(shí)現(xiàn)模塊服務(wù)控制層對(duì)數(shù)據(jù)持久化層訪問(wèn)。Mybatis是國(guó)際上獲得了許多認(rèn)可的持久層框架,通過(guò)動(dòng)態(tài)SQL、XML映射、結(jié)果集等特性,大大提高了開(kāi)發(fā)者的勞動(dòng)效率。而Mybatis-Plus內(nèi)置了通用的Service接口、Mapper接口大量減少了該管理員模塊中代碼的重復(fù)性。自帶的分頁(yè)插件更為管理員對(duì)信息的管理提供的便利性的同時(shí),降低了系統(tǒng)底層MySQL數(shù)據(jù)庫(kù)的訪問(wèn)壓力。在MyBatis-Plus的幫助下,商城管理系統(tǒng)更是引入了一個(gè)名為“邏輯刪除”的操作新型操作概念,通過(guò)簡(jiǎn)易配置文件加相關(guān)注解即可將這一特性啟動(dòng)。啟動(dòng)后,用戶對(duì)相關(guān)數(shù)據(jù)的刪除操作并不會(huì)被真正的執(zhí)行,取而代之的是將數(shù)據(jù)“隱藏”起來(lái),達(dá)到刪除的效果。系統(tǒng)將這一特性引入,降低了管理員對(duì)重要信息進(jìn)行了錯(cuò)誤操作造成的影響。4.3移動(dòng)端應(yīng)用設(shè)計(jì)?手機(jī)馬特銷售商城的主要使用用戶會(huì)是廣大的群眾人民,他們使用的移動(dòng)設(shè)備也各有不同,其中最為主要的兩大平臺(tái)實(shí)屬Android以及iOS。所以手機(jī)馬特的移動(dòng)端商城需對(duì)這兩個(gè)平臺(tái)進(jìn)行開(kāi)發(fā),才會(huì)獲得最大的用戶受群,滿足條件的選型技術(shù)有WebApp、ReactNative、Flutter、雙平臺(tái)分別進(jìn)行獨(dú)立開(kāi)發(fā)。不同的技術(shù)具有不同的優(yōu)缺點(diǎn)。其中WebApp由于性能低、操控體驗(yàn)不好的原因首先進(jìn)行排除。而雙平臺(tái)分別進(jìn)行獨(dú)立開(kāi)發(fā)首先對(duì)開(kāi)發(fā)人員的技術(shù)要求就具有一定的門檻,不僅需要對(duì)Android開(kāi)發(fā)有深入了解,對(duì)iOS的開(kāi)發(fā)語(yǔ)言swift也需要掌握,除此之外,也會(huì)大量地浪費(fèi)開(kāi)發(fā)人員的時(shí)間和精力于實(shí)現(xiàn)功能相同的邏輯代碼,并不是一個(gè)優(yōu)秀的選擇。ReactNative是由JavaScript開(kāi)發(fā)并且由原生控件渲染的的框架技術(shù),由Facebook在2015年發(fā)布,React組件包裝現(xiàn)有的本機(jī)代碼,并通過(guò)React的聲明性UI范例和JavaScript與本機(jī)API進(jìn)行交互。也就是說(shuō)僅通過(guò)JavaScript語(yǔ)言既可在ReactNative的框架的幫助下,開(kāi)發(fā)安卓以及iOS這兩臺(tái)主流移動(dòng)端的具有原生應(yīng)用體驗(yàn)程序。圖4-2ReactNative架構(gòu)圖Flutter框架由Google開(kāi)源并維護(hù)。技術(shù)也在不斷成熟中,越來(lái)越多的開(kāi)發(fā)者和公司愿意嘗試使用這套框架,由國(guó)內(nèi)一線互聯(lián)網(wǎng)企業(yè)阿里巴巴所開(kāi)發(fā)的應(yīng)用程序“閑魚(yú)”即是在Fluter框架下開(kāi)發(fā)而成,國(guó)內(nèi)外大小的企業(yè)都正在該技術(shù)領(lǐng)域探索更多的可能性。原因是Flutter框架天生具有許多優(yōu)秀的特性,其中“快速開(kāi)發(fā)”、“構(gòu)造漂亮的UI”、“原生性能”最為讓人對(duì)該技術(shù)著迷。不同于ReactNative,F(xiàn)lutter的底層渲染其實(shí)交由Skia接管,Skia下層便是CPU/GPU,減少了Chromium、Androidruntime等中間層,可以直接的進(jìn)行繪制圖形。圖4-3Flutter框架快速的原因而ReactNative框架從使用JavaScript到解析調(diào)用Native的過(guò)程中經(jīng)過(guò)了過(guò)個(gè)環(huán)節(jié),以至于速度也就沒(méi)有Flutter迅速了,經(jīng)過(guò)衡量取舍,采用Flutter作為手機(jī)馬特移動(dòng)端應(yīng)用開(kāi)發(fā)的框架技術(shù)選型。手機(jī)馬特的移動(dòng)端基于Flutter框架開(kāi)發(fā)出面向用戶群體的功能,無(wú)論是Android亦或是iOS用戶,都可在該應(yīng)用商店上享受到舒適的購(gòu)物體驗(yàn)。應(yīng)用程序通過(guò)前后端分離的思想與后端的伺服器進(jìn)行溝通,減低了移動(dòng)端的應(yīng)用程序占用空間,也利于手機(jī)馬特管理人員對(duì)用戶產(chǎn)生的數(shù)據(jù)進(jìn)行統(tǒng)一管理。應(yīng)用端的功能開(kāi)發(fā)主要以構(gòu)造優(yōu)美的用戶界面為主,主要以手機(jī)商品的瀏覽、商品詳細(xì)信息描述。手機(jī)馬特的移動(dòng)端是該套系統(tǒng)用戶使用最頻繁、感受最直觀的程序,因而對(duì)應(yīng)用程序的界面設(shè)計(jì)有極高的要求。由于手機(jī)屏幕的尺寸不同于電腦熒幕的尺寸,移動(dòng)平臺(tái)的界面相對(duì)較小且具有觸控的特性,針對(duì)該類特性進(jìn)行操控的優(yōu)化,包括界面與界面直接的切換方法和動(dòng)畫,使得操作應(yīng)用程序流暢、簡(jiǎn)潔、漂亮、易用。手機(jī)馬特的移動(dòng)端應(yīng)用程序重要分成了四大模塊,對(duì)應(yīng)著應(yīng)用程序的界面實(shí)現(xiàn)、控制器、本地?cái)?shù)據(jù)管理中心以及網(wǎng)絡(luò)工具。模塊與模塊間須有清晰的設(shè)計(jì)結(jié)構(gòu)與功能,提高方法的重用性的同時(shí)保證代碼的耦合性、可閱讀性。應(yīng)用程序的主題風(fēng)格遵循MaterialDesign的規(guī)范,細(xì)致到每一個(gè)Icon,每一幀過(guò)渡動(dòng)畫,以藍(lán)色為主題色調(diào)構(gòu)建App的每一個(gè)界面。設(shè)計(jì)的初稿靈感來(lái)源于一名為JuliaJakubiak的設(shè)計(jì)師的開(kāi)源設(shè)計(jì)圖。圖4-4手機(jī)端設(shè)計(jì)源稿卡片式的風(fēng)格構(gòu)筑應(yīng)用程序,以方便適用于任何尺寸的手機(jī)熒幕,配以鮮明的色彩突出商品的特點(diǎn)。系統(tǒng)的詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)5.1架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)圖5-1架構(gòu)組件圖該商城所使用的組件架構(gòu)如圖所示,由Nginx對(duì)請(qǐng)求進(jìn)行同一的反向代理、負(fù)載均衡,這樣做的目的一保證是為了模塊集群部署時(shí),可以輕易對(duì)不同主機(jī)ip地址的管理,其次通過(guò)Nginx反向代理的請(qǐng)求也可以再一定程度上避免前后端分離架構(gòu)時(shí)出現(xiàn)的跨域請(qǐng)求問(wèn)題。系統(tǒng)后臺(tái)設(shè)計(jì)中,只將對(duì)網(wǎng)關(guān)的請(qǐng)求反向代理,具體服務(wù)的調(diào)用將通過(guò)網(wǎng)關(guān)的路由功能實(shí)現(xiàn),避免了涉及安全性的具體服務(wù)主機(jī)的ip地址暴露問(wèn)題,可大大減少關(guān)鍵主機(jī)遭受網(wǎng)絡(luò)攻擊的機(jī)會(huì)。圖5-2系統(tǒng)架構(gòu)圖同時(shí)可明顯可以看出整體的架構(gòu)設(shè)計(jì)思想采用了微服務(wù)架構(gòu)設(shè)計(jì),因?yàn)樵趫D中可以看出不同的應(yīng)用服務(wù)都具有各自的一個(gè)獨(dú)立框框,而這些應(yīng)用服務(wù)同時(shí)被某些功能框架所關(guān)聯(lián)、管理。采用阿里巴巴Nacos框架作為注冊(cè)中心與配置中心,對(duì)微服務(wù)進(jìn)行服務(wù)治理。管理模塊由主要由GatewayApplication、AuthApplication、AdminApplication、PhoneMarketDataManagerApplication服務(wù)構(gòu)成,都將注冊(cè)進(jìn)同一個(gè)Nacos注冊(cè)中心中,服務(wù)間的調(diào)用將交由Feign框架作用,F(xiàn)eign框架底層其實(shí)是對(duì)Ribbon框架進(jìn)行了更符合微服務(wù)調(diào)用邏輯的操作封裝,Ribbon提供了不同的負(fù)載均衡算法,例如權(quán)重分配、輪訓(xùn)算法,將不同負(fù)載均衡搭配注冊(cè)中心的使用,可將本系統(tǒng)后期拓展集群開(kāi)發(fā)、部署提高便利性。同時(shí)可以發(fā)現(xiàn),該系統(tǒng)還采用了Sentinel組件對(duì)服務(wù)的流量進(jìn)行控制,限流框架的引入首先可以提高了服務(wù)間調(diào)用的可管理性。Sentinel框架實(shí)現(xiàn)了上述調(diào)用Feign接口實(shí)現(xiàn)服務(wù)間的調(diào)用時(shí)的熔斷降級(jí)功能,避免了單一服務(wù)宕機(jī)而影響到其他服務(wù)功能的情況。其次,Sentinel對(duì)服務(wù)內(nèi)接口也提供了多種限流規(guī)則,包括了QPS、熱點(diǎn)限流、削峰填谷等,這都對(duì)該手機(jī)銷售商城中的接口的流量管理起了很大的作用,防止了單一接口流量過(guò)高而對(duì)其他接口的使用而產(chǎn)生過(guò)大的影響。在該銷售系統(tǒng)的基礎(chǔ)設(shè)施上,采用了包括RocketMQ、Redis、Mysql的工具。其中RocketMQ作為消息中間件,主要用對(duì)應(yīng)對(duì)用戶高并發(fā)下單的情況下,容易出現(xiàn)的商品超售、數(shù)據(jù)庫(kù)突然被大量請(qǐng)求打崩等問(wèn)題,這其中主要是運(yùn)用了消息中間件的削峰功能與異步的功能,用戶調(diào)用了下單接口后,其實(shí)訂單并沒(méi)有立即生成,而是將所需生成的訂單相關(guān)信息生成信息通過(guò)RocketMQ發(fā)送至具體的下單服務(wù)中進(jìn)行處理,而消息中間件的消息隊(duì)列設(shè)計(jì)思想,已經(jīng)將并發(fā)的訂單下單請(qǐng)求做了削峰。而之所以選擇了RocketMQ,一大原因是由阿里巴巴所開(kāi)發(fā)的RocketMQ天生經(jīng)受過(guò)高并發(fā)電商有的考核,同時(shí)RocketMQ提供了多種的數(shù)據(jù)同步機(jī)制,數(shù)據(jù)更具可靠性。Redis的引入主要用作臨時(shí)數(shù)據(jù)的存儲(chǔ),例如用戶的Token信息、熱點(diǎn)信息、特定時(shí)間段內(nèi)高訪問(wèn)高修改數(shù)據(jù)、會(huì)被高并發(fā)操作的數(shù)據(jù),這主要的原因是在該銷售系統(tǒng)下并發(fā)對(duì)數(shù)據(jù)進(jìn)行修改其實(shí)是一常見(jiàn)的操作,而MySQL對(duì)這類頻繁并發(fā)修改的情況所支持的性能較低,且容易影響其他連接對(duì)非頻繁數(shù)據(jù)的訪問(wèn)。5.2移動(dòng)商城管理系統(tǒng)的開(kāi)發(fā)5.2.1系統(tǒng)登錄與權(quán)限功能設(shè)計(jì)與實(shí)現(xiàn)圖5-3后臺(tái)管理登陸界面商城管理系統(tǒng)的首界面如圖所示。將銷售商城的后臺(tái)管理系統(tǒng)設(shè)計(jì)為“物料”的設(shè)計(jì)風(fēng)格,與商城的移動(dòng)端應(yīng)用程序統(tǒng)一語(yǔ)言。前端架構(gòu)基于Vue框架進(jìn)行開(kāi)發(fā),Vue框架其中一技術(shù)特點(diǎn)可通過(guò)路由的功能實(shí)現(xiàn)單頁(yè)面web應(yīng)用。本商城管理系統(tǒng)的后臺(tái)管理系統(tǒng)前端模塊開(kāi)發(fā)正是利用了Vue框架的這一技術(shù)特點(diǎn),開(kāi)發(fā)成了單頁(yè)面應(yīng)用。在初次進(jìn)行訪問(wèn)時(shí)頁(yè)面將會(huì)進(jìn)行完整加載,在對(duì)具體的相關(guān)功能進(jìn)行查詢或操作時(shí),僅僅與服務(wù)器進(jìn)行必要的數(shù)據(jù)溝通,獲得響應(yīng)的數(shù)據(jù)后再交由頁(yè)面中的相關(guān)代碼進(jìn)行邏輯處理,最終向用戶展示。本商城管理系統(tǒng)的單頁(yè)面應(yīng)用的設(shè)計(jì),大大減輕了管理員與服務(wù)器之間的網(wǎng)絡(luò)傳輸壓力,對(duì)頁(yè)面的加載速度有了提高,減少了管理員在對(duì)系統(tǒng)進(jìn)行操作時(shí),面對(duì)空白頁(yè)面等待響應(yīng)的時(shí)間。登陸頁(yè)面做了扁平化與陰影的設(shè)計(jì),登陸表單不再單調(diào)。該前端服務(wù)僅做信息展示與交互,并不參與系統(tǒng)的具體功能業(yè)務(wù)。登陸表單調(diào)用管理系統(tǒng)后臺(tái)中的權(quán)限校驗(yàn)?zāi)K,將用戶輸入的賬戶與密碼通過(guò)配置好的接口信息,調(diào)用權(quán)限相關(guān)的登陸接口。前端服務(wù)于后端服務(wù)之間配置了一對(duì)秘鑰,稱之為公鑰、私鑰。該非對(duì)稱秘鑰用于在請(qǐng)求過(guò)程中對(duì)用戶所輸入的密碼進(jìn)行加密、解密處理,以防止重要信息在傳遞過(guò)程中被不法分子所攔截,留下密碼泄漏的系統(tǒng)安全隱患。用戶的信息不僅在傳輸過(guò)程了做了一定的加密處理,業(yè)務(wù)邏輯層對(duì)用戶的關(guān)鍵信息進(jìn)行存儲(chǔ)也采用了bcrypt加密方法進(jìn)行加密,并且該加密技術(shù)對(duì)同樣的字符串經(jīng)過(guò)計(jì)算后得到的密碼也會(huì)不相同,提高了密碼的破解難度。圖5-4基于授權(quán)碼實(shí)現(xiàn)的登陸時(shí)序圖如上述時(shí)序圖所示,該商城的權(quán)限校驗(yàn)?zāi)K實(shí)現(xiàn)流程主要根據(jù)OAuth2標(biāo)準(zhǔn)的授權(quán)碼模式。在前端系統(tǒng)發(fā)送的登陸請(qǐng)求得到響應(yīng)后,前端系統(tǒng)會(huì)對(duì)響應(yīng)的信息進(jìn)行分析處理,若用戶輸入的賬戶、密碼是正確的,權(quán)限校驗(yàn)?zāi)K除了返回賬戶密碼校驗(yàn)正確的信息外,還會(huì)根據(jù)管理系統(tǒng)中管理員角色所具有相關(guān)信息計(jì)算出一個(gè)定制化的標(biāo)識(shí)碼,稱之為令牌,在本系統(tǒng)中,每個(gè)令牌都有一個(gè)對(duì)應(yīng)的value值存儲(chǔ)在redis中,值中存儲(chǔ)了該令牌所對(duì)應(yīng)的用戶的權(quán)限信息,如存儲(chǔ)有登陸用戶的相關(guān)信息外,還具有時(shí)效的等信息。該令牌會(huì)隨著響應(yīng)抵達(dá)并儲(chǔ)存在用戶的瀏覽器中。當(dāng)管理員再調(diào)用該管理系統(tǒng)相關(guān)的接口時(shí),會(huì)將該令牌進(jìn)行處理攜帶在請(qǐng)求頭中,作為服務(wù)器識(shí)別用戶的身份標(biāo)記。另外,為了防止令牌被盜用,每個(gè)令牌是具有時(shí)效性的。根據(jù)用于登陸時(shí)傳入的Client信息不同,配置了不同的時(shí)效性,這也帶來(lái)了另一個(gè)問(wèn)題,Token續(xù)期處理的問(wèn)題。在本系統(tǒng)中,令牌的刷新采取了被被動(dòng)刷新的模式。圖5-5基于OAuth2授權(quán)碼實(shí)現(xiàn)的登陸原理當(dāng)個(gè)客戶端攜帶的過(guò)期令牌訪問(wèn)資源服務(wù)器時(shí),資源服務(wù)器調(diào)會(huì)調(diào)用權(quán)限服務(wù)器對(duì)傳入的令牌進(jìn)行一個(gè)校驗(yàn),若權(quán)限服務(wù)器返回的狀態(tài)是令牌已過(guò)期的狀態(tài),則將該令牌已過(guò)期的信息返回客戶端中,客戶端接受到令牌已過(guò)期的響應(yīng)會(huì)調(diào)用令牌刷新的接口,并刷新令牌所需的標(biāo)識(shí),完成一次令牌的刷新。這種解決方式比較符合一般的令牌續(xù)期處理邏輯,雖然某些時(shí)候?qū)涌诘脑L問(wèn)會(huì)產(chǎn)生不連續(xù)性的問(wèn)題,但對(duì)令牌時(shí)效設(shè)置的合理,即可減少令牌刷新次數(shù)。若是采用主動(dòng)刷新的模式,將會(huì)大大增加客戶端資源的占用。圖5-6權(quán)限校驗(yàn)流程圖整個(gè)權(quán)限校驗(yàn)流程通過(guò)SpringSecurityOAuth2架構(gòu)實(shí)現(xiàn),符合OAuth2規(guī)范,并保留了良好的系統(tǒng)拓展性、代碼耦合性。資源服務(wù)在權(quán)限框架的幫助下將不再編寫冗余的權(quán)限校驗(yàn)代碼,而權(quán)限服務(wù)也不再對(duì)不同的資源服務(wù)進(jìn)行權(quán)限區(qū)分。圖5-7服務(wù)間進(jìn)行接口調(diào)用權(quán)限校驗(yàn)流程圖資源服務(wù)只需專注于具體的業(yè)務(wù)處理,當(dāng)請(qǐng)求抵達(dá)服務(wù)前,SpringSecurity的權(quán)限相關(guān)Filter會(huì)對(duì)請(qǐng)求攔截并對(duì)當(dāng)前請(qǐng)求進(jìn)行權(quán)限判斷,判斷當(dāng)前請(qǐng)求是否具有相關(guān)的憑據(jù)的請(qǐng)求頭中帶的鍵為“Authorization”的值,也就是所謂的令牌。該資源服務(wù)會(huì)通過(guò)Feign調(diào)用權(quán)限服務(wù)中的令牌信息校驗(yàn)接口,該接口的主要作用是核驗(yàn)服務(wù)中是否存有該令牌的信息并返回對(duì)應(yīng)的結(jié)果,包括了用戶名稱、角色、令牌是否生效、用戶所具有的權(quán)限等。而這也會(huì)帶來(lái)另一個(gè)問(wèn)題,若是服務(wù)間通過(guò)Feign進(jìn)行接口調(diào)用,則在同一請(qǐng)求下,對(duì)同一個(gè)令牌會(huì)進(jìn)行多次的校驗(yàn)。為了解決這個(gè)問(wèn)題,在本系統(tǒng)中利用了AOP面向切面編程與注解的技術(shù),編寫了一用于接口的注解@Inner。首先在網(wǎng)關(guān)中重新配置了一名為清洗過(guò)濾器的Filter,用于清洗請(qǐng)求中的特定信息,在本系統(tǒng)中約定的信息為在請(qǐng)求頭中Key值為FromIn的信息。請(qǐng)求頭中的FromIn信息只允許在服務(wù)間進(jìn)行調(diào)用時(shí),由Feign在請(qǐng)求中添加,而被@Inner注解標(biāo)記的接口在權(quán)限框架中屬于“無(wú)需權(quán)限”即可訪問(wèn)的狀態(tài),這樣既可避免Security的過(guò)濾器對(duì)請(qǐng)求進(jìn)行攔截和校驗(yàn)。但這將引起安全問(wèn)題,這時(shí)候就需要運(yùn)用到請(qǐng)求頭中的FromIn信息。通過(guò)AOP技術(shù)編寫了一前置通知,在執(zhí)行標(biāo)注了@Inner注解的接口業(yè)務(wù)邏輯之前,會(huì)對(duì)當(dāng)前請(qǐng)求的請(qǐng)求頭信息進(jìn)行判斷,判斷是否具有FromIn屬性,如果沒(méi)有則會(huì)被攔截。在本商城系統(tǒng)中,廣泛運(yùn)用的該功能特性,大大降低了權(quán)限服務(wù)的訪問(wèn)壓力,同時(shí)也保證了系統(tǒng)接口的安全性。該管理系統(tǒng)的主界面如圖所示,屬于易用性極高的用戶界面。且前端界面的開(kāi)發(fā)使用了Bootstrap框架技術(shù),使得管理員在不同尺寸的設(shè)備上瀏覽該管理系統(tǒng)的后臺(tái)都能得到良好的交互體驗(yàn)。界面大致分成三板塊,位于界面左側(cè)的菜單、位于界面上方的導(dǎo)航條,以及占據(jù)重要空間的儀盤表。管理系統(tǒng)的菜單位于界面注冊(cè)并支持折疊功能,將菜單選項(xiàng)折疊后儀盤表的顯示面積會(huì)得到增大,方面了管理人員進(jìn)行相關(guān)操作。并對(duì)相關(guān)的菜單選項(xiàng)的展示添加上了一定的動(dòng)畫效果,增加了管理系統(tǒng)界面的美觀性。圖5-8權(quán)限相關(guān)數(shù)據(jù)表設(shè)計(jì)該管理系統(tǒng)對(duì)于菜單的管理并不是固定的,數(shù)據(jù)庫(kù)在設(shè)計(jì)之初預(yù)留了一張名為“sys_menu”的表單,用作系統(tǒng)管理系統(tǒng)的菜單數(shù)據(jù)的存儲(chǔ)。根據(jù)登陸管理員的角色不同,所查詢出的管理系統(tǒng)菜單內(nèi)容也會(huì)有所區(qū)別。但關(guān)于菜單選項(xiàng)的查詢會(huì)隨著菜單的每一次顯示而進(jìn)行,造成不必要的數(shù)據(jù)庫(kù)訪問(wèn)。為了解決該問(wèn)題,后端關(guān)于菜單查詢功能的相關(guān)接口中,引入了基于Redis中間件實(shí)現(xiàn)的緩存功能。在高性能緩存中間件的幫助下,并不是每次菜單的顯示都觸發(fā)數(shù)據(jù)庫(kù)的相關(guān)查詢,查詢的請(qǐng)求會(huì)先經(jīng)過(guò)Redis中間件。Redis中間件的引用降低了一部分的訪問(wèn)壓力,但也帶來(lái)了所謂的緩存與數(shù)據(jù)庫(kù)存儲(chǔ)雙寫的問(wèn)題,對(duì)問(wèn)題進(jìn)行簡(jiǎn)單描述既是管理員對(duì)相關(guān)的數(shù)據(jù)進(jìn)行增刪改操作后,造成的緩存與數(shù)據(jù)庫(kù)數(shù)據(jù)不一致的問(wèn)題。在本管理系統(tǒng)中,允許緩存與數(shù)據(jù)庫(kù)數(shù)據(jù)偶爾有不一致的情況發(fā)生,所以在對(duì)數(shù)據(jù)完成修改后,再對(duì)緩存執(zhí)行刪除操作即可。5.2.2權(quán)限管理功能模塊圖5-9用戶管理界面位于菜單列表第一個(gè)選項(xiàng)的是權(quán)限管理菜單,該選項(xiàng)是菜單列表,權(quán)限管理的菜單選項(xiàng)收納著用戶管理以及角色管理的兩個(gè)功能模塊。關(guān)于用戶管理以及角色管理的相關(guān)接口都由AdminService服務(wù)負(fù)責(zé)提供。不同級(jí)別的管理員由于分配的角色不同,不同的管理員用戶在進(jìn)行登錄后所看到的菜單選項(xiàng)或功能按鈕會(huì)有所不同。按照銷售商城管理系統(tǒng)中的功能需求分析,關(guān)于系統(tǒng)管理內(nèi)用戶權(quán)限的信息僅屬于高權(quán)限用戶可使用功能。在該功能模塊下基于表格的方式實(shí)現(xiàn)信息展示,并為最高權(quán)限的管理員用戶提供基礎(chǔ)的增刪改操作。刪除按鈕被點(diǎn)擊時(shí),會(huì)彈出窗口對(duì)執(zhí)行指令進(jìn)行二次詢問(wèn),防止錯(cuò)誤操作。權(quán)限模塊的存儲(chǔ)系統(tǒng)屬于重要級(jí)別,所以管理員對(duì)信息執(zhí)行確認(rèn)刪除的操作后,系統(tǒng)服務(wù)中的業(yè)務(wù)邏輯層也只是對(duì)數(shù)據(jù)庫(kù)中相關(guān)的信息執(zhí)行邏輯刪除處理。5.2.3系統(tǒng)管理功能模塊圖5-10系統(tǒng)管理界面日志功能的實(shí)現(xiàn)主要依賴于Spring的AOP技術(shù)。AOP又稱面向切面編程。在商城系統(tǒng)的后端模塊中編寫了相關(guān)的“Log”注解,并使用Spring的AOP技術(shù)橫向“切開(kāi)”帶有該注解的方法,使得帶有帶注解的方法在正確執(zhí)行后,會(huì)調(diào)用系統(tǒng)中關(guān)于日志處理的相關(guān)服務(wù),將執(zhí)行方法的用戶信息、方法執(zhí)行的時(shí)間以及方法的名稱信息、執(zhí)行結(jié)果的信息存入名為“sys_log”數(shù)據(jù)表中。日志模塊的信息展示調(diào)用了日志模塊的相關(guān)接口,調(diào)取了存儲(chǔ)在相關(guān)數(shù)據(jù)表中的信息并對(duì)信息做出表格展示。而整個(gè)日志生成的過(guò)程做到了潤(rùn)物無(wú)聲的效果,本系統(tǒng)的所有開(kāi)發(fā)人員僅需在方法上添加注解與日志相關(guān)信息即可。令牌管理功能主要對(duì)管理員使用的JWT信息做記錄。在權(quán)限校驗(yàn)?zāi)K對(duì)用戶輸入的賬戶密碼信息校驗(yàn)成功后生成的Token信息除了會(huì)發(fā)送會(huì)用戶之外,系統(tǒng)也將該令牌進(jìn)行了保存。基于Redis緩存中間件實(shí)現(xiàn)的相關(guān)信息保存功能。在令牌管理的模塊中可對(duì)系統(tǒng)存儲(chǔ)的所有Token信息進(jìn)行查詢,信息包括Token所持有的用戶ID、用戶名稱、令牌編碼、登陸類型、生效剩余時(shí)間等。令牌管理功能預(yù)留一刪除按鈕,用于刪除令牌。如上文所述,Token的相關(guān)信息與標(biāo)識(shí)以約定的規(guī)范采用KV存儲(chǔ)類型,存儲(chǔ)于Redis中。刪除功能的實(shí)現(xiàn)正是在Redis中對(duì)KV類型存儲(chǔ)的Token進(jìn)行刪除,Token的持有者再攜帶該標(biāo)識(shí)訪問(wèn)系統(tǒng)相關(guān)接口時(shí),由于權(quán)限校驗(yàn)?zāi)K并不能在Redis中間件中找到相關(guān)的信息,會(huì)返回?zé)o效標(biāo)識(shí)碼的信息,以至于達(dá)到將用戶“強(qiáng)制下線”的功能。5.2.4商城管理模塊圖5-11手機(jī)管理界面圖5-12訂單管理界面圖5-13商城用戶管理界面商城的管理模塊主要實(shí)現(xiàn)對(duì)銷售商稱中商城信息部分的管理功能,包括用戶管理、手機(jī)信息管理及訂單管理。在手機(jī)管理的模塊下,商城的管理者可完成對(duì)手機(jī)相關(guān)信息的調(diào)整,包括執(zhí)行手機(jī)新上、庫(kù)存調(diào)整、商品信息調(diào)整、價(jià)格調(diào)整等操作。訂單模塊主要向管理者提供像訂單發(fā)貨確認(rèn)、訂單狀態(tài)修改等操作。在用戶管理模塊可查詢用戶相關(guān)的信息,并可對(duì)用戶頭像進(jìn)行更換。管理系統(tǒng)中的信息主要以表格的方式展示,為了提高管理員使用的便利性,管理系統(tǒng)中的所有表格都提供了自定義分頁(yè)的功能,管理員可根據(jù)數(shù)據(jù)量的多少選擇每頁(yè)數(shù)據(jù)展示的量級(jí)。管理系統(tǒng)前端設(shè)計(jì)中更是為表格提供了篩選功能,使用的管理員可供過(guò)表格上方的“篩選”按鈕,將表格中不感興趣的列所隱藏,提高表格對(duì)數(shù)據(jù)的展示能力。5.3移動(dòng)端應(yīng)用開(kāi)發(fā)5.3.1應(yīng)用程序啟動(dòng)與用戶登陸界面圖5-14應(yīng)用啟動(dòng)界面與登錄界面Splash界面是用戶啟動(dòng)應(yīng)用程序后的首界面。它屬于功能性界面,該界面的可視化標(biāo)志著應(yīng)用程序正在初始化,并正在進(jìn)行一系列的初始化操作,例如讀取存儲(chǔ)在本地的應(yīng)用程序的相關(guān)信息、檢測(cè)手機(jī)網(wǎng)絡(luò)連接狀態(tài)、用戶是否已經(jīng)過(guò)進(jìn)行登陸,并連接服務(wù)器獲取應(yīng)用程序的最新版本號(hào)進(jìn)行比對(duì),若需更新則彈出相應(yīng)的提示框。用戶的登陸界面是用戶與應(yīng)用程序可進(jìn)行交互的第一個(gè)界面,由兩個(gè)輸入框以及兩個(gè)按鈕呈線性結(jié)構(gòu)構(gòu)成,盡最大能力的精簡(jiǎn)界面以確保App的易上手性。主題風(fēng)格遵循材料設(shè)計(jì)語(yǔ)言,給予用戶最優(yōu)秀的視覺(jué)體驗(yàn),也為應(yīng)用程序的主題風(fēng)格做下了統(tǒng)一的約定。為了保證的用戶在應(yīng)用程序中感受到的交互體驗(yàn),從Splash界面跳轉(zhuǎn)至登陸界面無(wú)需用戶進(jìn)行點(diǎn)擊的操作,開(kāi)發(fā)者已經(jīng)實(shí)現(xiàn)了相應(yīng)的代碼邏輯。5.3.2用戶注冊(cè)界面圖5-15應(yīng)用程序注冊(cè)界面應(yīng)用程序的注冊(cè)頁(yè)面會(huì)是新用戶與手機(jī)馬特商城進(jìn)行細(xì)致交互的一個(gè)界面。在這個(gè)界面可以完成用戶對(duì)手機(jī)馬特商城注冊(cè)的基本操作。注冊(cè)信息包括郵箱和密碼,其中郵箱會(huì)作為用戶的登錄名。郵箱的輸入信息會(huì)在客戶端中通過(guò)一個(gè)郵箱匹配的正則表達(dá)式進(jìn)行校驗(yàn),只有符合郵箱格式的信息才會(huì)被通過(guò)執(zhí)行。若輸入不符合規(guī)則會(huì)給予相應(yīng)提示,且禁止登陸按鈕的點(diǎn)擊事件觸發(fā),以降低服務(wù)器壓力且防止流量攻擊,當(dāng)然,在系統(tǒng)后端的服務(wù)器接口中,也對(duì)請(qǐng)求的數(shù)據(jù)進(jìn)行了相應(yīng)的判斷,避免不法分子繞過(guò)客戶端發(fā)送包含非法數(shù)據(jù)的請(qǐng)求。5.3.3商品瀏覽與商品詳情界面圖5-16應(yīng)用程序商品瀏覽界面商品瀏覽界面是應(yīng)用程序的門戶界面,所以不論是設(shè)計(jì)風(fēng)格或是界面的交互設(shè)計(jì)都應(yīng)當(dāng)呈現(xiàn)最優(yōu)的效果。不同于常見(jiàn)豎直列表,在該界面用戶是通過(guò)左右橫滑瀏覽商品的信息,并且支持右拉刷新。商品的信息存放于應(yīng)用程序的主題色的卡片中,符合扁平化的設(shè)計(jì)潮流??ㄆ瑒?dòng)流暢,滑動(dòng)至列表邊緣將觸發(fā)列表的回彈效果。商品的類別位于卡片的上方,取消類別與類別間的區(qū)分效果,是類別列表在界面中融為整體,減少界面的切割感。類別同樣以橫向滑動(dòng)為主,與底下的卡片做設(shè)計(jì)風(fēng)格的統(tǒng)一。在商品的瀏覽界面,點(diǎn)擊商品的信息卡片即可進(jìn)入該商品的詳細(xì)介紹頁(yè)面。在卡片式以及大色塊的搭配下描述該商品的相關(guān)信息,顯示“添加進(jìn)購(gòu)物車”的功能按鈕。該界面的最大特色是與商品的瀏覽界面形成了一整體的風(fēng)格。除了統(tǒng)一的卡片式設(shè)計(jì)語(yǔ)言外,商品瀏覽界面與商品詳細(xì)信息的界面之間通過(guò)AnimatedBuilder的動(dòng)畫構(gòu)造器進(jìn)行銜接。用戶在瀏覽界面點(diǎn)擊卡片后,卡片中商品的略縮圖會(huì)通過(guò)動(dòng)畫進(jìn)行“移動(dòng)”到對(duì)應(yīng)商品詳細(xì)界面的商品展示圖位置。這使得兩個(gè)界面在視覺(jué)效果上有了關(guān)聯(lián)。從詳細(xì)界面進(jìn)行返回的動(dòng)畫效果亦然。5.3.4購(gòu)物車界面以及訂單生成圖5-17應(yīng)用程序購(gòu)物車與下單界面用戶通過(guò)點(diǎn)擊圖標(biāo)為購(gòu)物車Icon即可進(jìn)入用戶的購(gòu)物車中,不同于其他頁(yè)面的從右滑入的Cupertino風(fēng)格,購(gòu)物車頁(yè)面的載入方法類似于Android的Material,由下至上載入,上至下滑出,也正因此在購(gòu)物車界面中位于左上角的返回按鈕的箭頭朝向向下。 購(gòu)物車頁(yè)面的設(shè)計(jì)總共由經(jīng)典的三部分構(gòu)成:header、body、footer,header提供路由相應(yīng)的信息以及功能,由頁(yè)面的名稱和返回Icon構(gòu)成。而頁(yè)面的body也就是該頁(yè)面的核心區(qū)域占據(jù)了頁(yè)面的較大面積,以列表的方式呈現(xiàn)購(gòu)物車中的每一項(xiàng)手機(jī)信息,包括有手機(jī)名稱、數(shù)量、單價(jià)。商品的數(shù)量與數(shù)量的增減功能集中成了一個(gè)控件,使得列表的視覺(jué)效果更加簡(jiǎn)潔??ㄆ挠疑辖歉缴狭艘粋€(gè)浮動(dòng)的“X”Icon,用于快速的刪除購(gòu)物車中的該商品。購(gòu)物車界面的footer的信息成線性布局,顯示了該購(gòu)物車的總價(jià)。位于footer的浮動(dòng)按鈕“Checkout”,添加了陰影以及圓角,浮動(dòng)與圓潤(rùn)的設(shè)計(jì)使得該按鈕成為購(gòu)物車頁(yè)面最為吸睛的一個(gè)按鍵,具有生成訂單并跳轉(zhuǎn)結(jié)賬功能。點(diǎn)擊“Checkout”按鈕,應(yīng)用程序會(huì)跳轉(zhuǎn)至訂單的生成界面,在該界面具有即將生成的訂單的相關(guān)信息,如購(gòu)買商品的數(shù)量與結(jié)賬價(jià)格、配送地址以及預(yù)計(jì)配送時(shí)間。位于界面最頂端的既是當(dāng)前訂單的配送地址信息以及聯(lián)絡(luò)郵箱,可通過(guò)點(diǎn)擊相應(yīng)按鈕跳轉(zhuǎn)至地址管理的界面更換配送地址。界面最底下的“PlaceOrder”按鈕與購(gòu)物車的“Checkout”按鈕的設(shè)計(jì)要素相同,并使得按鈕成為當(dāng)前頁(yè)面上最引人的選項(xiàng)。在“PlaceOrder”點(diǎn)擊后,應(yīng)用程序會(huì)與服務(wù)器進(jìn)行一次網(wǎng)絡(luò)通訊,應(yīng)用程序會(huì)將當(dāng)前訂單的商品數(shù)量發(fā)送至服務(wù)器中,服務(wù)器會(huì)對(duì)商品庫(kù)存、金額、配送地址等信息做判斷處理,并將處理的結(jié)果反饋至應(yīng)用程序。若當(dāng)前訂單的數(shù)量生成合法,則在當(dāng)前界面的底部彈出訂單生成成功的ButtonSheet,并引導(dǎo)用戶對(duì)訂單進(jìn)行支付。5.3.5訂單列表與訂單詳情界面圖5-18應(yīng)用程序訂單查詢界面訂單列表的界面設(shè)計(jì)布局以列表控件為主,位于界面的正中心位置,底下添加了可跳轉(zhuǎn)至主界面的FloatButton以點(diǎn)綴該界面。訂單列表項(xiàng)以卡片式風(fēng)格為主,修改卡片以圓角矩形、添加對(duì)應(yīng)的陰影設(shè)計(jì),使得每項(xiàng)訂單信息以“浮現(xiàn)”與面板的視覺(jué)體驗(yàn)。訂單列表項(xiàng)顯示大標(biāo)題、訂單狀態(tài)、訂單金額等訂單基本信息。約定以訂單生成的時(shí)間作為大標(biāo)題的內(nèi)容,小標(biāo)題顯示為此時(shí)訂單的狀態(tài)。設(shè)計(jì)的基礎(chǔ)是使用簡(jiǎn)單的控件,以突出每一項(xiàng)訂單的信息。不同于商品主界面的右滑動(dòng)刷新,訂單列表的信息通過(guò)下拉以獲取當(dāng)前登錄用戶的賬戶上最新的訂單列表信息。通過(guò)名為“RefreshController”的UI控件實(shí)現(xiàn)這一功能,下拉刷新的控件遵循名為“BezierCircle”的Android設(shè)計(jì)風(fēng)格。訂單的詳細(xì)界面顯示與訂單生成的頁(yè)面采用同一種展示信息的設(shè)計(jì)語(yǔ)言,與之不同的是底下的功能按鈕。底下的功能按鈕的顯示與訂單的狀態(tài)相關(guān),訂單共有八種狀態(tài),不同狀態(tài)下的訂單信息會(huì)具有不同的功能按鈕,例如“待支付”狀態(tài)的訂單訂單底下的功能按鈕會(huì)是“PAY”和“CANCELORDER”的功能按鈕。當(dāng)然,不同的按鈕也會(huì)觸發(fā)不同的事件,所以該界面被設(shè)計(jì)成了Stateful的界面,在按鈕點(diǎn)擊后,界面會(huì)基于服務(wù)器做出的響應(yīng)信息做出更新。5.3.6應(yīng)用程序設(shè)置界面圖5-19應(yīng)用程序Profile界面該界面相當(dāng)于應(yīng)用程序的一個(gè)菜單中心,集成了應(yīng)充程序訂單列表、進(jìn)入地址列表的功能入口,并顯示了登陸用戶的相關(guān)信息如賬戶余額、頭像。以統(tǒng)一應(yīng)用程序的設(shè)計(jì)語(yǔ)言,該界面依舊以藍(lán)色作為主色調(diào)并將菜單按鈕放置于一張“卡片”中。用戶的頭像放置于卡片的中間,點(diǎn)擊頭像將會(huì)調(diào)用系統(tǒng)的相關(guān)接口,用戶在給予應(yīng)用程序相關(guān)的權(quán)限后可自行選擇喜歡的圖片上傳更新頭像。5.3.7地址信息添加界面圖5-20應(yīng)用程序地址選擇界面在該界面用戶可以實(shí)現(xiàn)地址添加的功能,供用戶進(jìn)行輸入的區(qū)域共有兩塊:所屬省市的選擇、地址的詳細(xì)信息。是為了規(guī)范用戶輸入的省市內(nèi)容,也是為了更好的用戶體驗(yàn),省市的選擇使用了命名為“CityPicker”的控件,在該控件的支持下,用戶通過(guò)滑動(dòng)即可選擇所屬的省份、城市、區(qū)域。確認(rèn)的按鈕以Icon圖表的“+”號(hào)作為提示,添加成功系統(tǒng)會(huì)給予提示并將該界面“彈出”。其中地址的詳細(xì)信息由用戶進(jìn)行輸入,但輸入的字符串做出了大于5個(gè)單元、小于3

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論