架构
本文档介绍了为确保协作服务器本地部署顺利运行，应准备的基础设施的推荐架构。
以下设置是推荐的，但不是强制性的。我们努力使协作服务器本地部署易于运行，但同时也注重其可扩展性。因此，应用程序可能在单个服务器上作为单个实例运行，也可能在多个服务器上作为多个实例运行。
# 概述
在基础设施级别，可以区分两层。第一层是 应用层，用于运行作为 Docker 镜像提供的应用程序。第二层负责所有数据，是 数据库层。应用层与数据库层通信 - 应用层中运行的任何服务器都可以从数据库层检索数据。
这种分层架构是出于安全原因推荐的。应用层中的服务器暴露于公共访问。但是，数据库应在单独的层中运行，即在单独的服务器上，最好在限制外部流量的不同子网中。应仅允许应用层中运行的应用程序访问数据库。 应用层。
# 应用层
应用层中的基础设施包括应用服务器和负载均衡器。
在每个应用服务器上，都应该能够运行作为 Docker 镜像提供的应用程序。为此，建议使用容器编排器来进行集群，例如 Docker Swarm、Kubernetes 等。这样，就可以在多个应用服务器上运行和管理应用程序的多个实例。
当然，可以使用各种云提供商提供的容器编排来运行应用程序，例如 Amazon Elastic Container Service、 Azure Kubernetes Service 或 Google Kubernetes Engine。
由于所有应用程序数据都存储在 数据库层 中，因此可以将每个请求或套接字连接重定向到应用程序的其他实例。这样，如果一个实例发生故障，应用程序仍然对所有用户可用。为了实现这一点，需要在应用程序服务器之前运行负载均衡器。负载均衡器应配置为将请求和连接重定向到所有应用程序服务器。
建议
- 在应用层中，至少有 2 台服务器，并且每个服务器上应该至少运行 2 个应用程序实例。
- 负载均衡器配置为使用轮询算法。
- 负载均衡器需要支持 WebSocket 连接。请参阅您的负载均衡器文档以验证是否支持 WebSocket。某些流行的基于云的负载均衡器解决方案（例如 AWS 的经典负载均衡器）不允许 WebSocket 连接，不能用于协作服务器本地部署。
# 数据库层
数据库层包含 2 个数据库。
第一个数据库 Redis 用于存储协作中使用的临时数据 - 数据通常会在一段时间后被删除。该数据库还用于扩展应用程序。Redis 对于扩展是必要的，因为每个用户都可以连接到应用程序的不同实例。在这种情况下，通过 WebSocket 连接传递到一个应用程序实例的消息必须传递到应用程序的其他实例。通过使用此数据库，应用程序不需要了解其他应用程序实例，因为 Redis 处理将消息传递到所有实例。由于这种行为，不需要其他复杂且难以启动的组件。
数据库层中的下一个数据库是 SQL（目前支持 MySQL 和 PostgreSQL 数据库）。该数据库用于保存必须永久保存的数据，而不仅仅是在编辑文档时需要的数据，例如注释。
由于不同公司内部政策的不同，我们决定采用一种方法，即对数据库层的基础设施提出最少的要求。
应用程序只需要提供访问数据和数据库所在的服务器地址。数据库要求可在 需求 部分找到。因此，数据库可以通过任何方式运行 - 作为在单独服务器上的原生安装、使用任何云提供商的数据库或使用 Docker 容器。
您应该特别注意确保保存在 SQL 数据库中的数据安全且始终可用。
如果使用 Docker 镜像来提供 SQL 数据库，则数据必须在容器重启后可用。
建议
- 数据库不应公开可用。
- 准备并测试备份机制。
# 示例
为了帮助我们的客户构建稳定且安全的服务，我们创建了一组现成的 IaC 脚本，以更快地设置协作服务器。您可以将此存储库用作构建自己的基础设施的指南，采用推荐的配置，并使用最佳实践。您还可以使用这几个简单的步骤，将协作服务器本地部署部署到您选择的任何基础设施提供商。
该脚本将使用多个实例初始化基础设施，设置负载均衡器和数据层。它将自动获取并运行应用程序。
查看以下示例以了解更多信息
如果您有任何问题，请随时 联系我们。