微服务网关数据流（微服务架构网关）-eolink官网

微服务网关数据流（微服务架构网关）

本篇文章给大家谈谈微服务网关数据流，以及微服务架构网关对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。今天给各位分享微服务网关数据流的知识，其中也会对微服务架构网关进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

1、Spring Cloud Zuul微服务网关的API限流
2、微服务六：服务网关
3、微服务方式实现双重网关
4、微服务网关

Spring Cloud Zuul微服务网关的API限流

微服务开发中有时需要对API做限流保护，防止网络攻击，比如做一个短信验证码API，限制客户端的请求速率能在一定程度上抵御短信轰炸攻击，降低损失。

微服务网关是每个请求的必经入口，非常适合做一些API限流、认证之类的操作，这里有一个基于zuul微服务网关的API限流库：

https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit

比如我们要对 user-service 这个服务进行限流，限制每个请求源每分钟最多只能请求10次。

首先在项目中添加 spring-cloud-zuul-ratelimit 依赖：

然后再添加如下配置即可：

对API限流是基于Zuul过滤器完成的，默认情况下限流数据是记录在内存中的，实际上是用ConcurrentHashMap保存，当然也提供了多种存储方式，包括Redis、Consul、Spring Data JPA，使用这三种存储方式要添加相关依赖。

然后再添加存储配置，比如使用Redis的配置：

限流过滤器是在请求被转发之前调用的

限流类型主要包括url、origin、user三种

在过滤器的run方法中判断请求剩余次数，小于0就拦截请求：

可以看到，单位时间内剩余请求次数小于0时抛出ZuulRuntimeException，直接返回客户端TOO_MANY_REQUESTS异常消息，达到拦截请求的效果。

https://github.com/yunTerry/spring-cloud-netflix

微服务网关数据流（微服务架构网关）

微服务六：服务网关

服务除微服务网关数据流了内部相互之间调用和通信之外微服务网关数据流，最终要以某种方式暴露出去，才能让外界系统（例如客户微服务网关数据流的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图（15），网关是连接企业内部和外部系统的一道门，有如下关键作用微服务网关数据流：

服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。

限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。

监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。

日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。

图（15）gateway服务图

除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。

开源的网关组件有Netflix的Zuul，其工作原理如下图。

图（16）zuul工作原理图

在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图(17)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在图（17）的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Façade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。

图（17）简化的微服务架构图

微服务方式实现双重网关

最近在做一个多项目整合的工作，因为每个项目都有自己的一套网关，每个网关都有自己的加解密算法，整合到一起要求对外提供统一的用户鉴权，而且不对原有系统做大规模的重构，基于这些现实考虑使用两重API网关架构来构建新系统的统一网关体系。

备注：其中的统一网关、业务网关、业务微服务都是微服务的模式注册到微服务中心。

这个网关采用zuul来进行网关过滤及路由，其中过滤规则由各个业务网关以微服务方式提供，通过Feign来调用，这个方式也是区别于传统网关的，也是实现双重网关的关键所在。
这里要遵循的基本原则是：授权/鉴权一体化，即授权策略和鉴权方法都是由各个业务网关自己维护，这样就确保了功能的封闭性和一致性，在开发和后期维护中都非常的方便高效。

备注：这个类是zuul的主类实现了过滤/路由，其中的鉴权部分调用了相关的微服务，这些微服务以@Autowired的方式注入进来。
接口定义如下：

路由策略通过配置实现，因为是微服务所以直接指定路由到的微服务id即可，配置文件可以存储到微服务治理中心的配置中心。

备注：其中的user-base、user-org分别是两个业务微服务。

这个网关集群按照业务划分，每个网关实现了授权和鉴权的策略算法，并以微服务的方式提供，其中授权是对相关敏感信息做加密并以token的方式存储到cookie中，鉴权是将存储在客户端的token通过相应的解密算法进行核验和鉴权，确保该token的合法性、有效性，只有有效的token才能够通过鉴权并解析出敏感信息传递到指定的路由服务中。

备注：该网关使用JWT进行敏感数据加密

备注：该网关使用RSA进行敏感数据加密
H5业务网关以微服务方式提供了授权/鉴权服务，其中授权服务直接暴露给客户端，客户端调用后将业务类型app_type和授权token写入cookie，鉴权服务暴露给统一网关，对传递的token进行鉴权，鉴权成功后将token中的加密信息解析出来后返回给统一网关，由统一网关路由到业务微服务并将该参数传递下去。

备注：其中register、login是生成授权token流程，readUserinfo是通过token鉴权后访问业务微服务的流程。