綜合性B2C電商平臺設計與實現

2023-02-20 分類：網站建設

【摘要】
近些年，隨著當今世界的互聯網發展，為生活的方方面面提供了極大的便利。其中最為典型的電商借著這股東風已經成為了社會不可或缺的一環。相關行業也在不斷拓展和完善，對經濟社會生活產生了極大的促進，同時也成為我國經濟發展的重要一環。
電商平臺的使用，通過網上購物為人們在生活上提供極大的便利，使人們不受時間和空間的限制，在家里就能實現購物。同時對于商家來說，商家可以入駐平臺實現商品發布和出售，在線上實現訂單的過程，而只需要通過線下發貨和物流信息的發布完成訂單，能極大增加商家的銷售渠道和在時間上的便利。
此平臺的的研究工作中，結合實際情況對比，在使用分布式服務架構(RPC)的前提下，結合服務治理框架dubbo，zookeeper作為注冊中心，并結合使用了Spring、SpringMvc、Mybatis的SSM框架。借助Linux虛擬機，搭載各類第三方技術，比如vsftpd文件上傳服務器；nginx反向代理，負載均衡；redis集群配置主從復用，讀寫分離，搭建主備切換；solr搜索引擎和sso單點登錄等。
利用相關技術開發平臺，先后實現完成了后臺管理系統和前臺門戶系統。后臺完成簡單的商品管理功能，權限屬于管理員。前臺則實現完成了基本的用戶注冊登錄；首頁商品的瀏覽和搜索；經典的電商平臺購物車功能；訂單核對提交訂單；支付寶在線支付功能；前后臺的單點登錄功能。前后臺共同構成了一個完整的B2C電商平臺。
就本平臺的功能和測試結果來看，綜合性B2C電商平臺滿足了預期的用戶和管理功能需求，實現了平臺的架構的解耦分層，良好的高并發和高可用性能。測試結果證明了分布式架構在電商平臺中的高效性和可行性，獲得了應有的使用價值。
【關鍵詞】分布式架構；SSM；Linux；電商平臺
[錨點] 1前言
[錨點] [錨點] 1.1 課題的背景近些年，隨著當今世界的互聯網發展，為生活的方方面面提供了極大的便利。其中最為典型的電商借著這股東風已經成為了社會不可或缺的一環。相關行業也在不斷拓展和完善，對經濟社會生活產生了極大的促進，同時也成為我國經濟發展的重要一環。1.2 目的和意義電商平臺的使用，通過網上購物為人們在生活上提供極大的便利，使人們不受時間和空間的限制，在家里就能實現購物。同時對于商家來說，商家可以入駐平臺實現商品發布和出售，在線上實現訂單的過程，而只需要通過線下發貨和物流信息的發布完成訂單，能極大增加商家的銷售渠道和在時間上的便利。
電商平臺給人們的生活帶來了極大的變化，極大的發揮了消費水平，促進了經濟發展。在電商平臺上購物也不受時間和空間上的影響，方便業務管理，也解決了消費者的購物問題。1.3 國內外現狀和發展趨勢網絡營銷的熱潮已經席卷全球，國內外企業的生存競爭空間已經從傳統市場轉向網絡空間市場。網上購物已經滲透到國內外市場的方方面面，極大的改變了人們的工作和生活方式。天貓雙十一成交額的逐年變化是一個好的提現，從2009年的0.5億元到現在2021年的5403億元，實現了大跳躍。2021年上半年我國網絡購物用戶規模為8.12億人，占網民整體的80.3%。人們的生活已經離不開網上購物，特別是在如今的疫情時期，網絡電商平臺的作用更加重要。
在如今互聯網的發展帶動下，足不出戶的網上購物基本成為必需。在未來會有越來越多的人們加入這個行業。網絡電商平臺也將會朝著全球化，個性化，專業化的趨勢發展和改善，以至于改變全球的經濟結構，前途不可估量。1.4 論文架構本論文通過七個部分詳細講述綜合性B2C電商平臺的設計與實現。
第一部分前言，分析課題背景和國內外現狀，說明目的和意義，表明研究內容，簡述本文架構。
第二部分電商平臺的相關技術，分別對綜合性B2C電商平臺所運用到的相關技術加以介紹。
第三部分是電商平臺的需求分析，先后分析功能性和非功能性需求，且加以用例圖描述。
第四部分是電商平臺概要設計，通過第三部門的需求分析對平臺從架構搭建到各類服務組件，從個功能模塊設計到數據庫設計。
第五部分是電商平臺詳細設計與實現，從平臺架構詳細設計到平臺功能詳細設計，展示核心功能接口和部分核心代碼，且附上最終的頁面效果。
第六部分是電商平臺測試，對平臺進行細致的功能測試。
綜上所有，在論文的最后部分做了相關工作的總結與展望。
[錨點] 2 電商平臺的相關技術

