延續昨天的規劃，我們進入專案實作階段。接下來將透過實際的專案搭建，帶領各位理解每個技術選擇背後的設計思維與維運考量，幫助讀者更清楚地掌握專案落地過程中需要經歷與思考的重點。

技術選型

在資料平台規劃中，核心組件 Kafka 的部署至少有四種方案：

1. 實機安裝 Kafka（裸機 / VM）

• 抽象層級：最低，貼近硬體與作業系統。
• 技術基礎：OS、網路、磁碟 I/O、Kafka 配置。
• 維運影響：升級、監控與擴容需人工操作。
• 穩定性：高度可控，但操作錯誤或環境差異可能造成問題。
• 適合場景：追求極高穩定性，並且熟悉 Kafka 內部運作、精細效能調校。

2. Docker Image 部署 Kafka

• 抽象層級：中等，透過容器封裝部署細節。
• 技術基礎：Docker、容器網路與卷管理。
• 維運影響：可快速重建環境，但升級與監控仍需手動處理。
• 穩定性：比裸機更穩定，易於複製。
• 適合場景：對環境遷移有需求、開發測試、快速迭代。

3. Helm Chart 部署 Kafka（Bitnami Kafka）

• 抽象層級：中高，透過 Helm 封裝部署邏輯與設定。
• 技術基礎：Helm、Kubernetes、values.yaml 設計。
• 維運影響：支持快速安裝、升級與回滾，但仍需理解資源配置與持久化卷。
• 穩定性：比 Docker 更易於管理與擴展。
• 適合場景：跨團隊部署、可復用的模板化部署。

4. Operator 部署 Kafka（Strimzi Kafka Operator）

• 抽象層級：最高，完全宣告式管理 Kafka。
• 技術基礎：Kubernetes、CRD、Operator 模型與 Cluster Operator。
• 維運影響：自動升級、擴容、錯誤修復，手動干預最少。
• 穩定性：高度依賴 Operator 成熟度，長期運維成本低。
• 適合場景：多環境雲端部署、高度抽象的可操作運維。

技術選型對比表

在選擇部署方案時，需要考慮專案上線時程、技術基礎（避免技術債）、維運負擔（團隊人力與服務負荷）等因素。在本系列中，我們選擇使用 Strimzi Operator 進行 Kafka 部署。

Kafka Connect 實作方案

在確認 Kafka 部署方案後，下一步是思考如何將資料從 Source DB（如 MySQL） 可靠地傳入 Kafka，以及從 Kafka 推送到下游消費端。

根據 官方文件，Kafka Connect 提供了一個框架，實際的資料連接則需透過程式或 Connector 實現。我們可選擇的方案包括：

1. 自行實作生產者與消費者程式

   • 完全自定義資料處理邏輯，可依需求調整資料結構與處理流程。
   • 優點：高度可控、靈活性最大。
   • 缺點：維運與擴展需自行管理，開發成本較高，容易產生技術債。

2. 使用實機或 Docker Image 部署 Kafka，並上傳程式後透過 bin/connect-distributed.sh 啟動

   • 適合小規模測試或 PoC（Proof of Concept）。
   • 部署與升級仍需手動處理，擴展性與自動化較低。

3. 使用已封裝好的 Docker Image（如 Debezium Connect）

   • 官方提供的 Debezium Connect Image 可直接連接 MySQL 等資料庫。
   • 降低自建環境與 Connector 設定的難度，快速啟動。
   • 技術細節：Image 內部透過 connect-base 設定 Kafka Connect server 相關配置，最終執行 bin/connect-distributed.sh 啟動服務。

4. 透過 Strimzi Operator 管理 Kafka Connect 並使用封裝好的 Debezium Connect 部署

   • Operator 負責 Connector 的生命週期管理，包括創建、升級、擴容、錯誤修復。
   • 適合生產環境與多環境部署，維運成本最低。
   • 啟動流程：Kafka Connect server 啟動後，透過啟用插件（自建或現成 Connector）來建立資料流連接器，實現 Source DB 與 Kafka 的資料同步。

