微服务核心---服务的注册与发现，它们是什么？

服务注册与发现

微服务体系中，服务注册与服务发现是两个最核心的模块。服务A调用服务B时，需要通过服务发现模块找到服务B的IP和端口列表，而服务B的实例在启动时需要把提供服务的IP和端口注册到服务注册中心。一个典型的结构如下图：

也即是说，ServiceA需要通过查找ServiceRegistry来“发现”ServiceB，而ServiceB则需要通过每次启动时向ServiceRegistry发送自己服务的ip+port来“注册”ServiceB。

服务注册

目前，流行的注册中心比较多，常见的有zookeeper、ectd、consul、eureka等。服务注册通常有三种：自注册、第三方注册、注册中心主动同步。

• 自注册
  自注册，顾名思义，就是服务提供方在启动服务时自己把提供服务的IP和端口发送到注册中心，并通过心跳方式维持健康状态；服务下线时，自己把相应的数据删除。典型的像使用eureka客户端发布微服务。
• 第三方注册
  第三方注册是指，存在一个第三方的系统负责在服务启动或停止时向注册中心增加或删除服务数据。典型的用法是devops系统或容器调度系统主动调注册中心接口注册服务；
• 注册中心主动同步
  与第三方注册方式类似，主动注册方式是指注册中心和调度或发布系统打通，主动同步最新的服务IP列表；一个例子是kubernetes体系中，coredns订阅api server数据。

服务发现

在真正发起服务调用前，调用方需要从注册中心拿到相应服务可用的IP和端口列表，即服务发现。服务发现从对应用的侵入性上可以分为两大类：

• SDK-Based
  这类的服务发现方式，需要调用方依赖相应的SDK，显式调用SDK代码才可以实现服务调用，即对业务有侵入性，典型例子如eureka、zookeeper等。
• DNS-Based
  DNS本身是一种域名解析系统，可以满足简单的服务发现场景，如双方约定好端口、序列化协议等等。但是，这远远不能满足真正的微服务场景需求。近几年，基于DNS的服务发现渐渐被业界提了出来。后面将重点介绍基于DNS的服务发现及阿里巴巴的实践。

服务发现交互协议

微服务架构中，服务注册与发现的通信协议大致可以分为两类：一类是“私有”协议，如dubbo + zk及eureka；另一类是通用的DNS协议，如k8s + coredns。

“私有”协议

“私有”协议具有很高的定制性，可以和具体产品一起实现更高级的功能，如zk + dubbo，可以支持推送和长连接。但是，“私有”协议也带来了另外一个问题，就是开放性很差，第三方接入需要使用特定的SDK，跨语言特性不好。而在微服务或云环境下，跨语言服务注册和发现是非常常见的一个场景。

DNS协议为基础的服务发现

DNS协议是一个“古老”的协议，也是最基本、最通用的协议之一。基于DNS协议的服务发现具备非常好的通用性，几乎所有语言都可以无缝接入。与“私有”协议的服务发现相比，基于DNS协议的服务发现还有一些问题需要解决，如端口问题、语言框架的缓存问题。这些问题已经有了对应的解决方案，将在后续文章中向大家介绍，本文重点放在基于DNS的服务发现的大概玩法。