解决的方案是引入充分的集成测试，甚至是回归测试，并需要及时运行这些测试，以快速地获得反馈。我们可以将集成测试作为提交代码的验证们，要求每次提交代码都必须运行集成测试与指定的回归测试 。这正是持续集成的体现。通过在本地构建与远程构建运行集成测试与回归测试，有效地保证本地版本与集成后的版本不会因为消息的改变使得功能遭受破坏。一旦遭受破坏，也能够及时获得反馈，发现问题，即刻解决这些问题，而不是等到项目后期集中进行集成测试。

另一个问题是后台任务的非实时性带来的测试困难。由于后台任务是定期对消息队列中的消息进行处理，因而触发的时机是不可预测的 。对于这种情况，我们通常会同时运用两种方案，双管其下地解决问题。首先，我们会为系统引入一个同步实现功能的版本，并通过在配置文件中引入toggle的开关机制，随时可以在同步功能与异步功能之间进行切换。如果我们能够保证消息队列处理与后台任务执行的正确性，就可以设置为同步功能，这样就能快速而准确地对该任务所代表的功能进行测试，并及时收获反馈。同时，我们可以在持续集成服务器上建立一个专门的管道（pipeline），用以运行基于消息处理的异步版本。这个管道对应的任务可以通过手动执行，也可以对管道设置定时器，在指定时间执行（例如在凌晨两点执行一次，这样在第二天开始工作之前可以获得反馈）。我们需要为该管道准备特定的执行环境，并将后台任务的侦听与执行时间修改为可以接受的值。这样既能够及时了解功能是否正确，又能保证基于消息的系统是工作正常的。

当然，分布式系统还存在解析消息、网络传递的性能损耗。对于这些问题，需要架构师审慎地分析业务场景，正确地选择架构方案与架构模式。相比较本地系统而言，分布式系统的维护难度可能成倍递增。这既需要我们在进行架构决策与设计时，充分考虑系统架构的稳定性，同时还需要引入系统日志处理。更好的做法是为日志处理增加错误通知的功能，只要发生消息处理的错误信息，就通过邮件、短信等方式通知系统管理员，及时地处理错误。因为只有在发生错误的当时查询错误日志，才能够更好对问题进行定位。同时，还可以为系统引入Error Message Queue以及Dead Message Queue，以便于处理错误和异常情况。

对于分布式系统而言，还需要考虑服务执行结果的一致性，尤其是当某个业务需要多个服务参与到一个会话中时，一旦某个服务发生故障，就可能导致应用出现状态不一致的情况，因为只有所有参与者都成功执行了任务，才能视为完全成功。这就牵涉到分布式事务的问题，此时任务的执行就变成了事务型的：即任务必须是原子的，结果状态必须保持一致。在任务处理过程中，状态修改是彼此隔离的，成功的状态修改在整个事务执行过程中是持久的。这就是事务的ACID（Atomic，Consistent，Isolated与Durable）属性。

一种方案是引入分布式事务协调器，即DTC（Distributed Transaction Coordinator）,将事务分为两段式甚至三段式提交，要求整个事务的所有参与者以投票形式决定事务是完全成功还是失败。另一种方案是降低对结果一致性的要求。根据eBay的最佳实践，考虑到分布式事务的成本，获得分布式资源即时的一致性是不必要的，也是不现实的。在Randy Shoup的文章《可伸缩性最佳实践：来自eBay的经验》中提到了Eric Brewer的CAP公理：分布式系统的三项重要指标——一致性（Consistency）、可用性（Availability）和 分区耐受性（Partition-tolerance）——在任意时刻，只有两项能同时成立。我们应该根据不同的应用场景，权衡这三个要素。在不必要保证即时的一致性前提下，我们可以考虑合理地划分服务，尽量将可能作用在同一个事务范围的业务操作部署在同一个进程中，以避免分布式部署。如果确实需要多个分布式服务之间保持执行结果的一致，可以考虑引入数据核对，异步恢复事件或集中决算等手段。