20191123 SpringCloud Eureka学习笔记

前言

本文不涉及项目搭建和细的知识点，这里只是做个笔记，记录自己当下对Eureka的理解。

讨论Eureka时的背景

讨论Eureka时，前提背景是分布式的环境下，微服务的环境下！！！！！
讨论Eureka时，前提背景是分布式的环境下，微服务的环境下！！！！！
讨论Eureka时，前提背景是分布式的环境下，微服务的环境下！！！！！

脱离这个背景环境，当然就无法理解Eureka存在的意义。
分布式系统，如电商系统中有：订单子系统、仓储子系统、积分子系统、商品子系统、账户子系统、风控子系统、客服子系统等N多个子系统。而每个子系统为了保证高可用又需要集群部署，因此最终就有几十甚至上百个子系统/服务。
子系统太多导致存在着这样的问题：每个集群子系统需要对外提供统一的访问入口，这里可以使用nginx作为前置统一访问入口。尽管可以通过nginx配置访问的负载均衡。即使某个服务挂掉了nginx也能即使发现并剔除，但是我们却不知道哪一个服务在什么时候挂掉。N多个服务的访问地址，我们需要记录下哪个服务对应哪个接口地址，以及记录提供集群服务的子系统有多少个，每当有变化，就需要修改记录，这样就很不方便。以及当某台服务挂掉的时候，我们也不得而知。

为什么要使用Eureka

针对分布式系统/微服务环境存在的一些问题，迫切需要一个统一的管理平台来管理各个服务。而Eureka正是这样一个可以管理各个服务的组件。它作为服务注册中心，提供服务的注册与发现功能。各个服务在Eureka这里注册，这样Eureka就能拿到所有的服务信息，Eureka也提供一个可视化的后台系统，让我们知道有哪些服务注册了，我们也能在后台上看到各个服务对应的访问的地址以及对各个服务功能的描述信息。各个服务在Eureka中注册后还会持续和Eureka保持联系，即心跳检测，这样我们就能知道哪些服务能正常提供服务，以及哪些服务处于宕机状态。当我们在需要用到其他服务的时候，就可以向Eureka即服务注册中心发起访问，获取到指定服务的访问地址集合。然后选择其中一个发起访问。这样就无需使用Nginx作为前置统一访问入口。既然Eureka在分布式系统中这么重要，那么当然不能存在单点故障，因此Eureka通常需要集群部署，以保证高可用性。

对Eureka服务端和客户端的理解

Eureka就跟mysql、redis一样，是一个服务端，当我们在程序中去访问mysql或者redis，我们的程序就称为客户端。Eureka也是一样，我们创建了Eureka服务端，它作为服务注册中心。这样，其他需要跟Eureka服务端打交道的端就称为Eureka客户端。因此“Eureka就是Eureka客户端和Eureka服务端”这样的说法其实是不太准确的。