.NET / C# / OOP

微服務架構 #4, 如何強化微服務的安全性? API Token / JWT 的應用

| |

洛基的權杖 - Token

其實本來就有打算寫這篇了,聊聊微服務架構下的安全機制該怎麼做? 微服務把整套系統切割成很多套獨立的服務,這些 獨立的服務就必須有機制去識別其他的服務是否是安全的? 有沒有很簡單的方法解決他? 這類越是基礎的問題,越需要 使用正確的架構及演算法。沒有理論的基礎,只會越搞越糟而已,這也是架構師最重要的職責。微服務是個很要求 架構正確的應用模式,想要導入微服務,千萬別忽略這部分。

很巧的是,兩個禮拜前受邀在線上讀書會分享這個主題, 我就把我過去土炮 API Token 的經驗拿來分享了,藉由簡單的 POC 過程,讓大家 了解 API Token 的原理跟應用。這套機制尤其適用在 microservices 架構下,因為這套機制靠著密碼學的原理,讓兩個 service 之間不需要直接溝通,就能完成驗證的過程。

這兩年 JWT (Json Web Token) 當紅,但是跟幾個人聊了聊,大都是停在 library 用的很熟練 的階段,但是問到如何應用? 有無變通的應用方式就剩一半了,再問下去問知不知道 JWT 背後怎麼運作的? 若要實作有無 辦法自己做一套? 就沒有了 XD

在開始之前,先聊一下我為何會想挑這個主題。從事軟體開發的行業,我一直覺的我這年代是很幸運的。比我還年長的, 大都經歷過寫組合語言,甚至是用卡片的年代。比我年輕的,才剛入行就要面對各種技術及 framework。比我年長的那一代, 過程大都在跟工具及技術奮鬥,能把心思花在解決 user 問題本身的比例不高。比我年輕的這一代,面臨太多 framework, 每個 framework 都是累積多少經驗跟智慧才堆積起來的結晶,能夠充分掌握怎麼 “使用” 就很了不起了,哪有時間等你 慢慢鑽研背後的原理?

所以很幸運的,我經歷過軟體還不是這麼複雜難搞的年代,也經歷過 Java, C#, JavaScript 這些可以 讓我專心思考架構之美的程式語言。我碰過很多問題,當年都還沒有妥善的 framework 可以直接套用,因此多了自己 土炮過一些基礎架構的 framework, 包含 ORM (在 SQL2000 年代,實作 object > xml > database,外加 xml index), Content Server (自己處理 URL, mapping URL to file system), MVC 架構 (對,用 asp.net webform + url rewrite, 實作 MVC 架構) 等等,當然也包括這次的主題: API Token。

API & SDK Design #4, API 上線前的準備 - Swagger + Azure API Apps

| |

寫到這邊,寫了那麼多 code, 你的 API 總該要上線了吧! 這篇就來探討一下,除了寫好 Code 之外,API 上線還要 注意什麼? API 這種東西不比一般的系統,API 的開發者是 developer, 使用者也是 developer,溝通可以用更有效率 (更宅? XD) 的方法,而不是只能靠傳統的文件~

這篇主題就擺在 API 開發完成後,要上線的考量。包括如何顧好 DX? 如何讓使用你 API 的 developer 有最好的 usability? 另外一個議題,就是如何挑選適合 hosting API service 的服務? 雲端時代就別再自己架設 server 了, 挑選個好的環境可以事倍功半,輕鬆容易就顧好 reliability.

這篇講的東西比較瑣碎,我分三個部分進行:
第一部分: 以需求為主,把我考量的思考過程花點篇幅寫出來。
第二部分: 介紹 swagger 這套 API Framework 以及 tool chain, 靠他來跟其他 developer 聰明的溝通。
第三部分: Hosting 環境的選擇,我會介紹 Azure 上的 API Apps,選用他可以替我們解決那些問題。

API & SDK Design #3, API 的向前相容機制

| |

上一篇意外的受歡迎,那麼續集就不富樫了,sample code 準備好就開始動工…

You shall not pass

這篇要講向前相容,不知為何我就直覺的聯想到甘道夫對抗炎魔的場景了 XDD,如果你的 API 沒做好這件事,那麼使用你服務的 APP 結果就會…

“You shall NOT pass!”

講完 API / SDK 之間當下的約定,接下來來講講 API 跟 SDK 之間的承諾吧! 當下的約定,會保證當下的 API 跟 SDK 可以搭配運作,然而承諾,則是保證當下的 API 能夠跟過去某個時間以後的所有版本 SDK 都能夠 搭配,這個很考驗架構師的功力了。一個不小心,過去某個不知名的版本就給你出問題了。負責開發維護 API 的人,該怎麼確保這種問題不會 發生?

暌違多年的獎盃 - Microsoft MVP Award Get!

| |

MVP Banner

其實拿到這獎項時,我比其他人還意外 XD, 每個人都只跟我說..

什麼!? 我以為你早就是 MVP 了…

哈哈,不論如何,直到 2016/10,我總算拿到這頭銜了 :D

