这里的最小成本 = 最少的硬件成本 + 最小的维护成本 + 最小的配置成本
目前常用的高可用方案patroni+etcd，读写分离方案haproxy，当然同时我们还要考虑haproxy的高可用比如使用keepalived。
那么高可用+读写分离同时生效 = patroni + etcd + haproxy + keepalived。
有没有成本更小的方案替换上面的方案呢？
有，这个方案就是patroni + etcd + haproxy。
有人就问题了，如果使用haproxy就不需要配置ha吗？答案是不需要，那么是如何做到的呢？
这里我们先了解一下patroni回调脚本callbacks:
当patroni触发的特定动作比如启动、关闭或者角色切换时会触发一个脚本，同时默认会给这个脚本传三个变量：
$1 - action, patroni触发的动作,stop/start/on_role_change/restart/reload
$2 - role, 当前节点的角色，master/{slave|replica}
$3 - scope, 作用范围，pgsql服务
patroni配置文件增加：
启动patroni：
然后我们就可以修改回调脚本，当执行角色切换动作时，如果是升级为主节点则执行VIP绑定，否则解绑：
同时，在脚本中增加当执行角色切换动作时，升级为主节点VIP绑定后则启动haproxy
(这里就不写了，想来大家都应该知道怎么写)。
下面简单介绍haproxy中读写分离的配置信息：
整个流程是大概是这样的：
启动patroni->调用callback脚本->主节点->绑定VIP-> 启动haproxy
↓->备节点->如有haproxy，则关闭haproxy
haproxy一直跟随主节点，这样我们就可以不配置haproxy高可用，达到读写分离一直可用的目的，且硬件数量、配置与维护难度都低于文章开篇所提到的方案。
当然还有更多细节问题需要在测试与运行过程中去发现和解决，比如如何实现自动话配置haproxy、haproxy启动失败、微服务如何配置VIP等问题。
欢迎大家一起讨论学习。
