微服务登记中心的当前主流具有以下四种类型：
那么如何在实际开发中选择？这是值得的 - 深度研究。不用担心。今天，陈将带您了解四种注册中心以及如何选择。
这是“ Spring Cloud Advanced”列的第四篇文章。先前的文章如下：
随着单个应用程序的分裂，第一个挑战面临的第一个挑战是服务实例的数量很大，并且服务本身的访问地址是动态的。这可能是由于服务扩展，诸如服务的因素，服务失败和更新，导致服务实例的状态经常运行，如下所示：
产品详细信息需要三个服务：营销，订单和库存。有问题：
第一个解决问题是与一个有一个伟人的伟人说一个单词。添加中间层无法解决任何问题。该中层是我们的注册中心。
解决第二个问题是实施负载平衡。这需要与我们的中间兄弟联合实现。
对于如何实现注册中心的问题，首先将服务之间的服务模型抽象。我们结合了实际情况以说明这个问题。以产品服务为例：
总体执行过程如下：
上图还具有附加的设计缓存本地路由。缓存本地路线是提高服务路线的效率和容错性。服务消费者可以装备缓存机制来加速服务路由。更重要的是，当无法使用服务注册中心时，消费者可以使用本地缓存路由来实现现有服务的可靠呼叫。
在整个执行过程中，其中之一有点困难，也就是说，如何及时为消费者服务服务生产者如何在时间上变化。这个问题也是经典生产者的问题。有两种解决方法的方法
对于如何选择这两种方法，实际上存在一个数据一致性问题。例如，选择计时器必须放弃一致性。最重要的是最终的一致性。这些删除功能等。我认为，这只是一个附加功能。注册中心的重点是服务注册和发现仍在蛋糕上锦上添花。
有两种实现负载平衡的方法：
服务提供商的服务器的负载平衡更加强大，但是它无法满足不同消费者使用不同负载平衡策略的需求。
客户的负载平衡提供了这种灵活性，并为用户扩展提供了更友好的支持。但是，如果未正确配置客户端负载平衡策略，它可能会导致服务提供商中的热点，或者您无法获得任何服务提供商全部。
串行负载平衡的代表为NGINX。客户负载平衡的典型代表是色带。每种方法都有一个经典的代表。我们可以学习 - 深度学习。
为了实现共同负载平衡器的算法，共同算法是以下六个：
1.查询方法
该请求按顺序分配给后端服务器，并且在后端平衡的每个服务器都对每个服务器进行处理，而不必担心服务器的实际连接数和当前系统负载。
2.随机方法
通过系统的随机算法，可以选择其中一台服务器根据后端服务器的列表大小值访问。从概率统计理论，可以知道，随着客户端呼叫的数量增加，服务器；实际效果是从平均分配调用到后端的每个服务器越来越近，即旋转查询的结果。
3.哈希算法
哈希思想基于客户端的IP地址，由哈希函数获得的值，服务器列表的大小用于使用服务器列表的大小。结果是访问服务器的客户服务的序列号。源地址哈希方法用于负载平衡。具有相同IP地址的客户端。当后端服务器列表保持不变时，每次访问将映射到同一背面服务器。
4.加权旋转法
不同背部端服务器的配置可能与当前系统的负载不同，因此它们的压力电阻不同。具有高配置和低负载配置的机器，以便他们可以处理更多；当配置低和高负载的机器分配较低的重量，减少其系统负载以及加权旋转查询可能是对此问题的很好处理，并分配请求订单并根据符合该问题的方式分配给后端重量。
5.加权随机方法
像加权旋转方法一样，加权随机方法还根据背面机器的配置分配不同的权重。区别在于，它根据权重随机请求后端服务器。
6.最小连接编号方法
连接算法的最小数量相对灵活且智能。由于后端服务器的配置是不同的，因此请求处理是快速或缓慢的。它基于后端服务器的当前连接。台湾服务器处理当前请求，尽可能提高后端服务的效率，并负责为每个服务器的合理转移。
注册中心的选择也是多种多样的。在此阶段，此阶段有更多的知名度：
在引入此内容之前，这里需要了解的一些知识是CAP，PAXOS和RAFT算法。我不会在这里介绍太多。开始介绍上述五种实施注册中心的方法。
这有点有趣的是，这位官员没有说他是一个注册中心，但是许多国内的Dubbo场景都使用Zookeeper来完成注册中心的功能。
当然，有许多历史原因。在这里，我们不会在这里追踪它。我仍然来谈论Zookeeper的表现被用作注册中心。
Zookeeper基本概念1，三个字符
领导者角色：同时一个动物园管理员群集只有一项实际工作，它将通过每个follwork和观察者来启动和维护心跳。所有写作操作必须通过领导者完成，然后由领导者到其他服务器。
追随者角色：Zookeeper群集可能同时具有多个追随者，这对领导者的心跳做出了反应。Frolower可以直接处理并返回客户的阅读请求。同时，它将将写作请求转发给领导者进行处理，并在处理请求时负责投票。
观察者角色：类似于追随者，但没有投票权。
2.四个节点
持续持续的节点：除非手动删除，否则该节点始终存在于Zookeeper上
短期时间节点：临时节点的生命周期与客户端会话结合。客户端会话失败后，将删除该客户端创建的所有临时节点。
persistent_ questential特定顺序节点：基本特征与持久节点相同，但是添加了顺序属性。在节点名称之后，将添加由父节点维护的自我插入整数。
ephemeral_ sequententiment-sequarary序列节点：基本特征与临时节点相同，添加顺序属性。在节点名称之后，将添加由父节点维护的自我进攻和整数。
3.一种机制
Zookeeper的手表机制是一种轻巧的设计。因为它使用了推动-pull -pull binding的模型，一旦服务器side感知主题改变了，然后将仅发送一个事件类型和节点信息，将注意到并注意关注和关注的客户它将不包括特定的更改，因此事件本身是轻量级的，这是推动的一部分。这是拉力部分。
如何实现动物园管理员的注册中心？简而言之，Zookeeper可以充当服务注册表，允许多个服务提供商组成集群，使消费者能够通过服务注册表（IP+端口）获得特定的服务访问地址（IP+端口）.GO访问特定的服务提供商。如下所示：
每当部署服务提供商时，您都必须将服务注册到Zookeeeper的某个路径：/{service}/{version}/{ip：port}。
例如，我们的helloworldservice被部署到两台机器上，然后将在Zookeeper上创建两个目录：
此描述很难理解，下面的图片更直观，
在Zookeeper中，服务注册实际上是在Zookeeper中创建的，以创建一个Znode节点，该节点存储了服务的IP，端口，呼叫方法（协议，序列化方法）。
该节点承担最重要的责任。它是由服务提供商（发布服务时）创建的，供服务消费者在节点中获取信息，以便将服务提供商的真实IP定位并启动呼叫。通过IP设置临时节点，然后节点数据将不存储在Zookeeper服务器上。
当客户端会话创建的临时节点由于加班或异常而关闭时，该节点也相应地在Zookeeper服务器上删除。当排除或在线时，将触发Zookeeeper的手表机制，并将消息发送给消费者。因此，及时更新消费者信息。
从Zookeeper的设计来看，CP的原理随后随时都可以得出相同的数据结果。同时，系统对网络分区具有容错性。集群中的领导者降低，群集将由领导者选举，或者不可用Zookeeper群集中的一半以上的服务器节点（用于例如，有三个节点。如果节点1检测节点三个，则节点两个也检测到节点。三个挂起，然后该节点确实被悬挂），因此它将无法处理请求。
因此，Zookeeper不能保证服务可用性。
我认为Netflix应该酿造更好的东西。下面我们着重于引入Ereka 1.X相关设计。
Eureka由两个组件组成：Eureka Server和Eureka Client.eureka Server用作服务注册服务器。EUREKA客户端是一个Java客户端，用于简化与服务器的交互，用作旋转负载balanner，并提供服务服务，并提供服务服务。故障切换支持。
尤里卡的基本体系结构由3个字符组成：1。尤里卡服务器
提供服务注册和发现功能；
2.服务提供商服务提供商，向Eureka注册自己的服务，以便服务消费者找到；
3.服务消费服务消费者，从Eureka获取注册服务列表，以便能够消费服务
尤里卡（Eureka）在设计时遵循AP原理。尤里卡服务器可以运行多个实例来构建群集并解决单点问题。实例相互注册以提高可用性。对于每个示例，每个实例相等，并且每个节点都可以视为其他节点的副本。
在集群环境中，如果某个Eureka服务器的不利方面，Eureka客户端的请求将自动切换到新的Eureka服务器节点。恢复市区服务器后，Eureka将再次将其整合到服务器群集管理中。
当节点开始接受客户端请求时，所有操作将在节点之间复制，并将请求复制到Eureka Server当前知道的所有其他节点。
当新的Eureka服务器节点启动时，它将首先尝试从相邻节点获取所有注册列表信息并完成初始化。EUREKASERVER通过geteurekasekaseviceurls（）方法获得所有节点，并将通过心脏饮食合同定期更新。
默认情况下，如果Eureka Server在一定时间段内没有收到服务实例的心跳（默认周期为30秒），则Eureka Server将取消该实例（默认为90秒，eureka.instance.instance. lease-Expiation。- 自定义配置的秒内）。
当Eureka服务器节点在短时间内失去过多的心跳时，该节点将进入自我保护模式，并且在此测试环境时需要注意。
在尤里卡（Eureka）的群集中，只要有尤里卡（Eureka）仍然可以使用，但是发现的信息可能不是最新的（不能保证的一致性）。
此外，尤里卡还具有自我保护机制。如果15分钟内超过85％的节点没有正常的心跳，尤里卡（Eureka）认为客户和注册中心会有网络故障。在这个时间内：
NACO无缝支持一些主流开源生态学，如下所示：
NACOS致力于帮助您发现，配置和管理微服务。NACOS提供了一组简单易用的功能集，以帮助您快速实现动态服务发现，服务配置，服务元数据和流量管理。
NACOS可帮助您更加敏捷，更容易地构建，交付和管理微服务平台。Nacos是以“服务”为中心的现代应用程序架构的服务基础架构（例如微服务，Yunyuan悬挂）。
除了NACOS的注册外，NACOS还支持动态配置服务。DYNAMIC配置服务允许您以集中式，外部和动态的方式管理所有环境的应用程序配置和服务配置。动态配置消除了需要重新研究的需求当配置更改时，应用程序和服务，以使配置管理变得更加高效和敏捷。配置集中管理使得更容易实现无状态服务，从而使服务更容易扩展按需需求弹性。
NACOS功能服务发现和服务健康监测
NACOS支持DNS和基于RPC的服务。服务提供商使用本机SDK，OpenAPI或独立的代理TODO注册服务后，服务消费者可以使用DNS TODO或HTTP＆API查找和发现服务。
NACO提供有关服务的真实健康检查，以防止不健康的主机或服务示例请求。NACOS支持传输层（PING或TCP）和应用层（例如HTTP，MySQL，用户 - 用户定义）的健康检查。NACOS在复杂的云环境和网络拓扑（例如VPC，Edge Networks等）中提供服务的健康检查。帮助您根据健康状况管理服务的可用性和流量。
动态配置服务
动态配置服务允许您以集中式，外部和动态的方式管理所有环境的应用程序配置和服务配置。
当配置更改时，动态配置消除了重新删除应用程序和服务的需求，因此配置管理变得更加有效和敏捷。
配置集中管理使得实现无状态服务变得更加容易，使服务更容易按需弹性扩展。
NACOS提供了一个简单易用的UI（控制台样品演示）来帮助您管理所有服务和应用程序。NACOS还提供一系列配置管理特征，包括配置版本跟踪，Golden Bird的发布，其中一个 -单击“回滚配置”和客户端配置更新状态跟踪状态，该状态可帮助您在生产环境中更安全地管理生产环境中的配置，并降低配置更改带来的风险。
动态DNS服务
动态DNS服务支持重量路由，使您更易于实现中间负载平衡，更灵活的路由策略，流量控制和数据中心的简单DNS分析服务。DYNAMICDNS服务也可以使您更容易实现基于服务的服务。关于DNS协议，可以帮助您消除与制造商的私人服务耦合以发现API的风险。
NACOS提供了一些简单的DNS API TODO，以帮助您管理关联的域名和可用IP：端口列表。
服务和元数据管理
NACOS允许您所有服务和元数据从微服务平台构建的角度管理数据中心，包括对管理服务的描述，生命周期，服务的静态依赖分析，服务的健康状态，交通管理，交通管理，路线和安全策略，服务，路线和安全策略，SLA和最重要的指标统计数据。
NACOS支持插件管理
关于NACOS数据的存储，支持临时支持和持久性。
关于设计，支持CP还支持APS。这只是他的命令开关。在您玩游戏的情况下，它还支持各种注册中心迁移到NACOS。无论如何，只要您想要它，他就有它。
领事是Hashicorp启动的开源工具。领事是通过Go语言开发的。它很容易部署。它只需要很少的可执行过程和配置文件，这些文件是绿色和轻量级的。Consul是分布式，高度可用的服务发现和配置的分布式系统的水平扩展。
领事的功能服务发现（服务发现）
领事通过DNS或HTTP接口提供注册和发现服务。一些外部服务可以轻松找到通过领事依赖的服务。
健康检查
领事的客户端可以提供任何数量的健康检查点，这些检查点可以与给定服务（“ WebServer返回200 OK”）或本地节点（“内存利用率率是小于90％”）。操作员可以使用此信息来监视集群的健康状况。服务找到的组件可以使用此信息从不健康的托管中获取流量。
钥匙/值存储
应用程序可以根据您的需求使用领事提供的密钥/值来存储。Consul提供了一个简单简便的HTTP接口，并结合其他工具，与其他工具相结合，以实现动态配置，功能标记，领导力选举和其他功能。
安全服务通信
领事可以生成和分发服务生成和分配以建立相互tls连接的TLS证书。可以使用Intertent来定义服务通信允许的允许。服务细分可以轻松管理，其目的是实时更改它，而不是实时更改它使用复杂的网络拓扑和静态防火墙规则。
多塔中心
领事支持用于打开盒子的大型数据中心。这意味着用户不必担心建立额外的抽象层以将其业务扩展到多个领域。
领事支持许多数据中心。上图中有两个数据中心。它们通过互联网互连。同时，请注意，为了提高沟通效率，只有服务器节点添加了交叉数据中心。
在单个数据中心中，领事分为客户端和服务器的两个节点（所有节点也称为代理），服务器节点保存数据，客户端负责健康检查并将数据请求重新发布到服务器；服务器节点具有一个领导者和多个多频场，Leader节点将将数据同步到跟随器。建议使用3或5的服务器数量。当领导者挂起时，它将启动选举机制以生成新的领导者。
集群中的领事节点通过八卦协议（谣言协议）维持成员之间的关系，也就是说，一个节点可以理解群集中的哪些节点。这些节点是客户端或服务器。单个数据中心的谣言同时使用TCP和UDP通信，并且所有人都使用端口8301。交叉数据中心的谣言还使用TCP和UDP同时进行通信，并且该端口使用8302。
群集中数据的读取请求可以直接发送到服务器，也可以通过客户端将其重新发布到服务器。该请求最终将到达领导节点。当允许数据延迟时，也可以在普通服务器节点上完成读取请求，以完成集群中数据的读取和写入数据，可以通过TCP的8300端口完成。
领事实际上可以在应用程序中注册，然后使用Spring Cloud家族桶进行负载。
让我们在这里谈论领事申请的注册：
上图上方还有两个组件，即注册员和领事测试。接下来，我们将介绍如何在服务发现和注册的应用中实现这两个组件。
注册人：开源第三党服务管理器项目，该项目负责通过听力服务部署的Docker实例的生存来注册和破坏服务提供商。
领事模板：获取最新的服务提供商节点列表，并从注册的中心服务器中刷新LB配置（例如NGINX上游），以便服务消费者可以通过访问NGINX并实现动态调整负载负载负载负载量的目的来获得最新的服务提供商信息。
整体架构可能是这样的：
我们使用注册人来监视每个服务器的状态。当新服务器启动时，注册人将其注册到领事注册中心。
由于领事模板已订阅了注册中心的服务新闻，此时领事注册中心将将新服务器信息推向领事模板，领事模板将修改NGINX.conf的配置文件，然后让Nginx加载配置再次在配置中实现自动修改负载平衡的目的。
Kubernetes是一个轻巧且可扩展的开源平台，用于管理集装箱应用程序和服务。可以应用通过Kubernetes应用的Automated部署和扩展能力。
在Kubernetes中，将应用程序形成逻辑单元的容器将合并为更容易的管理和发现。Kubernetes积累了15年的经验，可以作为Google运行生产环境，并吸收社区的最佳想法和实践。
近年来，Kubernetes通过快速发展形成了一个庞大的生态环境。Google在2014年使用Kubernetes作为开源项目。Kubernetes的主要特征包括：
Kubernetes属于主要分布架构，主要由主节点和Worker节点组成，Kubectl以及其他其他项目在内，包括客户端命令行工具。
主节点：作为控制节点，群集已被安排和管理。主人主要由三个部分组成：
工人节点：作为一个真正的工作节点，运行业务应用程序的容器；工人节点主要包含五个部分：
这些开源产品已经考虑了如何建立高可用群集，这是一些差异。
对于服务发现，对于相同的服务，即使保存在注册中心的不同节点中的信息不同，也不会引起灾难性后果。
但是，对于消费者而言，如果由于注册中心的异常而无法正常进行消费，则该系统对系统造成了灾难性的灾难。因此，我认为注册中心应注意可用性，而不是一致，因此我选择了AP。
对于语言，我们都是Java技术堆栈。从这一点开始，我们更倾向于Eureka和Nacos。
如果公司内部有特殊的中间件或操作和维护团队，则可以领事和Kubernetes。毕竟，Kubernetes是未来。我们追求的是在框架中解决这些问题。不涉及应用程序中的业务发展。
应用程序中的解决方案通常适用于服务提供商，消费者属于同一技术系统。应用程序以外的解决方案通常适合服务提供商和服务消费者采用不同技术系统的业务场景。
关于尤里卡（Eureka）和NACOS如何选择，此选择更容易做到。我选择这使我做得更少，显然NACOS帮助我们做了更多。
这些开源产品总体上更为活跃
公共号码：代码猿技术专栏