Knative建構無伺服器應用程式實務

– 15 分鐘閱讀

Knative 簡化了無伺服器應用程式的佈署和管理，自動處理資源組態和擴充套件，讓開發者專注於程式碼。本篇文章除了介紹 Knative 的核心概念和設計原則外，也提供建構單頁應用程式、設定 YAML 以及整合事件驅動架構的實務範例。透過理解 Knative 的服務管理和事件觸發機制，開發者能更有效地運用 Knative 建構和佈署可擴充套件的無伺服器應用。

建構根據Knative的無伺服器應用程式

前言

無伺服器架構已成為現代雲端運算的重要趨勢，它讓開發者能夠專注於撰寫程式碼，而不必擔心底層基礎設施的管理。Knative作為一個開源的無伺服器平台，為開發者提供了強大的工具來建構、佈署和管理無伺服器應用程式。本篇文章將探討Knative的核心概念、設計原則以及如何利用它來建構高效的無伺服器應用程式。

無伺服器架構的本質

無伺服器架構並非意味著沒有伺服器，而是開發者不需要直接管理和維護這些伺服器。無伺服器平台會自動處理資源的分配和擴充套件，讓應用程式能夠根據需求動態調整。

工作單元的概念

在無伺服器架構中，「工作單元」是一個重要的概念。它代表了應用程式處理請求或事件的基本單位。瞭解工作單元有助於開發者設計出更高效的無伺服器應用程式。

從零開始設計無伺服器應用程式

設計無伺服器應用程式需要考慮多個因素，包括應用程式的架構、API的設計以及與其他服務的整合。

建立單頁應用程式

單頁應用程式（SPA）是一種常見的Web應用程式架構。使用React等框架可以快速建立SPA，並將其佈署到無伺服器平台上。

// 使用React建立單頁應用程式的範例
import React from 'react';
import ReactDOM from 'react-dom';

function App() {
  return <h1>我的單頁應用程式</h1>;
}

ReactDOM.render(<App />, document.getElementById('root'));

內容解密：

上述程式碼展示瞭如何使用React建立一個簡單的單頁應用程式。首先，我們匯入了React和ReactDOM函式庫。然後，定義了一個名為App的功能元件，它傳回一個包含標題的JSX元素。最後，使用ReactDOM.render方法將App元件渲染到ID為root的DOM元素中。

Knative的核心概念

Knative提供了一系列功能來支援無伺服器應用程式的開發和佈署，包括服務管理、事件驅動架構等。

服務管理

Knative的服務管理功能允許開發者輕鬆佈署和管理無伺服器應用程式。它提供了自動擴充套件、請求路由等功能。

# Knative服務的YAML組態範例
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: 我的服務
spec:
  template:
    spec:
      containers:
      - image: 我的應用程式映像檔

內容解密：

上述YAML組態定義了一個Knative服務。首先，指定了API版本和資源型別（Service）。然後，定義了服務的中繼資料，包括名稱。最後，指定了服務的規格，包括容器映像檔的位置。

事件驅動架構與無伺服器運算

事件驅動架構是一種常見的設計模式，它允許應用程式對特定事件做出反應。無伺服器運算非常適合事件驅動架構，因為它能夠根據事件自動擴充套件。

無伺服器運算的本質與未來發展

前言：無伺服器運算的興起

無伺服器運算（Serverless）已成為雲端服務供應商的重要賣點。在過去四年中，無數服務被標榜或重新命名為「無伺服器」。這顯示無伺服器運算與網路服務之間存在著某種特殊聯絡。那麼，究竟什麼是無伺服器運算？它為何重要？與容器、函式或雲原生技術又有何不同？儘管術語和定義不斷演變，本文旨在闡述無伺服器技術的核心屬性，並解釋為何「無伺服器」這一稱呼日益流行。

本文重點：無伺服器運算系統

