1. 架構面試題 #2, 連續資料的統計方式

    面試題這系列來到第二篇,這次來點靈活一點的應用題: 連續資料的統計方式。

    這個題目很簡單,例如購物網站,當你的網站每秒都好幾百筆訂單,都是好幾百萬上下時,如果我想看 “過去一小時所有成交金額” 的數字是多少,同時這數字還要每秒更新,你會怎麼設計這功能?

    其實這個問題,就跟一般點擊率統計的問題差不多,只是我多埋了兩個阻礙在裡面,提高這問題的困難度。其一是只統計 time window 範圍內的數值,有訂單進來時把數值往上累加很容易,但是要 “精準” 的把超過一小時的數值剔除就很頭痛,讓很多不善思考的工程師就直接改採暴力法解決 (不斷重新計算這小時的加總)。另一個阻礙是這些資料是源源不絕連續的灌進來的,你沒有任何空檔可以停下來整理資料,你的處理方式必須是能連續運行,也不能不斷累積垃圾資料,或是瞬間占用大量資源。否則長時間執行下來應該會垮掉。

    別小看這個問題,從最簡單的解法 (直接 SQL query) 到複雜的串流分析 (stream analytics) 都有,甚至還有需要自己土炮的做法… 過去往往很多人在爭論,演算法跟資料結構到底種不重要? 往下看下去你就會知道,當團隊碰到這種層次的問題時,你會很慶幸團隊裡有個腦袋靈活 + 懂資料結構的夥伴。如果你是面試官,花點時間看完這篇吧! 這類的問題,能讓你鑑別出優秀的軟體工程師。如果你想找的是能擔任架構師的人選,而非只是單純接需求把功能做出來的碼農,那麼一定要試試這個考題。如果真的找到有這樣能力的人,記得找來好好栽培他 :D

    2018/04/01 系列文章: 架構師觀點 架構師 面試經驗 microservices azure stream analytics

  2. 架構面試題 #1, 線上交易的正確性

    最近一直在思考,團隊裡的後端工程師能力是否到位,是微服務架構能否成功的關鍵之一。我該怎麼鑑別出面試者有沒有這樣的能力? 最有用的就是出幾個實際的應用題,讓面試者在白板上面說明。最近這一輪面試,談了不下幾十位吧,索性就把我幾個常問的白板考題整理起來,歸在微服務系列的文章裡的開發團隊篇,改善團隊成員的問題,也算是朝向微服務化的目標跨出一大步。

    這書應該是惡搞的吧? 竟然還有恰恰 XD

    2018/03/25 系列文章: 架構師觀點 架構師 面試經驗 microservices

  3. 微服務基礎建設 - 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 就是解決這個問題的方法。

    2017/12/31 系列文章: .NET + Windows Container, 微服務架構設計 系列文章: 架構師觀點 microservice 系列文章 架構師 service discovery service mesh

  4. 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 的能力。

    2017/10/04 Docker Windows Container LCOW LABS

  5. 架構師觀點: 你需要什麼樣的 CI / CD ?

    圖片出處: https://blog.infostretch.com/39-tools-for-building-your-cicd-stack/

    這篇沒有要分享太多太硬的東西,或是太燒腦的架構文章,單純分享一下最近我協助團隊導入版控,以及 CI/CD 的想法而已。我一直覺得台灣 (還是世界各地都一樣?) 的軟體開發團隊存在這種 “工具控”、”框架控”、或是 “技術控” 的想法;選用跟得上潮流的技術,比什麼都重要。重要到這些技術或是框架本身到底是想解決什麼問題都不重要了,只要我用了最新的框架就是潮…

    CI/CD, DevOps, SCRUM, Microservices, Containers 等等也是現在熱門的關鍵字,看過我前面文章的朋友大概都知道,我是很反對不知道這些技術是在幹嘛之前就一窩蜂的投入。最近在協助團隊從無到有建立起版控機制與 CI/CD 的過程有感,於是就寫了這一篇…

    不過在開始進入正題之前,先讓我發發牢騷 XDD

    2017/08/05 系列文章: 架構師觀點 架構師 CI CD DevOps 軟體工程 開發流程