请教一个微服务相关的问题,微服务中的鉴权中心应当整合用户账号服务吗？

应该要吧 鉴权中心连用户都不晓得 那鉴了个寂寞呀
至于说的整合不清楚是代码层面的整合还是远程调用用户服务
我们系统是鉴权服务远程调用用户服务查询用户信息 然后进行鉴权

@freeup 言之有理

鉴权肯定得校验账号密码吧，那肯定得调用户服务的 RPC 吧，拿到 Token 后，后续就可以直接网关校验了

当然如果网关要鉴权可能还是需要拿权限信息

@ouyanglong721 说错了，认证得校验账号密码

鉴权应当和用户信息分离，鉴权应当只关注用户是否有权限操作资源。

我认为大概是这样的结构：前端页面，前端服务器，网关，授权服务器，业务资源服务器也就是 API 服务器。流程大概是这样的：用户点击某些简单功能时，不需要知道用户是谁，也就不用登录；当用户点击某些重要功能是，要知道用户是谁，有没有请求这个功能 API 的权限。用 OAUTH2+JWT 模式的话，这时候就要前端服务器就要携带授权类型 header 和 redirect_uriheader 跳转到授权服务器的登录页面，让用户输入身份信息（一般是用户名密码），授权服务器验证完用户的身份信息，验证失败就返回 401 未认证成功响应，验证成功就返回授权码。前端服务器再拿着授权码并携带自己的身份信息 client_id 和 client_secret ，redirect_uri 向授权服务器请求 Token ，授权服务器验证成功，响应 Token 。||||前端服务器保存 Token 。||||当用户点击业务功能 API 时，前端服务器为这个 request 携带上 Token ，请求到网关，由于网关启动时已经从授权服务器获取了验证 Token 的公钥，这时候就验证这个 Token 可用性和未被修改就行了，验证成功后，网关放行跳转到指定的业务资源 API ，资源服务器给出业务响应。这样整个流程就结束了。

@qqlyatt 有没有比较好用的网关推荐 最好是 k8s friendly 的

@ifane 不拿到用户信息怎么判断用户是否有权限操作资源呢

没有啥应该不应该，都是看整合了成本和收益如何、拆分了成本和收益如何。

我个人的习惯是，不到有充分理由的情况下不拆成单独服务，但要具备能随时拆的设计。

我做的项目用户信息管理是个底层公共服务，很多表层服务都会依赖这个服务的 API ，所以拆了出来，使得运维上更容易做性能优化，以及更方便做一些信息安全方面的合规设计。

@freeup 谢谢您的解答。嗯，我跟您的想法差不多，认同远程调用，问题没描述清楚

@ouyanglong721 谢谢您的解答。嗯，我也觉得调用户服务是合理的。

@libook 先谢谢您的解答。对，一切得根据实际情况来看拆不拆，我还是喜欢拆一点

@qqlyatt 先谢谢您的解答。这样做也行，在.NET 生态里，配合 IdentityServer4 或者 Identity 很舒服。但是我感觉，可能还是得单独拆出来可能会更加好一点。等有时间我都去实践实践

我分了 6 个服务：资源、用户、租户、组织机构、角色、身份认证

鉴权是在网关做的，加上这个 7 个服务了

@xuanbg 先谢谢您的解答。角色也要跟用户服务拆分开吗？