设计之道避免服务单点
单点问题
对外提供能力输出的软件或硬件，有且仅有一个节点提供能力的保证，包括路由器、磁盘存储、软硬件网关、软件服务、注册中心、DB等，任何单点的节点，都存在故障的可能，根据墨菲定律，只要是可能发生的问题就一定会发生，因此为了提供稳定的服务能力，一定要尽力避免单点的存在！
避免单点
- 主从方式
redis、mysql、zookeeper等中间件的HA是可以通过主从方式做的实现，当master发生故障时，会进行重新选主和故障转移，该方式下因为主从节点是不对等的，所以需要保证故障转移后数据的一致性问题 - 集群方式
该方式下，所有节点都是平等独立，任何节点的下线，对其他节点没有任何影响，这场景下典型的实现是通过nginx实现的反向代理组成服务集群，另外比如eureka提供的注册中心能力，也是基于集群方式
案例实现
这里以一个真实的场景，对设计" title="服务设计">服务设计中避免单点依赖做讲解，我们需要设计一个爬虫的系统，需要满足如下的特点：
- 工作节点可伸缩
伴随着业务的增长，工作节点需要承担的抓取任务会愈加频繁，所以系统架构需要支持工作节点的动态伸缩 - 工作+调度节点高可用
任何工作节点和调度节点都是理论上是不可靠的，所以这两组节点需要支持集群的工作模式
核心实现：
- workNode启动，在zookeeper的/nodes目录，注册一个临时节点，并且监听/schedule节点
- scheduleNode启动，监听/nodes目录，当该节点下的目录发生变化（workNode的伸缩变化），获取到所有的任务taskId,获取到所有的workNode名字，执行分配，写入/schedule
- workNode节点感知到/schedule发生变化，则重新把task刷新至内存
- scheduleNode会有两个节点，一个节点作为standby存在，master节点对任务做分配
以上是 设计之道避免服务单点 的全部内容， 来源链接： utcz.com/z/512746.html
