分布式基础理论

分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。分布式系统（distributed system）是建立在网络之上的软件系统。

首先需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、使用更好的CPU）高昂到得不偿失的时候，应用程序也不能进一步优化的时候，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。。。

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，急需一个治理系统确保架构有条不紊的演进。

应用架构的发展演变

• 垂直应用也是把后端代码和前端代码放在一起的

• 公用模块无法重复利用，开发性的浪费

  • 例如，订单模块有时候会用到用户模块的代码，就需要在订单模块写用户相关的代码，就是说应用之间也是会交互的
  • 应用不可能完全独立，大量的应用之间需要交互
    

• 分布式把前端和后端就分开了

  • 好处是，业务逻辑不变的情况下，如果我们只想改界面，那我们只需要重启界面的服务器就好了

• 问题

用户的web可能在A服务器，业务逻辑可能在B服务器上，订单在C服务器上，此时如果A服务器要调用B服务器的功能，这种跨服务器的调用分为RPC（远程过程调用）

分布式服务架构下最核心的难点就是如何进行远程过程调用，以及如何拆分业务提升业务的复用程度，此时分布式服务框架就能极大的简化我们的开发。


随着我们业务不断的增多，我们拆分的服务也越来越多，有成千上万的服务器在跑各种不同的服务，而出现的资源浪费的情况就尤为严重。

比如我们的用户业务，访问量比较小，结果它有100台服务器在跑，而我们的商品业务却只有10台服务器在跑，那么就应该有一个基于访问压力的调度中心帮我们监控这些数据并动态的调度，提高资源的利用率。

用户业务的服务器多了，就减几台，让这些服务器跑其他业务量更大的业务。这时候我们就可以采用流动计算架构。

我们引入调度中心，它负责维护我们这些服务之间的复杂关系以及实时管理整个集群。

比如A服务器访问量大了，我们给A动态的多来几台，假设A的集群第一台服务器有100个请求，第二个有2个请求，那么下次请求进来就应该找比较闲的服务器来处理请求，以此来提高我们整个服务的利用率。

RPC

• 与之相对应的是http

• RPC两个核心模块，通讯和序列化。

• 影响一个RPC框架的性能有两点

  • 看这个RPC框架能否快速的在各个服务器之间建立连接
  • 看这个RPC框架序列化和反序列机制速度快不快

RPC框架在市面上也有很多，它们虽然用法不同，但是思想都是一样的，都是通过网络通信来实现远程过程调用

• 阿里的dubbo、hsf
• 谷歌的gRPC
• facebook的Thrift
  
  

dubbo

dubbo发展历程

• 11年阿里将duboo托管到了github上，并持续更新
• 14年10月阿里发布了dubbo 2.4.1版本，至此以后停更
• 当当网维护了dubbo的一个分支dubbox，网易考拉维护的dubbok
• 17年Spring Cloud在抢占分布式市场，大红大紫，阿里就连续更新了几个版本
• 18年1月阿里将dubbo与dubbox合并，更新到了dubbo的2.6版本，一直到18年的2月15日阿里将dubbo开源贡献给了Apache

dubbo与它的核心能力

Apache Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力

• 面向接口的远程方法调用

提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。

• 智能容错和负载均衡

内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量

• 服务自动注册和发现

支持多种注册中心服务，服务实例上下线实时感知。

• 高度可扩展能力

遵循微内核 + 插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现

• 运行期流量调度

内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。

• 可视化的服务治理与运维

提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

dubbo设计架构

• 服务提供者（Provider)
  暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。

• 服务消费者（Consumer)：调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

• 注册中心（Registry)：注册心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者

• 监控中心（Monitor)：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中

• Dubbo框架容器（Container）

dubbo运行流程

1. dubbo框架启动就会启动Container（这儿就可以直接理解为dubbo框架启动了），服务提供者就会将该服务信息注册到注册中心，注册中心就知道有哪些服务上线了

2. 服务消费者启动的时候就会从注册中心订阅自己所需要的服务，如果某个服务提供者有变更，注册中心基于长连接的方式将这次服务变更推送给服务消费者，消费者就实时的知道这个服务器不能调用了

