什么是 spring cloud？

spring cloud 是一系列框架的分布式方案集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。
在软件技术领域，软件系统关注的业务颗粒越来越细化，微服务已是大趋所势，spring cloud即是贴合着微服务的概念，作出的一种技术整合。

为什么要用微服务技术（ Spring cloud）？

一般传统的软件开发，一个系统内包含所有业务模块，在开发或部署都是基于一个软件包，我们称之为单体应用。随着社会技术的发展，企业对的软件需求越来越丰富和细化，早先单体应用模式开发的软件会越来越复杂，体积也越来越庞大，这就给开发和维护带来了极大的不确定性和困难。
例如开发，几乎不可避免的导致一下几个问题：
代码结构混乱：业务复杂，导致单体代码量很大，管理会越来越困难。同时，复杂的系统结构会给业务的快速迭代带来巨大挑战；
开发效率变低：开发人员同时开发一套代码，很难避免代码冲突，开发过程会伴随着不断解决冲突的过程，这严重的影响开发效率；同时，在公共类库基础类库的维护上，也将会带来混乱，令开发成员心惊胆战；
排查解决问题成本高：线上业务发现 bug，修复 bug 的过程可能很简单。但是，由于只有一套代码，如果涉及到公共类的变动，还要考虑其他模块的潜在影响；修复完bug还需要整体的重新编译、打包、测试、上线，使得维护成本很高。

谈一谈微服务的优缺点

一般聊到微服务，我们更多的是如何绘声绘色的描述他的优点，相对于单点应用的各种优势；但任何东西，从不同的角度去看，都会有另外一面。

微服务优点

1，高内聚，每个服务聚焦单一业务功能，设计上更容易有所偏重；
2，由于业务单一，服务技术栈也不会太复杂，开发效率提高，维护成本降低，同时也容易控制团队规模，更容易打造小而美的高效团队；
3，松耦合，微服务架构强调服务间的独立，之间通过相互通信进行联系，这样可以使得开发团队更为专注于服务本身，甚至不局限于任何技术栈；
4，微服务体系的思想基础是面向接口编程，这也就是的气更容易集成任何第三方业务；
6，讨论微服务一般强调的是业务层面上的独立，事实上显示层也被抽离成为独立的服务；这就使得业务层专注于业务逻辑，显示层专注于显示交互；
6，因为独立，微服务可以灵活搭配技术类型，且技术更新成本也会降低；
7，可快速定位问题，且单个服务出现问题，可以通过策略优化使其对整个系统影响降至较低水平。

微服务缺点

1，随着服务数量增加，服务器数量逐渐增多，部署工作开始繁复，各项管理将会复杂，运维难度即会陡增；
2，较多的服务数量，使得系统内部通信压力增大，甚至成为瓶颈，服务监控和性能监控将成为重要工作；
3，由于业务的抽离独立，避免不了系统依赖的增强，使得系统整体设计的要求提高；
4，业务的独立即可能对数据库的操作相互独立，即数据一致性将成为重要议题；
5，真正的微服务设计旨在处理相对复杂的系统问题，也对应着更大的人力资源开销。

总结

凡事都有两面性，就像微服务这个东西，追求技术优势的同时，也需知道面临的问题。在具体的方案选型上，采不采用微服务架构，主要还是看是否需要；具体在微服务业务的抽离独立的颗粒度上，也要考虑业务需求，使用场景，甚至人力资源等各种因素。最后还是那句话，适合的，才是最好的。

Spring、SpringBoot和SpringCloud的关系

