java中小型公司面试预习资料（四）：微服务架构

一、概念

板书： 微服务架构是一种将复杂软件系统拆分为多个小型、独立、模块化服务的架构风格，每个服务围绕特定业务功能构建，并通过明确定义的接口（如HTTP API、RPC或消息队列）进行通信。
个人： 随着业务越来越大，用户和请求量越来越多，传统的单体/分布式架构已经不足以支持当前互联网环境快速迭代、快速扩展新业务的需求。进而衍生出微服务架构。
原则： 单一职责（个人感觉太单一了也不好，视公司/业务情况而定），边界清晰。
优点：
1、灵活性与可扩展性：服务可独立升级、替换或扩展，避免单体架构中“牵一发而动全身”的问题。例如，单体架构的变更需整体部署，而微服务仅需修改特定模块。
2、技术异构性：不同服务可采用适合其业务场景的技术栈，促进创新。
3、弹性和容错：单个服务故障可通过熔断、降级等机制隔离，避免系统级崩溃。
4、敏捷开发：小团队聚焦单一服务，缩短开发周期，支持快速迭代。
缺点：
1、分布式系统复杂性：服务间通信可能引入网络延迟、一致性问题（如CAP定理）及调试困难。
指出微服务的错误率和延迟通常高于单体系统。
2、运维与监控难度：需统一日志收集（如ELK）、链路追踪（如Zipkin）和自动化监控工具应对多节点动态变化。
3、数据管理：分散的数据存储导致跨服务事务（如分布式事务）难以实现，常需最终一致性或Saga模式补偿。
适用：
1、系统规模：适合大型复杂应用，小型项目可能因运维成本过高而得不偿失。
2、团队结构：需跨职能团队支持DevOps文化，微服务需强搭配的团队协作。
3、业务需求：高频迭代、多技术栈需求或高伸缩性场景（如电商促销）更受益于微服务。
4、技术成熟度：需具备容器化、容器云（k8s）、服务网格（如Istio）等基础设施能力。

二、企业级微服务架构基础能力

SpringBoot：基础框架
SpringCloud：微服务一代目（netflix组件停止维护）
SpringCloudAlibaba：微服务二代目

1、Spring Cloud Alibaba 全家桶（第二代，阿里实现）

作为 Netflix 组件的替代与扩展，Spring Cloud Alibaba 整合了阿里生态的高性能组件：
服务注册与配置中心（Nacos）： 动态服务发现、配置管理一体化平台，替代 Eureka/Config 。
流量控制与熔断降级（Sentinel）： 支持流量控制、熔断、系统保护、热点规则等，替代 Hystrix。
服务网关（Spring Cloud Gateway）： 高性能 API 网关，替代 Zuul，支持动态路由和过滤器。
分布式事务（Seata）： 提供 AT、TCC 等分布式事务模式，解决数据一致性问题。
服务调用与通信（OpenFeign、Dubbo）： 增强的声明式 HTTP 客户端与可选 RPC 框架，支持高性能服务间调用。
链路追踪与监控（SkyWalking）： 全链路监控工具，替代 Sleuth+Zipkin，提供可视化界面。
安全认证（OAuth 2.0 + Spring Security）： 实现微服务安全认证与授权。

分布式缓存：Redis 。
分布式搜索：ElasticSearch 。
分库分表：Sharding-JDBC。
消息队列：RocketMQ。

二、CAP定理

CAP定理是分布式系统设计的核心理论，指出在一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）三者中，系统最多只能同时满足两项
一致性： 一致性（C）要求分布式系统中的所有节点在同一时刻看到完全相同的数据状态。例如，若用户向系统写入新数据，所有后续读操作必须能立即读到该更新后的值。这种强一致性是传统数据库事务的核心特性，但在分布式系统中面临网络分区的挑战。

1、CAP定理对一致性的限制：

