软件体系结构（Software Architecture）

软件体系结构（Software Architecture）是系统的高层设计蓝图，定义了组件、组件间交互方式、系统约束及设计原则，以确保满足功能和非功能需求（如性能、可维护性、可扩展性）。其核心包括组件（功能模块）、连接器（通信机制）、约束（设计规则）和配置（结构布局）。

---

1. 分层架构（Layered Architecture）

核心逻辑

将系统按职责垂直切割为多个层级，每层只能调用下一层的服务，不能跨层调用。就像一栋大楼的楼层分工：

• 表现层（Presentation Layer）：用户直接交互的界面（如网页、APP界面）。
• 业务逻辑层（Business Layer）：处理核心业务规则（如计算订单价格、验证用户权限）。
• 数据访问层（Data Layer）：与数据库、文件系统交互（如读取用户信息）。

代码示例（伪代码）

# 表现层：接收HTTP请求
@app.route("/order", methods=["POST"])
def create_order():user_id = request.form["user_id"]items = request.form["items"]# 调用业务逻辑层order = OrderService.create_order(user_id, items)return render_template("order.html", order=order)# 业务逻辑层
class OrderService:@staticmethoddef create_order(user_id, items):user = UserRepository.get_user(user_id)  # 调用数据层if user.credit < 100:raise Exception("信用分不足")# 计算订单逻辑...return order# 数据访问层
class UserRepository:@staticmethoddef get_user(user_id):# 连接数据库查询用户return db.query("SELECT * FROM users WHERE id = ?", user_id)

典型场景

• 传统Web应用：如使用Spring MVC的Java应用、Django/Python应用。
• 桌面软件：如Photoshop（UI层、图像处理层、文件IO层）。

优缺点

• 优点：代码结构清晰，易于分工和维护。
• 缺点：层级过多时性能下降（如一个请求穿透所有层）。

---

2. 客户端-服务器（Client-Server）

核心逻辑

客户端（如浏览器、手机APP）负责展示界面和用户交互，服务器（如后端API）负责处理业务和数据存储。两者通过网络协议（如HTTP）通信。

典型交互流程

1. 用户在客户端点击“登录”按钮。
2. 客户端发送HTTP请求到服务器：POST /login {username: "alice", password: "123"}。
3. 服务器验证账号密码，返回结果：{status: "success", token: "xyz"}。
4. 客户端根据响应跳转到主页。

应用场景

• Web应用：Gmail、淘宝网。
• 移动应用：微信（APP是客户端，腾讯服务器提供消息服务）。

代码示例（RESTful API）

// 服务器端（Node.js + Express）
app.post('/login', (req, res) => {const { username, password } = req.body;const user = db.findUser(username);if (user.password === password) {res.json({ token: generateToken(user) });} else {res.status(401).json({ error: "密码错误" });}
});// 客户端（浏览器JavaScript）
fetch("/login", {method: "POST",body: JSON.stringify({ username: "alice", password: "123" })
})
.then(response => response.json())
.then(data => localStorage.setItem("token", data.token));

优缺点

• 优点：职责分离，服务器可集中管理数据和安全。
• 缺点：服务器单点故障可能导致整个系统瘫痪。

---

3. 微服务架构（Microservices）

核心逻辑

将大型应用拆分为多个独立的小型服务，每个服务专注单一业务功能（如用户服务、订单服务），可独立开发、部署、扩展。

典型架构图

用户请求 → API网关 → 路由到对应微服务（用户服务、商品服务、支付服务...）

• 每个服务有自己的数据库（避免直接共享数据）。
• 服务间通过HTTP/RPC或消息队列（如Kafka）通信。

场景案例：电商系统

• 用户服务：注册、登录、权限管理。
• 商品服务：商品信息管理、库存更新。
• 订单服务：下单、支付状态跟踪。
• 推荐服务：根据用户行为推荐商品。

代码示例（服务间调用）

// 订单服务调用支付服务（通过HTTP）
@PostMapping("/order/pay")
public String payOrder(@RequestBody Order order) {// 调用支付服务的APIPaymentResult result = restTemplate.postForObject("http://payment-service/api/pay", order.getPaymentDetails(), PaymentResult.class);if (result.isSuccess()) {updateOrderStatus(order.getId(), "PAID");}return result.getMessage();
}

优缺点

• 优点：灵活扩展（如促销时单独扩容商品服务），技术栈可多样化（不同服务用不同语言）。
• 缺点：运维复杂（需监控多个服务），网络通信可能成为性能瓶颈。

---

4. 事件驱动架构（Event-Driven）

核心逻辑

组件之间通过发布/订阅事件异步通信，而不是直接调用对方接口。事件发生时，监听该事件的组件自动响应。

典型流程

1. 用户下单 → 订单服务发布事件OrderCreated。
2. 库存服务监听此事件 → 扣减库存。
3. 通知服务监听同一事件 → 发送短信提醒用户。

技术实现

• 消息中间件：Kafka、RabbitMQ。
• 事件总线：Redis的Pub/Sub功能。

代码示例（伪代码）

# 订单服务发布事件
def create_order(order_data):save_order(order_data)event_bus.publish("OrderCreated", order_data)# 库存服务订阅事件
@event_bus.subscribe("OrderCreated")
def reduce_stock(event):for item in event.items:Stock.decrement(item.id, item.quantity)# 通知服务订阅事件
@event_bus.subscribe("OrderCreated")
def send_notification(event):user = User.get(event.user_id)sms.send(user.phone, "您的订单已创建！")

应用场景

• 实时系统：股票交易平台（价格变动触发交易）。
• 物联网（IoT）：传感器数据触发报警。

优缺点

• 优点：高解耦，组件可独立扩展。
• 缺点：事件流复杂时调试困难，需保证事件顺序和可靠性。

---

5. 管道-过滤器架构（Pipe-Filter）

核心逻辑

将数据处理过程分解为多个过滤器（Filter），数据像水流一样依次通过各个过滤器处理，每个过滤器只做单一任务。

典型流程（图像处理）

原始图片 → 去噪过滤器 → 锐化过滤器 → 压缩过滤器 → 输出图片

代码示例（日志处理管道）

// 定义过滤器接口
interface LogFilter {String process(String log);
}// 具体过滤器：脱敏
class SensitiveFilter implements LogFilter {public String process(String log) {return log.replaceAll("password=.*", "password=*");}
}// 具体过滤器：时间格式化
class TimestampFilter implements LogFilter {public String process(String log) {return log.replace("${timestamp}", LocalDateTime.now().toString());}
}// 管道组装
List<LogFilter> pipeline = Arrays.asList(new SensitiveFilter(), new TimestampFilter());
String processedLog = pipeline.stream().reduce(rawLog, (log, filter) -> filter.process(log));

应用场景

• 编译器：词法分析 → 语法分析 → 代码生成。
• ETL工具：数据抽取 → 转换 → 加载。

优缺点

• 优点：灵活组合处理流程，易于测试单个过滤器。
• 缺点：不适合需要复杂状态管理的场景。

---

对比总结

架构类型	适用场景	核心优势	潜在问题
分层架构	传统企业应用（如ERP）	结构清晰，易于维护	层级过多时性能差
微服务	大型分布式系统（如电商平台）	独立扩展，容错性强	运维复杂，网络延迟
事件驱动	实时数据处理（如聊天室、IoT）	高解耦，异步处理	事件顺序和可靠性管理难
管道-过滤器	数据流水线处理（如编译器、ETL）	灵活组合处理步骤	不适合复杂状态管理