1.什么是服务网关2.为什么是服务网关3.服务网关技术选型1.总体流程2.引入网关注意事项3.服务网关的基本功能4.技术选型1.什么是服务网关服务网关=路由转发+过滤器1、路由转发：接收所有外部请求，转发给后端微服务；2、Filter：在服务网关中可以完成一系列的横切功能，比如权限校验、限流和监控等，都可以通过过滤器来完成（其实路由和转发也是通过过滤器来实现的）.2.为什么需要服务网关？上面提到的横切功能（以权限验证为例）可以写在三个地方：每个服务自己实现，写成一个公共服务，然后所有其他服务依赖于这个服务，写在前置过滤器中服务网关的所有请求都来进行权限验证。第一种缺点明显，基本不用；第二种比第一种好很多，代码开发不会冗余，但是有两个缺点：由于每个服务都引入了这个公共服务，相当于在每个服务中都引入了相同的权限验证码，增加了无故每个服务的jar包大小，特别是在使用docker镜像部署的场景下，jar越小越好；由于每个服务都引入了这个公共服务，我们以后可能很难升级这个服务，公共服务的功能越多，升级就越难，假设我们改变公共服务中的权限验证方式和想要所有的服务都使用新的权限验证方式，我们需要将之前的所有服务重新打包，编译部署。服务网关正好可以解决这个问题：把权限校验的逻辑写在网关的filter中，后端服务不需要关注权限校验的代码，这样服务的jar包就不会引入权限校验逻辑，不会增加jar包体积；如果要修改权限验证的逻辑，只需要修改网关中的权限验证过滤器即可，不需要升级所有已有的微服务。所以，需要一个服务网关！！！3、服务网关技术选择引入服务网关后的微服务架构如上，一般包括三部分：服务网关、开放服务和服务。1、整体流程服务网关、open-service和service在启动时都会注册到注册中心；用户请求时，直接向网关请求，网关对open-service进行智能路由转发（包括服务发现、负载均衡），包括权限验证open-service聚合内部服务响应，进行检查、监控、和限流，并将它们返回给网关，然后再返回给用户。只是），性能会下降一点（但下降不大，一般情况下，网关机器性能会很好，而且网关和open-service之间的访问一般都是内网访问，速度非常快）；网关的单点问题：在整个网络调用过程中，必然存在一个单点，可能是网关、nginx、DNS服务器等，为了防止网关单点，可以挂网关层前面的另一个nginx。nginx的性能极高，基本不会挂。之后网关服务就可以继续添加机器了。但是这样的请求被转发了两次，所以最好的办法是把网关单点服务部署在强大的机器上（通过压测估计机器的配置），nginx和zuul的性能对比，据国外判断从我一个朋友做的实验来看，差别不大。Zuul是netflix用于网关的开源框架；网关应尽可能轻。3、服务网关基本功能智能路由：接收所有外部请求，转发给后端对外服务open-service；注意：我们只转发外部请求，服务之间的请求不经过网关，也就是说全链路跟踪、内部服务API监控、内部服务调用之间的容错、智能路由都不能在网关完成；当然，所有的服务调用也可以通过网关进行路由，那么几乎所有的功能都可以集成到网关中，但是这样的话，网关的压力就会很大，不堪重负。权限验证：只验证用户对开通服务的请求，不验证服务内部请求。是否需要验证服务内部的请求？API监控：只监控经过网关的请求，以及网关本身的一些性能指标（如gc等）；限流：配合监控进行限流操作；API日志统一收集：类似于aspect切面，记录接口进入和退出时的相关日志。..后续补充以上功能是网关的基本功能，网关还可以实现以下功能：A|B测试：A|B测试是一个比较大的东西，包括后台实验配置，数据埋点（见转化率)和分发引擎，在服务网关中，可以实现分发引擎，但实际上分发引擎会调用内部服务，所以如果按照上图的架构，分发引擎最好做在开放服务，不在服务网关。...后续补充4.技术选型笔者打算自己搭建一个轻量级的服务网关。技术选择如下：开发语言：java+groovy。groovy的优点是网关服务可以动态添加过滤器实现一些功能而不用重启；微服务基础框架：springboot；网关基础组件：netflixzuul；服务注册表：consul；权限验证：jwt；API监控：prometheus+grafana；API统一日志采集：logback+ELK；..后续补充在后续的介绍中逐步介绍各个知识点，完成一个轻量级的服务网关！！！
