瞭解微服務架構

現代應用程式透過組成一些獨立建構的服務而建構。這可為修正問題及引進新功能提供靈活度與上市速度。

此範例稱為微服務架構，雖然完整應用程式所提供的服務數目可以介於數百個 (微服務) 或數十個 (巨集服務) 中。有一些新名詞也用於稱為模數的模組化單體，而 Spring Modulith 則是這類範例。

雖然許多組織已經擁有微服務架構，但微服務部署具有複雜性，而且成功的部署仍在大多數組織中工作。此解決方案手冊嘗試使用熱門的 Spring Boot 平台，以及搭配 Oracle Database 的雲端基礎架構、容器、Kubernetes 和後端即服務平台，簡化現代微服務的建置和部署。

如果您想要設計一個多語言、可輕鬆擴展、易於維護和部署、高度可用的應用程式，並將失敗次數降到最低，請使用微服務架構來設計和部署雲端應用程式。在微服務架構中，每個微服務都擁有簡單的工作，並且使用輕量型通訊機制 (例如 REST API 要求) 與用戶端或其他微服務進行通訊。

下圖顯示由多個微服務組成的應用程式架構。

microservice_architecture.png 圖解說明

微服務可讓您將應用程式設計為鬆散耦合服務的集合。微服務會遵循共用無內容模型，並以無狀態程序執行。此方法可讓您輕鬆調整及維護應用程式。

API 層是微服務之所有用戶端要求的進入點。API 層也可讓微服務透過 HTTP、gRPC 及 TCP/UDP 彼此相互通訊。
邏輯層著重於單一業務任務，將其他微服務的相依性降到最低。此圖層可針對每個微服務以不同的語言撰寫。
資料存放區層提供持續性機制，例如資料庫儲存引擎、日誌檔等等。請考慮為每個微服務使用個別的永久資料存放區。Oracle 提供具有多個可插拔資料庫的資料庫容器，讓微服務能夠輕鬆隔離資料，以達到安全性、高可用性及擴充性。此外，SaaS 應用程式也可以安全地利用多租用戶。此外，融合式資料庫可在單一屋頂下提供各種資料，以獲得更豐富的資料洞察力。

一般而言，每個微服務都會在提供輕量型程式實際執行環境的容器中執行。

微服務與單體式架構之間的差異

開始使用微服務架構設計應用程式之前，您必須瞭解此架構與傳統單體架構有何不同。

應用程式設計著重於解決業務需求及導入業務邏輯。在單體式架構中，整個應用程式都是以包含所有商業邏輯的單一單元形式建置。在微服務架構中，業務邏輯組織為多個鬆散耦合服務。

下圖顯示單體式與微服務架構。

monolithic_vs_microservice.png 圖解說明

下表概述微服務與單體式架構之間的差異。

特性	微服務架構	單石架構
單位設計	應用程式由鬆散耦合服務所組成。每個服務都支援單一業務任務。	整個應用程式都是設計、開發和部署為單一單元。
功能重複使用	微服務定義了向任何用戶端公開其功能的 API。用戶端甚至可以是其他應用程式。	跨應用程式重複使用功能的機會有限。
應用程式內的通訊	若要彼此通訊，應用程式的微服務會使用要求回應通訊模型。一般實作會根據 HTTP 通訊協定使用 REST API 呼叫。	內部程序 (函數呼叫) 可促進應用程式元件之間的通訊。不需要限制內部程序呼叫的數目。
技術彈性	每個微服務都可以使用最適合微服務所設計解決問題的程式設計語言和架構來開發。	通常，整個應用程式都是以單一程式設計語言撰寫。
資料管理	分散式：每個微服務都可以使用自己的資料庫。	集中化：整個應用程式使用一或多個資料庫。
部署	每個微服務都會獨立部署，而不會影響應用程式中的其他微服務。	不過，任何變更都需要重新部署和重新啟動整個應用程式。
可維護性	微服務簡單、專注且獨立。因此，應用程式容易維護。	隨著應用程式範圍的增加，維護程式碼會變得更加複雜。
復原能力	應用程式功能會分散至多個服務。如果微服務失敗，則其他微服務所提供的功能會繼續可供使用。	任何元件若失敗，可能會影響整個應用程式的使用狀態。
擴展性	每個微服務都可以獨立調整為其他服務。	即使商業需求僅用於擴展應用程式的特定部分，仍必須調整整個應用程式。

