spring服务治理过程

服务的注册发现和调用

1.服务注册中心Eureka

eureka是netflix开发的服务发现框架,本身是一个基于rest的服务,由两个组件构成

• Eureka server: 也被称作是服务注册中心,用于提供服务的注册和发现
• Eureka client: 包含服务消费者和服务生产者

eureka的作用就是将我们定义的API接口注册到eureka服务器上,方便管理,调用的时候只需要知道服务名称就可以,不在通过ip加端口号的方式调用,利于解耦

2.服务调用

springcloud有两种服务调用的方式

• Ribbon
• Feign

2.1.Ribbon

spring ribbon是一个基于http和tcp的客户端负载均衡工具,基于netflix ribbon实现,几乎存在于每一个springcloud构建的微服务和基础设施中,因为微服务的调用,api网关的请求转发等内容,实际上都是通过ribbon来实现的

2.2. fegin

fegin是基于ribbon实现的工具,才用基于接口的注解

ribbo的作用是负载均衡,默认的负载机制是轮询机制.他和fegin和eureka紧密工作,共同完成工作

1. 首先ribbon会从eureka client获取各个服务的节点信息
2. 然后ribbon会根据自身的负载算法进行删选最终要把请求发往哪台机器上
3. 这时候fegin构造请求的url就知道要发送机器的地址了

3. hystrix 熔断器

Hystrix会搞很多个小小的线程池，比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务

4. zuul 微服务网关

负责网络路由

k8s中的服务沟通

我们现在已经有了 pod ，那让他们相互访问不可以么？答案是，不可以，因为 pod 是有生命周期的，他可能随时被创建也可能随时被销毁，而 每次新建 pod 就会给其分配一个随机的 ip，并且 k8s 也会自动调控 pod 的数量。这就导致了 pod 之间直接访问是不现实的，如果有一个入口，可以动态绑定那些提供相同服务的 pod，并将其开放在固定端口上，这样访问起来不就方便很多了么？这个入口在 k8s 中被称为service。

同一个命名空间中可以通过标签名称来直接访问,

service 对 pod 的动态绑定

因为svc是通过我们事先定义好的标签选择器来查找 pod 的，所以 pod 的 ip 地址变动对于svc毫无影响，其实在svc和pod之间还包含了一个资源叫做endpoint，endpoint(简称ep)是一组地址及其端口的合集，如下图，只要一个svc有标签选择器的话，他就会自动创建一个同名的ep来标记出自己的要管理的 pod。

。

访问集群外部服务

自定义一个endpoint资源，用它指定外部服务的 ip 及端口，然后绑定到一个svc上，这样内部的 pod 不就通过完全一样的方式访问外部服务了么？

service > endpoint > 服务提供者的传递流程