3°

设计之道-避免服务单点

单点问题

对外提供能力输出的软件或硬件,有且仅有一个节点提供能力的保证,包括路由器、磁盘存储、软硬件网关、软件服务、注册中心、DB等,任何单点的节点,都存在故障的可能,根据墨菲定律,只要是可能发生的问题就一定会发生,因此为了提供稳定的服务能力,一定要尽力避免单点的存在!

避免单点

  • 主从方式
    redis、mysql、zookeeper等中间件的HA是可以通过主从方式做的实现,当master发生故障时,会进行重新选主和故障转移,该方式下因为主从节点是不对等的,所以需要保证故障转移后数据的一致性问题
  • 集群方式
    该方式下,所有节点都是平等独立,任何节点的下线,对其他节点没有任何影响,这场景下典型的实现是通过nginx实现的反向代理组成服务集群,另外比如eureka提供的注册中心能力,也是基于集群方式

案例实现

这里以一个真实的场景,对服务设计中避免单点依赖做讲解,我们需要设计一个爬虫的系统,需要满足如下的特点:

  • 工作节点可伸缩
    伴随着业务的增长,工作节点需要承担的抓取任务会愈加频繁,所以系统架构需要支持工作节点的动态伸缩
  • 工作+调度节点高可用
    任何工作节点和调度节点都是理论上是不可靠的,所以这两组节点需要支持集群的工作模式

核心实现:


1、workNode启动,在zookeeper的/nodes目录,注册一个临时节点,并且监听/schedule节点
2、scheduleNode启动,监听/nodes目录,当该节点下的目录发生变化(workNode的伸缩变化),获取到所有的任务taskId,获取到所有的workNode名字,执行分配,写入/schedule
3、workNode节点感知到/schedule发生变化,则重新把task刷新至内存
4、scheduleNode会有两个节点,一个节点作为standby存在,master节点对任务做分配

本文由【白中墨】发布于开源中国,原文链接:https://my.oschina.net/13426421702/blog/3158587

全部评论: 0

    我有话说: