先说一下，我为什么了解到了网关上来了。
公司有好几个系统维护，它们都需要鉴权。然后有人提出了想要单点登录。
我们之前的鉴权是针对各个系统的，整个链路的调用是，用户的请求直接到了服务上，然后服务又去远程调用了鉴权，通过则返回结果，不通过则拦截。
这和我想的不一样，我想的是，所有的请求应该到统一的一个地方，然后这个地方负责统一的权限认证，负责单点登录，负责负载均衡，负责限流，还负责审查，和监控。
# # 最终锁定了：网关
这个技术就是我想找到，它可以解决我想要解决的的问题。除了上边我提到的问题，网关还解决了跨域问题，解决了复杂的调用问题，网关推进了前段与后端的解耦。前端统一调用网关，网关分发给服务。
# # 网关位于整个架构中的位置,以及好处
可以从下图中看到，在使用网关以后，可以把常用的功能抽取出来，也叫公共服务的下沉。鉴权，限流，熔断，审计，报警，等系统应该具备的能力，全部从业务中提取了出来。
最终我们的后台业务开发，就值需要关注业务逻辑，而不需要单独关注鉴权，限流，熔断，审计，报警，等公共服务了。真正意义上能够做到代码的复用。
## 对于众多的网关系统，如何选择适合自己公司的
其实任何一个技术的选型，都可以从 社区的活跃度，以及扩展性，性能等大的方面去考量。还应该考虑在压力测试下，稳定性究竟如何。
还有考虑一个语言生态环境的问题，在团队的技术栈中，是否包含对应的技术。比如下边的，如果使用java语言的话，则使用OpenResty和kong，则不太合适，因为它们是 nginx+lua的。
## 使用网关有诸多的好处，但是我们也是要认清楚问题
比如说在使用网关以后，带来的性能的损失。
我看了《高可用可伸缩为服务架构》这本书，上边单点截图也是来自这本书。
在书中，有介绍这几个网关的性能的损失，其中性能的话是这样一个顺序：getway zuul2 < OpenRest < Kong
以直连为参照，getway 和 zuul2 是直连的百分之三十到四十， OpenRest 和 kong 大概是直连的 百分值六十到百分之七十。
对于性能的损失，我们是可以通过增加机器来弥补的。在书中说：其中zuul 的稳定性是非常差的，200用户，1000并发，返回错误竟然有百分之五十。
