能否在云端托管 SQL Server 并连接 DiscountASP 上的 ASP.NET 应用？

结论

可以。只要 DiscountASP 上的 ASP.NET 应用能通过网络访问云端数据库，云端 SQL Server 允许连接，并且双方使用兼容的 SQL Server 协议和身份验证方式，这套架构在技术上就是可行的。

需要评估的重点不是”能不能连”，而是这些实际问题：

• DiscountASP 是否允许向外连接 SQL Server 端口；
• Web 主机是否有固定的出站 IP 地址，以便配置数据库防火墙；
• Web 应用与数据库之间的网络延迟能否接受；
• 跨公网访问是否足够安全；
• 云服务商如何收取数据库流量、计算、存储和备份费用；
• 云端数据库发生故障或网络中断时，应用如何处理。

如果应用频繁执行大量小查询，或者每次页面请求都要多次访问数据库，跨托管商连接造成的延迟可能很明显。如果查询次数较少、SQL 设计合理且连接稳定，通常可以正常运行。

可选择的云端 SQL Server 方案

常见方案分为三类。

托管数据库服务

例如 Azure SQL Database。云平台负责操作系统、补丁、基础备份和部分高可用工作，日常维护较少。

它与 SQL Server 高度兼容，但并不等同于一台完整的 SQL Server。某些实例级功能、跨数据库操作、SQL Server Agent 作业或第三方扩展可能受到限制。迁移前需要检查现有数据库用到了哪些功能。

托管实例

例如 Azure SQL Managed Instance。这类服务更接近完整的 SQL Server 实例，适合依赖实例级功能，或者需要迁移多个相关数据库的场景。

部分托管实例主要通过私有网络提供访问。DiscountASP 能否连接，要看服务的网络配置、是否支持公开端点，以及托管商有哪些网络限制，不能假定它一定可以从公网直接访问。

云端虚拟机中的 SQL Server

另一种方案是租用云服务器，在 Windows Server 或 Linux 上自行安装 SQL Server。这种方式的兼容性最高，现有实例通常也更容易迁移，但操作系统更新、SQL Server 补丁、备份、监控、防火墙和高可用都要自己负责。

如果只是为普通 ASP.NET 应用托管数据库，可以优先考虑托管数据库服务。只有确实依赖完整 SQL Server 功能时，再考虑托管实例或虚拟机。

实施步骤

1. 确认 DiscountASP 的网络限制

先向 DiscountASP 确认以下事项：

• 当前套餐是否允许访问外部 SQL Server；
• 是否允许 TCP 1433，或云数据库实际使用的其他端口；
• 应用服务器是否有固定的出站公网 IP；
• 是否限制长时间数据库连接；
• 是否有连接数、流量或防火墙方面的限制。

“入站 IP”和”出站 IP”很容易混淆。云数据库防火墙需要放行的是 Web 应用连接数据库时使用的出站 IP，不是网站域名解析出的 IP。

如果托管商不提供固定出站 IP，数据库防火墙就很难精确限制连接来源。直接放开大范围公网地址并不合适。这种情况下，可以考虑 VPN、专用网络连接、代理网关，或者将 Web 应用迁移到能提供稳定网络出口的环境。

2. 创建云端数据库

创建数据库时需要确定：

• 数据库所在区域；
• 计算和存储规格；
• SQL Server 版本或兼容级别；
• 登录与身份验证方式；
• 自动备份和保留期限；
• 是否需要区域冗余或故障转移。

数据库区域应尽量靠近 DiscountASP 应用服务器所在的数据中心。跨地区甚至跨洲访问仍然可以建立连接，但延迟更高，网络波动也会更大。

3. 迁移并验证现有数据库

迁移方式取决于目标平台：

• 从完整 SQL Server 迁移到云虚拟机，可以使用备份与还原等常规方法；
• 迁移到托管数据库前，需要先进行兼容性评估；
• 数据量较小时，也可以使用数据层应用程序、迁移工具或脚本；
• 如果对停机时间要求较高，需要规划增量同步和最终切换。

迁移后至少要检查：

• 用户、角色和权限；
• 数据库排序规则；
• 登录账号与数据库用户的映射；
• 存储过程、视图、触发器和函数；
• SQL Agent 作业或其他定时任务；
• 跨数据库引用；
• 应用所需的兼容级别。

不能只检查”表和数据是否存在”。很多迁移问题出在登录、作业、权限和实例级依赖上。

4. 配置防火墙和加密

只放行 DiscountASP 提供的固定出站 IP，不要为了省事而允许所有公网地址。

数据库账号应遵循最小权限原则。应用账号通常不应拥有 sysadmin、db_owner 或创建数据库等权限，只需授予应用运行所必需的读取、写入和执行权限。

连接应启用 TLS 加密，并验证服务器证书。除非是在明确了解风险的临时测试环境中，否则不要长期使用 TrustServerCertificate=True 绕过证书验证。

5. 修改连接字符串

现代 ASP.NET Core 应用可以在 appsettings.json 中配置连接字符串：

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=tcp:database.example.com,1433;Initial Catalog=ApplicationDb;User ID=app_user;Password=REPLACE_WITH_SECRET;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"
  }
}

