楊思譽，劉海霞，童基均，冉宇瑤

（1.浙江理工大學(xué) 信息學(xué)院，浙江 杭州310016 ；2.浙江理工大學(xué) 科技與藝術(shù)學(xué)院，浙江 紹興 312369）

0 引言

隨著計算機硬件性能的不斷提升，以及虛擬化技術(shù)和計算機網(wǎng)絡(luò)技術(shù)的發(fā)展與逐步完善，云計算（Cloud Computing）應(yīng)運而生。企業(yè)將服務(wù)遷移到云平臺上，可以節(jié)省運行維護硬件的人力資源成本、計算資源空閑時的閑置成本，在需要大量計算資源時可直接向云平臺申請資源，從而降低了企業(yè)運行成本等。但是，許多在云計算平臺上運行的應(yīng)用仍然是被設(shè)計在傳統(tǒng)硬件架構(gòu)上，若出現(xiàn)熱點事件或用戶量極速增長的情況，手動擴容集群規(guī)模往往不能及時應(yīng)對突發(fā)壓力，甚至在擴容過程中還可能由于節(jié)點拓?fù)錈o法在線修改引發(fā)應(yīng)用閃斷，降低服務(wù)的可用性［1］。

云原生應(yīng)用完全是從云服務(wù)中誕生的應(yīng)用，即一切圍繞著云計算而設(shè)計架構(gòu)。相對于傳統(tǒng)業(yè)務(wù)，更加充分且頻繁地應(yīng)用例如微服務(wù)、彈性計算和服務(wù)編排等云平臺提供的先進技術(shù)，幫助業(yè)務(wù)更穩(wěn)定、高效地運行。以Netflix 為例，其為世界上最大的點播流媒體平臺之一，通過將所有服務(wù)“上云”的方式，使其運維成本下降87%。云原生技術(shù)給用戶提供了一個抽象、彈性、高可用的基礎(chǔ)設(shè)施（如數(shù)據(jù)庫、網(wǎng)絡(luò)、存儲等），因此是未來的大勢所趨。

本文針對當(dāng)前業(yè)界應(yīng)用架構(gòu)的發(fā)展，采用云原生的設(shè)計理念，在使用Spring Cloud、Docker 和云計算平臺作為工具的基礎(chǔ)上，快速搭建一個可擴展、高可用、彈性的云服務(wù)應(yīng)用程序。

1 云計算與云原生架構(gòu)

云晴［2］對云原生發(fā)展歷程進行了梳理：2013 年，Pivotal（美國云軟件開發(fā)工具與服務(wù)公司）的Matt Stine 根據(jù)其多年的架構(gòu)和咨詢經(jīng)驗總結(jié)出來一個思想集合，并對其不斷發(fā)展與完善；同年，Docker 項目正式發(fā)布；2014 年，Google 和Redhat 聯(lián)合發(fā)布Kubernetes，用于更方便、快速地對容器進行管理；2015 年，由Google、Redhat 與微軟等大型云計算廠商以及一些開源公司共同牽頭成立了云原生基金會（CNCF）。CNCF 這個非盈利組織的初衷為推廣孵化和標(biāo)準(zhǔn)化云原生相關(guān)技術(shù)，包括推動云原生計算的可持續(xù)發(fā)展與幫助云原生技術(shù)開發(fā)人員快速構(gòu)建出色的產(chǎn)品。此后，CNCF 得到了快速發(fā)展，并逐漸構(gòu)建出一整套云原生技術(shù)。

1.1 云計算

云計算是以虛擬化技術(shù)為基礎(chǔ)、以網(wǎng)絡(luò)為載體提供基礎(chǔ)架構(gòu)，整合大規(guī)?？蓴U展的計算、存儲、數(shù)據(jù)、應(yīng)用等分布式計算資源進行協(xié)同工作的超級計算模式［3］。如圖1 所示，云平臺提供的云計算服務(wù)自下而上可分為基礎(chǔ)設(shè)施即服務(wù)（IaaS）、平臺即服務(wù)（PaaS）和軟件即服務(wù)（SaaS），面對不同用戶，可提供不同等級的抽象資源。

