微服务框架有哪些

SpringCloud入门简述

微服务，是一个小型的服务，也是一种设计理念，将一个大型繁杂的系统拆分为多个小型的服务，进行独立部署，这些服务在独立进程中运行，通过特定的协议进行通信 优点： 缺点： 在服务通信性能上RPC更强，但是Rest更为灵活 SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。 Spring Cloud专注于为典型的用例提供良好的开箱即用体验，并为其他用例提供扩展性机制。 参考地址： Eureka是Netflix开发的基于Rest的服务发现框架，SpringCloud基于此进行二次封装，实现服务的管理。 创建一个Eureka服务：https://www.cnblogs.com/william-m/p/15991511.html 如果没有Eureka，如何进行服务之间的调用? 使用Rest进行调用，先将RestTemplate注册到Bean，然后： Eureka遵循的是AP原则，Eureka各个节点都是平等的，部分服务节点的下线不会影响正常服务的调用，只要该服务还剩下一个节点在线就可以进行正常的服务访问，即保证了服务可用，但是并不能保证查询到的信息是最新的。Zookeeper的CP原则与之不同，Zookeeper会有一个master节点来保证一致性，一旦master节点挂掉，剩余的节点会重新选举一个leader，而选择的过程需要时间，这期间会使得该服务瘫痪，所以需要满足高可用的话该情况是不能够容忍的。 Spring Cloud Ribbon是一个基于HTTP和TCP的 客户端负载均衡 工具，基于Netflix Ribbon实现，通过轮询、随机等算法选择一个可用服务。 目的：将用户的请求平摊的分配到多个服务上，实现高可用 最大区别：服务清单所存储的位置 客户端先发送请求到负载均衡服务器，然后由负载均衡服务器通过负载均衡算法，在众多可用的服务器之中选择一个来处理请求。 客户端自己维护一个可用服务器地址列表，在发送请求前先通过负载均衡算法选择一个将用来处理本次请求的服务器，然后再直接将请求发送至该服务器。 逻辑时序：RestTemplate发起请求 负载均衡器拦截器拦截 LoadBalanceClient获取ILoadBalance 获取服务列表 根据负载均衡器选择一个server 发起请求 记录调用信息 Ribbon基于HTTP和TCP客户端的负载均衡器可以自己构建HTTP请求，使用RestTemplate发送服务 Feign基于Ribbon进行改进，采用接口的方式，将需要调用的服务的方法定义成抽象方法 Consumer应用 启动类 为了调用Product应用服务的接口类 Product应用 controller Hystrix是一个服务容错与保护的组件，用于 服务降级 、 服务熔断 、 服务限流 等等，能够保证在其中一个服务出现问题的时候，不会出现级联故障，防止雪崩，提高分布式服务的健壮性。 将某些服务停掉会i这不进行业务处理，释放资源来维持主要服务的功能。 应对服务雪崩的一种保险措施，是微服务的链路保护机制，是服务降级的一种特殊处理方式。 为了应对某个服务故障的情况，保证系统的整体可用性，熔断器会切断对该服务的请求，返回一个比较友好的错误响应，直到服务恢复正常 熔断机制的三种状态： 示例： 熔断：直接切断服务的调用 降级：牺牲非核心业务保证核心服务的正常 限流：服务访问量达到阈值后拒绝多余的调用 Zuul是一个微服务网关。网关：是一个网络系统的前置入口。也就是说要想访问一个有网关的网络系统请求相应的服务，需要先进入网关，然后路由到相应的服务。 通常是组成一个系统的微服务很多、或者有权限要求时需要用到网关。 Zuul提供一个过滤器，父类为ZuulFilter，用来过滤代理请求，提供额外的功能逻辑（这点类似于AOP），包括前置过滤、路由后过滤、后置过滤、异常过滤。 ZuulFilter包含的抽象方法：filterType、filterOrder、shouldFilter、run 当微服务众多的时候，想要管理各个服务的配置时过于繁杂，SpringCloud Config则可以用来对每个微服务的配置进行集中的管理。可以实现权限管控、灰度发布、版本管理、格式检验、安全配置等。 作用： 特点： 文章来自https://www.cnblogs.com/william-m/p/16153557.html

SpringCloud

微服务的优点:

1易于开发和维护,只需要关注每个服务的单独业务即可,不需要关心其他

2启动较快

3局部修改容易部署

4技术栈不受限

5按需伸缩

微服务的缺点:

1运维成本较高

3分布式复杂

4接口调整成本高

SpringCloud 的特点：

1约定优于配置


2开箱即用、快速启动

3适用于各种环境

4轻量级的组件,比如 服务发现组件 Eureka  ribbon  zuul

