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

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

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

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

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

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

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

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

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

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

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

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

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

数据库读写分离

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

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

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

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

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

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

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

性能优化5个过程

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

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

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

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

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

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

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

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