-
[架構師的修練] #2, SLO - 如何確保服務水準?
繼上一篇文章: 刻意練習 - 打好基礎 講完整個我對技術人員職涯要持續成長，就必須要刻意的持續練習看法後，這篇我就來舉實際的案例吧。這篇案例是示範，當你學習了技術與管理的知識之後，如何融會貫通，運用在解決問題上的案例。你累積的經驗或是能力，若無法轉換為價值，那是沒有用的。技術人能展現的價值，就是解決問題。怎樣才能讓一個問題拿到你面前你都能迎刃而解? 最有用的就是連結你累積的各種能力。連結越強，織起來的知識網就越強韌，你看問題就會越到位。
這篇我就拿我在去年 91APP TechDay 以及 .NET Conf 2020 分享的主題: 維持非同步系統的 SLO 來當例子吧。這是近年來我擔任架構師，端出來的幾個 solution 之中，對於 “連結” 這件事最有代表性的案例了。這是個包含開發技術，架構設計，服務水準與流程管理等等層面的綜合需求。要解決這問題，你不但要有很札實的技術及實作能力、也要有很到位的 cloud infrastructure 掌控能力，同時還要具備管理知識，缺一不可，才有可能把這件事情解的漂亮。表面上看來，訂定服務水準要達成的目標 (SLO, Service Level Objective) 並落實，是個很純粹的技術題目啊，但是真正做過的人就知道，光是開規格就不知道該怎麼開了，團隊做出來你也很難驗證 (直到上線後碰到流量撐不住之後… )。
-
[架構師的修練] #1, 刻意練習 - 打好基礎
我在下半年的幾場公開演講，開始做了一點不同的嘗試。除了技術或是架構知識之外，我開始會強調為什麼會這樣思考的過程，也開始會帶到該怎麼培養這樣的經驗與能力的想法。在 2020 下半年，有幾場演講都往這個方向調整了。2020 下半年是個爆忙的半年，到現在終於有點力氣把這些內容整理一下了，於是就開了這系列文章 - 刻意練習。這篇是第一篇，主要就是對應到 2020/08 我在 Study4.Dev 八月份活動上分享的主題 - 後端工程師的修練之路。
-
[架構師觀點] 資安沒有捷徑，請從根本做起!
最近一連串資安事件，加上這兩天看到圈子內很熱門的討論串 (大意: 服務開發商，到底該不該儲存能還原的使用者密碼)，於是就想來寫點短篇一點的，說明一下我對軟體開發相關資安 issue 的看法。
那個討論串，我就不提供連結了。我的目的不是要把那位仁兄抓出來鞭，我只是要來聊聊這事件背後的看法而已。如果有人在底下留言附上 link, 我看到會刪掉的，先在此告知
其實我要談的，不是密碼該怎麼加密儲存 (encrypt)，或是只儲存加鹽後的雜湊 (salt + hash) 這些技術問題，我想探討的是技術決策或架構設計者的原則跟態度問題。在軟體開發團隊內 (尤其是技術決策者)，應該都要有正確的認知，不只是密碼儲存，而是泛指所有資安相關議題。如果你只把資安問題當作一種 “需求規格” 來看待，而非品質要求或是法規要求的話，一旦出事時真的會讓公司陷入困境的。
-
架構面試題 #4 - 抽象化設計；折扣規則的設計機制 (06/25 補完)
最近看到好幾篇有內容的討論串，都提到 “抽象化思考” 是個很關鍵的能力。我就在想 “什麼才是正確的抽象化思考” 案例? 看了很多講理論的文章，也看了很多定義, 我相信很多人還是一樣有看沒有懂，或是你真的理解抽象化的概念了，但是真正應用在工作上，你也不一定用的到位啊! 於是就有了寫這篇文章的念頭。我一樣不喜歡只講 “理論”，理論說的容易，要落實才是最難的那一步，因此我決定拿個實際上工作相關的案例來說明 “抽象化” 概念。
我就拿我在 面試架構師常問的問題 之一: “折扣機制的設計方式” 當作這篇文章的主題吧! 只要做過銷售網站，或是相關的系統，我相信一定都被這個主題弄得牙癢癢的，你想的再週全，你的客戶就是有辦法想出你意料不到的折扣規則來折磨你…。不過，這是個很好的例子啊，正好拿來驗證你的抽象化思考夠不夠到位。該說是職業病嗎? 從開始學寫 code 後，我就習慣在日常生活中，碰到大小事情，我都會在腦袋裡想一下 “這東西我該怎麼寫 code 來處理?” …，就是這個折扣計算的問題，每次我在收銀機等結帳時就在想:
這個第二件六折的折扣我該怎麼去計算?
這個第二件加一元我該怎麼設定才合理?
這個即期品半價優惠的機制我該怎麼設計，POS 機才能搞的定?
這麼多種折扣混在一起，結帳時怎麼用一致的規則來處理才不會算錯?
這些問題我就這樣，在我腦袋裡面轉過好幾次了 XDD (所以一時之間想不出來的朋友們不用難過)。我就用這篇文章的篇幅來說明一下該如何將這問題抽象化，然後一步一步解決現在跟未來的問題。
-
微服務基礎建設: Process Pool 的設計與應用
好久沒寫微服務系列的文章了，這篇算是 Message Queue 的進階版本，如果你有越來越多的任務需要 Message Queue 後端的 Worker 來處理，後端 Worker 的架構其實是個很有意思的架構思考練習題。會想解決這個議題: Task Management, 需求有點類似 serverless, 我希望有個 pool 能很快的消化掉我丟進去的 task …。其實我需要的架構就類似 message queue + serverless 就能符合了，但是有些因素, 我得認真評估自行建置最關鍵的那一塊該怎麼做。不過這篇我沒打算把主題擴的那麼大，我就專注在 Process Pool 上面了。
本來打算先講我打算如何解決問題，再來講實作的，不過架構題的決策，往往就是需求、架構跟實作的平衡啊，不先交代一下基本的實作技術，有點講不下去 XDD，我決定先花點篇幅說明程式碼隔離機制 (Isolation) 的架構選擇，再來講應用考量，最後說明 Process Pool 的實作。我分三個段落來說明最終 Process Pool 這個構想是怎麼誕生的:
-
挑戰: Isolation 的機制研究:
了解與比較各種執行環境隔離的技術 (InProcess / AppDomain / Process), 以及如何橫跨隔離環境進行有效率的通訊 (IPC) -
為何需要建立隔離環境:
交代我工作場合面臨的需求與挑戰，Container + Orchestration / Serverless 無法滿足的需求 -
挑戰: Process Pool 的設計與開發
在技術與平台的選擇與平衡, 如何設計與開發 Process Pool
在這過程中，其時用了很多我過去文章個別提過的好幾種技巧，算是個終極的綜合應用篇吧! 最遠可以追溯到 10 年前那系列 Thread Pool 設計與實作的相關文章。只是這篇的應用，把 “Thread” Pool 的觀念，擴大到 “Process” Pool 了。現在的技術，Process 層級的隔離期時有更多的工具可以運用了，例如 Container 就是一例；所以過程中我也花了不少時間在拿捏，站在巨人的肩膀上 vs 重新發明輪子 的取捨；對這部分有興趣的讀者們，可以直接跳到第二段。
-
