云原生架構(gòu)需遵循七個(gè)原則

李代麗
在軟件開發(fā)過程中,當(dāng)代碼數(shù)量與開發(fā)團(tuán)隊(duì)規(guī)模都擴(kuò)張到一定程度后,就需要重構(gòu)應(yīng)用,通過模塊化與組件化的手段分離關(guān)注點(diǎn),降低應(yīng)用的復(fù)雜度,提升軟件的開發(fā)效率,降低維護(hù)成本。

作為一種架構(gòu)模式,云原生架構(gòu)通過若干原則來對應(yīng)用架構(gòu)進(jìn)行核心控制。這些原則可以幫助技術(shù)主管和架構(gòu)師在進(jìn)行技術(shù)選型時(shí)更加高效、準(zhǔn)確,下面將展開具體介紹。

1、服務(wù)化原則

在軟件開發(fā)過程中,當(dāng)代碼數(shù)量與開發(fā)團(tuán)隊(duì)規(guī)模都擴(kuò)張到一定程度后,就需要重構(gòu)應(yīng)用,通過模塊化與組件化的手段分離關(guān)注點(diǎn),降低應(yīng)用的復(fù)雜度,提升軟件的開發(fā)效率,降低維護(hù)成本。

如圖1,隨著業(yè)務(wù)的不斷發(fā)展,單體應(yīng)用能夠承載的容量將逐漸到達(dá)上限,即使通過應(yīng)用改造來突破垂直擴(kuò)展(Scale Up)的瓶頸,并將其轉(zhuǎn)化為支撐水平擴(kuò)展(Scale Out)的能力,在全局并發(fā)訪問的情況下,也依然會面臨數(shù)據(jù)計(jì)算復(fù)雜度和存儲容量的問題。因此,需要將單體應(yīng)用進(jìn)一步拆分,按業(yè)務(wù)邊界重新劃分成分布式應(yīng)用,使應(yīng)用與應(yīng)用之間不再直接共享數(shù)據(jù),而是通過約定好的契約進(jìn)行通信,以提高擴(kuò)展性。

1.png

圖1應(yīng)用服務(wù)化擴(kuò)展

服務(wù)化設(shè)計(jì)原則是指通過服務(wù)化架構(gòu)拆分不同生命周期的業(yè)務(wù)單元,實(shí)現(xiàn)業(yè)務(wù)單元的獨(dú)立迭代,從而加快整體的迭代速度,保證迭代的穩(wěn)定性。同時(shí),服務(wù)化架構(gòu)采用的是面向接口編程方式,增加了軟件的復(fù)用程度,增強(qiáng)了水平擴(kuò)展的能力。服務(wù)化設(shè)計(jì)原則還強(qiáng)調(diào)在架構(gòu)層面抽象化業(yè)務(wù)模塊之間的關(guān)系,從而幫助業(yè)務(wù)模塊實(shí)現(xiàn)基于服務(wù)流量(而非網(wǎng)絡(luò)流量)的策略控制和治理,而無須關(guān)注這些服務(wù)是基于何種編程語言開發(fā)的。

有關(guān)服務(wù)化設(shè)計(jì)原則的實(shí)踐在業(yè)界已有很多成功案例。其中影響最廣、最為業(yè)界稱道的是Netflix在生產(chǎn)系統(tǒng)上所進(jìn)行的大規(guī)模微服務(wù)化實(shí)踐。通過這次實(shí)踐,Netflix在全球不僅承接了多達(dá)1.67億訂閱用戶以及全球互聯(lián)網(wǎng)帶寬容量15%以上的流量,而且在開源領(lǐng)域貢獻(xiàn)了Eureka、Zuul、Hystrix等出色的微服務(wù)組件。

不僅海外公司正在不斷進(jìn)行服務(wù)化實(shí)踐,國內(nèi)公司對服務(wù)化也有很高的認(rèn)知。隨著近幾年互聯(lián)網(wǎng)化的發(fā)展,無論是新銳互聯(lián)網(wǎng)公司,還是傳統(tǒng)大型企業(yè),在服務(wù)化實(shí)踐上都有很好的實(shí)踐和成功案例。阿里巴巴的服務(wù)化實(shí)踐發(fā)端于2008年的五彩石項(xiàng)目,歷經(jīng)10年的發(fā)展,穩(wěn)定支撐歷年大促活動(dòng)。以2019年“雙11”當(dāng)天數(shù)據(jù)為例,阿里巴巴的分布式系統(tǒng)創(chuàng)單峰值為每秒54.4萬筆,實(shí)時(shí)計(jì)算處理為每秒25.5億筆。阿里巴巴在服務(wù)化領(lǐng)域的實(shí)踐,已通過Apache Dubbo、Nacos、Sentinel、Seata、Chaos Blade等開源項(xiàng)目分享給業(yè)界,同時(shí),這些組件與Spring Cloud的集成Spring Cloud Alibaba已成為Spring Cloud Netflix的繼任者。

雖然隨著云原生浪潮的興起,服務(wù)化原則不斷演進(jìn)、落地于實(shí)際業(yè)務(wù),但企業(yè)在實(shí)際落地過程中也會遇到不少的挑戰(zhàn)。比如,與自建數(shù)據(jù)中心相比,公有云下的服務(wù)化可能存在巨大的資源池,使得機(jī)器錯(cuò)誤率顯著提高;按需付費(fèi)增加了擴(kuò)縮容的操作頻度;新的環(huán)境要求應(yīng)用啟動(dòng)更快、應(yīng)用與應(yīng)用之間無強(qiáng)依賴關(guān)系、應(yīng)用能夠在不同規(guī)格的節(jié)點(diǎn)之間隨意調(diào)度等諸多需要考慮的實(shí)際問題。但可以預(yù)見的是,這些問題會隨著云原生架構(gòu)的不斷演進(jìn)而得到逐一解決。

