为Laravel Forge中的Laravel应用程序添加第二服务器的7个注意事项

Laravel  /  管理员 发布于 10个月前   353

为应用程序添加额外服务器时需要考虑的关键事项，我们将以托管在Laravel Forge 中的 Laravel为例，

但这些概念可以应用于任何类型的应用程序，甚至不仅限于 PHP 语言。

当前的基础架构

首先，为了确保我们说的是同一种语言，这是当前基础架构的概要。

该应用程序目前运行在由 Laravel Forge 创建的服务器上，并在 AWS 上运行。

Lets Encrypt 用于 SSL 证书；

Redis（安装在机器上）用于会话、缓存，并作为队列驱动程序用于存储和处理后台作业；

MySQL（安装在机器上）作为数据库；

本地文件夹，用于保存用户上传的内容；

每分钟使用服务器 CRON 的 Laravel 调度器；

通过点击 Laravel Forge 的 "立即部署 "按钮手动触发部署；

1. 负载平衡器

首先需要一个负载平衡器。这将是应用程序的入口点，

也就是说，你要把域名 DNS 指向负载平衡器，而不是直接指向服务器。

正如你所猜测的那样，负载平衡器的工作就是在所有健康的注册服务器之间平衡传入的请求。

从现在起，我们每次提到 "应用服务器"（App Server）时，

指的都是运行 Laravel 应用程序的单个服务器。

负载均衡器有一个很好的功能，那就是健康检查，它的作用是确保所有连接的服务器都是健康的。

如果其中一台服务器因某种原因出现故障，例如计划外维护，

负载平衡器就会停止向该服务器发送请求，直到该服务器恢复正常运行。

我们建议使用应用程序负载平衡器，如果需要，它可以提供更强大的功能。

应用程序负载平衡器可以根据请求的 URL 将流量路由到特定服务器，

甚至可以将请求路由到多个应用程序。

目前，我们将让它使用轮循方法平均分配流量。

由于你的域名现在将指向负载平衡器，你的 SSL 证书现在也应该在负载平衡器中，

而不是在你的服务器中。

2. 数据库（MySQL）、缓存和队列（Redis）

目前，有一台服务器在运行我们的应用程序、MySQL 的本地实例和 Redis。

如果第二台服务器连接到我们的负载平衡器，会发生什么情况？

如果我们的数据库和缓存层有多个真相来源，就会产生各种问题。

如果有多个数据库，用户就会在一个服务器上注册，而在另一个服务器上却无法注册。

如果每台服务器上只有一个 Redis 实例，

那么用户可以登录 App Server 1，但当负载均衡器将用户重定向到 App Server 2 时，

用户就必须重新登录，因为用户的会话存储在本地 Redis 实例中。

我们可以让应用服务器 2 或将来连接到负载均衡器的任何应用服务器连接到应用服务器 1 的服务，

但当应用服务器 1 需要停机维护或意外发生故障时该怎么办呢？

增加第二台服务器的原因之一是为了提高可靠性和可扩展性，但这并不能解决我们的问题。

当我们拥有多个应用程序服务器时，最理想的情况是让 MySQL 和 Redis 

等外部服务在单独的环境中运行。

要实现这一目标，我们可以使用托管服务（如 AWS RDS）来运行数据库，

使用 AWS Elasticache 来运行 Redis，或者使用非托管服务

（即我们自己建立一个单独的服务器来运行这些服务）。

如果成本不是问题，托管服务通常是更好的选择，因为你不必担心操作系统和软件的升级，

而且它们通常有更好的安全层。

假设我们决定

-DB_HOST=localhost
+DB_HOST=app-database.a2rmat6p8bcx7.us-east-1.rds.amazonaws.com
-REDIS_HOST=localhost
+REDIS_HOST=app-redis.qexyfo.ng.0001.use2.cache.amazonaws.com

一切就绪后，将应用程序服务器连接到我们的服务时，我们的基础架构会是这样的。

3. 用户上传内容

我们的应用程序允许用户上传自定义的个人资料图片，该图片会在登录时显示。

在我们当前的基础架构中，图片保存在应用程序的内部文件夹中，并从那里提供服务。

现在我们有多个应用服务器，这将是一个问题，

因为在应用服务器 1 中上传的图片不会出现在第二个服务器上。

有几种方法可以解决这个问题。其中之一就是在服务器之间共享文件夹（例如亚马逊 EFS）。

如果我们选择这种方法，就必须在 Laravel 中配置一个自定义文件系统，

指向应用程序服务器上的共享文件夹位置。

虽然这是一个有效的选择，但需要一定的知识来设置服务器上的磁盘，

而且每设置一个新服务器，就必须重新配置共享文件夹。