Fig.1 Cloud service system differentiation圖1 云服務(wù)體系區(qū)分

1.2 云原生

云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建與運行可彈性擴展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API［4］，這些技術(shù)能夠構(gòu)建容錯性好、易于管理及便于觀察的松耦合系統(tǒng)。云原生應(yīng)用的特點包括分布式、高可用、高性能、彈性、無狀態(tài)、本地輕依賴等。如圖2所示，云原生主要包括容器化、微服務(wù)、DevOps、持續(xù)交付等幾方面內(nèi)容，其中容器化是一種集裝箱技術(shù)，通過將應(yīng)用“裝”起來以實現(xiàn)應(yīng)用之間的相互隔離［5］；微服務(wù)架構(gòu)是隨著分布式技術(shù)發(fā)展而出現(xiàn)的一種新型軟件設(shè)計模式，其理念是分而治之，微服務(wù)也體現(xiàn)了系統(tǒng)設(shè)計中的內(nèi)聚、低耦合理念；DevOps（Development 與Operations 的組合）旨在促進軟件交付及基礎(chǔ)設(shè)施開發(fā)人員（Dev）與IT 運維技術(shù)人員（Ops）之間的溝通合作；持續(xù)交付（Continuous Delivery，縮寫為CD）是一種軟件工程手法，其目標(biāo)在于讓軟件的構(gòu)建、測試與發(fā)布變得更快、更頻繁，從而減少軟件開發(fā)時間及成本，降低風(fēng)險。

Fig.2 Main content of cloud native圖2 云原生主要內(nèi)容

2 Spring Cloud 組件與架構(gòu)設(shè)計

Spring Cloud 是一系列框架、組件的有序集合，擁有功能完善、輕量級的微服務(wù)實現(xiàn)組件，例如在服務(wù)發(fā)現(xiàn)治理、服務(wù)容錯、服務(wù)網(wǎng)關(guān)、服務(wù)配置、負(fù)載均衡、消息總線、服務(wù)跟蹤等方面均有經(jīng)過實踐檢驗的成熟組件［6］?；赟pring Cloud 組件的云原生服務(wù)部署架構(gòu)如圖3 所示。

Fig.3 Cloud native server architecture圖3 云原生服務(wù)部署架構(gòu)

2.1 服務(wù)消費與負(fù)載均衡

2.1.1 服務(wù)消費

目前，在Spring Cloud 中服務(wù)之間通過Restful 協(xié)議進行遠(yuǎn)程調(diào)用有兩種方式：RestTemplate+Ribbon 和Feign。Spring Cloud Netflix 的微服務(wù)都是以HTTP 接口形式暴露的，可用Apache的HttpClient或Spring的RestTemplate調(diào)用。

Ribbon 是一個基于HTTP 與TCP 客戶端的負(fù)載均衡器，可在客戶端配置RibbonServerList（服務(wù)端列表），然后輪詢請求以實現(xiàn)均衡負(fù)載。在聯(lián)合使用Eureka 時，Ribbon-ServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka 注冊中心獲取服務(wù)端列表，同時其也會用NIWSDiscoveryPing 取代IPing，并將職責(zé)委托給Eureka 確定服務(wù)端是否已啟動。

Feign 是一個用起來比Ribbon+RestTemplet 更方便的HTTP 客戶端，使用Feign 就如同調(diào)用本地方法一樣，無需關(guān)注目標(biāo)服務(wù)所在環(huán)境。本架構(gòu)設(shè)計采用Feign，F(xiàn)eign 相當(dāng)于在Ribbon 之上再作了一次封裝，隱藏了底層更多細(xì)節(jié)，更易于使用。

2.1.2 負(fù)載均衡

Ribbon 負(fù)責(zé)服務(wù)間的負(fù)載均衡，默認(rèn)策略有輪詢、隨機、加權(quán)、哈希、一致性哈希等負(fù)載均衡算法。用戶可根據(jù)自己的需求選擇對應(yīng)的負(fù)載均衡策略，也可通過繼承抽象類方式實現(xiàn)自己的負(fù)載均衡策略。

