微服务介绍

微服务

单体应用的问题

• 部署效率底下。单体应用代码增加，依赖的资源就会增加，部署的时间就会增加。
• 团队协作开发成本高。协同开发，会出现代码冲突、重复测试，效率低。
• 系统高可用性差。如果依赖的资源有问题，就会导致整个应用有问题。
• 线上发布变慢。规模变大，线上发布的实现就会增加。

微服务的特点

• 服务拆分力度更细。将一个大模块拆分为多个小模块，独立成为一个服务。
• 服务独立部署。每个服务遵循独立打包部署的准则。
• 服务独立维护。每个服务可以交给几个人开发、测试、发布和运维等。
• 服务治理能力要求高。服务数量增加，需要有服务治理平台，进行统一管理。

服务拆分方式

• 纵向拆分:从业务唯独拆分。关联紧密的业务拆分为一个微服务，功能相对独立的，拆分为一个微服务。
• 横向拆分:从公共且独立功能纬度拆分。将功能组件拆分出来。

服务化拆分的前置条件

• 服务如何定义:每个服务都运行在各自的进程之中，通过接口来进行通信。
• 服务如何发布和订阅:拆分为微服务之后，如何知道那个服务是提供者、消费者。
• 服务如何监控:要保证SLA，必须要对服务进行监控，能够及时发现问题，需要知道哪些是重要指标。
• 服务如何治理:服务之间依赖关系变服务，如何保证当前服务出现问题，其他的服务不受影响。
• 故障如何定位:系统出现问题，如何快速定位到问题的出处。

服务组件

服务描述

服务调用首先要解决的问题就是服务如何对外描述。常用的服务描述方式包括RESTful API、XML配置和IDL文件三种。

RESTful API使用http协议的服务描述。

XML配置方式多用RPC协议的服务描述，通过*.xml配置文件来定义接口名、参数以及返回值类型等。

IDL文件方式通常用作Thrift和gRPC这类跨语言服务框架中(thrift使用的是tcp，四层，grpc使用的是七层)。

RESTful API、XML、IDL的区别:

服务描述方式	使用场景	缺点
RESTful	跨语言平台，组织内外皆可	使用了HTTP作为通信协议，相比TCP协议，性能较差
XML配置	Java平台，一般用作组织内部	不支持跨语言平台
IDL文件	跨语言平台，组织内外平台皆可	修改或者删除PB字段不能向前兼容

如果企业内部之间的服务调用，并且都是Java语言的话，选择xml配置方式是最简单的。
如果企业内部存在多个服务，并且服务采用的是不通过语言平台，建议使用IDL文件方式进行描述服务。
如果还存在对外开放服务调用的情形的话，使用RESTful API方式更加通用。
例如：A项目使用Consul，对应RESTful；B项目使用dubbo，对应XML；C项目设计Java和Python服务之间调用，使用thrift，对应IDL文件。

注册中心

注册中心的工作流程是:

• 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
• 服务消费者在启动时，根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。
• 注册中心返回服务提供者地址列表给服务消费者。
• 当服务提供者发生变化，注册中心将变更通知给服务消费者。

服务框架

• 服务通信协议:四层TCP、UDP，还是7层HTTP协议
• 数据传输方式:同步/异步。
• 数据压缩格式:数据传输会对数据进行压缩，减少网络传输的数据量，例如JSON序列化、Java序列化和Protobuf序列化。

服务监控

服务监控主要包括三个流程:

• 指标收集:每次调用请求耗时以及成功与否收集起来，并传到集中的数据处理中心。
• 数据处理:计算QPS、请求平均耗时以及成功率等指标。
• 数据展示:将收到的指标进行处理之后，在页面上展示。

服务追踪

服务追踪工作原理:

• 服务消费者发起请求前，按照规则生成一个requestid，发起调用时，将requestid当作请求参数的一部分，传递给服务提供者。
• 服务提供者接收到请求后，记录这次请求的requestid，然后处理请求。如果需要调用其他服务，按照之前的流程走一遍。

服务治理

• 单机故障:系统规模大，出现故障机器比较多，人力需求量大，需要做到自动移除故障节点,保证服务正常。
• IDC故障:IDC之间可以切换流量。
• 依赖服务不可用。通过熔断方式，保证其他服务的正常使用。

如何注册和发现服务

注册中心原理

微服务架构下，主要有三种角色:服务提供者、服务消费者和服务注册中心。

