接上篇设计一个授权服务 来聊聊 他是怎么被设计出来的
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