前言
上文说到了关于高并发的一些原则及设计，这篇主要是讲讲关于高可用这一块，毕竟都是难兄难弟，谁也离不开谁。
关于高可用？
高可用的本质就是对系统的不确定性做预期准备，来保证服务的健康，包括经常听到的数据丢失、容灾、故障等除了不可抗因素外，要达到所谓衡量标准的N个9。
关于N个9的计算方式，例如3个9：(1-99.9%) * 365 * 24=8.76小时，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
设计高可用原则
-
降级：总的来说就是保障数据最终一致性，分散流量，提前预处理或分散处理，前面文章里面说到的Hystrix熔断就是实现服务降级与依赖隔离，对访问down服务进行隔离丢给降级后的服务处理，防止影响到其它服务。这里说的是服务/业务方面的降级，当然还有很多其它方面。例如：
降级-
超时降级：类似推荐或者评论啊，暂时不展示或者暂未更新对整体不会有太大的影响。 -
依赖降级：针对的是一些外部服务，一些不稳定的API。 -
故障降级：网络、RPC服务等挂掉了，处理方案可以通过缓存、默认值、兜底数据来保障。 -
限流降级：针对一些超大流量做友好处理。
-
-
隔离：将系统或资源分开，服务之间都是有依赖的，很容易因一方面服务故障导致滚雪球，隔离能够保障其它服务不会受影响，把问题控制并降低。-
线程隔离：请求分类，不影响其它分类线程池的正常运行。
线程隔离 -
进程隔离：物理分离，部署多个实例，通过负载均衡路由转发，但是更好的解决方案是将系统拆分为多个子系统来实现隔离。 -
读写隔离：类似Redis就可用通过主从复制模式将读和写进行集群分离。 -
动静隔离：前面说的高并发也提到过，都是相辅相成的，把动态内容和静态资源分离，静态资源可用提前做缓存。 -
爬虫隔离：主要是为了防止恶意请求流量，会导致正常流量不可用，所以一方面可用通过限流解决，一方面可用将爬虫单独路由到单独服务上，或者让爬虫只能访问到cache。 -
热点隔离：热点一般都是能够提前预知的，比如秒杀、抢购、大降价等，最好是做成独立系统或者服务进行隔离，也可用通过缓存和队列来进行削峰。
-
-
限流：限流主要是防止流量超出系统峰值，是限制流量穿透到后端薄弱的应用层，这个可用从多个方面考虑；最终做到有损服务而不是不服务。常用的限流算法有令牌桶、漏桶等。-
限制并发/连接/请求数：系统都是由阀值（TPS/QPS）的，超过了要么非常慢，要么直接被击垮。 -
时间内/平滑限流：限制时间内的请求次数，或者每隔多长时间处理一个请求。 -
接入层限流：接入层也就是请求流量的入口，像Nginx自带的两个模块就可以，连接数限流模块和请求限流模块。
-
-
分流：引流就是当某个服务挂了或者某个地方故障了需要把流量引向其他好的服务或者备用服务上去。负载均衡与反向代理
超时与重试机制：设置超时能够避免慢请求累积导致系统雪崩，需要设置合理的重试机制，并且应该和熔断、快速失败机制配合。回滚：当程序或者数据出错，可用通过回滚恢复到最近的一个正确版本上，比如事务回滚、代码库回滚、更新版本回滚、数据库回滚、静态资源回滚等等。压测与预案：评估系统的稳定性和性能，提前做好应急预案。
总结来说通过降级保证服务有损而不是不可用，通过限流保护服务健康避免雪崩，通过分流与隔离保障服务正常并能够对故障实行隔离，设置合理的超时与重试机制避免请求堆积，通过回滚能够快速修复。做到这些往往能实现系统的高可用。
附上设计例图：
结语
关于例图里面的一些详细示例以后再慢慢补充吧！
推荐：浅谈高并发和设计的一些原则(JAVA)
个人博客~
简书~
