我正在build立一个Flask / uswgi Web服务器。 我仍然想知道微服务架构：
我应该把nginx还是Flask与uwsgi放在一个容器中，还是放在两个不同的容器中，然后连接起来？
我打算在Kubernetes集群中运行这些服务。
谢谢
简短的回答：
我将部署nginx和uwsgi / flask应用程序作为单独的容器。 这为您提供了一个更灵活的架构，允许您将更多的微服务容器链接到nginx实例，以满足您对更多服务增长的需求。
说明：
使用docker的通常策略是将nginx服务和uwsgi / flask服务分成两个独立的容器。 然后你可以使用链接链接他们两个。 这在码头世界里是一种常见的建筑理念。 像docker-compose这样的工具简化了运行多个容器并在它们之间形成链接的管理。 以下docker-compose配置文件显示了一个例子：
version: '2' services: app: image: flask_app:latest volumes: - /etc/app.cfg:/etc/app.cfg:ro expose: - "8090" http_proxy: image: "nginx:stable" expose: - "80" ports: - "80:8090" volumes: - /etc/app_nginx/conf.d/:/etc/nginx/conf.d/:ro links: - app:app 这意味着如果你想添加更多的应用程序容器，你可以通过链接将它们连接到同一个ngnix代理。 另外，如果你想升级你的基础设施的一部分，比如说升级nginx，或者从apache转移到nginx，那么你只需要重新构建相关的容器，然后把所有的部分留在原地。
如果你想将两个服务都添加到一个容器中（例如通过从Dockerfile入口点启动supervisord进程），那么你可以更容易地选择使用socks文件而不是IP的nginx和uwsgi进程之间的通信，但是我不认为这是一个足够强大的理由，把两个在同一个容器。
另外，考虑一下，如果最终你最终运行了20个微服务，并且每个运行着每个自己的nginx实例，这意味着你现在有20套nginx（access.log / error.log）日志来跟踪20个容器。
如果您正在使用“微服务”架构，这意味着随着时间的推移，您将会添加越来越多的容器。 在这样一个生态系统中，将nginx作为一个单独的docker进程运行，并将微服务连接到它，使其更容易与您的扩展需求相一致。
关于服务发现的说明
如果容器运行在同一个主机上，那么连接所有的容器很容易。 如果容器运行在多个主机上，使用Kubernetes或者Docker群集，那么事情可能会变得更复杂一些，因为你（或者你的集群框架）需要能够把你的DNS地址和你的nginx实例连接起来，而docker容器需要能够“找到”彼此 – 这增加了一些概念的开销。 Kubernetes通过将容器分组到容器，定义服务等来帮助你实现这一点。
Docker的理念是在容器中使用微服务。 过去几年来，“微服务Microservice Architecture ”（ Microservice Architecture这个术语出现了，它描述了一种将软件应用程序设计成independently deployable services套件的特殊方式。
这uwcgi ，你可以在一个单独的容器中部署uwcgi ，并受益于microservices architecture 。
microservices architecture一些优点是：
如果你在你的Flask / uwsgi服务器前面使用Nginx，你使用Nginx作为代理：它负责转发到服务器的流量，最终照顾TLS加密，也许认证等等。
使用像Nginx这样的代理服务器的目的是为了能够平衡流量到服务器：Nginx代理接收请求，并在多个服务器之间分配负载。
这意味着你需要一个Nginx实例，以及Flask / usqgi服务器的一个或多个实例作为“上游”服务器。
要做到这一点，唯一的办法是使用单独的容器。
请注意，如果您位于云提供商（如AWS或GKE）（它提供负载平衡器以将您的外部流量引入您的Kubernetes集群），并且您仅使用Nginx转发流量（即，不将其用于TLS或auth），那么你可能甚至不需要Nginx的代理服务器，但可以使用一个代理服务。 添加Nginx只是给你更多的控制。