核心背景 Link to heading
在 SI 系統整合產業任職期間，我們團隊長期深耕電信產業，曾參與 4G/5G 設備開發認證機制的關鍵專案。即便通訊技術不斷演進，架構穩健的 RADIUS 協定依舊是當時認證機制的核心。在技術選型上，我們捨棄了常見的開源方案，導入芬蘭 Radiator Software 開發的商用軟體 —— Radiator，利用其卓越的可擴充性來滿足電信級的連線需求。
選擇 Radiator 的關鍵因素： Link to heading
- 高度模組化的「瑞士刀」架構： Radiator 內建豐富的模組，原生支援 DBM、MySQL、LDAP 等多種認證後端。其開放式架構允許開發者針對特殊的業務邏輯進行高度客製化，確保系統能彈性介接各種異質平台，完美解決了複雜的後端整合問題。
- 完善的 EAP-SIM 支援： EAP-SIM（Extensible Authentication Protocol-SIM） 利用手機 SIM 卡內的憑證作為認證基礎。此技術最典型的應用範例，即是在台灣中華電信的「4G Auto Wi-Fi」自動連網服務，確保使用者在不同網路環境間切換時，具備流暢且安全的驗證體驗。
- 整合 TACACS+ 協定，簡化系統架構： 除了 RADIUS 外，Radiator 亦完整支援由 Cisco 提出的 TACACS+ 協定（用於網路設備管理認證）。相較於傳統需部署兩種獨立服務（Daemon）的作法，Radiator 透過 單一服務進程（Single Daemon） 即可同時處理兩種協定。這不僅大幅降低了系統維護的複雜度，也讓資源調度與監控更加集中高效。
遭遇到的問題 Link to heading
當我接手這個以 Radiator 為基礎的專案時，初期主要配合 TACACS+ 進行網路設備（Router/Switch）的 AAA 認證。在此情境下，由於設備登入頻率固定，效能並非首要痛點。
然而，當應用場景切換至 4G/5G 大量行動裝置登入 時，系統必須應對瞬間爆發的認證請求。在這種高併發（High Concurrency）的情境下，原有的整合架構便暴露出嚴重的效能瓶頸：
外部程式調用引發的 fork 災難 Radiator 本身由 Perl 編寫，若使用內建模組進行認證，資源損耗極低。但在該專案中，為了介接特定的第三方認證系統，使用了 pipe 的方式與外部程式進行溝通：
運作機制：Radiator 將 RADIUS Attributes 透過 stdin 傳遞給外部程式，處理完畢後再經由 stdout 接收回應。
致命傷：這種模式會導致系統頻繁執行
fork()產生新行程。在電信級的海量請求下，頻繁的fork與context switch（上下文切換）會迅速耗盡系統資源，導致處理延遲（Latency）飆升，成為典型的效能債。
同步阻塞問題（Implicit Synchronous Block） 由於 Perl 的單執行緒特性，若外部程式處理速度跟不上請求進來的速度，整個 Radiator 進程會因為等待 pipe 的 I/O 回應而陷入阻塞，無法發揮電信級設備應有的吞吐量。
Perl 解釋器啟動的龐大開銷 (Interpreter Overhead) 最關鍵的效能殺手在於：若外部認證程式本身也是 Standalone Perl Script，每一次請求都意味著要重新啟動一個 Perl 解釋器進程、載入相依模組並進行編譯。這種「隨用隨棄」的模式，在處理完極短的認證邏輯後便銷毀行程，絕大部分的 CPU 週期都浪費在 啟動開銷（Startup Overhead） 而非實際業務邏輯上，極度低效。
解決方案：從外部程序最佳化成原生模組 Link to heading
為了徹底根除前述的效能瓶頸，我們決定捨棄 Pipe 模式，將原本獨立運作的 Perl 認證程式，重構成符合 Radiator 規範的 原生 Perl 模組（Custom Radiator Module）。
為什麼不直接使用原生的 MySQL 模組？ Link to heading
在電信級的認證場景中，常有人問：「既然資料存放在 MySQL，為何不直接設定 Radiator 內建的 AuthBy SQL 模組就好？」 這主要源於複雜的商業邏輯需求：
- 客製化處理流程：電信商的認證過程往往包含多重的邏輯判斷、特定屬性的轉換（Attribute Manipulation），或是需同時介接多個資料來源進行權限校驗。
- 官方模組的限制：原廠模組雖穩定，但在處理高度非標準的商業規則（Business Logic）時缺乏彈性。
- 技術決策：為了在保留客製化靈活性的同時，又能享有原生執行的高效率，我們選擇將邏輯封裝進 Radiator 的運作進程（Process）中，實現 In-Process 的處理機制。
重構後的技術優勢 Link to heading
透過模組化重構，我們成功實現了以下技術指標：
- 消除行程開銷：認證邏輯現在與 Radiator 共享同一個 Perl 解釋器空間，徹底告別了 fork() 災難與解釋器重新啟動的開銷（Startup Overhead）。
- 最佳化資料庫連接：藉由原生模組架構，我們可以更有效地管理資料庫長連接（Persistent Connections），避免了頻繁建立與關閉 DB Connection 造成的延遲。
- 大幅提升吞吐量：在相同的硬體資源下，系統處理請求的能力得到了數量級的提升，成功應對 4G/5G 大規模登入的瞬時爆發流量。
深度調優：SQL 查詢層面的極致最佳化 Link to heading
當認證機制成功轉化為原生模組並實現 In-Process 處理後，系統效能雖已有顯著提升，但在極高併發的壓測下，我們觀察到延遲曲線仍偶爾出現微幅抖動（Jitter）。經過分析追蹤，我們進一步針對資料庫互動層面進行了細緻的「微手術」：
- 消除過度抓取（Over-fetching）的開銷
原先的查詢存在
SELECT *的慣性，這在電信級海量請求下會產生額外負擔：
- 問題：抓取大量不必要的欄位不僅浪費 MySQL 的 I/O，更會在 Perl 層級造成不必要的記憶體配給與資料結構映射（Data Mapping）成本。
- 解決：精確限定查詢欄位，僅取回認證邏輯所需的屬性，將記憶體足跡（Memory Footprint）降至最低。
- 導入預編譯指令（Prepared Statements）
- 問題：若每一次認證請求都重新解析 SQL 語法（Parsing & Building Execution Plan），會消耗大量的 CPU 週期於重複的計算。
- 解決：改用 Prepared Statements，讓 MySQL 僅編譯一次查詢計畫並快取（Cache）起來，隨後只需傳遞參數即可執行。這在瞬時高爆發的認證浪潮中，能有效減輕資料庫引擎的解析壓力。
- 索引微調與查詢路徑最佳化 即使前兩項優化到位，系統偶爾仍會出現短暫的卡頓。經過對 Slow Query Log 與執行計畫（Explain Plan）的深度剖析，我們發現：
- 瓶頸：在特定的複合查詢場景中，由於缺乏最適索引（Optimal Index），導致資料庫進行了掃描（Scan）而非尋找（Seek）。
- 解決：重新調整 Database Index 策略 並最佳化 Query 撰寫方式，確保每一筆認證請求都能精準地命中索引。
總結：電信級效能的體現 Link to heading
透過這三層次的優化—— 消除 Fork 災難、實作 In-Process 原生模組、以及深層 SQL 調優——我們最終打造出一套兼具「靈活商業邏輯」與「極致吞吐量」的認證系統。
這套架構不僅成功支撐了電信商 4G/5G 設備的巨量登入需求，更在硬體資源不變的前提下，透過軟體層級的深度優化（Software Optimization），解決了原本看似需要靠「增加機器數量」才能消化的效能債。
聊聊您的技術挑戰 Link to heading
我們 Embark Systems 提供專業的軟體顧問服務，特別擅長處理底層整合與效能最佳化。如果您有相關需求，歡迎隨時與我們 聯絡詳談，讓我們用積累多年的技術經驗，為您的專案打造最合適的解決方案。