三选二的必然性
当系统发生网络分区（如节点间通信中断）时，必须在一致性和可用性之间做出选择：
CP系统：优先保证一致性和分区容错性。例如ZooKeeper在选举Leader期间会拒绝写入请求，牺牲可用性以确保数据强一致。
AP系统：优先保证可用性和分区容错性。例如DNS系统在部分节点故障时仍可响应查询，但可能返回旧数据。

实际应用中的取舍

1. 金融交易系统通常选择CP模型（如HBase），因为数据一致性是核心需求。
2. 互联网服务（如微博）更倾向AP模型，通过最终一致性（如BASE理论）保证高可用。例如用户发表内容后，可能短暂出现部分用户看不到更新，但最终所有节点会同步。

2、延伸与实现策略

1. BASE理论对一致性的弱化
   BASE（Basically Available, Soft state, Eventually consistent）理论允许系统在正常运作时暂时不一致，但最终会达成一致。
   例如：电商库存扣减可能允许超卖，后续通过补偿事务修正。
   Kafka通过异步复制机制实现最终一致性，而非实时强一致。

2. 技术实现方案
   强一致性：采用两阶段提交（2PC）、Paxos/Raft共识算法等，但会引入较高延迟。
   最终一致性：通过版本向量（Version Vectors）、冲突自由数据类型（CRDTs）等解决数据冲突。

CAP中的一致性是分布式系统设计的核心权衡点。实际应用中需结合业务场景：
强一致性需求（如金融系统）：选择CP模型，通过共识算法保障，但需容忍可用性降低。
高可用需求（如社交平台）：选择AP模型，通过最终一致性+补偿机制实现数据收敛。
混合策略：如Redis Cluster在不同分片间采用异步复制（AP），但在单个分片内保持强一致（CP）。
设计者需明确业务对数据一致性的容忍度，并借助CAP/BASE理论选择合适的技术方案。

三、SOA架构

1、概念和原则

SOA（面向服务的架构）是一种以服务为核心的软件设计方法，通过模块化、松耦合和标准化接口实现复杂系统的灵活构建与集成。
模块化与独立性： SOA将系统拆分为独立的功能单元（服务），每个服务封装特定业务逻辑，可独立开发、部署和维护。
松耦合： 服务间通过明确定义的接口（如REST、SOAP ）通信，接口独立于底层技术栈（如编程语言、操作系统），增强系统的灵活性和可扩展性。
服务注册与发现： 通过服务注册中心（如nacos、eurakeESB、KMSD ）动态管理服务信息，支持服务的动态订阅、发布和调用。

2、关键组成与角色

服务（Service） ： 功能单元的核心，需具备自包含性、可重用性和无状态性。
服务提供者（Provider）： 负责服务的实现、部署和运维，需满足服务级别协议（SLA）。
服务消费者（Consumer）： 调用服务的实体，可以是其他服务、应用或用户。
服务注册中心（Registry）： 存储服务元数据（如功能、接口、位置），支持动态发现和调用。

3、SOA和微服务

SOA：
起源于1996年，旨在通过模块化服务整合异构系统，解决企业级应用中的信息孤岛问题。SOA强调服务重用和松耦合，通过标准化协议（如SOAP、WebService）和ESB（企业服务总线）连接服务，实现跨系统的通信与协作。其服务粒度较粗，通常对应完整的业务逻辑单元。
微服务：
作为SOA的演进和子集，微服务将应用拆分为细粒度、独立部署的小型服务，每个服务专注于单一业务功能（如用户服务、订单服务）。其核心是去中心化和轻量化，采用REST、gRPC等轻量协议通信，支持容器化部署和敏捷开发。

注： Saga是一种长事务的管理模式，通过一系列有序的本地事务和相应的补偿事务来保证最终一致性。

四、DDD领域

领域驱动设计（Domain-Driven Design，DDD）是一种以业务领域为核心的软件开发方法论，由Eric Evans于2004年在其著作中正式提出。其核心目标是通过构建精准的领域模型，解决复杂系统的设计问题，并确保业务逻辑与技术实现的一致性。

