1：后端架构演变过程当中，单体到集群解决了什么问题？
后端从单体架构升级到集群架构，核心解决了单节点的性能瓶颈、服务可用性低、负载承载能力不足三大核心问题，同时也初步解决了业务增长带来的资源弹性诉求，具体落地价值：
- 突破硬件上限：摆脱单服务器的 CPU、内存、网络等硬件资源限制，通过多节点横向扩展支撑更高并发的业务请求，提升系统整体处理能力；
- 提升服务可用性：单节点故障不会导致整个系统宕机，剩余正常节点可继续承接请求，实现服务的故障容错和高可用；
- 实现负载均衡：通过负载均衡器将请求均匀分发到各节点，避免单节点过载，让系统资源得到充分利用，提升整体响应稳定性；
- 支持弹性扩展：可根据业务流量动态增加 / 减少节点，适配峰谷期的资源需求，相比单体架构的纵向扩容（升级单服务器硬件）更灵活、成本更可控。
简单来说，集群架构让系统从 "单台机器扛所有" 变成 "多台机器一起扛"，从根本上解决了单体架构在高并发、高可用场景下的核心痛点，为业务后续的规模化增长打下基础。
2：集群架构到分布式/微服务架构 解决了什么问题？请简要回答？
- 解决单体代码强耦合问题
集群还是一套单体代码部署在多节点，模块间代码耦合严重、牵一发而动全身；
分布式 / 微服务按业务域拆分独立服务，服务间低耦合，修改、迭代单个服务无需整体
发布，开发维护更高效。
- 解决资源利用率低问题
集群所有节点均运行完整的单体应用，无论业务模块流量高低，都占用相同的服务器资源，核心模块易资源不足、非核心模块易资源闲置；
分布式 / 微服务可对各服务独立分配资源，针对高流量核心服务精准扩容，低流量服务按需缩容，实现资源精细化利用。
- 解决整体扩展不灵活问题
集群扩展是对整个应用的 "无脑横向加节点"，哪怕仅一个模块压力大，也需扩容整个应用，扩缩容成本高、效率低；
分布式 / 微服务支持服务级精准扩缩容，仅对压力大的服务单独增加节点，扩展更灵活、资源投入更精准。
- 解决故障影响范围大问题
集群中单个模块出现故障，会导致整个节点的应用不可用，若故障模块是核心链路，所有集群节点都会受影响，最终引发系统整体故障；
分布式 / 微服务中各服务独立部署、运行，单个服务故障仅影响自身相关业务，通过熔断、降级可实现故障隔离，避免全链路雪崩。
- 解决团队协作效率低问题
集群模式下多团队开发仍基于同一套代码库，易出现代码冲突、提测发布相互阻塞，开发效率随团队规模扩大而降低；分布式 / 微服务让各团队负责独立的服务模块，可独立开发、测试、发布，实现团队并行协作，适配大规模研发团队的分工需求。
- 解决技术栈单一锁定问题
集群部署的单体应用通常采用单一技术栈开发，若部分业务模块有更适配的技术方案
分布式 / 微服务各服务可独立选择适配自身业务特性的技术栈、中间件，实现技术栈解耦，让技术方案更贴合业务需求。
3：分布式和微服务关系是什么？
分布式是基础思想 / 架构模式：
核心是将一个完整系统拆分为多个独立模块，部署在不同节点（服务器 / 容器）上协同工作，解决单节点性能、可用、扩展瓶颈，是大范畴。
微服务是分布式的一种现代实现形式：
微服务严格遵循 "单一职责、服务自治、轻量通信" 原则，将系统拆分为独立部署、独立开发、独立运维 的小型服务，是分布式架构的精细化、标准化落地。
关系总结：微服务属于分布式，但分布式≠微服务；
分布式是底层逻辑，微服务是该逻辑在云原生、敏捷开发背景下的具体实践方案。
4：分布式还有没有其他实现方式
除微服务外，分布式常见实现形式还有：
垂直拆分：
按业务模块将单体系统拆分为独立的垂直应用（如电商拆分为订单、支付、商品系统），各应用独立部署，无跨应用服务调用；
SOA（面向服务架构）：
将系统拆分为松耦合的服务，通过企业服务总线（ESB） 实现服务间通信、协议转换，服务粒度比微服务粗，中心化管理；
集群化部署：
单应用无业务拆分，仅将相同的单体应用部署在多节点，通过负载均衡实现分流（如 Tomcat 集群、数据库主从），是最基础的分布式；
分布式中间件化：
核心业务仍为单体，仅将存储、计算、消息等能力抽离为分布式中间件（如 Redis 集群、Kafka 集群、Elasticsearch 集群），单体应用对接中间件实现分布式能力。