2、彈性原則

彈性原則是指系統(tǒng)部署規(guī)??梢噪S著業(yè)務(wù)量變化自動(dòng)調(diào)整大小,而無須根據(jù)事先的容量規(guī)劃準(zhǔn)備固定的硬件和軟件資源。優(yōu)秀的彈性能力不僅能夠改變企業(yè)的IT成本模式,使得企業(yè)不用再考慮額外的軟硬件資源成本支出(閑置成本),也能更好地支持業(yè)務(wù)規(guī)模的爆發(fā)式擴(kuò)張,不再因?yàn)檐浻布Y源儲備不足而留下遺憾。

在云原生時(shí)代,企業(yè)構(gòu)建IT系統(tǒng)的門檻大幅降低,這極大地提升了企業(yè)將業(yè)務(wù)規(guī)劃落地為產(chǎn)品與服務(wù)的效率。這一點(diǎn)在移動(dòng)互聯(lián)網(wǎng)和游戲行業(yè)中顯得尤為突出。一款應(yīng)用成為爆款后,其用戶數(shù)量呈現(xiàn)指數(shù)級增長的案例不在少數(shù)。而業(yè)務(wù)呈指數(shù)級增長會對企業(yè)IT系統(tǒng)的性能帶來巨大考驗(yàn)。面對這樣的挑戰(zhàn),在傳統(tǒng)架構(gòu)中,通常是開發(fā)人員、運(yùn)維人員疲于調(diào)優(yōu)系統(tǒng)性能,但是,即使他們使出渾身解數(shù),也未必能夠完全解決系統(tǒng)的瓶頸問題,最終因系統(tǒng)無法應(yīng)對不斷涌入的海量用戶而造成應(yīng)用癱瘓。

除了面臨業(yè)務(wù)呈指數(shù)級增長的考驗(yàn)之外,業(yè)務(wù)的峰值特征將是另一個(gè)重要的挑戰(zhàn)。比如,電影票訂票系統(tǒng)下午時(shí)段的流量遠(yuǎn)超凌晨時(shí)段,而周末的流量相比工作日甚至?xí)脦妆?;還有外賣訂餐系統(tǒng),在午餐和晚餐前后往往會出現(xiàn)訂單峰值時(shí)段。在傳統(tǒng)架構(gòu)中,為了應(yīng)對這類具有明顯峰值特征的場景,企業(yè)需要為峰值時(shí)段的流量提前準(zhǔn)備大量的計(jì)算、存儲及網(wǎng)絡(luò)資源并為這些資源付費(fèi),而這些資源在大部分時(shí)間內(nèi)卻處于閑置狀態(tài)。

因此,在云原生時(shí)代,企業(yè)在構(gòu)建IT系統(tǒng)時(shí),應(yīng)該盡早考慮讓應(yīng)用架構(gòu)具備彈性能力,以便在快速發(fā)展的業(yè)務(wù)規(guī)模面前靈活應(yīng)對各種場景需求,充分利用云原生技術(shù)及成本優(yōu)勢。

要想構(gòu)建彈性的系統(tǒng)架構(gòu),需要遵循如下四個(gè)基本原則。

1)按功能切割應(yīng)用

一個(gè)大型的復(fù)雜系統(tǒng)可能由成百上千個(gè)服務(wù)組成,架構(gòu)師在設(shè)計(jì)架構(gòu)時(shí),需要遵循的原則是:將相關(guān)的邏輯放到一起,不相關(guān)的邏輯拆解到獨(dú)立的服務(wù)中,各服務(wù)之間通過標(biāo)準(zhǔn)的服務(wù)發(fā)現(xiàn)(Service Discovery)找到對方,并使用標(biāo)準(zhǔn)的接口進(jìn)行通信。各服務(wù)之間松耦合,這使得每一個(gè)服務(wù)能夠各自獨(dú)立地完成彈性伸縮,從而避免服務(wù)上下游關(guān)聯(lián)故障的發(fā)生。

2)支持水平切分

按功能切割應(yīng)用并沒有完全解決彈性的問題。一個(gè)應(yīng)用被拆解為眾多服務(wù)后,隨著用戶流量的增長,單個(gè)服務(wù)最終也會遇到系統(tǒng)瓶頸。因此在設(shè)計(jì)上,每個(gè)服務(wù)都需要具備可水平切分的能力,以便將服務(wù)切分為不同的邏輯單元,由每個(gè)單元處理一部分用戶流量,從而使服務(wù)自身具備良好的擴(kuò)展能力。這其中最大的挑戰(zhàn)在于數(shù)據(jù)庫系統(tǒng),因?yàn)閿?shù)據(jù)庫系統(tǒng)自身是有狀態(tài)的,所以合理地切分?jǐn)?shù)據(jù)并提供正確的事務(wù)機(jī)制將是一個(gè)非常復(fù)雜的工程。不過,在云原生時(shí)代,云平臺所提供的云原生數(shù)據(jù)庫服務(wù)可以解決大部分復(fù)雜的分布式系統(tǒng)問題,因此,如果企業(yè)是通過云平臺提供的能力來構(gòu)建彈性系統(tǒng),自然就會擁有數(shù)據(jù)庫系統(tǒng)的彈性能力。

3)自動(dòng)化部署

