【開源力量】雲原生架構概述

1. 什麼是雲原生

1.1 CNCF組織

在講雲原生之前，我們先了解一下CNCF，即雲原生計算基金會，2015年由谷歌牽頭成立，基金會成員目前已有一百多企業與機構，包括亞馬遜、微軟。思科等巨頭。

目前CNCF所託管的應用已達14個，下圖為其公佈的Cloud Native Landscape，給出了雲原生生態的參考體系。

Cloud Native Landscape

1.2 雲原生

CNCF給出了雲原生應用的三大特徵：

• 容器化封裝：以容器為基礎，提高整體開發水平，形成程式碼和元件重用，簡化雲原生應用程式的維護。在容器中執行應用程式和程式，並作為應用程式部署的獨立單元，實現高水平資源隔離。
• 動態管理：通過集中式的編排排程系統來動態的管理和排程。
• 面向微服務：明確服務間的依賴，互相解耦。

雲原生包含了一組應用的模式，用於幫助企業快速，持續，可靠，規模化地交付業務軟體。雲原生由微服務架構，DevOps 和以容器為代表的敏捷基礎架構組成。

這邊引用網上關於雲原生所需要的能力和特徵總結，如下圖。

雲原生所需要的能力和特徵

1.3 The Twelve Factors

12-Factors經常被直譯為12要素，也被稱為12原則，12原則由公有云PaaS的先驅Heroku於2012年提出（https://12factor.net/），目的是告訴開發者如何利用雲平臺提供的便利來開發更具可靠性和擴充套件性、更加易於維護的雲原生應用。具體如下：

• 基準程式碼
• 顯式宣告依賴關係
• 在環境中儲存配置
• 把後端服務當作附加資源
• 嚴格分離構建、釋出和執行
• 無狀態程式
• 通過埠繫結提供服務
• 通過程式模型進行擴充套件
• 快速啟動和優雅終止
• 開發環境與線上環境等價
• 日誌作為事件流
• 管理程式

另外還有補充的三點：

• API宣告管理
• 認證和授權
• 監控與告警

距離12原則的提出已有五年多，12原則的有些細節可能已經不那麼跟得上時代，也有人批評12原則的提出從一開始就有過於依賴Heroku自身特性的傾向。不過不管怎麼說，12原則依舊是業界最為系統的雲原生應用開發指南。

2. 容器化封裝

最近幾年Docker容器化技術很火，經常在各種場合能夠聽到關於Docker的分享。Docker讓開發工程師可以將他們的應用和依賴封裝到一個可移植的容器中。Docker背後的想法是建立軟體程式可移植的輕量容器，讓其可以在任何安裝了Docker的機器上執行，而不用關心底層作業系統。

Docker可以解決虛擬機器能夠解決的問題，同時也能夠解決虛擬機器由於資源要求過高而無法解決的問題。其優勢包括：

• 隔離應用依賴
• 建立應用映象並進行復制
• 建立容易分發的即啟即用的應用
• 允許例項簡單、快速地擴充套件
• 測試應用並隨後銷燬它們

自動化運維工具可以降低環境搭建的複雜度，但仍然不能從根本上解決環境的問題。在看似穩定而成熟的場景下，使用Docker的好處越來越多。

3. 服務編排

筆者看到Jimmy Song對雲原生架構中運用服務編排的總結是：

Kubernetes——讓容器應用進入大規模工業生產。

這個總結確實很貼切。編排排程的開源元件還有：Kubernetes、Mesos和Docker Swarm。
 

Kubernetes是目前世界上關注度最高的開源專案，它是一個出色的容器編排系統。Kubernetes出身於網際網路行業的巨頭Google公司，它借鑑了由上百位工程師花費十多年時間打造Borg系統的理念，通過極其簡易的安裝，以及靈活的網路層對接方式，提供一站式的服務。
Mesos則更善於構建一個可靠的平臺，用以執行多工關鍵工作負載，包括Docker容器、遺留應用程式（例如Java）和分散式資料服務（例如Spark、Kafka、Cassandra、Elastic）。Mesos採用兩級排程的架構，開發人員可以很方便的結合公司業務場景自定製MesosFramework。

他們為雲原生應用提供的強有力的編排和排程能力，它們是雲平臺上的分散式作業系統。在單機上執行容器，無法發揮它的最大效能，只有形成叢集，才能最大程度發揮容器的良好隔離、資源分配與編排管理的優勢，而對於容器的編排管理，Swarm、Mesos和Kubernetes的大戰已經基本宣告結束，Kubernetes成為了無可爭議的贏家。

4. 微服務架構

傳統的Web開發方式，一般被稱為單體架構（Monolithic）所有的功能打包在一個WAR包裡，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裡，包含了DO/DAO，Service，UI等所有邏輯。其架構如下圖所示。

傳統的單體架構

單體架構進行演化升級之後，過渡到SOA架構，即面向服務架構。近幾年微服務架構（Micro-Service Archeticture）是最流行的架構風格，旨在通過將功能模組分解到各個獨立的子系統中以實現解耦，它並沒有一成不變的規定，而是需要根據業務來做設計。微服務架構是對SOA的傳承，是SOA的具體實踐方法。微服務架構中，每個微服務模組只是對簡單、獨立、明確的任務進行處理，通過REST API返回處理結果給外部。在微服務推廣實踐角度來看，微服務將整個系統進行拆分，拆分成更小的粒度，保持這些服務獨立執行，應用容器化技術將微服務獨立執行在容器中。過去設計架構時，是在記憶體中以引數或物件的方式實現粒度細化。微服務使用各個子服務控制模組的思想代替匯流排。不同的業務要求，服務控制模組至少包含服務的釋出、註冊、路由、代理功能。

容器化的出現，一定程度上帶動了微服務架構。架構演化從單體式應用到分散式，再從分散式架構到雲原生架構，微服務在其中有著不可或缺的角色。微服務帶給我們很多開發和部署上的靈活性和技術多樣性，但是也增加了服務呼叫的開銷、分散式系事務、除錯與服務治理方面的難題。

Spring Cloud整體架構圖

從上圖Spring Cloud元件的架構可以看出在微服務架構中所必須的元件，包括：服務發現與註冊、熔斷機制、路由、全域性鎖、中心配置管理、控制匯流排、決策競選、分散式會話和叢集狀態管理等基礎元件。

Spring Cloud VS Kubernetes

Spring Cloud和Kubernetes有很大的不同，Spring Cloud和Kubernetes處理了不同範圍的微服務架構技術點，而且是用了不同的方法。Spring Cloud方法是試圖解決在JVM中的微服務架構要點，而Kubernetes方法是試圖讓問題消失，為開發者在平臺層解決。Spring Cloud在JVM中非常強大，Kubernetes管理那些JVM很強大。看起來各取所長，充分利用這兩者的優勢是自然而然的趨勢了。

5. 總結

技術架構的演變非常快，各種新的名詞也是層出不窮。本文主要是對雲原生的概述。雲原生應用的三大特徵：容器化封裝、動態管理、面向微服務。首先由CNCF組織介紹了雲原生的概念，然後分別對這三個特徵進行詳述。雲原生架構是當下很火的討論話題，是不同思想的集合，集目前各種熱門技術之大成。