雲原生這個詞已經頻頻霸佔技術頭條榜上，繼深度學習、大數據、區塊鏈技術之後又一跨界刷榜利器，那麼雲原生究竟講得是什麼呢？那麼我來雜談下雲原生得那些事。
雲原生,相信這個詞大家應該或多或少都聽過, 那麼什麼是雲原生計算呢?雲原生技術得技術棧有哪些呢?
下面主要從以下三個主題來聊聊今天得話題, 什麼是雲原生, 雲原生得發展史和雲原生得生態圈。
雲原生的概念最早開始於2010年，在當時 Paul Fremantle 的一篇博客中被提及，他主要將其描述為一種和雲一樣的系統行為的應用的編寫，比如分佈式的、鬆散的、自服務的、持續部署與測試的。當時提出雲原生是為了能構建一種符合雲計算特性的標準來指導雲計算應用的編寫。後來到2013年 Matt Stine在推特上迅速推廣雲原生概念，並在2015年《遷移到雲原生架構》一書中定義了符合雲原生架構的特徵：12因素、微服務、自服務、基於API協作、扛脆弱性。而由於這本書的推廣暢銷，這也成了很多人對雲原生的早
CNCF得定義總結一下就是:（1）基於容器、服務網格、微服務、不可變基礎設施和聲明式API構建的可彈性擴展的應用；（2）基於自動化技術構建具備高容錯性、易管理和便於觀察的松耦合系統；（3）構建一個統一的開源雲技術生態，能和雲廠商提供的服務解耦，可以看出這一階段CNCF對雲原生的定義加上服務網格和聲明式API，同時為這一概念闡述更深一層的意義，也就是建立一個統一中立的開源雲生態（至於是否中立嘛這裡就不談了:）。這對雲原生的生態定位會是很重要的一點，也算CNCF最初成立的宗旨之一吧，打破雲巨頭的壟斷。
為什麼用“解構”？
解構，或譯為“結構分解”，是後結構主義提出的一種批評方法。是解構主義者德里達的一個術語。“解構”概念源於海德格爾《存在與時間》中的“deconstruction”一詞，原意為分解、消解、拆解、揭示等，德里達在這個基礎上補充了“消除”、“反積澱”、“問題化”等意思。這裡是打算用解構得思想給大家來分析下“雲原生”得理解：
Cloud Native，從詞面上拆解其實就是 Cloud 和 Native，也就是雲計算和土著的意思——雲計算上的原生居民，即天生具備雲計算的親和力。那怎麼理解“雲的原生居民”呢？首先從雲的角度來理解，雲本質可以看作是一種提供穩定計算存儲資源的對象，為了實現這點，像虛擬化、彈性擴展、高可用、高容錯性、自恢復這些都是雲的基本屬性，雲原生作為一種雲計算，這是所具備的第一層含義。第二層要從 Native 來看，雲原生和傳統的在雲上跑的應用是不同。比如一些基於公有云搭建的應用，是基於傳統的SOA架構來搭建的，然後再移植到雲上去運行，那麼他和雲得整合是非常低得。為什麼低呢？雲作為一種分佈式架構，其“土著居民”也應該是基於分佈式架構設計出來得，而微服務或者Serverless這種將服務或函數拆分成一個個模塊的松耦合系統天然就具備分佈式設計得屬性。這是Native的第一種表現。其次雲作為一種PaaS服務，這位“土著居民”從出生(設計)到成長(開發)，再到生活(部署)都應該是基於雲的理念來實現的，那麼就需要一套自動化的開發流程CI/CD來實現。這是Native的第二種表現。而最後“土著居民”的特點希望做到能在所有的雲端都是適應的，不管是各廠商的公有云 像AWS、Azure、阿里雲，還是各企業自己搭建的私有云，雲原生的應用都能做到無縫的運行和連接。
雲原生的發展歷史可以分為三個時代, 虛擬機時代->容器時代->雲原生時代。
虛擬機時代:這要從2006年說起，這一年Avi Kivity宣告了Kernel-based Virtual Machine的誕生，也就是我們常說的KVM——基於內核的虛擬機，採用硬件虛擬化技術的全虛擬化解決方案。KVM以其精簡的架構，清晰的定位獲得Linux社區多數開發人員的支持並快速被合併入主幹,2007年2月，KVM發佈到內核2.6.20中。KVM從誕生開始就定位於基於硬件虛擬化支持的全虛擬化實現。它以內核模塊的形式加載之後，就將Linux內核變成了一個Hypervisor，但硬件管理等還是通過Linux kernel來完成的，一個KVM客戶機對應於一個Linux進程，每個vCPU則是這個進程下的一個線程，還有單獨的處理IO的線程，也在一個線程組內。所以，宿主機上各個客戶機是由宿主機內核像調度普通進程一樣調度的，即可以通過Linux的各種進程調度的手段來實現不同客戶機的權限限定、優先級等功能。除了KVM，這一年由Google的工程師Paul Menage和Rohit Seth 在2006年發起一個叫進程容器（process containers）的項目，這就是後面容器時代的基石之一 —— Cgroups。在2007年時，因為在Linux內核中，容器（container）這個名詞有許多不同的意義，為避免混亂，被重命名為Cgroups，並且被合併到2.6.24版的內核中去。隨後，2008 年，通過將 Cgroups 的資源管理能力和 Linux Namespace 的視圖隔離能力組合在一起，LXC 完整的容器技術出現在 Linux 內核中，並且可以在單個 Linux 內核上運行而無需任何補丁。隨後2010年7月，NASA和Rackspace共同發佈了著名的開源項目Openstack，Openstack的開源標誌著開源領域真正具有一個成熟的雲計算解決方案。
容器時代：容器時代的標誌性事件就是 dotCloud 開源的一個基於 LXC 的高級容器引擎 Docker的問世。Docker產品的發佈，讓企業逐漸從笨重的虛擬機轉換到輕量級的容器部署，隨著docker的發佈，市面上湧現出大量的容器解決方案大量輕量級的虛擬化解決方案，如Rocket、Windows Containers等。
雲原生時代：隨著容器的成熟和雲計算的發展，人們迫切需要一種在雲上的最佳實踐，雲原生就被提出了。在2015年，Linux基金會成立了一個叫The Cloud Native Computing Foundation基金組織，也就是CNCF。隨著大廠的加盟，像Google、AWS、微軟、阿里巴巴、騰訊雲、IBM等，CNCF逐漸成為雲原生的最權威組織，並將雲原生技術推廣到世界各地。
這裡主要分成了幾個技術板塊，應用定義及部署(App Definition and Development)編排與管理(Orchestration & Management)運行環境(Runtime)配置(Provisioning)平臺(Platform)可觀測性和分析(Observability and Analysis)無服務(Serverless)這幾大板塊基本把雲原生技術所涉及領域都涵括進去了，下面詳細介紹下各板塊所涉及到的技術棧。從系統層次來看，從上到下分別是：應用層：應用定義及部署(App Definition and Development)、配置(Provisioning)、可觀測性和分析(Observability and Analysis)、無服務(Serverless)集群：編排與管理(Orchestration & Management)底層運行環境：運行環境(Runtime)
數據庫(Database)：應用層的數據庫，其中 PingCAP 公司推出的 TiDB 就是其中的佼佼者之一，其具有水平彈性擴展、分佈式事務等特性讓其和雲原生應用理念天然的契合。流式處理和消息隊列(Streaming and Messaging)：常用的消息隊列有kafka、NATS、RabbitMQ等，常用的應用系統中也用的比較多。流式處理有Spark streaming、storm、flink等，都是常用的大數據流式計算框架。應用定義和鏡像構建(App Definition and Image Build)：雲原生的應用構建一般由於一堆 YAML 文件組成，為了能更靈活的生成和打包管理這些配置定義文件，我們需要一些工具，而 Helm 就是k8s應用比較多的一種應用程序 Chart 的創建、打包、發佈以及創建的軟件包管理工具。持續集成與持續部署(Continuous Integration and Continuous Delivery)：持續集成和持續部署是一種基於敏捷開發提出的開發工具，由於敏捷開發中要求要以快步小走的方式進行迭代，為了節約測試、部署時間週期，必須需要一個能做到和代碼管理進行結合的自動化測試和部署工具，而這就是持續集成和部署（簡稱CI/CD）。常用的CI/CD工具有Jenkins、Travis CI、gitlab runner等。
TiDB算得上比較正宗的雲原生數據庫，其採用了計算和存儲節點分離的方式，TiDB 具有水平擴展和高可用特點，這裡簡單大家介紹下 TiDB 的整體架構。TiDB 集群主要包括三個核心組件：TiDB Server，PD Server 和 TiKV Server。
PD ServerPlacement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個：一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 集群進行調度和負載均衡（如數據的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務 ID。PD 通過 Raft 協議保證數據的安全性。Raft 的 leader server 負責處理所有操作，其餘的 PD server 僅用於保證高可用。建議部署奇數個 PD 節點。
TiKV ServerTiKV Server 負責存儲數據，從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range（從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region。TiKV 使用 Raft 協議做複製，保持數據的一致性和容災。副本以 Region 為單位進行管理，不同節點上的多個 Region 構成一個 Raft Group，互為副本。數據在多個 TiKV 之間的負載均衡由 PD 調度，這裡也是以 Region 為單位進行調度。
TiSparkTiSpark 作為 TiDB 中解決用戶複雜 OLAP 需求的主要組件，將 Spark SQL 直接運行在 TiDB 存儲層上，同時融合 TiKV 分佈式集群的優勢，並融入大數據社區生態。至此，TiDB 可以通過一套系統，同時支持 OLTP 與 OLAP，免除用戶數據同步的煩惱。
容器編排與調度(Orchestration and Scheduling)：容器的編排和管理可以說是雲原生的基石，而 Kubernetes 可以說是這個領域的事實標準，作為 CNCF 基金會的首個畢業項目和金字招牌甚至很多人認為雲原生就是 k8s 和其相關的一系列技術，雖然這樣的說法是很不準確的，不過現在雲原生技術確實和k8s綁定的越來越緊密，由此而衍生了一大批的工具生態。一致性與服務發現(Coordination and Service Discovery)：各服務之間的協同以及服務發現是分佈式計算中的核心，分佈式架構作為雲原生的基礎特性之一可以說是不可或缺的功能組件，從大數據時代的老牌的Zookeeper到到Docker Swarm採用的Consul，再到k8s中集成的分佈式鍵值數據庫etcd和DNS服務發現CoreDNS都是其中的佼佼者。遠程調用服務(Remote Procedure Call)：廣義上的遠程調用一般分為兩種，一種基於HTTP協議，一種基於RPC，而狹義的遠程調用一般指的RPC。比較常用的RPC框架有 Google 開源的 gRPC和 Apache 旗下的 Thrift 框架，k8s是採用 gRPC 框架作為服務間調用。服務代理(Service Proxy)：平常用的最多的服務代理應該就是nginx了，作為一個高性能支持正向和方向代理的服務器, nginx具備成熟和廣泛的應用場景。envoy 則是一個新生的用go寫的服務代理，像Istio、Ambassador的服務代理就是採用了envoy，因此在雲原生應用中 envoy 也具備強大的生命力。API網關(API Gateway)：API網格主要起到對所有的API的調用進行統一接入和管理、認證、授權等功能。ambassador、traefik、kong等都是優秀的微服務網關。服務網格(Service Mesh)：服務網格是用於控制應用的不同部分之間如何共享數據，服務網格是內置於應用程序中的專用基礎架構層，用於記錄應用的不同部分是否能正常交互。服務網格可以更細粒度地為每個服務提供限流、管控、熔斷、安全等功能。Istio 是最流行的 Service Mesh 之一，其以易用性、無侵入、功能強大贏得眾多用戶青睞，相信不久將來應該有可能會成為服務網格的事實標準。
各種應用和工作負載逐漸運行在k8s之上，有個比喻特別好，就是k8s是雲原生的操作系統，而運行在k8s之上的容器應用就像電腦的app一樣
雲原生存儲(Cloud Native Storage)：隨著數據庫、消息隊列等中間件逐步在容器環境中得到應用，容器持久化存儲的需求也逐步增多，隨之而來的是建立一套基於雲原生的存儲系統，在k8s中對應的就是CSI——容器存儲接口。持久化存儲中用的比較多的是Ceph，作為一個分佈式存儲系統，Ceph提供較好的性能、可靠性和可擴展性。容器運行時(Container Runtime)：容器運行時就是指容器的運行環境，比如最常用的Docker。除了docker,還有一個比較著名的開源容器運行時標準組織（Open Container Initiative），簡稱OCI。OCI由Linux基金會於2015年6月成立，旨在圍繞容器格式和運行時制定一個開放的工業化標準，目前主要有兩個標準文檔：容器運行時標準 （runtime spec）和 容器鏡像標準（image spec），Containerd就是一個滿足OCI規範的核心容器運行時。雲原生網絡(Cloud Native Network)：容器的網絡方案，為容器集群提供一層虛擬化的網絡，像k8s的CNI就是其中一個標準的網絡接口，flannel是 CoreOS 公司主推的容器網絡方案，現在現在比較主流的一種網絡之一。
Kubernetes的分層架構：核心層：Kubernetes最核心的功能，對外提供API構建高層的應用，對內提供插件式應用執行環境應用層：部署（無狀態應用、有狀態應用、批處理任務、集群應用等）和路由（服務發現、DNS解析等）管理層：系統度量（如基礎設施、容器和網絡的度量），自動化（如自動擴展、動態Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）接口層：kubectl命令行工具、客戶端SDK以及集群聯邦生態系統：在接口層之上的龐大容器集群管理調度的生態系統，可以劃分為兩個範疇Kubernetes外部：日誌、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等Kubernetes內部：CRI、CNI、CVI、鏡像倉庫、Cloud Provider、集群自身的配置和管理等
自動化與配置(Automation & Configuration)：用於自動化部署和配置容器運行平臺和環境，代表工具包括Ansible、Chef、Puppet、VMware、OpenStack。容器註冊(Container Registry)：容器註冊是整個CNCF雲原生中的重要部件，因為基於容器的運行環境中，所有的應用都需要藉助容器鏡像庫來進行安裝和部署。容器註冊工具主要分公有工具和私有工具，公有的容器鏡像庫主要包括docker官方的registry，在私有鏡像庫最著名的是Harbor，目前市面上大量的容器平臺目前都基於Harbor構建其鏡像倉庫。安全與合規性(Security & Compliance)：安全性和合規性基本是所有系統都會面臨的東西，Notary和TUF是這個領域兩個主要的項目，其中TUF是一個開源的安全標準，Notary是其中一個實現。密鑰管理(Key Management)：秘鑰管理做權限管理和身份認證，比如雅虎發佈的athenz，就是一個基於RBAC的權限管理和配置。SPIFFE通用安全身份框架提供了統一的工作負載身份解決方案。
監控(Monitoring)：監控主要是對運行系統和應用的狀態進行觀測與預警，常用的監控有Prometheus、Zabbix等，Grafana通常會配合Prometheus做圖形化的展示。日誌(Logging)：日誌採集模塊，如ELK(elastic/logstash/kibana)、fluentd等。追蹤(Tracing): 這裡的tracing是指分佈式鏈路追蹤，因為在分佈式系統中，各服務之間相互調用，一個地方出問題可以會導致很多其他服務上的組件出現連鎖問題，因此在定位問題的時候十分困難，必須要建立分佈式鏈路追蹤來對錯誤和故障進行定位，分佈式跟蹤是對日誌和監控指標的重要補充。OpenTracing 是一套分佈式系統跟蹤標準協議，為大家建立一套統一的標準來實現分佈式跟蹤信息的描述和傳遞。混沌工程(Chaos Engineering)：混沌工程主要是解決在高複雜性的分佈式系統之上建立起值得信任的生產部署體系，比如服務不可用時後備設置不當 ; 因超時設置不當導致反覆重試 ; 下游依賴關係在接收到大量流量時出現中斷 ; 發生單點故障時連鎖引發後續問題等一系列混亂的難題，建立受控實驗觀察分佈式系統。
混沌工程類似於“故障演練”，不侷限於測試，而更像是工程實踐。為什麼這麼說，通常的測試用例會有“期望結果”和“實際結果”，通過將兩個結果比較，或者對用戶行為的預期，來判斷測試通過或失敗。而混沌試驗類似於”探索性測試“，試驗本身沒有明確是輸入和預期結果，通過對系統和服務的干預，來觀察系統的”反應“。我們將混沌工程原則融入在試驗過程中：在生產環境小規模模擬系統故障並定期自動化執行試驗，通過試驗結果與正常結果進行比對，觀察系統”邊界“。引入混沌實踐時需要了解混沌工程的五大原則。1）建立穩定狀態的假設在做混沌工程實驗的時候，首先得確定需要測試的指標已經做了高可用的工作，才能進行驗證指標對業務的是否有影響。如果沒有做好高可用工作，而引入混沌工程實驗的話，對業務而言將會是一聲災難。2）多樣化現實世界事件不能夠憑空想像出一些事件來驗證，而是引入那些真實存在的，頻繁發生的，且影響重大的事件。對我們而言給這些事件做混沌實驗才具有價值。如磁盤故障、網絡延時、主機宕機等。3）在生產環境運行實驗儘量在類生產環境中進行測試，生產環境的多樣性是任何其它環境無法比擬的。混沌工程的價值就是保證生產上的業務連續不中斷。4）持續自動化運行實驗實施混沌工程實驗一般最開始是人工手動操作，當我們對業務有足夠的信心時，要把混沌實驗做成持續自動化。在版本升級、不斷迭代的過程中，持續不斷自動化地做驗證，最大程序保證業務的連續性驗證。5）最小化影響範圍做混沌工程的意義就是保證生產上的業務。在我們實施混沌實驗時也必須保證對線上業務影響最小。在實施實驗時，從小範圍開始，不斷擴大範圍，避開高風險時段，如選擇業務量最小的時候實施實驗。
工具(Tools)：一些工具集，，比如CNCF的landscape作為一個信息聚合網站可以用於查看各種新的軟件工具、Dashbird可以用於serverless監控和故障排查工具。安全(Security)：主要提供serverless的安全防護。框架(Framework)：指直接用於構建、管理serverless應用的框架，比如Apex可以用於構建、發佈和管理AWS Lambda，SAM 一個Python的開源serverless應用構建框架。註冊平臺(Hosted Platfrom)：指提供第三方註冊的廠商服務，比如AWS的Lambda、阿里雲的函數計算服務、Google的cloud functions服務等。可安裝平臺(Installable Platform)：這裡就是用於自己搭建serverless平臺的工具，比如著名的Knative，就是由谷歌開源的 serverless 架構方案。
Serve在這裡非常重要，它實際上是一種帶有內置Istio的組件。Istio提供了許多功能 ，例如流量管理、智能路由、自動縮放和縮放到零等，這是一個非常酷的概念。但實際上，對於非服務器應用程序，開發者希望的是可以擴展到1000個數據包，並且當沒有人訪問時，將其恢復為0。那麼，讓我們看看Knative Serve 是如何工作的。首先，在啟動一個傳統的microservice或function後，該服務指向並管理兩個不同的事物：1）Route 2）Config。Knative Serve為我們提供了快照，提供了智能的、可拓展的路由。使用Istio流量管理功能，實際上可以通過Route管理所有流量，並將它們路由到新舊兩個版本中的一個或多箇中，我們可以這麼假設，如所有流量的10％被路由到版本2，90％停留在版本1上。
閱讀更多 機械視角 的文章
