微服務與混合雲 (二): 微服務與雲原生技術的互補性

Published in

Gemini Open Cloud 雙子星雲端

9 min readJan 9, 2021

第二章：微服務與雲原生技術的互補性

前文提要

微服務與第一章所述的各種架構（虛擬技術、容器、K8S、REST API、公有雲、API Gateway⋯⋯）原本都是獨立由不同團隊開發出來的技術，沒有一定的連帶關係。但在互聯網服務的大前題下，這些技術就有很大的互補性。一方面可以讓開發者各自獨立開發、測試、整合他們的軟體程式。另一方面，也可以讓 IT 將互聯網服務看成一堆鬆散耦合的模組 (loosely coupled modules)，能夠獨立部署和升版。最後，對使用者而言，一筆網路交易，可以在不同時空及不同地域執行。

微服務與混合雲 (一）

第一章：淺談從互聯網進化到微服務的過程

medium.com

這一章將會介紹上述各種技術的互補性。

微服務與 REST API

2007年 Steve Jobs 在 Apple MacWorld 發表 iPhone，開始智慧手機年代，締造出普羅大眾與互聯網不可分割的關係。其實智慧手機與微服務也大有關連，因為一個互聯網使用者情境 (user context)，不再綁定在一個固定的 IP，而是可以在不同時間、不同的地點完成一筆網路交易。舉例來說，一個網購行為，就可能包含了：

使用者瀏覽廠家目錄
使用者登錄
伺服器端調閱會員資訊
檢查會員有興趣之商品，存貨是否充足
購物車處理
與銀行連線，進行信用卡交易
建立交易序號
追踪出貨與送貨流程
等等⋯⋯

上述每一項都可以是獨立的微服務，不單單用戶端會在不同時空，在雲端也很可能在不同的伺服器，甚至在不同的機房進行。

然而，這筆網路交易一定要提供使用者無縫順暢的體驗，因此分散式處理 (distributed processing) 和遠端程序呼叫（英語：Remote Procedure Call，縮寫為 RPC）就變成非常的重要了。這幾十年來，其實有很多不同的 RPC 技術（如 SOAP、COBRA、DCOM、.NET 等等)，但隨著互聯網的大量需求，以及讓開發人員能快速上手的前題下，REST API 最終成為互聯網上最普遍應用的 RPC protocol。

REST 是 Representation State Transfer 的縮寫。REST 架構提供了計算系統之間，能夠相互合作、協同工作（即互操作，英語：interoperability）的能力。相對於其它種類的 RPC，例如 SOAP 或 COBRA，則是以本身所定義的操作集 (e.g. SOAP-XML)，來存取網絡上的資源。簡單來就，RESTful API 就是直接利用互聯網最流行的 HTTP 格式，定義了八種資料交換的協議 (GET, PUT, POST, DELETE…)，讓雙方的服務得以交換資訊。開發者普遍認為 REST 模式比傳統的 SOAP-XML 程序要簡單，封裝層次分明，所以越来越多的Web 服務開始採用REST風格設計，它也成為互聯網服務最普遍的 RPC 技術了。

容器與 Kubernetes

第一章已對容器技術有初步描述，簡而言之，容器對微服務的重要性，就是因為它輕盈卻又具備虛擬的本質，可提供開發人員一個完整的運行環境，讓每個微服務都可以獨立開發測試。微服務與微服務之間，最重要的協定就是 REST API，所以在整合過程也相對簡單，可以讓微服務快速上線。

針對容器的管理和調度，可以再多加一點觀察與詮釋。隨著微服務的普及，企業 IT 使用的容器數量以倍數地快速成長。為了管理各個專案下的容器生命週期（Create, read, update and delete. 縮寫為 CRUD），一個簡單而又強大的容器叢集管理工具刻不容緩，因此，Kubernetes (K8S) 應運而生。

Kubernetes 是 Google 在 2014年發布的開源軟體。2015年7月，Google 釋出了 Kubernetes 1.0 版本，並與 Linux Foundation 合作建立了 Cloud Native Computing Foundation (CNCF)，以 Kubernetes 作為種子技術，開發各種互聯網與微服務的相關技術。目前 CNCF 已有超過 250 個會員，180 個Kubernetes 認證服務提供者 (Kubernetes Certified Service Provider, KCSP)，以及超過 90 種通過認證的 Kubernetes 發行版本、託管版本和安裝工具。

Kubernetes 所提供的不只於叢集管理，它更提供了以下資源管理功能：