1、核心思想

业务驱动： DDD强调从业务需求出发，通过与领域专家合作提炼通用语言（Ubiquitous Language），形成团队共享的业务术语体系，避免技术术语与业务概念脱节。
模型与代码统一： 领域模型不仅是设计文档，还需直接映射到代码实现，确保模型变更能同步驱动代码演进，而非割裂为“文档模型”与“实现模型”。
分治复杂系统： 通过划分限界上下文（Bounded Context）和子域，将庞大系统拆解为高内聚、低耦合的模块，每个模块聚焦特定业务场景。

2、领域模型

抽象性与业务导向： 模型是对业务本质的抽象，仅包含与领域相关的核心概念，与技术实现无关。例如，银行系统中“账户”需建模其开户、转账等行为，而非存储细节。
逻辑集中： 业务规则封装在领域对象（如实体、值对象）中，避免分散在Service层导致“贫血模型”。例如，Customer类应包含信用评分计算逻辑，而非仅作为数据容器。
可演进性： 模型需适应业务变化，通过聚合根（Aggregate Root）管理领域对象生命周期，确保数据一致性。

3、设计相关

战略设计

1. 划分子域：识别核心域（业务差异化关键）、支撑域（辅助功能）和通用域（共性需求）。例如，电商系统中“订单处理”是核心域，“日志管理”为通用域。

2. 定义限界上下文：明确每个子域的边界及交互方式，避免概念混淆。如“用户”在会员系统中指账户信息，在物流系统中则关联配送地址。

3. 事件风暴（Event Storming） ：通过协作工作坊提炼领域事件、命令和聚合，形成初步模型。

战术设计

1. 构建领域对象：
   实体（Entity） ：具有唯一标识和生命周期的对象（如“订单”含订单号）。
   值对象（Value Object） ：通过属性定义且不可变的对象（如“金额”由数值和币种组成）。
   聚合根：作为访问入口，维护一组关联对象的一致性（如“购物车”聚合管理商品项和总价）。
2. 分层架构：通常分为用户界面层、应用层（协调业务流程）、领域层（核心业务逻辑）和基础设施层（技术实现）。

4、贫血模型和充血模型

贫血模型： 领域对象仅包含数据属性（getter/setter），所有业务逻辑集中在Service层实现。例如Employee类只有Id、Name等属性，而增删改查等操作由EmployeeService处理。
充血模型： 领域对象既包含数据，又封装与之相关的业务逻辑。例如Employee类不仅存储属性，还直接实现save()、adjustPosition()等方法。

严格遵循DDD时，贫血模型被认为是“反模式”，而充血模型能更好地表达领域概念。
两者的Service层差异显著：贫血模型的Service需要调用DAO操作数据库，而充血模型的Service仅协调领域对象。

大多数公司很难从设计到执行都应用充血模型，因为贫血模型更易于开发维护，逻辑清晰简单（比如MVC）。博主之前在微服务层设计时参考了DDD和充血模型，但是在具体微服务内部还是使用的MVC+贫血模型（但是会把复杂业务逻辑单独抽出service避免service过于臃肿）。

5、DDD+微服务

服务边界划分：限界上下文或者子域映射为微服务。
领域隔离（防腐）：通过领域层隔离业务逻辑，避免微服务退化为“小单体”。这个领域层不要生搬硬套~
事件驱动：领域事件可用于跨服务通信（消息中间件），实现松耦合。

DDD+微服务很适合用于敏捷开发，建议通过测试驱动开发（TDD）验证模型有效性。但是对有分布式强一致性的业务不友好，设计的时候需要深入业务场景按需定制~

没有最好的架构，只有最合适的架构。
脱离业务谈架构就是耍流氓。
架构都是根据业务和公司（boss）能提供的支持来定的。

上一篇：java中小型公司面试预习资料（三）：消息中间件