鐵人檔案
利用雲原生方案建制成本可控的高併發售票系統，因工作所需小弟有幸接觸到高併發應用的架構設計及開發，過程中發生許多有趣及富有挑戰的故事，透過本次鐵人賽重新設計實作一次並分享經驗給讀者。
建立 Process Service 先前都是透過 Sales Service 來做雲端資源之間交互測試，但實際上並不是全部遭錯都在 Sales Service...
Cloud SQL 建立好了一個 PostgreSQL 但目前裡面都還沒有 Table Schema ，先前也設計好 Schema 為了方便做資料庫的版本控制，...
接下來可以要開始撰寫 API 了，可以依照先前設計的 API 規格來實作，如果有特別需求再做調整。 建立註冊及登入API 售票系統一定會有使用者登入的機制，無論...
管理活動 今天繼續依照先前設計的 API 規格來實作，身分驗證完成之後要來時做活動的管理，一個活動通常會有活動本身資訊及座位資訊，這兩種資料都可以根據我們先前設...
有了活動資訊之後要開始來建立最核心的售票服務，基本上售票的 API 最好是越簡單越好，做的事情越少 API 的 Latency 通常就會越低。 同步處理 正常來...
昨天我們實作了售票的 API ，並把購票資訊推送給 Pub/Sub 的 Topic 再由 Scbscription 推送給 Process，但 Process...
身分驗證與售票流程開發完畢後就可以先來做個簡單的壓力測試了，進行壓力測試當然要有合適的工具來進行，壓力測試的工具有非常多種，如 Jmeter、Locust、K6...
昨天我們對售票 API 進行了壓力測試，可以看到結果是慘不忍睹，RPS 只 27 ，今天我們要好好地來優化購票 API。 增加 Log 首先我們要先知道整個流程...
目前窮小子售票系統的售票 API 已經能夠承受 2400 左右的 RPS 了，但承受了這麼高的流量最後持久化的資料是否是正確的呢? 接下來就一起驗證看看 起初為...
最後一天了我們來快速的 Review 一下實作結果跟起初設定的目標 目標 首先來看看我們一開始訂的需求 需求: 7*24 提供服務 離峰時段只有少量的使用者...
