使用 shuf 来打乱一个文件中的行或是选择文件中一个随机的行。

社区日报 第1161期 (2021-01-06)

1.Elasticsearch VS ClickHouse,成本太高,效率太低?不存在的
https://blog.csdn.net/u0136134 ... 57935
2.极限网关 INFINI Gateway 初体验
https://elasticsearch.cn/article/14173
3.ElasticSearch 学习笔记
https://blog.gmem.cc/elasticsearch-study-note

编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
 
继续阅读 »
1.Elasticsearch VS ClickHouse,成本太高,效率太低?不存在的
https://blog.csdn.net/u0136134 ... 57935
2.极限网关 INFINI Gateway 初体验
https://elasticsearch.cn/article/14173
3.ElasticSearch 学习笔记
https://blog.gmem.cc/elasticsearch-study-note

编辑:江水
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
  收起阅读 »

社区日报 第1159期 (2021-01-04)

1. 另一个elasticsearch web管理ui
https://github.com/appbaseio/dejavu

2. 聊聊replication的方式
https://juejin.cn/post/6844903505535189005

3. Elasticsearch 分片策略优化
https://zhuanlan.zhihu.com/p/59339787

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. 另一个elasticsearch web管理ui
https://github.com/appbaseio/dejavu

2. 聊聊replication的方式
https://juejin.cn/post/6844903505535189005

3. Elasticsearch 分片策略优化
https://zhuanlan.zhihu.com/p/59339787

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1155期 (2020-12-31)

1.Elasticsearch-BulkProcessor踩坑之源码分析
https://www.jianshu.com/p/8908737acc83
2.vivo全球商城:订单中心架构设计与实践
https://www.jianshu.com/p/9221aba391a5
3.Elasticsearch索引生命周期管理方案
https://mp.weixin.qq.com/s/gWeArS2eyedoabPR5zDKXQ

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.Elasticsearch-BulkProcessor踩坑之源码分析
https://www.jianshu.com/p/8908737acc83
2.vivo全球商城:订单中心架构设计与实践
https://www.jianshu.com/p/9221aba391a5
3.Elasticsearch索引生命周期管理方案
https://mp.weixin.qq.com/s/gWeArS2eyedoabPR5zDKXQ

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1153期 (2020-12-29)

1. 19种ElasticSearch字符串搜索方式
https://www.cnblogs.com/sunshuyi/p/12716828.html

2. grafana和kibana的历史发展关系
https://www.zhihu.com/question/54388690

3.使用elastic apm 实现程序中的指标监控
https://www.elastic.co/guide/e ... ation

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. 19种ElasticSearch字符串搜索方式
https://www.cnblogs.com/sunshuyi/p/12716828.html

2. grafana和kibana的历史发展关系
https://www.zhihu.com/question/54388690

3.使用elastic apm 实现程序中的指标监控
https://www.elastic.co/guide/e ... ation

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1152期 (2020-12-28)

1. 数据流在ES存储索引命名策略
https://www.elastic.co/blog/an ... cheme
2. 使用ElasticSearch赋能HBase二级索引
https://juejin.cn/post/6844904120017485838
3. 蚂蚁金服 ZSearch 在向量检索上的探索
https://www.sofastack.tech/blo ... arch/

编辑:wt
归档:https://ela.st/cn-daily-all 
订阅:https://ela.st/cn-daily-sub 
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. 数据流在ES存储索引命名策略
https://www.elastic.co/blog/an ... cheme
2. 使用ElasticSearch赋能HBase二级索引
https://juejin.cn/post/6844904120017485838
3. 蚂蚁金服 ZSearch 在向量检索上的探索
https://www.sofastack.tech/blo ... arch/

编辑:wt
归档:https://ela.st/cn-daily-all 
订阅:https://ela.st/cn-daily-sub 
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1151期 (2020-12-27)

1.将Go服务与ELK系列集成。 
https://pmihaylov.com/series-i ... -elk/ 
2.使用Kibana调试生产问题。 
https://pmihaylov.com/kibana-debugging-tutorial/ 
3.对AWS Storage Options感到困惑吗? S3,EBS,EFS解释 
https://dzone.com/articles/con ... ained
编辑:至尊宝