在經(jīng)典算法中，加權(quán)最少連接調(diào)度（Weighted Least-Connection，WLC）是LVS 集群中一種經(jīng)典的動態(tài)負(fù)載均衡算法［7］，該算法使用服務(wù)器節(jié)點的連接數(shù)作為負(fù)載評價標(biāo)準(zhǔn)。隨著集群環(huán)境的規(guī)模化及資源的異構(gòu)化，以負(fù)載評估為目標(biāo)的負(fù)載均衡算法已不能滿足集群調(diào)度的需要，因此布谷鳥搜索（Cuckoo Serch，CS）等元啟發(fā)式算法被引入到負(fù)載均衡機制中。張娜等［8］在布谷鳥算法基礎(chǔ)上引入了混沌變異和反向?qū)W習(xí)，增加了布谷鳥算法求最優(yōu)解的準(zhǔn)確性。

2.2 分布式系統(tǒng)集中配置

在分布式系統(tǒng)中，當(dāng)單體應(yīng)用程序被拆分成微服務(wù)時，每一個微服務(wù)都是一個單體應(yīng)用程序，故每一個微服務(wù)都需要維護自身的配置。相同代碼可能會在不同環(huán)境下運行：開發(fā)、測試、灰度測試、上線運行、并行容器等。本文希望微服務(wù)在修改配置后可實時生效，以便于集群統(tǒng)一管理，且擁有完善的權(quán)限和審核機制等。在采用分布式開發(fā)模式后，項目之間的相互引用隨著服務(wù)的不斷增多，相互之間的調(diào)用復(fù)雜度呈指數(shù)級增加，因此需要引用分布式配置中心。

Spring Cloud Config 為分布式系統(tǒng)中的外部配置提供服務(wù)器和客戶端支持，以方便部署與運維。其中服務(wù)端也稱為分布式配置中心，是一個獨立的微服務(wù)應(yīng)用，用來連接配置服務(wù)器并為客戶端提供配置信息獲取、信息加密/解密等訪問接口?？蛻舳藙t是通過指定的配置中心管理應(yīng)用資源以及與業(yè)務(wù)相關(guān)的配置內(nèi)容，并在啟動時從配置中心獲取與加載配置信息。默認(rèn)采用git，并且可通過git 客戶端工具方便地管理與訪問配置內(nèi)容。

2.3 API 網(wǎng)關(guān)

在微服務(wù)架構(gòu)中，服務(wù)對外暴露的是API 接口，并且對于同一個微服務(wù)會有多個服務(wù)提供者，因此要提供網(wǎng)關(guān)負(fù)責(zé)對外部請求的導(dǎo)航。在前端，展示頁面時需要從多個微服務(wù)中聚合數(shù)據(jù)，而且服務(wù)的劃分位置結(jié)構(gòu)可能會有所改變。為統(tǒng)一管理API 的訪問路徑與前線，本文引入API 網(wǎng)關(guān)組件。網(wǎng)關(guān)可對外暴露聚合API，屏蔽內(nèi)部微服務(wù)的微小變動，保持整個系統(tǒng)的穩(wěn)定性。另外，網(wǎng)關(guān)還具有外部請求負(fù)載均衡、統(tǒng)一鑒權(quán)、協(xié)議轉(zhuǎn)換、監(jiān)控監(jiān)測等一系列功能。

Zuul 是Netflix 開源的一個API Gateway 服務(wù)器，本質(zhì)上是一個Web Servlet 應(yīng)用。Zuul 在云平臺上提供動態(tài)路由、監(jiān)控、彈性、安全等邊緣服務(wù)框架，相當(dāng)于設(shè)備與云原生應(yīng)用后端所有請求的導(dǎo)航。Zuul 的樣例可參考Netflix在Github上的Simple Webapp例子，按照Netflix 在Github Wiki 上的文檔說明進行使用。

2.4 服務(wù)熔斷、降級與監(jiān)控

在分布式環(huán)境中，許多服務(wù)依賴項中的一些請求必然會失敗。Hystrix 是一個庫，通過添加延遲容忍和容錯邏輯，幫助人們控制這些分布式服務(wù)之間的交互。Hystrix 通過隔離服務(wù)之間的訪問點、停止級聯(lián)失敗和提供回退選項實現(xiàn)該功能。熔斷器是微服務(wù)彈性化過程中的一部分，能很好地保護應(yīng)用程序。

