方嵩柯 谷志峰 張冠甲 王偉光 馬學(xué)友

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

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

中圖分類號：TP31 1.5 文獻(xiàn)標(biāo)識碼：A

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

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

1.1研究背景一陷入焦油坑的單體應(yīng)用模型

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

1.2研究內(nèi)容

1.2.1微服務(wù)解決復(fù)雜難題

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

1.2.2云原生架構(gòu)下的微服務(wù)實踐

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

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;虛擬化技術(shù)：VMware+Docker;

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

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

5）前端主要技術(shù)棧：前端框架：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)架構(gòu)圖

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

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

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

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

3.1基礎(chǔ)設(shè)施即服務(wù)-Doeker

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

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

3.2平臺即服務(wù)-Nexus，GitLab，Registry

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

3.3平臺即服務(wù)-Spring Cloud基礎(chǔ)設(shè)施搭建

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

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

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

4結(jié)論

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