楊思譽(yù)，劉海霞，童基均，冉宇瑤

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

0 引言

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

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

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

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

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

1.1 云計(jì)算

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

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

1.2 云原生

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

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

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

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

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

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

2.1.1 服務(wù)消費(fèi)

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

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

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

2.1.2 負(fù)載均衡

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

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

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

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

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

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

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

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

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

在分布式環(huán)境中，許多服務(wù)依賴項(xiàng)中的一些請求必然會(huì)失敗。Hystrix 是一個(gè)庫，通過添加延遲容忍和容錯(cuò)邏輯，幫助人們控制這些分布式服務(wù)之間的交互。Hystrix 通過隔離服務(wù)之間的訪問點(diǎn)、停止級(jí)聯(lián)失敗和提供回退選項(xiàng)實(shí)現(xiàn)該功能。熔斷器是微服務(wù)彈性化過程中的一部分，能很好地保護(hù)應(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ù)時(shí)，服務(wù)因調(diào)用鏈路上的某個(gè)微服務(wù)而下線導(dǎo)致整體不可用，或該服務(wù)響應(yīng)時(shí)間過長，調(diào)用鏈上的前置服務(wù)會(huì)處于等待狀態(tài)而耗盡資源（如線程池資源耗盡），導(dǎo)致服務(wù)集體下線，系統(tǒng)崩潰。

2.4.2 熔斷與降級(jí)

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

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

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

在云原生的理念中，一切部署、運(yùn)維都由一個(gè)自動(dòng)化平臺(tái)進(jìn)行維護(hù)，因此需要一個(gè)平臺(tái)能實(shí)時(shí)監(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ù)，而一個(gè)請求的處理將會(huì)涉及大量的服務(wù)間調(diào)用。離散的微服務(wù)在讓應(yīng)用內(nèi)部解耦的同時(shí)，也增加了調(diào)試方面的困難，導(dǎo)致難以定位問題出現(xiàn)的具體位置。一個(gè)請求的處理可能會(huì)呈樹狀以調(diào)用不同的微服務(wù)，為了追蹤一個(gè)請求調(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），在兩臺(tái)遠(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 個(gè)分別運(yùn)行在端口8001、8002、8003 的服務(wù)注冊與發(fā)現(xiàn)集群，三者之間互相注冊，組成了高可用集群。

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

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

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

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

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

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

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

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

3.3 打包與部署

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

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

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

4 結(jié)語

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