教师节刚过，各种段子层出不穷。比如这个每年必发的梗：
然而就在刚刚，优秀学员张大妈家疑似发生了类似事件（难道也是因为中秋发了个mao导致？）
俗话说HA做的好，老公回家早。今天主要就研究下Orchestrator的几种高可用方式。
Orchestrator支持以下几种方式部署：
1 无高可用：
最简单的方式，适合测试、开发环境。后端数据库可用MySQL或者sqlite
2 半高可用：
后端基于mysql主从复制的master或负载均衡，自身数据库不具备高可用。
3 高可用方式：
这里又分为两种架构：
后端共享数据库方式（Shared backend）：多Orch节点使用同一后端数据库，如Galera/XtraDB Cluster/InnoDB Cluster/NDB Cluster。在数据库层面通过分布式架构共享数据。
基于raft协议方式（orchestrator/raft）：多orch节点都有各自的后端数据库，节点间通过raft算法来进行投票和同步。
下面就这几种方式展开话题
半半子小姐姐镇个楼
1 无高可用
单节点，单后端DB。
后端DB可部署在本机或者其他机器。
这样做成本很低，最少用1台服务器就可以部署。
比较适合测试环境
2 半高可用
多个Orch节点使用一套后台数据库。
后台数据库可以是主从复制，也可以是前面有负载均衡的复制。
由于只依赖mysql原生的复制，搭建简单又具备一定的高可用（orch多节点），但是Orch自身的后端数据库不具备高可用能力，即使前面加上HAProxy之类做负载均衡仍有脑裂的风险，因此不建议生产使用。
3 共享后端数据库的高可用
在架构2的基础上，改用共享的后端数据库，如Galera/PXC/InnoDB Cluster/NDB Cluster。
由于数据库集群本身实现了高可用，可避免脑裂。但数据库集群的维护有一定的技术门槛
Orch节点访问数据库可以只单点写入，也可以多点写入。
Orch应用之间无通信。
底层数据库集群有大量数据交互，对网络要求较高。尤其跨机房、跨地区场景。
4 基于raft协议方式
Orch节点之间通过raft协议相互通信来实现高可用。
每个Orch节点都有各自独立的后端数据库。
Orch程序和后端数据库可以部署在一起，也可以分开。
数据库节点之间无通信。
只有一个leader节点来探测拓扑和发现实例，其他节点只监控和投票。
节点数量要奇数，建议使用3或者5节点。
由于Orch节点之间数据交互较少，适合跨机房、地区的大规模部署。
配置Raft高可用相关参数：
https://github.com/github/orchestrator/blob/master/docs/configuration-raft.md
配置方法：
"RaftEnabled": true,"BackendDB": "mysql","RaftBind": "10.7.91.63","RaftDataDir": "/usr/local/orchestrator","DefaultRaftPort": 10008,"RaftNodes": ["10.7.91.63","10.7.91.168","10.7.91.169"],
RaftBind是本节点Orch IP
RaftNodes是所有Orch节点IP列表
默认端口10008，所有的节点要使用相同端口
在Home -> Status 中可以看到当前的节点角色，只有1个leader
脑力风暴：共享后端数据库的HA
参考某国外的大神的架构，前面用ProxySQL做读写分离，再花点小钱使用RDS厂商的黑盒技术来保障后端数据库高可用。
