設計思想 接上篇設計一個授權服務 來聊聊 他是怎麼被設計出來的 https://www.cnblogs.com/alangur/p/13187053.html#4628838 設計說明 許可權服務作為微服務中其實也可以認為只一個授權中心。在這個授權中心下，他主要提供其他服務的需要的用戶的業務邏輯的驗證 ...
設計思想
接上篇設計一個授權服務 來聊聊 他是怎麼被設計出來的
https://www.cnblogs.com/alangur/p/13187053.html#4628838
設計說明
許可權服務作為微服務中其實也可以認為只一個授權中心。在這個授權中心下，他主要提供其他服務的需要的用戶的業務邏輯的驗證。比如你審核的時候需要驗證當前的這個用戶是否擁有操作這個動作的許可權。再比如賬務的操作也需要判斷當前的用戶是否擁有這些 許可權去完成這些動作。更多的是業務內部的數據操作，故而逐漸形成一個授權中心，負責給各個 系統，各個業務分發許可權。
在網關中，他也是存在一個對外的授權驗證。這個驗證時驗證當前的用戶是否有許可權對接這個對外的介面，但是驗證的數據支持仍然時從許可權這個服務中提供的。
故而我們的授權中心許可權其實就分成了三種：
第一：就是我們的業務許可權。經過許可權服務的驗證
第二：就是我們的對外的介面請求的許可權。
第三：內部介面的許可權驗證
對於第三種許可權是否需要，我覺得是可有可無的。因公司業務而定。為什麼這樣講，我覺得一些公司的服務都是在內網內，相對來說是沒有外在風險 存在的，並且因為少一些業務邏輯的占用，效率上可能 還高效一點。但是還有一些企業可能 他們內部制度的原因，部門太多的原因。導致他們也需要許可權去做這些事情。當然這對於這個授權中心來說，都是可行的。
所以我們的授權中心應該是一個體系，而不是單獨的某一個模塊，它是整個運營體系中重要的一環。
在這個服務設計出來的時候，看到各位網友們在討論ids4的集成。其實ids4的jwt驗證功能也是集成在一起的。為啥沒有採用ids4 RBAC的實現，我不想對於ids4的功能耦合的太多，想自己實現，對於結果都是大同小異。對於實現，可以更靈活 ，可以使用自己擅長的orm，自己擅長的單體架構，當然你如果還是比較熟悉ids4的RBAC，那也沒有什麼問題啦。
寫在最後
如果它對你有幫助，請給一波start
服務 ketchup.zero 源碼地址：https://github.com/simple-gr/ketchup.zero
微服務框架 ketchup 源碼地址：https://github.com/simple-gr/ketchup
ketchup 交流群：592407137