2.4.1 服務(wù)雪崩

在分布式系統(tǒng)中存在雪崩效應(yīng)問題。當(dāng)微服務(wù)A 調(diào)用微服務(wù)B，微服務(wù)B 調(diào)用微服務(wù)C 或其他微服務(wù)時，服務(wù)因調(diào)用鏈路上的某個微服務(wù)而下線導(dǎo)致整體不可用，或該服務(wù)響應(yīng)時間過長，調(diào)用鏈上的前置服務(wù)會處于等待狀態(tài)而耗盡資源（如線程池資源耗盡），導(dǎo)致服務(wù)集體下線，系統(tǒng)崩潰。

2.4.2 熔斷與降級

為避免系統(tǒng)中出現(xiàn)雪崩效應(yīng)，本文引入“服務(wù)熔斷”和“服務(wù)降級”機制。熔斷機制是應(yīng)對雪崩效應(yīng)的一種服務(wù)鏈路保護機制，當(dāng)發(fā)現(xiàn)服務(wù)調(diào)用鏈路上的某一個服務(wù)下線或響應(yīng)時間過長時，會進行服務(wù)降級，進而熔斷該節(jié)點服務(wù)的調(diào)用，快速返回錯誤信息。當(dāng)檢測到該節(jié)點微服務(wù)的調(diào)用響應(yīng)正常后，則恢復(fù)調(diào)用該鏈路。

服務(wù)降級的理念是在流量洪峰到來時，犧牲一些邊緣服務(wù)以保護系統(tǒng)核心服務(wù)的可用性，其在客戶端進行處理，與服務(wù)端無關(guān)。當(dāng)察覺某個時間段內(nèi)，某一個服務(wù)即將承受大流量的沖擊，而另一些服務(wù)所占用的資源卻大部分閑置時，可通過服務(wù)降級先將某些服務(wù)單元忍痛關(guān)閉掉，留下一些可返回的備選方法，等待整體系統(tǒng)承受住流量峰值，再重啟被暫時關(guān)閉的服務(wù)。

2.4.3 服務(wù)監(jiān)控

在云原生的理念中，一切部署、運維都由一個自動化平臺進行維護，因此需要一個平臺能實時監(jiān)控所有微服務(wù)狀態(tài)。常用的服務(wù)監(jiān)控方式有：網(wǎng)關(guān)+Hystrix 組合、Eureka注冊中心服務(wù)集成Spring Boot Admin Dashboard 服務(wù)。

2.5 鏈路追蹤

在云原生應(yīng)用中，單體系統(tǒng)被拆分成大量微服務(wù)，而一個請求的處理將會涉及大量的服務(wù)間調(diào)用。離散的微服務(wù)在讓應(yīng)用內(nèi)部解耦的同時，也增加了調(diào)試方面的困難，導(dǎo)致難以定位問題出現(xiàn)的具體位置。一個請求的處理可能會呈樹狀以調(diào)用不同的微服務(wù)，為了追蹤一個請求調(diào)用鏈路上的具體信息，本文引入分布式鏈路追蹤的概念。

3 配置要求及分析

3.1 硬件配置

本次部署采用騰訊云的云服務(wù)器（Cloud Virtual Machine，CVM，1 核2G，50G 硬盤，CentOS 7.0）模擬遠(yuǎn)程云數(shù)據(jù)庫（關(guān)系型數(shù)據(jù)庫MySQL 7.0，非關(guān)系型數(shù)據(jù)庫Redis 3.2），在兩臺遠(yuǎn)程服務(wù)器（4 核8G）上使用Docker 容器搭建服務(wù)集群，以模擬云原生應(yīng)用的微服務(wù)（見表1）。

Table 1 Server configuration表1 服務(wù)器配置

3.2 微服務(wù)介紹

3.2.1 基礎(chǔ)設(shè)施