在 C# 中读取连接字符串：

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));

传统 ASP.NET Framework 应用通常在 Web.config 中配置：

<connectionStrings>
  <add
    name="ApplicationDb"
    providerName="System.Data.SqlClient"
    connectionString="Server=tcp:database.example.com,1433;Initial Catalog=ApplicationDb;User ID=app_user;Password=REPLACE_WITH_SECRET;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;" />
</connectionStrings>

示例中的服务器名称、数据库名称、账号和端口都要替换成实际值。不同云数据库对连接字符串的要求可能不同，应使用目标服务生成的连接信息。

生产环境中不要把真实密码提交到源代码仓库。如果 DiscountASP 支持环境变量、受保护的配置项或密钥管理功能，应通过这些机制注入密码。

应用层需要做的调整

跨网络数据库连接比同一机房内的连接更容易发生短暂故障。应用需要为可重试的瞬时错误做好准备，但不能无限重试。

Entity Framework Core 可以配置有限次数的重试：

builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection"),
        sqlOptions =>
        {
            sqlOptions.EnableRetryOnFailure(
                maxRetryCount: 3,
                maxRetryDelay: TimeSpan.FromSeconds(5),
                errorNumbersToAdd: null);
        }));

重试次数和延迟要根据实际业务设置。涉及付款、库存扣减或其他非幂等操作时，还要防止重试造成重复执行。

应用还需要注意：

• 继续使用连接池，不要为每条查询创建并长期保留独立连接；
• 尽快关闭或释放数据库连接；
• 避免在循环中执行大量单行查询；
• 合并可以合并的查询；
• 为常用查询条件建立合适的索引；
• 缓存不经常变化的数据；
• 为命令设置合理的超时时间；
• 记录连接失败、超时和查询耗时。

在 ADO.NET 中，应通过 using 及时释放连接：

await using var connection = new SqlConnection(connectionString);
await connection.OpenAsync();

await using var command = new SqlCommand(
    "SELECT DisplayName FROM dbo.Users WHERE UserId = @UserId",
    connection);

command.Parameters.Add("@UserId", SqlDbType.Int).Value = userId;

var displayName = await command.ExecuteScalarAsync();

参数化查询有助于提高安全性，也能避免直接拼接 SQL 引起的类型和转义问题。

这种架构的主要缺点

网络延迟

网络延迟是最直接的问题。一次跨公网查询可能只增加少量延迟，但如果一个页面顺序执行几十次查询，累计时间会很明显。

例如，假设每次数据库往返额外增加 20 ms，一个请求串行执行 30 次查询，仅网络往返就可能增加约 600 ms：

20 ms × 30 = 600 ms

这个例子只用于说明延迟的累计效应，不代表实际环境的性能。实际延迟需要从 DiscountASP 应用服务器到目标数据库进行测试。

可用性依赖增加

应用能否正常运行，将同时取决于：

• DiscountASP 的托管环境；
• DiscountASP 的外部网络；
• 公网路由；
• 云数据库服务；
• 双方的 DNS 和防火墙配置。

其中任何一个环节出现问题，都可能导致网站无法访问数据库。监控不能只检查网站能否打开，还要检查数据库连接和关键查询能否成功。

安全边界更复杂

数据库使用公网端点会扩大攻击面。即使已经启用密码和 TLS，仍应采取以下措施：

• 设置精确的 IP 白名单；
• 使用强密码或平台支持的更安全身份验证方式；
• 为应用配置最小权限账号；
• 监控登录失败；
• 定期轮换凭据；
• 禁止不必要的管理员远程登录。

如果无法限制来源 IP，这种方案的安全性会明显下降。

成本未必只是”按量计费”

云计算不一定比传统托管便宜，费用也不一定全部按实际查询次数计算。常见费用包括：

• 固定或按小时计算的数据库资源；
• 存储空间；
• 备份存储；
• 高可用或冗余；
• 公网数据传出；
• 许可证；
• 监控和日志。

只要数据库规格一直处于运行状态，即使访问量很低，也可能持续产生费用。估算总成本时，需要考虑预计的数据库大小、峰值负载、备份周期和网络流量。

是否值得采用

如果必须保留 Web 应用当前的托管位置，同时又希望集中管理多个 SQL Server 数据库，这种架构是合理的。采用它需要满足以下条件：

• DiscountASP 明确允许外部数据库连接；
• 能获得稳定的出站 IP；
• 云数据库可以安全地限制访问来源；
• 实测延迟符合要求；
• 应用已经减少不必要的数据库往返；
• 能接受跨供应商带来的故障排查复杂度。

如果应用与数据库交互非常频繁，或者托管商无法提供固定出口和可靠的外部连接，把 Web 应用和数据库部署在同一个云区域通常更简单、更快，也更方便使用私有网络。

比较稳妥的方式是先创建一个小规格测试数据库，迁移一份脱敏数据，再从 DiscountASP 上的实际应用环境测试连接、延迟、并发、故障重试和费用。确认测试结果符合要求后，再迁移生产数据库。

备注：内容仅供参考。