Dubbo学习笔记（四）——微服务架构
微服务架构
解决方案
-
Spring Boot + Spring Cloud
组件多，功能完备，基于HTTP。 -
Spring Boot + Dubbo + Zookeeper
组件少，功能不完备，基于RPC通信方案
微服务架构需要解决的难题
-
客户端如何访问这么多服务
API 网关 -
服务与服务之间如何通信
同步通信 HTTP（Apache Http Client） RPC（Dubbo）
异步通信 消息队列（Kafka RabbitMQ RocketMQ) -
服务治理
基于客户端的服务注册与发现（Zookeeper)
基于服务端的服务注册与发现（Eureka） -
服务挂了怎么解决
重试机制、服务熔断、服务降级、服务限流
ZooKeeper
是一种分布式协调服务，用于管理大型主机，主要用于解决分布环境当中多个进程之间的同步控制，让他们有序地去访问某种临界资源，防止造成脏数据的后果。
数据模型
它很像数据结构中的树。树是由节点组成的，数据存储是基于节点，这种节点叫做Znode。
不同于树的节点，Znode的引用方式是路径引用，类似于文件。
这样的层级结构，让每个Znode节点拥有唯一的路径，就像命名空间一样，对不同信息做出清晰的隔离。
Znode包含哪些元素：
- data：节点存储的数据信息。
- ACL：记录节点的访问权限。
- stat：包含节点的各种元数据，例如事务ID、版本号、时间戳、大小等。
- child：当前节点的子节点引用。
每个节点存储的数据最大为1MB。
Znode分成四种类型：
- 临时节点：当创建节点的客户端与zookeeper断开之后，临时节点会被删除。
- 临时顺序节点
- 持久节点
- 持久顺序节点
所谓顺序节点，就是在创建节点的时候，zookeeper根据创建的时间顺序给节点名称进行编号。
事件通知
watch可以理解为注册在特定节点上的触发器，当这个节点发生了改变，也就是调用了create、delete、setData方法的时候，会触发节点上注册的对应事件，请求watch的客户端会接收到异步通知。
一致性
为了防止单机会挂掉的情况，zookeeper维护了一个集群，主从模式，是一主多从结构的，一个master，多个slave。
在更新数据的时候，首先更新到master，然后再同步到slave，读取数据的时候，直接从任意位置读取，为了保持主从数据的一致性，zookeeper采用ZAB协议，类似于paxos。
ZAB协议
zookeeper atomic broadcast，有效解决了zookeeper集群崩溃和主从同步问题。
定义了节点三种状态：选举态、following、Leading。如果master挂了，集群会通过ZAB进行崩溃恢复，选举新的master。
- 选举阶段：选举master的依据是投票，每个节点会将票投给事务id最大的节点，也就是数据最新的节点。
- 发现阶段：在选举结束之后，Leading状态的准master会利用纪元号通知各个slave告诉自己是leader，这样避免脑裂。
- 同步阶段：把master收集到的最新历史事务日志，同步给集群中所有的slave，当有半数slave同步成功，这个master才能成为正式的master。
ZAB数据写入：涉及到broadcast阶段，就是zookeeper常规情况下更新数据的时候，由master广播到所有slave，过程如下。
- 客户端发出写入数据请求给任意slave；
- slave把写入数据情况转发给master；
- master采用二段提交方式，先发送propose广播给slave；
- slave接收到propose消息，写入日志成功后，返回ack给master；
- 当master接收到半数以上ack消息，返回成功给客户端，并且广播commit给所有slave。
应用场景
- 分布式锁
- 服务注册和发现
- 共享配置和状态信息
实现分布式锁
什么是分布式锁？
为了防止分布式系统中多个进程相互干扰，需要一种分布式协调技术来实现进程调度，其技术核心就是来实现分布式锁。
分布式锁应该具备以下条件：
- 分布式系统环境下，一个方法在同一时间只能在一个线程执行；
- 高可用的获取锁与释放锁；
- 高性能的获取锁与释放锁；
- 可重入性；
- 具备失效机制，防止死锁；
- 非阻塞锁特性，没有获取到锁的线程不会被阻塞，而是直接返回失败。
分布式锁的实现方式：
- Memcached
- Redis
- Zookeeper：天生就是为了实现分布式锁的。
- Chubby
客户端需要获取锁的时候，就创建指定的Znode，如果其他线程来获取锁，发现节点存在，就不能获得锁。
Znode有临时顺序节点：
利用临时性，当客户端连接的时候，就加锁，当客户端掉了，就解锁了，这样实现了加锁和解锁，同时防止了死锁。
利用有序性，多个进程创建一个锁，可以对锁节点进行编号排序，序号最小的锁节点可以获取资源，然后通过zookeeper的watch机制，当发现比自己小的锁节点被删除了，当前锁就能获取到资源了。
zookeeper于redis实现分布式锁的比较：
| 分布式锁 | 优点 | 缺点 |
|---|---|---|
| zookeeper | 有封装好的框架，容易实现，有等待锁的队列，大大提升竞争锁的效率。 | 添加和删除节点的性能较低。 |
| Redis | Set和Del指令的性能高。 | 实现复杂，需要考虑超时、原子性、误删等情况；没有等待锁的对垒，只能在客户端进行自旋获取，效率低。 |
配置
三种工作模式：
- 单机模式
- 集群模式：在多台机器上部署，适合线上。
- 伪集群模式：在一台机器上部署多个zookeeper，适合实验环境。
三种端口号：
- 2183：客户端连接zookeeper集群所使用的监听端口号。
- 3888：选举leader使用。
- 2888：集群内机器通讯使用。
单机模式配置文件
clientPort = 2181
dataDir = /data
dataLogDir = /datalog
tickTime = 2000
- tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。
- dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
- clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
- dataLogDir：保存日志的目录。
集群模式配置文件
tickTime=2000
initLimit=10
syncLimit=5
dataLogDir=/opt/zookeeper/logs
dataDir=/opt/zookeeper/data
clientPort=2181
autopurge.snapRetainCount=500
autopurge.purgeInterval=24
server.1= 192.168.1.148:2888:3888
server.2= 192.168.1.149:2888:3888
server.3= 192.168.1.150:2888:3888
-
initLimit：这个配置项是用来配置zookeeper接受客户端（这里所说的客户端不是用户连接zookeeper服务器的客户端,而是zookeeper服务器集群中连接到leader的follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。
当已经超过10个心跳的时间（也就是tickTime）长度后 zookeeper 服务器还没有收到客户端的返回信息,那么表明这个客户端连接失败。总的时间长度就是 10*2000=20秒。 -
syncLimit：这个配置项标识leader与follower之间发送消息,请求和应答时间长度,最长不能超过多少个tickTime的时间长度,总的时间长度就是5*2000=10秒。
-
定时清理：
autopurge.purgeInterval，指定清理频率，单位是小时。
autopurge.snapRetainCount，这个参数和上面的参数搭配使用，这个参数指定了需要保留的文件数目。 -
maxClientCnxns：限制连接到Zookeeper的客户端数量，限制并发连接的数量，它通过IP来区分不同的客户端。可以用来阻止一些Dos攻击。
-
server.A=B:C:D中的A是一个数字,表示这个是第几号服务器,B是这个服务器的IP地址，C第一个端口用来集群成员的信息交换,表示这个服务器与集群中的leader服务器交换信息的端口，D是在leader挂掉时专门用来进行选举leader所用的端口。
Dubbo
是一款高性能轻量级的开源Java RPC分布式服务框架，提供三大核心能力：
- 面向接口的远程方法调用。
- 智能容错和负载均衡。
- 服务自动注册和发现。
具有特性：
- 透明远程调用
- 负载均衡机制
- 容错重试机制
- 自动注册发现
- 性能日志监控
- 服务治理中心
- 自动治理中心
Dubbo功能介绍在之前的笔记中可以看到。
服务熔断
什么是服务熔断？
在微服务架构中，根据业务来拆分一个个的服务，服务与服务之间可以通过RPC相互调用，为了保证其高可用，单个服务通常会集群部署，如果单个服务出现了线程阻塞，调用这个服务就会出现阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性导致故障传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的雪崩效应。
为了解决服务依赖导致的故障传播，提出了通过服务熔断。
服务熔断配置
利用Hystrix实现服务熔断，需要配置触发熔断的条件和熔断方法。如果对目标服务调用失败，并触发了熔断机制，就是调用熔断方法，防止阻塞。
可以在服务的提供者或者消费者上使用熔断机制。