云原生（Cloud Native） = 微服務(wù) DevOps 持續(xù)交付容器化？

邸彥強 2022-04-30 發(fā)布于河北

展開全文

云原生技術(shù)生態(tài)現(xiàn)狀

云原生基金會 —— CNCF

云原生技術(shù)社區(qū)

云原生技術(shù)產(chǎn)業(yè)

我們正處于時代的關(guān)鍵節(jié)點

2019 年，云原生技術(shù)普及元年

云原生應(yīng)用的邏輯依賴關(guān)系

技術(shù)的趨勢和影響

軟件生命周期維度看云原生

微軟的 Azure 計算服務(wù)架構(gòu)

Completing the picture

參考資料

Kotlin 開發(fā)者社區(qū)

容器化包裝：軟件應(yīng)用的進程應(yīng)該包裝在容器中獨立運行。
動態(tài)管理：通過集中式的編排調(diào)度系統(tǒng)來動態(tài)的管理和調(diào)度。
微服務(wù)化：明確服務(wù)間的依賴，互相解耦。

https:///articles/cloud-native-seeing-through-the-hype

什么是云原生？

云原生準(zhǔn)確來說是一種文化，更是一種潮流，它是云計算的一個必然導(dǎo)向。意義在于讓云成為云化戰(zhàn)略成功的基石，而不是障礙。

FaaS Landscape

云原生之前

云原生

Service Mesh 的思路，體現(xiàn)在將 SDK 客戶端的功能剝離出來，放到 Sidecar 中。通過這種方式，實現(xiàn)應(yīng)用的輕量化。此時絕大部分的功能都在剝離，應(yīng)用中只留下一個輕量級的客戶端。這個輕量級客戶端中還保留有少數(shù)功能和信息，比如目標(biāo)服務(wù)的標(biāo)識（指出要調(diào)用的目標(biāo)），序列化的實現(xiàn)。

云原生簡介

Cloud Native 翻譯為云原生，是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續(xù)交付（Continuous Delivery）、微服務(wù)（MicroServices）、敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據(jù)商業(yè)能力對公司進行重組。Cloud Native既包含技術(shù)（微服務(wù)，敏捷基礎(chǔ)設(shè)施），也包含管理（DevOps，持續(xù)交付，康威定律，重組等）。Cloud Native也可以說是一系列Cloud技術(shù)、企業(yè)管理方法的集合。

Cloud Native是更好的工具、自我修復(fù)系統(tǒng)、和自動化系統(tǒng)的集合，可以讓應(yīng)用和基礎(chǔ)設(shè)施的部署和故障修復(fù)更加快速和敏捷，極大的降低企業(yè)在云計算方面的部署成本。

目前業(yè)界公認(rèn)的云原生主要包括以下幾個層面的內(nèi)容。

容器，服務(wù)網(wǎng)格，微服務(wù)，不可變的基礎(chǔ)設(shè)施，公開的API都接近云原生相關(guān)概念。

云原生技術(shù)可以讓系統(tǒng)松耦合，支持彈性伸縮、可管理的、清晰的。通過整合健壯且有效的自動化，工程師可以用很少的勞動來完成頻繁的、預(yù)期中的高危代碼修改。

微服務(wù)

微服務(wù)解決的是我們軟件開發(fā)中一直追求的低耦合+高內(nèi)聚，記得有一次我們系統(tǒng)的接口出了問題，結(jié)果影響了用戶的前臺操作，于是黎叔拍案而起，靈魂發(fā)問：“為啥這兩個會互相影響？！”

微服務(wù)可以解決這個問題，微服務(wù)的本質(zhì)是把一塊大餅分成若干塊低耦合的小餅，比如一塊小餅專門負(fù)責(zé)接收外部的數(shù)據(jù)，一塊小餅專門負(fù)責(zé)響應(yīng)前臺的操作，小餅可以進一步拆分，比如負(fù)責(zé)接收外部數(shù)據(jù)的小餅可以繼續(xù)分成多塊負(fù)責(zé)接收不同類型數(shù)據(jù)的小餅，這樣每個小餅出問題了，其它小餅還能正常對外提供服務(wù)。

隨著微服務(wù)化架構(gòu)的優(yōu)勢展現(xiàn)和快速發(fā)展，2013年，MartinFlower對微服務(wù)概念進行了比較系統(tǒng)的理論闡述，總結(jié)了相關(guān)的技術(shù)特征。首先，微服務(wù)是一種架構(gòu)風(fēng)格，也是一種服務(wù)；其次，微服務(wù)的顆粒比較小，一個大型復(fù)雜軟件應(yīng)用由多個微服務(wù)組成，比如Netflix目前由500多個的微服務(wù)組成；最后，它采用UNIX設(shè)計的哲學(xué)，每種服務(wù)只做一件事，是一種松耦合的能夠被獨立開發(fā)和部署的無狀態(tài)化服務(wù)（獨立擴展、升級和可替換）。微服務(wù)架構(gòu)如圖1-8所示。

