-
Notifications
You must be signed in to change notification settings - Fork 299
Review of Azure Storage Queues multi-accounts #7885
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Clarified throttling issues related to Azure Storage Queues and the use of multiple storage accounts.
Clarified language regarding scaling out to multiple storage accounts and throughput limitations.
Removed redundant text and clarified guidance on using multiple storage accounts with Azure Storage Queues.
Restored the Scale Units section with detailed explanations about throughput limitations and resource partitioning.
Added note about throughput limits and scaling strategy.
Updated the section on routing with multiple storage accounts to clarify the use of NServiceBus and the notation for specifying destination addresses.
437d83b to
e1ec6e6
Compare
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
Corrected grammatical error in the documentation regarding connection string aliases.
Revised wording for clarity and consistency in the documentation regarding endpoint registration and message routing.
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
| ### Using registered endpoints | ||
|
|
||
| An example of a partitioned application with a different number of deployed scale units is an application deployed in various regions. | ||
| In order to route a message to an endpoint without having to specify the destination each time, the endpoint can be registered for a given command type, assembly, or namespace. | ||
|
|
||
|  | ||
| snippet: storage_account_routing_registered_endpoint | ||
|
|
||
| > [!NOTE] | ||
| > Use real Azure storage accounts. Do not use Azure storage emulator as it only supports a single fixed account named devstoreaccount1.". | ||
| Once the endpoint is registered, no send options need to be specified. | ||
|
|
||
| snippet: storage_account_routing_send_registered_endpoint | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should move this above so it immediately follows the connection string aliases as the first example showing and introducing the @ notation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Aliases can be provided for both the endpoint's connection strings as well as other accounts' connection strings. This enables using the `@` notation for destination addresses like `queue_name@accountAlias`. | ||
|
|
||
| snippet: storage_account_routing_send_options_alias |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should remove this lower, perhaps to the end of the configuration section in this article, since this is the "exceptional" scenario for customers. Most of the time they should be using routing configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I addressed this?
| ### Publishers | ||
|
|
||
| NServiceBus allows to specify destination addresses using an `"endpoint@physicallocation"` when messages are dispatched, in various places such as the [Send](/nservicebus/messaging/send-a-message.md) and [Routing](/nservicebus/messaging/routing.md) API or the `MessageEndpointMappings`. In this notation the `physicallocation` section represents the location where the endpoint's infrastructure is hosted, such as a storage account. | ||
| Similar to sending to an endpoint, the transport can also be configured to subscribe to events published by endpoints in another storage account, using: | ||
|
|
||
| Using this notation it is possible to route messages to any endpoint hosted in any storage account. | ||
| snippet: storage_account_routing_registered_publisher |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should make this section follow immediately after the routing configuration.
| ### Using send options | ||
|
|
||
| Although registering endpoints to route messages is preferred, NServiceBus allows specifying destination addresses using the `<endpoint>@<physicallocation>` notation when messages are dispatched. Using this notation, it is possible to route messages to any endpoint hosted in any storage account. The `physicallocation` element represents the location where the endpoint's infrastructure is hosted, such as a storage account alias. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be the last section. I am wondering if we should show both the SendOptions and the short context.Send("endpoint@account") form.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean "Using send options" should go below the "Publishers" section? I don't have an opinion on whether or not to show both.
| > Use real Azure storage accounts. Do not use Azure storage emulator as it only supports a single fixed account named "devstoreaccount1". | ||
| > [!NOTE] | ||
| > There are limits to how much using multiple storage accounts increase throughput. Consider using [scale units as a comprehensive scaling strategy](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/scale-partition#choose-a-scaling-strategy) to address higher throughput and reliability needs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| > There are limits to how much using multiple storage accounts increase throughput. Consider using [scale units as a comprehensive scaling strategy](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/scale-partition#choose-a-scaling-strategy) to address higher throughput and reliability needs. | |
| > There are limits to how much increasing storage accounts increases throughput. Consider using [scale units as a comprehensive scaling strategy](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/scale-partition#choose-a-scaling-strategy) to address higher throughput and reliability needs. |
Co-authored-by: Bob Langley <[email protected]>
transports/azure-storage-queues/multi-storageaccount-support.md
Outdated
Show resolved
Hide resolved
Clarified the use of aliases for connection strings in multi-storage account support.
Uh oh!
There was an error while loading. Please reload this page.