归档:https://ela.st/cn-daily-all 
订阅:https://ela.st/cn-daily-sub 
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.将Go服务与ELK系列集成。 
https://pmihaylov.com/series-i ... -elk/ 
2.使用Kibana调试生产问题。 
https://pmihaylov.com/kibana-debugging-tutorial/ 
3.对AWS Storage Options感到困惑吗? S3,EBS,EFS解释 
https://dzone.com/articles/con ... ained
编辑:至尊宝

归档:https://ela.st/cn-daily-all 
订阅:https://ela.st/cn-daily-sub 
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1149期 (2020-12-25)

1、Elasticsearch分词器介绍
https://hackernoon.com/analyze ... k3w4h
2、elasticsearch初学终极教程
https://kalasearch.cn/blog/elasticsearch-tutorial/
3、零停机升级Elasticsearch 实战
https://www.elastic.co/cn/blog ... ction
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1、Elasticsearch分词器介绍
https://hackernoon.com/analyze ... k3w4h
2、elasticsearch初学终极教程
https://kalasearch.cn/blog/elasticsearch-tutorial/
3、零停机升级Elasticsearch 实战
https://www.elastic.co/cn/blog ... ction
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1148期 (2020-12-24)

1.满帮开源的es orm框架ebatis
https://mp.weixin.qq.com/s/GFRiiQEk-JLpPnCi_WrRqw
2.Elasticsearch 开发入门 - Python
https://elasticstack.blog.csdn ... 73923
3.基于NodeJS的高性能分布式游戏日志系统
https://www.jianshu.com/p/582a55a8a5a4

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.满帮开源的es orm框架ebatis
https://mp.weixin.qq.com/s/GFRiiQEk-JLpPnCi_WrRqw
2.Elasticsearch 开发入门 - Python
https://elasticstack.blog.csdn ... 73923
3.基于NodeJS的高性能分布式游戏日志系统
https://www.jianshu.com/p/582a55a8a5a4

编辑:金桥
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1147期 (2020-12-23)

1. 如何在生产环境不停服平滑升级elasticsearch
https://www.elastic.co/blog/ho ... ction
2. Elasticsearch Machine Learning AIOps 实践
https://flashgene.com/archives/69226.html
3. 一款elasticsearch向量词快速评分插件
https://github.com/lior-k/fast ... oring

编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. 如何在生产环境不停服平滑升级elasticsearch
https://www.elastic.co/blog/ho ... ction
2. Elasticsearch Machine Learning AIOps 实践
https://flashgene.com/archives/69226.html
3. 一款elasticsearch向量词快速评分插件
https://github.com/lior-k/fast ... oring

编辑:wt
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1146期 (2020-12-22)

1. 开始使用 Elastic on Google Cloud
https://www.elastic.co/cn/blog ... cloud
2. 训练、评估、监测、推理:Elastic 中的端对端 Machine Learning
https://www.elastic.co/cn/blog ... astic
3.Rancher开源Harvester:基于K8S的超融合基础架构软件
https://mp.weixin.qq.com/s/MWcYD0PnvtVQTNrF2NBe9g

编辑:寂寞的烟
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. 开始使用 Elastic on Google Cloud
https://www.elastic.co/cn/blog ... cloud
2. 训练、评估、监测、推理:Elastic 中的端对端 Machine Learning
https://www.elastic.co/cn/blog ... astic
3.Rancher开源Harvester:基于K8S的超融合基础架构软件
https://mp.weixin.qq.com/s/MWcYD0PnvtVQTNrF2NBe9g

编辑:寂寞的烟
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1145期 (2020-12-21)

1.使用elasticSearch进行机器学习
https://zhuanlan.zhihu.com/p/266314466

2.使用python和django搭建的elasticsearch搜索脚手架
https://github.com/sunnyjiecha ... jango

3.一个基于springboot的elasticsearch java客户端调用封装工具
https://gitee.com/zxporz/ESClientRHL

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
 
继续阅读 »
1.使用elasticSearch进行机器学习
https://zhuanlan.zhihu.com/p/266314466

2.使用python和django搭建的elasticsearch搜索脚手架
https://github.com/sunnyjiecha ... jango

3.一个基于springboot的elasticsearch java客户端调用封装工具
https://gitee.com/zxporz/ESClientRHL

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
  收起阅读 »

