应用架构演进历史以及各个阶段使用的主要技术

CAP模型

分布式系统设计的核心理论，指出一个系统无法同时完美满足

• 一致性（Consistency）：所有节点在同一时间看到相同的数据
• 可用性（Availability）：每个请求都能收到响应，系统持续运行
• 分区容错性（Partition tolerance）：系统在部分节点间通信失败时仍能工作

这三个需求，最多只能同时保证其中的两项。

模型类型	特点	适用场景
‌CA模型‌	放弃分区容错性，追求强一致性和高可用性	单节点数据库（如PostgreSQL、Redis），不适用于分布式环境
CP模型	放弃可用性，保证一致性和分区容错性	银行转账系统、分布式数据库（如ZooKeeper），允许系统在分区时暂时不可用
AP模型	放弃一致性，保证可用性和分区容错性	电商网站、社交网络（如AWS DynamoDB），允许读取到过期数据

BASE理论

在分布式系统中，可以通过牺牲强一致性，来换取更高的可用性和性能‌。由三个核心思想组成：

• ‌基本可用 （Basically Available）：系统允许部分功能在故障时降级，但核心功能必须保持可用。
• ‌软状态（Soft State）：允许数据在不同节点间存在短暂的不一致（中间状态），这是为了应对网络延迟或分区。
• ‌最终一致性 （Eventual Consistency）：经过一段时间，所有数据副本最终会达成一致。

和ACID（强一致性）的主要区别在于，BASE更注重‌可用性‌和‌性能‌，适用于像电商、社交网络这类对实时性要求高的场景。

微服务架构常用技术

微服务架构技术的核心是将应用拆分为一组松耦合、可独立部署的小型服务，每个服务围绕特定业务能力构建，通过轻量级通信机制交互。其关键技术栈包括：

一、常用技术栈

‌1.服务注册与发现‌

服务注册与发现是微服务架构中的核心组件，它允许服务在启动时向注册中心注册自己的网络位置，并让其他服务能够动态发现和通信。

(1) Eureka

• ‌特点‌：由Netflix开发，是一个基于 REST 的服务，是Spring Cloud生态中的核心组件之一。它提供服务注册与发现功能，支持服务的自动注册和发现。
• ‌适用场景‌：适用于Spring Cloud微服务架构，尤其在传统微服务项目中广泛使用。
• 核心功能：服务注册、服务发现、健康检查等。
• 核心组件：Eureka Server（服务注册中心）和 Eureka Client（服务客户端）。
• 一致性模型：遵循 ‌AP 模型，优先保证服务可用性，允许数据最终一致性

(2)‌ Consul‌(HashiCorp)

• ‌特点‌：由HashiCorp开发，不仅提供服务注册与发现，还支持健康检查、键值存储和多数据中心功能。Consul提供了更丰富的功能，适合复杂的分布式系统。
• ‌适用场景‌：适用于需要健康检查和多数据中心支持的场景。
• 核心功存储能：‌键值（Key/Value Storage）、安全服务通信‌、多数据中心支持‌等。
• 核心组件：‌Agent（Client 模式、Server 模式）‌、‌Server 集群‌、Gossip 协议‌
• 一致性模型： ‌CP 模型‌，Raft 协议、GOSSIP协议

(3) Nacos‌‌(阿里)

• 特点‌：阿里巴巴开源的动态服务发现、配置管理和服务管理平台。
• ‌适用场景‌：适用于需要配置中心和动态服务发现的场景，特别适合国内企业级应用。
• 核心功能：‌服务发现与注册‌、动态配置管理‌、服务健康检查、动态DNS服务‌、元数据管理。
• 核心组件：‌Nacos Server‌、Nacos Client‌、Naming Service、Config Service‌。
• 一致性模型：AP模型（可用性优先）‌和CP模型（一致性优先）

(4)‌ Zookeeper‌(Apache)

• ‌特点‌：Apache Zookeeper是一个开源的分布式协调服务，常用于实现服务注册与发现。它通过维护配置信息和服务状态，实现分布式系统中的协调和一致性。
• ‌适用场景‌：适用于需要强一致性保证的分布式系统，如分布式锁、配置管理等。
• 核心功能：支持分布式系统的协调和管理，分布式锁、配置管理、Master选举等。
• 核心组件：ZK集群、Znode节点、Leader节点等
• 一致性模型：‌顺序一致性、原子性‌、单一视图、‌可靠性、ZAB协议

(5) Spring Cloud Consul‌

• ‌特点‌：Spring Cloud对Consul的支持，提供了与Spring Boot和Spring Cloud的无缝集成。
• ‌适用场景‌：适用于基于Spring Boot和Spring Cloud构建的微服务架构。
• 核心功能：同Consul‌。
• 核心组件：同Consul‌。
• 一致性模型：同Consul‌。

(6)‌ Spring Cloud Eureka‌

• ‌特点‌：Spring Cloud 项目对 Eureka 的集成和封装，简化了Eureka的集成过程。通过Spring Cloud Eureka，开发者可以快速构建服务注册与发现的微服务架构。
• ‌适用场景‌：适用于基于Spring Boot和Spring Cloud构建的微服务架构。
• 核心功能：同Eureka。
• 核心组件：同Eureka。
• 一致性模型：同Eureka。

(7) Dubbo‌(阿里)

• ‌特点‌：阿里巴巴开源的高性能RPC框架，支持服务注册与发现。Dubbo通过Zookeeper等注册中心实现服务的自动注册与发现。
• ‌适用场景‌：适用于需要高性能RPC调用的微服务架构。
• 核心功能：远程方法调用、智能容错及负载均衡、服务注册及发现。
• 核心组件：‌注册中心（Registry）、‌服务提供者（Provider）、服务消费者（Consumer）、监控层（Monitor）‌等
• 一致性模型：通过服务治理能力来支持分布式环境下的数据一致性需求。

(8)‌ Kubernetes Service‌

• ‌特点‌：Kubernetes原生的服务发现机制，通过Pod的标签选择器和Service对象实现服务的注册与发现。Kubernetes Service为Pod提供稳定的网络访问入口。
• ‌适用场景‌：适用于容器化部署的微服务架构，特别是使用Kubernetes进行编排的场景。
• 核心功能：为一组 Pod 提供稳定的网络访问入口和负载均衡能力，它隐藏了后端 Pod 的动态变化，确保客户端能够持续访问服务。
• 核心组件：‌kube-proxy(网络代理组件)、kube-apiserver‌(与 etcd 集群交互的组件，负责管理集群状态和数据)、‌etcd‌(集群数据的后台数据库)、‌EndpointSlice 控制器‌。
• 一致性模型：‌数据一致性‌、服务状态一致性‌、Pod 状态一致性

2.负载均衡‌

(1) Ribbon

• 实现方式：采用传统的阻塞式调用方式，其核心 API 基于线程池和阻塞调用，在响应式编程场景下兼容性较差。此外，Ribbon 包含了大量 Netflix 的内部组件，导致包体积较大、复杂度较高。
• 集成与扩展性：独立的第三方库，需要单独引入，并且需要手动配置负载均衡策略和服务发现机制
• 负载均衡策略：轮询、随机、加权等，这些策略可以通过配置进行调整。

(2) Spring Cloud LoadBalancer

• 实现方式：基于响应式编程（Project Reactor），天然支持响应式编程，同时对阻塞式调用也提供了适配。它在性能上表现更好，具有更轻量级的依赖，启动更快。
• 集成与扩展性：与Spring Cloud生态系统深度集成，提供更多的特性(如断路器和监控)，具备良好的扩展性。
• 负载均衡策略：目前提供的负载均衡策略相对较少。

‌3.服务通信‌

‌(1) RESTful API‌

