SpringCloud面试题

SpringCloud面试题

什么是微服务

微服务架构是一种架构模式，将单一应用程序划分成一组小的服务。每个服务运行在其独立的自己的进程中服务之间相互配合、相互协调，为用户提供最终价值。服务之间采用轻量级通信。每个服务都围绕具体业务进行构建，并能够独立部署到生产环境等。单独的模块只处理单独的业务逻辑。

微服务之间的通信

同步通信： dobbo通过 RPC 远程过程调用、springcloud通过 REST  接口json调用
异步通信： 消息队列

SpringCloud 和 Dubbo

Dubbo优势：

• 单一应用架构：系统压力小时，一个应用就可以将所有功能部署在一起，节省成本，部署节点少
• 垂直应用架构：访问量大时，将应用拆开，提升效率
• 分布式服务架构：垂直应用增加时，将核心业务抽取出来独立，形成稳定的服务中心。

SpringCloud优势：

• 开箱即用，快速启动
• 使用与各种复杂场景
• 轻量级的丰富组件，功能齐全
• 约定优于配置

比较：

1. Dubbo使用二进制传输，占用的带宽更少。
2. SpringCloud使用http传输，带宽消耗较大。
3. Dubbo的jar包依赖处理起来很麻烦
4. Dubbo的注册中心可选zk，redis等，SpringCloud的注册中心只能是eureka或者自研
5. SpringCloud的接口协议约定比较自由，需限制接口无序升级

总结：

	Dubbo	SpringCloud
服务注册中心	Zookeeper	eureka
调用方式	RPC	基于http的rest api
服务监控	Dubbo-monitor	boot admin
断路器	不完善	hystrix
网关	×	zuul
分布式配置	×	config
服务跟踪	×	sleuth
消息总线	×	bus
数据流	×	stream
批量任务	×	task

SpringBoot 与 SpringCloud

SpringBoot是开发单个微服务。

SpringCloud：关注全局的微服务协调治理框架，将SpringBoot开发的一个个单体微服务组合并管理起来。
SpringBoot可以离开SpringCloud独立使用，但是SpringCloud不可以离开SpringBoot，属于依赖关系。

熔断与服务降级

熔断：

类似于电路上的保险丝，当服务出现宕机或者连接超时的情况，为了防止整个微服务挂掉

降级：

对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性

微服务的优缺点

优点：

• 松耦合，聚焦单一业务功能，
• 在开发中，不需要了解多有业务，只专注于当前功能
• 微服务一个功能宕机，对其他功能影响并不是太大，可以快速定位问题。
• 微服务只专注于当前业务逻辑代码，不会和 html、css 或其他界面进行混合。可以灵活搭配技术，独立性高。

缺点：

• 随着服务数量增加，管理复杂，
• 部署复杂，服务器需要增多，服务通信和调用压力增大，
• 运维工程师压力增大，人力资源增多，
• 系统依赖增强，
• 数据一致性要求高
• 需要性能监控

eureka和zookeeper的区别

• zookeeper 是CP原则，强一致性和分区容错性
• eureka 是AP 原则 可用性和分区容错性
• zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，耗时过长，虽然最终能够恢复，但是选取主节点期间会导致服务不可用
• eureka各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。

C(一致性)、A(可用性)和P(分区容错性)

微服务技术栈

微服务	技术栈
服务开发	Spingboot、SpringCloud、SpringMVC
配置管理	Netfix的Archaius、阿里的Diamoind
注册发现	eureka、zookeeper
远程调用	rest rpc
熔断	hystrix
负载均衡	nginx ribbon
接口调用	feign
消息队列	rabbitMQ、Kafka
配置中心	config、chef
路由网关	zuul
服务监控	zabbix nagios metrics spectator
全链路跟踪	zipkin brave dapper
服务部署	docker openstack kubemetes
数据流	SpringCloudStream
消息总线	SpringCloud Bus