劉琦
摘 要:隨著容器技術(shù)的快速發(fā)展,應(yīng)用服務(wù)的支撐框架已從原先的物理機(jī)、云計(jì)算虛擬機(jī)到目前的基于Kubernetes的容器平臺(tái)?;谌萜髌脚_(tái)的云原生應(yīng)用通過(guò)應(yīng)用本身的彈性、動(dòng)態(tài)擴(kuò)張實(shí)現(xiàn)可造性(resiliency)。文章從平臺(tái)支持和應(yīng)用本身的改造兩方面說(shuō)明云原生應(yīng)用可造性的實(shí)現(xiàn)方式。
關(guān)鍵詞:云原生應(yīng)用;應(yīng)用服務(wù);可造性
1 云原生應(yīng)用平臺(tái)研究背景
云計(jì)算時(shí)代,各類云計(jì)算平臺(tái)如雨后春筍般出現(xiàn)在各個(gè)企業(yè)中,雖然在服務(wù)類型和平臺(tái)功能上有所差異,但是他們本質(zhì)都是一樣,均是一種資源的服務(wù)模式。云平臺(tái)的快速發(fā)展,衍生了一系列云平臺(tái)產(chǎn)品。隨著大規(guī)模的互聯(lián)網(wǎng)應(yīng)用不斷在云計(jì)算平臺(tái)上遇到挑戰(zhàn),新的應(yīng)用架構(gòu)模式呼之欲出,在眾多的實(shí)踐和方法論中,云原生應(yīng)用是其中的佼佼者,主要包含容器化、容器的動(dòng)態(tài)編排和微服務(wù)。
2 云原生應(yīng)用平臺(tái)介紹
Kubernetes是Google開(kāi)源的容器集群管理系統(tǒng),構(gòu)建在Docker技術(shù)之上,為容器化的應(yīng)用提供資源調(diào)度、部署運(yùn)行、服務(wù)發(fā)現(xiàn)動(dòng)態(tài)伸縮等一系列完整功能,它最大的優(yōu)點(diǎn)是可以顯著提升整個(gè)集群的總CPU利用率,所以成為眾多容器調(diào)度框架中最受歡迎的調(diào)度模式。云原生應(yīng)用平臺(tái)是基于Kubernetes實(shí)現(xiàn)的,在完全兼容Kubernetes、Docker 技術(shù)的基礎(chǔ)上,提高大規(guī)模容器集群管理的便捷性。
2.1 使用場(chǎng)景
2.1.1 大型復(fù)雜系統(tǒng)
原本小而簡(jiǎn)單的應(yīng)用會(huì)隨著長(zhǎng)時(shí)間使用變得臃腫,在大型復(fù)雜系統(tǒng)中,應(yīng)用越大,啟動(dòng)時(shí)間越長(zhǎng),修復(fù)bug和實(shí)施新功能也就愈發(fā)困難且耗時(shí)頗多,從而影響開(kāi)發(fā)和交付的敏捷性,大大降低了生產(chǎn)效率。面對(duì)數(shù)據(jù)中心規(guī)模大、應(yīng)用數(shù)量多,技術(shù)架構(gòu)多樣,但運(yùn)維人力有限的問(wèn)題,將運(yùn)維復(fù)雜度和應(yīng)用規(guī)模解耦是可行的解決思路。從運(yùn)維系統(tǒng)的角度出發(fā),隨著應(yīng)用越來(lái)越復(fù)雜,必須引入相應(yīng)的平臺(tái)化手段進(jìn)行解耦,避免有限的運(yùn)維人力與不斷擴(kuò)大的數(shù)據(jù)規(guī)模之間的矛盾。
云原生應(yīng)用平臺(tái)通過(guò)微服務(wù)架構(gòu)重新構(gòu)建復(fù)雜的應(yīng)用,將單體式應(yīng)用從不同緯度拆分成多個(gè)微服務(wù),每個(gè)微服務(wù)的內(nèi)容使用一個(gè)Docker鏡像管理。在功能不變的情況下,應(yīng)用拆分成了多個(gè)可管理的服務(wù),每個(gè)單體的服務(wù)容易理解、開(kāi)發(fā)和維護(hù)。不同的服務(wù)也可以由不同的團(tuán)隊(duì)來(lái)開(kāi)發(fā),開(kāi)發(fā)團(tuán)隊(duì)可自由選擇開(kāi)發(fā)技術(shù)和程序語(yǔ)言等,每個(gè)服務(wù)又可獨(dú)立部署、獨(dú)立擴(kuò)展。
2.1.2 業(yè)務(wù)頻繁升級(jí)
龐大且復(fù)雜的應(yīng)用的另一問(wèn)題是難以進(jìn)行持續(xù)部署更新,而目前的發(fā)展趨勢(shì)要求應(yīng)用可以在單日內(nèi)多次將修改推送到生產(chǎn)環(huán)境。對(duì)于傳統(tǒng)應(yīng)用而言,更新應(yīng)用的某個(gè)部分,必須重新部署整個(gè)應(yīng)用,更新周期被無(wú)限拉長(zhǎng),漫長(zhǎng)的啟動(dòng)時(shí)間更是雪上加霜,此外,由于不能完全預(yù)見(jiàn)修改的影響,用戶不得不提前進(jìn)行大量人工測(cè)試,使得持續(xù)部署變得不可能。實(shí)現(xiàn)快速迭代首先需要開(kāi)發(fā)獨(dú)立,如果一單體應(yīng)用由幾百人開(kāi)發(fā)一個(gè)模塊,將可能出現(xiàn)代碼提交沖突頻發(fā)、人員過(guò)多而難以溝通解決的情況。團(tuán)隊(duì)規(guī)模越大,沖突概率則越大。
當(dāng)應(yīng)用被拆分成不同的模塊,每個(gè)模塊由10個(gè)人左右進(jìn)行維護(hù)時(shí),首先可大幅降低代碼沖突的概率,當(dāng)技術(shù)沖突發(fā)生時(shí)也更容易解決。每個(gè)模塊對(duì)外提供接口,其他依賴模塊無(wú)需關(guān)注具體的實(shí)現(xiàn)細(xì)節(jié),只需要保證接口正確。適合需要快速上線、頻繁更新升級(jí)的業(yè)務(wù)。
云原生應(yīng)用平臺(tái)通過(guò)持續(xù)集成、持續(xù)交付、持續(xù)運(yùn)維,極大提高軟件的發(fā)布效率。持續(xù)集成強(qiáng)調(diào)開(kāi)發(fā)人員提交了新代碼之后,立刻進(jìn)行構(gòu)建、(單元)測(cè)試,便于確定新代碼和原有代碼能否正確地打包集成在一起。持續(xù)交付在持續(xù)集成的基礎(chǔ)上,將集成的代碼部署到預(yù)發(fā)布環(huán)境和現(xiàn)網(wǎng)環(huán)境上。而持續(xù)運(yùn)維則通過(guò)各種自動(dòng)化工具實(shí)現(xiàn)了整個(gè)應(yīng)用在運(yùn)行過(guò)程中的托管。通過(guò)以上3項(xiàng)功能實(shí)現(xiàn)應(yīng)用全生命周期管理。
2.1.3 功能持續(xù)擴(kuò)展
應(yīng)用要實(shí)現(xiàn)快速迭代,首先需要上線獨(dú)立。如果沒(méi)有拆分微服務(wù),每次上線都將面臨各類挑戰(zhàn)。當(dāng)修改某個(gè)小功能時(shí),因?yàn)橐蕾嚻渌K而造成的模塊耦合、互相依賴,使得整體應(yīng)用上線的復(fù)雜度更高、風(fēng)險(xiǎn)更大、周期更長(zhǎng)。
當(dāng)服務(wù)拆分后,在接口穩(wěn)定的情況下,不同的模塊可以獨(dú)立上線。上線的次數(shù)增多,單次上線的需求列表變小,可隨時(shí)回滾,風(fēng)險(xiǎn)降低,周期縮短,影響面小,從而加快迭代速度。對(duì)于需要接口升級(jí)的部分,可采取灰度的方式,先做接口新增,而非原接口變更,并通過(guò)注冊(cè)中心監(jiān)控接口調(diào)用情況,確保原接口不再使用再進(jìn)行刪除。
2.1.4 應(yīng)用并發(fā)量大、穩(wěn)定、高可用
可靠性是傳統(tǒng)應(yīng)用難以解決的問(wèn)題之一。由于所有模塊都運(yùn)行在同一進(jìn)程中,任何模塊中的一個(gè)bug,例如內(nèi)存泄漏都可能影響到整個(gè)進(jìn)程。此外,由于應(yīng)用中的所有實(shí)例都是唯一,這個(gè)bug將影響整個(gè)應(yīng)用的可用性。
并發(fā)性是另一個(gè)問(wèn)題。對(duì)于并發(fā)量不大的系統(tǒng)而言,進(jìn)行云原生化的驅(qū)動(dòng)力較低,如果只有少量的用戶在線,多線程即可解決問(wèn)題。然而對(duì)于存在突發(fā)性訪問(wèn)高峰,有明顯波峰和波谷的應(yīng)用而言,云原生化不僅可大幅提高其可用性,還可以實(shí)現(xiàn)熱備和雙活等特性。
2.2 核心功能
云原生應(yīng)用平臺(tái)為客戶提供了一套完整的云原生應(yīng)用服務(wù),可提供容器服務(wù)、資源管理與編排、多租戶鏡像倉(cāng)庫(kù)、應(yīng)用部署、應(yīng)用全生命周期管理、持續(xù)集成以及應(yīng)用常用通用組件,例如智能網(wǎng)關(guān)、基礎(chǔ)賬號(hào)體系支撐等功能。主要可以實(shí)現(xiàn)這六大特性:以應(yīng)用驅(qū)動(dòng)資源、多語(yǔ)言集成、一鍵式部署、快速發(fā)布更新、彈性伸縮、持續(xù)穩(wěn)定。
云原生平臺(tái)的主要功能包含以下方面。
2.2.1 資源統(tǒng)一納管
(1)虛擬機(jī)、物理機(jī)混合管理:云原生應(yīng)用平臺(tái)容器平臺(tái)能進(jìn)行統(tǒng)一資源管理和調(diào)度,打通物理機(jī)、虛擬機(jī),使之互相通信,協(xié)同工作?;谠圃鷳?yīng)用平臺(tái)創(chuàng)建的k8s集群,可實(shí)現(xiàn)基于IP地址手動(dòng)添加虛擬機(jī)、物理機(jī)資源節(jié)點(diǎn)。提供對(duì)虛擬機(jī)或物理節(jié)點(diǎn)完善的管理功能,可以方便直觀地獲取主機(jī)監(jiān)控信息以及主機(jī)信息等,包括CPU、內(nèi)存、I/O。
(2)存儲(chǔ)資源管理:云原生應(yīng)用平臺(tái)提供對(duì)存儲(chǔ)節(jié)點(diǎn)完善的管理功能,容器應(yīng)用通過(guò)持久卷實(shí)現(xiàn)狀態(tài)存儲(chǔ),后臺(tái)使用Ceph存儲(chǔ)集群,云原生應(yīng)用平臺(tái)支持存儲(chǔ)節(jié)點(diǎn)動(dòng)態(tài)添加,可以方便直觀地獲取存儲(chǔ)節(jié)點(diǎn)監(jiān)控信息,包括CPU、內(nèi)存、I/O。
(3)異構(gòu)IaaS層資源接入:云原生應(yīng)用平臺(tái)異構(gòu)實(shí)現(xiàn)對(duì)接多種異構(gòu)IaaS,統(tǒng)一其接口及資源模型,可以實(shí)現(xiàn)在不同IaaS部署標(biāo)準(zhǔn)的Kubernetes集群。支持同時(shí)接入虛擬機(jī)CPU、虛擬機(jī)GPU、物理機(jī)CPU、物理機(jī)GPU 4種類型的資源管理。
(4)多集群、多租戶隔離:云原生應(yīng)用平臺(tái)采用多集群、多租管理模型和租戶的資源配額管理,嚴(yán)格實(shí)現(xiàn)多租戶資源/服務(wù)的安全隔離。集群(Cluster)為物理隔離單位,實(shí)現(xiàn)物理資源隔離。租戶(Tenant)為邏輯隔離單位,實(shí)現(xiàn)虛擬資源的邏輯隔離。如一個(gè)公司可創(chuàng)建多個(gè)集群,并在集群中配置多個(gè)租戶,通過(guò)用戶組、用戶和權(quán)限對(duì)各個(gè)集群、租戶的安全性進(jìn)行隔離和控制。同時(shí)也能實(shí)現(xiàn)配額管理,為避免單一租戶過(guò)量占用資源,可通過(guò)K8s集群中的租戶管理實(shí)現(xiàn)資源配額,主要包括CPU和內(nèi)存資源限制,同時(shí)也可以限制容器資源的創(chuàng)建。
2.2.2 集群自動(dòng)化部署
云原生應(yīng)用平臺(tái)容器平臺(tái)提供K8s集群的自動(dòng)化部署??蓪?shí)現(xiàn)部署過(guò)程中每一個(gè)步驟的自動(dòng)化,在整個(gè)生命周期(包括部署在內(nèi))中把必須的人工干預(yù)降低到最小。
2.2.3 多租戶鏡像倉(cāng)庫(kù)
(1)多租戶鏡像管理:云原生應(yīng)用平臺(tái)提供對(duì)容器鏡像的統(tǒng)一管理,內(nèi)容包括鏡像名稱、版本,從軟件包的鏡像構(gòu)成,以及鏡像打包的統(tǒng)一規(guī)范流程,其主要功能包括:鏡像全生命周期管理,鏡像版本管理,安全掃描以及鏡像倉(cāng)庫(kù)訪問(wèn)控制。
(2)鏡像倉(cāng)庫(kù)訪問(wèn)控制:鏡像倉(cāng)庫(kù)實(shí)現(xiàn)多租戶訪問(wèn)控制,用戶可以使用并修改被綁定租戶中的鏡像。
2.2.4 應(yīng)用商店及一鍵式部署
(1)標(biāo)準(zhǔn)應(yīng)用包管理:可以直接通過(guò)配置文件和容器鏡像,對(duì)應(yīng)用包進(jìn)行管理,包括版本、配置文件、腳本等。
(2)大量PaaS、SaaS服務(wù):為用戶提供大量常用應(yīng)用模板,包含成熟的PaaS服務(wù),開(kāi)源的服務(wù)(MySQL、Redis等),實(shí)現(xiàn)應(yīng)用一鍵式部署
(3)自動(dòng)化部署、升級(jí):該平臺(tái)為各種業(yè)務(wù)配置合適的資源進(jìn)行安裝部署,并支持應(yīng)用的更新、升級(jí)、擴(kuò)容、伸縮、卸載等。為各種業(yè)務(wù)配置合適的資源進(jìn)行安裝部署,并支持業(yè)務(wù)的更新、升級(jí)、擴(kuò)容、伸縮、卸載等,其支持業(yè)務(wù)包括:無(wú)狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、多鏡像聯(lián)調(diào)部署模型。
(4)通過(guò)平臺(tái)可以實(shí)現(xiàn)對(duì)應(yīng)用的調(diào)度策略,以容器為最小運(yùn)行單位實(shí)現(xiàn)應(yīng)用的不同調(diào)度策略,包括:①應(yīng)用(容器)間的親和/反親和性調(diào)度,不同的業(yè)務(wù)調(diào)度部署在相同或不同節(jié)點(diǎn)中。②應(yīng)用與節(jié)點(diǎn)的親和/反親和性調(diào)度,應(yīng)用的容器調(diào)度部署到指定的或與指定不同的節(jié)點(diǎn)中。
2.3 平臺(tái)架構(gòu)
在數(shù)字化轉(zhuǎn)型的過(guò)程中,針對(duì)應(yīng)用上云的需求,云原生應(yīng)用平臺(tái)結(jié)合原有的技術(shù)沉淀,為警務(wù)服務(wù)創(chuàng)建了一套云原生應(yīng)用支撐平臺(tái)。在基礎(chǔ)實(shí)施和應(yīng)用層面解決了警務(wù)應(yīng)用在數(shù)字化轉(zhuǎn)型中所面臨的痛點(diǎn),幫助客戶采用云原生技術(shù)實(shí)現(xiàn)應(yīng)用架構(gòu)轉(zhuǎn)型升級(jí)和高效管理。平臺(tái)架構(gòu)如圖1所示。
3 應(yīng)用服務(wù)可造性
3.1 應(yīng)用拆分&集成
3.1.1 分拆模式
云原生應(yīng)用采取有關(guān)松散耦合的服務(wù),它采用的是單一職責(zé)原則。理論上要將應(yīng)用分成多個(gè)小塊,在實(shí)際分拆中一般遵守以下規(guī)則。按照業(yè)務(wù)功能分拆:業(yè)務(wù)功能是指產(chǎn)生價(jià)值的最小單位,一組給定業(yè)務(wù)的功能劃分則取決于企業(yè)本身的類型,每一個(gè)業(yè)務(wù)功能都可以被看作是一種面向業(yè)務(wù),而非技術(shù)的服務(wù)。
3.1.2 分拆規(guī)范
(1)規(guī)范一:服務(wù)縱向拆分最多3層、兩次調(diào)用。服務(wù)拆分是為了橫向擴(kuò)展,因而應(yīng)橫向拆分而非縱向拆成多層級(jí)式。縱向最多拆分3層。
①基礎(chǔ)服務(wù)層:用于屏蔽數(shù)據(jù)庫(kù)、緩存層,提供原子的對(duì)象查詢接口,封裝數(shù)據(jù)從而實(shí)現(xiàn)數(shù)據(jù)庫(kù)擴(kuò)容、緩存替換等。使得數(shù)據(jù)對(duì)上層透明,上層僅調(diào)用這一層的接口而不直接訪問(wèn)數(shù)據(jù)庫(kù)和緩存。
②組合服務(wù)層:這一層調(diào)用基礎(chǔ)服務(wù)層,完成較為復(fù)雜的業(yè)務(wù)邏輯,實(shí)現(xiàn)分布式事務(wù)也多在這一層。
③對(duì)外接口層:調(diào)用組合服務(wù)層對(duì)外提供標(biāo)準(zhǔn)接口。
(2)規(guī)范二:僅單向調(diào)用、嚴(yán)禁循環(huán)調(diào)用。服務(wù)拆分后,如果服務(wù)間的依賴關(guān)系復(fù)雜(如循環(huán)調(diào)用),則升級(jí)將會(huì)變得難以維護(hù)。因而層次之間的調(diào)用規(guī)定如下。
①基礎(chǔ)服務(wù)層主要做數(shù)據(jù)庫(kù)的操作和一些簡(jiǎn)單的業(yè)務(wù)邏輯,不允許調(diào)用其他任何服務(wù)。
②組合服務(wù)層可以調(diào)用基礎(chǔ)服務(wù)層,完成復(fù)雜的業(yè)務(wù)邏輯,可以調(diào)用組合服務(wù)層,不允許循環(huán)調(diào)用,不允許調(diào)用對(duì)外接口層服務(wù)。
③對(duì)外接口層,可以調(diào)用組合業(yè)務(wù)層服務(wù),不允許被其他服務(wù)調(diào)用。如果出現(xiàn)循環(huán)調(diào)用,則使用消息隊(duì)列,將同步調(diào)用改為異步調(diào)用。
(3)規(guī)范三:將串行調(diào)用改為并行或異步調(diào)用。如有的組合服務(wù)需要調(diào)用多個(gè)外部服務(wù),應(yīng)考慮如何通過(guò)消息隊(duì)列實(shí)現(xiàn)異步化和解耦。對(duì)基于Kubernetes的云原生應(yīng)用,使用消息隊(duì)列可增強(qiáng)其橫向擴(kuò)展能力。或者通過(guò)Kubernetes內(nèi)服務(wù)自帶的負(fù)債均,這樣處理時(shí)間會(huì)大大縮短(不是多次調(diào)用的時(shí)間之和,而是調(diào)用所需最長(zhǎng)時(shí)間)。
(4)規(guī)范四:接口嚴(yán)格按照REST標(biāo)準(zhǔn)寫(xiě)。以前不同服務(wù)接口之間傳遞往往通過(guò)數(shù)據(jù)結(jié)構(gòu),從底層一直到上層使用同一個(gè)數(shù)據(jù)結(jié)構(gòu),或上層的數(shù)據(jù)結(jié)構(gòu)內(nèi)嵌底層的數(shù)據(jù)結(jié)構(gòu)。當(dāng)數(shù)據(jù)結(jié)構(gòu)中添加或者刪除一個(gè)字段的時(shí)候,波及的面會(huì)非常大。因REST標(biāo)準(zhǔn)在每?jī)蓚€(gè)接口之間約定,嚴(yán)禁內(nèi)嵌和透?jìng)?。這樣接口協(xié)議的改變,影響面僅僅在調(diào)用方和被調(diào)用方,當(dāng)接口需要更新的時(shí)候比較可控,也容易升級(jí)。
3.2 應(yīng)用容器化
3.2.1 應(yīng)用分析
操作系統(tǒng):應(yīng)用運(yùn)行的操作系統(tǒng)類型和版本,如centos7.2。
運(yùn)行環(huán)境:Java,go,php,python等,以及對(duì)應(yīng)的版本號(hào)。
依賴:如openssl,以及對(duì)應(yīng)的版本號(hào)。
3.2.2 盡量使用TCP、HTTP協(xié)議
服務(wù)間接口調(diào)用使用非標(biāo)準(zhǔn)協(xié)議進(jìn)行交互(如EJB調(diào)用使用t3協(xié)議),無(wú)法通過(guò)負(fù)載均衡器進(jìn)行有效負(fù)載。建議服務(wù)間接口調(diào)用通過(guò)TCP和HTTP協(xié)議進(jìn)行交互,這樣可使用負(fù)載均衡器進(jìn)行有效負(fù)載。
3.2.3 確定域名、端口
每個(gè)服務(wù)盡量只提供一個(gè)服務(wù)。
避免使用IP:如果服務(wù)需要與其他服務(wù)通訊,由于容器IP是不固定的,依賴IP地址將無(wú)法實(shí)現(xiàn)通訊。建議在程序中盡量使用域名代替IP,并且通過(guò)Kubernetes的Service負(fù)債均衡,尤其對(duì)傳統(tǒng)非改造的應(yīng)用直接搬遷,需要使用這個(gè)模式。集群中訪問(wèn),則使用service的域名方式訪問(wèn)更好。
監(jiān)聽(tīng)固定端口:對(duì)于標(biāo)準(zhǔn)的服務(wù)只需提供一個(gè)對(duì)外服務(wù)端口,而有些服務(wù)在運(yùn)行過(guò)程中會(huì)自己產(chǎn)生一些服務(wù)端口對(duì)外服務(wù),而且這些端口是隨機(jī)產(chǎn)生,給管理帶來(lái)不便。建議在服務(wù)設(shè)計(jì)時(shí)盡量使用固定服務(wù)端口,并且需要讓端口固定下來(lái)并體現(xiàn)在集成文檔中。
3.2.4 設(shè)計(jì)好程序啟動(dòng)過(guò)程和時(shí)間
雖然容器服務(wù)本身可以做到“秒級(jí)”啟動(dòng),但是對(duì)于程序如何在容器/Kubernetes里啟動(dòng),需要遵守標(biāo)準(zhǔn)的規(guī)范。程序在容器內(nèi)啟動(dòng)過(guò)程大體如圖2所示。
Kubernetes提供雙重檢查:liveness和readiness。容器啟動(dòng)并不代表程序已經(jīng)可以被訪問(wèn),因?yàn)槿萜鲀?nèi)部程序啟動(dòng)比較費(fèi)時(shí),如果此時(shí)去訪問(wèn)服務(wù)則很容易timeout。
Liveness: 確保程序還存活,否則Kubernetes就會(huì)重啟這個(gè)POD。
Readiness: 確保程序已經(jīng)可以接收流量了,否則不會(huì)分發(fā)流量給它。
3.2.5 充分利用K8s Deployment & Service
使用Kubernetes的Deployment的方式來(lái)部署服務(wù),Deployment會(huì)保證服務(wù)時(shí)刻有一定的副本存活,提高了服務(wù)穩(wěn)定性。其次,Kubernetes的Service可以實(shí)現(xiàn)負(fù)載的均衡。Kube-DNS可以將Service名解析成具體的ClusterIP?;贙ube-DNS和Service的特性,可以實(shí)現(xiàn)服務(wù)的注冊(cè)發(fā)現(xiàn)和負(fù)載均衡。具體如圖3所示。
3.3 應(yīng)用無(wú)狀態(tài)化
有狀態(tài)應(yīng)用是指在應(yīng)用內(nèi)存儲(chǔ)狀態(tài)信息。例如用戶在登錄后會(huì)有一定的會(huì)話信息(也就是應(yīng)用中的session對(duì)象)存儲(chǔ)在實(shí)例中,如果該實(shí)例異常停止,該用戶的會(huì)話信息就會(huì)丟失。
建議應(yīng)用開(kāi)發(fā)時(shí)將用戶的會(huì)話信息保存到緩存(如Redis,Memcached)中,根據(jù)用戶的唯一標(biāo)識(shí)session_id來(lái)對(duì)緩存服務(wù)器進(jìn)行存取用戶的會(huì)話信息,這樣會(huì)話信息與應(yīng)用實(shí)例分離,實(shí)現(xiàn)應(yīng)用無(wú)狀態(tài)化。
3.4 熱數(shù)據(jù)緩存
熱數(shù)據(jù)指程序在運(yùn)行過(guò)程中經(jīng)常使用的數(shù)據(jù),傳統(tǒng)方式是程序在啟動(dòng)時(shí)通過(guò)數(shù)據(jù)庫(kù)加載到程序?qū)嵗彺嬷?,提高?shù)據(jù)的訪問(wèn)速度,但往往因?yàn)榧虞d的數(shù)據(jù)過(guò)多而導(dǎo)致系統(tǒng)啟動(dòng)過(guò)慢。
建議程序在設(shè)計(jì)時(shí)將熱點(diǎn)數(shù)據(jù)存放到緩存(如Redis,Memcached)中,在啟動(dòng)時(shí)避免執(zhí)行加載緩存動(dòng)作,提高程序啟動(dòng)速度,相關(guān)熱點(diǎn)數(shù)據(jù)可通過(guò)手動(dòng)或自動(dòng)方式更新到緩存中,程序通過(guò)訪問(wèn)緩存獲取相關(guān)熱點(diǎn)數(shù)據(jù)。
3.5 有狀態(tài)數(shù)據(jù)庫(kù)
服務(wù)必須是松散耦合的,以便部署和獨(dú)立擴(kuò)容,尤其當(dāng)各個(gè)服務(wù)需要橫跨多個(gè)服務(wù)時(shí)。當(dāng)應(yīng)用需要從多個(gè)服務(wù)中查詢到數(shù)據(jù)時(shí),有時(shí)需要根據(jù)需求和規(guī)模對(duì)數(shù)據(jù)庫(kù)進(jìn)行復(fù)制或分片,不同的服務(wù)具有不同的數(shù)據(jù)存儲(chǔ)需求。
服務(wù)單獨(dú)DB:為每個(gè)服務(wù)配備一個(gè)獨(dú)享的數(shù)據(jù)庫(kù)模式,該數(shù)據(jù)庫(kù)僅能被其對(duì)應(yīng)服務(wù)的API單獨(dú)訪問(wèn),而不能被其他服務(wù)直接訪問(wèn)到。每個(gè)服務(wù)應(yīng)該擁有一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)ID,以便它們?cè)讵?dú)享訪問(wèn)的同時(shí),禁止再訪問(wèn)其他的服務(wù)表集。
服務(wù)共享DB:服務(wù)單獨(dú)DB是一種理想的微服務(wù)模式,只有在新的云原生應(yīng)用中會(huì)用到。但對(duì)于采用微服務(wù)架構(gòu)的應(yīng)用,按服務(wù)共享DB的模式雖然有些違背微服務(wù)的理念,但對(duì)于將傳統(tǒng)的單體應(yīng)用拆分成較小的邏輯塊而言是更為適用的。在該模式下,一個(gè)數(shù)據(jù)庫(kù)可以匹配多個(gè)服務(wù),當(dāng)然至多2~3個(gè),否則會(huì)影響到擴(kuò)容、自治性和獨(dú)立性。
3.6 網(wǎng)絡(luò)梳理
對(duì)應(yīng)用容器化后的網(wǎng)絡(luò)進(jìn)行規(guī)劃是另一個(gè)重要工作。首先容器平臺(tái)本身分為管理集群master,計(jì)算集群slave以及包含其他日志、監(jiān)控、鏡像倉(cāng)庫(kù)等系統(tǒng)服務(wù)的集群??梢詫⒐芾砑?、日志、監(jiān)控等劃入管理IP網(wǎng)段,將計(jì)算集群劃入業(yè)務(wù)IP網(wǎng)段,并且對(duì)每臺(tái)主機(jī)上安裝的組件進(jìn)行端口規(guī)劃。
另外,需要根據(jù)應(yīng)用的特性,進(jìn)行網(wǎng)絡(luò)模式選擇。例如無(wú)狀態(tài)的分布式應(yīng)用,可以在容器部署時(shí)使用bridge模式。需要指定端口的應(yīng)用,或者對(duì)網(wǎng)絡(luò)性能要求高的應(yīng)用,更適合使用host網(wǎng)絡(luò)模式,但使用host模式時(shí),需要進(jìn)行網(wǎng)絡(luò)端口資源規(guī)劃,同樣的應(yīng)用實(shí)例只能在一臺(tái)主機(jī)上部署一個(gè),避免端口沖突。
4 云原生應(yīng)用平臺(tái)展望
云原生應(yīng)用,專門(mén)為在云平臺(tái)部署和運(yùn)行而設(shè)計(jì)的應(yīng)用。通過(guò)容器化、容器的動(dòng)態(tài)編排和微服務(wù)來(lái)統(tǒng)一管理應(yīng)用,實(shí)現(xiàn)資源的統(tǒng)一納管、集群的自動(dòng)化部署、多租戶鏡像倉(cāng)庫(kù)和應(yīng)用商店一鍵式部署,整個(gè)平臺(tái)滿足應(yīng)用運(yùn)行所需的資源、部署、管理等各個(gè)環(huán)節(jié),真正可實(shí)現(xiàn)應(yīng)用自動(dòng)化管理,帶來(lái)應(yīng)用開(kāi)發(fā)的新時(shí)代。
[參考文獻(xiàn)]
[1]BALALAIE A,HEYDARNOORI A,JAMSHIDI P.Microservices architecture enables devops: migration to a cloud-native architecture[J].IEEE Software,2016(3):42-52.
[2]BALALAIE A,HEYDARNOORI A,JAMSHIDI P.Migrating to cloud-native architectures using microservices: an experience report[C].Taormina:European Conference on Service-Oriented and Cloud Computing,2015:201-215.
[3]BREWER E A.Kubernetes and the path to cloud native[C].New York:Proceedings of the Sixth ACM Symposium on Cloud Computing,2015:167.
[4]ROUSSEV V,MCCULLEY S.Forensic analysis of cloud-native artifacts[J].Digital Investigation,2016(16):104-113.
[5]TOFFETTI G,BRUNNER S,BL?CHLINGER M,et al.Self-managing cloud-native applications: design,implementation,and experience[J]. Future Generation Computer Systems,2017(72):165-179.