#游戏圈资讯#
小学生恶意差评潮来了。
本周是《王者荣耀》实行新规的第一周，这几天晚8点之后都会涌入大批的未成年玩家，在昨日晚间还因为高峰流量问题挤爆了服务器，导致大量玩家掉线，排位、巅峰赛进入异常等问题。
虽然《王者荣耀》官方后来快速响应，并完成了修复，同时给出相应补偿措施，但根据网友反馈多数应用市场中的《王者荣耀》评分都直线下滑。从评论区中可以看到大量恶意一星差评存在。
目前依然在持续下降中，但《王者荣耀》官方还未做出回应。从另一方面来说也表明了《王者荣耀》在未成年群体中的普及程度挺高的。就是不知道其他游戏是否也会出现这种情况。
看图了解 OAuth2 授权码流程
1. 用户与客户端交互；
2. 客户端重定向浏览器，向授权服务器申请授权；
3. 用户登录验证，向用户申请授权许可；
4. 用户提交授权许可；
5. 重定向到客户端，并附带授权码（Authorization Code）；
6. 客户端应用交换授权码为令牌（Token）；
7. 向资源服务器请求资源；
8. 资源服务器返回响应；
9. 将响应结果返回给用户；
授权服务器的主要任务是代表用户签发访问令牌。
客户端向授权服务器申请的访问令牌中会申明授权范围（Scope），该令牌允许客户端以授权用户的身份与API进行交互。
在任何时候，令牌都可以过期或撤销，而不需要用户修改密码。
客户端有了访问令牌之后，就可以在每个请求的Authorization 头信息中传递这个令牌，从而与资源服务器API 交互。
资源服务器实际上就是 API 前面的一个过滤器，它确保对需要授权的资源的请求中包含了一个有效的访问令牌和所需的scope。
资源服务器会通过授权服务器获取到公钥，并验证请求中的令牌是否有效。
大规模采用微服务时，需要考虑的问题。
微服务是目前比较流行的架构方法，不少传统企业也纷纷采用微服务架构来开发新的项目。但是，微服务架构中是存在很多陷阱的，并不是简单地拿来使用就可以。 例如，采用微服务架构后，服务之间的调用链路会比以前延长了很多，在调用链路上发生故障的概率也就随之增大，同时调用 链路越长，性能越会受影响。
所以企业要大规模使用微服务，不仅仅是从思想和业务上面进行合理划分，还需要诸多技术组件， 以及高效的运维来协同合作，这些考虑点，如图 1-11 所示。
防止雪崩
在微服务系统中，整个系统是以一系列固有功能的微服务组成，如果某一个服务，因为流量异常或者其他原因，导致响应异常，那么同样的也会影响到调用该服务的其他服务，从而引起了一系列连锁反应，最终导致整个系统崩溃。
如图2所示，服务A、B、C串行调用，如果在某一时刻，ServerC出现异常，且暂时没有恢复，那么逐渐的，ServerB和ServerA也会出现异常，从而使得整个调用链异常，不能正常提供服务。
当一个服务无法承受大请求压力的时候，是否会影响所依赖的其他服务?这时候可以考虑限流等措施。
服务限流
限制客户端的调用来达到限流的做法是很常见的，比如，我们限制每秒最大处理200个请求，超过个数量直接拒绝请求。常见的算法如令牌桶算法，如图3所示。
以一定的速度在桶里放令牌，当客户端请求服务的时候，要先从桶里得到令牌，才能被处理，如果桶里的令牌用完了，则拒绝访问。
功能降级 当某个服务出现故障时，是否有容错手段能够让业务继续运行下去，而不影响整体应用。
什么是服务降级呢？ 这里有两种场景: - 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度！ - 当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑，避免卡顿，迅速返回给用户！
幂等
分布式系统中的幂等性概念：用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。
当用户多次下同一订单时，得到的结果永远是同一个。
缓存
当请求量较大时，为避免对数据库造成较大压力，可以适当将一些变化较小、读取量 较大的数据放入缓存。
超时
超时时间对于调用服务来说非常重要，超时时间设置太长可能会把整体系统拖慢，而 设置短了又会造成调用服务未完成而返回，我们在实际工作中需要根据业务场景进行 分析，选择一个恰当的超时设定值。
熔断 当请求下游的服务时发生一定数量的失败后，熔断器(断路器)打开，接下来的请求快速返回失败。过一段时间后再来查看下游服务是否已恢复正常，重置熔断器。
如图4所示。
在客户端控制对依赖的访问，如果调用的依赖不可用时，则不再调用，直接返回错误，或者降级处理。状态：
- 关闭状态，允许调用依赖
- 打开状态，不允许调用依赖，直接返回错误，或者调用fallback
- 半开状态，根据熔断尝试恢复时间来开启，允许调用依赖，如果调用成功则关闭失败则继续打开
服务隔离
当所调用的服务发生故障时，上游服务能够隔离故障以确保业务能够继续运行下去
可伸缩
当并发量较大，原有服务集群无法满足现有业务场景时，可以采用扩容策略;当并发 量较小时，服务集群可以采用缩容策略，以节省资源。
#数据库拆分# 通过为每个独立部署的服务提供单独的数据库，降低了数据库耦合，也让不同微服务
间隔离得更彻底，系统更健壮，同时也利于针对不同数据分别进行扩容和其他处理。
可扩展
系统经过良好的设计，可以随时灵活地以比较小的改动代价增加新的功能或能力。
#微服务架构##微服务雪崩##雪崩##服务熔断#