圖：微服務(wù)架構(gòu)示例

由微服務(wù)的定義分析可知，一個微服務(wù)基本是一個能獨立發(fā)布的應(yīng)用服務(wù)，因此可以作為獨立組件升級、灰度或復(fù)用等，對整個大應(yīng)用的影響也較小，每個服務(wù)可以由專門的組織來單獨完成，依賴方只要定好輸入和輸出口即可完全開發(fā)，甚至整個團隊的組織架構(gòu)也會更精簡，因此溝通成本低、效率高。根據(jù)業(yè)務(wù)的需求，不同的服務(wù)可以根據(jù)業(yè)務(wù)特性進行不同的技術(shù)選型，是計算密集型還是I/O密集型應(yīng)用都可以依賴不同的語言編程模型，各團隊可以根據(jù)本身的特色獨自運作。服務(wù)在壓力較大時，也可以有更多容錯或限流服務(wù)。

微服務(wù)架構(gòu)確實有很多吸引人的地方，然而它的引入也是有成本的，它并不是銀彈，使用它會引入更多技術(shù)挑戰(zhàn)，比如性能延遲、分布式事務(wù)、集成測試、故障診斷等方面，企業(yè)需要根據(jù)業(yè)務(wù)的不同的階段進行合理的引入，不能完全為了微服務(wù)而“微服務(wù)”

DevOps

DevOps的意思就是開發(fā)和運維不再是分開的兩個團隊，而是你中有我，我中有你的一個團隊。我們現(xiàn)在開發(fā)和運維已經(jīng)是一個團隊了，但是運維方面的知識和經(jīng)驗還需要持續(xù)提高。

DevOps如果從字面上來理解只是Dev（開發(fā)人員）+Ops（運維人員），實際上，它是一組過程、方法與系統(tǒng)的統(tǒng)稱，其概念從2009年首次提出發(fā)展到現(xiàn)在，內(nèi)容也非常豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不同方面。首先，組織架構(gòu)、企業(yè)文化與理念等，需要自上而下設(shè)計，用于促進開發(fā)部門、運維部門和質(zhì)量保障部門之間的溝通、協(xié)作與整合，簡單而言組織形式類似于系統(tǒng)分層設(shè)計。其次，自動化是指所有的操作都不需要人工參與，全部依賴系統(tǒng)自動完成，比如上述的持續(xù)交付過程必須自動化才有可能完成快速迭代。再次，DevOps的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識到，為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)部門和運維部門必須緊密合作?？傊?，DevOps強調(diào)的是高效組織團隊之間如何通過自動化的工具協(xié)作和溝通來完成軟件的生命周期管理，從而更快、更頻繁地交付更穩(wěn)定的軟件。如圖所示，

圖 DevOps強調(diào)組織的溝通與協(xié)作

持續(xù)交付

持續(xù)交付的意思就是在不影響用戶使用服務(wù)的前提下頻繁把新功能發(fā)布給用戶使用，要做到這點非常非常難。我們現(xiàn)在兩周一個版本，每次上線之后都會給不同的用戶造成不同程度的影響。

它更多是代表一種軟件交付的能力，過程示例請參考圖：

圖持續(xù)交付流程

容器化

容器化的好處在于運維的時候不需要再關(guān)心每個服務(wù)所使用的技術(shù)棧了，每個服務(wù)都被無差別地封裝在容器里，可以被無差別地管理和維護，現(xiàn)在比較流行的工具是docker和k8s。

基于虛擬機技術(shù)，陸續(xù)出現(xiàn)了 IaaS/PaaS/FaaS 等形態(tài)，以及他們的開源版本。

2013 年 docker 出現(xiàn)，容器技術(shù)成熟，然后圍繞容器編排一場大戰(zhàn)，最后在 2017 年底，kubernetes 勝出。2015 年 CNCF 成立，并在近年形成了 cloud native 生態(tài)。

云原生的發(fā)展歷程

云原生（Cloud Native）最初來描述云上應(yīng)用的典型架構(gòu)與特性，隨著容器、kubernetes、Serverless、FaaS技術(shù)的演進，CNCF（Cloud Native Computing Foundation ，云原生計算基金會）把云原生的概念更廣泛地定義為“讓應(yīng)用更有彈性、容錯性、觀測性的基礎(chǔ)技術(shù)，讓應(yīng)用更容易部署、管理的基礎(chǔ)軟件、讓應(yīng)用更容易編寫、編排的運行框架等”，希望能夠讓開發(fā)者最好的利用云的資源、產(chǎn)品和交付能力。

下邊大致梳理一下云原生的發(fā)展過程。

