高可用（High Availability）一般是指通过良好的系统设计和实现，尽最大程度的减少系统不可用时长；HA是系统架构设计中必须考虑的重要因素之一，我们平时所说的SLA 99.9% 或 99.99%，便是高可用的对外重要体现指标；
而要做到真正的高可用，会涉及方方面面的能力（限流、熔断、弹性、自愈等等），聚石塔云应用PaaS始终致力于成为“帮助客户以较低的技术投入，打造高可用系统”的PaaS平台；下文会简单介绍如何通过聚石塔云应用PaaS已有的能力，来帮助客户打造高可用系统；同时我们会持续引入新的能力，帮助客户不断提升系统的可用性。
对于不同的系统而言，系统架构也各不相同，但“应用实例”作为应用运行时的载体，是所有系统都必然存在的最基本的逻辑单元。它可能是你的java进程（tomcat、springboot2），也可能是一个nginx进程，亦或者是一些进程的集合（业务进程 + 辅助进程（日志收集等））；
理想情况下，我们总是希望我们的“应用实例”可以始终运行并对外提供服务；而现实中，“应用实例”总会因为各种意外情况而终止（如进程OOM、I/O打满等情况）；因此，我们需要一种方式，能够自发的检查“应用实例”当前是否健康，从而决定是否立刻重启它。这就是我们要说的“健康检查机制”，“健康检查机制”可以在“应用实例”已经不可用（即不能对外提供服务）的情况下自动重启，从而继续对外提供服务；
参见：云应用如何配置健康检查。
虽然“健康检查机制”可以解决部分问题，但对于有些情况（如磁盘打满）缺无法解决，因为即使重启也仍然无法对外提供服务，此时就需要配合“监控告警”来提前收到告警，从而提前规避故障的发生；
通常情况下，不同的应用对外提供的服务也各不相同；而如果进行归纳总结，我们会发现有一类应用有以下特点：
1）一天内大部分时间短流量都很平稳，但会在特点时间段有明显的流量峰值（电商类尤其如此）；
2）平时的流量都很平稳，但会偶尔做促销活动（短时间周期），推广时间段有明显的流量增加（各种促销活动）；
3）和某些机构进行了合作推广或广告推广（长时间周期），我们不知道什么时候有效果、甚至不知道效果到底怎么样，所以我们无法预知什么时候流量峰值过来，同时也不知道峰值有多高；
对于以上情况，我们有几种应对方法：
1）可以选择购买足够的机器资源来应对高峰流量；但如果始终保留着这么多的机器资源，无疑会增加我们的资源成本；
2）我们也可以选择每次在高峰流量来临之前，人为的去购买机器扩容，等流量高峰过去后，再释放这些资源；但这种做不仅会让我们的人工运维成本直线上升，而且无法解决我们上面提到的情况3；
对此，聚石塔云应用PaaS提供了《弹性伸缩》能力，可以根据用户的设定，自适应的弹性的扩容以应对流量峰值，在流量峰值过去后，再自适应的缩容以降低成本；
参见：伸缩策略使用说明。
对于一些突发情况，导致服务负载飙高，短时间无法及时恢复业务，为了避免系统由于负载过高导致崩溃，平台提供了限流的能力，通过限制请求量，保证后端服务的稳定性。目前提供的能力仅支持小程序业务，在小程序网关进行流量控制，通过百分比限制用户是否可以访问后端服务，有效的控制访问量。
参见：限流使用说明。
虽然我们已经通过很多手段（健康检查自愈、弹性伸缩、限流等）来保障系统的可用性，但我们都知道，任何系统都无法做到100%的高可用，总会有一些意外的情况导致系统出现问题 或者 埋下故障的隐患，并且我们无法预知是什么问题 以及 是什么时候；但我们希望可以有一种方法或能力，来做到问题来临时甚至来临前提前收到提醒；《监控告警》能力的职责正是如此，充当我们的眼睛和耳朵，可以通过观察系统的各项指标，帮助我们第一时间发现问题，从而可以第一时间解决和规避问题，最大程度的降低损失；
参见：监控告警使用说明。
