Poe(IT运维人员)发言：
每一个服务(Azure服务总线, SQL数据库，Azure storage)都有自己独特的方式来实现节流行为，并在负载过重时通知您。例如，请参见SQL Azure Throttling。重要的是要了解应用程序使用的不同服务可能会对您的应用程序造成的所有节流。
Poe(IT运维人员)发言：
团队还考虑使用Azure SQL数据库商业版来取代Azure SQL数据库Web版，但经过调查，我们确定目前版本之间的唯一区别是最大数据库大小。不同版本没有进行调优以支持不同类型的工作负载，而且两个版本实现了相同的节流行为。
有关可伸缩性的其他信息，请参阅：
Microsoft Azure Storage Abstractions and their Scalability Targets
Best Practices for Performance Improvements Using Service Bus Brokered Messaging
在谈到可伸缩性和高可用性时，重要的是不要抱有错误的乐观态度。尽管使用许多建议的实践，应用程序往往可以更有效地伸缩，并且对失败更有弹性，但它们仍然容易出现高需求瓶颈。确保为性能测试和实现性能目标分配足够的时间。
不停机迁移“我常说，任何冒险工作的三分之二都是做准备” Amelia Earhart
团队计划在Azure中进行从V2到V3版本的无停机迁移。为了实现这一点，迁移过程使用一个运行在Azure工作者角色中的特殊处理器来执行一些迁移步骤。
迁移过程仍然需要您完成一个配置步骤来关闭V2处理器并打开V3处理器。回想起来，我们应该使用一种不同的机制来简化从V2到V3处理器的转换，该转换基于处理程序本身的反馈，以指示它们何时完成了处理。
有关这些步骤的详细信息，请参见附录1“发布说明”。
Poe(IT运维人员)发言：
在生产环境中执行迁移之前，应该始终在测试环境中演练迁移。
在从V2迁移到V3期间，我们必须执行的步骤之一是通过重播事件日志中的事件来重新构建DraftOrder和PricedOrder视图模型，以填充新的V3读模型表。我们可以异步执行此操作。然而，在某个时候，我们需要开始将事件从活动的应用程序发送到这些读模型。此外，我们需要保持这些读模型的V2和V3版本都是最新的，直到迁移过程完成，因为V2前端web角色需要V2的读取模型数据可用，直到切换到V3前端web角色。在切换到V3前端时，我们必须确保V3读取的模型完全是最新的。
为了使这些读取模型保持最新，我们创建了一个作为Azure工作者角色的临时处理器，它在迁移过程中运行。有关更多细节，请参阅会Conference解决方案中的MigrationToV3项目。该处理器执行的步骤是：
创建一组新的Topic订阅，这些订阅将接收活动事件，这些活动事件将用于填充新的V3读模型。这些订阅将开始累积V3应用程序部署时将处理的事件。
重播事件日志中的事件，用历史数据填充新的V3读取模型。
处理活动事件并使V2的读模型保持最新，直到V3前端是活动的，此时我们不再需要V2的读模型。
迁移过程首先从事件存储中重播事件，以填充新的V3读模型。当这一切完成时，我们停止包含事件处理程序的V2处理器，并在V3处理器中启动新的处理程序。当它们运行并跟踪新Topic订阅中积累的事件时，ad-hoc处理器还使V2的读模型保持最新，因为此时我们仍然拥有V2前端。当V3工作者角色准备好时，我们可以执行一个VIP切换来使用新的V3前端。在V3前端运行之后，我们不再需要V2读模型。
使用这种方法要解决的问题之一是，如何确定新的V3处理器应该在什么时候从处理事件日志中的存档事件切换到处理实时的事件流。在将事件写入事件日志的过程中存在一些延迟，因此瞬时切换可能导致一些事件的丢失。团队决定允许V3处理器暂时可以同时处理存档事件和实时事件，这意味着可能会有重复的事件，相同的事件存在于事件存储区和由新订阅累积的事件列表中。但是，我们可以检测这些副本并相应地处理它们。
Markus(软件开发人员)发言：
通常，我们依赖于基础设施来检测重复的消息。在这个重复事件可能来自不同来源的特定场景中，我们不能依赖于基础设施，必须显式地将重复检测逻辑添加到代码中。