• 服务提供者提供服务。在启动时，根据服务发布文件server.xml中的配置的信息，向Registry注册自身服务，并向Registry定期发送心跳汇报存活状态。
• 服务消费者调用服务。在启动时，根据服务引用文件client.xml中配置的信息，向Registry订阅服务，把Registry返回的服务节点缓存在本地内存中，并于服务提供者建立连接。
• 服务提供者节点发生变更时，Registry会同步变更，服务消费者感知后会刷新本地内存中的服务节点列表。
• 服务消费者从本地缓存的服务节点列表中，基于负载均衡算法选择一台服务提供者发起调用。

注册中心实现方式

注册中心API

注册中心必须提供的基础API:

• 服务注册接口: 服务提供者通过调用服务注册接口来完成服务注册。
• 服务反注册接口: 服务提供者通过调用服务翻注册接口来完成服务注销。
• 心跳汇报接口: 服务提供者通过调用心跳汇报接口完成节点存活状态上报。
• 服务订阅接口: 服务消费者通过调用服务订阅接口完成服务订阅，获取可用的服务提供者节点列表。
• 服务变更查询接口: 服务消费者通过调用服务变更查询接口，获取最新的可用服务节点列表。

集群部署

注册中心一般都是采用集群部署来表征高可用性，并通过分布式一致性协议来保证集群中不同节点之间的数据保持一致。

Zookeeper的工作原理:

• 每个Server在内存中存储一份数据，Client的读请求可以请求任意一个Server。
• Zookeeper启动时，将从实例中选举一个Leader(Paxos协议)。
• Leader负责处理数据更新等操作(ZAB协议)。
• 一个更新操作成功，当且仅当大多数Server在内存中成功修改。

目录存储

以Zookeeper为例，注册中心存储服务信息一般采用层次化的目录结构:

• 每个目录在Zookeeper中叫做znode,并且其有一个唯一的路径标识。
• znode可以包含数据和子znode。
• znode中的数据可以有多个版本。

服务健康状态检测

注册中心除了支持最基本的服务注册和服务订阅功能意外，还需要有健康状态检测功能。

以Zookeeper为例，基于Zookeeper客户端和服务端的长链接和会话超时控制机制，来实现服务健康状态检测的。
在Zookeeper中，客户端和服务端建立连接后，并生成一个全局唯一的SessionID。服务端和客户端维持的是一个长连接，
在SESSION_TIMEOUT周期内，通过发送心跳信息来检测链路是否正常，如果超过SESSION_TIMEOUT，服务端认为
这个Session结束，Zookeeper认为这个服务节点已经不可用，将会从注册中新删除其消息。

服务状态变更通知

注册中心感知到服务提供者节点的变化，立即通知所有订阅该服务的服务消费者，刷新本地缓存的服务节点，确保
服务调用不会请求不可用的服务提供者节点。

基于Zookeeper的Watcher机制，来实现服务状态变更通知给服务消费者。

白名单机制

注册中心提供保护机制，只有添加到注册中心白名单内的服务器，才能够调用注册中心的注册接口。

注册中心和DNS的比较

	注册中心	DNS
服务注册和发现	基于API，可以自动处理， 相对于DNS具有实时性、 容错性优势	人工注册
注册方式	http、rpc	只能注册http服务
健康检查	自动检测	没有
结构	一级分布式	多级架构

如何实现RPC远程服务调用

客户端和服务端如何建立网络连接

• HTTP通信(基于传输层TCP协议):三次握手、四次分手的过程。
• Socket通信(基于TCP/IP协议封装):
  • 服务监听(ServerSocket通过bind()方法来绑定端口，listen()实时监控网络状态，等待请求)。
  • 客户端请求(ClientSocket通过connect()方法向ServerSocket绑定的地址和端口发起请求)。
  • 服务端连接确认:ServerSocket监听到客户端的请求，调用accept()来相应客户端的请求，并建立连接。
  • 数据传输:ClientSocket调用send()函数，ServerSocket调用receive()函数，ServerSocket处理完成请求后，调用send()方法,ClientSocket调用receive()函数，可以得到的返回结果。
• 保活的方式:链路存活检测(发送ping请求，看是否可以正常返回);断连重试(断开之后，根据设置的时间进行重连)。

服务端如何处理请求

