安德魯的部落格

  1. 架構師觀點 - 轉移到微服務架構的經驗分享 (Part 3)

    前面兩篇，分別介紹了微服務架構的規劃方向，還有實際切割的案例探討。這篇 (Part 3) 的重點就要擺在微服務到底該在甚麼樣的基礎建設上面 運行? 維運過去單體式架構的 application, 所需要的基礎建設，會跟微服務架構下可能會有數十個 service instances 同時執行，甚至上百個 service instances 一樣嗎?

    我只能說，考量完全不一樣!! 微服務架構簡化了服務本身的複雜度 (每個服務變小了，責任也變單一)，但是整體的 application 並沒有變簡單啊， 因此複雜度都轉移到服務與服務之間。因此要能妥善管理及維護好眾多的服務 instances 能彼此順利的合作，是個不小的挑戰。這邊最主要的關鍵， 就在於底層的基礎建設了! 這篇就花點篇幅來聊聊這個部分: 微服務架構的基礎建設與部署。

    2017/07/11 系列文章: .NET + Windows Container, 微服務架構設計 系列文章: 架構師觀點 microservice 系列文章 ASP.NET 架構師 infra message queue api gateway service discovery

  2. 容器化的微服務開發 #1, IP查詢架構與開發範例

    總算把包含架構與觀念的實際案例篇寫完了，前面也寫完了微服務化一定會面臨的 API 開發設計問題，那接下來可以開始 進入有趣一點的部分了。微服務架構是由很多獨立的小型服務組合而成的，這次我們直接來看看每一個服務本身應該怎麼開發。

    • 這張圖真是百搭啊…

    這篇既然要講到實作，那就不能不提讓微服務可以實現的容器技術。我一直覺得很可惜的是，不管國內或國外的文章，以開發者的 角度來介紹容器技術的案例實在不多啊 (還是我關鍵字下的不對? @@) 過去的觀念裡面，都是強調 container 有多好用，但是 看來看去都是把現有的 apps 重新用 container 打包及部署。DockerCon 2017 正式介紹了 LinuxKit, Microsoft 也宣布了 Windows Container 要開始支援 Linux container 等等…，我想不用多久就是 container 滿天飛了。到時你還 只是 在考慮 containerize (容器化) 而已嗎? 如果你的服務將來註定要在 container 環境下執行，在開發的當下，你會如何設計你的軟體架構?

    介紹 docker 的文章，很少是以 pure developer 角度在寫得，如果領域換到 windows container + .net developer 就更少了。我從小就是靠 Microsoft Solution 吃飯長大的，C# 我也從當年還是 Visual J# 的年代，一路到 .NET framework 1.0 就 開始用到現在，既然 Windows Container 也都問世了，那這篇文章的示範內容，我就用 Windows Container + .NET Framework + Azure 來做吧!

    Container Driven Development (我自己亂掰的名詞，不過竟然還 google 的到東西 @@) 就是我這篇想寫的概念，從 container 的 角度來思考你的 application 該怎麼設計。其實方針前面這幾篇微服務的文章都講過了。這篇就直接看我如何用這樣的思維來規劃 開發架構吧。我這次挑選的主題，是前陣子我實際上碰到的 case: 用 IP 查詢來源國家的服務。

    這功能很符合微服務的定義: “小巧，專心做好某一件事”，剛好前陣子 Darkthread 也寫了一篇 “用 100 行 C# 打造 IP 所屬國家快速查詢功能“，我就沿用 Darkthread 貢獻的 Source Code, 把它包裝成微服務，用容器化的方式部署到 Azure !

    2017/05/28 系列文章: .NET + Windows Container, 微服務架構設計 系列文章: 架構師觀點 microservice 系列文章 ASP.NET 架構師 Docker Windows Container DevOps

  3. 架構師觀點 - 轉移到微服務架構的經驗分享 (Part 2)

    前情提要: (Part 1)

    補上欠很久的第二篇~

    上一篇聊了進入微服務架構前，架構師本身的心理建設、為何要用微服務的原因，以及導入這些美好的架構背後的代價。 這篇開始拿我過去負責過的實際案例，來聊聊我如何把典型的商用大型軟體 (單體式架構)，逐步調整為微服務架構的過程跟決策。

    先寫在前面，如果你想看的是現在大型的雲端服務，如何用微服務架構落實的 (例如 Netflex 等等)，那這篇可能不是你有興趣的。 這篇講的案例，比較是台灣大部分軟體公司會面臨的狀況，過去發展很久的傳統企業應用程式 (通常是 ASP.NET + MS-SQL)，架構 較講究的會有三層式架構，有的甚至只有兩層 (WEB + DB) 而已。隨著時間的發展，功能不斷的增加，軟體越來越複雜，但是架構上 卻沒有太大的變化。

    這樣發展了幾年下來，大概都已經面臨到維護的成本跟難度已經到達瓶頸的階段了吧! 這時會採用微服務架構的動機，就跟大型雲端 服務採用微服務架構的理由不同了。主要動機都會再改善既有問題為主。這篇講的就是我過去處理過的這類案例。所以也請各位先有 心理準備，這篇的內容並非完全按照典型的微服務的路線發展，我自己為這套系統的狀況做了些調整與取捨，寫這篇單純分享經驗而已~

    看到這邊，準備好了就請繼續往下捲，本文開始~ :D

    2017/05/20 系列文章: .NET + Windows Container, 微服務架構設計 系列文章: 架構師觀點 microservice 系列文章 ASP.NET 架構師 Docker Windows Container DevOps

  4. 架構師觀點 - 轉移到微服務架構的經驗分享 (Part 1)

    寫在前面

    微服務這系列的文章暫停了三個月，不是沒興趣寫了，而是這幾個月都在 “還債” + “充電”，換了另一種形式在產出分享內容，同時 也花了些時間累積微服務的基礎建設研究及評估經驗。我想分享的都是實際的開發及導入經驗，如果沒實際做過是寫不出來的.. 因此才暫停 文章的寫作計畫一陣子。

    這幾個月，工作的方向做了些轉變，不變的是我仍然在 .NET & 微服務架構開發與導入這領域努力。在這陣子，幾個單位 也不約而同的找我分享這些內容，因此就 microservices & windows containers 這領域，有這幾場現場的演講 & 互動:

    1. DevOps Taipei, 這一夜讓我們來聊聊 Microservices
      微服務的架構與觀念，以及導入時要留意的陷阱。導入微服務架構，最重要的是了解微服務能解決你現有的那些問題，最忌諱的就是一窩蜂的 改寫 + 擁抱新技術，這樣會得不償失。這個 session 則是我親身執行過的案例經驗分享。

    2. Study4.TW, Visual Studio Everywhere 台北場
      專注在 .NET 開發人員，為甚麼一定要關注 windows container 這項技術? 容器化的部署方式，已經是大家關注的焦點了。 也被認定是要落實 DevOps 的必要技術之一。不過身為 .NET 開發人員，總覺得 container 技術離 .NET 還很遙遠，因為 目前主流的容器化應用，都還是在 linux 平台上面的 docker. windows container 在去年年底推出，讓 .NET 開發人員也開始 有機會接觸容器化的部署技術了。這個 session 則是針對 .NET 開發人員的 windows container 介紹及 demo 。

    3. TibaMe - Windows Container容器技術, 線上課程
      這是我初次嘗試錄製一系列的線上課程，其中一段也進棚拍攝，算是很特別的體驗。這次的內容我挑了 windows container 入門， 想從容器化的技術基礎開始談起，說明為何容器技術對於微服務架構而言是很重要的推手。這課程內容包含 docker / microservice 的背景 介紹。課程要傳遞的概念與 VS Everywhere 的那場一樣，只是形式是以線上課程 (video) 為主。總時數約 6 hr, 因此在觀念，架構以及 實作 Labs 講得比較仔細，包含 Step by step 的操作影片教學。

    4. TibaMe - 線上小聚主題分享-Windows Container 入門與實作, 線上讀書會 (Free)
      第二次跟線上讀書會的紀相安合作，由 TibaMe 主辦的線上小聚分享活動。主題一樣是圍繞在 windows container，不過線上互動的形式， 重點就比較偏向實際的 labs 操作，與 QA 的進行。因為容器化的技術觀念並不難，一般都很容易了解。倒是 windows container 相對的 使用族群較少，很多操作上會踩到的地雷都需要一一克服，因此線上的互動可以實際 live 操作，所以我把較多的時間擺在這邊，也當作是 線上課程的延伸。希望藉著線上互動的方式，解決自己在看影片或是文章時，無法自己搞清楚的一些細節及觀念問題。

    這四個場子的屬性都不大一樣，每場講的主題都圍繞在 .NET + Microservices + Windows Container, 只不過重點擺的地方都不同。 每場講完都覺得有點缺憾，好像都可以再補足些什麼… 我還是擅長用寫的啊，寫下來的東西總是比用講的精確。因此我打算用這篇文章， 把這四個場次的分享重點都串起來。沒機會參加前面幾場的朋友們，可以看這篇文章；有參加過的朋友也可以看看文章，補上了我沒機會在 現場提到的重點。

    這篇文章我不打算帶到 code 或是太硬的技術，只打算帶到單純的觀點 & 經驗分享。不過別擔心，這陣子累積了一些實作的技巧，這篇 之後就會繼續看到一堆 code 的內容了 XD, 敬請期待!

    2017/04/15 系列文章: .NET + Windows Container, 微服務架構設計 系列文章: 架構師觀點 microservice 系列文章 ASP.NET 架構師 Docker Windows Container DevOps

  5. 不只是 TDD #2, 兩個版本自我驗證 + 執行期驗證

    LeetCode Logo

    接續 上一篇，如果你以為要在本機解 LeetCode 的題目，只是把 test cases 改成 unit test 就結束的話，那 我就不需要寫這幾篇文章了。如果你的目標只擺在 “解題”，那的確看第一篇就夠了。如果這是老闆或是客戶給你的 “需求”，那 你得訂更高的目標去執行才行，包含正確性，執行效率之外，還有可維護性等等考量。

    這篇就會跳出大家常看到的 “狹義” 的 TDD 做法。TDD 絕對不只是寫單元測試而已。你總是會有想像不到的狀況發生，我面對這問題時採取 兩個做法來解決:

    1. 把單元測試，從開發階段延伸到執行階段
    2. 自動化產生新的測試案例，讓機器隨機擴大測試案例的涵蓋範圍

    (2) 可能抽象一點，我的想法是先創造一個 “可敬的對手“，再讓這個對手不斷隨機的產生測試案例來測試自己，同時由這個對手來告訴我做的對不對…

    這情境有沒有很熟悉? 2016 的大事: AlphaGo 打敗世界冠軍，背後一個關鍵成功因素， 就是 AlphaGo 沒日沒夜的跟自己對練，累積的經驗。我們面對的問題不像圍棋這麼複雜 (10170 種組合)，實作起來很容易的， 唯一的障礙是你想不想做而已…。

    2017/01/31 系列文章: 如何學好寫程式 系列文章: .NET + Windows Container, 微服務架構設計 系列文章: 架構師觀點 專欄 技術隨筆 TDD Microservices 架構師

Facebook Pages

Sponsor Ads