運用容器化架構及微服務架構,升級企業 IT 環境(1)

應用程式現代化和分離 (decoupling) 基礎架構服務及雲端團隊

在公有雲上將應用程式現代化能夠優化產品的成本面和生產面,但這些優勢通常只有「全有」或「全無」兩種選項,若要有這些好處,你必須搬遷到雲端。企業希望透過搬資料到雲端進行現代化,且能夠依照需求提供本機和雲端遷移路徑的解決方案。這項現代化對於企業的創新十分重要,可以結合機器學習和資料分析。

此外,不同的公有雲提供不同的平台,讓工作負載的遷移在技術上和開發人員操作上變得十分困難。有許多企業會選擇使用多種雲端平台,不同時間能夠和不同的供應商合作,希望能夠保有一些作業的獨立性。

這是兩種截然不同的型態需求:內部現代化、多雲解決方案。這兩種需求都需要一種可在各雲端平台上運作,並提供方便開發的新平台。Kubernetes 在容器的編排和工作負載轉移上都是業界先驅,它迅速成為能夠跨平台執行應用程式的標準,是眾多平台的基礎。為了能夠同時滿足敏捷式開發和企業團隊營運的需求,這個產業現在可以專注於最初的目標:建立一個全自動化的雲端平台服務:一個能夠自然發展的動態分散式系統,用途種類繁多的機器學習,同時也提供一致性的開發者體驗和單一管控機制。

Google 建立 Cloud Services Platform (CSP) 來加速 SaaS 供給商、開發人員、IT 營運商和終端使用者的應用服務現代化。為了平衡開發速度、營運效率和管理平台,CSP 框架支援關鍵元件分離法:

  • 基礎設施和應用程式分離 (decoupling) 應用:透過容器和 Kubernetes
  • 團隊分離 (decoupling) 運作:透過 Kubernetes pods 和服務
  • 開發和營運分離 (decoupling):透過服務和政策管理
  • 安全性、開發及營運分離:透過結構化政策管理

成功的分離 (decoupling) 基礎架構、服務和團隊,減少人工調整、成本和複雜性,並大幅提升開發人員的速度、營運效率和企業生產力。它提供一個框架、執行方法和運作模式,確保迎接開放、混合和多雲的未來。

圖一:現代化的方式

透過分離 (decoupling) 加速應用程式現代化

分離 (decoupling) 基礎設施和應用程式:容器和Kubernetes

原生雲端的轉移比起虛擬主機 VM 需要考慮更多。VM 可以解決許多問題,但僅介於基礎設施的表現而不是應用程式上。特別的點為,VM 映像檔和應用程式的關聯十分緊密,作業系統(OS)、應用程式、引用的程式庫。

因此,由 Docker 驅動的容器第一個角色為將應用程式打包與基礎架構區隔開來,包括模擬機、程式庫和 OS 操作系統。事實上,Docker 其中一個最成功的例子是在使用者筆電上能夠建立、測試應用程式,並且將之部署到雲端上。例如:容器中定義正確的程式庫及附屬元件並部署到基礎架構,可以忽略原本部署在基礎架構上的其他資料,並讓可能發生衝突的程式庫同時並存在同一台機器上。

容器的第二種角色 (有時稱為「Linux 容器」),能夠在同一台機器上分別獨立不同應用程式。Google 在十多年前開創這一系列的工作,以至於我們能夠在同一台機器上打包許多不同應用程式,並不用擔心彼此互相干擾的問題。這讓我們能夠檢視叢集的排程,像是跨平台特定應用程式的 bin-packing 裝箱問題。

基於「程式撰寫一次,隨處執行」的成功,可攜式和效能獨立在共享的基礎架構上,容器已被證明是分離應用程式與基礎架構的第一個關鍵步驟,也是應用程式現代化的基本要素。

分離 (decoupling) 雲端團隊:Pods 和服務

對一個簡單的應用程式來說,容器提供足夠的功能:一個開發團隊可以用容器開發應用程式,並且將之部署到雲端上。但是對於開發應用程式較複雜的團隊,我們希望能夠將團隊的分工運作各自切割。對於負責共享基礎架構的團隊而言,能夠清楚分離更是攸關重要 (例如監控軟體或日誌紀錄)。一個日誌團隊必須要根據應用程式的更新去發展自有的日誌功能。如果客戶每一個app都使用一個容器,他們必須要針對容器建立一個記錄檔的版本並部署該版本。客戶若要升級日誌紀錄,須部署一個新的容器 – 分離應用程式和日誌團隊,也需要做整合,並適時的調降他們的速度。

