设计 Web API 基础架构的建议

Question

我想知道是否有人可以就我关于基于 Web 的 API（我们使用 Microsoft 堆栈）的问题分享他们的想法..

我们目前正在构建基础架构以在我们的业务中托管 Web API。

作为一个组织，我们有独立的业务领域，为我们的客户提供服务。我们业务的这些单独领域通常都有自己最好的 IT 系统。提供 API 是我们长期以来一直在考虑的事情，并且我们已经开始了设计过程。

我们的目标是提供基于 Web 的 API（.NET/webAPI/WCF 等），并且大部分 (99%) 将在我们的组织内部使用，但如果未来出现需求，一些可能会在外部公开（新移动应用程序可能需要使用服务等）

我很想听听您对如何构建您的农场的想法和经验。我理解这是一个相当开放的问题，但不了解我们要求的骗局，但我想听听它更一般的建议/经验。

特别是我们正在尝试决定是否应该通过以下方式设计基础设施：

1) 为业务的每个领域提供自己的 API 服务器，我们将在 IIS 内的新应用程序中部署每个 Web API。

或

2) 建立一个负载平衡的 web api 场，我们说 2/3 iis web 服务器，所有构建相同，托管相同的 web api，但业务领域将有效共享同一服务器。每个区域在 iis 中都有一个隔离的站点，新的 API 应在各自网站内的新应用程序下设置。

我预计我们不会拥有数千个 API，但其中一些对业务至关重要，因此我当然会牢记弹性，这就是为什么尽管我喜欢每个业务领域都有自己的 API 服务器，但我还是倾向于拥有一个由整个企业共享的负载平衡场的选项。

有人有什么想法、经验等吗？

谢谢！

Answer 1

这是一个非常有趣的问题，我很想听听其他人的想法。我不是专家，但这是我的两分钱。

在我看来，答案应该介于您指定的这两个选项之间。具体来说，每个关键业务领域都应该拥有自己的弹性负载平衡农场，而不太关键的服务可以利用单机部署。关键业务领域可能不仅仅意味着一个 API，而实际上可以是一组 API，它们之间具有很高的内聚性。

完全使用选项 1 环境可能难以维护， 在充分利用选项 2 的同时，如果（或者更好的是，何时）业务逻辑发生变化，则在重新部署方面可能效率低下。此外，我认为贪婪的 API 可能会在峰值流量中占用资源，从而使其他服务暂时性能降低（除非你有某种动态扩展机制）。