面试题
一、你的项目是从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）堆栈，来分析日志，从而得到接口的耗时
三、 如果一个接口性能比较差，你该如何进行优化，请说明思路以及实施路径
排查接口执行慢，可以从以下角度考虑：
-
看是否有慢sql，如果有慢sql ，可以根据情况选择合适的索引。如果已经有索引，看索引是否失效 -
看是否有使用缓存 -
看是否可以使用异步，异步的方式可以根据具体情况选择多线程或者消息队列 -
看是否有用到大事务，如果有，需要将事务进行拆分 -
看代码业务逻辑，是否可以进行预处理，比如某个数据在多个地方用到了，可以先提前算出来 -
串行改并行，比如有a，b，c三个子接口，c接口需要依赖a的结果，b接口完全独立。那么可以将a，c和b分为两组，并行执行 -
看设计是否合理，比如某个接口，数据可以直接查出来，产品却搞了一堆配置。这种情况可以和产品沟通，是否有必要改需求。
四、你有没有进行过架构设计，架构设计需要考虑哪些方面，你是如何去实施的？
-
需要考虑；从承接的需求开始，分析项目。 -
系统分解：将整个系统分解为可管理的部分，通常是服务或模块，以便于理解、开发和测试。 -
组件选择：选择合适的软件和硬件组件，包括数据库、中间件、服务框架、前端框架等。 -
技术栈选择：根据项目需求和团队技能选择合适的技术栈。 -
可扩展性：设计时要考虑系统未来的扩展，包括水平扩展（增加更多的节点）和垂直扩展（增强单个节点的能力）。 性能：确保系统设计能够满足性能要求，包括处理速度、响应时间、吞吐量等。 -
可靠性和容错性：系统应该能够处理各种错误情况，并且在出现部分故障时仍能保持运行。 -
安全性：保护系统免受未授权访问和攻击，确保数据的安全和隐私。 -
可维护性和可测试性：设计应该便于未来的维护和升级，同时也要便于测试。
五、 如果一个程序的内存占用过高你该如何去分析呢？
可以基于监控工具进行全链路排查，查看QPS、TPS、瞬时峰值，用户规模等。之后在针对性的分析具体的系统流程。之后结合工具 JProfiler（一般全链路监控工具是有集成的）之后就可以看到具体的内存高的代码片段，在做分析和验证处理
六、nacos 注册中心怎么判断服务端已经崩溃了？
Nacos作为注册中心，通过心跳机制来检测服务实例是否存活。每一个注册到Nacos的服务实例，都会定期向Nacos发送心跳包，表明它们的存在。默认情况下，这个心跳间隔是5秒，也就是说每5秒，服务实例就会向Nacos发送一次心跳。
如果Nacos在15秒（默认配置，也就是3个心跳周期）内没有收到某个服务实例的心跳，那么Nacos会认为这个服务实例已经下线或者崩溃，然后从服务列表中移除这个服务实例。
这个心跳间隔和超时时间都可以在Nacos的配置中修改。如果你的服务实例在高负载下运行，或者网络状况不稳定，可能需要增大这些值以避免误判。
需要注意的是，这个机制只能检测服务实例是否能够正常响应心跳，不能判断服务实例是否能够正常提供服务。如果一个服务实例虽然能够发送心跳，但是由于某种原因无法正常处理请求，那么这个服务实例仍然会被Nacos认为是存活的。在这种情况下，可能需要额外的健康检查机制来判断服务实例的状态。