广西网站设计运营公司,删除wordpress所以评论,c苏宁网站开发,网站建设都有什么栏目“灵魂拷问分布式系统为什么需要注册中心呢#xff1f;分布式系统注册中心有哪些坑#xff1f;分布式系统注册中心怎么来实现呢#xff1f;注册中心利用现成的组件很好实现吗#xff1f;看到标题你可能会鄙视一下#xff0c;注册中心有是什么讲的。注册中心作为现在架构中… “灵魂拷问分布式系统为什么需要注册中心呢分布式系统注册中心有哪些坑分布式系统注册中心怎么来实现呢注册中心利用现成的组件很好实现吗看到标题你可能会鄙视一下注册中心有是什么讲的。注册中心作为现在架构中的一个组件来说确实很常见。微服务作为分布式系统最典型的一种表现形式是最近几年最流行的概念之一。每个讲微服务的文章中或多或少都会提及注册中心但也只是一带而过注册中心作为分布式系统或者微服务架构中最重要的一环我觉得有必要写一篇单独的文章来详细的介绍一下这也是有这篇文章的原因。分布式系统的痛点注册中心从架构的角度来讲其实是一个统称的概念并非现在流行的微服务所有在很早之前利用Nginx做负载均衡反向代理的时候Nginx会根据配置文件把每个请求根据配置的策略导向后端具体的处理程序在这个流程中站在客户端角度Nginx很像一个网关站在后端处理程序的角度Nginx更像是服务的管理中心它管理着所有可以提供服务的后端处理程序信息并且还可以利用某些手段来达到服务的健康检查服务的自动注册和剔除等操作。当然现在流行微服务网关和注册中心被分为两个并行的概念和组件。在重要性上来说我觉得注册中心的权重要大于网关。现在十分流行单体服务拆分操作但是这里我要强调一点你的单体服务是否有必要拆分还要根据很多情况来综合考虑毕竟拆分成小的微服务并非没有代价。在很早之前如果客户端需要请求后端的多个服务很多情况下后端的服务信息是写在请求方的配置文件中的类似于这样{ServiceA:[http://192.168.100.100,http://192.168.100.101,http://192.168.100.102]
}
这种方式固然是一种解决方案但是随着系统的不断升级会遇到很多问题在系统需要扩容后端服务器的时候需要手动修改客户端的配置文件而且在多数情况下还需要重启客户端进程当后端的一个服务节点出现故障的时候需要手动删除客户端配置文件中对应的节点而且在多数情况下还需要重启客户端进程每次增加或者删除节点的时候需要人工干预大大提高了维护成本鉴于以上几个原因注册中心应运而生。注册中心的作用注册中心不仅仅解决了服务节点的增加删除问题而且在整个的查找服务可用节点的流程上做了修改在搭配了服务健康检查的手段之后更可以做到自动化。目前业界有很多可供选择的注册中心比如ZooKeeperETCD阿里的微服务注册中心 Nacos、Spring Cloud 的 Eureka 等等之前菜菜的文章就有写过利用ETCD来实现一个配置中心为微服务撸一个简约而不简单的配置中心服务注册发现服务的注册发现是注册中心提供的最基础也是最主要的功能当一个新的服务节点上线的时候可以通过注册中心的接口进行注册当一个服务节点发生故障的时候注册中心会自动删除该服务节点当注册中心的服务节点发生变化的时候能够及时通知调用方服务的调用方可以近乎实时的来更新可用的服务节点信息image负载均衡当客户端在注册中心获取到可用的服务节点之后就可以根据轮训或者权重等策略来访问服务了这种场景下注册中心更像一个负载均衡器把流量导向多个不同的节点。既然是负载均衡在某种意义上讲就可以实现服务的横向扩展说实话这确实没有什么问题道理和Nginx做负载均衡道理类似。那些坑服务中心虽然在整体架构模式上解决了很多问题但是在使用中我们也要直面它所带来的一些副作用而且这些副作用有时候会成为整个系统瘫痪的导火线。数据一致性问题数据的一致性好像是所有系统都要面对的问题注册中心也不例外。这里的一致性是指注册中心内存储的可用节点数据和后端真实可用节点以及客户端存储的可用节点之间的差异性问题。举个栗子假如注册中心中存储了ABC三个服务节点信息而这个时候节点A由于某种原因下线了注册中心必须要及时把A节点移除掉并且通知客户端也把A节点移除。从理论上来讲以上过程跨越了注册中心和调用方以及被调用方的交互流程属于分布式中的事务问题即分布式事务问题。在之前菜菜的文章中也说过分布式的事务要想保证严格的一致性必然会影响可用性分布式下我想要一致性那些分布式事务解决方案而且从目前主流的注册中心技术来看注册中心和双方的通信流程属于异步流程所以做不到实时的事务性要求。目前注册中心在通知客户端变化的方面可以做到近乎于实时其实并非实时但是在监测后端服务节点是否可用的过程中却很难做到近乎实时。其中的原因一是因为网络的不可靠特性一次网络通信失败并非意味着下次网络通信失败二是监测后端服务可用的方式并非实时的。目前流行的两种探测后端服务可用的方式为注册中心主动探测很多注册中心的组件都支持这种方式在这种方式下后端的每个服务需要提供一个可供探测的接口或者端口注册中心根据配置每隔一段时间去调用一次服务的接口或端口如果返回正常就认为服务处于正常运行状态否则则认为服务不可用不可用的情况下注册中心会主动把当前服务移除列表并通知客户端。虽然这种方式看似很完美其实还是有坑注册中心在探测的过程中可能会由于网络问题而出错但是服务其实是在正常运行状态也就是说会产生误判的结果当然这种问题我们可以设置通过多次探测结果来确定而不是通过一次探测结果就草草确定。如果服务节点比较多注册中心相当于承受了比较重的探测任务会对注册中心的性能造成一定损失影响它的可用性。如果服务是以端口的形式开放探测接口在服务较多的情况下可能会产生端口抢占的情况毕竟这些服务可能会是不同团队开发的。后端服务主动心跳相比较注册中心主动探测的模式我更喜欢使用服务主动上报心跳的模式。采用心跳的模式大体流程是这样的后端的每个服务节点都按照配置这个配置可以修改每隔固定时间就主动向注册中心发送心跳包至于心跳包的内容可以协商约定比如有的系统只发送ping命令有的会发送比较详细的服务状态比如cpu使用率内存使用率等信息然后注册中心就可以根据这些信息来做更精确的流量分配工作比如可以让资源充沛的服务节点承担更多的流量。注册中心在接收到服务节点的心跳包之后可以以滑动窗口的形式给服务节点续约时间存活时间只要服务节点不停的发送心跳包注册中心就可以判定这个节点一直在正常运行。image当然这个流程中也会有意外情况发生比如由于网络情况某个服务节点上报心跳失败但是服务是在正常运行的这种场景下最直接的解决方案是注册中心判断服务存活的时间窗口大于上报时间间隔即可比如心跳上报时间是10秒的话注册中心判定服务不可用的时间窗口设置为30秒既三次心跳时间都没有上报心跳就判定服务不可用。当然以上只是注册中心的一个假设而已其实系统可以结合主动探测的方式来判定服务是否可用这样的话结果的正确率会更高。也就是说当服务的某个节点超过配置的N次心跳时间仍然没有上报心跳数据注册中心可以通过主动探测的方式来再次确定服务是否处于正常运行状态当然这在设计上增加了一定的复杂度需要编写更多的代码。还有一个不太常见的但是我们需要考虑的场景假如所有的服务节点都因为网络异常情况而发生心跳上报超时而且主动探测失败的情况按照约定注册中心会逐步移除所有的节点信息这样造成的后果是系统肯定会出问题有的时候系统设计的同时可以考虑一些保护措施比如当节点信息移除的数目大于一定比率的时候就停止移除操作并且发送报警信息这在一定程度上可以避免注册中心无节点数据的情况发生当然客户端也可以有这样的保护策略。通知风暴虽然这个问题在多数情况下不算是个问题但是还是有必要提及一下。当注册中心随着项目的升级承担起越来越多的服务节点的时候服务间的调用链复杂度也随之上升伴随而来的是新增一个节点可能要通知数十个客户端移除一个节点也会有类似情况发生如果有多个服务同时发生新增或移除节点操作注册中心推送的消息将会更多。这样的场景下就需要系统设计者控制注册中心服务节点的数量来避免产生网络风暴这个数量具体多少可以根据服务器的峰值带宽来确定。更多精彩文章????分布式大并发系列????架构设计系列????趣学算法和数据结构系列????设计模式系列
