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倍以上，使用网关进行查询优势巨大特别明显。



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

[尊重社区原创，转载请保留或注明出处]
本文地址：http://elasticsearch.cn/article/14188