试图找出可伸缩应用程序的最佳实践。
NGINX <-> ASGI（很多）<-> Starlete / FastAPI <->进程
NGINX <-> Clojure / Memcached事物<-> Starlete / FastAPI <->进程
NGINX-> Clojure / Memcached事物-> Starlete / FastAPI->进程-> NGINX
NGINX-> ASGI（许多）-> Starlete / FastAPI->进程-> ASGI（许多）-> NGINX
思维过程是...在传统方法中，您在每个应用程序之间都存在某种过程依赖关系来做出响应。在具有大量微服务的环境中（想象3层以上），您必须依靠每一个服务而不会崩溃/超时以做出响应。
ASGI应该可以提高应用程序服务器端的性能。但是，我们仍然依赖于对请求的响应，前提是所有微服务都在做它们的工作，并且没有潜在的动作或瓶颈。
如果您有办法劫持Nginx信息来存储带有唯一ID的ch，则可以将其传递给诸如memcached之类的东西，以便您可以有一种单向的信息流。不需要FastAPI机制就可以保持另一个应用程序的状态，并且想法是每个微服务都是无状态的，永远不必等待另一个应用程序的响应。
既然asgi使应用程序服务器的运行速度比传统模式快得多，那么该模型是否比传统模式有意义？
我倾向于选项4，在复制的ASGI服务器之间使用某种Memcached。这样，在处理完成后，他们可以使用nginx请求的唯一ID随机调用任何ASGI，并响应来自任何asgi的特定nginx请求。我主要关心的是..这是否会违背asgi的工作原理以使其比预期的慢？
我基本上要做的是从asgi中获取范围并将其添加到memcached实例中。然后，当某个处理节点向asgi服务器场中的某个服务器场发送请求时，它将从memcached中获取范围并创建一个等待（发送）（尽管在编写时听起来有点奇怪）知道了要发送回哪个nginx ch？否则，响应仍然取决于asgi的正常运行时间（相对于复制的memcached）。
这会提高系统的性能还是仅仅是过大？在某种程度上，我觉得它可能比传回响应的传统模型更糟糕。
谢谢