一、企业级架构的演进历程
企业级软件系统随着业务规模和技术发展，经历了多次架构演变，大致可分为以下几个阶段：
单体架构
所有功能模块（用户、订单、商品、支付等）都写在同一个项目中，打包成一个应用部署。优点：开发简单，部署方便，初期成本低。
缺点：代码越来越臃肿，修改一处可能需要重新部署整个系统；某个模块出问题可能影响全部功能；团队协作困难。
SOA架构（面向服务架构）
将系统拆分为多个服务，通过企业服务总线（ESB）进行集成和通信。比单体更灵活，但ESB往往成为性能瓶颈，且服务间耦合度仍然较高。
微服务架构（MSA）
将系统进一步拆分为更小、更独立的服务，每个服务拥有独立的数据库和部署流程，服务间通过轻量级的HTTP API（如RESTful）通信。优点：各服务可由不同团队独立开发、部署、扩展，技术栈也可灵活选择（Java、Go、Python等）。
这也是目前最主流的企业级架构风格。
云原生架构
在微服务基础上，充分利用容器、Kubernetes、自动伸缩等云平台能力，使系统更具弹性和可观测性。AI原生架构
当前前沿方向，将AI能力（如大模型）深度融入系统设计。
一个典型的微服务系统通常包含设备端、移动端、浏览器等客户端，通过API网关访问后端的用户服务、订单服务、产品服务等，每个服务拥有独立的数据库。
二、分布式系统的基本概念
微服务架构本质上是分布式系统的一种，但分布式系统并不等同于微服务。
什么是分布式系统？
分布式系统是指一组通过网络通信和协调的计算机组件，对外表现如同一个完整的系统。例如，用户访问一个网站，后台可能有多台服务器协同处理请求。
分布式系统的两种常见形式：
微服务架构：各个服务的代码和职责不同，相互配合完成业务。
集群：多台服务器运行相同的代码，目的是提升处理能力和可用性（例如三台服务器都部署同一个订单服务，分担访问压力）。
因此，微服务是分布式的，但分布式系统还包括集群等形态。
三、分布式系统的核心理论
1. CAP定理
CAP定理指出，分布式系统在一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三者中，最多只能同时满足两个。
C（一致性）：所有节点在同一时刻看到的数据完全相同。
A（可用性）：系统始终能够对请求返回结果（不超时、不报错）。
P（分区容错性）：当网络出现故障，部分节点之间无法通信时，系统仍能继续工作。
由于网络故障无法避免，P是必须选择的，因此我们通常在C和A之间做权衡。例如，金融系统更看重一致性，而电商大促时可能更看重可用性。
2. BASE理论
BASE理论是对CAP的补充，更适合大规模互联网系统：
BA（基本可用）：允许系统出现短暂故障，但核心功能仍可正常使用（比如下单稍慢，但最终能完成）。
S（软状态）：允许数据存在中间状态（例如支付成功后，积分暂时未增加）。
E（最终一致性）：经过一段时间，数据最终会达成一致状态。
BASE理论让我们不必时刻追求强一致性，从而提升系统的并发能力和可用性。
四、Spring Cloud 简介
Spring Cloud 是一套用于快速构建分布式系统的工具集，涵盖了微服务架构中常见的模式，例如：
配置管理（集中管理配置文件）
服务发现（服务之间能够自动发现彼此）
断路器（防止某个服务故障拖垮整个系统）
智能路由、API网关、分布式追踪等
Spring Cloud 是一个伞形项目，包含多个子项目和组件，主要分为几大体系：
Spring Cloud Netflix（第一代微服务组件，如Eureka、Ribbon）
Spring Cloud Alibaba（国内常用的组件集，如Nacos、Sentinel）
Spring Cloud 官方组件（如Gateway、LoadBalancer、OpenFeign）
在具体技术选型时，常见组合如下：
| 功能 | 常用组件 |
|---|---|
| 配置管理 | Nacos |
| 服务发现 | Nacos |
| 负载均衡 | Spring Cloud LoadBalancer |
| 服务调用 | OpenFeign |
| 分布式事务 | Seata |
| 服务容错（熔断降级） | Sentinel |
| 分布式追踪 | Zipkin |
| 服务网关 | Spring Cloud Gateway |
这些组件共同构成了完整的微服务基础设施，开发者可以按需集成。
五、微服务分层与调用规则
在实际项目中，服务通常划分为两个层次：
聚合服务层（BFF，Backend For Frontend）：面向不同客户端（主站、移动端、小程序、运营后台），负责聚合原子服务的数据，定制成前端需要的形式。它更靠近用户，业务针对性强。
原子服务层：按业务领域划分，如用户服务、订单服务、商品服务、优惠券服务。这些服务专注于各自的业务逻辑，不直接面向用户，保持独立和纯粹。
服务之间的调用需遵循以下规则：
上层可以调用下层，下层不能直接调用上层（若下层需要通知上层，可通过消息队列解耦）。
同一层级内的服务可以互相调用。
上层的任意服务可以调用下层的任意服务。
每个服务拥有自己独立的数据库，确保数据层面的解耦。
六、实际互联网平台示例
一个大型互联网平台通常包含众多业务模块，例如：
会员管理（实体卡、电子卡、积分、手机号）
商品管理（商品信息、库存）
活动管理（优惠券、活动信息）
门店管理（门店信息、权限、员工、货架）
订单管理（线上订单、门店订单）
这些模块通过微服务架构组织起来，既能独立演进，又能协同工作，支撑起复杂的业务场景。
以上内容梳理了企业级架构的演进、分布式系统的基本概念和理论，以及Spring Cloud在微服务中的角色和服务分层思路。对于刚接触微服务的初学者来说，理解这些基础概念是后续学习和实践的重要前提。随着后续深入，我们会逐步掌握各组件的具体用法和最佳实践。希望这篇文章能帮助到同样在路上的小伙伴们。