• 同步阻塞方式(BIO):按照顺序处理请求。适用于连接数比较少的业务场景。
• 同步非阻塞方式(NIO):把多个I/O的阻塞复用到同一个select的阻塞上，在不同的时间片内，处理不同的请求。开销少，不用为每一个请求创建一个线程。适用于连接数比较多且请求消耗比较轻的业务场景。
• 异步分阻塞方式(AIO):客户端无需等待，不存在阻塞等待问题。适用于连接数比较多且请求消耗比较重的业务场景。

在使用组件时，建议使用Netty。

选择序列化的方式

选择序列化时，主要考虑以下三个方面:

• 支持数据结构类型的丰富度。数据结构种类支持的越多越好。
• 跨语言支持。每个语言适用于不同的应用场景。
• 性能:主要看序列化后的压缩比和序列化的速度。

如何监控微服务调用

监控对象

• 用户端监控:指业务对用户提供的功能的监控。
• 接口监控:业务提供的功能所依赖的具体RPC接口的监控。
• 资源监控:某个接口资源的的监控。
• 基础监控:对服务器本身的健康状况的监控。

监控指标

• 请求量:分为实时请求量(QPS，每秒查询次数来衡量)和统计请求量(PV，一段时间内用户的访问量来衡量)。
• 响应时间:一段时间内所有调用的平均耗时来反映请求的响应时间。
• 错误率:一段时间内调用失败的次数占用总次数的比率来衡量。

监控维度

• 全局维度:从整体角度监控对象的请求量、平均耗时以及错误率。
• 分机房运维:不同机房地域的不同，同一监控对象的各种指标可能差异较大。
• 单机维度:不同年份的机器，指标也有一定差异。
• 时间维度:业务有高峰、也有低峰，时间不同，QPS不同。
• 核心维度:核心业务的维度。

监控系统原理

监控系统主要包括四个环节:1.数据采集、数据传输、数据处理和数据展示。

数据采集

• 服务主动上报:在业务代码或者服务框架加入数据收集代码逻辑，将信息上报。
• 代理收集:通过服务调用后把调用的详细信息记录到本地日志文件，然后通过代理解析本地日志文件，然后再上报服务的调用信息。

数据传输

数据传输最常用的方式有两种:

• UDP传输:数据采集后通过UDP协议与服务器建立连接，然后把数据发送出去。
• KafKa传输:数据采集后发送到指定的Topic，然后数据处理单元再订阅对应的Topic，就可以从Kafka消息队列中读取到对应的数据。

传输的数据格式常用的有:

• 二进制协议:常用的是PB对象，高压缩和高性能，可以减少传输带宽并且序列化和反序列化效率特别高。
• 文本协议:JSON字符串，可读性好。

数据处理

• 接口维度聚合:将实时收到的数据按照接口实时聚合在一起。
• 机器维度聚合:把实时收到的数据按照调用的节点维度聚合在一起。

将聚合后的数据存储在数据库中，一般选用的数据库分为两类:

• 索引数据库:以倒排索引的数据结构存储，需要查询的时候，按照索引来查询。
• 时序数据库:以时序序列的方式存储，查询的时候按照时序维度来查询。

数据展示

数据展示的图形多种多样:

• 曲线图:用来监控变化趋势。
• 饼状图:监控占比分布。
• 格子图:细粒度的监控。

如何追踪微服务调用

服务追踪的作用

• 优化系统瓶颈:记录一条链路上的耗时，能够快速定位整个系统的瓶颈。
• 优化链路调用:将一些服务调用替换掉或者减少服务调用。
• 生成拓扑结构:服务之间的相互依赖关系。
• 透明传输数据:服务之间数据的传递。

服务追踪系统原理

通过一个全局唯一的ID将分布在哥哥服务节点上的同一次请求串联起来，从而还原原由的调用关系，可以追踪系统问题、分析调用数据并统计分钟系统指标。

概念	含义
traceId	一次分布式调用的链路踪迹，不断传递下去
spanId	标识一次RPC调用在分布式请求中的位置
annotation	用于业务自定义买点数据
sampling	采样率

服务治理的手段有哪些

节点管理

• 注册中心主动摘除机制:如果超过一定时间，没有收到心跳信息，认为这个服务挂了，将这个服务的机器剔除。
• 服务消费者摘除机制:如果服务消费者调用服务提供者节点失败，就将这个节点从内存中保存的可用服务提供者列表中移除。

