架构

副标题 / 摘要 紧急设计强调“先做出来”，演化架构强调“持续演进”。本文对比两者并给出落地建议。 目标读者 负责架构演进的工程师 需要平衡交付与演进的团队 技术负责人和架构师 背景 / 动机 快速交付常会牺牲长期演进能力。 理解不同设计哲学有助于减少技术债务。 核心概念 紧急设计（Emergent Design）：先做出最小可用形态 演化架构（Evolutionary Architecture）：持续演进与可变性设计 架构适应度：衡量架构是否仍适用 实践指南 / 步骤 先保证可交付，再设演进边界 建立架构适应度指标 用自动化测试保护演进 定期清理技术债务 可运行示例 # 用配置切换策略，模拟架构演进 def strategy_v1(x: int) -> int: return x + 1 def strategy_v2(x: int) -> int: return x * 2 def compute(x: int, use_v2: bool) -> int: return strategy_v2(x) if use_v2 else strategy_v1(x) if __name__ == "__main__": print(compute(3, False)) print(compute(3, True)) 解释与原理 紧急设计解决“马上能用”，演化架构解决“持续适用”。 二者不是对立，而是阶段性的取舍。 常见问题与注意事项 紧急设计会导致技术债务吗？ 会，需要明确偿还计划。 演化架构会不会过度设计？ 会，因此要用实际指标约束。 ...

副标题 / 摘要 当底层系统不支持事务时，你仍然需要一致性保障。本文给出从应用层实现“类事务”的核心思路。 目标读者 需要保证数据一致性的后端工程师 构建存储系统或中间层的开发者 负责业务可靠性的技术负责人 背景 / 动机 没有事务意味着更新失败会留下不一致状态。 在关键业务中，必须通过应用层补偿或日志保证正确性。 核心概念 写前日志（WAL）：记录意图，支持回滚 锁/隔离：防止并发冲突 补偿事务：失败后反向修复 实践指南 / 步骤 为关键操作记录意图日志 设计回滚逻辑与补偿函数 用锁或版本号避免并发冲突 定期对账，检测异常状态 可运行示例 # 简化的“事务”示例：使用回滚日志 class Txn: def __init__(self, store): self.store = store self.log = [] def set(self, key, value): self.log.append((key, self.store.get(key), value)) def commit(self): for key, _, value in self.log: self.store[key] = value def rollback(self): for key, old, _ in reversed(self.log): if old is None: self.store.pop(key, None) else: self.store[key] = old if __name__ == "__main__": store = {"a": 1} tx = Txn(store) tx.set("a", 2) tx.set("b", 3) tx.rollback() print(store) 解释与原理 通过记录“修改前状态”，可以在失败后回滚。 这模拟了事务中的“原子性”，但要自己处理并发与持久化。 ...

副标题 / 摘要 紧耦合通常被视为反模式，但并非绝对。本文讨论在性能与一致性优先时，何时可以接受紧耦合。 目标读者 需要做架构取舍的工程师 关注性能与一致性的团队 软件架构师与技术负责人 背景 / 动机 为了抽象而抽象会带来复杂度和性能损耗。 在可控边界内，紧耦合反而能带来更高效率。 核心概念 紧耦合：组件依赖强，替换成本高 松耦合：抽象接口降低依赖 性能与一致性：常与抽象层数量冲突 实践指南 / 步骤 评估是否存在严格的延迟预算 确认模块生命周期是否一致 记录耦合原因与边界 设置后续解耦计划或替换点 可运行示例 # 直接调用减少抽象层，提高性能 def hash_id(user_id: int) -> int: return user_id * 31 % 1000 def route_request(user_id: int) -> int: # 紧耦合：直接依赖 hash 规则 return hash_id(user_id) if __name__ == "__main__": print(route_request(42)) 解释与原理 紧耦合减少了中间层与动态分发成本，能提升性能与确定性。 代价是灵活性降低，变更成本提高。 常见问题与注意事项 紧耦合会不会让系统难以演进？ 会，因此要明确边界与风险。 什么时候一定要解耦？ 当模块演进速度不一致时。 如何控制风险？ 通过测试覆盖与明确文档约束。 最佳实践与建议 对紧耦合区域建立“可替换计划” 在性能关键路径优先考虑直接调用 用版本策略降低变更风险 小结 / 结论 紧耦合不是“坏”，而是“有成本的选择”。 当性能与一致性优先时，它可以是正确决策。 参考与延伸阅读 Clean Architecture Software Architecture Tradeoffs 元信息 阅读时长：6~8 分钟 标签：架构取舍、耦合 SEO 关键词：紧耦合, 架构取舍 元描述：说明紧耦合的合理场景与风险。 行动号召（CTA） 标记你系统里最紧耦合的模块，写下“为何如此”的技术说明。

