高可用高性能系统（五）基于规则的请求路由

    首先必须申明，这不是个路由器，而是借用路由器的特性。一般说来，传统的路由器，将IP包转发到目标机器上，那么他的路由规则就是IP地址。但对服务请求来说，可能是SQL语句或者其他具有规则特性的请求。我们可以建立一个服务，按照一定的规则，将这些请求分发到其他服务上去，就像路由器转发IP包那样。这个路由服务主要的功能就是按规则分发，但他可以也可以不需要处理请求的结果数据。对于接收到请求的服务来说完全可以直接将数据返回给客户端。
    可能会很奇怪，要这个功能有什么用呢？其实这个功能非常有用，特别是在高可用高性能的系统中。以DBMS为例，如果一个数据按时间段分布在12个数据库中，每个数据库存储每天中2个小时的数据。那么如果有一个请求需要计算1天的数据，就需要将这个请求分发到12个数据库中，这个例子多见于海量数据的情况。当然，也有的时候，每个数据库的数据是完全相同，当遇到写操作的时候，需要同时向多个数据库写入数据。而读请求只由一个数据库来响应。这样一读多写的请求同样需要一个服务来处理这个分发功能。上面2个例子是典型的高可用高性能系统DBMS的方案。但在传统的C/S架构中，客户端和服务器直接交互，缺乏这种中间环节，也失去了这种灵活性。
    从单个请求的总体计算时间看，可能会稍大点，因为需要增加路由的计算，但由于计算负荷被多个机器分担，用户响应时间反而要减少很多。当某个服务器失效时，由于路由服务的存在，完全可以将这个请求重新定位到一个可用的服务。在传统的C/S架构中，插入路由服务，并不是单纯意义上的三层或者四层。对于路由服务来说，同样可以插入到应用服务和客户端之间，关键问题是他需要基于什么样的规则来实现请求的分发功能。
    同时，我们还必须关注一个问题，当请求被分发到多个服务器之后，其中一个处理失败，我们应该采取什么策略来处理这个结果呢？如果我们采用鸵鸟策略，将它置之不理，那么这种情况可能会破坏了数据的完整性。但如果我们将它视为一个事务，全部回滚的话，也可能导致错误。比如期货交易系统中的成交回报，成交回报是交易所返回的报告，说明某笔委托已经完成交易，不论我们在存储这个信息的时候是否发生错误，那么交易所不可能去回滚。所以它必须完成。我们必须不断的强制发送这个存储请求直到全部成功。但是这种方案的后果，可能导致系统的性能严重下降。我们应该认识到，如果路由服务管理着越多的节点，那么发生错误的概率越大。这个问题和UDP多播的情况很相似。
    我们知道，就像TCP和UDP那样，一个请求是否需要被复制，是否需要保证完整性，是否必须具备实时性，都是因情况而异的。针对不同的情况，我们可以采取不同的策略，而不是一概而论。现在我们讨论3种比较通用的情景：
    1、需要高可靠性：毫无疑问，我们必须同时保证所有的请求得到同样的结果，当然一个分发出来的请求失败后，我们需要不断的重启，当最终无法解决时，我们必须将负责处理这个请求的点标志为失效。
    2、需要高可靠性，但容忍较大的延时：和上面一样，我们必须保证全部分发的请求处理成功，不过有点比较特殊，如果遇到失败的处理，我们可以将这个请求缓存下来，等待机会继续重发，而不是花大量的资源来不断重试。
    3、只要发送一次就可以了：这种情况比较简单，我们把它当作UDP那样就可以了。

    对于使用路由服务的系统来说，时序也是很重要的考虑因素。我们打个比方，一个客户的保证金为零，但他先卖出合约，然后再买入合约，这个交易过程是可以成功的。但如果这个过程交换了次序却是失败，而这种情况在我们的系统中，以及分布式系统中完全可能发生的。当多个请求被多个路由服务所分发，那么在时序上是很难保证的，除非被严格的排序。我们可以使用序号或者时间戳等方式来控制这种时序性，而不是去排序。