3. 消费者获取到所有它能调用的服务提供者，可以同步来调用服务提供者，如果有多个服务提供者，消费者可以通过负载均衡算法选择一个服务提供者来进行调用

4. 服务消费者和服务提供者每一次调用的信息，定时每分钟发送一次统计数据到监控中

注册中心 zookeeper

Zookeeper是Apache Hadoop的子项目，是一个树形的目录服务，支持变更推送，适合作为Dubbo服务的注册中心，工业强度较高，可用于生产环境并推荐使用

Zookeeper 注册中心实现支持以下高可用能力：

• 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息

• 当注册中心重启时，能自动恢复注册数据，以及订阅请求

• 当会话过期时，能自动恢复注册数据，以及订阅请求

• 当设置 registry.check=false 时，记录失败注册和订阅请求，后台定时重试

todo 由于时间原因，所有的代码，下载之类，都全部是从老师的文档中直接拷贝的，并没有经过自己的实际验证

• zookeeper是需要下载来进行启动的，老师在这块儿讲的是windows下的操作

1. 讲zookeeper下的conf下的zoo_sample.cfg复制一份改名为zoo.cfg，核心配置有

   • clientPort=2181，zookeeper的端口号
   • dataDir=/tmp/zookeeper，zookeeper的临时数据存放位置，这是linux的存放目录，我们可以在zookeeper的目录下创建一个data目录，把临时数据都存放到这个文件夹中，dataDir=…/data，重新启动zookeeper

zookeeper命令

• get /：测试根节点下的值
• create -e /atguigu 123456：在根节点下创建atguigu节点，值为123456

管理控制台和监控中心

监控中心其实可以不安装，不影响后来的任何操作，只是它可以帮助我们通过可视化的界面管理和维护我们众多的服务。

下载的地方是Dubbo的github，Dubbo OPS，其中包含dubbo-admin（管理控制台）、dubbo-monitor（监控中心）

它俩都是SpringBoot项目，

• dubbo-admin

修改application.properties，dubbo.redistry.address=zookeeper://127.0.0.1:2181

使用mvn package打成jar包，使用java -jar运行即可

账密都是root

• dubbo-monitor的启动方式与dubbo-admin的一致，监控中心的默认端口号是7070

DeepSeek介绍

Dubbo是什么与核心价值

• 精确定义：Dubbo是阿里巴巴开源、现为Apache顶级项目的高性能Java RPC（远程过程调用）框架。它的核心职责是让调用远程服务像调用本地方法一样简单。

• 核心价值（解决什么问题）：

  • 服务间通信：在微服务架构中，服务A需要调用服务B的方法，Dubbo负责通过网络完成这个调用，并封装了底层网络通信的复杂性。

  • 服务治理：这是Dubbo区别于普通HTTP客户端（如RestTemplate）的关键。它提供了服务注册/发现、负载均衡、集群容错、流量路由等能力，让您能管理成百上千个服务实例。

• 面试考点：

  • Q: “为什么不用Spring Cloud的Feign（基于HTTP）而用Dubbo？”

  • A:性能（Dubbo基于TCP长连接+NIO，比HTTP短连接效率更高）、服务治理能力（Dubbo内置了更丰富的负载均衡、容错和路由策略）、协议灵活性（可定制序列化方式）。

核心架构与调用流程

• 四大角色职责：

1. Provider（服务提供者）：暴露服务的应用。启动时向注册中心注册自己提供的接口和地址。
2. Consumer（服务消费者）：调用远程服务的应用。启动时从注册中心订阅所需服务的地址列表。
3. Registry（注册中心）：服务地址的“电话簿”。负责存储和通知服务列表的变更。常用ZooKeeper、Nacos。
4. Monitor（监控中心）：统计服务调用次数、耗时、成功率等，用于运维监控。

• 生产应用：理解这个流程后，您就知道了服务发现的机制。当您部署新的Provider节点时，它会自动注册，Consumer会收到通知并开始将流量分发到新节点，实现动态扩缩容。

• 面试考点：

  • Q: “描述一次Dubbo调用全过程。”

  • A: 按上述时序图分阶段描述，重点是Consumer通过动态代理生成远程代理对象，该对象内部通过Invoker处理集群容错、负载均衡，最后通过Protocol层序列化并发送网络请求。

注册中心

协议