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

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

0 引言

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

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

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

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

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

1.1 云計算

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

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

1.2 云原生

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

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

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

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

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

2.1 服務消費與負載均衡

2.1.1 服務消費

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

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

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

2.1.2 負載均衡

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

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

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

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

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

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

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

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

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

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

2.4.1 服務雪崩

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

2.4.2 熔斷與降級

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

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

2.4.3 服務監(jiān)控

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

2.5 鏈路追蹤

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

3 配置要求及分析

3.1 硬件配置

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

Table 1 Server configuration表1 服務器配置

3.2 微服務介紹

3.2.1 基礎(chǔ)設施

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

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

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

3.2.2 服務提供與服務消費

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

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

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

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

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

3.3 打包與部署

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

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

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

4 結(jié)語

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