本文主要關注無伺服器運算系統，即執行使用者自定義軟體的系統，而非僅執行固定功能的系統，如儲存、索引或訊息佇列。雖然無伺服器儲存系統也存在，但並非本文的主要焦點。理論上，固定功能儲存和通用運算之間的界限並不明確。例如，支援SQL查詢語法的資料函式庫系統結合了儲存、索引和執行以SQL編寫的宣告式查詢程式。雖然瞭解固定功能系統的架構對於效能調優至關重要，但本文主要關注無伺服器運算系統，因為它為應用程式開發者提供了最多的自由度，也是他們日常最常互動的系統。

無伺服器運算的定義與演變

如果您仍然不確定無伺服器運算的定義，不必擔心。鑑於市場上眾多不同的產品，大多數人都處於相同的困惑之中。我們將在本文的「背景」部分探討「無伺服器」術語的演變，並在第一章中給出精確的定義。

本文結構與內容

本文分為四個部分，分別探討無伺服器運算的不同導向：

  1. 無伺服器運算基礎：介紹無伺服器運算的核心概念和屬性。
  2. 無伺服器架構設計：探討如何使用無伺服器技術進行系統設計，包括擴充套件單體架構、使用事件驅動架構等。
  3. 無伺服器運算的實踐：討論在無伺服器環境中開發和營運系統的挑戰和最佳實踐。
  4. 無伺服器運算的歷史與未來：回顧無伺服器技術的發展歷程，並展望其未來可能的發展方向。

重點章節解析

第五章：擴充套件單體架構

本章探討如何將單體架構擴充套件為無伺服器架構，包括微服務擴充套件點、非同步清理和擴充套件、提取-轉換-載入（ETL）過程，以及 strangler fig 模式等。

第六章：事件驅動架構

本章探討事件驅動架構，包括事件與訊息的區別、CloudEvents 的重要性、事件作為 API 的角色，以及工作流程協調等主題。

第七章：建立健全的內部溝通機制

本章討論如何建立健全的內部溝通機制，包括環境事件發布、主動儲存模式、內部溝通與 RPC 的比較，以及敏感資料處理等。

第九章：高速失敗

本章分析無伺服器環境中的失敗模式，包括熔斷、最窄瓶頸、冷啟動等，並提供避免這些問題的策略。

第十一章：無伺服器簡史

本章回顧了無伺服器技術的發展歷程，從早期的 inetd 和 CGI，到現代的 AWS Lambda、Azure Functions 等，展望了無伺服器未來的發展方向。

結語

無伺服器運算正在改變我們構建和營運軟體的方式。透過瞭解其核心屬性和最佳實踐，開發者可以更好地利用這一技術，構建更高效、更可靠的系統。未來，無伺服器運算將繼續演進，為軟體開發帶來更多創新和可能性。

無伺服器運算的背景與基礎

本文讀者

本文的主要讀者對像是軟體工程師與技術人員，他們可能是對無伺服器運算不熟悉，或是希望加深對無伺服器架構原理和最佳實踐的理解。對於想要立即開始撰寫無伺服器應用的新手，可以從第二章開始閱讀，但建議先閱讀第一章以獲得對無伺服器運算的整體認識和重要性。

本文結構

本文的章節安排對於熟悉無伺服器運算的讀者來說是自然且合理的。第五章和第六章提供了應用無伺服器運算的標準模式清單，而第八章及其後續章節則像是「賓果卡」一樣，列出了無伺服器運算的警告訊號和解決方案草圖，這些在日常工作中可能會很有用。第十一章提供了歷史背景，也為檢視過去的技術社群以尋找模式和解決方案提供了一張地圖。

背景知識

在過去的六年中，「雲原生」、「無伺服器」和「容器」等術語經歷了多輪的炒作和重新定義，甚至許多從業人員都難以跟上或完全同意這些術語的定義。以下章節旨在為本文其餘部分提供一些重要參考點的定義，但這些定義可能會繼續演變。

