敗口罩開發記錄-基礎架構篇

  • 4560
  • 0
  • 2020-03-21

距離這個達94萬好友數的Linebot出生差不多剛好滿月,是時候來做個個人記錄了,緣由就不多浪費篇幅說明,簡單來說一開始只是為了方便自己和親友能快速查到販賣口罩的超商位置,就在開發完Linebot後,政策改為只有健保藥局才可以販售口罩,最後進化成藥局版,身為技術人用技術幫助自已也是件合情合理的事

使用者介面的選擇

做為一個side project性質的應用,使用者介面的選擇並不想花費太多時間,並且在考量隨時可用的方便性情境下,選擇使用Chatbot是最先浮現的想法,而Line是最常用的平台,對於操作熟悉度來說更是不做第二人選,加上原先已有自行以C#語言封裝Line API,因此在開發速度上也是最快的。

Chatbot核心Host環境

Chatbot不像一般Web或APP的應用,訊息的互通並不是直接對接,也就是使用者的訊息是先進入到Channel平台(在這裡指的是Line平台),再由Line平台轉送,相對的Bot要回覆的訊息也是要先進到Channel平台,再轉送至使用者的Line上面,這中間的訊息的互通靠的是Webhook機制,所以必須選擇一個平台來Host我的bot APP,因此我個人熟悉的Azure雲端平台成為了優先選項,而最後事實證明Host在雲端是對的選擇,從沒意料到有機會能創造成一個累積94萬好友數的Chatbot,以及處理現實上瞬間高流量的衝擊。

在實名制口罩販售的當天,每分鐘的請求數量一度衝上2000,即便在前一天調整完程式功能部署至Azure後已有預先提升Web APP應用層級,仍然突破原先的設想量,但也幸好是在雲端,因此可以靠著Auto scale的機制自動調節,應付突發性的高流量請求,Auto scale的機制可以依據像是CPU、IO、RAM等情境,設定好條件規則後,不須人工介入,當系統環境滿足條件後自動進行擴展,但要注意的是別忘了也要設定自動降載,否則一旦過了高峰卻沒降載回來,那荷包君可是會失血的,除了環境要能快速應變之外,這個Linebot要應付高流量還有其它幾個關鍵的關卡。

首先是資料來源端,因為口罩庫存是即時變動的(有些使用者抱怨數據不準,其實多數是號碼牌的因素造成,非常時期大家多體諒囉),若資料來源端承受不住,大概所有口罩的應用會全掛了,幸好目前看起來資料來源端是很給力的。

再來就是程式邏輯整合資料面的速度,資料是分散的,舉例來說口罩數量是一個數據源,健保藥局資料則又是另一個數據源,再加上經緯度資料,有些資料變動頻率不需太即時,就可以預先做處理,像是藥局地址的經緯度 (總不會時時刻刻搬家吧,就可以利用每天半夜再更新藥局資料),也降低部份效能壓力。

最後則是Line的Webhook傳送速度,畢竟訊息的接收以及回覆都是必須透過Line平台,這部份實際運行下來是可靠的,沒有遇到延遲的現像。

bot 整體平均回應大約都落在1秒左右。

該Auto scale UP或是Auto scale Out

前面提到自動擴展,應付突發性的高流量請求,然而我們是該選擇Auto scale UP或是Auto scale Out呢?一般簡單來說scale UP通常是對硬體層的提升,而scale Out則是增加多台機器分散處理效率,在這一次的情境,我是選擇scale Out方式來進行擴展,主要是我觀察到瓶頸並不是在IO的處理上,且RAM的耗用也沒有特別高,因此選擇使用scale Out方式來達到類似負載平衡的概念,當然要做到真正的負載平衡是可以選用Azure Load Balancer服務來進行。(Azure Load Balancer

整合Azure bot service

在最初版本除了把bot核心Host在Azure雲端平台上,也使用了Azure bot service,其優勢是能快速以幾乎零程式碼的概念,將Bot核心與Channel連結並且能跨不同的平台,例如Line+facebook messenger,擴及更多的使用者群眾,除此之外Azure bot service的dev framework支援對話流程的設計,若是chatbot有對話管理及流程設計的需求,也是可以考慮使用的。(可參考先前的文章)(Azure bot service )

什麼是Webhook

前面有提到Chatbot的運作模式,訊息必須透過Webhook機制,由Channel平台(Line)做訊息的轉送,怎麼建立Webhook,事實上我們可以建立一個Web API來處理,以Linebot為例,當你在Line後台申請建立一個Linebot後,會需要你填入一個Webhook的URL,當使用者有發送訊息至Linebot時,訊息會主動傳送至這個URL,簡單來說可以視為後端伺服器訂閱機制,當有事件發生時,通知者(Line平台)會主動通知訂閱者(我們的bot),這就是Webhook機制,目前所知的Chat Channel基本上都是這樣的運作模式。

本篇簡單記錄一下基礎環境及bot架構,下一篇預計針對納入LUIS服務做個記錄。

學習資源

 

若本文對您有所幫助,歡迎轉貼,但請在加註【轉貼】及來源出處,並在附上本篇的超連結,感恩您的配合囉。

By No.18