我想做 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