SpringCloud面试题（必看）

一、微服务架构四个核心问题？

1、服务很多，客户端怎么访问

2、这么多服务，服务之间如何通信

3、这么多服务，如何治理

4、服务挂了怎么办

---

二、微服务优缺点

优点

1、单一职责

2、每个服务足够内聚，足够下小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求

3、开发简单，开发效率高，一个服务可能就是专一的干一件事

4、微服务能够被小团队单独开发，可以是2-5人组成

5、微服务是松耦合，是有功能意思的服务，无论是在开发解读那还是部署阶段都是独立

6、微服务能使用不同的语言开发

7、每个服务都是自己的存储能力

缺点

1、开发人员要处理分布式系统的复杂行

2、随着服务的增加，运费的压力也增大

3、系统部署依赖

4、服务间的通信成本

5、数据一致性

6、系统集成测试

7、性能监控

---

三、为什么要选择cloud做微服务架构

1、整体解决方案和框架成熟度

2、社区热度

3、可维护性

---

四、cloud深入了解

1、所有实体类必须实现序列化，传输汇报错误

2、热部署 spring-boot-devtools

3、请求接口 Get/postForObject4、RestTemplate{请求接口地址，参数，返回值类型}

5、需要通过bean把接口注入进去

---

五、Eureka注册中心

1、理念：Eureka：服务注入，显示当前已有的服务，自我保护机制：好死不如赖活着，宁可同时保留所有的服务，也不盲目的注销监看的服务，自我保护机制也可以关闭

2、client.getServices获取微服务列表，getInstances根据服务名字获取服务信息

3、CAP原则：c：强一致性，a：可用性，p：分区容错性，ca：单点集群，满足一致性，可用性的系统，通常可扩展性较差，ap：满足一致性，分区容错性的系统，通常性能不是特比高，cp：满足可用性，分区容错性的系统，通常可能对一致性要求低

4、ACID原则：a：原子性，c：一致性，I：隔离性，d：持久性

5、Zookeeper：保证cp原则:容忍注册中心返回几分钟以前的信息，但是不能容忍服务直接死掉，当master节点失去联系回重新选择master节点，选取时间过长，服务期间不能使用，

6、Eureka：保证ap原则：各个节点平等，其中一个节点死掉也会正常运行，只不过信息可能不是最新的，如果在15分钟内超过85%的节点没有正常心跳，会采取一下措施

a：不会从列表中移除

b：任然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上

c：当前网络稳定时，单前实例新的注册信息会被同步到其他节点中

总结：Eureka可以很好的应对因网络故障导致的部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

---

六、Ribbon负载均衡

1、cloud ribbon是基于netflix ribbon实现的一套客户端负载均衡工具，提供客户端的软件负载均衡算法，将netflix的中间层链接起来，配置项：丽娜姐超市，重试，ribbon会自动的帮你基于某种规则如（单轮询，随机链接），

2、ribbon能干嘛

将用户的请求平均分配到，多个服务上，从而达到系统的HA

3、常见的负载均衡软件，nginx，lvs

4、dubbo，springcloud中均给我提供了负载均衡，cloud的负载均衡算法可以自定义

5、依赖：cloud-starter-ribbon，cloud-starter-eureka

6、原先Eureka是指定服务链接，现在是指定服务名字

7、LoadBalanced 开启负载均衡

---

七、负载均衡类型

1、RoundRobinRule 轮询

2、RandomRule随机

3、AvailabilityFilteringRule 先过滤掉故障服务，对剩下的服务进行轮询

4、RetryRule 先按照轮询获取服务，如果服务获取失败，则会在指定时间内进行重试

5、负载均匀用法 @Configuration @Bean 外加算法

自己写的不能与主应用程序统计目录，因为会被@ComponentScan扫描到

6、RibbonClient（name="服务名称", configuration = 负载均衡算法类名.class）

7、随机服务源码

八、FeignClient（注入服务名，让别的服务能获取到你的方法）

Component FeignClient（vlaue="服务名"）

启动类：@EnableFeignClients 扫描FeignClient @COmponentScan让所有的注解都生效