基于Sentinel的高可用限流系统HASentinel设计及实现

最新推荐文章于 2024-05-23 10:40:23 发布

置顶冯立彬

最新推荐文章于 2024-05-23 10:40:23 发布

阅读量2.5k

点赞数 1

分类专栏： Sentinel 文章标签： Sentinel 限流微服务治理

本文链接：https://blog.csdn.net/fenglibing/article/details/103809612

版权

Sentinel 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

注：

当前博客中的内容不是最新的内容，最新的博客内容请查看有道笔记中记录的内容：

https://note.youdao.com/ynoteshare1/index.html?id=f2f88ed8e33ada01e8c44ed5d8b3ac5f&type=note

因为内容比较多，确实不方便搬运，需要详细了解的，请移步。

该项目的源代码也已经完全开源了，详情请查码云开源项目HASentinel：

https://gitee.com/laofeng/hasentinel

一、背景说明

1、为什么要限流

拿旅游景点举个示例，每个旅游景点通常都会有最大的接待量，不可能无限制的放游客进入，比如故宫每天只卖八万张票，超过八万的游客，无法买票进入，因为如果超过八万人，景点的工作人员可能就忙不过来，过于拥挤的景点也会影响游客的体验和心情，并且还会有安全隐患；只卖N张票，这就是一种限流的手段。

软件架构中的服务限流也是类似，也是当系统资源不够的时候，已经不足以应对大量的请求，为了保证服务还能够正常运行，那么按照规则，系统会把多余的请求直接拒绝掉，以达到限流的效果；大家应用都有参与过双11，当天晚上的客服系统通常都是不让访问的，当用户访问的时候会提示“为了更好的提供服务...请于XX时间后再次访问”等，这个就是被限流了，也是为了确保用主要业务，如商品浏览、购物车、下单、付款等业务可以更顺利，减少由于其它非重要系统对主系统的影响。

2、Sentinel的主要特点

多样化的流量控制 
熔断降级 
系统负载保护 
实时监控和控制台

3、默认的架构

其默认的架构很简单，应用的注册和监控数据，都是保存在Sentinel的内存中的，不能够直接使用于生产。不过也正因为其简单，方便大家体验，才会受到这么多用户的欢迎，并且其提供了许多的扩展点给用户，大家可以根据自己的应用场景去设计。

二、架构设计

设计原则：

1）高可用

2）高可扩展

3）高性能

4）支持高并发

三、具体实现

1、sentinel-dashboard的修改

1）修改Metric的存储

将Metric数据由默认存储到内存中，修改为存储到外部Influxdb集群中，Influxdb集群理论上支持任意多个Influxdb实例，sentinel-dashboard会根据app对存储进行sharding，然后将数据存储到指定的Influxdb实例中，application.properties 中增加类似如下Influxdb的配置：

#Influxdb理论上可以上多个，以英文的逗号分隔不同Influxdb的URL influxdb.url=http://localhost:8086,
http://localhost:18086 
#目前要求所有Influxdb都使用相同的用户名和密码 
influxdb.username=admin 
influxdb.password=admin

2）修改限流配置的存储

将限流配置由默认存储到内存中，修改为存储到外部的Zookeeper中，application.properties 中增加类似如下Influxdb的配置：

dynamic.rules.source.type = zookeeper 
zookeeper.config.connectString = 127.0.0.1:2181 
zookeeper.config.sessionTimeout = 30000 
zookeeper.config.connectionTimeout = 10000

注：ZK中需要建立以下节点用于存储规则：

/SENTINEL-GROUP/APP-MACHINES 
/SENTINEL-GROUP/AUTHORITY-RULES 
/SENTINEL-GROUP/DEGRADE-RULES 
/SENTINEL-GROUP/FLOW-RULES 
/SENTINEL-GROUP/HOT-RULES 
/SENTINEL-GROUP/SYSTEM-RULES

3）修改应用Metric的获取方式

默认情况下，sentinel-dashbord会定时通过线程的方式到应用端获取Metric的数据，其架构如下所示：

这种架构会受限于sentinel-dashbord的任务的处理能力，总会有一个上限，当应用达到几百个、几千个的时候，sentinel-dashbord的Metric处理能力就会受收非常大的影响，并且sentinel-dashbord本身会存在单点的风险。

为了增强sentinel-dashbord的处理能力，规避其单点风险，将Metric的获取方式修改为应用主动上报的方式，架构如下所示：

