基于云原生應(yīng)用平臺(tái)實(shí)現(xiàn)應(yīng)用服務(wù)可造性

劉琦

摘 要：隨著容器技術(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.