在微服务架构中我们可以：

Netflix 在 Netflix API 重新设计中使用了第二种风格。我们可以肯定地说，他们在其架构中创建了一个智能中间件，承担了多种职责。
但是这个单一的 API 后端能处理多少工作，似乎很容易成为瓶颈。

所以我的问题是，选择单个 API 来处理超过 1000 个客户端的请求，而不是创建专门为一种类型的客户端设计的 API 网关有什么好处？他们在管理和维护这个复杂的部分时是否面临许多挑战？

这完全取决于您的最终用户在哪里，如果是 Netflix，他们有不同类型的客户端、网络/移动/流媒体棒/蓝光播放器/什么不是，而网络(一直更新到最新)、移动(最终更新到最新版本)，例如预装应用程序的蓝光播放器可能永远不会更新。

您必须为每个平台相应地对您的 api 进行版本控制，并根据客户端更新周期对其进行维护，以实现向后兼容性。如果您在单个 api 中有太多变化，则很难维护，相反，为每种类型的客户端编写一个 api 会更容易。除非您真正需要#3 并且有足够的资源来为每种类型的客户端进行开发，否则我不会跳入其中，因为您必须为同一目的维护许多 api 变体。

我会从 #1 开始。