Wcf 设计Web API基础设施的建议

我想知道是否有人可以分享他们对我关于基于web的API（我们使用Microsoft stacks）的问题的想法

我们目前正在构建一个基础设施，以便在我们的业务中托管web API

作为一个组织，我们拥有为客户提供服务的独立业务领域。我们业务的各个领域通常都有自己最好的IT系统。提供API是我们长期以来一直在思考的问题，我们已经开始了设计过程

我们打算提供的API应基于网络（.NET/webAPI/WCF等），并且大部分（99%）将在我们的组织内使用，但如果需要，一些API将来可能会暴露在外部（新的移动应用程序可能需要使用服务等）

我很想听听你的想法和经验，看看你是如何设计your农场的。我理解这是一个相当开放的问题，不了解我们的要求，但它更一般的建议/经验，我想听听

特别是，我们正试图通过以下方式决定是否设计基础设施：

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

或

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

我不认为我们会有数千个API，但有些API将是业务关键型的，所以我一定要牢记弹性，这就是为什么我非常喜欢每个业务领域都有自己的API服务器，但我倾向于选择拥有一个负载平衡的服务器场，整个业务都共享这个服务器场

有人有什么想法、经历等吗

---

谢谢

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

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

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