2004 年 ~ 2007 年，Google 已在內(nèi)部大規(guī)模地使用像 Cgroups 這樣的容器技術(shù)；
2008 年，Google 將 Cgroups 合并進入了 Linux 內(nèi)核主干。
2013 年，Docker 項目正式發(fā)布。
2014 年，Kubernetes 項目也正式發(fā)布。
2015 年，CNCF 成立。
2017 年，CNCF 達到 170 個成員和 14 個基金項目。
2018 年，CNCF 成立三周年有了 195 個成員，19 個基金會項目和 11 個孵化項目，如此之快的發(fā)展速度在整個云計算領(lǐng)域都是非常罕見的。

2014 年 Kubernetes 項目發(fā)布的原因也非常容易理解，因為有了容器和 Docker 之后，就需要有一種方式去幫助大家方便、快速、優(yōu)雅地管理這些容器，這就是 Kubernetes 項目的初衷。在 Google 和 Redhat 發(fā)布了 Kubernetes 之后，這個項目的發(fā)展速度非常之快。

2015 年由 Google、Redhat 以及微軟等大型云計算廠商以及一些開源公司共同牽頭成立了 CNCF 云原生基金會。CNCF 成立之初，就有 22 個創(chuàng)始會員，而且 Kubernetes 也成為了 CNCF 托管的第一個開源項目。在這之后，CNCF 的發(fā)展速度非常迅猛。

云原生技術(shù)生態(tài)現(xiàn)狀

因此，如今我們所討論的云原生技術(shù)生態(tài)是一個龐大的技術(shù)集合。CNCF 有一張云原生全景圖（https://github.com/cncf/landscape），在這個全景圖里已經(jīng)有 200 多個項目和產(chǎn)品了，這些項目和產(chǎn)品也都是和 CNCF 的觀點所契合的。所以如果以這張全景圖作為背景，加以思考就會發(fā)現(xiàn)，我們今天所討論的云原生其實主要談?wù)摿艘韵聨c：

云原生基金會 —— CNCF

CNCF 是目前云計算領(lǐng)域最成功的開源基金會之一，是 Kubernetes、 etcd、Envoy 等知名開源項目的托管基金會。

云原生技術(shù)社區(qū)

云原生技術(shù)社區(qū)，比如像 CNCF 目前正式托管的 20 多個項目共同構(gòu)成了現(xiàn)代云計算生態(tài)的基石，其中像 Kubernetes 這樣的項目已經(jīng)成為了世界第四活躍的開源項目；目前從 CNCF 畢業(yè)的項目以及有 6 個，分別是 Kubernetes 、Prometheus、Envoy、CoreDNS、containerd、Fluentd 。

云原生技術(shù)產(chǎn)業(yè)

除了前面兩點之外，現(xiàn)在全球各大公有云廠商都已經(jīng)支持了 Kubernetes。此外，還有 100 多家技術(shù)創(chuàng)業(yè)公司也在持續(xù)地進行投入?，F(xiàn)在阿里巴巴也在談全面上云，而且上云就要上云原生，這也是各大技術(shù)公司擁抱云原生的一個例子。

我們正處于時代的關(guān)鍵節(jié)點

2019 年正是云原生時代的關(guān)鍵節(jié)點，為什么這么說？我們這里就為大家簡單梳理一下。

從 2013 年 Docker 項目發(fā)布開始說起，Docker 項目的發(fā)布使得全操作系統(tǒng)語義的沙盒技術(shù)唾手可得，使得用戶能夠更好地、更完整地打包自己的應(yīng)用，使得開發(fā)者可以輕而易舉的獲得了一個應(yīng)用的最小可運行單位，而不需要依賴任何 PaaS 能力。這對經(jīng)典 PaaS 產(chǎn)業(yè)其實是一個“降維打擊”。

2014 年的時候，Kubernetes 項目發(fā)布，其意義在于 Google 將內(nèi)部的 Borg/Omega 系統(tǒng)思想借助開源社區(qū)實現(xiàn)了“重生”，并且提出了“容器設(shè)計模式”的思想。而 Google 之所以選擇間接開源 Kubernetes 而不是直接開源 Borg 項目，其實背后的原因也比較容易理解：Borg/Omega 這樣的系統(tǒng)太復(fù)雜了，是沒辦法提供給 Google 之外的人使用，但是 Borg/Omega 這樣的設(shè)計思想?yún)s可以借助 Kubernetes 讓大家接觸到，這也是開源 Kubernetes 的重要背景。

這樣到了 2015 年到 2016 年，就到了容器編排“三國爭霸”的時代，當(dāng)時 Docker、Swarm、Mesos、Kubernetes 都在容器編排領(lǐng)域展開角逐，他們競爭的原因其實也比較容易理解，那就是 Docker 或者容器本身的價值雖然大，但是如果想要讓其產(chǎn)生商業(yè)價值或者說對云的價值，那么就一定需要在編排上面占據(jù)一個有利的位置。

