核心设计
本文不接受任何抬杠，谢谢，是摸鱼的时候狐思乱想的杂文哟（如果实现的会最近会做吧）不喜欢就直接右上角吧，不是什么干货
（咱就是个cs垃圾quq）
- 每个Slave节点的Cron会每分钟给Master节点上报一次服务器信息
- Master节点检测如果Slave节点五分钟没上报信息，则认为Slave节点已经Down机，记录状态并发到通知系统
- 无论Master节点还是Slave节点数据库并不存在主从/主主，每个节点都有自己的数据库
- 当Master节点将Slave节点判断为Down机会自动将此信息下发到其他Slave节点
- 当通知Slave节点同步重要数据库完全失败（有重试机制），则Slave节点判断为Down机并下发其他通知节点
- Master节点会像Slave节点发布需要同步的数据（一般为设置同步以及节点列表）
- Slave节点若请求Master节点失败，则会通过同步过来的节点数据库请求其他节点，进行判断若Slave节点请求不通则不操作，若Slave节点请求成功则内部进行选举/按优先级，通过阿里云DNS/DNSPOD将解析记录改到Slave节点，此时Slave节点变为Master节点，新的Master节点只会处理Slave节点时已经同步在数据库的数据，不会处理已经Down机的Master节点的未处理的数据（该系统主要用于提供API，需要关联的操作不多），若Down机Master节点重新上线则会变成Slave节点。
- Master节点添加Slave节点会自动通过DNS API分配一个域名
- 节点UUID是唯一识别码（不认ip地址）
- 当Master节点产生，Master节点无论DNS解析是否成功，部分功能都将运行（例如通知系统）
- 若Slave节点状态正常且收到需要处理的API请求，部分API可直接返回结果，部分需请求Master节点获取许可
- 若出现Master节点Down机进入切换，在切换途中Master节点恢复则Master节点会对API请求返回错误/拒绝处理/转发API至其他节点 视API而定
- 符合这套系统接口的程序，都可以进行由Master节点进行节点管理
- 不同功能Master节点会使用DNS API将一个子域名解析至Slave节点，当Slave节点Down机那么Master节点会自动将子域名通过DNS API解析到新的Slave节点
- 若支持部分功能且支持接口的其他系统，可以作为Slave节点，但不可选举为Master节点（无论Slave节点如何实现功能只要支持接口且功能可用即可成为Slave节点并分配子域名以及服务域名）
备注
- 数据库采用Mysql处理，原计划使用ETCD
- 本实现并不需要网站服务器（Apache Nginx…）,甚至可以在虚拟空间上实现
- 该分布式设计是实现在多台服务器应用部署以及DNS记录之间，与其他分布式设计拥有较大差距
- 本节点管理与资产管理是两个完全不同的功能，节点管理只管理服务
- 不使用Mysql主从同步/主主同步以及ETCD数据库是故意的设计的
- 不使用DNS负载均衡/其他负载均衡服务是为了需要支持更多的功能
- 主要提供API服务，对服务之间的关联性不强
- 资产管理的Agent会协助该分布式设计的实现
- 在可能的情况除了使用dns解析记录还会最大程度的与BGP Anycast结合
- 本方案并非轻量级/成熟解决方案可能只适用于该系统
- 本分布式设计方案非最优设计，仅适用于该系统
- 本分布式设计不支持会话同步
- 部分设计是为了Admin System的资产管理功能
- DNS缓存以及同步问题会通过同步的节点数据库解决
- 是网络操作都会出现问题
- 系统的API主要为无状态API
- 若出现数据问题，每个节点会校对各自的history库来解决问题
- 该方式进行节点切换恢复时间较长，预计五分钟内恢复使用（瓶颈在DNS）若支持BGP AnyCast则速度更快