Spring，包括Spring全家桶，关注的是功能的技术实现，即如何通过好的设计模式理念、更好的程序逻辑，实现所需要的功能，是技术框架；SpringBoot聚焦的是单个个体微服务，专注于提供简单便捷的开发维护方案，是技术使用框架；而SpringCloud考虑的是全局整体，即将SpringBoot开发的单体微服务整合并管理起来，是（分布式）方案整合框架。
从Spring到SpringBoot到SpringCloud，是技术抽象到使用落地的一个优化过程，Spring技术栈本身就很丰富，很优秀，很强大；SpringBoot延续了Spring的优良特质，使Spring技术的应用更为简单便捷，锦上添花；SpringCloud则是在spring技术栈强大的基础上，在SpringBoot专注简单便捷思想的加持下，搜罗了几乎所有现有的成熟技术组件，顺应微服务应用的历史潮流，整合出了一套体系完整的分布式技术框架方案，如虎添翼！

Dubbo是什么？

说道基于Java技术栈的分布式框架，除了Spring Cloud，也不得不提下Dubbo 。
Dubbo是一个分布式服务框架，相较于SpringCloud技术应用，Dubbo框架早在12年之前就出现了，那时候除了极个别大厂有分布式的方案需求，绝大部分企业都没有使用场景，所以即使开源很早，生态社区也不是很活跃，以至于中间维护停滞了好长时间，直到2017年又开始继续更新，开启第二春。
Dubbo到底能做什么？ 我们在他的官网上看到这样的描述：Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架；Apache Dubbo 提供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

结合Spring Cloud、Dubbo，谈谈他们的优缺点

Spring Cloud和Dubbo都是致力于提供高性能分布式方案的服务框架，由于Dubbo 的服务间同是通过RPC协议，而SpringCloud则依赖于 REST的方式调用，由于注册中心元数据兼容等问题，导致我们在微服务基础框架选型时只能二选一，下面我们就总结下他们各自的特点：

Dubbo的优点

Dubbo服务间调用借助的是远程过程调用（RPC，remote procedure call）的方式，这个在性能方面略占优势；
Dubbo支持多种序列化协议，如 Hessian、HTTP、WebService；
Dobbo Admin提供了一个功能强大的管理台，可以进行路由规则、动态配置、访问控制、权重调节、均衡负载等操作；
Dobbo早些年在国内影响力比较大，中文社区文档相对比较全面。

Dubbo存在的问题

Dubbo的服务注册严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断；
Dubbo 只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）；
Dubbo RPC 本身不支持跨语言（可以用跨语言 RPC 框架解决，比如 Thrift、gRPC（重复封装了），或者自己再包一层 REST 服务，提供跨平台的服务调用实现，但相对麻烦很多）；
Dubbo 只是实现了服务治理，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且有一定风险；
更新可能随时中断（阿里、很多国内开源项目的通病），后续技术更新困难；
主要用户是一些国内公司，社区生态较 Spring Cloud差很多。

Spring Cloud的优点

Spring Cloud 通过标准化的技术范式将微服务的成熟组件和框架结合一起，这些组件大都久经市场考验，技术更新也相对及时；且Spring Cloud 提供了整套微服务解决方案，开发成本较低，且风险较小；
Spring Cloud 是基于 Spring Boot技术的，具有简单配置、快速开发、轻松部署、方便测试的特点；
Spring Cloud 服务间调用借助的是表述性状态传递（REST，Representational State Transfer）方式；相比于 RPC，REST更加轻量化和灵活（服务间只依赖一纸契约，不存在代码级别的强依赖，真正的接口编程），有利于跨语言服务的实现，以及服务的发布部署。Spring Cloud 可以很方便的结合 Swagger，使得服务的文档统一规范变得非常可行；
Spring Cloud 提供了 Docker 及 Kubernetes支持，可以更为便捷的开展开发部署和维护；
Spring Cloud 有强大的 Spring 社区，开源社区贡献非常活跃；且有Netflix、Amazon等优秀公司的支持，这对于开源项目就是绝对的信心。

Spring Cloud存在的问题

