微服務初探 之可不可以不要 動不動就死掉 (一)

最近無聊來研究rabbitmq，加上之前的一些什麼微服務什麼的，
在新買了的nas看到了假設我上圖片或影音檔，它們都會跑出一欄任務顯示處理中，在其他電商的案例也有可以能是以消息佇列進行排程?
舉幾個例子
在以掏x來說訂單不可以消失，貨可以再補，馬先生絕對不會讓你漏掉的機會，

再來websocket實作的消息推播來說，在處理完使用者功能後，server要推送給client

假設使用者沒開機的話是沒法接獲這條消息的，那這條消息就這麼算了嗎? ? 當然你說可以用firebase等等去實作但是在某些地區 大陸這些地區就不能使用 google服務(當然以後說不定會開放哈哈

再者當然你想成本上不許可想自行搭建推播server或許可以使用消息佇列來實作 ,當然不只有rabbitmq
Apache 的 Kafka、阿里巴巴 RocketMq 都各有優點 請大家選擇合適的場景來選擇

那麼以我的認知來說rabbitmq 實作一個類似 nas 處理相片功能 可以做到下列功能

影片傳到後台後 呼叫大量 ffmpeg 去處理相片功能，+人臉辨識 進行分類那麼我們用

rabbitmq進行實作可能會變成下列這樣

微服務 最近幾年好像很夯，應該是它裡面的可擴展性，當然像一般的程式，你把所有功能寫在同一支
當負載太重 導致程式 crash

那摩何嘗不使用一下rabbitmq 你就可以透過水平擴展增加負載量較大的功能
rabbitmq 有支持HA - High availability
跟負載平衡很像不過又好像有點不一樣(自己去查一下
所以你的功能就掛了或許可以參考一下 rabbitmq，其二我選擇他的原因就是他以前是負責金融交易平台的重要利器所以穩定性呢可以說相當的夠，再來就是它是免費的，無聊可以玩一下
其三就是不同的消息佇列可以支持各種不同語言來編寫，這邊在應對新的世代我們可以銜接各種不同的程式語言以便擴展。

那麼 參考以我的了解跟剛剛要實作的情形是這樣

錯了別罵我，保持著討論心態
(上圖假設沒錯的話，記憶有點模糊xd，這個月在休息
這邊舉例呢可以看到，
-------->這是針對 任務處理完 沒有要返回訊息給其他佇列的情況下

那麼我們的server端 可以 開始指派任務也就是 我們的生產端將產生一個任務給我們的消費端
可以看到我們的消費端有兩個一個是負責處理 影像壓縮 一個是負責 臉部分類
那麼呢

兩個使用者上傳影片到 nas
就可以看到影像壓縮任務c1,c2放在佇列等待被消化
裡面的任務欄位中間可以我有寫 看到 同步(async) 和 非同步 (sync)
裡面的任務就算失敗了也可以被重新執行到成功這點算蠻重要的(當然你程式要寫好xd
那麼大致流程圖就是這樣，當我們的某一部分功能負載過於嚴重我們就可以

直接水平擴展一部分功能，當然你可以看到 生產端到 消費端 其實裡面還隱藏了一小部分的功能
exchange可以根據我們的chanel 選擇頻道進行 任務的派送

比如說 chanel1 的 消息佇列裡的其中一個任務c1已經完成
那麼則再通知生產端產生一個任務給chanel2
那麼chanel2這邊任務分配就會變成



進行任務上的分配 所以我們可以看到我們的功能佇列可以透過 水平擴張 依據機器 的流量以及處理能力來進行權重上的調配

-------->這是針對 任務處理完 返回訊息給原始佇列的情況下
那麼這種情況有沒有可能任務佇列跟任務佇列 要進行溝通這種情況呢?
你可以透過 grpc 進行任務上的溝通

我們的機器上c1的任務被處理中並呼叫 生產端產生 其他兩個子任務c2 c3

那麼這邊有兩種
第一種情況
c2裡面任務先被消化那麼他就要等 c3裡面的任務 消化完再 發送給訊息 給 c1
第二種情況
c3的任務消化完畢， c2的任務完成還沒完成等待c3，c2才可以發送 任務完成給 c1
解決方式就是邏輯寫在c2完成後，在透過grpc 取 任務佇列的 c3任務進行判斷完成後再 發送訊息給c1 說任務已經完成。
這邊可以看到，微服務在某些環境確實有點不錯，但是在 任務複雜度太過於多的話，可以由上方例子得知程式與程式之間的溝通不太方便雖然有rpc 通訊
，所以我們要避免的就是微服務不要拆得太細就可以解決我們的系統效能上的瓶頸。

然後最後上方的所有範例圖要等最近有空才會做簡單 demo ，等待穩定後這一篇我會詳細補充，修正其錯誤知識(ps 總覺得技術落差一直卡在兩年前