分布式通信，微服务协调组件，zookeeper

目录

分布式通信

PRC框架

Http和rpc的区别

微服务协调组件

分布式和微服务的区别

负载均衡

zookeeper

zookeeper是什么？

watch机制原理

leader选举

分布式通信

PRC框架

远程调用，跨进程的调用方法。跨进程，跨同一台计算机的多个进程，多个jvm，多台计算机之间的进程。

rpc，remote procedure call，远程过程调用，指通过网络从远程计算机上获取服务，而不需要了解代码的网络技术实现的一种协议。作用，A计算机提供一个服务，B计算机可以像调用本地服务一样去调用A计算机提供的服务。
要实现rpc需要通过网络进行数据传输，并且对调用的过程进行封装，一般采用tcp作为底层传输协议。
rpc协议，强调的是过程调用，调用的过程对用户来说是完全透明的，用户不需要关心调用细节，可以像调用本地服务一样去调用远程服务。
协议的组件
client：服务的调用方
server：服务提供方
client stub:客户端存根，用来存放服务端的地址信息，将客户端的请求参数打包成网络消息，序列化，然后通过网络远程发送给服务提供方。
server stub：服务端存根，接收客户端发送过来的消息，然后解析消息内容，反序列化，并调用本地方法。

应用：
1.分布式网络通信
2.分布式子系统之间的服务治理
3.分布式负载均衡
4.服务发现和注册
5.构建分布式调试环境

分布式架构：利用多台普通计算机组成一个庞大的复杂计算机网络，提供高并发，高性能，高可用的系统。在分布式架构里，原本单体应用服务被拆分成多个独立部署的服务，这些服务需要通过网络进行通信。而rpc框架，解决了在分布式架构里各个服务之间的网络通信问题的架构。

在Java里jdk提供了rmi,但是不支持跨语言的远程调用。

一般来说，rpc框架应用于大型企业，只有在业务逻辑复杂度高，用户体量比较大的时候，才需要对服务进行解耦，从而达到扩展性强灵活部署的目的。流行rpc框架，Google的grpc,Facebook的thrift，阿里dubbo。

Http和rpc的区别

功能特性：
1.Http是一个应用层的超文本传输协议，是万维网数据通信的基础，主要服务在网页端和服务端的数据传输上。
2.rpc是远程过程调用协议，实现计算机跨网络通信，屏蔽通信底层的复杂性，让开发者像调用本地服务一样调用远程服务。定位层面不同。

实现原理：Http是一个应用层协议，定义了通信的报文格式，例如，Request body，Request header ，response body，response header
rpc是一个协议规范，没有具体实现，只有按照rpc协议规范实现的通信框架，才是协议的具体实现，例如，dubbo，grpc。所以在实现rpc框架的时候，自定义报文通信的协议规范，自定义序列化方式，自定义通信类型，Http是成熟应用协议，rpc只是定义不同服务之间的通信规范。
应用层面：Http和实现rpc协议的框架都能够实现跨网络节点的服务之间的通信，他们底层使用tcp作为通信基础，rpc是一种标准协议，只要符合rpc协议的框架都属于rpc框架，因此rpc的网络通信层可以使用Http实现，例如grpc，openFeign底层采用了Http。

微服务协调组件

分布式和微服务的区别

分布式是一种系统的部署方式，主要是将一个服务拆分部署到多台机器，分摊单台机器负载压力。拆分方式，水平和垂直。部署方式，集群或者主备。

微服务系统架构的设计方式，将复杂的业务拆分成多个微小的服务，这些服务可以单独的部署和运行，服务之间使用rpc进行通信。

为什么有分布式和微服务？

架构演变，在开始的时候Java web服务是打包成一个jar，放入Tomcat运行，这样的项目不利于团队分工协作，后面就有了垂直拆分前后端分离，前端开发前端的，后端开发后端的，前后端可以同时开发，在事先把接口定义好，就可以相互协作互不干扰，这样就提高了开发效率。

