微服务12:流量策略

服务,流量,策略 · 浏览次数 : 715

小编点评

**★微服务系列微服务1:微服务及其演进史** **★价值和必要性★** **价值驱动:** * 支持蓝绿发布 * 提高服务整体的 SLA * 实现所有业务 分级发布、扩散发布的能力 **业务视角:** * 实现所有业务 分级发布、扩散发布的能力 * 降低早期为实现灰度而做多服务的资源损耗 **流量调控** * 金丝雀发布、ABTesting 是流量调度中典型的场景 * 流量染色流量染色也是一种典型的场景 **流量管理策略** * **金丝雀发布**:使用 Istio 在流量中携带一些特征进行路由匹配,转发到相应的版本上 * **流量染色**:根据用户群体的特征,将流量分配到不同的版本上 **结论** 微服务系列微服务提供了一些技术来实现对微服务的流量的管理,包括金丝雀发布、ABTesting、分级扩散流量和流量染色等策略。这些策略可以确保微服务的稳定性以及流量的多样化。

正文

★微服务系列

微服务1:微服务及其演进史
微服务2:微服务全景架构
微服务3:微服务拆分策略
微服务4:服务注册与发现
微服务5:服务注册与发现(实践篇)
微服务6:通信之网关
微服务7:通信之RPC
微服务8:通信之RPC实践篇(附源码)
微服务9:服务治理来保证高可用
微服务10:系统服务熔断、限流
微服务11:熔断、降级的Hystrix实现(附源码)

1 微服务的基本流量策略

微服务提供了一些技术来实现对微服务的流量的管理,其中最典型的就是对流量进行拆分和转发。
具体体现在金丝雀发布(灰度发布)、ABTesting 以及流量染色 等策略方案上,下面会进行详细的介绍。

2 价值和必要性

★ 价值驱动:

  • 支持蓝绿发布、金丝雀发布,无需停服也能保证发布的无缝衔接,提高了服务整体的SLA。
  • 全链路的ABTesting,保证不同特征类型的用户可以在独立的链路通道上测试、使用、实验、生产。
  • 大幅降低早期为实现灰度而做多服务的资源(时间、服务器资源)损耗。

★ 业务视角:

  • 实现所有业务 分级发布、扩散发布的能力,保证发布的渐序性。比如上线一个新功能,首先在小范围发布,观察一段时间之后在全量发布。
  • 染色实验的各种场景,让不同类型的用户体验不同类型的功能。
  • 实现多环境场景的降本增效:无需再对不同环境的服务独立部署,从维护和资源上来说,大大降低了成本。

3 流量调控

3.1 金丝雀发布、ABTesting

image
这是流量调度中典型的金丝雀场景,可以先放行一部分流量转发到一个新的服务实例中,这个新的服务实例只有你的研发和测试团队可以接入。可以在上面尝试使用或者测试,直到你确认你的服务是健康的,功能完整的,没有bug的,再把流量逐渐的引流过去。
这个的好处是减少发布新功能存在的风险,而且全程是无停服发布,对用户是透明无感知的,大大提高了可用性,提升服务SLA

3.2 流量染色

image
流量染色也是一种典型的场景。如果你想让不同的用户群体(比如这边的Group A、Group B、Group C)使用的功能也是不同的,那流量染色是一个不可缺少的功能。
它可以把符合某些特征的用户流量调控到对应的服务版本中。比如GroupA是学生群体,对应到V1版本,GroupB是政企员工群体,对应到V2版本。需要注意的是,如果是一条完整的链路,那链路上的各个服务包括数据存储层都应该有不同的版本,这样才能一一对应。

3.3 染色实现方案(以ServiceMesh为例子)

Mesh如果想要实现流量染色,需要具备以下几个条件:

  1. 请求的流量中,需要附带某些特征,如流量的请求的Header、Cookies、queryParams等 中带有某些信息。
Request Header:
UserId: 135648468
Dep: T204351
X-Request-Id: ee6637e816d7470bb2e90e13e1130733
  1. 部署在kubernetes上的服务(svc)的实例(pod)需要接入Mesh(如Istio),并在pod上打上版本标签。
labels:
    app: traffic-test
    appName: traffic-test
    appType: java
    istio.io/rev: default
    pod-template-hash: 78ab8776a9
    security.istio.io/tlsMode: istio
    service.istio.io/canonical-revision: v1
    version: v1  #  在具体的 pod 中 label 上 v1 的 version 标签
  1. 下发Istio的策略到kubernetes对应服务服务上:当请求的流量带有某些特征(如header中带有Dep=SO)时,流量路由到对应标签(如 version = v1 )的服务实例上。
  spec:
    exportTo:
    - '*'
    host: xxx.com
    subsets:
    - labels:   #  这是v1 版本
        version: v1
      name: v1
      trafficPolicy:
        loadBalancer:
          simple: ROUND_ROBIN
    - labels:  # 这是default
        version: default
      name: default
  1. header中符合带Dep=T204351的走v1版本,不符合条件的路由则默认走到默认版本中(如 version = default)。