• 特点：以资源为中心，强调通过统一接口对资源进行操作。每个资源由 URI 唯一标识，通过标准 HTTP 方法（GET、POST、PUT、DELETE）来执行 CRUD 操作。它遵循无状态、可缓存等架构约束
• 性能：基于HTTP，最常用且简单‌。
• 适用场景：需要广泛集成和公共 API 的场景。

‌(2) RPC框架‌

• 特点：远程过程调用，更关注“动作”或“过程”，将远程服务调用伪装成本地方法调用。
• 性能：性能上优于 RESTful API，因为它使用更轻量级的协议和二进制数据格式
• 适用场景：如gRPC、Dubbo，适合高性能、内部服务调用的场景

4‌.API网关‌

网关作为统一入口，是微服务架构中的核心组件，它作为统一入口，处理所有外部请求，负责路由、安全、限流等关键功能，有效简化了客户端与后端服务的交互。

核心功能：

• ‌请求路由与负载均衡‌：根据URL、Header等规则将请求转发到对应服务，并支持负载均衡策略。
• ‌安全与认证‌：集成OAuth2.0、JWT等协议，统一处理身份验证和权限控制。
• ‌限流与熔断‌：通过令牌桶等算法限制请求速率，并在服务故障时快速失败，保护后端系统。
• ‌协议转换‌：支持HTTP、gRPC、WebSocket等协议间的转换，简化客户端调用。
• ‌监控与日志‌：收集请求延迟、成功率等指标，便于性能分析和故障排查。

主要技术：

(1) Nginx(流量网关)

• 技术特性：基于 C 语言开发，高性能的 HTTP 和反向代理服务器。
• 局限性：功能单一，缺乏服务治理、动态配置能力
• 适用场景：
  • 作为‌反向代理服务器‌，处理静态资源和负载均衡。
  • 适用于‌非微服务架构‌或需要高性能处理的场景。
  • 作为‌流量入口网关‌，处理大量请求

(2) Zuul(Netflix)

• 技术特性：基于 Java Servlet 实现，是 Netflix 开源的网关。使用阻塞式 API，不支持长连接和异步处理，性能低于 Spring Cloud Gateway。
• 局限性：需依赖 Ribbon + Eureka 实现。
• 适用场景：对自定义过滤器有深度定制需求的场景，适用于初期微服务架构。

(3) Spring Cloud Gateway

• 技术特性：基于 Java 8、Spring 5、Spring Boot 2 和 Project Reactor 构建，与 Spring Cloud 生态无缝集成。
• 局限性：配置复杂、限流机制局限、依赖外部系统、技术栈限制以及路由稳定性等。
• 适用场景：
  • ‌Spring Cloud 微服务架构‌中的首选网关。
  • 需要与 Spring 生态系统深度集成的项目。
  • 对性能和响应式编程有较高要求的场景。

5‌.配置中心‌

(1) Nacos(阿里)

• 功能特性：全面的微服务平台，不仅提供配置管理功能，还支持动态服务发现、服务注册与管理等。它具备更丰富的配置推送通知机制和版本管理功能。
• 配置更新机制：支持长轮询机制，配置变更后能迅速通知客户端，响应速度优于 Spring Cloud Config
• 适用场景：需要服务发现与配置管理一体化的场景

(2) Spring Cloud Config

• 功能特性：专注于配置管理，其配置存储默认基于 Git，适合与 Spring Cloud 生态无缝集成。但它缺乏可视化界面，配置更新依赖于 Spring Cloud Bus 消息总线
• 配置更新机制：需要结合 Spring Cloud Bus 实现动态刷新，流程相对复杂
• 适用场景：已有 Spring Cloud 架构且对 Git 配置管理有强依赖的项目

‌6.熔断与限流‌，防止故障扩散和保障稳定性

(1) Hystrix(Netflix)