负载均衡

• 随机算法:从可用的节点中随机选取一个节点。
• 轮询算法:按照固定的权重，对可用服务节点进行轮询。
• 最少活跃调用算法:每次在选择服务节点时，根据内存里维护的连接数倒序排列，选择连接数最小的节点发起调用，也就是选择调用量最小的服务节点，性能理论上也是最优的。
• 一致性hash算法:相同参数的请求总是发到同一服务节点。

服务容错

• FailOver:失败自动切换。服务消费者调用失败或者超时后，自动从可用的服务节点列表中选择一个节点重启发起调用，也可以设置重试的次数。
  这种策略要求服务调用的操作必须是幂等的。
• FailBack:失败通知。服务消费者调用失败或者超时后，不在重试，根据失败原因决定后面的策略。
• FaileCache:失败缓存。服务消费者调用失败或者超时后，而一段时间后再次尝试发起调用。
• FailFast:快速失败。服务消费者调用失败后，不在重试。

开源服务注册中心如何选型

当下主流的服务注册与发现的解决方案，主要有两种:

• 应用内注册与发现:注册中心提供服务端和客户端的SDK，业务应用通过引用注册中心提供的SDK，痛殴SDK与注册中心交互，来实现服务的注册和发现。
• 应用外注册与发现:业务应用本身不需要通过SDK与注册中心打交道，而是通过其他方式与注册中心交互，间接完成服务注册与发现。

两种典型的注册中心实现

Eureka(应用内)

• Eureka Server:注册中心的服务端，实现了服务信息注册、存储以及查询等功能。
• 服务端的Eureka Client:集成在服务端的注册中心SDK，服务提供者通过调用SDK，实现服务注册、反注册等功能。
• 客户端的Eureka Client:集成在客户端的注册中心SDK，服务消费者通过调用SDK，实现服务订阅、消费更新等功能。

Consul(应用外)

• Consul：注册中心的服务端，实现服务注册信息的存储，并提供注册和发现服务。
• Registrator:通过监听服务部署的Docker实例是否存活，来负责服务提供者的注册和销毁。
• Consul Template:定时从注册中心服务端获取最新的服务提供者节点列表并刷新LB配置，
  这样消费者就通过访问nginx就可以获取最新的服务提供者信息。

应用内的解决方案一般适用于服务提供者和服务消费者同属于一个技术体系；
应用外的解决方案一般适合服务提供者和消费者采用不同的技术体系的业务场景。

注册中心选型要考虑的两个问题

• 高可用:集群部署(通过部署多个实例组成集群来保证高可用性);多IDC部署(部署在不止一个机房)。
• 数据一致性:C(Consistency，一致性)、A(可用性)、P(Partition Tolerance分区容错性)。出现网络故障，导致整个网络被分成了
  互不连通的区域，这就叫做分区，一旦出现分区，一个区域内的节点就没法访问其他节点上的数据，最好的方法是把数据复制到其他区域内的节点，
  这样即使把数据复制到其他区域内的节点，这样即使出现分区，也能访问任意区域内节点上的数据，这就是分区容错性。把数据复制到多个节点
  就可能出现数据不一致的情况，这就是一致性。要保证一致，必须等待所有节点上的数据都更新成功才可用，这就是可用性。

数据节点越多，分区容错性越高，但数据一致性越难保证。为了保证数据一致性，又会带来可用性的问题。

根据CAP不能同时满足，所以不同的注册中心解决方案选择的方向不同，大致分为两种:

• CP型注册中心:牺牲可用性来保证数据抢一致性(Zookeeper,etcd,Consul)。Zookeeper集群内只有一个Leader，使用Paxos算法选举出来。
  Leader的目的是保证写信息的时候只向这个Leader写入，Leader会同步信息到Follower是，这个过程保证数据一致性。如果多个Zookeeper之间
  出现网络问题,发生脑裂的话，注册中心就不可用了。etcd和Consul集群内都是通过raft协议来拨正一致性，如果出现脑裂的话，注册中心也不可用。
• AP型注册中心:牺牲一致性来博阿政可用性。Eureka不用选举一个Leader，每个Eureka服务器单独保存服务器注册地址，因为有可能出现信息不一致的信息。

如何RPC选型

Dubbo

