当系统从Azure服务总线检索消息时,团队启用了prefetch选项。此选项使系统能够在一次到服务器的往返中检索多个消息,并有助于减少从服务总线Topic检索现有消息的延迟。
下面来自SubscriptionReceiver类的代码示例展示了如何启用此选项。
protected SubscriptionReceiver(ServiceBusSettings settings, string topic, string subscription, bool processInParallel, ISubscriptionReceiverInstrumentation instrumentation, RetryStrategy backgroundRetryStrategy) { this.settings = settings; this.topic = topic; this.subscription = subscription; this.processInParallel = processInParallel; this.tokenProvider = TokenProvider.CreateSharedSecretTokenProvider(settings.TokenIssuer, settings.TokenAccessKey); this.serviceUri = ServiceBusEnvironment.CreateServiceUri(settings.ServiceUriScheme, settings.ServiceNamespace, settings.ServicePath); var messagingFactory = MessagingFactory.Create(this.serviceUri, tokenProvider); this.client = messagingFactory.CreateSubscriptionClient(topic, subscription); if (this.processInParallel) { this.client.PrefetchCount = 18; } else { this.client.PrefetchCount = 14; } ... } 并行接收多个会话在V2版本中,SessionSubscriptionReceiver创建会话来依次接收来自Azure服务总线的消息。但是,如果您正在使用会话,则只能处理来自该会话的消息。在切换到另一个会话之前,其他消息将被忽略。在V3版本中,SessionSubscriptionReceiver并行创建多个会话,使系统能够同时接收来自多个会话的消息。
有关详细信息,请参见SessionSubscriptionReceiver类中的AcceptSession方法。
Markus(软件开发人员)发言:
AcceptSession方法使用Transient Fault Handling Application Block来可靠地接收会话。
当系统通过向RegistrationProcessManager类添加时间戳属性来保存RegistrationProcessManager类时,团队还添加了一个乐观并发性检查,如下面的代码示例所示:
[ConcurrencyCheck] [Timestamp] public byte[] TimeStamp { get; private set; }有关更多信息,请参见MSDN网站上的Code First Data Annotations。
在进行了乐观并发性检查之后,我们还删除了SessionSubscriptionReceiver类中的锁,这是系统中潜在的瓶颈。
给MakeSeatReservation命令添加一个time-to-live值Azure服务总线代理消息可以为TimeToLive属性分配一个值,当time-to-live过期时,消息将自动发送到dead-letter队列。如果与MakeSeatReservation命令关联的订单已经过期,应用程序将使用服务总线的这个特性来避免处理MakeSeatReservation命令。
减少到数据库的往返次数我们在PricedOrderViewModelGenerator类中标识了许多位置,可以在这些位置优化代码。以前,当这个类处理正在预定或过期的订单时,系统对SQL数据库实例进行两次调用,现在系统只发起一个调用。
对测试的影响在旅程的这个阶段,团队重新组织了Conference.Specflow项目,以更好地反映测试的目的。
集成测试Conference.Specflow项目中的Features\Integration文件夹中的测试旨在直接测试领域的行为,通过查看发送和接收的命令和事件来验证领域的行为。这些测试的目的是让程序员而不是领域专家能够理解,并使用比普遍使用的语言更专业的词汇表来表示。除了验证领域的行为并帮助开发人员理解系统中的命令流和事件流之外,这些测试还被证明对于在事件丢失或接收顺序错误的场景中测试领域的行为非常有用。
Conference文件夹包含会议管理限界上下文的集成测试,而Registration文件夹包含订单和注册限界上下文的测试。
Markus(软件开发人员)发言:
这些集成测试假定命令处理程序信任命令的发送者发送的是有效的命令消息。这一点可能不适用于正在设计测试的其他系统。
UserInterface文件夹包含验收测试。这些测试在第4章“扩展和增强订单和注册限界上下文”有更详细的描述。Controllers文件夹包含使用MVC控制器作为入口点的测试,Views文件夹包含使用WatiN通过其UI驱动系统的测试。
总结