什麼是雲原生

時間  2020-12-20 標籤 其他

雲計算技術發展

在這裏插入圖片描述

雲原生的定義

CNCF

全稱Cloud Native Computing Foundation（雲原生計算基金會）

2015年7月21日Google主導成立了雲原生計算基金會，其最初的口號是堅持和整合開源技術來讓編排容器作爲微服務架構的一部分，致力於雲原生應用推廣和普及。

CNCF作爲一個廠商中立的基金會，致力於Github上的快速成長的開源技術的推廣，如Kubernetes、Prometheus、Envoy等，幫助開發人員更快更好的構建出色的產品。

CNCF對雲原生的定義

雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

雲原生計算基金會（CNCF）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。我們通過將最前沿的模式民主化，讓這些創新爲大衆所用。

雲原生應用的三大特徵

  • 容器化包裝：軟件應用的進程應該包裝在容器中獨立運行。
  • 動態管理：通過集中式的編排調度系統來動態的管理和調度。
  • 微服務化：明確服務間的依賴，互相解耦。

雲原生概念思維導圖

在這裏插入圖片描述

雲原生的設計理念

  1. 面向分佈式設計（Distribution）：容器、微服務、API 驅動的開發。
  2. 面向配置設計（Configuration）：一個鏡像，多個環境配置。
  3. 面向韌性設計（Resistancy）：故障容忍和自愈。
  4. 面向彈性設計（Elasticity）：彈性擴展和對環境變化（負載）做出響應。
  5. 面向交付設計（Delivery）：自動拉起，縮短交付時間。
  6. 面向性能設計（Performance）：響應式，併發和資源高效利用。
  7. 面向自動化設計（Automation）：自動化的 DevOps。
  8. 面向診斷性設計（Diagnosability）：集羣級別的日誌、metric 和追蹤。
  9. 面向安全性設計（Security）：安全端點、API Gateway、端到端加密。
    以上的設計理念很多都是繼承自分佈式應用的設計理念。

雲原生生態體系

在這裏插入圖片描述

容器化

由於KVM（ for Kernel-based Virtual Machine ）hypervisor虛擬化技術仍然存在⼀些性能和資源使⽤效率⽅⾯的問題，因此出現了⼀種稱爲容器技術（Container）的新型虛擬化技術來幫助解決這些問題。

虛擬化技術可以在宿主機上安裝多個不同的操作系統，運⾏多套不同的應⽤。但可能就是爲了運⾏⼀個微應用，卻還要在虛擬機⾥運⾏⼀個完整的操作系統，內核和其它⽆關程序，這種做法資源利⽤不⾼。

所以我們希望更多的關注應⽤程序本身，⽽不再分精⼒去關注操作系統與⽆關程序，操作系統內核直接與宿主機共享。

Docker 容器

Docker容器本質上是宿主機的進程. 可以把docker容器內部跑的進程看作是宿主機的線程。
Docker通過namespace實現了資源隔離，通過cgroups實現了資源限制。

Linux內核實現namespace的⼀個主要⽬的就是實現輕量級虛擬化(容器)服務。在同⼀個namespace下
的進程可以感知彼此的變化，⽽對外界的進程⼀⽆所知。

Linux容器技術是⼀種輕量級的虛擬化技術。主要特點有:

  1. 輕量:只打包了需要的bins/libs(也就是命令和庫⽂件)。與宿主機共享操作系統,直接使⽤宿主機的內核。
  2. 部署快: 容器的鏡像相對虛擬機的鏡像⼩。部署速度⾮常快，秒級部署。
  3. 移植性好: Build once，Run anywhere (⼀次構建,隨處部署運⾏)。
  4. 資源利⽤率更⾼: 相對於虛擬機，不需要安裝操作系統，所以⼏乎沒有額外的CPU，內存消耗。

虛擬化與容器化對比

虛擬化（VM）Docker容器操作系統宿主機OS上運行虛擬機OS與宿主機共享OS存儲大小鏡像龐大（vmdk、vdi等）鏡像小，便於存儲於傳輸運行性能操作系統額外的CPU、內存開銷幾乎無額外的性能損失移植性笨重，與虛擬化耦合度高輕便、靈活、適應於linux硬件親和性面向硬件開發者面向軟件開發者部署速度較慢、10秒級別快速、秒級

