独立于后端对反应前端进行 docker 化是一种好习惯吗？

Question

我即将部署一个 React 应用程序。我的反应应用程序有一个 API。在 react 开发服务器上，它在端口 3000 上提供 react，而我的 API 在端口 4000 上。

我看到了两种解决方法。

一种方法是在开发中使用 CORS。如果我们走这条路，我们还需要在生产中使用 CORS。我们将有一个 ENV 文件，它告诉反应应用程序它应该向哪个主机/端口发出请求。我们的 CI 管道将有 2 个 docker 容器，2 个 repos。当我们部署前端或后端更改时，我们将能够独立重启两台服务器。我们将在 mysite.com 上运行 1 个 docker，在 api.mysite.com 上运行 api。

另一种方法是使用 package.json 中的代理并将所有请求转发到我们的后端。即不必向localhost:4000/sign-in 提出请求，我们只需向/sign-in 提出请求。通过这种方法，我认为使用 monorepo 很有意义。我们会有

app
  api/
    my-api
  ui/
    my-react-app

我的 api 将主要是 RESTful 路由，但对于所有非 api 路由，这些路由将提供一个 HTML 文件，该文件将为 javascript 提供服务。 CI 管道将构建和最小化并将 JS 推送到 S3 并为其命名，例如 {SHA1}.min.js，我们的 API 的 index.html 文件将具有

<script src=`{SHA1}.min.js`></script>

我似乎无法决定更好的方法。能够独立部署前端和后端会更简单吗？是否不需要一个只提供一个 html 文件的 docker ？我们应该走哪条路？

Answer 1

注意：此问题没有正确答案（或可能有多个）：这取决于您的环境和您的经验。

在您的应用构建期间，不仅 JS 可能会发生变化。也许您更改了您的网站图标，或可安装的徽标或清单中的其他一些细节，或其他一些资产，如 CSS。因此，部署前端不仅仅是将 JS 部署到 S3 并更改初始 HTML 中的 SHA。

除此之外，使用基本的 NGinx/Apache（可能在 CDN 之后）可以非常快速地提供静态数据。但是您的后端可能需要进行一些计算，从硬盘访问一些数据库或一些数据文件。这是一种不同的工作方式，因此拆分两个部署是一个好主意。它还允许根据需要进行不同的扩展。

无论您是使用单个入口（1 个域）还是将其拆分为两个（2 个域），我认为这只是您感觉更舒服的方式和您的规模方法的问题。从前端访问api.yoursite.com/ 或yoursite.com/api/ 并没有太大区别。

• 使用同一域，捕获/api/ 请求以将它们代理到后端。其余的请求直接提供或代理到具有静态的第二个网络服务器。如果只是代理东西，你可以使用 HAProxy 或 Træffick 代替，它们的性能可能比 NGinx 或 Apache 更好。
• 使用不同的域允许删除第一个代理，这非常快/便宜，但可能允许以不同的方式扩展（例如，将更多公共 IP 添加到 api.yoursite.com 以实现-缓慢-扩展）。李>

如您所见，有几个变量：例如，使用 docker-compose 部署到单个服务器、部署到 Kubernetes 集群或 AWS 的自动缩放组是非常不同的。如果您希望每天获得 100 次访问，这与处理数十亿活跃用户大量访问您的数据库的情况也大不相同。