大家好！我是新人唱跳 rap 打篮球，是一个立志 2025 年开始每周都能水一篇文章的人
上次水文是两周前了，不是不想分享，只是上周又面对了亲人的离世
3 月 23 日晚上，我还在学习 AI 相关的视频，姑姑突然问我联系得到表弟不，他们好几天联系不上表弟了
我 19 号的白天还和他聊了一下，后面发消息他没有回我，不知如此竟然成了永别
表弟是自己走的，这些天来我常常责怪自己没有照顾好表弟，可惜说什么都太晚了
我第二天从深圳赶回贵州，下午到修文，看到的只是弟弟静静地躺在那里，就像什么事都没有发生
只是他走了，上个月他还在身边和我一起送奶奶走，可今天我却成了送他走的人
他到底是多痛苦难过，才走得对我们一点留恋都没有，
奶奶走时，我没有太多的话，可弟弟离去，我却有说不完的话给他说，可惜他走了
死亡不是真正的逝去，遗忘才是
希望大家爱的人都能好好的，平平安安，珍惜当下
经历奶奶、弟弟的离去，突然觉得一切也不是那么重要了，慢下节奏好好生活，做自己爱做的事，照顾好自己就已经很了不起了
回到正题啊，社区不让发与社区无关的东西，所以就写些最近看的东西吧
1 分布式系统
分布式系统作为单体系统的颠覆者出现，给业界带来了震撼和惊喜，但也带来一个由新问题及其解决方案构成的复杂技术生态
我是怎么理解分布式的，字面上理解可能就是到处都是系统，分布在不同的地方
就像一个个的组件，在不同的位置，但他们通过网络连接在一下，形成一个完整的系统
下面我就按我查到的资料和看到的书上的内容给大家胡诌一下
1.1 分布式系统的发展
从 20 世纪 70 年的模块化编程，到 80 年代的面向事件设计，再到 90 年代的基于接口/组件设计，软件世界很自然地演化出了 SOA（面向服务的架构）
SOA 是构造分布式计算应用程序的方法，它将应用程序的功能作为服务发送给最终用户或其他服务，采用开放标准与软件资源进行交互，并采用了标准的表示方式。
开发、维护和使用 SOA 应遵循以下基本原则。
- 可重用、粒度合适、模块化、可组合、构件化及有互操作性。
- 可重用：可以重复使用，使用后不会对其有啥不可逆的影响，至少整体软件生命周期内可以重复使用
- 粒度合适：模块划分的大小合适，不大不小刚刚好，揣进兜里就能跑
- 模块化、可组合、构件化：可以合体啊，变成一个整体的一小部分，是一个模块
- 互操作性：可以互相通信、操作调用彼此模块
- 符合通用或行业标准
- 大家都在用的协议、技术栈，大家好才是真的好
- 能明确区分服务的识别和分类、提供和发布、监控和跟踪。
- 服务发现、服务分类、发布和监控、traceing
看完 kubernets 会说，正是在下！
由于 IBM 开发的 SOA 非常沉重，业界对 SOA 的裁剪和优化从未停止。
比如原来使用的 SOAP、WSDL 和 XML 等技术基本都被抛弃了，RESTful 和 JSON 等方式称为了主流。
而 ESB（企业服务总线）也被简化成发布/订阅的消息服务（消息队列）。
但 SOA 的思想一直延续至今。
SOA 经历了三个比较大的发展阶段
- 20 世纪 90 年代之前，单体架构是主流，软件模块之间处于高度耦合的状态。
- 2000 年左右出现了松耦合的 SOA，它需要一个标准的协议或中间件来联系相关的服务（如 ESB）
- 2010 年前后，耦合程度更低的微服务架构出现了。每个微服务都能独立完整地运行，后端的单体数据库在微服务架构中也被分散部署到不同的服务中。编排的概念开始出现了
一般的编排和组织微服务的引擎可以是工作流引擎，也可以是网关。
需要容器化调度这样的技术辅助，K8s 的出现，以及后续的云原生，使得微服务开发更快、部署更快、隔离度更好，系统的扩展性也更好。
但也让集成测试、运维和服务管理变得比较麻烦。
因此，一个好的微服务 PaaS 平台，就像 Spring Cloud 一样，需要提供服务配置、服务发现、智能路由、控制总线等功能，以及各种部署和调度方式。
没有 PaaS 层的支持，微服务也很难被管理和运维。
基本每家大公司都会做自己的微服务 PaaS 平台，来提升自己的研发效率和流程规范
1.2 分布式系统的特点
使用分布式系统主要有两个原因：
一个是为了增大系统容量，一个是加强系统可用性。
- 随着业务量增大，一台机器的性能已经无法满足需求，需要多台机器来应对大规模的应用场景。
为此，我们需要对业务系统进行垂直拆分或水平拆分，使其变成一个分布式架构。
- 业务越来越关键，对整个系统架构的可用性提出了更高要求，比如系统架构中不能存在单点故障。
分布式架构通过冗余系统来消除单点故障，从而提高了系统的可用性，防止一台机器出故障导致整个系统不可用等情况。
分布式系统的模块化程度高，模块的可重用性更高，系统的扩展性更强。
由于软件服务被拆分，团队协作也会得到改善，开发和发布可以并行操作，研发速度也变快了
但分布式也带来了一些问题，这里列一下分布式架构的优缺点
- 分布式架构设计较为复杂（尤其是分布式事务的架构设计）
- 部署单个服务速度较快，但如果需要同时部署多个服务，则流程会变得复杂
- 系统吞吐量增大，但响应时间会变长
- 运维复杂度因服务数量增加而显著增加
- 架构的复杂性加大了其学习难度
- 测试和排错的过程变得更加复杂
- 技术多元化导致运维的复杂度相应增加
- 管理分布式系统重的服务和调度变得困难和复杂
分布式架构解决了 “单点故障” 和 “性能容量” 的问题，同时在系统的设计、管理和运维方面制造了诸多困难和问题。
1.3 核心使命与关键技术
构建分布式系统旨在增肌系统容量、提高系统可用性。
在技术上，首先要处理大流量，通过集群技术将大规模并发请求的负载分散到不同的机器上；
其次要保护关键业务，提高后台服务的可用性，通过故障隔离防止多米诺骨牌效应（雪崩效应）的发生
如果流量过大，某些业务需要降级，以保护关键业务的正常流转
简单来说，分布式系统用于提高整体架构的吞吐量，为更多的并发任务和流量提供服务，也用于提高系统的稳定性。
下面聊聊有那些技术
-
提高系统性能
- 缓存系统：缓存分区、缓存更新、缓存命中；分布式系统需要一个缓存集群，还需要一个代理来实现缓存的分片和路由功能。
- 负载均衡系统：负载均衡、服务路由、服务发现；可以使用多台机器来共同分担流量请求
- 异步调用：消息队列、消息持久、异步事务；消息队列排队，可以让后端以常规速度处理请求；如何处理消息丢失，又是持久化和状态处理的问题了
- 数据镜像：数据同步、读写分离、数据一致性
- 数据分区：分区策略、数据访问层、数据一致性
-
提高系统稳定性
- 服务拆分：服务治理、服务调用、服务依赖、服务隔离
- 服务冗余：服务调度、弹性伸缩、故障迁移、服务发现
- 限流降级：限流降级、异步队列、降级控制、服务熔断
- 高可用架构：高可用架构、多租户系统、灾备多活、高可用服务
- 高可用运维：运维系统、全栈监控、DevOps、自动化运维
这些技术非常艰深，需要个人投入大量的时间和精力才能掌握。
分布式系统引入了一系列技术问题，解决这些问题需要从一下几个方面入手
- 服务治理
- 软件架构管理
- DevOps
- 资源调度管理
- 系统架构监控
- 流量控制
由诸多技术组成的分布式系统技术栈，不仅需要大量资金、人力和时间，从配套能力角度来看，这也是一个很难跨越的技术门槛。
不过，有赖于 Docker 及其衍生的 K8s 之类的软件或解决方案，分布式系统的难度已大幅降低。
Docker 把软件和运行的环境打成一个包，从而使软件服务可以轻量级地启动和运行。
在运行过程中，软件服务可能会改变现有的环境，但是只要重新启动一个 Docker，环境又会恢复初始状态。
因此，可以利用 Docker 的这个特性，在不同的机器上部署、调度和管理软件。有了容器虚拟化技术，分布式系统的普及已不可逆转。
分布式系统的技术栈离不开很多基础理论，CAP 定理和分布式计算谬误尤其重要
1.4 CAP 定理
CAP 定理是分布式系统设计中最基础也最关键的理论。它的核心思想是，分布式数据存储不可能同时满足以下三个条件。
- 一致性（Consistency）：所有节点子啊同一时间看到的数据完全一致（强一致性） 每个服务节点的每次读取，要么获得最新写入的数据，要么获得一个错误。
- 可用性（Availability）：每个请求都能在合理时间内获得非错误响应（非超时或失败） 每个服务节点的每次请求都能获得一个（非错误）响应，但是不保证返回的是最新写入的数据。
- 分区容错性（Partition tolerance）：系统在网络分区（节点间通信中断）时仍然继续运行。 尽管不定量的消息在节点间的网络传输中丢失（或延迟），系统仍然可以继续运行。
掌握 CAP 定理，尤其是正确理解 C、A、P 的含义，对分布式系统的架构设计非常重要。
因为网络故障在所难免，在出现网络故障的时候，系统按照正常的行为逻辑维持运行尤为重要，这需要结合实际的业务场景和具体需求来权衡。
对于大多数互联网应用，由于机器数量庞大、部署节点分散、网络出故障时常态
但可用性是必须要保证的，所以只有通过舍弃数据一致性来保证服务的 A 和 P。
而对于银行等需要确保一致性的场景，通常会权衡 CA 和 CP 模型。
当网络出现故障时，CA 模型完全不可用，CP 模型具备部分可用性。
- CA 系统关注一致性和可用性。
- 它需要一个非常严格的全局一致协议，例如 “两阶段提交”（2PC）。CA 系统无法容忍网络错误或节点错误。一旦出现问题，整个系统将拒绝写入请求。
- 因为它不知道是其他节点崩溃，还是仅仅网络出现问题，唯一安全的方法时限定只读模式
- CP 系统关注一致性和分区容错性。
- 它关注系统中大多数服务节点的一致性协议，例如 Paxos 算法。
- CP 系统只需确保大多数节点数据一致，而少数节点在数据被同步到最新版本之前可能会变为不可用状态，这时系统仅提供部分可用性。
- AP 系统关注可用性和分区容错性。
- 它无法实现数据一致性，且需要处理数据冲突和维护数据版本，AWS 的 Dynamo 就是这样的系统。
1.5 分布式计算谬误
分布式计算谬误由 Sun 公司的多伊奇等人提出，是刚进入分布式
计算领域的程序员常会提出的一系列错误假设。
- 网络是稳定的
- 网络传输延迟为零
- 网络的带宽无穷大
- 网络是安全的
- 网络的拓扑不会改变
- 只有一个系统管理员
- 传输数据的成本为零
- 整个网络是同构的
这些错误假设至今仍然有着很大的影响。
分布式计算谬误不仅对于中间件、底层系统开发者及架构师很重要，对于网络应用程序的开发者也同样重要。
它让我们清楚地认识到在分布式系统中，错误是不可避免的，我们需要把错误处理作为功能写入代码中。
以上就是个人学习分布式架构相关的学习笔记，由于个人能力不够，也只能简单列一下提纲
R.I.P
R.I.P
我是新人唱跳 rap 打篮球，是一个立志 2025 年开始每周都能水一篇文章的人，希望我的文章可以给你带来好心情！