微服务之分布式理论概述

2024-04-27 09:04:01
开发
38

一、分布式技术相关的理论

CAP理论

CAP定理(CAP theorem)，⼜被称作布鲁尔定理(Eric Brewer)，1998年第⼀次提出.
最初提出是指分布式数据存储不可能同时提供以下三种保证中的两种以上:

(1) ⼀致性(Consistency): 每次读取收到的信息都是最新的;
(2) 可⽤性(Availability): 每个请求都会收到(⾮错误)响应;
(3) 分区容错性(Partition tolerance): 尽管节点之间的⽹络不通导致分区，系统仍继续运⾏.

事实上，不仅仅是分布式数据存储应⽤，所有分布式系统都必须在CAP这三点之间进⾏权衡.

分区容错性

在分布式系统中，分区容错性是指系统能够继续正常工作，即使网络分区（即网络中的一部分节点无法与其他节点通信）发生。分布式系统通常使用复制和容错技术来实现分区容错性。例如，在分布式数据库系统中，数据可以复制到多个节点上，当一个节点无法与其他节点通信时，系统仍然可以使用其他节点上的数据进行操作。

BAS理论

数据⼀致性模型

如果数据的读取、写⼊、更新的结果是可预测的，称之为遵循数据⼀致性模型.

(1) 严格⼀致性(Strict Consistency)(强)
不论在哪个节点，看到的资源都是统⼀的结果;
(2) 顺序⼀致性(Sequential Consistency)(弱)
节点的数据变动和操作的顺序保持⼀致;
(3) 最终⼀致性(Eventual Consistency)(弱)
所有数据副本最终都会变得⼀致.

⼀致性算法

Paxos : Zookeeper

Raft : ETCD

BASE理论

BASE是Basically Available(基本可⽤)、 Soft state(软状态)和Eventual Consistency(最终⼀致性)三个短语的缩写.

(1) 基本可⽤: 可能是部分功能不可⽤或者是响应时间延⻓;
(2) 软状态: 不同系统/节点之间，数据存在过渡状态;
(3) 最终⼀致: 经过系统内部协调机制，最终所有的节点保持⼀致(分布式系统中的⼀致并不⼀定指数据保持⼀样).

两条系统设计的原则

墨菲定律

