根据https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed-processor上的下图，至少有 4 个分区键范围分布在两台主机之间。我在这张图中难以理解的是主机和消费者之间的区别。在 的上下文中Azure Functions，是否可以说主机是Function应用程序而消费者是活动/温暖的实例？
我想创建一个包含 N 多个Function应用程序的设置，每个应用程序都有 0-200 个活动实例（取决于工作负载）。同时，我想阅读Change Feed。如果我CosmosDBTrigger在每个应用程序中使用具有相同连接字符串和租用容器的 a，这是自动处理还是需要手动实现？
您链接的文档主要用于更改馈送处理器，但 Azure Functions 绑定实际上在下面运行更改馈送处理器。
仅使用 CFP 时，可能更容易理解，因为您主要控制实例和分布，但我会尝试将其映射到 Functions。
该文档提到了一个部署单元的概念：
单个更改源处理器部署单元由一个或多个具有相同处理器名称和租用容器配置的实例组成。您可以拥有许多部署单元，其中每个部署单元都有不同的更改业务流程，并且每个部署单元都包含一个或多个实例。
例如，您可能有一个部署单元，只要您的容器发生更改，就会触发外部 API。每次发生变化时，另一个部署单元可能会实时移动数据。当您的受监控容器发生更改时，您的所有部署单元都会收到通知。
Functions 中的部署单元是 Function App。一个 Function App 可以跨越多个实例。因此，该 Function App 部署中的每个实例/主机都将充当可用的主机/消费者。
再往下，这篇文章讨论了动态扩展，它所说的基本上是，在一个部署单元（功能应用程序）内，租约将得到均匀分布。因此，如果您有 20 个租约和 10 个 Function App 实例，那么每个实例将拥有 2 个租约并独立于其他实例处理它们。
那篇文章的一个重要说明是，缩放可以实现更高的 CPU 池，但不一定是更高的并行度。
正如文档所提到的，即使在单个实例上，CFP 也会处理并读取它在独立任务上拥有的每个租约。问题是，所有这些并行处理都共享同一个 CPU，因此如果您当前看到实例具有 CPU 线程/瓶颈，则添加更多实例会有所帮助。
现在，在您的示例中，您想要拥有 N 个功能应用程序，我假设每个应用程序都在做不同的事情。基本上，微服务部署会触发任何更改，但会执行不同的任务或触发不同的业务流程。
这另一篇文章涵盖了这一点。基本上，您可以让每个 Function App 使用单独的 Lease 集合（让受监控的集合相同），或者您可以共享租约集合，但对每个 Function App 部署使用不同的 LeaseCollectionPrefix。如果您将共享租约集合的功能应用数量较多，请检查租约集合上的 RU 使用情况，因为您可能需要增加它（文章中有说明）。