多專案管理 (multi-tenancy)
高可用性管理 (HA)
排程管理 (scheduling)
發放處理 (locality & affinity dispatcher)
負載均衡處理 (Load Balancer)
自動化部署及升級 (deployment & upgrade)
應用程序編排 (application orchestration)
等等⋯⋯

微服務跑在容器上，再加上 Kubernetes，可以大幅增加開發人員的生產力，也可讓 IT 有效率地管理機房資源，因此讓我們可以了解，為何雲原生在過去幾年快速成長的原因。

混合雲

嚴格來說，混合雲並不算是一種參考架構或是開發框架，它是一種 IT 利用地端私有雲之隱私資源的方便性，配合公有雲的靈活性，來達成用戶的商業要求。在理想情況下，開發人員並不需要知道服務最後會跑在哪兒，IT 可以根據用戶的需求和使用量，來決定將服務部署到公有雲或私有雲上。如此一來，企業不再需要建置自己的 IDC，就能享受到 IaaS 平台服務商的擴展性、高可用性，和穩定性。

混合雲和微服務的互補，就在於微服務架構的隔離性和 REST API 的普及，讓 IT 幾乎可以無顧慮地部署各個服務，非常方便。在使用情境上，有兩大主因讓企業 IT 會考慮用混合雲架構來部署微服務：

第一，微服務非常適合使用 DevOps 持續整合／持續部署的開發模式。假如碰上私有雲的資源問題，開發人員和維運人員都可以彈性利用公有雲以加速整合測試新版本的服務。

第二個原因是，在正式的生產環境上 (production environment)，企業 IT 不見得都有辦法能把傳統的主機應用做革新，因此，企業 IT 往往把原有的單體應用 (monolithic application) 留在私有雲的 VM 上，而將新一代面對互聯網的商業邏輯轉成微服務，跑在公有雲上。

API Gateway

本文的最後，來談一下 API Gateway。

雖然微服務有很多好處，能讓開發者增加效率，也能讓 IT 快速自動部署和更新服務。但因為微服務天性就會有很多不同的模組，會常常讓使用者呼叫某個服務，提取後台資料，感覺增加了複雜度和困擾。API Gateway 這時候就可以幫忙解決這個問題。API Gateway 提供給終端使用者一個單一接口，去呼叫多個後台的微服務。換句話說，API Gateway 是一個管理後台眾多微服務路由 (service routes) 的工具。

API Gateway 的底層架構，其實就是一個反向代理伺服器 (Reverse Proxy)，能夠讓客戶端用單一接點接到多個服務。客戶端的程式，不再需要直接呼叫各個微服務的 URL，只需要呼叫單一的 API Gateway 服務接點，搭配上一個易懂的路由名稱，就可以連接上需要的微服務。

因為 API Gateway 幾乎是微服務架構必需元件，目前市面上的 API Gateway 產品，都會加上其他功能，讓使用和管理微服務更為方便。這些功能包括了認證、授權、快取、流量管控、資安黑白名單、稽核日誌、法規遵循等等。

結語

我們認為，混合雲是大勢所趨的必然走向。新開發的商業服務，愈來愈流行採用微服務與容器架構，視需求量而可彈性地部署到混合雲架構上。Kubernetes 和 REST API 已經不只是一個叢集管理或 RPC 協議工具，而變成了實質上混合雲的標準程式部署與訊息交換架構 (Standard handshake and communication protocol)。

下一章我們將會介紹，管理微服務和混合雲的最佳實踐方案。

微服務與混合雲(三)：管理混合雲的最佳實踐

如何管理混合雲呢？本文說明導入混合雲的主要原因、建置混合雲的策略、工具的選擇，以及最佳實踐

medium.com

References:

作者介紹

符儒嘉，現為 Gemini Open Cloud 雙子星雲端的 CEO。於美國矽谷資訊軟體業工作約30 年，曾在IBM、Amdahl、Sun Micro、Interwoven任職，2009回台加入工研院雲端中心之研發團隊，擔任雲端中心關鍵計畫 Cloud OS 系統軟體開發之計畫主持人，將其在美國所累積的系統軟體開發知識與經驗，運用於 Cloud OS 之計畫執行中。

Gemini Open Cloud 雙子星雲端簡介

在NASA著名的阿波羅登月計畫之前，有個成功的前導任務「雙子星」，為人類太空旅行寫下成功的里程碑，雙子星雲端運算因而以此命名；期許雲端產品能立足台灣，放眼世界，能像NASA雙子星任務一樣的成功，為台灣的雲端產業貢獻心力，攜手軟硬體夥伴共創雲端商機。