discuss: Routing Rules Matching

[membphis]

目前的路由实现是基于 libr3 完成的，我当时选择它是看中了他的强大和高效。几乎可完成任意规则的路由，但是他的强大也有副作用，就是上手成本相对较高。

当匹配路由时，主要有下面四种索引：

1. 以 uri 为主索引：其他字段做遍历匹配。适合场景是用户 api 的 uri 都长得不一样。目前 apisix 采用该做法。
2. 以 host 为索引：其他字段做遍历匹配。适合场景是用户 api 的分类是完全通过 host 完成的。有点像 nginx 中的 server 分类处理模型。
3. 以 host + uri 前缀索引：其他字段做遍历匹配。比如：www.foo.com/v2/{:.*}
4. 以 host + uri 正则做索引：其他字段做遍历匹配。比如：www.foo.com/v2/id/{id:\d+}

大家目前的网关规则，主要是使用的是那种呢？欢迎大家在这里留言评论。

The current routing implementation is based on libr3. It also has side effects, that is, the cost of starting is relatively high.

When matching routes, there are four main indexes:

1. Uri-based index: other fields do traversal matching. For scenarios, the URI of the user API grows differently. Apisix currently uses this approach.

2. Indexed by host: Traversal matching for other fields. Suitable scenarios are classified by user API entirely through host. It's a bit like the server classification model in nginx.

3. Index with host + URI prefix: traversal matching for other fields. For example: www.foo.com/v2/{:*}

4. Index with host + URI rule: other fields do traversal matching. For example: www.foo.com/v2/id/{id:d+}

What kind of gateway rules do you currently use? Welcome to leave a comment here.

[vkill]

先说说我这网关的使用场景吧

场景 1

记录产品 event 的项目

前期采用单机 nginx proxy_pass / 到后端服务的方式，加 nginx 只是为了 https ，https 证书用的 acme.sh 申请和 renew 的

后期为了提高成功率，在各州、部分国家开了十多个机器，使用 octodns 配置的 Geo dns

那么这样就无法在那些 proxy 上使用 nginx 了，一个是机器系统复杂（ubuntu 14、ubuntu 16、ubuntu 18都有），一个是拷贝 https 证书到各个机器上比较复杂，当然可以用 ansible/SaltStack 等完成

那就使用了 kong ，kong 就没有 https 证书更新的问题了，但是 kong 的痛点是 admin 端口得自己使用 iptables 做限制，这个 apisix 做的比较好，用了 nginx 自己的 allow 就完成了

对于这个场景，只需要一个 uri / 索引即可

场景 2

小公司的某台服务器

初期要了 项目1 ， 采用了单机 nginx proxy_pass / 到 php-fpm 服务的方式

后面要上 项目2 ， 直接 nginx 加个 server 也行，但是考虑到后面还要上项目，就改用 kong

这样一个项目，kong 上建一个 service 和 一个 route （host 为 x.example.com paths 为 /）

后面又上了 项目3

后面发现 项目1 接口 /v1/x 出现瓶颈，针对这个接口使用 go 进行了重写，然后在 kong 上新上建一个 service 和 一个 route （host 为 x.example.com paths 为 /v1/x）

对于这个场景，需要 host 做主索引，然后 uri 做二层索引

场景 3

接场景 2，后来项目1 做大了，我们迁移项目到一台新的服务器，直接装了 kong

再后来，业务需要网站接入 100 多个域名，每个域名都有公司主体

那么这个时候就变成 uri 做主索引 （/ 和 /v1/x 和 /v2 等），然后 host 不需要索引，不够这个得加上类 nginx 的 server_name _ 的处理

===========================

以上是我处理的几个线上案例，完全没有用到复杂的路由匹配

个人觉得路由能支持到 nginx 的 location / 和 location /v1 就好了，其他复杂的 location 后面挂个 nginx 处理吧

废弃正则，像正则我只在很久以前的 nginx 中写过 .js$ 这样的，后来有了 webpack/gulp 等后都使用 location /assets 了

另外之前有个需求是这样的，我需要限制某个 ip ，还有限制某个 id 的用户的访问速度，为了这两个需求我是改 nginx.conf 来实现的

那么我们是否可以设置些 filters 呢？

比如匹配 query 中的某个 key 的 value 如果在一个 数组 中，那么我们可以执行 deny / limit conn 等动作

又比如现在都用 JWT ，那么是否可以从 query 中 access_token key 或者 header Authorization 中拿出 JWT ，然后 base64 解出 payload ，payload 中某个 key 的 value 如果如果在一个 数组 中，那么我们执行 deny / limit conn 等动作

这些 filters 才是实际中常用到的，我觉得可以在这些地方挖一挖，kong 的那个自定义 script 不是个好的方案

以上。

[vkill]

接上面的 filter 来说，匹配 query 中 key 这个其实都可以结合 nginx log 来动态帮助用户完成。比如用户输入了 /v1/ 那么帮助用户动态的提示出前缀为 /v1/ 的 path，用户选择好具体的 path 后，那么给出这些 query 的 keys 等等这些。不过为了完成这个可能需要配个 Elasticsearch 或者 prometheus .