背景
业务进行高可用架构设计时，主要解决以下问题：
- 正视底层组件故障
- 构建高可用应用，保证业务连续性
- 提供多种构建高可用的方案
- 为不同类型业务设计不同的高可用方案
原则
在设计业务高可用时我们总尝试总结一些方法论或找到一些原则，其实墨菲定律可以作为高可用设计的原则。
云平台中的任何一台云服务器均有可能宕机，也一定会宕机；任何一块硬盘均有可能丢失数据，也一定会丢失数据。这些我们可以成为底层资源的不可靠性，不仅云平台，传统IT架构也是同样的情况。我们应该设计更复杂的逻辑来避免云服务器宕机、云硬盘丢失数据吗？不是的，在云平台中各项产品及服务会提供相应的SLA（Service Level Agreement），业务构建在云服务之上，架构师需要做的是正视每一个细节、每一个可能出现故障的组件，通过上层应用设计去解决底层组件的不可靠。
实现高可用，就要做到冗余、避免单点。我们采用N个9的方式来衡量高可用，不同的9代表了不同的允许停机时间，如下图：
方案
可用区级别的高可用
依据前面设计规则，避免单点，那就要避免云主机的单点，业务部署采用多台服务器即可避免单点（相信现在没有多少应用可以仅由一台云主机支撑）。既然做到了云主机级别高可用，自然而然要进行跨可用区部署，不增加成本、也基本不会增加系统部署难度，还能避免单个可用区造成的单点。因为云服务商在设计可用区概念时就考虑了可用区之间的低延迟、无差别内网互通，同时还因为可用区之间相距数十公里，而隔离了风险。
地域级别的高可用
更通俗的名称是两地三中心部署，一些对可靠性要求更高的业务显然不满足于单个地域部署业务，考虑到天灾人祸，银行、大型电商等业务需要做到跨地域的两地三中心部署。通过了解地域及可用区的概念，我们可以知道地域之间的通信是走公网或云服务商提供的高速通道，不同于可用区之间的低延迟，地域之间延迟相对较高，实现跨地域的业务部署、数据主从单向同步这些都不难，而数据库主从一致性和时效性将会成为两地三中心难点。
云平台级别的高可用
按照墨菲定律来说，仅选用一个云厂商也是属于单点，需要选用多个云服务商来支撑业务运行。而实现多云部署，考虑的因素又不全相同，按照流量进行切分，还是按照不同业务进行切分？仅上层应用实现多云还是数据也要分布式存储？采用多云是为了凑热闹，还是为了防止云厂商绑定，或者是真的有需求要采用多个云平台？
多云部署讲从另一篇文章中进行介绍，大家可以先思考起来了。
云平台组件自身高可用
如果在上层应用设计时充分考虑了墨菲定律，如果底层云平台组件出现单点又怎么避免？云服务商不可能会忽略这个的，云主机在底层物理机故障时可以实现整机迁移、负载均衡ULB自身是高可用设计。
疑问
1. 进行高可用架构设计需要增大费用预算吗？如何在高可用和费用之间进行平衡？
2. 业务进行高可用设计，那么代码层面需要做哪些调整？状态数据肯定不能写在本地云主机了，写到Redis或UMQ？业务API为什么要设计成幂等性？
3. 我们知道负载均衡ULB是在同一个地域内进行流量分发，那么全局负载均衡有哪些实现的方案呢？
解答你的问题
关于高可用架构设计，还有很多细节、应用最佳实践，带着你的问题和思考来参加我们的进阶云架构师培训，将会深入解答这些问题，并有资深讲师跟你探讨工作中遇到的难点，帮你出出主意。
