01-概念
AKF扩展立方体
基本概念
一种系统化的可扩展性方法论，旨在通过三个正交维度（X、Y、Z轴）解决性能瓶颈问题。该理论由《The Art of Scalability》提出，广泛应用于分布式系统设计，帮助架构师以最低成本实现高效扩展
简单来说就是通过加机器就可以解决容量和可用性问题
X轴 —— 通过复制无状态服务或数据副本来分担负载，提升吞吐量和可用性
Y轴 —— 按业务功能或数据模型拆分系统，形成独立服务或子系统。
Z轴 —— 基于用户、地理位置或数据键值分片，将数据分散到不同节点。
三个维度扩展的对比
- 1.X轴扩展
优点：成本最低，实施简单；
缺点：受指令集多少和数据集大小的约束。当单个产品或应用过大时，服务响应变慢，无法通过X轴的水平扩展提高速度；
场景：发展初期，业务复杂度低，需要增加系统容量。 - 2.Y轴扩展
优点：可以解决代码量和数据集的约束，解决代码复杂度问题，可以实现隔离故障，可以提高响应时间，可以使团队聚焦更利于团队成长；
缺点：成本相对较高；
场景：业务复杂，数据量大，代码耦合度高，团队规模大。 - 3.Z轴扩展
优点：能解决数据集的约束，降低故障风险，实现渐进交付，可以带来最大的扩展性。
缺点：成本最昂贵，且不一定能解决指令集的问题；
场景：用户指数级快速增长。
几种场景的扩展
- 1.为扩展分割应用
X轴：从单体系统或服务，水平克隆出许多系统，通过负载均衡平均分配请求；
Y轴 ：面向服务分割，基于功能或者服务分割，例如电商网站可以将登陆、搜索、下单等服务进行Y轴的拆分，每一组服务再进行X轴的扩展；
Z轴 ：面向查找分割，基于用户、请求或者数据分割，例如可以将不同产品的SKU分到不同的搜索服务，可以将用户哈希到不同的服务等。 - 2.为扩展分割数据库
X轴：从单库，水平克隆为多个库上读，一个库写，通过数据库的自我复制实现，要允许一定的读写时延；
Y轴 ：根据不同的信息类型，分割为不同的数据库，即分库，例如产品库，用户库等；
Z轴 ：按照一定算法，进行分片，例如将搜索按照MapReduce的原理进行分片，把SKU的数据按照不同的哈希值进行分片存储，每个分片再进行X轴冗余。 - 3.为扩展而缓存
在理想情况下，处理大流量最好的方法是通过高速缓存来避免处理它。从架构层面看，我们能控制的主要有以下三个层次的缓存：
对象缓存：对象缓存用来存储应用的对象以供重复使用，一般在系统内部，通过使用应用缓存可以帮助数据库和应用层卸载负载。
应用缓存：应用缓存包括代理缓存和反向代理缓存，一个在用户端，一个在服务端，目标是提高性能或减少资源的使用量。
内容交付网络缓存：CDN的总原则是将内容推送到尽可能接近用户终端的地方，通过不同地区使用不同ISP的网关缓存，达到更快的响应时间和对源服务的更少请求。 - 4.位扩展而异步
同步改异步：同步调用，由于调用间的同步依赖关系，有可能会导致雪崩效应，出现一系列的连锁故障，进而导致整个系统出现问题，所以在进行系统设计时，要尽可能的考虑异步调用方式，邮件系统就是一个非常好的异步调用例子。
应用无状态：当进行AKF扩展立方体的任何一个轴上的扩展时，都要首先解决应用的状态问题，即会话的管理，可以通过避免、集中和分散的方式进行解决。
SOA
- （Service-Oriented Architecture，面向服务的架构） 是一种通过将系统功能拆分为独立、可重用的服务单元，并通过标准化接口进行通信的设计方法。它强调服务的模块化、解耦和灵活性，旨在支持跨系统、跨组织的业务整合和协作
- 核心思想
- 服务化：将业务功能封装为独立服务，每个服务具有明确的接口和功能边界。例如，订单处理、用户认证等业务可分别封装为独立服务。
- 松耦合：服务间通过标准化协议（如HTTP、SOAP、REST）交互，不依赖具体实现技术（编程语言、硬件平台等），降低系统间的依赖性。
- 可重用性：服务可被多个应用或模块调用，避免重复开发。例如，支付服务可同时被电商平台和财务系统使用。
- 开放性：基于开放标准（如XML、JSON），支持异构系统的互联互通。
- 关键组件
- 服务（Service）
- 自包含的业务功能单元，例如用户注册服务、库存查询服务。
- 通过接口定义（如WSDL、OpenAPI）明确输入输出参数和功能。
- 服务注册与发现中心（Service Registry）
- 用于服务的发布和查找。服务提供者将服务元数据注册到中心（如Consul、ZooKeeper），消费者通过中心发现所需服务。
- 企业服务总线（ESB）或API网关
- ESB：传统SOA中用于服务通信的中介，支持协议转换、路由、消息队列等功能（如IBM Integration Bus）8。
- API网关：现代分布式SOA中更常用的组件，统一管理服务入口，处理鉴权、限流、监控等非业务功能（如Kong、Spring Cloud Gateway）。
- 服务治理
- 包括服务版本控制、负载均衡、容错（如熔断机制）、监控（如Prometheus）和日志管理，确保服务的高可用性和可维护性。
- 服务（Service）
分布式一致性
- 强一致性 ：系统写入了什么，读出来的就是什么。
- 弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
- 最终一致性 ：弱一致性的升级版。，系统会保证在一定时间内达到数据一致的状态，
CAP
- CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。
Consistency(一致性)
- 一致性指的是多个数据副本是否能保持一致的特性，在一致性的条件下，系统在执行数据更新操作之后能够从一致性状态转移到另一个一致性状态。
- 对系统的一个数据更新成功之后，如果所有用户都能够读取到最新的值，该系统就被认为具有强一致性。
Availability(可用性)
- 可用性指分布式系统在面对各种异常时可以提供正常服务的能力，可以用系统可用时间占总时间的比值来衡量，4 个 9 的可用性表示系统 99.99% 的时间是可用的。
- 在可用性条件下，要求系统提供的服务一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
Partition tolerance（容错性）
- 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
- 一般来说，分区容错是必须做到的，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。
BASE理论
- BASE 是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。
- BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
基本可用
- 指分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。
- 例如
- (响应时间上的损失)电商在做促销时，为了保证购物系统的稳定性，部分消费者可能会被引导到一个降级的页面。
- (系统功能上的损失)电商在做促销时，为了保证购物系统的稳定性，历史订单查询功能将不可用
软状态
- 指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在时延。
最终一致性
- 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能达到一致的状态。
- ACID 要求强一致性，通常运用在传统的数据库系统上。而 BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。
- 在实际的分布式场景中，不同业务单元和组件对一致性的要求是不同的，因此 ACID 和 BASE 往往会结合在一起使用
gossip协议
Gossip 协议是一种允许在分布式系统中共享状态的去中心化通信协议，通过这种通信协议，我们可以将信息传播给网络或集群中的所有成员。
传播示意图
消息传播模式
- 反熵（Anti-Entropy）
- 同步节点的全部数据，以消除各节点之间的差异，目标是整个网络各节点完全的一致
- 传谣
- 仅仅发送新到达节点的数据，即只对外发送变更信息
- 反熵（Anti-Entropy）
优点
- 对节点间的网络连通性和稳定度要求不高
- 能够容忍网络上的节点随意的增加和减少
- 每个节点都是平等的，没有主子节点的概念
缺点
- 会存在系统中节点不一致的情况
- 每次随机选择节点，不能很好的预测系统达到完全一致需要多长时间
- 由于随机选择节点，消息可能重复发送，增加了网络压力和节点处理信息的能力
靠gossip检测故障的过程
- 每个节点维护一个节点成员列表，其中包含成员ID和心跳计数器
- 每个节点定期增加它自己心跳计数器
- 每个节点定期向一组随机节点发送心跳，然后再传播到另一组节点上
- 一旦节点收到心跳，成员名单就会更新到最新信息。
- 如果心跳没有增加超过预定的时间，该成员被认为是离线的。
01-概念
https://x-leonidas.github.io/2022/02/01/12分布式系统/01-概念/