其中，Swarm 更偏向于生態(tài)，而 Mesos 技術(shù)更強一些。相比之下， Kubernetes 則兼具了兩者優(yōu)勢，最終在 2017 年“三國爭霸”的局面中得以勝出，成為了當(dāng)時直到現(xiàn)在的容器編排標(biāo)準(zhǔn)。這一過程的代表性事件就是 Docker 公司宣布在核心產(chǎn)品中內(nèi)置了 Kubernetes 服務(wù)，并且 Swarm 項目逐漸停止維護。

到了 2018 年的時候，云原生技術(shù)理念開始逐漸萌芽，這是因為此時 Kubernetes 以及容器都成為了云廠商的既定標(biāo)準(zhǔn)，以“云”為核心的軟件研發(fā)思想逐步形成。

而到了 2019 年，情況似乎又將發(fā)生一些變化。

2019 年，云原生技術(shù)普及元年

為什么說 2019 年很可能是一個關(guān)鍵節(jié)點呢？我們認(rèn)為 2019 年是云原生技術(shù)的普及元年。

首先大家可以看到，在 2019 年，阿里巴巴宣布要全面上云，而且“上云就要上云原生”。我們還可以看到，以“云”為核心的軟件研發(fā)思想，正逐步成為所有開發(fā)者的默認(rèn)選項。像 Kubernetes 等云原生技術(shù)正在成為技術(shù)人員的必修課，大量的工作崗位正在涌現(xiàn)出來。

這種背景下，“會 Kubernetes” 已經(jīng)遠(yuǎn)遠(yuǎn)不夠了，“懂 Kubernetes”、“會云原生架構(gòu)” 的重要性正日益凸顯出來。從 2019 年開始，云原生技術(shù)將會大規(guī)模普及，這也是為什么大家都要在這個時間點上學(xué)習(xí)和投資云原生技術(shù)的重要原因。

云原生代表技術(shù)

“12要素”

“12要素”英文全稱是The Twelve-Factor App，最初由Heroku的工程師整理起步，是集體貢獻總結(jié)的智慧，如圖所示。

圖：12要素

根據(jù)基于云的軟件開發(fā)模式，12要素比較貼切地描述了軟件應(yīng)用的原型，并詮釋了使用原生云應(yīng)用架構(gòu)的原因。比如，一個優(yōu)雅的互聯(lián)網(wǎng)應(yīng)用在設(shè)計過程中，需要遵循的一些基本原則和云原生有異曲同工之處。通過強化詳細(xì)配置和規(guī)范，類似Rails的基于“約定優(yōu)于配置”（convention over configuration）的原則，特別在大規(guī)模的軟件生產(chǎn)實踐中，這些約定非常重要，從無狀態(tài)共享到水平擴展的過程，從松耦合架構(gòu)關(guān)系到部署環(huán)境?；?2要素的上下文關(guān)聯(lián)，軟件生產(chǎn)就變成了一個個單一的部署單元；多個聯(lián)合部署的單元組成一個應(yīng)用，多個應(yīng)用之間的關(guān)系就可以組成一個復(fù)雜的分布式系統(tǒng)應(yīng)用。

下面簡要介紹圖1-9中的這些原則。相信很多開發(fā)者在實際開發(fā)工作中已經(jīng)很好地應(yīng)用了其中的一些原則，只是沒有意識到概念本身。對這些原則比較陌生的開發(fā)者，如果想了解更多的操作過程，請參閱《云原生時代下的12要素（12-Factor）應(yīng)用與實踐》一文。

基準(zhǔn)代碼

每一個部署的應(yīng)用都在版本控制代碼庫中被追蹤。在多個部署環(huán)境中，會有多種部署實例，單個應(yīng)用只有一份代碼庫，多份部署相當(dāng)于運行了該應(yīng)用的多個實例，比如開發(fā)環(huán)境一個實例，測試環(huán)境、生產(chǎn)環(huán)境都有一個實例。

實際上，在云計算架構(gòu)中，所有的基礎(chǔ)設(shè)施都是代碼配置，即Infrastructure as Code（IaC），整個應(yīng)用通過配置文件就可以編排出來，而不再需要手工的干預(yù)，做到基礎(chǔ)服務(wù)也是可以追蹤的。

依賴

應(yīng)用程序不會隱式依賴系統(tǒng)級的類庫，通過依賴清單聲明所有依賴項，通過依賴隔離工具確保程序不會調(diào)用系統(tǒng)中存在，但清單中未聲明依賴項，并統(tǒng)一應(yīng)用到生產(chǎn)和開發(fā)環(huán)境。比如通過合適的工具（例如Maven、Bundler、NPM），應(yīng)用可以很清晰地對部署環(huán)境公開和隔絕依賴性，而不是模糊地對部署環(huán)境產(chǎn)生依賴性。

在容器應(yīng)用中，所有應(yīng)用的依賴和安裝都是通過DockerFile來完成聲明的，通過配置能明確把依賴關(guān)系，包括版本都明確地圖形化展示出來，不存在黑盒。

配置

