青學習

  當初翻開這本書的目錄，第一個念頭是：「就是他了！」 我是後端工程師，現在正在從 0 到 1 開發一項類似 FB、IG 的社群/社交 App。 想當然爾，這顆 App 就會用到會員註冊/登入服務、貼文服務、通知服務等。 當時我是負責最簡單的會員註冊/登入，串接 Firebase 的 Single sign-on （從第三方用同個帳號登入，例如你可以用 Apple, Google, FB 帳號登入我們的 App）。同事負責設計通知中心的架構，當時連架構都不懂的我，看著同事畫的架構圖，什麼 Queue、Kafka 的，我完全一頭霧水。重點是，主管還特別叮嚀同事說，在設計通知中心時，一定要解釋給我聽，跟我說裡頭的 know how。 呼應我面試這間公司時，主管告訴我的： 「身為後端工程師，如果要精進，未來的職涯規劃要朝架構師去走。」 我想同事設計通知中心的能力， 就是資深後端該具備的能力， 也太強大了。 回到翻開這本書的目錄的那一刻，「Chapter 10 設計通知系統」幾個大字閃閃發亮， 想說有這本書，我也可以嘗試設計通知系統了耶！ 興奮的我立馬翻到那一章節，看完後，公司開會時提到的「外推播、內推播」、「多裝置登入時要儲存 user 的 device ID 」、「通知訊息要先塞到 Queue 裡再從 Workers 拉出來處理」，原本聽不懂的對話，或不知道怎麼實作的部分，全都豁然開朗，也理解同事的架構圖為什麼要那樣設計了。 小小一章，就解了我很多的「為什麼？」 其實剩下的章節，光看目錄名稱，沒辦法勾起我太大的興趣，直到有一天，主管又發問了。 我們的 App 架構是 Micro-services 外面有一層 Gateway，後來有個新需求是 Web 也要可以用，由於 Web 有可能出現流量太高，把後端打爆的情況，為了不讓 Web 的體驗影響到 App，同事在想要不要把 Web 跟 App 拆成兩個 Gateway。 主管就問：「我們 gateway 有 rate limit (或預期有) 的功能嗎？ 或是 rate limit 被規劃做在哪個地方？」 我立馬想起這本書的「Chapter 4 設計網路限速器 rate limiter」，想說這也太讚了吧！翻完後就能理解主管在說什麼了。通常微服務 + Gateway 的架構，會把 rate limiter 做在 Ga