每日阅读

Databricks

#

问题背景

#

Feature Flag（特性开关）在现代开发中无处不在，用于灰度发布、A/B测试或紧急降级。但在Databricks的规模下，传统的“查数据库”或“调用远程API”获取开关状态的方法成为了致命的瓶颈：

1. 延迟惊人：如果每次代码里写if (feature.isOn)都要发起网络请求，系统会很慢。
2. 单点故障(SPOF)：如果存储开关配置的数据库挂了，整个Databricks所有的服务可能都无法启动或运行。

架构

#

文章介绍了他们架构的演进：

1. 传统的服务端计算 (Server-Side Evaluation) - 被弃用
   • 模式：App 发请求给 FF 服务 -> FF 服务查 DB 计算结果 -> 返回 True/False。
   • 缺点：FF 服务成为了核心依赖路径（Critical Path）。FF 服务一挂，全站瘫痪。
2. 客户端本地计算 (Client-Side / SDK Evaluation) - 最终方案
   • 模式：
     • 控制面 (Control Plane)：管理员在后台修改配置。
     • 分发层：配置被打包成JSON/Protobuf，推送到S3或CDN。
     • 数据面 (Data Plane)：应用程序内部集成了SDK，SDK会异步拉取最新的配置规则，并缓存在本地内存中。
     • 计算：当代码执行isOn()时，直接在本地内存计算，耗时接近0ms，且不依赖网络。
   • 优势：即使配置服务完全炸了，应用程序依然可以用最后一次成功拉取的本地缓存继续运行，实现了极高的可用性。

性能优化

#

除此之外，他们针对SDK做了一些优化：

1. 静态维度预计算(Static Dimension Pre-evaluation)
   • 问题：Flag的判断条件是一棵复杂的布尔逻辑树（Boolean Expression Tree），如果每次请求都完整遍历这棵树就太慢了。
   • 优化：Flag的判断条件被分为静态维度（云厂商、Region、环境，这些在进程启动后就不变了）和运行时维度（WorkspaceID, UserID）。当 SDK 收到配置包时，它会立即把所有的静态条件算一遍。这样原本复杂的逻辑树就被剪枝成了一棵非常简单的树，运行时只需要判断剩下的动态维度。
2. 配置的二进制压缩：他们没有直接分发庞大的JSON文本，而是把复杂的Jsonnet DSL编译成了紧凑的Protobuf二进制流，并且把逻辑转换为了布尔表达式树的数据结构传输给SDK。这大大减少了网络带宽和SDK的内存占用。

Anthropic Engineering

#

这篇博客挺有意思，我将在AI辅助下尝试这个问题。

字节跳动技术团队

#

概述

#

Skills这个概念最早由Anthropic提出，如今已成为大多数Agent开发工具和IDE都支持的一种标准扩展规范。一个Skills通常包含三样东西：一份说明书SKILL.md、一堆操作脚本Scripts、一些参考资料References。

原理介绍

#

Skill1运行在一个沙盒环境里，这个环境允许大模型访问文件系统和执行bash命令，它接受需求，然后返回结果，Agent继续利用结果来解决问题。

Skills的加载机制分为三层：