说明：

默认架构中的Sentinel Dashboard，其只负责维护连接到其本身的应用，包括从这些连上来的应用中获取Metric数据、往应用推送或从应用中拉取限流配置、检测应用是否健康等，其负担着整体调控的作用，由于保存部分数据在内存中，因而其本身是有状态的，且本身存在着不可扩展的瓶颈；默认情况下，限流配置都是保存到应用App中，存在着重启应用就丢失败的风险。新的架构为高可用的架构，Sentinel Dashboard中不保存数据，所有的限流配置数据都保存在ZK中，其除了对客户端APP做健康检查这一操作以下，不会主动与客户端APP产生任何交互，且其本身不保存任何数据，因面登陆任何一台Sentinel Dashboard，对可以整个集群进行操作，即使有Sentinel Dashboard挂掉，也不会影响到数据的收集和报表的查询。
Metric数据默认是保存到Sentinel Dashboard内存中的，不便于长期保存，也不方便和其它第三方图报展示平台对接，修改为将Metric数据保存到Influxdb集群中，Influxdb集群为多个Influxdb实例组成的，使用app做为Hash key，根据一定的Hash规则将数据分布存储到不同的Influxdb中。

这种架构不会由于应用的增多导致sentinel-dashbord成为瓶颈，因为sentinel-dashbord也是可以水平扩展的，并且Metric是保存在Influxdb的集群中，因而在任何一台Sentinel控制台上都可以查看到所有应用相同的Metric数据。

4）修改应用“机器列表”的存储

应用“机器列表”的存储默认是保存在内存中，但是在布署多个Sentinel控制台的情况下，保存在内存中的应用机器列表只能够展示连接到当前Sentinel控制台本身的应用服务器，而不能够展示连接到其它Sentinel控制台服务器的机器，在修改为将机器列表保存为ZK中后，在任何一台Sentinel控制台服务器上，都可以看到所有的应用机器列表。

5）修改应用“降级规则”的存储

修改应用“降级规则”的存储为ZK，应用通过接收ZK的通知更新本地的降级规则。

原逻辑：

A、默认的“降级规则”逻辑是保存在应用端的，Sentinel控制台每次都是通过API的方式从应用去拉取，并且只能够拉取指定应用、指定IP和指定端口的规则，即只能够拉取一条，如果需要查看应用集群中不同服务器上的“降级规则”，只能够一台台的执行查询；

B、修改“降级规则”也只能够针对应用集群中的一台服务器进行修改，Sentinel控制台在每次有修改的时候主动通过调用应用的API实现规则变化通知，如果要想通知应用集群中的所有服务器，只能够一台台的去通知，效率非常低下；

现逻辑：

A、Sentinel控制台从ZK中获取当前应用的所有降级规则，并进行展示；

B、修改“降级规则”，Sentinel控制台负责将其写到ZK，不再主动通过API的方式调用应用进行通知；

C、应用集群中的服务器，接收ZK配置变化的通知，再更新配置；

D、去掉页面上针对一台台服务器的配置，只保留针对全部服务器的配置，提升操作效率；

6）修改应用的“授权规则”

其实现逻辑和“降级规则”基本一致，也都是Sentinel控制台通过API从应用端获取配置，更新规则时，再通过调用应用端的API进行主动通知，改造的方式和“降级规则”基本一致；

7）修改应用的“热点（参数）规则”

8）修改应用的“系统规则”

通过对sentinel-dashbord以上几点的改造，sentinel-dashbord就可以以集群的方式进行布署，水平扩展。

注：当前sentinel-dashboard的版本支持1.7.2-SNAPSHOT～1.8.0-SNAPSHOT的，后续可以在该版本的基础之上扩展新功能。

Git地址：http://xxx.com/base-component/ld-sentinel/tree/master/ld-sentinel-dashboard

2、增加应用Agent

应用Agent包括：

ld-sentinel-web-spring-boot-starter (支持基于spring boot的web应用限流，自动发现和统计web应用的调用)
ld-sentinel-web-spring-boot-starter (支持基于spring boot的dubbo应用限流，自动发现和统计dubbo应用的调用)
ld-sentinel-web-spring-cloud-starter (支持基于spring cloud的应用限流，自动发现和统计web应用的调用和基于Feign的对外调用)
ld-sentinel-common-spring-boot-starter (使用@SentinelResource注解自定义的应用限流，自动发现和统计注解@SentinelResource自定义的限流使用场景)

