腳踏車抵家的系統設計

engineer working with laptop at table軟體開發
Photo by Andrea Piacquadio on Pexels.com

前言

在確認了產品需求之後,接下來就會走到開發實作的階段,這個階段第一個面臨的問題就是:我的系統要怎麼處理比較好?在回答這問題之前,必須盤點手上所有的資源,尤其要注意這些資源的限制,因為會攸關到可行性。

產品需求見下文:

資源清單

  • Oracle Cloud VPS * 1
  • Supabase Database (PostgresSQL + Postgis) * 1
  • Google Cloud Functions (for Auth)
  • 政府開放資料

除了 Google Cloud Functions,其他都是免費資源。都有 VPS 了,為何還需要去付費使用 Cloud Functions?

我之所以將 Cloud Functions 納入是因為:不想讓別人看到我的 API endpoint。尤其我是用免費的 VPS,機器比較不夠力一些,加上自身 SRE 的專業不強,很怕 Server 被人打趴,因此將驗證做在 Cloud Functions,先濾除一些非法的連線再去連我的 VPS;而不是直接把驗證做在我後端程式的 middleware。

版本 1.0.0

最一開始我串接雙北的公共自行車開放資料,因為開放資料沒有統一欄位,所以我寫了爬蟲程式放在 VPS 上,把開放資料整理後存入資料庫,並透過 API 將這些整理過的資訊給 App 使用。

版本 1.1.0 – 1.2.0

後來我發現交通部有個公共運輸整合資訊流通服務平臺(Public Transport Data eXchange,PTX),它整合全台灣公共自行車的資料,做的事情跟我 1.0.0 爬蟲程式差不多,就是取出資料交集,整理出一致的資料格式。此時決定改用 PTX 的資料,省下處理各縣市開放資料不一致問題的工。

這時拿掉了很多東西,因為 PTX 滿足產品早期的需求,少維護一台伺服器我也樂得輕鬆。此時還留著 Cloud Functions 是因為:Android 應用程式容易反組譯,我不想讓 PTX 的金鑰外流,因此多墊一層確保安全性無虞,也保留一開始驗證使用者的功能。

版本 1.3.0 – 現在

新的產品規格有一些細膩的資料需求,這是 PTX 的 API 無法提供的,所以走回老路,重新啟用我那台 VPS 跟爬蟲程式,改爬 PTX 的資料;下圖左下是長回來的部分,專門處理新功能的需求。

原本想要讓 Cloud Functions 直接對我的 Server 拿資料就好,但我自己的 API 回應時間一直調不到我預期的水準,所以保留 Cloud Functions 對 PTX API 拿資料的那段,確保回應時間壓在 100 ms 以下。

優點與缺點

每個解決方案都是權衡下的結果,我認為沒有最好的解決方法,只有最適合當下的處理方式。下述提到的優點是我追求的,但一定也為此犧牲了某些東西。

高流量

因為 Cloud Functions 可以自動水平擴充,所以使用者變多時也不太擔心。腳踏車抵家的主功能是在地圖上瀏覽腳踏車的站點,這是打 PTX API,我看 PTX 有處理 Cache 機制,感覺打不太死。而我的 Server 負責小功能的 API,這被打趴就算了,至少主功能還活著。

安全性

Cloud Functions 那邊用 Firebase Auth 處理驗證,不該外流的 key / secret 也沒有暴露給人看,看起來還算安全。

費用

便宜,目前 Cloud Functions 每個月花不到 100 台幣,當然使用者少也是一個原因。

速度

Cloud Functions 對 PTX 那段的速度還行,但我 Server 那邊就有點問題了。Cloud Functions(台灣)、VPS(日本)、Database(日本)分屬不同雲端服務,且分散在各個位置,這是先天不足之處,加上我沒有完全榨出那台 VPS 的效能;這問題我最後用連線策略跟使用者體驗處理掉,實際感受沒有那麼慢。

最讓我有感的是 Cloud Functions 沒用時會睡著,要用時才會被喚醒,這個啟動時間超過十秒。就我自己觀察:有時打開 App 的前兩個 API request 會特別久,回應時間遠超出我的預期,即便我調整 Cloud Functions 的常駐數量也無法達到舒服的回應時間。但這就是它便宜的原因,想改善就是要換掉。

潛在成本

PTX 之後可能會收費,加上它是有使用上限的。目前爬蟲抓 PTX 資料是不可避免的成本,但主功能連 PTX API 那段其實是可以省下的,在正式處理之前都會是個隱憂。

未來可行方案

Typo, Radis -> Redis

未來若有機會不計成本,我想以這個架構來實作。自然是囊括上述提到的所有優點,但目前的我還無法實踐,需要先擴充我的 SRE 技能點以及我的口袋深度。認真來看,這應該可以滿足商用等級的需求。

留言列表

Copied title and URL