摘要：建構雲端原生應用程式

以下是本指南重要結論摘要：

• 雲端原生是關於在現代化的動態環境中，例如公用、私人和混合式雲端，設計擁有快速變更、大規模和復原能力的現代化應用程式。

• Cloud Native Computing Foundation (CNCF) 是集結了 300 多家大公司，具有影響力的開放原始碼聯盟。 負責推動跨技術和雲端堆疊採用雲端原生運算。

• 如圖 11-1 所示，CNCF 指導建議雲端原生應用程式採用六大要素：

  

  圖 11-1。 雲端原生基礎要素

• 這些雲端原生要素包括：

  • 雲端及其基礎服務模型
  • 新式設計原則
  • 微服務
  • 容器化和容器協調流程
  • 雲端式支援服務，例如資料庫和訊息代理程式
  • 自動化，包括基礎結構即程式碼和程式碼部署

• Kubernetes 是大多數雲端原生應用程式會選擇的裝載環境。 較小型的簡單服務有時會裝載於無伺服器平臺，例如 Azure Functions。 在許多重要的自動化功能中，這兩個環境都會提供自動擴縮以處理變動的工作負載磁碟區。

• 建構雲端原生應用程式時，服務通訊會成為重要的設計決策。 應用程式一般會公開 API 閘道以管理前端用戶端通訊。 然後，後端微服務會盡可能互相努力通訊，以實作非同步通訊模式。

• gRPC 是現代化的高效能架構，可使歷史悠久的遠端程序呼叫 (RPC) 通訊協定進化。 雲端原生應用程式通常採用 gRPC 以簡化後端服務之間的傳訊。 gRPC 使用 HTTP/2 作為傳輸通訊協定。 相較於 JSON 序列化，其速度最快可達 8 倍，訊息大小卻小了 60-80%。 gRPC 是由 Cloud Native Computing Foundation (CNCF) 管理的開放原始碼。

• 分散式資料通常是雲端原生應用程式實作的模型。 應用程式會將商務功能分隔成小型的獨立微服務。 每項微服務都會封裝自己的相依性、資料和狀態。 傳統共用資料庫模型會進化成許多較小資料庫的其中之一，每個都與微服務一致。 當結果出現後，我們會公開 database-per-microservice 模型的設計。

• No-SQL 資料庫是指高效能的非關聯式資料存放區。 具備容易使用、可擴縮性、復原和可用性等特性。 需要不到一秒回應時間的大量服務偏好 NoSQL 資料存放區。 分散式雲端原生系統的 NoSQL 技術激增並非誇大。

• NewSQL 是一種新興的資料庫技術，結合了 NoSQL 的分散式可擴縮性和關聯式資料庫的 ACID 保證。 NewSQL 資料庫的目標，是必須跨分散式環境處理大量資料，且完全符合完整交易/ACID 規範的商務系統。 Cloud Native Computing Foundation (CNCF) 有數個 NewSQL 資料庫專案。

• 復原是系統在回應失敗時仍能正常運作的能力。 雲端原生系統採用失敗無可避免的分散式架構。 應用程式必須建構成能簡潔回應失敗，並快速回復完全正常運作的狀態。

• 服務網格是可設定的基礎結構層，具有可處理服務通訊和其他跨領域挑戰的內建功能。 其會分離跨領域責任與您的商務程式碼。 這些責任會移至服務 Proxy。 Proxy 會部署到個別的流程 (稱為 Sidecar pattern)，以與您的商務程式碼隔離。

• 可檢視性是雲端原生應用程式的重要設計考量。 當服務分散到節點叢集時，集中化的記錄、監視和警示就會變成必要。 Azure 監視器是雲端式工具的集合，旨在讓您了解系統的狀態。

• 基礎結構即程式碼是廣為大眾接受的做法，可將平台佈建自動化。 您的基礎結構和部署是自動化、一致且可重複的。 Azure Resource Manager、Terraform 和 Azure CLI 等工具，可讓您以宣告方式編寫所需雲端基礎結構的指令碼。

• 程式碼自動化是雲端原生應用程式的需求。 新式 CI/CD 系統有助實現此原則。 其分別提供建置和部署步驟，以協助確保一致且高品質的程式碼。 此建置階段會將程式碼轉換為二進位成品。 發行階段會挑選二進位成品、套用外部環境組態，並將其部署至指定的環境。 Azure DevOps 和 GitHub 是功能完整的 DevOps 環境。