微服務架構下電商平臺的研究和實現(xiàn)

方嵩柯 谷志峰 張冠甲 王偉光 馬學友

摘要：近年來，隨著互聯(lián)網(wǎng)行業(yè)的迅猛發(fā)展，公司和業(yè)務的不斷擴展，使得原本一個小型而簡單的應用變得十分復雜，一旦一個小型的應用成長為一個龐大而復雜的單體，開發(fā)很有可能將陷入一個原地踏步的境地，為了解決單體應用的問題，我們采用近幾年流行的微服務架構的方式來進一步實現(xiàn)電商平臺的高內(nèi)聚，低耦合，提高開發(fā)效率。

關鍵詞：B/S架構;電商平臺;SpringCloud;持續(xù)集成;云原生;微服務;Docker容器;MySQL數(shù)據(jù)庫

中圖分類號：TP31 1.5 文獻標識碼：A

文章編號：1009-3044（2020）10-0288-02

1研究背景及研究內(nèi)容

1.1研究背景一陷入焦油坑的單體應用模型

近年來，隨著互聯(lián)網(wǎng)行業(yè)的迅猛發(fā)展，公司和業(yè)務的不斷擴展，需求的快速變化以及用戶量的不斷攀升，以及隨著SSH和SSM框架的成熟，一個傳統(tǒng)項目的開發(fā)似乎已經(jīng)進入一個非常簡單的方式。然而，成功的應用程序都有一個趨勢，隨著時間的推移業(yè)務量逐漸增多，需要修改的地方也就越來越多，這就意味著需要添加更多的代碼，這種添加的代碼量使得原本一個小型而簡單的應用變得十分復雜，一旦一個小型的應用成長為一個龐大而復雜的單體，開發(fā)很有可能將陷入一個原地踏步的境地，甚至在修改一處BUG后，帶來更多的BUG。為了修改更多的問題，又會產(chǎn)生更多的代碼，如此惡性循環(huán)，使得產(chǎn)品陷人焦油坑最終成為一個不可思議的大泥球。當產(chǎn)品陷入焦油坑而不能自拔時會來帶來更多的問題，原本重啟服務耗時五十秒，那么在添加了大量代碼后，重啟時間可能會達到三分鐘之長，使得開發(fā)變得愈加困難。

1.2研究內(nèi)容

1.2.1微服務解決復雜難題

為了解決單體應用的問題，也出現(xiàn)了一系列架構來解決這些問題，我們從單體架構走向分布式架構再走向SAO面向服務架構。直到2014年當今世界軟件開發(fā)領域具影響力的大師Martin Fowler與James Lewis共同提出了微服務的概念，定義微服務架構，將微服務架構推到了一個時代浪尖。我們將一個傳統(tǒng)的龐大的業(yè)務進行拆分，拆分原則可按照業(yè)務來進行劃分，如果過于復雜我們可以采用DDD領域驅動設計來進行劃分。將龐大的業(yè)務拆分成若干個小的業(yè)務，各個業(yè)務之間內(nèi)部采用RPC的方式來進行通訊，對外部則采用REST風格的API進行通訊。從而將一個大型應用分解為若干個小型應用通過對模塊解耦來解決問題。

1.2.2云原生架構下的微服務實踐

2010年5月28日WSO2的CTO和聯(lián)合創(chuàng)始人在他的一篇博客中首次提出了CloudNative這個概念，2014年Nelflix的云架構師Adrian Cockcroft介紹了基于Cloud Native的成功應用，吸引了大批開發(fā)人員爭相模仿。我們在向微服務架構的轉型中將會出現(xiàn)各種各樣的問題，云原生的敏捷基礎設施以及公共基礎設施將成為一個微服務是否成功的關鍵。為此出現(xiàn)了代替虛擬機的容器Docker，持續(xù)集成私有云平臺gitlab，docker鏡像管理平臺DockerRegistry等。為此，此次研究我們結合云原生與微服務，來做到真正的微服務架構。

2系統(tǒng)總體要求

2.1系統(tǒng)框架要求

1）開發(fā)環(huán)境。操作系統(tǒng)：Windows 10 Enterprise;開發(fā)工具：InteHii IDEA;數(shù)據(jù)庫：MySQL 5.7.22;

2）部署環(huán)境。操作系統(tǒng)：LinuxUbuntuServer 16.04X64;虛擬化技術：VMware+Docker;

3）項目管理工具。項目構建：Maven+Nexus;代碼管理：Git+GitLab;鏡像管理Docker Registry;

4）后臺主要技術。核心框架：Spring Cloud+SpringBoot;視圖框架：Spring MVC;頁面引擎：Thymeleaf;ORM框架：tk.myba-tis簡化MyBatis開發(fā);數(shù)據(jù)庫連接池：Alibaba Druid;數(shù)據(jù)庫緩存：Redis Sentinel;消息中間件：RabbitMQ;接口文檔引擎：Swag-ger2 RESTful風格API文檔生成;分布式日志系統(tǒng)：ELK（Elastic-Search+Logstash+Kibana）;反向代理負載均衡：Nginx;

5）前端主要技術棧：前端框架：Bootstrap+jQuery或者ele-mentui+vue;

6）自動化運維：持續(xù)集成：GitLab;持續(xù)交付：Jenkins。

2.2硬件的支持要求

運行本系統(tǒng)的硬件最低要求：CPU：3.0Hz;內(nèi)存：16G;硬盤：256G。

2.3系統(tǒng)架構圖

圖1為系統(tǒng)架構圖。

3系統(tǒng)設計與實現(xiàn)

