115 司法特考三等 檢察事務官類科電子資訊組 系統分析 考古題詳解

核心觀念

本題考查「事件驅動架構（Event-Driven Architecture, EDA）」與「三層式微服務架構（3-Tier Microservices Architecture）」的架構特性、適用情境，以及在高併發、即時串流與非同步業務流程下的設計取捨。

以命題當年（民國 115 年）法規為準：本題屬資訊系統架構設計題，無直接適用之法條，評分重點在於能否依需求特性選擇合適架構，並提出具體的效能、可靠性、一致性與維運分析。

一、事件驅動架構

事件驅動架構以「事件」作為系統元件溝通的主要媒介。事件代表某項狀態已經發生，例如：

• TelemetryReceived：收到動態捕捉資料
• GiftPurchased：觀眾完成虛擬禮物購買
• GiftSettled：禮物交易完成結算
• RevenueShareTriggered：觸發藝人分潤計算

典型元件包括：

1. 事件生產者（Event Producer）：產生事件的直播服務、禮物服務或演算法服務。
2. 事件代理者（Event Broker）：負責接收、保存、分派事件，例如訊息佇列或事件串流平台。
3. 事件消費者（Event Consumer）：依需求訂閱事件並執行處理。
4. 事件儲存與重播機制：保存事件紀錄，使系統具備重試、稽核與事件重播能力。

其主要特徵是生產者與消費者解耦，生產者不必同步等待所有消費者完成工作。

二、三層式微服務架構

三層式微服務架構通常將系統分為：

1. 表示層（Presentation Layer）：API Gateway、WebSocket、直播控制介面等。
2. 業務邏輯層（Business Layer）：帳務、禮物、藝人、分潤、直播管理等微服務。
3. 資料存取層（Data Layer）：關聯式資料庫、快取、檔案儲存與資料存取服務。

微服務具有獨立部署、服務邊界清楚與可針對個別服務擴展的特性。服務間常透過同步 API，例如 REST 或 gRPC，直接呼叫完成工作，也可搭配訊息機制作為非同步通訊。

---

解題方法

本題應採用「需求特性對應架構能力」的分析方式，依序判斷：

1. 系統是否需要即時處理大量事件。
2. 各功能是否需要獨立擴展。
3. 業務流程是否具有非同步特性。
4. 是否要求強一致性。
5. 系統能否接受最終一致性。
6. 系統是否需要事件重播、稽核與故障隔離。

題目中的三類工作，其架構需求如下：

系統需求	主要特性	適合的架構能力
動態捕捉數據串流	高頻寬、連續資料、尖峰流量	串流分區、水平擴展、批次或視窗處理
即時虛擬禮物	高併發、秒級反應、交易可靠性	非同步佇列、冪等、重試、交易狀態管理
後台即時分潤	業務事件觸發、可延後處理	事件訂閱、工作佇列、Saga、最終一致性

因此，不能只比較「哪一種架構較好」，而應判斷兩者在不同子系統中的適用程度。

---

事件驅動架構的優點

一、適合高併發與尖峰流量

直播平台的觀眾人數、禮物數量與 Telemetry 流量都具有高度波動性。事件代理者可透過佇列或串流分區吸收瞬間流量，使前端服務不必同步等待後端所有工作完成。

例如禮物服務收到購買請求後，可先完成必要的交易驗證，再發出 GiftPurchased 事件，由不同消費者分別處理：

• 更新觀眾餘額
• 更新藝人收益
• 發送直播間特效
• 建立分潤工作
• 寫入稽核紀錄
• 更新即時排行榜

此方式可避免單一請求串接過多同步服務，降低高峰時的連鎖阻塞。

二、服務解耦程度高

事件生產者只需知道事件格式，不必知道所有消費者的內部實作。新增排行榜、推薦、風控或數據分析功能時，只要訂閱既有事件，通常不必修改原有禮物服務。

此特性有利於新創平台快速增加功能，也能降低服務間的直接依賴。

三、便於水平擴展

當某類事件數量增加時，可增加相同類型的消費者實例，分攤事件處理工作。對 Telemetry 串流而言，可依直播間、藝人或資料分區進行平行處理。

系統容量可用基本排隊模型理解：

$$L = \lambda W$$

其中：

• $L$：系統中平均存在的事件數
• $\lambda$：平均事件到達率
• $W$：事件在系統中的平均處理時間

