mrkt的程式學習筆記

將兩篇文章的原始碼做了整理，然後放上 Github

過去工作專案大多使用 RabbitMQ 來處理訊息佇列，RabbitMQ 的幾種模式（Direct, Topic, Fanout）都有使用，因為都可以解決大多數的應用情境，所以就沒有想要去使用 Kafak，畢竟多建立一套服務就需要再多花時間去維護。

一直以來也想要找個時間來玩玩 Kafka，於是就利用週末時間學習怎麼使用 Docker 架設服務，程式開發練習怎麼使用 Confluent.Kafka，這是一篇學習筆記。

之前寫了一篇「使用 Channels 與 BackgroundService 實作生產者-消費者模式（Producer-Consumer Pattern）」是使用 Channels 與 BackgroundService 來實作，而這一次就來改用 Wolverine 這個套件來試試看。

有關 Wolverine 這個套件我也看了好久，一直想拿來試試看，會想要用這個套件，主要是它是一個輕量化的工具，適合用於整合訊息佇列、事件驅動設計和後台任務處理。

而且也因為適合用於整合訊息佇列、事件驅動設計，所以支援了許多第三方服務，例如：RabbitMQ, Kafaka, MQTT, AzureServiceBux, AmazonSqs 等，所以打算之後也繼續玩玩 Wolverine。

過去的工作專案為了要加快 Request 的回應速度，所以就想方設法地去做了很多的調整…

例如一個訊息建立後要做很多的事情，像是要許多相關資料 Table 的資料異動、透過 RabbitMQ 去發送 message 通知其他 Client、快取資料的更新等等等

這麼多的處理如果都是在一個 Request 裡全部處理完成後才回傳 Response 結果，因為每個處理都會花費一些時間，全部累積起來就相當可觀，於是就會想到是不是要往平行處理或多執行緒的方式來解決，但是在繁忙的網站服務去使用這些解決方案又有很多風險，程式沒有寫好的話就會出現嚴重錯誤。

所以就想到用發送事件的方式，當訊息建立完成後，就發送一個事件到一個佇列裡，然後有一個 BackgroundService 去專門接收訊息建立完成事件，當收到事件後就開始一連串的處理，這麼一來 Action 方法的回應時間就能夠加快一些。

前一篇文章「練習題 - 設計模式 - 責任鍊模式 (職責鍊模式) Chain of Responsibility Pattern」是不藉助任何套件的方式下完成實作，但我總會想應該是有人會做個 NuGet 套件來讓開發者可以直接套用就能夠完成責任鍊模式的實作，找了一輪後發現到還蠻少的，雖然少但也還是有一些，不過有的是已經很久沒有更新或是用的人不多，而有些是不適合真的拿來使用，有這種情況大概是責任鍊模式的實作其實並不複雜。

不過還是有找到一個還可以的套件，所以就拿來用在之前的練習題裡，看看是不是適合。

工作專案裡並不會去刻意地去使用設計模式，不過在很多時候為了想要有更好的實作，又或者是覺得當下的程式一定會有更好的解法，就會去找目前情境所適合使用的設計模式來改寫。

有的時後會看到誤用了不適合的設計模式所實作的程式，明明應該是用行為類的設計模式來做，卻用了結構類的設計模式來做，雖然最後的執行結果是有符合預期，但怎麼看就怎麼怪，所以設計模式還是要好好地認識認識，於是這次就來練習練習責任鍊模式。