@feelapi 用这个方案估计大家都不能愉快滴玩游戏了。。。

可靠性越高，系统复杂度就越高，可用性也就越低。游戏嘛，还是回档+补偿就完了，最简单。研发满意、策划满意、运营满意、玩家满意，你还有啥不满意的？

首先，这个不是幂等性问题。有 3 个办法可以解决这个问题：
1 、前端防抖，按钮点击后立即禁用，等接口返回后再视情况启用或跳转页面。
2 、后端限流，同一来源在一定时间间隔内只允许调用一次。这个方案的好处是通用，且可以顺便减轻接口被非法调用的压力。
3 、使用令牌，前端提交数据前先获取一个令牌，后端限制令牌只能使用一次。

电磁炉一定要配那种厚厚的铸铁锅，否则锅底都烧红了，锅沿还是凉的。这种受热极度不均匀的情况下，炒菜你就别想了。

在接口响应特别慢的前提下，是应该先返回一个任务 id，然后用这个 id 轮询另一个接口获取数据。

假的真不了，A 的破绽太多了。。。光日志里面改成 B 的 IP 有毛用，B 完全可以申请证据无效，因为这个数据是可篡改的。云服务运营商那边的服务器或数据库的访问记录才是铁证。

@ksice 不是啥东西，是一种中心化的模式。p2p 是去中心化的模式，当然 p2p 去中心化不彻底，只实现了数据交换不需要经过中心服务器，但还需要有中心服务器来交换信息。微服务同样要有注册中心作为信息交换的媒介，所以我说微服务相当于 p2p 。

这十年，是文化沙漠化的十年。

soa 相当于 P2S2P，微服务相当于 P2P 。

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

首先要定义你的视觉上红色、蓝色的色域范围，然后 rgb 值在哪个范围就是什么颜色。

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

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

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

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

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

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

@learningman 瞧你这话说的，现如今这配环境就是初学者最大的门槛了好吧。。。

别问，问就是让自己累到倒头就睡。