當事件到達率 $\lambda$ 上升時，系統必須透過增加消費者數量、提高單一消費者處理能力，或降低不必要的同步等待，控制處理時間與佇列長度。

四、天然支援非同步分潤

分潤通常不必阻塞觀眾端的禮物操作。禮物交易完成後，系統可發布事件，由分潤服務非同步計算平台、藝人、經紀方及其他參與者的分配金額。

此設計可將即時交易與複雜計算分離，避免分潤服務短暫故障直接造成禮物購買流程全面失敗。

五、具備重試、事件重播與稽核能力

若消費者暫時故障，事件可暫存在佇列中，待服務恢復後繼續處理。若需要重新計算分潤或重建排行榜，也可依照歷史事件重新播放。

對金流、分潤及爭議處理而言，事件紀錄亦可作為重要的稽核依據。

---

事件驅動架構的缺點

一、系統一致性較複雜

事件驅動架構通常採用最終一致性。禮物交易完成後，藝人收益、排行榜、通知與分析資料可能在不同時間點更新。

若業務要求「扣款、交易紀錄與分潤結果必須在同一個資料庫交易中立即一致」，單純事件驅動方式並不適合直接處理全部流程。

二、除錯與追蹤困難

一個禮物事件可能依序觸發多個服務。若沒有分散式追蹤、Correlation ID、事件版本與完整日誌，發生錯誤時不易判斷問題位於：

• 生產者未發出事件
• 事件代理者遺失或延遲
• 消費者處理失敗
• 重試造成重複執行
• 下游資料庫寫入失敗

因此必須建立集中式日誌、分散式追蹤、事件狀態查詢及失敗事件管理機制。

三、重複事件與順序問題

訊息系統通常不宜假設事件只會送達一次。服務可能因重試而收到重複事件，因此消費者必須具備冪等性。

例如分潤服務可使用：

• 唯一交易編號
• 事件 ID
• 去重資料表
• 唯一索引
• 冪等更新語句

防止同一筆禮物被重複計算。

部分業務亦要求事件順序，例如先扣款，再建立禮物交易，再計算分潤。系統必須依聚合根、直播間或交易編號設計分區與順序控制。

四、架構與維運成本較高

事件代理者、Schema Registry、重試佇列、死信佇列、監控、事件版本管理與資料保留政策，均會增加系統複雜度。

若團隊缺乏分散式系統與串流平台經驗，事件驅動架構容易形成難以維護的「事件蜘蛛網」。

---

三層式微服務架構的優點

一、業務邏輯較直觀

禮物服務可以直接呼叫帳務服務、訂單服務與分潤服務，流程較容易以請求與回應方式理解。對交易型功能而言，同步 API 的控制流程較清楚。

二、較容易實作強一致性流程

核心觀念

本題考查物件導向設計中的「狀態設計模式（State Pattern）」。其核心是：

將物件在不同狀態下的行為，分別封裝於不同的狀態類別中，使物件的行為能隨內部狀態改變而改變。

本題的電動機車具有下列狀態：

• Available：待租
• In-Use：騎乘中
• Low-Battery：低電量待配
• Maintenance：維修中

若將所有判斷集中在 Scooter 類別中，程式容易形成大量 if-else 或 switch-case：

if (state == Available) { ... }
else if (state == InUse) { ... }
else if (state == LowBattery) { ... }
else if (state == Maintenance) { ... }

當未來增加「充電中」、「暫停」、「報廢」等狀態時，必須修改大量既有程式，違反開放封閉原則（Open-Closed Principle），也提高維護及測試成本。

State Pattern 的處理方式，是將各狀態的行為與轉移規則分別封裝，讓 Scooter 僅負責持有目前狀態及委派操作。

---

解題方法

本題可依照下列步驟設計：

1. 建立狀態介面 ScooterState。
2. 將各狀態實作成具體狀態類別。
3. 建立情境類別 ElectricScooter，代表被控管的電動機車。
4. 由情境類別保存目前狀態，並將事件委派給目前狀態物件。
5. 當事件發生時，由各具體狀態類別決定下一個狀態。
6. 由 ElectricScooter 統一執行狀態切換。

---

類別角色設計

一、情境類別：ElectricScooter

ElectricScooter 是 State Pattern 中的 Context，代表系統後台所管理的單台電動機車，主要責任包括：

