-
微服務基礎建設: 斷路器 #1, 服務負載的控制
原本 “服務量控制” 這是我要拿來寫 “架構面試題 #3” 的內容的，不過想想拿這個來考白板也太殘忍了吧! 同時這些基礎知識恰好是微服務架構裡面 “斷路器” (circuit breaker) 很重要的基礎，因此這篇就順理成章地接在 “服務發現” (service discovery) 的下一個主題了。
這篇文章我還不打算介紹 “斷路器” 該怎麼使用，取而代之的是使用斷路器的基礎知識: 流量控制。這裡指的流量不光是網路封包而已，而是泛指某個服務在一定時間內能夠處理的服務量。”服務量” 指的可能是訂單件數，可能是出貨量，也可能是發送的訊息數等等。先要能搞清楚如何掌握服務量，你才能預測系統何時會到達極限，何時該啟動斷路器保護整個系統。
-
容器化的微服務開發 #2, IIS or Self Host ?
雖然微服務跟容器化是兩回事，不過兩者的搭配是絕佳組合啊，所以我決定先花點篇幅，先交代如何將 web api 容器化部署的問題 (self-host or IIS host)。部署這件事，過去都是 operation team 解決掉了，不需要 development team 傷腦筋。現在微服務需要更密切的整合，必須要同時能掌握 development 跟 operation 的 know how, 才能正確的拿捏該捨掉那些東西。這篇就是從這角度，告訴你 IIS 與 Self Host 兩種開發與部署的模式該如何取捨。我先說明一下採用 Self-Host 的考量，同時也會示範一下如何開發一個通用的 Self-Host class library, 微服務的應用上，你勢必會有很多大量的服務需要開發，先把這個通用的 Self-Host 架構搞定，接著統一處理其他微服務的各種 infrastructure (如下篇介紹的 consul) 的整合，可以替整個團隊省下不少功夫。
在上一篇 容器化的微服務開發 #1, IP查詢架構與開發範例 我拿 IP 地區查詢服務當作範例，用容器驅動開發的觀念，實作了微服務版本的 IP2C Service。我提到的 “Container Driven Development” 概念，就是假設你將來 “一定” 會用容器化的方式來部署的話，那麼在架構設計之初就能盡可能的對容器最佳化。這邊的最佳化，不是要你 多做 一些什麼，反而是要你多思考哪些是多餘的部分，直接拿掉改用容器 (container or orchestration) 來替代。適度的簡化，可以讓 Operation 的團隊更容易接手維護你的服務，Developer 也能更專注把精力用在核心的業務上。
這次我會重構先前的範例程式，進一步的擴大 “Container Driven Development” 的概念，假設將來 “一定” 會用 container 的方式部署。同樣的來看看，你可以如何建構這樣的 application?
-
Tips: 在 .NET Console Application 中處理 Shutdown 事件
會寫這篇實在有點意料之外，原本我只是想寫 service discovery 使用 consul 的應用案例啊，為了配合我之前推廣的 CDD (Container Driven Development, 容器驅動開發) 的想法，所有的服務開發，只要搭配 container 就都能簡化成 console application 模式就好，結果過程就碰到這個坑…。解決的過程中，也意外挖出不少 google 不到的細節，加上這個問題沒搞定之前，我要寫的內容跟範例實在寫不下去啊.. 於是就多了這篇…
Windows 畢竟是個以 GUI 竄起來的 OS, 有很多東西還是根深蒂固的綁在 windows 上。這次碰到的問題最後還是搬出 windows message, 視窗的運作基礎才解決掉的, 感覺繞了點遠路, 我也擔心跟 windows form 這麼龐大的機制綁住了，會產生很多不必要的相依性? 如果你知道有更好的做法，麻煩留個言指點一下~ :)
-
架構面試題 #2, 連續資料的統計方式
面試題這系列來到第二篇，這次來點靈活一點的應用題: 連續資料的統計方式。
這個題目很簡單，例如購物網站，當你的網站每秒都好幾百筆訂單，都是好幾百萬上下時，如果我想看 “過去一小時所有成交金額” 的數字是多少，同時這數字還要每秒更新，你會怎麼設計這功能?
其實這個問題，就跟一般點擊率統計的問題差不多，只是我多埋了兩個阻礙在裡面，提高這問題的困難度。其一是只統計 time window 範圍內的數值，有訂單進來時把數值往上累加很容易，但是要 “精準” 的把超過一小時的數值剔除就很頭痛，讓很多不善思考的工程師就直接改採暴力法解決 (不斷重新計算這小時的加總)。另一個阻礙是這些資料是源源不絕連續的灌進來的，你沒有任何空檔可以停下來整理資料，你的處理方式必須是能連續運行，也不能不斷累積垃圾資料，或是瞬間占用大量資源。否則長時間執行下來應該會垮掉。
別小看這個問題，從最簡單的解法 (直接 SQL query) 到複雜的串流分析 (stream analytics) 都有，甚至還有需要自己土炮的做法… 過去往往很多人在爭論，演算法跟資料結構到底種不重要? 往下看下去你就會知道，當團隊碰到這種層次的問題時，你會很慶幸團隊裡有個腦袋靈活 + 懂資料結構的夥伴。如果你是面試官，花點時間看完這篇吧! 這類的問題，能讓你鑑別出優秀的軟體工程師。如果你想找的是能擔任架構師的人選，而非只是單純接需求把功能做出來的碼農，那麼一定要試試這個考題。如果真的找到有這樣能力的人，記得找來好好栽培他 :D
-
架構面試題 #1, 線上交易的正確性
最近一直在思考，團隊裡的後端工程師能力是否到位，是微服務架構能否成功的關鍵之一。我該怎麼鑑別出面試者有沒有這樣的能力? 最有用的就是出幾個實際的應用題，讓面試者在白板上面說明。最近這一輪面試，談了不下幾十位吧，索性就把我幾個常問的白板考題整理起來，歸在微服務系列的文章裡的開發團隊篇，改善團隊成員的問題，也算是朝向微服務化的目標跨出一大步。
這書應該是惡搞的吧? 竟然還有恰恰 XD
