我想知道是否有人可以就我基于网络的API（我们使用Microsoft堆栈）的问题分享他们的想法。
我们目前正在构建一个基础架构，以便在我们的业务中托管Web apis。
作为一个组织，我们拥有独立的业务领域，为客户提供服务。我们业务的这些个别领域通常拥有自己最好的IT系统。提供API是我们一直在思考的问题，我们已经开始设计过程。
我们打算提供的API应该是基于网络的（.NET / webAPI / WCF等），并且在很大程度上（99％）将在我们的组织内消费，但如果需求出现，有些可能会在将来暴露在外部（新的）移动应用可能需要使用服务等。）
我很想听听你对如何构建你的农场的想法和经验。我理解这是一个非常开放的问题，但不了解我们要求的骗子，而是我想听到的更一般的建议/经验。
特别是我们试图决定是否应该通过以下方式设计基础设施：
1）为企业的每个区域提供自己的API服务器，我们将在IIS内部的新应用程序中部署每个Web API。
或
2）建立一个负载平衡的web api服务器场，我们说2/3 iis web服务器，都是相同的，托管相同的web apis，但业务区域将有效地共享同一个服务器。每个区域都有一个iis内的隔离站点，新的API应在各自网站内的新应用程序下设置。
我没有预见到我们有成千上万的API，但有些会对业务产生重要影响，所以我当然会考虑到弹性，这就是为什么我喜欢每个业务领域都有自己的API服务器，我正在朝着这个方向发展。选择拥有一个负载均衡的农场，整个企业共享。
任何人都有任何想法，经历等等。
谢谢！
答案 0 :(得分：0)
这是一个非常有趣的问题，我很想听听其他人的想法。我不是大专家，但这是我的两分钱。
在我看来，答案应该介于你指定的两个选项之间。具体而言，每个关键业务领域都应该拥有自己的弹性负载平衡服务器场，而不太关键的服务可以利用单机部署。关键业务领域可能并不仅仅意味着一个API，但实际上可以是一组API，它们之间具有高内聚性。
完全使用选项1环境可能难以维护， 在完全使用选项2的情况下，如果业务逻辑发生变化（或者更好，何时），则在重新部署方面可能效率低下。此外，我认为贪婪的API有可能在高峰流量中占用资源，使其他服务临时性能降低（除非你有某种动态扩展机制）。