在分布式系统中，如何基于业务方面的考量、将RESTful与MQ(消息中间件)结合、解决事务完整性/数据一致性问题的架构设计。
一、面向业务考量的最终一致性方案考虑
这里先举两个例子。
1、支付宝的“WS Transaction标准”尝试：
支付宝在他们的分布式系统中为解决事务完整性的问题，曾经尝试过WS Transaction标准，但是经过实际做测试，最后发现成本实在是太高了。完成一个事务，为确保事务完整性，20多条的消息的交互，其中只有1条是业务消息，其他都是系统之间的协议消息。这就会导致客户端响应太慢，客户无法承受这样的性能。
2、Ebay架构师的最终一致性方案：
来自Ebay的架构师根据他们的最佳实践给出过解决方案。就是关于数据一致性的，比如他们的分布式存储如何保持数据一致性。其中探讨了“实时一致”与“严格事务”之间的悖论，他们采用了局部实时一致、全局最终一致的解决方案。在这里就需要从业务上辨别哪些操作是可以放宽的（允许不在一个事务中），哪些操作必须是原子性的。现在Ebay的整个架构就是基于“最终一致性”的，支付宝也从中受到启发，沿用该设计思路解决了“客户端迅速响应”和“服务端数据一致”的矛盾。
故考虑系统架构设计的时候，不仅仅考虑技术，也把业务因素考虑进来，面向业务考量进行系统设计，会让我们在技术上做出更合理的抉择。基于业务考虑，有利于得出事务的优先级别，也有利于作出架构设计上的最佳取舍。通常来说银行、证券系统的事务完整性（或者说数据一致性）具有绝对优先级，也就要求绝对严格的实时保证。而通讯系统在事务完整性（或者说数据一致性上）的优先级别上甚至没有支付宝和Ebay高，这两者都有复杂的帐务交易。如果他们也认为局部实时一致、全局最终一致就能够满足业务的要求，那么自然在通讯系统中也有其可行性。
二、Restful与MQ技术适用场景分析
一般而言Restful技术架构为对客户端开放的一组资源服务。在分布式系统中既有客户端与服务器之间的交互，又有服务器与服务器之间的交互。比如说XCAP协议就是标准的Restful风格的接口，提供客户端远程操作XML文档的服务，而“运营管理系统”调用其他业务系统接口，用以管理用户可被分配的服务以及权限等，则是服务器之间的信息交互。前者当然适合Restful风格的技术接口，后者个人更倾向于异步的、基于消息的通信方式。因为客户端与服务器通常是跨越互联网的，而服务器与服务器之间可能位于一个局域网内，甚至可能被安放在同一个机房。
我们知道Restful风格的技术架构通常是通过JSON或者XML等进行信息的传递，总之都是通过“字符串格式”的封装进行信息传递。通过字符格式交互信息在使用上带来简便的同时，因为封装、解析、转换等过程使其在性能自然要付出一些代价，如果是服务器之间在更底层同类协议之间的数据交互性能就要高的多。这里顺便提到信息交互在不同场景下的性能顺序，按照从快到慢排序：
1、同一进程之间的信息交互；
2、同一机器两个进程之间的信息交互；
3、两个分布机器之间的信息交互。
因为HTTP是在TCP/IP协议之上的包装，WebService是在HTTP协议之上的包装，根据越低层协议之间的信息交互越高效的特征，从协议级由快到慢排序：
1、基于TCP/IP协议的信息交互；
2、基于HTTP协议的信息交互；
3、基于WebService协议的信息交互。
另外，因为“运营管理系统”与其他系统之间是直接交互的，比如运营要给某个用户开通某些特定服务，那就要分别调用提供这几个服务的业务系统的“细粒度”接口。一旦增加新的服务，也势必影响到运营管理系统的修改。我们说在分布式系统中有个原则，尽可能设计“粗粒度”接口，以减少系统之间的网络交互。如果在运营管理系统与其他业务系统之间由“消息中间件”来进行信息交互，那么：
1、运营管理系统可以设计面向服务的“粗粒度”接口，开通几个服务只需要把几种类型的数据封装在一起，一次性传递给MQ。增加服务也只不过增加一种数据类型而已；
2、MQ可以保证消息最终一定会被接收、处理。因为MQ可以实现基于“订阅-通知”的Event-Driven机制，业务系统只要在MQ中注册自己，就可以实时收到来自MQ的消息。即使出现系统或者网络异常，消息也会被MQ中间件持久化，一旦业务系统恢复，消息马上会被发往业务系统，这显然比目前采用的每隔一段时间扫描一次数据库要高效的多。
三、MQ与最终一致性
MQ消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上，队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行——它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。它为构造异步方式实现的分布式应用提供了松耦合方法，在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。
在分布式系统中，尤其是不同语言的分布式系统中，如果没有消息中间件完成信息交换，应用开发者为了高效传输数据，就要编写相应语言的应用程序来发送和接收信息，且交换信息没有标准方法，每个应用必须进行特定的编程从而和多平台、不同环境下的一个或多个应用通信。
假如系统可以采用数据“局部实时一致、全局最终一致”的方案，就可以选择不需要支持事务的MQ中间件，因为其可以保证：即使在系统异常、网络异常等特殊情况下，消息也会被持久化，当系统恢复，消息马上会被处理，也即最终一定会被接受处理，也就是最终一致。而不需要支持事务的MQ性能及吞吐率都会很高。
总之，个人倾向于用 Restful对客户端提供服务，服务器之间引入MQ服务，建立异步的、基于消息的信息交互方式，并基于数据局部实时一致、全局最终一致的原则，来解决事务问题