这个task描述弹性应用的熔断能力。熔断允许开发人员编写应用程序,以限制故障,延迟尖峰,网络特性造成的其他不良影响。这个task将展示如何为连接,请求,异常值检测配置熔断。

Before you begin

  • 安装Istio
  • 启动 httpbin 示例,并将它作为我们task的后端服务。
kubectl apply -f <(istioctl kube-inject --debug -f samples/httpbin/httpbin.yaml)

Circuit breaker

让我们建立一个方案来描述Istio的熔断能力。我们应该在之前部分运行过 httpbin 服务。我们想要确认我们设置的一些路由规则将所有流量路由到 version=v1httpbin 。我们通过创建一个Istio destination policy 来设置熔断,但是为了destination policies生效,这首先需要一个针对destination 的路由规则。现在我们来创建一个路由规则:

Creating circuit breaking policies

1.创建一个默认路由规则,路由所有流量到我们的 httpbin 服务的 v1 版本:

istioctl create -f samples/httpbin/routerules/httpbin-v1.yaml

2.当调用httpbin 服务时,为指定我们的熔断设置,需要创建一个 destination policy

cat <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1beta1
kind: DestinationPolicy
metadata:name: httpbin-circuit-breaker
spec:destination:name: httpbinlabels:version: v1circuitBreaker:simpleCb:maxConnections: 1httpMaxPendingRequests: 1sleepWindow: 3mhttpDetectionInterval: 1shttpMaxEjectionPercent: 100httpConsecutiveErrors: 1httpMaxRequestsPerConnection: 1
EOF

3.验证我们刚创建的 destination policy 的正确性:

istioctl get destinationpolicy
NAME                    KIND                                            NAMESPACE
httpbin-circuit-breaker DestinationPolicy.v1alpha2.config.istio.io      istio-samples
Setting up our client

现在我们为调用 httpbin 服务已经创建了规则,现在让我们创建一个客户端来给我们的服务发送流量,并观察我们是否可以实现熔断。我们将使用一个荷载测试客户端 fortio 。用这个客户端,我们可以控制连接数,并发和外部HTTP调用的延迟。在这步,我们创建了一个注入了Istio sidecar proxy的客户端,这样我们的网络交互由Istio管理:

kubectl apply -f <(istioctl kube-inject --debug -f samples/httpbin/sample-client/fortio-deploy.yaml)

现在我们应该能够进入到客户端pod中,使用示例fortio 工具去调用 httpbin. 我们会通过-curl来表明我们只想进行一次调用:

FORTIO_POD=$(kubectl get pod | grep fortio | awk '{ print $1 }')
kubectl exec -it $FORTIO_POD  -c fortio /usr/local/bin/fortio -- load -curl  http://httpbin:8000/get
HTTP/1.1 200 OK
server: envoy
date: Tue, 16 Jan 2018 23:47:00 GMT
content-type: application/json
access-control-allow-origin: *
access-control-allow-credentials: true
content-length: 445
x-envoy-upstream-service-time: 36
{"args": {}, "headers": {"Content-Length": "0", "Host": "httpbin:8000", "User-Agent": "istio/fortio-0.6.2", "X-B3-Sampled": "1", "X-B3-Spanid": "824fbd828d809bf4", "X-B3-Traceid": "824fbd828d809bf4", "X-Ot-Span-Context": "824fbd828d809bf4;824fbd828d809bf4;0000000000000000", "X-Request-Id": "1ad2de20-806e-9622-949a-bd1d9735a3f4"}, "origin": "127.0.0.1", "url": "http://httpbin:8000/get"
}

你可以看到请求成功了!现在,让我们干点坏事~

Tripping the circuit breaker:

在熔断设置中,我们指定了 maxConnections: 1httpMaxPendingRequests: 1. 这些意味着如果我们同时超过一个连接和请求,我们应该能看到istio-proxy为进一步请求/连接而开启电路。让我们尝试同时2个连接 (-c 2)并发送20个请求 (-n 20)

