2015年，Google牽頭創立了CNCF(Cloud Native Computing Foundation)，同年，CNCF 發佈了其標誌性作品——Kubernetes 1.0。由此，圍繞 CNCF 又產生了許多很有價值的雲原生項 目。CNCF 獨立維護了一個全景圖項目，該項目發佈非常頻繁，截止到本書寫作時，其最新版 本是 0.9.9。大家可以在 GitHub 上查看相關內容。
如圖所示，在 CNCF 全景圖中，雲原生的生態圈在橫切面上被劃分爲五層，同時在縱 切面上又規劃出兩部分作爲共用層。五層分別是應用定義與開發層、編排與治理層、運行時層、 供應保障層和雲設施層。另外兩部分是觀察與分析、平臺。將這些功能整合起來就是一個完善 的雲平臺服務產品。
圖中所含信息量巨大，無法看清細節，下面我們就層層遞進地來仔細解讀一下 CNCF 全景圖。首先來看看橫切面五層中每層涵蓋的內容。
應用定義與開發層
應用定義與開發層中的內容對於有經驗的技術人員來說是比較熟悉的。無論是否要開發基於雲原生的應用，這些內容都是開發和運維的基礎，與傳統開發模式並無二致。
應用定義與開發層包括數據庫與數據分析、流式處理、軟件配置管理、應用定義以及持續 集成/持續交付，下面分別來看。
1.數據庫與數據分析
圖 1-15 展示了 CNCF 應用定義與開發層中數據庫與數據分析部分的內容。
這部分主要包括數據庫與大數據分析工具，涉及關係型數據庫、NoSQL、NewSQL、數據庫中間層以及大數據處理方案。
基於 SQL 操作的關係型數據庫主要包括 Oracle、SQL Server、MySQL、PostgreSQL、DB2、 MariaDB 等。雖然各種新型數據庫層出不窮，但關係型數據庫的存儲引擎畢竟經歷了數十年的 打磨，又有經典的 ACID 事務模型作爲支撐，因此它作爲核心數據存儲選型的地位不可撼動。 針對關鍵業務，大部分企業依然傾向於採用關係型數據庫進行存儲，如存儲交易數據、訂單信 息等。數據庫本身的穩定性、SQL 的查詢靈活度、開發工程師的熟悉程度以及數據庫管理員的 專業度等，共同形成了關係型數據庫的強大生態圈，使得關係型數據庫始終是格式化數據存儲 行業最優先的選擇。
作爲關係型數據庫的有效補充，NoSQL 數據庫在數據存儲領域也佔據重要地位，常用的有 MongoDB、Couchbase、Redis、Cassandra、HBase、Neo4j 等。面向文檔、面向列簇、面向 Key-Value、 面向圖等的 NoSQL 數據庫在數據的分佈式處理方面表現得更加優秀，編程模型也更加貼近面 向對象原有的方式，雖然查詢的靈活度遠不如 SQL，但在特定場景中的性能、對面向對象的原 生存儲能力、無 Schema 模式等方面都做得很不錯，因此在適合的業務場景下，NoSQL 數據庫 也大有用武之地。比如，將 Redis 當作緩存，將 Neo4j 當作關係分析的數據庫，將 MongoDB 當 作存儲 Schema 易變型數據的數據庫，這些都是很常見的使用方式。
NewSQL 數據庫目前是新一代數據庫的焦點，是顛覆關係型數據庫統治地位的有力競爭者。它在兼容 SQL 的同時，更加擅長分佈式處理。其中的優秀代表是 PingCAP 開源的 TiDB。
TiDB 採用 Key-Value 存儲引擎，採用不同於 ACID 的強一致分佈式事務，可動態平滑地進 行數據遷移，自動水平伸縮，也可以在線修改 Schema，進行索引變更，是完整的數據存儲方案。 但新的存儲引擎的成熟度畢竟還需要時間來檢驗，而且“無須專業數據庫管理員運維”的理念 也需要時間來讓更多的企業接受。因此，願意嘗試的公司仍然秉持“關係型數據庫和 NewSQL 數據庫共用”的較爲謹慎的態度。隨着時間的沉澱，相信 NewSQL 的前景會越來越光明。
大數據處理方案用在離線或準實時的計算大數據的技術棧中，如 Hadoop、Spark、Druid 等。 這裏的 Druid 不是指阿里巴巴開源的數據庫連接池，而是一個用於大數據實時處理的分佈式系統。
以 Map/Reduce 聞名的 Hadoop 體系，將計算任務抽象成 Mapper 和 Reducer 的編程模型， 能夠通過分佈式手段在由成百上千臺 PC 服務器組成的不完全可靠的集羣中併發處理大量的數 據集，並且將分佈式和故障恢復等實現細節隱藏起來。它將數據處理過程分解爲多個包含 Mapper 和 Reducer 的作業，將這些作業放入集羣執行，並最終得出計算結果。但由於 Map/Reduce 任務將中間結果存入 HDFS 文件系統，因此延時較長，只適合高吞吐和大批量的數據處理場景， 無法滿足交互式數據處理的需要。
以 RDD(Resilient Distributed Dataset)作爲計算模型的 Spark，提供了一個供集羣使用的分 布式內存。在 Spark 中，RDD 轉換操作後會生成新的 RDD，而新的 RDD 數據仍然依賴於原來 的 RDD。因此，程序構造了一個由多個相互依賴的 RDD 組成的 DAG(有向無環圖)，並將其 作爲一個作業交由 Spark 執行。由於每次迭代的數據並不需要寫入磁盤，而可以保存在內存中， 因此 Spark 的性能較 Hadoop 有很大提升。
2.流式處理
流式處理所包含的內容如圖 1-16 所示。
流式處理包括消息中間件以及流式實時計算框架。
消息中間件用於異步化和解耦系統依賴，如 RabbitMQ 和 Kafka，未上榜的還有老牌消息中 間件 ActiveMQ，以及國產的優秀消息中間件 RocketMQ 等。由於存儲引擎不同，ActiveMQ、 RabbitMQ 這種可以基於消息索引查詢的消息中間件，功能雖然完善，但分佈式能力和性能不盡 如人意。Kafka 以及早期的 RocketMQ 採用日誌追加的存儲引擎，因此分佈式能力和性能大幅 提升，但自身對於消息的控制能力有限。新一代的 RocketMQ 以及阿里巴巴隨之孵化的 OpenMessaging，正在努力平衡和兼容兩種流派的消息中間件。
流式實時計算框架包括 Strom、Flink 等，相較於 Hadoop 這樣的離線計算體系，這類框架 更加關注實時性。Storm 與 Flink 都是將輸入流進行轉換和計算，並將結果作爲輸出流傳輸至下 一個計算節點的。對於實時統計 PV、UV 等需求，採用流式實時計算框架來實現是不錯的選擇。
3.軟件配置管理
軟件配置管理即SCM(Software Configuration Management)，它通過執行版本控制來保證 所有代碼和配置項變更的完整性和可跟蹤性。在源代碼版本控制工具領域，老牌的 SVN 已是明 日黃花，將會逐漸退出歷史舞臺，取而代之的是 Git，Git 已是當前的行業標準。Git 的出現使得 源代碼版本控制工具升級爲分佈式工具，進而愈加受到青睞。
GitLab 使用 Git 作爲其源代碼版本控制工具，在管理源碼的同時可以提供便捷的 Web 服務， 在成爲代碼託管服務平臺的同時還可以通過安裝配置各種插件完成代碼評審、代碼質量檢查等 工作。企業一般都使用 GitLab 來搭建自己的軟件配置管理系統。
對於個人開發者、開源項目負責人、企業付費用戶來說，推薦採用 GitHub 來管理源代碼， 世界頂級公司大多將頂級開源項目源碼託管在 GitHub 上。
由開源中國搭建的碼雲同樣採用 Git 作爲其源代碼管理工具，它在國內的訪問速度優於 GitHub，更加符合國人的使用習慣，也是非常優秀的源碼管理平臺。
4.應用定義
對於熟悉 Java 技術棧的工程師來說，圖 1-14 中可能沒有特別熟悉的產品。其實，Java 中 的 Maven 就屬於該範疇，它由於功能穩定、周邊生態多元化，因此成爲業界的主流，也是 Java 用於編譯打包和依賴管理的首選。Maven使用項目對象模型(Project Object Model)聲明和管 理項目的生命週期和應用依賴，並且可以自定義插件開發方式。大量的第三方插件使得 Maven 的應用場景被無限擴大，比如，代碼靜態檢查、代碼風格評審、測試覆蓋率計算等都會用到 Maven。
5.持續集成/持續交付
持續集成是指自動且持續不斷地構建和測試軟件項目並監控其結果是否正確。有了持續集 成工具的支持，項目可以頻繁地將代碼集成到主幹位置，進而使得錯誤能夠快速被發現。它的 目的是讓產品在快速迭代的同時還能保持高質量。持續集成並不能消除 Bug，但是它能讓 Bug 被快速發現並且容易被改正。
持續交付是指頻繁地將應用的新迭代版本交付給測試團隊或最終用戶以供評審，如果評審通過，則自動部署至生產環境。持續交付的中心思想是，無論應用如何更新，它都可以隨時隨地交付並自動化部署。
常見的持續集成/持續交付工具有 Jenkins、Bamboo、CircleCI、Travis 等。 上面講到的軟件配置管理、應用定義、持續集成/持續交付三個部分的內容如圖 1-17 所示。
應用定義與開發層的變動非常頻繁，之前 CNCF 將開發語言、開發框架等都納入這一層， 但從 0.9.6 版本起，新的全景圖卻將這些內容全部刪除了。原因大概是 CNCF 認爲這些內容屬於業務開發範疇，雲原生無須關注。因此，無論選擇 Java 還是 PHP 進行開發，也不管使用 Spring 還是 Play 搭建架構，都可能開發出契合雲原生的應用，也可能開發出不契合雲原生的應用。
編排與治理層
將應用框架的分佈式治理與雲原生所需的調度、編排等功能抽象出來，形成獨立的一層， 即編排與治理層，如圖 1-18 所示。這種劃分方式使業務開發工程師對雲原生的瞭解更準確，雲 原生中間件工程師也無須過多關注業務。相對來說，CNCF 的產品更多地集中在這一層，這是 雲原生產品比較容易發力的部分。
這一層包括調度與編排、分佈式協調與服務發現、服務管理。下面我們具體來看一下每個部分涉及的內容。
1.調度與編排
調度與編排提供了面向應用的容器集羣部署和管理功能，目的是解耦 CPU、GPU、內存、 網絡以及存儲等基礎設施與應用程序間的依賴，使開發人員將重點完全放在覈心業務應用的研 發上，而不必操心資源管理的問題，同時也使運維人員將重點放在硬件基礎設施以及操作系統 和網絡本身的維護上，而不必操心資源利用率最大化的問題。調度與編排負責按照預定的策略 將承載着應用的容器調度到擁有相應運行資源的執行服務器中。除了 CNCF 的核心成員 Kubernetes，Mesos、Swarm 也屬於此範疇。
雖然調度與編排同屬一部分，但它們負責的內容並不相同，調度是將分佈式系統中的閒置資源合理分配給需要運行的進程並採用容器進行封裝的過程，編排則是對系統中的容器進行健康檢查、自動擴縮容、自動重啓、滾動發佈等的過程。
Mesos 採用兩級調度架構，因此能將調度和編排分離得比較徹底。由 Mesos 自身負責資源 的調度，由運行在 Mesos 系統中的 Marathon 進行容器的編排。
調度與編排是雲原生中最基礎的需求，其中包含的內容如圖 1-19 所示。
2.分佈式協調與服務發現
分佈式場景由於網絡的延遲以及不確定性，因此複雜度非常高。分佈式系統一般都是通過一個可靠性非常高的註冊中心對分佈式服務進行協調與發現的。註冊中心需要確保數據在分佈式場景下的一致性，並且能夠將分佈式集羣的狀態變化及時通知給每個分佈式節點。
在很多分佈式系統中，我們都可以看到分佈式協調和服務發現的身影，如 Hadoop、Kafka、 Dubbo中的ZooKeeper，Spring Cloud中的Eureka，Swarm中的Consul，其他常見的產品還有 CNCF 的項目 CoreDNS，以及負責 Kubernetes 元數據存儲的 etcd。雖然 etcd 並未在 Kubernetes 中扮演分佈式協調和服務發現的角色，但它可以作爲註冊中心提供這方面的能力。分佈式協調 與服務發現中包含的內容如圖 1-20 所示。
3.服務管理
如同編排與調度是雲原生的基礎需求一樣，服務管理是雲原生的另一個重要基礎，也是 CNCF 的重點關注點之一。服務管理的產品主要集中在三個方面:遠程通信、反向代理、服務治理。
服務間的遠程通信需要依託高性能和跨語言的通信框架，gRPC、Thrift、Avro 等跨語言框 架集序列化和通信功能於一身，是分佈式系統的重要基石。
關於反向代理的產品目前已經非常成熟，有涉及硬件的 F5，涉及軟件的 HAProxy、Nginx 等。它們負責承載入口流量，並將請求按照規則配置分發給相關的系統。
在服務治理方面，也已經有很多成熟的框架可以使用，如 Netfix OSS 負責網關的 Zuul、負責客 戶端負載均衡的Ribbon、負責熔斷的Hystrix等，它們也是Spring Cloud開發套件中的重要組成部 分。由 Twitter 開源的用 Scala 語言開發的 Finagle，以及國內非常流行的 Dubbo，也屬於此範疇。
在服務治理方面，業界新興的Service Mesh概念正在漸漸被更多人認同，它的中文翻譯爲 服務網格。Linkerd 和 Istio 是這方面的代表，由於技術實在太新，目前還處於快速發展時期。 其中 Linkerd 和 Istio 的通信底層組件 Envoy 都已加入 CNCF。Istio 是與英文 sail 對應的希臘文 單詞，中文則是“航行”的意思，它與 Kubernetes 一脈相承，Kubernetes 同爲希臘文，是“舵 手”的意思。除了 Envoy，Linkerd 也實現了 Istio 的接口並提供了底層通信能力。因此，Kubernetes 掌控編排，Istio 掌控服務治理，雲原生的未來秩序已逐漸清晰。
值得一提的是，Kubernetes 也內置了服務管理的功能，它們並未從 Kubernetes 的核心中抽 離出來。Kubernetes使用Service和Ingress處理服務發現和負載均衡。未來的Service Mesh是 否能夠從 Kubernetes 中將服務治理完全接管過來，這將是一個值得關注的重點。
服務管理中包含的內容如圖 1-21 所示。
運行時層
雲原生的應用並不直接運行在物理服務器或傳統的虛擬機之上，通常爲了運行雲原生應用，會在物理服務器或傳統的虛擬機之上再構建一層，用於輕量和靈活地運行更多的實例。
雲原生應用的運行時環境與傳統應用的運行時環境有很大不同，但是它們的抽象層級是類 似的，與傳統應用的文件系統、進程以及網絡環境相對應的是雲原生存儲、容器和雲原生網絡。 運行時層包含的內容如圖 1-22 所示，下面我們具體來看一下每個部分涉及的內容。
1.雲原生存儲
雲原生存儲是指適合雲服務的分佈式文件存儲系統，它能將運行在雲平臺上的應用所需的 或產生的數據放入一個可以不依賴本地磁盤且可以平滑擴容的高可靠文件系統，典型的產品有 HDFS、Ceph、ClusterFS 等。
雲原生存儲與專門用於存儲業務數據的數據庫並不是一個概念，目前很少有將數據庫安裝 在雲原生存儲上的成熟方案。雲原生存儲目前最廣泛的應用途徑是存放日誌、圖片、文檔等文 件。雲原生存儲中包含的內容如圖 1-23 所示。
2.容器
容器是過去幾年的熱門話題。雲原生應用選擇容器這種更加輕量級的方案作爲運行應用的載體，將容器作爲最小單元對應用進行資源隔離以保證雲平臺的隔離性，並且通過容器打包環境和應用來提供更易複製的部署方式。不過需要注意的是，Kubernetes 採用 Pod 作爲應用的最 小單元，一個 Pod 內可以包含多個容器。Docker 是目前使用最廣泛的容器，業界也有 rkt 等替 代方案。關於容器，其中包含的內容如圖 1-24 所示。
3.雲原生網絡
雲原生網絡可以解決爲每個容器(或 Pod)分配獨立 IP 地址的問題。若採用和宿主機一樣 的 IP 地址，運行在同一個宿主機中的容器 IP 地址則會發生衝突。雖然可以通過改造應用程序 來屏蔽對 IP 地址的依賴，但爲了使應用透明化，令每個容器都擁有一個獨立的 IP 地址纔是上 策。爲了實現這一點，使用軟件定義網絡(SDN)是最佳方案。
雲原生網絡比較複雜，各種網絡方案也層出不窮，因此產生了 CNI(Container Network Interface)這樣的容器網絡接口標準，它的主要實現有 Flannel、Calico、OVS、weave 等。雲原 生網絡包含的如容見圖 1-25 所示。
供應保障層
供應保障層包括宿主機管理工具、基礎設施自動化工具、容器倉庫、鏡像安全和密鑰管理， 如圖 1-26 所示，這一層用於爲宿主機和容器本身提供保障，它的關注點更加偏向於運維。下面 我們來具體看一下其中的每個部分。
1.宿主機管理工具
雖然雲原生應用運行在一個相互隔離的由調度系統掌控的容器環境中，但它們最終仍然是 運行在真正的物理服務器或虛擬機之上的。因此，我們需要通過管理工具將 Docker、Kubernetes、 Mesos、etcd、ZooKeeper、Flannel 等衆多運行時所需環境和工具自動安裝和配置在應用運行的 宿主機上。
原有的自動化運維工具在這裏仍然有用武之地，它們無須再安裝複雜的軟件應用環境，只 搭建容器運行環境和編排調度平臺即可，這類工具包括 Ansible、Puppet、Chef 等。自動化運維 工具的目標不再是安裝應用及其相關環境，而是安裝雲原生應用所需的環境。
2.基礎設施自動化工具
對於雲原生的系統來說，調度編排平臺即基礎設施。基礎設施自動化工具的用途是爲調度 編排平臺安裝插件。常見的相關工具有 Docker 的包管理工具 Infrakit，以及簡化 Kubernetes 應 用的部署工具Helm。Helm可以看作Kubernetes的apt-get或yum，它通過Helm Charts幫助使 用者安裝和更新複雜的 Kubernetes 應用，支持版本管理和控制，這在很大程度上降低了 Kubernetes 應用部署和管理的複雜性。
宿主機管理工具與基礎設施自動化工具有類似之處，都屬於系統軟件安裝的範疇，它們包 含的內容如圖 1-27 所示。
3.容器倉庫
容器倉庫負責容器鏡像內容的存儲與分發。Docker Registry 是 Docker 的核心組件之一，客 戶端的 docker pull 以及 docker push 命令都與它交互。Harbor 是一個比較知名的項目，它的目 標是幫助用戶迅速搭建一個企業級的 Docker Registry 服務。
4.鏡像安全
安全漏洞一直存在於程序世界。升級爲容器之後，此類安全威脅仍然存在，因此我們需要 一個能夠發現容器中可能存在的安全問題的工具，如 Clair、Twistlock 等工具均可以檢查容器中 應用的漏洞。
供應保障層中還包含一個密鑰管理的部分，是新加入 CNCF 的部分，筆者並不是很熟悉， 因此不做詳細介紹。以上三個部分的內容如圖 1-28 所示。
雲設施層
雲設施層主要包括用於提供物理服務器的雲廠商，如圖 1-29 所示。
按照公有云和私有云來分，常見的公有云有 AWS、Azure、阿里雲、騰訊雲、華爲雲等， 常見的私有云有 OpenStack、VMware 等。嚴格來講，這一層其實並不在 CNCF 的範疇內，它們僅用於提供服務所需的資源。
下面再介紹一下另一個維度下的雲原生應用。觀察與分析是每一層都需要的功能，平臺則是將每一層功能組合起來的整體解決方案。
觀察與分析
觀察與分析包括對系統指標的監控，對鏈路調用的追蹤，以及對分佈式日誌的收集。除了收集相關數據，還能夠通過對這些數據進行解讀，將系統當前狀態以易懂的可視化圖形形式展現出來，以便運維工程師掌控整個系統。
1.監控
監控部分包括以下內容:對物理服務器指標進行採集與報警的工具，如 Nagios、Zabbix 等; 對容器指標進行採集的工具，如 CAdvisor 等;存儲海量採集信息的時間序列數據庫，如 Prometheus、InfluxDB 等。監控部分的具體內容如圖 1-30 所示。
監控往往通過“採集、存儲、分析、報警(展現)”的流程自動將系統狀態通知給系統責任 人，令其處理或定期分析。一般可以採用 Grafana 等專門用於監控分析的圖形工具來展示數據。
2.日誌
由於雲原生應用是無狀態的，因此不應該將日誌寫入本地磁盤，而是應該寫入日誌中心。 用於採集標準輸出並將日誌輸入其他流的工具主要有 Fluentd、Flume、FileBeat、Logstash 等， 然後這些工具會將日誌通過各種緩衝的管道進行處理，寫入日誌中心，日誌中心的存儲介質可 以是 Elasticsearch、HBase 等。Elastic 公司提供的由搜索引擎 Elasticsearch、日誌收集工具 Logstash 和圖形界面 Kibana 所組成的日誌中心套件(簡稱 ELK)是一站式的開源解決方案，也有如 Splunk 這樣的一體化商業日誌解決方案。
3.追蹤
雲原生應用運行實例多，應用調用複雜，因此一旦系統響應變慢，便會難以定位問題。因 此需要提供一套梳理和分析服務之間調用鏈以及服務內部調用棧的解決方案。OpenTracing 是調 用鏈的一個標準協議，遵循該協議的開源解決方案主要有 ZipKin、JAEGER，以及國產的優秀 開源項目 SkyWalking 等。也有一些開源解決方案並未遵循此協議，如 PinPoint、Open-Falcon、 CAT等。
平臺
基於雲的整合平臺是目前各個雲公司都着力打造的產品，比較知名的有 Mesosphere 公司圍 繞 Mesos 打造的 DC/OS，以及 Rancher 公司打造的可以整合 Mesos 和 Kubernetes 的 Rancher 平臺等。
上面提到的技術只是整個雲原生技術的冰山一角，無論是開源產品還是商業產品，優秀的 解決方案非常多。雲原生可以有不同的實現方式，但它的本質在於彈性地利用雲平臺的資源。 無論是通過“應用程序 + 分佈式中間件 + 自動化運維”的方式，還是通過“應用程序 + 調 度編排平臺 + 容器 + 服務治理”的方式，都可以實現健壯的系統。
相關文章：
架構新紀元（一）：從分佈式架構到雲原生架構
本文節選自圖書《未來架構：從服務化到雲原生》第一章。本書對快速演進中的雲原生數據架構、典型分佈式數據庫中間件進行了剖析，重點介紹 Service Mesh 等新興概念，創新性地提出了 Database Mesh 的理念，深度揭祕 Apache 項目——ShardingSphere。
購買鏈接： https://u.jd.com/sbmG4Y
作者簡介：
張亮
京東數科數據研發負責人，Apache ShardingSphere 發起人兼 PPMC 成員。熱愛分享，擁抱開源，主張代碼優雅化，擅長以 Java 爲主的分佈式架構以及以 Kubernetes 和 Mesos 爲主的雲平臺的構建。ShardingSphere 已進入 Apache 軟件基金會，是京東集團首個進入 Apache 的開源項目，也是 Apache 首個分佈式數據庫中間件。
吳晟
Apache SkyWalking 創始人及 PPMC 成員，Apache ShardingSphere 原型作者及 PPMC 成員，Apache Zipkin 貢獻者，Apache 孵化器導師，CNCF 基金會 OpenTracing 標準化委員會成員，W3C Trace Context 規範貢獻者。擅長分佈式架構、性能監控與診斷、分佈式追蹤、雲原生監控等領域。
敖小劍
具有十七年軟件開發經驗，資深碼農，微服務專家，Cloud Native 擁護者，敏捷實踐者，Service Mesh 佈道師，ServiceMesher 中文社區聯合創始人。專注於基礎架構建設，對微服務、雲計算等相關技術有着深入研究和獨到見解。
宋淨超
螞蟻金服雲原生布道師，ServiceMesher 中文社區聯合創始人，Kubernetes 社區成員，Istio 社區成員，《Cloud Native Go》《Python 雲原生》《雲原生 Java》等圖書譯者。