探索 Azure SQL 的监控、调试与 DevOps 实践
1. 监控与调试工具的价值
在开发和生产阶段,监控、调试和故障排除是至关重要的环节。有一个非常全面且实用的工具,能在这两个阶段为你提供有力的支持。你可以在官方文档 Application Insights 中获取详细信息。
监控应用程序是关键步骤,但和调试一样,常常被忽视。当出现问题需要解决时,其价值就会凸显出来,拥有的数据越多越好。通常,系统的透明度越高越好,这样你可以深入到各个层面,找到问题所在。Azure SQL 是目前最具透明度的数据库之一,动态管理视图(DMVs)能提供详细信息,必要时甚至能精确到单个执行线程。这意味着,若出现意外情况,你或微软的客户支持服务(CSS)能获取所需的所有信息来查找并解决问题。
以下是一些有助于深入了解 Azure SQL DMVs 的资源:
- Glenn Berry’s DMVs: https://glennsqlperformance.com/resources/
- sp_WhoIsActive: http://whoisactive.com/
- sp_Blitz: www.brentozar.com/blitz/
- Tiger toolbox: https://github.com/Microsoft/tigertoolbox
此外,还有一些关于 SQL Server 的学习资源:
| 资源名称 | 链接 |
| — | — |
| Query Store for SQL Server 2019: Identify and Fix Poorly Performing Queries | www.amazon.com/Query-Store-SQL-Server-2019/dp/1484250036 |
| Expert Performance Indexing in SQL Server 2019: Toward Faster Results and Lower Maintenance | www.amazon.com/Expert-Performance-Indexing-Server-2019/dp/1484254635 |
| Pro SQL Server 2019 Wait Statistics: A Practical Guide to Analyzing Performance in SQL Server | www.amazon.com/Pro-Server-2019-Wait-Statistics/dp/1484249151 |
| SQL Server 2017 Query Performance Tuning: Troubleshoot and Optimize Query Performance | www.amazon.com/Server-2017-Query-Performance-Tuning-ebook/dp/B07H49LN75 |
2. DevOps 与 CI/CD 概念
DevOps 是一门将人员、流程和产品结合起来的学科,旨在实现向最终用户持续交付价值。它有助于弥合开发、运营和管理之间的差距。对于开发者来说,DevOps 中最重要的方面之一是拥有健康的 CI/CD 管道。
- 持续集成(CI) :持续推送和合并对解决方案代码库所做的更改,使其能与团队其他开发者的更改集成、测试和验证。此过程会使用自动化工具来构建和测试解决方案,以实现无缝且高度自动化。目标是拥有一个健康且经过测试的代码库,几乎随时可以投入生产。
- 持续部署(CD) :处理将新代码部署到生产环境的过程,使这个微妙而关键的过程更自动化、可重复且不易出错。目标与持续集成相同,但从部署过程的角度出发。即使代码库中的代码运行完美,将其部署到生产环境也并非易事,持续部署能确保组织随时部署最新的、经过测试且可运行的代码。
可以看出,DevOps、CI/CD 以及敏捷原则是现代开发的基石。对于现代开发者来说,从一开始就采用 DevOps 原则无疑是最佳实践,如今已成为一种普遍的行为。
3. CI/CD 在 Azure SQL 中的应用
将 DevOps 应用于数据库更具挑战性,因为数据库只有部分是代码,大部分是数据。那么,测试数据库意味着什么?如何处理数据?如何在不损害现有数据完整性和性能的情况下持续部署和发展数据库?目前尚无明确且被广泛接受的答案。DevOps 学科相对年轻(2009 年首次正式提及),其在数据领域的应用更是如此,因此在定义一套全球公认的最佳实践之前,还有很多需要学习的地方。不过,有一些工具可以提供帮助,下面介绍 GitHub Actions 和 Azure DevOps 在 Azure SQL 中的应用。
- GitHub Actions :GitHub 是最流行且广泛使用的代码仓库,提供了众多免费功能,其中 GitHub Actions 专为 DevOps 设计。它允许你直接从仓库实现 CI/CD 管道,通过一系列小任务(即操作)创建自定义的软件开发生命周期。这些操作可以通过自定义工作流进行组合和编排,涵盖构建、测试和部署解决方案的各个方面。除了 GitHub 提供的原生操作外,还有一个市场,GitHub 社区开发的操作可以在此发布,供任何人使用以满足各种需求。微软发布了一个免费的 Azure SQL 特定操作,允许开发者在自动化工作流中向目标 Azure SQL 数据库部署更新。GitHub Actions 市场链接: https://aka.ms/ghmas 。借助 Azure SQL 部署操作,你可以创建一个工作流,在有人将代码推送到仓库后,将脚本部署到目标 Azure SQL 数据库,运行你配置的测试,并通知你结果。
- Azure DevOps :Azure DevOps 是一套功能齐全的产品,可支持团队处理 DevOps 的各个方面。它包括与 git 兼容的代码仓库、用于构建和发布生成的解决方案的管道、用于自动化测试的测试工具集、用于本地管理包的工件存储库,以及用于确保工作得到正确跟踪、分配和监控的敏捷规划和问题跟踪系统。如果是新项目且团队规模较小,Azure DevOps 是不错的选择,因为前五个用户是免费的。将代码推送到 Azure DevOps 源代码仓库后,你可以指示构建管道将 Azure SQL 代码部署到指定的 Azure SQL 数据库。管道可以使用不同的任务来定义代码推送到仓库时要执行的步骤,其中 Azure SQL 数据库部署任务可用于将提供的 T-SQL 脚本部署到目标 Azure SQL 数据库。
4. 数据库迁移挑战与解决方案
在 CI/CD 管道中处理数据库变更时,主要挑战是在部署现有数据库的更改时,可能需要保留数据库中已有的数据,尤其是生产数据库。扩展架构(如添加新列)通常比较简单,但更改现有数据使用的架构则具有挑战性,无论采用读时架构还是写时架构。实际上,并不存在无架构的解决方案,Martin Fowler 在其演讲中明确指出了这一点,并引入了隐式架构的概念。
为了解决这些挑战,可将 CI/CD 管道分为两个部分,针对不同用例创建两个管道:
- 合成环境管道 :用于确保对数据库所做的所有更改都在合成环境中进行测试。该环境每次都会从头创建数据库,其中包含的数据集是已知的,代表了预期要管理的数据,还包括可能导致意外情况的数据。随着从测试人员或用户那里收到反馈和问题,应不断向该数据集中添加新数据,以帮助避免回归错误和问题。此管道的步骤如下:
1. 创建新数据库。
2. 部署架构和对象。
3. 加载参考数据集。
4. 运行测试。
graph LR
A[创建新数据库] --> B[部署架构和对象]
B --> C[加载参考数据集]
C --> D[运行测试]
- 集成环境管道 :如果合成环境中的所有测试都成功执行且无错误,则可以开始执行更复杂的管道。此管道的主要目标是确保用于将现有架构和数据更新到新架构的脚本正确无误,并在预期时间内运行。这需要一个生产数据库的副本,但出于安全原因,可能无法访问包含敏感数据的生产数据库。你可以选择获取一个经过数据混淆处理的生产数据库副本,或者在高度安全的环境中,使用一个可以填充模拟数据的空生产数据库。有一些工具和库可以生成模拟但逼真的数据,例如:
- Faker:适用于 .NET 和 Python(也适用于 PHP、Perl 和 Ruby)
- Mimesis:Python 库
- MockNeat:Java 库
- Faker.js:Node.js 库
- Bogus:Faker.js 的 .NET 端口
集成环境管道的步骤如下:
1. 恢复参考数据库。
2. 生成将参考数据库迁移到目标架构并更新现有对象,同时保留现有数据所需的 T-SQL 代码。
3. 运行生成的脚本。
4. 运行测试以验证结果。
graph LR
E[恢复参考数据库] --> F[生成 T-SQL 代码]
F --> G[运行生成的脚本]
G --> H[运行测试以验证结果]
5. 数据库迁移工具 - Code First 方法
生成将数据库从现有架构迁移到另一个架构的脚本,可根据采用的开发理念(Code First 或 Database First)涉及不同的步骤和技术。这里重点介绍 Code First 方法。
Code First 意味着直接通过应用程序代码驱动数据库的创建、更改和发展,无需手动执行 T-SQL 脚本,也无需使用 SQL Server Management Studio 或 Azure Data Studio 等单独工具。以下是一些采用 Code First 方法的示例:
- Django :一个广泛使用的 Python 框架,用于构建 Web 应用程序。数据模型的定义完全在 Python 中完成,例如:
class Member(models.Model):
"""A model of a rock band member."""
name = models.CharField("Member's name", max_length=200)
instrument = models.CharField(choices=(
('g', "Guitar"),
('b', "Bass"),
('d', "Drums"),
),
max_length=1
)
band = models.ForeignKey("Band")
要创建数据库,可使用以下命令:
python manage.py makemigrations
python manage.py migrate
需要注意的是,这种方法假设数据库没有手动进行外部更改。例如,如果有人在未使用提供的工具的情况下手动向要迁移的数据库添加了列,迁移可能会失败,因为它不检查对象的当前状态,只是假设数据库的架构与上次迁移时相同。
-
SQLAlchemy :如果你只需要一个对象关系映射器(ORM)用于任何 Python 应用程序,SQLAlchemy 通过 Alembic 包也支持迁移。
-
.NET Core :通过 Entity Framework(.NET Core 自带的原生工具)支持 Code First 和迁移。创建 .NET 模型后,例如:
namespace AzureSQLForDevelopers
{
public class BloggingContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
public DbSet<Post> Posts { get; set; }
[...]
}
public class Blog
{
public int BlogId { get; set; }
public string Url { get; set; }
public int Rating { get; set; }
public List<Post> Posts { get; set; }
}
}
需要生成并应用迁移步骤,命令如下:
dotnet ef migrations add FirstMigration
dotnet ef database update
此外,虽然自动化很棒,但在某些情况下,可能需要手动干预迁移过程以满足特定需求。幸运的是,大多数常见的 Code First 解决方案都提供了自定义迁移步骤的方法,无论使用何种语言和框架,都能满足你进行初始化数据库数据或进行更复杂更改的需求。
探索 Azure SQL 的监控、调试与 DevOps 实践
6. 数据库迁移策略总结
不同的数据库迁移方法各有优劣,以下是对前面提到的合成环境和集成环境管道以及 Code First 方法的总结对比:
| 迁移策略 | 适用场景 | 优点 | 缺点 | 关键步骤 |
| — | — | — | — | — |
| 合成环境管道 | 对数据库变更进行初步测试,验证不同数据情况下的处理逻辑 | 能模拟各种数据情况,提前发现潜在问题,构建有价值的参考数据集 | 需要维护参考数据集,创建数据库和加载数据有一定时间成本 | 1. 创建新数据库;2. 部署架构和对象;3. 加载参考数据集;4. 运行测试 |
| 集成环境管道 | 在接近生产环境的条件下,验证数据库变更脚本的正确性和性能 | 能确保变更在生产环境中的可行性,减少生产故障风险 | 需要获取生产数据库副本或模拟数据,操作相对复杂 | 1. 恢复参考数据库;2. 生成 T - SQL 代码;3. 运行生成的脚本;4. 运行测试以验证结果 |
| Code First 方法 | 通过应用程序代码驱动数据库创建和变更 | 代码与数据库紧密结合,便于管理和维护,自动化程度高 | 对数据库手动更改兼容性差,迁移失败风险高 | 不同框架步骤不同,如 Django:python manage.py makemigrations;python manage.py migrate;.NET Core:dotnet ef migrations add FirstMigration;dotnet ef database update |
7. 数据模拟工具对比
在集成环境中,需要模拟生产数据,以下是几种常见数据模拟工具的对比:
| 工具名称 | 支持语言 | 特点 |
| — | — | — |
| Faker | .NET、Python、PHP、Perl、Ruby | 支持多种语言,通用性强,能生成常见类型的模拟数据 |
| Mimesis | Python | Python 专用库,提供丰富的数据生成功能,可定制性高 |
| MockNeat | Java | 专为 Java 设计,简单易用,能快速生成模拟数据 |
| Faker.js | Node | Node 环境下的模拟数据生成工具,适合前端和后端开发 |
| Bogus | .NET | Faker.js 的 .NET 端口,方便 .NET 开发者使用 |
8. 实际应用中的注意事项
在实际应用 Azure SQL 的监控、调试和 DevOps 实践时,有以下几点需要注意:
- 数据安全 :在使用生产数据库副本或模拟数据时,要确保数据的安全性。对于包含敏感信息的生产数据库副本,要进行数据混淆处理,防止信息泄露。
- 自动化测试的完整性 :无论是合成环境还是集成环境的测试,都要确保测试用例的完整性。不仅要测试正常数据情况,还要考虑异常数据和边界条件,以保证数据库变更的稳定性。
- 手动干预的时机 :虽然自动化是 DevOps 的重要目标,但在某些复杂情况下,手动干预是必要的。要明确何时需要手动干预,并制定相应的流程和规范。
- 持续学习和改进 :DevOps 和数据库迁移技术都在不断发展,要持续关注行业动态,学习新的方法和工具,不断改进自己的开发和运维流程。
9. 未来发展趋势
随着技术的不断进步,Azure SQL 的监控、调试和 DevOps 实践也将呈现以下发展趋势:
- 智能化监控 :利用人工智能和机器学习技术,实现对 Azure SQL 数据库的智能监控。系统可以自动分析性能数据,预测潜在问题,并提供优化建议。
- 无代码 DevOps :未来可能会出现更多无代码或低代码的 DevOps 工具,降低开发者的技术门槛,使更多人能够参与到数据库的持续集成和持续部署中。
- 数据治理与合规性 :对数据治理和合规性的要求将越来越高。DevOps 流程将更加注重数据的安全性、隐私性和合规性,确保数据库操作符合各种法规和标准。
- 跨平台和多云支持 :随着企业采用多平台和多云战略,Azure SQL 的 DevOps 工具将提供更好的跨平台和多云支持,方便在不同环境中进行数据库管理和迁移。
10. 总结
Azure SQL 的监控、调试和 DevOps 实践是现代数据库开发和运维的重要组成部分。通过有效的监控和调试工具,可以及时发现和解决数据库问题,提高系统的稳定性和性能。而 DevOps 中的 CI/CD 管道和数据库迁移策略,则能确保数据库的持续更新和发展,同时保证数据的完整性和安全性。
在实际应用中,要根据具体的业务需求和技术栈,选择合适的工具和方法。例如,对于小型项目,可以优先考虑 GitHub Actions 的便捷性;对于大型团队和复杂项目,Azure DevOps 的全面功能可能更适合。同时,要重视数据模拟和测试,以及手动干预和持续学习的重要性。
未来,随着技术的发展,我们可以期待更智能、更便捷的 Azure SQL 管理和运维方案,帮助企业更好地应对不断变化的业务需求。希望本文能为你在 Azure SQL 的开发和运维实践中提供有价值的参考和指导。
超级会员免费看
17

被折叠的 条评论
为什么被折叠?



