本篇文章主要源自本人自学左耳朵耗子的专栏中的相关分布式的文章归纳而来。
https://coolshell.cn/ 该专栏作者自己的博客，推荐一下
目录
什么是分布式架构
相对单机而言，分布式至少是多机部署，多机共同分担任务处理（源自一位网友）
为什么要使用分布式架构
分布式架构的优点
- 增大系统容量：垂直或是水平拆分业务系统，让其变成一个分布式的架构
- 加强系统可用：通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性
- 模块重用度高
- 软件服务模块被拆分，开发和发布速度可以并行而变得更快
- 系统扩展性更高
- 团队协作流程改善
分布式架构的缺点
- 架构设计变得复杂（尤其是其中的分布式事务）
- 部署单个服务会比较快，但是如果一次部署需要多个服务，流程会变得复杂
- 系统的吞吐量会变大，但是响应时间会变长
- 运维复杂度会因为服务变多而变得很复杂
- 架构复杂导致学习曲线变大
- 测试和查错的复杂度增大
- 技术多元化，这会带来维护和运维的复杂度
- 管理分布式系统中的服务和调度变得困难和复杂
单体应用和分布式架构的比较
分布式架构解决了什么问题
- 大流量处理：通过集群技术把大规模并发请求的负载分散到不同的机器上
- 关键业务保护：提高后台服务的可用性，把故障隔离起来阻止多米诺骨牌效应（雪崩效应）。如果流量过大，需要对业务降级，以保护关键业务流转
分布式系统的发展
- 20 世纪 90 年代前，是单体架构，软件模块高度耦合
- 2000 年左右出现了比较松耦合的 SOA 架构：一个标准的协议或是中间件来联动其它相关联的服务（如 ESB）；服务间并不直接依赖，而是通过中间件的标准协议或是通讯框架相互依赖
- 2010 年后，出现了微服务架构：松耦合；每一个微服务都能独立完整地运行（自包含）；数据库根据服务分库；
微服务的意义：微服务的出现使得开发速度更快，部署快，隔离性高，系统的扩展度好，但是在集成测试、运维和服务管理等方面比较麻烦。所以，需要一套比较好的微服务 PaaS 平台。就像 Spring Cloud 一样需要提供各种配置服务、服务发现、智能路由、控制总线……还有像 Kubernetes 提供的各式各样的部署和调度方式。
分布式系统需要注意的问题
异构系统的不标准问题
- 软件和应用不标准
- 通讯协议不标准
- 数据格式不标准
- 开发和运维的过程和方法不标准
系统架构中的服务依赖性问题
- 如果非关键业务被关键业务所依赖，会导致非关键业务变成一个关键业务
- 服务依赖链中，出现“木桶短板效应”——整个 SLA 由最差的那个服务所决定
解决思路：
- 定义出服务的关键程度
- 服务调用的主要路径
- 数据库方面也需要做相应的隔离，一个业务线用一套自己的数据库
故障发生的概率更大
- 故障恢复时间过长
- 故障影响面过大
解决思路：
- 监控关键指标
- 自动化的方式恢复故障，减少故障影响面
多层架构的运维复杂度更大
- 任何一层的问题都会导致整体的问题
- 没有统一的视图和管理，导致运维被割裂开来，造成更大的复杂度
- 按技能分工导致各管各的，分工后的协作是否统一和规范
分布式架构层级
- 基础层：机器、网络和存储设备等
- 平台层：中间件层，Tomcat、MySQL、Redis、Kafka 之类的软件
- 应用层：业务软件，比如，各种功能的服务
- 接入层：接入用户请求的网关、负载均衡或是 CDN、DNS等
配置管理
- 底层和操作系统相关：底层和中间层是不能让用户灵活修改的，而是只让用户选择
- 中间层和中间件相关
- 最上面和业务应用相关
分布式架构技术栈
提高架构的性能
- 缓存系统：对于分布式系统下的缓存系统，需要的是一个缓存集群。这其中需要一个 Proxy 来做缓存的分片和路由。
- 负载均衡系统：水平扩展的关键技术，它可以使用多台机器来共同分担一部分流量请求
- 异步调用：主要通过消息队列来对请求做排队处理，把前端的请求的峰值给“削平”，后端通过能够处理的速度来处理请求。这样可以增加系统的吞吐量，但是实时性较差。同时，还会引入消息丢失的问题，所以要对消息做持久化，这会造成“有状态”的结点，从而增加了服务调度的难度
- 数据分区和数据镜像：数据分区是把数据按一定的方式分成多个区（比如通过地理位置），不同的数据区来分担不同区的流量。需要一个数据路由的中间件，会导致跨库的 Join 和跨库的事务非常复杂。数据镜像是把一个数据库镜像成多份一样的数据，不需要数据路由的中间件。可以在任意结点上进行读写，内部会自行同步数据。数据镜像中最大的问题就是数据的一致性问题
提高架构的稳定性
- 服务拆分：一是为了隔离故障，二是为了重用服务模块。但服务拆分完之后，会引入服务调用间的依赖问题。
- 服务冗余：为了去除单点故障，并可以支持服务的弹性伸缩，以及故障迁移。弹性伸缩时，需要考虑数据的复制或是重新分片，迁移的时候还要迁移数据到其它机器上
- 限流降级：当系统实在扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分服务，或是拒绝一部分用户，以确保整个架构不会挂掉
- 高可用架构：通常来说高可用架构是从冗余架构的角度来保障可用性。比如，多租户隔离，灾备多活，或是数据可以在其中复制保持一致性的集群。总之，就是为了不出单点故障
- 高可用运维：高可用运维指的是 DevOps 中的 CI/CD（持续集成 / 持续部署）。一个良好的运维应该是一条很流畅的软件发布管线，其中做了足够的自动化测试，还可以做相应的灰度发布，以及对线上系统的自动化控制。这样，可以做到“计划内”或是“非计划内”的宕机事件的时长最短。
最低0.47元/天 解锁文章
扫一扫
1127
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
