微服务架构实践（服务发现）

在单体架构时，因为服务不会经常和动态迁移，所有服务地址可以直接在配置文件中配置，所以也不会有服务发现的问题。但是对于微服务来说，应用的拆分，服务之间的解耦，和服务动态扩展带来的服务迁移，服务发现就成了微服务中的一个关键问题。

在微服务架构中，每个应用一般都有多个实例，实例故障重启透明化，负载均衡等都与服务发现密切相关。通过服务发现机制，可以同时透明地对多个实例进行访问，并实现实例之间的负载均衡。

服务发现

服务发现分为客户端服务发现和服务端服务发现两种，架构如下图所示。

ms-service-discovery.png

这两种架构都各有利弊。客户端服务发现由客户端决定相应服务实例的网络位置，并且对请求实现负载均衡。这种模式相对直接，除了服务注册外，其它部分无需变动。此外，由于客户端知晓可用的服务实例，能针对特定应用实现智能负载均衡。当然缺点也比较明显，客户端与服务注册中心绑定，要针对服务端用到的每个编程语言和框架，实现客户端的服务发现逻辑。服务端服务发现对于消费者来说，无需关注服务发现具体细节，只需知道服务的DNS域名即可，但是缺点就是需要基础设施（中间的Load Balancer）支撑，多了一次网络跳转，相对而言也可能有相应的性能损失。

我们使用的是客户端服务发现，因为在我们内部使用的是统一的开发语言跟统一的开发框架，因此对于服务发现的逻辑以及后续的服务治理逻辑都可以一次性统一实现，对我们来说可能更加简单直接，也更容易维护。

注册中心

注册中心是服务发现的核心，是包含服务实例数据(例如ip地址，端口等)的数据库。所以注册中心需要一个高可用的分布式键/值存储，例如Etcd，Zookeeper，Consul等。我们选择的是Etcd，主要原因是我对Etcd比较熟悉，我从Etcd 2.x就开始使用，也仔细阅读过Etcd的源码，相对而言比较顺手些。
至于为啥不用Zookeeper，就仁者见仁了，在这里不多阐述。
有篇文章可以作为参考：https://mp.weixin.qq.com/s/uMj3JEhgyYw4CaIhP1-GTQ
关于Etcd的测试可以参考：https://github.com/coreos/dbtester

服务与节点概览

如何根据注册中心查看注册的服务，以及注册的节点呢？我们使用了一个比较粗糙的界面来查看公司所有的微服务应用以及对用的节点，后续还需重构。

real-etcd.png

（未完待续）

我的微信公众号（欢迎扫描关注）

qrcode_for_gh_e51d4037d8fa_430.jpg