一起聊聊什么是云原生技術
近期在社區里看到很多人都在問什么是云原生，很有幸我是一位云原生技術的初級使用者，我們目前運用到的云原生技術有微服務、Kubernetes、Docker、Istio、Serverless, 今天我們就一起來聊聊。
云原生的起源
重量級嘉賓
在介紹云原生之前，我們先介紹一位重量級嘉賓，可以說是目前云原生領域影響力最大最有話語權的組織 CNCF。
CNCF，全稱Cloud Native Computing Foundation(云原生計算基金會)，成立于 2015 年7月21日于美國波特蘭OSCON 2015上宣布，其最初的口號是堅持和整合開源技術來讓編排容器作為微服務架構的一部分，其作為致力于云原生應用推廣和普及的一支重要力量。
再來一張 CNCF 的全景圖：
云原生定義
CNCF 的定義
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。
云原生計算基金會(CNCF)致力于培育和維護一個廠商中立的開源生態系統，來推廣云原生技術。我們通過將最前沿的模式民主化，讓這些創新為大眾所用。
以上內容來源于：CNCF Cloud Native Definition v1.0 - github.com
Pivotal 的定義
2015年，云原生剛推廣時，Matt Stine在《遷移到云原生架構》一書中定義了符合云原生架構的幾個特征：12因素、微服務、自敏捷架構、基于API 協作、扛脆弱性。
到了2017年，Matt Stine改了口風，將云原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理6特質。而Pivotal官網對云原生概括為4個要點：DevOps+持續交付+微服務+容器。
MattStine認為云原生它是一個思想的集合，包括DevOps、持續交付(Continuous Delivery)、微服務(MicroServices)、敏捷基礎設施(Agile Infrastructure)、康威定律(Conways Law)等。
云原生既包含技術(微服務，敏捷基礎設施)，也包含管理(DevOps，持續交付，康威定律，重組等)，可以說是一系列云技術、企業管理方法的集合。
我們暫且以 CNCF 官方的定義為準，按CNCF的定義，云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
云原生的代表技術
微服務
微服務可以從兩個方面去理解：什么是“微”、什么是“服務”。
微，狹義來講就是體積小。
服務，一定要區別于系統，服務一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。
傳統的單體架構，是以整個系統為單位進行部署。而微服務，則是以每一個獨立組件(例如用戶服務，商品服務)為單位進行部署。
對于單體應用，如果發現某一業務的請求量非常大，那么是無法單獨擴展該業務的，只能拷貝整個單體應用，再部署一套環境，來實現集群。正因為單體應用的缺陷，才有了微服務。而近幾年流行的Docker，為微服務架構提供了有效的容器。
容器
開源解決方案供應商紅帽官網給出的容器定義：
Linux?容器是與系統其他部分隔離開的一系列進程。
運行這些進程所需的所有文件都由另一個鏡像提供，這意味著從開發到測試再到生產的整個過程中，Linux 容器都具有可移植性和一致性。
容器提供進程級的隔離，可以將操作系統管理的資源劃分到相互隔離的組中，在相互隔離的組之間解決資源使用存在沖突的問題。比如應用程序(Application)APP 1 ，只能在centos 操作系統上運行;APP2只能在Ubuntu操作系統上運行。而同一個操作系統同時運行APP1和APP2就產生沖突。容器技術則恰恰可以解決這類問題。目前主流的容器技術有Docker、LXD以及RKT等。
Docker
說到容器，就不得不說Docker。
2010年，幾個大胡子的年輕人在美國舊金山成立了一家名叫“dotCloud”的公司。這家公司主要提供基于PaaS的云計算技術服務。具體來說，是和LXC有關的容器技術。
LXC，就是Linux容器虛擬技術(Linux container)。
后來，dotCloud公司將自己的容器技術進行了簡化和標準化，并命名為——Docker。
Docker項目通過容器鏡像，直接將一個應用運行所需的完整環境，即：整個操作系統的文件系統也打包了進去。
這種思路，可算是解決了困擾PaaS用戶已久的一致性問題，制作一個“一次發布、隨處運行”的Docker鏡像的意義，一下子就比制作一個連開發和測試環境都無法統一的Buildpack高明了太多。
Docker項目大大降低了容器技術的使用門檻。輕量級，可移植，虛擬化，語言無關，寫了程序扔上去做成鏡像可以隨處部署和運行，開發、測試和生產環境徹底統一了，還能進行資源管控和虛擬化。
Docker作為一種開源應用容器引擎，是為開發人員和系統管理員設計的用于構建、發布和運行分布式應用的平臺，典型的Docker平臺Kubernetes、OpenShift V3、Flynn、Deis等。
Docker允許開發人員將各種應用以及依賴包打包到一個可移植的Docker容器中，以Docker容器為資源分割和調度的基本單位，封裝整個軟件運行時的環境，然后發布到Linux機器上。
Kubernetes
有了容器，就需要編排管理容器的生命周期。這里不得不提一下 Kubernetes。
Kubernetes，這個單詞來自于希臘語，含義是舵手或領航員。K8s是它的縮寫，用“8”字替代了“ubernete”這8個字符。Kubernetes并不是一件全新的發明。它是谷歌根據其內部使用的Borg改造成的一個通用容器編排調度器，于2014年6月開源。
2015年，谷歌將其捐贈給Linux基金會下屬的云原生計算基金會(CNCF)，Kubernetes也成為CNCF第一個項目。
CNCF中托管的一系列項目，即致力于云原生應用整個生命周期的管理，從部署平臺、日志收集、Service Mesh(服務網格)、服務發現、分布式追蹤、監控以及安全等各個領域通過開源軟件為我們提供一整套解決方案。
Kubernetes作為云應用的部署標準，直接面向業務應用，大大提高了云應用的可移植性，解決云廠商鎖定的問題，讓云應用可以在夸云之間無縫遷移，甚至用來管理混合云，成為企業 IT 云平臺的新標準。
服務網格
服務網格(Service Mesh)，是指用以處理服務與服務之間通信的基礎設施層。
其最早由Buoyant公司(開發Service Mesh項目Linkerd的公司)提出，并在內部使用。該公司2016年9月29日第一次公開使用這個術語。
Service Mesh一般用于微服務應用的可配置基礎架構層(configurable infrastructure layer)。Istio(由Google、IBM、Lyft公司在背后進行支持)是目前最廣為人知的一款服務網格架構。
Docker和Kubernetes這樣的工具已經“解決了部署問題”。但他們還沒有解決運行時的問題，這就是服務網格的由來， 而 Service Mesh的出現，彌補了Kubernetes在微服務的連接、管理和監控方面的短板，為Kubernetes提供更好的應用和服務管理。
因此，Service Mesh的代表Istio一經推出，就被認為是可以和Kubernetes形成雙劍合璧效果的微服務管理的利器，受到了業界的推崇。
不可變基礎設施
在傳統的可變服務器基礎架構中，服務器會不斷更新和修改。使用此類基礎架構的工程師和管理員可以通過SSH連接到他們的服務器，手動升級或降級軟件包，逐個服務器地調整配置文件，以及將新代碼直接部署到現有服務器上。可變基礎設施通常在災難發生的時候，難以重新構建服務。持續過多的手工操作，缺乏記錄，會導致很難由標準初始化后的服務器來重新構建起等效的服務。在服務運行過程中，持續的修改服務器，就猶如程序中的可變變量的值發生變化而引入的狀態不一致的并發風險。這些對于服務器的修改，同樣會引入中間狀態，從而導致不可預知的問題。
而不可變基礎架構是程序設計中不可變變量(ImmutableVariable)就是在完成賦值后就不能發生更改，只能創建新的來整體替換舊的。由于具有這樣的特性這種變量可以在并發環境下安全的使用。對于基礎設施的不可變性，最基本的就是指運行服務的服務器在完成部署后，就不在進行更改。其好處包括基礎架構中更高的一致性和可靠性，以及更簡單，更可預測的部署過程。它可以緩解或完全防止可變基礎架構中常見的問題，例如配置漂移和雪花服務器。
聲明式API
在聲明式 API 中，我們可以聲明系統要執行的操作，系統將不斷向該狀態驅動。有點“產品經理”和“開發”之間的關系，“產品經理”只負責提需求，而“開發”怎么實現的，他并不關心。
總結一下：
- Kubernetes是整個云原生的基石，云原生的整個生態體系都是依靠Kubernetes建立起來的。
- 容器(Container)是Kubernetes的底層引擎。
- Docker是應用最廣的容器工具。
- 微服務是Docker的好搭檔。
- 服務網格是微服務的輔助，建立在k8s上的針對請求的擴展功能。
- 不可變基礎設施是現代運維的基石。
- 聲明式API是Kubernetes的編碼方式。
云原生到底哪里好?
綜合來說云原生可以打通微服務開發、測試、部署、發布的整個流程環節，在云原生架構下，底層的服務或者是API都由將部署到云中，等價于將繁重的運維工作轉移給了云平臺供應商， 但這也得益于云計算的基礎設施更加廉價。詳細來說一下個人認為的以下三個優勢：
快速迭代
利用云原生應用程序開發，使得交付團隊可以使用重復的自動化和編排來快速迭代，讓開發人員有更多的精力聚焦于業務開發上。
自動部署
云原生方法遠優于傳統的面向虛擬化的業務流程，傳統方法需要投入大量的精力來構建開發環境，以及軟件交付過程中的其他不同環境。而云原生架構具備自動化和組合功能，并且依賴于可靠、經過驗證和審核的已知良好流程的基礎，交付十分敏捷，而不再需要人工干預重復執行。
獨立高效
云原生帶來了微服務化架構，一個微服務基本是一個能獨立發布的應用服務，因此可以作為獨立組件升級、灰度或復用等，對整個大應用的影響也較小，每個服務可以由專門的組織來單獨完成，依賴方只要定好輸入和輸出口即可完全開發、甚至整個團隊的組織架構也會更精簡，因此溝通成本低、效率高。
寫在最后，云原生的確給我們帶來了很多便捷，但同時也對我們研發和運維人員提出了更高的要求，如何選擇更合適的云原生技術來解決日益復雜的業務問題。
參考資料
- https://github.com/cncf/landscape#trail-map。
- https://github.com/cncf/toc/blob/main/DEFINITION.md。
- https://www.bookstack.cn/read/kubernetes-handbook-201910/cloud-native.md。
