Azure 中的 Web.Config 连接字符串和 ServiceConfiguration 连接字符串之间有什么关系？
我对 Windows Azure 比较陌生，需要更好地了解 Azure 平台如何处理连接字符串配置设置。
假设我有一个 ASP.Net Web 项目，并且它具有如下所示的 Web.Config 连接字符串设置：
<add name="MyDb" connectionString="Data Source=NzSqlServer01;Initial Catalog=MyAzureDb;User ID=joe;Password=bloggs;"
providerName="System.Data.SqlClient" />
我使用此连接字符串进行本地测试等。假设我有一个包含相同连接信息的 ServiceConfiguration.Local.cscfg 文件。
现在我已准备好部署到我的 Azure 实例。我的 ServiceConfiguration.Cloud.cscfg 文件如下所示：
<Setting name="MyDb"
value="Data Source=tcp:e54wn1clij.database.windows.net;Database=MyAzureDb{0};User ID=joe.bloggs@e54wn1clij;Password=reallysecure;Trusted_Connection=False;Encrypt=True;" />
我想要了解的是，如果我的 Web 应用程序中有代码正在寻找名为“MyDb”的连接字符串（例如，通过调用这一行代码：ConfigurationManager.ConnectionStrings["CeraDb"].ConnectionString)，Azure 是否自动知道根据以下名称查找名为 MyAzureDb1 或 MyAzureDb2 的数据库： ServiceConfiguration 文件的连接字符串，或者 Web 应用程序的代码是否会简单地查找 Web.Config 中的内容，而无法正确对数据库连接进行负载平衡？
I'm relatively new to Windows Azure and I need to get a better appreciation of how the Azure platform handles connection string configuration settings.
Assume I have an ASP.Net web project and this has a Web.Config connection string setting like the following:
<add name="MyDb" connectionString="Data Source=NzSqlServer01;Initial Catalog=MyAzureDb;User ID=joe;Password=bloggs;"
providerName="System.Data.SqlClient" />
I use this connection string for local testing and such. Let's assume I have a ServiceConfiguration.Local.cscfg file that holds that same connection information.
Now I'm ready to deploy out to my Azure instance. My ServiceConfiguration.Cloud.cscfg file looks like this:
<Setting name="MyDb"
value="Data Source=tcp:e54wn1clij.database.windows.net;Database=MyAzureDb{0};User ID=joe.bloggs@e54wn1clij;Password=reallysecure;Trusted_Connection=False;Encrypt=True;" />
What I'm trying to get my head around is that if I have code in my web application that's looking for a connection string called "MyDb" (for example, by calling this line of code: ConfigurationManager.ConnectionStrings["CeraDb"].ConnectionString), does Azure automagically know to look for a database called MyAzureDb1 or MyAzureDb2 based on the ServiceConfiguration file's connection string, or will the web application's code simply look for whatever's in Web.Config and fail to correctly load-balance the database connections?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要调用 RoleEnvironment.GetConfigurationSettingValue(...) 来读取 ServiceConfiguration.Cloud.cscfg 中的值。
使用 .cscfg 存储设置的优点是您可以在运行时更改它们，而无需部署新代码。 Web.config 只是应用程序一部分的另一个文件，因此您必须部署一个新包来更新它，但 .cscfg 中的设置可以在门户中修改，或者通过上传新的 .cscfg 文件来修改，而无需部署和干扰应用程序本身。
You'd need to call RoleEnvironment.GetConfigurationSettingValue(...) to read the one in ServiceConfiguration.Cloud.cscfg.
The advantage to using .cscfg to store settings is that you can change them at runtime without having to deploy new code. Web.config is just another file that's part of your app, so you have to deploy a new package to update it, but the settings in .cscfg can be modified in the portal or by uploading a new .cscfg file without deploying and disturbing the app itself.
从本质上讲，除非您以其他方式编写代码，否则所有 Azure 实例都是平等创建的。在您的情况下，这意味着同一 Web 角色的两个或多个实例的配置将是相同的。
因此，如果您已经对数据库进行了分片并希望不同的实例读取不同的数据库，则需要巧妙地编写启动代码并创建一些将分片分配给实例的代码。您可以访问
System.Environment.MachineName，它可以在实例启动后在代码中区分它们。有几种方法可以做到这一点。一种可能是在（比如说）表存储中拥有一个中央注册表，用于保存分片实例的最后一次查看时间的日志。服务器上的后台进程定期写入此日志。然后，在实例启动时，检查每个分片的上次查看时间 - 如果有任何分片“过时”（明显早于当前时间减去写入间隔），则实例知道它可以将该分片声明为旧分片实例已死亡。
（但是，有更好的分片方法，通常围绕系统使用的数据进行分片，例如按系统中最大的表进行分片。）
Intrinsically, unless you code otherwise, all Azure instances are created equal. In your case, this means that the configuration for two or more instances of the same Web Role will be the same.
So, if you've sharded your database and want different instances to read different databases, you'll need to get clever in your startup code and create something that allocates a shard to an instance. You've access to
System.Environment.MachineNamewhich can distinguish in code between instances once they're started.There's a few ways to do this. One might be to have a central registry in (say) table storage that keeps a log of the last-seen-time of an instance for a shard. A background process on the server periodically writes out to this log. Then, on instance start, check the last-seen-time for each shard -- if any are "stale" (significantly older than the current time less the write interval) then the instance knows it can claim that shard for itself as the old instance has died.
(There are better ways to shard, however, generally around the data your system uses -- e.g. by the largest table in your system.)