系統(tǒng)突發(fā)流量通常無法預(yù)計(jì),因此常用的解決方案是,通過人工擴(kuò)容系統(tǒng)的方式,使系統(tǒng)具備支持更大規(guī)模用戶訪問的能力。在完成架構(gòu)拆分之后,彈性系統(tǒng)還需要具備自動(dòng)化部署能力,以便根據(jù)既定的規(guī)則或者外部流量突發(fā)信號觸發(fā)系統(tǒng)的自動(dòng)化擴(kuò)容功能,滿足系統(tǒng)對于縮短突發(fā)流量影響時(shí)長的及時(shí)性要求,同時(shí)在峰值時(shí)段結(jié)束后自動(dòng)縮容系統(tǒng),降低系統(tǒng)運(yùn)行的資源占用成本。

4)支持服務(wù)降級

彈性系統(tǒng)需要提前設(shè)計(jì)異常應(yīng)對方案,比如,對服務(wù)進(jìn)行分級治理,在彈性機(jī)制失效、彈性資源不足或者流量峰值超出預(yù)期等異常情況下,系統(tǒng)架構(gòu)需要具備服務(wù)降級的能力,通過降低部分非關(guān)鍵服務(wù)的質(zhì)量,或者關(guān)閉部分增強(qiáng)功能來讓出資源,并擴(kuò)容重要功能對應(yīng)的服務(wù)容量,以確保產(chǎn)品的主要功能不受影響。

國內(nèi)外已有很多成功構(gòu)建大規(guī)模彈性系統(tǒng)的實(shí)踐案例,其中最具代表性的是阿里巴巴一年一度的“雙11”大促活動(dòng)。為了應(yīng)對相較于平時(shí)上百倍的流量峰值,阿里巴巴每年從阿里云采買彈性資源部署自己的應(yīng)用,并在“雙11”活動(dòng)之后釋放這一批資源,按需付費(fèi),從而大幅降低大促活動(dòng)的資源成本。另一個(gè)例子是新浪微博的彈性架構(gòu),在社會熱點(diǎn)事件發(fā)生時(shí),新浪微博通過彈性系統(tǒng)將應(yīng)用容器擴(kuò)容到阿里云,以應(yīng)對熱點(diǎn)事件導(dǎo)致的大量搜索和轉(zhuǎn)發(fā)請求。系統(tǒng)通過分鐘級的按需擴(kuò)容響應(yīng)能力,大幅降低了熱搜所產(chǎn)生的資源成本。

隨著云原生技術(shù)的發(fā)展,F(xiàn)aaS、Serverless等技術(shù)生態(tài)逐步成熟,構(gòu)建大規(guī)模彈性系統(tǒng)的難度逐步降低。當(dāng)企業(yè)以FaaS、Serverless等技術(shù)理念作為系統(tǒng)架構(gòu)的設(shè)計(jì)原則時(shí),系統(tǒng)就具備了彈性伸縮的能力,企業(yè)也就無須額外為“維護(hù)彈性系統(tǒng)自身”付出成本。

3、可觀測原則

與監(jiān)控、業(yè)務(wù)探活、APM(Application Performance Management,應(yīng)用性能管理)等系統(tǒng)提供的被動(dòng)能力不同,可觀測性更強(qiáng)調(diào)主動(dòng)性,在云計(jì)算這樣的分布式系統(tǒng)中,主動(dòng)通過日志、鏈路跟蹤和度量等手段,讓一次App點(diǎn)擊所產(chǎn)生的多次服務(wù)調(diào)用耗時(shí)、返回值和參數(shù)都清晰可見,甚至可以下鉆到每次第三方軟件調(diào)用、SQL請求、節(jié)點(diǎn)拓?fù)洹⒕W(wǎng)絡(luò)響應(yīng)等信息中。運(yùn)維、開發(fā)和業(yè)務(wù)人員通過這樣的觀測能力可以實(shí)時(shí)掌握軟件的運(yùn)行情況,并獲得前所未有的關(guān)聯(lián)分析能力,以便不斷優(yōu)化業(yè)務(wù)的健康度和用戶體驗(yàn)。

隨著云計(jì)算的全面發(fā)展,企業(yè)的應(yīng)用架構(gòu)發(fā)生了顯著變化,正逐步從傳統(tǒng)的單體應(yīng)用向微服務(wù)過渡。在微服務(wù)架構(gòu)中,各服務(wù)之間松耦合的設(shè)計(jì)方式使得版本迭代更快、周期更短;基礎(chǔ)設(shè)施層中的Kubernetes等已經(jīng)成為容器的默認(rèn)平臺;服務(wù)可以通過流水線實(shí)現(xiàn)持續(xù)集成與部署。這些變化可將服務(wù)的變更風(fēng)險(xiǎn)降到最低,提升了研發(fā)的效率。

在微服務(wù)架構(gòu)中,系統(tǒng)的故障點(diǎn)可能出現(xiàn)在任何地方,因此我們需要針對可觀測性進(jìn)行體系化設(shè)計(jì),以降低MTTR(故障平均修復(fù)時(shí)間)。

要想構(gòu)建可觀測性體系,需要遵循如下三個(gè)基本原則。

數(shù)據(jù)的全面采集

指標(biāo)(Metric)、鏈路跟蹤(Tracing)和日志(Logging)這三類數(shù)據(jù)是構(gòu)建一個(gè)完整的可觀測性系統(tǒng)的“三大支柱”。而系統(tǒng)的可觀測性就是需要完整地采集、分析和展示這三類數(shù)據(jù)。

(1)指標(biāo)

