Skip to main content

学习使用Web应用体系架构

分类:  Azure指南 ◆ 标签:  #Azure #基础 #Azure Cloud Architecting #Azure入门 ◆ 发布于: 2023-05-28 10:16:11

我们之前学习了《Azure入门 1-10》主要介绍Azure的一些基本工具和知识，从本章开始我们会的持续学习Azure的开发基础知识，希望能够帮助大家快速的了解和学习Azure, 本章先介绍Web应用的体系架构。

我们先来参考一张图，这张图主要是使用Azure App Service和Azure SQL Database作为应用开发的架构。


如果你需要更详细的参考，可以从这里下载visio 文档：https://arch-center.azureedge.net/app-service-reference-architectures.vsdx

对于上述图中的架构，我们主要包括了如下的Azure资源：

  • Azure App Service Plan 和一个 Azure App Service
  • Azure SQL Database
  • Azure Key Vault :用户存储安全高的密钥或者配置值，例如Database Connection String
  • Azure Monitor: 用于日志收集处理，监控，以及报警。

部署实例

为了更为直观的参考这个结构，我们也提供了一个Azure ARM 模板，可以快速的利用该模板帮助里部署上述我们提到的所有的资源。我们之前的文章有提过如何使用模板进行部署，如果不记得可以再回去参考一下，我们这里使用Azure Cli来做实例进行部署：

创建资源组(Resource Group)

先创建一个资源组:

az group create --name basic-web-app --location Chinaeast2

注意在这之前已经登录了Azure, 并且设定默认的订阅，关于这个部分如何处理，请参考文档：登录Azure

创建完资源组使用，使用如下的命令通过模板创建资源：

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

当然您可以使用如下的链接直接创建:https://docs.microsoft.com/en-us/samples/mspnp/samples/basic-web-app-deployment/

架构描述

当前这个架构包括下述的组件：

  • App Service Plan(Azure应用计划): Azure应用计划提供虚拟机给用户托管应用，需要注意的是使用同一个应用计划的应用都运行在同样的虚拟机实例上。
  • App Service App(Azure应用): Azure App Service(Azure应用服务)是一个全托管的平台(PaaS服务), 主要用于创建和部署云应用。
  • Deployment Slot(部署槽): 部署槽允许你预发布应用，并且非常方便的将预发布环境和产线环境切换。这样可以避免直接发布到产线环境，仅仅只有在预发布上完成了测试，才能切换到产线环境上。
  • IP 地址: Azure应用服务使用公网地址和域名或者自定义域名来访问该服务。
  • Azure DNS: Azure DNS 为用户提供DNS解析服务，用户也可以自定义域名：https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-custom-domain-name
  • Azure SQL Database: Azure提供的关系型数据库。除了可以使用SQL Database, 还可以选用Azure Database for MySQL以及Azure Database for PostgreSQL。这些服务都是全托管服务。

Web应用的最佳实践

每个用户可能面临着不同的需求，可以考虑使用下述的最佳实践进行调整。

App应用计划

使用Free(免费)定价层和Shared定价层用于测试，这个两个定价层和其他的用户共享资源和不能进行扩展，如果是在产线上建议使用Basic, Standard, 以及Preminu定价层，在这些定价层上，应用运行在独立的虚拟机上，而且可以扩展。另外注意的是Service Plan按照使用来收费的。

如果要估计使用的费用，可以参考这里:https://docs.microsoft.com/en-us/azure/app-service/overview-hosting-plans#how-much-does-my-app-service-plan-cost

另外需要注意的是Standard和Preminum定价层支持横向扩展，自动缩放以及支持SSL, 这个两个定价层支持更多的实例，以及更多的Core和内存。可以随意的更改这些资源。更详细的信息请参考：https://azure.microsoft.com/pricing/details/app-service

由于Service Plan收费按照实例来收费，如果您仅仅是停止了App应用，由于实例还存在，所以还是会被收费，建议如果不使用了可以删除Service Plan。

SQL Database

需要注意的是SQL Database使用逻辑服务组使得管理员的任务会比较简单，在逻辑分组中的每个数据库都是有具体的定价层。虽然在同一个逻辑分组，但是每个数据库之间并不共享资源，同时对于Server来讲，是没有费用的，但是你必须指定数据库的定价层，因此数据库的性能由于是独立的资源，会比较好。但是费用也会相应的增高。

SQL Database有Basic, Standard以及Premium几种定价层，同时衡量数据库性能的主要单位使用DTU(Database Transaction Units), 应用切实的注意该指标。

Tips
最好将应用服务和SQL Database放在同一个区域，这样会大大减少网络延迟。

可缩放需要考虑的因素

由于Azure应用服务最大的好处就是可以非常方便的根据应用的负载进行缩放，不过在缩放的时候还是考虑一些因素。

有两种缩放形式：

  • 横向扩展(Scale Up): 所谓横向扩展在Azure应用服务中，我们使用实例来进行横向扩展，例如原本只有1一个实例，可以多添加几个实例，这是横向扩展，同时我们需要注意运行应用的还是虚拟机。
  • 纵向扩展(Scale Out): Azure应用服务每个定价层都使用不同的虚拟机类型，每个虚拟机类型的Core, 内存等等都不一样，纵向扩展就是使用不同类型的虚拟机，也就是有不同的计算核心，不同的内存等等。

关于缩放你可以使用手动缩放，其实质就是改变实例的个数。同时您可以使用自动缩放，自动缩放可以参考：https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-scale

Azure应用服务缩放的最佳实践：

  • 尽量避免过多的缩放以及不必要的缩放，因为缩放可能会触发应用重启，应该在应用部署上线之前，尽可能的使得应用符合你的实际使用量。
  • 启用自动缩放。
  • CPU的使用量是一个非常好的衡量指标，如果要使用自动缩放完全可以根据CPU的指标来判定是否需要缩放。
  • 使用自动缩放时要考虑一个cool-down的周期，cool-down是指在缩放操作完成之后，到开始另外一个新的缩放动作之间最好要等待的时间。设定cool-down时间非常有利于系统的稳定。添加新的实例设定一个短一点的cool-down时间，例如5分钟。但是移除实例要设定一个长一点的cool-down时间， 例如60分钟。

SQL Database的缩放：

如果你需要一个高性能的SQL Database, 你可以无缝的scale up一个独立的数据库:https://docs.microsoft.com/en-us/azure/sql-database/sql-database-single-database-scale

可用性需要考虑的因素

需要注意的是Azure提供的服务保障是不同的，而且肯定不会是100%。 Azure应用服务目前的服务保证(SLA)是99.95%， 而SQL Database是99.99%（Basic, Standard, Premium), 还是有一定的机率会影响可用性的。

备份

为了放置数据丢失，SQL Databasa提供了根据时间点的恢复和Geo恢复(Geo-Restore), 所有的定价层都是支持这些特性，而且是自动启用。因此你无需自己规划或者管理备份。关于恢复，请参考：

Azure应用服务的备份和恢复请参考:https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-backup

其他更细节的说明，您可以参考一下文档：https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/basic-web-app?tabs=cli