API & SDK Design #2, 設計專屬的 SDK

| |

上一篇出來後,才發現,原來不是每個人都清楚 API 跟 SDK 的差別… 接下去之前我就花點篇幅來說明一下。 這個分不清楚的話實在有點囧啊,以前在本機上,這可能幾乎是一樣的東西,但是到了分散式的環境就不是那麼一回事..。

我這系列打算從 上一篇 介紹 client side 如何用 C# 呼叫 Http API 的技巧,延續到如何開發搭配的 SDK 設計, 以及 web api 在正式上線時必須考量的安全、效能、確保介面的相容性,可靠性等等設計。不過當你的 API 要正式 發布給其他人使用時,要面臨的就遠遠不止設計跟開發層面而已,還會有線上維運等問題,這邊我也會介紹一下 Azure 上的 API App Service, 還有 API Management

範例程式: 請從 GitHub 下載,本篇的內容對應到 dev-SDK 分支


(sorry, 這圖找不到原圖出處, 知道的請通知我,我再補上~)

API & SDK Design #1, 資料分頁的處理方式

| |


(圖片來源: http://hamidarebai.blogspot.tw/2016/09/building-restful-api-with-aspnet-core.html)

這篇算是 “微服務架構” 系列文章的外傳… 所以標題稍微改一下 XD!

上一篇講到 “重構“,不斷的進行重構,直到能夠將模組切割為服務為止。 這篇就接續這個話題,展示一下服務化之後的 API / SDK / APP 之間的關係,以及設計上要顧慮到的細節。我用最常碰到的資料查詢 API 的分頁機制 當作案例來說明這些觀念。資料分頁是個很煩人的東西,不論是在 UI 或是在 API 層面上都是。尤其是 client 端要把 分頁後的資料重新組合起來,就會有越來越多的 義大利麵風格 的 dirty code 被加進來..

這時 SDK 扮演很重要的角色,善用 C# 的 yield return 就能很漂亮的解決這問題。這篇就來示範幾個 API / SDK 的實作技巧 (C#),之後微服務講到這部份時,可以再回頭參考這篇的內容。

微服務架構 #2, 按照架構,重構系統

| |

上一篇說明了微服務架構的好處,這篇來談談該如何做。其實說穿了很簡單,不就把大型的單體式 應用程式,拆成幾個獨立的服務不就行了? 這樣講沒錯,不過關鍵就在於你這刀應該怎麼切,該往哪邊切? 切出來的服務能不能再繼續切? 有沒有哪些服務是切過頭的,需要重新合併成一個大的?

其實軟體開發的觀念,說穿了都很類似。微服務其實就是更進一步的模組化。一般的模組化只是 code 層級的隔離, 而微服務化則是更強的網路層級隔離。很多軟體設計的概念都是互通的,今天要探討的就是 “重構”。當你的程式碼 架構良好的時候,不僅 code 維護容易,要切割出獨立的服務也會相對輕鬆。因此,不論你打算做甚麼架構調整, 我通常會做的第一步就是 “程式碼重構” !!

這篇我先跳過評估及決定服務邊界的問題,先從最基本的程式碼體質改善做起。體質良好你想怎麼改都很 容易。這篇就先藉由重構,說明把一些顯而易見的服務切割出來的過程。

Running Jekyll on NAS - 高效率的新選擇

| |

自從發現了 GitHub Pages 這好用的服務,原來是源自 Jekyll 這 open source project 後,想說靜態網站產生器這麼好的東西, 怎麼沒人拿來用在 NAS 上? 與其在 NAS 貧弱的硬體上面,安裝 wordpress, 還不如在上面放靜態的 HTML 來的快速且安全。不過順手 Google 了一下,還真的沒什麼人這樣用,於是一時手癢,就…

Blogging as code !!

| |

TL;DR

想想我開始寫 blog 的這十幾年 (Orz, 這麼久了),用的部落格系統也換了不少套了, 從最早我自己土炮寫的 asp.net 1.1 blog 開始算, 中間光是系統就換了 5 套, 還不包括 同一套系統的版本升級… 這些 post 都還能留下來也真算是奇蹟了.. 不過再怎麼換, 終究是有套 “系統” 需要去維護,不管是自己管還是代管都一樣,開始想走純樸路線,省點 運算資源,好好照顧一下北極熊…

於是就決定改採最低科技的路線,丟掉所有的 “系統”,直接採用最單純的靜態檔案。至於 Hosting 的方式,就用最宅的 GitHub 附屬的服務: GitHub Pages… 現在流行什麼都冠上 xxxx as code, 那就來個 blogging as code 吧 XD

微服務架構 #1, WHY Microservices?

| |

八月底,接受了 Microsoft 的邀請,參加了 Community Open Camp 研討會,講了這場 “微服務架構 導入經驗分享 - .NET + Windows Container”。 其實這個主題涵蓋範圍還蠻大的,不過我一直認為,container 技術單獨介紹的話,那他就是個技術而已,若從他存在的目的來介紹,那他就是能解決 問題的好東西。因此我特地訂了這個主題: container + microservices.