容器的編排與調度

Kubernetes（k8s）是Google基於Borg開源的容器編排調度引擎，作爲CNCF（Cloud Native Computing Foundation）最重要的組件之一，它的目標不僅僅是一個編排系統，而是提供一個規範，可以讓你來描述集羣的架構，定義服務的最終狀態，Kubernetes可以幫你將系統自動得達到和維持在這個狀態。

Kubernetes用戶可以通過編寫一個yaml或者json格式的配置文件，也可以通過工具/代碼生成或直接請求Kubernetes API創建應用，該配置文件中包含了用戶想要應用程序保持的狀態，不論整個Kubernetes集羣中的個別主機發生什麼問題，都不會影響應用程序的狀態，你還可以通過改變該配置文件或請求Kubernetes API來改變應用程序的狀態。

Kubernetes 架構圖：
在這裏插入圖片描述
其他容器編排與調度技術方案：
Swarm、Mesos

微服務

微服務是一種分佈式架構設計理念，爲了推動細粒度服務的使用，這些服務要能協同工作，每個服務都有自己的生命週期。一個微服務就是一個獨立的實體，可以獨立的部署在PAAS平臺上，也可以作爲一個獨立的進程在主機中運行。服務之間通過API訪問，修改一個服務不會影響其它服務。

微服務帶給我們很多開發和部署上的靈活性和技術多樣性，但是也增加了服務調用的開銷、分佈式系統管理、調試與服務治理方面的難題。

Spring框架

當前最成熟最完整的微服務框架Spring，而Spring又僅限於Java語言開發，其架構本身又跟Kubernetes存在很多重合的部分，如何探索將Kubernetes作爲微服務架構平臺就成爲一個熱點話題。就拿微服務中最基礎的服務註冊發現功能來說，其方式分爲客戶端服務發現和服務端服務發現兩種，Java應用中常用的方式是使用Eureka和Ribbon做服務註冊發現和負載均衡，這屬於客戶端服務發現，而在Kubernetes中則可以使用DNS、Service和Ingress來實現，不需要修改應用代碼，直接從網絡層面來實現。

服務網格

Kubernetes中的應用將作爲微服務運行，但是Kubernetes本身並沒有給出微服務治理的解決方案，比如服務的限流、熔斷、良好的灰度發佈支持等。

Service Mesh可以用來做什麼

  • Traffic Management：API網關
  • Observability：服務調用和性能分析
  • Policy Enforcment：控制服務訪問策略
  • Service Identity and Security：安全保護

Service Mesh的特點

  • 專用的基礎設施層
  • 輕量級高性能網絡代理
  • 提供安全的、快速的、可靠地服務間通訊
  • 擴展kubernetes的應用負載均衡機制，實現灰度發佈
  • 完全解耦於應用，應用可以無感知，加速應用的微服務和雲原生轉型

當前開源的Service Mesh有哪些？
使用Service Mesh將可以有效的治理Kubernetes中運行的服務：

  • Linkderd：https://linkerd.io，由最早提出Service Mesh的公司Buoyant開源，創始人來自Twitter
  • Envoy：https://www.envoyproxy.io/，Lyft開源的，可以在Istio中使用Sidecar模式運行
  • Istio：https://istio.io，由Google、IBM、Lyft聯合開發並開源
  • Conduit：https://conduit.io，同樣由Buoyant開源的輕量級的基於Kubernetes的Service Mesh
    此外還有很多其它的Service Mesh魚貫而出，請參考awesome-cloud-native。

DEVOPS

持續集成

Continuous integration，簡稱CI
是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味着每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發佈，自動化測試)來驗證，從而儘快地發現集成錯誤。
在這裏插入圖片描述持續集成的目的不是減少build失敗的次數，⽽是儘早發現問題，在最短的時間內解決問題，減少風險和浪費。從而讓產品開發流程更加敏捷，縮短產品開發週期，在產品上線後，讓用戶用得更加順暢。