[錨點] 2.1分布式服務架構（RPC）互聯網的快速發展下，傳統的垂直應用架構已經無法滿足日漸壯大中的網站規模的需要，分布式服務和流動計算架構就成如今新的血液，甚至于微服務架構。
圖2-1開發模式的演變
傳統的單一應用架構，在網站流量很少的情況下，雖然只需要一個應用，但是缺點也很明顯。由于所有功能都部署在一起，即使成本很低，但是在應用功能不斷增多的情況下，隨著代碼量的不斷增大，也變得越來越難維護。
垂直應用架構，為了提高效率將應用分開成若干個不相關的應用。但是缺點也依然是明顯的，在這個架構下，相同邏輯的代碼需要反復復制，不得復用。
分布式服務架構，隨著垂直應用的增加，各個應用之間的交互是不可避免的。分布式服務架構分離獨立出核心業務服務，構成一個穩定的服務中心，前端的應用程序能夠迅速應對變化的市場需求。分布式服務架構的缺點是，服務的增加，各服務地址管理成為必要，調用依賴關系也更為復雜,服務狀態不好管理，沒法根據實際服務情況進行動態管理。
因此，本平臺的開發，在分布式服務架構的基礎上，為了解決其缺點，結合服務治理框架dubbo，zookeeper作為注冊中心，以達到服務統一調度管理的目的，解決遠程調用的難題，開發也從面向對象跳轉到了面向服務，比以往更加的松耦合,而實際上這個時候已經成為了一個微服務[9]架構。
[錨點] 2.2 RPC協議（Remote Procedure Call Protocol）即不需要理解底層網絡技術，而是通過網絡在遠程計算機程序上請求程序的遠程過程調用協議。RPC協議假設存在若干傳輸協議，諸如tcp或udp，在通信程序之間傳輸信息數據。在OSI網絡協議模型中，RPC實現了傳輸層和應用層之間的跨界，從而有助于開發包含網絡分布式多程序的應用。
RPC是客戶端/服務器模式。客戶端請求程序，服務器提供程序。客戶端調用進程，向服務進程發出調用數據，并等待數據的響應。服務器在呼叫數據到達之前，最初保持睡眠狀態。一個調用數據到達的情況下,服務器得到進程參數,結算結果,應答數據返還,其次等待下一個數據,最終客戶端接收應答數據和結果,繼續執行調用。
圖2-2RPC過程處理示例圖
從上圖中可以清晰的看出RPC的執行流程。
[錨點] 2.3服務治理框架Dubbo和注冊中心Zookeeper服務治理框架Dubbo[3]：
Dubbo是Alibaba開發推出的一個遠程調用框架。Dubbo具有基于接口的遠程調用，負載均衡和容錯，服務的自動注冊和發現三個核心功能。在阿里巴巴內部，Dubbo得到了廣泛的應用，很多大型互聯網公司也在用，比如考拉，當當，京東等等。
Dubbo Architecture：
圖2-3Dubbo工作原理示例圖
節點角色說明：
Provider：服務提供方
Consumer：服務消費方
Register：注冊中心
Moniter：監控中心
Container：服務運行容器
調用關系說明：
1.服務容器負責啟動、加載、運行服務提供者
2.服務提供者啟動并向注冊中心注冊自身提供的服務
3.服務消費者啟動并向注冊中心訂閱自己所需的服務
4.注冊中心列表給消費者返回提供者地址，如果有所變動注冊中心會基于長連接發送變動數據給消費者
5.基于軟負載均衡算法，消費者在地址列表里選擇一臺提供者調用，如果失敗則調用另一臺
6.服務提供者和服務消費者在內存中累計的調用次數和調用時間定時每分鐘發送一次統計數據至監控中心
注冊中心Zookeeper：
Zookeeper作為分布式應用程序協調服務，開源實現了谷歌的Chubby，所提供的功能有：分布式同步，配置維護，域名服務，租服務等，是一個為分布式應用提供一致性服務的軟件。
在本平臺中，Zookeeper身為服務注冊中心，注冊著編寫的服務供客戶端遠程調用。
Zookeeper注冊中心是Dubbo官方推薦，負責服務地址的注冊和發現，也就是目錄服務。適合作為Dubbo的服務注冊中心在于其適合生產環境且工業強度高。
[錨點] 2.4 Spring、SpringMVC和Mybatis框架
[錨點] 2.4.1Spring框架Spring是為了解決企業級應用開發的復雜性，簡便Java開發而誕生的，是一個由Rod Johnson開發的為開發者提供一站式應用開發平臺的輕量級開源Java框架。Spring為Java應用程序開發提供全面的基礎架構支持，所以Java開發者可以致力于應用程序的開發。在JavaEE開發中，支持POJO和JavaBean開發方式，使應用面向接口開發，充分支持OO（面向對象）設計方法；Spring通過IOC容器實現對象耦合關系的管理，并實現依賴反轉，將對象之間的依賴關系交給IOC容器，實現解耦。
Spring豐富的功能給企業級開發提供極大便利。依賴注入（DI）和面向切面編程（AOP）是這些功能的底層依賴。Spring框架的核心是IOC容器和AOP模塊。通過IOC容器管理POJO對象以及他們之間的耦合關系；通過AOP以動態非侵入的方式增強服務，把遍布于應用各層的功能分離出來形成可重用的功能組件。
圖2-4 Spring5模塊結構圖
[錨點] 2.4.2 SpringMVC框架Spring MVC[10]是一個基于Java的輕量級web框架，它實現了請求驅動型MVC設計模式。通過分離模型視圖控制器，解耦web層的職責，將復雜的web應用程序劃分為幾個具有清晰邏輯的部分，簡化了開發，減少了錯誤，促進了團隊開發人員之間的合作。
Spring MVC中有許多重要組件，如下：
（1）前端控制器DispatcherServlet
作用：接收請求、響應結果，相當于轉發器，有了DispatcherServlet就減少了其它組件之間的耦合度。
（2）處理器映射器HandlerMapping
作用：根據請求的URL來查找Handler
（3）處理器適配器HandlerAdapter
（4）處理器Handler（需要程序員開發）
（5）視圖解析器ViewResolver（不需要程序員開發）
作用：進行視圖的解析，根據視圖邏輯名解析成真正的視圖（view）
（6）視圖View（需要程序員開發jsp）
View是一個接口，它的實現類支持不同的視圖類型（jsp，freemarker，pdf等等）
Spring MVC的工作流程：
圖2-5 Spring MVC工作流程圖
[錨點] 2.4.3 Mybatis框架Mybatis是一款優秀的持久層框架，一個半 ORM（對象關系映射）框架，它支持定制化 SQL、存儲過程以及高級映射。Mybatis避免了幾乎所有的 JDBC代碼和手動設置參數以及獲取結果集。
Mybatis在查詢關聯對象或關聯集合對象時，需要手動編寫sql來完成，所以，稱之為半自動ORM映射工具。ORM（Object Relational Mapping），對象關系映射，是一種為了解決關系型數據庫數據與簡單Java對象（POJO）的映射關系的技術。Hibernate屬于全自動ORM映射工具，使用Hibernate查詢關聯對象或者關聯集合對象時，可以根據對象關系模型直接獲取，所以它是全自動的。
Mybatis工作原理：
圖2-6 Mybatis工作原理流程圖
[錨點] 2.5 Vsftpd文件服務器和Nginx服務器Vsftpd文件服務器：
Vsftpd是一個運行在Unix類操作系統上的服務器，也能運行在比如Linux[1]，Solaris，Bsd，Irix上。本系統使用中，Vsftpd運行在Linux上，它相比于其他的ftp服務器提供了更多的支持，也是Linux發行版里廣為推薦的ftp服務器程序。
本平臺使用Vsftpd文件上傳服務器，將文件（圖片）上傳至該服務器上，進行統一的獨立管理，需要拿到服務器上文件（圖片）的時候，只需要攜帶地址發出請求即可。
Nginx服務器[8]：
Nginx是一個高性能、輕量級的HTTP和反向代理web服務器。它也是一個電子郵件服務器，提供IMAP / POP3 / SMTP服務，由俄羅斯人Igor sesoyev開發，源代碼以類似BSD許可證的形式發布。穩定性高，系統資源消耗低，配置文件簡單，功能集豐富是其優點，在中國大陸得到了廣泛的應用。
正因為其高性能的反向代理和負載均衡，本平臺中選擇使用Nginx，并將其搭載在Linux上，配置了三臺Tomcat[2]服務器的反向代理負載均衡。
[錨點] 2.6 Redis緩存數據庫Redis[5]是一個ANSI C語言編寫，支持網絡，可基于內存也可持久化的日志型，Key-Value數據庫，而且提供了許多語言的API，是一個開源的非關系型數據庫。Redis的誕生實際上是因為Mysql數據庫的低性能，所以一家意大利公司的創始人Salvatore Sanfilippo為了避免這一問題而親自開發了Redis緩存數據庫，事實證明，Redis的高性能是Mysql所無法匹及的。
Redis所支持的語言有很多，比如常用的Java，C,C++，Python，Php，Go等等。在數據類型上，Redis支持string，set，hash，list，sorted set這五種。
本平臺中Redis正是用于數據庫緩存，存儲前臺數據量龐大的數據，是介于持久層和服務層之間的，配置了主備切換，讀寫分離。比如前臺商品分類欄，當刷新頁面時，會先從Redis緩存中查詢數據，若存在緩存則返回數據，若不存在緩存，這個時候Redis便會訪問Mysql數據庫得到數據返回，并在Redis上相應緩存。以這種方式打到減緩Mysql數據庫壓力的目的，提升商城平臺的整體性能。
[錨點] 2.7 Solr搜索引擎Apache Solr是一個獨立的企業級搜索應用服務器，其對外提供類似Web-service的API接口。用戶經過HTTP請求，且得到XML格式的返回結果，而且通過用類似REST的HTTP API保證我們能可以使用Solr通過幾乎任何編程語言。在如今的生活里，搜索引擎的使用不可或缺，各式各樣的網站往往都有搜索功能，而搜索伴隨的是相當龐大的資源消耗，這對于數據庫來說是相當沉重的，沉重的加載難免會拖慢甚至拖垮我們的應用，因此搜索引擎為我們解決了這一問題。
Solr實際上是基于Lucene封裝的，Lucene同樣是一個搜索引擎工具，Solr和Lucene兩者的索引庫也是公用的。不過因為Solr是基于Lucene封裝的，因此Solr的操作更加的簡單人性化，它是一個企業級的開源搜索平臺，廣泛被用于構建搜索應用程序，是建立在Lucene之上的，具有高速可擴展以及快速的性能。
相比于Mysql，Solr是一個不同的產品，雖然兩者都有索引，但是索引的文件并不是同種文件，前者的查詢和后者的搜索也不是一個概念。Mysql為Solr提供了索引數據的來源，Solr從Mysql中存儲的數據進行分析得出索引庫。
[錨點] 2.8 SSO單點登錄SSO單點登錄是一種流行的企業業務集成解決方案。SSO是在多個應用程序系統中定義的。用戶可以通過一次登錄訪問所有相互信任的應用系統。在實現單點登錄時，所有應用系統都需要共享一個身份認證系統，這是單點登錄的前提條件之一。應用系統應該能夠識別并提取票據，當用戶首次登錄時能夠識別登錄的用戶，而認證系統應該對票據進行驗證，驗證其合法性。
圖2-7 SSO實現原理圖
如果用戶第一次訪問應用系統時沒有登錄，則會被定向到認證系統進行登錄。首先，根據用戶輸入的登錄信息對用戶進行身份驗證。如果認證通過，經過身份驗證票將返回給用戶，然后用戶可以使用這張票作為身份驗證票訪問其他應用系統，收到票后，應用系統將其發送給驗證確認其合法性的驗證系統。一旦通過了驗證，用戶就可以訪問其他系統而無需再次登錄。
[錨點] 2.9 RabbitMQ消息隊列消息隊列（MQ）在計算機科學里是一種進程間通信或同一進程的不同線程間的通信方式，在軟件里處理一系列來自用戶的輸入。MQ的模型是消費者-生產者，一端不斷寫入消息到消息隊列中，另一端訂閱或讀取隊列中的消息，MQ遵循了AMQP協議，本平臺選用的RabbitMQ是眾多消息隊列開源實現中的一個。
RabbitMQ是一個開源的AMQP實現，以Erlang語言編寫的服務器端，支持數種客戶端，比如常用的JAVA,PYTHON,RUBY,C等等，同時也支持AJAX。因為其在易用性，擴展性，高可用性等方面表現出色，所以被廣泛應用于分布式系統中存儲轉發信息。
使用RabbitMQ的原因有很多，比如基于AMQP協議，高并發，高性能，高可用，支持插件和多語音，由于被廣泛使用，所以有強大的社區支持。對于AMQP,這是一個高級消息隊列協議，面向消息，隊列，路由，可靠性，安全，是應用層協議的一個開放標準，為面向消息的中間件而設計。
[錨點] 2.10 其他第三方技術支付寶開放平臺（Alipay）：
使用支付寶開放平臺官方提供的支付寶支付API實現商城的在線支付，選擇的是平臺里的沙箱環境實現支付寶在線支付的集成。
圖2-8 支付寶開放平臺官方主頁
郵件發送：
郵件發送上選擇的是網易163郵箱，通過開啟網易163郵箱里的SMTP服務，然后在系統里編程開發實現注冊成功后郵件的發送，發送方是網易163郵箱，接收方是自己輸入的存在的郵箱，不限于只是網易163郵箱。
圖2-9 163郵箱設置截圖
GEETEST極驗驗證：
GEETEST極驗驗證在計算機領域里用于區別機器人和自然人，通過官方提供的方式進行簡單集成，就能給開發者提供安全、便攜的云端驗證服務。
圖2-10 GEETEST極驗驗證官方行為驗證截圖
[錨點] 3 電商平臺的需求分析在本章中，將會對本電商平臺的需求進行分析，從功能需求和非功能需求兩個角度分析。功能需求是從用戶的角度出發分析各個平臺功能的需求和操作流程，非功能需求則是分析用戶和平臺性能上的使用體驗，安全可靠性等。
這是本次平臺開發最初的一環也是最重要的，需求分析能為接下去的平臺開發提供藍圖，給平臺開發設計做到極大的便利。
[錨點] 3.1 平臺功能需求簡述后臺管理系統和前臺門戶系統。后臺完成簡單的商品管理功能，權限屬于管理員。前臺則實現完成了基本的用戶注冊登錄；首頁商品的瀏覽和搜索；訂單核對提交訂單；前后臺的單點登錄功能；在購物車里提交訂單填寫需要的信息，并跳轉支付頁面完成在線支付。如圖所示：
圖3-1 系統功能劃分圖
[錨點] 3.2 平臺功能需求分析
[錨點] 3.2.1 注冊登錄功能需求分析注冊登錄功能是電商平臺上的一個基礎功能，注冊用戶的信息會被得到保存以供平臺為用戶提供相應的服務。在此平臺里，未注冊的用戶身為游客，不擁有查看或添加至購物車，提交訂單，在線支付等功能。注冊登錄后擁有使用前臺門戶系統的所有功能的權限，具體如下：
未注冊用戶：進入首頁，需要注冊時可以點擊“免費注冊”按鈕跳轉至注冊頁面，填寫相應的正確信息之后，進行極驗驗證和勾選同意協議最后點擊進行注冊，信息錯誤的話給予提示以重新填寫注冊。注冊成功后在頁面上給用戶反饋提示“注冊成功”并跳轉登錄頁面，后臺發送注冊郵件到對應的用戶郵箱。
已注冊用戶：有兩種方式可以進入到登錄頁面，第一種是新注冊完成后的自動跳轉至登錄頁面，第二種則是可以在平臺首頁上點擊“登錄”按鈕跳轉至登錄頁面。進入登錄頁面之后，用戶根據頁面提示輸入用戶名和密碼，填寫正確的話提示“登錄成功”并跳轉至平臺首頁；填寫錯誤的話則提示“用戶名或密碼錯誤”，重新輸入再次登錄。如圖所示：
[錨點] 圖3-2注冊登錄功能用例圖
[錨點] 3.2.2 后臺商品管理功能需求分析平臺管理員通過后臺網址訪問進入后臺登錄頁面，在正確輸入用戶名、密碼和驗證碼之后成功登陸則跳轉至后臺首頁。后臺中有商品管理這一功能模塊，其中分別有五個功能：
商品分類：對商品分類實行分級管理，所有商品分類被查詢出后分級顯示在頁面上，管理員可以進行新增分類，編輯修改分類并保存，刪除分類的操作。
商品列表：進入頁面后所有商品被后臺查詢出后分頁顯示在頁面上，頁面處理后可以進行上下頁的切換和相應頁碼的跳轉。可以通過選擇分類，品牌或者關鍵字搜索出對應的商品。管理員可以新增商品，編輯和修改商品信息（包括通用信息，商品相冊，商品模型等），刪除商品。
商品模型：商品模型用于規定某一類商品共有規格和屬性的集合。商品模型被后臺查詢后顯示在頁面上，管理員可以新增商品模型，編輯和修改商品模型信息和刪除商品模型。
商品規格：商品模型下的一個子集，可以選擇分類篩選查詢規格顯示在頁面，管理員可以新增商品規格，編輯修改規格信息和刪除規格。
商品屬性：商品模型下的另一個子集，可以選擇分類篩選查詢屬性顯示在頁面，管理員可以新增商品屬性，編輯修改屬性信息和刪除屬性。如圖所示：
圖3-3 商品管理功能用例圖
[錨點] 3.2.3 前臺商品搜索功能需求分析前臺上的搜索框為用戶提供方便快捷的商品搜索，這里利用到的是Solr搜索引擎。用戶可以通過輸入商品關鍵字，名稱或者是品牌來搜索商品，搜索到的商品信息會返顯在前臺頁面上，達到更加方便人性化的目的，而不需要在頁面上逐個瀏覽尋找商品。這里的搜索功能并不受注冊登錄的影響，即使是以游客的身份訪問前臺也可以使用搜索功能。
流程：用戶進入平臺首頁點擊搜索框，輸入關鍵字，商品名稱或者品牌名稱后點擊“搜索”按鈕。如果搜索的商品存在則搜索成功，相應的商品返顯在頁面；如果搜索的商品不存在則搜索失敗，頁面顯示空白。如圖所示：
[錨點] 圖3-4搜索功能用例圖
[錨點] 3.2.4 前臺購物車功能需求分析平臺上的購物車功能用于存儲用戶想要購買的商品或者所以喜愛的商品，購物車列表里顯示這用戶所添加的商品信息，包括商品名稱，數量，價格等，用戶可以對其進行相應操作，另外購物車功能不支持游客身份使用。
向購物車添加和保存物品：用戶可以通過單擊商品信息欄中的購物車圖標按鈕向購物車添加物品，并可以重復添加。點擊頁面上的購物車按鈕，跳轉到購物車頁面，顯示用戶添加到購物車中的所有商品（包括商品信息、總數量和總價），用戶可以修改相應商品的數量。
刪除購物車中的商品：用戶可以刪除單個商品或清空購物車，相應的數量和價格會隨著刪除而改變。
修改購物車中的商品數量：用戶可以點擊“+”“-”按鈕來修改購物車中的商品數量，相應的數量和價格也會隨著數量的變化而變化。
去結算：購物車頁面里的去結算按鈕，結算購物車商品并跳轉至訂單頁面。
[錨點] 圖3-5 購物車功能用例圖
[錨點] 3.2.5 前臺訂單功能需求分析提交訂單這一功能，一是給用戶核對訂單信息，包括商品清單，地址信息，價格等等；二是用戶點擊提交訂單按鈕跳轉至支付頁面，這一功能不支持游客身份使用。
用戶在購物車點擊“去結算”按鈕跳轉至核對訂單頁面。
進入核對訂單頁面后，用戶核對商品清單，價格，地址等等信息。
用戶確認無誤后，點擊“提交訂單”按鈕跳轉至訂單提交成功頁面，于此同時，購物車里的商品需要得到清空，相應的后臺數據庫也是，可以點擊“去付款”按鈕跳轉支付頁面。如圖所示：
圖3-6 提交訂單功能用例圖
[錨點] 3.2.6 前臺支付功能需求分析支付功能為用戶提供虛擬的在線支付，采用的是支付寶開放平臺的支付寶在線支付體驗，在登錄相應支付寶賬號之后便可點擊支付完成購買。
在提交訂單成功頁面點擊“去付款”按鈕跳轉至支付頁面。
登錄用戶支付寶賬號后，可以進行支付購買，不支付的話訂單會處以未支付的狀態在一定時間之后消除。
支付成功后，自動跳轉只平臺首頁，后臺相應生成訂單信息，支付時間等。
[錨點] 圖3-7支付功能用例圖
[錨點] 3.3 平臺非功能需求分析效率性能：
為了給用戶良好的體驗，本電商平臺在海量數據下也要具備較高性能的能力，盡量控制用戶請求的響應時長相對較低，還要做到高并發量滿足平臺的高并發需求。
安全性[7]：
因為此平臺是供用戶購物的，所以會有很多的用戶信息，比如基本的用戶賬號密碼，郵箱手機號，地址等。需要確保絕對的安全性，以保證用戶的相關信息安全保密，避免不必要的非法操作而導致信息泄露造成損失。
可靠性：
本平臺是在分布式架構下開發的微服務系統，多個子系統組成。需要確保整個平臺的可靠性，在某些特定環境下也不易出錯，還要考慮某個子系統故障時盡量不影響其他系統的使用。
可擴展性：
作為一個綜合的電商平臺，在考慮必要的效率和安全可靠性能下同樣也得考慮未來后續平臺的優化升級。這就需要一個良好擴展性，減少未來優化升級開發中不必要的麻煩，以便更好的維護平臺。
[錨點] 4 電商平臺概要設計本章的概要設計面向開發者對用戶需求從構建系統的角度進行重構，包含四部分。一個是平臺整體系統架構的設計；第二個是平臺相關服務器的架構設計；第三個則是根據用戶的功能需求進行功能模塊的概要設計；最后一個是數據庫的設計。
[錨點] 4.1 平臺系統架構設計平臺在基于MVC的模式下，在三層架構的基礎下設計分布式服務架構，做到面向服務。微服務方面使用Dubbo服務治理框架和Zookeeper注冊中心構建RPC框架，實現遠程調用和服務的統一調度管理。如圖所示：
圖4-1 電商平臺整體架構設計圖
[錨點] 1.表現層：
這是電商平臺的業務控制層，業務上包括前臺門戶系統，后臺管理系統，搜索系統和訂單系統。控制層根據客戶端瀏覽器發出的不同請求調用對應的業務控制模塊。不同的Controller為不同的請求服務，調用服務層且以View的形式返回。
[錨點] 2.服務層：
服務層在三層架構中起到一個承上啟下的作用，對下使用持久層的接口，對上為控制層提供接口，作為業務邏輯層，一個Service方法完成一個功能。
[錨點] 3.持久層：
起到與數據庫通信的作用，且為服務層提供接口，是一個數據訪問層。當服務層發送請求，持久層接收并完成相應的增刪改以及數據訪問操作。
[錨點] 4.2 相關服務器架構設計本電商平臺擁有多臺服務器，外加數據庫，多數部署在部署在VMware虛擬機的Linux環境下。一個Vsftpd文件上傳服務器，一個Nginx服務器實現反向代理負載均衡，三個Tomcat服務器構成的一個集群，通過Nginx服務器實現集群上的反向代理負載均衡；數據庫上有兩個兩個持久化的Mysql數據庫，一個部署在Linux環境下為索引庫提供數據來源，一個部署在Window環境下為整個平臺提供數據；一個Redis緩存數據庫；一個Solr搜索引擎索引庫。
Vsftpd文件上傳服務器：作為商品圖片的存放服務器，通過Nginx反向代理Tomcat服務器攜帶地址訪問Vsftpd上的圖片。
Nginx服務器：部署一臺Nginx服務器，起到為Tomcat服務器集群反向代理負載均衡的作用，而且對Vsftpd上圖片的訪問就是先通過Nginx服務器的反向代理到Tomcat服務器上的。
Tomcat服務器：三臺Tomcat服務器構成一個集群，提供Http請求等。
Redis緩存數據庫：Redis作為緩存數據庫緩存數據，減輕Mysql的壓力，是一個非關系型數據庫。Redis搭載在Linux環境下，有一臺主機和兩臺從機構成一個集群，實現了主備切換讀寫分離，避免以為宕機而導致數據丟失。
Solr搜索引擎索引庫：此索引庫為平臺前臺的搜索提供服務，加快搜索效率的同時減輕Mysql數據庫的壓力，而索引庫中的數據來源于Mysql數據庫，由Solr索引庫自身整理而來。
Mysql數據庫[4]：配置兩種不同環境下的Mysql為平臺服務。一個在Window環境下，存放整個平臺的用戶信息和商品信息等；另一個在Linux環境下，作用是為Solr搜索引擎索引庫提供數據來源。
[錨點] 4.3平臺功能概要設計
[錨點] 4.3.1 前臺注冊功能概要設計注冊頁面可從兩個地方進入，第一個平臺首頁的“免費注冊”按鈕，第二個是登錄頁面里的“注冊新用戶”按鈕，通過以上兩種方式跳轉至注冊頁面。在注冊頁面的表單里，填寫郵箱，用戶名和密碼，點擊極驗驗證進行行為驗證，一切都正確填寫之后，點擊“提交注冊”按鈕完成注冊。當注冊成功時，提示用戶“注冊成功”隨后跳轉至登錄頁面，于此同時后臺發送注冊郵件到用戶所填寫的郵箱，如果注冊失敗則根據提示重新填寫注冊。其中行為驗證用到的是GEETEST極驗驗證，郵件發送使用的是網易163郵箱的SMTP服務。
[錨點] 4.3.2 登錄功能概要設計通過點擊平臺首頁的“請登錄”按鈕跳轉至登錄頁面，輸入用戶名和密碼并進行驗證，驗證錯誤則提示“用戶名或密碼錯誤”，驗證成功則跳轉至平臺首頁。由于本平臺屬于前后臺分離，所以登錄功能上做了SSO單點登錄的技術。如果用戶第一次訪問應用系統時沒有登錄，則會被定向到認證系統進行登錄。首先，根據用戶輸入的登錄信息對用戶進行身份驗證。如果認證通過，經過身份驗證票將返回給用戶，然后用戶可以使用這張票作為身份驗證票訪問其他應用系統，收到票后，應用系統將其發送給驗證確認其合法性的驗證系統。一旦通過了驗證，用戶就可以訪問其他系統而無需再次登錄。另外，當游客想要使用用戶才具備的功能時，比如購物車功能等等，則把頁面自動跳轉至登錄頁面提示用戶先登錄。
[錨點] 4.3.3 后臺商品管理功能概要設計商品分類：在后臺管理平臺點擊商品管理下的“商品分類”按鈕進入分類頁面，頁面上三層分級顯示所有的商品分類，可以通過點擊“展開”“收縮”按鈕進行分級展開和收縮的操作。點擊“新增分類”按鈕跳轉新增頁面，在頁面表單上正確填寫各項信息，除了文字信息外還有一個圖片上傳的功能，填寫完成后可以點擊“提交”完成新增并保存至數據庫。新增頁面上還有返回分類頁和重新清空表單信息的兩個按鈕。點擊編輯圖標跳轉編輯頁面對相應分類信息進行編輯修改。點擊刪除圖標則可以刪除相應的分類信息并清理數據庫的信息。
商品列表：商品列表展示著平臺所有的商品，可以通過下拉框選擇分類或者是平臺查詢商品，也可以通過關鍵字搜索，由于商品數量多，實現分頁技術方便用戶使用。商品列表里可以添加新商品，其中包括通用信息，商品相冊，模型。在列表頁，通過點擊編輯和刪除圖片，可以進行對應商品的編輯修改和刪除。
商品模型：由于商品模型是規定一類商品公有規格和屬性的集合，所以模型頁面上在展示模型的同時，設計“屬性列表”和“規格列表”兩個按鈕分別跳轉至對應頁面。商品模型可以通過點擊按鈕跳轉新增頁面新增模型，也可以點擊編輯和刪除圖標進行相應的編輯修改和刪除。
商品規格：作為商品模型的一個子集，在做到常規的規格頁面展示外，可以通過下拉框選擇展示某個模型下的規格。同樣應該就被新增，編輯修改和刪除按鈕進行對應操作。
商品屬性：作為商品模型的一個子集，在做到常規的屬性頁面展示外，可以通過下拉框選擇展示某個模型下的屬性。同樣應該就被新增，編輯修改和刪除按鈕進行對應操作。
[錨點] 4.3.4 前臺商品搜索功能概要設計前臺商品功能的設計，搭載Solr搜索引擎，實現快速的關鍵字搜索，為Mysql數據庫減輕壓力且為用戶提高體驗感。在搜索框內輸入關鍵字信息后，點擊“搜索”按鈕實現商品的搜索，搜索成功商品展示至前臺首頁。因為商品數量的問題以及使用體驗，搜索而展示的商品進行分頁展示。
[錨點] 4.3.5 前臺購物車功能概要設計前臺購物車功能的設計上，頁面上每件商品都會有一個購物車圖標，用戶通過點擊商品信息欄中的購物車圖標按鈕便可以將商品添加至購物車，且可重復添加。點擊頁面上的購物車按鈕可跳轉至購物車頁面，顯示著用戶添加至購物車的所有商品（包括商品信息，總數量及總價格），用戶可以對相應商品修改數量。用戶可以刪除單個商品或者清空購物車，相應的數量和價格也會隨著刪除而變化。用戶可以通過點擊“+”，“-”按鈕修改購物車里商品的數量，同時相應的數量和價格也會隨著數量的改變而變化。購物車頁面里的去結算按鈕，結算購物車商品并跳轉至訂單頁面。購物車不屬于游客所能使用的功能，實現游客使用時自動跳轉至登錄頁面。
[錨點] 4.3.6 前臺訂單功能概要設計提交訂單功能設計上，用戶在購物車點擊“去結算”按鈕跳轉至核對訂單頁面，進入核對訂單頁面后；點擊“提交訂單”按鈕跳轉至訂單提交成功頁面，于此同時，購物車里的商品需要得到清空，相應的后臺數據庫也是，可以點擊“去付款”按鈕跳轉支付頁面。
[錨點] 4.3.7 前臺支付功能概要設計前臺支付功能設計上，使用支付寶開放平臺沙箱環境下的支付寶在線支付體驗，頁面上通過提交訂單功能后的“去付款”按鈕跳轉至支付頁面。進行支付寶在線支付相關操作之后，設計頁面跳轉回平臺首頁，生成訂單信息，未完成支付則保留訂單一定時間后清除。
[錨點] 4.4 平臺數據庫設計本平臺的數據庫上選用的是Mysql數據庫，分別在Window和Linux環境下搭載，一個為整個平臺提供數據，一個為Solr索引庫提供數據來源。數據庫的設計上，嚴格遵守數據庫的設計原則和規范，根據平臺實際需求而設計，做到數據庫的完整性約束，一致性約束，可擴展性和可修改性，借助Navicat可視化工具進行操作。
數據庫E-R圖：
圖4-2 數據庫E-R圖
數據庫表設計：
商品表
表4-1 t_goods
字段數據類型字段大小約束字段含義
goods_id mediumint 8 主鍵，非空商品編號
cat_id int 11 非空分類編號
goods_name varchar 120 非空商品名稱
click_count int 10 非空點擊次數
brand_id smallint 5 非空品牌編號
store_count smallint 5 非空庫存數量
shop_price decimal 10 非空商品價格
on_time int 10 非空上架時間
goods_type smallint 5 非空模型編號
spec_type smallint 5 非空規格編號
商品分類表
表4-2 t_goods_category
字段數據類型字段大小約束字段含義
id smallint 5 主鍵，非空分類編號
name varchar 90 非空分類名稱
level tinyint 1 默認空分級
image varchar 512 默認空分類圖片
is_show tinyint 1 非空是否顯示
商品模型表
表4-3 t_goods_type
字段數據類型字段大小約束字段含義
id smallint 5 主鍵，非空模型編號
name varchar 60 非空模型名稱
商品屬性表
表4-4 t_goods_attribute
字段數據類型字段大小約束字段含義
attr_id int 11 主鍵，非空屬性編號
attr_name varchar 60 非空屬性名稱
type_id smallint 5 非空模型編號
type_name varchar 60 默認空模型名稱
商品規格表
表4-5t_goods_spec
字段數據類型字段大小約束字段含義
spec_id int 11 主鍵，非空規格編號
spec_name varchar 60 默認空規格名稱
type_id smallint 5 默認空模型編號
type_name varchar 60 默認空模型名稱
訂單表
表4-6 t_order
字段數據類型字段大小約束字段含義
order_id mediumint 8 主鍵，非空訂單編號
user_id mediumint 8 非空用戶編號
order_status tinyint 1 非空訂單狀態
pay_status tinyint 1 非空支付狀態
consignee varchar 60 非空收貨人
goods_price decimal 10 非空商品總價
pay_time int 10 非空支付時間
total_amount decimal 10 非空訂單總價
訂單項表
表4-7 t_order_goods
字段數據類型字段大小約束字段含義
rec_id mediumint 8 主鍵，非空表編號
order_id mediumint 8 非空用戶編號
goods_id mediumint 8 非空商品編號
goods_name varchar 120 非空商品名稱
goods_num smallint 5 非空購物數量
goods_price decimal 10 非空商品總價
spec_key varchar 128 非空規格編號
spec_key_name varchar 128 非空規格名稱
用戶表
表4-8 t_user
字段數據類型字段大小約束字段含義
user_id smallint 5 主鍵，非空用戶編號
user_name varchar 60 非空用戶名稱
email varchar 60 非空用戶郵箱
password varchar 32 非空用戶密碼
ec_salt varchar 50 非空密鑰
add_time int 11 非空注冊時間
[錨點] 5 電商平臺詳細設計與實現在第四章電商平臺的概要設計基礎上，在本章進一步描述電商平臺的詳細設計與實現，將從平臺架構和功能兩個角度進行剖析。
[錨點] 5.1 平臺架構詳細設計本平臺的工程架構為Maven工程，ego-parent是整個工程的一個父工程，其中包括公共工具類系統ego-common，后臺系統ego-manager，前臺系統ego-portal，服務系統ego-rpc，訂單系統ego-order和單點登錄系統ego-sso，除了公共工具類系統每個子系統都擁有自己的pojo和mapper對象，也擁有service層和web層，共同組建成一個完整的平臺工程，其中各個子系統的pojo和mapper是由Mybatis的逆向工程generator自動生成，包括pojo，mapper.xml，mapper.java，不需要手動編寫，大大的提高了編程效率。
圖5-1 平臺工程架構圖
平臺的系統架構是在MVC模式的三層架構下，利用Dubbo服務治理框架和Zookeeper注冊中心搭建服務系統。利用Nginx分別實現前后臺系統的方向代理，前后臺系統則通過Dubbo實現服務的遠程調用。
Vsftpd文件上傳服務器，安裝在Linux環境下，是商品圖片的存儲地。
Redis服務器安裝在Linux環境下，由一臺主機和兩臺從機構成一個集群，配置了主備切換讀寫分離，用來存儲一些臨時數據或常用數據。
Solr搜索引擎安裝在Linux環境下，為前臺的搜索功能所服務，實現了前臺的關鍵字搜索，做到了搜索的快速高效，Solr的索引庫數據源于Linux環境下的Mysql數據庫，由Solr自己整理而來。
圖5-2 平臺執行流程圖