-
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
-
微服務基礎建設 - Service Discovery
要動筆寫這個主題 (service discovery) 之前，我想了很久該怎麼講這個主題… 如果講他怎麼做，那是很乏味的 process 而已。介紹產品或 step by step 的操作，那又不是我的 style. 想了半天，還是從架構的角度，切入 service discovery 想要解決什麼問題，搭配幾種常見的處理模式，再介紹一下有哪些成熟的服務是用這種模式設計的，正好一次把這幾個目的解決掉…
Microservices 先天就是個分散式系統，在開發領域上的門檻，主要就是各種呼叫遠端服務 RPC - remote procedure call 的相關技術了。然而在架構上最重要的一環，就屬 “服務發現” service discovery 這技術了。說他是微服務架構的靈魂也當之無愧，試想一下就不難理解: 當一個應用系統被拆分成多個服務，且被大量部署時，還有什麼比 “找到” 我想要呼叫的服務在哪裡，以及是否能正常提供服務還重要? 同樣的有新服務被啟動時，如何讓其他服務知道我在哪? 人家說微服務考驗的就是你治理大量服務的能力，包含多種服務, 也包含多個 instances。要做到這件事，service discovery 就是你要挑戰的第一關。
說到治理大量服務的能力，Nginx 官網有篇 文章 講得不錯，我就借他的圖用一用。裡面提到 Modern Apps 演進過程，從 1980 的 client / server, 到 2000+ 的 3-tiers, 到現在的 microservices …
從這張圖可以理解到, 走向微服務架構，有沒有能力管理好這麼多數量的 instance, 是你的 apps 能否成功的上線運作的關鍵因素之一。如果以 container 來看，服務的數量從小規模 (100+) 到中大規模 (1000+)，到你在書上看到的各種微服務大型成功案例 (10000+) 就知道，這種數量不大可能靠 IT 人員逐一設置固定 IP + PORT, 然後由 developer 逐一設置 configuration file, 這時善用 service discovery 就是解決這個問題的方法。
-
LCOW Labs: Linux Container On Windows
繼上次颱風天介紹的 Mixed-OS Docker Swarm 之後，適逢中秋節，那就再來一篇吧!
Microsoft 的 LCOW (Linux Container On Windows, 以下簡稱 LCOW) 推出後，Windows + Linux 的整合程度就更進一步了。Microsoft 願意這樣破釜沉舟的整合 Linux + Windows, 看來是下了很大的決心啊! 又進一步的讓 Windows 跟 Linux 的界線越來越模糊了。這是是在 Windows Container 的架構下，用原本就支援的 Hyper-V Container (簡單的說，為特定的 Container 準備一個獨立的 VM + 一套精簡的 OS，只為了執行 Container 使用的 OS 環境，來運行 Container), 進一步把裡面的 OS 從 NanoServer 換成 Linux Kit (或是 Ubuntu 也行), 讓 Windows Container 得到原生執行 Linux Container 的能力。