• 保存目前狀態。
• 接收外部事件，例如扣款成功、電量過低、硬體異常。
• 將事件委派給目前狀態。
• 提供 changeState 方法，統一切換狀態。
• 保存車輛編號、目前電量等資料。

ElectricScooter 不直接判斷所有狀態的細節，因此不必持有大量 if-else。

二、狀態介面：ScooterState

狀態介面宣告各狀態必須處理的共同事件，例如：

• rent：使用者租借或扣款成功。
• batteryBelow15Percent：電量低於 $15\%$。
• hardwareError：硬體回傳異常碼。
• returnScooter：結束騎乘並歸還車輛。

各具體狀態依據自身情境實作這些操作。

三、具體狀態類別

具體狀態類別包括：

• AvailableState
• InUseState
• LowBatteryState
• MaintenanceState

每一個類別只負責一種車輛狀態下的行為及狀態移轉規則。

---

狀態移轉規則

本題的主要狀態移轉如下：

$$Available \xrightarrow{\text{扣款成功}} In\text{-}Use$$ $$In\text{-}Use \xrightarrow{\text{電量低於 }15\%} Low\text{-}Battery$$ $$In\text{-}Use \xrightarrow{\text{硬體異常碼}} Maintenance$$

初始狀態為：

$$InitialState = Available$$

若考試答案需呈現完整性，也可補充合理的回復流程：

$$Low\text{-}Battery \xrightarrow{\text{完成換電}} Available$$ $$Maintenance \xrightarrow{\text{維修完成}} Available$$

題目只明確要求低電量及硬體異常的轉移，因此上述回復流程屬於合理的系統設計補充，並非題目明文規定的必要轉移。

---

類別架構圖（Class Diagram）

 +----------------------+
 | ElectricScooter |
 | <<Context>> |
 +----------------------+
 | - state: ScooterState|
 | - batteryLevel |
 | - scooterId |
 +----------------------+
 | + rent |
 | + batteryBelow15 |
 | + hardwareError |
 | + returnScooter |
 | + changeState(s) |
 | + getState |
 +----------+-----------+
 |
 | 持有目前狀態
 v
 +----------------------+
 | ScooterState |
 | <<interface>> |
 +----------------------+
 | + rent(ctx) |
 | + batteryBelow15(ctx)|
 | + hardwareError(ctx) |
 | + returnScooter(ctx) |
 +----------+-----------+
 ^
 +----------------------+----------------------+
 | | |
 | | |
+------------+------------+ +-------+--------------+ +-----+----------------+
| AvailableState | | InUseState | | LowBatteryState |
| <<ConcreteState>> | | <<ConcreteState>> | | <<ConcreteState>> |
+------------------------+ +----------------------+ +---------------------+
| 實作租借行為 | | 實作騎乘行為 | | 實作低電量處理 |
| 扣款成功後轉 In-Use | | 低於15%轉 Low-Battery| | 引導至換電站 |
| 硬體異常轉 Maintenance | | 異常碼轉 Maintenance | | 換電完成轉 Available |
+------------------------+ +----------------------+ +---------------------+
 ^
 |
 +----------+-----------+
 | MaintenanceState |
 | <<ConcreteState>> |
 +---------------------+
 | 車輛停止服務 |
 | 維修完成轉 Available |
 +---------------------+

在 UML 關係上：

• ElectricScooter 與 ScooterState 為關聯關係，前者持有目前狀態。
• 各具體狀態類別實作 ScooterState。
• 具體狀態類別可透過 ElectricScooter.changeState 要求情境物件切換狀態。
• 狀態物件不宜直接任意修改情境物件內部欄位，應透過公開方法完成狀態切換，以維持封裝性。

---

狀態介面與具體實作示意

核心觀念

本題考查「要徑法」（Critical Path Method, CPM）與專案時程網路分析，重點包括：

• 任務的前置關係判定
• 網路圖繪製
• 關鍵路徑判定
• 最早開始時間（ES）
• 最早完成時間（EF）
• 最晚開始時間（LS）
• 最晚完成時間（LF）
• 總時差（Total Float, TF）

主要公式如下：

$$EF=ES+\text{工期}$$ $$LS=LF-\text{工期}$$ $$TF=LS-ES=LF-EF$$

