分布式基础理论分布式系统是若干独立计算机的集合这些计算机对于用户来说就像单个相关系统分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器处理更多的数据。分布式系统distributed system是建立在网络之上的软件系统。首先需要明确的是只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候且硬件的提升加内存、加磁盘、使用更好的CPU高昂到得不偿失的时候应用程序也不能进一步优化的时候我们才需要考虑分布式系统。因为分布式系统要解决的问题本身就是和单机系统一样的而由于分布式系统多节点、通过网络通信的拓扑结构会引入很多单机系统没有的问题为了解决这些问题又会引入更多的机制、协议带来更多的问题。。。随着互联网的发展网站应用的规模不断扩大常规的垂直应用架构已无法应对分布式服务架构以及流动计算架构势在必行急需一个治理系统确保架构有条不紊的演进。应用架构的发展演变垂直应用也是把后端代码和前端代码放在一起的公用模块无法重复利用开发性的浪费例如订单模块有时候会用到用户模块的代码就需要在订单模块写用户相关的代码就是说应用之间也是会交互的应用不可能完全独立大量的应用之间需要交互分布式把前端和后端就分开了好处是业务逻辑不变的情况下如果我们只想改界面那我们只需要重启界面的服务器就好了问题用户的web可能在A服务器业务逻辑可能在B服务器上订单在C服务器上此时如果A服务器要调用B服务器的功能这种跨服务器的调用分为RPC远程过程调用分布式服务架构下最核心的难点就是如何进行远程过程调用以及如何拆分业务提升业务的复用程度此时分布式服务框架就能极大的简化我们的开发。随着我们业务不断的增多我们拆分的服务也越来越多有成千上万的服务器在跑各种不同的服务而出现的资源浪费的情况就尤为严重。比如我们的用户业务访问量比较小结果它有100台服务器在跑而我们的商品业务却只有10台服务器在跑那么就应该有一个基于访问压力的调度中心帮我们监控这些数据并动态的调度提高资源的利用率。用户业务的服务器多了就减几台让这些服务器跑其他业务量更大的业务。这时候我们就可以采用流动计算架构。我们引入调度中心它负责维护我们这些服务之间的复杂关系以及实时管理整个集群。比如A服务器访问量大了我们给A动态的多来几台假设A的集群第一台服务器有100个请求第二个有2个请求那么下次请求进来就应该找比较闲的服务器来处理请求以此来提高我们整个服务的利用率。RPC与之相对应的是httpRPC两个核心模块通讯和序列化。影响一个RPC框架的性能有两点看这个RPC框架能否快速的在各个服务器之间建立连接看这个RPC框架序列化和反序列机制速度快不快RPC框架在市面上也有很多它们虽然用法不同但是思想都是一样的都是通过网络通信来实现远程过程调用阿里的dubbo、hsf谷歌的gRPCfacebook的Thriftdubbodubbo发展历程11年阿里将duboo托管到了github上并持续更新14年10月阿里发布了dubbo 2.4.1版本至此以后停更当当网维护了dubbo的一个分支dubbox网易考拉维护的dubbok17年Spring Cloud在抢占分布式市场大红大紫阿里就连续更新了几个版本18年1月阿里将dubbo与dubbox合并更新到了dubbo的2.6版本一直到18年的2月15日阿里将dubbo开源贡献给了Apachedubbo与它的核心能力Apache Dubbo是一款高性能、轻量级的开源Java RPC框架它提供了三大核心能力面向接口的远程方法调用提供高性能的基于代理的远程调用能力服务以接口为粒度为开发者屏蔽远程调用底层细节。智能容错和负载均衡内置多种负载均衡策略智能感知下游节点健康状况显著减少调用延迟提高系统吞吐量服务自动注册和发现支持多种注册中心服务服务实例上下线实时感知。高度可扩展能力遵循微内核 插件的设计原则所有核心能力如Protocol、Transport、Serialization被设计为扩展点平等对待内置实现和第三方实现运行期流量调度内置条件、脚本等路由策略通过配置不同的路由规则轻松实现灰度发布同机房优先等功能。可视化的服务治理与运维提供丰富服务治理、运维工具随时查询服务元数据、服务健康状态及调用统计实时下发路由策略、调整配置参数。dubbo设计架构服务提供者Provider)暴露服务的服务提供方服务提供者在启动时向注册中心注册自己提供的服务。服务消费者Consumer)调用远程服务的服务消费方服务消费者在启动时向注册中心订阅自己所需的服务服务消费者从提供者地址列表中基于软负载均衡算法选一台提供者进行调用如果调用失败再选另一台调用。注册中心Registry)注册心返回服务提供者地址列表给消费者如果有变更注册中心将基于长连接推送变更数据给消费者监控中心Monitor)服务消费者和提供者在内存中累计调用次数和调用时间定时每分钟发送一次统计数据到监控中Dubbo框架容器Containerdubbo运行流程dubbo框架启动就会启动Container这儿就可以直接理解为dubbo框架启动了服务提供者就会将该服务信息注册到注册中心注册中心就知道有哪些服务上线了服务消费者启动的时候就会从注册中心订阅自己所需要的服务如果某个服务提供者有变更注册中心基于长连接的方式将这次服务变更推送给服务消费者消费者就实时的知道这个服务器不能调用了消费者获取到所有它能调用的服务提供者可以同步来调用服务提供者如果有多个服务提供者消费者可以通过负载均衡算法选择一个服务提供者来进行调用服务消费者和服务提供者每一次调用的信息定时每分钟发送一次统计数据到监控中注册中心 zookeeperZookeeper是Apache Hadoop的子项目是一个树形的目录服务支持变更推送适合作为Dubbo服务的注册中心工业强度较高可用于生产环境并推荐使用Zookeeper 注册中心实现支持以下高可用能力当提供者出现断电等异常停机时注册中心能自动删除提供者信息当注册中心重启时能自动恢复注册数据以及订阅请求当会话过期时能自动恢复注册数据以及订阅请求当设置 registry.checkfalse 时记录失败注册和订阅请求后台定时重试todo 由于时间原因所有的代码下载之类都全部是从老师的文档中直接拷贝的并没有经过自己的实际验证zookeeper是需要下载来进行启动的老师在这块儿讲的是windows下的操作讲zookeeper下的conf下的zoo_sample.cfg复制一份改名为zoo.cfg核心配置有clientPort2181zookeeper的端口号dataDir/tmp/zookeeperzookeeper的临时数据存放位置这是linux的存放目录我们可以在zookeeper的目录下创建一个data目录把临时数据都存放到这个文件夹中dataDir…/data重新启动zookeeperzookeeper命令get /测试根节点下的值create -e /atguigu 123456在根节点下创建atguigu节点值为123456管理控制台和监控中心监控中心其实可以不安装不影响后来的任何操作只是它可以帮助我们通过可视化的界面管理和维护我们众多的服务。下载的地方是Dubbo的githubDubbo OPS其中包含dubbo-admin管理控制台、dubbo-monitor监控中心它俩都是SpringBoot项目dubbo-admin修改application.propertiesdubbo.redistry.addresszookeeper://127.0.0.1:2181使用mvn package打成jar包使用java -jar运行即可账密都是rootdubbo-monitor的启动方式与dubbo-admin的一致监控中心的默认端口号是7070DeepSeek介绍Dubbo是什么与核心价值精确定义Dubbo是阿里巴巴开源、现为Apache顶级项目的高性能Java RPC远程过程调用框架。它的核心职责是让调用远程服务像调用本地方法一样简单。核心价值解决什么问题服务间通信在微服务架构中服务A需要调用服务B的方法Dubbo负责通过网络完成这个调用并封装了底层网络通信的复杂性。服务治理这是Dubbo区别于普通HTTP客户端如RestTemplate的关键。它提供了服务注册/发现、负载均衡、集群容错、流量路由等能力让您能管理成百上千个服务实例。面试考点Q: “为什么不用Spring Cloud的Feign基于HTTP而用Dubbo”A:性能Dubbo基于TCP长连接NIO比HTTP短连接效率更高、服务治理能力Dubbo内置了更丰富的负载均衡、容错和路由策略、协议灵活性可定制序列化方式。核心架构与调用流程四大角色职责Provider服务提供者暴露服务的应用。启动时向注册中心注册自己提供的接口和地址。Consumer服务消费者调用远程服务的应用。启动时从注册中心订阅所需服务的地址列表。Registry注册中心服务地址的“电话簿”。负责存储和通知服务列表的变更。常用ZooKeeper、Nacos。Monitor监控中心统计服务调用次数、耗时、成功率等用于运维监控。生产应用理解这个流程后您就知道了服务发现的机制。当您部署新的Provider节点时它会自动注册Consumer会收到通知并开始将流量分发到新节点实现动态扩缩容。面试考点Q: “描述一次Dubbo调用全过程。”A: 按上述时序图分阶段描述重点是Consumer通过动态代理生成远程代理对象该对象内部通过Invoker处理集群容错、负载均衡最后通过Protocol层序列化并发送网络请求。注册中心协议