应用集成Agent的也很方便，只需要引入对应的maven信赖，在application.properties中做相应的配置即可。

为了方便应用更方便的集成，项目中包括了对应的示例Example。

Git地址：http://xxxx.com/base-component/ld-sentinel/tree/master/ld-sentinel
示例Git地址：http://xxxx.com/base-component/ld-sentinel/tree/master/ld-sentinel-samples

3、增加应用ld-sharding-influxdb

应用ld-sharding-influxdb处于Grafana与Influxdb的中间层，用于处理Grafana从不同的Influxdb sharding库中查询数据时的请求拆分，以及结果合并的处理，再将结果统一返回。处理逻辑如下：

1）获取Grafana请求的所有参数；

2）拆分查询的SQL语句，并从SQL语句中解析出应用的app名称，根据应用的app名称的hash值，与后端总的Influxdb sharding库数量求与运算，并得到该份数据存储到后端的真实的Influxdb的连

3）拼装所的查询参数，往真实的Influxdb库发送请求；

4）合并所有SQL的查询结果，并组装结果后再返回给Grafana；

application.properties 中增加类似如下Influxdb的配置：

#Influxdb理论上可以上多个，以英文的逗号分隔不同Influxdb的URL 
influxdb.url=http://localhost:8086,http://localhost:18086 
#目前要求所有Influxdb都使用相同的用户名和密码 
influxdb.username=admin 
influxdb.password=admin

注：其应用场景目前只适合于查询条件中包括app参数的查询，其它的查询会返回默认的库；

Git地址：http://xxx.com/base-component/ld-sharding-influxdb

4、Influxdb集群架构

架构图示：

每个库中包含了4个Measurements：

sentinel_metric_dubbo：存放的是dubbo请求的metric
sentinel_metric_web：存放的是web请求的metric
sentinel_metric_other：用于保存非WEB及DUBBO请求的Metric，如使用注解@SentinelResource自定义的限流方式
sentinel_metric_each_last：保留每个应用中的每个请求的最后一份的请求数据

Mesurements中保存的数据大致如下：

通过这些维度数据，可以在Grafana中展示Web请求、Dubbo请求及Top耗时请求的不同报表。

四、应用的集成

1、环境及版本

1）当前版本

目前ld-sentinel.version的版本号为：1.0.7

2）Sentinel控制台地址

测试环境
Nginx登陆地址（后带了192.168.10.131和192.168.10.132两个控制台）：http://192.168.10.130:8080/ sentinel/sentinel
192.168.10.131控制台：http://192.168.10.131:20440 sentinel/sentinel
192.168.10.132控制台：http://192.168.10.132:20440 sentinel/sentinel
生产环境
http://sentinel.xxx.com sentinel/sentinel
预发布环境
http://172.16.200.8:20440/ sentinel/sentinel

3）Sentinel Grafana地址

测试环境
http://192.168.10.131:3000/ admin/admin
生产环境
http://grafana.xxx.com/d/ECS1u69Zz/sentinel-metric-all?orgId=1

4）Influxdb地址

测试环境
Influxdb 133：http://192.168.10.133:8086 admin/admin
Influxdb 134：http://192.168.10.134:8086 admin/admin
Sharding Influxdb（后带了192.168.10.133和192.168.10.133两个Influxdb）：http://192.168.10.132:20430 admin/admin
生产环境
Sharding Influxgh：http://sharding-influxdb.xxx.com

2、基于Spring boot的web应用

1）应用引入ld-sentinel-web-spring-boot-starter

		<dependency>
		    <groupId>xxx</groupId>
		    <artifactId>ld-sentinel-web-spring-boot-starter</artifactId>
		    <version>${ld-sentinel.version}</version>
		</dependency>

2）application.properties增加配置

核心配置

#[应用必填]应用的名称，也可以在JVM参数中通过-Dproject.name指定，优先读取配置文件中的，读取不到再读取JVM参数中的配置
spring.application.name=sentinel-webmvc-sample
#[应用选填]ZK的连接配置（如果不配置，系统会自动判断当前是测试环境还是生产环境，并使用相应的配置）
#sentinel.zookeeperAddress = 192.168.10.185:2181
#Sentinel相关的配置项
#[应用选填]Sentinel控制台地址（如果不配置，系统会自动判断当前是测试环境还是生产环境，并使用相应的配置）
#sentinel.sentinelServer = 192.168.10.130:8080
[应用选填]当前应用往Sentinel控制台注册的端口
#该端口目前主要用于控制台检查应用是否还健康，如果未设置则默认使用54321端口，如果本地启动了多个连接Sentinel控制台的应用，
#导致该端口被其它应用占用了，为了确保应用的顺利启动和正常运行，则会使用30000~40000的随机端口。
#生产环境强烈建议设置，否则不利用应用端口的管理，应用的每次重启，在Sentinel控制台都会显示原来端口的应用不可用
#注：如果应用运行于容器中，该端口要映射出来
sentinel.apiPort=54321