容器技術

容器技術（無論是 Docker 還是 Open Container Initiative (OCI) 格式）提供了一種機制，可以將一台主機劃分為多個獨立的執行環境。與虛擬機器（VMs）不同，容器環境分享單一作業系統核心，這帶來了一些好處：

  • 減少作業系統負擔：因為只執行一個作業系統。
  • 簡化應用程式捆綁：執行獨立於作業系統驅動程式和硬體。
  • 提高應用程式可見性：分享核心允許監控應用程式的詳細資訊，如開啟的檔案控制程式碼，這些對於完整的虛擬機器來說是難以提取的。
  • 標準化的分發機制：將容器儲存在OCI登入檔中。

雲端服務供應商

雲端服務供應商是指出售遠端存取運算和儲存服務的公司。常見的例子包括 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Platform (GCP)。這些公司按小時或甚至更細粒度地出租服務存取權，使得企業在需要時能夠輕易獲得運算能力，而無需提前投資和規劃資料中心空間、硬體和網路。

雲端供應商經濟學

主要的雲端供應商透過出售或多工存取底層實體硬體來賺取大部分利潤。例如，他們可能以（攤銷）5,000美元/年的價格購買一台伺服器，然後將其劃分為20個插槽，以0.05美元/小時的價格出售。對於一家公司來說，如果需要租用半台伺服器進行幾小時的測試，這意味著以不到1美元的價格獲得價值2,500美元以上的硬體。

雲端供應商因此對許多型別的業務具有吸引力，尤其是那些需求並非每天或每小時都一致，且可以接受透過網際網路存取的業務。如果雲端供應商能夠售出四分之三的機器（15個插槽 × 0.05美元 = 0.75美元/小時的收入），他們每年可以獲得0.75美元 × 24 × 365 = 6,570美元的收入，這對於投資回報來說相當可觀。

無伺服器運算模式

本文中描述的無伺服器運算模式主要是由雲端供應商自己開發的，或者是由客戶提供指導和反饋，說明什麼樣的服務會更有吸引力（因此值得更高的價格溢價）。無論您使用的是專有的單一雲端服務還是自行託管解決方案，雲端供應商都可以為組態和執行無伺服器應用程式提供一個有吸引力的環境。

**圖表翻譯：**此圖示呈現了雲端供應商如何透過銷售對運算和儲存服務的存取權來運作。他們提供各種服務，包括虛擬機器、Blob 儲存、資料函式庫和訊息佇列，並且透過多工存取底層硬體來提高資源利用率。

內容解密：

這段程式碼使用 Plantuml 語法建立了一個簡單的有向圖，用於展示雲端供應商如何營運及其提供的服務。主要節點包括雲端供應商、運算和儲存服務，以及各種具體的服務型別如虛擬機器和資料函式庫。圖表清晰地表達了雲端供應商透過多工底層硬體來提高資源利用率的概念。

雲原生技術與Kubernetes的演進

雲端供應商最初提供的運算服務，是將實體硬體虛擬化的基礎設施即服務（IaaS）。然而，人們很快意識到，維護網路和作業系統的大部分工作是重複且適合自動化的。理想的解決方案是使用容器作為佈署軟體的可重複方式，在批次管理的Linux作業系統上執行，並具備「剛好足夠」的網路連線，以私密連線容器而不將其暴露在整個網際網路中。

Kubernetes的崛起

多家新創公司嘗試在這個領域建立解決方案，但最終由Google引入並由Red Hat、IBM等貢獻的技術——Kubernetes——勝出。Kubernetes不僅在技術上具有優勢，其成功更歸功於圍繞該專案形成的生態系統。

Kubernetes被捐贈給中立的基金會（雲原生計算基金會，CNCF），並很快與其他基礎專案（如gRPC和可觀察性框架、容器封裝、資料函式庫、反向代理和服務網格專案）整合。儘管CNCF是一個廠商中立的基金會，但它和其成員有效地宣傳和行銷這套技術，贏得了關注和開發者的青睞。到2019年，Kubernetes + Linux的組合已成為許多組織的首選基礎設施容器平台。

