服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的。
更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和分布往往是动态变化的,也是无法预先确定的。
因此,原本在单体应用阶段常用的静态 LB 机制就不再适用了,需要引入额外的组件来管理微服务提供者的注册与发现,而这个组件就是服务注册中心。
CAP 理论
CAP 理论是分布式架构中重要理论:
一致性(Consistency),所有节点在同一时间具有相同的数据。
可用性(Availability),保证每个请求不管成功或者失败都有响应。
分隔容忍(Partition tolerance),系统中任意信息的丢失或失败不会影响系统的继续运作。
服务注册中心解决方案
应用内:直接集成到应用中,依赖于应用自身完成服务的注册与发现,最典型的是 Netflix 提供的 Eureka。
应用外:把应用当成黑盒,通过应用外的某种机制将服务注册到注册中心,最小化对应用的侵入性,比如 Airbnb 的 SmartStack,HashiCorp 的 Consul。
DNS:将服务注册为 DNS 的 SRV 记录,严格来说,是一种特殊的应用外注册方式,SkyDNS 是其中的代表。
测活:服务注册之后,如何对服务进行测活以保证服务的可用性?
负载均衡:当存在多个服务提供者时,如何均衡各个提供者的负载?
集成:在服务提供端或者调用端,如何集成注册中心?
运行时依赖:引入注册中心之后,对应用的运行时环境有何影响?
可用性:如何保证注册中心本身的可用性,特别是消除单点故障?
主流注册中心产品
Consul 是支持自动注销服务实例,在 check 的 DeregisterCriticalServiceAfter 这个参数。
新版本的 Dubbo 也扩展了对 Consul 的支持。
Eureka 不再从注册表中移除因为长时间没有收到心跳而过期的服务。
Eureka 仍然能够接受新服务注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)。
当网络稳定时,当前实例新注册的信息会被同步到其它节点中。
在 Leader 挂掉了之后,重新选举出 Leader 之前会导致 Consul 服务不可用。
Consul 本质上属于应用外的注册方式,但可以通过 SDK 简化注册流程。而服务发现恰好相反,默认依赖于 SDK,但可以通过 Consul Template(下文会提到)去除 SDK 依赖。
服务注册相比 Eureka 会稍慢一些。因为 Consul 的 Raft 协议要求必须过半数的节点都写入成功才认为注册成功
Leader 挂掉时,重新选举期间整个 Consul 不可用。保证了强一致性但牺牲了可用性。
服务注册相对要快,因为不需要等注册信息 Replicate 到其他节点,也不保证注册信息是否 Replicate 成功。
当数据出现不一致时,虽然 A,B 上的注册信息不完全相同,但每个 Eureka 节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求 A 查不到,但请求 B 就能查到。如此保证了可用性但牺牲了一致性。
作者:琦彦
编辑:陶家龙
出处:http://45dwz.com/ax2HY
要想做好微服务,其实有几条规则必须遵守
中国人发明的计算机,程序该怎么写呢?