iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 30
0

Cold start

其實個家園端平台多少都會有這問題,畢竟大家都是靠流量賺錢,自然會需要個方法限制使用者,不然免費爽爽用他們也不是做慈善的 ?,像我最常用的 Heroku,只要 30 分鐘沒有使用他就會進入睡眠時間(參考),叫醒的時間需要 10~15 秒,不過對於我這個免費宅來說測試夠用了 ?

AWS以我實際測試起來大概 2 秒左右,回應時間看起來不會太差,其實第一天就有提到這部分,需要的話可以參考。

若是需要它隨時都在都活著的話就要搭配 warm-up,抑或是搭配 crontab 去設定特定時間執行 warm-up。

Function as a Service

在快速成長的前、中期是很適合這個服務的, 畢竟開發者只要將 serverless.yml 基本設定完之後就可以先好好開發,等到中期之後把設定檔稍微整理一下又是一尾活龍了,且平台大多都擁有 auto-scaling 的功能,在服務快扛不住流量的時候只要錢拿出來平台就幫你解決。

只是說當流量越來越大之後相對錢也會越付越多,或許當流量 > 10K 之後代表你的服務應該也有不少人使用了,自己架主機應該不會是什麼難事(?)

幫忙推廣一下 Backend 大大的 高流量心得雜談

在 FaaS 架構下其實很適合 Chatbot 的服務,以概念來說實作時只需要一個路由**(Function)**即個完成,不需要額外太多的資源去處理 web server 的問題,像是這個系列的只要透過 serverless + WSGI 就可以馬上就可以進行本地測試,部署只要下 sls deploy,實在是超級快又輕鬆,不用像以前一樣還要去處理 Nginx 等等相關的問題 ?。

且 AWS、Google 在使用 python 跟 nodejs 上支援度很高,也不用怕找不到資源使用。

使用 Node JS 的朋友可以參考 C.T Lin 大大的文章,他們家的 bottender 超猛的!

Log

在 Log 這部分我覺得 AWS 有點不太好的地方就是他們的 Cloud Watch 應該是獨立服務,當我的 Lambda 輸出紀錄時大概要過 10 秒才會印出來,不像以前自己架主機時只要進 server 就可以馬上切到目錄看紀錄抓蟲,在使用這雲端服務可能在抓蟲有一半的時間都在等 log 出來,有時候急的時候還真的會被氣死 ?。

SNS

像是我前一陣子發的一篇文章,SNS 被觸發事件之後回來的東西是舊的,那時候看到錯誤訊息真的是心很涼,就得用一個 Lambda 排程一直去抓 DB 的 updated_at 欄位有沒有變更時間而去更新狀態,這樣情況就會多浪費一個 Function 去處理這樣的事件,不得不說專門來支援 AWS 服務的 boto3 套件(python)在某些時候做的事不是那麼完善,得使用旁門做到的方法去完成這件事,讓整個開發體驗不是那麼好,若他們可以把一些 error handle 弄更好那就完美了。

結論

其實還有好多服務沒有玩到

但其實使用 AWS 來實作 Serverless 的服務也是這一陣子加入新公司所學到的新技能,過程中總是會用舊的開發思維去想,但常常都因為這樣落坑 ?,但也因此讓我更了解像 AWS 這類的雲服務他們是如何開發每個服務並如何串接,同時也研究了 Serverless 相關的 plugins,看他們是如何支援雲平台讓開發者在開發時可以更像平常時在開發 web,也因為這樣我去貢獻了 example 到了 Serverless 的範例專案上面(參考),慶祝完成人生第一場鐵三十,跟自己的競賽也告一段落,發現趕著寫文章品質真的會差很多,看來是時候該整理一下,謝謝您的收看 <(_ _)>


上一篇
Day 29 - LINE API 的使用心得
系列文
一步步帶你了解 AWS & LINE API 並使用 Serverless 介接的各種應用30

尚未有邦友留言

立即登入留言