騰訊大牛深入淺出詳解雲原生

• 2020 年 2 月 14 日
• 筆記

| 作者：王珏，騰訊雲數據庫高級研發工程師，主要負責騰訊雲MySQL數據庫、數據庫中台等研發工作。

本文介紹目前業界非常火熱的「雲原生（CloudNative）」相關知識結構，包括微服務、DevOps、持續交付、服務網格、Serverless等相關知識點。「雲原生」通過提供一套完整的技術體系和方法論來指導我們在雲環境下，在系統功能越來越複雜的情況下，還能夠做到敏捷開發並保證系統可用性。

1

雲原生產生背景

隨着雲計算平台的成熟和分佈式框架的普及，應用上雲已經是不可逆轉的趨勢，未來應用會分成兩種，一種是「構建雲」的，另一種是「基於雲構建」的應用。

真正的雲化不僅僅是基礎設施和平台的變化，應用也需要做出改變，擯棄傳統的土方法，在架構設計、開發方式、部署維護等各個階段和方面都基於雲的特點重新設計，從而建設全新的雲化的應用，即雲原生應用。

在雲環境下怎樣保證在應用程序越來龐大、功能越來越複雜的情況下，還能夠做到敏捷開發並保證可用性呢？雲原生有一套完整的體系和方法論。

1

何謂雲原生？

雲原生是一種構建和運行應用程序的方法，是一套技術體系和方法論。雲原生（CloudNative）是一個組合詞，Cloud+Native。

Cloud表示應用程序位於雲中，而不是傳統的數據中心；

Native表示應用程序從設計之初即考慮到雲的環境，原生為雲而設計，在雲上以最佳姿勢運行，充分利用和發揮雲平台的彈性+分佈式優勢。

不同的人和組織對雲原生有不同的定義，相同的人和組織在不同時間點對雲原生也有不同的定義：

• 2013年，Pivotal公司的Matt Stine首次提出雲原生（CloudNative）的概念；
• 2015年，Matt Stine在《遷移到雲原生架構》一書中定義了符合雲原生架構的幾個特徵：12因素、微服務、自敏捷架構、基於API協作、扛脆弱性；
• 2017年，Pivotal最新官網對雲原生概括為4個要點：DevOps+持續交付+微服務+容器；
• 2018年，CNCF又更新了雲原生的定義，把服務網格（Service Mesh）和聲明式API給加了進來；

可以簡單的理解為：

雲原生 = DevOps+持續交付(Continuous Delivery)+微服務(Micro Services)+敏捷基礎設施(Agile Infrastructure)+12要素(The Twelve-Factor App)+服務網格（Service Mesh）+聲明式API。

雲原生不但包括根據業務能力對公司進行文化、組織架構的重組與建設，也包括方法論與原則，還有具體的操作工具。採用基於雲原生的技術和管理方法，可以更好地把業務生於「雲」或遷移到雲平台，從而享受「雲」的高效和持續的服務能力。

雲原生範疇：

雲原生與傳統應用有比較明顯的區別，雲原生更倡導敏捷、自動化、容錯，而傳統應用則大多還處於原生的瀑布開發模型和人工運維階段。

雲原生應用和傳統應用的區別：

1. 敏捷基礎設施

敏捷的不可變基礎設施交付類似於IaaS，用來提供計算網絡存儲等基礎資源，這些資源是可編程且不可變的，直接通過API可以對外提供服務。

開發運維同學可以通過代碼或者配置來定義一組基礎設施，並通過版本化的管理能夠保證業務的快速變更，開發人員可以隨時拉取一套基礎設施來服務於開發、測試、聯調和灰度上線等需求。

最佳實踐：docker+kubernetes+雲資源（雲服務器，雲數據庫、雲存儲等）。

kubernetes作為雲原生生態的基石，可以說「Kubernetes是雲原生時代的Linux」，CNCF整個技術棧都是圍繞k8s建立，它不僅是解決了容器的編排問題，更進一步可以說對雲原生應用提供了定義規範，通過kubernetes可以很方便的拉取一套基礎設施用戶開發，測試、發佈。

2. 持續交付

為了滿足業務需求頻繁變動，通過快速迭代，產品能做到隨時都能發佈的能力，是一系列的開發實踐方法。分為持續集成、持續部署、持續發佈等階段，用來確保從需求的提出到設計開發和測試，再到讓代碼快速、安全地部署到產品環境中。

