开发者学堂课程【全面讲解 Spring Cloud Alibaba 技术栈（知识精讲+项目实战）第三阶段：服务网关介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/685/detail/11885
服务网关介绍
内容介绍
一、引言
二、服务网关
三、网关的应用
一、引言
在学习服务网关之前要首先看一下现有环境中用到了哪些技术，还有什么样的缺点。
在这里画一下现在服务的一个架构，那么首先画一下用的两个微服务，上面就是订单微服务，下面是商品微服务。
用的一个案例就是下单，下单的话，订单微服务要去调用商品微服务，一开始是把商品的服务的 ip 地址和端口写死在订单里面，那么后来说这种方式管理起来是不方便，那么由此做一个组件，为服务治理组件，在这里表示一下服务治理组件，本次 用的服务治理组件是 spring cloud 阿里巴巴机组带动的 nacos，
接下来 需要将的订单和商品微服务都来注册到组件上，这个过程 称为服务注册。
接下来，订单微服务可以从 nacos 中获取商品微服务的 IP 地址和端口，这个过程就是服务发现，拿到商品微服务以后，就可以调用了，这个过程就是服务调用。
当多个商品微服务出现的时候，这个服务调用是没法负载均衡的，所以说又引入了另外一个组件，ribbon，来完成负载均衡，再加入一个组件 feign，像调用本地服务一样远程服务。
上一章，学了一个服务容错，当服务调用出现错误的时候，不至于造成服务雪崩，这个是 sentinel，在这里是做服务容错的。
二、服务网关
订单访问商品微服务这一条线是没有什么大问题的，但是如果不使用订单访问商品为微服务，而是在外界客户端，这个客户端可能有多个，比如说有 APP 或者 PC端。
如果这时客户端来调用订单微服务和商品微服务，这时就出现了问题。第一个出现的问题就很容易想到。
就是从客户端里维护订单微服务和品微服务的 IP 地址和端口号。如果是人工维护的话，这个难度是可想而知的。因为微服务一旦拆分就会出现成千上万个微服务。这个时候人工维护就不可能了。
IP 和端口号随时可能会变化。但是服务距离组件中有他们的变化列表。
当前架构下的问题:
1、客户端需要维护服务端的各个地址 代码困难
2、认证鉴权复杂
3、跨域问题
除此之外，再举一个案例
订单微服务是需要一定的权限才能访问的，我们需要先登录才能下订单，这就相当于在进行订单微服务之前，先需要进行一次健全，看是否登录，这个微服务需要健全，那么其他的微服务可能也需要鉴权，比如用户微服务的个人中心，这个也是需要鉴权的，如果在各个微服务之前加一个鉴权的话，可能会造成大量的重复逻辑，这就是认证或鉴权复杂，除此两种之外，还有第三个问题，在某些情况下，客户端问访问是有跨域问题的，要在每一个微服务中解决这个问题，也是一个非常复杂的代码问题，解决方案就是服务网关。
上面提到的问题，就可以借助 API 网关来解决，而这就是所说的服务网关，所谓的API 网关就是指系统的统一入门，它封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现诸如认证，鉴权，监控，路由，转发等等， 将这段话放在第一张图解释一下，将API网关添加进去，在拥有了 API 网关之后， 接下来需要做的如下图，
由API网关处理一些逻辑关系，就可以由此判断权限，如果没有权限，那就不需要往后面转发直接打回去就好，在这里也可以做一些监控，因为所有的东西都会经过API网关，在这里可以拿到所有的请求，他还可以做路由转发，一旦客户端的所有权限都对应上那就需要把它转到新的微服务上面去，例如他要返回订单，就需要把它转到订单微服务上，如果要转到商品微服务上，那就可以把它转到这里，这时 ，上面提到的第一个问题，就不需要维护每一个微服务的地址了，
而是由 API 网关来维护，而 API 网关从 nacos 中获取到地址，而 API 网关也可以看做是一个微服务，也可以注册到 nacos 上，
也可以在这中进行服务发现，拿到所有的地址，那这个时候只需要给他对应的地址标识就可以了，比如可以写一个//product.serv这就代表 想访问的是商品微服务，如果再写一个//order.serv，这代表想访问的是订单微服务，在看到这个路径之后，API 网关就会寻找对应的路径，会找相应的微服务的 IP 地址和端口，然后进行服务调用，这就是网关。
三、网关的应用
第一个是 Ngnix+luo，他经常在各种情况下使用，比如说静态网页服务器，反向代理负载均衡，他反向代理负载均衡的功能，就是起到一个网关的作用，而且这个他没有语言的依赖性，除了 JAVA 可以用，Python 也可以，PPT 也可以用，使用它的反向代理和负载均衡可实现对服务器的负载均衡及高可用，
也就是说，把他放在 API 网关的位置，他就可以把请求对应的转发，这里还有一个lua 的作用，它是一种脚本语言，可以在这里实现一种简单的业务逻辑编写，比如说鉴权，你就可以使用这个脚本写一段鉴权，甚至可以使用它连接客户端去查一些东西，然后通过鉴权以后，看看这个客户端能不能满足服务，Ngnix 内置是对 lua脚本进行了支持的，不需要单独加别的模块。
第二种是 kong，它是基于 Ngnix+luo 进行了一个开发，性能高，稳定，有多个可用的插件，（限流，鉴权等等），可以开箱即用，但他也有一些问题，第一个问题就是只支持 HTTP 协议，第二问题是在他继续进行二次开发的时候，就比较困难，第三问题是他提供管理 API，但是他缺乏更易用的管控，配置方式。
第三个就是 zuul，这是 spring clue 的一系列默认用的一个网关，基于 Netflix 开源的网关，功能丰富，使用JAVA开发，易于二次开发，但是zuul的1.0版本是有很大问题的，第一个问题是缺乏管控，无法动态配置，第二个问题是依赖组件较多，第三个问题是处理HTTP请求依赖的是 web 容器，性能不如 Ngnix，目前spring cloud 全家桶中使用的网关是 spring cloud getaway，而非 zuul。
第四个是 spring cloud getaway，是为了替换 zuul 而开发的网关服务。
目前学的这个站点是 spring cloud alibaba，但是这个里面没有专门提供一个网关，为了保证此次课程的一个完整性，选用了 spring cloud 提供的这一款 getaway 做网关，接下来提到的 getaway 都是 spring cloud gateway。
