这一系列针对Go面试题整理，仅供参考
文章目录
-
- 00｜综合服务治理方案：怎么保证微服务应用的高可用？
-
- 1. **什么是微服务架构？**
- 2. **怎么保证微服务架构的高可用？**
- 3. **怎么判定服务是否已经健康？**
- 4. **如果服务不健康该怎么办？**
- 5. **怎么判定服务已经从不健康状态恢复过来了？**
- 6. **Redis崩溃时如何处理？**
- 7. **Kafka崩溃时如何处理？**
- 8. **设计开放平台时需要考虑哪些问题？**
- 01｜服务注册与发现：注册中心应该选 AP 还是 CP？
-
- 0. 服务注册与发现：注册中心应该选 AP 还是 CP？
- 1. **什么是注册中心？**
- 2. **服务注册与发现机制的基本模型是怎样的？**
- 3. **服务上线与服务下线的步骤是什么？**
- 4. **注册中心选型需要考虑哪些因素？**
- 5. **为什么使用 Zookeeper/Nacos/etcd 作为注册中心？**
- 6. **什么是CAP？**
- 7. **在服务注册与发现里面你觉得应该用 AP 还是 CP？**
- 8. **如何保证服务注册与发现的高可用？**
- 9. **服务器崩溃，如何检测？**
- 10. **客户端容错的措施有哪些？**
- 11. **注册中心崩溃了怎么办？**
- 12. **注册中心怎么判断服务端已经崩溃了？**
- 02｜负载均衡：调用结果、缓存机制怎么影响负载均衡的？
-
- 1. **你了解负载均衡算法吗？**
- 2. **静态负载均衡算法和动态负载均衡算法的核心区别是什么？**
- 3. **轮询与随机负载均衡算法有什么区别？**
- 4. **你了解平滑的加权轮询算法吗？**
- 5. **如何根据调用结果来调整负载均衡效果？**
- 6. **为什么有些算法要动态调整节点的权重？权重究竟代表了什么？**
- 7. **你们公司的算法有没有调整过权重？为什么？**
- 8. **最快响应时间负载均衡算法有什么缺点？**
- 9. **如果我现在有一个应用，对内存和CPU都非常敏感，你可以针对这个特性设计一个负载均衡算法吗？**
- 10. **为什么使用轮询、加权轮询、随机之类的负载均衡算法，系统仍会出现偶发性的流量不均衡？**
- 03｜熔断：熔断-恢复-熔断-恢复，抖来抖去怎么办？
-
- 1. **熔断可以提高系统的可用性吗？为什么？**
- 2. **如何判断节点的健康状态？需要看哪些指标？**
- 3. **触发熔断之后，该熔断多久？**
- 4. **响应时间超过多少应该触发熔断？**
- 5. **响应时间超过阈值就一定要触发熔断吗？**
- 6. **怎么避免偶发性超过阈值的情况？**
- 7. **服务熔断后如何恢复？**
- 8. **熔断恢复中的抖动现象的原因和解决方法**
- 04｜降级：为什么每次大促的时候总是要把退款之类的服务停掉？
-
- 1. **什么时候会用到降级？请举例说明**
- 2. **降级有什么好处？**
- 3. **跨服务降级常见的做法是什么？**
- 4. **怎么评估业务服务的重要性？或者说，你怎么知道 A 服务比 B 服务更加重要？**
- 5. **服务内部常见的降级思路是什么？**
- 6. **怎么判断哪些服务需要降级？**
- 7. **触发降级之后，应该保持在降级状态多久？**
- 8. **服务降级之后如何恢复，如何保证恢复过程中不发生抖动？**
- 9. **公司产品首页如何保证高可用？**
- 05｜限流：别说算法了，就问你阈值怎么算？限流的目的是什么？
-
- 1. **限流算法都包括哪些？**
- 2. **不同的限流算法怎么选？**
- 3. **限流的对象应该如何选择？**
- 4. **怎么确定流量的阈值？**
- 5. **如何应对突发流量？**
- 6. **被限流的请求会被怎么处理？**
- 7. **为什么使用了限流，系统还是有可能崩溃？**
- 8. **一个功能普通用户需限制每分钟不超过 10 次，整天不超过 1000 次；VIP 用户不限制，如何实现？**
- 06｜隔离：怎么保证尊贵的 VIP 用户体验不受损？
-
- 1. **什么是隔离，你用来解决什么问题？**
- 2. **你了解哪些隔离策略？你用过哪些？**
- 3. **当某个服务崩溃的时候，你有什么办法保证其它服务不受影响？**
- 4. **在使用线程池、连接池和协程池的时候，怎么避免业务之间相互影响？**
- 07｜超时控制：怎么保证用户一定能在1s内拿到响应？
-
- 1. **为什么要做超时控制？**
- 2. **为什么缺乏超时控制有可能引起连接泄露、线程泄露？**
- 3. **什么是链路超时控制？**
- 4. **如何确定超时时间？**
- 5. **怎么在链路中传递超时时间？**
- 6. **超时时间传递的是什么？**
- 7. **如何计算网络传输时间？**
- 8. **什么是时钟同步问题？**
- 9. **客户端和服务端谁来监听超时？**
- 10. **超时之后能不能中断业务？怎么中断？**
- 08｜调用第三方：下游的接口不稳定性能又差怎么办？
-
- 1. **如何保证调用第三方接口的可用性？**
- 2. **如果在出错的时候你会切换不同的第三方，但是如果全部第三方换一遍之后都崩溃了，怎么办？**
- 3. **调用第三方接口出错的时候，你是怎么重试的？重试次数和重试间隔你是怎么确定的？**
- 4. **你怎么判定第三方服务已经非常不可用，以至于要切换一个新的第三方服务了？**
- 5. **对时效性要求不高的接口，你可以怎么优化架构？**
- 6. **在压力测试一个接口的时候，如果这个接口依赖了一个第三方接口，你怎么解决？**
- 7. **公司业务依赖一个非常关键的第三方依赖，我要怎么保证我在调用第三方的时候不出错？**
00｜综合服务治理方案：怎么保证微服务应用的高可用？
- 什么是微服务架构？
- 怎么保证微服务架构的高可用？
还有下面这些问题，横跨了多个主题，可以从不同的角度回答。 - 怎么判定服务是否已经健康？
- 如果服务不健康该怎么办？
- 怎么判定服务已经从不健康状态恢复过来了？
- 听你说你用到了 Redis 作为缓存，如果你的 Redis 崩溃了会怎么样？
- 听你说你用到了 Kafka 作为消息队列，如果你的 Kafka 崩溃了怎么办？
- 现在需要设计一个开放平台，即提供接口给合作伙伴用，你觉得需要考虑一些什么问题？
1. 什么是微服务架构？
回答：微服务架构是一种将应用程序拆分为多个小而独立服务的设计方法，每个服务围绕特定的业务功能构建，具有独立的代码库、数据库和生命周期。每个微服务通常通过轻量级通信协议（如HTTP或gRPC）来实现服务间通信。这种架构使得开发团队可以独立地构建、部署和扩展每个服务，有助于增加系统的灵活性和弹性，但也带来了服务协调和复杂度管理的挑战。
2. 怎么保证微服务架构的高可用？
回答：
- 冗余和自动化恢复：通过水平扩展和服务实例的冗余来确保在部分实例故障时系统仍可用。使用自动恢复工具（如Kubernetes的自动重新调度、Pod重启策略等）来快速替换故障实例。
- 负载均衡：借助负载均衡器（如Nginx、Envoy、Kubernetes Service），将请求均匀分配到多个实例，防止单一实例过载。
- 服务降级和熔断：为关键服务实现熔断器（如Hystrix或Resilience4j）和降级策略，一旦检测到异常，自动限流或提供部分功能，防止连锁反应导致整体不可用。
- 健康检查：配置健康检查探针（如HTTP探针、TCP探针），监控每个微服务的状态，发现异常时自动剔除不健康的服务实例。
- 数据隔离和备份：在数据库或缓存层上设置主从架构、数据备份、分布式存储，以确保数据可用性和一致性。
3. 怎么判定服务是否已经健康？
回答：通过健康检查机制来判定服务的健康状态，通常包括两类检查：
- Liveness Check：判定服务是否存活，通常检查服务的基础运行状态，例如端口可用性、主线程是否卡住等。
- Readiness Check：判定服务是否已准备好处理请求，主要检测依赖组件（如数据库、缓存）的连接状态，确保服务可以正常响应用户请求。
4. 如果服务不健康该怎么办？
回答：当服务被判定为不健康时，可以采取以下措施：
- 重启实例：在自动化部署环境中（如Kubernetes），可以配置自动重启机制，让调度器自动重启故障实例。
- 降级服务：部分场景下，可以将不健康实例的功能降级，如提供只读功能或禁用部分非关键操作。
- 熔断或剔除实例：通过熔断器或负载均衡将不健康实例从服务池中剔除，避免它对外提供服务。
- 发送告警通知：将故障情况通知给相关运维或开发人员，及时进行人工干预或分析根本原因。
5. 怎么判定服务已经从不健康状态恢复过来了？
回答：可以通过以下方法判定服务是否恢复正常：
- 持续监控健康检查：当服务通过了一段时间的健康检查后，视为已经恢复正常。
- 基于监控指标：借助日志分析、监控工具（如Prometheus、Grafana），观察请求响应时间、错误率、资源使用情况等指标是否恢复正常。
- 验证依赖连接：如果恢复服务依赖外部系统（如数据库、缓存），需要确认与依赖系统的连接是否已经恢复稳定。
6. Redis崩溃时如何处理？
回答：
- 缓存降级：Redis崩溃时，服务应能够实现缓存降级策略，将数据请求转发到数据库中并返回给用户，同时监控数据库的负载情况。
- 重启或切换到备份节点：设置主从架构或Redis Cluster模式，在主节点崩溃时自动切换到备节点。确保集群具备自动恢复机制。
- 热加载：在Redis恢复后，从数据库批量加载重要数据进入缓存，恢复缓存命中率。
- 报警通知：及时向运维人员发送报警，以便快速介入处理。
7. Kafka崩溃时如何处理？
回答：
- 副本恢复：Kafka通常会配置多副本机制，以确保单节点故障不会导致数据丢失。在故障节点恢复或重启后，会自动从其他副本中恢复消息。
- 重试机制：对于重要消息，可以在生产者端和消费者端设置重试机制，避免Kafka短暂不可用导致的数据丢失。
- 数据存储回滚：在关键任务场景下，可以在消费者侧保存处理进度的偏移量，等Kafka恢复后再从上次偏移量继续消费，避免消息丢失。
- 监控与报警：通过Kafka的监控工具及时发现故障节点，及时进行修复或节点替换。
8. 设计开放平台时需要考虑哪些问题？
回答：
- 认证和授权：为合作伙伴提供安全的认证机制（如OAuth2.0、API Key），并确保API接口的授权和权限控制，避免数据泄露。
- 限流和防护：设置限流策略，防止恶意请求或误用造成系统过载。可以通过API Gateway或WAF（Web Application Firewall）来防止DDoS攻击。
- 稳定性和高可用：使用负载均衡、故障转移和健康检查等方法，确保API接口的高可用性和稳定性，防止接口长时间不可用。
- 版本控制：API接口需要支持版本控制，确保新功能不会影响到旧版本合作伙伴的正常使用，提供合理的升级和迁移计划。
- 监控和日志：设置全面的监控和日志系统，跟踪接口调用、错误率、响应时间，帮助快速定位问题并优化。
- 文档和支持：提供完善的API文档和示例代码，便于合作伙伴快速集成，并设置技术支持通道，解决合作伙伴的问题。
01｜服务注册与发现：注册中心应该选 AP 还是 CP？
- 什么是注册中心？
- 服务注册与发现机制的基本模型是怎样的？
- 服务上线与服务下线的步骤是什么？
- 注册中心选型需要考虑哪些因素？
- 你为什么使用 Zookeeper/Nacos/etcd 作为你的注册中心？
- 什么是CAP?
- 在服务注册与发现里面你觉得应该用 AP 还是 CP？
- 如何保证服务注册与发现的高可用？
- 服务器崩溃，如何检测？
- 客户端容错的措施有哪些？
- 注册中心崩溃了怎么办？
- 注册中心怎么判断服务端已经崩溃了？
0. 服务注册与发现：注册中心应该选 AP 还是 CP？
在微服务注册与发现中，多数应用更偏向AP，因其高可用性更适合大多数服务间的通信需求。如果系统内存在强一致性的需求，可以在特定模块使用CP模式的注册中心（如Zookeeper、etcd）。
在服务注册与发现中，是否选择AP或CP取决于系统的优先级需求：
- AP（可用性优先）：
- 如果系统更看重服务的高可用性和响应速度，可以选择AP模式。
- 适用场景：对瞬时一致性要求不高，允许服务间短时间内有一定的非一致性，比如负载均衡、自动扩展等。
- 优势：即使在出现网络分区的情况下，系统仍可响应请求，最大化服务的可用性。
- 示例：像Nacos、Eureka这样的注册中心可以采用AP模式，因其优先保证服务的实时可用性，适合对一致性要求不严格但高可用性要求高的场景。
- CP（强一致性优先）：
- 如果系统更注重数据一致性，则可选择CP模式。
- 适用场景：对一致性要求高的系统，如分布式锁、选主机制、配置中心等，确保服务间的数据状态始终一致。
- 优势：通过强一致性来确保所有服务的状态一致，但可能在网络分区发生时降低可用性。
- 示例：Zookeeper、etcd是常见的CP注册中心，在分布式锁和选主中，确保严格一致性更为重要，适合关键数据强一致性的场景。
1. 什么是注册中心？
回答：注册中心是微服务架构中的一个核心组件，用于管理服务实例的注册和发现。服务启动后，会向注册中心注册自己的地址、端口等信息，其他服务可以从注册中心查询到该服务的位置。注册中心在服务间提供了一种动态发现的机制，使得服务消费者可以找到服务提供者的地址，而不需要硬编码。
2. 服务注册与发现机制的基本模型是怎样的？
回答：基本模型分为三部分：
- 服务注册：服务启动后，将自己的信息（如IP、端口、版本等）注册到注册中心，以供其他服务查找。
- 服务发现：其他服务通过注册中心找到已注册的服务，从而实现相互通信。
- 心跳检测：注册中心通过周期性的心跳或租约机制检测服务的健康状态，及时将异常的服务下线，确保可用性和一致性。
3. 服务上线与服务下线的步骤是什么？
回答：
-
服务上线：
- 服务启动后向注册中心发起注册请求，提交服务的地址、端口、版本等信息。
- 注册中心记录该服务的信息，将其加入可用服务列表。
- 注册中心通知服务发现客户端（消费者）更新服务列表。
-
服务下线：
- 服务停止前发送注销请求到注册中心。
- 注册中心将该服务从服务列表中删除。
- 注册中心通知相关的客户端更新服务列表。
4. 注册中心选型需要考虑哪些因素？
回答：
- CAP属性：需要考虑一致性（Consistency）与可用性（Availability）的平衡。不同的注册中心（如Zookeeper、etcd、Nacos）对CAP属性的支持不一样。
- 性能和可扩展性：要评估注册中心的性能，特别是在高并发下的负载能力。
- 高可用和容错能力：确保注册中心的高可用性，选择具备容灾能力的方案。
- 数据一致性需求：如在强一致性场景中，Zookeeper或etcd适合；在可用性优先场景中，可以选择Nacos或Eureka。
- 生态兼容性和易用性：如选择与已有生态兼容的注册中心（Kubernetes原生服务发现、Spring Cloud的Eureka等）。
5. 为什么使用 Zookeeper/Nacos/etcd 作为注册中心？
回答：选择注册中心的原因包括：
- Zookeeper：提供强一致性（CP），适合对服务一致性要求较高的场景；如分布式锁、选主服务的场景。
- Nacos：支持AP模式，具有良好的扩展性，适合对可用性要求高且更关注实时性的场景。Nacos还支持多语言和丰富的配置管理功能。
- etcd：也是CP系统，性能高，适合对数据一致性要求高的场景，如Kubernetes等分布式系统使用etcd来存储集群配置。
6. 什么是CAP？
回答：CAP指的是Consistency（一致性）、Availability（可用性）**和**Partition Tolerance（分区容错性）。在分布式系统中，同时满足三者很难，一般会根据需求在一致性和可用性