最佳實踐：

CI/CD, Jenkins，流水線pipeline

3. DevOps

DevOps如果從字面上來理解只是Dev（開發人員）+Ops（運維人員），實際上，它是一組過程、方法與系統的統稱；

DevOps強調的是如何通過自動化的工具協作和溝通來完成軟件的生命周期（開發，測試，運維）管理，從而更快、更頻繁地交付更穩定的軟件。

最佳實踐：Git，Jenkins，Bamboo，Docker，Kubernetes

4. 12要素

「12要素」英文全稱是The Twelve-Factor App，最初由Heroku的工程師首次提出並開源，並由眾多經驗豐富的開發者共同完善。

它定義了一個優雅的互聯網應用在設計過程中，需要遵循的一些基本原則，可看做雲原生應用開發的「十二條軍規」。

那具體有哪十二原則呢，見下圖：

1）基準代碼

每一個部署的應用都在版本控制代碼庫中被追蹤，一份代碼，可部署在多個環境。

在雲計算架構中，所有的基礎設施都是代碼配置，即Infrastructure as Code（IaC），整個應用通過配置文件就可以編排出來，而不再需要手工的干預，做到基礎服務也是可以追蹤的。

最佳實踐：git代碼管理

2）依賴

應用程序不會隱式依賴系統級的類庫，通過依賴清單聲明所有依賴項，應用可以很清晰地對部署環境公開和隔絕依賴性，而不是模糊地對部署環境產生依賴性。

最佳實踐：Maven、Go Modules

3）配置

配置與代碼分離，代碼中不能出現運行時依賴的配置，通過運行時環境獲取配置，根據不同的環境配置運行在不同的環境中

最佳實踐：配置中心化

4）後端服務

不用區別對待本地或第三方服務，統一把依賴的後端作為一種服務來對待，比如在雲架構的基礎服務中，計算、網絡、存儲資源都可以看作是一種服務去對待使用即可，不用區分是遠程還是本地的。

最佳實踐：API、雲函數、serverless

5）構建、發佈、運行

應用嚴格區分構建，發佈，運行這三個階段。舉例來說，直接修改處於運行狀態的代碼是非常不可取的做法，因為這些修改很難再同步回構建步驟。

雲原生應用的構建流程可以把發佈配置挪到開發階段，包括實際的代碼構建和運行應用所需的生產環境配置。

在雲原生應用中，基於容器的Build-Ship-Run和這三個階段完全吻合，也是Docker對本原則的最佳實踐。

最佳實踐：Docker

6）進程

進程必須無狀態且無共享，即雲應用以一個或多個無狀態不共享的程序運行。任何必要狀態都被服務化到後端服務中（緩存、對象存儲等）；

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

最佳實踐：無狀態，面向失敗設計

7）端口綁定

本身不依賴其他組件（如java依賴tomcat）就能提供網絡服務，同時暴露一個監聽端口來對外提供服務；

在容器應用中，應用通過暴露端口來服務，盡量避免通過本地文件或進程來通信，每種服務通過服務發現而服務；

最佳實踐：微服務架構

8）並發

應用設計要實現能夠輕易的水平擴展，通過水平擴展來實現擴容；

在互聯網的服務中，業務的爆發性隨時可能發生，因此不太可能通過硬件擴容來隨時提供擴容服務，需要依賴橫向擴展能力進行擴容。

最佳實踐：無狀態化，水平擴容

9）易處理

應用要能快速啟動和優雅終止，更少的啟動時間提供了更敏捷的發佈以及擴展過程，此外還增加了健壯性，應對快速迭代場景；

此類型的進程所隱含的要求是，任務都應該 可重複執行， 這主要由將結果包裝進事務或是使重複操作 冪等 來實現。

在雲環境中，由於業務的高低峰值經常需要能實現快速靈活、彈性的伸縮應用，以及不可控的硬件因素等，應用可能隨時會發生故障，因此應用在架構設計上需要儘可能無狀態，應用能隨時隨地拉起，也能隨時隨地銷毀，同時保證進程最小啟動時間和架構的可棄性，也可以提供更敏捷的發佈及擴展過程。

最佳實踐：無狀態化，熱重啟，可重入，冪等

