eureka

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项 。 CAP的证明 上图是我们证明CAP的基本场景，网络中有两个节点N1和N2，可以简单的理解N1和N2分别是两台计算机，他们之间网络可以连通，N1中有一个应用程序A，和一个数据库V，N2也有一个应用程序B2和一个数据库V。现在，A和B是分布式系统的两个部分，V是分布式系统的数据存储的两个子数据库。 在满足一致性的时候，N1和N2中的数据是一样的，V0=V0。在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。 上图是分布式系统正常运转的流程，用户向N1机器请求数据更新，程序A更新数据库Vo为V1，分布式系统将数据进行同步操作M，将V1同步的N2中V0，使得N2中的数据V0也更新为V1，N2中的数据再响应N2的请求。 这里，可以定义N1和N2的数据库V之间的数据是否一样为一致性；外部对N1和N2的请求响应为可用性；N1和N2之间的网络环境为分区容错性。 这是正常运作的场景，也是理想的场景，然而现实是残酷的，当错误发生的时候，一致性和可用性还有分区容错性，是否能同时满足，还是说要进行取舍呢？

6.1 zuul 简介 spring cloud zuul API 网关是一个智能的应用程序,它的定义类似于面向对象设计模式中的 faced 门面模式,它的存在就像是整个微服务架构应用的门面一样,所有的外部客户端访问都需要经过它来进行调度与过滤.它除了要实现请求路由,负载均衡,校验过滤等功能之外,还需要更多的能力,比如与服务治理框架的结合,请求转发时的熔断机制,服务的聚合等一些列高级功能. 首先对于路由规则与服务实例的维护问题. spring cloud zuul 通过与 spring cloud eureka 进行整合,将自身注册为 eureka 服务治理下的应用,同时从 eureka 中获取所有的服务实例. 这样的设计非常巧妙的将服务治理体系中维护的实例信息利用起来,使得维护服务实例的工作交给了服务治理框架自动完成,不需要人工介入. 而对于路由规则的维护,zuul默认会将通过以服务名作为 ContextPath 的方式来路由映射,大部分情况下,这样的默认设置已经可以实现我们大部分的路由需求,除了一些特殊情况还需要做一些特别的配置. 其次对于类似签名校验,登录校验,在微服务架构中的冗余问题.理论上说,这些校验逻辑在本质上与微服务应用自身的业务并没有太大的关系,所以它们完全可以独立成一个单独的服务存在,只是它们被剥离与独立出来之后,并不是给各个微服务使用,而是在 API

4.1 客服端负载均衡 Ribbon 通过上一篇《Spring Cloud构建微服务架构：服务消费》，我们已经学会如何通过LoadBalancerClient接口来获取某个服务的具体实例，并根据实例信息来发起服务接口消费请求。但是这样的做法需要我们手工的去编写服务选取、链接拼接等繁琐的工作，对于开发人员来说非常的不友好。所以，下来我们看看Spring Cloud中针对客户端负载均衡的工具包：Spring Cloud Ribbon。 Spring Cloud Ribbon Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。 当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务实例列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。 而当Ribbon与Consul联合使用时，ribbonServerList会被ConsulServerList来扩展成从Consul获取服务实例列表

3.1 服务注册于发现 由于Spring Cloud为服务治理做了一层抽象接口，所以在Spring Cloud应用中可以支持多种不同的服务治理框架，比如：Netflix Eureka、Consul、Zookeeper。在Spring Cloud服务治理抽象层的作用下，我们可以无缝地切换服务治理实现，并且不影响任何其他的服务注册、服务发现、服务调用等逻辑。 所以，下面我们通过介绍两种服务治理的实现来体会Spring Cloud这一层抽象所带来的好处。 Spring Cloud Eureka Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。而Spring Cloud Netflix项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。通过一些简单的注解，开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路由（Zuul），客户端负载均衡（Ribbon）等。 创建“服务注册中心” 创建一个spring cloud 子模块 Spring Boot工程，命名为eureka-server，并在build.gradle中引入需要的依赖内容：

客户端负载均衡：Spring Cloud Ribbon 一、负载均衡概念 负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡对系统的高可用性、 网络压力的缓解和处理能力的扩容的重要手段之一。通常所说的负载均衡指的是服务端负载均衡，分为 硬件负载均衡和软件负载均衡，服务端负载均衡架构方式： 负载均衡都会维护一个下挂可用的服务端清单，并通过心跳检测来剔除故障的服务端节点。 客户端负载均衡与服务端负载均衡最大的不同点在于服务清单的位置，在客户端负载均衡 中，所有的客户端节点都维护着自己要访问的服务端清单，这些清单都来自于服务注册中心。　　 二、快速入门 代码详情见：https://gitee.com/tangjiapi/RibbonDemon.git 三、Spring Cloud Ribbon 实战 1.Ribbon负载均衡策略与自定义配置 在Ribbon中有丰富的负载均衡策略可供选择： 策略类 命名 描述 RandomRule 随机策略 随机选择server RoundRobinRule 轮询策略 按顺序选择server(默认策略) RetryRule 重试策略 在一个配置时间段内当选择server不成功，则一直尝试选择一个可用的server BestAvailableRule 最低并发策略 逐个考察server,如果server断路器打开，则忽略

