有言值:到母校读博也要学位认证
数据库

揭开 SQL 数据库服务开发的面纱

  几年前,SQL 团队发布了基于 SQL Server 的 Azure SQL 数据库服务。为了实现“云优先”的目标,我们花费了大量时间和精力来改进 SQL Server 的开发模式。经过几年的努力,新的开发模式不但使我们实现了 Azure SQL 数据库服务的快速迭代开发,并且帮助我们改进了 SQL Server 的开发和更新效率。本文将带你走进 SQL团队的开发模式内幕,回顾在过去几年中 SQL 开发模式的变化,以及了解新的开发模式如何帮助我们改进 SQL Server 的开发、发布以及更新的流程。

  在早年的 SQL Server 开发过程中,我们使用类似瀑布模型的开发流程来同步不同开发团队之间的工作。每个产品周期都花费了大量的时间进行规划和文档工作:项目经理写需求文档,开发团队写设计文档,测试团队写测试文档。在开发的过程中,又需要大量的时间进行功能之间的整合测试。因此,SQL Server 的发布周期一般在3年左右甚至更长。

  在 SQL Server 发布之后,用户往往又需要几个月甚至几年的时间来进行测试和升级,并且使用新版本中的新功能。在这种情况下,新功能从设计开发到真正应用到用户的生产环境中需要几年的时间。这要求我们在设计新功能时具有非常强的前瞻性。否则新功能在投入使用之前就可能被市场所淘汰了。

  Azure SQL 数据库作为一款云服务,要求我们大大缩短新功能从设计开发到投入使用的时间。产品团队为了实现这一目标,在开发流程中进行了几项比较大的改动:

  改进编译和测试的自动化流程。利用Azure 所提供的高扩展性,我们将整个编译测试流程迁移到云端,并在上千台服务器上分布运行,从而将整个流程的时间从几周缩短到平均几小时。

  针对SQL 提供的非常广泛的各种功能,我们在产品的整体架构上进行了改进,把整个架构分解为若干个微服务。这样个个开发团队可以分别对不同的功能进行独立的开发,大大缩短了集成以及集成测试所需的时间。

  采用更加精确的增量的方式进行开发,新功能会在每月预览版中发布,并不断进行改进。

  这些开发流程上的改进使得产品团队可以更快速的推出新功能。与传统的 3 到 5 年的发布周期相比,在最新版本的 SQL Server 2017 中,我们仅使用了 16 个月就实现了从 Windows 到 Linux 的跨平台的迁移和开发。

  在 SQL Server 2017 的开发过程中,产品团队每个月会发布一个新的预览版给用户用于早期的测试。因此,我们可以在新功能开发的过程中就获得大量的用户反馈。开发团队可以基于这些反馈来修复发现的问题,以及改进功能设计。在 SQL Server 2017 正式发布时,绝大部分功能都已经在用户真实生产环境中经过了好几轮的反复测试和验证。

  在旧的开发模式中,如果一个功能没有赶上当前版本的末班车,就要等待三年后新版本的发布。因此每次正式发布前夕总会有一些功能带有已知问题挤进了发布。在新的开发模式中,我们实现了完成即发布。如果一个功能在发布前夕发现问题,那么我们可以有充足的时间修复问题,然后在下个月的发布中再加入这个功能。

  在新的开发模式中,我们在产品规划上也做出了改进。首先,我们所做的每一项工作,所添加的每一个新功能都需要有真实的客户需求和反馈来支持,以确保我们的工作可以最大化用户的利益。和以往追求大而全的方式不同,对于每一个用户面临的问题或需求,产品架构师,项目经理和开发经理会一起寻求一个可以在短期内实现的最简方案(我们称之为 MVP,Minimum Viable Product)。开发团队先开发并发布这个最简方案,以供用户测试并提供反馈,然后根据客户的反馈不断的改进和迭代,直到功能最终成型。

  为了实现云端的 Azure SQL 数据库服务的持续开发和持续部署,产品团队决定不再从 Azure SQL 数据库以及 SQL Server 中移除已有的功能。为了实现这一目标,我们添加了大量测试用例来测试产品的向后兼容性,以保证无缝升级。

  在某些情况下,我们必须要在产品中进行一些改动而无法保证向后兼容。这种情况下,我们会主动提前联系收到影响的用户,帮助用户理解新的改动,提供迁移或替代方案,以保证用户可以顺利的使用升级后的产品。

  用户还可以通过控制数据库的兼容性级别(database compatibility level)来保证应用程序不受数据库升级的影响。在 SQL Server 和 Azure SQL 数据库中,和查询引擎相关的改进和新功能(例如自适应查询处理等)在数据库兼容性级别升级之后才会生效,而其他新功能(例如图数据库等)则在数据库版本升级后即可使用。用户可以利用这一特性来控制和避免数据库升级对查询效率性能的负面影响。用户还可以使用 Query Store 以及查询计划自动纠错等功能来降低数据库兼容性级别升级所带来的风险。

  SQL 产品团队使用在产品中收集到的计量数据(Telemetry)来改善产品质量,包括:

  所有计量数据在使用之前都进行了安全性处理,以保护用户隐私。Azure SQL 数据库服务每天会收集约 600TB 的计量数据。产品团队使用这些数据建立了大量的预警以及自动修复机制。这使得我们可以在没有任何 DBA 的情况下,管理和运行超过两百万个 SQL 数据库。产品团队还监控和分析所有的 crash dump 文件,并修复其中的问题。

  数据驱动的质量管理也同时为 SQL Server 用户带来了好处。产品团队所发现并修复的问题会自动部署到 Azure SQL 数据库以及新版本的 SQL Server 中,并且为已有的 SQL Server 版本提供持续更新。整套自动机制帮助我们更快的发现并解决问题,并通过 SQL Server 的累积更新(CU)提供给现有的 SQL Server 客户。这改变了以往用户发现问题后需要自行分析,联系微软支持团队报告问题并等待产品团队提供解决方案的流程,大大优化了用户体验。DBA 可以通过部署最新的累积更新来获得稳定性和性能的提升。

  前面提到,在 SQL Server 的开发过程中,我们利用 Azure 所提供的高可扩展性,在上千台服务器上并行运行测试。这使得我们可以比以往更频繁的运行完整的测试集。而在测试中所发现的问题,会和从 Azure SQL 数据库所收集的计量数据中发现的问题一起被修复,并增量的部署到所有的 Azure SQL 数据库中。使用这些新的机制,我们可以比以往更频繁的发布更新,并保证更新的质量可以满足客户生产环境的需求。

  从 SQL Server 2017 开始,我们将每一个月发布一次累积更新(从第二年开始每季度一次)来代替原有的 Service Pack 系统。用户将不再需要等待 SP1 来完善生产环境中的 SQL Server 部署。

  通过在 Azure SQL 数据库的开发和部署中获取的经验,我们改进了并将持续改进整个 SQL 产品线的开发和发布流程。 通过共享 Azure SQL 数据库和 SQL Server 的开发模式,我们可以更快更好的发布新版本的 SQL Server 和对现有版本 SQL Server 进行更新。我们一直致力于为客户的数据服务提供最好的云端和本地平台。而对于开发模式的不断改进和创新将 SQL 数据平台的用户体验提升到一个新的高度。