Python中的“图像服务Web框架”？

我正在计划一个iOS应用程序，该应用程序需要服务器后端，该服务器后端必须能够有效地提供图像文件并根据其获得的请求执行一些动态操作（例如，对数据存储区进行读写，例如Redis）。我最满意，因此更喜欢用Python编写后端。

我看过很多Python Web框架/服务器选项，包括Flask，Bottle，static和Tornado。共同的思路似乎是它们要么仅出于开发时的方便性而支持提供静态文件，要么不鼓励在生产中使用它，或者它们是高效的静态文件服务器，但并没有真正面向类似动态框架的方面。这并不是说它们不能充当后端，但是乍一看，他们似乎都有点尴尬。

简而言之，我需要一个专门提供JPEG而不是生成HTML的Web框架。我可以肯定没有这种东西存在，但是现在我希望有人可以提出一个可行的解决方案，而不会以不适合的方式弯曲使用过的Python应用程序。

规格和实际要求

我要提供给客户端的图像位于浅目录层次结构的文件系统中。客户端将看不到实际的文件名。服务器实际上将在启动时读取目录层次结构，为每个文件分配一个数字ID，并将请求路由到控制器方法，然后该控制器方法实际为映像文件提供服务。以下是客户端在不同情况下希望访问图像的方式的一些示例：

随机（例如URL路径：/image/random） 随机地，每个文件只有一次（/image/random_unique），在文件耗尽时会生成一些合适的非200 HTTP状态代码 依次在任一方向（/image/0，/image/1，/image/2等） 等等。此外，还将有URL端点，用于收视率，图像信息和其他元数据以及一些特定于客户端的信息（客户端将在服务器上“注册”，因此也需要一些逻辑）。该数据最有可能存在于Redis数据存储中。

总而言之，后端需要擅长提供image / jpeg和application / json（它们也会生成）。可伸缩性和并发性要求适中，至少从一开始就是要考虑的（这不是App Store应用，而是临时或企业分发）。

我不希望该应用程序依赖重定向。也就是说，我不希望有一个模型，其中对URL的请求将返回重定向到另一个URL的重定向，该URL由例如nginx作为单独的静态文件服务器支持，仅保留Python后端的图像选择逻辑。相反，来自客户端的URL请求应始终返回image / jpeg，并在必要时在自定义HTTP标头中包含元数据。我指定它是因为这是一种避免从我想到的Python提供静态文件的方式，而其他人也可能会想到;-)

有了这些信息，您会认为哪种解决方案是一个不错的选择，为什么？还是我需要为现有项目的非平凡的扩展编写代码？