副标题 / 摘要 Cloud Ready 不等于用上容器。本文总结系统上云前必须具备的可伸缩性、可观测性与自动化特征。 目标读者 准备上云的工程团队 需要改造系统的架构师 负责运维与交付的技术负责人 背景 / 动机 传统系统常依赖本地状态与手工运维，上云后会暴露稳定性问题。 Cloud Ready 关注的是工程能力，而不是部署形式。 核心概念 无状态：实例可随时替换 配置外置：环境变量/配置中心 自动化运维：可脚本化部署与回滚 实践指南 / 步骤 把状态外置到数据库/缓存 用环境变量或配置中心管理配置 实现健康检查与就绪探针 建设日志、指标与追踪 可运行示例 import os def load_config(): return { "db_url": os.getenv("DB_URL", "sqlite:///local.db"), "env": os.getenv("APP_ENV", "dev"), } if __name__ == "__main__": print(load_config()) 解释与原理 云环境要求实例可随时被替换，因此必须无状态。 配置外置与自动化运维确保部署可重复、可回滚。 常见问题与注意事项 用了容器就算 Cloud Ready 吗？ 不算，关键在可替换性与可观测性。 有状态服务怎么处理？ 外置到托管服务或独立持久层。 观测性为什么重要？ 弹性扩缩容会增加排查难度。 最佳实践与建议 采用 12-Factor 思维整理配置 做自动化部署与回滚演练 建立清晰的 SLO 与告警 小结 / 结论 Cloud Ready 是工程能力升级，不是简单的“搬家”。 无状态、配置外置与可观测性是基础门槛。 ...

副标题 / 摘要 存储过程可以提高性能与一致性，但也会带来可维护性与迁移成本。本文给出工程取舍建议。 目标读者 设计数据库与业务逻辑的工程师 负责性能优化的团队 关注可维护性的架构师 背景 / 动机 业务逻辑放在数据库可减少网络往返，但也会锁死技术栈。 如何在效率与可维护性之间取舍是关键。 核心概念 存储过程：在数据库内部执行的逻辑 网络往返成本：应用与数据库的调用开销 版本控制与测试：数据库代码的工程化难点 实践指南 / 步骤 评估性能瓶颈是否在数据库侧 确定逻辑是否需要强一致性保障 为存储过程建立版本管理策略 设计回滚与兼容策略 可运行示例 -- PostgreSQL 存储过程示例 CREATE OR REPLACE FUNCTION transfer(from_id INT, to_id INT, amount INT) RETURNS VOID AS $$ BEGIN UPDATE accounts SET balance = balance - amount WHERE id = from_id; UPDATE accounts SET balance = balance + amount WHERE id = to_id; END; $$ LANGUAGE plpgsql; -- 调用 SELECT transfer(1, 2, 100); 解释与原理 把逻辑放进存储过程能减少网络往返，并利用数据库事务能力。 代价是测试难、跨库迁移成本高。 常见问题与注意事项 存储过程更快吗？ 通常是，但不一定显著。 业务逻辑能否完全放数据库？ 不建议，复杂逻辑会降低可维护性。 如何测试存储过程？ 需要专门的数据库测试环境与回滚脚本。 ...