我们通常更喜欢使用云对象存储服务，比如亚马逊 S3 或 Digital Ocean Spaces。

如果你使用的是文件存储选项，Laravel 可以让你很容易地使用这些服务。

在这种情况下，你只需将文件系统磁盘配置为使用 S3，

并将之前用户上传的所有内容上传到一个桶中即可。

-FILESYSTEM_DISK=local
+FILESYSTEM_DISK=s3 
 
AWS_ACCESS_KEY_ID=your-key
AWS_SECRET_ACCESS_KEY=your-secret-access-key
AWS_DEFAULT_REGION=us-east-1
AWS_BUCKET=your-bucket-name

用户上传的所有内容都将存储在同一个集中式存储桶中。S3 具有内置的版本控制和多层冗余，

我们添加到负载平衡器的任何其他应用服务器都可以使用同一个存储桶来存储内容。

如果您的应用程序将来会增长，您可以设置 AWS Cloudfront，它可以作为 S3 存储桶顶部的 CDN 层，

以更快的速度向用户提供存储桶内容，而且通常比 S3 更便宜。

4. 队列工作者

在第 2 步中，我们设置了一个集中式 Redis 服务器，这是我们用来管理应用程序队列的技术。

这也适用于我们的负载均衡应用程序，但还有一些不错的选择可供探索。

如果继续利用集中式 Redis 实例在应用服务器上处理队列，则无需进行任何更改。

作业将由有 Worker 可用来处理作业的服务器接收。

另一种方法是使用 AWS SQS 等服务，它可以通过将工作负载卸载到其他服务来减轻 Redis 实例的压力。

5. 调度命令

在负载平衡器后面运行多台服务器时，默认情况下，

调度命令将在连接到负载平衡器的每台服务器上运行，这并不是最佳选择。

多次运行相同的命令不仅会浪费处理能力，还可能导致数据完整性问题，这取决于该命令要做什么。

Laravel 有一个内置的方法来处理这种情况，通过链式 onOneServer() 方法，

使你的计划命令只在单个服务器上运行。

$schedule->command('report:generate')
    ->daily()
    ->onOneServer();

6. 部署

在部署应用程序时，您现在有很多选择和需要考虑的事情。

我们仍然可以使用以前的方法部署应用程序，但现在必须确保记得在两台服务器上都点击部署按钮。

如果忘记了，我们的服务器就会运行不同版本的应用程序，这可能会导致巨大的问题。

如果有多台服务器，可能就需要提高部署策略的级别了。

现在有一些非常不错的部署工具和服务，比如 Laravel Envoyer 或 PHP Deployer。

通过这些工具和服务，你可以在多台服务器上自动完成部署过程，从而避免人为错误。

如果我们想在部署过程中更进一步，因为我们现在有两个应用程序服务器，

其中一个最大的好处是，我们可以暂时从负载平衡器中移除其中一个服务器，该服务器将停止接收请求。

这样，我们就可以实现零停机部署，即从负载平衡器中移除第一台服务器，部署新代码，

将其放回负载平衡器，然后移除第二台服务器，并再次执行相同的过程。

服务器 2 完成部署后，两台服务器都将拥有新代码并连接到负载平衡器。

要实现这一目标，我们需要使用 AWS CodeDeploy 等工具，但其设置要比之前的方案复杂得多。

部署是我们应用程序的一个非常重要的流程，

因此如果我们能使用 Github Actions 或任何 CI/CD 服务实现自动化部署，我们就能大大改进流程。

让部署流程变得简单，让任何人都能触发部署，这才真正体现了开发团队和应用程序的成熟度。

7. 网络与安全

使用负载平衡器的另一个好处是，我们的服务器不再是网站的入口。

这意味着我们的服务器只能在内部访问和/或受特定 IP（我们的 IP、负载平衡器的 IP 等）的限制。

由于无法直接访问，这大大提高了服务器的安全性。

我们的数据库和缓存集群也可以（而且应该）这样做。

为此，我们只允许从自己的 IP 向 22 端口传输流量（这样我们就可以通过 SSH 登录服务器），

只允许从负载平衡器向 80 端口传输流量，这样它就可以向服务器发送请求。

同样的规则也适用于我们的数据库和缓存集群。

最后的想法

在基础架构中添加额外服务器时，有很多事情需要考虑。

它增加了基础架构和工作流程的复杂性，但同时也提高了应用程序的可靠性和可扩展性，并改善了整体安全性。

如果从一开始就考虑到这些建议，那么实施起来就会很简单，而且会对改进您的应用程序产生很大的影响。

转：

https://laravel-news.com/adding-a-second-server-to-your-app