-
架構面試題 #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 的能力。
-
架構師觀點: 你需要什麼樣的 CI / CD ?
圖片出處: https://blog.infostretch.com/39-tools-for-building-your-cicd-stack/
這篇沒有要分享太多太硬的東西，或是太燒腦的架構文章，單純分享一下最近我協助團隊導入版控，以及 CI/CD 的想法而已。我一直覺得台灣 (還是世界各地都一樣?) 的軟體開發團隊存在這種 “工具控”、”框架控”、或是 “技術控” 的想法；選用跟得上潮流的技術，比什麼都重要。重要到這些技術或是框架本身到底是想解決什麼問題都不重要了，只要我用了最新的框架就是潮…
CI/CD, DevOps, SCRUM, Microservices, Containers 等等也是現在熱門的關鍵字，看過我前面文章的朋友大概都知道，我是很反對不知道這些技術是在幹嘛之前就一窩蜂的投入。最近在協助團隊從無到有建立起版控機制與 CI/CD 的過程有感，於是就寫了這一篇…
不過在開始進入正題之前，先讓我發發牢騷 XDD
