# springcloud
1.什么是微服务
目前的微服务并没有一个统一的标准,一般是以业务来划分
将传统的一站式应用,拆分成一个个的服务,彻底去除耦合,一个微服务就是单功能业务,只做一件事。
每一个微服务可以有自己独立的数据库
与微服务相对的叫巨石
2 微服务之间是如何通信的
服务与服务间采用轻量级通讯,如HTTP的RESTful API等
3.SpringCloud和Dubbo[X]的区别
4 请谈一下 你对SpringBoot和SpringCloud的理解
SpringBoot:专注于快速方便的开发单个个体微服务(关注微观)
SpringCloud:关注全局的微服务协调治理框架,将SpringBoot开发的一个个单体微服务组合并管理起来(关
注宏观)
SpringBoot可以离开SpringCloud独立使用,但是SpringCloud不可以离开SpringBoot,属于依赖关系
5 什么是服务熔断?什么是服务降级?
服务熔断
这种模式主要是参考电路熔断,如果一条线路电压过高,保险丝会熔断,防止火灾。放到我们的系统中,如果某个目标服务调用慢或者有大量超时,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
熔断机制的注解是@HystrixCommand
熔断机制是应对雪崩效应的一种链路保护机制,一般存在于服务端
当扇出链路的某个服务出现故障或响应超时,会进行服务降级,进而熔断该节点的服务调用,快速返回“错误”的相应信息
服务降级
当系统整体资源快不够的时候,忍痛将部分服务暂时关闭,带渡过难关后,再重新开启。
降级处理时在客户端完成的,与服务端没有关系
理解:所谓降级,一般是从整体负荷考虑,当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的FallBack回调,返回一个缺省值。这样做虽然服务水平下降,但好歹可用,比直接挂掉好
为什么要解耦
如果按照上面的熔断案例来做的话,Controller下的每个方法,都要给其编写一个FallBack方法,当方法慢慢变多,就会造成代码膨胀,一个是增加编写的工作量,另外一个也会增大维护的难度,代码的耦合度也会高,是十分不合理的,所以要将其解耦。
解耦思路:
因为服务端的是通过实现接口访问服务端的,如果在父接口上实现了FallBack方法,通过这样一种方式去维护起来就能实现解耦,也顺便完成了降级的机制。
6 微服务的优缺点是什么?你在项目开发中遇到的坑是什么?
1.3.1 优点
- 每个服务足够内聚,足够小,比较容易聚焦
- 开发简单且效率高,一个服务只做一件事情
- 开发团队小,一般2-5人足以(当然按实际为准)
- 微服务是松耦合的,无论开发还是部署都可以独立完成
- 微服务能用不同的语言开发
- 易于和第三方集成,微服务允许容易且灵活的自动集成部署(DEVOPS持续集成工具有
Jenkins,Hudson,bamboo等) Maven + git/svn + Jenkins - 微服务易于被开发人员理解,修改和维护,这样可以使小团队更加关注自己的工作成果,而无需一定要
通过合作才能体现价值 - 微服务允许你融合最新的技术
- 微服务只是业务逻辑的代码,不会和HTML,CSS或其他界面组件融合。
- 每个微服务都可以有自己的存储能力,数据库可自有也可以统一,十分灵活。
1.3.2 缺点
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度,随着服务的增加,运维的压力也会增大
- 依赖系统部署
- 服务间通讯的成本,网络延迟等
- 数据的一致性,分布式事务问题
- 系统集成测试
7.监控的难度
7 你所了解的微服务的技术栈有哪些?
8 Eureka和zookeeper都可以提供服务的注册和发现,他们有什么区别【重点】
9 SpringCloud中是如何实现负载均衡的
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡工具。Ribbon会自动帮助你基于某种规则(简单轮询、随机连接等),也可以实现自定义的负载均衡算法。
英文名称:Load Balance,微服务或分布式集群中常用的一种应用
简单来说负载均衡就是将用户的请求ping平摊的分配到多个任务上,从而是系统达到HA(高可用)
两种负载均衡:
- 集中式LB:偏硬件,服务的消费方和提供方之间使用独立的LB设施,由该设施负责把访问请求以某种策略转发至服务的提供方。
- 进程内LB:偏软件, 将LB逻辑集成到消费方,消费方从服务注册中心指导哪些地址可用,再自己选择一个合适的服务器。
1、什么是负载均衡?
负载均衡是微服务架构中必须使用的技术,通过负载均衡来实现系统的高可用、集群扩容等功能。负载均衡可
通过硬件设备及软件来实现,硬件比如:F5、Array等,软件比如:LVS、Nginx等。
如下图是负载均衡的架构图:
用户请求先到达负载均衡器(也相当于一个服务),负载均衡器根据负载均衡算法将请求转发到微服务。负载均衡算法有:轮训、随机、加权轮训、加权随机、地址哈希等方法,负载均衡器维护一份服务列表,根据负载均衡算法将请求转发到相应的微服务上,所以负载均衡可以为微服务集群分担请求,降低系统的压力。
2、什么是客户端负载均衡?
上图是服务端负载均衡,客户端负载均衡与服务端负载均衡的区别在于客户端要维护一份服务列表,Ribbon从Eureka Server获取服务列表,Ribbon根据负载均衡算法直接请求到具体的微服务,中间省去了负载均衡服务。
如下图是Ribbon负载均衡的流程图
1、在消费微服务中使用Ribbon实现负载均衡,Ribbon先从EurekaServer中获取服务列表。
2、Ribbon根据负载均衡的算法去调用微服务。