指標(biāo)是指在多個(gè)連續(xù)的時(shí)間周期里用于度量的KPI數(shù)值。一般情況下,指標(biāo)會按軟件架構(gòu)進(jìn)行分層,分為系統(tǒng)資源指標(biāo)(如CPU使用率、磁盤使用率和網(wǎng)絡(luò)帶寬情況等)、應(yīng)用指標(biāo)(如出錯(cuò)率、服務(wù)等級協(xié)議SLA、服務(wù)滿意度APDEX、平均延時(shí)等)、業(yè)務(wù)指標(biāo)(如用戶會話數(shù)、訂單數(shù)量和營業(yè)額等)。

(2)鏈路跟蹤

鏈路跟蹤是指通過TraceId的唯一標(biāo)識來記錄并還原發(fā)生一次分布式調(diào)用的完整過程,貫穿數(shù)據(jù)從瀏覽器或移動(dòng)端經(jīng)過服務(wù)器處理,到執(zhí)行SQL或發(fā)起遠(yuǎn)程調(diào)用的整個(gè)過程。

(3)日志

日志通常用來記錄應(yīng)用運(yùn)行的執(zhí)行過程、代碼調(diào)試、錯(cuò)誤異常等信息,如Nginx日志可以記錄遠(yuǎn)端IP、發(fā)生請求時(shí)間、數(shù)據(jù)大小等信息。日志數(shù)據(jù)需要集中化存儲,并具備可檢索的能力。

數(shù)據(jù)的關(guān)聯(lián)分析

讓各數(shù)據(jù)之間產(chǎn)生更多的關(guān)聯(lián),這一點(diǎn)對于一個(gè)可觀測性系統(tǒng)而言尤為重要。出現(xiàn)故障時(shí),有效的關(guān)聯(lián)分析可以實(shí)現(xiàn)對故障的快速定界與定位,從而提升故障處理效率,減少不必要的損失。一般情況下,我們會將應(yīng)用的服務(wù)器地址、服務(wù)接口等信息作為附加屬性,與指標(biāo)、調(diào)用鏈、日志等信息綁定,并且賦予可觀測系統(tǒng)一定的定制能力,以便靈活滿足更加復(fù)雜的運(yùn)維場景需求。

統(tǒng)一監(jiān)控視圖與展現(xiàn)

多種形式、多個(gè)維度的監(jiān)控視圖可以幫助運(yùn)維和開發(fā)人員快速發(fā)現(xiàn)系統(tǒng)瓶頸,消除系統(tǒng)隱患。監(jiān)控?cái)?shù)據(jù)的呈現(xiàn)形式應(yīng)該不僅僅是指標(biāo)趨勢圖表、柱狀圖等,還需要結(jié)合復(fù)雜的實(shí)際應(yīng)用場景需要,讓視圖具備下鉆分析和定制能力,以滿足運(yùn)維監(jiān)控、版本發(fā)布管理、故障排除等多場景需求。

隨著云原生技術(shù)的發(fā)展,基于異構(gòu)微服務(wù)架構(gòu)的場景會越來越多、越來越復(fù)雜,而可觀測性是一切自動(dòng)化能力構(gòu)建的基礎(chǔ)。只有實(shí)現(xiàn)全面的可觀測性,才能真正提升系統(tǒng)的穩(wěn)定性、降低MTTR。因此,如何構(gòu)建系統(tǒng)資源、容器、網(wǎng)絡(luò)、應(yīng)用、業(yè)務(wù)的全棧可觀測體系,是每個(gè)企業(yè)都需要思考的問題。

4、韌性原則

韌性是指當(dāng)軟件所依賴的軟硬件組件出現(xiàn)異常時(shí),軟件所表現(xiàn)出來的抵御能力。這些異常通常包括硬件故障、硬件資源瓶頸(如CPU或網(wǎng)卡帶寬耗盡)、業(yè)務(wù)流量超出軟件設(shè)計(jì)承受能力、影響機(jī)房正常工作的故障或?yàn)?zāi)難、所依賴軟件發(fā)生故障等可能造成業(yè)務(wù)不可用的潛在影響因素。

業(yè)務(wù)上線之后,在運(yùn)行期的大部分時(shí)間里,可能還會遇到各種不確定性輸入和不穩(wěn)定依賴的情況。當(dāng)這些非正常場景出現(xiàn)時(shí),業(yè)務(wù)需要盡可能地保證服務(wù)質(zhì)量,滿足當(dāng)前以聯(lián)網(wǎng)服務(wù)為代表的“永遠(yuǎn)在線”的要求。因此,韌性能力的核心設(shè)計(jì)理念是面向失敗設(shè)計(jì),即考慮如何在各種依賴不正常的情況下,減小異常對系統(tǒng)及服務(wù)質(zhì)量的影響并盡快恢復(fù)正常。

韌性原則的實(shí)踐與常見架構(gòu)主要包括服務(wù)異步化能力、重試/限流/降級/熔斷/反壓、主從模式、集群模式、多AZ(Availability Zone,可用區(qū))的高可用、單元化、跨區(qū)域(Region)容災(zāi)、異地多活容災(zāi)等。