EUREKA-SERVER-1、EUREKA-SERVER-2、EUREKA-SERVER-3 是3 個分別運行在端口8001、8002、8003 的服務(wù)注冊與發(fā)現(xiàn)集群，三者之間互相注冊，組成了高可用集群。

HYSTRIX-DASHBOARD-TURBINE 是系統(tǒng)的自動化監(jiān)控平臺，負(fù)責(zé)監(jiān)控所有微服務(wù)運行狀態(tài)。其會分析所有流經(jīng)微服務(wù)的請求，統(tǒng)計每個請求的響應(yīng)狀態(tài)（如成功、失敗、掛起等）及響應(yīng)時間，并根據(jù)一個時間片內(nèi)的情況判斷該微服務(wù)是否出現(xiàn)了問題，然后將其轉(zhuǎn)化為UI 界面以警示運維人員，便于定位與排查問題。

ZUUL-APPLICIATION是一個APIGetaway網(wǎng)關(guān)，其是整個應(yīng)用的入口點，也是唯一對外暴露的端口。所有請求都會流經(jīng)該微服務(wù)，其會對流量進行篩選與鑒權(quán)，錯誤請求將會返回對應(yīng)錯誤信息。在鑒權(quán)通過后，請求將被導(dǎo)航至系統(tǒng)內(nèi)部的各個微服務(wù)上，系統(tǒng)內(nèi)部被隱藏的微服務(wù)將處理這些請求，并返回相應(yīng)數(shù)據(jù)和狀態(tài)碼。在該微服務(wù)上集成了Spring Security Oauth2，以對請求進行權(quán)限校驗，只有攜帶了正確的access_token 請求才能通過，而鑒權(quán)失敗的請求將被駁回。用戶登錄信息會被存儲在云Redis 中，并會定時過期，過期后需要使用refresh_token 刷新access_token。

3.2.2 服務(wù)提供與服務(wù)消費

EUREKA-CLIENT 模擬的是服務(wù)提供者，并對外暴露RESTful 風(fēng)格的HTTP 接口。在Eureka 服務(wù)注冊表中，有兩個與之對應(yīng)的IP 地址，意味著有兩個相同的微服務(wù)注冊為同一個名字，這就是服務(wù)的橫向擴展：通過增加機器的方式搭建集群以提高服務(wù)的整體性能和可用性。當(dāng)服務(wù)消費者訪問該微服務(wù)時，會根據(jù)其配置的負(fù)載均衡策略決定訪問哪一個微服務(wù)。應(yīng)用的彈性體現(xiàn)在可通過擴展任意一臺機器的方式提升該服務(wù)總體性能上限，只需在啟動時在注冊中心使用相同的服務(wù)名注冊它自己，其在整個服務(wù)網(wǎng)絡(luò)上就是可被感知的，會自動分配流量給該服務(wù)。故運維人員在處理巨大的流量洪峰時，可通過申請短暫的計算資源進行應(yīng)對，并在處理結(jié)束后馬上將其釋放。高可用體現(xiàn)在對該服務(wù)而言，任意一臺機器下線只會導(dǎo)致處理流量峰值的能力下降，而不會導(dǎo)致整個服務(wù)下線。

CONSUMER1 模擬的是服務(wù)消費者，其通過HTTP 請求訪問應(yīng)用內(nèi)的服務(wù)提供者。在該服務(wù)上集成了輪詢規(guī)則的負(fù)載均衡器，即會按順序一個個訪問服務(wù)的不同提供者。

USER-INFORMATION 是一個完整的微服務(wù)，負(fù)責(zé)系統(tǒng)中用戶信息的增刪改查，模擬應(yīng)用與云數(shù)據(jù)庫之間的互動。

SIMHASH 是另一個微服務(wù)，其職責(zé)是提供文字查重服務(wù)。對外暴露一個接口的作用是計算兩段文字的SimHash值，根據(jù)兩組SimHash 判斷兩篇文章的海明距離。在該系統(tǒng)中，海明距離為0～10，數(shù)值越小，文章相似程度越高，這是一個CPU 密集型微服務(wù)。