閱讀 Debezium Connect 的 Dockerfile，可以清楚看到啟動流程與設定邏輯：本質上仍是透過 connect-distributed.sh 啟動 Kafka Connect Server，只是將環境與依賴封裝在 Image 中，降低部署複雜度。

為了方便統一管理、提升自動化程度與穩定性，我們在本系列中選擇 同樣採用 Strimzi Operator 進行部署。這不僅與 Kafka 集群的管理方式一致，也能確保 Connector 的生命週期、配置管理與監控流程統一，為後續端到端資料流管線的建置奠定穩固基礎。

專案基礎設置

有了前面 Kafka 與 Kafka Connect 部署方案的基礎，我們可以利用 Strimzi 提供的範例進行專案的初步設置：

• Strimzi Operator：helm3/strimzi-kafka-operator
• Kafka Cluster（Ephemeral 模式）：kafka-ephemeral.yaml
• Kafka Connect Cluster：kafka-connect.yaml
• Kafka Connector（Source / Sink 範例）：source-connector.yaml

基於這些範例，我們可以整理專案目錄，完成基本架構如下：

dataplatfomr-poc/
├── docker/                   
│   └── dockerfile             # kafka connect image
│
├── kafka/                    
│   ├── strimzi.yml            # Strimzi Operator Helm 安裝參數
│   ├── kafka-ephemeral.yml    # Kafka Cluster 設定（Ephemeral 模式）
│   ├── kafka-connect.yml      # Kafka Connect Cluster 設定
│   ├── topic.yml              # Kafka Topic 建立設定
│   ├── mysql-debezium-connector.yaml  # Source Connector (Debezium)
│   └── jdbc-sink-connector.yml        # Sink Connector (JDBC Sink)
│
├── mysql/                    
│   ├── configmap-init.yml     # 初始化 SQL 腳本
│   ├── configmap-mycnf.yml    # MySQL 配置（my.cnf）
│   └── deployment.yml         # MySQL Deployment 與 Service
│
├── target-db/                
│   └── target-mysql.yml       # Sink MySQL (目標資料庫) Deployment 定義
│
├── terraform/                
│   ├── main.tf                # 建立 Namespace 或其他 k8s 資源
│   └── variables.tf
│
├── scripts/
│   └── deploy-all.sh          # 一鍵部署腳本 (Terraform + K8s)
│
└── README.md                  # 專案文件與操作說明

可以看到，與昨天規劃的內容相比，目錄結構有了不少調整。這正是專案落地與敏捷開發過程中的常態：需求變化、技術選型或環境配置，往往會引導架構持續迭代與優化。

小結:

今天帶領各位實際進行專案的搭建，並根據需求進行資源探索與技術選型。這部分雖然在多數分享中常被忽略，卻是我認為 DevOps 工作中最關鍵、也最能體現專業價值的一環。

隨著軟體開發的成熟與生態系的豐富，未來利用開源專案或內部既有程式碼來快速建構服務，將會成為主流。而在生成式 AI 不斷進步的今日，DevOps 的角色正從 IaC、SRE，逐漸邁向平台化與人機協作的整合設計者。

面對愈趨多元的資源（包括 AI 生成內容），DevOps 不僅要會「使用服務」，更要懂得 逆向理解技術原理──能夠閱讀 source code、查閱技術文件、分析配置邏輯，並進一步驗證、測試生成內容的正確性與可用性。這正是新時代工程師的核心競爭力所在。

也因此，這一階段我選擇不再只是提供一個可直接運行的 PoC，而是 帶領大家從零開始，實際搭建一個能被團隊理解、擴充、共享的專案。我相信，比起「知道服務能做什麼」，更重要的是「知道如何讓服務成為團隊能共用的架構基石」。
這樣的思維，也逐漸趨近於 vibe coding 或 spec-driven development 的理念。

為了讓持續閱讀的朋友不感到混亂，我已調整 Day27 的內容──
最後四天的「整合篇」將從「帶領使用 PoC 驗證」改為「帶領實際搭建專案並進行驗證」。

感謝一路陪伴閱讀的朋友，也感謝未來某天因緣際會讀到這系列文章的你。
希望這些內容能帶給你啟發與助益，我們明天見！