搜索结果正在快递途中
gateway

gateway

极限网关入门视频教程已发布

Elasticsearchmedcl 发表了文章 • 4 个评论 • 772 次浏览 • 2021-11-21 11:41 • 来自相关话题

录制了一系列视频教程,介绍极限网关的使用,不断更新中,第一次做 up 主,记得一键三连,支持一下。:) 
    极限网关地址:
录制了一系列视频教程,介绍极限网关的使用,不断更新中,第一次做 up 主,记得一键三连,支持一下。:) 
    极限网关地址:

使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求

Elasticsearchmedcl 发表了文章 • 7 个评论 • 1533 次浏览 • 2021-10-16 11:31 • 来自相关话题

使用场景

如果你的业务需要用到有多个集群,并且版本还不一样,是不是管理起来很麻烦,如果能够通过一个 API 来进行查询就方便了,聪明的你相信已经想到了 CCS,没错用 CCS 可以实现跨集群的查询,不过 Elasticsearch 提供的 CCS 对版本有一点的限制,并且需要提前做好 mTLS,也就是需要提前配置好两个集群之间的证书互信,这个免不了要重启维护,好像有点麻烦,那么问题来咯,有没有更好的方案呢?

😁 有办法,今天我就给大家介绍一个基于极限网关的方案,极限网关的网址:。

