前一天的最後，我先談到了微服務架構，而今天就要把這個架構裡的各個 container 與服務角色再說得更清楚一些。

之所以要特別說明服務內容，是因為若沒有先理解現有服務由哪些元件組成、request 如何流動，以及各服務之間如何運作，就直接開始撰寫 Kubernetes 設定，後面在實際部署時很容易會需要一直不斷地調整，而默默地增加了許多工時。

先把現行架構釐清清楚，也會有助於後續 Kubernetes 資源的規劃，例如 Namespace 要如何切分、Deployment 的設定與環境變數要怎麼安排、Service 甚麼模式，以及未來 Istio Service Mesh 的設計，都需要先知道服務的責任、流量方向與外部依賴，才有辦法做出合理設計。

當然，實務上很難在一開始就把整個系統百分之百摸清楚，也不可能保證 Kubernetes 能一次就規劃完、部署完。實際部署過程中，仍可能才發現某個設定檔、route 或外部服務需求原本沒有被注意到，只能一邊部署、一邊補充調整，這都是正常的，但我們可以先盡量降低這些意外發現與設計錯誤的成本。因此在開始部署 Kubernetes 之前，現行架構能摸得多清楚，就應該先摸得多清楚。

各服務的角色

以下就來說明各項微服務所使用的技術、功能：

• portal-web

  • Portal 的 SPA root，也是使用者進入系統時的主要入口。
  • 使用 Nginx 作為站台運行底層服務，負責提供 SPA 的靜態檔案。
  • SPA 的 fallback 也由 Nginx 處理。

• frontend-a、frontend-b

  • 分別負責不同主功能的 SPA 前端。
  • 兩個前端都以 Nginx 作為 container 內的 Web server。
  • 前端不直接呼叫後端 API，而是透過 API Gateway 存取服務。

• api-gateway

  • 後端 API 的統一入口，依 route 規則轉送 request 到對應後端 API。
  • 集中處理 path rewrite、authentication、header、timeout 與錯誤狀態回應。

• api-a、api-b

  • 一律採用 ASP.NET Core WebAPI。
  • 分別承擔不同的後端商業功能，並以 HTTP API 對外提供服務。
  • 某些情境下，後端 API 也可能再呼叫另一個後端 API，也就是 east-west 東西向流量。

Request 的流向

前端 API request 會先送到 api-gateway，再由制定好的 route 規則決定要送到哪一個後端 API，例如：

/api/a/*  → api-a
/api/b/*  → api-b

route 通常不只比對 path，也可能根據 host、HTTP method、header 或登入身分決定處理方式，也是設計 Istio Service Mesh 至關重要的內容。

Stateless 為什麼會使遷移更容易

這些 container 的共同特性是 stateless，任何資料、狀態（例如登入 Session）都不會保存在 container 本地，而是交給外部 DB、Redis、遠端共用資料夾等。服務被重建、擴縮或更新時，container 直接依原本的流程去啟動服務，基本上就可以正常運作。

對這類架構來說，遷移到 Kubernetes 時，可以先把原本的 container 對應成 Pod（先不提 Pod 內有兩顆以上的 Container ），再透過 Deployment 管理 Pod 的建立與更新，並使用 Service 提供穩定的服務入口。

原本放在環境設定裡的內容，則可以整理到 ConfigMap 或 Secret，只要網路、DNS、防火牆、帳號權限與外部服務連線條件都已準備好，Pod 啟動後通常就能依照原本的設定，連接外部 DB、SMB 或其他服務。

這也是 stateless 架構讓遷移速度比較快的原因，容器本身沒有需要另外搬移的本地資料，也沒有特殊的啟動狀態需要保存，只要 image、設定與連線條件正確，要將容器放到另一台主機，或是部署到 Kubernetes 內變成 Pod，兩個情境基本上都能順利運作。當然還是要提一下，所謂的容易還是建立在外部相關服務已可連線、設定值正確的情況，該驗證的還是要驗證，也不一定每個容器服務都這麼順利 XD

這樣的特性也會讓後續的 Kubernetes 在維運 Pod 時比較單純。未來要進行 autoscaling、rolling update、Pod 重建或版本更新時，不必先擔心每一個新 Pod 是否會遺失原本的業務狀態；只要 Deployment、Service、ConfigMap、Secret 與 Probe 設定正確，就能把關注點放在 Pod 是否正常建立、是否能連到外部服務，以及新舊版本切換是否符合預期。

微服務帶來的彈性與代價

再說明一下微服務的優點與缺點，畢竟微服務在維運的概念上，跟傳統單體式服務還是有蠻大的區別，
切得多，理想上就能讓服務更好管控，就像是程式開發一樣，Function 抽得乾淨，關注點分離就會被實現得好，SOLID 的 OCP（開放封閉原則）也更容易實現，
但是複雜起來就會覺得東西開始分散了，而且如果邊界控制不好，不小心將 A 邏輯丟到 B 服務裡，久了就變成災難了 😇

微服務帶來的優點包括：

• 服務可獨立部署、更新與擴縮。
• 某個功能服務故障時，影響範圍可能較小或比較好控制。
• 更精確的前端與後端責任分工（Infra 人員表示：嗯👀？）。
• 容器邊界更清楚後，逐步遷移到 Kubernetes 較容易規劃。

而相對應的代價是：

• API 版本相容、端對端測試會變得更複雜。
• log、metrics、trace 與告警必須能跨服務關聯起來，才能排查問題，Trace Bug 變得相對不容易或是要花更多時間在看不同容器。
• 服務越多，設定、權限、部署順序與維運溝通的成本也越高。

本日結論

今天主要詳細說明了本次鐵人賽文章所要部署到 K8s 內的微服務架構，包括前端的 Portal 與功能前端、API Gateway，以及後端的各個服務與外部依賴，也簡單了說明一下 Stateless、微服務架構的優缺點，以及後續遷移到 K8s 會有甚麼影響。

接著從下一篇開始就會正式進入 Kubernetes 主題。我會先從 Kubernetes 的核心元件開始，例如 API Server、Controller 與 Scheduler 等等的 K8s 底層服務，先理解 Control plane 如何協調整個叢集，接著再逐一介紹最主要的資源，包含 Deployment、Service、ConfigMap、Secret 等。

當說明完這些核心元件與資源後，再回頭把今天介紹的微服務架構逐一對應到這些 Kubernetes 資源，思考每個 container 該如何規劃成 Deployment、Service，以及還需要哪些設定、權限、網路或是其他維運服務，慢慢把把目前的容器化服務，逐步建立成 Kubernetes 版本的架構。