分布式架构中的三高：高并发、高性能、高可用

关于高并发

高并发场景

互联网应用以及云计算的普及，使得架构设计和软件技术的关注点从如何实现复杂的业务逻 辑，转变为如何满足大量用户的高并发访问请求。

一个简单的计算处理过程，如果一旦面对大量的用户访问，整个技术挑战就会变得完全不 同，软件开发方法、技术团队组织、软件的过程管理都会完全不同。

架构策略

垂直伸缩

垂直伸缩，就是提升单台服务器的处理能力。

比如用更快频率的 CPU，用更多核的 CPU，用更大的内存，用更快的网卡，用更多的磁盘组成一台服务器，使单台服务器的处理能力得到提升。

垂直伸缩带来的价格成本和服务器的处理能力并不一定呈线性关系。

增加同样的费用，并不能得到同样的计算能力。而且计算能力越强大，需要花费的钱就越多。

而且，受计算机硬件科技水平的制约，单台服务器的计算能力并不能无限增加，而互联网，特别是物联网的计算要求几乎是无限的。

因此，在互联网以及物联网领域，并不使用垂直伸缩这种方案，而是使用水平伸缩。

水平伸缩

所谓的水平伸缩，指的是不去提升单机的处理能力，而是使用更多的服务器，将这些服务器构成一个分布式集群，通过这个集群，对外统一提供服务，以此来提高系统整体的处理能力。

但是要想让更多的服务器构成一个整体，就需要在架构上进行设计，让这些服务器成为整体 系统的一个部分，将这些服务器有效地组织起来，统一提升系统的处理能力。

这就是互联网应用和云计算中普遍采用的分布式架构方案。

分布式技术方案

• 分布式缓存
• 负载均衡
• 反向代理与 CDN
• 分布式消息队列
• 分布式数据库
• NoSQL 数据库
• 分布式文件
• 搜索引擎
• 微服务

将这些分布式技术整合起来，就是分布式架构方案

互联网分布式架构演化

单机架构

微服务架构

分布式缓存架构

负载均衡架构

数据库读写分离

消息队列&反向代理&CDN&分布式数据库架构

海量数据的存储，主要通过分布式数据库、分布式文件系统、NoSQL 数据库解决。

直接在数据库上查询已经无法满足这些数据的查询性能要求，还需要部署独立的搜索引擎提供查询服务。

同时减少数据中心的网络带宽压力，提供更好的用户访问延时，使用 CDN 和反向代理提供前置缓存，尽快返回静态文件资源给用户。

为了使各个子系统更灵活易于扩展，则使用分布式消息队列将相关子系统解耦，通过消息的发布订阅完成子系统间的协作。

使用微服务架构将逻辑上独立的模块在物理上也独立部署，单独维护，应用系统通过组合多个微服务完成自己的业务逻辑，实现模块更高级别的复用，从而更快速地开发系统和维护系统。

关于高性能

高性能场景

互联网应用以及云计算的普及，使得架构设计和软件技术的关注点从如何实现复杂的业务逻 辑，转变为如何满足大量用户的高并发访问请求。

衡量指标

4个性能指标：并发数不变，响应时间足够快，单位时间的吞吐量就会相应的提高。

• 响应时间：指从发出请求开始到收到最后响应数据所需要的时间。反映系统快慢。
• 并发数：系统同时处理的请求数。反映系统负载。
• 吞吐量：单位时间内，系统处理请求的数量。体现系统处理能力。
  • HTTP请求数：HPS
  • 每秒事务数：TPS
  • 每秒查询数：QPS
• 性能计数器：
  • 系统负载System Load
  • 对象和线程数
  • 内存使用
  • CPU使用
  • 磁盘和网络

性能测试

• 性能测试
• 负载测试
• 压力测试
• 稳定性测试

性能优化

性能优化5个过程

• 1.性能测试
• 2.性能分析
• 3.性能优化
• 4.性能测试
• 5.是否符合预期性能目标

性能优化策略

• 1.数据中心优化
• 2.硬件优化
• 3.操作系统优化
• 4.虚拟机优化
• 5.基础组件优化
• 6.架构优化
  • 缓存
  • 消息队列
  • 集群
• 7.代码优化
  • 使用合理的数据结构优化性能
  • 编写性能更好的SQL语句
  • 实现异步I/O与异步方法调用

关于高可用

高可用场景

我们知道，Web 应用在各种情况下都有可能不可访问，也就是不可用。

各种硬件故障，比如应用服务器及数据库宕机、网络交换机宕机、磁盘损坏、网卡松掉等等。还有各种软件故障，程序 Bug 什么的。即使没有 Bug，程序要升级，必须要关闭进程重新启动，这段时间应用也是不可用的；

此外，还有外部环境引发的不可用，比如促销引来大量用户访问，导致系统并发压力太大而崩溃，以及，黑客攻击、机房火灾、挖掘机挖断光缆，各种情况导致的应用不可用。

而互联网的高可用是说，在上面各种情况下，应用都要是可用的，用户都能够正常访问系统，完成业务处理。

衡量指标

业界通常用多少个 9 来说明互联网应用的可用性。

• 两个9：系统基本可用，年度不可用时间小于88小时
• 三个9：系统较高可用，年度不可用时间小于9个小时
• 四个9：具有自动恢复能力的高可用，年度不可用时间
• 五个9：极高的可用性，年度不可用时间小于5分钟

我们熟悉的互联网产品的可用性大多是 4 个 9。淘宝、百度、微信，差不多都是这样。

相对支付宝的可用性超过 99.99%，Twitter 的可用性只有 98%。

在互联网企业中，为了更好地管理系统的可用性，界定好系统故障以后的责任，通常会用故障分进行管理。

架构策略

• 提高应灾能力
  • 冗余备份：数据库主主复制
  • 负载均衡
  • 异地多活
• 保护策略
  • 失败隔离：限制影响范围。主要架构技术是消息队列
  • 限流降级