前言
在確認了產品需求之後，接下來就會走到開發實作的階段，這個階段第一個面臨的問題就是：我的系統要怎麼處理比較好？在回答這問題之前，必須盤點手上所有的資源，尤其要注意這些資源的限制，因為會攸關到可行性。
產品需求見下文：
資源清單
- 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 那段其實是可以省下的，在正式處理之前都會是個隱憂。
未來可行方案
未來若有機會不計成本，我想以這個架構來實作。自然是囊括上述提到的所有優點，但目前的我還無法實踐，需要先擴充我的 SRE 技能點以及我的口袋深度。認真來看，這應該可以滿足商用等級的需求。
留言列表