墨菲定律(Murphy's law)是⼀种⼼理学效应，由爱德华·墨菲(Edward A. Murphy)提出，亦称墨菲法则.

墨菲定律: 如果有两种或两种以上的⽅式去做某件事情，⽽其中⼀种选择⽅式将导致灾难，则必定有⼈会做出这种选择.

本质: 如果事情有变坏的可能，不管这种可能性有多⼩，它总会发⽣.

康威定律

“设计系统的架构受制于⽣产这些设计的组织的沟通结构

二、zookeeper

2.1概述

安装

import sys
from kazoo.client import KazooClient, KazooState

def main():
  zk = KazooClient(hosts='118.25.185.49:3306',timeout=100)
  zk.start()
  data, stat = zk.get("/")
  print(data)
  print(stat)
  chilen = zk.get_children("/")
  print(chilen)
  zk.stop()
  zk.close()

if __name__ == "__main__":
  main()

2.2应用案例

zookeeper的同类产品

Consul

ETCD

Doozer

ZooKeeper -server host:port cmd args
  # 连接到指定主机和端口的 ZooKeeper 服务器，并执行指定的命令和参数。

stat path [watch]
  # 获取指定路径节点的状态，可以设置监视器以接收更改通知。

set path data [version]
  # 将指定路径节点的数据设置为给定数据，可选进行版本检查。

ls path [watch]
  # 列出指定路径节点的子节点，可以设置监视器以接收更改通知。

delquota [-n|-b] path
  # 删除指定路径的配额，可以是命名空间（-n）或字节（-b）。

ls2 path [watch]
  # 列出指定路径节点的子节点，可以设置监视器以接收更改通知。

setAcl path acl
  # 为指定路径节点设置 ACL（访问控制列表）。

setquota -n|-b val path
  # 为指定路径设置配额，可以是命名空间（-n）或字节（-b），并指定值。

history
  # 显示命令历史记录。

redo cmdno
  # 重做指定的命令编号。

printwatches on|off
  # 打印监视器状态，可以开启或关闭。

delete path [version]
  # 删除指定路径的节点，可以指定版本。

sync path
  # 同步指定路径。

listquota path
  # 列出指定路径的配额信息。

rmr path
  # 递归删除指定路径。

get path [watch]
  # 获取指定路径节点的数据，可以设置监视器。

create [-s] [-e] path data acl
  # 创建具有指定数据和 ACL 的节点，可以选择顺序（-s）或临时（-e）。

addauth scheme auth
  # 添加指定方案和凭证的认证信息。

quit
  # 退出 ZooKeeper 客户端。

getAcl path
  # 获取指定路径节点的 ACL。

close
  # 关闭 ZooKeeper 客户端连接。

connect host:port
  # 连接到指定主机和端口的 ZooKeeper 服务器。

2.3Zookeeper核⼼概念

Session会话

数据模型

Watch

Session会话

⼀个客户端连接⼀个会话，由Zookeeper分配唯⼀的会话ID;

客户端以特定的时间间隔发送⼼跳以保持会话有效，tickTime;

超过会话超时时间未收到客户端的⼼跳，则判定客户端“死”了，默认是两倍的tickTime;

会话中的请求按FIFO顺序执⾏.

数据模型

Znode命名规范

Znode节点类型

顺序节点

Znode数据构成

Znode 元数据stat结构

ACL: 访问控制列表

create [-s] [-e] path data acl 
setAcl path acl 
getAcl path

Zookeeper中的时间

Watch监听机制

Watch重要特性

⼀次性触发

Watch触发后即被删除，要持续监控变化，则需要持续设置watch.

有序性

客户端先得到watch通知，之后才会看到变化结果.

Watch注意事项

Watch是⼀次性触发器，如果你获得⼀个watch事件，并且希望得到关于未来更改的通知，则必须设置另⼀个watch;

因为watch是⼀次性触发器，并且在获取事件和发送获取watch的新情求之间存在延迟，所以不能可靠地得到节点发⽣的每个更改;

⼀个watch对象只会被特定的通知触发⼀次。如果⼀个watch对象同时注册了exists、getData，当节点被删除时，删除事件对exists、getData都有效，但只会调⽤watch⼀次.

Zookeeper特性

2.4Zookeeper集群

组⽹⽅式

三台虚拟机
192.168.31.241
192.168.31.242
192.168.31.243
通过映射到主机端
2181/2888/3888
容器⽹络⽅案: OpenVSwitch

docker run -d --rm -p 2181:2181 -p 2888:2888 -p 3888:3888 -e ZOO_MY_ID=1 -e ZOO_SERVERS="server.1=0.0.0.0:2888:3888 server.2=192.168.31.242:2888:3888 server.3=192.168.31.243:2888:3888" zookeeper:3.4.11

docker run -d --rm -p 2181:2181 -p 2888:2888 -p 3888:3888 -e ZOO_MY_ID=2 -e 
ZOO_SERVERS="server.1=192.168.31.241:2888:3888 server.2=0.0.0.0:2888:3888 server.3=192.168.31.243:2888:3888" 
zookeeper:3.4.11

docker run -d --rm -p 2181:2181 -p 2888:2888 -p 3888:3888 -e ZOO_MY_ID=3 -e 
ZOO_SERVERS="server.1=192.168.31.241:2888:3888 server.2=192.168.31.242:2888:3888 server.3=0.0.0.0:2888:3888" zookeeper:3.4.11

三、RPC原理

3.1概述

Remote procedure call - RPC
远程过程调⽤

过程是什么?
过程就是业务处理、计算任务，更直⽩理解，就
是程序;
像调⽤本地⽅法⼀样调⽤远程的过程.

熟悉的Webserveice、restful接⼜调⽤时都是RPC，仅消息的组织⽅式以及消息协议不同.

远程过程调⽤较本地调⽤有何不同?

速度相对慢;

可靠性减弱.

3.2RPC流程

3.3RPC协议

3.3RPC框架

封装好参数编组、消息解组、底层⽹络通信的RPC程序开发框架，带来的便捷是可以直接在其
基础上只专注过程代码编写

为什么要⽤RPC

服务化;

可重⽤;

系统间交互调⽤.

3.4 RPC核⼼概念术语

3.5基于RPC的分布式服务注册与服务发现架构

流程图

步骤

1. 创建Zookeeper集群

2. 制作Kazoo镜像

3. 实现服务注册代码

4. 实现服务发现代码

创建Zookeeper集群

. 制作Kazoo镜像

实现服务注册

实现服务发现代码

原文地址:https://blog.csdn.net/qq_62377885/article/details/138220714 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：https://www.suanlizi.com/kf/1784025675074768896.html 如若内容造成侵权/违法违规/事实不符，请联系《酸梨子》网邮箱：1419361763@qq.com进行投诉反馈，一经查实，立即删除！

阅读全部