简短的答案:如果您在编写函数代码时考虑了水平缩放，则应该发现端口耗尽对总体吞吐量的影响最小.

Short answer: if you write your function code with horizontal scale in mind, you should find that port exhaustion has minimal impact on your overall throughput.

Azure Functions的使用计划与专用的应用程序服务计划完全不同.您描述的一个应用程序影响其他应用程序性能的问题在专用上是有意义的，因为所有这些应用程序都在同一组VM上运行.对于消耗计划，您的功能应用程序将根据工作负载随时间在许多不同的VM上运行.您的功能应用程序的给定实例可能会遭受端口耗尽的影响，但这将导致该实例的吞吐量降低，从而导致更多的功能应用程序实例被激活.而且，基于同一计划的多个基于消耗的功能应用程序可以并且将在不同的VM上运行，因此它们不会争用资源.

The consumption plan for Azure Functions works very differently to a dedicated App Service Plan. The problem you describe of one app impacting the performance of other apps makes sense on dedicated because all of those apps are running on the same set of VMs. For the consumption plan, your function app will run on many different VMs over time, based on the workload. A given instance of your function app might suffer from port exhaustion, but that should result in decreased throughput for that instance which in turn will result in more instances of your function app being activated. Also, multiple consumption based function apps on the same plan can and will run on different VMs and so they won't be competing for resources.

当然，在某些情况下这将无法正常工作-如果您的计时器触发器正在创建数百个出站连接，则您绝对可能会遇到端口耗尽问题，因为计时器无法扩展到多个实例.在这种情况下，答案是让您的计时器将事件添加到轻松支持横向扩展的内容中，例如队列，主题或eventhub.

Of course there are situations where this wont work - if you have a timer trigger that is creating hundreds of outbound connections you could absolutely hit port exhaustion issues because timers don't scale out to multiple instances. The answer in this case is to have your timer add events to something that easily supports horizontal scale out such as a queue, topic or eventhub.

就监视/诊断而言，情况基本上与专用情况相同(即困难).但是，正如我上面概述的那样，在消费计划中应大大减少对此的需求.如果您发现任何相反的行为，请告诉我们！

In terms of monitoring/diagnosis, the situation is basically the same as it is for dedicated (i.e. its difficult). But as I've outlined above, the need for this should be significantly diminished in the consumption plan. If you observe any behavior to the contrary, please let us know!