【架构】常见技术点--架构设计
导读：收集常见架构技术点，作为项目经理了解这些知识点以及解决具体场景是很有必要的。技术要服务业务，技术跟业务具体结合才能发挥技术的价值。
1、高并发 (High Concurrency)
由于分布式系统的问世，高并发（High Concurrency）通常是指通过设计保证系统能够同时并行处理很多请求。通俗来讲，高并发是指在同一个时间点，有很多用户同时的访问同一 API 接口或者 Url 地址。
高并发问题的本质就是：资源的有限性，比如：带宽、CPU、内存、IO等。
它经常会发生在有大活跃用户量，用户高聚集的业务场景中。高并发设计同样要秉承架构设计的3个原则：简单、合适和演进。“过早的优化是万恶之源”，不能脱离业务的实际情况，更不要过度设计，合适的方案就是最完美的。
2、高可用 (High Availability)
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，一个系统经过专门的设计，以减少停工时间，而保持其服务的高度可用性。
高可用的实践方案：
- 对等节点的故障转移，Nginx和服务治理框架均支持一个节点失败后访问另一个节点。
- 非对等节点的故障转移，通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。
- 接口层面的超时设置、重试策略和幂等设计。
- 降级处理：保证核心服务，牺牲非核心服务，必要时进行熔断；或者核心链路出问题时，有备选链路。
- 限流处理：对超过系统处理能力的请求直接拒绝或者返回错误码。
- MQ场景的消息可靠性保证，包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。
- 灰度发布，能支持按机器维度进行小流量部署，观察系统日志和业务指标，等运行平稳后再推全量。
- 监控报警：全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。
- 灾备演练：类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。
整个互联网分层系统架构的高可用，又是通过每一层的冗余+自动故障转移来综合实现的，具体的：
- （1）【客户端层】到【反向代理层】的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived + virtual IP自动故障转移
- （2）【反向代理层】到【站点层】的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移
- （3）【站点层】到【服务层】的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移
- （4）【服务层】到【缓存层】的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性
- （5）【服务层】到【数据库“读”】的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移
- （6）【服务层】到【数据库“写”】的高可用，是通过写库的冗余实现的，常见实践是keepalived + virtual IP自动故障转移
3、读写分离
为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改业务的生产服务器；第二台数据库服务器，主要进行读的操作。
通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力，即可以解决可用性的问题，又解决了数据库性能问题。
4、冷备/热备
冷备：两个服务器，一台运行，一台不运行做为备份。这样一旦运行的服务器宕机，就把备份的服务器运行起来。冷备的方案比较容易实现，但冷备的缺点是主机出现故障时备机不会自动接管，需要主动切换服务。
热备：即是通常所说的active/standby方式，服务器数据包括数据库数据同时往两台或多台服务器写。当active服务器出现故障的时候，通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。当一台服务器宕机后，自动切换到另一台备用机使用。
5、异地多活
异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。
6、负载均衡 (Load Balance)
负载均衡，是对多台服务器进行流量分发的负载均衡服务。可在多个实例间自动分配应用程序的对外服务能力，通过消除单点故障提升应用系统的可用性，让您实现更高水平的应用程序容错能力，从而无缝提供分配应用程序流量所需的负载均衡容量，为您提供高效、稳定、安全的服务。
负载均衡运行时，一般通过一个或多个前端负载均衡器将客户访问请求分发到后端一组服务器上，从而达到整个系统的高性能和高可用性。
实现几种方式：
（1）HTTP重定向负载均衡。
这种负载均衡方案的优点是比较简单，缺点是浏览器需要每次请求两次服务器才能拿完成一次访问，性能较差。
（2）DNS域名解析负载均衡。
DNS域名解析负载均衡的优点是将负载均衡工作交给DNS，省略掉了网络管理的麻烦，缺点就是DNS可能缓存A记录，不受网站控制。
（3）反向代理负载均衡。
优点是部署简单，缺点是反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。
（4）IP负载均衡。
优点：IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。缺点：负载均衡的网卡带宽成为系统的瓶颈。
（5）数据链路层负载均衡。
避免负载均衡服务器网卡带宽成为瓶颈，是目前大型网站所使用的最广的一种负载均衡手段。
7、动静分离
动静分离是指在web服务器架构中，将静态页面与动态页面或者静态内容接口和动态内容接口分开不同系统访问的架构设计方法，进而提升整个服务访问性能和可维护性。另外，搜索公众号后端架构师后台回复“架构整洁”，获取一份惊喜礼包。
8、集群
单台服务器的并发承载能力总是有限的，当单台服务器处理能力达到性能瓶颈的时，将多台服务器组合起来提供服务，这种组合方式称之为集群，集群中每台服务器就叫做这个集群的一个“节点”，每个节点都能提供相同的服务，从而成倍的提升整个系统的并发处理能力。
9、分布式
分布式系统就是将一个完整的系统按照业务功能拆分成很多独立的子系统，每个子系统就被称为“服务”，分布式系统将请求分拣和分发到不同的子系统，让不同的服务来处理不同的请求。在分布式系统中，子系统独立运行，它们之间通过网络通信连接起来实现数据互通和组合服务。
分布式系统优点：
- 1. 分布式系统中的所有节点都是相互连接的。所以节点可以很容易地与其他节点共享数据。
- 2. 更多的节点可以很容易地添加到分布式系统中，即可以根据需要进行扩展。
- 3. 一个节点的故障不会导致整个分布式系统的失败。其他节点仍然可以相互通信。
- 4. 硬件资源可以与多个节点共享，而不是只限于一个节点。
分布式缺点：
- 1. 在分布式系统中很难提供足够的安全，因为节点以及连接都需要安全。
- 2. 一些消息和数据在从一个节点转移到另一个节点时，可能会在网络中丢失。
- 3. 与单用户系统相比，连接到分布式系统的数据库是相当复杂和难以处理的。
- 4. 如果分布式系统的所有节点都试图同时发送数据，网络中可能会出现过载现象。
10、 弹性扩容
指对部署的集群进行动态在线扩容。弹性扩容系统可以根据实际业务环境按照一定策略自动地添加更多的节点（包括存储节点、计算节点、网络节点）来增加系统容量、提高系统性能或者增强系统可靠性，或者同时完成这三个目标。
11、水平扩展/垂直扩展
水平扩展 Scale Out通过增加更多的服务器或者程序实例来分散负载，从而提升存储能力和计算能力。垂直扩展 Scale Up 提升单机处理能力。
垂直扩展的方式又有两种：
-
（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G;
-
（2）提升单机软件或者架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；
11、平行扩容
与水平扩展类似。集群服务器中的节点均为平行对等节点，当需要扩容时，可以通过添加更多节点以提高集群的服务能力。一般来说服务器中关键路径（如服务器中的登录、支付、核心业务逻辑等）都需要支持运行时动态平行扩容。
12、CAP理论
CAP理论，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。
-
一致性：它要求在同一时刻点，分布式系统中的所有数据备份都相同或者都处于同一状态。
-
可用性：在系统集群的一部分节点宕机后，系统依然能够正确的响应用户的请求。
-
分区容错性：系统能够容忍节点之间的网络通信的故障。
简单的来说，在一个分布式系统中，最多能支持上面的两种属性。但显然既然是分布式注定我们是必然要进行分区，既然分区，我们就无法百分百避免分区的错误。因此，我们只能在一致性和可用性去作出选择。
在分布式系统中，我们往往追求的是可用性，它的重要性比一致性要高，那么如何实现高可用，这里又有一个理论，就是 BASE 理论，它给 CAP 理论做了进一步的扩充。
12、BASE理论
BASE 理论指出：
-
Basically Available（基本可用）
-
Soft state（软状态）
-
Eventually consistent（最终一致性）
BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。