• 核心功能：主要围绕‌熔断器模式‌和服务‌隔离‌设计，其核心目标是防止服务级联故障，通过线程池隔离或信号量隔离来保护系统。
• 隔离策略：采用‌线程池隔离‌或‌信号量隔离。
• 熔断机制：基于‌失败比率‌（异常比率）和‌超时‌，当调用失败率或超时达到设定阈值时，会触发熔断，阻止后续请求，直到熔断窗口期结束后自动恢复。

(2) Sentinel(阿里)

• 核心功能：流量控制组件，支持流量控制、熔断降级、系统自适应保护‌等多方面能力。还提供了细粒度的流量控制策略，如基于 QPS、并发线程数、调用关系等进行限流。
• 隔离策略：支持‌信号量隔离‌和‌基于线程池的隔离‌。
• 熔断机制：熔断策略更加丰富，支持‌基于响应时间、异常比率、异常数‌等多种熔断策略，且能更灵活地应对不同异常情况

二、通信协议

1‌.同步‌

(1) HTTP/REST

• 协议基础：基于 HTTP 协议的‌资源导向‌通信方式。
• 性能：使用文本格式（如 JSON）和 HTTP/1.1 协议，存在‌头部信息冗余‌和‌单连接串行处理‌的问题，在高并发场景下性能较低。传输效率不如二进制协议。
• 服务治理：依赖外部组件（如 API 网关、服务注册中心）实现。
• 适用场景：对外暴露 API、跨平台调用、需要浏览器或移动端支持的场景。

(2) gRPC

• 协议基础：基于 ‌HTTP/2‌ 协议和 ‌Protocol Buffers (protobuf)‌ 序列化协议。
• 性能：吞吐量和延迟表现‌显著提升。其二进制格式比 JSON 小得多，数据传输更高效。在高 QPS 和低延迟要求的场景下，gRPC 的性能优势明显。
• 服务治理：依赖于外部服务发现机制
• 适用场景：高性能、低延迟的‌微服务间通信‌，特别是金融交易系统、实时多人游戏等对延迟敏感的场景

(3) Dubbo‌

• 协议基础：高性能 Java RPC 框架，支持多种通信协议，默认的 Dubbo 协议基于 ‌Netty‌ 实现，提供高性能的二进制传输。
• 性能：默认协议基于 Netty 实现，具有‌高性能‌和‌低延迟‌的特点。
• 服务治理：内置服务注册与发现、负载均衡、容错机制等服务治理功能，支持与 Zookeeper、Nacos 等注册中心集成。Dubbo 3.x 引入了 Triple 协议，兼容 gRPC 生态，进一步增强了其扩展性。
• 适用场景：需要高性能、高并发的‌Java 微服务架构‌，尤其适合与 Spring 生态集成的项目

‌2.异步‌

(1) AMQP

• 协议基础：复杂的、功能丰富的应用层协议，支持多种消息模式，包括点对点和发布/订阅。
• 性能：相对复杂，需要更多的系统资源，不太适合资源受限的设备
• 可靠性：支持事务机制和确认机制，确保消息的可靠传递和处理。此外，AMQP 还支持消息持久化和高可用性配置。
• 安全性：内置安全机制，但可以通过 TLS/SSL 和 SASL 等手段增强安全性。
• 适用场景：更多用于企业级应用集成、金融交易、后台数据处理等需要高可靠性和事务支持的场景。

(2) MQTT（通过消息队列如RabbitMQ、Kafka）。

• 协议基础：一种轻量级的发布/订阅消息传输协议，专为低带宽、高延迟或不可靠网络环境下的设备通信而设计。
• 性能：协议结构简单，消息头较小，适合带宽有限或功耗敏感的设备。
• 可靠性：提供三种服务质量等级（QoS 0, 1, 2），以确保在不稳定的网络环境下也能可靠地传输消息。
• 安全性：支持 TLS/SSL 和 QUIC 等加密方式，并提供多种认证机制，如 LDAP、JWT、PSK 和 X.509 证书。
• 适用场景：广泛应用于物联网领域，如智能家居、工业自动化、车联网等，尤其适用于远程设备间的通信。