安德魯的部落格

  1. 架構面試題 #5: Re-Order Messages

    好久沒有來練習解題的技巧了，這次來聊個有趣的題目:

    如果我透過 API 短時間收到大量的 Request, 我如何保證訊息必須按照順序處理?

    順序問題，我常碰到的是都不分青紅皂白的就丟到 Message Queue, 結果塞進去的順序就已經不對了，才來問我順序該怎麼辦, 我只能雙手一攤說我也沒轍啊 XDD! 如果你沒辦法一開始就用對的順序放進 Message Queue，你就必須自己面對這問題了。這篇我就是想來聊聊，當 “必要” 時，你會如何處理這種問題?

    當年在學網路通訊時，TCP 跟 UPD 的差異就是會處理封包順序 & 重送問題，也剛好讀過背後的作法，你懂原理後就會有機會自己解決。類似例子其實很多，QoS 的應用也是，先前研究過的 微服務基礎建設: 斷路器 #1, 服務負載的控制 那篇，你懂 QoS 怎麼做 Rate Limit，必要時你就能自己解決商業需求。

    2023/10/01 系列文章: 架構師的修練 系列文章 架構師的修練 架構師觀點 刻意練習 抽象化

  2. 架構師觀點 - API Design Workshop

    最近這陣子，我對外分享的主題，其實都集中在 “API First” 身上。碰到一些朋友給我的 feedback, 我覺得挺有趣，我挑一個，放在這篇實做篇的最前面:

    Andrew 你談的技巧 (例如: 狀態機, 認證授權, API 開發與測試) 其實我都懂，但是為何你能把這些技巧串再一起? 用這方法來開 API Spec, 我連想都沒想過，而且外面也沒多少人是像你這樣組合起來用的… blah blah (以下省略閒聊的 800 字)

    是啊，這老兄講得沒錯啊，這的確是我自己的經驗談。我擅長的就是只靠幾樣精通的基本功夫，善加利用組合，就能拿來面對許多未知的問題。先前一篇聊職涯發展的文章，我就談到 “知識的連結”，這就是我展現出來的應用。當你每一項技巧都熟練到某種程度以上，你就有自由變化的能力了。能夠達到這種層次的技能不用太多，但是你只要多掌握一個，你能應付的範圍就是別人的好幾倍。我拿來應用在 API First 這主題，就是其中一個案例。

    API 的成功與否，規格定的好不好 (這是設計議題) 占了 70% 以上，規格定對了，後面的實做 (效能，可靠度等等) 做得好才有加分。而 API 的規格怎麼定，講白了很吃設計者的經驗。前陣子 FB 都在分享一篇 “一流工程師可以用很簡單的方法解決問題”，這情境套用在 API 的設計上再洽當也不過了。你如果能看透 API 背後要解決的問題，開出適合的介面，並且用恰到好處的技術跟工具把她實現出來，這就是個成功的 API。對我而言，我的手法就是 OOP，如何用物件導向的想法去分析 API 背後要處理的問題，然後把物件的介面 (interface) 翻譯成 API 的規格。

    因此，正文開始之前，我就加一段在正式演講都沒有談到的內容: 物件導向的思考方式 吧!

    2023/01/01 系列文章: 微服務架構 系列文章 架構師的修練 microservices

  3. 架構師觀點 - API First 的開發策略

    這篇的內容，是我在 DevOpsDays Taipei 2022 的 Keynote 演講的主題: DevOps 潮流下的 API First 開發策略。這場次的內容，正好是我近期正在努力的方向，演講的時間有限，沒能 100% 表達我想講的內容，於是我還是用我最習慣的方式: 文章，重新來闡述一次這個主題吧。

    API First, 講的是在你的開發流程內，API 應該被擺在第一順位思考的開發策略。一開始就瞄準 API 為主軸的開發方式，你會發現整個流程跟思考方式都不一樣了，這就是我這篇想要傳達的主軸。我在第一部分先花了點篇幅，說明 API 為什麼應該要 “First” 的理由。API 是很講究事前的規劃與設計啊，有時候會讓人有跟 DevOps 闡述 “先交付價值，尋求回饋持續改善” 的快速循環有所衝突的錯覺。這並非是你要做出二擇一的選擇，而是在持續改善的循環中，有沒有掌握好長期的目標的差別；而 API 的設計往往就是容易被忽略的一環。

    因此我多準備了一段: 就是 “架構師在敏捷團隊中該扮演的角色”，這是我在演講當下沒時間聊到的段落，我在文章內也把他補上了! 同樣的內容，除了 DevOpsDays Taipei 2022 Keynote (2022/09/16) 之外，我事後也跟保哥進行了一場同主題的線上直播 (2022/10/07)，相關連結我擺在文章最後面。你可以選擇你想要的方式來了解，不過我個人是最推薦看我部落格文章啦 :D

    2022/10/26 系列文章: 微服務架構 系列文章 架構師的修練 microservices

  4. 水電工日誌 #8. 家用網路設備整合, UniFi + NAS 升級之路

    自從 2019/10 因為原本網路設備掛掉, 開始敗入 UniFi 的體系, 果然如同傳聞的一般, 不知不覺就整套換下去, UniFi 的設備就這樣一直繁殖下去了。事隔兩年半, 我家網路主要設備總算都更新完畢, 於是重新補上這篇, 把我對家裡網路的想法交代一下。

    這篇我想寫的，不是只介紹硬體的更新而已。硬體更新沒啥特別要交代的啊，這種東西裝好了大概就無感了 (會有感都是網路出問題)。我想說明的是我怎麼藉由 UniFi 的 SDN 把我想要的網路環境搭建起來。從 2007 我開始在家裡擺機櫃開始，機櫃裡的設備其實都在處理這些事情:

    1. 網路設施 (routing, switch)
    2. 網路服務 (dns, web server, storage, backup)
    3. 監控設備 (dvr)
    4. 電話總機

    回顧一下當年的設備, 果然看得出時代的眼淚, 在過去幾年都被我逐步的換掉了。這一連串設備的整併更新，其實我早就想做了，只是一直都沒有看到滿意的 solution 就沒有很積極的替換，直到我開始購入 UniFi WiFi AP 開始 …

    2022/06/10 系列文章: 水電工日誌 水電工 有的沒有的 敗家 UniFi

  5. [架構師的修練] - 從 DateTime 的 Mock 技巧談 PoC 的應用

    圖片來源: 動畫瘋, SPYxFAMILY #4

    這篇不打算寫那麼長，短篇就好，先聊聊一些比較直覺的實做技巧，同時也當作 PoC 這主題的起點。我想聊聊一件事: 就是在單元測試 / PoC (Proof Of Concept) 的過程中，怎麼處理 DateTime.Now 難以控制預期結果的問題?

    DateTime.Now 會傳回系統目前的時間，不過這很難預測 (你不知道何時程式才會啟動啊)，這也讓依賴 DateTime.Now 開發的程式碼難以精準的測試。要解決的方法也不難，只要用這些關鍵字 (C#, DateTime, Mock) 到 Google 查一下，應該就可以查到一堆。不過，如果只是要在單元測試過程中掌控 DateTime.Now 的行為，其實這樣就夠了。我在思考系統設計過程中，很常用 PoC 的技巧，也常常會面對時間的問題啊… 隨便舉個例子:

    系統在接受客戶的訂單時，會立即傳送確認訊息，同時會排定在每個月 15 日的 02:00, 更新月結報… blah blah …

    如果我要寫這樣的 code, 難道每次測試或是 demo 都得要等一天嗎? 或是我就真的得調整系統時間嗎? 如果這些場合還有面臨 UI 等等元素的介入 (不只是單元測試)，我該怎麼做?

    因為有這些延伸的需求 (反正 DateTime 的處理也不複雜)，我就決定捲起袖子自己弄了…

    2022/05/29 系列文章: 架構師的修練 系列文章 架構師的修練 刻意練習 UnitTest PoC

Facebook Pages

Sponsor Ads