關鍵路徑是專案網路中工期最長的路徑。位於關鍵路徑上的任務，其總時差為 $0$；任一關鍵任務延遲，均會造成專案完工日延遲。

---

解題方法

一、整理任務前置關係

題目給定：

• A：採購防偽硬體晶片，工期 4 週
• B：建置外部海關 API 串接，工期 2 週
• C：開發核心共識排程演算法，工期 5 週
• D：系統端到端整合測試，工期 3 週

前置關係為：

• A 與 B 均為 C 的前置任務
• C 為 D 的前置任務

因此網路關係為：

$$A \parallel B \rightarrow C \rightarrow D$$

其中 $A$ 與 $B$ 可同時進行，C 必須等 A、B 全部完成後才能開始。

---

二、繪製專案時程網路圖

 ┌──────────────┐
 ┌─────▶│ A：4 週 │─────┐
 │ └──────────────┘ │
開始 ─────┤ ├────▶ C：5 週 ────▶ D：3 週 ────▶ 完成
 │ ┌──────────────┐ │
 └─────▶│ B：2 週 │─────┘
 └──────────────┘

C 的開始時間取決於 A、B 之中較晚完成者，因此：

$$ES_C=\max(EF_A,EF_B)$$

---

關鍵計算

一、正推計算：最早時程

假設專案於第 $0$ 週開始。

任務	工期	ES	EF
A	4	0	4
B	2	0	2
C	5	$\max(4,2)=4$	9
D	3	9	12

各任務計算如下：

任務 A

$$ES_A=0$$ $$EF_A=0+4=4$$

任務 B

$$ES_B=0$$ $$EF_B=0+2=2$$

任務 C

C 必須等待 A、B 皆完成，因此：

$$ES_C=\max(EF_A,EF_B)=\max(4,2)=4$$ $$EF_C=4+5=9$$

任務 D

D 必須等待 C 完成，因此：

$$ES_D=EF_C=9$$ $$EF_D=9+3=12$$

所以本專案最短完工期為：

$$12\text{ 週}$$

---

二、逆推計算：最晚時程

專案最晚完工時間以第 $12$ 週為基準。

任務 D

$$LF_D=12$$ $$LS_D=12-3=9$$

任務 C

C 必須在 D 開始前完成，因此：

核心觀念

本題考查軟體開發生命週期模型的選擇，以及依據專案特性進行「模型裁適」與「混合型開發」的能力。核心判斷標準有二：

1. 需求是否明確且穩定。
2. 技術、資安與硬體整合風險是否高，是否需要嚴格審查與驗證。

瀑布模型屬於計畫導向、階段性開發模式，通常依序經過需求分析、系統設計、實作、測試、部署與維護。其優點是文件完整、責任與審查節點明確，適合需求穩定、法規或安全要求嚴格的系統；缺點是變更成本高，使用者須在前期明確描述需求。

Scrum 屬於敏捷開發方法，以短週期 Sprint 持續交付可運作成果，透過 Product Backlog、Sprint Planning、Daily Scrum、Sprint Review 與 Retrospective，持續取得利害關係人回饋。其優點是能快速因應需求變更，適合需求不明確、使用者互動頻繁的系統；缺點是若缺乏架構治理、文件與整合控制，容易產生範疇漂移、技術債與整合風險。

混合型開發模式，是依不同子系統、工作階段或風險性質，分別採用適合的開發模式。其重點不是把瀑布與 Scrum 任意並列，而是建立清楚的責任邊界、交付介面、審查機制與整合流程。

本題不涉及特定法條，應以軟體工程與系統分析的開發模型原理作答。

---

解題方法

本題應採「需求穩定度 × 風險程度 × 變更頻率」三項標準分析。

第一，衛星軌道硬體控制與資安通訊協定具有下列特性：

• 規格高度確定。
• 與硬體、韌體、通訊設備及地面站整合。
• 涉及衛星控制安全與資安。
• 錯誤成本極高，甚至可能造成設備失效、資料外洩或任務失敗。
• 需要完整文件、基準線、測試紀錄及審查證據。

因此，該部分應採計畫導向的瀑布式或具階段閘門的開發方式。

第二，地面端物流商的 Web/App 視覺化介面與報表排程需求具有下列特性：

• 使用者需求尚未完全明確。
• 不同物流商可能有不同操作習慣。
• 介面與報表須透過實際操作取得回饋。
• 需求會隨營運流程及管理需求改變。
• 需要快速製作原型、試用、修正與迭代。

