复杂度

副标题 / 摘要 服务拆得太细会导致网络放大、治理成本暴涨。本文给出判断微服务是否过度拆分的指标。 目标读者 进行服务拆分的工程师 负责架构演进的技术负责人 关注运维成本的团队 背景 / 动机 “拆得越细越好”是误区。 过度拆分会引入大量跨服务调用与一致性成本。 核心概念 边界上下文：服务应围绕业务边界 调用链长度：服务过细导致链路过长 治理成本：部署、监控、告警激增 实践指南 / 步骤 统计核心请求的跨服务调用数 观察跨团队依赖是否频繁变更 衡量运维成本（部署频率/告警量） 合并高耦合且同步频繁的服务 可运行示例 # 模拟调用链开销 import time def call_service(name): time.sleep(0.02) return name def chain(n): start = time.time() for i in range(n): call_service(f"s{i}") return time.time() - start if __name__ == "__main__": print(chain(2)) print(chain(6)) 解释与原理 每个服务调用都有网络延迟与失败概率。 拆分过细会放大延迟与故障率，同时提升治理成本。 常见问题与注意事项 微服务一定要小吗？ 不，小是相对业务边界而言。 怎么判断是否需要合并？ 同步调用频繁、边界不清晰时。 会不会影响自治？ 适度合并反而提升效率。 最佳实践与建议 以业务边界为拆分核心 评估调用链和故障放大效应 用数据驱动拆分与合并决策 小结 / 结论 微服务过度拆分会带来延迟、故障与治理成本。 合理边界比“越细越好”更重要。 ...

副标题 / 摘要 生成不重复随机序列的标准方法是洗牌。本文说明原理并提供可运行实现。 目标读者 学习随机算法的开发者 需要抽样与随机化的工程师 算法面试准备者 背景 / 动机 随机且不重复是很多场景的基础能力，例如抽奖、打乱顺序、采样。 洗牌算法能保证均匀分布且复杂度可控。 核心概念 均匀随机：所有排列等概率 洗牌（Fisher-Yates）：线性时间打乱 采样：在大规模集合中取子集 实践指南 / 步骤 初始化序列 从尾到头随机交换 保证每一步的随机性 输出最终序列 可运行示例 import random def shuffle(nums): for i in range(len(nums) - 1, 0, -1): j = random.randint(0, i) nums[i], nums[j] = nums[j], nums[i] return nums if __name__ == "__main__": nums = list(range(1, 11)) print(shuffle(nums)) 解释与原理 Fisher-Yates 在第 i 步随机选择 [0..i] 中的元素交换。 这样可保证所有排列等概率出现。 常见问题与注意事项 能否用 sort + random key？ 不建议，分布不一定均匀。 是否需要固定随机种子？ 测试时建议固定，生产可随机。 ...