社区日报 第1144期 (2020-12-20)

1.为大型集群和Ops构建的ES管理面板。
https://github.com/moshe/elast ... ME.md
2.(自备梯子)集成Elasticsearch和KsqlDB实现强大的数据分析。
https://www.confluent.io/blog/ ... tics/
3.计算机辅助学习对学生长期发展的影响。
https://papers.ssrn.com/sol3/p ... 09169

编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.为大型集群和Ops构建的ES管理面板。
https://github.com/moshe/elast ... ME.md
2.(自备梯子)集成Elasticsearch和KsqlDB实现强大的数据分析。
https://www.confluent.io/blog/ ... tics/
3.计算机辅助学习对学生长期发展的影响。
https://papers.ssrn.com/sol3/p ... 09169

编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
收起阅读 »

INFINI Gateway 的使用方法和使用心得分享

本文主要分享一下大神Medcl开发的INFINI Gateway的使用方法和使用心得,当然可能由于研究得不够深入某些地方理解肤浅甚至说的根本就是错的也请Medcl大神和各位专家大佬能够多多包涵,下面详细对我使用INFINI Gateway的经验进行一下分享。
安装部署
安装部署非常简单,INFINI Gateway使用go语言进行编写,linux系统基本不需要安装任何其他依赖,直接从github上下载解压即可使用,由于需要反复重启调试,同时网关需要具备进程保护功能,我使用了supervisord进行纳管,supervisord安装部署我在此省略,有兴趣的同学直接网上搜索即可。Supervisord配置文件如下:
[program:gateway]
command = /app/logger/gateway/gateway-linux64
username = appuser
autostart=false
autorestart=true
startsecs=3
priority=1007
stdout_logfile=/app/logger/gateway/log/infini_gateway.log
注意这里由于我的测试服务器kibana、gateway和es节点都部署在一起,统一都是用supervisord进行纳管,由于网关必须等到es节点启动以后才可以启动成功,所以将gateway 的autostart设置为false。另外网关节点由于流量、资源不足等问题会有一定风险自己挂掉(测试过程中就遇到过),所以推荐将autorestart设置为true,当网关节点意外挂掉以后能够马上重启不影响应用使用。
配置文件
这块可能是我比较重点想分享的地方,因为可能由于目前项目刚刚发布,medcl大神一直忙于功能开发无暇顾及使用说明的介绍(我妄自揣测,请medcl大神不要见怪^_^),所以配置文件目前在安装介质中只有一个模板,外加模板中的一些参数注释的介绍,可能对于新手进行配置还是有比较大的难度(比如我),所以在自己摸索外加medcl大神的指导下我初步成功配置并实现了预期效果,现在分享给大家。
Path模块:
path.data: data
path.logs: log
这块没什么好说的,就是这是data和log的相对路径,一般也不要改
entry模块:
entry:
- name: es_gateway #your gateway endpoint
enable: true
router: default #configure your gateway's routing flow
network:
binding: 0.0.0.0:8000
reuse_port: true #you can start multi gateway instance, they share same port, to full utilize system's resources
tls:
enabled: false #if your es is using https, the gateway entrypoint should enable https too
这里实际上就是定义gateway的总体模块,指定了gateway网关名字,绑定的地址端口和网关是否启用的开关,这个开关就是指enable参数,我发现后面的版本有的模板文件中是不带enable这个参数的,这里其实有问题,因为测试时发现如果不设置enable为true的话默认值时false,也就是说网关不生效,为了当时排查这个问题我花了不少时间。这里划重点哈,entry模块里定义最重要的参数就是router,也就是网关gateway的路由策略。gateway的配置文件包含关系是这样的,gateway的entry指定了router,router中指定了tracing_flow和default_flow以及默认flow选择策略,tracing_flow是指定网关自己的流,也就是网关监控的流的处理逻辑,和业务查询和写入是无关的,default_flow实际上是真实网关的业务流,这个流一定是要走cache的。然后flow里面才会包含filter,filter顾名思义就是网关流的过滤筛选条件,filter里会有cache逻辑、rate限流条件、filter条件、elasticsearch属性。因为网关的监控数据要单独向es写入,需要设置一些写入属性和参数,所以需要module模块去指定模板、运行态参数和pipeline,然后再pipeline模块中指定写入es属性,包括es地址、索引名、队列名、worksize、bulksize等等,另外网关自己的一些队列参数设置在queue模块中,网关监控信息参数设置在statsd模块中。
flow模块:
- name: cache_first
filter: #comment out any filter sections, like you don't need cache or rate-limiter
- name: get_cache_1
type: get_cache
- name: rate_limit_1
type: rate_limit
parameters:
message: "Hey, You just reached our request limit!"
rules: #configure match rules against request's PATH, eg: /_cluster/health, match the first rule and return
- pattern: "/(?P<index_name>test.*?)/_search" #use regex pattern to match index, will match any /$index/_search, and limit each index with max_qps ~=100
max_qps: 1000
group: index_name
- name: elasticsearch_1
type: elasticsearch
parameters:
elasticsearch: default #elasticsearch configure reference name
max_connection: 1000 #max tcp connection to upstream, default for all nodes
max_response_size: -1 #default for all nodes
balancer: weight
- host: 192.168.3.201:9200 #the format is host:port
weight: 100
- host: 192.168.3.202:9200
weight: 100
discovery:
enabled: false
- name: set_cache_1
type: set_cache
parameters:
cache_ttl: 1000s
# max_cache_items: 100000
- name: request_logging # this flow is used for request logging, refer to `router`'s `tracing_flow`
filter:
- name: request_path_filter_1
type: request_path_filter
parameters:
must: #must match all rules to continue
prefix:
- /test
- name: request_logging_1
type: request_logging
parameters:
queue_name: request_logging
如上,flow模块就是定义了两个flow,一个是cache_first,一个是request_logging,cache_first是承接业务流,所以在filter中一定要设置get_cache和set_cache强制走缓存策略,这里注意set_cache中要有缓存失效时间cache_ttl,默认是10s,这个我根据我的业务需求直接增加到了1000s,因为我想将缓存多保留一段时间,max_cache_items我直接注释掉了,不限制缓存数量的大小,如果一定要设置这个值要注意一下这个值针对的是每一个查询语句的而不是总共的。另外在cache_first中可以设置限流策略,/(?P<index_name>test.*?)表示test开头的索引全部应用限流策略。这里还有一个关键点是指定elasticsearch地址时可以配置连接权重,这个参数对我还是蛮有用的,因为我想我的应用查询通过网关只从coor节点进入而不是datanode和masternode,做到读写节点分离同时降低大查询灾难蔓延扩散的风险。所以我会将es集群中两个coor节点配置到这里,weight尽量设置的大一点,这里要注意如果这样配置必须把discovery的enable设置为false,否则网关还是会从master或者data节点进入。
request_logging的流其实就是网关trace监控自己用的,由于后面进行了filter强匹配,所以采样sample参数我就没有配置。注意这里其实我们在cache_first中并没有配置filter规则,所以这里任何过网关的查询都会进入缓存,包括查询tracing_flow自己创建的索引。在request_logging尽量按照自己的需求去配置一些filter规则来减少监控写入的索引,如果不配置,写入的量级会非常多,后续用仪表盘进行监控时响应会非常慢。目前gateway网关支持的filter类型非常全面,包括request_path_filter根据索引名或者路径去筛选,request_header_filter根据请求头部信息去筛选索引,request_method_filter根据请求的方法类型去筛选,注意如果使用request_header_filter根据请求头部信息去筛选索引,需要在应用在请求的头里加入特殊标识,比如如果要通过request_header_filter方式把所有kibana的请求全部过滤掉,就需要在kibana配置文件中增加头部参数并自定义值:
elasticsearch.customHeaders: { "app": "kibana" }
然后在request_header_filter中加过滤条件:
- name: request_header_filter1 # filter out the requests that we are not interested, reduce tracing pressure
type: request_header_filter
parameters:
exclude: # any rule match will marked request as filtered
- app: kibana # in order to filter kibana's access log, config `elasticsearch.customHeaders: { "app": "kibana" }` to your kibana's config `/config/kibana.yml`
我目前的需求是只想监控某些固定索引前缀的请求,所以我只配置了request_path_filter并must强配置了比如test索引前缀的索引,这样已经满足我得需求并最大限度的减少了监控请求数量。
这里还有一个点,就是在filter类型中还有个特殊的类型,叫做request_logging,这个是专门针对tracing_flow设计的,其中有一个重要参数是queue_name,他会在gateway网关所在的服务器磁盘上创建一个队列用来加速写入,减少tracing_flow对网关所造成的性能影响,所以这个队列在这里创建之后会在后面的pipelines中去指定写入磁盘队列。
router模块:
router:
- name: default
tracing_flow: request_logging #a flow will execute after request finish
default_flow: cache_first
rules: #rules can't be conflicted with each other, will be improved in the future
- id: 1 # this rule means match every requests, and sent to `cache_first` flow
method:
- "*"
pattern:
- /
# priority: 1
flow:
- cache_first # after match, which processing flow will go through
router模块最重要的就是指定了tracing_flow和default_flow,这里可以定义路由规则,按照默认全部匹配就走缓存可以,同时最后在flow参数指定默认要走的flow流,也就是cache_first业务请求流。
elasticsearch模块:
elasticsearch:
- name: default
enabled: true
endpoint: http://localhost:9200 # if your elasticsearch is using https, your gateway should be listen on as https as well
version: 7.9.1 #optional, used to select es adaptor, can be done automatically after connect to es
index_prefix: gateway_
basic_auth: #used to discovery full cluster nodes, or check elasticsearch's health and versions
username: elastic
password: pass
这里需要指定es地址和端口,可以配置多个,也就是说可以将业务的es和监控索引存储的es进行分离,这里有个参数index_prefix,我的理解是这个会在kibana中去创建这个索引模式,用来后续进行仪表盘监控,但是真实测试结果是这个设置没有生效,索引模式前缀都是gateway_requests,这个可能需要后续和Medcl大神再确认一下。
modules模块:
modules:
- name: elastic
enabled: true
elasticsearch: default
init_template: true
- name: pipeline
enabled: true
runners:
- name: primary
enabled: true
max_go_routine: 1
threshold_in_ms: 0
timeout_in_ms: 5000
pipeline_id: request_logging_index
modules需要配置两个模块,一个是es模块,一个是pipeline模块,主要是为
request_logging要往es中写数做准备,es模块使用默认模板,pipeline设置一些写入需要的参数,我全部没改使用默认值。
pipelines模块:
pipelines:
- name: request_logging_index
start:
joint: json_indexing
enabled: true
parameters:
index_name: "gateway_requests"
elasticsearch: "default"
input_queue: "request_logging"
timeout: "60s"
worker_size: 1
bulk_size_in_mb: 10 #in MB
process:
因为要向es中写入trace数据,所以需要在pipeline中配置写入参数,包括json方式传输,写入的es(如果es有多个需要拆分),使用的磁盘队列queue,超时时间,写入worker数以及bulksize,这个我觉得后续可以根据监控的量级进行优化。
queue模块:
queue:
min_msg_size: 1
max_msg_size: 50000000
max_bytes_per_file: 53687091200
sync_every_records: 100000 # sync by records count
sync_timeout_in_ms: 10000 # sync by time in million seconds
read_chan_buffer: 0
这个就是那个trace数据本次磁盘队列的一些写入参数,包括消息大小,磁盘文件大小,同步消息数,read buffer等等,如果像我目前的应用场景已经严格匹配索引的量级有限可以不用改,但是我觉得默认max_bytes_per_file默认值是50G,这个我觉得单个文件有点大,生产环境可以考虑调小。
statsd模块:
enabled: false
host: 127.0.0.1
port: 8125
namespace: gateway.
这个模块目前我没用到,应该是本身监控gateway状态的模块,指定了监控端口,后续可以进行验证。
使用对比结果:
通过gateway中自带仪表盘可以对使用情况和效果进行方便的监控,通过比对可以发现一条复用的查询语句走网关缓存和不走网关缓存性能差距在100倍以上,使用网关进行查询优势巨大特别明显。

