API 设计 - 拆分成不同的子域（微服务）

Question

我们的应用程序基于 API 优先架构，目前基于单个域/服务：

api.todos.com

API 的使用者是：

• 我们的网络前端
• 我们的移动应用程序
• 其他业务/公众

我们将为同一个应用程序构建用不同语言编写的新微服务。例如，我们可能会为以下对象开发 API 服务：

• 统计数据
• 博客/内容
• RSS 提要
• 搜索

我的问题是关于处理域。最好将每个服务拆分为不同的子域，例如

• api.todos.com
• stats.todos.com
• content.todos.com
• rss.todos.com
• search.todos.com

或者最好有一个统一的 API 域，我们在其中执行 HTTP（第 7 层）路由以到达我们的端点。例如

• api.todos.com/todos
• api.todos.com/stats
• api.todos.com/content
• api.todos.com/rss
• api.todos.com/search

不确定哪个更适合公共 API？拥有多个子域会更容易，而不必处理中间路由层/代理。

Answer 1

作为系统架构师，我认为it is better to have a single unified API domain where we do HTTP (layer 7) routing to reach our endpoints。您可以使您的系统更加灵活，而无需对您的客户进行任何更改。例如，您有一个带有路由的微服务：

• api.todos.com/route1
• api.todos.com/route2

以后你可以通过这个路由拆分微服务。

但大多数情况下，这取决于您将使用什么 API 网关。 API 网关是您系统中的单一入口点，用于纠正微服务的代理请求。它还进行身份验证和缓存。有关此微服务模式的更多信息，您可以阅读here。