小白入门微服务(4) - 服务注册与服务发现

1,751 阅读4分钟

概述

  • 前言
  • 什么是服务注册、服务发现
  • 两种服务注册方式
  • 两种服务发现方式
  • 常见的第三方注册工具
  • 后记

前言

好一阵子没有更新了,有些小伙伴在后台问我有没有更新,看来大家还是挺喜欢看我的文章的嘛。主要是这段是间忙着复习算法的一些东西,也不想随便写一篇繁衍。**如果我的文章对你有帮助,欢迎关注、点赞、转发,这样我会更有动力做原创分享。**OK,进入正题!

什么是服务注册、服务发现

产品架构
我们来回顾一下上一盘文章的微服务架构图,假如这个产品已经在线上运行,有一天运营想搞一场促销活动,那么我们相对应的【产品服务】可能就要新开启三个微服务实例来支撑这场促销活动。而与此同时,作为苦逼程序员的你就只有手动去 API gateway 中添加新增的这三个微服务实例的 ip 与port ,一个真正在线的微服务系统可能有成百上千微服务,难道也要一个一个去手动添加吗?有没有让系统自动去实现这些操作的方法呢?答案当然是有的。且看,

注册中心
如图所示,当我们新添加一个微服务实例的时候,微服务就会将自己的 ip 与 port 发送到注册中心,在注册中心里面记录起来。当 API gateway 需要访问某些微服务的时候,就会去注册中心取到相应的 ip 与 port。从而实现自动化操作。 以下是一个比较完整的服务注册与服务发现的流程:

服务注册的两种方式

服务注册方式有以下两种:

  • 客户端注册 客户端注册即为:将服务注册与服务注销的逻辑写进代码里面,当一个微服务启动的时候,将信息写入注册中心,当一个微服务下线的时候,注销相应的信息。且,需要不同的编程语言实现相同的一套逻辑。对业务代码有一定的入侵。期间,注册中心与各个微服务之间还需要保持心跳。

  • 第三方注册 第三方注册由一个独立的服务 Registrar 负责注册与注销。当服务启动后以某种方式通知Registrar,然后Registrar负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳,当服务不可用时,向注册中心注销服务。

服务发现的两种方式

  • 客户端发现 客户端负责向注册中心获取相应的 ip 与 port ,多种语言需要实现同一套逻辑,有点冗余的感觉。
  • 服务端发现 由 API gateway 实现服务发现的功能,这样一套语言便可轻松维护服务发现的功能。

常见的第三方注册工具

registrator registrator 通过检查容器在线或者停止运行状态自动注册和去注册服务,它目前支持 etcd、consul、zookeeper 和 SkyDNS 2。链接传送。它通常会和下面的工具配合使用,实现自动化服务注册功能。

zookeeper zookeeper 起源于 Hadoop ,它非常成熟、稳定,有比较多的大公司在使用一个高性能、分布式应用程序协调服务,用于名称服务、分布式锁定、共享资源同步和分布式配置管理。

etcd etcd 是一个采用 HTTP 协议的健/值对存储系统,它是一个分布式和功能层次配置系统,可用于构建服务发现系统。其很容易部署、安装和使用,提供了可靠的数据持久化特性。它是安全的并且文档也十分齐全。它需要搭配一些第三方工具才可以提供服务发现功能。

consul Consul 是强一致性的数据存储,使用 gossip 形成动态集群。它提供分级键/值存储方式,不仅可以存储数据,而且可以用于注册器件事各种任务,从发送数据改变通知到运行健康检查和自定义命令,具体如何取决于它们的输出。consul web 界面,用户可以查看所有的服务和节点、监控健康检查状态以及通过切换数据中心读取设置键/值对数据。

consul web 界面

后记

下一篇文章将是实战篇,主要是手把手编写一个小型的微服务架构,将之前学到的东西实践一下,不实践其实是很难掌握到的,尽请期待。 个人的知识储备总是有限的,如有错误的地方,还请大佬斧正。点击阅读原文,链接到我的知乎,我会在知乎上对文章错误的地方进行修改。 本篇文章首发于公众号「zone7」,关注公众号获取最新推文,后台回复【小白微服务】获取源码。

参考文献: 服务发现:Zookeeper vs etcd vs Consul 服务注册与发现