注：

如果不配置ＺＫ和Sentinel控制台地址，系统会自动判断当前是测试环境还是生产环境，并使用相应的配置；如果有配置则使用配置的值覆盖默认的值。

3）高级应用

A、URL排除：自定义UrlCleaner

包中已经默认实现了URL排的类：com.xxx.sentinel.web.ExcludeUrlCleaner，为了使用该规则，只需要在application.properties增加如下配置：

#需要排除Sentinel统计的URL的前缀，多个Rest URL以英文逗号分隔
#sentinel.excludeUrlPrefix =

注：如果实现了自定义UrlCleaner，并且在应用启动时，通过com.xxx.sentinel.web.WebConfigManager注册到了系统中，类似如下：

WebConfigManager.setUrlCleaner(new TestUrlCleaner());

则默认的ExcludeUrlCleaner就会不生效。

B、配合授权规则，自定义来源处理

针对WEB应用，默认是不会获取来源的，也即在Sentinel控制台配置了针对WEB应用的“授权规则”也不会生效，因为Sentinel不知道根据什么规则来判断来源，需要应用的使用方自定义来源的处理。

来源可以是从一个URL参数中获取，也可以从请求的Header属性中获取；来源可以是一个应用的名称，也可以是一个IP地址等，这些Sentinel留给了我们充足的想像空间，让我们自由的发挥实现，只需要实现com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser接口，根据当前的应用场景具体处理即可。

以下是一个从URL中获取一个参数来判断来源的实例：

/**
 * 授权规则处理示例： <br>
 * 针对配置了授权规则的资源，仅允许在授权规则定义的白名单之内的APP进行访问，在黑名单之中的、或者没有定义的APP访问时，全部都拒绝
 * @author fenglibin
 */
public class WhiteAppRequestOriginParser implements RequestOriginParser {
	private static final String BLACK = "BLACK";
	@Override
	public String parseOrigin(HttpServletRequest request) {
		String app = request.getParameter("app");
		if (app == null || app.trim().length() == 0) {
			return BLACK;
		}
		return app;
	}
}

然后com.xxx.sentinel.web.WebConfigManager将该实现注册到Sentinel中，代码操作如下：

WebConfigManager.setOriginParser(new WhiteAppRequestOriginParser());

如果在Sentinel控制台的授权规则做了如下截图的配置：

则表示/hello2这个接口，只有参数中带了"app=app2"的请求才可以访问，其它的全部都会被Block掉。

C、自定义异常处理

Sentinel中的流控异常BlockException分为以下几种：

FlowException
AuthorityException
DegradeException
ParamFlowException
SystemBlockException

默认的情况下，都是返回以下429代码的异常：

	@Override
	public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {		
		// Return 429 (Too Many Requests) by default.
        response.setStatus(429);
        StringBuffer url = request.getRequestURL();
        if ("GET".equals(request.getMethod()) && StringUtil.isNotBlank(request.getQueryString())) {
            url.append("?").append(request.getQueryString());
        }
        PrintWriter out = response.getWriter();
        out.print("[LD]You request are blocked. Come back later.");
        out.flush();
        out.close();
	}

也可以针对不同的异常类型，做个性化的异常处理，异常处理类需要实现接口com.alibaba.csp.sentinel.slots.block.BlockException，然后通过com.xxx.sentinel.web.exception.WebBlockExeptionManager注册应用中：

//设置违返授权规则的被Block的异常处理
WebBlockExeptionManager.setAuthorityExceptionHandler(authorityExceptionHandler);
//设置违返降级规则的被Block的异常处理
WebBlockExeptionManager.setDegradeExceptionHandler(degradeExceptionHandler);
//设置违返热点参数规则的被Block的异常处理
WebBlockExeptionManager.setParamFlowExceptionHandler(paramFlowExceptionHandler);
//设置违返系统规则的被Block的异常处理
WebBlockExeptionManager.setSystemBlockExceptionHandler(systemBlockExceptionHandler);
//设置违返限流规则的被Block的异常处理
WebBlockExeptionManager.setFlowExceptionHandler(flowExceptionHandler);

