微服务通信之服务发现（service discovery），从简

要实现服务间的通信，服务需要能够发现彼此，这就是平台层的服务发现。

实现服务发现最简单的方式是使用负载均衡器。比如，AWS上的弹性负载均衡器(ELB)为服务分配了一个DNS名称并且负责管理底层节点的健康检查。这些节点是属于同一个虚拟机组的（在AWS中是自动扩容组）。

这种方式是可行的，但是它无法处理那些更复杂的场景。如果想要将请求路由到不同版本的代码中支持“金丝雀部署”或者“灰度上线”呢？如果需要将请求路由到不同的数据中心呢？

一种更加复杂先进的方式是使用类似Consul这样的注册中心。每个服务实例把它们自己注册到注册中心，然后注册中心会提供一个API来对这些服务的请求进行解析——实现方式可以是通过DNS，也可以是其他自定义的机制。

服务发现需要依赖于所部署的应用的拓扑结构的复杂度。部署方式越复杂（比如多地部署），越要求服务发现的架构更具鲁棒性。

总结，服务发现的本质是服务间能找到对应的通信对象，域名方式是最简单的。某软件的服务怎么才能更好的被发现呢？某软件对外提供服务后，将提供的服务在某个公正机构(服务注册中心)注册下自己的能力，也可以是不同阶段不同版本提供不同的能力。其它服务需要这种能力时到这个公正机构找到对应服务。找到对应服务后，可以拿到对应的IP和端口，就可以直接调用这个服务的接口，大多数用于系统内部通信，当然系统间也可以，前提是和该服务的IP网络是通的。找到对应服务后，还可以直接调用服务的对外的IP和对外发布的端口，服务注册中心将消息转发到对应服务内部，这样服务中心可以看作是网关，大多数适用于系统间通信，不用关心和该服务的IP网络问题。。

摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》