10）環境等價

確保環境的一致性，保持研發、測試和生產環境儘可能相似，這樣可以提供應用的持續交付和部署服務。

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

最佳實踐：docker，devops

11）日誌

應用的日誌要以流式的方式輸出到遠程日誌服務或者本地stdout，不要寫本地文件；

日誌是系統運行狀態的部分體現，無論在系統診斷、業務跟蹤還是後續大數據服務的必要條件中，Docker提供標準的日誌服務，用戶可以根據需求做自定義的插件開發來處理日誌。

最佳實踐：日誌中心化，filebeat（日誌採集），opentracing（調用鏈），prometheus（監控）

12）管理進程

把後台管理任務當作一次性進程運行；

一些工具類在生產環境上的操作可能是一次性的，因此最好把它們放在生產環境中執行，而不是本地，並且需要把它們像管理應用一樣管理起來。例如定時任務，可以通過分佈式任務調度平台統一管理。

最佳實踐：統一的調度平台

5. 微服務（MicroServices）

隨着業務越來越複雜，業務架構也經歷了不斷變化和演進，每一次演進都是為了解決上一代系統架構的痛點，下圖是業務架構演進路線圖：

第一代單體架構把所有業務依賴的組件、庫全部打包到一個執行程序，業務相互調用，大大增加了系統複雜度，導致系統維護成本高，改動影響大，發佈風險高；並且系統完全封閉，內部組件不能共享給其他組件調用，導致產品能力不能共享，大大降低開發效率。

第二代面向服務架構SOA（Service Oriented Architecture）是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在與操作系統進程中，各個服務之間通過網絡調用。

第三代微服務架構是在 SOA 上做的升華，微服務架構強調的一個重點是「業務需要徹底的組件化和服務化」，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。

SOA架構和微服務架構的區別：

微服務架構確實有很多吸引人的地方，然而它的引入也是有成本的，它並不是銀彈，使用它會引入更多技術挑戰，比如性能延遲、分佈式事務、集成測試、故障診斷等方面，企業需要根據業務的不同的階段進行合理的引入，不能完全為了微服務而「微服務」。

6. 服務網格（Service Mesh）

服務網格（Service Mesh）很多人將之稱為下一代微服務，或直接稱之為微服務2.0。

微服務1.0時代的主要問題主要包括如下三方面：

• 技術門檻高：開發團隊在實施微服務的過程中，除了基礎的服務發現、配置中心和鑒權管理之外，團隊在服務治理層面面臨了諸多的挑戰，包括負載均衡、熔斷降級、灰度發佈、故障切換、分佈式跟蹤等，這對開發團隊提出了非常高的技術要求。
• 多語言支持不足：對於互聯網公司，尤其是快速發展的互聯網創業公司，多語言的技術棧、跨語言的服務調用也是常態，但目前開源社區上並沒有一套統一的、跨語言的微服務技術棧，而跨語言調用恰恰是微服務概念誕生之初的要實現的一個重要特性之一。
• 代碼侵入性強：Spring Cloud、Dubbo等主流的微服務框架都對業務代碼有一定的侵入性，技術升級替換成本高，導致開發團隊配合意願低，微服務落地困難。

為了解決微服務1.0時代的諸多問題，Service Mesh概念開始走入了開發者的視線中。

介紹Service Mesh概念之前，我們先來了解一下Sidecar。Sidecar是以第一次世界大戰時活躍在戰場上的軍用邊斗車命名（也是我們在抗日神劇中最常見的道具之一）。

Sidecar是Service Mesh中的重要組成部分，Sidecar在軟件系統架構中特指邊斗車模式，這個模式的精髓在於實現了數據面（業務邏輯）和控制面的解耦。

在Service Mesh架構中，非業務功能下層到Sidecar，用戶只需要關係業務邏輯，而不用關係服務治理等非業務功能，每個微服務實例部署一個Sidecar Proxy。該Sidecar Proxy負責接管對應服務的入流量和出流量，並將微服務架構中的服務訂閱、服務發現、熔斷、限流、降級、分佈式跟蹤等功能從服務中抽離到該Proxy中。

最佳實踐：Istio，Envoy

Istio：Service Mesh的開源框架，Istio在邏輯架構上由數據平面和控制平面組成。

