咱们今天继续说springcloud的zuul。在最早我们是没有网关这个概念的,微服务搭建起来后,客户端就直接访问一个个微服务了,这些方式有很多的弊端,上次都说了,针对这些弊端,我们用一种什么样的方式去解决呢,那就是springcloud为我们整合一个框架zuul统一的微服务,在这些所有的后端的微服务中间加了一层网关层,网关层类似于设计模式里面的门面模式,就是靠这种门面进行隔离让后端的和请求端进行隔离解耦,互相之前不进行相互的影响,他们之前的影响都通过门面来进行解决。切记:网关调用后端的微服务,全部使用无状态请求。
源码:https://github.com/limingios/netFuture/tree/master/源码/『互联网架构』软件架构-zuul微服务网关(中)(101)/
![f9ceeabb8a4b43fb890698c3649e5638.png](https://i-blog.csdnimg.cn/blog_migrate/0a1cf9d00a5a0465e860414758a301c6.jpeg)
(一)zuul聚合微服务
许多场景下,外部请求需要查询 zuul后端的多个微服务。举个例子,一个电影售票手机APP,在购票订单页上,既需要查询“电影微服务"获得电影相关信息,又需要查询“用户微服务"获得当前用户的信息。如果让手机端直接请求各个微服务(即使使用 zuul进行转发),那么网络开销、流量耗费、耗费时长可能都无法令我们满意。那么对于这种场景,可使用 zuul聚合微服务请求一一一手机 APP只需发送一个请求给 zuul,由 zuul请求用户微服务以及电影微服务,并组织好数据给手机 APP,使用这种方式,手机端只须发送一次请求即可,简化了客户端侧的开发;不仅如此,由于 zuul、用户微服务、电影微服务一般都在同一个局域网中,因此速度会非常快,效率会非常高。
- 实例代码
08-ms-gateway-zuul-aggregation
![d2c1d756359367b7c139d46c878aa8ad.png](https://i-blog.csdnimg.cn/blog_migrate/5b5929d506fedc50380f97e88bcaaf47.jpeg)
- 运行项目(需启动两个用户微服务和一个订单微服务,eureka-server,zuul的项目
- 1.08-ms-consumer-order-ribbon
- 2.08-ms-eureka-server
- 3.08-ms-gateway-zuul-aggregation
- 4.08-ms-provider-user