雲原生是什麼？
1、雲原生產生背景
雲計算技術的發展，企業上雲已成爲趨勢，越來越多的企業都已將應用部署到了雲上。但是應用上雲並不意味着就能充分利用雲平臺的優勢。目前，大部分雲化的應用，都是基於傳統的軟件架構來搭建的，然後再移植到雲上去運行，和雲平臺的整合度非常低，主要表現在以下幾個方面：
-
操作系統依賴強
傳統應用程序和底層操作系統、硬件、存儲和後備服務之間存在緊密的依賴關係，這些依賴關係使得應用程序在跨越雲基礎設施進行遷移和擴展時非常複雜且有風險。 -
系統緊耦合
傳統的企業應用多采用單體架構，將許多不同的功能模塊捆綁在一個部署包中，導致功能模塊之間產生不必要的依賴，並導致開發和部署過程中喪失敏捷性，無法獨立的部署、發佈更新、重啓。 -
手動化擴展
通過手工管理基礎設施，包括手工編寫管理服務器、網絡和存儲的配置腳本。在大規模複雜的操作中，操作人員在診斷問題時會很慢，而且無法大規模地實施。手工製作的自動化腳本還有可能將人爲錯誤硬編碼到基礎設施中。 -
恢復緩慢
基於虛擬機的基礎設施相對於基於微服務的應用程序來說，是緩慢而低效的。因爲單個虛擬機啓動/關閉的速度很慢，並且在部署應用程序代碼之前就會帶來巨大的開銷。 -
瀑布開發
傳統應用的開發模式，IT團隊定期發佈軟件，通常間隔幾周或幾個月。儘管發佈的許多組件已經提前準備好了，並且沒有依賴關係，也必須等待版本中的其他組件。客戶想要的功能被延遲，企業失去贏得客戶和增加收入的機會。
小結
- 早期雲計算提供了一些基礎設施，我們只是對雲計算初級的利用，並沒有充分發貨雲計算的優勢。（彈性、高可用性、易擴展性）。
- 如果想要充分利用雲計算，從基礎設施、平臺、軟件架構、開發方式、部署等各個方面和各個階段都應基於雲的特點來重新設計。
2、雲原生定義的變化
每個人對雲原生的理解都可能不同，就如莎士比亞所說：一千個人眼中有一千個哈姆雷特。
2013年由Pivotal公司的Matt Stine首次提出了雲原生（CloudNative）的概念；
2015年Matt Stine在《遷移到雲原生應用架構》書中定義了符合雲原生架構的幾個特徵：
- 符合 12 因素應用
- 面向微服務架構
- 自敏捷架構
- 基於API協作
- 扛脆弱性
在2017年10月，Matt Stine在接受InfoQ採訪時,則對雲原生的定義做了小幅調整,將Cloud Native Architectures定義爲具有以下六個特質:
- 模塊化(Modularity): (通過微服務)
- 可觀測性(Observability)
- 可部署性(Deployability)
- 可測試性(Testability)
- 可處理性(Disposability)
- 可替換性(Replaceability)
兩年後, Pivotal在其官網上將雲原生的定義概況爲DevOps、持續交付、微服務、容器這四大特徵，這也成了很多人對 Cloud Native的基礎印象。
- DevOps:
開發運維一體化。涉及整個軟件的開發週期中的持續開發、持續測試、持續集成、持續部署、持續監控等。（什麼是DevOps？） - 持續交付
整個開發過程不停機不"斷電"的更新新特性。一般採用敏捷模式小布快跑，反傳統瀑布流開發模型，要求開發版本、穩定版本等多版本共存。需要大量流程和工具作爲支撐。《發佈可靠軟件的系統方法》 - 微服務
微服務是一種開發軟件的架構和組織方法，其中軟件由通過明確定義的 API 進行通信的小型獨立服務組成。康威定律、ddd等可以指導工作。 (什麼是微服務?) - 容器
容器的本質是與系統其他部分隔離開的一個或一組進程。 (容器的隔離與限制 什麼是容器？)
2015 年 Google 主導成立了雲原生計算基金會CNCF開始圍繞雲原生的概念打造雲原生生態體系，起初CNCF對雲原生的定義包含以下三個方面：
- 應用容器化
- 面向微服務架構
- 應用支持容器的編排調度
2018年，隨着雲原生生態的擴大，衆多主流雲計算供應商都加入了CNCF。在6月正式對外公佈了更新之後的雲原生的定義V1.0版本:
雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。
雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。
雲原生計算基金會（CNCF）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。我們通過將最前沿的模式民主化，讓這些創新爲大衆所用。
-
容器
-
服務網格（Service Mesh）
處理服務間通信的專用基礎設施層，負責在微服務間進行可靠地請求傳遞。服務網格通常通過一組輕量級網絡代理來實現，這些代理與應用程序代碼一起部署，而不需要感知應用程序本身。
隨着規模和複雜性的增長，服務網格包含的實現的功能越來越多，它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及通常更加複雜的運維需求，例如 A/B 測試、金絲雀發佈、限流、訪問控制和端到端認證等
![img]()
-
微服務是一種開發軟件的架構和組織方法，其中軟件由通過明確定義的 API 進行通信的小型獨立服務組成。這些服務由各個小型獨立團隊負責。
特性:自主性、專用性
優勢:敏捷性、靈活擴展、輕鬆部署、技術自由、可重複使用的代碼、彈性 -
不可變基礎設施（Immutable Infrastructure）
任何基礎設施的實例（包括服務器、容器等各種軟硬件）一旦創建之後便成爲一種只讀狀態，不可對其進行任何更改。如果需要修改或升級某些實例，唯一的方式就是創建一批新的實例以替換。這種思想與不可變對象的概念是完全相同的。
-
聲明式API（Declarative APIs）
首先，所謂“聲明式”，指的就是我只需要提交一個定義好的 API 對象來“聲明”，我所期望的狀態是什麼樣子。
其次，“聲明式 API”允許有多個 API 寫端，以 PATCH 的方式對 API 對象進行 修改，而無需關心本地原始 YAML 文件的內容。一次能處理多個寫操作，並且具 備 Merge 能力。
最後，也是最重要的，有了上述兩個能力，Kubernetes 項目纔可以基於對 API 對象的增、刪、改、查，在完全無需外界干預的情況下，完成對“實際狀態”和“期 望狀態”的調諧（Reconcile）過程。
小結
- 雲原生的定義一直在變
- 不同組織有不同的定義: Pivotal & CNCF
- 同一個組織在不同時間點有不同的定義
- 同一個人在不同時間點也有不同的定義
- 雲原生的定義未來還會變
- CNCF最新的定義:版本v1.0
雲原生自身的定義一直在變，這讓我們該如何才能準確的理解雲原生呢？
3、如何理解雲原生(Cloud Native)？
Cloud Native我們拆開來理解，先看看什麼是Cloud。
1、什麼是Cloud
雲計算的演進歷史
雲計算的出現和虛擬化技術的發展和成熟密切相關，2000年前後x86的虛擬機技術成熟後，雲計算逐漸發展起來。
基於虛擬機技術，陸續出現了IaaS/PaaS/FaaS等形態，以及他們的開源版本
2013年docker出現，容器技術成熟，然後圍繞容器編排一場大戰，最後在2017年底，kubernetes勝出。2015年CNCF成立，並在近年形成了cloud native生態。
這是雲的形態變化，可以看到：供應商提供的功能越來越多，而客戶或者說應用需要自己管理的功能越來越少。
2、什麼是Native？
拋出一個我們自己的理解：雲原生代表着原生爲雲設計。詳細的解釋是：應用原生被設計爲在雲上以最佳方式運行，充分發揮雲的優勢。
CNCF
什麼是CNCF
cncf官網：https://www.cncf.io/
CNCF 致力於培育和維護一個廠商中立的開源社區生態，用以推廣雲原生技術。
從 2015 年 Google 牽頭成立 CNCF 以來，雲原生技術開始進入公衆的視線並取得快速的發展，到 2018 年包括 Google、AWS、Azure、Alibaba Cloud 等大型雲計算供應商都加入了雲原生基金會 CNCF，雲原生技術也從原來的應用容器化發展出包括容器、Service Mesh、微服務、不可變基礎設施、Serverless、FaaS 等衆多技術方向。
CNCF 是非營利性 Linux 基金會的一部分。他成立的目的是希望打破雲巨頭的壟斷，實際上是希望通過容器和k8s，將提供底層資源的雲服務商變得無差異化
雲原生Landscape（景觀）指南
https://landscape.cncf.io/guide
如果您研究過雲原生應用程序和技術，那麼您可能見過 CNCF Cloud Native Interactive Landscape。它的龐大規模可能是巨大的，擁有如此多的類別和如此多的技術。
cloud native landscape的目標是將所有云原生開源項目和專有產品編譯和組織到類別中，提供當前生態系統的概覽。擁有云原生項目或產品的組織可以 提交 PR以請求將其添加到環境中。
CNCF 目前託管了非常多的開源項目，其中有很多我們耳熟能詳的項目，例如 Kubernetes、Prometheus、Envoy、Istio、etcd 等。
參考資料
CNCF雲原生定義
cncf.io
遷移到雲原生應用架構
容器的隔離與限制
雲原生應用開發“12-Factors”
什麼是DevOps？
什麼是微服務?
什麼是雲原生？
什麼是容器？
Micro Service
如何更好地使用容器技術實現不可變基礎設施）
自定義資源
極客時間：深入剖析Kubernetes
持續部署
持續集成
什麼是linux容器
--- 部門分享