不管是商业应用仍是用户应用,在业务初期都很简单,咱们一般会把它实现为单体结构的应用。可是,随着业务逐渐发展,产品思想会变得愈来愈复杂,单体结构的应用也会愈来愈复杂。这就会给应用带来以下的几个问题:html
代码结构混乱:业务复杂,致使代码量很大,管理会愈来愈困难。同时,这也会给业务的快速迭代带来巨大挑战;开发效率变低:开发人员同时开发一套代码,很难避免代码冲突。开发过程会伴随着不断解决冲突的过程,这会严重的影响开发效率;排查解决问题成本高:线上业务发现 bug,修复 bug 的过程可能很简单。可是,因为只有一套代码,须要从新编译、打包、上线,成本很高。因为单体结构的应用随着系统复杂度的增高,会暴露出各类各样的问题。近些年来,微服务架构逐渐取代了单体架构,且这种趋势将会愈来愈流行。Spring Cloud是目前最经常使用的微服务开发框架,已经在企业级开发中大量的应用。java
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等,均可以用Spring Boot的开发风格作到一键启动和部署。Spring Cloud并无重复制造轮子,它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,经过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。nginx
设计目标git
协调各个微服务,简化分布式系统开发。面试
优缺点spring
微服务的框架那么多好比:dubbo、Kubernetes,为何就要使用Spring Cloud的呢?编程
优势:后端
产出于Spring你们族,Spring在企业级开发框架中无人能敌,来头很大,能够保证后续的更新、完善组件丰富,功能齐全。Spring Cloud 为微服务架构提供了很是完整的支持。例如、配置管理、服务发现、断路器、微服务网关等;Spring Cloud 社区活跃度很高,教程很丰富,遇到问题很容易找到解决方案服务拆分粒度更细,耦合度比较低,有利于资源重复利用,有利于提升开发效率能够更精准的制定优化服务方案,提升系统的可维护性减轻团队的成本,能够并行开发,不用关注其余人怎么开发,先关注本身的开发微服务能够是跨平台的,能够用任何一种语言开发适于互联网时代,产品迭代周期更短缺点:api
微服务过多,治理成本高,不利于维护系统分布式系统开发的成本高(容错,分布式事务等)对团队挑战大总的来讲优势大过于缺点,目前看来Spring Cloud是一套很是完善的分布式框架,目前不少企业开始用微服务、Spring Cloud的优点是显而易见的。所以对于想研究微服务架构的同窗来讲,学习Spring Cloud是一个不错的选择。缓存
Spring Cloud对于中小型互联网公司来讲是一种福音,由于这类公司每每没有实力或者没有足够的资金投入去开发本身的分布式系统基础设施,使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减小开发成本。同时,随着近几年微服务架构和Docker容器概念的火爆,也会让Spring Cloud在将来愈来愈“云”化的软件开发风格中立有一席之地,尤为是在五花八门的分布式解决方案中提供了标准化的、全站式的技术方案,意义可能会堪比当年Servlet规范的诞生,有效推动服务端软件系统技术水平的进步。
Spring Cloud的子项目,大体可分红两类,一类是对现有成熟框架"Spring Boot化"的封装和抽象,也是数量最多的项目;第二类是开发了一部分分布式系统的基础设施的实现,如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。
集中配置管理工具,分布式系统中统一的外部配置管理,默认使用Git来存储配置,能够支持客户端配置的刷新及加密、解密操做。
Netflix OSS 开源组件集成,包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。
Eureka:服务治理组件,包括服务端的注册中心和客户端的服务发现机制;Ribbon:负载均衡的服务调用组件,具备多种负载均衡调用策略;Hystrix:服务容错组件,实现了断路器模式,为依赖服务的出错和延迟提供了容错能力;Feign:基于Ribbon和Hystrix的声明式服务调用组件;Zuul:API网关组件,对请求提供路由及过滤功能。
用于传播集群状态变化的消息总线,使用轻量级消息代理连接分布式系统中的节点,能够用来动态刷新集群中的服务配置。
基于Hashicorp Consul的服务治理组件。
安全工具包,对Zuul代理中的负载均衡OAuth2客户端及登陆认证进行支持。
Spring Cloud应用程序的分布式请求链路跟踪,支持使用Zipkin、HTrace和基于日志(例如ELK)的跟踪。
轻量级事件驱动微服务框架,可使用简单的声明式模型来发送及接收消息,主要实现为Apache Kafka及RabbitMQ。
用于快速构建短暂、有限数据处理任务的微服务框架,用于向应用中添加功能性和非功能性的特性。
基于Apache Zookeeper的服务治理组件。
API网关组件,对请求提供路由及过滤功能。
基于Ribbon和Hystrix的声明式服务调用组件,能够动态建立基于Spring MVC注解的接口实现用于服务调用,在Spring Cloud 2.0中已经取代Feign成为了一等公民。
Spring Cloud是一个由许多子项目组成的综合项目,各子项目有不一样的发布节奏。为了管理Spring Cloud与各子项目的版本依赖关系,发布了一个清单,其中包括了某个Spring Cloud版本对应的子项目版本。为了不Spring Cloud版本号与子项目版本号混淆,Spring Cloud版本采用了名称而非版本号的命名,这些版本的名字采用了伦敦地铁站的名字,根据字母表的顺序来对应版本时间顺序,例如Angel是第一个版本,Brixton是第二个版本。当Spring Cloud的发布内容积累到临界点或者一个重大BUG被解决后,会发布一个"service releases"版本,简称SRX版本,好比Greenwich.SR2就是Spring Cloud发布的Greenwich版本的第2个SRX版本。目前Spring Cloud的最新版本是Hoxton。
注意:Hoxton版本是基于SpringBoot 2.2.x版本构建的,不适用于1.5.x版本。随着2019年8月SpringBoot 1.5.x版本中止维护,Edgware版本也将中止维护。
SpringBoot专一于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,
为各个微服务之间提供,配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot能够离开SpringCloud独立使用开发项目, 可是SpringCloud离不开SpringBoot ,属于依赖的关系
SpringBoot专一于快速、方便的开发单个微服务个体,SpringCloud关注全局的服务治理框架。
(1)与分布式系统相关的复杂性 - 这种开销包括网络问题,延迟开销,带宽问题,安全问题。
(2)服务发现 - 服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录,在该目录中注册服务,而后可以查找并链接到该目录中的服务。
(3)冗余 - 分布式系统中的冗余问题。
(4)负载平衡 - 负载平衡改善跨多个计算资源的工做负荷,诸如计算机,计算机集群,网络链路,中央处理单元,或磁盘驱动器的分布。
(5)性能问题 - 因为各类运营开销致使的性能问题。
(6)部署复杂性 - DevOps的要求。
当咱们开始一个项目时,咱们一般在属性文件中进行全部的配置。随着愈来愈多的服务开发和部署,添加和修改这些属性变得更加复杂。有些服务可能会降低,而某些位置可能会发生变化。手动更改属性可能会产生问题。Eureka 服务注册和发现能够在这种状况下提供帮助。因为全部服务都在 Eureka 服务器上注册并经过调用 Eureka 服务器完成查找,所以无需处理服务地点的任何更改和处理。
(1)服务调用方式:dubbo是RPC,Spring Cloud是Rest Api。
(2)注册中心:dubbo 是zookeeper,Spring Cloud能够是zookeeper或其余。
(3)服务网关:dubbo自己没有实现,只能经过其余第三方技术整合,springcloud有Zuul路由网关,做为路由服务器,进行消费者的请求分发,springcloud支持断路器,与git完美集成配置文件支持版本控制,事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。
(4)架构完整度:Spring Cloud包含诸多微服务组件要素,完整度上比Dubbo高。
在计算中,负载平衡能够改善跨计算机,计算机集群,网络连接,中央处理单元或磁盘驱动器等多种计算资源的工做负载分布。负载平衡旨在优化资源使用,最大化吞吐量,最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会经过冗余来提升可靠性和可用性。负载平衡一般涉及专用软件或硬件,例如多层交换机或域名系统服务器进程。
Hystrix 是一个延迟和容错库,旨在隔离远程系统,服务和第三方库的访问点,当出现故障是不可避免的故障时,中止级联故障并在复杂的分布式系统中实现弹性。
一般对于使用微服务架构开发的系统,涉及到许多微服务。这些微服务彼此协做。
思考如下微服务
假设若是上图中的微服务 9 失败了,那么使用传统方法咱们将传播一个异常。但这仍然会致使整个系统崩溃。
随着微服务数量的增长,这个问题变得更加复杂。微服务的数量能够高达 1000.这是 hystrix 出现的地方 咱们将使用 Hystrix 在这种状况下的 Fallback 方法功能。咱们有两个服务 employee-consumer 使用由 employee-consumer 公开的服务。
简化图以下所示
如今假设因为某种缘由,employee-producer 公开的服务会抛出异常。咱们在这种状况下使用 Hystrix 定义了一个回退方法。这种后备方法应该具备与公开服务相同的返回类型。若是暴露服务中出现异常,则回退方法将返回一些值。
因为某些缘由,employee-consumer 公开服务会引起异常。在这种状况下使用Hystrix 咱们定义了一个回退方法。若是在公开服务中发生异常,则回退方法返回一些默认值。
若是 firstPage method() 中的异常继续发生,则 Hystrix 电路将中断,而且employee使用者将一块儿跳过 firtsPage 方法,并直接调用回退方法。断路器的目的是给firstPage方法或firstPage方法可能调用的其余方法留出时间,并致使异常恢复。可能发生的状况是,在负载较小的情况下,致使异常的问题有更好的恢复机会 。
Feign 是受到 Retrofit,JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。
Feign 的第一个目标是将约束分母的复杂性统一到 http apis,而不考虑其稳定性。
在 employee-consumer 的例子中,咱们使用了 employee-producer 使用 REST模板公开的 REST 服务。
可是咱们必须编写大量代码才能执行如下步骤
(1)使用功能区进行负载平衡。
(2)获取服务实例,而后获取基本 URL。
(3)利用 REST 模板来使用服务。前面的代码以下
以前的代码,有像 NullPointer的几率,并非最优的。咱们将看到如何使用 Netflix Feign 使调用变得更加简洁。并且若是当 Netflix Ribbon 依赖关系也在类路径中,那么 Feign 默认也会负责负载平衡。
考虑如下状况:咱们有多个应用程序使用 Spring Cloud Config 读取属性,而Spring Cloud Config 从 GIT 读取这些属性。
下面的例子中多个员工生产者模块从 Employee Config Module 获取 Eureka 注册的财产。
若是假设 GIT 中的 Eureka 注册属性更改成指向另外一台 Eureka 服务器,会发生什么状况。在这种状况下,咱们将不得不从新启动服务以获取更新的属性。
还有另外一种使用执行器端点/刷新的方式。可是咱们将不得不为每一个模块单独调用这个 url。例如,若是 Employee Producer1 部署在端口 8080 上,则调用 localhost:8080/refresh。一样对于 Employee Producer2 localhost8081/refresh 等等。这又很麻烦。这就是 Spring Cloud Bus 发挥做用的地方。
Spring Cloud Bus 提供了跨多个实例刷新配置的功能。所以,在上面的示例中,若是咱们刷新 Employee Producer1,则会自动刷新全部其余必需的模块。若是咱们有多个微服务启动并运行,这特别有用。这是经过将全部微服务链接到单个消息代理来实现的。不管什么时候刷新实例,此事件都会订阅到侦听此代理的全部微服务,而且它们也会刷新。能够经过使用端点/总线/刷新来实现对任何单个实例的刷新。
当一个服务调用另外一个服务因为网络缘由或自身缘由出现问题,调用者就会等待被调用者的响应 当更多的服务请求到这些资源致使更多的请求等待,发生连锁效应(雪崩效应)
断路器有彻底打开状态:一段时间内 达到必定的次数没法调用 而且屡次监测没有恢复的迹象 断路器彻底打开 那么下次请求就不会请求到该服务
半开:短期内 有恢复迹象 断路器会将部分请求发给该服务,正常调用时 断路器关闭
关闭:当服务一直处于正常状态 能正常调用
在分布式系统中,因为服务数量巨多,为了方便服务配置文件统一管理,实时更新,因此须要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件spring cloud config ,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中。在spring cloud config 组件中,分两个角色,一是config server,二是config client。
使用通常也是三步:
(1)添加pom依赖
(2)配置文件添加相关配置
(3)启动类添加注解@EnableConfigServer
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架,取代Zuul网关。网关做为流量的控制,在微服务系统中有着很是做用,网关常见的功能有路由转发、权限校验、限流控制等做用。
它使用了一个RouteLocatorBuilder的bean去建立路由,除了建立路由,RouteLocatorBuilder也可让你添加各类predicates和filters,predicates断言的意思,顾名思义就是根据具体的请求的规则,由具体的route去处理,filters是各类过滤器,用来对请求作各类判断和修改。
1.远程过程调用(Remote Procedure Invocation):
也就是咱们常说的服务的注册与发现
直接经过远程过程调用来访问别的service。
优势:
简单,常见,由于没有中间件代理,系统更简单
缺点:
只支持请求/响应的模式,不支持别的,好比通知、请求/异步响应、发布/订阅、发布/异步响应
下降了可用性,由于客户端和服务端在请求过程当中必须都是可用的
2.消息:
使用异步消息来作服务间通讯。服务间经过消息管道来交换消息,从而通讯。
优势:
把客户端和服务端解耦,更松耦合
提升可用性,由于消息中间件缓存了消息,直到消费者能够消费
支持不少通讯机制好比通知、请求/异步响应、发布/订阅、发布/异步响应
缺点:
消息中间件有额外的复杂
优势
开发中,两种开发模式
先后端分离
全栈工程师
缺点
1.ZooKeeper保证的是CP,Eureka保证的是AP
ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,可是选举期间不可用的
Eureka各个节点是平等关系,只要有一台Eureka就能够保证服务可用,而查询到的数据并非最新的
自我保护机制会致使
Eureka再也不从注册列表移除因长时间没收到心跳而应该过时的服务
Eureka仍然可以接受新服务的注册和查询请求,可是不会被同步到其余节点(高可用)
当网络稳定时,当前实例新的注册信息会被同步到其余节点中(最终一致性)
Eureka能够很好的应对因网络故障致使部分节点失去联系的状况,而不会像ZooKeeper同样使得整个注册系统瘫痪
2.ZooKeeper有Leader和Follower角色,Eureka各个节点平等
3.ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
4.Eureka本质上是一个工程,而ZooKeeper只是一个进程
当Eureka Server 节点在短期内丢失了过多实例的链接时(好比网络故障或频繁启动关闭客户端)节点会进入自我保护模式,保护注册信息,再也不删除注册数据,故障恢复时,自动退出自我保护模式。
答:** Feign是一个受到Retrofit,JAXRS-2.0和WebSocket启发的java到http客户端绑定器。Feign的第一个目标是下降将Denominator统一绑定到http apis的复杂性,不管其是否安宁。员工 - 消费者中的先前示例咱们使用REST模板 使用员工生产者公开的REST服务
可是咱们必须编写大量代码来执行如下操做 -
使用功能区进行负载均衡。
获取服务实例,而后获取基本URL。
使用REST模板来消费服务
疯狂创客圈 - Java高并发研习社群,为你们开启大厂之门