关于微服务架构落地的一些疑问

[sha851092391]

Q1: Gateway 使用 JWT 作为 Token 的解决方案中，每个业务服务中如何做授权校验？

• 一种方式是 JWT 的 Payload 中包含了“角色”或者“权限”等信息，但是 Token 会变大。
• 另一种方式是业务服务通过 JWT 再去请求一次用户服务拿到“角色”或者“权限”等信息，但是网络请求会增加。

Q2: 一般是 Gateway 使用的服务名的路由策略把所有注册的服务的所有接口都暴露出去，就会把类似“通过用户 ID 获取用户信息”这类的基础接口服务都暴露出去，一般这种场景如何去做？

• 现在使用聚合服务，网关只暴露聚合服务出去即可，但是就会出现很多非常薄的一层聚合服务。

Q3：定时任务、MQ 消费者、异步任务等任务去调用其他业务服务时，因为其他业务服务需要 token，像这种场景如何处理？

• 现在我们会生成一个临时的 token 用作该类场景的服务调用。

[xuanbg]

@yule111222
>内部接口加上 @PreAuthorize("#oauth2.hasScope('server')")
>再在 feign 做一个拦截器把客户端模式的 token 带上即可
>另外都用 JWT 了当然把权限信息放到 token 里面

楼主有定时任务要调用的时候，就没有 token 。权限信息放 token 里面会使 token 变得非常大。所以楼主才来提问。

[Evilk]

我们用不上微服务,只上了 SOA

[sha851092391]

临时和永久做法都是一样的，关键是 token 需要对应一个用户（现在对应一个叫做“系统用户”的用户），token 做认证，用户信息做授权，所以这种做法感觉不够优雅。

[sha851092391]

@linvon
A1：我们有考虑过，token 认证完成后南向的服务请求直接传递 uid，但是授权的问题还是存在每个被调用的服务都要去拿一遍用户的角色以及权限等信息。这里网络请求会变成 2n 次。
A2：是的，部署没问题。例如“用户服务”里面有很多接口，其中包括“通过用户 ids 批量获取用户信息”等基础接口供其他服务调用。因为 Gateway 直接路由到“用户服务”，就相当于能访问该服务所有的接口。如果要限制，就需要人工声明管理哪些接口是基础的不给外部调用的。这也是我们目前的做法，维护成本太高。
A3：因为会调用业务服务，所以模拟 token，但是由于 token 是对应用户的，所以这里面需要指定一个“系统用户”去对应 token （默认用户设计）。因为对数据修改需要获取修改人记录日志。

[sha851092391]

@yaming116 哈哈，这不是协议的问题。

[sha851092391]

@paragon
和 @linvon 的 Q1 描述的一样，认证没问题，但是授权的问题还是存在每个被调用的服务都要去拿一遍用户的角色以及权限等信息。这里网络请求会变成 2n 次

[sha851092391]

@Kyle18Tang
A1：是的，JWT 自验证就是为了减少获取用户信息的请求。认证没问题，但是每个服务的 RBAC 的授权就还没什么好的解决方案。
A2：是的，目前类似这么做，但是因为业务服务需要知道当前用户，因此 client credentials 无用户对应所以不太适用。

[sha851092391]

@Evilk 是的，其实 80%的所谓微服务顶多就算服务化，还没到微服务化的水平。更多的不是为了业务而是为了微服务而微服务。

[sha851092391]

@lihongming 嗯嗯，网关其实只是一部分。其实很多问题不仅仅在网关，而是服务之间的治理和编排上。

[xomix]

@sha851092391 这种时候你是搞一个部门审核（ policy 整体服务）还是每个衙役单独审核（单独接口内 policy 审核）是你根据自己业务范围和系统承载自己去规划的事情，你也可用来个尚方宝剑（ token 直接鉴权）见剑如见圣亲临也不是不行，鱼符和符（ hash(查询信息+key)后服务端和客户端的 hash 值比对）也不是不行啊。鉴权这个东西人类社会已经有几千年的历史给你参考，你自己基于自己的实际业务需求选择合适的鉴权方式实现，不要被技术绑死了才好。

[sha851092391]

@xuanbg
A1：对的，现在这种方案统一在 gateway 层做 url 级的授权校验。
A2：非自增也无法保证安全性。因为这种接口其实是拆分后无法 join 表用的基础接口，仅内部调用的。
A3：就是网关所以需要一个用户 token 才能调用，而且这个 token 必须映射到一个用户上去。

[sha851092391]

@twl007 好像是 CNCF 孵化的东西，了解看看。

[sha851092391]

@xomix 整体和单独做认证授权都试过，就是各有各的问题，因为是自己摸索的，所以想了解下有没有更好的实践。token 直接鉴权的方式只适合于 C 端用户权限不负责的情况，但是对于有 RBAC 要求的就不行了。签名部分仅保证传输的安全性，不适合用作用户维度的认证。

[xuanbg]

@sha851092391 #31 这种接口你可以标记为需要授权，这样没权限就调用不了，也就安全了呀。
第三个问题，你的调用不经过网关，自然不需要验证和鉴权。把身份验证和鉴权放在网关的目的是由网关统一实现，这样服务就不需要实现，服务间调用也就不需要 token 了。

[cloudhuang]

Q1. 内部服务是裸奔的，Token 不是用在内部服务之间，而是外部 ---> Gateway 这部分的

[cloudhuang]

Q2. 你都网关了，怎么会存在这个问题
Q3. 见 Q1