Go微服务架构实战 中篇：6. 微服务治理策略
Go微服务架构实战-【公粽号：堆栈future】
Go微服务架构实战目录
1. 微服务架构上篇
1. grpc技术介绍
2. grpc+protobuf+网关实战
3. etcd技术介绍
4. 基于etcd的服务发现与注册
5. 基于etcd的分布式锁实战
2. 微服务架构中篇
1. k8s架构介绍
2. 基于k8s的容器化部署
3. 基于k8s的Deployment工作负载
4. 基于k8s的ingress实战
5. 基于ingress和service实现灰度发布
6. 常见的服务治理策略
干货：
服务容错: 故障转移/快速失败/故障恢复等
流量控制：滑动时间窗口/令牌桶/分布式限流等
1. 服务容错
通过一张图一目了然：
容错设计模式：
1. 断路器模式
断路器的基本思路是很简单的，就是通过代理（断路器对象）来一对一地（一个远程服务对应一个断路器对象）接管服务调用者的远程请求。断路器会持续监控并统计服务返回的成功、失败、超时、拒绝等各种结果，当出现故障（失败、超时、拒绝）的次数达到断路器的阈值时，它状态就自动变为“OPEN”，后续此断路器代理的远程访问都将直接返回调用失败，而不会发出真正的远程服务请求。通过断路器对远程服务的熔断，避免因持续的失败或拒绝而消耗资源，因持续的超时而堆积请求，最终的目的就是避免雪崩效应的出现。由此可见，断路器本质是一种快速失败策略的实现方式，它的工作过程可以通过下面图来表示：
从调用序列来看，断路器就是一种有限状态机，断路器模式就是根据自身状态变化自动调整代理请求策略的过程。一般要设置以下三种断路器的状态：
CLOSED：表示断路器关闭，此时的远程请求会真正发送给服务提供者。断路器刚刚建立时默认处于这种状态，此后将持续监视远程请求的数量和执行结果，决定是否要进入 OPEN 状态。
OPEN：表示断路器开启，此时不会进行远程请求，直接给服务调用者返回调用失败的信息，以实现快速失败策略。
HALF OPEN：这是一种中间状态。断路器必须带有自动的故障恢复能力，当进入 OPEN 状态一段时间以后，将“自动”（一般是由下一次请求而不是计时器触发的，所以这里自动带引号）切换到 HALF OPEN 状态。该状态下，会放行一次远程调用，然后根据这次调用的结果成功与否，转换为 CLOSED 或者 OPEN 状态，以实现断路器的弹性恢复。
这些状态的转换逻辑与条件如下图所示：
OPEN 和 CLOSED 状态的含义是十分清晰的，与我们日常生活中电路的断路器并没有什么差别，值得讨论的是这两者的转换条件是什么？最简单直接的方案是只要遇到一次调用失败，那就默认以后所有的调用都会接着失败，断路器直接进入 OPEN 状态，但这样做的效果是很差的，虽然避免了故障扩散和请求堆积，却使得外部看来系统将表现极其不稳定。现实中，比较可行的办法是在以下两个条件同时满足时，断路器状态转变为 OPEN：
一段时间（譬如 10 秒以内）内请求数量达到一定阈值（譬如 20 个请求）。这个条件的意思是如果请求本身就很少，那就用不着断路器介入。
一段时间（譬如 10 秒以内）内请求的故障率（发生失败、超时、拒绝的统计比例）到达一定阈值（譬如 50%）。这个条件的意思是如果请求本身都能正确返回，也用不着断路器介入。
以上两个条件同时满足时，断路器就会转变为 OPEN 状态。
断路器做的事情是自动进行服务熔断，这是一种快速失败的容错策略的实现方法，也是一种典型的服务降级策略。举个例子：你女朋友被前男友约出去了，你打她手机没人接，你气冲冲地的挂断后（快速失败），然后你有打了另外三个你女朋友闺蜜的手机号（故障转移），都还是没能找到你女朋友（重试超过阈值）。这时候你非常生气地在微信上给她留言“三分钟不回电话就分手”，以此来与你取得联系。原谅我这么举例，虽然不太吉利，但是你给你女朋友留言这个行为便是服务降级逻辑。
其他服务治理的工具，譬如Envoy、istio等也同样会包含有类似的设置。
2. 重试模式
重试模式适合解决系统中的瞬时故障，简单的说就是有可能自己恢复（Resilient，称为自愈，也叫做回弹性）的临时性失灵，网络抖动、服务的临时过载（典型的如返回了 503 Bad Gateway 错误）这些都属于瞬时故障。重试模式实现并不困难，即使完全不考虑框架的支持，靠程序员自己编写十几行代码也能够完成。在实践中，重试模式面临的风险反而大多来源于太过简单而导致的滥用。我们判断是否应该且是否能够对一个服务进行重试时，应同时满足以下几个前提条件：
仅在主路逻辑的关键服务上进行同步的重试，不是关键的服务，一般不把重试作为首选容错方案，尤其不该进行同步重试。
仅对具备幂等性的服务进行重试。
重试必须有明确的终止条件，常用的终止条件有两种：
超时终止
次数终止
由于重试模式可以在网络链路的多个环节中去实现，比如客户端发起调用时自动重试，网关中自动重试、负载均衡器中自动重试，等等，而且现在的微服务框架都足够便捷，只需设置一两个开关参数就可以开启对某个服务甚至全部服务的重试机制。
2. 流量控制
与容错模式类似，对于如何进行限流，也有一些常见的设计模式可以参考使用，本节将介绍滑动时间窗、令牌桶以及分布式限流三种限流设计模式。
1. 滑动时间窗口
有一个滑动时间窗口算法，在计算机科学的很多领域中都有成功的应用，比如著名的TCP协议的流量控制等都是使用这个算法实现流控的。具体实现大概可以想象下就是在不断向前流淌的时间轴上，漂浮着一个固定大小的窗口，窗口与时间一起平滑地向前滚动。任何时刻静态地通过窗口内观察到的信息，都等价于一段长度与窗口大小相等、动态流动中时间片段的信息。由于窗口观察的目标都是时间轴，所以它被称为形象地称为“滑动时间窗模式”。
滑动时间窗口模式可以保证任意时间片段内，只需经过简单的调用计数比较，就能控制住请求次数一定不会超过限流的阈值，在单机限流或者分布式服务单点网关中的限流中很常用。不过，这种限流也有其缺点，它通常只适用于否决式限流，超过阈值的流量就必须强制失败或降级，很难进行阻塞等待处理，也就很难在细粒度上对流量曲线进行整形，起不到削峰填谷的作用。
2. 令牌桶
假设我们要限制系统在 X 秒内最大请求次数不超过 Y，那就每间隔 X/Y 时间就往桶中放一个令牌，当有请求进来时，首先要从桶中取得一个准入的令牌，然后才能进入系统处理。任何时候，一旦请求进入桶中却发现没有令牌可取了，就应该马上失败或进入服务降级逻辑。与此同时令牌桶也有最大容量限制，这意味着当系统比较空闲时，桶中令牌累积到一定程度就不再无限增加，预存在桶中的令牌便是请求最大缓冲的余量。上面这段话，可以转化为以下步骤：
让系统以一个由限流目标决定的速率向桶中注入令牌，比如要控制系统的访问不超过 100 次，速率即设定为 1/100=10 毫秒。
桶中最多可以存放 N 个令牌，N 的具体数量是由超时时间和服务处理能力共同决定的。如果桶已满，第 N+1 个进入的令牌会被丢弃掉。
请求到时先从桶中取走 1 个令牌，如果桶已空就进入降级逻辑。
桶：bucket 速率：rate
令牌桶模式的实现看似比较复杂，每间隔固定时间就要放新的令牌到桶中，但其实并不需要真的用一个专用线程或者定时器来做这件事情，只要在令牌中增加一个时间戳记录，每次获取令牌前，比较一下时间戳与当前时间，就可以轻易计算出这段时间需要放多少令牌进去，然后一次性放入即可，所以真正编码并不会显得很复杂。
3. 分布式限流
一种常见的简单分布式限流方法是将所有服务的统计结果都存入集中式缓存（如 Redis）中，以实现在集群内的共享，并通过分布式锁、信号量等机制，解决这些数据的读写访问时并发控制的问题。在可以共享统计数据的前提下，原本用于单机的限流模式理论上也是可以应用于分布式环境中的，可是其代价也显而易见：每次服务调用都必须要额外增加一次网络开销，所以这种方法的效率肯定是不高的，流量压力大时，限流本身反倒会显著降低系统的处理能力。
anyway，出现问题解决它就好了，但是你不能因为它一两个缺点就不用，我觉得这不是一个程序员良好的做事风格，能扛事的人一般都是能成大事的人。
3. 小结
服务治理的话题随便拿出一个来研究就能让你增长不少见识，所以说大家下去有时间可以专门研究下相关的服务或者产品，比如我们提到的envoy以及istio等，看下它们是如何做到全部或者部分治理的，博采众长，才能脱胎换骨，加油。
公粽号：堆栈future
使很多处于迷茫阶段的coder能从这里找到光明，堆栈创世，功在当代，利在千秋
Go微服务架构实战 中篇：6. 微服务治理策略相关推荐
- Go微服务架构实战-中篇 1. k8s架构介绍
Go微服务架构实战-公粽号:[堆栈future] 本系列文章主要是针对云原生领域微服务架构的实战,包括网关,k8s,etcd以及grpc等相关技术的应用,同时也会把服务发现与注册,熔断,降级,限流以及 ...
- python 微服务架构实战_《分布式服务架构：原理、设计与实战》第一章分布式微服务架构设计原理...
1.从传统单体架构到服务化架构 1.1 JEE架构 JEE将企业级软件架构分为三个层级 : Web 层.业务逻辑层和数据存取层.对应的职能团队,主要包括:用户 交互 UI 团队.后台业务逻辑处理团 队 ...
- 微服务架构实战第八节 微服务安全框架，认证与授权
25 服务安全:如何理解微服务访问的安全需求和实现方案? 今天,我们又将进入一个全新的话题,讨论微服务架构中的服务访问安全性相关的需求和实现方案.在设计微服务架构时,安全性是一个重要但又往往被忽略的主 ...
- Spring Cloud与Docker微服务架构实战 PDF版 内含目录
Spring Cloud与Docker微服务架构实战 目录 1 微服务架构概述 1 1.1 单体应用架构存在的问题1 1.2 如何解决单体应用架构存在的问题3 1.3 什么是微服务3 1.4 微服务 ...
- SpringCloud与Docker微服务架构实战pdf
下载地址:网盘下载 作为一部帮助大家实现微服务架构落地的作品,<Spring Cloud与Docker微服务架构实战>覆盖了微服务理论.微服务开发框架(Spring Cloud)以及运行平 ...
- 【福利】赠书：Spring Cloud与Docker微服务架构实战（第2版）
本次福利送出好友周立的第二版书籍! 正在关注和使用Spring Cloud的朋友们不要错过哦! 内容提要 <Spring Cloud与Docker微服务架构实战(第2版)>基于Spring ...
- 《Spring Cloud与Docker微服务架构实战》配套代码
不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将 ...
- Serverless化微服务架构实战
简介:企业如何通过Serverless技术,降低微服务应用的资源成本?本次直播为您深入剖析阿里云Serverless化微服务架构实战经验. 直播议题名称: Serverless化微服务架构实战 讲师简 ...
- 微服务 前台调用后台的慢的原因_20年IT农民工分享SpringCloud微服务架构实战文档...
前言 越来越多的企业使用 SpringCloud 实现微服务架构设计.我们可以看到这样一种现象:不管是全新开发,还是系统重构,大家似乎都在争先恐后地使用微服务.对于一个Java开发人员来说,学习微服务 ...
最新文章
- 有效感受野--Understanding the Effective Receptive Field in Deep Convolutional Neural Networks
- [导入]Asp.net 2.0 实现自定义Email格式有效性验证(示例代码下载)
- P3501-[POI2010]ANT-Antisymmetry【hash,二分答案】
- 基于Tablestore管理海量快递轨迹数据架构实现
- oracle package 函数,Oracle 存储过程procedure，函数function用法，以及package用法
- java编写一个框架_手把手教你写一个基于 RxJava 的扩展框架
- Chrome 成为互联网看门人？！
- python中函数的参数传递
- 【笔记】k-Nearest Neighbors（KNN/k近邻）原理
- linux命令查bin中所有变量名,Linux--文件查找命令
- [MDK]MDK通杀版注册机（更新最新的注册机，支持5.15, 5.16, 5.17,5.18，5.20，5.21， 5.22，5.23，5.24）
- HTML 下拉式菜单
- 2021 ICPC Asia EC网络预选赛I、II
- 关于小程序网易云音乐接口用户登录，繁忙问题
- 服务器上训练深度学习模型anaconda+cuda+cudnn+pycharm
- 麒麟V10下 安装打包程序
- python 成长笔记 序章
- 用迁移学习创造的通用语言模型ULMFiT，达到了文本分类的最佳水平
- JavaScript -- jQuery网页开发案例笔记
- vue指令模式 添加埋点
热门文章
- 小内存海量数据，找中位数： 只有2G内存，在10G数据量怎样找到中位数？
- Downloading https://ultralytics.com/assets/Arial.ttf to /data/..../.config/Ultralytics/Arial.ttf
- 快速学习Groovy
- 利用百度地图Android定位SDK获取经纬度
- 增量式编码器和绝对式编码器的介绍
- CSS反爬获取伪元素的值
- OpenFOAM学习笔记 案例1之Cavity（1）
- android配置参数详解,安卓手机CPU与GPU等配置参数含义详解【详细介绍】
- 【面试】计算机操作系统
- 如何让自己像打王者荣耀一样发了疯、拼了命、石乐志的学习？