環(huán)境變量是一種清楚、容易理解和標(biāo)準(zhǔn)化的配置方法，將應(yīng)用的配置存儲于環(huán)境變量中，保證配置排除在代碼之外，或者其他可能在部署環(huán)境（例如研發(fā)、展示、生產(chǎn)）之間區(qū)別的任何代碼，可以通過操作系統(tǒng)級的環(huán)境變量來注入。

實例根據(jù)不同的環(huán)境配置運行在不同的環(huán)境中，此外，實現(xiàn)配置即代碼，在云環(huán)境中，無論是統(tǒng)一的配置中心還是分布式的配置中心都有好的實踐方式，比如Docker的環(huán)境變量使用。

后端服務(wù)

不用區(qū)別對待本地或第三方服務(wù)，統(tǒng)一把依賴的后端作為一種服務(wù)來對待，例如數(shù)據(jù)庫或者消息代理，作為附加資源，同等地在各種環(huán)境中被消耗。比如在云架構(gòu)的基礎(chǔ)服務(wù)中，計算、網(wǎng)絡(luò)、存儲資源都可以看作是一種服務(wù)去對待使用即可，不用區(qū)分是遠(yuǎn)程還是本地的。

構(gòu)建、發(fā)布、運行

應(yīng)用嚴(yán)格區(qū)分構(gòu)建、發(fā)布、運行這3個階段。3個階段是嚴(yán)格分開的，一個階段對應(yīng)做一件事情，每個階段有很明確的實現(xiàn)功能。云原生應(yīng)用的構(gòu)建流程可以把發(fā)布配置挪到開發(fā)階段，包括實際的代碼構(gòu)建和運行應(yīng)用所需的生產(chǎn)環(huán)境配置。在云原生應(yīng)用中，基于容器的Build-Ship-Run和這3個階段完全吻合，也是Docker對本原則的最佳實踐。

進程

進程必須無狀態(tài)且無共享，即云應(yīng)用以一個或多個無狀態(tài)不共享的程序運行。任何必要狀態(tài)都被服務(wù)化到后端服務(wù)中（緩存、對象存儲等）。

所有的應(yīng)用在設(shè)計時就認(rèn)為隨時隨地會失敗，面向失敗而設(shè)計，因此進程可能會被隨時拉起或消失，特別是在彈性擴容的階段。

端口綁定

不依賴于任何網(wǎng)絡(luò)服務(wù)器就可以創(chuàng)建一個面向網(wǎng)絡(luò)的服務(wù)，每個應(yīng)用的功能都很齊全，通過端口綁定對外提供所有服務(wù)，比如Web應(yīng)用通過端口綁定（Port binding）來提供服務(wù)，并監(jiān)聽發(fā)送至該端口的請求（包括HTTP）。

在容器應(yīng)用中，應(yīng)用統(tǒng)一通過暴露端口來服務(wù)，盡量避免通過本地文件或進程來通信，每種服務(wù)通過服務(wù)發(fā)現(xiàn)而服務(wù)。

并發(fā)

進程可以看作一等公民，并發(fā)性即可以依靠水平擴展應(yīng)用程序來實現(xiàn)，通過進程模型進行擴展，并且具備無共享、水平分區(qū)的特性。

在互聯(lián)網(wǎng)的服務(wù)中，業(yè)務(wù)的爆發(fā)性隨時可能發(fā)生，因此不太可能通過硬件擴容來隨時提供擴容服務(wù)，需要依賴橫向擴展能力進行擴容。

易處理

所有應(yīng)用的架構(gòu)設(shè)計都需要支持能隨時銷毀的特點，和狀態(tài)的無關(guān)性保持一致，允許系統(tǒng)快速彈性擴展、改變部署及故障恢復(fù)等。

在云環(huán)境中，由于業(yè)務(wù)的高低峰值經(jīng)常需要能實現(xiàn)快速靈活、彈性的伸縮應(yīng)用，以及不可控的硬件因素等，應(yīng)用可能隨時會發(fā)生故障，因此應(yīng)用在架構(gòu)設(shè)計上需要盡可能無狀態(tài)，應(yīng)用能隨時隨地拉起，也能隨時隨地銷毀，同時保證進程最小啟動時間和架構(gòu)的可棄性，也可以提供更敏捷的發(fā)布及擴展過程。

環(huán)境等價

必須縮小本地與線上差異，確保環(huán)境的一致性，保持研發(fā)、測試和生產(chǎn)環(huán)境盡可能相似，這樣可以提供應(yīng)用的持續(xù)交付和部署服務(wù)。

在容器化應(yīng)用中，通過文件構(gòu)建的環(huán)境運行能做到版本化，因此保證各個不同環(huán)境的差異性，同時還能大大減少環(huán)境不同帶來的排錯等成本溝通問題。

日志

