springcloud学习总结

1:集中式系统：也叫单体应用，就是把所有的程序，功能，模块集中到一个项目总，部署到一台服务器中，对外提供服务

2:分布式系统 就是把所有的程序，功能拆分成不同的子系统，部署在不同的服务器上，这些子系统相互协作对外提供服务，而对用户而言是不知道后台是多个子系统和多台服务器在提供服务，在使用上和集中式系统一样。

3：分布式背景 用户量增加，功能增加 很多人维护一个系统，开发、测试，上线都会造成很大问题。所以按照业务维度进行应用拆分 各个服务之间相互吊笼完成某一项业务功能。

4，微服务架构属于分布式架构的范畴  简单的说微服务是系统架构上的一种设计风格，它的主旨就是将一个原本独立的系统拆分成多个小型服务，这种小型服务都在各自独立的进程中运行，服务之间通过基于http的restful Api进行通信协作。

被拆分后的每一个小型服务都围绕着系统中的某一样业务功能进行构建，并且每个服务都是一个独立的项目，可以进行独立的测试，开发和部署

5：每个服务独立的开发和部署，因此每个服务的更新不会影响其他服务

可以精准的监控每个服务的资源消耗情况，进行性能容量的评估，通过压力测试，可以发现各个服务之间的性能瓶颈所在。

独立开发减少代码冲突

微服务可以使用不同的变成语言进行开发。

缺点：微服务架构增加了系统维护，部署的难度导致一些功能模块或代码不能复用

随着系统规则的日渐增长，微服务在一定程度上导致系统越来越复杂，增加了集成测试的复杂度。

随着微服务的增多，数据的一致性问题，服务之间的通信成本等都凸显了出来。

6：springcloud有强大的技术背景 和活跃的社区

7：springcloud是一个一站式的开发分布式系统的框架，为开发者提供了一系列的构建分布式系统的工具集，

为开发人员提供了快速构建分布式系统中一些常见模式的工具比如配置管理，服务发现，断路器，智能路由，微代理，控制总线，全局锁，决竞选，分布式回话和集群状态管理等

开发分布式系统都需要解决一系列共同关心的问题，而使用springcloud可以快速的实现这些分布式开发共同关心的问题，并能方便的在任何分布式环境中部署与运行

springcloud成为目前进行微服务架构的优先选择工具

springcloud基于springboot框架

8：

dubbo RPC 调用返回对象

http调用 返回json

9：SpringCloud提供了多种注册与发现中心，eureka Zookeeper Consul 

spring对eureka支持的最好。其次是Consul 最次  Zookeeper

注册发现： 

服务注册： 将服务所在主机，端口，版本号 ，通信协议，等信息记录到注册中心中

服务发现：服务消费者向注册中心请求已经登记的服务列表，然后得到某个服务的主机，端口，版本号 ，通信协议等信息， 从而实现对具体服务的调用

10：CAP理论

C一致性  A可用性 P分区容错性

P必须满足  因此只能在A和C之间权衡 

zookeeper ：  集群中只有一个主 只能通过主 去访问 ，当主机宕机集群就不可用 ，从机之间通过选举 确立新的主机 ，但是选举是需要时间的 ，因此在此期间集群是不可用 ，和redis的哨兵模式类型 ，原来的主机重启之后变成新的从节点   可以保证CP 数据一致性

eureka ：保证AP 多个节点每个节点都是平等，相互复制相互备份，一个节点宕机，不影响整个集群的使用，剩余一个节点 集群都可以正常使用。在数据同步的过程中 是需要时间的 在没有同步之前 不同节点的数据是不一致的 

11.当eureka里面有多个同种服务，使用ribbon进行负载均衡， 客户端负载均衡

ribbon的使用

▪️服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。

▪️服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用。

12:搭建eureka集群

eureka不注册自己 但是可以在其他eureka服务中注册自己

eureka的高可用实际上就是把自己当做服务注册到其它注册中心， 这样就会得到一个相互注册的服务中心，进而实现服务清单的互相同步。

13：DS Replicas  eureka9100

由以上代码和展示，我总结出，是说明该服务器，从哪里同步数据。

