微服务面试题整理

分布式和微服务的区别是什么？

分布式系统是将传统的集中式系统拆分成多个独立的小系统，每个系统单独对外提供一部分功能。

而微服务是分布式系统的一种。其它还有C/S架构、Serverless架构、p2p架构等。

什么是微服务架构？优势？特点？

软件结构风格、拆分单元、独立部署运行扩展、轻量级的通信机制、高内聚低耦合、互不影响、不同技术栈、

微服务架构是一种软件结构风格，主要用于构建复杂的应用程序，它将一个大型的系统拆分成一组小型、独立的服务单元，每个服务单元都可以独立部署、运行和扩展。每个微服务都专注于一个特定的业务功能，并通过轻量级的通信机制进行通信。

微服务的目的是有效地拆分应用，实现敏捷开发和部署。实现系统高内聚和系统间低耦合。

并且每个拆分出来的服务都可以使用不同的技术栈，这使得团队可以选择最擅长的技术来构建服务。

SOA和微服务之间的主要区别是什么？

SOA和微服务差不多，主要是通信方面，SOA使用服务总线进行通信，而微服务基于更轻量的通信方式（rpc、http）。

什么是康威定律？

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these 》 organizations.- Melvin Conway(1967)

即设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。

即企业的组织结构决定了业务架构、系统架构。而系统架构的不合理，往往是因为组织架构的不合理导致的。

如何进行微服务的拆分？

业务功能。根据业务功能进行拆分，某些业务比较独立的，可以解耦出来的，可以单独作为一个服务。比如用户服务、订单服务等。
团队组织结构。按照康威定律来说，应用架构和组织架构应该是一一对应的，这样更容易进行微服务的开发与维护，能够做到最小成本沟通和最快速度迭代。
技术架构。不同的技术栈、不同的中间件体系，不同的开发语言等。

微服务架构的服务治理有哪些方案？

服务治理包括了以下模块：

服务注册与发现

微服务可以向注册中心注册服务的信息，如地址、端口等，其它服务可以动态地获取该服务的信息，从而实现服务之间的通信。

常见的实现方案有：

ZooKeeper
Concul
Eureka
Nacos

复杂均衡

负载均衡是指将请求分配到多个服务实例中，以达到分摊负载的目的，常见的实现方案有：

Ribbon：Ribbon是Netflix开源的一个负载均衡框架，可以与Eureka配合使用。
Nginx：Nginx是一个高性能的Web服务器，也可以用作反向代理和负载均衡器，可以实现对多个服务实例的复杂均衡。

熔断机制

当某个服务不可用时，可以快速断开该服务的调用，防止故障扩散，并提供备用响应或执行其他补救措施。常见的实现方案有：

Hystrix：Hystrix是Netfix开源的一个容错框架，可以实现服务的熔断、降级和容错等功能。
Sentinel：Sentinel是阿里开源的一个流量控制和容错框架，可以实现服务的熔断、降级、限流和系统保护等功能。

限流机制

限制服务的访问量，通过限制每个微服务的请求频率或并发数，防止服务过载和雪崩效应的发生。常见的实现方案有：

Rate Limiter：Rate Limiter是Google开源的一个限流框架，可以实现对访问频率的限制。
lstio：lstio是由Google、IBM和Lyft等公司共同推出的一个服务网格框架，可以实现对服务流量的控制和管理。
Sentinel：Sentinel也支持限流的功能。

降级机制

在资源紧张或者故障情况下，可以通过降级机制优先处理重要或者核心功能，关闭不重要的功能。比如，在后端出现问题时，前端执行默认兜底逻辑。常见的实现方案有：

Hystrix：Hystrix是Netflix开源的一个容错框架，可以实现服务的熔断、降级和容错等功能。
Sentinel：Sentinel也支持降级的功能。

分布式链路追踪

通过对微服务调用链路进行追踪和监控，可以帮助定位问题、优化性能，并提供可视化的调用链路图。常见的实现方案有：

skywalking：Skywalking是分布式系统的应用程序性能监视工具，专为微服务，云原生架构和基于容器(Docker，K8S,Mesos)架构而设计，它是一款优秀的APM工具，包括了分布式追踪，性能指标分析和服务依赖分析等。
zipkin：Zipkin是Twitter 的一个开源项目，基于Google Dapper实现。可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的RESTAPI接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。

服务监控

服务监控是指对服务进行实时监控和追踪，以及对服务性能进行评估和优化。常见的实现方案有：

