如何构建 API 服务应用架构

Question

背景：

我正在构建一个 API 服务应用。该应用程序与其他应用程序一样，您发送 HTTP 请求并接收响应。这似乎很简单，直到我开始考虑用户注册、支付、身份验证、日志记录等。

应用：

tl;博士simple app diagram

端点监听 HTTP 请求并执行所有与请求相关的工作。这是服务的核心，服务用户使用这个应用程序的目的。最终用户无法直接访问（除非它知道 url）。 Python 烧瓶服务器，部署在谷歌云 RUN 上。

API 网关 充当代理和将请求转发到端点的单个访问点。这是最终用户的服务接入点。这部分还将负责身份验证、限制、记录和跟踪 API 端点的使用。 Python 烧瓶服务器，部署在谷歌云 RUN 上。

网站包括文档、演示和通过 API 网关展示 API 调用、注册、支付（考虑 Stripe）等。谷歌云计算 VM 上 NodeJS 服务器上的 VueJS 应用程序。

数据库存储注册用户的凭据、支付信息和授权密钥。尚未实施。

问题：

1. 这种架构合适吗？可以做些什么不同或改进？如何进一步简化应用程序各个部分之间的所有交互？我没有遗漏任何重要的部分吗？

2. 还没有实现数据库部分，我不确定我应该做什么 采用？有很多options on google cloud。我也可以做一些简单的事情，只需在谷歌云计算虚拟机上安装一个带有 http/JSON 接口的数据库。我如何选择数据库？考虑到这样的应用，最好的选择是什么？

3. 请推荐类似应用的文献/博客/其他信息来源 不熟悉的新开发者的架构？

Answer 1

这是一个非常开放的结局，但这里有一些通用的 cmets：

想想你的 UI 将如何工作。您是在设置直接从云存储提供的静态应用程序，还是需要在服务器上呈现某些内容？就我个人而言，我更喜欢尽可能将 UI 与 API 分离，但您需要了解诸如搜索引擎优化之类的事情。即使您需要动态呈现某些内容，您的网站仍然可以是静态的。看看像 Gatsby 这样的静态站点生成器。多年来我不必实现服务器渲染的 UI，这让我很高兴。

API 网关可能没问题，但你真的不需要它来做任何事情。在没有它的情况下开始并专注于真正重要的事情可能会更简单。如果您的 API 被外部客户端调用，则无论如何您都不能信任这些调用，并且您可能使用的任何 API 密钥都将被公开。我会说不要担心单个应用程序。话虽如此，如果您确实想使用 GW 那就使用一个，请注意它主要是一个美化的代理，而不是您架构的核心部分。

确保您的 API 实现不存储任何本地状态，以便您可以依靠 Cloud Run 来扩展和缩减您的服务。 绝对不要将状态直接存储在您的容器中。如果您需要服务器上的状态，则它需要在一些外部数据存储中。

使用 JWT 或外部 IDM（将生成 JWT）进行身份验证。尽可能将会话数据保留在客户端，并在每个 API 调用中传递 JWT 以对调用者进行身份验证。如果您自己实现登录，则您需要在没有令牌的情况下公开的唯一 API 是用于身份验证和密码恢复，您可以将其分离到它们自己的服务中。

数据库的选择取决于您对流程的了解程度、服务的事务性以及您现有的技能组合。总的来说，我会使用你喜欢的东西，你可能会在很多事情上取得成功。某些 NoSQL 风格表面上看起来很简单，但如果您对需要运行的查询类型没有清楚的了解，那么使用它们可能会变得乏味。一般来说，你应该坚持使用关系数据库来实现 OLAP 风格，并考虑 NoSQL 来实现 OLTP。就我个人而言，我喜欢 MongoDB，它非常受欢迎，可能是因为它处于中间位置，这使得它适合很多应用程序。使用 MongoDB 还可以让您与云无关，因为它在每个平台上都可用。使用特定于平台的数据库风格可能会将您锁定在特定的供应商上。

无论你做什么，都不要开始在虚拟机上安装东西。如果出现这种情况，你几乎可以 100% 确定你做错了。请记住，您使用的服务不必全部由 Google 管理，甚至不必在 GCP 上运行。您可以直接从 MongoDB 获取 MongoDB 容量，后者代表您管理所有 Big3 云供应商。

至少要考虑长期，即使您现在不一定需要让它影响您的架构。如果您希望您的应用程序能够运行多年，请尝试使其与平台无关。这可能意味着放弃一些真正特定于平台的无服务器功能，这些功能将迫使您多跳几圈。如果您使用 Cloud Run，您使用的容器已经使您的应用非常便携，请不要通过使用许多特定于平台的功能将其锁定在一个平台上。话虽如此，也不要远离他们。您应该始终追求唾手可得的成果，因此不要试图避免使用秘密管理器等。如果您的应用程序的生命周期很短，并且您需要非常快的上市时间，那么请不要担心。

只是我的 2c，你所做的非常通用，可以通过很多不同的方式来完成。