接入层
端到接入层，最好通过域名，而不是ip直连。当提供服务的ip，不可用时，可以通过切换dns更换入口。
接入层冗余部署，nginx通过统一的ip（虚拟ip）对外服务，多台Nginx采用keepalive检测，当对外提供服务的nginx挂了，通过把ip切换给备用机器，实现故障转移。
接入层到ui层
接入层到ui层也是通过部署冗余的ui层服务实现，接入层nginx上配置失败检测和转移，当nginx发现某个ui层机器挂了，自动将失败请求转移别的ui机器，并且隔离失败的机器。
UI层到服务层
部署冗余的服务层，ui层每次请求随机请求其中一个服务，并且在失败的情况转移到其他服务，请求种可异步统计每个服务的响应时间，服务可用率，可以设置阈值，当请求平均耗时比如超过100毫秒时，认为这个机器已经超载，减少权重，减少到该机器的流量，当连续失败次数达到一定值认为服务不可用，隔离该服务。
服务层到存储层
redis可以部署集群，利用哨兵机制实现高可用，也可以部署codis集群实现高可用。
mysql可以部署mha或者类似的高可用服务，当主卦了，会自动提升有最新数据的从作为主，当有从服务不可用时自动隔离。
多机房冗余
单机房无论多么冗余，多么牛逼，当施工队靠近，自然灾害发生，还是面临不可用，这时我们需要部署多机房高可用，服务多机房同活很容易，但是对于需要持久化的存储层则需要采用光纤直连，设置保证分布式多机房的情况，至少保证其中两个机房事务已经落盘，才返回给用户成功。当然会牺牲部分速度。
总结
高可用是架构设计上必须考虑的问题，主要是指减少系统因为某些不可抗拒原因带来的不可用时间。方法论：冗余部署+自动故障转移+自动服务降级+自动服务隔离等
