系统架构

1. 单体架构 (Monolithic Architecture)

将应用程序的所有功能（用户界面、业务逻辑、数据访问等）都打包在一个单一的、紧耦合的单元中进行开发和部署。

优势 (Pros)	劣势 (Cons)
部署简单：只有一个部署包（JAR/WAR），发布操作简单。	技术锁定：整个系统必须使用同一套技术栈与开发语言。
开发简单：小型项目开发速度快，易于调试，代码跳转直观。	扩展性差：无法独立扩展某个高负荷模块，只能整体扩容，成本高。
易于测试：容易进行统一的端到端系统测试。	维护困难：代码库庞大，新成员学习成本高，小改动需重新编译部署。
性能较高：模块间通信属于进程内调用，无网络开销。	容错性差：任一模块故障（如内存泄漏）都可能导致整个应用崩溃。

将单个应用程序拆分成一组小型、独立的服务，每个服务都运行在自己的进程中，专注于特定的业务功能。服务之间通过轻量级的通信机制（如 HTTP/REST、gRPC 或消息队列）相互协作。

优势 (Pros)	劣势 (Cons)
技术多样性：每个服务可选用最适合自身业务的技术栈和数据库。	运维复杂性高：涉及服务发现、负载均衡、容错、分布式追踪与日志收集等。
独立部署/扩展：服务可独立开发、部署和弹性扩展，提高敏捷性。	测试困难：跨服务协作使得端到端测试与集成测试更加繁琐。
系统健壮性高：单个服务故障不易导致整体崩溃，隔离性好。	分布式事务难题：难以保证跨多个微服务的数据强一致性。
更好的模块化：业务边界清晰，代码库小，降低单体服务的理解难度。	网络延迟开销：服务间通过网络通信，存在网络延迟与序列化损耗。

分布式架构是一个广义概念（微服务也属于其子集），其本质是将系统中的不同组件部署到多台物理或虚拟机器上，通过网络协同工作，以实现高并发、高可用和横向扩展。

优势 (Pros)	劣势 (Cons)
资源利用率高：通过集群化部署充分利用多节点计算资源。	通信协议复杂：需要妥善解决网络通信、RPC 调用及序列化问题。
高可用性：配合负载均衡和故障转移机制，单点失效不影响系统运行。	一致性挑战：数据分散在不同节点，需采用分布式事务或最终一致性协议。
弹性扩展：通过增加服务器即可实现水平扩容，提升处理上限。	运维难度大：引入了消息队列、分布式缓存、注册中心等大量中间件。

系统各组件之间通过 事件 (Event) 进行异步通信。当某个组件发生状态改变时，发布一个事件到消息总线/消息队列（如 Kafka、RabbitMQ），其他感兴趣的订阅者接收并异步处理。

优势 (Pros)	劣势 (Cons)
极致解耦：事件生产者与消费者解耦，互不感知对方。	调试和追踪困难：业务流为非线性异步执行，难以追踪端到端链路状态。
高扩展性：支持动态增加或移除订阅者来扩展系统功能。	对中间件依赖重：对消息总线（MQ）的性能、吞吐量和可靠性要求极高。
实时响应：能实时响应外界发生的各类事件，延迟低。	幂等性问题：需解决消息重复消费带来的幂等性设计挑战。

最经典的水平切分架构模式，通常包含以下三层或四层：

优势 (Pros)	劣势 (Cons)
结构清晰：职责边界分离明确，降低系统复杂度。	扩展性有限：数据流必经各层，业务或数据层易成为单点性能瓶颈。
便于维护：某一层内部修改理论上不影响其他层，易于隔离。	部署不够灵活：各层通常打包在一起部署，属于单一物理部署单元。
容易测试：各层之间可通过 Mock 依赖进行独立的单元测试。	容易产生跳层调用：实践中开发者常为了方便绕过业务层直接调数据层。