本篇文章是笔者流量治理的第一篇文章,笔者希望在这里系统的讲解下这些年以来对流量和流量治理的理解,希望对读者有所帮助,也希望读者能够及时指正文章中笔者理解不对的地方。 本篇文章笔者会从下面几点来介绍流量治理。 问题一:流量治理是什么? 问题二:为什么需要流量治理? 问题三:如何进行流量治理? 一、流量治理是什么 流量治理:顾名思义流量治理就是针对流量就行治理,这里面有两个关键字,流量和治理。 三、如何流量治理 笔者根据对流量治理的程度将流量治理划分成了三个层级去治理: 层级一:提供稳定和准确的流量转发功能。 5.具备灵活调配流量转发的能力。 对于流量的转发需要通过配置修改就可以立马生效,当中不需要重启服务。
通过什么方式进行流量治理 一、Istio服务模型 服务(Service)与版本(Version):Istio中的服务在kubernetes中以service形式存在,可定义不同的服务版本。 二、Istio流量治理 治理原理 通过Isito中VirtualService、DestinationRule、ServiceEntry等配置实现流量治理,即Istio将流量配置通过xDS下发给Enovy ,通过拦截Inbound和Outbound流量,在流量经过时执行规则,实现流量治理。 通常流量治理有:动态变更负载均衡策略、不同版本灰度发布、服务治理限流熔断和故障注入演练等。 概念说明 1.VirtualService 含义:形式上为虚拟服务,将流量转发到对应的后端服务。 ;网格外流量配置关联的Gateway表示执行该规则;网格内外都需要访问:需要配置Gateway和mesh两个字段 http 用于处理HTTP流量 tls 用于处理非终结的TLS和HTTPS流量 tcp
本篇文章就是来整理和讲解istio中的流量治理功能,更准确的说是介绍envoy的治理功能,流量治理的常见场景,如下图所示,本文主要对这些场景做一个详细的介绍: ? 1. 一般来说系统的吞吐量是可以被测算的,为了保证系统的稳定运行,一旦达到的需要限制的阈值,就需要限制流量并采取一些措施以完成限制流量的目的。比如:延迟处理,拒绝处理,或者部分拒绝处理等等。 异常检测的类型: 1.连续5XX响应:上游主机连续返回一定数量的5XX响应,该主机就会被驱逐。 istio中的策略: 灰度发布只是流量染色的一种典型应用场景,对与istio来说只需要简单的进行一些路由规则配置就可以。 ? 配置: ? 5. 外部注入服务治理 概念: 在业务变得很复杂之后,内部服务已经不能够满足需求,此刻我们就需要外部的服务来提供支撑,而这个外部接入的服务也是需要进行管理和维护的。
上一篇,笔者概括介绍了一下对于流量治理的三板斧操作;本篇文章笔者主要来介绍下流量的常见特点,所谓知己知彼百战百胜,我们只有了解了流量的特点,特别是他们存在的挑战,我们才能更好的治理流量。 针对流量而言,长期的流量不均,流量的响应延迟过高,瞬时的流量过大,以及流量本身内容的不安全,是我们平时治理流量的时候,不得不面对的问题,并且这些问题往往会对我们的产品产生很大的影响和冲击。 如果上述几种负载均衡策略还是不能满足你的流量需求,特别是流量中夹杂着某一类耗时很久的特殊流量的情况,这就需要构建流量反馈机制,让负载均衡和后端服务进行配合,通过反馈机制做自适应调节,对负载均衡进行实时调节来达到目的 当然也可以在业务服务上面实现降级,例如:流量优先级丢弃策略,在流量超过限制之后,选择性丢掉一些优先级不高的流量。 3.瞬时流量过大问题 这类问题,首先要识别流量特征,是可以丢弃的,还是不可以丢弃的。 如果上报流量的客户端也是自己开发的话,可以做个闭环设计,在客户端做下流量过滤和聚合来减少无效流量的上报,不过这种玩法取决于对客户端的定位。
基于Librados的流量治理方案 1 需求背景&现状 需要自己实现一套类似RGW的对象存储服务,解耦元数据存储到独立的数据库服务(如TiDB),同时提供跨Ceph集群的数据读写能力,实现横向扩展和跨集群级别的容灾 数据请求的跨集群路由 整个系统的数据写入会分布在不同的Ceph集群,因此需要在入口侧进行数据流量的按集群拆分。
root@worker ~]# curl helloworld.sample.svc:5000/helloHello version: v2, instance: helloworld-v2-54df5f84b-tts2z root@worker ~]# curl helloworld.sample.svc:5000/helloHello version: v1, instance: helloworld-v1-776f57d5f6 app: test 在vm上启动一个http server python3 -m http.server 80 测试 kubectl exec -it helloworld-v1-776f57d5f6 test.test.svc.cluster.localDefaulting container name to helloworld.Use 'kubectl describe pod/helloworld-v1-776f57d5f6
这家公司是典型的中台战略践行者,两年间从5个服务拆到了68个。技术团队很骄傲:"我们微服务做得很彻底。" 这是朴素而正确的思路,但它只解决了寻址问题,治理问题一个没解决。1.2流量治理逻辑侵入业务代码超时重试、熔断降级、限流——这些逻辑被开发团队写进了业务代码。 关键配置——声明式流量策略(零业务代码侵入):展开代码语言:YAMLAI代码解释#库存服务的流量治理策略#一个YAML,替代每个服务里200行SDK代码apiVersion:policy.linkerd.io 18分钟灰度发布耗时2周4小时业务代码中治理逻辑占比~35%<5%服务间mTLS加密❌无✅全量老板那边的反应:大促前三天,老板说要给VIP开快车道。 P1统一Nginx/Kong南北向治理接入层标准化3周P2引入Linkerd东西向治理服务间治理,核心攻坚2月P2建设黄金指标监控体系可观测性基础1月P3建设OpenAPI规约契约库OPC时代的基础设施持续
一句话总结Istio流量治理的目标:以基础设施的方式提供给用户非侵入的流量治理能力,用户只需关注自己的业务逻辑开发,无须关注服务访问管理。 Istio流量治理的概要流程如图1所示: 图1 Istio流量治理的概要流程 在控制面会经过如下流程: (1)管理员通过命令行或者API创建流量规则; (2)Pilot将流量规则转换为Envoy的标准格式 在数据面会经过如下流程: (1)Envoy拦截Pod上本地容器的Inbound流量和Outbound流量; (2)在流量经过Envoy时执行对应的流量规则,对流量进行治理。 负载均衡 下面具体看看Istio提供了流量治理中的负载均衡功能。 图5 Kubernetes的负载均衡 本篇内容节选及改编自《云原生服务网格Istio:原理、实战、架构与源码解析》
istio-system NAME READY STATUS RESTARTS AGE istio-egressgateway-5c8d96c9b5 v2 版本会调用 ratings 服务,并使用 1 到 5 个黑色星形图标来显示评分信息。 v3 版本会调用 ratings 服务,并使用 1 到 5 个红色星形图标来显示评分信息。 AGE grafana-f766d6c97-4888w 1/1 Running 0 3m57s istio-egressgateway-5c8d96c9b5 61m jaeger-7f78b6fb65-bj8pm 1/1 Running 0 3m56s kiali-85c8cdd5b5 -b5zv4 1/1 Running 0 3m55s prometheus-54b5dcf6bf-wjkpl 3/
SentinelSentinel 面向分布式、多语言异构化服务架构的流量治理组件。替换 Spring Cloud CircuitBreaker。 Sentinel 实现了从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助保障微服务稳定性。 我们在 Sentinel 页面中,点击熔断规则-新增熔断规则,并进行配置资源名:/testA熔断策略:慢调用比例最大RT:200比例阈值:0.1熔断时长:5(s)最小请求数:5统计时长:1000(ms) 例如上述图内表示当 1s 内的调用数多于 5 个时,触发熔断规则。熔断状态的判断依据:在统计时长内,实际请求数 > 设定的最小请求数且实际慢调用比例 > 比例阈值,进入熔断状态。测试过程参考流控。 @SentinelResource 注解SentinelResource 是一个流量防卫组件的注解,用于防护指定资源,对配置的资源进行流量控制、熔断降级等功能。
5.商机溯源的成果 接下来看一下商机溯源的成果。 4.治理的目标与措施 再来看治理的目标与措施。 我们分析低质量商机发现了有很多类型,这里主要列举几个非常典型的类型: 第一类是黑产类的商机。这种商机一般都会说拉着经纪人去做一些流量类型的活动。 5总结与展望 最后总结一下,我们主要提到了四个方面的内容 贝壳的商机概念,不同阶段的诉求 商机回收服务的架构,面临的挑战与采取的措施 商机溯源的背景、方案、成果 商机治理的背景,无效商机的分类与概念, 治理方案与处置措施 后续我们还有很多的探索规划: 展望一:探索在流量分发场景中的应用。 目前主要负责贝壳商机数据回收、治理、流量溯源等方面工作。曾毕业并就职于华北计算技术研究所,参与过某军工信息系统建设;后加入阿里集团,工作相关代表产品包括 UC 浏览器、学习强国等。
本篇文章是笔者对流量治理治理思路的总结,在这里笔者把它们称为流量治理的“三板斧”,这里笔者只是阐述下个大概,算是先给它们做个介绍,后续会详细讲解每一部分。 对于流量治理来说,笔者觉得一定要从三个方面来着手,他们分别是:“看得见”,“摸得着”,“管得住”。 ,才能发现流量的热点,瓶颈,才能更好的进行治理,当然用户也可以看到流量的价值,进而进行数据挖掘,在运营面做写文章进而产生价值。 二、摸得着 “摸得着”,指的是治理的人工交互能力,特别在流量出现异常或者不可控的时候,我们能够有办法与产品进行交互。而产品也具有这种交互能力,可以按照用户的意愿采取对应的措施,进行流量的治理。 三、管得住 “管得住”,指的是流量治理的实际规则,这里针对两种类型的流量,一种是正常流量,一种是异常流量。
OpenSergo 是开放通用的,覆盖微服务及上下游关联组件的微服务治理项目,从微服务的角度出发,涵盖流量治理、服务容错与自愈、服务元信息治理、安全治理等关键治理领域,提供一系列的治理能力与标准、生态适配与最佳实践 OpenSergo 涵盖的微服务治理关键领域: 流量治理与服务容错:流量路由、流量染色、全链路灰度、流量防护与自愈(流量控制、服务熔断、容错防抖) 微服务视角的数据库与缓存治理:端侧连接池治理、读写流量路由 Sentinel 底层基于精心设计的高性能毫秒级滑动窗口统计结构来实现百万 QPS 流量的精确统计,结合上层各个流量治理策略模块的组合来实现对不同维度的流量进行治理,同时支持灵活的扩展定制机制。 Sentinel 2.0 品牌将升级为流量治理,并作为 OpenSergo 流量治理的标准实现。 5 展望 流量防护与容错是微服务流量治理中的重要的一环,同时 OpenSergo 还提供更广范围、更多场景的微服务治理标准与最佳实践,包括流量路由、流量染色、微服务视角的数据库治理、日志治理等一系列的微服务治理能力与场景
如何确认哪些治理规则需要对当前流量生效? 在服务网格中,sidecar 的职责当然不只是简单的流量转发了,更重要的是流量观察及流量治理。所以,获取到了流量原始目标 IP 和端口之后,直接转发出去显然不是网格想要的,必须进行更进一步的治理。 这就是第二个问题了,如何使治理规则生效,又有哪些治理规则需要对当前流量生效呢? 答案其实就在第1小节中。 请求头,如 Dubbo 请求中 interface)识别流量的目标服务并应用治理规则。 本文以尽可能浅显的概念来说明服务网格中流量治理的实现原理与多协议嗅探机制要解决的问题。希望能够让读者对于服务网格流量治理和协议嗅探能有一个基本认知。
在这里对于安全层面也存在一些规范要求,包括两地三中心的治理和针对中间件数据业务的隔离,对流量治理和安全性的要求相对是比较严格的。 场景痛点与需求 考虑到真实使用场景,每家公司对于流量治理的层次和需求其实也各不相同。 比如有些公司可能相对来讲更希望网关更前置,仅作为边缘网关角色,有些可能希望网关能够处理南北流量或者是东西、南北流量共同治理。 下图展示的是在流量治理过程中的逻辑部署,主要涉及流量网关、微服务网关、统一运营网关、BaaS 网关和域网关。 希望在后续的落地实践中,众安保险可以基于 Apache APISIX 实现整体流量治理的完整落地,助力互联网保险领域的流量管控与安全治理。
本章是作为服务治理的番外篇讲述,对注册中心的另一种实现方案探讨。也为接下来讲述SPI做好铺垫。 那么本章是基于redis作为存储中间件,实现服务治理,也就是图片中的第1,2,3步,思路跟zookeeper实现方式一致,存储结构也大致相同。使用redis的list类型。 本节涉及博客中代码的module,farpc-registry(服务治理),这章对IRegistrar进行了修改,将init()沉在AbstractRegistrar,在AbstractRegistrar
第3章 非侵入的流量治理 通过对本章的学习,可基于Istio的这些配置在不修改代码的情况下实现各种流量治理 ---- 3.1 Istio流量治理的原理 流量治理是一个非常宽泛的话题 动态修改服务间访问的负载均衡策略 只要应用运行在Istio的基础设施上,就可以使用这些治理能力 一句话总结 Istio 流量治理的目标:以基础设施的方式提供给用户非侵入的流量治理能力,用户只需关注自己的业务逻辑开发,无须关注服务访问管理 基于Istio的灰度发布 Istio本身并没有关于灰度发布的规则定义,灰度发布只是流量治理规则的一种典型应用,在进行灰度发布时,只要写个简单的流量规则配置即可 ? ? ---- 3.2 Istio路由规则配置:VirtualService VirtualService是Istio流量治理的一个核心配置,可以说是Istio流量治理中最重要、最复杂的规则 3.2.1 路由规则配置示例 5.端口流量策略设置(PortTrafficPolicy) 只要了解在端口上定义的流量策略会覆盖全局的流量策略即可 ? ?
无论是项目重构,还是新项目的开发,即使项目初期没有多大的流量,但从长远考虑,企业也基本会优先使用微服务架构。 服务降级、限流、熔断、流量效果控制 Sentinel的特性 Sentinel性能压测 第2章 了解概念与核心 类 本章开始探索Sentinel。 基于滑动窗口实现资源指标数据统计 资源指标数据统计全解析 第5章 限流 限流一般指的是按QPS/T hreads限流,除QPSThreads限流外,还有热点参数限流、集群限流。 本章主要分析Sentinel限流功能的实现原理及几种流量效果控制器的实现原理。 热点参数限流功能的实现 流量效果控制 第12章 集群限流 由于请求倾斜的存在,分发到集群中每个节点上的流量不可能是均匀的,因此单机限流无法实现精确地限制整个集群的整体流量,从而造成在总流量没有达到阈值的情况下一些机器就开始限流
第5章 流量管理 ---- 流量管理中的规则配置 要控制流量,就需要定义一些规则。Istio中定义了一个简单的配置模型,可以很方便地进行规则的配置。 根据不同的版本对服务流量进行拆分是常用的功能。在Istio中服务版本依靠标签进行区分,可以定义不同种类的标签(如版本号、平台),对流量以不同的维度进行灵活的分配。拆分流量使用weight关键字来设置。 如下面的配置,把75%的流量分配给v1版本的reviews服务,25%的流量分配给v2版本 ? 上面的配置中出现了subset(子集)关键字。 在下面的例子中我们注入了一个延迟故障,使得ratings服务10%的响应会出现5s的延迟。 需要做的就是制定 路由规则,将流量转移到v2版本上 定义DestinationRule 定义VirtualService设置路由,将流量指向v1版本 定义VirtualService,将流量切换到v2版本
背景 应用微服务化场景下,随着服务个数的增加,服务之间的相互调用变得更加复杂,服务治理需求愈加突出,其中服务流量控制是服务治理中的重要一环。 UAVStack作为一套智能化服务技术栈,其服务治理(UAV.ServiceGovern)模块提供了基于画像的服务注册与发现、服务访问授权及服务流量控制能力。 图1限流模型 UAV服务治理流量控制采用上图所示的漏斗+能力池限流模型。将应用根据UAV画像抽象出三层,分别是应用层(应用实例层)、服务组件层和URL层。 二、关键技术 2.1 MOF中间件劫持 MOF(MonitorFramework)中间件劫持为UAV服务治理中流量控制提供基础支撑。 图5 应用吞吐量测试 从图5中可以看出,对比原生和安装UAV无限流情况,UAV限流对应用的吞吐量影响比较小,基本可以忽略不计。