rest - 公共(public)API架构

Question

我一直在致力于一个数据透明度项目，其中一项举措是使用 API 提供对我们数据的访问。到目前为止，我们决定使用 API Manager 平台来公开和管理所有 API。 API网关(由平台提供)将控制所有请求。

我们现在的主要疑问是，公共(public) API 应该如何构建？其架构应该如何规划？例如(非常简化的示例):

(1)复制生产数据库:

(2)不复制生产数据库:

在情况(1)(复制)中，我如何处理实时数据？例如:公交车位置？

对于情况(2)，我可能有什么顾虑？ (性能、安全性...)

我一直在尝试寻找著名的公共(public) API 案例(例如 twitter API)，但我还没有找到任何有关公共(public) API 架构和实现的信息。

Answer 1

我认为首先应该建立几个条件。

1。您的生产不会(不应该)与您的 API 分开。

大多数公司都以某种方式使用他们拥有的外部 API。他们为什么不呢？它是可靠的/被监控的/分布式的/负载平衡的，所以它将是一个很好的服务。他们可能有这些 API 的一些内部版本用于测试/发布环目的，但主要是他们的前端将构建在您可以调用的同一堆栈上。因此，您不应该将 API 与您的生产中的 API 完全分开。在当今时代，它实际上只是系统的一部分。

2。数据库复制

这两个图对我来说看起来都不正确。顶部的一个看起来不正确，因为您显式地从另一个实例读取，而底部的一个看起来不正确，因为您没有复制。现在，复制是一个非常冗长的主题 - 简短的教训是您绝对应该进行复制。查看此链接以查看复制数据的不同类型的一致性:https://en.wikipedia.org/wiki/Consistency_model 您必须在这里做出一些权衡，但作为一个例子，取决于您的负载和负载模式；您可以复制您的数据库，允许您的读取是多区域的，写入是单区域的，并且您的业务层 - 这也使您的 API 能够部署到多个区域。 (前提是你有足够的流量)

3。设计问题

这存在一些设计问题，但让我们先解决您的问题。

In case (1) (Replicating), how may I deal with real time data? For example: Bus Location?

• 查看不同的一致性类型并选择最适合您的服务的一种。
• 您理想的实时体验是什么？这是一个 map 应用程序，您将公交车位置的通知推送到设备/或者您是否期望用户连接并查询以查看下一趟公交车的时间？根据您的需求，您可能会在此处做出不同的设计决策。 (而且我非常怀疑您的总线位置将来自数据库)尽管它们都没有真正影响复制，但一致性+读/写比率和整体负载/负载模式在本案。

In case (2), what kind of concerns I may have? (performance, security...)

您不应该使用情况 2。

我认为您应该首先确定用户和系统的要求。仅通过这些图表来设计也非常困难，因为我们无法真正知道我们是为本地区域还是为全局系统设计该系统。理想情况下，您应该对所有内容都有冗余(因此，多个服务器为网络流量提供服务/多个数据库/多个 CDN 用于静态内容等。)，这样您将获得更高的服务质量和更小的失败机会。有时，甚至整个云服务区域都会因自然灾害而瘫痪/因此跨不同区域进行复制是一个好主意，但您的系统可能并不真正需要它。在所有情况下，您的公共(public) API 都不应该与您的生产分开。