Ribbon

第一章 微服务与 Spring Cloud 1.1 架构的衍进 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 互联网产品常常面临庞大的用户量，日均数十亿 PV 的高并发， PB 级别的数据存储等问题的挑战，同时要求保证系统的高可用和弹性伸缩，并且能够根据需要进行快速迭代扩展，这些都对于系统架构提出了很高的要求。 互联网架构从简到繁的演进至今，大体上可分为这么几个阶段：单一应用架构 -> 垂直应用架构 -> 微服务架构。 1.1.1 单一应用架构 当网站流量很小时，只需要一个应用，将所有的功能都部署在一起，用来减少部署节点和成本。这时，用于简化增删改查工作量的数据访问框架(ORM)是关键。我们更加关注的是简化开发工作。如图1-1： 特点： 所有的功能集中在一个工程中。 应用与数据库分开部署。 通过部署应用集群和数据库集群来提高系统的性能。 优点： 项目架构简单，前期开发成本低，周期短，小型项目的首选。 缺点： 全部功能集中在一个工程中，代码耦合，对于大型项目不易扩展及维护。 提高系统性能只能通过扩展集群，成本高。 单点容错率低。 1.1.2 垂直应用架构 · 当访问量逐渐增大，功能逐渐复杂起来，单一应用架构就显得有些捉襟见肘，由于所有的功能都写在同一个工程中

简介 在微服务架构中，微服务之间的依赖关系错综复杂，难免的某些服务会出现故障，导致服务调用方出现远程调度的线程阻塞。在高负载的场景下，如果不做任何处理，可能会引起级联故障，导致服务调用方的资源耗尽甚至整个系统奔溃。Hystrix是一个由Netflix开源的一个延迟和容错库，它通过添加延迟容忍和容错逻辑来帮助控制这些微服务之间的交互。Hystrix通过隔离服务之间的访问点、停止跨服务的级联故障并提供回退选项来实现这一点，所有这些选项都提高了系统的总体弹性。 项目介绍 sc-parent，父模块(请参照 SpringCloud学习笔记(1)：Eureka注册中心 ) sc-eureka，注册中心(请参照 SpringCloud学习笔记(1)：Eureka注册中心 ) sc-provider，提供者(请参照 SpringCloud学习笔记(1)：Eureka注册中心 ) sc-consumer-hystrix-ribbon，使用Hystrix+Ribbon的消费者 sc-consumer-hystrix-feign，使用Hystrix+Feign的消费者 在Ribbon上使用Hystrix 1.在父模块下创建子模块项目sc-consumer-hystrix-ribbon，pom.xml： <project xmlns="http://maven.apache.org/POM/4.0.0"

持续更新在工作中使用eureka遇到的问题以及一些配置说明 ----集成篇---- Eureka为我们提供服务发现的能力, 在微服务体系中, 有很重要的地位(最核心和基础的组件), 主要用来实现各个微服务之间的自动化注册与彼此可见(发现) Spring cloud Eureka是对netflix Eureka的二次封装, 使其成为spring cloud微服务治理体系中的一员 eureka在应用时, 要两种模式互相配合使用, 一种为服务注册中心(discover-center), 一种为服务提供者(product) 在springboot环境中集成eureka非常简单, 具体步骤如下: 注册中心和服务提供者配置是不一样的, 一定要注意下 1. 引入依赖(需要配置springCloud依赖管理) 使用springboot脚手架新建两个springboot空项目(一个是注册中心, 一个是服务提供者) <!-- 注册中心依赖 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <!-- 服务提供者依赖 --> <dependency> <groupId