在沒有應用持續集成之前，傳統的開發模式是項目一開始就劃分模塊，每個開發人員分別負責一個模塊，等所有的代碼都開發完成之後再集成到一起提交給測試⼈人員，隨着軟件技術團隊的發展，軟件已經不能簡單地通過劃分模塊的方式來開發，需要項目內部相互協作，劃分模塊這種傳統的模式的弊端也越來越明顯。由於很多bug在項目早期的設計、編碼階段就引入，到最後集成測試時才發現問題，開發人員需要花費⼤量的時間來定位bug，加上軟件的複雜性，bug的定位就更難了，甚⾄出現不得不調整底層架構的情況。這種情況的發生不僅對測試進度造成影響，⽽且會拖長整個項⽬週期。

而持續集成可以有效解決軟件開發過程中的許多問題，在集成測試階段之前就幫助開發人員發現問題，從而可以有效的確保軟件質量，減小項目的風險，使軟件開發團隊從容的面對各種變化。持續集成報告中可以體現目前項目進度，哪部分需要已經實現，哪些代碼已經通過自動化測試，代碼質量如何，讓開發團隊和項目組瞭解項目的真實狀況。

持續交付

Continuous Delivery，簡稱CD
持續交付是指軟件開發過程，從原始需求到最終產品開發過程中，較短週期內以需求的小顆粒度（小批量）頻繁提交的過程。
在這裏插入圖片描述
目的

  1. 開發過程的快速迭代，小步快跑，及時糾正偏離主線
  2. 小顆粒度實現，避免顆粒度大，出現問題解決麻煩
  3. 迅速反饋軟件功能，避免⽅向性錯誤
  4. 團隊角色（含客戶）協作密切，減少時間浪費

持續部署

Continuous Deployment，簡稱CD
基於持續交付的基礎上，把功能穩定，符合產品需求的版本有方法地部署至生產環境中。

持續發佈

Continuous Release，簡稱CR
發佈是週期性或不定期地對項目在部署後，進行整體軟件版本的更新，例如，更新功能或展示頁面框架等。

目的

  1. 產品快速迭代，小步快跑
  2. 適應市場變化
  3. 匹配市場策略
  4. 應對市場風險

持續測試

Continuous Testing，簡稱CT
持續測試是貫穿着整個軟件開發過程，驗證程序員提交代碼，檢驗合規性及降低bug，減少最終錯誤，實現敏捷及精益開發。

目的

  1. 爲了降低開發、部署、發佈等可能出現的錯誤
  2. 防止代碼出錯
  3. 防止功能出錯
  4. 防止業務邏輯出錯等

Jenkins

Jenkins是一款由Java編寫的開源的持續集成工具。

Jenkins提供了軟件開發的持續集成服務。它運行在Servlet容器中。它支持軟件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），可以執行基於Apache Ant和Apache Maven的項目，以及任意的Shell腳本和Windows批處理命令。

使用Jenkins進行持續集成與發佈流程圖：
在這裏插入圖片描述
應用構建和發佈流程說明：

  1. 用戶向Gitlab提交代碼，代碼中必須包含Dockerfile。
  2. 將代碼提交到遠程倉庫。
  3. 用戶在發佈應用時需要填寫git倉庫地址和分支、服務類型、服務名稱、資源數量、實例個數，確定後觸發Jenkins自動構建。
  4. Jenkins的CI流水線自動編譯代碼並打包成Docker鏡像推送到Harbor鏡像倉庫。
  5. Jenkins的CI流水線中包括了自定義腳本，根據我們已準備好的Kubernetes的YAML模板，將其中的變量替換成用戶輸入的選項。
  6. 生成應用的Kubernetes YAML配置文件。
  7. 更新Ingress的配置，根據新部署的應用的名稱，在Ingress的配置文件中增加一條路由信息。
  8. 更新PowerDNS，向其中插入一條DNS記錄，IP地址是邊緣節點的IP地址。
  9. Jenkins調用Kubernetes的API，部署應用。
联系我们 沪ICP备13005482号-10