楊思譽(yù),劉海霞,童基均,冉宇瑤
(1.浙江理工大學(xué) 信息學(xué)院,浙江 杭州310016 ;2.浙江理工大學(xué) 科技與藝術(shù)學(xué)院,浙江 紹興 312369)
隨著計(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)用程序。
云晴[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ù)。
云計(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ū)分
云原生技術(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)容
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.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)確性。
在分布式系統(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)容。
在微服務(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)行使用。
在分布式環(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ù)。
在云原生應(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)用鏈路上的具體信息,本文引入分布式鏈路追蹤的概念。
本次部署采用騰訊云的云服務(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.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)用不可用。
在部署應(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)
本文采用云原生的理念和開發(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)并得到普及。