副标题 / 摘要 请求/响应强调确定性与即时性，发布/订阅强调解耦与扩展。本文给出工程取舍与选型依据。 目标读者 设计系统通信方式的工程师 需要落地消息队列的团队 关注系统扩展性的架构师 背景 / 动机 不同业务对实时性、耦合度与可靠性要求不同。 选错通信模式会导致复杂度或性能问题。 核心概念 请求/响应：点对点、强同步 发布/订阅：多对多、异步解耦 背压与重试：决定系统稳定性 实践指南 / 步骤 确定是否必须实时同步返回结果 评估消费者数量与扩展需求 设计失败重试与死信队列 为消息定义幂等与去重策略 可运行示例 # 极简发布/订阅示例 subscribers = [] def subscribe(fn): subscribers.append(fn) def publish(event): for fn in subscribers: fn(event) if __name__ == "__main__": subscribe(lambda e: print("A got", e)) subscribe(lambda e: print("B got", e)) publish({"type": "order.created", "id": 1}) 解释与原理 请求/响应适合“需要立即结果”的业务流程。 发布/订阅适合“事件驱动、解耦扩展”的场景，但需要处理一致性与幂等。 常见问题与注意事项 发布/订阅会丢消息吗？ 可能，需配置持久化与重试机制。 请求/响应能扩展吗？ 可以，但耦合更高、弹性更差。 混用可以吗？ 可以，常见是“同步写 + 异步通知”。 ...

副标题 / 摘要 新建项目（Greenfield）与遗留系统（Brownfield）各有成本与风险。本文给出选择依据与工程化落地策略。 目标读者 需要决定“重写还是演进”的团队 负责技术决策的负责人 维护老系统的工程师 背景 / 动机 “重写 vs 演进”是长期争论的话题。 选择错误会导致成本爆炸或业务停滞。 核心概念 Greenfield：从零开始，无历史负担 Brownfield：已有系统上演进 迁移成本：数据、流程、人员 风险控制：业务连续性优先 实践指南 / 步骤 评估现有系统核心价值 量化重写成本与风险 考虑业务连续性 选择渐进式替换或并行系统 预留回滚通道 可运行示例 # 选择模型：成本与风险的简化比较 def choose(rewrite_cost, evolve_cost, risk): return "rewrite" if rewrite_cost + risk < evolve_cost else "evolve" if __name__ == "__main__": print(choose(100, 60, 50)) 解释与原理 Greenfield 的优势是“自由”，但风险是“未知”。 Brownfield 的优势是“稳定”，但成本是“历史债务”。 常见问题与注意事项 重写一定更快吗？ 不一定，往往低估了边界与隐性需求。 演进会不会永远修不完？ 如果没有清晰边界与目标，会陷入维护泥潭。 如何降低风险？ 用并行系统与灰度切换。 最佳实践与建议 核心业务优先演进 非核心模块可重写试点 设定里程碑与回滚点 小结 / 结论 Greenfield 和 Brownfield 的选择不是偏好问题，而是风险与成本的权衡。 理性评估比直觉更重要。 参考与延伸阅读 Working Effectively with Legacy Code Monolith to Microservices 元信息 阅读时长：7~9 分钟 标签：Greenfield、Brownfield、工程决策 SEO 关键词：Greenfield, Brownfield 元描述：对比新项目与遗留系统的选择策略。 行动号召（CTA） 列出系统中最该演进的模块，先从可拆分的部分开始。

