从本地Windows Service Bus迁移至Azure Service Bus的步骤及全量迁移方案

Hey there, migrating 40+ microservices from on-premises Windows Service Bus 1.1 to Azure Service Bus is totally doable—let’s walk through a practical, step-by-step plan that covers infrastructure migration, code adaptation, full message transfer, and risk mitigation. I’ve supported teams with similar scale migrations, so here’s what works:

First, get a clear picture of your existing setup to avoid surprises:

• Inventory all Service Bus resources: Use tools like Service Bus Explorer or PowerShell scripts (Get-SBQueue, Get-SBTopic) to list every queue, topic, and subscription, along with their configurations (TTL, max delivery count, dead letter rules, session settings, etc.). Export this as a reference to replicate in Azure.
• Map performance requirements: Analyze peak message volumes, average message sizes, production/consumption rates, and special features (like delayed messages, sessions, or dead letter handling). This will help you choose the right Azure Service Bus SKU—Premium is ideal for your 40+ microservices due to higher throughput, low latency, and dedicated resources.
• Check feature compatibility: Note gaps between Windows Service Bus 1.1 and Azure Service Bus:
  • Azure Service Bus doesn’t have a direct equivalent for on-prem relays; use Azure Relay if you relied on that feature.
  • Authentication models differ: On-prem uses Active Directory, while Azure supports Azure AD (recommended) or SAS keys.
  • Confirm message serialization formats (e.g., DataContractSerializer) are compatible—Azure Service Bus works with most standard formats, but double-check custom serializers.

Replicate your Service Bus topology in Azure with consistent configurations:

• Provision resources at scale: Use ARM templates, Bicep, or Azure CLI to batch-create queues, topics, and subscriptions instead of manual portal setup. This ensures consistency and repeatability. Example CLI command for a queue:

  az servicebus queue create --resource-group <your-rg> --namespace <sb-namespace> --name <queue-name> --max-delivery-count 5 --default-message-time-to-live P7D --enable-session false
  

• Set up secure authentication: Use Azure AD Managed Identities or service principals for your microservices, assigning roles like Azure Service Bus Data Sender or Azure Service Bus Data Receiver to follow least-privilege principles. If you need temporary compatibility, SAS keys are an option, but Azure AD is more secure long-term.

Update your microservices to work with Azure’s SDKs:

• Upgrade client libraries: Replace the old Microsoft.ServiceBus NuGet package with the modern Azure.Messaging.ServiceBus SDK (recommended) or the legacy Microsoft.Azure.ServiceBus package. Note that APIs have changed—for example, sending messages now uses async methods like ServiceBusSender.SendMessageAsync() instead of synchronous QueueClient.Send().
• Update connection logic: Swap on-prem connection strings with Azure Service Bus namespace connection strings, or use DefaultAzureCredential to authenticate via Azure AD without hardcoding secrets.
• Adjust for feature differences:
  • If you use sessions, ensure your Azure queues/topics have session support enabled.
  • For delayed/scheduled messages, use ServiceBusMessage.ScheduledEnqueueTimeUtc instead of the on-prem delayed message API.

Choose a migration approach based on your downtime tolerance:

Option 1: Dual-Write/Dual-Read (Zero Downtime) #

This is the safest approach for production environments:

• Modify producer services to send messages to both the on-prem Service Bus and Azure Service Bus.
• Update consumer services to read from both sources, ensuring messages are processed only once (use message IDs or correlation IDs to deduplicate if needed).
• Once the on-prem queues/topics are empty (verify with monitoring), switch producers to send only to Azure, then update consumers to read only from Azure.

Option 2: Offline Migration (Maintenance Window) #

If you can tolerate a short downtime:

• Pause all producer and consumer services.
• Use Service Bus Explorer to export messages from on-prem queues/topics to JSON files, preserving all message properties (CorrelationId, MessageId, TTL, etc.).
• Use the same tool or a custom script to import messages into the corresponding Azure Service Bus resources.
• Restart your microservices with updated Azure Service Bus connections.

Option 3: Custom Migration Tool #

For very large message volumes, build a lightweight tool:

• Use the on-prem Service Bus client to read messages in batches.
• Use the Azure Service Bus SDK to send these messages to Azure, preserving all metadata.
• Add error handling and retry logic to handle failures, and track progress to avoid missing messages.

• Gradual rollout: Switch a small subset of microservices to Azure first, validate end-to-end workflows, then incrementally migrate the rest. This limits risk if issues arise.
• Monitor closely: Use Azure Portal’s Service Bus metrics to track message counts, throughput, dead letter queues, and latency. Compare these to your on-prem baseline to ensure performance matches expectations.
• Test critical workflows: Run end-to-end tests for your most important business processes to confirm messages are produced, routed, and consumed correctly without loss or duplication.

• Keep your on-prem Service Bus resources running for a few weeks post-migration.
• Add a configuration switch in your microservices to quickly toggle between on-prem and Azure connections if you need to roll back.

• Test everything in a staging environment first, mirroring your production setup.
• Plan for cost: Premium SKU costs more than Basic/Standard, so calculate throughput units and partition counts based on your actual usage.
• Gradually decommission on-prem resources once you’re confident the migration is successful.

内容的提问来源于stack exchange，提问作者Hossein Margani