速度
云原生架構(gòu)使用敏捷開發(fā)和DevOps夜牡，不但可以讓企業(yè)快速的開發(fā)產(chǎn)品，自動化部署產(chǎn)品堰怨，同時還能持續(xù)的更新產(chǎn)品芥玉，讓產(chǎn)品跟得上需求，甚至是引導需求备图，讓企業(yè)立于不敗之地灿巧。在傳統(tǒng)企業(yè)中，為應用提供環(huán)境和部署新版本花費的時間通常以天揽涮、周或月來計算抠藕。在使用了docker和k8s之后，部署時間可以縮短到幾分鐘甚至幾秒鐘蒋困。
安全與魯棒性
云原生架構(gòu)依托于容器編排工具（K8S）與微服務的組合盾似，應用就擁有了自動恢復能力、容錯能力雪标、故障隔離能力零院，讓應用時刻處于可用的狀態(tài)。
自動恢復
憑借可視化村刨、故障隔離和容錯能力告抄，我們擁有確定故障所需的工具，從故障中恢復嵌牺，并在進行錯誤檢 測和故障恢復的過程中為客戶提供合理的服務水平打洼。一些故障很容易識別:它們在每次發(fā)生時呈現(xiàn)出 相同的易于檢測的模式蜓洪。以服務健康檢查為例焦人，結(jié)果只有兩個:健康或不健康，up或down昔园。很多時 候枯饿，每次遇到這樣的故障時酝锅，我們都會采取相同的行動。在健康檢查失敗的情況下奢方，我們通常只需重 新啟動或重新部署相關(guān)服務搔扁。云原生應用程序架構(gòu)不要當應用在這些情況下無需手動干預。相反蟋字，他 們會自動檢測和恢復稿蹲。換句話說，他們給電腦裝上了尋呼機而不是人
容錯
僅僅將系統(tǒng)拆解為可以獨立部署的微服務還是不夠的;還需要防止出現(xiàn)錯誤的組件將錯誤傳遞它所依賴的組件上而造成級聯(lián)故障鹊奖。Mike Nygard 在他的《Release It! - Pragmatic Programmers》一書中描述了一些容錯模型苛聘，最受歡迎的是斷路器。軟件斷路器的工作原理就類似于電子斷路器(保險絲):斷開它所保護的組件與故障系統(tǒng)之間的回路以防止級聯(lián)故障。它還可以提供 一個優(yōu)雅的回退行為设哗，比如回路斷開的時候提供一組默認的產(chǎn)品推薦唱捣。我們將在“容錯”一節(jié)詳細討論該模型。
故障隔離
為了限制與故障帶來的風險网梢，我們需要限制可能受到故障影響的組件或功能的范圍震缭。如果每次亞馬遜 的推薦引擎掛掉后人們就不能再在亞馬遜上買產(chǎn)品，那將是災難性的战虏。單體架構(gòu)通常就是這種類型的 故障模式拣宰。云原生應用程序架構(gòu)通常使用微服務。通過將系統(tǒng)拆解為微服務烦感，我們可以將任何一個微 服務的故障范圍限制在這個微服務上巡社，但還需要結(jié)合容錯才能實現(xiàn)這一點。
可視化：
提供必要的工具手趣，以便可以在發(fā)生故障時看到它晌该。 我們需要觀測一切的能力， 建立一個“哪些是正陈淘”的概況气笙，檢測與標準情況的偏差(包括絕對值和變化率)，并確定哪些組件導 致了這些偏差怯晕。功能豐富的指標、監(jiān)控缸棵、警報舟茶、數(shù)據(jù)可視化框架和工具是所有云原生應用程序體系結(jié)構(gòu)的核心。
彈性擴展
隨著需求的增加堵第，我們必須擴大服務能力吧凉。過去我們通過垂直擴展來處理更多的需求:購買了更強悍 的服務器。我們最終實現(xiàn)了自己的目標踏志，但是步伐太慢阀捅，并且產(chǎn)生了更多的花費。這導致了基于高峰 使用預測的容量規(guī)劃针余。我們會問”這項服務需要多大的計算能力?”然后購買足夠的硬件來滿足這個要求饲鄙。很多時候我們依然會判斷錯誤，會在如黑色星期五這類事件中打破我們的可用容量規(guī)劃圆雁。但是忍级， 更多的時候，我們將會遇到數(shù)以百計的服務器伪朽，它們的CPU都是空閑的轴咱，這會讓資源使用率指標很難 看。
創(chuàng)新型的公司通過以下兩個開創(chuàng)性的舉措來解決這個問題:
- 它們不再繼續(xù)購買更大型的服務器，取而代之的是用大量的更便宜機器來水平擴展應用實例朴肺。這些機器更容易獲得窖剑，并且能夠快速部署。
- 通過將大型服務器虛擬化成幾個較小的服務器戈稿，并向其部署多個隔離的工作負載來改善現(xiàn)有大型服務器的資源利用率西土。
隨著公有云基礎(chǔ)設施的出現(xiàn)，這兩個舉措融合了起來器瘪。虛擬化工作被委托給云提 供商翠储，消費者只需要關(guān)注在大量的云服務器實例很想擴展它們的應用程序?qū)嵗Ｗ罱鹛郏鳛閼贸绦?部署的單元援所，發(fā)生了另一個轉(zhuǎn)變，從虛擬機轉(zhuǎn)移到了容器欣除。
由于公司不再需要大量啟動資金來部署軟件住拭，所以向云的轉(zhuǎn)變打開了更多創(chuàng)新之門。正在進行的維護 還需要較少的資本投入历帚，并且通過API進行配置不僅可以提高初始部署的速度滔岳，還可以最大限度地提 高我們應對需求變化的速度。
不幸的是挽牢，所有這些好處都帶有成本谱煤。相較于垂直擴展的應用，支持水平擴展的應用程序的架構(gòu)必須 不同禽拔。云的彈性要求應用程序的狀態(tài)短暫性刘离。我們不僅可以快速創(chuàng)建新的應用實例;我們也必須能夠 快速、安全地處置它們睹栖。這種需求是狀態(tài)管理的問題:一次性與持久性如何互相影響? 在大多數(shù)垂直 架構(gòu)中采用的諸如聚類會話和共享文件系統(tǒng)的傳統(tǒng)方法并不能很好地支持水平擴展硫惕。
云原生應用程序架構(gòu)的另一個標志是將狀態(tài)外部化到內(nèi)存數(shù)據(jù)網(wǎng)格，緩存和持久對象存儲野来，同時保持 應用程序?qū)嵗旧砘旧鲜菬o狀態(tài)的恼除。無狀態(tài)應用程序可以快速創(chuàng)建和銷毀，以及附加到外部狀態(tài)管 理器和脫離外部狀態(tài)管理器曼氛，增強我們響應需求變化的能力豁辉。當然這也需要外部狀態(tài)管理器自己來擴 展。大多數(shù)云基礎(chǔ)設施提供商已經(jīng)認識到這一必要性搪锣，并提供了這類服務的健康管理秋忙。
屏蔽底層差異
因為使用了容器化技術(shù)，應用運行于容器之中构舟，應用就不需要考慮底層硬件的差異灰追，只要是能運行容器鏡像的硬件都可以運行程序堵幽，大大簡化了開發(fā)工作量。同時對運維人員也非常友好弹澎，不需要再為環(huán)境問題而苦惱朴下。
云原生架構(gòu) = 微服務 + 容器化 + DevOps + 持續(xù)交付
