markkwsu我想做 2C 網際網路服務的人，都很清楚這個標題的含意；有流量才有收入，但流量也伴隨著成本的上升，特別是當你把服務架設在公有雲的時候。
所以在一開始規劃系統架構的時候，就必須在收入與成本之間取得平衡。不能讓成本犧牲了使用者體驗（要不然收入從哪來），也不能讓成本無限制擴張，否則入不敷出的狀態可能讓服務很快玩完。
以 GoHoops 的服務來說，最重要的就是從賽事現場回傳的數據，要能夠寫入我們的資料庫中，再來就是所收集到的數據，要能夠穩定的發送到所有需要取得即時數據的媒體通路。從這個服務自 2016 年啟用以來，雖然經過很多次的優化，但系統架構基本上不會跟下圖差別太多：
HBL 賽事，是 Yahoo! 台灣在扮演官網（其他外部網站）的角色，跟這麼專業的廠商配合是很舒服的，他們非常懂不能讓網際網路流量衝擊到後端的服務（一方面也是因為當後端服務如果受到衝擊，會帶來連鎖反應，最後連外部網站的服務也都可能跟著一起掛掉），而因為服務當中針對圖檔的部分是 host 在我們的伺服器上面，我親眼見到了一個國際級入口網站的流量真是驚人，逼得我不得不把 CDN 服務開起來降低成本。
後來 HBL 自己也必須要能夠揭露賽事數據，因此是由我們協助 host 數據網站，在看過 Yahoo! 台灣所帶給我們的流量之後，我就開始思考要怎麼設計一個比較不怕流量影響的網站。最後想出來的解決方案就是：一個純靜態內容的網站，完完全全在用戶端瀏覽器執行的內容（動態內容用 JavaScript 去處理）。
而這樣的設計方式，延續到後來的瓊斯盃／SBL／WSBL 網站，都是只有在賽事進行的時候，會由 GoHoops 核心這裡，將賽事數據推送到這些網站裡，所以流量再大也不會發生問題，只是流量一大，荷包很痛而已。（2020 年的時候，全球一度只剩下台灣有職業賽事在進行，像是 CPBL、SBL／WSBL，那時侯網站海外流量大的不像話…）
後來的客戶們，有的選擇讓我們 host 網站，有的選擇自己找廠商 host 網站，然後再用與 Yahoo! 台灣相同的介接方式進行資料整合，大多數的廠商都很專業，合作起來也相當的愉快，直到我們碰上了這樣的廠商：
- 直接把網際網路流量與 server to server API 掛鉤，換句話說，當有網際網路使用者在存取頁面的時候，他們會將這個 request 直接帶到 server to server API 去查詢，說是因為時程的關係所以才這樣做（但從今天看，系統上線也過了好一陣子了，也沒看到在沒有時程壓力之後，做出任何調整）。更不要說在一開始的會議裡，就已經提過要用 server to server API 的方式做整合，或者說有 Yahoo! 台灣那樣的系統架構概念了。
- 認為可以透過 cache 的方式降低網際網路流量與 server to server API 之間的耦合度，但對於這個問題：「當 cache 過期的時候，同時間有 1000 個使用者來存取，會是 1000 個使用者都沒有 cache 而直接存取 server to server API，還是第 1 個使用者存取 server to server API，然後剩下的 999 個使用者都讀取到 cache」，他們的答案是：「 1000 個使用者都會存取到 server to server API」，那要 cache 何用？更不用說那個 cache 的時間很短…
第一次發生問題的時候，整個核心資料庫 CPU 100% 滿載，原因就是有太多的 query request 灌進來，結果連賽事的數據都沒辦法進來（因為資料庫太忙了，沒空處理數據新增的工作），還好我們有設計 backup 的子系統，可以將上傳漏失的資料再補進來，才沒有造成客戶以及其他協力廠商（使用這個資料庫的人，不是只有你們一個服務好嗎？）更大的損失。
後來因為改善的狀況有限，我們只好多開一台 replica 資料庫（read only）以及一台 endpoint 伺服器，以避免核心數據資料庫與既有其他廠商使用的 endpoint 受到影響；然而就像前面兩點提到的，根本的問題不面對，加再多的機器都沒有辦法解決。所以直到今天為止，還是可以常常看到 replica 資料庫是 CPU 100% 滿載的狀況，而 CPU 100% 就代表無法輸出任何資料到前端，但說實在的，我們能提供的協助真的有限。
2C 的網際網路服務真的不容易做，更不要以為運動產業是小眾流量，還記得自己剛開始做這些服務的時候，心裡還會想：「是能有多難？會比我過去遭遇到的任何大型專案還難嗎？」
但事實就是，沒那麼簡單
而事實是，已經邁向第 6 年了，但這套服務都還沒做到我滿意的程度，所以 IT 人千萬不要把運動產業給看小了。
Add comment