每一個運行的進程都會直接標(biāo)準(zhǔn)輸出（stdout）和錯誤輸出（stderr）事件流，還可以將日志當(dāng)作事件流作為數(shù)據(jù)源，通過集中服務(wù)，執(zhí)行環(huán)境收集、聚合、索引和分析這些事件。

日志是系統(tǒng)運行狀態(tài)的部分體現(xiàn)，無論在系統(tǒng)診斷、業(yè)務(wù)跟蹤還是后續(xù)大數(shù)據(jù)服務(wù)的必要條件中，Docker提供標(biāo)準(zhǔn)的日志服務(wù)，用戶可以根據(jù)需求做自定義的插件開發(fā)來處理日志。

管理進程

管理或維護應(yīng)用的運行狀態(tài)是軟件維護的基礎(chǔ)部分，比如數(shù)據(jù)庫遷移、健康檢查、安全巡檢等，在與應(yīng)用長期運行的程序相同環(huán)境中，作為一次性程序運行。

在應(yīng)用架構(gòu)模式中，比如Kubernetes里面的Pod資源或者dockerexec，可以隨著其他的應(yīng)用程序一起發(fā)布或在出現(xiàn)異常診斷時能通過相關(guān)的程序去管理其狀態(tài)。

云原生應(yīng)用的邏輯依賴關(guān)系

云原生的內(nèi)容非常廣泛，目前沒有系統(tǒng)的說明和完整的定義，上文介紹了云原生應(yīng)用的基礎(chǔ)組件和相關(guān)特點，可能讀者對云原生應(yīng)用的邏輯還存在一些困惑。為了更清楚地進行說明，我們總結(jié)了其依賴關(guān)系，如圖所示。

首先，為了抓住商業(yè)機會，業(yè)務(wù)需要快速迭代，不斷試錯，因此，企業(yè)需要依賴擁有持續(xù)交付的能力，這些不僅包括技術(shù)需求還包括產(chǎn)品的需求，如何能擁有持續(xù)交付的能力，大而全的架構(gòu)因為效率低下，顯然是不合適的。于是演變出微服務(wù)架構(gòu)來滿足需求，通過把系統(tǒng)劃分出一個個獨立的個體，每個個體服務(wù)的設(shè)計依賴需要通過12要素的原則來規(guī)范完成。同樣，如果系統(tǒng)被分成了幾十個甚至幾百個服務(wù)組件，則需要借助DevOps才能很好地滿足業(yè)務(wù)協(xié)作和發(fā)布等流程。最后，DevOps的有效實施需要依賴一定的土壤，即敏捷的基礎(chǔ)設(shè)施服務(wù)，現(xiàn)實只有云計算的模式才能滿足整體要求。通過上述梳理，我們總結(jié)出面向云原生應(yīng)用的3個不同層次的特點。

高可用設(shè)計（Design for Availability），依據(jù)應(yīng)用業(yè)務(wù)需求，高可用分為不同級別，比如不同區(qū)域、不同機房（跨城或同城）、不同機柜、不同服務(wù)器和不同進程的高可用，云原生應(yīng)用應(yīng)該根據(jù)業(yè)務(wù)的可用性要求設(shè)計不同級別的架構(gòu)支持。

可擴展設(shè)計（Design for Scale），所有應(yīng)用的設(shè)計是無狀態(tài)的，使得業(yè)務(wù)天生具有擴展性，在業(yè)務(wù)流量高峰和低峰時期，依賴云的特性自動彈性擴容，滿足業(yè)務(wù)需求。

快速失敗設(shè)計（Design for Failure），即包括系統(tǒng)間依賴的調(diào)用隨時可能會失敗，也包括硬件基礎(chǔ)設(shè)施服務(wù)隨時可能宕機，還有后端有狀態(tài)服務(wù)的系統(tǒng)能力可能有瓶頸，總之在發(fā)生異常時能夠快速失敗，然后快速恢復(fù)，以保證業(yè)務(wù)永遠(yuǎn)在線，不能讓業(yè)務(wù)半死不活地僵持著。

通過上面的基本描述及云原生應(yīng)用的組成或特點，與容器技術(shù)相比可以得知，容器的特性天生就是按這些原則進行設(shè)計的。隨著互聯(lián)網(wǎng)業(yè)務(wù)的架構(gòu)不斷演進，從單體應(yīng)用到分布式應(yīng)用，甚至微服務(wù)架構(gòu)應(yīng)用中，12要素較好地為構(gòu)建互聯(lián)網(wǎng)化應(yīng)用提供了統(tǒng)一的方法論和標(biāo)準(zhǔn)化，具有強大的生命力，每一條原則都是應(yīng)用開發(fā)的珠璣。當(dāng)然，在實踐過程中，每一個原則也不是一成不變的，隨著新的理念和技術(shù)出現(xiàn)，原有的因素會得到延伸和發(fā)展，會出現(xiàn)新的原則和應(yīng)用，這套理論也適用于任意語言和后端服務(wù)（數(shù)據(jù)庫、消息隊列、緩存等）開發(fā)的應(yīng)用程序，因此也作為云原生架構(gòu)應(yīng)用的基本指導(dǎo)原則之一.

