資深 PHP 後端工程師面試指南：架構思維、模組化能力、可維護性與擴充性設計的問題

🏗️ 系統架構師視角：現代 PHP 應用程式的模組化、可擴充性與高可用性實戰

在多變的商業需求和高壓的迭代速度下，設計一套具備高可擴充性、高維護性且能應對高併發的 PHP 系統，是後端工程師的核心價值。本文將彙整我在多個中大型 Laravel 專案中的架構設計原則、模組化策略，以及應對極端狀況的技術選型與實戰經驗。

---

🧱 核心設計哲學：模組化與可擴充性

1. 可擴充模組化系統的設計原則

我的設計起點是 **DDD（Domain-Driven Design）**的分層架構，確保職責分離：

• Domain Layer：核心業務邏輯，不依賴任何外部框架。

• Application Layer (Service Layer)：應用服務，處理業務流程與交易。

• Infrastructure Layer：處理 DB、外部 API 整合（如 Repository 實作）。

優先考慮的設計原則：

1. SOLID 原則：特別是 Dependency Inversion（依賴介面而非實作），這讓模組間保持鬆耦合。

2. Open-Closed Principle (OCP)：封閉修改、開放擴充。利用 Interface 和 Event 機制，新增功能時無需觸碰核心舊程式碼。

