侧边栏壁纸
  • 累计撰写 14 篇文章
  • 累计创建 22 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录

微服务面试套路一

Administrator
2024-03-02 / 0 评论 / 0 点赞 / 47 阅读 / 4838 字

一、你的项目是从SpringBoot演进到微服务架构的,你在此过程中有调研过哪些技术,怎么调研落地的?

需要选择适合项目的微服务通信框架,如Dubbo、Spring Cloud或gRPC Feign RestTemplate 等。调研方式可以是通过官方文档、技术交流社区和开源项目等途径了解各个框架的优缺点,并根据项目需求进行选型。

容器化技术:

为了更好地管理微服务,需要将每个服务打包成容器镜像,如Docker等。调研方式可以是通过官方文档、技术交流社区和实践案例等途径了解Docker的使用方法和最佳实践,并学习如何将Spring Boot应用打包成Docker镜像。

服务注册与发现:

微服务架构中的服务数量众多,需要通过服务注册与发现来定位和调用其他服务。调研方式可以是通过官方文档、技术交流社区和开源项目等途径了解ZooKeeper、Eureka或Nacos 等服务注册与发现框架的原理和使用方法。

分布式事务:

在微服务架构中,需要保证事务的一致性和可靠性。调研方式可以是通过官方文档、技术交流社区和开源项目等途径了解Seata、Atomikos或Spring Cloud Transaction等分布式事务框架的原理和使用方法。

监控和日志管理:

微服务架构中的系统复杂度较高,需要对各个服务的性能和异常情况进行监控和日志管理。调研方式可以是通过官方文档、技术交流社区和开源项目等途径了解Prometheus、Grafana、Logstash或Kibana等监控和日志管理工具的原理和使用方法。

Api网关

Api网关是微服务架构中的重要组件 Zuul \ Gateway 等 我会部署一个Api网关 所有的外部请求都会先经过API 网关 再由Api 网关路由到相应的服务器. 以上是将SpringBoot项目演进到微服务架构过程中需要调研和落地的一些技术,调研方式包括官方文档、技术交流社区和实践案例等途径。在调研过程中需要根据项目需求和项目人员进行选型,并结合实际情况进行实践和调整。

二、 如何通过啥工具来查看分析一个接口中每个部分的耗时

分布式追踪系统:

像Zipkin、Jaeger、SkyWalking等分布式追踪系统可以帮助你追踪一个请求在系统中流转的情况,包括每个部分的耗时。这些系统通常需要你在代码中集成相关的库,然后它们就可以自动收集和上报追踪数据。

APM工具:

应用性能管理(APM)工具,如New Relic、Dynatrace、AppDynamics等,可以提供全面的性能监控和分析,包括接口耗时、数据库查询耗时、外部服务调用耗时等。

Profiler工具:

像JProfiler、YourKit等Profiler工具可以帮助你分析Java应用的性能,包括方法调用的耗时。这些工具通常需要你在启动Java应用时加入相关的参数,然后它们就可以收集和展示性能数据。

Spring Boot Actuator:

如果你的应用是Spring Boot应用,那么你可以使用Spring Boot Actuator的/metrics端点来查看一些基本的性能数据,包括接口的请求次数、平均耗时等。

日志分析工具:

如果你的应用将详细的日志(包括接口调用的开始时间和结束时间)输出到文件或者发送到日志服务,那么你可以使用日志分析工具,如ELK(Elasticsearch、Logstash、Kibana)堆栈,来分析日志,从而得到接口的耗时

三、 如果一个接口性能比较差,你该如何进行优化,请说明思路以及实施路径

排查接口执行慢,可以从以下角度考虑:

  1. 看是否有慢sql,如果有慢sql ,可以根据情况选择合适的索引。如果已经有索引,看索引是否失效
  2. 看是否有使用缓存
  3. 看是否可以使用异步,异步的方式可以根据具体情况选择多线程或者消息队列
  4. 看是否有用到大事务,如果有,需要将事务进行拆分
  5. 看代码业务逻辑,是否可以进行预处理,比如某个数据在多个地方用到了,可以先提前算出来
  6. 串行改并行,比如有a,b,c三个子接口,c接口需要依赖a的结果,b接口完全独立。那么可以将a,c和b分为两组,并行执行
  7. 看设计是否合理,比如某个接口,数据可以直接查出来,产品却搞了一堆配置。这种情况可以和产品沟通,是否有必要改需求。

四、你有没有进行过架构设计,架构设计需要考虑哪些方面,你是如何去实施的?

  1. 需要考虑;从承接的需求开始,分析项目。
  2. 系统分解:将整个系统分解为可管理的部分,通常是服务或模块,以便于理解、开发和测试。
  3. 组件选择:选择合适的软件和硬件组件,包括数据库、中间件、服务框架、前端框架等。
  4. 技术栈选择:根据项目需求和团队技能选择合适的技术栈。
  5. 可扩展性:设计时要考虑系统未来的扩展,包括水平扩展(增加更多的节点)和垂直扩展(增强单个节点的能力)。 性能:确保系统设计能够满足性能要求,包括处理速度、响应时间、吞吐量等。
  6. 可靠性和容错性:系统应该能够处理各种错误情况,并且在出现部分故障时仍能保持运行。
  7. 安全性:保护系统免受未授权访问和攻击,确保数据的安全和隐私。
  8. 可维护性和可测试性:设计应该便于未来的维护和升级,同时也要便于测试。

五、 如果一个程序的内存占用过高你该如何去分析呢?

可以基于监控工具进行全链路排查,查看QPS、TPS、瞬时峰值,用户规模等。之后在针对性的分析具体的系统流程。之后结合工具 JProfiler(一般全链路监控工具是有集成的)之后就可以看到具体的内存高的代码片段,在做分析和验证处理

六、nacos 注册中心怎么判断服务端已经崩溃了?

Nacos作为注册中心,通过心跳机制来检测服务实例是否存活。每一个注册到Nacos的服务实例,都会定期向Nacos发送心跳包,表明它们的存在。默认情况下,这个心跳间隔是5秒,也就是说每5秒,服务实例就会向Nacos发送一次心跳。

如果Nacos在15秒(默认配置,也就是3个心跳周期)内没有收到某个服务实例的心跳,那么Nacos会认为这个服务实例已经下线或者崩溃,然后从服务列表中移除这个服务实例。

这个心跳间隔和超时时间都可以在Nacos的配置中修改。如果你的服务实例在高负载下运行,或者网络状况不稳定,可能需要增大这些值以避免误判。

需要注意的是,这个机制只能检测服务实例是否能够正常响应心跳,不能判断服务实例是否能够正常提供服务。如果一个服务实例虽然能够发送心跳,但是由于某种原因无法正常处理请求,那么这个服务实例仍然会被Nacos认为是存活的。在这种情况下,可能需要额外的健康检查机制来判断服务实例的状态。

0
广告 广告

评论区