专栏首页编程坑太多『互联网架构』软件架构-zuul微服务网关(上)(100)

『互联网架构』软件架构-zuul微服务网关(上)(100)

不知不觉,文章都写100篇了,从0到1,从1到100,感谢老铁们的支持,不同的微服务一般有不同的网络地址,而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。比如一个电影购票的收集APP,可能回调用电影分类微服务,用户微服务,支付微服务等。源码:https://github.com/limingios/netFuture/tree/master/源码/『互联网架构』软件架构-zuul微服务网关(上)(100)/

zuul微服务网关

  • 微服务网关产生原因

公司内部一致都使用微服务,微服务都是通过doubo这种互相调用了,现在新起来一个项目需要调用电影分类微服务,用户微服务,支付微服务等。

1. 客户端会多次请求不同微服务,增加客户端的复杂性。2. 存在跨域请求,在一定场景下处理相对复杂。(有的公司服务比较微服务都是通过内部的域名的方式,分类的微服务域名www.idig8.com/type,用户微服务www.idig8.com/user,用户微服务www.idig8.com/pay,这样就不存在跨域的问题。但是大多数公司都是分类的微服务域名type.idig8.com,用户微服务user.idig8.com,用户微服务pay.idig8.com,主流的公司都是通过二级域名来的区分微服务的东西,如果通过ajax进行调用的话,这就涉及到跨域的问题) 3. 认证复杂,每一个服务都需要独立认证。4. 难以重构,随着项目的迭代,可能需要重新划分微服务,如果客户端直接和微服务通信,那么重构会难以实施。(本身微服务都是拆分的细,拆分的越细越方便重构,对于整体来说是复杂了,但是对于小模块来说业务逻辑少了细了方便重构了。BAT这种大型互联网公司最大的特点就是快,三天两头需求跟这边,一天可能变几次需求,一周可能发布5,6个版本,一个是需求快,快速响应需求,在做新需求的时候需要重构以前写的不好的地方,第一开始设计的系统都是不完美的,真正完美的系统都是通过重构出来的,可能重构很多次,例如上边的图例如果把商品分类微服务拆分了,拆分成商品价格服务,商品基础资料服务,商品分类服务,这样拆分后完蛋了,原来客户端调用一个服务现在调用3,4个服务,它也需要改。) 5. 某些微服务可能使用了其他协议,直接访问有一定困难。(有的服务是http的,有的服务RPC的,也就是需要支持多种协议,也特别麻烦)

都可以借助微服务网管解决。微服务网管是介于客户端和服务器端之间的中间层,所有的外部请求都会先经过微服务网关,架构演变成(其实就是门面的设计模式,统一服务,到达隔离)。

  • zuul微服务网关

Zuul是Netflix开源的微服务网关,他可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul 组件的核心是一系列的过滤器。 官网https://github.com/Netflix/zuul

1. 动态路由:动态将请求路由到不同后端集群。2. 压力测试:逐渐增加指向集群的流量,以了解性能。3. 负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求。4. 静态响应处理:边缘位置进行响应,避免转发到内部集群。5. 身份认证和安全: 识别每一个资源的验证要求,并拒绝那些不符的请求。

Spring Cloud对Zuul进行了整合和增强。目前,Zuul使用的默认是Apache的HTTP Client,也可以使用Rest Client,可以设置ribbon.restclient.enabled=true。 源码:08-ms-gateway-zuul 添加依赖

    <dependency>      <groupId>org.springframework.cloud</groupId>      <artifactId>spring-cloud-starter-netflix-zuul</artifactId>    </dependency>    <dependency>      <groupId>org.springframework.cloud</groupId>      <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>    </dependency>

application.yml

server:  port: 8040spring:  application:    name: microservice-gateway-zuuleureka:  client:    service-url:      defaultZone: http://localhost:8761/eureka/  instance:    prefer-ip-address: truemanagement:  security:    enabled: false

运行项目(需启动两个用户微服务和一个订单微服务,eureka-server,zuul的项目 1.08-ms-consumer-order-ribbon 2.08-ms-eureka-server 3.08-ms-gateway-zuul 4.08-ms-provider-user

访问尝试:http://127.0.0.1:8040/microservice-consumer-order/user/1发现zuul会代理所有注册到eureka server的微服务,并使用ribbon做负载均衡,zuul的路由规则如下,可以访问地址:http://localhost:8040/routes

http://ZUULHOST:ZUULPORT/微服务在Eureka上的serviceId/**会被转发到serviceId对应的微服务:http://127.0.0.1:8040/microservice-consumer-order/user/1

zuul还自动整合了hystrix。http://localhost:8040/hystrix.stream

PS:目前通过一个zuul的一个api地址只能访问一个服务,但是在实际的生产中,通过访问一个网关需要调用后端的多个微服务,也就是客户端想访问商品的详情的页面,如果是接口的话,我需要访问后端的3个接口,现在使用了zuul我需要的客户端只请求1个api接口,却可以调用后端的3-4个接口,而不是一个一个请求调用。下次咱们一起说说聚合微服务网关。

本文分享自微信公众号 - 编程坑太多(idig88),作者:诸葛阿明

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 『高级篇』docker之微服务架构带来的问题(五)

    IT故事会
  • 『互联网架构』软件架构-服务限流降级熔断机制详解(95)

    IT故事会
  • 『高级篇』docker容器来说什么是微服务(三)

    IT故事会
  • 京东技术沙龙系列之二 | 深度解析京东微服务组件平台

    京东技术
  • 7个点说清楚spring cloud微服务架构

    spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注...

    程序员追风
  • 一张图带你了解 Spring Cloud 微服务架构!

    Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注释说明,蓝线由A指向B,表示B从A处获取服务。

    搜云库技术团队
  • 一张图了解 Spring Cloud 微服务架构

    Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注...

    芋道源码
  • 云计算的体系结构

    云计算的体系结构由5部分组成,分别为应用层,平台层,资源层,用户访问层和管理层,云计算的本质是通过网络提供服务,所以其体系结构以服务为核心。 如下图: ? 1,...

    cloudskyme
  • ServiceMesh实战——什么是服务网格

    牛顿有曰:如果说我看得比别人更远些,那是因为我站在巨人的肩膀上。 学习前人的成果,就是先努力站到巨人的肩膀上;掌握前人的成果是前进的必要过程。有些人不学就懂了,...

    秦始皇2.0
  • 「微服务架构」Google和eBay在构建微服务生态系统方面的深刻教训

    当你看到来自谷歌,Twitter,eBay和亚马逊的大规模系统时,他们的架构已演变成类似的东西:一组多语言微服务。

    首席架构师智库

扫码关注云+社区

领取腾讯云代金券