下面結(jié)合具體案例詳細(xì)說明如何在大型系統(tǒng)中進(jìn)行韌性設(shè)計(jì)。“雙11”對于阿里巴巴來說是一場不能輸?shù)膽?zhàn)役,因此其系統(tǒng)的設(shè)計(jì)在策略上需要嚴(yán)格遵循韌性原則。例如,在統(tǒng)一接入層通過流量清洗實(shí)現(xiàn)安全策略,防御黑產(chǎn)攻擊;通過精細(xì)化限流策略確保峰值流量穩(wěn)定,從而保障后端工作正常進(jìn)行。為了提升全局的高可用能力,阿里巴巴通過單元化機(jī)制實(shí)現(xiàn)了跨區(qū)域多活容災(zāi),通過同城容災(zāi)機(jī)制實(shí)現(xiàn)同城雙活容災(zāi),從而最大程度提升IDC(Internet Data Center,互聯(lián)網(wǎng)數(shù)據(jù)中心)的服務(wù)質(zhì)量。在同一IDC內(nèi)通過微服務(wù)和容器技術(shù)實(shí)現(xiàn)業(yè)務(wù)的無狀態(tài)遷移;通過多副本部署提高高可用能力;通過消息完成微服務(wù)間的異步解耦以降低服務(wù)的依賴性,同時(shí)提升系統(tǒng)吞吐量。從每個(gè)應(yīng)用的角度,做好自身依賴梳理,設(shè)置降級開關(guān),并通過故障演練不斷強(qiáng)化系統(tǒng)健壯性,保證阿里巴巴“雙11”大促活動(dòng)正常穩(wěn)定進(jìn)行。

隨著數(shù)字化進(jìn)程的加快,越來越多的數(shù)字化業(yè)務(wù)成為整個(gè)社會經(jīng)濟(jì)正常運(yùn)轉(zhuǎn)的基礎(chǔ)設(shè)施,但隨著支撐這些數(shù)字化業(yè)務(wù)的系統(tǒng)越來越復(fù)雜,依賴服務(wù)質(zhì)量不確定的風(fēng)險(xiǎn)正變得越來越高,因此系統(tǒng)必須進(jìn)行充分的韌性設(shè)計(jì),以便更好地應(yīng)對各種不確定性。尤其是在涉及核心行業(yè)的核心業(yè)務(wù)鏈路(如金融的支付鏈路、電商的交易鏈路)、業(yè)務(wù)流量入口、依賴復(fù)雜鏈路時(shí),韌性設(shè)計(jì)至關(guān)重要。

5、所有過程自動(dòng)化原則

技術(shù)是把“雙刃劍”,容器、微服務(wù)、DevOps以及大量第三方組件的使用,在降低分布式復(fù)雜性和提升迭代速度的同時(shí),也提高了軟件技術(shù)棧的復(fù)雜度,加大了組件規(guī)模,從而不可避免地導(dǎo)致了軟件交付的復(fù)雜性。如果控制不當(dāng),應(yīng)用就會無法體會到云原生技術(shù)的優(yōu)勢。通過IaC、GitOps、OAM、Operator和大量自動(dòng)化交付工具在CI/CD(持續(xù)集成/持續(xù)交付)流水線中的實(shí)踐,企業(yè)可以標(biāo)準(zhǔn)化企業(yè)內(nèi)部的軟件交付過程,也可以在標(biāo)準(zhǔn)化的基礎(chǔ)上實(shí)現(xiàn)自動(dòng)化,即通過配置數(shù)據(jù)自描述和面向終態(tài)的交付過程,實(shí)現(xiàn)整個(gè)軟件交付和運(yùn)維的自動(dòng)化。

要想實(shí)現(xiàn)大規(guī)模的自動(dòng)化,需要遵循如下四個(gè)基本原則。

1)標(biāo)準(zhǔn)化

實(shí)施自動(dòng)化,首先要通過容器化、IaC、OAM等手段,標(biāo)準(zhǔn)化業(yè)務(wù)運(yùn)行的基礎(chǔ)設(shè)施,并進(jìn)一步標(biāo)準(zhǔn)化對應(yīng)用的定義乃至交付的流程。只有實(shí)現(xiàn)了標(biāo)準(zhǔn)化,才能解除業(yè)務(wù)對特定的人員和平臺的依賴,實(shí)現(xiàn)業(yè)務(wù)統(tǒng)一和大規(guī)模的自動(dòng)化操作。

2)面向終態(tài)

面向終態(tài)是指聲明式地描述基礎(chǔ)設(shè)施和應(yīng)用的期望配置,持續(xù)關(guān)注應(yīng)用的實(shí)際運(yùn)行狀態(tài),使系統(tǒng)自身反復(fù)地變更和調(diào)整直至趨近終態(tài)的一種思想。面向終態(tài)的原則強(qiáng)調(diào)應(yīng)該避免直接通過工單系統(tǒng)、工作流系統(tǒng)組裝一系列過程式的命令來變更應(yīng)用,而是通過設(shè)置終態(tài),讓系統(tǒng)自己決策如何執(zhí)行變更。

3)關(guān)注點(diǎn)分離

自動(dòng)化最終所能達(dá)到的效果不只取決于工具和系統(tǒng)的能力,更取決于為系統(tǒng)設(shè)置目標(biāo)的人,因此要確保找到正確的目標(biāo)設(shè)置人。在描述系統(tǒng)終態(tài)時(shí),要將應(yīng)用研發(fā)、應(yīng)用運(yùn)維、基礎(chǔ)設(shè)施運(yùn)維這幾種主要角色所關(guān)注的配置分離開來,各個(gè)角色只需要設(shè)置自己所關(guān)注和擅長的系統(tǒng)配置,以便確保設(shè)定的系統(tǒng)終態(tài)是合理的。

4)面向失敗設(shè)計(jì)

要想實(shí)現(xiàn)全部過程自動(dòng)化,一定要保證自動(dòng)化的過程是可控的,對系統(tǒng)的影響是可預(yù)期的。我們不能期望自動(dòng)化系統(tǒng)不犯錯(cuò)誤,但可以保證即使是在出現(xiàn)異常的情況下,錯(cuò)誤的影響范圍也是可控的、可接受的。因此,自動(dòng)化系統(tǒng)在執(zhí)行變更時(shí),同樣需要遵循人工變更的最佳實(shí)踐,保證變更是可灰度執(zhí)行的、執(zhí)行結(jié)果是可觀測的、變更是可快速回滾的、變更影響是可追溯的。