所以,Mesh的染色本质上是通过在流量中携带一些特征(如流量的请求的Header、Cookies、queryParams等),而Mesh会根据这些请求的特征进行路由匹配,转发到对应的带有某些特征的服务实例上。
未匹配成功的流量则走到默认版本中,从而实现多个版本和跟默认版本的业务隔离的目标。
image
上面的图,当部门编号为 T204351的时候,流量会转发到服务的v1版本中;当部门编号为 T204352的时候,流量会转发到服务的v2版本中;剩余的流量,默认转发到服务的default版本中。

4 总结

丰富的流量管理策略为我们系统的稳定性,以及流量的多样化(金丝雀发布、ABTesting、分级扩散流量、流量染色)使用提供了保证。

与微服务12:流量策略相似的内容:

微服务12:流量策略

★微服务系列 微服务1:微服务及其演进史 微服务2:微服务全景架构 微服务3:微服务拆分策略 微服务4:服务注册与发现 微服务5:服务注册与发现(实践篇) 微服务6:通信之网关 微服务7:通信之RPC 微服务8:通信之RPC实践篇(附源码) 微服务9:服务治理来保证高可用 微服务10:系统服务熔断、

微服务使用openfeign调用单点的会话失效问题

# 项目Springcloud,认证中心方式实现SSO使用开源框架Sa-Token >本身的单独访问每个客户端服务的单点就没有问题。然后单点通过Fegin调用就不好使了! ##### 主要使用的Sa-Token的微服务单点功能 ##### 使用的依赖如下 ```xml cn.dev33 sa-tok

[转帖]十二要素应用宣言(12-Factor App)

https://www.jianshu.com/p/d08cba7349dc 从摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》这本书上得知十二要素应用宣言,网上搜索从infoQ搬迁至此。 十二要素应用宣言英文版,对应中文版。 简介 如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或“软件

[转帖]Skywalking介绍

https://www.jianshu.com/p/ffa7ddcda4ab 微服务架构已经是一个很通用的系统架构,常见的技术栈如下图所示,这张架构图基本涵括了当前微服务体系下的各种技术栈,可能不同的技术栈有不同的开源实现。 Screen Shot 2022-01-23 at 12.48.19 PM

[转帖]Skywalking介绍

https://www.jianshu.com/p/ffa7ddcda4ab 微服务架构已经是一个很通用的系统架构,常见的技术栈如下图所示,这张架构图基本涵括了当前微服务体系下的各种技术栈,可能不同的技术栈有不同的开源实现。 Screen Shot 2022-01-23 at 12.48.19 PM

SpringCloud-Config配置中心搭建保姆级教程

一、分布式配置中⼼ 在使⽤微服务架构开发的项⽬中,每个服务都有⾃⼰的配置⽂件(application.yml),如果将每个服务的配置⽂件直接写在对应的服务中,存在以下问题: 1. 服务开发完成之后,需要打包部署,配置⽂件也会打包在jar⽂件中,不便于项⽬部署之后的配置修改(在源码中修改——重新打包—

如何实现简单的分布式链路功能?

为什么需要链路跟踪 为什么需要链路跟踪?微服务环境下,服务之间相互调用,可能存在 A->B->C->D->C 这种复杂的服务交互,那么需要一种方法可以将一次请求链路完整记录下来,否则排查问题不好下手、请求日志也无法完整串起来。 如何实现链路跟踪 假设我们从用户请求接口开始,每次请求需要有唯一的请求

[转帖]微服务集成skywalking实现全链路日志追踪方案

目录 1、安装部署skywalking 1.1 环境准备 1.2 部署步骤 2、微服务整合skywalking实现链路监控 2.1 下载skywalking官方版本 2.2 将微服务引入skywalking监控 2.3 以上配置完成后启动服务即可实现链路监控 3、通过logback+ELFK实现全链

微服务架构必备技术栈:万变不离其宗的奥义!

前言 之前我们说过,微服务是一种软件设计、架构思想。当然,里面也包含了相关技术点要解决当前要务。学习微服务,我们不能空口而谈,一定要落实到具体的技术栈上。 当今使用比较多两个技术体系,一个是Java,另外一个就是Net。 废话不多说,今天我就把相关“微服务架构”所用到的技术栈罗列出来。(以下是微软相

微服务新体验之Aspire初体验

安装aspire 查看vs版本 我这的版本是17.9.7,不支持aspire,所以需要升级 更新VS 点击 帮助->检查更新 点击更新 静等安装升级 创建aspire项目 项目创建成功,如下图 运行Aspire项目 在AspireApp1.AppHost的launchSettings.json文件中