Ray Liu's Blog

前言在 Relational Database (RDBMS) 無法支撐海量擴展與非結構化資料的時代，NoSQL 應運而生。然而，許多工程師對 NoSQL 的理解僅停留在「沒有 Schema」與「好擴張」。實際上，NoSQL 並非單一技術，而是為了解決特定場景而生的「特化型工具」。 在眾多 NoSQL 中，**MongoDB（文件型）**與 **Cassandra（寬行型）**是極具代表性的兩座大山。本文將拋開表面的 API 差異，從底層儲存引擎（WiredTiger vs LSM-Tree）、分散式架構（Raft-based Replica Set vs Masterless Ring）以及 CAP 定理的抉擇，為你深度剖析兩者的架構本質與選型策略。 一、核心架構與資料模型1. MongoDB：靈活的文件型資料庫 (Document Store)MongoDB 以 BSON（二進位 JSON）格式儲存資料，最大的優勢在於極致的開發者體驗與彈性的資料結構。 資料模型：文件導向。一筆資料可以包含深層疊套的陣列與物件（Nested Arrays/Objects），非常貼...

前言在關聯式資料庫（RDBMS）的領域中，MySQL 與 PostgreSQL 是兩大最受歡迎的開源解決方案。兩者雖然都支援標準 SQL，但在底層架構、設計理念及擅長的場景卻有著根本性的差異。本文將從核心架構、關鍵功能、效能表現，深入剖析兩者的差異，並提供實務上的選型建議。 一、設計理念與核心架構1. MySQL：以「速度」與「Web 生態」為出發點MySQL 最初的設計目標是為了支撐快速的 Web 應用（如早期 LAMP 網站）。 架構特性：採用「可插拔儲存引擎（Pluggable Storage Engine）」，預設為 InnoDB。這種架構讓 MySQL 在面對簡單的讀取和高併發寫入時，能夠有極高的吞吐量。 執行緒模型：採用 Thread-per-Connection 模型。每個連線建立一個執行緒，在處理大量輕量級短連線時佔用記憶體較少。 2. PostgreSQL：以「正確性」、「標準」為信仰PostgreSQL 標榜自己為「世界上最先進的開源關聯式資料庫」，其前身可追溯至加州大學柏克萊分校的 POSTGRES 計畫。 架構特性：它是一個物件-關聯式資料庫（OR...

前言在現代分散式系統中，當微服務的數量從個位數增長到數十個，服務之間的通訊方式若仍依賴同步 REST API，系統將面臨嚴峻的「耦合性（Coupling）」與「級聯故障（Cascading Failure）」風險：任何一個下游服務的抖動，都可能沿著呼叫鏈蔓延至整個系統。 Apache Kafka 正是為了解決這個核心問題而生。它是一個以「持久化、高吞吐、分割區（Partitioned）、事件日誌（Log）」為核心設計哲學的分散式串流平台（Distributed Streaming Platform），讓生產者（Producer）與消費者（Consumer）能夠完全解耦，各自以最適合的速率運作。 然而，Kafka 強大能力的背後，伴隨著遠比 REST API 複雜的運維複雜度。本文將以架構師 → 後端工程師 → DevOps/SRE 三個視角，深度解析 Kafka 在 AWS 微服務環境中的實戰場景、常見災難與應對策略。 📖 本文架構導覽 層次 主題 Part 1：部署選型 EC2/ECS/EKS 環境的 Kafka 部署模式選擇 P...

前言當系統從單體架構走向微服務（Microservices），並部署在動態的雲端環境（如 AWS EC2、ECS 或 EKS）中時，**「無狀態（Stateless）」與「水平擴展（Scale-out）」**成為了架構設計的顯學。在這樣的環境下，Redis 不僅僅是快取，更是撐起微服務之間狀態共享、限流、併發控制與事件驅動的核心骨幹。 然而，當 Redis 運行在真實的高流量生產環境加上複雜的網路拓樸中時，往往會衍生出許多教科書上沒寫的「痛點」。本文將依循架構師 → 後端工程師 → DevOps/SRE 三個視角，深度解析 Redis 在 AWS 微服務環境下的經典場景、常見災難以及對應的解決方案。 📖 本文架構導覽 層次 主題 Part 1：部署選型 EC2/ECS/EKS 環境的 Redis 部署模式選擇 Part 2：實戰場景 Session、快取、分散式鎖、事件佇列 Part 3：架構師視角 命名規範、選型決策、快取一致性、讀寫分離 Part 4：後端工程師視角 Bloom Filter、Lua Script、Pip...

在生產環境中，日誌管理是系統穩定性與可維護性的關鍵基石。一個配置不當的日誌系統可能導致磁碟空間爆滿、系統崩潰,甚至影響業務運作。本文將深入探討 Docker、PM2 以及 Go、Node.js、Python 等常見運行環境的日誌管理最佳實踐,幫助你避免「日誌爆炸」的災難。 為什麼日誌管理如此重要?在生產環境中,日誌管理不當可能導致以下問題: 磁碟空間耗盡: 未限制的日誌檔案會持續增長,最終佔滿磁碟空間 系統效能下降: 過度的日誌寫入會影響 I/O 效能 除錯困難: 日誌過多或過少都會影響問題排查效率 合規風險: 敏感資訊洩漏或日誌保存期限不符合規範 [!IMPORTANT]生產環境的日誌策略應該在可觀測性與資源消耗之間取得平衡。過多的日誌會浪費資源,過少的日誌則無法有效除錯。 Docker 日誌管理Docker 日誌驅動概述Docker 支援多種日誌驅動 (Logging Driver),每種驅動適用於不同的場景: 驅動名稱 適用場景 優點 缺點 json-file 本地開發、小型部署 預設驅動、簡單易用 需手動管理日誌輪替 syslog 集...