Kubernetes的演進與雲原生技術

自那時以來，Kubernetes已經演變成一個通用系統，用於透過標準化和可擴充套件的API模型控制基礎設施系統。Kubernetes API模型根據自定義資源定義（CRDs）和基礎設施控制器，這些控制器觀察世界狀態並嘗試調整世界以匹配儲存在Kubernetes API中的期望狀態。這個過程稱為調解，當正確實施時，可以實作比集中式協調模型更簡單、更具彈性和自我修復能力的系統。

與Kubernetes和其他CNCF專案相關的技術被稱為「雲原生」技術，無論它們是在雲端供應商的虛擬機器上還是在使用者組織內部的實體或虛擬硬體上實作。這些技術的關鍵特徵是，它們被明確設計為在半可靠的電腦和網路叢集上執行，並能夠優雅地處理個別硬體故障，同時保持對使用者的可用性。

無伺服器技術的興起

在過去五年中，許多雲端供應商的技術被重新命名為「無伺服器」，但這個術語最初指的是簡化開發者服務佈署的一組雲端託管技術。無伺服器技術分為兩個主要類別：後端即服務（BaaS）和函式即服務（FaaS）。

後端即服務（BaaS）

BaaS提供了結構化的儲存服務，具有豐富且可組態的API，用於管理客戶端的儲存狀態。這些API通常包括將小型至中型的JSON物件儲存在鍵值儲存中的機制，並在物件在伺服器上被修改時傳送裝置推播通知。API還支援定義伺服器端物件驗證、自動身份驗證和使用者管理，以及行動客戶端感知的安全規則。最流行的例子是Parse（2013年被Facebook收購，現為Meta，並在2017年開源）和Firebase（2014年被Google收購）。

然而，BaaS最終遇到了一些問題，導致其不受歡迎：

  • 大多數應用程式最終都會超出固定的功能。雖然採用BaaS可能提供初始的生產力提升，但幾乎肯定會保證未來的儲存遷移和重寫，如果應用程式變得流行。
  • 與其他儲存選項相比，BaaS既昂貴又擴充套件性有限。雖然應用程式開發者不需要管理伺服器，但許多實作架構需要單一的前端伺服器，以避免複雜的物件鎖定模型。

函式即服務（FaaS）

在FaaS模型中，應用程式開發者編寫個別的函式，這些函式在特定條件下被呼叫。FaaS可以與BaaS結合使用，以解決一些固定的功能問題，但也可以與可擴充套件的雲端供應商儲存服務結合使用，以實作更具擴充套件性的架構。在FaaS模型中，每個函式呼叫都是獨立的，甚至可以在不同的電腦上平行發生。函式呼叫之間的協調需要使用事務或鎖顯式處理，而不是像BaaS那樣由儲存API隱式處理。第一個廣泛流行的FaaS實作是AWS Lambda，於2014年推出。

FaaS內容解密：

FaaS是一種無伺服器計算模型，允許開發者編寫和佈署個別的函式，而無需管理底層基礎設施。每個函式都是獨立的，可以根據特定事件或條件觸發。這種架構提供了高度的可擴充套件性和靈活性，因為函式可以根據需求平行執行。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Knative建構無伺服器應用程式實務

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

圖表翻譯： 此圖示展示了FaaS的基本流程。當客戶端發出請求時，FaaS函式被觸發。如果滿足特定條件，則執行函式並傳回結果；否則，系統將等待事件發生。這種機制確保了系統的高效運作和資源的最佳利用。

無伺服器運算的演進與 Knative 實務

前言

