分布式系统服务单点问题的探讨 _分布式架构

分布式系统服务单点问题的探讨
在分布式系统中，单点问题是一个比较常见的问题，对于单点问题可以分为有状态服务的单点问题和无状态服务的单点问题。无状态服务的单点问题
对于无状态的服务，单点问题的解决比较简单，因为服务是无状态的，所以服务节点很容易进行平行扩展。比如，在分布式系统中，为了降低各进程通信的网络结构的复杂度，我们会增加一个代理节点，专门做消息的转发，其他的业务进行直接和代理节点进行通信，类似一个星型的网络结构。
参考上面两个图，图中proxy是一个消息转发代理，业务进程中的消息都会经过该代理，这也是比较场景的一个架构。在上图中，只有一个proxy，如果该节点挂了，那么所有的业务进程之间都无法进行通信。由于proxy是无状态的服务，所以很容易想到第二个图中的解决方案，增加一个proxy节点，两个proxy节点是对等的。增加新节点后，业务进程需要与两个Proxy之间增加一个心跳的机制，业务进程在发送消息的时候根据proxy的状态，选择一个可用的proxy进行消息的传递。从负载均衡的角度来看，如果两个proxy都是存活状态的话，业务进程应当随机选择一个proxy 。
那么该解决方案中会存在什么问题呢？
主要存在的问题是消息的顺序性问题。一般来说，业务的消息都是发送、应答，再发送、再应答这样的顺序进行的，在业务中可以保证消息的顺序性。但是，在实际的应用中，会出现这样一个情况：在业务进程1中，有个业务需要给业务进程3发送消息A和消息B，根据业务的特性，消息A必须要在消息B之前到达。如果业务进程1在发送消息A的时候选择了，在发送消息B的时候选择了，那么在分布式环境中，我们并不能确保先发送的消息A一定就能比后发送的消息B先到达业务进程3 。那么怎么解决这个问题？其实方案也比较简单，对于这类对消息顺序有要求的业务，我们可以指定对应的proxy进行发送，比如消息A和消息B都是使用进行发送，这样就可以保证消息A比消息B先到达业务进程3 。
整体来说，对于无状态的服务的单点问题的解决方案还是比较简单的，只要增加对应的服务节点即可。
有状态服务的单点问题
相对无状态服务的单点问题，有状态服务的单点问题就复杂多了。如果在架构中，有个节点是单点的，并且该节点是有状态的服务，那么首先要考虑的是该节点是否可以去状态，如果可以，则优先选择去除状态的方案（比如说把状态存储到后端的可靠DB中，可能存在性能的损耗），然后就退化成了一个无状态服务的单点问题了，这就可以参考上一节的方案了。
但是，并不是所有的服务都是可以去状态的，比如说对于一些业务它只能在一个节点中进行处理，如果在不同的节点中处理的话可能会造成状态的不一致，这类型的业务是无法去除状态的。对于这种无法去除状态的单点的问题的解决方案也是有多种，但是越完善的方案实现起来就越复杂，不过整体的思路都是采用主备的方式。
第一个方案就是就是增加一个备用节点，备用节点和业务进程也可以进行通信，但是所有的业务消息都发往节点进行处理。节点和Slave节点之间采用ping的方式进行通信。Slave节点会定时发送ping包给节点，节点收到后会响应一个Ack包。当Slave节点发现节点没有响应的时候，就会认为节点挂了，然后把自己升级为节点，并且通知业务进程把消息转发给自己。该方案看起来也是挺完美的，好像不存在什么问题，Slave升级为后所有的业务消息都会发给它。但是，如果在内部有一些自己的业务逻辑，比如说随机生成一些业务数据，并且定时存档。那么当和Slave之间的网络出现问题的时候，Slave会认为挂了，就会升级为，同样会执行的相应的业务逻辑，同样也会生成一些业务数据回写到DB 。但是，其实是没有挂的，它同样也在运行对应的业务逻辑（即使业务进程的消息没有发给旧的了），这样就会出现两个进行写同一份数据了，造成数据的混乱。所以说，该方案并不是一个很好的方案。