简介 当我们的业务系统越来越庞大复杂的时候，各种配置就会层出不群。一旦配置修改了，那么我们就是必须修改后停服务，然后再上线，如果服务少，我们可以手动来操作，如果是成千上百的服务，如果是手动操作，肯定就不合适宜了，然后SpringCloudConfig就出来了，就是我们通常意义上的配置中心，把应用原本放在本地文件的配置抽取出来放在中心服务器，从而能够提供更好的管理、发布能力。 SpringCloudConfig分服务端和客户端，服务端负责将git（svn或本地文件系统）中存储的配置文件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST方法触发各自的 /refresh 。 SpringCloudBus通过一个轻量级消息代理连接分布式系统的节点。这可以用于广播状态更改（如配置更改）或其他管理指令。SpringCloudBus提供了通过POST方法访问的endpoint /bus/refresh ，这个接口通常由git的webhook功能调用，用以通知各个SpringCloudConfig的客户端去服务端更新配置，本节就讲怎么搭建一套自动刷新的spring cloud config 一、创建模块 模块结构如下： 二、maven聚合模块microservice-config的pom.xml文件

Ribbon配置初步 1.修改microservicecloud-consumer-dept-80工程 2.修改pom.xml文件 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.atguigu.springcloud</groupId> <artifactId>microservicecloud</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <artifactId>microservicecloud-consumer-dept-80</artifactId> <description>部门微服务消费者</description> <dependencies> <dependency><!-- 自己定义的api --> <groupId>com

Git+Jenkins+Shell实现持续部署 ** 本文主要实现了在Centos7平台使用Git+Jenkins+Shell实现SpringCloud项目的持续部署,当然如果是使用其他的版本管理器如SVN也是可以参考本文进行配置，教程很详细每个步骤都会讲解，如有遗漏或者错误欢迎大家指正。** 1.安装Jenkins 因为Jenkins安装比较简单，只是一个war包安装Tomcat部署上去进行配置即可，同理部署需要安装Git和Maven直接安装好就行 1.1安装所需环境 按顺序安装好Jdk,Maven,Tomcat,Git 1.2启动服务 然后直接将jenkins.war放到tomcat的webapps目录下启动tomcat即可 1.3获取密码 启动后打开浏览输入地址：http://ip8080/jenkins访问Jenkins,会提示第一次访问需要密码 输入cat /root/.jenkins/secrets/initialAdminPassword，然后粘贴密码 1.4 JenKins离线 输入密码后会提示你的Jenkins实例似已离线。 直接搜索文件 [root@localhost ~]# find / -name "hudson.model.UpdateCenter.xml" /root/.jenkins/hudson.model.UpdateCenter.xml

 我的博客： 程序员笑笑生 ,欢迎浏览博客！  上一章 SpringCloud基础教程(五)-配置中心热生效和高可用 当中,我们对配置中心进行进行了深入的了解，本章将继续微服务架构的深入学习，了解在微服务中是如何做到负载均衡的。 前言  简单来讲，Ribbon是Netflix发布的开源项目，主要的功能是提供客户端的软件负载均衡算法。它可以在客户端配置服务端类别，然后轮询请求以实现负载均衡。  当项目引入Eureka依赖后，会自动的引入ribbon的依赖，当然我们可以显示的引入ribbon依赖。在集成Eureka时，DiscoveryEnabledNIWSServerList重写了Ribbon的服务列表，在com.netflix.ribbon:ribbon-eureka:2.3.0模块我们可以看到，同时使用 NIWSDiscoveryPing取代IPing： 一、Ribbo快速使用  当前的实例我们会涉及到Eureka注册中心，两个服务提供者(server-provider),一个服务消费者（server-consumer）,首先，我们启动两个服务提供者，并注册到Eureka，服务提供接口如下： @RestController public class RibbonController { @RequestMapping("/sayHello") public String

父应用 GroupId: top.bing Artifact: battle Dependencies: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.4.RELEASE</version> </parent> <properties> <spring-cloud.version>Greenwich.RELEASE</spring-cloud.version> </properties> <dependencies> <!-- lombok 工具通过在代码编译时期动态的将注解替换为具体的代码, IDEA 需要添加 lombok 插件 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.16.18</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId>