-
掃雷回憶錄 - Windows Container Network & Docker Compose
最近外務比較多，文章耽擱了一陣子… 在繼續寫 microservices 系列文章前，我先補一篇最近跟 windows container network 奮鬥的紀錄吧，踩過的地雷跟掃雷的經驗，就分享給有同樣困擾的朋友們…
對，我的感受就像 Frodo 在山洞碰到蜘蛛一樣… 被 network 困住了… T_T
-
網路搶票小幫手 - 遠端網站時鐘, WebServerClock v1.0
圖片來源: http://blog.mixflavor.com/2013/12/ticket.html很多線上訂票，或是限時搶購等等的應用，都會碰到一個困擾:
我的電腦時鐘跟網站的時鐘有誤差，我怎樣才能在網站的 00:00 整按下訂購的按鈕??
如果你有這種困擾，哈哈哈，那你看這篇就對了 :D
如果你以為這是自動搶票的機器人，那你可以關掉瀏覽器了 XD 這篇文章不會教你任何後門，用非正當手段搶到票，只是個輔助工具，讓你能更精確掌握 server 的時鐘，可以 更準確的在那關鍵的一秒按下訂購的按鈕而已..
-
微服務架構 #4, 如何強化微服務的安全性? API Token / JWT 的應用
其實本來就有打算寫這篇了，聊聊微服務架構下的安全機制該怎麼做? 微服務把整套系統切割成很多套獨立的服務，這些 獨立的服務就必須有機制去識別其他的服務是否是安全的? 有沒有很簡單的方法解決他? 這類越是基礎的問題，越需要 使用正確的架構及演算法。沒有理論的基礎，只會越搞越糟而已，這也是架構師最重要的職責。微服務是個很要求 架構正確的應用模式，想要導入微服務，千萬別忽略這部分。
很巧的是，兩個禮拜前受邀在線上讀書會分享這個主題， 我就把我過去土炮 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 準備好就開始動工…
這篇要講向前相容，不知為何我就直覺的聯想到甘道夫對抗炎魔的場景了 XDD，如果你的 API 沒做好這件事，那麼使用你服務的 APP 結果就會…
“You shall NOT pass!”
講完 API / SDK 之間當下的約定，接下來來講講 API 跟 SDK 之間的承諾吧! 當下的約定，會保證當下的 API 跟 SDK 可以搭配運作，然而承諾，則是保證當下的 API 能夠跟過去某個時間以後的所有版本 SDK 都能夠 搭配，這個很考驗架構師的功力了。一個不小心，過去某個不知名的版本就給你出問題了。負責開發維護 API 的人，該怎麼確保這種問題不會 發生?
