Springcloud：网关zuul+链路追踪zipkin

prtyaa 2023-12-28 16:06:59  50551

分类专栏：资讯

微服务没有网关，会有下面的问题：

客户端请求多个微服务，增加了客户端复杂性，每个微服务都要做用户认证，限流等，避免和多个微服务打交道的复杂性。
有跨域问题，不在同一个域。
认证复杂，每个服务都要独立认证，服务要求的权限不一致。
难以重构。因为微服务被客户端调用着，重构难以实施。

网关是介于客户端（外部调用方比如app，h5）和微服务的中间层。

Zuul是Netflix开源的微服务网关，核心是一系列过滤器。这些过滤器可以完成以下功能。

是所有微服务入口，进行分发。
身份认证与安全。识别合法的请求，拦截不合法的请求。
监控。在入口处监控，更全面。
动态路由。动态将请求分发到不同的后端集群。
压力测试。可以逐渐增加对后端服务的流量，进行测试。
负载均衡。也是用ribbon。
限流（望京超市）。比如我每秒只要1000次，10001次就不让访问了。
服务熔断，不应该等到调用链很深的时候发现熔断了，应该一开始就在网关熔断。

网关和服务的关系：演员和剧场检票人员的关系。

zuul默认集成了：ribbon和hystrix。

把网关搭起来，本地的话就可以localhost/user-consumer/xxx localhost/user-provider/xxx访问了

provider有集群，但是consumer没有，consumer访问是springmvc接收请求，那每一个consumer都记一个ip吗？显然不是，consumer集群前面再来一层网关。

因为网关zuul默认集成了：ribbon和hystrix。而且注册了eureka，则可以把eureka中注册的consumer的服务列表拉取出来，当用户访问的时候就可以选一个。网关会将服务名转换成具体服务的ip和端口，实际进行访问

consumer服务名/consumer里的资源（方法名）：
例如 localhost/user-consumer11/demo

这个功能叫路由，网关的第一个功能路由

zuul 网关没有 kong的性能好

网关单点怎么办？前面再加一层负载均衡 Nginx或者LVS

基于隧道模式的业务网关 zuul nginx kong，想要提高zuul的性能的话，设置成无状态，优化线程为异步，zuul是跑在tomcat上，基于servlet和filter的。

所有的拒绝策略尽可能的前置

链路追踪 sleuth + zipkin 在consumer和provider都需要配置。

链路追踪的必要性

如果能跟踪每个请求，中间请求经过哪些微服务，请求耗时，网络延迟，业务逻辑耗时等。我们就能更好地分析系统瓶颈、解决系统问题。因此链路跟踪很重要。

自己思考解决方案：在调用前后加时间戳。捕获异常。

链路追踪目的：解决错综复杂的服务调用中链路的查看。排查慢服务。

市面上链路追踪产品，大部分基于google的Dapper论文。

zipkin,twitter开源的。是严格按照谷歌的Dapper论文来的。

pinpoint 韩国的 Naver公司的。

Cat 美团点评的

EagleEye 淘宝的

链路追踪要考虑的几个问题

探针的性能消耗。尽量不影响服务本尊。
易用。开发可以很快接入，别浪费太多精力。
数据分析。要实时分析。维度足够。

Sleuth简介

Sleuth是Spring cloud的分布式跟踪解决方案。

span(跨度)，基本工作单元。一次链路调用，创建一个span，
span用一个64位id唯一标识。包括：id，描述，时间戳事件，spanId,span父id。
span被启动和停止时，记录了时间信息，初始化span叫：root span，它的span id和trace id相等。
trace(跟踪)，一组共享“root span”的span组成的树状结构称为 trace，trace也有一个64位ID，trace中所有span共享一个trace id。类似于一颗 span 树。
annotation（标签），annotation用来记录事件的存在，其中，核心annotation用来定义请求的开始和结束。

CS(Client Send客户端发起请求)。客户端发起请求描述了span开始。
SR(Server Received服务端接到请求)。服务端获得请求并准备处理它。SR-CS=网络延迟。
SS（Server Send服务器端处理完成，并将结果发送给客户端）。表示服务器完成请求处理，响应客户端时。SS-SR=服务器处理请求的时间。
CR（Client Received 客户端接受服务端信息）。span结束的标识。客户端接收到服务器的响应。CR-CS=客户端发出请求到服务器响应的总时间。

其实数据结构是一颗树，从root span 开始。

使用

Sleuth单独

pom
每个需要监控的系统

<!-- 引入sleuth依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>

测试点：

启动eureka 7900，service-sms 8002，api-driver 9002.
访问一次。看日志结果。

 [api-driver,1a409c98e7a3cdbf,1a409c98e7a3cdbf,true] 
 
 [服务名称，traceId（一条请求调用链中 唯一ID），spanID（基本的工作单元，获取数据等），是否让zipkin收集和展示此信息]

看下游
[service-sms,1a409c98e7a3cdbf,b3d93470b5cf8434,true]

traceId， 是一样的。

服务名必须得写。

zipkin

上面拍错看日志，很原始。刀耕火种，加入利器 zipkin。

zipkin是twitter开源的分布式跟踪系统。

原理收集系统的时序数据，从而追踪微服务架构中系统延时等问题。还有一个友好的界面。

由4个部分组成：

Collector、Storage、Restful API、Web UI组成

采集器，存储器，接口，UI。

原理：

sleuth收集跟踪信息通过http请求发送给zipkin server，zipkin将跟踪信息存储，以及提供RESTful API接口，zipkin ui通过调用api进行数据展示。

默认内存存储，可以用mysql，ES等存储。

操作步骤：

每个需要监听的服务的pom中添加。

<!-- zipkin -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

每个需要监听的服务yml中

spring:
  #zipkin
  zipkin:
    base-url: http://localhost:9411/
    #采样比例1
  sleuth:
    sampler:
      rate: 1

启动zipkin。

jar包下载：curl -sSL https://zipkin.io/quickstart.sh | bash -s
我放到了 目录：C:\github\online-taxi-demo  下面。


java -jar zipkin.jar

或者docker：
docker run -d -p 9411:9411 openzipkin/zipkin

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=31766

赞同 0

评论 0 条