dubbo+zookeeper

分布式系统中的相关概念

概念

互联网项目架构目标

集群和分布式

分布式概述：能够独立启动，能独立对外提供服务

下图中的区别在于切菜，一个是人工一个是机器。

这个 故事是这样的：我开了一家餐馆；一开始只有我一个人，然后我负责洗菜切菜和炒菜；

高性能：我雇了一个大厨，跟我干一模一样的事情；原本一小时我只能做十个菜，现在可以做二十个了；

高可靠：但是我发现，一个人干三个人的活，效率太低了，于是我聘请了四个人，帮我和另一个大厨洗菜和切菜；

可伸缩：然后我又发现，这洗菜的效率太慢了，于是我又雇了一个洗菜的；（加人-加机器）

高可扩展：随着科技的发展，我发现机器人切菜效率更高，费用更低，那我就把俩切菜工替换成为两个机器人；

1、高性能、高可用

浏览器进来之后由负载均衡负责统一调度。实现流量的转发，实现的工具Nginx；我将系统上传三份一样的到三个服务器上，这个时候一个个app(服务器)组成的就是一个集群；从而实现了高性能和高可。

2、可伸缩

拆分服务,将AB和CD进行拆分到多个机器上,然后进行方便拓展;这种方式称为集群分布式,既有集群,又有分布式.

3、高可扩展

简单来说就是机器不够加机器，三个AB变成四个；如果加服务就加太机器去实现E；

架构的演进

1、单体架构

所有服务模块都部署到一台机器上。

如果是一个app部署到一个服务器上，那就是单机单体架构

如果是一个app部署到多个服务器上，那就是多机单体架构；需搭建集群

2、垂直架构

将项目拆分成为两个独立的项目，拆分后两项目不进行交互。

缺点：重复功能太多了，比如用户管理（公共模块），大家都得用，因为是不能交互的，那所有的机器中都必须写一个相同的模块，很麻烦。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

3、分布式架构

将公共模块抽离出来成为一个独立模块。Dubbo就 是把RPC框架进行再封装。

4、SOA架构

ESB：总线—中介，A要调用D,那么A就要告诉ESB说我要调用D了，拿ESB就会找到D的地址进行转发。这个东西我怎么像是代理模式一样。

5.微服务架构

Bubbo

概念

架构

0.start：服务的提供者要运行在一个容器中，将服务启动起来。例如：Tomcat

1.register：然后服务就会注册到注册中心；相当于将你服务调用的ip、端口、服务发布的URL等信息放到注册中心中去。告诉别人我有一个服务已经发布了，别人可以调用我了。

2.subscribe（服务发现）：这个时候我就找注册中心让你把刚才注册的ip、端口、服务发布的URL告诉我。

3.notify：我要一次你给我一次，叫做服务唤醒。

4.invoke（PRC过程是同步的）：是一个RPC的过程，就是可以调用了。这个地方就是由dubbo内部自动实现。

5.管理部署，监控的作用。

bubbo快速入门

安装zookeeper，tar -zxvf 解压文件

我来解释一下下面几个图片，第一图我需要创建一个zoo.cfg 这个就是zookeeper的配置文件，这个是由zoo_sample.cfg复制得来的；其次就是第二个图片，是创建在zookeeper目录下的zkdata ，是用于zookeeper用于存放数据，最后修改zoo.cfg中dataDir中zkdata 的绝对地址。

启动/停止/查看状态：zookeeper；端口号是2181

快速入门dubbo

正片

开头先说遇见的问题:

1. 我在dubbo-service中出错并且加以修改但是未生效,run Maven ->install 后生效。

2. 添加插件

3. Failed to stop iptables.service: Unit iptables.service not loaded. 关闭防火墙：systemctl stop firewalld

创建Spring和SpringMVC项目.

这里正常应该是controller下写service;现在拆分成为两个模块,然后通过依赖将二者联系起来

然后就是正常创建项目了，导入依赖、配置文件、日志