微服務架構主要在于其思想，正所謂，有道無術，術尚可求，有術無道，止于術，可見思想的重要性。而各種基礎設施的搭建和敏捷開發(fā)的實現(xiàn)都將成為系統(tǒng)能否架構成微服務的關鍵因素，業(yè)務的開發(fā)不再是微服務架構的難點。因此我們將實現(xiàn)一個電商平臺來對微服務架構進行研究，對于此電商平臺的前臺展示頁面我們采用Bootstrap+iQuery框架來進行展示，后臺我們使用Spring Cloud和Spring Boot來作為我們的核心框架，由于Spring Boot支持Thymeleaf作為頁面引擎，因此我們的頁面引擎不再使用JSP，同時利用docker作為虛擬化技術來進行搭建各種基礎設施，以及服務的部署，使用gitlab來實現(xiàn)持續(xù)集成，做到開發(fā)人員提交了新代碼之后，立刻進行構建、（單元）測試。具體業(yè)務的開發(fā)將不再是我們研究的重點。

下面通過部分具有代表性的功能模塊進行具體詳解，以及介紹所用到的技術實現(xiàn)：

3.1基礎設施即服務-Doeker

Docker是一個開源的應用容器引擎，開發(fā)者可以將自己的應用打包放到一個可移植的鏡像中，然后發(fā)布到任何裝有Docker的電腦上，一個虛擬機可同時擁有若干的docker容器，各個容器之間是完全地隔離。真正做到一次上傳，到處運行。

Docker官方為了簡化流程我們在系統(tǒng)上只需運行一行代碼即可下載，由于國內(nèi)拉取鏡像會有些困難，我們可以設置使用阿里云的加速器，在修改成功后可以測試是否有效，使用docker需要學會docker的基本命令，只有熟悉使用docker才能進行基礎設施的搭建。同時為了解決多個docker容器一次部署完成我們使用Docker Compose來進行快速的部署分布式應用。

3.2平臺即服務-Nexus，GitLab，Registry

我們利用Docker來作為基礎設施，安裝Nexus，GitLab，Registry作為我們微服務私有云平臺的支撐，Nexus是一個強大的倉庫管理平臺，會收入我們的JAR包，在安裝Nexus后我們需要在項目的pom文件中加入我們Nexus的地址。GitLab是一個開源的分布式版本控制系統(tǒng)，類似于GitHub，但是GitLab是私有云平臺，我們在后期的持續(xù)集成中也會使用Git-Lab作為支撐，同樣我們在Docker中拉取鏡像來運行一個GitLab容器，在安裝完成后，進行登錄，配置SSH免密登錄后，我們便可以創(chuàng)建項目并將我們的項目上傳到GitLab平臺中。Registry是一個私有的上傳鏡像的平臺，同樣通過Docker來進行安裝。

3.3平臺即服務-Spring Cloud基礎設施搭建

Spring Cloud為開發(fā)人員提供了快速構建分布式系統(tǒng)中一些常見模式的工具f例如配置管理，服務發(fā)現(xiàn)，斷路器，智能路由，微代理，控制總線）。微服務中由于服務的眾多，我們需要有一個專門的組件來發(fā)現(xiàn)這些服務，因此我們采用Eureka作為我們的服務注冊與發(fā)現(xiàn)中心。在微服務中，由于大量的服務，也產(chǎn)生新的問題，那就是網(wǎng)絡的不可靠性，因此Spring Cloud中使用熔斷器模式Hystrix來解決這個問題，在某個服務出現(xiàn)問題后，為了避免連鎖反應，可以通過fallback方法返回一個固定值。我們使用Spring Cloud提供的Zuul作為路由轉發(fā)和過濾器，路由功能是微服務的一部分，比如/api/user轉發(fā)到到User服務。使用Spring Cloud ZipKin作為分布式鏈路追蹤，為了解決服務之間的復雜調(diào)用問題。使用SpringCloud Con-fig作為系統(tǒng)的配置中心，每個服務從這里獲取自身配置所需要的參數(shù)。使用Spring Boot Admin用于管理和監(jiān)控一個或多個SpringBoot程序。均在docker容器中部署，作為微服務的基礎設施。

3.4GitLab實現(xiàn)持續(xù)集成

正如前文所講，我們需要部署幾十個甚至成百上千個服務，如果我們每次都手動打包，手動測試，耗費的時間將是無可估量的，因此我們必須采用持續(xù)集成來部署服務，首先我們要安裝GitLab Runner來進行cI，安裝完成后我們啟動Runner，然后和GitLab cI進行綁定，綁定完成后可以在GitLab的私有平臺的設置CI/CD中進行查看，我們需要在項目中編寫.gitlab-ci.yml文件即可進行持續(xù)集成。

4結論

通過對微服務架構的電商平臺進行研究，其主要是通過將功能分解到各個離散的服務中以實現(xiàn)對解決方案的解耦，單一職責，模塊之間分而治之。相對于傳統(tǒng)的單體應用開發(fā)，微服務架構使得產(chǎn)品的變成一顆顆小的微粒，這些微粒組成一個系統(tǒng)，單個服務啟動時間較短，同樣因為各個服務之間通過API的方式通訊，所以無論是什么編程語言只要能通過API進行通訊即可，因此技術棧不受限制，同時微服務與云原生以及DevO-ps能夠很好地結合，使得開發(fā)更加優(yōu)雅、便捷。然而軟件開發(fā)沒有銀彈，分布式系統(tǒng)的cAP理論已經(jīng)證明了分布式系統(tǒng)所存在的固有問題，同樣因為服務眾多，網(wǎng)絡的不可靠性也是我們需要注意的焦點，起點高，涉及的知識廣泛，團隊如何進行敏捷開發(fā)也是未來微服務架構所面臨的挑戰(zhàn)。