如何利用qpid构建分布式总线

和所有基于Broker总线一样，qpid本身架构是联邦制的总线集群，这意味着，一份数据需要在多个broker之间互相备份。这个架构是AMQP定义的，本身并没有什么问题，因为AMQP是为交易而生的，对数据准确可靠的要求远远超过对性能的要求。

    我们看到在很多公有云中，也经常使用AMQP的另外一个实现RabbitMQ。和qpid一样，这两者之间基本可视为等价，知识每个供应商有所偏好，但各项指标不会有太大差别。我比较倾向于使用qpid，就像我现在要改造qpid，就没有什么难度。而RabbitMQ是Erlang实现的，开发者比较少，想定制的难度还是比较大。

    qpid是集群，中心模式的总线，利用他构建分布式总线是否可行，在判断这个解决方案之前，我们来一一讨论下分布式总线的几个关键要素。

    1、分布式总线必须在各个节点上，有能够独立运行的总线实例。毫无疑问，qpid没有问题。

    2、实例之间必须能够互相通讯，这一点qpid是有缺陷的。首先qpid是client和broker分离的，而broker和broker之间是通过AMQP定义的联邦协议构建集群。当节点数量不断增加时，集群的数据同步复制机制，在性能上显然就要拖后腿，因此在这个方向上，需要做改变。

    3、提供一致性服务的协调器，这个不在AMQP的定义范围内，qpid显然也不具备。那么就必须额外引入这块。

    4、消息队列。分布式架构并不必然要求消息队列，但作为总线而言，基本都要基于消息队列。而qpid本身就是AMQP的一个实现，因此消息队列，以及其复杂的管理功能都具备。

    5、服务注册，寻址。这块qpid已经具备大部分功能，Exchange、Queue的名字，可以等同于服务注册和实例的内部寻址功能。但跨实例之间，还必须借助于格外的服务器。幸运的是，qpid提供了一套管理机制，非AMQP协议，可以实时得到实例中Exchange和Queue名字和其他属性的变化。

    综上所述，qpid作为总线的一种实现，已经具备了完整的功能。但要扩展到分布式架构，显然还不够，主要还要加入一致性协调器，跨实例寻址，消息队列拷贝三个关键特性。除了一致性协调器外，其他在项目本身就可以找到合适的代码复用。而一致性协调器可以简单地基于zookeeper或者etcd等开源项目，稍加改造就可以了。

    换句话说，将集群模式的qpid改造成分布式架构的总线没有想象中的那么难。工作量比较大的还是如何分解qpid，在《qpid-lite，一个清晰版的qpid-amqp》一文中，也给大家展示过qpid代码结构中的问题，不过这个问题已经得到了解决，在此基础上重构qpid为分布式架构，还是要简单了许多。