kubectl exec -it $FORTIO_POD  -c fortio /usr/local/bin/fortio -- load -c 2 -qps 0 -n 20 -loglevel Warning http://httpbin:8000/get
Fortio 0.6.2 running at 0 queries per second, 2->2 procs, for 5s: http://httpbin:8000/get
Starting at max qps with 2 thread(s) [gomax 2] for exactly 20 calls (10 per thread + 0)
23:51:10 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
Ended after 106.474079ms : 20 calls. qps=187.84
Aggregated Function Time : count 20 avg 0.010215375 +/- 0.003604 min 0.005172024 max 0.019434859 sum 0.204307492
# range, mid point, percentile, count
>= 0.00517202 <= 0.006 , 0.00558601 , 5.00, 1
> 0.006 <= 0.007 , 0.0065 , 20.00, 3
> 0.007 <= 0.008 , 0.0075 , 30.00, 2
> 0.008 <= 0.009 , 0.0085 , 40.00, 2
> 0.009 <= 0.01 , 0.0095 , 60.00, 4
> 0.01 <= 0.011 , 0.0105 , 70.00, 2
> 0.011 <= 0.012 , 0.0115 , 75.00, 1
> 0.012 <= 0.014 , 0.013 , 90.00, 3
> 0.016 <= 0.018 , 0.017 , 95.00, 1
> 0.018 <= 0.0194349 , 0.0187174 , 100.00, 1
# target 50% 0.0095
# target 75% 0.012
# target 99% 0.0191479
# target 99.9% 0.0194062
Code 200 : 19 (95.0 %)
Code 503 : 1 (5.0 %)
Response Header Sizes : count 20 avg 218.85 +/- 50.21 min 0 max 231 sum 4377
Response Body/Total Sizes : count 20 avg 652.45 +/- 99.9 min 217 max 676 sum 13049
All done 20 calls (plus 0 warmup) 10.215 ms avg, 187.8 qps

我们看到几乎所有请求都通过了!

Code 200 : 19 (95.0 %)
Code 503 : 1 (5.0 %)

istio-proxy允许有一些偏差。让我们把同时连接数升到3:

kubectl exec -it $FORTIO_POD  -c fortio /usr/local/bin/fortio -- load -c 3 -qps 0 -n 20 -loglevel Warning http://httpbin:8000/get
Fortio 0.6.2 running at 0 queries per second, 2->2 procs, for 5s: http://httpbin:8000/get
Starting at max qps with 3 thread(s) [gomax 2] for exactly 30 calls (10 per thread + 0)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
Ended after 71.05365ms : 30 calls. qps=422.22
Aggregated Function Time : count 30 avg 0.0053360199 +/- 0.004219 min 0.000487853 max 0.018906468 sum 0.160080597
# range, mid point, percentile, count
>= 0.000487853 <= 0.001 , 0.000743926 , 10.00, 3
> 0.001 <= 0.002 , 0.0015 , 30.00, 6
> 0.002 <= 0.003 , 0.0025 , 33.33, 1
> 0.003 <= 0.004 , 0.0035 , 40.00, 2
> 0.004 <= 0.005 , 0.0045 , 46.67, 2
> 0.005 <= 0.006 , 0.0055 , 60.00, 4
> 0.006 <= 0.007 , 0.0065 , 73.33, 4
> 0.007 <= 0.008 , 0.0075 , 80.00, 2
> 0.008 <= 0.009 , 0.0085 , 86.67, 2
> 0.009 <= 0.01 , 0.0095 , 93.33, 2
> 0.014 <= 0.016 , 0.015 , 96.67, 1
> 0.018 <= 0.0189065 , 0.0184532 , 100.00, 1
# target 50% 0.00525
# target 75% 0.00725
# target 99% 0.0186345
# target 99.9% 0.0188793
Code 200 : 19 (63.3 %)
Code 503 : 11 (36.7 %)
Response Header Sizes : count 30 avg 145.73333 +/- 110.9 min 0 max 231 sum 4372
Response Body/Total Sizes : count 30 avg 507.13333 +/- 220.8 min 217 max 676 sum 15214
All done 30 calls (plus 0 warmup) 5.336 ms avg, 422.2 qps

现在我们开始看到熔断按照我们的预期开始行动。

Code 200 : 19 (63.3 %)
Code 503 : 11 (36.7 %)

仅有 63.3% 的请求通过,剩下的被熔断捕获。我们可以通过查看istio-proxy的状态获取更多信息:

kubectl exec -it $FORTIO_POD  -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep httpbin | grep pending
cluster.out.httpbin.springistio.svc.cluster.local|http|version=v1.upstream_rq_pending_active: 0
cluster.out.httpbin.springistio.svc.cluster.local|http|version=v1.upstream_rq_pending_failure_eject: 0
cluster.out.httpbin.springistio.svc.cluster.local|http|version=v1.upstream_rq_pending_overflow: 12
cluster.out.httpbin.springistio.svc.cluster.local|http|version=v1.upstream_rq_pending_total: 39

我们看到 upstream_rq_pending_overflow 的值是12,这意味着目前为止熔断器被调用了12次。

Cleaning up

  • 移除规则。
