专注于Docker、Container等技术的交流和分享
挖掘最有价值的资讯动态、教程、国内外优秀资源

微服务化改造系列之二:服务注册中心

前情概要:微服务化改造系列之一:总览

服务注册中心概述

这篇文章是微服务化改造系列的第二篇,主题是服务注册中心。作为微服务架构最基础也是最重要的组件之一,服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的。更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和分布往往是动态变化的,也是无法预先确定的。因此,原本在单体应用阶段常用的静态LB机制就不再适用了,需要引入额外的组件来管理微服务提供者的注册与发现,而这个组件就是服务注册中心。

设计或者选型一个服务注册中心,首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案,大致可归为三类:

  • 应用内:直接集成到应用中,依赖于应用自身完成服务的注册与发现,最典型的是Netflix提供的Eureka
  • 应用外:把应用当成黑盒,通过应用外的某种机制将服务注册到注册中心,最小化对应用的侵入性,比如Airbnb的SmartStack,HashiCorp的Consul
  • DNS:将服务注册为DNS的SRV记录,严格来说,是一种特殊的应用外注册方式,SkyDNS是其中的代表

注1:对于第一类注册方式,除了Eureka这种一站式解决方案,还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制,这在大公司比较常见,但对于小公司而言显然性价比太低。

注2:由于DNS固有的缓存缺陷,本文不对第三类注册方式作深入探讨。

除了基本的服务注册与发现机制,从开发和运维角度,至少还要考虑如下五个方面:

  • 测活:服务注册之后,如何对服务进行测活以保证服务的可用性?
  • 负载均衡:当存在多个服务提供者时,如何均衡各个提供者的负载?
  • 集成:在服务提供端或者调用端,如何集成注册中心?
  • 运行时依赖:引入注册中心之后,对应用的运行时环境有何影响?
  • 可用性:如何保证注册中心本身的可用性,特别是消除单点故障?

以下就围绕上述几个方面,简单分析一下Eureka,SmartStack,Consul的利弊。

Eureka

从设计角度来看,Eureka可以说是无懈可击,注册中心、提供者、调用者边界清晰,通过去中心化的集群支持保证了注册中心的整体可用性,但缺点是Eureka属于应用内的注册方式,对应用的侵入性太强,且只支持Java应用。

SmartStack

SmartStack可以说是三种方案中最复杂的,涉及了ZooKeeper、HAProxy、Nerve和Synapse四种异构组件,对运维提出了很高的要求。它最大的好处是对应用零侵入,且适用于任意类型的应用。

Consul

Consul本质上属于应用外的注册方式,但可以通过SDK简化注册流程。而服务发现恰好相反,默认依赖于SDK,但可以通过Consul Template(下文会提到)去除SDK依赖。

方案

最终我们选择了Consul作为服务注册中心的实现方案,主要原因有两点:

  1. 最小化对已有应用的侵入性,这也是贯穿我们整个微服务化改造的原则之一
  2. 降低运维的复杂度,Consul Agent既可以运行在服务器模式,又可以运行在客户端模式

Consul Template

上文提到使用Consul,默认服务调用者需要依赖Consul SDK来发现服务,这就无法保证对应用的零侵入性。所幸通过Consul Template,可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置(比如nginx的upstream),这样对于服务调用者而言,只需要配置一个统一的服务调用地址即可。改造后的调用关系如下:

Spring Cloud Consul

由于我们选用了Spring Boot作为统一的微服务实现框架,很自然的,可以利用Spring Cloud提供的Consul组件进一步简化服务注册流程,省去额外的服务提供端的Consul配置。

参考

文章转自DockOne,点击查看原文

鲸鱼云公众号:dockercloud

鲸鱼云公众号

转载请加上原文链接和本文链接:鲸鱼云 » 微服务化改造系列之二:服务注册中心

分享到:更多 ()

评论 抢沙发

评论前必须登录!