Istio提供一種簡單的方式來為已部署的服務建立網絡，該網絡具有負載均衡、服務間認證、監控等功能，而不需要對服務的代碼做任何改動。

Envoy：數據層Sidecar，協調服務網格中所有服務的出入站流量，並提供服務發現、負載均衡、限流熔斷等能力，還可以收集與流量相關的性能指標。

7. 無服務架構（Serverless）

Serverless被翻譯為「無服務架構」，這個概念在2012年時便已經存在，比微服務和Service Mesh的概念出現都要早，但是直到微服務概念大紅大紫之後，Serverless才重新又被人們所關注。

Serverless（無服務器架構）並不意味着沒有任何服務器去運行代碼，Serverless是無需管理服務器，只需要關注代碼，而提供者將處理其餘部分工作。

對於開發者來說，Serverless架構可以將其服務器端應用程序分解成多個執行不同任務的函數，整個應用分為幾個獨立、鬆散耦合的組件，這些組件可以在任何規模上運行。

使用Serverless架構可以免除所有運維性操作，開發人員可以更加專註於核心業務的開發，實現快速上線和迭代，把握業務發展的節奏。Serverless架構可以認為是對微服務和容器化的一種補充，為用戶提供了一種新的選擇，來應對複雜多變的需求，尤其適合快速發展的初創型公司。

1

雲原生成熟度模型

我們可以通過雲原生成熟度模型來衡量我們系統目前所處的階段，藉助於雲計算平台，我們可以比較容易把我們的雲原生成熟度提高到第三級別。

雲原生成熟度模型：

1

雲原生技術圖譜

2015年Google牽頭創立雲原生計算基金會（www.cncf.io），致力於雲原生技術普及和可持續發展，發佈了標誌性作品k8s，也維護CNCF雲原生技術圖譜Landscape（https://landscape.cncf.io/images/landscape.png），具體包括：

• 應用定義開發層（App Definition and Development）
• 編排管理（Orchestration & Management）
• 運行環境（Runtime ）
• 供應保障（Provisioning）
• 平台管理（Platform）
• 監控分析（Observability and Analysis）
• 無服務（Serverless）
• 合作夥伴（Special）
• 成員構成（Member）

目前，在整個Landscape中按照功能或者模塊分為了29個部分，分別歸屬於9種類型或者稱為分層（包括生態中的培訓等部分，不是特別嚴謹），包括當前CNCF在孵化中和已經畢業的22個項目，相關的詳細信息如下所示：

CNCF的Landscape提供了非常之多的雲原生相關的工具、平台與框架進行選擇，並給出了大體方向的指引，它提供具體的可供落地實施的工具方法，在企業推行雲原生應用落地的時候，應該作為首選參照的內容之一。

1

總結

雲原生是一種構建和運行應用程序的方法，是一套技術體系和方法論，它還包括研發流程規範，軟件架構，基礎設施和工具集，為我們在基於的雲上開發提供了指導思想和最佳實踐。

只有按照雲原生的技術和管理方法，才能更好地把業務生於「雲」或遷移到雲平台，從而享受「雲」的高效和持續的服務能力。

為了讓我們的產品更加符合雲原生，我們應該緊跟開源社區，順勢而為，迎合雲原生的理念，迎合社區的發展方向。

參考資料：

https://blog.csdn.net/csdnnews/article/details/90093190

https://blog.csdn.net/wufaliang003/article/details/79533345

https://skyao.io/talk/201902-cloudnative-freely-talk/

https://skyao.io/talk/201902-cloudnative-freely-talk2/

https://skyao.io/publication/201902-service-mesh-2018-summary/

https://www.liangzl.com/get-article-detail-4046.html

https://www.jianshu.com/p/e21594c2e9e7

https://www.cnblogs.com/xiao2shiqi/p/11298663.html

https://www.jianshu.com/p/cf4d4258b7f6

http://www.geekpark.net/news/243185

https://blog.csdn.net/liumiaocn/article/details/100713072

https://jimmysong.io/kubernetes-handbook/cloud-native/from-kubernetes-to-cloud-native.html

《持續演進的Cloud Native – 雲原生架構下微服務最佳實踐》

往期推薦

（點擊圖片即可跳轉閱讀）

開年大禮包 

↓↓更多驚喜優惠請點這兒~