image.png
首先是要进行服务的注册与发现，每一个服务都向Eureka来注册自己的服务信息（ip地址、端口号、版本号、通信协议等），这样的话我每个节点上就不需要维护其他节点的信息，而是在Eureka上找，再去调用。Eureka注册多个服务，每个服务又有多个实例，并会对各个服务进行心跳检测，剔除不可用的服务。Eureka自身也可以集群，节点间也会相互注册，每个节点上的数据保持一致（最终一致性）。服务之间的相互调用时不需要指定服务的具体地址，只需要通过服务名去调用。
但是每个服务可能有多个实例，那通过服务名去调用的时候不知道去调用哪一个实例，所以就要做服务的负载均衡，同时还能实现流量的负载。这就是Ribbon的作用。
而如果不使用feign的话，Ribbon其实还是通过http请求通过服务名的方式去调用的，每一次调用还是要手动的去发起http请求，就比较麻烦。所以springcloud的就用feign来封装调用细节。feign基于动态代理机制，我们只需要创建一个接口，并通过注解的方式来配置它（服务名和调用路径），即可完成对服务提供方的接口绑定。其实是feign会生成一个代理类来完成原来的调用逻辑。
在微服务中，不能因为一个服务的大流量访问而影响其他服务的正常运行，所以就有了Hystrix，通过统计接口的超时次数，实现服务的熔断（不让服务继续下去）和降级（不立刻响应，可以发到mq中慢慢处理，给用户一个友好的提示）。
如果前端需要调用后端系统，统一从Zuul进入，由Zuul网关转发请求给对应的服务，通过与Eureka整合，将自身注册为Eureka下的服务，从Eureka下获取所有服务的实例来进行路由（还可以定义过滤机制）。
网友评论