Birjemin

随遇而安|时光不语,静等花开

View My GitHub Profile

目录:

服务发现

背景

在微服务应用中,服务实例的数量和网络地址都是动态变化的,这对系统运维提出了巨大的挑战。因此,动态的服务注册与发现就显得尤为重要:服务注册和服务发现。

  • 服务注册:服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port,以及暴露服务自身状态以及访问协议等信息。
  • 服务发现:服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提供的服务。
  • 监控:微服务应用中,服务处于动态变化的情况,需要一定机制处理无效的服务实例。一般来讲,服务实例与注册中心在注册后通过心跳的方式维系联系,一旦心跳缺少,对应的服务实例会被注册中心剔除。
  • 负载均衡:同一服务可能同时存在多个实例,需要正确处理对该服务的负载均衡。

CAP理论

CAP原则,指的是在一个分布式系统中,Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性),不能同时成立。

  • 一致性:它要求在同一时刻点,分布式系统中的所有数据备份都处于同一状态。
  • 可用性:在系统集群的一部分节点宕机后,系统依然能够响应用户的请求。
  • 分区容错性:在网络区间通信出现失败,系统能够容忍。

一般来讲,基于网络的不稳定性,分布容错是不可避免的,所以我们默认CAP中的P总是成立的。 一致性的强制数据统一要求,必然会导致在更新数据时部分节点处于被锁定状态,此时不可对外提供服务,影响了服务的可用性,反之亦然。因此一致性和可用性不能同时满足。

常见的实现

|名称|类型|语言|算法|健康检查|优劣势|备注| |:—:|:—:|:—:|:—:|:—:|:—:|:—:| |Eureka|AP|Java|X|可配支持|Eureka仅开源到1.X版本,2.X版本已经宣布闭源| |Consul|CP|Golang|Raft算法|支持|| |ZooKeeper|CP|Java|Paxos算法|支持|| |Etcd||||||

总结

备注

  1. https://cloud.tencent.com/developer/article/1357318