KK 的 Web 實驗室(Day28–30)
‘Flames to dust Lovers to friends Why do all good things come to an end?’
32 成為看起來很強的後端：運算是什麼？
KK 老師今天來談談運算(Computation or Computing)，也就是商業邏輯的部分。
以電商網站為例，運算包含計算商品價錢、訂單總量、折扣金額、過去消費習慣…等等。
如果是遊戲的話，運算談的是如何從a點走到b點、中間練了什麼技能、揮了幾刀、損失多少血…等等。
那我們要怎麼區分各種運算呢？
用「使用位置」區分運算
一種是「雲端運算」，會在遠端的在 Server 上做運算。
優點：
不用吃本地端的效能，可以有非常多台機器做運算。
可以讓更多人進行連結，比較好擴展。
缺點：
沒有網路或網路不穩的時候就不能使用。
一種是「本地運算」，也就是自己的 Client 端做運算。
有可能是瀏覽器、App、或是嵌入式裝置（如：智慧手環）。
還有一種是結合「雲端運算」和「本地運算」的「霧運算」（Fog computing），會定義哪些資料適合在雲端、哪些在本地端運算。
前幾年 IoT (物聯網，Internet Of Things) 開始被廣泛討論，各種智慧裝置逐漸普及，如：智能電燈、智能手錶、智能音響、智能監控…等。
這些裝置規格較低而且大小偏小，所以比較便宜但運算能力比較差。
所以本地端需要雲端運算協助。
拿智能車來說，進到山洞或去收訊不好的地方，如果純靠雲運算就可能會出問題。
用「運算種類」區分運算
分為三種：單一、平行、網格，這幾種運算。
單一運算
假設我們拿到很多點數卡，讓一個人拿著一台計算機把點數加總，這就是「單一運算」。
那如果要算快一點呢？
一種方法是讓這個人按計算機按快一點，也就是讓運算的演算法變得更快。
另一種方法是加大規格（垂直擴充），例如從一般的計算機變成工程計算機。
因此單一運算比較難去做擴充或是加速。
平行運算
以剛剛的點數卡例子來說，如果要算快一點，能不能找十個人算？
那這時候就會遇到一些挑戰，例如點數卡要如何分配？
要先每個人拿十張、還是每個人算完一張再去拿一張？
這樣的方式就會影響到「平行運算」的策略。
一個好的策略，不管是十個人、一百個人、一千個人來做，都可以做好。
我們稱這種方式為「水平擴充」。
網格運算
網格運算比較像是單一和平行合再一起。
KK 老師說他對這塊沒有特別研究，不過如果平行運算是一個維度，網格運算就是兩個維度做運算。
以上這三種方法，在本地端、雲端都可以實作。
本地端：
單一運算，從手機瀏覽器（效能比較差）改用電腦瀏覽器（效能比較好），就是垂直擴充。
平行運算各位可能聽過 P2P (Peer-to-peer)或是區塊鏈。 有很多裝置代表節點，互相溝通。
網格運算，KK老師說他不懂。
雲端：
單一機器越換越強。
雲端有各種平行策略來處理大量資料、讓大量的人算同一個東西。
那如果現在有一萬個任務，要分給十個人，要怎麼分？怎麼拿任務？怎麼通知每個人？
33 成為看起來很強的後端：什麼是 Webhook？
為什麼要在網站上做一個鉤子？
各位請想像，門上面放一個掛鉤。
希望達到的目的是：當某件事情發生時，會觸發另外一個事件。
我們假設這個門，是一個 Server 。
今天有人按了喜歡的文章讚、付完款訂單被更新、把物品加到購物車…等等行為(Action)。
這時候鉤子被掛上另外一個行為（Action2）。
實際例子
拿第三方金流來做例子。
通常會看到一個 Webhook 的網址，讓你輸入發生 Action 時要把資料打給哪個網址。
因此當使用者付款的 Action 發生時，Server1 上的 Webhook 會被觸發 Action2 給 Server2。
此時 Action2 會告訴 Server2 幾個東西。
Name 會說明是否付款完成、失敗、預期…等，type 會說明是否為付款或檢修或其他、payload 會有其他的資料。
這裡以 name、type、payload 來說明，實際名稱會由第三方金流做定義。
Webhook 通常使用 HTTP POST 來進行，也就是 Server2 必須開一個 API 讓 Server1 打過來，如 /listen。
而 Server1 就需要設定 Webhook 的 URL 為 https:/server2/listen
Server2 接到這些資料之後，會跟自己的 DB 做串接，來處理這個商業邏輯。
Webhook 模型應用
Webhook 模型很泛用，常在後端的商業邏輯做 event trigger ，處理訂單狀態、出貨…等。
另外一個常見應用就是使用 Github 的時候，把上面畫的圖的第三方金流換成 Github。
當 code 被丟上去 Github ，後端程式會被觸發去幫忙作部署，也稱為 CI/CD。
（CI/CD 是 continuous integration, continuous delivery, and continuous deployment 的縮寫，這邊剛好有篇文章參考。https://ithelp.ithome.com.tw/articles/10219083）
用 Webhook 的缺點是什麼？
以第三方金流為例，如果今天只有付款成功對方才把資料打給你，而付款失敗不會，這樣就會有問題。
因為你可能無法知道失敗的原因是什麼。
Webhook 的細緻程度，就會影響這個第三方服務好不好用。
如果今天在一個比較大的公司，Server1 跟 Server2 是不同的部門在做，當缺資料的時候，只要請另外一個部門多把資料打給你就不會有限制了。
如何透過 Webhook 去進行平行運算？
如果給 Server1 多個不同的 Webhook URL ，當很多 Action 進來就可以分配給不同的 Server 作處理。
34 成為看起來很強的後端：更多 Webhook
透過之前的例子，我們 Webhook 實作有打出去的 outcoming 跟接收的 incoming。
Client 到 Service 之間主要是做商業邏輯的事情，例如轉帳、付錢…等。
Service 主要處理使用者給的各種資料，處理完就打給 Handler 。
對 Handler 來說，Service 打給他的資料就稱為 incoming 或 inbound 的 Webhook。
反之，對 Service 來說就是 outcoming 或 outbound 的 Webhook 。
假設我們在 Slack App （辦公室協作軟體）上輸入 /weather 想要查天氣狀況。
Slack 的 Service 可能就會把這個 Request 存在自己的 DB 裡面，紀錄有這個指令。
處理完後打給 Handler ， Handler 會去找天氣資料（例如中央氣象局）。
然後再把資料打回去給 Service 。
Incoming 和 Outcoming 怎麼看？
圖上的 in 跟 out 是從 Handler 的角度來看，而對 Service 來說剛好是相反。
因此你在談 Webhook 時，要注意你的主詞是誰。
使用的第三方服務 Webhook 通常以他們的平台為主詞。
接下來請用兩倍速看這不到三十秒的複習影片，已經幫大家選好時間了。