问题4：zk访问失败，可能的原因是防火墙没关，端口没有放开，linux则需要关闭或者放通端口，windows则需要把360关了。

改造服务提供者

这里是spring，所以把mvc删了。

配置dubbo，看图…

这个时候是dubbo 的@Service

改造服务消费者

1.这个时候已经不存在依赖了。删依赖

2.@Reference的使用过程中有一个问题就是，你需要本地和远程必须要写一模一样的服务（方法）否则你调用的时候就找不到，就是spring找不到这个bean；如果一直那么写，一两个接口还好，要是一亿个接口不就裂开了。

解决方法

• 抽取出一个公共模块

dubbo高级特性

dubbo-admin安装和基本使用（失败）

作为Monitor的替代，比Monitor效率更高，功能更多。

这个已经跑了两天，跑不起来，算了！后面去改成Nacos

大概流程就是跑起来后就能看到界面，界面长这个样子。

然后把之前写的服务启动起来，就能查询到提供者，消费者是第一次运行后才能看见。

两个机器要建立连接，那就必须要有管道。将对象序列化成为流的形式通过管道进行传输.

地址缓存

当zookeeper挂掉之后，注册的服务还能用吗？答案是可以。因为有缓存

超时与重试

评论区说可以用MQ去解决，还有说这是心跳，还有说这样还是有可能会雪崩。

服务的消费方和提供方都能设置超时，但是建议在提供方，谁定义的服务，那谁就应该知道服务的情况从而进行设置。

重试

比如网络抖动，如果网络突然断掉，然后重新连上了。

设置重试次数

多版本

负载均衡

第一种：概率

第二种：轮询

• 场景一：如果没有权重或者权重一样则就是1->2->3一个一次
• 场景二：权重是1：2：1，顺序则为 1232

第三种leatActive：来了一个请求，消费者会问提供者，你们最后一次处理请求花了多少时间呢？三个提供者会提供时间给消费者，消费者这个时候就会去找那个时间最少的，也是最快的。若活跃度相同：则是随机调用。

第四种ConsistentHash：消费者会找相同参数请求的服务提供者。将会永远调用同一部机器。

配置项：

1.tomcat端口号，启动的时候记得是tomcat7 ：run，相当于三个tomcat，端口不一样。

2.@Service(weight=权重)；配置权重。

3.<dubbo:protocol port=“20884”/> 配置dubbo协议端口，仨都不一样。

4.<dubbo:parameter key=“qos.port” value=“33333”/> 配置qos.port端口。

5.@Reference(loadbalance = “random”) 配置负载均衡策略。 默认值就是random，还u有其他三种策略。

集群容错

就是当消费者消费的时候出错了的时候dubbo怎么处理。

服务降级

打比方：B机器中最重要的服务就是支付服务，既然如此，当服务器CPU等性能消耗到极致的时候，那就会将一些不重要的服务停掉以换取系统的正常运行，如果你支付服务都不能用了，系统就没有跑着的必要了。

补充

RPC框架：远程调用

网络三要素：协议、ip、端口

war项目：可以独立对外提供服务

序列化：将Java对象转换成为流数据这叫做序列化，下图为zk没有序列化对象导致的报错

maven的依赖传递

关于maven依赖问题相关解决办法

先上报错：报错的原因是找不到类

报错就在于25行找不到findUser这个方法，原因在于dubbo-service本身就是一个war包，而maven需要的是一个jar包，因此报错。

还有一个就是因为版本问题导致的

这个问题的原因就是很经典的你pojos没打包就打包interface导致你maven编译的时候找不到Student这个类。

idea和maven两种打包方式

maven打包的方式：

• web打包需要到仓库去寻找已知的jar包，就是已经打包了的jar，war包不算。
  • 若找不到则报错，版本不对找不到方法也错（忘记打包更新）

idea打包：用tomcat测试即可

• 实时的，可以避免maven去找仓库导致的版本不对齐问题