概述
- 前言
- 什么是服务注册、服务发现
- 两种服务注册方式
- 两种服务发现方式
- 常见的第三方注册工具
- 后记
前言
好一阵子没有更新了，有些小伙伴在后台问我有没有更新，看来大家还是挺喜欢看我的文章的嘛。主要是这段是间忙着复习算法的一些东西，也不想随便写一篇繁衍。如果我的文章对你有帮助，欢迎关注、点赞、转发，这样我会更有动力做原创分享。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 界面，用户可以查看所有的服务和节点、监控健康检查状态以及通过切换数据中心读取设置键/值对数据。
后记
下一篇文章将是实战篇，主要是手把手编写一个小型的微服务架构，将之前学到的东西实践一下，不实践其实是很难掌握到的，尽请期待。
个人的知识储备总是有限的，如有错误的地方，还请大佬斧正。点击阅读原文，链接到我的知乎，我会在知乎上对文章错误的地方进行修改。
本篇文章首发于公众号「zone7」，关注公众号获取最新推文，后台回复【小白微服务】获取源码。