也可以统一设置所有的异常处理：

WebBlockExeptionManager.setDefaultExceptionHandler(defaultExceptionHandler);

注：设置了默认限流后，原来已有的所有限流异常处理器都会被替换为当前的默认处理器，如果还需要单独对不同的场景使用不同的异常处理器的，需要在后面重新设置相应异常的限流异常处理器。

３、基于Spring Cloud的应用

1）应用引入ld-sentinel-web-spring-cloud-starter

		<dependency>
		    <groupId>xxx</groupId>
		    <artifactId>ld-sentinel-web-spring-cloud-starter</artifactId>
		    <version>${ld-sentinel.version}</version>
		</dependency>

基于Spring Cloud应用的核心配置、高级应用（URL排除、配合授权规则自定义来源处理、自定义异常处理）与前面基于Spring Boot应用的处理是一致的。

4、基于Spring boot的dubbo应用

1）应用引入ld-sentinel-web-spring-boot-starter

       <dependency>
            <groupId>xxx</groupId>
	    	<artifactId>ld-sentinel-dubbo-spring-boot-starter</artifactId>
            <version>${ld-sentinel.version}</version>
        </dependency>

2）application.properties增加配置

核心配置

#[应用必填]应用的名称，也可以在JVM参数中通过-Dproject.name指定，优先读取配置文件中的，读取不到再读取JVM参数中的配置
spring.application.name = ld-sentinel-dubbo-sample
#[应用选填]ZK的连接配置（如果不配置，系统会自动判断当前是测试环境还是生产环境，并使用相应的配置）
sentinel.zookeeperAddress = 192.168.10.185:2181
#[应用选填]Sentinel控制台地址（如果不配置，系统会自动判断当前是测试环境还是生产环境，并使用相应的配置）
sentinel.sentinelServer = 192.168.10.130:8080
[应用选填]当前应用往Sentinel控制台注册的端口
#该端口目前主要用于控制台检查应用是否还健康，如果未设置则默认使用54321端口，如果本地启动了多个连接Sentinel控制台的应用，
#导致该端口被其它应用占用了，为了确保应用的顺利启动和正常运行，则会使用30000~40000的随机端口。
#生产环境强烈建议设置，否则不利用应用端口的管理，应用的每次重启，在Sentinel控制台都会显示原来端口的应用不可用
#注：如果应用运行于容器中，该端口要映射出来
#sentinel.apiPort=54321

3）高级应用

A、Dubbo应用与Web应用有点不同：

不需要自定义UrlCleaner，因为Sentinel会使用类名加方法做为Sentinel的资源名称；

不需要自定义处理来源，Sentinel会使用Dubbo Consumer的名称做为来源，如下配置：

<dubbo:application name="dubbo-consumer"/>

中的名称"dubbo-consumer"会被用于来源，如果需要对其使用配置授权规则，则可以在Sentinel控制台中的授权规则针对该参数进行处理。

B、自定义异常处理

同WEB中的Block异常一样，Sentinel中Dubbo的流控异常也分为以下几种：

FlowException
AuthorityException
DegradeException
ParamFlowException
SystemBlockException

Dubbo中可以分别定义Provider和Consumer的Block异常处理，将Provider和Consumer的异常处理类，分别使用DubboBlockExeptionManager.DubboProviderFallbackConfig和DubboBlockExeptionManager.DubboConsumerFallbackConfig将其注册到Sentinel中：

Provider异常处理设置：

//设置违返授权规则的被Block的异常处理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setAuthorityDubboFallback(authorityDubboFallback);
//设置违返降级规则的被Block的异常处理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setDegradeDubboFallback(degradeDubboFallback);
//设置违返限流规则的被Block的异常处理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setFlowDubboFallback(flowDubboFallback);
//设置违返热点参数规则的被Block的异常处理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setParamFlowDubboFallback(paramFlowDubboFallback);
//设置违返系统规则的被Block的异常处理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setSystemDubboFallback(systemDubboFallback);

Consumer异常处理设置：

