服务注册与发现

259 阅读2分钟

这个名称听起来有些高大上,实际理解起来很简单

类比114

114号码百事通(服务中介)大家应该很熟悉,我们有啥需求就会去打个电话查询一下。我们(服务消费者)比如想知道附近电影院电话是多少,就会先去打114问(服务发现)一下。那114为啥知道这么多信息呢,还不是因为商店、机构等(服务提供者)都已经在114上登记(服务注册)了嘛。
附近电影院就是好记的名字(nickname) 电话就是真实地址(realname)
这个类比和DNS过程也非常类似
但是,传统的DNS和114与服务注册发现系统的不同之处在于

  1. 传统的DNS的注册机构和查询机构是分开的,查询机构通常从注册机构那儿得到注册的数据后缓存一段时间,这个与微服务中要求服务地址更新后,消费者能立即得到更新后的地址的期望是不符的
  2. 传统的DNS系统在服务提供者更新注册的地址后没法主动通知客户端机器立即将服务地址更新。微服务中要求注册与发现系统将更新push到消费者手上,即消费者能够察觉到这个更新。
  3. 服务注册与发现需要关注监控服务提供者实例运行状态

通信过程

通常的部署方式

服务中心若为单节点系统,且作为数据库服务器。然后有一个服务提供者往服务器发送了一个值。这个值在单节点上的一致性非常容易保证。
但是为了避免出现单点故障和数据容灾情况以及响应速度的考虑,服务中心多采用多节点部署,采用分布式数据库。这样就出现了分布式系统需要满足CAP原则的问题。其中C代表数据一致性,分布式数据库数据一致性的一个解决算法是raft算法。 Raft算法参考 www.cnblogs.com/xybaby/p/10… 可以从选举的角度去理解,选一个领导人,这个领导人得满足以下条件

  1. 是活的
  2. 响应速度快
  3. 够优秀,知识库比一般人更新、懂得比普通人多
    一个选举过程下来会出现三种角色:普通人follower、候选人candidate、领导人leader。 选举完成后领导人会有一个任期term。 多个选举过程中一个节点可能会这三种角色中转换。

参考

  1. 牧码耕云- ServiceComb 开发实战(2)—— Service-Center 服务注册发现对接