用户您好!请先登录!

分类目录注册与发现

微服务注册中心的原理及Go的基本实现

在现实生活中,我们每个家庭都有一个户口本,我们会统一的去户籍中心,去注册自己家的信息,包括自己家的门牌号,家里几个人,如果有人找我们,就可以通过这个来定位,同理微服务中的注册中心也是一样,所有的服务实例都到注册中心去注册,后续大家如果需要查找别的服务,就到注册中心去查找即可

服务调用方式

图解微服务注册中心设计原理与思考并基于go语言实现核心架构

服务调用方式主要是指微服务中服务之间调用的方式,主要分为两类:

  • 基于负载均衡:通过负载均衡设备对外提供VIP地址来实现服务的调用
  • 基于注册中心:微服务之间通过服务注册中心进行节点发现,然后在服务端直接调用对应的节点进行调用

阅读更多

ETCD 简介及使用场景

随着CoreOS和Kubernetes等项目在开源社区日益火热,它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库,渐渐为开发人员所关注。在云计算时代,如何让服务快速透明地接入到计算集群中,如何让共享配置信息快速被集群中的所有机器发现,更为重要的是,如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群,已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音,本文将从etcd的应用场景开始,深入解读etcd的实现方式,以供开发者们更为充分地享用etcd所带来的便利。

经典应用场景

要问etcd是什么?很多人第一反应可能是一个键值存储仓库,却没有重视官方定义的后半句,用于配置共享和服务发现。

A highly-available key value store for shared configuration and service discovery.

实际上,etcd作为一个受到ZooKeeper与doozer启发而催生的项目,除了拥有与之类似的功能外,更专注于以下四点。

阅读更多

ZooKeeper:分布式协调服务原理

ZooKeeper是一种用于分布式应用程序的分布式开源协调服务。它公开了一组简单的原语,分布式应用程序可以构建这些原语,以实现更高级别的服务,以实现同步,配置维护以及组和命名。它被设计为易于编程,并使用在熟悉的文件系统目录树结构之后设计的数据模型。它在Java中运行,并且具有Java和C的绑定。

众所周知,协调服务很难做到。他们特别容易出现竞争条件和死锁等错误。ZooKeeper背后的动机是减轻分布式应用程序从头开始实施协调服务的责任。

设计目标

ZooKeeper很简单。ZooKeeper允许分布式进程通过共享的分层命名空间相互协调,该命名空间的组织方式与标准文件系统类似。名称空间由数据寄存器组成 – 在ZooKeeper用语中称为znodes – 这些与文件和目录类似。与专为存储而设计的典型文件系统不同,ZooKeeper数据保存在内存中,这意味着ZooKeeper可以实现高吞吐量和低延迟数量。

阅读更多

微服务注册中心 Eureka 架构解读

微服务架构中最核心的部分是服务治理,服务治理最基础的组件是注册中心。随着微服务架构的发展,出现了很多微服务架构的解决方案,其中包括我们熟知的 Dubbo 和 Spring Cloud。

关于注册中心的解决方案,dubbo 支持了 Zookeeper、Redis、Multicast 和 Simple,官方推荐 Zookeeper。Spring Cloud 支持了 Zookeeper、Consul 和 Eureka,官方推荐 Eureka。

两者之所以推荐不同的实现方式,原因在于组件的特点以及适用场景不同。简单来说:

  • ZK 的设计原则是 CP,即强一致性和分区容错性。他保证数据的强一致性,但舍弃了可用性,如果出现网络问题可能会影响 ZK 的选举,导致 ZK 注册中心的不可用
  • Eureka 的设计原则是 AP,即可用性和分区容错性。他保证了注册中心的可用性,但舍弃了数据一致性,各节点上的数据有可能是不一致的(会最终一致)
  • Eureka 采用纯 Java 实现,除实现了注册中心基本的服务注册和发现之外,极大的满足注册中心的可用性,即使只有一台服务可用,也可以保证注册中心的可用性。

这里聚焦到 Eureka 的内部实现原理,先从微服务架构的部署图介绍 Eureka 的总体架构,然后剖析服务信息的存储结构,最后探究跟服务生命周期相关的服务注册机制、服务续约机制、服务注销机制、服务剔除机制、服务获取机制、和服务同步机制。

阅读更多