网关截图.png


未来展望:
首先感谢Medcl大神把这么好的东西发布出来,使用网关对于业务查询有百倍上的性能提升确实十分诱人。而且目前虽然INFINI Gateway刚刚发布出来,但是已经陆陆续续迭代了好几个版本,可以明显看到一些bug修复、功能增强和性能优化提高,目前最新的版本又增加了请求灰度切换、流量迁移和流量复制功能,可以实现双写和多写,这个功能对于我来说后续很可能会应用到,因为实际上是一种变相的多集群数据同步方式的实现。所以可以看出INFINI Gateway网关不仅仅定位于查询缓存网关,而是集查询和写入功能为一体的综合性大网关,期待Medcl大神后续的精彩表演,让我们拭目以待。
继续阅读 »
本文主要分享一下大神Medcl开发的INFINI Gateway的使用方法和使用心得,当然可能由于研究得不够深入某些地方理解肤浅甚至说的根本就是错的也请Medcl大神和各位专家大佬能够多多包涵,下面详细对我使用INFINI Gateway的经验进行一下分享。
安装部署
安装部署非常简单,INFINI Gateway使用go语言进行编写,linux系统基本不需要安装任何其他依赖,直接从github上下载解压即可使用,由于需要反复重启调试,同时网关需要具备进程保护功能,我使用了supervisord进行纳管,supervisord安装部署我在此省略,有兴趣的同学直接网上搜索即可。Supervisord配置文件如下:
[program:gateway]
command = /app/logger/gateway/gateway-linux64
username = appuser
autostart=false
autorestart=true
startsecs=3
priority=1007
stdout_logfile=/app/logger/gateway/log/infini_gateway.log
注意这里由于我的测试服务器kibana、gateway和es节点都部署在一起,统一都是用supervisord进行纳管,由于网关必须等到es节点启动以后才可以启动成功,所以将gateway 的autostart设置为false。另外网关节点由于流量、资源不足等问题会有一定风险自己挂掉(测试过程中就遇到过),所以推荐将autorestart设置为true,当网关节点意外挂掉以后能够马上重启不影响应用使用。
配置文件
这块可能是我比较重点想分享的地方,因为可能由于目前项目刚刚发布,medcl大神一直忙于功能开发无暇顾及使用说明的介绍(我妄自揣测,请medcl大神不要见怪^_^),所以配置文件目前在安装介质中只有一个模板,外加模板中的一些参数注释的介绍,可能对于新手进行配置还是有比较大的难度(比如我),所以在自己摸索外加medcl大神的指导下我初步成功配置并实现了预期效果,现在分享给大家。
Path模块:
path.data: data
path.logs: log
这块没什么好说的,就是这是data和log的相对路径,一般也不要改
entry模块:
entry:
- name: es_gateway #your gateway endpoint
enable: true
router: default #configure your gateway's routing flow
network:
binding: 0.0.0.0:8000
reuse_port: true #you can start multi gateway instance, they share same port, to full utilize system's resources
tls:
enabled: false #if your es is using https, the gateway entrypoint should enable https too
这里实际上就是定义gateway的总体模块,指定了gateway网关名字,绑定的地址端口和网关是否启用的开关,这个开关就是指enable参数,我发现后面的版本有的模板文件中是不带enable这个参数的,这里其实有问题,因为测试时发现如果不设置enable为true的话默认值时false,也就是说网关不生效,为了当时排查这个问题我花了不少时间。这里划重点哈,entry模块里定义最重要的参数就是router,也就是网关gateway的路由策略。gateway的配置文件包含关系是这样的,gateway的entry指定了router,router中指定了tracing_flow和default_flow以及默认flow选择策略,tracing_flow是指定网关自己的流,也就是网关监控的流的处理逻辑,和业务查询和写入是无关的,default_flow实际上是真实网关的业务流,这个流一定是要走cache的。然后flow里面才会包含filter,filter顾名思义就是网关流的过滤筛选条件,filter里会有cache逻辑、rate限流条件、filter条件、elasticsearch属性。因为网关的监控数据要单独向es写入,需要设置一些写入属性和参数,所以需要module模块去指定模板、运行态参数和pipeline,然后再pipeline模块中指定写入es属性,包括es地址、索引名、队列名、worksize、bulksize等等,另外网关自己的一些队列参数设置在queue模块中,网关监控信息参数设置在statsd模块中。
flow模块:
- name: cache_first
filter: #comment out any filter sections, like you don't need cache or rate-limiter
- name: get_cache_1
type: get_cache
- name: rate_limit_1
type: rate_limit
parameters:
message: "Hey, You just reached our request limit!"
rules: #configure match rules against request's PATH, eg: /_cluster/health, match the first rule and return
- pattern: "/(?P<index_name>test.*?)/_search" #use regex pattern to match index, will match any /$index/_search, and limit each index with max_qps ~=100
max_qps: 1000
group: index_name
- name: elasticsearch_1
type: elasticsearch
parameters:
elasticsearch: default #elasticsearch configure reference name
max_connection: 1000 #max tcp connection to upstream, default for all nodes
max_response_size: -1 #default for all nodes
balancer: weight
- host: 192.168.3.201:9200 #the format is host:port
weight: 100
- host: 192.168.3.202:9200
weight: 100
discovery:
enabled: false
- name: set_cache_1
type: set_cache
parameters:
cache_ttl: 1000s
# max_cache_items: 100000
- name: request_logging # this flow is used for request logging, refer to `router`'s `tracing_flow`
filter:
- name: request_path_filter_1
type: request_path_filter
parameters:
must: #must match all rules to continue
prefix:
- /test
- name: request_logging_1
type: request_logging
parameters:
queue_name: request_logging
如上,flow模块就是定义了两个flow,一个是cache_first,一个是request_logging,cache_first是承接业务流,所以在filter中一定要设置get_cache和set_cache强制走缓存策略,这里注意set_cache中要有缓存失效时间cache_ttl,默认是10s,这个我根据我的业务需求直接增加到了1000s,因为我想将缓存多保留一段时间,max_cache_items我直接注释掉了,不限制缓存数量的大小,如果一定要设置这个值要注意一下这个值针对的是每一个查询语句的而不是总共的。另外在cache_first中可以设置限流策略,/(?P<index_name>test.*?)表示test开头的索引全部应用限流策略。这里还有一个关键点是指定elasticsearch地址时可以配置连接权重,这个参数对我还是蛮有用的,因为我想我的应用查询通过网关只从coor节点进入而不是datanode和masternode,做到读写节点分离同时降低大查询灾难蔓延扩散的风险。所以我会将es集群中两个coor节点配置到这里,weight尽量设置的大一点,这里要注意如果这样配置必须把discovery的enable设置为false,否则网关还是会从master或者data节点进入。
request_logging的流其实就是网关trace监控自己用的,由于后面进行了filter强匹配,所以采样sample参数我就没有配置。注意这里其实我们在cache_first中并没有配置filter规则,所以这里任何过网关的查询都会进入缓存,包括查询tracing_flow自己创建的索引。在request_logging尽量按照自己的需求去配置一些filter规则来减少监控写入的索引,如果不配置,写入的量级会非常多,后续用仪表盘进行监控时响应会非常慢。目前gateway网关支持的filter类型非常全面,包括request_path_filter根据索引名或者路径去筛选,request_header_filter根据请求头部信息去筛选索引,request_method_filter根据请求的方法类型去筛选,注意如果使用request_header_filter根据请求头部信息去筛选索引,需要在应用在请求的头里加入特殊标识,比如如果要通过request_header_filter方式把所有kibana的请求全部过滤掉,就需要在kibana配置文件中增加头部参数并自定义值:
elasticsearch.customHeaders: { "app": "kibana" }
然后在request_header_filter中加过滤条件:
- name: request_header_filter1 # filter out the requests that we are not interested, reduce tracing pressure
type: request_header_filter
parameters:
exclude: # any rule match will marked request as filtered
- app: kibana # in order to filter kibana's access log, config `elasticsearch.customHeaders: { "app": "kibana" }` to your kibana's config `/config/kibana.yml`
我目前的需求是只想监控某些固定索引前缀的请求,所以我只配置了request_path_filter并must强配置了比如test索引前缀的索引,这样已经满足我得需求并最大限度的减少了监控请求数量。
这里还有一个点,就是在filter类型中还有个特殊的类型,叫做request_logging,这个是专门针对tracing_flow设计的,其中有一个重要参数是queue_name,他会在gateway网关所在的服务器磁盘上创建一个队列用来加速写入,减少tracing_flow对网关所造成的性能影响,所以这个队列在这里创建之后会在后面的pipelines中去指定写入磁盘队列。
router模块:
router:
- name: default
tracing_flow: request_logging #a flow will execute after request finish
default_flow: cache_first
rules: #rules can't be conflicted with each other, will be improved in the future
- id: 1 # this rule means match every requests, and sent to `cache_first` flow
method:
- "*"
pattern:
- /
# priority: 1
flow:
- cache_first # after match, which processing flow will go through
router模块最重要的就是指定了tracing_flow和default_flow,这里可以定义路由规则,按照默认全部匹配就走缓存可以,同时最后在flow参数指定默认要走的flow流,也就是cache_first业务请求流。
elasticsearch模块:
elasticsearch:
- name: default
enabled: true
endpoint: http://localhost:9200 # if your elasticsearch is using https, your gateway should be listen on as https as well
version: 7.9.1 #optional, used to select es adaptor, can be done automatically after connect to es
index_prefix: gateway_
basic_auth: #used to discovery full cluster nodes, or check elasticsearch's health and versions
username: elastic
password: pass
这里需要指定es地址和端口,可以配置多个,也就是说可以将业务的es和监控索引存储的es进行分离,这里有个参数index_prefix,我的理解是这个会在kibana中去创建这个索引模式,用来后续进行仪表盘监控,但是真实测试结果是这个设置没有生效,索引模式前缀都是gateway_requests,这个可能需要后续和Medcl大神再确认一下。
modules模块:
modules:
- name: elastic
enabled: true
elasticsearch: default
init_template: true
- name: pipeline
enabled: true
runners:
- name: primary
enabled: true
max_go_routine: 1
threshold_in_ms: 0
timeout_in_ms: 5000
pipeline_id: request_logging_index
modules需要配置两个模块,一个是es模块,一个是pipeline模块,主要是为
request_logging要往es中写数做准备,es模块使用默认模板,pipeline设置一些写入需要的参数,我全部没改使用默认值。
pipelines模块:
pipelines:
- name: request_logging_index
start:
joint: json_indexing
enabled: true
parameters:
index_name: "gateway_requests"
elasticsearch: "default"
input_queue: "request_logging"
timeout: "60s"
worker_size: 1
bulk_size_in_mb: 10 #in MB
process:
因为要向es中写入trace数据,所以需要在pipeline中配置写入参数,包括json方式传输,写入的es(如果es有多个需要拆分),使用的磁盘队列queue,超时时间,写入worker数以及bulksize,这个我觉得后续可以根据监控的量级进行优化。
queue模块:
queue:
min_msg_size: 1
max_msg_size: 50000000
max_bytes_per_file: 53687091200
sync_every_records: 100000 # sync by records count
sync_timeout_in_ms: 10000 # sync by time in million seconds
read_chan_buffer: 0
这个就是那个trace数据本次磁盘队列的一些写入参数,包括消息大小,磁盘文件大小,同步消息数,read buffer等等,如果像我目前的应用场景已经严格匹配索引的量级有限可以不用改,但是我觉得默认max_bytes_per_file默认值是50G,这个我觉得单个文件有点大,生产环境可以考虑调小。
statsd模块:
enabled: false
host: 127.0.0.1
port: 8125
namespace: gateway.
这个模块目前我没用到,应该是本身监控gateway状态的模块,指定了监控端口,后续可以进行验证。
使用对比结果:
通过gateway中自带仪表盘可以对使用情况和效果进行方便的监控,通过比对可以发现一条复用的查询语句走网关缓存和不走网关缓存性能差距在100倍以上,使用网关进行查询优势巨大特别明显。

网关截图.png


未来展望:
首先感谢Medcl大神把这么好的东西发布出来,使用网关对于业务查询有百倍上的性能提升确实十分诱人。而且目前虽然INFINI Gateway刚刚发布出来,但是已经陆陆续续迭代了好几个版本,可以明显看到一些bug修复、功能增强和性能优化提高,目前最新的版本又增加了请求灰度切换、流量迁移和流量复制功能,可以实现双写和多写,这个功能对于我来说后续很可能会应用到,因为实际上是一种变相的多集群数据同步方式的实现。所以可以看出INFINI Gateway网关不仅仅定位于查询缓存网关,而是集查询和写入功能为一体的综合性大网关,期待Medcl大神后续的精彩表演,让我们拭目以待。 收起阅读 »