Prometheus：Prometheus是由SoundCloud开源的一个监控系统，可以实现对服务的实时监控和度量。

什么是DevOps？

现在很多公司和团队都在提DevOps，这其实不是个技术，其实是一种开发流程，或者说一种开发文化。**它强调软件开发和IT运维的紧密结合，以实现更快速、更频繁、更可靠的软件交付。**DevOps的核心目标是提高软件交付的速度和质量，缩短软件上线的周期，同时提高应用程序的可靠性和可维护性。DevOps的出现是为了解决传统软件开发和运维模式中存在的问题，例如开发和运维之间的沟通不畅、软件交付周期过长、人工操作错误率高、应用程序可靠性低等。通过采用DevOps理念和工具，企业可以更快速、更高效地推出新的软件功能，降低软件交付成本，提高客户满意度。和传统的开发方式上比较的区别是:以前的开发模式中，开发和运维团队是完全独立开的，开发负责应用开发，运维团队负责打包和发布。出了问题各自看各自的问题。但是在DevOps的实践中，开发团队和运维团队不再是独立的个体，而是合作伙伴，共同负责整个软件的全生命周期，甚至有些公司直接不要运维团队了，由开发自己做运维。之所以可以这么做，是因为有很多持续集成、持续交付和持续部署的自动化工具的出现。

微服务中的CI/CD？

CI时Continuous Integration，翻译过来是持续集成，CD可以是Continuous Delivery和Continuous Deployment，翻译过来就是持续交付和持续部署。

CI是让开发者快速将变更合并到主干，就像Github Actions一样，在code review前，先把项目在不同平台上构建、测试，如果出现问题，就不进行code review，这大大降低了项目维护人员的工作时间。

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试如果代码没有问题，可以继续手动部署到生产环境中。

持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。

什么是ServiceMesh?

Service Mesh是一个比较新的概念，用于解决微服务架构中的一些问题，如服务发现、服务间通信、负载均衡安全、监控等。它是一种新型的架构模式，主要思想是将服务之间的通信从服务代码中抽象出来，并在整个应用中提供一种统一的方式进行管理和控制。 Service Mesh代理通常是以sidecar的方式部署在每个服务实例旁边，它们可以拦截和处理来自服务实例的所有网络流量，并提供各种功能，例如负载均衡、故障转移、熔断、限流、安全、监控等。Service Mesh代理可以提供更细粒度的控制和管理，例如在请求级别进行路由和重试，并且可以实时监控和调整服务的行为。

目前比较流行的Service Mesh产品包括lstio、Linkerd、Envoy等。 Service Mesh一般在异构系统中用的比较多，比如一家公司的技术栈比较杂，既有Java、又有C++，还有Python，PHP等，通过Service Mesh可以很好的用同一套架构体系将异构语言的程序员整合到一起。除了前面说的这些，ServiceMesh在实际应用中，还会用来实现以下以下一些功能:

rpc转http，http转rpc，用于调用者不支持rpc的情况
真实流量压测，将多机的流量转发到一台机器上
精准的流量分析，如vip日志，针对某个用户维度的全链路流量跟踪
服务健康状态巡检，分析服务的异常，qps，使用率等信息生成报告，并对比历史数据给出异常告警
提供数据通路，服务自身可以通过这个通路上报各种非业务性质的内部状态
流量拷贝和镜像，把流量拷贝到测试环境，再通过data mesh提供cow与线上数据环境打通，同时不影响线上业务数据。这样排查问题非常方便
加速服务通信性能，mesh aqnet位于服务机器内，通过l0与服务通信代理流量作为统一流量入口。lo不会过内核协议栈，大幅度降低cpu压力和耗时。而mesh agent自身收发网络流量也可以使用ebpf或者dpdk这样kernelbypass技术绕过协议栈协议解析，降低cpu压力和耗时。整体通信成本大幅度降低，使用mesh前耗时10-20ms可降低到几ms。

灰度发布、蓝绿部署、金丝雀部署都是什么？

蓝绿部署

蓝绿部署是在部署新版本时，准备两套相同的生产环境，成为蓝环境和绿环境。初始状态下，用户的请求会被路由到蓝环境，而绿环境处于闲置状态。

当新环境部署完成并通过测试后，将流量逐步切换到绿环境。而蓝环境作为备份。

金丝雀发布

金丝雀发布就是灰度发布。之所以叫金丝雀，是因为金丝雀对矿场的毒气比较敏感，所以矿场开工时会放一只金丝雀进去，以验证矿场是否有毒气。

