（随笔）基于路由的消息传输系统（1）

脑袋里有一些消息传输系统架构的想法，其主要核心内容就是消息路由，从今天开始整理，不确定能否坚持下去，直到有一个比较清晰的系统架构的思路。


想研究什么、不研究什么。
    如果有一个相对清晰的系统架构，反过来可以思考我们可以用这个消息系统来做什么。除非有必要，否则在这里都不会涉及关于“什么是”的问题。

    内容转换。这是系统集成的一个相对独立的、必不可少的领域内容。跟消息传输关系不大。
    消息队列。这是消息系统中承载消息的容器，简单的可以理解为消息放在哪里、消息如何存放、消息从哪里取出。其实现技术也是一个比较专业、深层次的领域，包含管理调度、缓存、事务、持久化等多方面的技术，但它也不是这个架构主要关注的内容。

    消息、消息路由。这个应该是这个架构重点研究的内容。


消息是无状态的。
    第一个约束就很纠结，通常来说每个消息就是一个独立的数据实体，不应该跟其他消息存在关联关系，但很可能以后会讨论到消息分组、大消息的拆分、合并，搞不好会违背无状态原则。某些MQ产品确实包含这些违背消息无状态原则的功能，让人觉得整个系统架构看起来很不舒服。
   
交互模式：
    点对点，1:1模型。指定目的地。
    多播、广播。指定目的地的、可能包含通配符的确定、不确定目的地个数。1：(0-N)模型
    发布/订阅。基于消息内容(消息主题)的广播模型。1：（0-N），它的目的地是由订阅者反向选择的。
    请求/应答。这种交互模式是系统集成中最常用的，但传统的JMS以及MQ产品都没有直接对其提供支持。通常的解决方案是通过两端的两个消息队列，使用点对点模式间接的实现该功能。由于其广泛的应用需求，一个好的消息系统应该为其提供通用的解决方案。
   
服务访问。继承与请求/应答模型，指定要访问的服务，最终通过系统路由为其选择一个提供该服务的目的地。

传输网络
    多个节点组成的消息传输系统。
    最简单的是单一路由的线性网络。
    多个节点的对等网络
    分层网络
    局部对等网络+分层网络
集群
    针对高可靠性要求的主备(Master/Slave)集群。
    高可用性、高伸缩性的负载均衡集群

消息传输系统的最基本需求就是把消息传输到期望的目的地，各种交互模式、各种网络拓扑结构、集群，基本上都可以概括成重复的“从哪里取出消息，再把消息传输到哪里”的过程。

传输系统个节点间的通讯协议只有一个，那就是消息传输协议。当然系统管理监控、订阅发布、集群功能等都存在网络交互的需求。但这些功能的实现都可以通过消息系统自身的消息交互功能来实现，这样的系统架构看起来就比较优美。

实际上最终的消息传输系统也可能会包含两个消息传输协议，一个是应用客户端连接消息服务器的通讯协议，另一个是服务器之间的通讯协议。当然可以做到只使用一个传输协议，但考虑到需要针对不同场景进行针对性的优化，可能一个传输协议无法做到二者兼顾。比如应用客户端协议可能希望有更高的可靠性（需要分布式事务）以及更短的响应时间，而服务器之间的协议可能希望有更高的传输效率、最大的吞吐量。
从上面的分析来看，完全有可能把一个消息系统建立在一个通用的、基础的消息路由框架下。

不要大而全
    做通用产品最头疼的问题就是要考虑可能存在的各种各样应用需求。关于这个问题，我的想法就是设计一个足够灵活的架构，为预见到的许许多多的功能保留其实现的可能性和便利性。然后就集中资源去做那些核心的、迫切需要的功能。想到，但不做到。也是一种境界。