1. 什么是服务注册和发现
    假如这个产品已经在线上运行，有一天运营想搞一场促销活动，那么我们相对应的【用户服务】可能就要新开启三个微服务实例来支撑这场促销活动。而与此同时，作为苦逼程序员的你就只有手动去 API gateway 中添加新增的这三个微服务实例的 ip 与port ，一个真正在线的微服务系统可能有成百上千微服务，难道也要一个一个去手动添加吗？有没有让系统自动去实现这些操作的方法呢？答案当然是有的。
    当我们新添加一个微服务实例的时候，微服务就会将自己的 ip 与 port 发送到注册中心，在注册中心里面记录起来。当 API gateway 需要访问某些微服务的时候，就会去注册中心取到相应的 ip 与 port。从而实现自动化操作。

    基于配置文件的微服务弊端
    image.png
    2. 技术选型
    Consul 与其他常见服务发现框架对比

    | 名称

    | 优点

    | 缺点

    | 接口

    | 一致性算法

    | | —- | —- | —- | —- | —- | | zookeeper

    | 1.功能强大，不仅仅只是服务发现 2.提供 watcher 机制能实时获取服务提供者的状态 3.dubbo 等框架支持

    | 1.没有健康检查 2.需在服务中集成 sdk，复杂度高 3.不支持多数据中心

    | sdk

    | Paxos

    | | consul

    | 1.简单易用，不需要集成 sdk 2.自带健康检查 3.支持多数据中心 4.提供 web 管理界面

    | 1.不能实时获取服务信息的变化通知

    | http/dns

    | Raft

    | | etcd

    | 1.简单易用，不需要集成 sdk 2.可配置性强

    | 1.没有健康检查 2.需配合第三方工具一起完成服务发现 3.不支持多数据中心

    | http

    | Raft

    |