微服务面试

1. 什么是SpringCloud

   Spring Cloud 是一个相对比较新的微服务框架

   Spring Cloud提供的全套的分布式系统解决方案。

   Spring Cloud是一个微服务框架的规范，只是规范，他不是任何具体的框架。

   • SpringCloud是分布式微服务治理解决方案。提供了一系列框架技术的有序集合。
   • 利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
   • Spring Cloud是集大成者，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

2. SpringCloud的优缺点

   优点：

   1.耦合度比较低。不会影响其他模块的开发。
   2.配置比较简单，基本用注解就能实现，不用使用过多的配置文件。
   3.微服务跨平台的，可以用任何一种语言开发。
   4.每个微服务可以有自己的独立的数据库也有用公共的数据库。
   5.直接写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行服务通信。

   6.组件化（模块化）、随时开箱拆箱。

   缺点：

   微服务过多，治理成本高，不利于维护系统
   分布式系统开发的成本高（容错，分布式事务等）对团队挑战大

   1.微服务落地部署

   2.微服务监控

   3.微服务日志管理

   4.微服务集成测试与质量管理

3. 传统(单体）架构和微服务架构区别和特点

   区别
   1、单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

   2、单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

   3、单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

   优点：

   这种单体架构的优点在于方便管理，所有代码在同一项目中，但是当需求越来越多，项目规模越来越大，其坏处也很明显。

   • 开发简单，集中式管理
   • 基本不会重复开发
   • 功能都在本地，没有分布式的管理和调用消耗

   缺点：

   1、项目过于臃肿，部署效率低下

   2、开发成本高

   3、无法灵活拓展

   微服务特性

   1、服务拆分粒度更细

   2、服务独立部署

   3、服务独立维护，分工明确

   1、每个微服务可独立运行在自己的进程里；

   2、一系列独立运行的微服务共同构建起了整个系统；

   3、每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；

   4、微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

4. 微服务架构常见的设计模式

   1、聚合器微服务设计模式

   聚合器调用多个服务实现应用程序所需的功能。

   2、代理微服务设计模式

   这是聚合器模式的一个变种，在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

   3、链式微服务设计模式

   这种模式在接收到请求后会产生一个经过合并的响应，在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。

   4、分支微服务设计模式

   这种模式是聚合器模式的扩展，允许同时调用两个微服务链

   5、数据共享微服务设计模式

   自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式

   6、异步消息传递微服务设计模式

   虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应

5. 微服务落地的技术解决方案有哪些\

   微服务之自动化部署

   Nexus+Jenkins+Git+GitLab+Docker

   微服务之日志收集与性能监控

   ELK(ElasticSearch+Logstash+Kibana)+ Cloud Sleuth+Zipkin

   1. 日志输出
   2. 日志收集
   3. 日志分析

   每个服务根据自身需要输出日志，大致分为：异常日志、请求响应结果日志、响应时间日志（整个请求的响应时间、某一块逻辑的响应时间，如数据库访问时间）等。

   由于微服务的服务/实例数量很多，可以在网关中做整体监控。

   不同类型/作用的日志采用不同的格式输出，这样方便后续收集展示。 ELK(ElasticSearch+Logstash+Kibana)+ Cloud Sleuth+Zipkin

   微服务之自动化测试与质量管理

   Nexus+Jenkins+Git+GitLab+Docker+SonarQube

   微服务之监控告警

   SpringBoot+Prometheus+grafana监控+alertmanager+企业微信报警

6. 描述并理解CAP和BASE理论

   CAP理论

   来自加州大学伯克利分校的Eric Brewer教授，这位教授好像很厉害的样子，据说是加州大学伯克利分校的终身教授，他首次提出了著名的cap猜想。后来，来自麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了这个猜想，从此出现了公认的cap定理：一个分布式系统不可能同时满足一致性[Consistency]，可用性[Availability]，和分区容错性[Partition tolerance]这三个基本需求，最多只能同时满足其中的两项。

   ①一致性。

   一致性是指数据在多个副本之间是否能够保持一致的特性。假如现在的多个结点中的数据是保持一致的，当执行完某一个更新操作之后，应当要保证系统的数据然后处于一致性的状态。

   对于一个将数据副本分布在不同的分布式节点上，如果对第一个结点的数据进行了更新的操作，并且更新成功之后，却没有让第二个节点得到相应的更新。当外部系统再去调用第二个节点时，获取到的依然是原始的数据，这就是分布式数据不一致的情况了。在分布式系统中，如果能够做到针对一个数据项更新操作执行成功之后，所有的用户都可以读取到最新的值，那么这样的系统就被认为是具有强一致性的。

   ②可用性。

   可用性是指系统提供的服务必须一致处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内，返回结果。

   有限的时间内：对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的结果。如果超过了这个时间，就认为系统是不可用的。

   返回结果是可用性的一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果包含成功或失败，而不是一个让用户迷惑的结果。

   ③分区容错性。

   分布式系统在遇到任何网络分区故障的时候，仍然需要对外提供满足一致性和可用性的服务。

   ①选择CA

   放弃分区容错性，比较简单的方式就是把所有的数据都放在一个分布式节点上。那不就又成为了单机应用了吗？

   ②选择CP

   放弃可用性，一旦出现网络故障，受到影响的服务需要再等待一定时间，因为系统处于不可用的状态。

   ③选择AP

   放弃一致性，这里所指的一致性是强一致性，但是确保最终一致性。是很多分布式系统的选择。

   小结：从cap的定理可以看出，分区容错性是一个最基本的要求，因为既然是一个分布式系统，必然要部署到两个或两个以上的节点上，否则，就不是分布式系统，因此我们只能在一致性和可用性寻求平衡。

   BASE理论

   base是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。base是对cap中一致性和可用性的权衡的结果。是根据cao理论演变而来，核心思想是即使无法做到强一致性，但是每个应用根据自身的业务特点，采用适当的方式来使系统达到最终与执行。

   ①基本可用

   基本可用指的是分布式系统出现了不可预知故障的时候，允许损失部分可用性。响应时间合理延长，功能上适当做服务降级。

   ②弱状态

   弱状态指的是允许系统中的数据存在中间状态，并认为该中间状态不会影响系统的整体可用性，即允许在各个节点数据同步时存在延时。

   ③最终一致性

   最终一致性强调的是系统中所有的数据副本，在经过一点时间 的同步之后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证数据最终能够达到一致。而不需要实时保证系统数据的一致性。

7. 描述你对DDD（领域驱动设计模式）的理解

   能够规范设计过程,使设计过程更加规范.

   有了规范的设计就有了核心而稳定是领域内核,当产品有了领域内核,领域知识的更利于传递.

   领域驱动设计强调团队与领域专家的合作,能够帮助团队建立良好的沟通.

   领域驱动设计的思想、原则与模式有助于提高团队成员面向对象设计能力与架构设计能力.

   DDD分为三个单词简写,分别为Domain,Driven,Design.

   Domain: 核心业务.要做什么样的系统,解决什么样的问题.

   Driven : 通过建立模型来解决领域中的核心问题.模型驱动思想.

   Design : 设计.只要保证领域模型设计正确,代码严格按领域驱动的意图落地,那就能解决领域的核心问题.