对于双十一，优惠券、补贴金、满减是“买买买人”的噩梦，高并发、高性能、高可用也是技术人的魔咒。双十一秒杀时几万人抢同一个商品，直播间几十万人同时抢红包，每秒订单高达 58 万笔，在双十一大促活动当天，如何保证流量激发的时候不宕机？本篇文章将揭秘如何基于云平台来构建高可用的互联网应用。
什么是高并发、高性能、高可用
高并发（High Concurrency）
高并发是如今互联网分布式系统架构设计必须要考虑的因素之一，能够保证系统同时并行处理很多请求。高并发意味着大流量，需要运用技术手段抵抗流量的冲击，这些手段好比操作流量，能让流量更平稳地被系统所处理，带给用户更好的体验。高并发相关常用的一些指标有响应时间（Response Time）、吞吐量（Throughput）、每秒查询率 QPS（Query Per Second）、每秒事务处理量 TPS(Transaction Per Second)、并发用户数等。
- 响应时间（Response Time）：系统对进来的请求反应的时间，比如你打开一个页面需要 1 秒，那么这 1 秒就是响应时间。
- 吞吐量（Throughput）：吞吐量是指每秒能处理多少请求数量，好比你吃饭，每秒能吃下多少颗米饭。
- 每秒查询率 QPS（Query Per Second：秒查询率是指每秒响应请求数，和吞吐量差不多。
- 每秒事务处理量 TPS(Transaction Per Second)：每秒响应事务请求数。
- 并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。
高性能（High Performance）
什么是高性能呢？高性能是指程序处理速度非常快，所占内存少、CPU 占用率低。高性能的指标经常和高并发的指标紧密相关，想要提高性能，那么就要提高系统高并发能力，两者互相捆绑在一起。应用性能优化的时候，对于计算密集型和 IO 密集型还是有很大差别，需要分开来考虑。还有可以增加服务器的数量、内存、IO 等参数提升系统的并发能力和性能，但不要浪费资源，要考虑硬件的使用率最高才能发挥到极致。怎么样提高性能呢？
- 避免因为 IO 阻塞让 CPU 闲置，导致 CPU 的浪费。
- 避免多线程间增加锁来保证同步，导致并行系统串行化。
- 免创建、销毁、维护太多进程、线程，导致操作系统浪费资源在调度上。
高可用（High Availability）
高可用通常用来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。假设系统一直能够提供服务，我们说系统的可用性是 100%。如果系统每运行 100 个时间单位，有 1 个时间单位无法提供服务，我们说系统的可用性是 99%。很多公司的高可用目标是 4 个 9，也就是 99.99%，这就意味着，系统的年停机时间为 52.6 分钟。
实现一个高可用的互联网应用和服务是个非常具有挑战的任务。每个架构师对高可用或许都有不同理解。对很多架构师而言，高可用意味着服务不存在单点故障、数据有冗余备份、架构设计上避免使用单点。
基于云平台构建高可用的互联网应用
高可用自下而上可分为三个层面。
首先是资源高可用。就云平台而言，这通常指的是 IaaS 资源的高可用。IaaS 即 Infrastructure as a Service（基础设施即服务）, 一般指的是云平台为用户提供的 IT 基础架构服务，如计算、存储、网络等，类似于大家生活中使用的水和电一样。
其次是应用高可用。就云平台而言，这通常指的是 PaaS 服务高可用。PaaS 即 Platform as a Service（平台即服务）, 一般指的是云平台为用户提供的中间件服务、数据库服务、日志服务、大数据处理服务等一系列应用支持服务。
最后是服务高可用。就云平台和对用户而言，这通常指的是 SaaS 服务高可用。SaaS 即 Software as a Service（软件即服务），一般我们指的是由软件提供商和服务商在互联网上直接提供给客户，通常是面向最终用户的多租户服务。
IaaS 服务高可用
我们将依次说明云平台是如何通过计算资源高可用、存储资源高可用、和网络资源高可用做到 IaaS 层高可用的。
首先，计算资源的高可用相对比较简单，它一般通过在不同可用区（Zone）部署相同的计算类型资源来实现。下图中举例了一个地域（Region）的不同可用区（Zone）部署了相同实例类型 ID 的计算资源。这里地域（Region）通常是指不同城市，比如北京或上海， 而可用区（Zone）通常指一个城市分布在不同地点位置的机房。
在存储资源高可用上，青云实现了跨区的本地多副本。同时青云自研的 NeonSan 云存储架构在超高性能下实现了云存储的高可用。它基于 RDMA 技术，在实现高可用的同时，最大发挥出了 SSD 云存储的性能。
在网络资源高可用方面，青云在 QingCloud 公有云平台构建了跨区高可用的多种网络资源，这包括弹性公网地址（Elastic IP）、私有网络 VPC、基础网络 Vxnet、负载均衡器、NAT 网关等网络资源。
PaaS 高可用
PaaS 高可用一般通过应用集群来实现。集群一般可分为主从集群（包括一主多从，甚至多主多从）和对等集群。
主从应用集群通常是用在数据只能一个实例进行修改的情况。而对等集群通常用在数据可进行并发修改的情况。
其中一种实现一主多从集群的方式是借助应用协调服务（如 Zookeeper) 来帮助集群进行主从选举。为达到应用集群的高可用，我们通常会在选举出 Master 节点后将一个写VIP 绑定到 Master 节点中。而将一个读 VIP 通过负载均衡绑定到多个 Slave 节点上。这个绑定关系需要随着集群拓扑结构的变化而动态变化。
实现一主多从集群的另一种方式是在应用集群内部实现分布式一致性协议（如 Raft 算法） 帮助集群进行主从选举，选举出集群当前的 Master 主节点。
在实现对等型集群上，我们通常使用负载均衡器来协助进行流量分发，实现对等型高可用集群。
实现应用集群需注意几个关键要素：集群的升级、集群的扩缩容、集群的备份与恢复。它是一个集群生命周期管理所涉及的范畴。
青云在 PaaS 平台上为用户提供了一个实现了高可用应用集群的服务框架：AppCenter 应用基础架构。
在 AppCenter 框架下，用户不仅可以方便进行高可用应用集群的开发与创建，也可以进行集群的扩缩容等维护。借助青云的自动弹性伸缩服务，还能根据应用的负载来调整集群工作节点数量大小。例外，我们可通过配置弹性伸缩服务，在 8 点晚高峰时将集群是节点数自动增加，以提高集群的负载处理能力。在晚 12 点时自动将集群数量减少以降低资源使用成本。
青云提供的另一个 PaaS 高可用服务平台是 QingCloud Kubernetes Engine (QKE)。QKE 是一个容器服务平台，它集成了 Kubernetes、可视化集群管理工具 KubeSphere，整合了青云云平台的 IaaS 资源，为用户提供了一个集弹性、简单、开放、高可用于一身的容器服务运行环境。
SaaS 高可用
在 SaaS 高可用上，我们首先想到的是实现服务的多区高可用。
- 在引流层，我们可以在 QingCloud 云平台上通过 GSLB、双 EIP、双负载均衡器达到引流层高可用的效果。
- 在应用层，我们可以将前面所讲的 PaaS 应用集群部署为多区高可用来达到多区高可用的效果。
- 在数据层，我们也可将数据库服务部署为多区高可用来达到此效果。
在 SaaS 服务异地高可用上，我们通常会考虑两地三中心、异地灾备、异地双活这样的架构。
首先是两地三中心。下图显示了一种两地三中心的架构，在这种架构中， 除了有一个 Master 主服务，在同城的 2 个机房会部署多个 Slave，同时异地的机房还会部署至少一个 Slave 从服务。这些 Slave 通常可分担一些只读业务。
其次是异地灾备。与两地三中心不同，异地灾备中同城和异地通常都有完整和独立数据库集群。数据通过异步复制同步到异地的灾备中心中。异地灾备中心通常是不接受服务请求，而是进行 Hot Standby。
最后是异地双活。上面说的异地灾备因为异地灾备中心不处理业务，会比较浪费资源。我们就会想要把它这部分资源利用起来，让异地能够分担一定的业务，这就是我们说的异地双活。服务的异地高双活相对比较复杂，它通常需要基于地域进行业务分区和数据拆分。例如，我们首先将业务数据根据地域拆分成了独立 A、B 两个库。A 地的业务由 A 地服务来处理，在 B 地进行 Hot Standby；B 地的业务由 B 地服务来处理，在 A 地进行 Hot Standby。A、B 两地的数据通过异步复制来同步。针对公共数据和不能同时修改数据，我们还会考虑设置全局库和全局服务，全局数据通过同步或异步复制达到数据的最终一致。
SaaS 服务高可用特别是异地高可用需要注意几个要点：
- 缓存 100% 可重建
- 业务分片
- 主从服务切换的时间
- 数据同步带宽
考虑缓存 100% 异地可重建主要是因为相对于数据库的异步复制，缓存的异步复制通常需要更多的复制带宽和更小的网络延时。
为了保障 SaaS 服务的高可用，我们还要考虑对 SaaS 服务采取保护性措施。
API 网关为我们提供了一种很好的对 SaaS 服务进行保护的方式。
API 网关可以让我们对 API 请求进行限流、熔断、服务降级，以提高我们在关键服务的高可用性。
总结来说，在云平台构建高可用的互联网服务就是在 IaaS、PaaS 和 SaaS 层避免单点，并做好防护。
Q&A
如何在不同云平台间去做服务的迁移？
服务迁移首先保证的是数据的迁移，在迁移过程我们首先要考虑和实现的是数据的在线同步。在数据同步的基础上我们才能够将应用服务在另一端建起来，最后再通过切换引流或流量入口方式来完成服务的迁移。
如果本地服务不可用，我们如何将服务切换到异地？
通常的切换我们是会采用一系列脚本来实现，这不仅包括完成引流的切换，可能还会包括数据的加载，如缓存的预热等，否则业务流量突然过来，缓存可能就会被击穿，数据库扛不住。当然我们也可以通过一些方式，比如业务流量复制，来提前达到数据预热。
如何在高可用、高性能基础上实现数据的一致性？
任何事情都有个“不可能三角”。分布式高可用、高性能、和一致性正是这一不可能三角。三者我们不可同时兼得，我们只能尽量去取舍权衡。比如在保证高可用、高性能上情况下、数据一致性或只能保证最终一致。
QingCloud 的 PaaS 服务没有服务器规格型号，如何将 QingCloud 的 PaaS 服务去跟友商对比？
目前 QingCloud PaaS 服务正向 PaaS 服务化发展，用户可以通过服务计划用量，例如 QPS 这样性能指标需求去选择和衡量青云的 PaaS 服务，比如 20 万 QPS。
关注“青云技术社区”公众号，后台回复关键字“云原生实战”，即可加入课程交流群。
作者
梁朝东 青云科技容器及应用基础服务高级经理
本文由博客一文多发平台 OpenWrite 发布！