美文网首页
模块十一_SpringCloud组件设计原理(下)

模块十一_SpringCloud组件设计原理(下)

作者: 西西弗斯XD | 来源:发表于2020-11-10 19:44 被阅读0次

    序言:

    文章内容输出来源:拉勾教育Java高薪训练营。
    本篇文章是学习课程中的一部分课后笔记

    一、分布式链路追踪技术

    1、 场景描述

    使⽤微服务架构设计我们的系统,使得我们的系统不仅能够通过集群部署抵挡流量的冲击,⼜能根据业务进⾏灵活的扩展。
    那么,在微服务架构下,⼀次请求少则经过三四次服务调⽤完成,多则跨越⼏⼗个甚⾄是上百个服务节点。那么问题接踵⽽来:

    1. 如何动态展示服务的调⽤链路?(⽐如A服务调⽤了哪些其他的服务---依赖关系)
    2. 如何分析服务调⽤链路中的瓶颈节点并对其进⾏调优?(⽐如A—>B—>C,C服务处理时间特别⻓)
    3. 如何快速进⾏服务链路的故障发现?

    这就是分布式链路追踪技术存在的⽬的和意义。

    2、市场上的分布式链路追踪⽅案
    • Spring Cloud Sleuth + Twitter Zipkin
    • 阿⾥巴巴的“鹰眼”
    • ⼤众点评的“CAT”
    • 美团的“Mtrace”
    • 京东的“Hydra”
    • 新浪的“Watchman”
    • Apache Skywalking
    3、分布式链路追踪技术核⼼思想
    • 本质:记录⽇志,作为⼀个完整的技术,针对请求处理的调⽤链可以展现为⼀棵树。
    trace.png
    • ⼀个Trace由⼀个或者多个Span组成,每⼀个Span都有⼀个SpanId,Span中会记录TraceId,同时还有⼀个叫做ParentId,指向了另外⼀个Span的SpanId,表明⽗⼦关系,其实本质表达了依赖关系。

    • Span可以认为是⼀个⽇志数据结构,在⼀些特殊的时机点会记录了⼀些⽇志信息,⽐如有时间戳、spanId、TraceId,parentIde等,Span中也抽象出了另外⼀个概念,叫做事件,核⼼事件如下:

      • CS :client send/start 客户端/消费者发出⼀个请求,描述的是⼀个span开始 ;
      • SR: server received/start 服务端/⽣产者接收请求 SR-CS属于 请求发送的⽹络延迟;
      • SS: server send/finish 服务端/⽣产者发送应答 SS-SR属于服务端消耗时间 ;
      • CR:client received/finished 客户端/消费者接收应答 CR-SS表示回复需要的时间(响应的⽹络延迟) ;

    二、 Sleuth + Zipkin 简介

    1、Spring Cloud Sleuth
    • 耗时分析:通过 Sleuth 了解采样请求的耗时,分析服务性能问题(哪些服务调⽤⽐较耗时)

    • 链路优化:发现频繁调⽤的服务,针对性优化等Sleuth就是通过记录⽇志的⽅式来记录踪迹数据的

    • 注意:往往把Spring Cloud Sleuth 和 Zipkin ⼀起使⽤,把 Sleuth 的数据信息发送给 Zipkin 进⾏聚合,利⽤ Zipkin 存储并展示数据。

    zipkin.png

    三、微服务统⼀认证⽅案 Spring Cloud OAuth2+ JWT

    1、OAuth2介绍

    OAuth(开放授权)是⼀个开放协议/标准,允许⽤户授权第三⽅应⽤访问他们存储
    在另外的服务提供者上的信息,⽽不需要将⽤户名和密码提供给第三⽅应⽤或分享
    他们数据的所有内容。(第三方qq,微信登陆)

    oauth2.png
    2、OAuth2的颁发Token授权⽅式
    • 授权码(authorization-code)授权码模式使⽤到了回调地址,是最复杂的授权⽅式,微博、微信、QQ等第三⽅登录就是这种模式。
    • 密码式(password)提供⽤户名+密码换取token令牌
    • 隐藏式(implicit)
    • 客户端凭证(client credentials)
    3、Spring Cloud OAuth2介绍
    • Spring Cloud OAuth2 是 Spring Cloud 体系对OAuth2协议的实现,可以⽤来做多个微服务的统⼀认证(验证身份合法性)授权(验证权限)。
    • OAuth2解决问题的本质是 :
      引⼊了⼀个认证授权层,认证授权层连接了资源的拥有者,在授权层⾥⾯,资源的拥有者可以给第三⽅应⽤授权去访问我们的某些受保护资源。
    认证服务.png
    4、JWT令牌介绍
    • 当资源服务和授权服务不在⼀起时,资源服务使⽤RemoteTokenServices 远程请求授权 服务验证token,如果访问量较⼤将会影响系统的性能。

    • 解决上边问题: 令牌采⽤JWT格式即可解决上边的问题,⽤户认证通过会得到⼀个JWT令牌,JWT令牌中已经包括了⽤户相关的信 息,客户端只需要携带JWT访问资源服务,资源服务根据事先约定的算法⾃⾏完成令牌校验,⽆需每次都请求认证服务完成授权。

    5、什么是JWT?
    • JSON Web Token(JWT)是⼀个开放的⾏业标准(RFC 7519),它定义了⼀种简介的、⾃包含的协议格式,⽤于 在通信双⽅传递json对象,传递的信息经过数字签名可以被验证和信任。JWT可以使⽤HMAC算法或使⽤RSA的公 钥/私钥对来签名,防⽌被篡改。
    6、JWT令牌结构

    JWT令牌由三部分组成,每部分中间使⽤点(.)分隔,⽐如:xxxxx.yyyyy.zzzzz

    • 1、Header
      头部包括令牌的类型(即JWT)及使⽤的哈希算法(如HMAC SHA256或
      RSA):
    {
     "alg": "HS256",
     "typ": "JWT"
    }
    

    将上边的内容使⽤Base64Url编码,得到⼀个字符串就是JWT令牌的第⼀部分。

    • 2、Payload
      第⼆部分是负载,内容也是⼀个json对象,它是存放有效信息的地⽅,它可以存
      放jwt提供的现成字段,⽐ 如:iss(签发者),exp(过期时间戳), sub(⾯向的
      ⽤户)等,也可⾃定义字段。
      此部分不建议存放敏感信息,因为此部分可以解码还原原始内容。
    {
     "sub": "1234567890",
     "name": "John Doe",
     "iat": 1516239022
    }
    
    

    最后将负载使⽤Base64Url编码,得到⼀个字符串就是JWT令牌的第⼆部分。

    • 3、Signature
      第三部分是签名,此部分⽤于防⽌jwt内容被篡改。 这个部分使⽤base64url将
      前两部分进⾏编码,编码后使⽤点(.)连接组成字符串,最后使⽤header中声
      明 签名算法进⾏签名。
    HMACSHA256(
     base64UrlEncode(header) + "." +
     base64UrlEncode(payload),
     secret)
    

    base64UrlEncode(header):jwt令牌的第⼀部分。
    base64UrlEncode(payload):jwt令牌的第⼆部分。
    secret:签名所使⽤的密钥。

    四、Nacos 服务注册和配置中⼼

    1、 Nacos简介

    Nacos (Dynamic Naming and Configuration Service)是阿⾥巴巴开源的⼀个针
    对微服务架构中服务发现、配置管理和服务管理平台。
    Nacos就是注册中⼼+配置中⼼的组合(Nacos=Eureka+Config+Bus)

    2、 Nacos功能特性
    • 服务发现与健康检查
    • 动态配置管理
    • 动态DNS服务
    • 服务和元数据管理(管理平台的⻆度,nacos也有⼀个ui⻚⾯,可以看到注册的服务及其实例信息(元数据信息)等),动态的服务权重调整、动态服务优雅下线
    3、 保护阈值
    • 可以设置为0-1之间的浮点数,它其实是⼀个⽐例值(当前服务健康实例
      数/当前服务总实例数)
    • 保护阈值的意义
      当服务A健康实例数/总实例数 < 保护阈值 的时候,说明健康实例真的不多了,这个
      时候保护阈值会被触发(状态true);
      nacos将会把该服务所有的实例信息(健康的+不健康的)全部提供给消费者,消费
      者可能访问到不健康的实例,请求失败,但这样也⽐造成雪崩要好,牺牲了⼀些请
      求,保证了整个系统的⼀个可⽤。
    4、 Nacos 数据模型(领域模型)
    数据模型.png
    数据模型解析.png

    五、 SCA Sentinel 分布式系统的流量防卫兵

    1、Sentinel介绍
    • Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。
      替代Hystrix,针对问题:服务雪崩、服务降级、服务熔断、服务限流
    • Hystrix:
      服务消费者—>调⽤服务提供者(在调⽤⽅引⼊Hystrix—> 单独搞了⼀个Dashboard项⽬—>Turbine
      1)⾃⼰搭建监控平台 dashboard;
      2)没有提供UI界⾯进⾏服务熔断、服务降级等配置(⽽是写代码,⼊侵了我们源程
      序环境);
    • Sentinel:
      1)独⽴可部署Dashboard/控制台组件;
      2)减少代码开发,通过UI界⾯配置即可完成细粒度控制;


      对比.png
    2、Sentinel 分为两个部分:
    • 核⼼库:(Java 客户端)不依赖任何框架/库,能够运⾏于所有 Java 运⾏时环
      境,同时对 Dubbo / Spring Cloud 等框架也有较好的⽀持。
    • 控制台:(Dashboard)基于 Spring Boot 开发,打包后可以直接运⾏,不需
      要额外的 Tomcat 等应⽤容器。
    3、Sentinel 特征
    • 丰富的应⽤场景:
      Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。
    • 完备的实时监控:
      Sentinel 同时提供实时的监控功能,可以在控制台中看到接⼊应⽤的单台机器秒级数据,甚⾄ 500 台以下规模的集群的汇总运⾏情况。
    • ⼴泛的开源⽣态:
      Sentinel 提供开箱即⽤的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊ Sentinel。
    • 完善的 SPI 扩展点:
      Sentinel 提供简单易⽤、完善的 SPI 扩展接⼝,可以通过实现扩展接⼝来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
    4、Sentinel 的主要特性
    特性.png

    相关文章

      网友评论

          本文标题:模块十一_SpringCloud组件设计原理(下)

          本文链接:https://www.haomeiwen.com/subject/sskjbktx.html