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

[sha851092391]

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

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

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

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

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

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

[imherer]

不要为了微服务而微服务，适当的拆分吧。 感觉有时候拆太细反而不好

个人愚见

Q1：我倾向于把角色权限等信息放在 token 里，这样可以减少请求。 但是不知道你的权限信息有多大。你也说了 token 会变大

Q2：微信或者 QQ 第三方登录类似吧？都是先授权那到 acces_token 然后后面用这个 token 去做别的事

Q3：是否可以改成签名验证就好了？ token 的话先要发一次请求拿到 token，然后才能请求。但你实际上只是为了验证请求的合法性？

[xomix]

Token 在系统中的作用是令牌，令牌需要验证后确认令牌权限，不同接口权限不应一致，你可以在令牌中存储一些简单的 claim 信息，但是不应该把 policy 的东西存储在令牌里面。
验证丢下令牌的县令是否具有令牌权限的应当是衙役，而不是在令牌上写着县令权限令牌见令牌就直接执行命令不管扔下令牌的是县令还是胡闹的宋世杰。

[xomix]

令牌可以有简单的 claim 信息就好像令牌可以写甲乙丙不同刑法，但是丢下令牌的整个过程是否符合执行刑罚的权限是要衙役验证的，不是随时丢令牌就可以执行刑法不是吗？

[ZSeptember]

Q1:简单鉴权在 gateway 做了，Gateway 鉴权后向后面的服务直接传递 account_id，roles 等 header，这些是可信的。
Q2:gateway 提供配置功能，服务可配置在 gateway 不暴露某些接口，只允许内部调用
Q3:内部业务服务调用走内部服务调用鉴权，跟用户请求鉴权不一样。内部服务，一般是有比较高的权限，能访问所有用户数据。

[zhazi]

oauth2.0 就可以解决资源鉴权问题。

[sha851092391]

@xomix 这个抽象理解的很好，token 仅做认证，授权应该业务服务做准入实现。但是这也造成在调用链路中每个参与者都需要去获得用户权限并验证的问题。

[sha851092391]

@imherer 谢谢回复，现在已经是 oauth2 授权模式了。还有签名仅用做数据的有效性校验，跟认证授权应该是不一样的。去请求 token 也可以，但是你通过哪个用户信息去请求，因为这里是非用户发起的。

[sha851092391]

@zhazi 认证已经使用了 oauth2 了，但是 rabc 的授权还是做的不够优雅。

[sha851092391]

@ZSeptember

a1：这种方式考虑过，但是由于服务与服务之间调用不走 gateway 的，所以这种从服务内安全性和我 q3 问题还是本地调试都需要手动填写相关授权信息。

a2：是的，需要定制网关，但是就需要成本去维护那些接口不被外部调用，这里面会存在遗漏。

a3：但是被调用的服务其实用户也会用到，定时任务也会用到，所以没法很好的区分两种授权方式

[Leigg]

定时任务是内部调用，还要搞临时 token 不麻烦？给调用者一个不过期 token，只能调用对应接口不就好了。

[linvon]

我感觉你这三个问题都出在一个点上啊，就是 Gateway 与 Service 的隔离
Q1 鉴权在 Gateway 做过就不用再做了，到 Service 的调用都传内部 id 就可以了
Q2 Gateway 和 Service 分开部署，Service 机器在网络拓扑上仅向 Gateway 环境开放，这样 Service 也不需要担心接口暴露，而 Gateway 只暴露业务接口
Q3 内部的离线服务调用服务直接调用 Service 就可以了，不需要再鉴权了，当然如果要模拟业务那可能确实需要一个固定 token

[yaming116]

内部 rpc，外部才走 http

[Kyle18Tang]

1. 用户信息我们放在 token 里, 不用每次都请求数据库
2. 异步或者定时任务通过 OAuth 的客户端模式申请 token 然后调用

[paragon]

用户信息在网关获取了就可以透传下去了~

[twl007]

https://www.openpolicyagent.org/ 可以试试这个

[lihongming]

关于 gateway，直接抄一下各大云的功能吧，已经算最佳实践了。不轻不重的，用起来很舒服。

[xuanbg]

Q1: Gateway 使用 JWT 作为 Token 的解决方案中，每个业务服务中如何做授权校验？
A1：在网关中根据 url 判断用户是否授权。你需要在对角色授权时把操作权限与对应接口的 url 做关联，可能会 1 个操作权限对应多个 url 。

Q2: 一般是 Gateway 使用的服务名的路由策略把所有注册的服务的所有接口都暴露出去，就会把类似“通过用户 ID 获取用户信息”这类的基础接口服务都暴露出去，一般这种场景如何去做？
A2：不要使用自增 ID 就没关系了，接口本来就应该暴露出去。

Q3：定时任务、MQ 消费者、异步任务等任务去调用其他业务服务时，因为其他业务服务需要 token，像这种场景如何处理？
A3：只在网关鉴权，就不存在这个问题。

[xuanbg]

@xuanbg 补充 A1：token 可以不带任何授权信息，在网关根据用户 ID 和 url 进行鉴权，鉴权过程最简单的做法就是查表。进一步优化就是缓存，但缓存的更新是非常复杂的问题。qps 不高的情况下直接查表就行了。

[yule111222]

内部接口加上 @PreAuthorize("#oauth2.hasScope('server')")
再在 feign 做一个拦截器把客户端模式的 token 带上即可

另外都用 JWT 了当然把权限信息放到 token 里面

[dyllen]

@sha851092391 内部调用你还搞个 oauth2 ？用数据签名就行了，数据签名需要一个密钥的，那个密钥不就是鉴权了，保存好。