採用微服務架構的考量

設計新應用程式時，請考量需要高擴展性、彈性及可靠性的應用程式微服務架構。您可以使用不同的程式設計語言和架構來開發每個元件。

如果您可以將應用程式的功能分成特定服務 (每個服務範圍有限)，請考慮將單一應用程式移轉至微服務。對於無法移轉至微服務架構的複雜單體式應用程式，請考慮僅開發新功能作為微服務。

服務之間的相互相依性會影響服務重新部署期間無法使用的應用程式數量。在應用程式設計期間解決任何這類相依性問題。

重製單體式應用程式相當困難。如果您想要使用微服務架構，請從專案開始進行規劃。

開發微服務時，請考量分散式系統的複雜性，並記住遠端呼叫速度緩慢且可能失敗。根據使用案例的不同，您必須在一致性、可用性和分割區容錯之間取得平衡。

為微服務架構所涉及的作業複雜性做好準備。在將單體式應用程式移至微服務架構之前，建議您先滿足下列先決條件：

快速佈建：可快速佈建伺服器
基本監控：能夠偵測服務問題和業務問題。服務問題包括服務可用性、功能錯誤和效能問題
快速的應用程式部署：可快速將任何服務部署到測試和生產環境

確保微服務架構的優點超出成本。

關於微服務架構中的通訊機制

在微服務架構中，服務會在多部伺服器上執行。這些服務之間的通訊會透過 HTTP、AMQP 和 TCP 等協定進行。HTTP/REST 和非同步訊息傳遞是最廣泛使用的協定。

Web 服務的 REST API 通常使用 HTTP 通訊協定。透過 HTTP 方法 (例如 GET、POST、PUT 以及 DELETE)，用戶端可以使用統一的資源定位器 (URL)，來存取和操控應用程式資源。

從屬端會透過代表應用程式功能之進入點的 REST API 將要求傳送給服務。用戶端可以直接或透過 API 閘道與微服務通訊。

API 閘道樣式會為對服務的所有要求定義單一進入點。當從屬端要求到達時，API 閘道會將要求遞送至適當的服務。

API 閘道樣式的變化形式是前端後端樣式，此樣式會為每種從屬端定義個別的 API 閘道 (例如，行動從屬端的一個閘道，以及 Web 應用程式的另一個閘道)。

建議做法是將服務之間的通訊降到最低。當通訊至關重要時，建議使用非同步通訊。傳送要求的服務可以在不等待回應的情況下繼續運作。

訊息佇列和串流系統是提供非同步通訊的理想方法，當整合至資料庫時，它們會為資料作業和傳送訊息提供交易語意。這使得微服務變得更簡單且更具擴展性，可進行部署。使用 REST API 專門讓微服務之間的通訊同步，而且通常會限制擴展。

關於必要服務與角色

此解決方案需要下列服務：

Oracle Cloud Infrastructure Database (包含 Oracle Autonomous Database 的各種選擇)
Oracle Cloud Infrastructure Container Engine for Kubernetes
Oracle Backend for Spring Boot and Microservices

這些是每項服務所需的角色。

服務名稱：角色	需要 ...
Oracle Cloud Infrastructure Database ：`SYSTEM` 或 `ADMIN`	設定 Oracle Backend for Spring Boot and Microservices 時，建立使用者以代理資料庫存取。雖然 `SYSTEM` 或 `ADMIN` 可運作，但其權限過高，不應用於生產環境中。
Oracle Cloud Infrastructure Container Engine for Kubernetes :`CLUSTER_MANAGE`	建立 Oracle Cloud Infrastructure Container Engine for Kubernetes 叢集，以及一個含有三個工作節點的節點集區。
Oracle Backend for Spring Boot and Microservices:`ROLE_ADMIN`	安裝 Oracle Backend for Spring Boot and Microservices。

請參閱 Oracle 產品、解決方案和服務，以瞭解您的需求。