聊天機器人

今天會帶大家看看如何利用Serverless來擴展像是自動化客服（聊天機器人語意分析）、視覺分析等雲端服務，並接入上面電商MVP架構，以達到高可擴展性的需求。

首先我們必須了解聊天機器人的工作流程，

1. 提供一個視窗給使用者輸入對話內容，並讀取我們提供給他的資訊。
2. 將使用者對話內容接收之後傳送給語意分析服務。
3. 從語意分析服務的結果，做出相對應的動作，並設定即時回覆還是要請使用者等待回覆。
4. 即時回覆使用原本的api回傳回應就好，等待回覆就得使用Websocket。

以上第一點由前端畫面更新出一個視窗讓使用者可以讀取跟輸入，並將該資料傳送到api服務下指定的Azure Functions就可以處理完畢。

第二點則是利用Azure Functions檢查使用者輸入資料後轉發給Azure LUIS(Language understanding intelligent service)，等待語意分析的結果。
第三點為從語意分析結果回傳之後，可能會有需要查詢資料庫的動作，或是立刻回覆及請使用者提供下一步資訊等。
第四點則是回傳一個結果讓使用者，需等待的結果觸發另一個Functions處理並告知使用者的Websocket連線ID，並等動作處理完畢後透過Azure Web App Service提供的Gateway回傳Websocket訊息給前端並顯示訊息。

一個網站擴展聊天機器人功能就只是這樣快速易用，這就是微服務架構的高擴展性。

很多事情感覺很難，但做了才知道到底難不難。

下面這個是Azure官方建議的專用程式架構（我們是以電商原本的架構加上功能來設計的）

影像辨識

我們來了解影像辨識的工作流程，

1. 可能因為某些事情需要影像辨識，像是產品加標籤、產品分類、杜絕不良圖片等功能。
2. 從一個Functions判斷完需要影像辨識的時候就觸發影像辨識並回傳結果給呼叫的Functions。

在電商的狀況可能會再上傳商品圖片的時候壓縮的同時做一個圖片標籤的功能，因此可以在壓縮的後續加上標籤，併一同將影像辨識結果放入標籤後連同圖片的存放的網址回傳。

請記得去評估每個服務的定價，否則等到帳單來的時候賣幾顆腎都不夠。

下面這個是Azure官方建議的專用程式架構

物聯網

那如果我們想要做到收到訂單就把揀貨單跟訂單印出來呢？流程是這樣：

1. 確認收到訂單，就呼叫另一個Functions。
2. 這個Functions只做一件事情，把傳來的資料轉成統一格式，並傳入Azure IoT Hub，讓連上網路的列印機列印訂單。

系統設計就是這樣，定好流程跟規格，就是直接開工。

很多流程沒做過說起來很容易，做起來就是一堆屎坑。

本日小節

這時候大家應該也慢慢了解，今天每一個服務都只要包裝好I/O(輸入跟輸出格式），透過API就可以因應需求而呼叫相對應的服務，而雲端服務商雖然服務非常全面，但也有一些是服務商想不到的，而串接其他提供SaaS服務的公司，透過協商後的API定價，再由Azure Api-management做Proxy即可在自己的Domain下指定一個路徑是專門管理其他SaaS服務商的整合服務，如我們的API，路徑下的qsearch/即是直接傳呼ＱSearch的服務，想好在哪個節點呼叫，再作進一步處理，達到彈性擴展的目的。

更重要的是，獨立開發Functions跟Api的路徑，可以在完全不影響上線的產品情況下自行任意設計。

但要注意的是，資料庫需要做切分或是單向備份。

前幾篇屬於系統設計類別的篇幅，由於觀念性的文章對於實戰經驗較少的讀者來說難免都像是在講道理，筆者接連思考幾天後決定先進實戰，在鐵人賽結束後的幾天再回來將系統設計觀念的部分做一個分門別目，並將實戰後的一些結論呼應到相對應篇幅。

講古誰都會，捲起袖子來幹的沒幾個。