分布式系统

什么是分布式

分布式或者说SOA分布式重要的就是面向服务，说简单点分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等，拆分之后的每个服务可以部署在不同的机器上，如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。

为什么要分布式

从开发角度来讲单体应用的代码都集中在一起，而分布式系统的代码根据业务被拆分。所以，每个团队可以负责一个服务的开发，这样提升了开发效率。另外，代码根据业务拆分之后更加便于维护和扩展。

将系统拆分成分布式之后不光便于系统扩展和维护，更能提高整个系统的性能。

分布式

相关理论

CAP理论和BASE理论

CAP：Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 。

BASE：Basically Available（基本可用）、Soft-state（软状态）、Eventually Consistent（最终一致性）。
BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。

Paxos算法和Raft算法

API网关

API网关的作用：

1. 动态路由：将请求路由到对应的服务上去，如果服务不可用还会有重试机制；
2. 负载均衡：多服务器提供同一种服务，需要从注册中心拉取各服务注册信息，然后将请求均衡处理；
3. 流量控制：限制流量，避免内部系统受到冲击；
4. 统一鉴权：对相关权限做验证（请求者的访问权限，还可实现单点登录）；
5. 熔断降级：当服务不可用或者访问量过大，可以将请求做降级，如转到其他服务器或者做其他处理，提示用户暂时不可用；
6. 灰度发布：只给少量服务器升级，将少量的服务转到已升级的服务器用来测试升级的服务器，大量请求还是转在老版本的服务器；
7. 日志服务：服务访问情况报表，请求吞吐量，并发数，日常告警等。

分布式协调

配置中心：一种统一管理各种应用配置的基础服务组件。
注册中心：管理各种服务功能包括服务的注册、发现、熔断、负载、降级等。

服务调用

RPC（Remote Procedure Call）——远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

分布式ID

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。比如数据量太大之后，往往需要对数据进行分库分表，分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求。

分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

高性能

消息队列

消息队列在分布式系统中主要是为了解耦和削峰。

读写分离和分库分表

读写分离主要是为了将数据库的读和写操作分不到不同的数据库节点上。主服务器负责写，从服务器负责读。一主一从或者一主多从都可以。
读写分离可以大幅提高读性能，小幅提高写的性能。因此，读写分离更适合单机并发读请求比较多的场景。

分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。

负载均衡

负载均衡系统通常用于将任务比如用户请求处理分配到多个服务器处理以提高网站、应用或者数据库的性能和可靠性。

常见的负载均衡系统包括3种：

1. DNS负载均衡 ：一般用来实现地理级别的均衡。
2. 硬件负载均衡 ： 通过单独的硬件设备比如F5来实现负载均衡功能（硬件的价格一般很贵）。
3. 软件负载均衡 ：通过负载均衡软件比如Nginx来实现负载均衡功能。

高可用

限流

限流是从用户访问压力的角度来考虑如何应对系统故障。

限流是对服务端的接口接受请求的频率进行限制，防止服务挂掉。比如某一接口的请求限制为100个每秒, 对超过限制的请求放弃处理或者放到队列中等待处理。限流可以有效应对突发请求过多。

排队

另类的限流，类比于现实世界的排队。

降级

降级是从系统功能优先级的角度考虑如何应对系统故障。

服务降级指的是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

熔断

熔断和降级是两个比较容易混淆的概念，两者的含义并不相同。

降级的目的在于应对系统自身的故障，而熔断的目的在于应对当前系统依赖的外部系统或者第三方系统的故障。

集群

相同的服务部署多份，避免单点故障。

超时和重试机制

一旦用户的请求超过某个时间得不到响应就结束此次请求并抛出异常。 如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法再处理请求。

重试的次数一般设为3次，再多的重试次数没有好处，反而会加重服务器压力（部分场景使用失败重试机制会不太适合）。在一次重试失败之后通常会加上一个时间间隔再进行下一次重试，时间间隔通常建议是随机的。

并且，为了更好地保护下游，我们还可以结合断路器。

灾备设计和异地多活

灾备 = 容灾+备份。

• 备份 ： 将系统所产生的的所有重要数据多备份几份。
• 容灾 ： 在异地建立两个完全相同的系统。当某个地方的系统突然挂掉，整个应用系统可以切换到另一个，这样系统就可以正常提供服务了。

异地多活：是将服务部署在异地并且服务同时对外提供服务。和传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。异地多活是为了应对突发状况比如火灾、地震等自然或者人为灾害。

相关技术栈