随着业务规模越来越大，业务的复杂度越来越高，仅仅前后端分离已经不能满足业务的需求，而一个系统在运行里，往往是后端压力更大，为了缓解后端的压力，开始增加机器，在程序上做一下调优，产生了分布式技术。而服务一旦拆分后面对许多新问题，例如，服务之间通信，发现，主从选举，集群负载均衡问题，为了解决通信问题使用rpc框架，解决服务间发现选举问题，使用zookeeper,nginx解决负载均衡问题。

微服务是在分布式之后出现的一种架构设计思想，SpringBoot出现后才流行微服务这个名称，SpringBoot内置Tomcat，做到了开箱即用，部署一个服务，不需要手动添加依赖环境。

负载均衡

单体架构：对与应用软件，使用一台高配置的服务完成对业务的支撑，特点，用户量少，业务需求简单。

随着用户量的增加，单体架构的问题：
1.软件的性能逐步下降，访问延迟越来越高
2.单点故障
解决方法，集群化部署架构，把一个软件应用同时部署在多台服务器上。
架构变化带来的新问题：
1.客户的请求如何均匀的分发给多台服务器
2.如果检查服务器的健康状态，使客户端不会将请求发送给异常服务器。
解决方法，负载均衡，核心目的让客户端将请求适当均匀的发送给多台目标服务器。因为请求分发给了多个节点，所以整体服务的性能得到了提升。
常用方案:

基于dns实现：在dns上针对某个域名做多个IP地址映射。
原理：当用户通过域名访问网站时，先通过dns进行域名解析，然后dns服务器可以随机分配一个服务集群里某台服务器的IP地址进行访问，实现请求分发。
根据不同地域就近分配IP地址。就近原则处理请求，好处是缩短通信距离，提升网站访问效率。
优点：配置简单，实现成本低，无须额外的开发和维护。
缺点：dns存在多级缓存特性，当我们修改dns配置之后，因为存在缓存导致IP地址更新不及时，影响负载均衡效果。

基于硬件实现：可以简单的把负载均衡设备理解成一个网络设备，类似于网络交换机。
优点：1.性能好，每秒可以处理百万级别请求。
2.支持多种负载均衡算法，可以灵活配置策略。
3.具备防火墙安全功能。
4.硬件负载均衡，有售后支持，企业无须花费精力去维护。
缺点：F5，价格昂贵。一般应用银行和电信领域。

基于软件实现：通过开源或者商业软件实现负载均衡功能。
大部分互联网企业采用，Nginx，lvs,haProxy
优点：1.免费，成本低
2.开源，可以根据企业不同的需求进行二次开发。
3.灵活性高。
根据实际情况选择合适实现。

ISO七层网络模型，负载均衡是作用在网络通信上实现请求分发，我们可以在网络的某些层上做请求分发，负载均衡的作用范围划分：
2层负载：基于Mac地址实现请求分发，采用虚拟Mac的方式实现，服务器收到请求后，通过动态分配后端服务的实现Mac地址进行响应，实现负载均衡
三层负载：基于IP层负载，使用虚拟IP实现，外部请求访问虚拟的IP地址，服务器收到请求后根据后端实际的IP地址转发。
四层负载：根据请求里目标地址和端口进行负载均衡，将用户的请求发送给后端，修改报文里目标地址和源地址进行报文转发。例如，Nginx，F5等可以实现四层负载
七层负载：基于应用层的负载均衡，服务器端可以根据Http请求的报文信息决定把请求分发到那个服务器上。

负载均衡策略
决定当前客户端请求匹配到集群里那个具体的节点。
轮询：多个服务器按照顺序返回，每个服务器得到相同请求次数。
随机：随机获得以目标服务器地址，每个服务器获得请求的不相等。
一致性hash：具有相同hash码的请求永远发送到一个节点上。
最小连接数：根据目标服务器的请求的数量来决定请求分发的权重，在集群里请求较少的节点获得更多的请求。

zookeeper