<div class="contentDiv" style="color:#333333"><p><span style="font-size:16px;">启动spring cloud中的网关，报错：</span></p><p><span style="font-size:16px;">***************************<br>APPLICATION FAILED TO START<br>***************************<br><br>Description:<br><br>The bean 'httpClient', defined in class path resource [org/springframework/cloud/openfeign/ribbon/HttpClientFeignLoadBalancedConfiguration$HttpClientFeignConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/cloud/gateway/config/GatewayAutoConfiguration

前言、Spring-Cloud家族相关 注册中心：Eureka(停止更新，不建议使用)、Zookeeper、Consul、Nacos(阿里巴巴提供的技术)，个人觉得可以优先考虑Nacos，其次是Zookeeper 服务调用：Ribbon、LoadBalancer、Feign(停止更新，不建议使用)、OpenFeign 服务降级：Hystrix(不建议)、Resilience4j(国内不流行)、Spring Cloud Sentienl(阿里巴巴提供的技术，推荐使用) 服务网关：Zuul(不建议使用)、GateWay(Spring自己的) 服务配置：Config、Nacos(推荐) 服务总线：Bus、Nacos(推荐) 建议参考网站（还是比较完整的，而且时中文文档，方便阅读）： https://www.springcloud.cc/spring-cloud-dalston.html#_features 笔者写一大堆应该也没有人有耐心看吧，直接上源码 ，希望可以帮到各位 https://gitee.com/suyujie/spring-cloud-test Alibaba相关的技术很多都在工具配置里了，不得不说，确实牛逼，解决了不少配置文件上的麻烦，各位可以到Nacos、Sentinel官网上下载工具试试吧 一、CAP原则 CAP原则又称CAP定理，分别指的是Consistency

声明：本文来源于MLDN培训视频的课堂笔记，写在这里只是为了方便查阅。 1、概念：Feign 接口服务 2、具体内容 现在为止所进行的所有的 Rest 服务调用实际上都会出现一个非常尴尬的局面，例如：以如下代码为例： Dept dept = this .restTemplate .exchange(DEPT_GET_URL + id, HttpMethod.GET, new HttpEntity<Object>( this .headers), Dept. class ) .getBody(); 所有的数据的调用和转换都必须由用户自己来完成，而我们本身不擅长这些，我们习惯的编程模式是： 通过接口来实现业务的操作，而不是通过具体的 Rest 数据。 2.1、Feign 基本使用 为了方便起见现在将“microcloud-consumer-80”模块复制为了“microcloud-consumer-feign”模块。 1、 【microcloud-consumer-feign】为了可以使用到 feign 支持，需要修改 pom.xml 配置文件，引入相关依赖包： < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-feign </

服务网关和Zuul 为什么要有服务网关： 我们都知道在微服务架构中，系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？难道要一个个的去调用吗？很显然这是不太实际的，我们需要有一个统一的接口与这些微服务打交道，这就是我们需要服务网关的原因。 我们已经知道，在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用N个微服务的接口完成一个用户请求。比如：用户查看一个商品的信息，它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等，而这些信息获取则来源于不同的微服务，诸如产品系统、价格系统、评论系统、促销系统、库存系统等等，那么要完成用户信息查看则需要调用多个微服务，这样会带来几个问题： 客户端多次请求不同的微服务，增加客户端代码或配置编写的复杂性 认证繁杂，访问每个服务都要进行一次认证 每个服务都通过http访问，导致http请求增加，效率不高拖慢系统性能 多个服务存在跨域请求问题，处理起来比较复杂 如下图所示： 我们该如何解决这些问题呢？我们可以尝试想一下，不要让前端直接知道后台诸多微服务的存在，我们的系统本身就是从业务领域的层次上进行划分，形成多个微服务，这是后台的处理方式。对于前台而言，后台应该仍然类似于单体应用一样，一次请求即可，于是我们可以在客户端和服务端之间增加一个API网关

今年，ServiceMesh(服务网格)概念在社区里头非常火，有人提出2018年是ServiceMesh年，还有人提出ServiceMesh是下一代的微服务架构基础。作为架构师，如果你现在还不了解ServiceMesh的话，是否感觉有点落伍了？那么到底什么是ServiceMesh？它诞生的背景是什么？它解决什么问题？企业是否适合引入ServiceMesh？根据近年在一线互联网企业的实践和思考，从个人视角出发，我为大家一一解答这些问题。 微服务架构的核心技术问题 在业务规模化和研发效能提升等因素的驱动下，从单块应用向微服务架构的转型(如下图所示)，已经成为很多企业(尤其是互联网企业)数字化转型的趋势。 图片发自简书App 在微服务模式下，企业内部服务少则几个到几十个，多则上百个，每个服务一般都以集群方式部署，这时自然产生两个问题(如下图所示)： 图片发自简书App 一、服务发现：服务的消费方(Consumer)如何发现服务的提供方(Provider)？ 二、负载均衡：服务的消费方如何以某种负载均衡策略访问集群中的服务提供方实例？ 作为架构师，如果你理解了这两个问题，可以说就理解了微服务架构在技术上的最核心问题。 三种服务发现模式 服务发现和负载均衡并不是新问题，业界其实已经探索和总结出一些常用的模式，这些模式的核心其实是代理(Proxy，如下图所以)，以及代理在架构中所处的位置，

前言 前情回顾 上一讲深入的讲解了Ribbon的初始化过程及Ribbon与Eureka的整合代码，与Eureka整合的类就是 DiscoveryEnableNIWSServerList ，同时在 DynamicServerListLoadBalancer 中会调用 PollingServerListUpdater 进行定时更新Eureka注册表信息到 BaseLoadBalancer 中，默认30s调度一次。 本讲目录 我们知道Ribbon主要是由3个组件组成的： ILoadBalancer IRule IPing 其中 ILoadBalancer 前面我们已经分析过了，接下来我们一起看看 IRule 和 IPing 中的具体实现。 目录如下： 负载均衡默认Server选择逻辑 Ribbon实际执行http请求逻辑 Ribbon中ping机制原理 Ribbon中其他IRule负载算法初探 说明 原创不易，如若转载 请标明来源！ 博客地址： 一枝花算不算浪漫 微信公众号：壹枝花算不算浪漫 源码分析 负载均衡默认Server选择逻辑 还记得我们上一讲说过，在Ribbon初始化过程中，默认的 IRule 为 ZoneAvoidanceRule ，这里我们可以通过debug看看，从 RibbonLoadBalancerClient.getServer() 一路往下跟