- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
微服务1:微服务及其演进史 微服务2:微服务全景架构 微服务3:微服务拆分策略 微服务4:服务注册与发现 微服务5:服务注册与发现(实践篇) 微服务6:通信之网关 微服务7:通信之RPC 微服务8:通信之RPC实践篇(附源码) 微服务9:服务治理来保证高可用 微服务10:系统服务熔断、限流 微服务11:熔断、降级的Hystrix实现(附源码) 微服务12:流量策略 。
微服务提供了一些技术来实现对微服务的流量的管理,其中最典型的就是对流量进行拆分和转发。 具体体现在金丝雀发布(灰度发布)、ABTesting 以及流量染色 等策略方案上.
云原生基础场景下,如果想要实现流控和调度,需要具备以下几个条件:
所以,流控调度的本质上是通过在流量中携带一些特征(如流量的请求的Header、Cookies、queryParams等),而Mesh会根据这些请求的特征进行路由匹配,转发到对应的带有某些特征的服务实例上。 未匹配成功的流量则走到默认版本或者给定的具体版本中,从而实现多个版本和跟默认版本的业务隔离的目标。这种模式下,实现 灰度发布、ABTesting 以及流量染色 都是很方便的.
这边以Istio 实现的 Service-Mesh为案例 。
基于上述的策略模型,如果你想配置如下:请求的header 带有 username = brand 或者 departname = hr 的时候,将流量转发到服务的v1版本,否着转发到default版本。 则策略代码如下:
# 说明:VirtualService 流量染色,根据不同的条件将流量发往不同特征的版本中,假设这边有default、v1、v2 版本
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: test-service1-vs
spec:
hosts:
- test-service1 # 治理发往test-service1服务的流量
exportTo:
- "."
http: # 加各种路由条件,比如匹配人员、部门进行路由
- match # 用户匹配 brand,部门匹配 hr 部门时
- headers:
username:
exact: brand
- headers:
departname:
exact: hr
route:
destination:
# todo 匹配条件的流量路由到对应的服务上......
- route:
- destination:
# todo 不匹配条件的流量路由到对应的服务上......
云原生基础平台上的服务遵循如下层级结构,namespace对标应用,svc对标服务.
假设你给你的服务配置了多个版本,比如你发布了default(默认版本)、v1版本。 检查kubernetes的信息会发现,service保持不变,这个命名为testsvc-admin-default的服务下,对应两个deployment,两个pod.
root@xxxxxxxxxxxxxx:~# kubectl -n testsvc-debug get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
testsvc-admin-429mvh 1/1 1 1 18m
testsvc-admin-default 1/1 1 1 142m
root@xxxxxxxxxxxxxx:~# kubectl -n testsvc-debug get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
testsvc-admin-default ClusterIP 172.100.110.220 <none> 80/TCP 142m
root@xxxxxxxxxxxxxx:~# kubectl -n testsvc-debug get pods
NAME READY STATUS RESTARTS AGE
testsvc-admin-429mvh-5b567969b4-nq4zp 2/2 Running 0 17m
testsvc-admin-default-85467f8f79-xzfgz 2/2 Running 0 23m
看看两个deployment的信息对比,labels中的app属性一致,version属性不一致。所以,服务按照同一个app寻址,不同的version进行流量shift的方式进行.
root@xxxxxxxxxxxxxx:~# kubectl -n testsvc-debug get deployment testsvc-admin-default -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "2"
creationTimestamp: "2022-01-14T06:40:22Z"
generation: 2
labels:
app: testsvc-admin-default
appName: testsvc-admin
appType: java
projectName: testsvc-debug
version: default
workspaceName: SPACE_BASIC_SERVE
name: testsvc-admin-default
namespace: testsvc-debug
resourceVersion: "335716111"
uid: 7531a9b3-53eb-475d-ae0b-75df957badb9
root@xxxxxxxxxxxxxx:~# kubectl -n testsvc-debug get deployment testsvc-admin-429mvh -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2022-01-14T08:45:03Z"
generation: 1
labels:
app: testsvc-admin-default
appName: testsvc-admin
appType: java
projectName: testsvc-debug
version: 429mvh
workspaceName: SPACE_BASIC_SERVE
name: testsvc-admin-429mvh
namespace: testsvc-debug
resourceVersion: "335719639"
uid: 85c0e1f2-b56d-4afc-8c51-ccb887e420b6
现在,envoy的流转规则有了,服务的特征也有了,完整策略匹配代码如下:
# 说明:VirtualService 流量染色,根据不同的条件将流量发往不同特征的版本中,假设这边有default、v1、v2 版本
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: test-svc-vs
spec:
hosts:
- test-svc # 治理发往test-svc服务的流量
exportTo:
- "."
http: # 加各种路由条件,比如匹配人员、部门进行路由
- match # 用户匹配 brand,部门匹配 hr 人事部时
- headers:
username:
exact: brand
- headers:
departname:
exact: hr
route:
destination:
host: test-svc
subset: v1 # 匹配条件的流量路由到对应的服务的v1版本上
- route:
- destination:
host: test-svc # 剩余的流量走到default版本上
subset: default
规则下发之后,envoy存储在本地,当流量出去的时候,outbound 那边会做一个判断。 如果是header中带上 username = brand 或者 departname = hr ,流量转发到带有v1 标签的pod中, 否则流量转发到带有default标签的pod中.
丰富的流量管理策略为我们系统的稳定性,以及流量的多样化(金丝雀发布、ABTesting、分级扩散流量、流量染色)使用提供了保证.
最后此篇关于微服务13:云基础场景下流量策略实现原理的文章就讲到这里了,如果你想了解更多关于微服务13:云基础场景下流量策略实现原理的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
就目前情况而言,这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持,但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放,visit
我计划使用 python 开发一个 Web/云应用程序,它执行以下操作, 1.上传Perl/Python抓取脚本并执行。 2. 上传脚本以按计划运行。 3. 使用不同的输入参数运行同一脚本的多个实例。
我正在开发一个应用程序,我想实现一个功能,可以在相同的用户设备之间共享,比方说,收藏夹、书签等。所以,我想实现类似 iCloud 的东西。 我想到了 2 个可能的想法:Backup Manager 和
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持,但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开,visit the
我正在尝试从一系列短语中使一个单词云成为一个词云,而不是从单个单词中重复很多短语。我的数据看起来像这样,数据框的一列是短语列表。 df$names <- c("John", "John", "Jose
对于配置AWS服务(EC2/R53/VPC/S3/..),Terraform等技术在执行回滚、错误处理等方面的方法不可靠。 AWS CloudFormation 模板解决了这些问题。 CloudFor
我无法使用我的 Azure 帐户执行任何操作,例如创建服务器或数据库或任何操作。看起来这一切都围绕着我无法创建的资源组>我收到此错误: 这特别困难,因为我什至无法使用云外壳,因为我得到了这个:请求 C
是否有在客户端使用 socket.io 的云/托管推送系统?据我所知,没有一个系统使用 socket.io AFAIK: http://beaconpush.com/ http://pusher.co
有没有办法在我的计算机上本地运行 RStudio,但使用运行 R 作为引擎的远程计算机而不是本地 R 安装? 需要明确的是,我知道可以将 RStudio 服务器与 Web GUI 一起使用,但我问的是
我正在寻找在这种情况下可以使用的合适服务: 在视频模式下打开相机并将其流式传输到 azure 云。 并从另一方聆听(也包括客户)。 我读到了有关 Azure 媒体服务的信息。 但根据this我知道客户
这个问题已经有答案了: 已关闭12 年前。 Possible Duplicate: Google App Engine, getting started 如何将 Java 应用程序部署到 Google
我有一个用 Java 7 编写的相当大的控制台应用程序,它管理大量的订单处理。 该应用程序使用大量订单 Web 服务、与数据库交互并将数据插入 ERP 系统。该应用程序的要求没有指定用户交互,因此在项
我已经阅读过有关 Windows Azure 的内容,但为了深入了解这项技术,我(显然)需要使用它。我有一个小型 ASP.NET 网站,流量很少,我认为在 Azure 上托管该网站会节省我的钱。除此之
我的 Activity 中有 3 个编辑文本(姓名、手机号码、职业)和一个按钮(保存)。每次用户单击按钮时,我都想将这三个数据保存到 Parse-cloud。然后新 Activity 在 imagev
我正在尝试通过node.js 将传感器数据发送到artik cloud。 (使用网络套接字和串行端口)。但它发送空。有人知道原因吗?我刚刚复制了教程中的代码,因此没有语法错误。 var webSock
我对 docker hub 和 docker cloud 有一点困惑。我有需要安装在客户端服务器中并运行容器的 docker 镜像。我相信这可以使用 docker hub 来完成,它允许在我的私有(p
晋城,华夏文化发祥地之一。两万年前留下高都遗址、塔水河、下川等人类遗址,女娲补天、愚公移山等神话传说,如今在云上有了崭新的魅力。 9月3日,阿里云数字中国行•晋城峰会期间,晋城市人民政府公布了
我刚开始使用 Airflow 插件,有点困惑。 我在 GCP (composer-1.13.4-airflow-1.10.12) 上使用 Cloud Composer 作为托管服务运行它 我按照文档编
据我所知,PHP 分析工具 XDebug 将其结果保存到文件中。然而,当应用程序运行在云分布式环境中时,处理此类文件是很困难的。处理这种情况的最佳做法是什么? XDebug 中是否有任何方法(最好是可
我们正在将 PHP 网站迁移到 Azure 云 Web 服务(Web 角色)。 目前,该网站通过驱动器盘符访问将用户提交的图像文件保存到文件系统。然后通过 URL 提供这些图像,例如content.e
我是一名优秀的程序员,十分优秀!