Spring Cloud使用REST方式的调用其实也有弊端，可能因为接口定义过轻，导致定义文档与实际实现不一致，从而导致服务集成时出现问题（可以使用统一文档和版本管理解决，比如 Swagger）；
还有，REST 服务间调用性能会比 RPC 低一些（由于不是强绑定，需要额外的解析）；
Spring Cloud 本质是对大量组件的有机组合，尽管成员组件设计实现都非常优秀，但无法避免的是他们各种文档形式不一，相对比较复杂，需要针对性的进行阅读。

总结

从整体技术层面看，Dubbo 专注于RPC 和服务治理，而Spring Cloud则是一个微服务架构生态，Spring Cloud拥有更为丰富的功能组件和相对成熟的技术支持，这也能解释为什么当下Spring Cloud技术栈为什么如此火爆。

谈谈微服务之间如何独立通讯的

微服务间通信，我们一般说的是同步通信，Dubbo采用的是远程过程调用（RPC）的方式，Spring Cloud则采用的是REST方式；此外，除了同步通信还有异步通信，一般借助消息队列，如RabbitMq、ActiveM、Kafka 等。

谈谈什么是熔断，什么是服务降级

熔断这个取义于保险丝，即出现异常（电流电压过大）时，为了保护工作的电器，采取的保护策略。同理，在微服务架构下，当某个服务出现异常时，为了防止依赖于此的其他服务出现异常扩散，导致服务雪崩，暂时停止对该异常服务的调用，从而对整个系统的稳定起到一定保护作用，熔断是一种保护性质的策略机制。
相对于熔断，服务降级则是一种考虑更为周全，实施更为温和的策略。即当服务出现异常，如服务超载、处理超时，则暂时先返回一个预定的数据（错误信息提示等），这样虽然业务没有完善处理，但不至于产生等待，从而保证系统整体的稳定。

谈一谈负载均衡

负载均衡是一种思维工具，在我们生活中，最典型的场景就是地铁站，在特定的时间，地铁站会因为人流的集中出现而异常拥堵，显然，如果只考虑一个出入口肯定是不行的，所以我们看到地铁站一般都有很多出入口，尤其是交汇大站，甚至有几十个出入口，将集中的人流分散至多个入口处，能很大程度上缓解拥堵的情况。
同理，负载均衡也是一种计算机应用技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。
在具体应用上，负载均衡一般是通过算法实现的，我们一般可以将负载均衡算法分为两类：静态负载均衡算法和动态负载均衡算法。静态负载均衡算法主要包括：轮询（Round Robin）、比率（Ratio）、优先权（Priority）、哈希（Hash）；动态负载均衡算法相对复杂，主要包括: 最少的连接方式（Least Connection）、最快模式（Fastest）、观察模式（Observed）预测模式（Predictive）、动态性能分配(Dynamic Ratio-APM)、动态服务器补充(Dynamic Server Act)、服务质量(QoS）、服务类型(ToS)、规则模式等。不同的负载均衡算法对应的是不同的策略，适用于不同的场景。

列举微服务（Spring Cloud）常见的技术栈

业务开发与服务构建：Spring、SpringMVC、SpringBoot
服务配置管理：Archaius、Diamond
服务配置中心管理：SpringCloudConfig（配置中心）、Chef
服务注册与发现：Eureka、Zookeeper、Consul
服务调用方式：Rest（表述性状态传递）、RPC（远程过程调用，Dubbo）、gRPC（RPC框架）
熔断保护：Hystrix、Envoy
负载均衡：Ribbon、Nginx
接口调用：Fegin
消息队列：Kafka、RabbitMQ、ActiveMQ
服务路由（网关）：Zuul、Gateway
消息总线：Spring Cloud Bus
消息驱动：Spring Cloud Stream（RabbitMQ、Kafka、RocketMQ）
服务跟踪：Spring Cloud Sleuth（ELK、Zipkin）、Brave、Dapper
服务监控：Zabbix、Nagios、Metrics、Spectator
服务部署：Docker、Kubernetes、OpenStack