因此，該部分適合採 Scrum，以短週期逐步交付功能。

第三，兩類工作雖可使用不同模型，但仍屬同一個整合型系統，必須透過共同架構與介面管理加以銜接。因此本題的結論是：本專案適合採用混合型開發模式，但必須以系統邊界、風險邊界及交付介面明確劃分兩者範疇。

---

混合型開發模式的適用性

本專案採用混合模式是適當的，理由如下。

一、專案內部存在不同程度的需求不確定性

衛星控制與資安協定的需求相對固定，適合在前期完成需求確認與設計審查。地面端介面與報表需求則需要透過使用者回饋逐步澄清，適合採用迭代式開發。

若整個專案全部採瀑布模式，地面端介面在後期才發現不符合使用者習慣，將造成大量返工。若整個專案全部採 Scrum，衛星控制與資安協定可能因頻繁變更而破壞安全基線與硬體整合穩定性。

二、專案內部存在不同程度的失誤成本

衛星軌道控制及資安通訊的錯誤成本極高，必須強調事前設計、正式審查、驗證與追蹤。地面端介面即使初版不理想，通常仍可透過下一個 Sprint 修正，錯誤成本相對可控。

因此，應依風險採取不同的控制強度，而非對所有功能使用同一種流程。

三、系統具有明確的技術分層與子系統界線

本專案可區分為：

• 衛星端硬體控制層。
• 衛星與地面站間的資安通訊層。
• 地面接收站及資料服務層。
• 物流商 Web/App 使用者介面層。
• 報表、查詢與排程服務層。

其中前兩層具備高度安全與穩定要求，後兩層則具備高度使用者互動與需求變動特性，適合採取不同模型。

---

瀑布模型的適用範圍與執行方式

瀑布模型應適用於「衛星軌道硬體控制與資安通訊協定」核心範圍，並涵蓋必要的地面站底層整合功能。

一、應納入瀑布模型的工作

1. 衛星姿態、軌道控制及命令執行邏輯。
2. 硬體控制介面、感測器介面及致動器介面。
3. 衛星與地面站之間的通訊協定。
4. 身分認證、金鑰管理、加密、訊息完整性與防重放機制。
5. 通訊封包格式、錯誤處理及異常復原程序。
6. 地面接收站對衛星控制命令的權限驗證與傳送流程。
7. 影響安全性與任務可靠性的底層資料模型及 API 契約。

二、瀑布範圍的主要控制活動

1. 完成需求規格書並建立需求基準線。
2. 建立硬體、韌體、通訊協定及資安需求的可追溯矩陣。
3. 進行系統架構設計、詳細設計與介面設計審查。
4. 進行設計驗證、單元測試、整合測試、系統測試與安全性測試。
5. 設置正式的變更控制委員會或變更審查機制。
6. 未經影響分析、風險評估與核准，不得任意修改核心規格。
7. 在進入下一階段前設置階段閘門，例如需求審查、設計審查、整合審查及驗收審查。

此部分可以採取「瀑布主流程加上驗證與確認」的 V-Model 精神，使每項需求均能對應至設計、測試案例與驗收證據。

---

Scrum 的適用範圍與執行方式

Scrum 應適用於「地面端物流商的 Web/App 視覺化使用者介面與報表排程需求」，以及不涉及衛星安全核心的地面端應用功能。

一、應納入 Scrum 的工作

1. 衛星位置、軌道狀態與設備狀態的儀表板。
2. 地圖、圖表、告警訊息與歷史資料視覺化。
3. 物流追蹤查詢、篩選與權限內資料呈現。
4. Web 與 App 的操作流程、畫面配置及互動設計。
5. 報表欄位、格式、篩選條件與匯出功能。
6. 報表排程、通知方式及不同物流商的客製化需求。
7. 使用者偏好、操作便利性與介面可用性改善。

二、Scrum 範圍的主要控制活動

1. 由 Product Owner 統整物流商與業務單位需求。
2. 將需求轉化為 User Story，並明確描述驗收條件。
3. 以一至四週的 Sprint 交付可操作功能。
4. 在 Sprint Review 展示成果，取得物流商及實際使用者回饋。
5. 依回饋調整 Product Backlog 的優先順序。
6. 透過 Retrospective 改善團隊工作流程。