SringCloud有关的重点问题！

1、微服务架构和一体化架构的对比

  1.1 一体化架构：通俗地讲，你可以认为，一体化架构就像一个大容器，这个应用包含的所有的软件组件都被装配起来并紧紧地打包在一起。

一体化架构的缺点：

                        1、不灵活——无法使用多种技术去构建一体化应用

                         2、不可靠——即便系统中只有一个功能不工作了，也会造成整个系统不工作

                         3、不可扩展——应用无法被轻易地被扩展，因为每次应用需要被升级，都必须重新构建整个系统

                         4、 阻塞持续集成——应用中的很多功能无法同时被构建和部署

                         5、迭代速度慢——一体化应用中新开发的代码需要很长时间来构建，因为需要一个一个地构建每一块功能。

                         6、不适用于复杂应用——复杂应用的功能有耦合度很高的依赖

1.2 微服务：又叫微服务架构，是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。

在微服务架构中，每个服务都是自我包含的，并且实现了单一的业务功能。

微服务的特点

       ●解耦：同一系统内的服务大部分可以被解耦。因此应用，作为一个整体，可以轻易地被构建、修改和扩展。

       ● 组件化：微服务可以被看成相互独立的组件，这些组件可以被轻易地替换和升级。

       ● 业务能力：微服务很小，它们可以专注于某种单一的能力

       ● 自治：开发者和团队可以独立地工作，提高开发速度。

       ● 持续交付：允许持续发布软件新版本，通过系统化的自动手段来创建、测试和批准新版本。

       ● 职责明确：微服务不把应用看成一个又一个的项目。相反，它们把应用当成了自己需要负责的项目。

       ● 去中心化管理：关注于使用正确的工具来完成正确的工作。这也就是说，没有标准化的方式或者技术模式。开发者们有权选择最好的工具来解决问题。

       ● 敏捷性：微服务支持敏捷开发。任何新功能都可以被快速开发或丢弃。

微服务的优点

       ● 独立开发：基于各个微服务所独有的功能，它们可以被轻易开发出来。

       ● 独立部署：基于它们所提供的服务，它们可以被独立地部署到应用中。

       ● 错误隔离：即便其中某个服务发生了故障，整个系统还可以继续工作。

       ● 混合技术栈：可以使用不同的语言和技术来为同一个应用构建不同的服务。

       ● 按粒度扩展：可以根据需求扩展某一个组件，不需要将所有组件全部扩展。

微服务的缺点

      微服务使整个应用服务增多，服务间通讯更复杂，也会带来大量 的问题。比如单体如何拆分成多个微服务，团队间沟通更多，运维成本增高，分布式事务问题，依赖管理变得复杂，测试 更加困难，故障更难于定位等等。

2、  微服务之间是如何独立通讯的

     1、客户端到服务端通信，API Gateway方法。

API Gateway是解决微服务通信的一个不错的方法。以客户端为例。一个客户端可以向多个微服务中的任意一个微服务发出请求。API Gateway负责请求转发、合成和协议转换。所有请求都要先经过API Gateway，然后再将请求转发到对应的微服务中。

     2、进程通信IPC

这种通信不但可以实现一对一、一对多。还可以实现同步和异步请求。

3、springCloud和Dubbo有哪些区别

1、dubbo由于是二进制的传输，占用带宽会更少

2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大(但是在国内95%的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解)

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

5、dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心能用eureka或者zk

6、dubbo是rpc调用，springcloud是REST调用

4、SpringBoot和SpringCloud，请你谈谈对他们的理解

1、SpringBoot专注于快速方便的开发单个个体微服务。
2、SpringCloud是关注全局的微服务协调、整理、治理的框架，它将SpringBoot开发的单体整合并管理起来。
3、SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系。

5、什么是服务熔断？什么是服务降级

相同点： 
目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段； 
最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用； 
粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）； 
自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；

区别： 
触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑； 
管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始） 
实现方式不太一样；服务降级具有代码侵入性(由控制器完成/或自动降级)，熔断一般称为自我熔断。

6、eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别

https://blog.csdn.net/w1028556865/article/details/81127885

知识点：

1、zipkin从F开始都不需要安装了，通过pom或者jar直接使用，zipkin链路监控、追踪(分布式请求链路跟踪)（zipkin: https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/）
2、ribbon:可以直接用默认的轮询负载均衡，也可以自定义算法，通过IRule类实现
3、feign也是负载均衡，他是通过service层（接口，方法上有@GetMapping等注解），统一的处理异常，在controller层进行调用（一般都会和hystrix进行整合，因为无论hystrix是一个方法对应一个fallback,还是加上一个默认的统一的Defaultproperties对应的fallback方法，代码的耦合性都会很高，所以我们在feign在负载均衡的时候，在@FeignClient注解上可以加上fallback方法）
4、hystrix是服务熔断降级，通过hystrixcommand进行一个，fallbackMethod异常信息的回调,Hystrix中的默认值为5秒内的20次故障，电路打开，不进行通话,hystrix在客户端服务端两者做服务降级（方法上有hystrixcommand的则找对应的方法，如果没有写，则去找@Defaultproperties对应的回调方法）
5、zuul网关，把直接访问项目路径改为访问zuul网关，包装一层
6、我们的负载均衡是加在consume层，在用户访问时即可实现负载的作用
7、springcloud bus 将分布式系统与轻量级消息系统链接起来的框架，它整合了java事件处理机制和消息中间件的功能，目前只整合了rabbitmq和kafka(消息总线，消息从服务端发到tocpik主题中，所有订阅过这个主题的都可以接收到信息)
curl -X POST "http://localhost:3344/actuator/bus-refresh"（全部通知）
curl -X POST "http://localhost:3344/actuator/bus-refresh/config-client:3355"(指定通知谁，config-client是spring-spplication-name)
8、spring stream屏蔽了底层mq消息中间件的差异性，它是外部消息传递和系统程序之间的桥梁，应用程序通过inputs和outputs与spring stream中的binder对象交互mq中存在重复消费的问题（不同组可以重复消费，同一个组，存在竞争关系，只有其中一个可以消费）
9、hystrixdashboard必须在调用了hystrix服务时才可以通过图形化界面看到，不然一直显示Loading