我们创建了一个使用 SQL Server 数据库的 dotnet core web api 项目，现在我们计划将该项目部署到 Microsoft Azure。在部署此应用程序时，我们还考虑启用自动缩放选项（水平缩放）。在执行之前，我们想要澄清一些问题。我们需要在应用程序中添加一些额外的代码以使自动缩放正常工作吗？"正常"意味着由于水平扩展，可能会运行多个应用程序实例。我们正在使用数据库，如果运行多个实例，那么是否会产生竞争条件（即两个资源同时访问相同的数据）？我的意思是我们可以在代码中添加事务（或使用锁定）来避免这些情况吗？我想知道在实施这种类型的应用程序时是否有任何最佳实践要遵循？谢谢并等待您的答案！
2个回答
2
设计自动伸缩策略时，请考虑以下几点：
该系统必须设计成具备水平可伸缩性。避免对实例亲和度作出假设；不要设计需要代码始终在特定的进程实例中运行的解决方案。当水平扩展云服务或网站时，不要假定来自同一来源的一系列请求始终会路由到同一实例。出于同样的原因，设计服务为无状态，避免要求应用程序的一系列请求始终路由到服务的同一实例。 当设计一个从队列中读取消息并处理它们的服务时，不要做任何关于哪个服务实例处理特定消息的假设，因为随着队列长度增加，自动缩放可以启动服务的其他实例。 竞争者消费模式 描述了如何处理这种情况。
如果解决方案实现长时间运行的任务，设计此任务支持横向和纵向扩展。如果没有谨慎处理，这样的任务可能会阻止进程实例在系统进行缩减时被正常关闭，或者在强制终止进程时丢失数据。理想情况下，重新设计长时间运行的任务，并将其执行的处理分成较小的离散块。 管道和过滤器模式 提供了一个实现这一点的示例。或者，您可以实现一个检查点机制，记录任务的状态信息，并将此状态保存在可访问任何运行任务进程实例的持久性存储中。这样，如果进程被关闭，它正在执行的工作就可以通过使用另一个实例从最后一个检查点恢复。
更多信息，请查看文档：自动缩放最佳实践。
该系统必须设计成具备水平可伸缩性。避免对实例亲和度作出假设；不要设计需要代码始终在特定的进程实例中运行的解决方案。当水平扩展云服务或网站时，不要假定来自同一来源的一系列请求始终会路由到同一实例。出于同样的原因，设计服务为无状态，避免要求应用程序的一系列请求始终路由到服务的同一实例。 当设计一个从队列中读取消息并处理它们的服务时，不要做任何关于哪个服务实例处理特定消息的假设，因为随着队列长度增加，自动缩放可以启动服务的其他实例。 竞争者消费模式 描述了如何处理这种情况。
如果解决方案实现长时间运行的任务，设计此任务支持横向和纵向扩展。如果没有谨慎处理，这样的任务可能会阻止进程实例在系统进行缩减时被正常关闭，或者在强制终止进程时丢失数据。理想情况下，重新设计长时间运行的任务，并将其执行的处理分成较小的离散块。 管道和过滤器模式 提供了一个实现这一点的示例。或者，您可以实现一个检查点机制，记录任务的状态信息，并将此状态保存在可访问任何运行任务进程实例的持久性存储中。这样，如果进程被关闭，它正在执行的工作就可以通过使用另一个实例从最后一个检查点恢复。
更多信息，请查看文档：自动缩放最佳实践。
- DixitArora-MSFT
1
关于这个问题：
适当地说，由于水平扩展，应用程序可能会有多个实例运行。我们正在使用数据库，如果有多个实例在运行，是否会导致竞争条件（即两个资源同时访问相同的数据）？我的意思是，我们可以在代码中添加事务（或使用锁定）来避免这些情况吗？
请记住，即使应用程序在单台机器上运行，请求仍将同时处理。这意味着即使在单台机器上，2个请求也可能导致数据库中的相同条目被更新。因此，上述关于竞争条件的问题也适用于单实例Web应用程序。
尽量避免锁定：（水平）扩展的整个重点是获得性能优势。通过使用锁定，您实际上消除了这些好处，因为只有一个进程可以同时使用锁定资源。
其他需要考虑的因素包括：
适当地说，由于水平扩展，应用程序可能会有多个实例运行。我们正在使用数据库，如果有多个实例在运行，是否会导致竞争条件（即两个资源同时访问相同的数据）？我的意思是，我们可以在代码中添加事务（或使用锁定）来避免这些情况吗？
请记住，即使应用程序在单台机器上运行，请求仍将同时处理。这意味着即使在单台机器上，2个请求也可能导致数据库中的相同条目被更新。因此，上述关于竞争条件的问题也适用于单实例Web应用程序。
尽量避免锁定：（水平）扩展的整个重点是获得性能优势。通过使用锁定，您实际上消除了这些好处，因为只有一个进程可以同时使用锁定资源。
其他需要考虑的因素包括：
- Peter Bons
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接