[每周一更]-(第121期)：模拟面试｜微服务架构面试思路解析

这一系列针对Go面试题整理，仅供参考

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取决于系统的优先级需求：

1. AP（可用性优先）：
   • 如果系统更看重服务的高可用性和响应速度，可以选择AP模式。
   • 适用场景：对瞬时一致性要求不高，允许服务间短时间内有一定的非一致性，比如负载均衡、自动扩展等。
   • 优势：即使在出现网络分区的情况下，系统仍可响应请求，最大化服务的可用性。
   • 示例：像Nacos、Eureka这样的注册中心可以采用AP模式，因其优先保证服务的实时可用性，适合对一致性要求不严格但高可用性要求高的场景。
2. CP（强一致性优先）：
   • 如果系统更注重数据一致性，则可选择CP模式。
   • 适用场景：对一致性要求高的系统，如分布式锁、选主机制、配置中心等，确保服务间的数据状态始终一致。
   • 优势：通过强一致性来确保所有服务的状态一致，但可能在网络分区发生时降低可用性。
   • 示例：Zookeeper、etcd是常见的CP注册中心，在分布式锁和选主中，确保严格一致性更为重要，适合关键数据强一致性的场景。

1. 什么是注册中心？

回答：注册中心是微服务架构中的一个核心组件，用于管理服务实例的注册和发现。服务启动后，会向注册中心注册自己的地址、端口等信息，其他服务可以从注册中心查询到该服务的位置。注册中心在服务间提供了一种动态发现的机制，使得服务消费者可以找到服务提供者的地址，而不需要硬编码。

2. 服务注册与发现机制的基本模型是怎样的？

回答：基本模型分为三部分：

• 服务注册：服务启动后，将自己的信息（如IP、端口、版本等）注册到注册中心，以供其他服务查找。
• 服务发现：其他服务通过注册中心找到已注册的服务，从而实现相互通信。
• 心跳检测：注册中心通过周期性的心跳或租约机制检测服务的健康状态，及时将异常的服务下线，确保可用性和一致性。

3. 服务上线与服务下线的步骤是什么？

回答：

• 服务上线：

  1. 服务启动后向注册中心发起注册请求，提交服务的地址、端口、版本等信息。
  2. 注册中心记录该服务的信息，将其加入可用服务列表。
  3. 注册中心通知服务发现客户端（消费者）更新服务列表。

• 服务下线：

  1. 服务停止前发送注销请求到注册中心。
  2. 注册中心将该服务从服务列表中删除。
  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（分区容错性）。在分布式系统中，同时满足三者很难，一般会根据需求在一致性和可用性