假设现在有两个集群,一个集群是 v2.4.6,有不少业务数据,舍不得删,里面有很多好东西 :)还有一个集群是 v7.14.0,版本还算比较新,业务正在做的一个新的试点,没什么好东西,但是也得用 :(,现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据,程序员懒得很,懂得都懂。

集群信息

  • v2.4.6 集群的访问入口地址:192.168.3.188:9202
  • v7.14.0 集群的访问入口地址:192.168.3.188:9206

这两个集群都是 http 协议的。

实现步骤

今天用到的是极限网关的 switch 过滤器:

网关下载下来就两个文件,一个主程序,一个配置文件,记得下载对应操作系统的包。

定义两个集群资源

elasticsearch:
  - name: v2
    enabled: true
    endpoint: https://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: https://192.168.3.188:9206

上面定义了两个集群,分别命名为 v2v7,待会会用到这些资源。

定义一个服务入口

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 1000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

这里定义了一个名为 my_es_entry 的资源入口,并引用了一个名为 my_router 的请求转发路由,同时绑定了网卡的 0.0.0.0:8000 也就是所有本地网卡监听 IP 的 8000 端口,访问任意 IP 的 8000 端口就能访问到这个网关了。

另外老板也说了,Elasticsearch 用 HTTP 协议简直就是裸奔,通过这里开启 tls,可以让网关对外提供的是 HTTPS 协议,这样用户连接的 Elasticsearch 服务就自带 buffer 了,后端的 es 集群和网关直接可以做好网络流量隔离,集群不用动,简直完美。

为什么定义 TLS 不用指定证书,好用的软件不需要这么麻烦,就这样,不解释。

最后,通过设置 max_concurrency 为 1000,限制下并发数,避免野猴子把我们的后端的 Elasticsearch 给压挂了。

定义一个请求路由

router:
  - name: my_router
    default_flow: cross-cluster-search

这里的名称 my_router 就是表示上面的服务入口的router 参数指定的值。

另外设置一个 default_flow 来将所有的请求都转发给一个名为 cross-cluster-search 的请求处理流程,还没定义,别急,马上。

定义请求处理流程

来啦,来啦,先定义两个 flow,如下,分别名为 v2-flowv7-flow,每节配置的 filter 定义了一系列过滤器,用来对请求进行处理,这里就用了一个 elasticsearch 过滤器,也就是转发请求给指定的 Elasticsearch 后端服务器,了否?

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7

然后,在定义额外一个名为 cross-cluster-search 的 flow,如下:

  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow

这个 flow 就是通过请求的路径的前缀来进行路由的过滤器,如果是 v2:开头的请求,则转发给 v2-flow 继续处理,如果是 v7: 开头的请求,则转发给 v7-flow 来处理,使用的用法和 CCS 是一样的。so easy!

对了,那是不是每个请求都需要加前缀啊,费事啊,没事,在这个 cross-cluster-search 的 filter 最后再加上一个 elasticsearch filter,前面前缀匹配不上的都会走它,假设默认都走 v7,最后完整的 flow 配置如下:

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7              

然后就没有然后了,因为就配置这些就行了。

启动网关

假设配置文件的路径为 sample-configs/cross-cluster-search.yml,运行如下命令:

➜  gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd
[10-16 11:00:52] [INF] [app.go:228] initializing gateway.
[10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0
[10-16 11:00:52] [INF] [api.go:260] api listen at: https://0.0.0.0:2900
[10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]
[10-16 11:00:52] [INF] [entry.go:225] auto generating cert files
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available
[10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: https://0.0.0.0:8000
[10-16 11:00:53] [INF] [app.go:309] gateway is running now.

可以看到网关输出了启动成功的日志,网关服务监听在 https://0.0.0.0:8000

试试访问网关

直接访问网关的 8000 端口,因为是网关自签的证书,加上 -k 来跳过证书的校验,如下:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000  
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

正如前面配置所配置的一样,默认请求访问的就是 v7 集群。

访问 v2 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:/    
{
  "name" : "Solomon O'Sullivan",
  "cluster_name" : "es-v246",
  "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",
  "version" : {
    "number" : "2.4.6",
    "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",
    "build_timestamp" : "2017-07-18T12:17:44Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.4"
  },
  "tagline" : "You Know, for Search"
}

查看集群信息:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:_cluster/health\?pretty
{
  "cluster_name" : "es-v246",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 5,
  "active_shards" : 5,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 5,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

插入一条文档:

➜  loadgen git:(master) ✗ curl-json -k   https://localhost:8000/v2:medcl/doc/1 -d '{"name":"hello world"}'
{"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}%  

执行一个查询

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:medcl/_search\?q\=name:hello                
{"took":78,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":0.19178301,"hits":[{"_index":"medcl","_type":"doc","_id":"1","_score":0.19178301,"_source":{"name":"hello world"}}]}}% 

可以看到,所有的请求,不管是集群的操作,还是索引的增删改查都可以,而 Elasticsearch 自带的 CCS 是只读的,只能进行查询。

访问 v7 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v7:/
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Kibana 里面访问

完全没问题,有图有真相:

Jietu20211016-114041.jpg

其他操作也类似,就不重复了。

完整的配置

path.data: data
path.logs: log

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7

router:
  - name: my_router
    default_flow: cross-cluster-search

elasticsearch:
  - name: v2
    enabled: true
    endpoint: https://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: https://192.168.3.188:9206

小结

好了,今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了,希望大家周末玩的开心。😁

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

Elasticsearchtianqi 发表了文章 • 7 个评论 • 2885 次浏览 • 2020-12-19 16:46 • 来自相关话题

本文主要分享一下大神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:  # 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大神后续的精彩表演,让我们拭目以待。

极限网关 INFINI Gateway 初体验

Elasticsearchliaosy 发表了文章 • 3 个评论 • 4931 次浏览 • 2020-12-09 00:57 • 来自相关话题

最近在elasticsearch足球社区看到medcl大神写的一篇文章《Elasticsearch 极限网关测试版本发布》,在es外层接了一个极限网关gateway,所有的请求先走网关,再到es。gateway能提供索引级别的限速限流,降低重复请求,缓存常见查询,起到查询加速的效果等等很多特性。看着很强大的样子,赶紧下载体验了一下。 下载 下载地址: 找到当前最新版1.1.0_SNAPSHOT
image_(1).png
根据自己的操作系统环境选择相应的包下载,本人用的是Macbook,选择了GATEWAY-darwin64.tar.gz
#切换该路径下(路径自定)
cd /Users/shiyang/code/elastic/gateway
#下载
wget 
#下载完后解压
tar -zxvf GATEWAY-darwin64.tar.gz
#解压后能看到两个新文件,一个可执行二进制文件,一个yml配置文件
ls
#gateway-darwin64   gateway.yml
安装部署 在run之前需要先运行elastisearch,否则会报错,如图所示:
image_(1).png
接下来先启动es集群(如果你本地还没有部署es,建议先参考官网的下载部署) 本机用的es版本为7.9.0,如下图表示启动es成功:
image_(2).png
接下来再启动gateway,yml配置文件可以先默认,后续可根据需要再修改。
#启动 
./gateway-darwin64
启动成功如下图所示:
image_(3).png
成功启动后,我们就可以直接访问gateway了。
curl 
image_(4).png
到此,gateway就算本地部署完毕了。 是不是很简单?嗯,下载即使用,简单方便。 (接下来可以试用一下gateway的特性了。将发布在下一篇文章。)

集群中gateway.*参数有不同值会导致什么结果?

Elasticsearchmedcl 回复了问题 • 2 人关注 • 1 个回复 • 2387 次浏览 • 2017-07-24 10:59 • 来自相关话题

使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求

Elasticsearchmedcl 发表了文章 • 7 个评论 • 1533 次浏览 • 2021-10-16 11:31 • 来自相关话题

使用场景

如果你的业务需要用到有多个集群,并且版本还不一样,是不是管理起来很麻烦,如果能够通过一个 API 来进行查询就方便了,聪明的你相信已经想到了 CCS,没错用 CCS 可以实现跨集群的查询,不过 Elasticsearch 提供的 CCS 对版本有一点的限制,并且需要提前做好 mTLS,也就是需要提前配置好两个集群之间的证书互信,这个免不了要重启维护,好像有点麻烦,那么问题来咯,有没有更好的方案呢?

😁 有办法,今天我就给大家介绍一个基于极限网关的方案,极限网关的网址:。

假设现在有两个集群,一个集群是 v2.4.6,有不少业务数据,舍不得删,里面有很多好东西 :)还有一个集群是 v7.14.0,版本还算比较新,业务正在做的一个新的试点,没什么好东西,但是也得用 :(,现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据,程序员懒得很,懂得都懂。

集群信息

  • v2.4.6 集群的访问入口地址:192.168.3.188:9202
  • v7.14.0 集群的访问入口地址:192.168.3.188:9206

这两个集群都是 http 协议的。

实现步骤

今天用到的是极限网关的 switch 过滤器:

网关下载下来就两个文件,一个主程序,一个配置文件,记得下载对应操作系统的包。

定义两个集群资源

elasticsearch:
  - name: v2
    enabled: true
    endpoint: https://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: https://192.168.3.188:9206

上面定义了两个集群,分别命名为 v2v7,待会会用到这些资源。

定义一个服务入口

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 1000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

这里定义了一个名为 my_es_entry 的资源入口,并引用了一个名为 my_router 的请求转发路由,同时绑定了网卡的 0.0.0.0:8000 也就是所有本地网卡监听 IP 的 8000 端口,访问任意 IP 的 8000 端口就能访问到这个网关了。

另外老板也说了,Elasticsearch 用 HTTP 协议简直就是裸奔,通过这里开启 tls,可以让网关对外提供的是 HTTPS 协议,这样用户连接的 Elasticsearch 服务就自带 buffer 了,后端的 es 集群和网关直接可以做好网络流量隔离,集群不用动,简直完美。

为什么定义 TLS 不用指定证书,好用的软件不需要这么麻烦,就这样,不解释。

最后,通过设置 max_concurrency 为 1000,限制下并发数,避免野猴子把我们的后端的 Elasticsearch 给压挂了。

定义一个请求路由

router:
  - name: my_router
    default_flow: cross-cluster-search

这里的名称 my_router 就是表示上面的服务入口的router 参数指定的值。

另外设置一个 default_flow 来将所有的请求都转发给一个名为 cross-cluster-search 的请求处理流程,还没定义,别急,马上。

定义请求处理流程

来啦,来啦,先定义两个 flow,如下,分别名为 v2-flowv7-flow,每节配置的 filter 定义了一系列过滤器,用来对请求进行处理,这里就用了一个 elasticsearch 过滤器,也就是转发请求给指定的 Elasticsearch 后端服务器,了否?

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7

然后,在定义额外一个名为 cross-cluster-search 的 flow,如下:

  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow

这个 flow 就是通过请求的路径的前缀来进行路由的过滤器,如果是 v2:开头的请求,则转发给 v2-flow 继续处理,如果是 v7: 开头的请求,则转发给 v7-flow 来处理,使用的用法和 CCS 是一样的。so easy!

对了,那是不是每个请求都需要加前缀啊,费事啊,没事,在这个 cross-cluster-search 的 filter 最后再加上一个 elasticsearch filter,前面前缀匹配不上的都会走它,假设默认都走 v7,最后完整的 flow 配置如下:

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7              

然后就没有然后了,因为就配置这些就行了。

启动网关

假设配置文件的路径为 sample-configs/cross-cluster-search.yml,运行如下命令:

➜  gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd
[10-16 11:00:52] [INF] [app.go:228] initializing gateway.
[10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0
[10-16 11:00:52] [INF] [api.go:260] api listen at: https://0.0.0.0:2900
[10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]
[10-16 11:00:52] [INF] [entry.go:225] auto generating cert files
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available
[10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: https://0.0.0.0:8000
[10-16 11:00:53] [INF] [app.go:309] gateway is running now.

可以看到网关输出了启动成功的日志,网关服务监听在 https://0.0.0.0:8000

试试访问网关

直接访问网关的 8000 端口,因为是网关自签的证书,加上 -k 来跳过证书的校验,如下:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000  
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

正如前面配置所配置的一样,默认请求访问的就是 v7 集群。

访问 v2 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:/    
{
  "name" : "Solomon O'Sullivan",
  "cluster_name" : "es-v246",
  "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",
  "version" : {
    "number" : "2.4.6",
    "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",
    "build_timestamp" : "2017-07-18T12:17:44Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.4"
  },
  "tagline" : "You Know, for Search"
}

查看集群信息:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:_cluster/health\?pretty
{
  "cluster_name" : "es-v246",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 5,
  "active_shards" : 5,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 5,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

插入一条文档:

➜  loadgen git:(master) ✗ curl-json -k   https://localhost:8000/v2:medcl/doc/1 -d '{"name":"hello world"}'
{"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}%  

执行一个查询

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:medcl/_search\?q\=name:hello                
{"took":78,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":0.19178301,"hits":[{"_index":"medcl","_type":"doc","_id":"1","_score":0.19178301,"_source":{"name":"hello world"}}]}}% 

可以看到,所有的请求,不管是集群的操作,还是索引的增删改查都可以,而 Elasticsearch 自带的 CCS 是只读的,只能进行查询。

访问 v7 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v7:/
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Kibana 里面访问

完全没问题,有图有真相:

Jietu20211016-114041.jpg

其他操作也类似,就不重复了。

完整的配置

path.data: data
path.logs: log

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7

router:
  - name: my_router
    default_flow: cross-cluster-search

elasticsearch:
  - name: v2
    enabled: true
    endpoint: https://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: https://192.168.3.188:9206

小结

好了,今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了,希望大家周末玩的开心。😁

集群中gateway.*参数有不同值会导致什么结果?

回复

Elasticsearchmedcl 回复了问题 • 2 人关注 • 1 个回复 • 2387 次浏览 • 2017-07-24 10:59 • 来自相关话题

极限网关入门视频教程已发布

Elasticsearchmedcl 发表了文章 • 4 个评论 • 772 次浏览 • 2021-11-21 11:41 • 来自相关话题

录制了一系列视频教程,介绍极限网关的使用,不断更新中,第一次做 up 主,记得一键三连,支持一下。:) 
    极限网关地址:
录制了一系列视频教程,介绍极限网关的使用,不断更新中,第一次做 up 主,记得一键三连,支持一下。:) 
    极限网关地址:

使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求

Elasticsearchmedcl 发表了文章 • 7 个评论 • 1533 次浏览 • 2021-10-16 11:31 • 来自相关话题

使用场景

如果你的业务需要用到有多个集群,并且版本还不一样,是不是管理起来很麻烦,如果能够通过一个 API 来进行查询就方便了,聪明的你相信已经想到了 CCS,没错用 CCS 可以实现跨集群的查询,不过 Elasticsearch 提供的 CCS 对版本有一点的限制,并且需要提前做好 mTLS,也就是需要提前配置好两个集群之间的证书互信,这个免不了要重启维护,好像有点麻烦,那么问题来咯,有没有更好的方案呢?

😁 有办法,今天我就给大家介绍一个基于极限网关的方案,极限网关的网址:。

假设现在有两个集群,一个集群是 v2.4.6,有不少业务数据,舍不得删,里面有很多好东西 :)还有一个集群是 v7.14.0,版本还算比较新,业务正在做的一个新的试点,没什么好东西,但是也得用 :(,现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据,程序员懒得很,懂得都懂。

集群信息

  • v2.4.6 集群的访问入口地址:192.168.3.188:9202
  • v7.14.0 集群的访问入口地址:192.168.3.188:9206

这两个集群都是 http 协议的。

实现步骤

今天用到的是极限网关的 switch 过滤器:

网关下载下来就两个文件,一个主程序,一个配置文件,记得下载对应操作系统的包。

定义两个集群资源

elasticsearch:
  - name: v2
    enabled: true
    endpoint: https://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: https://192.168.3.188:9206

上面定义了两个集群,分别命名为 v2v7,待会会用到这些资源。

定义一个服务入口

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 1000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

这里定义了一个名为 my_es_entry 的资源入口,并引用了一个名为 my_router 的请求转发路由,同时绑定了网卡的 0.0.0.0:8000 也就是所有本地网卡监听 IP 的 8000 端口,访问任意 IP 的 8000 端口就能访问到这个网关了。

另外老板也说了,Elasticsearch 用 HTTP 协议简直就是裸奔,通过这里开启 tls,可以让网关对外提供的是 HTTPS 协议,这样用户连接的 Elasticsearch 服务就自带 buffer 了,后端的 es 集群和网关直接可以做好网络流量隔离,集群不用动,简直完美。

为什么定义 TLS 不用指定证书,好用的软件不需要这么麻烦,就这样,不解释。

最后,通过设置 max_concurrency 为 1000,限制下并发数,避免野猴子把我们的后端的 Elasticsearch 给压挂了。

定义一个请求路由

router:
  - name: my_router
    default_flow: cross-cluster-search

这里的名称 my_router 就是表示上面的服务入口的router 参数指定的值。

另外设置一个 default_flow 来将所有的请求都转发给一个名为 cross-cluster-search 的请求处理流程,还没定义,别急,马上。

定义请求处理流程

来啦,来啦,先定义两个 flow,如下,分别名为 v2-flowv7-flow,每节配置的 filter 定义了一系列过滤器,用来对请求进行处理,这里就用了一个 elasticsearch 过滤器,也就是转发请求给指定的 Elasticsearch 后端服务器,了否?

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7

然后,在定义额外一个名为 cross-cluster-search 的 flow,如下:

  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow

这个 flow 就是通过请求的路径的前缀来进行路由的过滤器,如果是 v2:开头的请求,则转发给 v2-flow 继续处理,如果是 v7: 开头的请求,则转发给 v7-flow 来处理,使用的用法和 CCS 是一样的。so easy!

对了,那是不是每个请求都需要加前缀啊,费事啊,没事,在这个 cross-cluster-search 的 filter 最后再加上一个 elasticsearch filter,前面前缀匹配不上的都会走它,假设默认都走 v7,最后完整的 flow 配置如下:

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7              

然后就没有然后了,因为就配置这些就行了。

启动网关

假设配置文件的路径为 sample-configs/cross-cluster-search.yml,运行如下命令:

➜  gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd
[10-16 11:00:52] [INF] [app.go:228] initializing gateway.
[10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0
[10-16 11:00:52] [INF] [api.go:260] api listen at: https://0.0.0.0:2900
[10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]
[10-16 11:00:52] [INF] [entry.go:225] auto generating cert files
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available
[10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: https://0.0.0.0:8000
[10-16 11:00:53] [INF] [app.go:309] gateway is running now.

可以看到网关输出了启动成功的日志,网关服务监听在 https://0.0.0.0:8000

试试访问网关

直接访问网关的 8000 端口,因为是网关自签的证书,加上 -k 来跳过证书的校验,如下:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000  
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

正如前面配置所配置的一样,默认请求访问的就是 v7 集群。

访问 v2 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:/    
{
  "name" : "Solomon O'Sullivan",
  "cluster_name" : "es-v246",
  "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",
  "version" : {
    "number" : "2.4.6",
    "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",
    "build_timestamp" : "2017-07-18T12:17:44Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.4"
  },
  "tagline" : "You Know, for Search"
}

查看集群信息:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:_cluster/health\?pretty
{
  "cluster_name" : "es-v246",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 5,
  "active_shards" : 5,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 5,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

插入一条文档:

➜  loadgen git:(master) ✗ curl-json -k   https://localhost:8000/v2:medcl/doc/1 -d '{"name":"hello world"}'
{"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}%  

执行一个查询

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:medcl/_search\?q\=name:hello                
{"took":78,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":0.19178301,"hits":[{"_index":"medcl","_type":"doc","_id":"1","_score":0.19178301,"_source":{"name":"hello world"}}]}}% 

可以看到,所有的请求,不管是集群的操作,还是索引的增删改查都可以,而 Elasticsearch 自带的 CCS 是只读的,只能进行查询。

访问 v7 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v7:/
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Kibana 里面访问

完全没问题,有图有真相:

Jietu20211016-114041.jpg

其他操作也类似,就不重复了。

完整的配置

path.data: data
path.logs: log

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7

router:
  - name: my_router
    default_flow: cross-cluster-search

elasticsearch:
  - name: v2
    enabled: true
    endpoint: https://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: https://192.168.3.188:9206

小结

好了,今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了,希望大家周末玩的开心。😁

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

Elasticsearchtianqi 发表了文章 • 7 个评论 • 2885 次浏览 • 2020-12-19 16:46 • 来自相关话题

本文主要分享一下大神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:  # 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大神后续的精彩表演,让我们拭目以待。

极限网关 INFINI Gateway 初体验

Elasticsearchliaosy 发表了文章 • 3 个评论 • 4931 次浏览 • 2020-12-09 00:57 • 来自相关话题

最近在elasticsearch足球社区看到medcl大神写的一篇文章《Elasticsearch 极限网关测试版本发布》,在es外层接了一个极限网关gateway,所有的请求先走网关,再到es。gateway能提供索引级别的限速限流,降低重复请求,缓存常见查询,起到查询加速的效果等等很多特性。看着很强大的样子,赶紧下载体验了一下。 下载 下载地址: 找到当前最新版1.1.0_SNAPSHOT
image_(1).png
根据自己的操作系统环境选择相应的包下载,本人用的是Macbook,选择了GATEWAY-darwin64.tar.gz
#切换该路径下(路径自定)
cd /Users/shiyang/code/elastic/gateway
#下载
wget 
#下载完后解压
tar -zxvf GATEWAY-darwin64.tar.gz
#解压后能看到两个新文件,一个可执行二进制文件,一个yml配置文件
ls
#gateway-darwin64   gateway.yml
安装部署 在run之前需要先运行elastisearch,否则会报错,如图所示:
image_(1).png
接下来先启动es集群(如果你本地还没有部署es,建议先参考官网的下载部署) 本机用的es版本为7.9.0,如下图表示启动es成功:
image_(2).png
接下来再启动gateway,yml配置文件可以先默认,后续可根据需要再修改。
#启动 
./gateway-darwin64
启动成功如下图所示:
image_(3).png
成功启动后,我们就可以直接访问gateway了。
curl 
image_(4).png
到此,gateway就算本地部署完毕了。 是不是很简单?嗯,下载即使用,简单方便。 (接下来可以试用一下gateway的特性了。将发布在下一篇文章。)