副标题 / 摘要 好莱坞原则的核心是“框架调用业务代码”，而不是业务代码主动控制流程。本文解释其意义与使用方式。 目标读者 使用框架开发的工程师 设计扩展机制的开发者 关注解耦与控制反转的团队 背景 / 动机 传统流程由业务代码掌控，但当系统需要扩展与统一规范时，框架更适合主导流程。 好莱坞原则就是这种“控制反转”的表述。 核心概念 好莱坞原则：Don’t call us, we’ll call you 控制反转（IoC）：流程控制权交给框架 回调/钩子：框架在特定时机调用业务逻辑 实践指南 / 步骤 定义扩展点接口 框架控制主流程 业务只注册回调 通过配置加载插件 保持扩展点稳定 可运行示例 class App: def __init__(self): self.handlers = [] def on_event(self, handler): self.handlers.append(handler) def run(self, event): for h in self.handlers: h(event) def log_handler(evt): print("log:", evt) if __name__ == "__main__": app = App() app.on_event(log_handler) # 注册回调 app.run("start") # 框架调用回调 解释与原理 框架掌控主流程并决定何时调用业务逻辑，这样可以保证统一的生命周期、错误处理与资源管理。 业务只需实现扩展点，减少重复与耦合。 ...

副标题 / 摘要 Active Record 把数据与持久化绑定在一起，Data Mapper 把持久化隔离为独立层。本文对比二者并给出选型建议。 目标读者 使用 ORM 的后端工程师 设计领域模型的开发者 需要做架构取舍的团队 背景 / 动机 项目变复杂时，持久化模型往往开始“侵入”业务逻辑。 理解 Active Record 与 Data Mapper 的差异，是避免架构污染的关键。 核心概念 Active Record：对象自己保存/加载（数据与持久化耦合） Data Mapper：持久化逻辑在独立映射层 领域模型纯度：业务模型是否被 ORM 污染 实践指南 / 步骤 小型项目可用 Active Record 复杂领域建议 Data Mapper 明确领域边界，避免 ORM 侵入 用 Repository 隔离持久化 测试业务逻辑时替换存储层 可运行示例 # Active Record 风格 class UserAR: def __init__(self, name): self.name = name def save(self): print("save", self.name) # Data Mapper 风格 class User: def __init__(self, name): self.name = name class UserMapper: def save(self, user: User): print("save", user.name) if __name__ == "__main__": UserAR("Alice").save() UserMapper().save(User("Bob")) 解释与原理 Active Record 简单直观，但把持久化耦合进领域模型。 Data Mapper 更复杂，但让业务逻辑更纯粹、更易测试。 ...

副标题 / 摘要 设计关心方案与体验，架构关心结构与演进，功能关心“能做什么”，美学关心“好不好看、好不好用”。本文给出清晰区分与落地方法。 目标读者 负责产品与工程协作的开发者 需要做系统设计的工程师 希望减少沟通成本的团队负责人 背景 / 动机 很多团队在沟通时把“功能、设计、架构、美学”混在一起，导致讨论失焦。 明确它们的职责边界，是跨职能协作的前提。 核心概念 功能（Functionality）：系统能做什么，输出什么结果 设计（Design）：满足需求的方案与交互流程 架构（Architecture）：系统结构、组件边界与可演进性 美学（Aesthetic）：视觉与体验层面的感知质量 实践指南 / 步骤 先定义功能边界：输入/输出与业务规则 再做设计方案：交互流程与用户路径 确定架构结构：模块划分、接口与扩展方式 补齐美学细节：视觉层级与一致性 建立协作节奏：设计评审与架构评审分开 可运行示例 下面用一个简单例子展示“功能 vs 美学”的分离： def calc_total(items): return sum(price for _, price in items) def render_receipt(total, theme="minimal"): if theme == "minimal": return f"Total: {total}" return f"*** TOTAL ***\n{total}\n***********" if __name__ == "__main__": items = [("apple", 3), ("milk", 5)] total = calc_total(items) # 功能 print(render_receipt(total, theme="minimal")) # 美学 解释与原理 功能是“正确性”，设计是“可用性”，架构是“可演进性”，美学是“感知质量”。 把它们混在一起会造成目标冲突、决策混乱。 常见问题与注意事项 美学是不是不重要？ 不是，它影响使用意愿与信任感。 架构是不是过度设计？ 不是，架构关注长期演进与成本控制。 ...