無伺服器（Serverless）運算的概念自提出以來經歷了多次演變，其涵蓋的範圍從早期的後端即服務（Backend as a Service, BaaS）逐漸轉向函式即服務（Function as a Service, FaaS）。本文旨在探討無伺服器運算的核心概念、設計模式、實務挑戰及其歷史背景，並著重介紹 Knative 作為無伺服器運算平台的實作。

無伺服器運算的計費模式與多租戶架構

與傳統的基礎設施即服務（Infrastructure as a Service, IaaS）不同，雲端供應商提供的 FaaS 服務通常按照呼叫次數或函式執行時間計費，每次呼叫的最長執行時間一般限制在 5 至 15 分鐘之間。這種計費模式使得不頻繁使用的函式能夠保持極低的成本，同時對於突發性工作負載也能提供有利的計費方式。為了實作這種計費模式，雲端供應商營運多租戶平台，在相同的物理硬體上隔離不同使用者的函式，使其能夠在幾秒鐘內相繼執行。

無伺服器概念的擴充套件

大約在 2019 年，「無伺服器」一詞主要與 FaaS 相關聯，而 BaaS 則逐漸失寵。從那時起，無伺服器這一術語開始被用於非計算服務，這些服務與 FaaS 的計費模式相吻合，即僅對存取呼叫和儲存使用量收費，而非對長期執行的伺服器單位收費。本文將在第一章討論傳統伺服器運算與無伺服器運算之間的差異，並闡述無伺服器概念如何擴充套件至儲存系統和諸如視訊轉碼或 AI 影像辨識等專門服務。

本文的結構安排

本文分為四個主要部分，分別對應作者學習和理解無伺服器運算的不同階段：

第一部分：無伺服器理論基礎

  • 第一章：定義和描述無伺服器平台提供的服務。
  • 第二章：透過學習建立一個無狀態的無伺服器應用程式於 Knative 之上。
  • 第三章：探討 Knative 的實作，這是一個無伺服器計算系統。
  • 第四章：從商業價值的角度看待無伺服器運動。

第二部分：使用無伺服器進行設計

  • 第五章：將第二章的模式應用於現有應用程式。
  • 第六章：探討事件驅動架構的不同模式。
  • 第七章：專注於構建原生利用事件的無伺服器應用程式。
  • 第八章：討論可能阻礙無伺服器應用架構的模式。

第三部分：與無伺服器共存

  • 第九章：記錄了實施無伺服器架構所面臨的維運挑戰。
  • 第十章：介紹了除錯工具，用於解決日常應用程式錯誤。

第四部分：無伺服器的簡史

  • 第十一章：為無伺服器計算抽象的發展提供歷史背景。

本文使用的排版慣例

本文採用以下排版慣例：

  • 斜體字：表示新術語、URL、電子郵件地址、檔名和檔案副檔名。
  • 等寬字型：用於程式列表，以及在段落中參照程式元素，如變數或函式名稱、資料函式庫、資料型別、環境變數、陳述式和關鍵字。
  • 等寬粗體：顯示使用者應當原樣輸入的命令或其他文字。
  • 等寬斜體字：表示應當由使用者提供的值或由上下文決定的值所替換的文字。

使用程式碼範例

本文提供的補充材料（程式碼範例、練習等）可從 https://oreil.ly/BSAK-supp 下載。讀者可在程式和檔案中自由使用本文提供的範例程式碼，無需取得許可，除非複製了大量的程式碼。參照本文及範例程式碼回答問題亦無需許可，但將本文的大量範例程式碼納入產品檔案則需要取得許可。

#### 內容解密：

本文的結構安排和內容協調旨在幫助讀者深入理解無伺服器運算的概念和實踐應用。透過對 Knative 平台的探討，讀者可以掌握如何在現代雲端環境中設計和實施無伺服器應用程式。同時，本文也提供了對無伺服器架構挑戰和解決方案的全面分析，對於希望在實際工作中應用無伺服器技術的開發者和維運人員具有重要的參考價值。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。