3. KISS (Keep It Simple, Stupid) & YAGNI (You Aren't Gonna Need It)：避免過度設計，先用 POC (Proof of Concept) 驗證模組的可擴充性，再推廣。

2. Plugin-based 架構設計：事件驅動核心

要實現第三方無痛擴充，我採用了 事件驅動架構 (EDA) 結合 Laravel Service Provider：

• 核心定義：系統核心只發出 Events（如 OrderCreatedEvent）。

• 擴充機制：Plugin 透過 Composer 安裝，並在 Service Provider 中註冊 Listener 來監聽核心事件，或實作 Interface（如 PaymentPluginInterface）來覆寫核心功能。

• 無痛接入：提供清晰的 SDK 和文件，第三方只需實作 Interface 並在設定檔中註冊即可。核心系統利用 Laravel 的 boot() 方法自動載入。

3. Laravel Clean Architecture 組織：Service, Repository, DTO

在 Laravel 專案中，我嚴格遵守乾淨架構（Clean Architecture）的分層，確保高可測試性：

元件	職責與位置	設計目的
Service Layer	app/Services，複雜業務邏輯與 Transaction 處理。	協調各 Repository，確保業務流程的完整性。
Repository	app/Repositories，抽象化資料存取（Interface + Eloquent 實作）。	解耦資料庫層，方便未來替換 ORM 或 DB。
DTO (Data Transfer Object)	app/DTOs，傳遞資料物件（如 CreateOrderDTO）。	確保型別安全與資料的 Immutable，降低參數傳遞錯誤。

---

⚙️ 系統整合與資料流：高可用與容錯

1. 第三方 API 整合的容錯設計

面對金流、物流等不穩定的外部 API 整合，我採用了高規格的錯誤處理與重試機制：

• Adapter Pattern：包裝第三方 API 於統一的 Interface 下（如 PaymentGatewayAdapter），隔離核心系統與外部變動。

• 錯誤處理：使用 Guzzle 進行請求，搭配 Exponential Backoff 的重試 Middleware，對 5xx 錯誤進行 3 次（1s, 2s, 4s 間隔）的重試。

• 熔斷機制 (Circuit Breaker)：利用 Laravel Pennant 偵測如綠界金流連續 Timeout，達到閾值後斷開請求，以防止系統雪崩。

2. 事件驅動架構：同步與非同步的選擇

系統中的操作必須區分同步 (Synchronous) 與非同步 (Asynchronous)，以平衡即時性與系統負載：

類型	適用場景	Laravel 搭配	考量點
同步	即時性高的邏輯（如登入驗證、DB 交易更新）。	Event 發送後立即執行。	需考量延遲容忍度與資料強一致性。
非同步	背景任務（如寄信、推播通知、報表生成）。	shouldQueue 將 Listener 丟入 Laravel Queue，用 Horizon 監控。	達成最終一致性，不影響主服務效能，適用高峰期。

---

🧪 可測試性與維護性策略

1. 打造易測試架構的關鍵

• Dependency Injection (DI)：所有依賴都透過建構函數或方法注入，方便在測試中Mocking。

• Interface 邊界：用 Interface 定義邊界，確保單元測試可以完全隔離外部依賴（DB/API）。

• 避免 Static/Global：Static Method 和 Global Variable 會導致緊耦合和 Stateful 邏輯，是測試困難的主要來源。

2. 架構重構實戰：Strangler Pattern

在將 legacy 系統（如 8 年老舊的純 PHP/Yii 系統）轉移至 Laravel 時，我採用了 Strangler Pattern (絞殺者模式)：

1. 引入標準化：引入 Composer、PSR-4 命名空間，並用 PHPStan 掃描問題。

2. Repository 包裝：先抽離 DB 查詢邏輯到 Repository，將舊邏輯封裝。

3. 逐步替換：新的功能與路由直接使用 Laravel。舊頁面則透過 Route Proxy 或 Facade 指向 Legacy Code，然後逐頁重寫。

4. 安全切換：利用 Feature Toggle 進行新舊服務切換，確保線上服務零中斷。

---

🧠 效能、高併發與可擴充性

1. 流量暴增的架構應對（雙 11 經驗）

面對如電商雙 11 的瞬間流量，我會採取以下策略應對瓶頸：

1. 水平擴展：增加 Web 伺服器，利用 Nginx Load Balancer 分流。

2. PHP 運行模式升級：從傳統 PHP-FPM 轉向 Swoole/RoadRunner，大幅提高單機的 Concurrency。

3. 資料庫優化：新增 DB Read Replica 分散讀取壓力，優化索引。

4. 快取前置：將 80% 的讀取請求擋在 Redis Cache 層，減少對後端服務的衝擊。

5. Queue 擴容：Scale up Queue Workers 確保背景任務不堆積。

2. 多租戶（Multi-Tenant）系統設計

我主要採用 Shared DB (共用資料庫) 配合 tenant_id 欄位進行資料隔離，以兼顧成本與效能。

• 資料隔離：透過 Middleware 設置 Tenant Context，並在 Repository 層強制所有查詢自動加入 WHERE tenant_id = $current_tenant。

• 效能兼顧：確保 tenant_id 欄位已加索引，並在 Cache Key 中加入 Tenant Prefix（e.g., 'orders:tenant1:123'）防止資料污染。

3. Cache Stampede 防禦

為避免多個請求在快取過期（TTL）的瞬間同時重建成快取（Cache Stampede），導致資料庫瞬間超載：

• Early Expiration (提前過期)：使用隨機化的 TTL（e.g., 5 分鐘 ± 5%），避免所有快取同時失效。

• Lock 機制：只允許一個請求獲取 Redis Lock 來重建快取，其他請求則等待 Lock 釋放或返回舊資料，確保 DB 不被衝垮。

---

🧭 架構決策與技術選型

• 功能自製或 Package 選用：核心業務邏輯必須自己掌握，通用功能（如 Auth、Queue）則優先選用 Laravel 或經過社群驗證的高品質 Composer Package（需評估其 Star 數和維護頻率）。

• 架構協調：當團隊出現分歧，我的策略是先聽取意見、用數據說話（提供 POC 或 Benchmark 報告）、最終以業務價值來判斷技術方案的優劣，避免陷入無謂的技術爭論。

這套以 DDD 為核心、以 Laravel 生態為工具、以高可用性為目標的架構方法論，是在台灣環境中實現快速、穩定、可擴充產品的關鍵。