ZeroMQ
英文原文：
?MQ: The Theoretical Foundation
引见
与其他的基于惯例实际根底的（集中）通讯系统分歧，简直没有分布式通讯系统的甚么材料，ØMQ(ZeroMQ)是感兴味的读者少量能请举出的一个。
本文的目标是说明ØMQ架构的根本观点，它们是怎么组合起来的，和它们被如斯设计的缘由。
拓扑
拓扑是ØMQ最首要的观点，除非你晓得“拓扑”代表甚么，不然将与其他观点混杂更难了解，乃至了解不妥。
依照浅显定义，我们可以说“拓扑”是一组参与统一营业逻辑的使用程序。
比方：假定有一个图象转换服务，调剂图象到所需的尺寸和辨别率。一切供给转换的服务、一切运用该服务的使用程序和一切的中间节点，比方负载均衡等，配合构成了拓扑。
凡是，拓扑具有以属下性：
- 拓扑是张图表，这张图中节点是使用程序、连线时使用程序间的数据通道。
- 一切使用程序就为完成它们的营业逻辑服从类似的线路协议。
- 图表力争紧凑，比方任何两个节点或直接或经过一个或多其中介机构衔接。
第1点很分明，成心运用单词“通道”而不是运用“衔接”这一点是为了描绘模子任务的实践状况，即便IP多播或UDP等无衔接的底层传输亦是如斯。
第2点阐明一切拓扑里的使用程序应当就甚么告竣一致：正被传送的音讯(比方“这是一张需调剂尺寸的图片”或“这是调剂后的图片”)、音讯序列(如使用程序中形态机的完成)、实践数据的编码(图象怎么被序列化，RGB？CMYK?)等等。
第3点表达了如许一个现实：即便存在两个十分类似的（例如两家公司里的）商务逻辑安排，它们依然构成了两个拓扑，除非它们互相经过数据通道衔接。
为了直观地把握拓扑的观点，清楚这个观点是含糊不清的十分主要的。
它的含糊不清与面向工具编程里的类含糊不清类似。正式的定义说明了类是数据成员和办法的聚集，但是，没有定义说明商务逻辑的哪一部分该当构成类，哪一部分不能构成类。这完整由编程者决议可封装哪一个商务观点为类，哪一个不能封装为类。编程职员把一切的商务逻辑放在一个独自的类里或许是错误的-因而这实践上在逃避面向工具的设计-别的划分这个逻辑为无限多个小类也是错误的-它把这个程序改变为一大堆难以了解的互相依靠
异样含糊不清的是没有一个独自的准确办法去联系商务逻辑为多个拓扑。独一的经历规矩是拓扑是扩大的原子单位。你可以把拓扑作为全体实行扩大，但是你不能只扩大拓扑的某一方面。因而，假如你希冀未来有扩大自力于功用B的功用B的需求，那末你该当为A创立一个自力的拓扑，为B创立一个自力的拓扑。
让我们举个详细的例子来讲明上面所述：
在我们的图象转换使用里，有两个根本功用：调剂图象巨细和调剂图象亮度。我们可以选摘要么为这两个功用创立一个独自的拓扑，要末联系为“调剂巨细”的拓扑和“调剂亮度”的拓扑。
在前一种情况下，我们将定义线路传输协议，如许就能够传输我们感兴味的功用。假设音讯的第一个字节是“1”表现调剂巨细，或者为“2”表现调剂亮度。我们还应当意想到这类设计牢牢地耦合了两个功用。假如我们未来要对这个拓扑增加更多的处置节点，那末它们中的每一个节点都该当既能调剂巨细也能调剂亮度。
在后一种情况下，两个功用没有联系关系。线路传输格局里不需求特定的“类型”域，由于一切“调剂巨细”拓扑的恳求都是请求调剂图象巨细的，而一切通报给“调剂亮度”拓扑的恳求都是请求调剂图象亮度的。在如许的设计里我们可以自力于另外一个拓扑而扩大一个拓扑。也就是说，假如我们制作出特定的单目的的FPGA来完成调剂图象巨细，那末我们可以容易地把它们衔接到“调剂巨细”的拓扑，而不会影响“调剂亮度”的拓扑。如许的布署以下图所示：
留意：客户端使用既可以（经过拓扑A)恳求调剂图象 ,又可以（经过拓扑B）调剂亮度。任务者1仅仅做图象巨细调剂，任务者3仅仅做亮度调剂。而任务者2可以供给两种服务 。
最初应当留意的是，该当说幸而一个拓扑明晰地自力于其他任何拓扑，才使得拓扑可映照究竟层传输的一个属性，比方TCP端口。这就答应底层的收集依照商务规范标准其行动。例如，它可以丈量由特定拓扑耗费的收集带宽（因而，特定的商务逻辑，比方调剂巨细的服务耗费的带宽与调剂亮度服务耗费的带宽截然相反），如许可以依据拓扑对流量实行调剂，比方经过增加调剂亮度等来克制调剂图象巨细。
传输
凡是，除TCP以外的其他传输机制之上请求运转音讯层，不论是无限宽带（功能缘由），IP组播（最小化带宽运用）或者SCTP(多宿主，心跳等)。
最后的办法以TCP传输Start的，或许增加了TCP缺少的比方心跳等特征，厥后试图在其他底层传输之上供给完整类似的行动。
这类办法存在两个问题：
- 一，在特定的传输之上树立类TCP的封装实践上使得传输成为过剩的了。假如这类办法的行动相似于TCP，那末为何一Start就不必TCP呢？（功能特征扫除在这个规矩以外）
- 二，很多传输实践上不成能硬塞到TCP模子里。比方，定义的IP播送发送数据给收集上一切的机械，而不是像TCP那样发送给特定的目的。
基于以上问题，ØMQ采取了分歧的办法。底层的传输依然保存它们自身的特征，向上不供给通用、一切都包括的接口。但是，供给最小化接口（特别是：音讯联系，音讯分段和音讯原子化），而且请求更高层可以一致地处置分歧的底层传输的特征。
详细的来讲，这意味着传输层上方的封包是相当容易的封包，比方音讯联系协议（当封装TCP时），音讯分段协议（联系长的音讯为适合于基于包传输的几个包）或者后续衔接协议（当衔接PGM（实践通用组播协议的）组播流时，抛弃你取得的音讯的开头部分）：
树立拓扑和路由音讯
收集栈里的每层都是笼统了互联收集庞杂性的某一部分。IP层笼统了查找目标主机路由这个需求。TCP层笼统了收集固有的可丧失这个现实而供给了牢靠性包管。
ØMQ笼统了指定发送数据到特定收集地位如许需求。音讯是被发送到拓扑的，而不是发送给特定的终端节点。从头挪用哪一个与特定商务逻辑严密相连的拓扑意味着当你发送音讯给拓扑的时分，你根本上曾经恳求所供给的特定的服务，比方调剂图象亮度巨细。实践接纳音讯的终端节点是在ØMQ的通明传输方法里选择的。
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。
2KB翻译任务按照
CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