zookeeper是什么？

分布式中间件，开源协调组件，用来协调和解决分布式系统里的各种问题。

集群管理：为了保证集群的高可用，每个节点都会创建一个数据副本，保证客户端访问集群里的任意一个节点都是最新的数据。

分布式锁：如何保证共享数据的并发安全性，必须使用跨进程的锁，用分布式锁来实现。

master选举：在多个节点集群里为了降低数据同步的复杂度，一般会将节点设置为master，slave2个角色，master一般复制数据的读写事物性操作，而slave提供数据读操作。

zookeeper提供CP模型保证集群里每个节点的数据一致性，不保证强一致性，是一个顺序一致性模型。提供了不同类型的节点，例如持久节点，零时节点，有序节点和容器节点。对应分布式锁这个场景，可以利用有序节点实现，还可以使用同一节点的唯一特性实现。

可以使用持久化节点存储和管理其他集群节点的一些信息，可以利用集群里的一些有序节点的特性实现master选举，例如kafka,hbase,hadoop使用zookeeper实现主从选举。

zookeeper是一个分布式数据一致性解决方案，致力于分布式应用里的一些高可用，高性能，严格顺序访问控制能力模型。底层数据一致性算法基于zab协议实现。

watch机制原理

zookeeper是一个分布式协调组件，为分布式架构下的多一个应用组件提供顺序访问控制能力，他的数据存储采用了类似文件系统的树形结构，以节点的方式来管理存储在zookeeper上的数据，

提供watch机制让用户可以感知到zookeeper 服务器上存储的数据的变化，这个机制可以实现例如配置中心，注册中心等，采用push的方式实现，客户端和zookeeper服务器建立一个长连接，一旦监听到指定节点发生了变化，就会通过长连接把事件通知给客户端。

watch具体流程：
1.客户端通过指定命令例如，exists,get，对特点路径增加watch。

2.服务端接受到请求后，用hashMap保存这个客户端会话和对应关注的节点路径，同时客户端使用hashmap保存指定节点和事件回调函数的对应关系。

3.当服务器指定的watch节点发生变化时，找到这个节点对应的会话，把变化事件和节点信息发送给客户端。

4.客户端收到请求后，从zkwatcherMangager里找到对应的回调方法进行调用，完成事件变更通知。

leader选举

zookeeper集群节点由3中角色组成

leader，负责所有事物的请求处理，以及过半提交的投票发起和决策。

follower，负责接收客户端的非事物请求，参与leader选举投票。

observer，接收非事物请求，不参与选举投票，分担读操作的压力。

zookeeper使用中心化架构，有一个leader作为决策节点。负责事务请求处理和数据同步。好处是可以降低集群里数据同步的复杂度，集群管理简单和稳定。缺点是，如果leader节点宕机，为了保证集群继续提高可靠服务，zookeeper需要从剩下的follow节点里选出一个作为leader节点。

leader选举原理

zookeeper里的每一个节点都会向集群里其他节点发送一个票据vote，他有3个属性，epoch，逻辑时钟，表示当前票据是否过期。zxid,事物ID，表示当前节点最新存储的数据事物编号。myid,服务器ID，每个节点都会选择自己当leader，所以第一次投票的时候携带的是当前节点的信息，接下来每个节点把收到的票据和自己进行比较，根据epoch，zxid,myid,依次逐一比较，值最大的一方获胜。这个节点下次投票时候发送的是获胜的票据信息。经过多路投票之后，每个节点都会统计当前达成一致的票据，以少数服从多数的方式，最终获得票据最多的节点成为leader。

为什么选择epoch，zxid,myid作为投票判断依据？

1.epoch，因为可能存在网络通信延迟，在新一轮投票里面收到上一轮投票的票据，这种数据应该丢弃，否则会影响投票结果。

2.zxid越大，说明这个节点的数据越解决leader，使用他作为判断条件避免数据丢失问题。

3.myid 避免投票时间过长，使用他作为快速终结投票的属性。