在應(yīng)用中每一個服務(wù)提供者與服務(wù)消費者上配置了服務(wù)熔斷器，當(dāng)某個服務(wù)因某些原因不可用時，熔斷器會自動熔斷服務(wù)，快速返回錯誤信息，避免因大量請求堆積而造成服務(wù)雪崩，導(dǎo)致整個應(yīng)用不可用。

3.3 打包與部署

在部署應(yīng)用程序前，應(yīng)搭建自己的云計算集群。首先部署模擬云數(shù)據(jù)庫的服務(wù)器DataServer。在DataServer 上，防火墻開放3306 端口部署MySQL，開放6379 端口部署Redis。其次，部署模擬應(yīng)用生產(chǎn)環(huán)境的部分：AppServer1、AppServer2。在這兩臺機器上配置了Nginx 反向代理，監(jiān)聽并轉(zhuǎn)發(fā)80 端口收到的請求，同時安裝并配置Docker。如果使用傳統(tǒng)的打包成鏡像再上傳的方式，需要進行大量數(shù)據(jù)傳輸，因此要花費大量時間等待。為提高服務(wù)部署效率，也方便微服務(wù)的橫向擴展，本文選擇對每個微服務(wù)編寫Dockerfile，將代碼上傳到GitHub 遠(yuǎn)程倉庫中。在服務(wù)端從遠(yuǎn)程倉庫拉去代碼文件并進行編譯、Docker 鏡像打包、運行鏡像等操作。在AppServer1 上部署了Eureka Server、Zuul、HYSTRIX-DASHBOARD-TURBINE、UserInformation、Sim-Hash服務(wù)，在AppServer2上部署了Eureka Server、Zuul、ConfigServer、UserInformation、SimHash 服務(wù)，同時配置了防火墻，對外暴露80 端口如圖4 所示。

由于不同微服務(wù)對計算機資源的需求不同，若簡單、粗暴地令所有服務(wù)都在一臺單獨機器上運行，會造成大量計算資源浪費。使用Docker+微服務(wù)的思想可提高計算資源利用率，例如將CPU 密集型服務(wù)和IO 密集型服務(wù)部署在同一臺計算機上，其之間出現(xiàn)沖突的可能性很小，能很好地共存，從而最大化地利用計算資源。本文將用戶信息管理（IO 密集型服務(wù)）與相似文本查重算法（CPU 密集型服務(wù)）部署在同一臺服務(wù)器上，盡可能實現(xiàn)計算資源的最大化利用。

Fig.4 Application architecture圖4 應(yīng)用架構(gòu)

4 結(jié)語

本文采用云原生的理念和開發(fā)方式構(gòu)建一個云原生應(yīng)用，應(yīng)用包括集中配置中心、服務(wù)注冊與發(fā)現(xiàn)、API Getaway 網(wǎng)關(guān)、服務(wù)消費和負(fù)載均衡器、服務(wù)熔斷與降級、分布式鏈路追蹤等模塊，并且介紹了數(shù)個需要不同計算機資源的微服務(wù)：單點登錄與請求鑒權(quán)、用戶信息管理、文本查重算法設(shè)計與實現(xiàn)。在開發(fā)流程中使用GitHub 進行版本控制與持續(xù)交付，使用服務(wù)端打包Docker 的方式降低部署成本，使得開發(fā)更優(yōu)雅、便捷。在部署應(yīng)用時，選擇將需要不同資源的服務(wù)部署于同一服務(wù)器中，以實現(xiàn)計算資源利用率的最大化。相比于使用傳統(tǒng)架構(gòu)，云原生應(yīng)用是注定要在云平臺上運行的應(yīng)用程序，其經(jīng)過設(shè)計、優(yōu)化，易于迭代，且可以快速反饋。云原生應(yīng)用給用戶提供了一個抽象、彈性、高可用的基礎(chǔ)設(shè)施（如數(shù)據(jù)庫、網(wǎng)絡(luò)、存儲等），是未來發(fā)展的大勢所趨，越來越多互聯(lián)網(wǎng)公司、傳統(tǒng)企業(yè)都選擇將自己的應(yīng)用“上云”。因此，未來大量根植于云平臺的應(yīng)用會不斷出現(xiàn)并得到普及。