旅程8：后记:经验教训 我们的地图有多好?我们走了多远?我们学到了什么?我们迷路了吗? “这片土地可能对那些愿意冒险的人有益。”亨利.哈德逊
这一章总结了我们旅程中的发现。它强调了我们在这个过程中所学到的最重要的经验教训，提出了如果我们用新知识开始这段旅程，我们将以不同的方式做的一些事情，并指出了Contoso会议管理系统的一些未来道路。
你应该记住，这个总结反映的是我们的具体旅程，并非所有这些发现都适用于你自己的CQRS旅行。例如，我们的目标之一是探索如何在部署到Microsoft Azure并在利用云的可伸缩性和可靠性的应用程序中实现CQRS模式。对于我们的项目，这意味着使用消息传递来支持多个角色类型和实例之间的通信。您的项目可能不需要多个角色实例，或者没有部署到云中，因此可能不需要如此广泛地(或者根本不需要)使用消息传递。
我们希望这些发现能够被证明是有用的，特别是当您刚刚开始使用CQRS和事件源时。
我们学到了什么本节描述了我们学到的主要经验教训。它们没有以任何特定的顺序呈现。
性能问题在我们的旅程开始时，我们对CQRS模式的一个概念是，通过分离应用程序的读和写方面，我们可以优化每个方面的性能。CQRS社区的许多人都认同这一观点，例如:
“CQRS告诉我，我可以分别优化读和写，而且我不必总是手动的反规范化到平面表中。”
Kelly Sommers - CQRS顾问
这在我们的实践过程中得到了证实，当我们确实需要解决性能问题时，这种分离使我们受益匪浅。
在旅程的最后阶段，测试揭示了应用程序中的一组性能问题。当我们研究它们时，发现它们与我们实现CQRS模式的方式关系不大，而与我们使用基础设施的方式关系更大。发现这些问题的根源是困难的，由于应用程序中有如此多的活动部件，获得正确的跟踪和用于分析的正确数据是一项挑战。一旦我们确定了瓶颈，修复它们就相对容易了，这主要是因为CQRS模式使您能够清楚地分离系统的不同元素，比如读和写。尽管实现CQRS模式所导致的关注点分离会使识别问题变得更加困难，但是一旦您识别出一个问题，不仅更容易修复它，而且更容易防止它的重现。解耦的体系结构使得编写重现问题的单元测试更加简单。
我们在处理系统中的性能问题时遇到的挑战更多地是由于我们的系统是一个分布式的、基于消息的系统，而不是因为它实现了CQRS模式。
第7章“添加弹性和优化性能”提供了关于我们处理系统中性能问题的方法的更多信息，并对我们想要进行但没有时间实现的额外更改提出了一些建议。
实现消息驱动系统远非易事我们这个项目的基础设施是在旅程中根据需要开发它。我们没有预料(也没有预先警告)需要多少时间和精力来创建应用程序所需的健壮基础设施。我们在许多开发任务上花费的时间至少是最初计划的两倍，因为我们持续发现与基础设施相关的额外需求。特别是，我们从一开始就了解到拥有健壮的事件存储是至关重要的。我们从经验中得到的另一个关键思想是，消息总线上的所有I/O都应该是异步的。
Jana(软件架构师)发言：
虽然我们的事件存储还不是生产环境完备的，但是如果您决定实现自己的事件存储，那么当前的实现很好地指示了应该处理的问题类型。
尽管我们的应用程序并不大，但它向我们清楚地说明了end-to-end跟踪的重要性，以及帮助我们理解系统中所有消息流的工具的价值。第4章“扩展和增强订单和注册限界上下文”描述了测试在帮助我们理解系统方面的价值，并讨论了由我们的顾问之一Josh Elster创建的消息传递中间语言(messaging intermediate language, MIL)。
Gary(CQRS专家)发言：
如果我们有一个用于消息传递的标准符号，就可以帮助我们与领域专家和核心团队之外的人员沟通一些问题，这也会有所帮助。
总之，我们一路上遇到的许多问题都与CQRS模式没有特定的关系，而是与我们解决方案的分布式、消息驱动特性更相关。
Jana(软件架构师)发言：
我们发现，使用不同的Topc来传输由不同聚合发布的事件，通过这样来划分服务总线有助于实现可伸缩性。有关更多信息，请参见第7章“添加弹性和优化性能”。另外，请参阅这些博客文章:“Microsoft Azure Storage Abstractions and their Scalability Targets”和“Best Practices for Performance Improvements Using Service Bus Brokered Messaging”。
虽然云提供了很多好处，比如可靠的、可伸缩的、现成的服务，您只需单击几下鼠标就可以使用这些服务，但是云环境也带来了一些挑战：