14#同时指定多个eureka的注册中心地址 ，springcloud 就会根据底层算法，选择性的将数据注册到某一注册中心中

eureka.client.serviceUrl.defaultZone=http://eureka9100:9100/eureka/,http://eureka9200:9200/eureka/

15：eureka client 会不停的向注册中心发送心跳请求，

自我保护机制是eureka注册中心的重要特性，当eureka注册中心进入自我保护模式时在eureka server 首页会输出一下的警告信息

在没有eureka自我保护情况下，如果eureka server 在一定时间内没有接收到某个微服务实例的心跳，eureka server 将会注销该实例，但是当网络发生分区故障时，那么微服务与eureka server 之间将无法正常通信，以上行为就会变的很危险，因为微服务本身是正常的，此时不应该销毁这个微服务，如果没有自我保护机制，那么eureka server 就会将此服务注销掉。

eureka 通过自我保护模式，来解决这个问题，当eureka server 节点在短时间内 丢失过多客户端时，那么就会把这个微服务节点进行保护，一旦进入自我保护模式，eureka server 就会保护服务注册表中的信息，不删除服务注册中的数据，当网络故障恢复后，该eureka server 节点会在自动退出自我保护模式。

所以自我保护模式，是一种应对网络异常的安全保护措施，他的架构哲学就是能可保护所有的微服务，也不盲目注销任何健康的微服务，

也可以使用eureka.server.enable-self-preservation =false 禁用自我保护机制

16.配置自我保护机制  建议在生产中一直开启自我保护机制

#此配置建议只试用开发和测试环境
#心跳间隔时间,默认是30秒
#org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean.leaseRenewalIntervalInSeconds
eureka.instance.leaseRenewalIntervalInSeconds=2
#最后一次心跳时间后leaseExpirationDurationInSeconds秒就认为是下线了，默认是90秒
#org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean.leaseExpirationDurationInSeconds
eureka.instance.leaseExpirationDurationInSeconds=6

17：负载均衡

我们平时说的负载均衡指的是服务端负载均衡，指的是硬件负载均衡

硬件负载均衡：比如F5, 深信服，Array等

软件负载均衡，比如NGINX，LVS，HAProxy等

硬件负载均衡或是软件负载均衡，他们都会维护一个可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送

请求到负载均衡设备的时候，该设备按照某种算法(比如轮回，权重，最小连接数等)从维护的可用服务端清单中取出一台服务端的地址，然后进行转发。

Ribbon 是客户端负载均衡，只是提供了一套负载均衡的算法，是一个基于http和TCP的客户端负载均衡工具。支持多种负载均衡算法，

（1）Nginx服务器端负载均衡：nginx是客户端所有请求统一交给nginx，由nginx进行实现负载均衡请求转发，属于服务器端负载均衡。
既请求有nginx服务器端进行转发。

（2）Ribbon客户端负载均衡：Ribbon是从eureka注册中心服务器端上获取服务注册信息列表，缓存到本地，让后在本地实现轮训负载均衡策略。
既在客户端实现负载均衡。

（3）应用场景的区别：Nginx适合于服务器端实现负载均衡 比如Tomcat ，Ribbon适合与在微服务中RPC远程调用实现本地服务负载均衡，比如Dubbo、SpringCloud中都是采用本地负载均衡。

18负载均衡策略

RandomRule 随机策略

1. @Bean //全局负载均衡策略

2. public IRule ribbonRule(){

3. return new RoundRobinRule();

4. }

19Hystrix定义：

1:在分布式的环境中, 一些分布式服务会不可避免的出现的依赖项目发生错误的情况。 Hystrix 就是一个可以通过使用 延时策略 和 故障容错逻辑 帮助您管理控制这些__分布式服务之间交互__的一个库. Hystrix 通过 服务隔离,停止故障服务级联调用并提供应急（最常见的各种no fallback available异常出自这里）计划来改善系统的弹性.

2.服务降级：当某个服务被熔断后，不能正常给用户返回结果，因此在服务熔断后会自动调用服务的降级方法，来为用户返回一个本地响应信息。这个信息不是真正的处理结果。

什么是服务降级？当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。