業(yè)務(wù)實(shí)例的故障自愈是一個(gè)典型的過程自動(dòng)化場景。業(yè)務(wù)遷移到云上后,云平臺雖然通過各種技術(shù)手段大幅降低了服務(wù)器出故障的概率,但是卻并不能消除業(yè)務(wù)本身的軟件故障。軟件故障既包括應(yīng)用軟件自身的缺陷導(dǎo)致的崩潰、資源不足導(dǎo)致的內(nèi)存溢出(OOM)和負(fù)載過高導(dǎo)致的夯死等異常問題,也包括內(nèi)核、守護(hù)進(jìn)程(daemon進(jìn)程)等系統(tǒng)軟件的問題,更包括混部的其他應(yīng)用或作業(yè)的干擾問題。隨著業(yè)務(wù)規(guī)模的增加,軟件出現(xiàn)故障的風(fēng)險(xiǎn)正變得越來越高。傳統(tǒng)的運(yùn)維故障處理方式需要運(yùn)維人員的介入,執(zhí)行諸如重啟或者騰挪之類的修復(fù)操作,但在大規(guī)模場景下,運(yùn)維人員往往疲于應(yīng)對各種故障,甚至需要連夜加班進(jìn)行操作,服務(wù)質(zhì)量很難保證,不管是客戶,還是開發(fā)、運(yùn)維人員,都無法滿意。

為了使故障能夠?qū)崿F(xiàn)自動(dòng)化修復(fù),云原生應(yīng)用要求開發(fā)人員通過標(biāo)準(zhǔn)的聲明式配置,描述應(yīng)用健康的探測方法和應(yīng)用的啟動(dòng)方法、應(yīng)用啟動(dòng)后需要掛載和注冊的服務(wù)發(fā)現(xiàn)以及配置管理數(shù)據(jù)庫(Configuration Management Data Base,CMDB)信息。通過這些標(biāo)準(zhǔn)的配置,云平臺可以反復(fù)探測應(yīng)用,并在故障發(fā)生時(shí)執(zhí)行自動(dòng)化修復(fù)操作。另外,為了防止故障探測本身可能存在的誤報(bào)問題,應(yīng)用的運(yùn)維人員還可以根據(jù)自身容量設(shè)置服務(wù)不可用實(shí)例的比例,讓云平臺能夠在進(jìn)行自動(dòng)化故障恢復(fù)的同時(shí)保證業(yè)務(wù)可用性。實(shí)例故障自愈的實(shí)現(xiàn),不僅把開發(fā)人員和運(yùn)維人員從煩瑣的運(yùn)維操作中解放了出來,而且可以及時(shí)處理各種故障,保證業(yè)務(wù)的連續(xù)性和服務(wù)的高可用性。

6、零信任原則

基于邊界模型的傳統(tǒng)安全架構(gòu)設(shè)計(jì),是在可信和不可信的資源之間架設(shè)一道墻,例如,公司內(nèi)網(wǎng)是可信的,而因特網(wǎng)則是不可信的。在這種安全架構(gòu)設(shè)計(jì)模式下,一旦入侵者滲透到邊界內(nèi),就能夠隨意訪問邊界內(nèi)的資源了。而云原生架構(gòu)的應(yīng)用、員工遠(yuǎn)程辦公模式的普及以及用手機(jī)等移動(dòng)設(shè)備處理工作的現(xiàn)狀,已經(jīng)完全打破了傳統(tǒng)安全架構(gòu)下的物理邊界。員工在家辦公也可以實(shí)現(xiàn)與合作方共享數(shù)據(jù),因?yàn)閼?yīng)用和數(shù)據(jù)被托管到了云上。

如今,邊界不再是由組織的物理位置來定義,而是已經(jīng)擴(kuò)展到了需要訪問組織資源和服務(wù)的所有地方,傳統(tǒng)的防火墻和VPN已經(jīng)無法可靠且靈活地應(yīng)對這種新邊界。因此,我們需要一種全新的安全架構(gòu),來靈活適應(yīng)云原生和移動(dòng)時(shí)代環(huán)境的特性,不論員工在哪里辦公,設(shè)備在哪里接入,應(yīng)用部署在哪里,數(shù)據(jù)的安全性都能夠得到有效保護(hù)。如果要實(shí)現(xiàn)這種新的安全架構(gòu),就要依托零信任模型。

傳統(tǒng)安全架構(gòu)認(rèn)為防火墻內(nèi)的一切都是安全的,而零信任模型假設(shè)防火墻邊界已經(jīng)被攻破,且每個(gè)請求都來自于不可信網(wǎng)絡(luò),因此每個(gè)請求都需要經(jīng)過驗(yàn)證。簡單來說,“永不信任,永遠(yuǎn)驗(yàn)證”。在零信任模型下,每個(gè)請求都要經(jīng)過強(qiáng)認(rèn)證,并基于安全策略得到驗(yàn)證授權(quán)。與請求相關(guān)的用戶身份、設(shè)備身份、應(yīng)用身份等,都會作為核心信息來判斷請求是否安全。

如果我們圍繞邊界來討論安全架構(gòu),那么傳統(tǒng)安全架構(gòu)的邊界是物理網(wǎng)絡(luò),而零信任安全架構(gòu)的邊界則是身份,這個(gè)身份包括人的身份、設(shè)備的身份、應(yīng)用的身份等。要想實(shí)現(xiàn)零信任安全架構(gòu),需要遵循如下三個(gè)基本原則。

1)顯式驗(yàn)證

對每個(gè)訪問請求都進(jìn)行認(rèn)證和授權(quán)。認(rèn)證和授權(quán)需要基于用戶身份、位置、設(shè)備信息、服務(wù)和工作負(fù)載信息以及數(shù)據(jù)分級和異常檢測等信息來進(jìn)行。例如,對于企業(yè)內(nèi)部應(yīng)用之間的通信,不能簡單地判定來源IP是內(nèi)部IP就直接授權(quán)訪問,而是應(yīng)該判斷來源應(yīng)用的身份和設(shè)備等信息,再結(jié)合當(dāng)前的策略授權(quán)。

2)最少權(quán)限

對于每個(gè)請求,只授予其在當(dāng)下必需的權(quán)限,且權(quán)限策略應(yīng)該能夠基于當(dāng)前請求上下文自適應(yīng)。例如,HR部門的員工應(yīng)該擁有訪問HR相關(guān)應(yīng)用的權(quán)限,但不應(yīng)該擁有訪問財(cái)務(wù)部門應(yīng)用的權(quán)限。

3)假設(shè)被攻破

假設(shè)物理邊界被攻破,則需要嚴(yán)格控制安全爆炸半徑,將一個(gè)整體的網(wǎng)絡(luò)切割成對用戶、設(shè)備、應(yīng)用感知的多個(gè)部分。對所有的會話加密,使用數(shù)據(jù)分析技術(shù)保證對安全狀態(tài)的可見性。

從傳統(tǒng)安全架構(gòu)向零信任架構(gòu)演進(jìn),會對軟件架構(gòu)產(chǎn)生深刻的影響,具體體現(xiàn)在如下三個(gè)方面。

第一,不能基于IP配置安全策略。在云原生架構(gòu)下,不能假設(shè)IP與服務(wù)或應(yīng)用是綁定的,這是由于自動(dòng)彈性等技術(shù)的應(yīng)用使得IP隨時(shí)可能發(fā)生變化,因此不能以IP代表應(yīng)用的身份并在此基礎(chǔ)上建立安全策略。

第二,身份應(yīng)該成為基礎(chǔ)設(shè)施。授權(quán)各服務(wù)之間的通信以及人訪問服務(wù)的前提是已經(jīng)明確知道訪問者的身份。在企業(yè)中,人的身份管理通常是安全基礎(chǔ)設(shè)施的一部分,但應(yīng)用的身份也需要管理。

第三,標(biāo)準(zhǔn)的發(fā)布流水線。在企業(yè)中,研發(fā)的工作通常是分布式的,包括代碼的版本管理、構(gòu)建、測試以及上線的過程,都是比較獨(dú)立的。這種分散的模式將會導(dǎo)致在實(shí)際生產(chǎn)環(huán)境中運(yùn)行的服務(wù)的安全性得不到有效保證。如果可以標(biāo)準(zhǔn)化代碼的版本管理、構(gòu)建以及上線的流程,那么應(yīng)用發(fā)布的安全性就能夠得到集中增強(qiáng)。

總體來說,整個(gè)零信任模型的建設(shè)包括身份、設(shè)備、應(yīng)用、基礎(chǔ)設(shè)施、網(wǎng)絡(luò)、數(shù)據(jù)等幾個(gè)部分。零信任的實(shí)現(xiàn)是一個(gè)循序漸進(jìn)的過程,例如,當(dāng)組織內(nèi)部傳輸?shù)乃辛髁慷紱]有加密的時(shí)候,第一步應(yīng)該先保證訪問者訪問應(yīng)用的流量是加密的,然后再逐步實(shí)現(xiàn)所有流量的加密。如果采用云原生架構(gòu),就可以直接使用云平臺提供的安全基礎(chǔ)設(shè)施和服務(wù),以便幫助企業(yè)快速實(shí)現(xiàn)零信任架構(gòu)。

7、架構(gòu)持續(xù)演進(jìn)原則

如今,技術(shù)與業(yè)務(wù)的發(fā)展速度都非??欤诠こ虒?shí)踐中很少有從一開始就能夠被明確定義并適用于整個(gè)軟件生命周期的架構(gòu)模式,而是需要在一定范圍內(nèi)不斷重構(gòu),以適應(yīng)變化的技術(shù)和業(yè)務(wù)需求。同理,云原生架構(gòu)本身也應(yīng)該且必須具備持續(xù)演進(jìn)的能力,而不是一個(gè)封閉式的、被設(shè)計(jì)后一成不變的架構(gòu)。因此在設(shè)計(jì)時(shí)除了要考慮增量迭代、合理化目標(biāo)選取等因素之外,還需要考慮組織(例如架構(gòu)控制委員會)層面的架構(gòu)治理和風(fēng)險(xiǎn)控制規(guī)范以及業(yè)務(wù)自身的特點(diǎn),特別是在業(yè)務(wù)高速迭代的情況下,更應(yīng)該重點(diǎn)考慮如何保證架構(gòu)演進(jìn)與業(yè)務(wù)發(fā)展之間的平衡。

1)演進(jìn)式架構(gòu)的特點(diǎn)和價(jià)值

演進(jìn)式架構(gòu)是指在軟件開發(fā)的初始階段,就通過具有可擴(kuò)展性和松耦合的設(shè)計(jì),讓后續(xù)可能發(fā)生的變更更加容易、升級性重構(gòu)的成本更低,并且能夠發(fā)生在開發(fā)實(shí)踐、發(fā)布實(shí)踐和整體敏捷度等軟件生命周期中的任何階段。

演進(jìn)式架構(gòu)之所以在工業(yè)實(shí)踐中具有重要意義,其根本原因在于,在現(xiàn)代軟件工程領(lǐng)域達(dá)成的共識中,變更都是很難預(yù)測的,其改造的成本也極其高昂。演進(jìn)式架構(gòu)并不能避免重構(gòu),但是它強(qiáng)調(diào)了架構(gòu)的可演進(jìn)性,即當(dāng)整個(gè)架構(gòu)因?yàn)榧夹g(shù)、組織或者外部環(huán)境的變化需要向前演進(jìn)時(shí),項(xiàng)目整體依然能夠遵循強(qiáng)邊界上下文的原則,確保領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中描述的邏輯劃分變成物理上的隔離。演進(jìn)式架構(gòu)通過標(biāo)準(zhǔn)化且具有高可擴(kuò)展性的基礎(chǔ)設(shè)施體系,大量采納標(biāo)準(zhǔn)化應(yīng)用模型與模塊化運(yùn)維能力等先進(jìn)的云原生應(yīng)用架構(gòu)實(shí)踐,實(shí)現(xiàn)了整個(gè)系統(tǒng)架構(gòu)在物理上的模塊化、可復(fù)用性與職責(zé)分離。在演進(jìn)式架構(gòu)中,系統(tǒng)的每個(gè)服務(wù)在結(jié)構(gòu)層面與其他服務(wù)都是解耦的,替換服務(wù)就像替換樂高積木一樣方便。

2)演進(jìn)式架構(gòu)的應(yīng)用

在現(xiàn)代軟件工程實(shí)踐中,演進(jìn)式架構(gòu)在系統(tǒng)的不同層面有著不同的實(shí)踐與體現(xiàn)。

在面向業(yè)務(wù)研發(fā)的應(yīng)用架構(gòu)中,演進(jìn)式架構(gòu)通常與微服務(wù)設(shè)計(jì)密不可分。例如,在阿里巴巴的互聯(lián)網(wǎng)電商應(yīng)用中(例如大家所熟悉的淘寶和天貓等),整個(gè)系統(tǒng)架構(gòu)實(shí)際上被精細(xì)地設(shè)計(jì)成數(shù)千個(gè)邊界劃分明確的組件,其目的就是為希望做出非破壞性變更的開發(fā)人員提供更大的便利,避免因?yàn)椴贿m當(dāng)?shù)鸟詈蠈⒆兏鼘?dǎo)向難以預(yù)料的方向,從而阻礙架構(gòu)的演進(jìn)??梢园l(fā)現(xiàn),演進(jìn)式架構(gòu)的軟件都支持一定程度的模塊化,這種模塊化通常體現(xiàn)為經(jīng)典的分層架構(gòu)及微服務(wù)的最佳實(shí)踐。

而在平臺研發(fā)層面,演進(jìn)式架構(gòu)更多地體現(xiàn)為基于“能力”的架構(gòu)(Capability Oriented Architecture,COA)。在Kubernetes等云原生技術(shù)逐漸普及之后,基于標(biāo)準(zhǔn)化的云原生基礎(chǔ)設(shè)施正迅速成為平臺架構(gòu)的能力提供方,而以此為基礎(chǔ)的開放應(yīng)用模型(Open ApplieationModel,OAM)理念,正是一種從應(yīng)用架構(gòu)視角出發(fā),將標(biāo)準(zhǔn)化基礎(chǔ)設(shè)施按照能力進(jìn)行模塊化的COA實(shí)踐。

3)云原生下的架構(gòu)演進(jìn)

當(dāng)前,演進(jìn)式架構(gòu)還處于快速成長與普及階段。不過,整個(gè)軟件工程領(lǐng)域已經(jīng)達(dá)成共識,即軟件世界是不斷變化的,它是動(dòng)態(tài)而非靜態(tài)的存在。架構(gòu)也不是一個(gè)簡單的等式,它是持續(xù)過程的一種快照。所以無論是在業(yè)務(wù)應(yīng)用還是在平臺研發(fā)層面,演進(jìn)式架構(gòu)都是一個(gè)必然的發(fā)展趨勢。業(yè)界大量架構(gòu)更新的工程實(shí)踐都詮釋了一個(gè)問題,即由于忽略實(shí)現(xiàn)架構(gòu),且保持應(yīng)用常新所要付出的精力是非常巨大的。但好的架構(gòu)規(guī)劃可以幫助應(yīng)用降低新技術(shù)的引入成本,這要求應(yīng)用與平臺在架構(gòu)層面滿足:架構(gòu)標(biāo)準(zhǔn)化、職責(zé)分離與模塊化。而在云原生時(shí)代,開發(fā)應(yīng)用模型(OAM)正在迅速成為演進(jìn)式架構(gòu)推進(jìn)的重要助力。

結(jié)語

我們可以看到云原生架構(gòu)的構(gòu)建和演進(jìn)都是以云計(jì)算的核心特性(例如,彈性、自動(dòng)化、韌性)為基礎(chǔ)并結(jié)合業(yè)務(wù)目標(biāo)以及特征進(jìn)行的,從而幫助企業(yè)和技術(shù)人員充分釋放云計(jì)算的技術(shù)紅利。隨著云原生的不斷探索,各類技術(shù)不斷擴(kuò)展,各類場景不斷豐富,云原生架構(gòu)也將不斷演進(jìn)。但在這些變化過程中。典型的架構(gòu)設(shè)計(jì)原則始終都有著重要意義,指導(dǎo)我們進(jìn)行架構(gòu)設(shè)計(jì)以及技術(shù)落地。

THEEND

最新評論(評論僅代表用戶觀點(diǎn))

更多
暫無評論