Spring Cloud 服务治理-Eureka详解（一）

服务治理：
1、什么叫做服务治理？
在微服务的架构中，所有的功能实现全都以服务的方式存在的。对外来说，所有微服务组成的集合是一个整体。而对内来说，这个整体被拆分成了很多个服务。要完成一项功能，可能会牵扯到服务的调用，那么就会存在服务A调用服务B，服务B调用服务C的情况。这就存在一个问题：服务A怎么发现和调用服务B？服务B怎么发现和调用服务C？传统的解决方案是在服务中进行配置。例如，服务A要调用什么功能的时候，通过配置告诉服务A，当你需要调用该功能的时候，就去调用服务B。通过配置告诉服务B，当你需要调用某功能的时候，你就去调用服务C。每一个服务都要维护一个服务清单，将它需要用到的服务都编写在配置文件中。
如果项目很大，成千上万个微服务组成一个整体的系统，那么就需要为成千上万个服务配置成千上万个服务清单。
对于开发和维护来说都是极大的麻烦。服务治理就是为了解决这个需求而诞生的。通过服务管理中心来管理每个服务，当某个服务需要调用另一个服务时，直接从服务中心来获取想要调用的服务的信息，极大降低了运维的复杂度。

2、服务治理需要做哪些事情？
提到第一步中关于服务治理是什么的解释中，我们能够大致了解到服务治理的作用。
根据作用，我们能够很容易的推测出来，服务需要做的事情：
1>维护所有的服务信息
2>注册服务
3>提供服务信息

在服务治理框架中，通常都会构造一个注册中心。所有的微服务向注册中心登记自己所提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告知注册中心。我们在学习的过程中，可以把整个系统想象成一个公司，某个服务要想为这个公司服务，那么就必须去面试，HR就相当于这个注册中心。面试的人会将自己的信息交给HR，同时HR手中会维护着一张关于公司所有职工的清单。这个清单会按照部门、职员名称进行分类组织。同时如果有人离职，那么HR就会将这个人的信息从职工表中清除掉。服务注册中心同样扮演着这样的角色，它会按照服务的名称将服务进行分类组织，生成一个服务清单，服务清单还会以心跳的方式去检测清单中的服务是否可用，若不可用，则会将服务从该清单中剔除。

由于在服务治理框架下运作， 服务间的调用不再通过指定具体的实例地 址来实现， 而是通过向服务名发起请求调用实现。 所以， 服务调用方在调用服务提 供方接口的时候， 并不知道具体的服务实例位置。 因此， 调用方需要向服务注册中 心咨询服务， 并获取所有服务的实例清单， 以实现对具体服务实例的访问。 比如， 现有服务C希望调用服务A, 服务C就需要向注册中心发起咨询服务请求，服务注 册中心就会将服务A的位置清单返回给服务C, 如按上例服务A的情况，C便获得 了服务A的两个可用位置 192.168.0.100:8000和192.168.0.101:8000。 当服务C要发起调用的时候，便从该清单中以某种轮询策略取出一个位置来进行服 务调用，这就是后续我们将会介绍的客户端负载均衡。 这里我们只是列举了一种简 单的服务治理逻辑， 以方便理解服务治理框架的基本运行思路。 实际的框架为了性 能等因素， 不会采用每次都向服务注册中心获取服务的方式， 并且不同的应用场景 在缓存和服务剔除等机制上也会有一些不同的实现策略。

 

Eureka服务端，我们也称为服务注册中心。它同其他服务注册中心一样，支持高可用 配置。它依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。如 果Eureka以集群模式部署，当集群中有分片出现故障时，那么Eureka就转入自我保护模 式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中 的其他分片会把它们的状态再次同步回来。以在AWS 上的实践为例，Netflix推荐每个可 用的区域运行一个Eureka服务端，通过它来形成集群。不同可用区域的服务注册中心通过 异步模式互相复制各自的状态，这意味着在任意给定的时间点每个实例关于所有服务的状 态是有细微差别的。

Eureka客户端，主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式， 嵌入在客户端应用程序的代码中，在应用程序运行时，Euerka客户端向注册中心注册自身 提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注 册的服务信息并把它们缓存到本地并周期性地刷新服务状态。