什麼是“雲原生”？雲原生該怎麼落地？
微服務：幾乎每個雲原生的定義都包含微服務，跟微服務相對的是單體應用，微服務有理論基礎，那就是康威定律，指導服務怎麼切分，很玄乎，凡是能稱為理論定律的都簡單明白不了，不然就忒沒b格，大概意思是組織架構決定産品形态，不知道跟馬克思的生産關系影響生産力有無關系。
微服務架構的好處就是按function切了之後，服務解耦，内聚更強，變更更易；另一個劃分服務的技巧據說是依據ddd來搞。
容器化：docker是應用最為廣泛的容器引擎，在思科谷歌等公司的基礎設施中大量使用，是基于lxc技術搞的，容器化為微服務提供實施保障，起到應用隔離作用，k8s是容器編排系統，用于容器管理，容器間的負載均衡，谷歌搞的，docker和k8s都采用go編寫，都是好東西。
devops：這是個組合詞，dev+ops，就是開發和運維合體，不像開發和産品，經常刀刃相見，實際上devops應該還包括測試，devops是一個靈活思維，是一個溝通文化，也是組織形式，為雲原生提供持續傳遞能力。
持續傳遞：持續傳遞是不誤時開發，不停機更新，小步快跑，反傳統瀑布式開發模型，這要求開發版本和穩定版本并存，其實需要很多流程和工具支撐。
很多人都會問“到底什麼是雲原生？”
實際上，雲原生是一條最佳路徑或者最佳實踐。更詳細的說，雲原生為使用者指定了一條低心智負擔的、靈活的、能夠以可擴充、可複制的方式最大化地利用雲的能力、發揮雲的價值的最佳路徑。
是以，雲原生其實是一套指導進行軟體架構設計的思想。按照這樣的思想而設計出來的軟體：首先，天然就“生在雲上，長在雲上”；其次，能夠最大化地發揮雲的能力，使得我們開發的軟體和“雲”能夠天然地內建在一起，發揮出“雲”的最大價值。
是以，雲原生的最大價值和願景，就是認為未來的軟體，會從誕生起就生長在雲上，并且遵循一種新的軟體開發、釋出和運維模式，進而使得軟體能夠最大化地發揮雲的能力。說到了這裡，大家可以思考一下為什麼容器技術具有革命性？
其實，容器技術和集裝箱技術的革命性非常類似，即：容器技術使得應用具有了一種“自包含”的定義方式。是以，這樣的應用才能以靈活的、以可擴充可複制的方式釋出在雲上，發揮出雲的能力。這也就是容器技術對雲發揮出的革命性影響所在，是以說，容器技術正是雲原生技術的核心底盤。
雲原生的技術範疇包括了以下幾個方面：
第一部分是雲應用定義與開發流程。這包括應用定義與鏡像制作、配置 ci/cd、消息和 streaming 以及資料庫等。
第二部分是雲應用的編排與管理流程。這也是 kubernetes 比較關注的一部分，包括了應用編排與排程、服務發現治理、遠端調用、api 網關以及 service mesh。
第三部分是監控與可觀測性。這部分所強調的是雲上應用如何進行監控、日志收集、tracing 以及在雲上如何實作破壞性測試，也就是混沌工程的概念。
第四部分就是雲原生的底層技術，比如容器運作時、雲原生存儲技術、雲原生網絡技術等。
第五部分是雲原生工具集，在前面的這些核心技術點之上，還有很多配套的生态或者周邊的工具需要使用，比如流程自動化與配置管理、容器鏡像倉庫、雲原生安全技術以及雲端密碼管理等。
最後則是 serverless。serverless 是一種 paas 的特殊形态，它定義了一種更為“極端抽象”的應用編寫方式，包含了 faas 和 baas 這樣的概念。而無論是 faas 還是 baas，其最為典型的特點就是按實際使用計費（pay as you go），是以 serverless 計費也是重要的知識和概念。
在了解完雲原生的技術範疇之後你就會發現，其所包含的技術内容還是很多的，但是這些内容的技術本質卻是類似的。雲原生技術的本質是兩個理論基礎。
第一個理論基礎是：不可變基礎設施。這一點目前是通過容器鏡像來實作的，其含義就是應用的基礎設施應該是不可變的，是一個自包含、自描述可以完全在不同環境中遷移的東西；
第二個理論基礎就是：雲應用編排理論。目前的實作方式就是 google 所提出來的“容器設計模式”，這也是本系列課程中的 kubernetes 部分所需主要講解的内容。
首先為大家介紹一下“不可變基礎設施”的概念。其實，應用所依賴的基礎設施也在經曆一個向雲演進的過程，舉例而言，對于傳統的應用基礎設施而言，其實往往是可變的。
大家可能經常會幹這樣一件事情，比如需要釋出或者更新一個軟體，那麼流程大緻是這樣的，先通過 ssh 連到伺服器，然後手動更新或者降級軟體包，逐個調整伺服器上的配置檔案，并且将新代碼直接都部署到現有伺服器上。是以，這套基礎設施會不斷地被調整和修改。
但是在雲上，對“雲”友好的應用基礎設施是不可變的。
這種場景下的上述更新過程會這麼做：一旦應用部署完成之後，那麼這套應用基礎設施就不會再修改了。如果需要更新，那麼需要現更改公共鏡像來建構新服務直接替換舊服務。而我們之是以能夠實作直接替換，就是因為容器提供了自包含的環境（包含應用運作所需的所有依賴）。是以對于應用而言，完全不需要關心容器發生了什麼變化，隻需要把容器鏡像本身修改掉就可以了。是以，對于雲友好的基礎設施是随時可以替換和更換的，這就是因為容器具有靈活和一緻性的能力，也就是雲時代的應用基礎設施。
是以，總結而言，雲時代的基礎設施就像是可以替代的“牲口”，可以随時替換；而傳統的基礎設施則是獨一無二的“寵物”，需要細心呵護，這就展現出了雲時代不可變基礎設施的優點。
是以，像這樣的基礎設施向“不可變”演進的過程，為我們提供了兩個非常重要的優點。
1、基礎設施的一緻性和可靠性。同樣一個鏡像，無論是在美國打開，在中國打開，還是在印度打開都是一樣的。并且其中的 os 環境對于應用而言都是一緻的。而對于應用而言，它就不需要關心容器跑在哪裡，這就是基礎設施一緻性非常重要的一個特征。
2、這樣的鏡像本身就是自包含的，其包含了應用運作所需要的所有依賴，是以也可以漂移到雲上的任何一個位置。
此外，雲原生的基礎設施還提供了簡單、可預測的部署和運維能力。由于現在有了鏡像，應用還是自描述的，通過鏡像運作起來的整個容器其實可以像 kubernetes 的 operator 技術一樣将其做成自運維的，是以整個應用本身都是自包含的行為，使得其能夠遷移到雲上任何一個位置。這也使得整個流程的自動化變得非常容易。
應用本身也可以更好地擴容，從 1 個執行個體變成 100 個執行個體，進而變成 1 萬個執行個體，這個過程對于容器化後的應用沒有任何特殊的。最後，我們這時也能夠通過不可變的基礎設施來地快速周圍的管控系統和支撐元件。因為，這些元件本身也是容器化的，是符合不可變基礎設施這樣一套理論的元件。
以上就是不可變基礎設施為使用者帶來的最大的優點。
當我們回過頭來看雲原生關鍵技術點或者說它所依賴的技術理論的時候，可以看到主要有這樣的四個方向：
如何建構自包含、可定制的應用鏡像；
能不能實作應用快速部署與隔離能力；
應用基礎設施建立和銷毀的自動化管理；
可複制的管控系統和支撐元件。
雲原生（cloud native）的定義
pivotal 是雲原生應用的提出者，并推出了 pivotal cloud foundry 雲原生應用平台和 spring 開源 java 開發架構，成為雲原生應用架構中先驅者和探路者。
早在2015年pivotal公司的matt stine寫了一本叫做遷移到雲原生應用架構的小冊子，其中探讨了雲原生應用架構的幾個主要特征：
符合12因素應用
面向微服務架構
自服務靈活架構
基于api的協作
抗脆弱性
我已于2017年翻譯了本書，詳見遷移到雲原生應用架構。
到了2015年google主導成立了雲原生計算基金會（cncf），起初cncf對雲原生（cloud native）的定義包含以下三個方面：
應用容器化
應用支援容器的編排排程
到了2018年，随着近幾年來雲原生生态的不斷壯大，所有主流雲計算供應商都加入了該基金會，且從cloud native landscape中可以看出雲原生有意蠶食原先非雲原生應用的部分。cncf基金會中的會員以及容納的項目越來越多，該定義已經限制了雲原生生态的發展，cncf為雲原生進行了重新定位。
以下是cncf對雲原生的重新定義（中英對照）：
cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. containers, service meshes, microservices, immutable infrastructure, and declarative apis exemplify this approach.
雲原生技術有利于各組織在公有雲、私有雲和混合雲等新型動态環境中，建構和運作可彈性擴充的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式api。
these techniques enable loosely coupled systems that are resilient, manageable, and observable. combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
這些技術能夠建構容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。
the cloud native computing foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. we democratize state-of-the-art patterns to make these innovations accessible for everyone.
雲原生計算基金會（cncf）緻力于培育和維護一個廠商中立的開源生态系統，來推廣雲原生技術。我們通過将最前沿的模式民主化，讓這些創新為大衆所用。
雲原生架構定義
現在我們将探索雲原生應用架構的幾個主要特征，和這些特征是如何解決我們前面提到的使用雲原生應用架構的動機。
12因素應用是一系列雲原生應用架構的模式集合，最初由heroku提出。這些模式可以用來說明什麼樣的應用才是雲原生應用。它們關注速度、安全、通過聲明式配置擴充、可橫向擴充的無狀态/無共享程序以及部署環境的整體松耦合。如cloud foundry、heroku和amazon elasticbeanstalk都對部署12因素應用進行了專門的優化。
在12因素的背景下，應用（或者叫app）指的是獨立可部署單元。組織中經常把一些互相協作的可部署單元稱作一個應用。
12因素應用遵循以下模式：
代碼庫
每個可部署app在版本控制系統中都有一個獨立的代碼庫，可以在不同的環境中部署多個執行個體。
依賴
app應該使用适當的工具（如maven、bundler、npm）來對依賴進行顯式的聲明，而不該在部署環境中隐式的實作依賴。
配置
配置或其他随釋出環境（如部署、staging、生産）而變更的部分應當作為作業系統級的環境變量注入。
後端服務
後端服務，例如資料庫、消息代理應視為附加資源，并在所有環境中同等看待。
編譯、釋出、運作
建構一個可部署的app元件并将它與配置綁定，根據這個元件/配置的組合來啟動一個或者多個程序，這兩個階段是嚴格分離的。
程序
該app執行一個或者多個無狀态程序（例如master/work），它們之間不需要共享任何東西。任何需要的狀态都置于後端服務（例如cache、對象存儲等）。
端口綁定
該應用程式是獨立的，并通過端口綁定（包括http）導出任何/所有服務。
并發
并發通常通過水準擴充應用程式程序來實作（盡管如果需要的話程序也可以通過内部管理的線程多路複用來實作）。
可任意處置性
通過快速迅速啟動和優雅的終止程序，可以最大程度上的實作魯棒性。這些方面允許快速彈性縮放、部署更改和從崩潰中恢複。
開發/生産平等
通過保持開發、staging和生産環境盡可能的相同來實作持續傳遞和部署。
日志
不管理日志檔案，将日志視為事件流，允許執行環境通過集中式服務收集、聚合、索引和分析事件。
管理程序
行政或管理類任務（如資料庫遷移），應該在與app長期運作的相同的環境中一次性完成。
這些特性很适合快速部署應用程式，因為它們不需要對将要部署的環境做任何假定。對環境假設能夠允許底層雲平台使用簡單而一緻的機制，輕松實作自動化，快速配置新環境，并部署應用。以這種方式，十二因素應用模式能夠幫我們優化應用的部署速度。
這些特性也很好地适用于突發需求，或者低成本地“丢棄”應用程式。應用程式環境本身是100％一次性的，因為任何應用程式狀态，無論是記憶體還是持久性，都被提取到後端服務。這允許應用程式以易于自動化的非常簡單和彈性的方式進行伸縮。在大多數情況下，底層平台隻需将現有環境複制到所需的數目并啟動程序。縮容是通過暫停正在運作的程序和删除環境來完成，無需設法地實作備份或以其他方式儲存這些環境的狀态。就這樣，12因素應用模式幫助我們實作規模優化。
最後，應用程式的可處理性使得底層平台能夠非常快速地從故障事件中恢複。
此外，将日志作為事件流處理能夠極大程度上的增強應用程式運作時底層行為的可見性。
強制環境之間的等同、配置機制的一緻性和後端服務管理使雲平台能夠為應用程式運作時架構的各個方面提供豐富的可見性。以這種方式，十二因素應用模式能夠優化安全性。
微服務将單體業務系統分解為多個“僅做好一件事”的可獨立部署的服務。這件事通常代表某項業務能力，或者最小可提供業務價值的“原子“服務單元。
微服務架構通過以下幾種方式為速度、安全、可擴充性賦能：
當我們将業務領域分解為可獨立部署的有限能力的環境的同時，也将相關的變更周期解耦。隻要變更限于單一有限的環境，并且服務繼續履行其現有合約，那麼這些更改可以獨立于與其他業務來進行開展和部署。結果是實作了更頻繁和快速的部署，進而實作了持續的價值流動。
通過擴充部署組織本身可以加快部署。由于溝通和協調的開銷，添加更多的人，往往會使軟體建構變得更加苦難。 弗雷德·布魯克斯（fred brooks，人月神話作者）很多年前就教導我們，在軟體項目的晚期增加更多的人力将會時軟體項目更加延期。 然而，我們可以通過在有限的環境中建構更多的沙箱，而不是将所有的開發者都放在同一個沙箱中。
由于學習業務領域和現有代碼的認知負擔減少，并建立了與較小團隊的關系，是以我們添加到每個沙箱的新開發人員可以更快速地提高并變得更高效。
可以加快采用新技術的步伐。大型單體應用架構通常與對技術堆棧的長期保證有關。這些保證的存在是為了減輕采用新技術的風險。采用了錯誤的技術在單體架構中的代價會更高，因為這些錯誤可能會影響整個企業架構。如果我們可以在單個整體的範圍内采用新技術，将隔離并最大限度地降低風險，就像隔離和最小運作時故障的風險一樣。
微服務提供獨立、高效的服務擴充。單體架構也可以擴充，但要求我們擴充所有元件，而不僅僅是那些負載較重的元件。當且僅當相關聯的負載需要它時，微服務才會被縮放。
使用雲原生應用架構的團隊通常負責其應用的部署和持續營運。雲原生應用的成功采納者已經為團隊提供了自服務平台。
正如我們建立業務能力團隊為每個有界的環境建構微服務一樣，我們還建立了一個能力小組，負責提供一個部署和運作這些微服務的平台。
這些平台中最大好處是為消費者提供主要的抽象層。通過基礎架構即服務（iaas），我們要求api建立虛拟伺服器執行個體、網絡和存儲，然後應用各種形式的配置管理和自動化，以使我們的應用程式和支援服務能夠運作。現在這種允許我們自定義應用和支援服務的平台正在不斷湧現。
應用程式代碼簡單地以預建構的工件（可能是作為持續傳遞管道的一部分生成的）或git遠端的原始源代碼的形式“推送”。 然後，平台建構應用程式工件，建構應用程式環境，部署應用程式，并啟動必要的程序。 團隊不必考慮他們的代碼在哪裡運作或如何到達那裡，這些對使用者都是透明得，因為平台會關注這些。
這樣的模型同樣适合于後端服務。需要資料庫？ 消息隊列或郵件伺服器？ 隻需要求平台來配合您的需求。平台現在支援各種sql/nosql資料存儲、消息隊列、搜尋引擎、緩存和其他重要的後端服務。這些服務執行個體然後可以“綁定”到您的應用程式，必要的憑據會自動注入到應用程式的環境中以供其使用。進而消除了大量淩亂而易出錯的定制自動化。
這些平台還經常提供廣泛的額外操作能力：
應用程式執行個體的自動化和按需擴充
應用健康管理
請求到或跨應用程式執行個體間的動态路由和負載均衡
日志和名額的聚合
這種工具的組合確定了能力團隊能夠根據靈活原則開發和運作服務，進而實作速度，安全性和規模化。
在雲原生應用架構中，服務之間的唯一互動模式是通過已釋出和版本化的api。這些api通常是具有json序列化的http rest風格，但也可以是其他協定和序列化格式。
隻要有需要，在不會破壞任何現有的api協定的前提下，團隊就可以部署新的功能，而不需要與其他團隊進行同步。自助服務基礎設施平台的主要互動模式也是通過api，就像其他業務服務一樣。供給、縮放和維護應用程式基礎設施的方式不是通過送出單據，而是将這些請求送出給提供該服務的api。
通過消費者驅動的協定，可以在服務間互動的雙方驗證協定的合規性。服務消費者不能通路其依賴關系的私有實作細節，或者直接通路其依賴關系的資料存儲。實際上，隻允許有一個服務能夠直接通路任何資料存儲。這種強制解耦直接支援雲原生的速度目标。
nassim taleb在他的antifragile（random house）一書中介紹了抗脆弱性的概念。如果脆弱性是受到壓力源的弱化或破壞的品質系統，那麼與之相反呢？許多人會以穩健性或彈性作出回應——在遭受壓力時不會被破壞或變弱。然而，taleb引入了與脆弱性相反的抗脆弱性概念，或者在受到壓力源時變得更強的品質系統。什麼系統會這樣工作？聯想下人體免疫系統，當接觸病原體時，其免疫力變強，隔離時較弱。我們可以像這樣建立架構嗎？雲原生架構的采用者們已經設法建構它們了。netflix simian army項目就是個例子，其中著名的子子產品“混沌猴”，它将随機故障注入到生産元件中，目的是識别和消除架構中的缺陷。通過明确地尋求應用架構中的弱點，注入故障并強制進行修複，架構自然會随着時間的推移而更大程度地收斂。