这种方式，会在整个服务器集群中，挑选一部分机器进行灰度发布，发布会直接对外提供服务，来验证服务是否正常。

如果发现问题，可以及时回滚或者恢复，逐渐增加新版本的流量也可以降低风险，确保系统的稳定性。

如何快速回滚

记录基线。保留旧版本镜像。

什么是微服务的循环依赖？

服务之间互相调用，比如A调用B，B又反向调用A。循环依赖会导致以下问题：

流量放大:因为系统之间存在循环依赖，那么就会导致本来下单系统可能只有100 QPS，但是因为存在循环依赖，就会导致这个QPS被放大，因为100个请求调用到订单服务，订单服务就有100个请求调到库存服务，而库存服务又有100个请求再调到订单服务。就导致订单服务有200的QPS了。无形中被放大了流量。
性能问题:因为存在循环依赖，那么服务之间需要等待彼此的响应，就会无形中拖长请求的RT，让接口性能变的更慢。
互相影响:如果一个服务出现问题，这个问题可能会通过循环依赖影响到另一个服务。而一个服务中的错误可自能通过依赖链传播到其他服务，增加了系统出现级联故障的风险。
发布困难:每当一个服务需要更新时，我们需要同时考虑他依赖了谁以及谁依赖了他。一般是被依赖的应用先发布。但是因为系统间存在循环依赖，那么在上一个新的功能的时候需要发布时，就会带来很大的问题，那就是谁先发的问题，而谁先发都会有问题。

如何解决？

首先，遇到循环依赖的问题，第一件事就是考虑设计的不合理性，一般来说系统会有自己的明确的职责，并且一张自架构图中，一个系统一定是有属于他自己的位置的，一个系统又在上游，又在下游，那一定是设计的不合理，所以需要考虑做重新设计其次，像前面我们提到的例子，库存需要通知订单更新状态，这个过程我们可以把服务调用改成消息通信，通过异步消息来解耦调两个系统之间的相互依赖。这样就可以避免互相影响。另外，比较常用的一种方式，那就是引入一个共享库，当出现循环依赖时候，可以考虑将共享部分抽取出来作为-个共享库，然后由各个相关服务共同引用这个库。通过在循环依赖的两个微服务中引用共享库，而不是直接调用对方的接口来操作数据。上面的共享库，也可以做成一个共享服务(或者叫中介服务))，你俩不是互相依赖么，那么干脆我单独搞一个服务出来，你们都直接依赖他而不是做互相依赖。比如我们实际业务中就有一个台账系统，我们会把各个业务流水都写到台账中，所以当我们上游系统之间需要查询数据的时候，就可以直接去台账查，而不需要依赖其他的系统。而台账作为最下游系统，他也不会调用任何其他服务，他最多会提供消息给别的系统。

如何识别循环依赖？

链路追踪
评审

限流、降级、熔断有什么区别？

限流

限流的目的是控制系统的并发流量，通过限制请求流量的手段防止过度的流量导致系统崩溃。一般用于应对突发流量高峰。

降级

当系统负载过高，主动关闭一些非核心功能，以确保核心功能的正常运行。

熔断

熔断是为了防止系统因某个服务的故障而整体崩溃，类似于电路的熔断器。在检测到下游服务的异常时，自动停止向该服务发送请求，并在一定时间后尝试恢复。

各个微服务之间，有哪些调用方式？

HTTP、RPC、消息队列、Service Mesh

如果对性能有要求，需要选择高性能的RPC框架，如gRPC或者Dubbo等。
异步通信，需要消息队列。
跨语言场景，考虑用Service Mesh。

结论

微服务架构在现代软件开发中扮演着重要角色，理解其核心概念和相关技术是成功应对面试的关键。希望本文能为你提供有价值的信息，助你在微服务领域更进一步。

常见问题解答

微服务架构适合所有项目吗？
不适合。微服务更适合复杂的应用程序，对于小型项目，单体架构可能更简单有效。
如何监控微服务的性能？
使用APM工具，如Prometheus、Skywalking等进行性能监控。
微服务如何处理数据一致性问题？
可以使用分布式事务或最终一致性模型来处理数据一致性。
微服务的测试策略是什么？
应包括单元测试、集成测试和端到端测试，确保各个服务的功能和交互正常。
微服务的安全性如何保障？
可以通过身份验证、授权机制和加密等手段来保障微服务的安全性。