oauth2的概念,感覺 阮一峰寫的理解oauth 2.0可以對oauth的概念有較好的了解
對於許可權概念以及怎麼搭建許可權系統,微服務api級許可權的技術架構這篇文章，比較好了解釋了rbac，並簡單介紹了買單俠做的工作。 不過對於具體的技術講的不多
微服務架構下的安全認證與鑑權,這篇文章，講的比較全面了，oauth ，jwt，session 都有提到，不過token或者說jwt伺服器端的驗證還是沒講清楚。燕平方的server端的認證神器——jwt(一)這篇文章終於道出了jwt伺服器端怎麼驗證。不過對於配置的secretkey這個事情。 我的理解是如果是存在資料庫那麼重新生成signature的時候還是要訪問資料庫。 難道是整個認證服務配置乙個這樣的引數（不過這也是可以的，所有的認證就都基於這個金鑰了，可千萬不能被攻破）。
目前作者在處理api許可權(主要是針對服務)時，主要是採用客戶端利用分發的使用者名稱+密碼（不做傳輸）+時間+引數生成 signature，服務端根據傳過來的時間 引數 使用者名稱重新計算出signature。對比之後進行驗證。 也是無狀態的 但是需要訪問資料庫。 且客戶端也需要計算signature 對於前端來說不太友好。 輔助以ip黑白名單，然後前端工程 配置單點登入，再免密訪問其他微服務。 問題在於需要訪問資料庫，和客戶端需要計算。
微服務許可權問題認證方式，簡單學習
oauth2的概念,感覺 阮一峰寫的理解oauth 2.0可以對oauth的概念有較好的了解 對於許可權概念以及怎麼搭建許可權系統,微服務api級許可權的技術架構這篇文章，比較好了解釋了rbac，並簡單介紹了買單俠做的工作。不過對於具體的技術講的不多 微服務架構下的安全認證與鑑權,這篇文章，講的比較...
微服務學習筆記 微服務治理得方式
可能會出現一些問題 一 節點管理 1 註冊中心主動摘除機制 服務提供者定時的主動向註冊中心匯報心跳，註冊中心根據服務提供者節點最近一次匯報心跳的時間與上一次匯報心跳時間做比較，如果超出一定時間，就認為服務提供者出現問題，繼而把節點從服務列表中摘除，並把最近的可用服務節點列表推送給服務消費者。2 服務...
利用灰度方式解決微服務測試環境共用問題
先簡單交代下背景，好引出為什麼要做這個事情，當專案團隊大了之後我們經常會遇到的問題就是git流程的管理，以及遇到使用某套git管理流程之後所帶來的成本和問題，例如 如果你使用gitflow 流程你就會發現你對開發人員對git操作本身就需要很高的水準，不利於不同層次的人員協同，第二你有可能生產版本不穩...