istioctl delete routerule httpbin-default-v1
istioctl delete destinationpolicy httpbin-circuit-breaker
  • 关闭 httpbin 服务端和客户端。
kubectl delete deploy httpbin fortio-deploy
kubectl delete svc httpbin

Circuit Breaking相关推荐

  1. hic染色体构想_了解微服务:从构想到起点

    hic染色体构想 by Michael Douglass 迈克尔·道格拉斯(Michael Douglass) 了解微服务:从构想到起点 (Understanding Microservices: F ...

  2. 译 | 缓存穿透问题导致Facebook史上最严重事故之一

    点击关注公众号,Java干货及时送达 How a Cache Stampede Caused One of Facebook's Biggest Outages 2010年9月23,这个世界上最大的社 ...

  3. resilience4j小试牛刀

    为什么80%的码农都做不了架构师?>>>    序 本文主要研究下resilience4j的基本功能 maven <dependency><groupId>i ...

  4. Uber将整体式API拆分为微服务

    Uber工程师Emily Reinhold最近介绍了他们是如何将整体式API拆分为灵活的模块化微服务体系结构的.她重点介绍了在Uber的迁移工作中,设计和体系结构方面几个最重要的考虑. \\ 根据 R ...

  5. Spring Cloud、K8S、Netflix OSS三者啥关系???

    Netflix OSS是一组框架和库,Netflix为大规模解决一些有趣的分布式系统问题而编写的.今天,对于Java开发人员来说,它非常适合云环境中开发微服务.服务发现.负载平衡.容错等模式对于可扩展 ...

  6. Spring Cloud 加盟重量级成员Spring Cloud Alibaba,打造更符合中国国情的微服务体系...

    本周,Spring Cloud联合创始人Spencer Gibb在Spring官网的博客页面宣布:阿里巴巴开源 Spring Cloud Alibaba,并发布了首个预览版本.随后,Spring Cl ...

  7. Resilience4j-轻量级熔断框架

    Resilience4j 简介 Resilience4j是一款轻量级,易于使用的容错库,其灵感来自于Netflix Hystrix,但是专为Java 8和函数式编程而设计.轻量级,因为库只使用了Vav ...

  8. 使用熔断器设计模式保护软件

    作为软件开发人员,我们的生活是快节奏的,我们采用的是敏捷软件开发方法,迭代式的开发我们软件功能,开发完成提交测试,通过了QA的测试后被部署到生产环境,然后可怕的事情在生产环境里发生了,生产环境的压力超 ...

  9. 阿里巴巴开源 Spring Cloud Alibaba,加码微服务生态建设

    转载自  阿里巴巴开源 Spring Cloud Alibaba,加码微服务生态建设 本周,Spring Cloud联合创始人Spencer Gibb在Spring官网的博客页面宣布:阿里巴巴开源 S ...

最新文章

  1. 操作系统学习:进程、线程与Linux0.12初始化过程概述
  2. linux find命令通配,Linux Find 命令的详解与研究
  3. 1.2.3 TCP/IP参考模型和五层参考模型
  4. python 自动化-Python 接口自动化测试
  5. Spring Cloud Alibaba - 08 Ribbon 两种方式实现细粒度自定义配置控制微服务的负载均衡策略
  6. R 语言开发环境搭建
  7. MongoDB常用操作命令
  8. Koa -- 基于 Node.js 平台的下一代 web 开发框架
  9. python编程求极限_Sympy笔记一
  10. 【转】JAVA错误:The public type *** must be defined in its own file***
  11. Windows消息目录-消息大全
  12. 机器人新车号牌安装_他指挥机器人给新车“穿衣” 分分钟搞定
  13. Milogs客户销售工作日志软件系统简介
  14. 服务器电脑安装Centos7操作系统
  15. Gmail(Google App企业邮箱)的MX设置
  16. 学习python的感受
  17. HTTP GET 请求在请求体中带参数的问题
  18. Android学习之管理Activity的生命周期
  19. Java数据结构---hashMap
  20. Day17 什么是静态成员类?为什么静态成员类优于非静态成员类?

热门文章

  1. 桌面创建html文件路径,html本地图片路径
  2. ReactOS - debug
  3. Axure 点图片外区域即隐藏_免费彻底隐藏任意文件目录工具(真正的底层隐藏)...
  4. eclipse 国内下载镜像地址
  5. HTML5中设置自适应设备头的各个参数及意义
  6. 形状类族的中的纯虚函数
  7. 【iOS开发系列】地图与定位
  8. can总线不加末端电阻_高手写的CAN总线入门总结
  9. internal 和 external
  10. 盘点那些高考失利却仍然成功在各行各业的人