前言
前陣子周杰倫演唱會售票系統面對超過 89 萬人同時搶票的情況，售票系統方很自豪地說，系統能夠承載如此大的流量，不會掛掉的同時，還能順利地把票賣完。
雖然能夠推持住系統不會崩潰，但該系統的售票頁面不斷出現「轉圈圈」的狀況，讓許多歌迷無法順利購票，關於使用者體驗這一點，似乎還有可以再優化的空間。
本文將從技術角度深入分析售票系統架構，並探討各種可能的優化方案。
一、現有AWS架構的問題分析
根據 AWS 官方指出，售票系統就是架設在 AWS 雲端上。不過啊，這張圖是2020年的，現在的架構應該優化更多了，但目前只找到這張，我們就以這架構來分析看看吧！
首先來看一下售票系統的架構圖：
資料來源：AWS 官網
接下來以個人淺見來看看該架構是否有可以更好的地方：
(一) 系統架構層面
1. 負載平衡
想像一下，就像是一個只有三個服務窗口的車站，突然間來了九十萬人要買票。即使每個窗口再怎麼快，也無法應付這麼多人。
雖然有基本的負載平衡器 (Elastic Load Balancing) 來分配人流，但就像是交通指揮只會把人平均分配到三個窗口，沒有更聰明的疏導方式。系統需要的是更像春節期間的車站管理，有預約、分流、排隊等多重措施。
2. 資料庫設計問題
現在的資料庫就像是一本大帳本，所有人都要搶著在同一本帳本上記錄。當九十萬人同時要在這本帳本上寫東西，自然會打架。
DynamoDB 雖然很強大，但難以處理高併發，如果只用一個資料庫來處理所有請求，就像是再厲害的收銀員，同時間也只能服務有限的客人。
我們需要的是資料分片策略，就像是多個專門的小帳本，分別處理不同的資料，就像大賣場會開很多收銀台一樣。
3. 擴展性限制
EC2 主機的擴充速度可能趕不上需求，等擴展完成可能大部分客人已經等得不耐煩走人了。這就需要更智慧的預測和更快的擴充機制，就像餐廳會預先觀察訂位情況來準備桌位。
(二) 使用者體驗問題
1. 缺乏透明度
目前的系統就像是把用戶關在一個黑盒子裡，只能看到一個永遠轉不完的圈圈，不知道自己排在第幾位，還要等多久。
這種體驗就像是排隊但看不到前面有多少人，也不知道隊伍有沒有在動。這會造成用戶焦慮，也容易讓人懷疑系統是否還在正常運作。
資料來源 售票系統
2. 系統響應問題
當系統過載時，用戶看到的就是無止盡的載入畫面，不知道到底是成功了還是失敗了。這就像是在自動販賣機投錢後，機器既不出貨也不退錢，讓人不知所措。
系統需要明確告訴用戶當前的狀態，即使是失敗也要讓用戶知道原因和下一步該怎麼做。
也就是說，買票的粉絲可能太晚買票了，至少讓他們知道前面還有多少人在買，大概要等多久，當他們看到人數太多，也有可能乾脆就不買了，讓真正死忠的粉絲繼續排隊買票。
二、改進方案分析
(一) 資料庫架構優化
1. 為什麼需要改進資料庫架構？
現有的單一資料庫架構就像是一個超大的倉庫，所有人都要從同一個門進出。當人太多時，自然會造成擁擠。
改進的方案就像是把一個大倉庫分成多個小倉庫，每個倉庫負責不同的區域或功能，這樣就能更有效率地服務更多人。
如果使用多個不同資料庫，把一個大資料庫切分成多個小資料庫，就像是一個服務櫃台變成多個服務櫃台，自然能夠服務更多人，也降低了某個櫃台故障時影響所有人的風險。
2. 可能會有的缺點
想像一下，如果今天有個客人要同時買 A 區和 B 區的票，但這兩個區域是分別由不同資料庫管理的。這時系統就必須同時和兩個資料庫溝通，確保兩邊都要成功購票，才算交易完成。
這種跨資料庫的交易變得很複雜，就像是要同時在不同櫃台辦理業務。而且每個資料庫的資料都要保持同步，比如說座位狀態、購票紀錄等，
這會讓系統變得很複雜，也需要投入更多資源來維護這些資料庫。
3. 推薦做法
與其完全切分成獨立的資料庫，不如採用「分片」的方式。分片就像是同一個大資料庫的不同分部，它們共用相同的管理方式，但各自負責不同的資料。
再搭配分散式的快取系統，可以先把熱門的資料（例如座位狀態）存在記憶體中，這樣就不用每次都去資料庫查詢。
最後，對於跨區域的購票需求，可以使用訊息佇列來處理，讓系統能夠更有條理地處理這些複雜的交易。這樣的設計既保持了系統的簡單性，又能應付大量的購票需求。
(二) 實名制驗證機制
1. 實名驗證的好處
實名制最直接的好處就是能大幅降低黃牛票的問題，因為每張票都綁定實際觀眾的身分證，黃牛就無法大量囤票轉售。
這也讓整個交易變得更有保障，因為買票的人就是要進場看表演的人，票券的來源更有保障。
另外，當有人需要退票或換票時，主辦單位也能很容易確認這個要求是來自原始購票者，不會有人冒用他人身分來退票，整個售後服務變得更好管理。
當然，這點所有的人都理解，但並不是那麼容易做到。
2. 實名驗證的缺點
實名制最明顯的缺點是會拉長整個購票流程。想像一下，除了選位置、付款之外，還要額外填寫身分證字號、姓名等資料，而且可能還需要系統和政府資料庫做驗證，這些都會增加購票時間。
對售票系統來說，也需要建立更複雜的程式邏輯，要處理身分驗證、確認真實性、處理例外狀況等。
最重要的是，系統現在要處理大量的個人資料，不只要符合個資法的規範，還要有足夠的資安防護，以免發生資料外洩，這些都是很大的挑戰。
3. 建議做法
最理想的做法是讓使用者「提前」完成身分驗證。就像是網路銀行開戶，先在平常時間完成所有驗證程序，到真正要搶票時就不用再重新驗證，可以大幅縮短購票時間。
建議採用分散式的身分驗證服務，這樣就不會所有驗證請求都擠在同一個地方。系統可以同時使用多種驗證方式，例如身分證字號、手機號碼認證、金融卡驗證等，讓使用者可以選擇最方便的方式。
重要的是要在便利性和安全性之間取得平衡，既不能讓驗證程序太複雜而影響購票體驗，又要確保身分驗證的真實性。這樣的設計才能真正發揮實名制的優點，同時降低它帶來的負面影響。
4. 和劉德華演唱會實名制的做法比較
(1) 採用「登記抽選制」而非即時搶票
這完全避免了系統崩潰的風險。因為在15天的時間窗口內（8/25-8/30），人們可以從容地登記資料，系統負載被分散到更長的時間。
(2) 有清楚的分流機制
卡友優先購票時段（11:28-13:28）和一般民眾登記時段（15:28後），這樣的設計可以有效管理系統負載。
身分資料修改機制很人性化：給予5天的時間（8/25-8/30）供人們修正資料錯誤，而且提供了明確的修改介面（「查看詳情」修正資料）。
(3) 對特殊情況有完整的配套
・生僻字可以用護照英文名稱取代
・身心障礙者和陪同者必須同時登記
・明確區分本地居民和海外人士的證件要求
與我們原本建議方案的主要差異：
我們建議的「預先驗證」機制著重在搶票前就完成身分驗證，但劉德華演唱會採用的是「登記後慢慢驗證」的方式。這種方式雖然較不即時，但因為有抽選機制，所以時間不是那麼關鍵。
我們建議的分散式驗證服務主要是為了處理高併發的即時驗證需求，但在登記抽選制下，這種複雜的架構反而顯得多餘。
所以劉德華演唱會的做法其實更優秀，因為它徹底改變了遊戲規則 – 從「比快」變成「抽籤」。這種方式有幾個關鍵優勢：
・完全消除了系統崩潰的風險
・給予購票者更多時間確認和修正資料
・降低了黃牛票的投機空間（因為無法透過技術手段提高中籤機會）
・整體成本更低（不需要建置複雜的高併發架構）
這個案例告訴我們，有時候與其用技術解決問題，不如從商業邏輯層面改變遊戲規則。這種「登記抽選」的方式，既解決了技術問題，又提供了更好的使用者體驗，是一個值得借鑑的範例。
(三) 智慧排隊系統
1. 排隊機制的運作原理
想像一下，就像是遊樂園的快速通關系統，每個人進入隊伍時會拿到一個號碼，系統會告訴你大概什麼時候可以入場，你不用一直站在那裡等。在線上售票系統中，這表示用戶可以知道自己的位置，預估等待時間，甚至可以做其他事情同時等待。
2. 具體實做方式描述
(1) 即時狀態顯示
我們使用 API Gateway 的 WebSocket API 來建立與使用者的即時連線，這個連線資訊會被存放在 DynamoDB 中。
當使用者的排隊狀態有任何更新時，系統就會立即透過這個 WebSocket 連線推送最新狀態給使用者，讓他們能即時看到自己在隊伍中的位置和預估等待時間。
說到這個，我想到我用手機買郭富城演唱會門票時，至少它有告訴我要等多久。
資料來源：自己買票的系統截圖
(2) 排隊機制
排隊機制的實現則依賴於 DynamoDB 的分散式計數器功能。當使用者加入隊伍時，系統會在 DynamoDB 中建立一筆排隊記錄，並使用計數器來取得這位使用者在隊伍中的確切位置。
這些排隊資訊會被送入 SQS 佇列中等待處理，確保系統能夠有序地處理每一個排隊請求，不會因為大量湧入的請求而崩潰。
(3) 分批放行
分批放行的處理是透過 Lambda 函數來完成的。系統會定期觸發 Lambda 來處理一定數量的排隊用戶，這個數量是根據系統當前的負載狀況和處理能力來決定的。
當一批用戶被選中可以進入購票流程時，系統會同時通知這批用戶，讓他們開始選位和付款的流程。這種分批處理的方式可以有效控制系統負載，避免所有人同時湧入造成系統癱瘓。
(4) 超時處理
為了處理逾時的情況，我們使用 CloudWatch Events 來定期觸發檢查機制。
如果有用戶在規定時間內沒有完成購票流程，系統會自動將他們標記為逾時，釋放相關的資源（如暫時保留的座位），並通知後面的使用者前進。
這個機制確保了隊伍能夠持續流動，不會因為個別用戶的延遲而影響整體效率。
(5) 防欺詐機制
防欺詐機制則是整個系統的安全防護網。系統會檢查是否有重複排隊的情況，驗證每個用戶的身份，並且限制單一用戶在特定時間內能夠進行的操作次數。
這些機制共同確保了排隊過程的公平性，防止有人利用技術手段破壞正常的排隊秩序。
這整套系統需要多個 AWS 服務的配合才能順利運作。API Gateway 處理所有的即時通訊需求，DynamoDB 負責資料的儲存，SQS 確保訊息的可靠傳遞，Lambda 處理各種業務邏輯，CloudWatch Events 負責定時任務的觸發，而 ElastiCache 則用於提供快取服務以提升系統效能。
這些服務相互配合，打造出一個可擴展、可靠且高效的智能排隊系統。
這樣的架構設計不僅能夠處理大量的並發連接，還能確保整個購票過程的公平性，同時為使用者提供即時的狀態更新，並能自動處理各種異常情況。
最重要的是，它提供了良好的使用者體驗，讓使用者清楚知道自己的排隊狀態，不會因為系統的不透明而感到焦慮。
(四) 概念示意圖
1.入口層
系統的第一道防線是 CloudFront 全球內容分發網路（CDN）。它負責將靜態內容快取在全球各節點，大幅降低使用者的存取延遲。
當大量用戶同時湧入時，CDN 可以有效分散流量，避免直接衝擊後端伺服器。
在 CDN 之後，應用程式負載平衡器（ALB）進一步分配流量到不同的前端服務節點。
2.前端層
使用 ECS Fargate 運行前端應用程式，採用無伺服器架構可以根據實際流量自動擴展。這層主要處理使用者介面渲染和基本的業務邏輯，像是表單驗證、頁面導航等。
由於使用容器化技術，可以快速部署和擴展，且無需管理底層基礎設施。
3.排隊層
當用戶進入系統後，首先進入排隊層。這層使用 API Gateway 的 WebSocket 服務維持與用戶的即時連線，讓系統能夠即時推送排隊狀態更新。
排隊狀態存儲在 DynamoDB 中，確保高併發存取性能。使用 SQS 訊息佇列來管理排隊隊伍，確保公平性和系統穩定性。
4.身分驗證層
輪到用戶時，進入身分驗證層。REST API 接收驗證請求，Lambda 函數執行實際的驗證邏輯。
用戶資料存儲在 DynamoDB，而驗證結果快取在 ElastiCache 中以提升效能。
這層的設計重點是安全性和效能的平衡，確保驗證過程既安全又快速。
5.訂票層
通過身分驗證後，用戶進入實際的訂票流程。ECS Fargate 運行訂票服務，處理座位選擇和訂單創建。
座位狀態快取在 ElastiCache 中，確保快速響應。最終的訂單資料寫入 Aurora 資料庫，提供強大的交易保證和數據一致性。
6.資料流向
用戶從 CloudFront 進入系統，經過排隊系統獲得順序號，通過身分驗證後進入訂票流程，最後完成訂單創建。
每一步驟都有相應的快取和備份機制，確保系統的可靠性和效能。
這種分層的架構設計，不僅讓系統容易擴展和維護，也提供了良好的用戶體驗。
三、GCP優化架構方案
接下來，我們來看看，售票系統在 GCP上可以怎麼做。
(一) 核心服務
我們的售票系統核心架構是建立在六個關鍵的 GCP 服務上。
1. Cloud CDN 負責處理所有靜態資源的分發
包括網站的 JavaScript、CSS 文件、圖片等。這些資源會被快取在全球各地的節點上，大幅降低延遲時間，讓世界各地的用戶都能快速載入網頁。
系統會自動偵測使用者位置，連接到最近的 CDN 節點，確保最佳效能。
2. Global Load Balancer 扮演著全球流量調度的角色。
它能夠智慧地判斷使用者的地理位置和網路狀況，自動將請求導向最適合的資料中心。
尤其它跟 AWS 的 ALB 比起來，還不用預熱 Pre-Warm。
當某個區域的負載較高時，可以自動將流量導向其他區域，確保系統的穩定性。
而且它還具備智慧路由功能，可以根據後端服務的健康狀況來分配流量。
3. Cloud Run 用於部署前端應用
這個無伺服器的平台能根據流量自動擴展，當訪問量突然增加時，系統會自動建立更多的容器實例來處理請求。
閒置時則會自動縮減資源，既確保了效能又能節省成本。
4. GKE（Google Kubernetes Engine）處理核心業務邏輯。
我們將不同的功能（如訂單處理、座位管理、付款服務等）拆分成獨立的微服務，部署在 GKE Cluster 中。
這種微服務架構讓我們能夠獨立擴展每個服務，也讓系統更容易維護和更新。
5. Cloud Spanner 資料庫保證資料的一致性
這對於處理座位預訂這類需要精確性的操作特別重要。
它能夠在全球範圍內保持資料同步，同時支援大規模的並發操作，完全滿足大型演唱會售票的需求。
6. Pub/Sub 訊息佇列系統用於處理非同步任務
例如當用戶提交訂單時，系統會發送消息到 Pub/Sub，由後端服務依序處理，避免系統過載。
它也用於服務間的通訊，確保訊息能可靠傳遞。
(二) 高可用性設計 (High Availability)
1. 多區域部署
系統同時部署在多個地理位置的資料中心，即使某個區域發生故障，其他區域仍能繼續提供服務。
每個區域都配置了完整的服務架構，並通過 Global Load Balancer 進行流量分配。
2. Autoscale
Autoscale 機制是建立在 GKE 和 Cloud Run 的基礎上。系統會根據 CPU 使用率、記憶體使用量、請求數等指標自動調整資源配置。
例如，當檢測到存取量增加時，會自動增加容器主機數量；當負載降低時，則會自動縮減資源以節省成本。
3. 故障自動轉移
故障自動轉移機制確保了系統的穩定性。
當檢測到某個服務主機故障時，系統會自動將流量導向健康的主機，同時啟動新的主機來替補。這個過程對使用者來說是完全透明的。
4. 分散式快取
分散式快取系統使用了多層次的策略，包括瀏覽器快取、CDN 快取、應用層快取等。
我們使用 Memorystore 來儲存熱門資料，如座位狀態、活動資訊等，大幅減少資料庫的存取壓力。
(三) 監控與維運
1. Cloud Monitoring
負責收集各種系統指標，包括伺服器效能、網絡流量、API 回應時間等。
這些資料會以直觀的儀表板呈現出來，幫助維運團隊快速掌握系統狀態。
2. Cloud Logging
集中管理所有服務的 Log，支援複雜的查詢和分析。維運人員可以輕鬆追蹤問題，了解系統行為。
而且它還支援長期儲存，有助於後續的分析和稽核。
3. Cloud Trace
提供了詳細的 Request 追蹤功能。它可以追蹤一個 Request 在不同服務之間的傳遞過程，幫助我們找出效能瓶頸，就是看出 Latency 高到底是卡在哪裡。
特別是在微服務架構中，這個功能對於問題診斷極為重要。
4. 即時警報系統
當系統出現異常時（如錯誤率升高、回應時間變長），會立即通過 Email、簡訊等方式通知相關人員。不同層級的問題有不同的通知策略，確保運維團隊能及時處理各種情況。這個警報系統也與事件處理流程整合，能夠自動創建工單 (Ticket)，追踪問題解決過程。
四、結論
打造一個優秀的售票系統不僅需要穩定的技術架構，更需要良好的使用者體驗設計。關鍵改進點總結如下：
(一) 系統架構層面
- 1. 多層次快取策略
- 2. 智慧負載平衡
- 3. 資料分片處理
- 4. 異步處理機制
(二) 使用者體驗層面
- 1. 透明的排隊機制
- 2. 即時狀態更新
- 3. 清晰的錯誤提示
- 4. 合理的重試機制
(三) 運營管理層面
- 1. 完善的監控系統
- 2. 靈活的擴展策略
- 3. 有效的成本控制
- 4. 安全防護機制
這些層面的改進點環環相扣，缺一不可。好的系統架構是基礎，但如果沒有良好的使用者體驗設計，用戶仍然會感到挫折。
同樣，沒有完善的運營管理機制，再好的系統也可能因為無法及時發現和處理問題而導致服務中斷。只有將這三個層面都做好，才能打造出真正優秀的售票系統。