以下文章来自:微信微信官方账号作者:笑架构师在微服务架构或者分布式环境中，服务注册和发现技术是必不可少的，这也是程序员在进阶路上必须掌握的核心技术之一。这篇文章将通过举例的方式引导你容易地掌握它。 引入服务注册和发现组件的原因首先看一个问题。如果我们现在要做一个商城项目，作为架构师的你应该如何设计系统架构？你一定在想:直接照搬淘宝的架构不容易。 然而，在现实的创业环境中，一个项目可能是九死一生。如果一开始就投入巨大的人力和财力，一旦项目失败，损失会很大。 作为一个有经验的架构师，根据公司的财力、人力、预算等现状，选择最合适的架构才是王道。 大型网站都是由小型网站发展而来，架构也是如此。 任何一个大型网站的架构都不是一开始就千篇一律的，而是随着客户数量和数据的不断增加而不断迭代进化的结果。 在架构迭代进化的过程中，我们会遇到很多问题。技术发展的本质是不断发现问题然后处理问题，处理问题发现问题。 单体架构在系统建立之初可能没有多少客户。所有业务都被捆绑到一个应用程序包中，并在tomcat容器中运行，与数据库共享一个服务器。这种架构一般称为单体架构。 整体架构——应用程序和数据库在初始阶段共同部署。这个架构效率很高，可以根据客户反馈快速在线迭代。 但是随着客户的增加，一个服务的内存和CPU紧张，很容易造成瓶颈。如何处理新问题？与应用数据分离随着客户请求的增加，一台服务器的内存和CPU持续飙升，客户请求的响应时间变慢。 这时候可以考虑把应用和数据库分开，分别使用一个服务器。你可以看到问题又被处理了。 单体架构——应用与数据库分离突然有一天，扫地阿姨不小心碰到了电线，其中一台服务器断电，客户的所有请求都报错，随之而来的是一连串的投诉电话。 部署集群的单个实例很容易导致单点问题，比如服务器故障或服务器服务能力的瓶颈。我们做什么呢聪明的你一定想到了。使用集群。 集群部署集群部署是指将应用部署在多个服务器或虚拟机上，客户通过服务均衡随机访问一个实例，从而均衡多个实例的流量。如果一个实例出现故障，它可以脱机，其他实例仍然可以向外界提供服务而不受影响。 随着客户数量的快速增加，老板决定增加投资，扩大团队规模。 团队发展后，效率并没有明显提高。以前小团队一周可以在线迭代一次，现在至少要两到三周。 业务逻辑越来越复杂，代码之间的耦合非常严重。修改一行代码可能会带来几个在线问题。 架构师意识到了架构重构的必要性。 微服务架构:当单一架构进化到肯定阶段，开发和测试的复杂度会增加成本，团队规模的扩大也会使各自工作的耦合性更加严重。情况就是这样。 当单一架构遇到瓶颈，微服务架构就诞生了。 微服务就是将之前的单一服务按照业务维度进行拆分。拆分的粒度可大可小，拆分的时机可分节奏。 最好的做法是先从单体中分离出少量独立的功能，提取到一个或多个微服务中，这样可以保证业务的连续性和稳定性。 如上图所示，微服务架构将一个商业应用拆分为六个独立的微服务。 使用Docker容器化，可以在多个实例中部署六个微服务。 架构在这里遇到了一个难题。如果要查询所有客户的订单，客服可能会依赖订单服务。客服如何与订单服务互动？该服务有多个实例。我应该访问哪一个？通常有几种处理方式:(1)硬编码服务地址。服务的地址写在数据库或服务器配置文件中，通过访问DNS域名来路由地址。 服务元数据硬编码服务B的地址是在数据库或服务器配置文件中硬编码的。服务A首先需要获得服务B的地址，然后通过DNS服务器分析获得一个实例的真实地址。最后，它可以向服务b发出请求。 如果遇到大促活动需要扩展服务实例，大促结束后服务实例需要下线，运维人员要做大量的人工操作，非常容易出现误操作。 (2)服务的动态注册和服务地址的硬编码还有一个非常致命的问题。如果一个实例挂起，运维人员可能无法及时感知，导致部分客户请求异常。 服务注册和发现组件的引入可以很好地解决上述问题，避免过多的人工操作。 架构概述在单一架构中，一个应用就是一个服务包，包中的模块通过函数方法相互调用。模型足够简单，根本不存在服务注册和发现这样的事情。 在微服务架构中，一个应用会被拆分成多个微服务，微服务会部署在不同的服务器、不同的容器，甚至多个数据中心。微服务之间会相互调用，因此服务注册和发现成为不可或缺的组件。 服务注册和发现的基本原则服务注册和发现是两个关键步骤:注册和发现。 注册:服务进程在注册中心注册自己的元数据信息。 它通常包括主机和端口号，有时还包括身份验证信息、协议、版本号和运行环境信息。 服务发现:客户端服务进程向注册中心发起查询以获取服务信息。 服务发现的一个重要作用是为客户机提供可用服务的列表。 服务注册有两种形式:客户注册和代理注册。 注册客户端注册是服务本身负责注册和注销的工作。 当服务启动时，注册线程向注册中心注册，当服务脱机时，它注销自己。 客户端注册的缺点是注册和取消逻辑与服务的业务逻辑相耦合。如果服务是用不同的语言开发的，它需要适应多套服务注册逻辑。 注册代理注册由单独的代理服务进行注册和取消。 当服务提供者启动时，它以某种方式通知代理服务，然后代理服务负责向注册中心发起注册。 代理注册的缺点是引用一个代理服务，代理服务要保持高可用状态。 发现服务发现也可以分为客户端发现和代理发现。 用户发现(User Discovery)用户发现(User Discovery)是指用户负责向注册中心查询可用的服务地址，在获得所有可用实例地址的列表后，用户根据负载均衡算法选择一个实例发起请求调用。 发现这种方法非常直接，用户可以控制负载均衡算法。 但是，缺点也很明显。获取实例地址和负载平衡的逻辑与服务的业务逻辑相结合。如果服务发现或服务器的负载平衡发生变化，所有服务都必须修改并重新联机。 代理发现代理发现是指增加一个新的路由服务，负责服务发现和获取可用实例列表。如果服务消费者需要调用服务A的实例，可以直接将请求发送给路由服务，路由服务可以根据配置的负载均衡算法从可用实例列表中选择一个实例并转发请求。如果发现一个实例不可用，路由服务可以自己重试，服务消费者根本不需要知道。 代理服务注册心跳机制如果服务有多个实例，其中一个出现故障，注册中心可以实时感知，并从列表中删除实例信息，这也称为摘机。 如何实现摘机？业内常用的方法是心跳检测。心跳检测有两种方式:主动和被动。 被动检测是指服务主动向注册中心发送心跳消息，时间间隔可以自己设置，比如5秒一次。如果注册中心在三个周期(例如15秒)内没有收到实例的心跳消息，它将从列表中删除该实例。 心跳机制——被动检测显示上图中服务A的实例2宕机，无法主动向注册中心发送心跳消息。15秒后，注册将删除实例2。 主动检测由注册表启动。每隔几秒钟，心跳检测消息就会发送到列表中的所有服务实例。如果心跳检测消息没有成功发送或者在多个周期内没有收到回复，实例将被主动删除。 心跳机制——主动测试业内常用的服务注册和发现组件。了解了服务注册和发现的基本原理后，如果想在项目中使用服务注册和发现组件，面对众多的开源组件，应该如何选择技术？在互联网公司中，有R&D实力的大公司一般会选择基于开源组件的自研或二次开发，而中小公司直接选择一款开源软件是不错的选择。 常用的注册和发现组件包括eureka、zookeeper、consul、etcd等。因为eureka宣布2018年放弃维护，这里不再推荐。 业内开源组件:我们来比较一下每个组件的各个维度。 组件接口类型一致性算法zookeeper1的优缺点。强大，不仅仅是服务发现；2.提供watcher机制可以实时获取服务提供者的状态；3.应用广泛，有dubbo等微服务框架支持；1.没有体检；2.服务中需要引入sdk，集成复杂度高；3.不支持多个数据中心；SDAXOSCONSUL 1。它可以开箱即用，便于集成；2.进行健康检查；3.支持多个数据中心；4.提供web管理界面；无法实时获取服务更改通知restful/dnsRaftetcd1。可以开箱即用，便于集成；2.可配置性强1。没有健康检查；2.需要配合三方工具完成服务发现功能；3.不支持多个数据中心；总的来说，restfulRaft具有更完整和平衡的领事功能。 接下来以consul为例进行详细说明。 Consult ——推荐服务注册和开源组件的发现。consult consult简介consult是HashiCorp推出的开源工作者。它是用Go语言开发的，开箱即可轻松部署。 Consul是分布式的，具有高可用性和可扩展性，用于实现分布式系统的服务发现和配置。 领事有什么优势？服务注册和发现:Consul提供了一种通过DNS或restful接口注册和发现服务的方法。 可以根据实际情况选择服务。 健康检查:Consul的客户端可以提供任意数量的健康检查，这些检查可以与给定的服务或本地节点相关联。 多数据中心:Consul支持多数据中心，这意味着客户不需要担心Consul本身的高可用性以及多数据中心带来的扩展访问。 Consul Consul架构Consul实现多数据中心的架构图依赖于gossip协议协议。 这样做的目的是在不使用服务器地址的情况下配置客户端；服务发现是自动完成的。 检查健康故障的工作是分布式的，而不是在服务器上。 Consul的使用场景Consul的应用场景包括服务注册发现、服务隔离、服务配置等。 在服务发现场景中，consul是注册中心。在consul中注册服务地址后，可以使用consul提供的dns和http接口进行查询。领事支持健康检查。 在隔离服务场景中，consul支持按服务设置访问策略，支持传统和新兴平台、tls证书分发和服务到服务加密。 在配置场景中，consul提供了键值数据存储功能，可以快速通知变化。在Consul的帮助下，可以实现配置共享，需要读取配置的服务可以从Consul读取准确的配置信息。