要做什麼?

首先釐清一下我們要實作的目標是甚麼，一個售票系統，售票系統的流量有一個特性就是相對集中，在票券開發販售的時間點會有大量的使用者湧入購票，無論是演唱會、歌舞劇、火車、高鐵甚至蛋黃酥只要是熱門的限量商品都會有這種特性。

熱門商品百百種，我們今天要實作的是乞丐版的售票系統，當然不奢望它能夠應付五月天、周杰倫這種大熱門演唱會的售票，我們可以先設定一個預估的需求跟預算，看看我們是否能在預算內能完成需求。

雖然我們要做的是售票系統，但我們主要設計的目標是高併發應用，所以並不會去串接任何金流服務。

需求:

• 7*24 提供服務
• 離峰時段只有少量的使用者 RPS ≤ 10
• 每個月會有一次的熱門票務 RPS ≤ 3000 持續 5 分鐘

RPS: Request pre second 每秒的 Request 數量

預算:

• 期望是能夠壓在 100 USD/Month

怎麼做?

根據前面需求描述，大部分的時間系統附載都很低，每個月只有 5 分鐘會有大流量出現，在傳統的地端系統可能會依照系統的峰值用量來決定系統要用什麼樣的規格，如果沒有預算限制大可開 10 台甚至 100 台 VM 來應付這些流量，但這樣在大部分的時間裡面這些資源都是被浪費掉的而且我們是窮小子$$很少勢必不可能這樣做。

上雲最佳的好處就是有許多 Pay as you go 的服務可供使用，像我們這種流量不平均的系統就非常適合可以有效的節省預算。

要做到真正的雲原生第一件事情就是要把你的應用容器化，無論在哪一朵雲，只要你想使用雲原生的應用服務前提都是你的應用程式要是容器化的應用程式，在容器化跟微服務當道的這個年代我們當然也要跟上潮流，設計一套分散式高可用的售票系統，不但可以減少資源的浪費，最重要的是可以省$$呀!!

講到售票系統一定離不開高併發服務，何謂高併發服務呢? 以下有請 Gemini 來為我們說明

高併發服務是指能夠同時處理大量並發請求的系統或應用程序。在當今的網路環境中,許多熱門網站和應用都面臨著大規模用戶同時訪問的挑戰,這就要求系統具備高併發處理能力。

實現高併發服務的關鍵在於系統架構設計和性能優化。常見的策略包括:

1. 使用分散式系統,將負載分散到多台服務器上
2. 採用異步處理機制,提高系統吞吐量
3. 實施緩存技術,減少對數據庫的直接訪問
4. 資料庫優化,如分區、索引等
5. 使用消息隊列削峰填谷,平衡流量
6. 進行程式碼層面的優化,提高執行效率

高併發服務需要在可用性、一致性和分區容錯性之間權衡。同時還要考慮系統的可擴展性,以便根據需求進行橫向或縱向擴展。

構建高併發服務是一個持續優化的過程,需要通過壓力測試不斷發現和解決性能瓶頸。隨著雲計算和微服務等技術的發展,實現高併發服務變得更加靈活和高效。

非常棒，Gemini 已經幫我們列出了高併發服務在架構設計上時常使用的方法👍