最近開發的系統是前後端分離+微服務分布式架構，不同於單體應用的許可權身份校驗機制，前後端分離的情況下，無法直接確認前端請求者的身份許可權，需要通過第三方鑑權中心來操作，身份校驗較為簡單，直接過濾網關級別的請求即可，但是許可權校驗就比較複雜了。
資源：
物件：
樞紐：
整體關係如下：物件通過樞紐進行資源的許可權分配
通過對中間表的維護，來收集使用者的許可權資訊，其中部門角色具有繼承的特性
選單許可權通過前端配合實現動態路由，可以實現完全的許可權控制，其中按鈕的許可權主要還是在前端進行邏輯處理，服務端完全無法控制，只能作為資料提供者
api許可權，通過上面的許可權體系可以做到顆粒度為api級別的控制，功能可以實現
不足之處：問題在於，這個關係表人工維護的話，成本較大，因為需要明確規定好該頁面呼叫了哪些介面，前端有變更則需要及時錄入資料，否則會響應無操作許可權，這裡的想法是分三步走，
第一步：首先開發前後端同步開發，前端只維護系統選單資料，後端維護服務介面資料，選單介面關係表暫時不進行維護
第二步：前後端初步開發完畢之後，通過小工具掃瞄前端**， 進行選單介面關係的自動錄入
第三步：通過搭建乙個api接入申請系統，有需求變更的時候，前端申請某個頁面的需求變更，並對新增的和刪除的api進行申報，資料校驗完畢之後，申請系統自動非同步更新選單介面關係表，完成兩者的動態維護
關於微服務架構的思考
最近在專案中遇到了一些問題，乙個比較多的問題服務和服務直接呼叫混亂 a服務呼叫b b服務呼叫c c服務呼叫d 導致後期公升級會出現很多問題 如果有個流程圖也許會好些 但是沒有 因此我陷入了思考，如果進行重構的話那什麼樣的架構會是較好的 我想 設計模式的六大原則 在此也一樣適用 明確的分工,服務之間優...
關於微服務架構的思考
最近在專案中遇到了一些問題，乙個比較多的問題服務和服務直接呼叫混亂 a服務呼叫b b服務呼叫c c服務呼叫d 導致後期公升級會出現很多問題 如果有個流程圖也許會好些 但是沒有 因此我陷入了思考，如果進行重構的話那什麼樣的架構會是較好的 我想 設計模式的六大原則 在此也一樣適用 明確的分工,服務之間優...
微服務架構中整合閘道器 許可權服務
前言 之前的文章有講過微服務的許可權系列和閘道器實現，都是孤立存在，本文將整合後端服務與閘道器 許可權系統。安全許可權部分的實現還講解了基於前置驗證的方式實現，但是由於與業務聯絡比較緊密，沒有具體的示例。業務許可權與業務聯絡非常密切，本次的整合專案將會把這部分的操作許可權校驗實現基於具體的業務服務。...