开发者学堂课程【5天突破 Spring Cloud：网关、Nacos 和 Sentinel】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/781/detail/13704
网关、Nacos 和 Sentinel
课题引入：
从开始学习微服务架构包括应用场景，对应的问题点也叫关注点，不同的组件解决不同的问题，在相同的技术问题上 spring cloud 体系又出现了很多相同的或者类似的技术组件解决相应的问题，像是代理，网关，注册发现，相对的配置，安全都具有相似的技术出现。
spring secret 在 spring boot 2.5实战中提过，安全框架不一定要和 spring cloud 来结合用，它本身是独立的框架。
之前 spring boot2.5 实战中集成过一次安全课程， spring cloud 做安全实际上也可以和 spring secret 结合，同改装汽车一样，需要什么工种加什么工种， spring cloud 本身更高层次架构的，更复杂的集群架构模式下的一个借用 spring boot 的 API 自理的一套框架，不仅仅是简单的接口调用，更是大功率下的一种集群的监控，自理，调度这些问题。安全也是，其他企业知道后，部署完谁都可以调用性能不够安全。
一般情况下和 spring boot 讲到的机制一样，需要进行拦截身份验证，具体到拦截可以去定制去开发，去拦截恶意的请求消息，进行客户端消息的身份验证。
比如消息图中放入令牌自传来进行完成，无论是阿里 service 还是 spring secret ，spring secret 属于 spring 家族，它可以和其他 spring 的各个框架集成的非常好，去实现令牌的识别认证。 spring secret 属于独立的安全框架，主要是在整个体系中处理安全问题，现在的各种机制也都支持。
注意它底层原理本质上对于底层 service API的 wide 框架也是扩展的过滤器，通过这种模式来实现，对于有可能有些特殊的比如网关的输入模式，输入模式相对的较早的内品公司所贡献的，之后的 spring cloud gateway ，spring cloud 官方所说基于响应式编程，底层运用 well flags 模式，当然也可以做身份验证本质上也是用的过滤器，不同的是语法被换掉了。
响应式编程重要的特点是在编程中代码中大量的使用 long 表达式这种语法，看起来较为奇异。实际上万变不离其宗，只要有请求进入你的网站，需要想办法进行拦截才能进行验证。
比如现实生活中交警在高速公路式的盘卡抓犯人一样的道理，不拦截这些请求，请求随便进入没有安全机制。网络请求本质也上一样，只是在 java 网站方向来做，今天讲到的网关英文名 gateway ，听起来较为陌生，不太好理解，为什么会有网关这个词？
当然网关这个词不是 java 中专有的，在计算机网络有这样的一层设备中途做这件事情。严格意义来讲，英文叫 gateway 换个说法即从一个网络到另一个网络本来是有边界的，但是因为你有 gateway ，gateway可以通过其入口或者门进入到另一个网络，这是早期计算机网络领域中的一个词汇，值得注意的是， gateway 解决微服务对外暴露的问题，一般的数据库或者微服务在同一个局域网，但是在共网需要手机 APP 调用的话，需要域名以及固定的 IP 地址，这时如何找到它？一般情况，后台微服务有独立的局域网 IP 地址，这个 IP 地址在公共网上无法找到，这时需要一个统一的出口，即 Zuul 这样的一个角色。
内容介绍：
一、 Java spring cloud 网关 Zuul
二、 Spring cloud 网关 zuul 实站
一、Java spring cloud 网关 Zuul
Zuul 出现的比较早，最早是由 netflix 公司贡献，使用时间较长。Zuul 本身实际对外是网关是代理，别人先调用它，它再转发给后台具体的请求。后台正式的服务位于局域网， zuul 本身也有调用机制，包括 hystrix 机制，熔断机制， ribbon 负载平衡的机制也有。到现在而言网关代理还存在一个替身即 spring cloud gateway 注意一下。 zuul 本身在之后2.0就停止使用了，3.0比较有意思的就是后来又使用，spring cloud 官方发布 gateway 之后，采用响应式底层模式支持更高的充阻量， zuul 在3.0也进行改造。
现在面对的问题即如果3.0做集成，需要自己进行验证。官方也进行划分界限、切分，维护更新较慢，设法将其替换。注意观察架构图，如下：
定位 business service 1、2、3就是订单服务、自录服务、快递服务、点评服务、包括点赞服务等等不同的微服务，可能每个服务都有自己的数据库，可能有一部分会共享自己的数据库。
每个实际上是独立的一套应用集群，但统一都有出口，即 gateway 网关，早期 zuul， 现在 gateway 两个都有。本身它位于中间，既是服务端又是客户端，相对于前后端而言。
一般做身份验证在 zuul 拦截来做，一般都是基于令牌方面来做。安全一般都在特定的位置，这个机制本身比起分闸度，可以做日志，也可以定制自己的路由策略，发什么请求？给谁发？
二、Spring cloud 网关 zuul 实战
基于 spring cloud 中的 spring boot2.3版本，作为网关需要设法将 sentinel 自由化即监控数据自由化，可以用配置数据库的方法。有些监控系统如：
hystrix 默认在内存中临时缓存部分监控数据，现在性能良好的 nars， 其他的一些监控框架中的有些数据可以支持如：
基于 Mysql 或者基于其他的 ES 没有数据库来做替换操作。较好的框架有功能性的扩展，一般的框架较为基础。
演示例子也没有配置数据库，若条件适宜，可自行配置数据库。做网关服务，需要注意之后可以自己替换 ABI 链接，本质上是若你使用的是 client0 zuul netty 这种响应式模式，还有默认使用的 API 连接池没有，有链接池可以从一定程度上提升性能，也可以手动替换数据库。
观察网关的代码，zuul 本身的服务实际上和之前讲的 java 模式相类似，多了一个做引用。加有应用包后，注解 dependency 可以直接作为启用代理，有复杂的是自定义扩展，包括做的安全框架。只配代理服务器，其默认会像 zuul proxy 中心一样进行对接获取最新的服务状态信息，并且其请求转发会简化即可以把请求服务发送给代理服务器，代理服务器加上服务名和方法名即可。它自动会基于服务名进行路由位置的匹配转发，有些复杂的地方是有些公司企业可能会基于代理服务器进行拦截或者是身份验证亦或是进行消音路由。本质上，其配置文件和之前没发生改变，数字变为10000，其参数没发生改变。自定义路由可以用配置文件或者代码方式，具体示例如图，
等待数字中心页面显示，网页页面存在调用端，订单服务有一台，再多加一个订单服务即启用多台订单模拟集群，观察一下官方文档是否存在，官方文档存在即可。
代理服务器本身角色比较简单，在 k8s 社区中比较有名的代理服务器 ingress ，在之前讲路由算法提到过其支持路由算法多达十种，而且早期 ingress 转发 IGB 协议也可以支持 TDB 协议， TDB 路由的长链接主要是系统问题， ingress 可以很轻松的每秒达到十万级别，属于 k8s 中较为优秀的代理服务器。
还有一些优化的版本如 template 改版为 TElinux ， Kong 也是其改版。里面有很多，大多数是基于该例子的自定义代码的扩展版本， linux 本身被 iPhone 公司收购之后，推出 linux 收费版本，有很多高级部门如高级的启程负载，属于企业版本，官方网站类似于 mysql 收取费用，具体观看如图：
这里有两个订单服务，8001、8002有一个代理服务器1000，那么要访问之前的那个服务需要具体出服务名如： order-micro service ，名字注意一下。这个服务的功能即 hello 前面加一个服务名，具体怎么调查，做个测试，直接访问8001、10000加代理名字和服务名字，输入全称 order-micro service ，发现有问题如图：
转发出现问题，换成小写再次尝试，通过网关10000的访问接口，访问 order-micro service/hello 成功。刷新尝试，发现一直掉 c， 观察具体问题，出错如图：
显示问题是缺少 for back ，存在过滤器的错误说明服务中心接口出错。2服务附近的可以调通即 order-micro service 8001 可以调用，在这通过代理服务器调用后台的订单服务。
