网关你真的了解吗？为什么微服务一定要有网关？

①网关是什么

②什么是服务网关

③微服务中的网关技术选型是怎样的

今天这篇文章就围绕着上述三个标题为大家展开解读，欢迎大家一起相互探讨，交流学习！

网关是什么？

在之前的互联网单体的应用架构中，也是存在网关这一重要角色的。直到现在比较火热的微服务架构中，在无数的服务集群，同样，网关也是不可或缺的！那么网关究竟是什么？网关其实可以用一个公式去表示！

网关 = 路由转发 + 过滤链

路由转发：所谓的路由转发大家可能也都理解。在实际的prod环境中，我们既是项目是一个单体架构的应用，那么也会在生产环境考虑到做高可用，因为要保证我们的系统能够正常的运行，一般情况下都会去做集群或者双机热备等策略！那么其实路由就是建立在集群基础之上的。用户发来的请求根据不同的策略进行分发给系统集群服务器的实例。通常公司采用的技术选型都是nginx+lua做单体的网关服务！
过滤链
网关不单单只是做了请求的路由转发的功能，其实还有很多的公司会在网关层面去做log日志的收集，系统权限的验证，等等一系列的操作，但是归根结底是还同一种思想，那就是在网关层做一系列的横切功能！
nginx+lua
现阶段很多的公司在网关层基本上来说技术选型用的还是nginx+lua去做请求的转发，日志收集，以及系统权限的验证等，但是nginx+lua可不单单的只能做这两项操作，比如这两者做动静分离呀或者其它的东西，我们公司现在就是在商品详情以及商品列表用nginx+lua+ES/redis做的动静分离。当然技术结合起来能解决的问题还是非常多的，因此大家可以有时间自行学习研究！

在微服务中为什么需要服务网关

上述所说的横切功能（以权限校验为例）在微服务系统中可以写在三个位置：
①每个服务自己实现一遍
②写到一个公共的服务中，然后其他所有服务都依赖这个服务
③写到服务网关的前置过滤器中，所有请求过来进行权限校验
第一种，缺点太明显，基本不用；第二种，相较于第一点好很多，代码开发不会冗余，但是有两个缺点：
缺点一:由于每个服务引入了这个公共服务，那么相当于在每个服务中都引入了相同的权限校验的代码，使得每个服务的jar包大小无故增加了一些，尤其是对于使用docker镜像进行部署的场景，jar越小越好；
缺点二:由于每个服务都引入了这个公共服务，那么我们后续升级这个服务可能就比较困难，而且公共服务的功能越多，升级就越难，而且假设我们改变了公共服务中的权限校验的方式，想让所有的服务都去使用新的权限校验方式，我们就需要将之前所有的服务都重新引包，编译部署。

服务网关技术选型

运作流程

①服务网关、open-service和service启动时注册到注册中心上去；
②用户请求时直接请求网关，网关做智能路由转发（包括服务发现，负载均衡）到open-service，这其中包含权限校验、监控、限流等操作
③open-service聚合内部service响应，返回给网关，网关再返回给用户
注意点
①增加了网关，多了一层转发（原本用户请求直接访问open-service即可），性能会下降一些（但是下降不大，通常，网关机器性能会很好，而且网关与open-service的访问通常是内网访问，速度很快）；
②网关的单点问题：在整个网络调用过程中，一定会有一个单点，可能是网关、nginx、dns服务器等。防止网关单点，可以在网关层前边再挂一台nginx，nginx的性能极高，基本不会挂，这样之后，网关服务就可以不断的添加机器。但是这样一个请求就转发了两次，所以最好的方式是网关单点服务部署在一台牛逼的机器上（通过压测来估算机器的配置），而且nginx与zuul的性能比较，根据国外的一个哥们儿做的实验来看，其实相差不大，zuul是netflix开源的一个用来做网关的开源框架；
③网关要尽量轻。

轻量级的网关技术选型推荐

①开发语言：java + groovy，groovy的好处是网关服务不需要重启就可以②动态的添加filter来实现一些功能；
③微服务基础框架：springboot；
④网关基础组件：netflix zuul；
⑤服务注册中心：zookeeper/eureka/consul；
⑥权限校验：jwt；
⑦API监控：prometheus + grafana；
⑧API统一日志收集：logback + ELK；
⑨压力测试：Jmeter；