英文网站推广工作,环球资源外贸平台免费,群晖 搭建wordpress,怎样建设游戏网站微服务组件架构之服务注册与发现之Nacos
Nacos服务注册与发现流程
服务注册#xff1a;Nacos 客户端会通过发送REST请求的方式向Nacos Server注册自己的服务#xff0c;提供自身的元数据#xff0c;比如ip地址、端口等信息。 Nacos Server接收到注册请求后#xff0c;就会…微服务·组件架构之服务注册与发现之Nacos
Nacos服务注册与发现流程
服务注册Nacos 客户端会通过发送REST请求的方式向Nacos Server注册自己的服务提供自身的元数据比如ip地址、端口等信息。 Nacos Server接收到注册请求后就会把这些元数据信息存储在一个双层的内存Map中。服务心跳在服务注册后Nacos Client会维护一个定时心跳来持续通知Nacos Server说明服务一直处于可用状态防止被剔除。默认 5s发送一次心跳。服务同步如果是集群部署Nacos 服务端集群之间会互相同步服务实例用来保证服务信息的一致性。服务发现Nacos 客户端在调用服务提供者的服务时会发送一个REST请求给Nacos 服务端获取上面注册的服务清单并且缓存在Nacos 客户端本地同时会在Nacos客户端本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存。服务健康检查Nacos 服务端会开启一个定时任务用来检查注册服务实例的健康情况对于超过15s没有收到客户端心跳的实例会将它的 healthy属性置为false如果某个实例超过30秒没有收到心跳直接剔除该实例
Nacos服务注册中心数据模型
定义服务
在Nacos中服务的定义包括以下几个内容
命名空间NamespaceNacos数据模型中最顶层、也是包含范围最广的概念用于在类似环境或租户等需要强制隔离的场景中定义。分组GroupNacos数据模型中次于命名空间的一种隔离概念区别于命名空间的强制隔离属性分组属于一个弱隔离概念主要用于逻辑区分一些服务使用场景或不同应用的同名服务最常用的情况主要是同一个服务的测试分组和生产分组、或者将应用名作为分组以防不同应用提供的服务重名。服务名name该服务的实际名称一般用于描述该服务提供了某种功能或能力。 通常推荐使用运行环境作命名空间、应用名作为分组和服务功能作为服务名的组合来确保该服务的天然唯一性。
服务元数据
健康保护阈值ProtectThreshold未来防止因过多实例故障导致所有流量流入剩余实例继而造成流量压力将剩余实例被压垮形成的雪崩效应应将保护阈值定义为一个0到1之间的浮点数。当域名健康实例数占总服务实例数的比值小于该值时无论实例是否健康都会将这个实例返回给客户端。这样做虽然损失了一部分流量但是保证了集群中剩余健康实例能正常工作。实例选择器Selector用于在获取服务下的实例列表时过滤和筛选实例。该选择器也被称为理由器目前Nacos支持通过将实例的部分信息存储在外部元数据管理CMDB中并在发现服务时使用CMDB中存储的元数据标签进行筛选的能力。拓展数据extendData用于用户在注册实例时自定义扩展的元数据内容形式为k-v。
服务端数据结构
/*** Map(namespace, Map(group::serviceName, Service)).*/
private final MapString, MapString, Service serviceMap new ConcurrentHashMap();/*** Service of Nacos server side** pWe introduce a service -- cluster -- instance model, in which service stores a list of clusters, which* contain* a list of instances.** phis class inherits from Service in API module and stores some fields that do not have to expose to client.* * author nkorange*/
//重要Service实体类中包含Cluster对象
private MapString, Cluster clusterMap new HashMap();/*** Cluster. 集群类**/
//持久实例列表
JsonIgnore
private SetInstance persistentInstances new HashSet();//临时实例列表
JsonIgnore
private SetInstance ephemeralInstances new HashSet();//持有service对象
JsonIgnore
private Service service;定义实例
由于服务实例是具体提供服务的节点因此Nacos在设计实例的定义时主要需要存储实例的一些网络相关的基础信息。
网络IP地址该实例的IP地址在Nacos2.0版本后支持设置为域名。网络端口该实例的端口信息。健康状态Healthy用于表示该实例是否为健康状态会在Nacos中通过健康检查手段进行维护。集群Cluster用于标示该实例归属于哪个逻辑集群。拓展数据extendData用与用户自定义扩展的元数据内容形式为k-v。
实例元数据
权重Weight实例级别的配置。权重越大分配给该实例的流量越大。上线状态Enable标记该实例是否接受流量优先级大于权重和健康状态。拓展数据extendData用与用户自定义扩展的元数据内容形式为k-v。 在Nacos2.0版中实例数据被拆分为实例定义和实例元数据只要对应着两种不同场景开发运行场景以及运维场景。
客户端数据结构 /*** unique id of this instance.*/private String instanceId;/*** instance ip*/private String ip;/*** instance port*/private int port;/*** instance weight*/private double weight 1.0D;/*** instance health status*/private boolean healthy true;/*** If instance is enabled to accept request*/private boolean enabled true;/*** If instance is ephemeral** since 1.0.0*/private boolean ephemeral true;/*** cluster information of instance*/private String clusterName;/*** Service information of instance* 拼接分组名服务名*/private String serviceName;/*** user extended attributes*/private MapString, String metadata new HashMapString, String();集群
定义集群
健康检查类型HealthCheckTye使用哪种类型的健康检查方式目前支持的TCPHTTPMySQL设置为NONE可以关闭健康检查。健康检查端口HealthCheckPort设置用于健康检查的端口。是否使用实例端口进行健康检查UseInstancePort如果使用实例端口进行健康检查将会使用实例定义中的网络端口进行健康检查而不再使用上述设置的健康检查端口进行。拓展数据extendData用与用户自定义扩展的元数据内容形式为k-v。 生命周期
在注册中心中实例数据都和服务实例的状态绑定因此服务实例的状态直接决定了注册中心中实例数据的生命周期。
服务的生命周期
开始用户向注册中心发起服务注册请求结束用户主动发起删除服务的请求或一定时间内服务没有实例。
实例的生命周期
持久化实例
持久化的实例会通过健康检查的状态维护健康状态但是不会自动终止该实例的生命周期。唯一终止持久化实例生命周期的方法就是注销实例的请求。
非持久化实例
Nacos1.0版本通过心跳请求进行续约当超过一定时间内没有心跳进行续约时该非持久化实例则终止生命周期。 Nacos2.0版本通过gRPC的长连接来维持状态当连接发生中断时该非久化实例则终止生命周期。
集群的生命周期
开始与集群中第一个实例的生命周期同时开始。结束与集群中最后一个服务的生命周期同时结束。
元数据的生命周期
元数据通常为运维人员的主从操作的数据会被Nacos进行一段时间的记忆。因此元数据的生命周期的终止相比对应的数据要滞后如果在滞后期间对应的数据又重新开始生命周期则元数据的生命周期将被立即重制。
Nacos注册中心健康检查机制
临时实例健康检查机制
Nacos提供给了两种方式进行临时实例的注册即通过Nacos的OpenAPI进行服务注册或通过Nacos提供的SDK进行服务注册。 OpenAPI的注册方式是用户根据自身需求调用Http接口对服务进行注册然后通过Http接口发送心跳到注册中心。在注册服务的同时会注册一个全局的客户端心跳检测任务。在服务端一段时间没有收到来自客户端的心跳后该任务会将其标记为不健康如果在间隔的时间内还未收到心跳那么该任务会将其剔除。 SDK的注册方式实际是通过RPC与注册中心保持连接客户端会定时的通过RPC连接向Nacos注册中心发送心跳保持连接的存活。如果连接中断注册中心会剔除该client所注册的服务来达到下线的效果。
永久实例健康检查机制
Nacos采用的是注册中心探测机制注册中心会在永久服务初始化时根据客户端选择的协议类型注册探活的定时任务。Nacos内置提供了三种探测的协议Http、TCP、MySQL。
集群模式下的健康检查机制
对于集群下的服务Nacos一个服务只会被Nacos集群中的一个注册中心所负责其余节点的服务信息只是集群副本用于订阅者在查询服务列表时始终可以获得全部的服务列表。临时节点只会对其被负责的注册中心节点发送心跳信息注册中心服务节点会对其负责的永久实例进行健康探测在获取到健康状态后由当前节点将健康信息同步到集群中的其他注册中心。
Nacos为什么需要一致性协议
Nacos是一个简单存储数据的组件因此为了实现这个目标就需要在Nacos内部实现数据存储。单机下问题不大简单的内嵌关系型数据库即可但是在集群模式下就要考虑如何保障各个节点之间的数据一致性以及数据同步而要解决这个问题就不得不引入共识算法来保障各个节点之间的数据一致性。
Nacos为什么选择Raft以及Distro
Nacos在单个集群中同时运行了CP协议和AP协议这个要从Nacos的应用场景出发Nacos是一个集服务注册发现以及配置管理于一体的组件因此对于集群中各个节点之间的数据一致性保障问题要从两方面考虑。
从服务注册发现来看
服务注册发现中心在当前微服务体系下是十分重要的组件服务之间感知对方服务当前可正常提供服务的实例信息必须从服务注册中心中获取因此对于服务注册中心组件的可用性提出了很高的要求。需要在任何场景下尽最大可能保证服务注册发现能力可以对外提供服务。同时Nacos的服务注册发现设计采用了心跳可自动完成服务数据的补偿机制。如果数据丢失的话可以通过该机制快速弥补数据丢失。
针对非持久化服务即需要客户端上报心跳机制进行服务实例续约强一致性的共识算法不太合适因为强一致共识算法必须保证集群中可用节点超过半数。而最终一致算法更多的是保证可用性并且能够在一定时间内各个节点之间的数据达成一致。
针对持久化服务数据是直接使用Nacos服务端的因此需要由Nacos保障数据节点之间的强一致性。
从配置管理来看
配置数据是直接在Nacos服务端进行创建并管理的必须保证大部分节点都保存了此配置数据才能任务配置被成功保存了。因此需要使用强一致性共识算法。
为什么是Raft和Distro
对于强一致性算法当前工业生产中使用最多的就是Raft协议Raft协议更容易让人理解并且有很多成熟的工业算法实现比如蚂蚁金服的JRaft、Zookeeper的ZAB、Consul的Raft、百度的braft以及Apache的RatisJRaft支持多RaftGroup为Nacos的多数据分片带来了可能。
Distro是阿里自研的一个最终一致性协议。最终一致性协议有很多例如Gossip、Eureka内的数据同步算法。而Distro是集合以上两种算法的优点并加以优化而来的。对于原生Gossip由于随机选取发送消息的节点也就不可弥漫的存在消息重复发送给同一节点的清空增加了网路的传输压力也给消息节点带来了额外的处理负担而Distro引入权威Server的概念每个节点负责一部分数据以及自己的数据同步给其他节点有效的降低消息冗余问题。
Distro协议
Distro协议是Nacos社区自研的一种AP分布式协议是面向临时实例设计的一种分步式协议其保证了某些Nacos节点宕机后整个临时实例处理系统依旧可以正常工作。作为一种有状态的中间件应用的内嵌协议Distro保证了各个Nacos节点对于海量注册请求统一协调和存储。
设计思想
Nacos每个节点是平等的都可以处理写请求同时把新数据同步到其他节点。每个节点只负责部分数据定时发送自己负责数据的校验值到其他节点来保持数据一致性。每个节点独立处理读请求及时从本机发出的响应。
工作原理
数据初始化
新加入的Distro节点会进行全量数据拉取具体操作是轮询所有的Distro节点通过向其他的机器发送请求拉取全量数据。
在全量拉取操作完成后Nacos的每台机器上都维护了当前的所有注册上来的非持久化实例数据。
数据校验
在Distro集群启动之后各台机器之间会定期的发送心跳。心跳信息主要为各个机器上的所有数据的元信息之所以是元信息是因为需要保证网络中数据传输的量级维持在一个较低的水平。这种数据校验会以心跳的形式进行即每台机器在固定的时间间隔向其他机器发起一次数据校验的请求。
一旦在数据校验过程中某台机器发现其他机器上的数据与本地数据不一致则会发起一次全量拉取请求将数据补齐。
写操作
对于一个已经启动完成的Distro集群在一次客户端发起写操作的流程中当注册非持久化的实例的写请求打到某台Nacos服务器时Distro集群的处流程
前置的Filter拦截请求并根据请求中包含的IP和Port信息计算其所属的Distro负责节点并将该请求转发到所属的Distro节点上。Distro节点上的controller将写请求进行解析。Distro协议定期执行sync任务将本机所负责的所有实例信息同步到其他节点上。
读请求
由于每台机器上都存放了全量数据因此在每次读操作中Distro机器会直接从本地拉取数据快速响应。
这种协议保证了Distro协议可以作为一种AP协议对于读操作都进行了及时的响应。在网络分区的情况下对于所有的读操作也能够正常返回当网络恢复时各个Distro节点会把各个数据分片的数据进行合并恢复。
小结
Distro协议是Nacos对于临时实例数开发的一致性协议其数据存储在缓存中并且会在启动是进行全量数据同步并定期进行数据校验。
Nacos寻址机制
Nacos支持单机部署和集群部署针对单机部署Nacos只是自己和自己进行通信对于集群模式则集群中的每个Nacos成员都需要相互通信那么应该怎么管理集群内的Nacos成员节点信息这就是Nacos内部寻址机制。
设计
无论是单机模式还是集群模式其根本区别只是Nacos成员节点的个数是单个还是多个并且能够感知到这些节点的变更情况节点是增加了还是减少了当前罪行的成员列表信息是什么怎么管理成员列表信息如何快速的支持新的、更优秀的成员列表管理模式等.
内部实现
单机寻址
单机寻址就是找到自己的IPPost组合信息然后格式化一个节点信息调用afterLookup将信息存储到ServierMemberManager中。
文件寻址
文件寻址是Nacos集群模式下默认的寻址实现。文件寻址就是每个Nacos节点需要维护一个cluster.conf的文件文件中默认填写每个成员的IP信息即可。
当Nacos节点启动时会读取该文件的内容然后将文件内的IP解析为节点列表调用afterLookup将信息存储到ServierMemberManager中。如果发现集群扩缩容那么需要修改每个Nacos节点下的cluster.conf文件然后Nacos内部的文件变动监听中心会自动发现文件修改重新读取文件内容、加载IP列表信息更新新增节点。缺点是运维成本太大。
地址服务器寻址
地址服务器寻址模式是Nacos推荐的一种集群成员节点信息管理该模式利用了简易的web服务器用于管理cluster.conf文件的内容信息这样运维只需要管理一份集群节点内容即可。而每个Nacos成员节点只需要向这个web节点定时请求当前最新的集群成员节点列表信息即可。
