什么是微服务？
微服务架构是一种架构风格和架构思想，它倡导我们在传统软件应用架构的基础上，将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API，可以独立承担对外服务的职责，通过此种思想方式所开发的软件服务实体就是“微服务”，而围绕着微服务思想构建的一系列结，我们可以将它称之为“微服务架构
微服务有什么样的具体特点呢？
1、服务拆分粒度更细
微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
2、服务独立部署
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件为单位进行部署。
3、服务独立维护，分工明确
每个微服务都可以交由一个小团队进行开发，测试维护部署，并对整个生命周期负责，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个服务运行体系。
微服务它是由单体应用进化到服务化拆分部署,后期随着移动互联网规模的不断扩大,敏捷开发、DevOps 理论的发展和实践。随着微服务架构的越来越完善和发展，更多的企业已经使用这种架构方法。
4.基于分布式 不是一个单独的框架
5.他提倡将单一应用程序划分为一组小的服务 ——拆分
6.每一个服务运行在其独立的进程中——独立的进程
7.拥有自己独立的连接数据库——独立的数据库
微服务架构的优缺点
微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信的架构思路。
独立性
在开发层面，每个微服务基本上都是各自独立的项目（project），而对应各自独立项目的研发团队基本上也是独立对应，这样的结构保证了微服务的并行研发，并且各自快速迭代，不会因为所有研发都投入一个近乎单点的项目，从而造成开发阶段的瓶颈。开发阶段的独立，保证了微服务的研发可以高效进行。
可扩展性
我们可以快速地添加服务集群的实例，提升整个微服务集群的服务能力，而在传统 Monolith 模式下，为了能够提升服务能力，很多时候必须强化和扩展单一结点的服务能力来达成。如果单结点服务能力已经扩展到了极限，再寻求扩展的话，就得从软件到硬件整体进行重构。
隔离性
隔离性实际上是可扩展性的基础，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个服务运行体系。
在架构设计上有一种实践模式，即隔板模式（Bulkhead Pattern），这种架构设计模式的首要目的就是为了隔离系统中的各个功能单元和实体，使得系统不会因为一个单元或者服务的失败而导致整体失败。
服务独立维护，分工明确
每个微服务都可以交由一个小团队进行开发，测试维护部署，并对整个生命周期负责，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个服务。
当然，没有完美无瑕的技术，微服务也有自身的不足：
微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
Java中微服务架构与传统架构的区别
在聊微服务之前，先来看看传统架构的优缺点。
传统的 MVC 架构，所有的子系统都集成在一个很繁杂的 JVM 进程中。
传统架构的优点：
这种单体架构的优点在于方便管理，所有代码在同一项目中，但是当需求越来越多，项目规模越来越大，其坏处也很明显。
传统架构的缺点：
1、项目过于臃肿，部署效率低下
当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次非常耗时。系统高可用性差，资源无法隔离，整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
2、开发成本高
早期在团队开发人员只有两三个人的时候，协作修改代码，打包部署，更新发布这完全可以控制。但是团队一旦扩张，还是按照早期的方法去开发，那如果测试阶段只要有一块功能有问题，就得重新编译打包部署。所有的开发人员又都得参与其中，效率低下，开发成本极高。
3、无法灵活拓展
当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群：但是这种扩展并非灵活的扩展，因此，急需一种方法将应用的不同模块进行解耦，从而降低开发和部署成本。
要解决上面单体应用的问题，就必须引入服务化的概念。
Dubbo分布式服务框架
SpringCloud
1、为什么需要学习Spring Cloud
不论是商业应用还是用户应用，在业务初期都很简单，我们通常会把它实现为单体结构的应用。但是，随着业务逐渐发展，产品思想会变得越来越复杂，单体结构的应用也会越来越复杂。这就会给应用带来如下的几个问题：
代码结构混乱：业务复杂，导致代码量很大，管理会越来越困难。同时，这也会给业务的快速迭代带来巨大挑战；
开发效率变低：开发人员同时开发一套代码，很难避免代码冲突。开发过程会伴随着不断解决冲突的过程，这会严重的影响开发效率；
排查解决问题成本高：线上业务发现 bug，修复 bug 的过程可能很简单。但是，由于只有一套代码，需要重新编译、打包、上线，成本很高。
由于单体结构的应用随着系统复杂度的增高，会暴露出各种各样的问题。近些年来，微服务架构逐渐取代了单体架构，且这种趋势将会越来越流行。Spring Cloud是目前最常用的微服务开发框架，已经在企业级开发中大量的应用。
2、什么是Spring Cloud
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
设计目标与优缺点
设计目标
协调各个微服务，简化分布式系统开发。
优缺点
微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用Spring Cloud的呢？
优点：
产出于Spring大家族，Spring在企业级开发框架中无人能敌，来头很大，可以保证后续的更新、完善
组件丰富，功能齐全。Spring Cloud 为微服务架构提供了非常完整的支持。例如、配置管理、服务发现、断路器、微服务网关等；
Spring Cloud 社区活跃度很高，教程很丰富，遇到问题很容易找到解决方案
服务拆分粒度更细，耦合度比较低，有利于资源重复利用，有利于提高开发效率
可以更精准的制定优化服务方案，提高系统的可维护性
减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发
微服务可以是跨平台的，可以用任何一种语言开发
适于互联网时代，产品迭代周期更短
缺点：
微服务过多，治理成本高，不利于维护系统
分布式系统开发的成本高（容错，分布式事务等）对团队挑战大
总的来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud是一个不错的选择。
Spring Cloud和SpringBoot版本对应关系
| Spring Cloud Version | SpringBoot Version |
|---|---|
| Hoxton | 2.2.x |
| Greenwich | 2.1.x |
| Finchley | 2.0.x |
| Edgware | 1.5.x |
| Dalston | 1.5.x |
Spring Cloud和各子项目版本对应关系
| Component | Edgware.SR6 | Greenwich.SR2 |
|---|---|---|
| spring-cloud-bus | 1.3.4.RELEASE | 2.1.2.RELEASE |
| spring-cloud-commons | 1.3.6.RELEASE | 2.1.2.RELEASE |
| spring-cloud-config | 1.4.7.RELEASE | 2.1.3.RELEASE |
| spring-cloud-netflix | 1.4.7.RELEASE | 2.1.2.RELEASE |
| spring-cloud-security | 1.2.4.RELEASE | 2.1.3.RELEASE |
| spring-cloud-consul | 1.3.6.RELEASE | 2.1.2.RELEASE |
| spring-cloud-sleuth | 1.3.6.RELEASE | 2.1.1.RELEASE |
| spring-cloud-stream | Ditmars.SR5 | Fishtown.SR3 |
| spring-cloud-zookeeper | 1.2.3.RELEASE | 2.1.2.RELEASE |
| spring-boot | 1.5.21.RELEASE | 2.1.5.RELEASE |
| spring-cloud-task | 1.2.4.RELEASE | 2.1.2.RELEASE |
| spring-cloud-gateway | 1.0.3.RELEASE | 2.1.2.RELEASE |
| spring-cloud-openfeign | 暂无 | 2.1.2.RELEASE |
注意：Hoxton版本是基于SpringBoot 2.2.x版本构建的，不适用于1.5.x版本。随着2019年8月SpringBoot 1.5.x版本停止维护，Edgware版本也将停止维护。
SpringBoot和SpringCloud的区别？
SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系
SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。
使用 Spring Boot 开发分布式微服务时，面临以下问题
（1）与分布式系统相关的复杂性 - 这种开销包括网络问题，延迟开销，带宽问题，安全问题。
（2）服务发现 - 服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。
（3）冗余 - 分布式系统中的冗余问题。
（4）负载平衡 - 负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。
（5）性能问题 - 由于各种运营开销导致的性能问题。
（6）部署复杂性 - DevOps的要求。
服务注册和发现是什么意思？Spring Cloud 如何实现？
当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。
负载平衡的意义什么？
在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。
Eureka服务注册与发现
- 服务治理
- 服务注册
- 服务发现Discovery——@EnableDiscoveryClient
- actuator微服务信息完善
- Eureka自我保护机制
1. 什么是服务治理？
Springcloud 封装了Netflix 公司开发的Eureka模块来实现服务治理。
在传统的rpc 远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务与服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册。
2.什么是服务注册与发现？
Eureka采用了CS的设计架构，Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。
在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务器的信息 比如 服务地址通讯地址等以别名方式注册到注册中心上。另一方（消费者|服务提供者），以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC远程调用框架核心设计思想：在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系（服务治理概念）。在任何rpc 远程框架中，都会有一个注册中心（存放服务地址相关信息(接口地址)）
3.Eureka两组件
- Eureka Server
- Eureka Client
Eureka Server提供服务注册服务
各个微服务节点通过配置启动后，会在Eureka Server 中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观看到。
Eureka Client通过注册中心进行访问
是一个Java客户端，用于简化Eureka Server的交互，客户端同时也是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。
4、Eureka自我保护机制
概述：
保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护，一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务。
一句话： 某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存。
如果在Eureka Server的首页看到以下这段提示，则说明Eureka进入了保护模式。属于CAP里面的AP分支。
为什么会产生Eureka自我保护机制？
为了防止EurekaClient可以正常运行，但是 与 EurekaServer网络不通情况下，EurekaServer不会立刻将EurekaClient服务剔除。
什么是自我保护模式？
默认情况下，如果EurekaServer在一定时间内没有接受到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生（延迟、卡顿、拥挤）时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。
在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。
它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例，
综上： 自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留）也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。
Ribbon 负载均衡和 Rest 调用
Ribbon：
Ribbon 是一个软负载均衡的客户端组件，它可以和其他所需请求的客户端结合使用，和 eureka 结合只是其中的一个实例
1.负载均衡是什么
用一句话说就是负载均衡+RestTemplate调用，其实就是一个软负载均衡的客户端组件。
简单的说就是将用户的请求平摊的分布到多个服务上，从而达到系统的HA（高可用）。
常见的负载均衡有软件Nginx，LVS，硬件F5等。
2.Ribbon本地负载均衡客户端 VS nginx服务端负载均衡
Nginx是服务器负载均衡，客户端所有请求都会交给Nginx，然后由nginx实现转发请求。即负载均衡是由服务端实现的。
Ribbon本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用技术。
3.集中式LB
即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件nginx）由该设施负责把请求通过某种策略转发至服务的提供方。
4.进程内LB
将LB逻辑集成到消费方，消费方从服务注册中心获取有哪些地址可用，然后自己在从这些地址中选择出一个合适的服务器。
Ribbon就属于进程内LB，他是一个类库，集成于消费方进程，消费方通过他来获取服务提供方的地址。
5.Ribbon在工作的时候分成两步
第一步：先选择EurekaServer，它优先选择在同一个区域内负载较少的server
第二步：再根据用户指定的策略，再从server取到的服务注册列表中选择一个地址
其中Ribbon提供了多种策略：比如轮询、随机和根据响应时间加权重。
6.引入ribbon依赖
在这个版本中是不需要添加ribbon依赖的，因为最新版eureka依赖里面包含ribbon依赖的
7.RestTemplate的使用
getForObject()方法和/getForEntitiy()方法
这两个的返回结果是一样的
getForObject()返回对象为响应体中数据转化的对象，基本上可以理解为json。
getForEntitiy()返回对象为ResponseEntity对象，包含了响应中的一些重要信息，比如响应头、响应状态码、响应体等。具体可以参照下图：
postForObject()方法和/postForEntity()方法同上
总之一句话： Ribbon 就是 负载均衡 + RestTemplate调用，最终实现RPC的远程调用。
Ribbon默认自带的负载规则 有7种
ribbon中具体实现负载均衡的策略是通过IRule这个接口来实现的
OpenFeign
1.OpenFeign是什么？
Feign是一个声明式的Web Service客户端。它的出现使开发Web Service客户端变得很简单。使用Feign只需要创建一个接口加上对应的注解，比如：FeignClient注解。Feign有可插拔的注解，包括Feign注解和JAX-RS注解。Feign也支持编码器和解码器，Spring Cloud Open Feign对Feign进行增强支持Spring MVC注解，可以像Spring Web一样使用HttpMessageConverters等。
2、能干什么？（用在消费端）
前面在使用Ribbon+RestTemplate时，利用RestTemplate对http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每一个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上面做了封装，由他来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需要建立一个接口并使用注解的方式来配置它（以前是dao接口上面标注Mapper注解，现在是一个微服务上面标注一个Feign注解即可），即完成对服务提供方的接口绑定，简化了使用spring cloud Ribbon时，自动封装服务调用客户端的开发量。
3.Feign集成了Ribbon
利用Ribbon维护了Payment的服务列表信息，并且通过轮询实现了客户端的负载均衡。而与Ribbon不同的是，通过Feign只要定义服务绑定接口且以声明式的方法，优雅而简单的实现了服务调用。
6、OpenFeign超时控制
默认Feign 客户端只等待1秒钟，但是服务端处理需要超过1秒钟，导致Feign 客户端不想等待了，直接返回报错。
为了避免这样的情况，有时候我们需要设置Feign客户端的超时控制。
7、OpenFeign超时，怎么解决？
#80消费者yml配置文件中添加
# 设置feign客户端超时时间(OpenFeign默认支持ribbon)
ribbon:
# 指的是建立连接所用的时间,适用于网络状态正常的情况下,两端连接所用的时间
ReadTimeout: 5000
# 指的是建立连接后从服务器读取到可用资源所用的时间
ConnectTimeout: 5000
8、OpenFeign的日志打印功能
Feign提供了日志打印功能，
我们可以通过配置来调整日志级别，从而了解Feign中Http请求的细节。说白了就是对Feign接口的调用情况进行监控和输出。
Logger有四种类型：
- NONE(默认)：默认的，不显示任何日志
- BASIC：仅记录请求方法、URL、响应状态码及执行时间
- HEADERS：除了 BASIC 中定义的信息之外，还有请求和响应的头信息
- FULL：除了 HEADERS 中定义的信息之外，还有请求和响应的正文及元数据
Hystrix——容错降级限流
分布式系统面临的问题：
复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某个时候将不可避免的失败。
服务雪崩：
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的 “ 扇出 ” 。
如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A 的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的 “ 雪崩效应 ”。
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫 雪崩。
要避免这样的级联故障，就需要有一种链路中断的方案：
服务降级、服务熔断
Hystrix 简介：
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，已提高分布式系统的弹性。
“ 断路器 ” 本身是一种开关装置，当某个服务单元发送故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
Hystrix重要概念：
- 服务降级 （fallback）
- 服务熔断 （break）
- 服务限流 （flowlimit）
服务降级：
服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好提示，fallback
哪些情况会发出降级？
- 程序运行异常
- 超时
- 服务熔断触发服务降级
- 线程池 / 信号量打满也会导致服务降级
服务熔断：
类似保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示
服务限流：
秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行
Spring Cloud 和dubbo区别?
（1）服务调用方式：dubbo是RPC，Spring Cloud是Rest Api。
（2）注册中心：dubbo 是zookeeper，Spring Cloud可以是zookeeper或其他。
（3）服务网关：dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。
（4）架构完整度：Spring Cloud包含诸多微服务组件要素，完整度上比Dubbo高。
扫一扫
503
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
