服务器端服务发现模式

为什么使用服务发觉？

想象一下，如果你在写代码读取一个有REST API或Thrift API的服务，你的代码还要晓得一个服务例子的网路地址（IP地址跟端口）。运行在数学软件上的传统应用中微端服务器，服务例子的网路地址是相对静态的，你的代码可以从一个甚少更新的配置文件中调用网路地址。

在一个现代的，基于云的微服务应用中，这个问题就显得复杂多了，如下图所示：

服务器端服务发觉（server-side discovery）。我们首先来看下客户端服务发觉。

客户端服务发觉方式

当使用客户端服务发觉的时侯，客户端负责决定可用的服务例子的网路地址，以及紧扣她们的负载均衡。客户端向服务注册表（service registry）发送一个恳求，服务注册表是一个可用服务例子的数据库。客户端使用一个负载均衡算法，去选择一个可用的服务例子，来响应这个恳求，下图展示了这些机制的构架：

前面提及了，服务例子应当要从注册表中注册跟吊销，有很多种模式来处理注册跟吊销的过程。一个选择是服务例子自己注册，即self-registration机制。另一种选择是其它的系统组件管理服务例子的注册，即第third-party registration机制。

自注册机制（The Self-Registration Pattern）

在self-registration方式中，服务例子负责从服务注册表中注册跟吊销。如果还要的话，一个服务例子发送脉搏恳求避免注册过期。下图展示了这些机制的构架：

service registrar的一个实例是开源的Registrator项目。它会手动注册跟吊销象Docker容器一样布署的服务。Registrator支持etcd跟Consul等服务注册。

另一个service registrar的实例是NetflixOSS Prana。主要适于非JVM语言撰写的服务，它是一个跟服务例子配合的『双轮』应用。Prana会在Netflix Eureka上注册跟吊销例子。

service registrar是一个布署环境的外置组件，由Autoscaling Group争创的EC2例子可以被ELB手动注册。Kubernetes服务也可以手动注册。

third-party registration方式主要的优势在于前馈了服务跟服务注册表。不需要为每位语言跟框架都实现服务注册逻辑。服务例子注册由一个专用的服务集中实现。缺点是不仅被外置至布署环境中，它本来只是一个高可用的系统组件，需要被启动跟管理。

总结

在一个微服务应用中，服务例子在运行时的配置也会动态变化，包括她们的网路地址。为了满足客户端向服务发送恳求的还要，必须要实现服务发觉模式。

NSQ

Serf

Spotify

DNS

SkyDNS

Consul

Cloud Foundry

Gradle

Docker

Docker Hub

Docker Machine

Kitematic

Docker Compose

Docker Swarm

AWS

Jenkins

Continuum

Hudson

Artifactory

Terraform

Grunt

OpenShift

SonarCube

Logstash

New Relic

Graphite

Mesosphere / DCOS

Winston

Hystrix

原文：微服务构架