什麼是 Pods?

Kubernetes推出Pods的功能解決了分離 (decoupling) 的問題。一個 pod 中有一組容器 (container),這些容器可以共同排程 (在同一台機器上運作)。它可以共享機器資源例如:本地磁區 (local Volume) 及預定單一個 IP 位址。在日誌範例中,每個 pod 都有應用容器和日誌容器,透過兩個管道做溝通:共用磁區 和/或 localhost 本機網路。這種鬆耦合能夠在 pod 中各自獨立更新:應用容器能夠只更新客戶 API 紀錄,但不包括執行紀錄更新。擁有這種功能的容器在 pod 中通常被稱作「邊車模式 (sidecar)」。

每一個 pod 中都有自己的 IP 位置可以實現分離 (decoupling) 的功能 – 每一個 pod 可以使用所有的 port。這十分的重要,因為大多數的應用程式有假設的固定 port (例如 HTTP 的 port 80)。DNS 所使用的 port 並沒有按照慣例 (在正常狀態下),所以 port 會被假設 2。傳統來說,port 結合了應用端和機器端的概念,每台機器上有多種不同的應用程式,因此在每台機器上有多個 IP 位置。Pod 解決了這個問題,實際上一台機器有 100 個 pod 就會有至少 100 個 IP 位置。

基礎服務

現在基礎架構主要為「服務導向」,但是在我們回答「什麼是服務?」之前,必須先從 Kubernetes 這個抽象的服務開始說起。在文章的後面,我們會討論到一些建立在這個服務上好用的功能。

Kubernetes 的基本服務為一組機制為背景動態建立 pod 集合,並執行不同的政策和維護服務 IP。這種服務機制叫做「微服務」,但是服務的內容或範疇不須特別小,它更能做到建構區塊和團隊用來提供服務。Google 總共運行超過 10,000 多項服務。

目前為止這個服務最重要的部分為高可用永久性名稱。主要的名稱是個 IP 位址:Kubernetes 使用「服務IP」,每個 pod 都會分配到一個 IP,並且可以獨立運作。上述所提到的「一組機制」為一個 proxy,但它也可以是各種形式的路由或 NAT,動態地將服務 IP 對映到 pod IP。雖然 non-proxy 形式的彈性較少,但是通常具有較好的性能。

將執行和服務名稱分離 (decoupling),對客戶來說有幾個重要的好處:

  • 隨著服務和 pods 組成的生命週期分離,可以執行線上升級的運作
  • 由於 pod 可以 (手動或自動) 通透地適應客戶端的負載,因此擴展更容易
  • 政策定義和一致性可以透過 proxy 執行,簡化複雜的管理流程 (例如安全相關操作)

服務可以整合不同部門的語言和應用套件。

每一個服務可以依據不同語言或風格來建置自己的 pods。服務代表 API,可以使用 IDL 和結構描述來定義,通常使用 JSON HTTP。同樣的,客戶可以使用自己所熟悉的語言。需要高性能的服務可以使用 protobufs 和 gRPC4,透過十幾種語言來實現。

對於「邊車」來說語言獨立是很大的優勢,例如日誌代理程式。由於需和本機端溝通,因此邊車用不同語言撰寫應用程式是很常見的。只有客戶端日誌 API 需用應用程式語言編寫,且通常可以被自動產生。

服務可以讓大部分的應用程式獨立部署並向下相容升級。版本號碼有助於跟開發團隊分離,讓客戶知道是否安全使用新版本。實際上,按照常規開發團隊通常使用圍繞版本號碼來表示語義變化。

Kubernetes 的基本服務是無邊界的。定義上,服務內的所有 pod 都來自相同的規範,且可以隨時這個規範中重新啟動。這樣抽象定義對於大多數的服務和 12-factor apps 來說已經很足夠。一些需要永久儲存資料的假設性情況,被歸類在其他管理服務當中。

此服務的最終目標為分解團隊。如果一個團隊可以清楚的分割各自的工作範圍稱為「解離」,這在傳統上說起來容易,做起來卻不容易。服務是程式部署的最小單位 – 它們被獨立封裝並構成 API 的基礎單位,是更好的「物件」工具,因為它們更大、壽命長、可用性高。對於目前大部分的物件導向程序來說,微型化服務可以加以應用並走得長久。

下一篇:運用容器化架構及微服務架構,升級企業 IT 環境(2),將提到 Proxy 的用處、Istio 的微型服務和生命週期管理、安全性。

(原文翻譯自 Google Cloud。)

 


連絡「GCP 專門家」