跳到主要內容

發表文章

目前顯示的是 7月, 2022的文章

【程式設計基礎知識】宣告式 V.S 指令式

  圖片來源 相信身為軟體工程師的朋友們應該常常聽到宣告式及命令式兩種不同的名詞吧! 想當初剛入行的阿Han,對於這兩個名詞根本就是覺得文字天書,怎麼也看不懂,但在業界混了幾年之後終於有了一些領悟,也希望透過簡單說明的方式讓大家理解共同學習。 指令式程式設計(Imperative Programming) 圖片來源 這種方式是我們早期所使用的設計模式,先把需要的素材準備好,然後一步一腳印的打造出處理流程,最終產生成果的一種模式,這種模式很詳細沒錯,但是太多雜訊了,對於未來進入維護的新人來說會造成不易閱讀的門檻,以一個簡單的例子如下: --------------------------------------------------------------------------------- function imperative(elements: number[], threshold: number): number[] { // 準備素材 let results: number[] = []; // 一步一腳印的處理過程 for (let i = 0; i < elements.length; i++) { if (elements[i] >= threshold) { results.push(elements[i]); } } // 最終產生成果 return results; } --------------------------------------------------------------------------------- 宣告式程式設計(Declarative Programming) 圖片來源 這種方式屬於先設計在實作,以終為始,腦袋中先醞釀最終期望的成果,過程中逐步使用已封裝完成的功能,並告知每一個功能我所期望的結果,產生出最終結果,以一個簡單的例子說明如下: --------------------------------------------------------------------------------- function declarati

【資訊軟體知識】 Message Queue的傳輸協定 - AMQP

  對於軟體世界中Message Queue有興趣的朋友可以先閱讀這一篇「 【資訊軟體知識】井然有序的處理機制 - Message Queue 」建立基礎知識之後,再來看看這一篇會更容易進入情境唷! 上一篇我們有談論到Message Queue的架構之下,使用到通訊協定之一的「 【資訊軟體知識】 Message Queue的傳輸協定 - MQTT 」,主要追求速度,但另一個傳輸協定AMQP也就是今天的主題,著重於可靠性、豐富性,非常適合用於穩定的銀行體系。 AMQP協議 Advanced Message Queuing Portocol(高級訊息佇列協議) 圖片來源 ● Producer: 生產者, 負責生產訊息並送到交換機。 ● Broker: Message Queue的服務器(RabbitMQ...之類的產品) ● Exchange: 交換器, 它指定訊息按照什麼樣的規則送到哪個Queue。 ● Binding: 綁定規則, 後面會介紹幾種常用的MQ模式。 ● Queue: 消息隊列, 每條訊息都會被送到一個或多個Queue。 ● Consumer: 消費者, 負責接收與處理訊息。 特點 ● 金融業發展出來用於交易所訊息交換的協定。 ● 發布者、交換機、隊列、消費者都可以有多個。因為AMQP是一種網路協議, 所以過程中的發布者、消費者、代理都能分佈在不同的設備上。 ● 發布消息時可以帶上消息屬性(Message Meta), 有些屬性可以被消息代理(Brokers)使用, 有些則為不透明的, 只能被消費者使用。 ● 由於必須假設網路是不可靠的, 因此可能某個消費者處理訊息的過程中可能掛掉, 基於此原因AMQP協議就包含了消息確認(Message Acknowledgements)機制, 確保收到來自消費者的訊息後才將該筆訊息從Queue中刪除。 Exchange交換機 為什麼需要Exchange而不是直接將訊息發送到Queue呢? AMQP的核心思想就是讓生產者與消費者之間解耦, 因此生產者只需要一直生產消息並不需要知道這條消息會被送到哪個Queue, 而送到哪個Queue的工作就是交換機的事情了, 如此一來生產者與消費者的工作就更加單純。 以下是三種主要的交換機類型: 直連交換機(Direct Exchange) 圖片來源 假設我