Programming Language Notes

  圖片來源 這次會分享關於「鎖」的主題除了工作上遇到這樣的情境之外，也發現到其實軟體技術大部分跟我們生活情境息息相關，覺得非常有趣，因此嘗試將艱澀難懂的技術化為淺顯易懂的圖文知識來幫助大家快速理解，除了應用在工作上，或許對於生活過程中遇到的一些問題也能得到一些啟發。 此篇章主要著重於觀念的分享，並不會深入探討實作的細節，相信只要觀念通了，對於技術實作的道路上一定會非常順暢，好吧！廢話不多說，趕快來介紹一下樂觀鎖與悲觀鎖的基本觀念。 情境 軟體開發的過程中想必我們開會過程中常常會聽到以下的關鍵字句： - 併發問題就應該用樂觀鎖啊！ - 最安全的併發正確性應該用悲觀鎖吧！ - Scale Out的服務怎麼保證正確呢？ - 啊！雙十節要到了，如何確保客戶的訂單與商品數量是正確的又能兼顧效能？ 以上的問題都圍繞在效能、正確性， 而其中最關鍵的就是「鎖」， 雖然「鎖」難免會造成效能的下降， 但這點不足之處對於現階段的群集架構之下， 已經能夠透過橫向擴展的方式進行補足， 因此「鎖」的技術值得我們好好認識一番！ 悲觀鎖(Pessimistic Lock) 😭 圖片來源 就如同字面上的意思， 對任何的事物都很悲觀， 而這種情緒之下的處理方式就是盡量鎖住整個資源， 保證整體一致性之後再釋放， 雖然安全但效能下降程度非常的高。 以生活化的例子來說， 當我們要去餐廳慶祝一下的時候， 通常就兩種作法， 不是預訂就是現場候位， 那麼較悲觀的人可能會事先安排， 因此會進行訂位的動作， 那麼一旦訂位之後， 該位置到某個時段就等於是被「鎖」上， 直到我們用完餐之後才釋放， 這樣的情境下確保我們能正確的慶祝用餐， 但對於資源使用上來說就相對耗費了， 尤其當我們發生非預期狀況之下無法到場時， 原本餐廳能夠服務到更多客人， 卻因為我們的「鎖」而導致服務客人的量減少了， 餐廳也少賺了一些客人的消費金額。 優點 - 保證「鎖」上的資源能夠完整處理操作後再釋放。 缺點 - 「鎖」的粒度太大導致資源的浪費。 樂觀鎖(Optimistic Lock) 😀 圖片來源 先做就對了， 有衝突再解決...。 一樣以餐廳為例， 這次就變成現場候位的狀況， 不採取預訂方式， 有位置再吃， 大不了下個時段再來， 這樣對於餐廳端來說， 資源閒置的狀況減少了， 每一桌吃完就服務下一桌， 以軟體技術語言的角度來說就是...

  圖片來源 相信身為軟體工程師的朋友們應該常常聽到宣告式及命令式兩種不同的名詞吧！ 想當初剛入行的阿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 decla...

  對於軟體世界中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) 圖片來源...

  企業常常有代理人機制， 當我們有重要的事情需要請假時， 就會有代理人幫我們處理公司事務， 相當於「我們授權代理人處理什麼事情」，而這樣的代理機制在軟體世界也是常見的一種機制， 尤其是在分散式運算的架構下。 那代理能為我們帶來什麼好處呢？ 又為什麼非用不可？ 這也是我們今天著重探討的主題。 其實代理就是你跟我之間隔著一層， 彼此不知道對方， 只知道往哪邊遞送資料， 從而解決雙方的依賴， 尤其伺服器端如果是一群機器在服務， 撇開代理， 用戶端勢必得自己管控要送到哪一台機器去處理， 那刪減及增加機器時怎麼辦？ 對於用戶端不就得常常停機，更新這些機器的位置， 這對於應用上來講就大打折扣了，因此有了代理之後，這樣的問題就迎刃而解了。 另外我們可能也聽過反向代理這個詞， 後面也會進行介紹，說明一下什麼是正向代理，什麼又是反向代理。 使用代理帶來哪些好處？ 快取 由於Server與Client之間隔著一層Proxy Server，因此該台機器就可以加入緩存機制，當資料未發生變化時，每次Client的存取所看到的結果都會是一樣的，因此我們就可以將緩存的資料直接送往Client端，而不用往伺服器發送，減緩伺服器的壓力。 匿名性 透過Proxy的轉發，Client端並不知道真正處理請求的機器到底是哪一台，只知道要把這個請求送給Proxy請它代理處理。 流量控制 有了Proxy做為中間人，在這裡就能夠掌握流量，並且依序負荷程度進行適當的調配，避免阻塞。 稽核日誌 由於所有請求都會經過Proxy，因此在這裡非常容易掌控來源與目的，想當然也就更容易達到稽核的目的了。 先來搞懂正向代理與反向代理吧！ 正向代理 其實正向代理就是以Client端為出發點，Proxy的角色就是中間人，中間人可以為Client進行服務，代為向伺服端發送對應的請求，那麼相對的以這個角度來說，應該站在Client的立場進行服務，包括匿名、翻牆…都是正向代理的服務範疇。 反向代理 而反向代理就不一樣囉，以服務端為出發點，替他們站在最前線，阻擋非必要的需求，就很像PM跟PG的角色，PM站在最前線釐清需求後，再往後派工。 反向代理能夠帶來什麼好處？ 負載平衡： 由於運算量比較大的負擔會在伺服器端，因此在最前線的Proxy自然可以做到分散負擔的任務，才不至於太多的請求...

  Business Analyst簡稱BA，即業務分析師，在軟體開發職位打滾了幾年也是最近才聽到這個名詞，好奇心所趨之下來了解BA到底是什麼？ 主要的工作內容是什麼？ 在公司裡又是扮演什麼樣的角色？ 我們可能會想說BA不就只是每天與客戶溝通而已，寫寫使用者故事，主持主持會議，有時候又做為夾心餅，不斷的在客戶與開發團隊之間忙得不可開交，常常被挑戰不合理的需求怎麼開發，被質疑這種需求應該要能夠做到，為什麼不行，我想這對於外行來說常常看到的就是這樣的表面吧！ 但其實BA並非我們想像的那麼簡單，最終目標就是「用對方聽得懂的話去告訴對方不懂的事」，因此邏輯能力與溝通能力非常重要，當我們越具備這種能力，所能發揮的影響力也越大，在公司的地位相對的也越高。 尤其是現在任何商機都是講求數據的時代，若身為一個商業分析師能夠掌握數據、分析數據，相信用數據說話能夠引領公司做好一個重大的決策。 扮演著什麼樣的角色？ 如何計劃一個專案？ 制定商業目標： 找出客戶的痛點，制定藥方研發計畫。 蒐集商業需求： 探訪客戶痛點的過程中想方設法蒐集更多需求，並思考如何將這些需求轉化為專案目標。 分配資源： 需要什麼樣的工程團隊？ 工程、數據、…，需要什麼樣的內部資源？這些都是需要思考的範疇，並找出這些資源進行分配。 扮演利害關係人與工程團隊的橋樑。 蒐集客戶的反饋： 做為持續優化的養分。 建立報告： 透過專業技能將資料分析為有用的報表，並以報告方式呈現。 成果發表。 需要哪些專業技能？ BA不只是簡單的溝通而已，更重要的是手上掌握了許多資料，如何使用專業技能將這些資料有效的分析，並提供給老闆、客戶、工程團隊進行有效溝通，減少隔閡，而不是單純著扮演著橋梁的角色，別人提供什麼輸入就原封不動的進行輸出，反而是要轉化、分析、以對方聽得懂的語言去進行溝通才能發揮最大的價值。 具有哪些責任？ 解決企業內部遇到的挑戰。 分析數據，從資料中挖金，探嗅商業機會。 為客戶制定策略與解決方案。 做為公司各部門與客戶間重要的核心橋梁。 改善流程、策略制定。 結語 數位化的時代之下，軟體的需求也越發重要，複雜性也越來越高，我們常常發現需求與理解的過程會不斷的發生矛盾，而面對這樣的矛盾就需要有一個橋樑去化解，因此軟體開發不只是硬技能重要，軟技能也是不可或缺的能力之一，...

  軟體世界隨著現實應用越來越複雜，需要處理的資料量也就隨之倍數增長，假設我們每一個動作都要等待處理完畢後再回應，那麼勢必對於廣大用戶的使用者體驗大打折扣，因此這個過程如果有一個中間人幫我們處理掉先來後到的流程，那麼是不是我只要將要進行的動作交給中間人即可，而背後處理的服務商則透過中間人依序處理，處理完畢後再告知業主即可，相信會大幅提升使用效率。 同步與非同步任務 在進入Message Queue之前我們先來了解一下同步/非同步任務的概念。 圖片來源 菜單稱為訊息(Message), 為工作內容描述。 送出菜單的客人稱為生產者(Producer), 負責建立訊息。 櫃台就相當於Queue, 負責接單並依序處理。 廚師就是消費者的概念, 負責消化Queue裡面的訊息。 什麼是Message Queue? 採生產者/消費者模式，主要提供不同process之間通訊的方式之一。 Producer: 負責生產訊息。 Consumer: 負責接收及處理訊息。 應用場景 應用解耦 用戶下單後, 訂單系統需要通知庫存系統, 但是假設庫存系統故障, 就會導致客戶下單失敗。 圖片來源 引入Message Queue之後 圖片來源 訂單系統: 用戶下單後, 訂單系統完成持久化工作後, 發布消息到Message Queue, 並返回下單成功。 庫存系統: 向Message Queue訂閱下單的消息, 再根據下單的訊息內容進行庫存的更新。 如此一來客戶下單時假設庫存系統故障, 仍可正常下單。 並行處理 圖片來源 帳號註冊成功後還需要發送Mail及簡訊, 如果還沒有Message Queue時勢必需要依序發送, 但如果中間隔了一層Message Queue時, 簡訊系統及Mail系統就可以各自獲取訊息並處理。 流量控制 電商平台常常推出限時搶購活動, 但如果大家都在同一時間發出請求, 那麼當訂單系統無法負荷時將造成下單失敗, 勢必引來使用者抱怨的狀況, 而為了防止這種後端被壓垮的狀況, 可以導入MQ的架構來因應, 透過Queue來堆積下單的請求, 當系統有能力處理時再進行處理。 下單系統收到請求後就先丟到Queue，當Queue已經超出最大設定值時就reject請求。 訂單處理系統根據Queue的依序請求訊息進行後續...

  CDN全名為 Content Delivery(Distribution) Network，內容傳遞網路，光看名字應該還不知道能夠做什麼吧！那為什麼又要有CDN呢？ 主要是因為現在的時代，很多事務都開始搬上網際網路，而且參與的對象已經是全世界了，假若因為距離太遠，導致載入時間過久，相信對於使用者體驗必然大打折扣，因此CDN的出現主要是克服了這樣的限制，至於為什麼能夠克服呢？ 接下來的主題就是來談談這個部分。 沒有CDN時，遇到什麼樣的問題？ 當使用者距離我們的伺服器越遠時，傳輸速度必然會因為物理限制下減緩，加上如果流量又多，勢必會造成塞車的狀況，就像我們早期在瀏覽國外網站時一般，光是載入一個簡單的靜態頁面就足足等了幾分鐘之久，對於使用體驗上來說已經大打折扣。 加速的方式 其實就是分身的概念，建設多台伺服器的佈署，每一個節點都有儲存快取資料，因此當我們在瀏覽一個國外網站時，會優先以該國家附近的伺服器節點開始抓取快取資料並展示於瀏覽器，不需要全部連回主伺服器，也因此減少了主伺服器的壓力，讓讀取更加快速。 一個網站如果剛開始建置時，流量不大，都不會造成負擔，但當有一天營運的規模快速增長時，回應速度可能就隨之減慢，延遲時間也隨之變長，過往我們通常會再採購一台伺服器並搭配Proxy來進行轉發，負擔原本伺服器的壓力，但仍沒有解決物理距離的問題，因此CDN就很聰明的做為緩存伺服器分散在世界各處，並定期將網頁伺服器的快取資料同步到各個CDN節點。 就想像成物流中心，在各個地區都設置區域性的物流倉儲，前一天統一集貨到各個地區的物流倉儲，再由各地區的司機去運送，減少運輸時間。 CDN伺服器如果沒有資料怎麼辦？ CDN伺服器也有可能因為當機的因素，沒有緩存到網站伺服器的資料，這時候當瀏覽器存取最近的CDN伺服器時，若取不到資料就會再往下一台找，直到找回網站伺服器為止。 對於使用者端來說要怎麼自動找其他節點？ 通常我們會經過一個DNS伺服器幫我們決定去哪裡抓資料，就將其想像成查號台，我們先打過去查詢目的地的號碼，再進行打電話。 除了讓網頁更快的載入還有什麼作用？ 這時代最流行莫過於影音直播了，假設沒有CDN的分散負擔，當千萬人都透過一台伺服器讀取直播內容時很容易發生延遲的狀況，因為我們的頻寬就是這麼大，流量就是這麼擠，試想當高速公路塞車時的盛況就...

  Latency 延遲 執行一個操作要花費的「時間長度」。 舉例來說，時速100公里的前提下，從台北到高雄大約花費4個小時，而這個花費的耗時就稱為延遲。 Throughput 吞吐量 以一個時間區間作為單位，單位時間內可以執行「幾次」操作，或運算的「次數」。 舉例來說，時速100公里的前提下，從台北到高雄的路段，每一個小時能夠乘載的量能，以高速公路來說，一台車可以乘載4個人的理想狀況之下，那麼從台北到高雄一台車需要耗費3.5個小時，也就是平均一個小時可以乘載1.14個人。 Bandwidth 頻寬 以高速公路來說，假設A地到B地的路段都是四線道，理想的狀況下，四線道都通車，且不塞車的狀況下，同時並行四輛車就稱為頻寬。 結語 對於以上的名詞具有基本的認識之後，我們可能會想，如何減少延遲與提高吞吐量呢？ 減少延遲最簡單的方式就是提高時速、減少風阻...，也就是提升硬體資源，讓處理速度更快，減少延遲。 提高吞吐量的部分重點在於如何在有限的道路限制下運載更多的量到目的地，以高速公路來說，我們可能會採取高乘載管制，盡量讓每一台車(封包)，塞滿人(資料)，達到最有效率的運輸，讓道路的空間發揮到極致，並搭配最低限速來減少塞車的狀況。 增加頻寬雖有助於提升運載量，但如果沒有從減少延遲與提高吞吐量來改善的話，很容易誤入加大頻寬解決一切的陷阱。 其實我們會發現很多生活中的例子都應用在軟體領域的解決方案之上，我想兩者是相輔相成的，所有的解決方案都是基於我們人類的智慧，因此不論是虛擬甚至是實體生活，我們只要好好思考出一個策略就能解決眼前遇到的困難。 喜歡撰寫文章的你，不妨來了解一下： Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 - 為什麼要加入？ 歡迎加入一起練習寫作，賺取知識，累積財富！ ⭐ 跟著「阿Han」一起來閱讀、撰寫文章，讓知識變現吧! ⭐