5组件的支持很丰富，功能很齐全 包含:配置中心,注册中心,智能路由

6选型中立 比如服务发现组件,不限制必须使用某一种,例如 Eureka,Zookeeper,Consul

Eureka作为服务注册中心，Eureka比Zookeeper好在哪里

著名的CAP理论指出，在一个分布式系统中， 一致性 （Consistency）、 可用性 （Availability）、分区容忍性（Partition tolerance 分区相当于对通信的时限要求）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。


一致性（C）：在 分布式系统 中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后， 集群 整体是否还能响应 客户端 的读写请求。（对数据更新具备高可用性）

分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。

由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

传统分布式的模式的缺点

传统式是通过restTemplate硬编码硬性指定ip和端口一旦ip和端口改变name系统直接瘫痪，这个ip和端口改变是不可避免的。

springcloud是通过eureka作为服务的发现也就是注册中心就可以解决这个问题




eureka的集群：

  就是多个服务之间互相依赖你中有我我中有你

失效剔除和自我保护


默认每间隔60s服务就会通过心跳检测，检测超过90s没有响应的服务就会剔除，这时候在eureka的面板上就会有提示。



Ribbin 负载均衡

工作原理：

第一步先选择 Eureka Server, 它优先选择在同一个Zone且负载较少的Server；第二步再根据用户指定的策略

负载均衡的侧率：

1默认轮训，

2，随机

3，根据响应速度

开启默认负载均衡只需要价格注解LoadBalanced

@Bean


@LoadBalanced

public RestTemplate restTemplate() {

    return new RestTemplate(new OkHttp3ClientHttpRequestFactory());

}

修改调用方式，不再手动获取ip和端口，而是直接通过服务名称调用：

springcloud原理是什么？

springcloud原理如下和组成部分：Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务Spring Cloud是一系列微软服务框架的有序集合。注意：集合与集合的元素是两个不同的概念，教科书中是通过描述给出的，这与平面几何中的点与直线的概念类似。集合中的元素具有确定性、互异性和无序性({a,b}与{b,a}表示同一个集合)。集合具有两方面的意义，即：凡是符合条件的对象都是它的元素;只要是它的元素就必须符号条件。

springcloud是什么

微服务和springcloud的关系微服务是一种架构思想，springcloud是一套利于实现微服务架构的技术。相互之间没有必然的联系。数据访问层提供与数据存储层的交互，可以使用DAO设计模式或者对象-关系映射解决方案(如Hibernate、OJB或iBATIS)实现。SpringBoot可以离开SpringCloud独立开发项目，SpringCloud很大的一部分是基于SpringBoot来实现，属于依赖的关系。下面是SpringCloud的整体架构图：注册中心可以说是微服务架构中的“通讯录”，他记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其他服务时，就在这里找到对应服务的地址，进行调用。springcloud原理是什么?SpringClientFactory是不是感觉跟OpenFeign中的FeignContext很像，其实两个的作用是一样的，SpringClientFactory也继承了NamedContextFactory，实现了配置隔离，同时也在构造方法中传入了每个容器默认的配置类RibbonClientConfiguration。SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。SpringCloud是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。你所理解的SpringCloud是什么?1、SpringCloud是Pivotal提供的用于简化分布式系统构建的工具集。SpringCloud引入了云平台连接器（CloudConnector）和服务连接器（ServiceConnector）的概念。2、SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。3、SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。4、SpringCloud是一系列框架的有序集合（框架集），他利用SpringBoot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。5、SpringCloud是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。SpringCloud入门简述1、SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。2、SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。3、不像Spring（SpringFramework），大体上能够理解为它是一个管理bean的容器。也不想SpringBoot，可以理解为它是加强版的Spring，集成了SSM和其它一些框架，并且大量支持和推荐注解开发。SpringCloud微服务组件介绍1、SpringCloud是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。2、SpringCloud与SpringBootSpringBoot可以说是微服务架构的核心技术之一。通过在SpringBoot应用中添加SpringMVC依赖，就可以快速实现基于REST架构的服务接口，并且可以提供对HTTP标准动作的支持。3、当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。这个还是静态的，得配合SpringCloudBus实现动态的配置更新。4、SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。SpringCloud和Dubbo的区别是什么?springcloud和dubbo的最大区别：springcloud抛弃了dubbo的rpc通信，采用的是基于http的rest方式。SpringCloud是一系列微服务框架的有序集合，而Dubbo有2中常见理解，一种是狭义的理解，一种是广义的。dubbo和springcloud的定位不同。Dubbo的定位始终是一款RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案。dubbo和springcloud区别是SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。严格来说，这两种方式各有优劣。虽然在一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。