微服务的注册和发现

微服务的注册和发现

一、微服务设计，服务发现

微服务设计——服务发现

导语

在分布式微服务架构中，一个应用可能由一组职责单一化的服务组成。这时候就需要一个注册服务的机制，注册某个服务或者某个节点是可用的，还需要一个发现服务的机制来找到哪些服务或者哪些节点还在提供服务。
在实际应用中，通常还都需要一个配置文件告诉我们一些配置信息，比如数据连接的地址，redis 的地址等等。但很多时候，我们想要动态地在不修改代码的情况下得到这些信息，并且能很好地管理它们。
有了这些需求，于是发展出了一系列的开源框架，比如 ZooKeeper, Etcd, Consul 等等。

这些框架一般会提供这样的服务：

• 服务注册
  主机名，端口号，版本号，或者一些环境信息。

• 服务发现
  可以让客户端拿到服务端地址。

• 一个分布式的通用 k/v 存储系统
  基于 Paxos 算法或者 Raft 算法

• 领导者选举 (Leader Election)

其它一些例子：

• 分布式锁 (Distributed locking)
• 原子广播 (Atomic broadcast)
• 序列号 (Sequence numbers)
  …

我们都知道 CAP 是 Eric Brewer 提出的分布式系统三要素：

• 强一致性 (Consistency)
• 可用性 (Availability)
• 分区容忍性 (Partition Tolerance)

几乎所有的服务发现和注册方案都是 CP 系统，也就是说满足了在同一个数据有多个副本的情况下，对于数据的更新操作达到最终的效果和操作一份数据是一样的，但是在出现网络分区（分区间的节点无法进行网络通信）这样的故障的时候，在节点之间恢复通信并且同步数据之前，一些节点将会无法提供服务（一些系统在节点丢失的情况下支持 stale reads ）。

1 什么是服务发现？

服务发现组件记录了（大规模）分布式系统中所有服务的信息，人们或者其它服务可以据此找到这些服务。DNS 就是一个简单的例子。当然，复杂系统的服务发现组件要提供更多的功能，例如，服务元数据存储、健康监控、多种查询和实时更新等。服务发现是支撑大规模 SOA 的核心服务。

2 服务发的关键特性

• 高可用的
• 服务目录
• 服务查找
• 服务注册

3 为什么要使用服务发现

假设我们写的代码会调用 WebService、Rest Api、 Thrift API 的服务。在调用过程中,为了完成一次请求，代码需要知道服务实例的网络位置（IP 地址和端口）。

整个过程，对于基于云端的、现代化的微服务应用而言，这却是一大难题。为了更好的让大家了解服务发现的发展过程，现在举个例子。

##### 3.1 单体应用

假设你是项目经理或者公司的架构师，正准备组织团队开发一款产品，类似滴滴与Uber的出租车调度软件。
其中系统的核心业务有：客户端、司机端、定位、通知、支付
传统的架构图为：六边形架构（即模块化的单体是应用），也称单体式应用，如下图

六边形架构.png

单体应用的不足

这种简单方法却有很大的局限性。
一个简单的应用会随着时间推移逐渐变大。在每次的迭代中，开发团队都会面对新“故事”（需求），然后开发许多新代码。
几年后，这个小而简单的应用会变成了一个巨大的怪物。

如果有经验的管理者都知道，一旦你的应用变成一个又大又复杂的怪物，那开发团队肯定很痛苦。
敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。

1. 降低开发速度
2. 不利于持续性开发
3. 模块相互冲突
4. 可靠性低
5. 重构困难

##### 3.2 微服务

随着时间的发展和项目的发展，业务团队越来越庞大，业务越来越复杂，单体应用架构已经无法满足项目需求，所以微服务就腾空出世了。
许多公司，比如Amazon、eBay，通过采用微处理结构模式解决了单体应用出现的问题。
其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。

微服务架构.png

微服务架构的好处

1. 单个服务很容易开发、理解和维护。
2. 这种架构使得每个服务都可以有专门开发团队来开发。
3. 微服务架构模式是每个微服务独立的部署。
4. 微服务架构模式使得每个服务独立扩展。

微服务架构的不足

微服务应用是分布式系统，由此会带来固有的复杂性。
服务地址目录，服务健康度，部署困难，服务依赖问题，数据库分区问题。

如何解决微服务出现的这些问题呢？服务发现框架在这时就闪亮登场了。

4 常见的服务发现框架有哪些

常见服务发现框架 Consul、 ZooKeeper以及Etcd
ZooKeeper是这种类型的项目中历史最悠久的之一，它起源于Hadoop。它非常成熟、可靠，被许多大公司（YouTube、eBay、雅虎等）使用。
etcd是一个采用HTTP协议的健/值对存储系统，它是一个分布式和功能层次配置系统，可用于构建服务发现系统。其很容易部署、安装和使用，提供了可靠的数据持久化特性。它是安全的并且文档也十分齐全。

名称	Zookeeper	etcd	Consul
产生时间	长	短	短
原生语言	JAVA	Go	Go
算法	Paxos	Raft	Raft
多数据中心	不支持	不支持	支持
健康检查	支持	不支持	支持
web管理界面	较为复杂	不支持	支持
http协议	较为复杂	支持	支持
DNS协议	较为复杂	不支持	支持

5 Consul服务发现框架介绍

Consul是强一致性的数据存储，使用gossip形成动态集群。它提供分级键/值存储方式，不仅可以存储数据，而且可以用于注册器件事各种任务，从发送数据改变通知到运行健康检查和自定义命令，具体如何取决于它们的输出。

下面两张图是Consul的原理图

Consul的原理图01.png

Consul的原理图02.png

Consul 和 Etcd 一样也有两种节点，一种叫 client (和 Etcd 的 proxy 一样) 只负责转发请求，另一种是 server，是真正存储和处理事务的节点。

Consul 使用基于 Serf 实现的 gossip 协议来管理从属关系，失败检测，事件广播等等。gossip 协议是一个神奇的一致性协议，之所以取名叫 gossip 是因为这个协议是模拟人类中传播谣言的行为而来。要传播谣言就要有种子节点，种子节点每秒都会随机向其它节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想要信息一定要传递给所有的节点，但是随着时间的增长，在最终的某一时刻，全网会得到相同的信息。当然这个时刻可能仅仅存在于理论，永远不可达。

Consul 使用了两个不同的 gossip pool，分别叫做 LAN 和 WAN，这是因为 Cons