//设置违返授权规则的被Block的异常处理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setAuthorityDubboFallback(authorityDubboFallback);
//设置违返降级规则的被Block的异常处理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setDegradeDubboFallback(degradeDubboFallback);
//设置违返限流规则的被Block的异常处理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setFlowDubboFallback(flowDubboFallback);
//设置违返热点参数规则的被Block的异常处理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setParamFlowDubboFallback(paramFlowDubboFallback);
//设置违返系统规则的被Block的异常处理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setSystemDubboFallback(systemDubboFallback);

也可以统一设置：

//统一设置Dubbo Provider的异常处理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setDefaultDubboFallback(defaultDubboFallback);
//统一设置Dubbo Consumer的异常处理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setDefaultDubboFallback(defaultDubboFallback);

5、基于@SentinelResource实现自定限流的Spring boot应用

1）应用引入ld-sentinel-web-spring-boot-starter

        <dependency>
            <groupId>xxx</groupId>
	    	<artifactId>ld-sentinel-common-spring-boot-starter</artifactId>
            <version>${ld-sentinel.version}</version>
        </dependency>

2）application.properties增加配置

核心配置

#[应用必填]应用的名称，也可以在JVM参数中通过-Dproject.name指定，优先读取配置文件中的，读取不到再读取JVM参数中的配置
spring.application.name = ld-sentinel-common-sample
#[应用选填]ZK的连接配置（如果不配置，系统会自动判断当前是测试环境还是生产环境，并使用相应的配置）
sentinel.zookeeperAddress = 192.168.10.185:2181
#[应用选填]Sentinel控制台地址（如果不配置，系统会自动判断当前是测试环境还是生产环境，并使用相应的配置）
sentinel.sentinelServer = 192.168.10.130:8080
[应用选填]当前应用往Sentinel控制台注册的端口
#该端口目前主要用于控制台检查应用是否还健康，如果未设置则默认使用54321端口，如果本地启动了多个连接Sentinel控制台的应用，
#导致该端口被其它应用占用了，为了确保应用的顺利启动和正常运行，则会使用30000~40000的随机端口。
#生产环境强烈建议设置，否则不利用应用端口的管理，应用的每次重启，在Sentinel控制台都会显示原来端口的应用不可用
#注：如果应用运行于容器中，该端口要映射出来
#sentinel.apiPort=54321

6、Sentinel扩展配置项（配置到application.properties中）

#Sentinel扩展配置项

#日志输出路径，Sentinel默认会将日志输出到用户目录{@code ${user.home}/logs/csp/}下，默认值为logs/csp
#sentinel.logDir = logs/csp

#默认的日志文件名没有包括PID，但如果在同一台服务器上运行了多个实例，可能需要在日志文件中加上PID用于区分不同的日志文件，默认值为true
#sentinel.logUsePid = true

#应用端与控制台的心台检测时间，默认为10秒钟
#sentinel.heartbeatIntervalMS = 10000
#指定客户端ＩＰ地址，在有些多网卡的场景，获取的ＩＰ不正确，可以通过手动指定ＩＰ的方式
#sentinel.heartBeatClientHost = 192.168.0.1

五、Grafana报表的展示

1、说明

通过Grafana展示存储于Influxdb中的Metrics数据，操作方便且美观，不过其同一个报表不能够智能路由到不同的Influxdb中查询，因为需要一个中间应用，ld-sharding-influxdb就是基本这样场景的特定应用，GIT地址：http://xxx.com/base-component/ld-sharding-influxdb，其会根据应用的app，将请求路由到不同的Influxdb中，并将结果进行汇总后再返回给前端的Grafana。

2、使用ld-sharding-influxdb的步骤

1）启动ld-sharding-influxdb；

2）在Grafana中配置数据源，其配置方式和配置其它Influxdb数据源的方式一致，只需要将URL设置为ld-sharding-influxdb的地址和端口即可，如下所示：

3）报表选择该数据源；

3、报表展示样式

冯立彬

关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
基于Sentinel的高可用限流系统HASentinel设计及实现

一、背景说明1、为什么要限流拿旅游景点举个示例，每个旅游景点通常都会有最大的接待量，不可能无限制的放游客进入，比如故宫每天只卖八万张票，超过八万的游客，无法买票进入，因为如果超过八万人，景点的工作人员可能就忙不过来，过于拥挤的景点也会影响游客的体验和心情，并且还会有安全隐患；只卖N张票，这就是一种限流的手段。软件架构中的服务限流也是类似，也是当系统资源不够的时候，已经不足以应...
复制链接

扫一扫