创建成熟的 API 需要资源,包括时间和金钱。你需要考虑模型、设计、REST 原则等方面的东西。大多数情况下,你不知道这样做是否值得:你只是想要做出一个最小可行性产品,然后基于这个产品开始迭代。现在,我想向你展示如何在不编写一行代码的情况下实现它。
解决方案
解决方案的主要要求是使用 PostgreSQL 数据库,这是一个功能完善的开源 SQL 数据库。我们不编写 REST API,而是使用 PostgREST 组件。
备注:PostgREST 是一个独立的 Web 服务器,可以将 PostgreSQL 数据库直接转换成 REST API。数据库的结构约束和权限决定了 API 有哪些端点和操作。—— PostgREST 官网
我们将在一个简单的场景中使用它。下面是一张我想通过 CRUD API 暴露出来的 product 数据表。

PostgREST 的入门指南(
https://postgrest.org/en/stable/tutorials/tut0.html)提供了完整的内容,不过我没有找到现成的 Docker 镜像,所以自己创建了一个。
Dockerfile:

1.基于最新的 Debian。
2.参数化构建。
3.获取二进制包。
4.安装依赖项并解压二进制包。
Docker 镜像的/postgrest 文件夹中有一个 postgrest 可执行文件。我们可以通过 Docker Compose 来“部署”。
docker-compose.yml:

1.构建上面的 Dockerfile。
2.共享配置文件。
3.运行 postgrest 可执行文件。
4.使用配置文件。
5.初始化 Schema、权限和数据。
这个时候,我们可以查询 product 表:
curl localhost:3000/product
我们会立即得到结果:
[{"id":1,"name":"Stickers pack","description":"A pack of rad stickers to display on your laptop or wherever you feel like. Show your love for Apache APISIX","price":0.49,"hero":false},
{"id":2,"name":"Lapel pin","description":"With this \"Powered by Apache APISIX\" lapel pin, support your favorite API Gateway and let everybody know about it.","price":1.49,"hero":false},
{"id":3,"name":"Tee-Shirt","description":"The classic geek product! At a conference, at home, at work, this tee-shirt will be your best friend.","price":9.99,"hero":true}]
真是立竿见影!
改进解决方案
虽然这个解决方案是有效的,但还有很大的改进空间。例如,虽然用户不能修改数据,但每个人都可以访问到它。对于产品相关的数据,这可能不是一个大问题,但对于医疗数据呢?PostgREST 文档提到了这个问题,并明确建议使用反向代理:
备注:PostgREST 是快速构造 REST API 的一种方法,默认情况下非常适合用于构建开发脚手架。它也可以进入到生产环境,只要你需要采取一些预防措施。PostgREST 只是一个用于实现 API 到数据库映射的小工具,我们需要依靠像 Nginx 这样的反向代理来提供额外的安全性保障。—— PostgREST 官网
不过我们没有使用 Nginx,而是一个成熟的 API 网关——Apache APISIX。我们把它添加到 Docker Compose 中。
docker-compose.yml

1.使用 Apache APISIX。
2.APISIX 将配置存储在 etcd 中。
我们先配置 Apache APISIX,用它来代理对 postgrest 的调用:

1.应该运行在其中一个 Docker 节点上,因此使用 Docker 镜像名称。或者也可以使用 localhost,但一定要公开端口。
2.创建可重用的上游。
3.指向 PostgREST 节点。
4.创建到上游的路由。
现在,我们可以通过 APISIX 来查询端点:
curl localhost:9080/product
它返回与之前相同的结果。
DDoS 攻击保护
我们还没有加入任何东西,不过我们已经做好准备了。我们首先需要保护 API 免受 DDoS 攻击。Apache APISIX 是基于插件架构而设计的,为了防止 DDoS 攻击,我们将使用一个插件。我们可以在创建路由时设置插件,也可以在每个路由上设置插件。如果是第二种情况,就变成了全局规则。我们希望默认保护每一个路由,因此我们将使用第二种方式。

1. limit-count 限制一个时间窗口内的调用次数。
2. 限制为每 5 秒调用 1 次,这只是为了演示。
3. 返回“429 Too Many Requests”,默认值为 503。
现在,如果我们发送了太多请求,Apache APISIX 会保护上游:
<!-- 堆代码 duidaima.com -->
curl localhost:9080/product
<html>
<head><title>429 Too Many Requests</title></head>
<body>
<center><h1>429 Too Many Requests</h1></center>
<hr><center>openresty</center>
</body>
</html>
路由授权
PostgREST 还提供了一个 root 的 Open API 端点,因此我们有两个路由:/用于遵循 Open API 规范,/product 是产品的相关端点。假设我们想禁止未经授权的人访问我们的数据,即普通用户可以访问产品信息,admin 用户可以访问 Open API 规范和产品信息。
APISIX 提供了几种身份验证方法。我们将使用最简单的 key-auth。它依赖了消费者抽象,key-auth 需要一个特定的标头:插件对标头中的值进行反向查找,并找到对应的消费者。
下面演示如何创建一个消费者:

1.创建新的消费者。
2.消费者的名字。
3.消费者的键值。
我们也为消费者 user 和键 user 做同样的事情。现在,我们可以创建一个路由并配置它,只让来自 admin 的请求通过:

1.创建一个新的路由。
2.使用 key-auth 和消费者限制插件。
3.只有管理员认证的请求才能调用路由。
我们来尝试一下:
curl localhost:9080
无法调用,因为我们没有通过 API 标头进行身份验证:
{"message":"Missing API key found in request"}
curl -H "apikey: user" localhost:9080
也无法调用,因为我们使用了 user 的身份,但路由只授权给了 admin 身份。
{"message":"The consumer_name is forbidden."}
curl -H "apikey: admin" localhost:9080
这一次,它像预期的那样返回 Open API 规范。
监控
任何一个软件系统都有一个被低估的特性,那就是监控。在将组件部署到生产环境中后,我们就必须监控其运行状况。现在,我们有许多服务可用于监控。我们将使用 Prometheus,因为它是开源的,经过了实战的考验,并已被广泛使用。为了显示监控数据,我们将使用 Grafana。我们把组件添加到 Docker Compose 文件中。
docker-compose.yml

1.Prometheus 镜像。
2.Prometheus 的配置。可以在这里(https://github.com/ajavageek/poor-man-api/blob/master/prometheus/prometheus.yml)查看完整的文件。
3.Grafana 镜像。
4.Grafana 的配置。其中大部分来自 APISIX 提供的配置(https://github.com/apache/apisix/blob/master/docs/assets/other/json/apisix-grafana-dashboard.json)。
5.将默认端口 3000 改为 3001,避免与 PostgREST 服务冲突。
有了监控基础设施之后,我们只需要 APISIX 按照 Prometheus 期望的格式提供数据即可。我们可以通过配置和一个新的全局规则来实现。
config.yaml

1.绑定到任意地址。
2.绑定到 9091 端口。Prometheus 的指标信息可参考http://apisix:9091/apisix/prometheus/metrics。
我们可以创建全局规则:
/* 堆代码 duidaima.com */
curl http://apisix:9080/apisix/admin/global_rules/2 -H 'X-API-KEY: 123xyz' -X PUT -d '
{
"plugins": {
"prometheus": {}
}
}'
发送几个查询并打开 Grafana 仪表板,看起来应该像这样:
结论
创建一个完整的 REST API 是一项巨大的投资。我们可以通过 PostgREST 将数据库暴露成 CRUD API,进行快速简单的测试。当然,这样的架构并不适用于生产环境。
要解决这个问题,我们需要在 PostgREST 前面设置一个门面,可以是反向代理或 API 网关。Apache APISIX 提供了很多特性,包括授权和监控等。有了它,我们就可以用较低的成本快速验证 API 需求。在验证了需求后,我们可以保留现有的门面,并用定制开发的 API 替换 PostgREST。