权限认证不能放在Gateway中？
最近在网上冲浪时看见评论区有程序员抱怨自己被在某乎讨论权限设计时被冲，而对方的观点是微服务的权限要放在Gateway中
，他大为震惊。下面评论纷纷附和并把矛头直指某马程序员的教法。刚好本人最近也在练习某头条的微服务项目，看到这里不禁背后一凉。
确实如此，在某头条中就采用了Gateway做权限处理的方式，所有请求都要事先经过Filter，通过对请求头中的token进行解析来判断是否放行。
这种方法真的错了吗？
上网搜索 “微服务的权限认证” ，众多文章无一不例外的告诉我们微服务的权限要放在Gateway中，好像并不只是某马这样做。
而我自己也没有参与过企业项目的开发，无法根据自身经验评判是非。正当我陷入茫然之时，又看到了接下来的回复 ：
至此场景已经比较清晰了，对方想要通过微服务的方式将权限管理，服务管理这些业务做成一个通用的、在新的场景下也不用进行二次开发的服务。
听起来怪怪的，原来是打上了一劳永逸的算盘。那么先抛开权限认证，来钻研一下微服务的目的是什么吧
微服务的目的是什么，什么是弹性？
通过询问ai可以得到以下答案：
微服务架构是一种软件开发技术，它将一个大型应用程序分解为一组小型、独立的服务。这些服务可以独立开发、部署和扩展，从而实现更高的灵活性和可维护性。在Java开发中，使用微服务的目的主要有以下几点：
可伸缩性：微服务允许你根据需要对每个服务进行扩展，而不是整个应用程序。这意味着你可以为关键服务分配更多资源，而不需要为整个应用程序分配资源。
独立性：微服务可以独立开发、部署和扩展，这意味着你可以在不影响其他服务的情况下对单个服务进行更改。这有助于提高开发速度和降低风险。
技术多样性：微服务允许你在不同的服务中使用不同的技术栈。这意味着你可以为每个服务选择最合适的技术，从而提高整体性能和效率。
故障隔离：在微服务架构中，如果一个服务出现故障，它不会影响到其他服务。这有助于提高系统的稳定性和可靠性。
团队自治：微服务允许团队独立负责特定的服务，从而提高开发速度和质量。
微服务的弹性体现在以下几个方面：
容错性：由于微服务之间是独立的，因此一个服务的故障不会影响到其他服务。这有助于提高系统的容错能力。
负载均衡：微服务可以根据每个服务的负载情况动态调整资源分配，从而实现负载均衡。
自动恢复：微服务可以在发生故障时自动恢复，从而提高系统的可用性。
动态扩展：微服务可以根据需求动态扩展或缩减资源，从而实现更高的资源利用率。
版本控制：微服务允许你独立更新和回滚每个服务的版本，从而实现更灵活的版本控制。
又在阮一峰的博客里得到了大差不差的回答。我心中的微服务观念也变得明确了起来
功能解耦 毫无疑问是开发中永恒不变的追求。微服务的产生也顺应了这个追求。一个原本功能复杂的庞大的单体项目，
在拆分成为微服务后，各个模块都是独立的进程可以独立运行。微服务的弹性也就由此体现，不会因为其中任何一个模块的瘫痪而导致整个服务的瘫痪
回过头来
明确了微服务的目的后再接着看上面的问题，心中已然有了定数。
微服务的目的绝不是一劳永逸。代码是要遵循需求的不断变化的。
而将权限认证一股脑丢到Gateway中正是前者的表现。个人认为，应该在每个微服务中都实现过滤器和拦截器来进行权限认证：
- 功能解耦 ：每个微服务都可以独立的处理自己的过滤器和拦截器，不需要依赖其他服务和外部系统。减少了系统的复杂度，提高了可维护性和可扩展性。避免了因其他服务失效而导致自己“裸奔”的情况出现
- 灵活性 ：每个微服务可以根据其特定的业务需求定制过滤器和拦截器的实现。有的服务可能需要复杂的权限认证，而有的可以只需要基本的授权。此时定制权限认证就显得尤为可贵
最后
再回顾某头条的做法，在他的业务场景中，服务的使用者有两种人群：自媒体、用户。他在Gateway中实现了过滤器先对token进行认证。然后又在service微服务中再对自媒体定制拦截器，将其信息存入线程。算是偷了个懒，把过滤器抽出来了。这样做的最坏结果也就是Gateway失效后用户和自媒体账号都无法登录，整个系统就此瘫痪