技術(shù)的趨勢和影響

軟件設(shè)計有兩個關(guān)鍵目標(biāo)：高內(nèi)聚、低耦合，圍繞這2個核心目標(biāo)，又提出了單一職責(zé)、開閉原則、里氏替換、依賴導(dǎo)致、接口隔離、最少知識等設(shè)計原則。

軟件工程師一直都在為這兩個目標(biāo)而努力奮斗，以求把軟件編寫得更加清晰、更加健壯、更加易于擴展和維護。

但后來，人們發(fā)現(xiàn)有更多的訴求，希望開發(fā)軟件變得更簡單、更快捷，程序員希望更少編寫代碼，非專業(yè)人員也希望能開發(fā)程序，于是，更多的更傻瓜的編程語言被發(fā)明出來，更多的編程技術(shù)和編程思想被發(fā)明出來，比如庫、組件、云基礎(chǔ)設(shè)施。

于是很多技術(shù)變成了屠龍之技，比如匯編，時代變了，建國后動物不能成精了，沒有龍可以宰了，然后很多軟件工程師搖身一變成了調(diào)參工程師、Call API磚家、用庫包能手、拼組件達人，這是效率分工的結(jié)果，也是技術(shù)發(fā)展的使然。

縱觀近二十年的科技互聯(lián)網(wǎng)發(fā)展歷程，大的趨勢是技術(shù)下沉，特別是近些年，隨著云計算的發(fā)展和普及，基礎(chǔ)設(shè)施越來越厚實，業(yè)務(wù)開發(fā)變得越來越容易，也越來越?jīng)]有技術(shù)含量，而之前困擾小團隊的性能、負(fù)載、安全性、擴展性問題都不復(fù)存在，這不禁讓互聯(lián)網(wǎng)行業(yè)的油膩大叔們噤若寒蟬，仿佛分分鐘就要被卷入歷史洪流而萬劫不復(fù)。

雖然不可否認(rèn)技術(shù)的重要性在降低，但也還不至于那么悲觀。遙想PC時代，當(dāng)VB、Delphi、MFC出現(xiàn)的時候，也有類似論調(diào)，所見即所得，點點鼠標(biāo)，就可以開發(fā)PC桌面程序，是不是很高端？

那時候碼農(nóng)的擔(dān)心相比現(xiàn)在恐怕是只多不少吧，但后來隨著互聯(lián)網(wǎng)興起，出現(xiàn)了后端開發(fā)這個工種，碼農(nóng)很快找到了新的戰(zhàn)場，網(wǎng)絡(luò)、分布式、數(shù)據(jù)庫、海量服務(wù)、容災(zāi)防錯，于是又玩出一堆新花樣。

如果說PC時代的基礎(chǔ)設(shè)施是控件庫，互聯(lián)網(wǎng)時代的基礎(chǔ)實施是云，那AI時代基礎(chǔ)設(shè)施是什么？又有什么高端玩法？

Kubernetes是容器編排系統(tǒng)的事實標(biāo)準(zhǔn)

在單機上運行容器，無法發(fā)揮它的最大效能，只有形成集群，才能最大程度發(fā)揮容器的良好隔離、資源分配與編排管理的優(yōu)勢，而對于容器的編排管理，Swarm、Mesos和Kubernetes的大戰(zhàn)已經(jīng)基本宣告技術(shù)，kubernetes成為了無可爭議的贏家。下面這張圖是Kubernetes的架構(gòu)圖，其中顯示了組件之間交互的接口CNI、CRI、OCI等，這些將Kubernetes與某款具體產(chǎn)品解耦，給用戶最大的定制程度，使得Kubernetes有機會成為跨云的真正的云原生應(yīng)用的操作系統(tǒng)。

Kuberentes架構(gòu)（圖片來自網(wǎng)絡(luò)）

隨著Kubernetes的日趨成熟，“Kubernetes is becoming boring”，基于該“操作系統(tǒng)”之上構(gòu)建的適用于不同場景的應(yīng)用將成為新的發(fā)展方向，就像我們將石油開采出來后，提煉出汽油、柴油、瀝青等等，所有的材料都將找到自己的用途，Kubernetes也是，畢竟我們誰也不是為了部署和管理容器而用Kubernetes，承載其上的應(yīng)用才是價值之所在。

云原生的核心目標(biāo)

Cloud Native Core target

云已經(jīng)可以為我們提供穩(wěn)定的可以唾手可得的基礎(chǔ)設(shè)施，但是業(yè)務(wù)上云成了一個難題。Kubernetes的出現(xiàn)與其說是從最初的容器編排解決方案，倒不如說是為了解決應(yīng)用上云（即云原生應(yīng)用）這個難題。包括微服務(wù)和FaaS/Serverless架構(gòu)，都可以作為云原生應(yīng)用的架構(gòu)。

