面試題
一、你的項目是從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認為是存活的。在這種情況下，可能需要額外的健康檢查機制來判斷服務實例的狀態。
 (A~B))