前言經過前五篇的學習，你已經掌握了 Kubernetes 的核心概念。本篇將綜合運用這些知識，完成一個完整微服務應用的部署： 設計應用架構 使用 Helm 簡化部署 多環境配置管理 日誌與監控整合 常見問題排除 讓我們開始真正的實戰！ 應用架構設計範例應用：電商平台我們將部署一個簡化版的電商微服務系統： graph TD USER[使用者] -->|HTTPS| ING[Ingress] ING --> GW[API Gateway] GW --> USVC[User Service] GW --> PSVC[Product Service] GW --> OSVC[Order Service] USVC --> REDIS[(Redis)] PSVC --> PDB[(PostgreSQL<br/>Products)] OSVC --> ODB[(PostgreSQL<br/>Orders)] OSVC --> M...

前言當應用程式部署到 K8s 後，如何確保它穩定運行且高效利用資源？本篇將探討： 資源管理：設定 CPU 和記憶體的請求與限制 自動擴展：根據負載自動調整 Pod 數量 調度策略：控制 Pod 在哪些節點上運行 健康檢查：確保只有健康的 Pod 接收流量 這些是生產環境部署的必備知識。 資源管理：Requests 與 Limits為什麼需要資源管理？沒有資源限制的情況下： 某個 Pod 可能消耗所有 CPU/記憶體 導致其他 Pod 無法正常運行 節點可能因 OOM（Out of Memory）崩潰 graph TD subgraph "沒有限制" A[Pod A] -->|佔用 80% CPU| N1[Node] B[Pod B] -->|飢餓| N1 C[Pod C] -->|飢餓| N1 end subgraph "有限制" D[Pod A: 限制 30%] --> N2[Node] ...

前言應用程式除了程式碼本身，還需要配置資訊（如資料庫連線設定）、敏感資訊（如密碼）以及資料持久化。Kubernetes 提供了完整的解決方案： ConfigMap：管理非敏感配置 Secret：管理敏感資訊 Volume：提供資料儲存 本篇將深入探討這些資源的使用方式和最佳實踐。 ConfigMap：配置管理為什麼需要 ConfigMap？在容器化之前，我們可能這樣管理配置： 配置寫在程式碼裡（❌ 難以修改） 使用環境變數（✅ 但不易管理） 使用配置檔案（✅ 但需要掛載） ConfigMap 統一解決這些問題，將配置與容器映像檔分離。 graph LR CM[ConfigMap] -->|環境變數| POD1[Pod] CM -->|掛載檔案| POD2[Pod] CM -->|命令列參數| POD3[Pod] 創建 ConfigMap方法一：從文字值創建1234kubectl create configmap app-config \ --from-literal=DATABASE_HOST=db.example.co...

前言上一篇介紹了 Pod、Deployment 與 Service 的基本角色，但「有一個 Service」和「封包真的走得通」是兩件不同的事。本篇不再把網路元件當成名詞表，而是從一個 Pod 內的 localhost 開始，逐層追蹤封包如何走到另一個 Pod。 你會看到 network namespace、veth pair、Node routing、CNI、EndpointSlice、Service VIP 與 CoreDNS 各自負責哪一段。不同叢集可能使用 overlay、雲端 VPC 原生路由、eBPF 或其他資料平面，但 Kubernetes 對使用者提供的抽象仍然可以用同一套問題來理解：誰在查名字？誰在選後端？誰在搬封包？誰在阻擋封包？ 本篇完成後，你應該能回答： 同一個 Pod 裡的兩個 container，為什麼可以用 localhost 互相呼叫？ Pod A 直接連 Pod B 的 Pod IP，和連 Service 的 ClusterIP 有什麼不同？ 同節點與跨節點的封包，通常會經過哪些網路介面與路由？ CoreDNS 為什麼只參與 DNS loo...

前言上一篇文章介紹了 Kubernetes 的控制平面與節點元件。本篇把焦點移到「應用程式到底要如何在叢集中運行」：你要部署的是可替換的 Web API、需要固定身份的資料服務、每台節點都要有一份的 agent，還是跑完就結束的批次工作？ Kubernetes 的 Workload 資源不是一堆互相獨立的 YAML 名詞，而是不同的生命週期模型。讀完本篇，你應該能先選對資源，再從 Pod、Controller、節點與容器四個層次判斷「誰會重啟、誰會補 Pod，以及為什麼」。 本篇會用幾個可以直接套用到測試叢集的實驗，觀察 Deployment 的滾動更新、StatefulSet 的固定身份、DaemonSet 隨節點變化的行為，以及 Job/CronJob 的完成與重試。為了讓主題保持集中，Service 只保留必要基礎；CoreDNS、EndpointSlice、CNI、L4/L7 與 Ingress 的封包路徑留到後續網路篇深入拆解。 實驗假設你已經有可使用的 Kubernetes 叢集與 kubectl。除非特別說明，以下資源都放在目前 conte...