网络优化seo薪酬,semseo名词解释,河北保定网站建设,jsp网站开发实例.百度网盘前言
服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务#xff0c;原则上都应存在或者支持多个提供者#xff0c;这是由微服务的分布式属性决定的。更进一步#xff0c;为了支持弹性扩缩容特性#xff0c;一个微服务的提供者的数量和分布往往是动…前言
服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务原则上都应存在或者支持多个提供者这是由微服务的分布式属性决定的。更进一步为了支持弹性扩缩容特性一个微服务的提供者的数量和分布往往是动态变化的也是无法预先确定的。因此原本在单体应用阶段常用的静态LB机制就不再适用了需要引入额外的组件来管理微服务提供者的注册与发现而这个组件就是服务注册中心。
CAP理论
CAP理论是分布式架构中重要理论 一致性(Consistency) (所有节点在同一时间具有相同的数据)可用性(Availability) (保证每个请求不管成功或者失败都有响应)分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)关于P的理解我觉得是在整个系统中某个部分挂掉了或者宕机了并不影响整个系统的运作或者说使用而可用性是某个系统的某个节点挂了但是并不影响系统的接受或者发出请求CAP 不可能都取只能取其中2个原因是如果C是第一需求的话那么会影响A的性能因为要数据同步不然请求结果会有差异但是数据同步会消耗时间期间可用性就会降低。
如果A是第一需求那么只要有一个服务在就能正常接受请求但是对与返回结果变不能保证原因是在分布式部署的时候数据一致的过程不可能想切线路那么快。
再如果同事满足一致性和可用性那么分区容错就很难保证了也就是单点也是分布式的基本核心好了明白这些理论就可以在相应的场景选取服务注册与发现了。 服务注册中心解决方案
设计或者选型一个服务注册中心首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案大致可归为三类 应用内直接集成到应用中依赖于应用自身完成服务的注册与发现最典型的是Netflix提供的Eureka 应用外把应用当成黑盒通过应用外的某种机制将服务注册到注册中心最小化对应用的侵入性比如Airbnb的SmartStackHashiCorp的Consul DNS将服务注册为DNS的SRV记录严格来说是一种特殊的应用外注册方式SkyDNS是其中的代表
注1对于第一类注册方式除了Eureka这种一站式解决方案还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制这在大公司比较常见但对于小公司而言显然性价比太低。
注2由于DNS固有的缓存缺陷本文不对第三类注册方式作深入探讨。
除了基本的服务注册与发现机制从开发和运维角度至少还要考虑如下五个方面 测活服务注册之后如何对服务进行测活以保证服务的可用性 负载均衡当存在多个服务提供者时如何均衡各个提供者的负载 集成在服务提供端或者调用端如何集成注册中心 运行时依赖引入注册中心之后对应用的运行时环境有何影响 可用性如何保证注册中心本身的可用性特别是消除单点故障 主流注册中心产品 软件产品特性并非一成不变如果发现功能特性有变更欢迎评论指正 NacosEurekaConsulCoreDNSZookeeper一致性协议CPAPAPCP—CP健康检查TCP/HTTP/MYSQL/Client BeatClient BeatTCP/HTTP/gRPC/Cmd—Keep Alive负载均衡策略权重/ metadata/SelectorRibbonFabioRoundRobin—雪崩保护有有无无无自动注销实例支持支持支持不支持支持访问协议HTTP/DNSHTTPHTTP/DNSDNSTCP监听支持支持支持支持不支持支持多数据中心支持支持支持不支持不支持跨注册中心同步支持不支持支持不支持不支持SpringCloud集成支持支持支持不支持支持Dubbo集成支持不支持支持不支持支持K8S集成支持不支持支持支持不支持Consul是支持自动注销服务实例 请见文档 https://www.consul.io/api-docs/agent/service在check的 DeregisterCriticalServiceAfter 这个参数-- 感谢超帅的菜鸟博主提供最新信息新版本的Dubbo也扩展了对 Consul 的支持。 参考: https://github.com/apache/dubbo/tree/master/dubbo-registryApache Zookeeper - CP 与 Eureka 有所不同Apache Zookeeper 在设计时就紧遵CP原则即任何时候对 Zookeeper 的访问请求能得到一致的数据结果同时系统对网络分割具备容错性但是 Zookeeper 不能保证每次服务请求都是可达的。
从 Zookeeper 的实际应用情况来看在使用 Zookeeper 获取服务列表时如果此时的 Zookeeper 集群中的 Leader 宕机了该集群就要进行 Leader 的选举又或者 Zookeeper 集群中半数以上服务器节点不可用例如有三个节点如果节点一检测到节点三挂了 节点二也检测到节点三挂了那这个节点才算是真的挂了那么将无法处理该请求。所以说Zookeeper 不能保证服务可用性。 当然在大多数分布式环境中尤其是涉及到数据存储的场景数据一致性应该是首先被保证的这也是 Zookeeper 设计紧遵CP原则的另一个原因。
但是对于服务发现来说情况就不太一样了针对同一个服务即使注册中心的不同节点保存的服务提供者信息不尽相同也并不会造成灾难性的后果。
因为对于服务消费者来说能消费才是最重要的消费者虽然拿到可能不正确的服务实例信息后尝试消费一下也要胜过因为无法获取实例信息而不去消费导致系统异常要好淘宝的双十一京东的618就是紧遵AP的最好参照。
当master节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举。问题在于选举leader的时间太长30~120s而且选举期间整个zk集群都是不可用的这就导致在选举期间注册服务瘫痪。
在云部署环境下 因为网络问题使得zk集群失去master节点是大概率事件虽然服务能最终恢复但是漫长的选举事件导致注册长期不可用是不能容忍的。 Spring Cloud Eureka - AP Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则尽管现在2.0发布了但是由于其闭源的原因 但是目前 Ereka 1.x 任然是比较活跃的。
Eureka Server 也可以运行多个实例来构建集群解决单点问题但不同于 ZooKeeper 的选举 leader 的过程Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构无 master/slave 之分每一个 Peer 都是对等的。在这种架构风格中节点通过彼此互相注册来提高可用性每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。 在集群环境中如果某台 Eureka Server 宕机Eureka Client 的请求会自动切换到新的 Eureka Server 节点上当宕机的服务器重新恢复后Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时所有的操作都会在节点间进行复制replicate To Peer操作将请求复制到该 Eureka Server 当前所知的其它所有节点中。
Consul
Consul 是 HashiCorp 公司推出的开源工具用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写因此具有天然可移植性支持Linux、windows和Mac OS X。
Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案不再需要依赖其他工具比如 ZooKeeper 等使用起来也较为简单。
Consul 遵循CAP原理中的CP原则保证了强一致性和分区容错性且使用的是Raft算法比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性但是可用性就相应下降了例如服务注册的时间会稍长一些因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 在leader挂掉了之后重新选举出leader之前会导致Consul 服务不可用。 默认依赖于SDKConsul本质上属于应用外的注册方式但可以通过SDK简化注册流程。而服务发现恰好相反默认依赖于SDK但可以通过Consul Template下文会提到去除SDK依赖。 Consul TemplateConsul Template
Consul默认服务调用者需要依赖Consul SDK来发现服务这就无法保证对应用的零侵入性。
所幸通过Consul Template可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置比如nginx的upstream这样对于服务调用者而言只需要配置一个统一的服务调用地址即可。 Consul强一致性(C)带来的是
服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功Leader挂掉时重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性
服务注册相对要快因为不需要等注册信息replicate到其他节点也不保证注册信息是否replicate成功当数据出现不一致时虽然A, B上的注册信息不完全相同但每个Eureka节点依然能够正常对外提供服务这会出现查询服务信息时如果请求A查不到但请求B就能查到。如此保证了可用性但牺牲了一致性。
其他方面eureka就是个servlet程序跑在servlet容器中; Consul则是go编写而成。
Nacos
Nacos是阿里开源的Nacos 支持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使用Nacos只需要先下载 Nacos 并启动 Nacos serverNacos只需要简单的配置就可以完成服务的注册发现。
Nacos除了服务的注册发现之外还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单让服务按需弹性扩展变得更容易。
一句话概括就是Nacos Spring Cloud注册中心 Spring Cloud配置中心。
参考链接
主流微服务注册中心浅析和对比-阿里云开发者社区
https://nacos.io --------------------- 作者琦彦 来源CSDN 原文https://glory.blog.csdn.net/article/details/100023415 版权声明本文为作者原创文章转载请附上博文链接 内容解析ByCSDN,CNBLOG博客文章一键转载插件