Dubbo默认使用Netty作为通信框架；Dubbo除了支持私有的Dubbo协议，还支持RMI协议、Hession协议、HTTP协议、Thrift协议等；Dubbo支持多种序列化格式，
例如Dubbo、Hession、JSON、Kryo、FST等。

Spring Cloud

请求经过Spring Cloud的过程:

• 请求统一通过API网关Zuul来访问内部服务，先经过Token进行安全认证。
• 通过安全认证后，网关Zuul从注册中心Eureka获取可用服务节点列表。
• 从可用服务节点选取一个可用节点，然后把请求发送到这个节点。
• 整个请求过程中，Hystrix组件负责处理服务超时熔断，Turbine组件负责监控服务间的调用和熔断相关指标，Sleuth组件负责调用链监控，ELK负责日志分析。

gRPC

gRPC的原理是通过IDL文件定义服务接口的参数和返回值类型，然后通过代码生成服务端和客户端的具体实现代码。
gRPC的特性:

• 通信采用HTTP/2,因为HTTP/2提供了连接复用、双向流、服务器推送、请求优先级等机制，所以可以节省带宽、降低TCP连接次数、节省CPU。
• IDL使用ProtoBuf，ProtoBuf压缩和传输效率极高，语法也简单。
• 多语言支持，能够基于多种语言自动生成对应语言的客户端和服务端的代码。

如何搭建一个可靠的监控系统

ELK

• Logstash:负责数据收集和传输，支持动态地从各种数据源收集数据，并对数据进行过滤、分析、格式化等，然后存储到指定的位置。
• ElasticSearch:负责数据处理，它是一个开源分布式搜索和分析引擎，具有可伸缩、高可靠和易管理等特点，基于ApacheLucence构建，能对大容量的
  数据进行接近实时的存储、搜索和分析操作，通常被用作基础搜索引擎。
• Kibana:负责数据展示，也是一个开源和免费的工具。

Logstash从不同的数据源手机数据，所以比较消耗CPU和内存资源，造成服务器性能下降，后来，Beats出现，Beats所占系统的CPU和内存几乎忽略不计，
Beats可以从成百上千或者成千上完台机器向Logstash或者直接向ElasticSearch发送数据。

Beats支持多种数据源:

• Packetbeat:用来收集网络流量数据。
• Topbeat:用来收集系统、进程的CPU和内存使用情况等数据。
• FileBeat:用来收集文件数据。
• Winlogbeat:用来收集Windows事件日志数据。

Graphite

Graphite主要包含Carbon(负责数据处理)、Whisper(数据存储)、Graphite-Web(数据展示)，可以接入StatsD。

• Carbon:主要作用是接收被监视节点的连接，收集各个指标的数据，将这些数据写入carbon-cache并最终持久化到Whisper存储文件中去。
• Whisper:一个时序数据库，主要作用是存储时间序列数据。
• Graphiter-Web:数据展示。Carbon将数据写入Whisper存储的同时，会在carbon-cache中同时写入，Graphite-web会先查询carbon-cache，如果没有，在查询Whispher存储。

TICK

TICK 是Telegraf(负责数据收集)、InfluxDB(数据存储)、Chronograf(数据展示)、Kapacitor(数据告警)四个软件首字母的速写，由InfluxData开发的一套开源监控工具栈。

Prometheus

Prometheus的主要组件:

• Prometheus Server:用于拉取metrics信息并将数据存储在时间序列数据库。
• Job/Exporters:用于暴露已有的第三方服务的metrics给PrometheusServer，负责数据收集。
• PushGateWay:主要用于短期jobs。
• Alertmanager:用于数据报警。
• Prometheus Web UI:负责数据展示。

Prometheus工作流程:

• Prometheus Server定期从配置好的jobs或者Exporters中读取metrics信息，或者接收来自Pushgateway发过来的metrics信息。
• Prometheus Server把收集到的metrics信息存储到时间序列数据库中，并运行已经定义好的alert.rules，向Alertmanager推送警报。
• Alertmanager根据配置文件，对接收的警报进行处理，发出告警。
• 通过Prometheus Web UI进行可视化展示。

监控比较

	ELK	Graphite	TICK	Prometheus