但就2017年為止，kubernetes的主要使用場景也主要作為應(yīng)用開發(fā)測試環(huán)境、CI/CD和運行Web應(yīng)用這幾個領(lǐng)域，如下圖TheNewStack的Kubernetes生態(tài)狀況調(diào)查報告所示。

Workloads running on Kubernetes

另外基于Kubernetes的構(gòu)建PaaS平臺和Serverless也處于爆發(fā)的準(zhǔn)備階段，如下圖中Gartner的報告中所示：

當(dāng)前各大公有云如Google GKE、微軟Azure ACS、亞馬遜EKS（2018年上線）、VmWare、Pivotal、騰訊云、阿里云等都提供了Kuberentes服務(wù)。

微服務(wù)

微服務(wù)——Cloud Native的應(yīng)用架構(gòu)

下圖是Bilgin Ibryam給出的微服務(wù)中應(yīng)該關(guān)心的主題，圖片來自RedHat Developers。

Microservices concerns

微服務(wù)帶給我們很多開發(fā)和部署上的靈活性和技術(shù)多樣性，但是也增加了服務(wù)調(diào)用的開銷、分布式系統(tǒng)管理、調(diào)試與服務(wù)治理方面的難題。

當(dāng)前最成熟最完整的微服務(wù)框架可以說非Spring莫屬，而Spring又僅限于Java語言開發(fā)，其架構(gòu)本身又跟Kubernetes存在很多重合的部分，如何探索將Kubernetes作為微服務(wù)架構(gòu)平臺就成為一個熱點話題。

就拿微服務(wù)中最基礎(chǔ)的服務(wù)注冊發(fā)現(xiàn)功能來說，其方式分為客戶端服務(wù)發(fā)現(xiàn)和服務(wù)端服務(wù)發(fā)現(xiàn)兩種，Java應(yīng)用中常用的方式是使用Eureka和Ribbon做服務(wù)注冊發(fā)現(xiàn)和負(fù)載均衡，這屬于客戶端服務(wù)發(fā)現(xiàn)，而在Kubernetes中則可以使用DNS、Service和Ingress來實現(xiàn)，不需要修改應(yīng)用代碼，直接從網(wǎng)絡(luò)層面來實現(xiàn)。

兩種服務(wù)發(fā)現(xiàn)方式

Cloud Native

DevOps——通向云原生的云梯

CNCF（云原生計算基金會）給出了云原生應(yīng)用的三大特征：

容器化包裝：軟件應(yīng)用的進程應(yīng)該包裝在容器中獨立運行。
動態(tài)管理：通過集中式的編排調(diào)度系統(tǒng)來動態(tài)的管理和調(diào)度。
微服務(wù)化：明確服務(wù)間的依賴，互相解耦。

軟件生命周期維度看云原生

微軟的 Azure 計算服務(wù)架構(gòu)

Microsoft Azure Compute Service Categories

Virtual Machines - An Infrastructure as a Service (IaaS) offering that provides maximum control over the hosting environment and support for legacy workloads. Consumers are responsible for operational activities such as server patching and monitoring.
Virtual Machine Scale Sets - Provides services on top of Virtual Machines where you need to deploy large numbers of identical servers with load balancing and auto-scale, reducing some operational overhead.
Containers - Provides traditional container orchestrators (Docker, Kubernetes, Mesos) as well as Microsoft’s Service Fabric for building managed microservices applications that are resilient and scalable, and support Linux and Windows platforms.
App Services - A fully managed and scalable Platform as a Service (PaaS) offering for Web, Mobile and API applications, which removes a lot of the management overhead, yet provides flexibility with support for multiple platforms (Windows/Linux) and languages (.NET, Node.js, PHP, Java, Python).
Serverless - Provides an on-demand and scalable execution model for coded functions in multiple programming languages, so that you pay only for the time the code is executing, from the point at which it is triggered to completion.

Figure 2 Azure Cloud-Native Application Framework

Completing the picture

In addition to the compute services already described, Azure offers a range of other managed services to enable development of end-to-end applications.

Storage - Managed storage for logs, document and media files (e.g. Blobs and SMB File services).
Data - Relational and NoSQL databases, caching and search services (e.g. SQL Azure, Cosmos DB, Redis Cache, Azure Search).
Messaging - Queues and subscriptions (e.g. Azure Service Bus).
Security - Authentication services (e.g. Azure AD).
Network - Traffic management, content delivery, load balancing and network virtual appliances.

Specialised or more advanced apps can make use of additional services for Artificial Intelligence, Analytics and Event driven architectures (such as IoT) and integration for hybrid scenarios.

Putting all of this together, figure 2 shows a framework for building cloud-native applications on Azure. Other cloud platforms do provide similar offerings. If you are not using Azure, hopefully this article has given you some things to look out for on your cloud platform to build cloud-native apps that respond to change and enable you to work at the pace your business demands.