收集数据	Beats代理来采集数据	需要配合使用开源数据采集组件	Telegraf作为数据采集组件	通过jobs/exporters组件来获取statsd等采集过来的metrics
数据传输	Beats收集数据后传输给Logstash(推)	Graphite将收集的数据传递给Carbon(推)	将收集的数据传递给InfluxDB(推)	Prometheus自己从jobs/exporters中拉取
数据处理	可以对日志的任意字段索引，适合多维度的数据查询	支持正则匹配、sumSeries求和等函数	InfluxQL，对监控数据进行复杂操作	PromQL，查询
数据展示	Kibana，只支持ES	Grafana	Grafana	Grafana

服务追踪系统

服务追踪系统的实现，主要包括三个部分:

• 埋点数据收集:负责在服务端进行埋点，来收集服务调用的上下文数据。
• 实时数据处理:负责对收集到的链路信息，按照traceid和spanid进行串联和存储。
• 数据链路展示:把处理后的服务调用数据，按照调用脸的形式展示出来。

OpenZipkin

OpenZipkin是Twitter开源的服务追踪系统。

OpenZipkin主要有四个核心部分组成:

• Collector:负责收集探针Reporter埋点采集的数据，经过验证处理并建立索引。
• Storage:存储服务调用的链路数据，默认使用的是Cassandra。
• API:将格式化和建立索引的链路数据以API的方式对外提供服务。
• UI:以图形化的方式展示服务调用的链路数据。

Pinpoint

Pinpoint是Naver开源的一款深度支持Java语言的服务追踪系统。

Pinpoint的组成:

• PinPoint Agent:通过Java字节码注入的方式，来收集JVM中的调用数据，通过UDP协议传递给Collector,数据采用Thrift协议进行编码。
• PinPoint Collector:收集Agent传过来的数据，然后写到HBase Storage，Rowkey是traceId，SpanId和pSpanId都是列。
• HBase Storage:采用HBase集群存储服务调用的链路信息。
• PinPoint Web UI:通过web ui展示服务调用的详细链路信息。

OpenZipkin vs PinPoint

	OpenZipkin	PinPoint
埋点探针支持平台的广泛性	提供不同语言的Library	只支持Java语言
系统集成难易程度	OpenZipkin的Java探针Brave，只提供了基本的操作API，需要手动添加响应的配置文件并且增加trace业务代码	通过字节码注入的方式来实现拦截服务，从而收集trace信息,JVM加载class二进制文件时，动态修改加载的class文件，在方法前后执行拦截器的before和after方法，记录trace信息
调用链路数据的精确度	只能看到接口级别信息，只能绘制服务与服务之间的调用链路拓扑	字节码注入的方式实现trace信息收集，可以看到接口级别的链路调用信息，还可以看到调用所关联的数据库信息，绘制服务与服务之间的调用链路拓扑，绘制与DB之间的调用链路拓扑图

如何识别服务节点是否存活

心跳开关保护机制，是为了防止服务提供者节点频繁变更导致的服务消费者同时去注册中心获取最新服务节点信息；
服务节点摘除保护机制，是为了防止服务提供者节点被大量摘除引起服务消费者可以调用的节点不足。

如何使用负载均衡算法

	随机算法	轮询算法	加权轮询算法	最小活跃连接算法	一致性hash算法
含义	从可用的服务节点中，随机挑选一个节点来访问	按照固定的顺序，把可用的服务节点，挨个访问一次	给每个节点赋予一个权重，从而使每个节点被访问到的概率不同	每一次访问都选择连接数最少的节点	把来源相同的请求映射到同一个节点上
使用场景	各个服务节点的性能差异不大的情况下	服务节点性能差异不大的情况下	新机器性能大于旧机器，新节点设置更高的权重	服务端节点性能差异比较大，选择连接数比较少的节点	服务端节点处理不同客户端请求差异较大的情况

hystrix通过滑动窗口来对数据进行统计，默认情况下，滑动窗口包含10个桶，每个桶时间宽度为1s，每个桶内记录了这1s内所有服务调用中成功的、失败的、超时的以及被线程拒绝的次数。
当新的1s到来时，滑动窗口就会往前滑动，丢弃掉最旧的1个桶，把最新1桶包含进来。hystrix开关的开启、关闭是按照10个桶内记录的所有的数据。

Spring Cloud Config只支持Java语言，配置存储在git中，变更配置也需要通过git操作，如果配置中心有配置变更，需要手动刷新。
Disconf:只支持Java，基于Zookeeper来实现配置变更实时推送给订阅的客户端，并通过界面统一管理。

参考文献

Graphite Documentation
https://github.com/graphite-project/graphite-web
influxdata
prometheus