为什么需要安全沙箱 ​

平台型产品，总是会遇到各种各样的高级需求、定制需求，通用设计很难满足所有场景。

因此，平台型产品的归宿，一定是平台通用功能 + 用户自定义逻辑的方式来Scale out。

用户在平台上的自定义逻辑，简单需求可以用DSL、Expression Language解决，比如Google CEL、AviatorScript等等。

复杂到无法用DSL或Expression Language描述时，就需要上通用编程语言代码了。

这时，必然需要一个Runtime，来承载和运行用户的非可信代码。

有哪些Runtime方案，它们安全吗？ ​

业界有4类常见的运行自定义逻辑的方案：

• Script Engine路线：Java Rhino、GraalVM.js等等
• MicroVM路线：AWS Lambda这类Serverless Runtime
• 容器路线：让用户代码运行在自定义的K8S Pod中
• Custom Sandbox路线：基于Goja、QuickJS等Runtime二次封装

除了第一种路线从设计上不是Secure by default，其他三类都是Secure by default。

但实际上是否真的安全，是一个复杂的问题。比如Script Engine从Runtime Security的角度不安全，但如果在使用这个功能的人上做限制，也能通过纵深防御(Defend in-depth)避免安全问题。

为什么第一条路线ScriptEngine不安全？ ​

我们对“执行非可信代码”建立威胁模型，除了业务层的Sproofing, Tampering, Information Disclosure的威胁，Runtime自身的关键风险可以归为两方面问题： DoS - 本质上是资源滥用 越权和逃逸 - 本质上是让非可信代码，拿到了宿主上的非预期的函数指针

和宿主共享同一个Runtime的Scripted Engine，DoS攻击是几乎没法防范的，写个while true轻松搞死宿主。

第二类逃逸越权威胁，在没有share nothing的设计下，也几乎无法防范，我们举3个语言的例子：

• Java JSR-223 ScriptEngine
• Node.js VM
• Python eval

Java - Rhino ScriptEngine 逃逸案例 ​

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import java.io.BufferedReader;
import java.io.InputStreamReader;

public class Main {
    public static void main(String[] args) throws Exception {
        String dynamicCode = "new java.lang.ProcessBuilder[\"(java.lang.String[])\"]([\"env\"]).start()";
        ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
        ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension(args[0]);
        if (scriptEngine == null) {
            System.out.printf(String.format("no script engine of %s found", args[0]));
        }

        Process process = (Process) scriptEngine.eval(dynamicCode);
        process.waitFor();
        BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
        StringBuilder output = new StringBuilder();
        String line;

        while ((line = reader.readLine()) != null) {
            output.append(line).append(System.lineSeparator());
        }
        System.out.println(output);
    }
}

新版本的rhino引入了ClassShutter限制script的Context中对java class的访问，通过ClassShutter能解决吗？

还是不行，对Hacker来说只是多走一步路的问题，任何对象调一下 getClass() 拿到reflection包就全部沦陷了。

因此，一个稍微安全一些的ScriptEngine，至少要禁掉所有可能导致反射和拿到constructor的代码路径

有一篇文章详细讲了怎么在Rhino上构建安全沙箱，但在不安全的基础上再缝缝补补，也存在很大的隐患。

因此，这些直接在宿主上跑的非隔离型ScriptEngine都有这个问题，JSR 223规范下这些常见的包都不能暴露给用户用：

• org.graalvm.js:js
• org.graalvm.js:js-scriptengine
• org.python:jython-standalone
• org.codehaus.groovy:groovy-jsr223
• org.codehaus.groovy:groovy-json

另外，SpringEL也不是Secure by default，默认能访问的类和方法太多了，需要额外配置才能禁用访问。

Node.js vm.runInNewContext 逃逸示例 ​

const vm = require("vm")
vm.runInNewContext("this.constructor.constructor('return process')().exit()");
vm.runInNewContext("this.constructor.constructor('return require')()('fs')");

Python eval 逃逸示例 ​

eval("__builtins__.__dict__['__import__']('os').environ")

MicroVM路线真的安全吗？ ​

AWS Lambda和Fargate背后的runtime，都是一个Rust写的MicroVM - Firecraker，Firecraker这个项目的技术水平非常高，把创建虚拟机的时间直接干到了Container同一个水平，我们可以简单理解成：

Lambda的安全性 = 虚拟机的安全性 = 给用户创建一台EC2的安全性。

可见，AWS Lambda是一个“既要又要”的产物，既要给用户最大的自定义程度，又要追求极致的安全性。

如果不深入思考，很容易陷入AWS Lambda安全又弹性的营销陷阱。

理性思考一下我们的应用场景 -- “给我们的客户运行代码”：

• 除了发一台物理服务器给客户，VM Level的沙箱已经是最底层的沙箱了
• 最底层的OS沙箱，相当于给了一个完整的Linux内核，暴露了最多的系统调用
• 最多的系统调用意味着：如果不加一层应用层沙箱，用户代码可以做任何事情
• 用户能做任何事情，要么意味着拿你的Lambda资源挖挖矿，造成DoS或者巨额Bills；要么意味着顺藤摸瓜SSRF搞你的服务

用Lambda执行用户代码，一般ScriptEngine这类高层Runtime没法调用的底层CPU指令，在Lambda中用户却可以任意构造，也就是说，所有的VM逃逸漏洞或幽灵漏洞一旦有EXP，暴露在外面的Lambda，就是黑客免费的试验场。

Lambda跑的结果，总归要和内部服务交互的，一旦有Lambda的网络和AWS权限(VPC Subnet / AWS IAM) 出问题，或者通信机制有问题，黑客可以摸到整个产线。

这个风险在DataDog的Serverless研究报告中也有描述：65%的组织把Lambda使用了其他服务同一个VPC而不是没有任何网络权限的隔离VPC。

你说不对啊，我们只要在信任边界上把把关，确保让AWS Lambda可以让Execution IAM Role权限最小化，可以让Lambda运行在独立的VPC设置独立的Security Group啊？

且不说我们公司目前IAM Role和VPC/SecurityGroup管理是多么的手动，即使全部能自动化，灵活性和管控粒度也太粗了，总不可能给每个Function搞一套Security Group吧。

至此，可以得出结论：Lambda对于AWS自己是安全的，如果要基于Lambda再来构建第二层非可信代码执行沙箱，攻击面大，控制粒度粗，并不安全。

除非，再做一个资源限额和计费/限流层防DoS + 再做一层应用层Runtime隔离危险操作。

既然MicroVM路线不结合其他方案，不能保障运行用户代码的安全性，那容器路线更不可能满足安全需求了，相比于VM，容器多出了一个共享OS内核可能导致宿主机级联失败(Cascade Failure)的风险，还要再多做一些租户分级和风险识别的事情，结合应用层沙箱和使用限额，才有可能安全的执行用户自定义代码。

那么，只剩下Custom Sandbox路线了 ​

开源社区找不到完整的非可信代码执行平台。AWS只开源了Firecraker运行时，Serverless公司大多只开源了SDK和Runtime。

比较可行的方案是：用现存成熟的Runtime，减去所有OS Level API，加上业务能力层API，再把威胁模型的其他风险处理好。

我们再结合”托管和执行外部用户非可信代码“的威胁模型，可以得出理想方案的两个基本要求：

1. 在沙盒中只提供充分且必要的能力层，避免能力溢出，导致用户脱离预期的用例，导致DoS风险
2. 宿主与沙盒之间必须是两种不同的Runtime, share nothing。必须要定义通信协议而非直接函数调用，才能从根本上解决 宿主运行时的高权限函数指针 暴露给用户的风险，通俗的说，就是要避免宿主被夺舍。

带着这个需求不难发现，Secure CodeSandbox这枚硬币的反面，就是Serverless Runtime，都是用来执行用户的非可信代码。

因此，我们只要寻找最适合集成和扩展的Serverless Runtime即可满足构建平台型产品扩展点的需求。

市面上有大量Serverless Runtime项目，可以使用或借鉴，具体分析请看下篇。

有哪些Serverless Runtime可以用？ ​

Serverless已经发展多年了，我们可以从宿主提供的API这个维度，给所有Runtime分个类，鸟瞰Serverless Runtime生态。

第一类是操作系统沙箱

基于MicroVM或Container，提供底层OS-level API，隔离粒度是OS内核级别或进程级别。

第二类是WebAssembly沙箱

基于WASM Runtime封装，提供WASI/WASIX系统调用或应用开发API，隔离粒度在进程线程级别。

第三类是基于V8解释器的应用层沙箱

基于一些动态类型编程语言的Runtime封装，提供可以直接写业务的API，隔离粒度比线程级别还细。主流方案几乎都是基于V8 Engine的Isolate实现的。

随着宿主运行时 封装层次提高和隔离粒度细化，相比于Serverful的VM/BareMetal，这几类Serverless方案在多租户并发情况下，都产生了效率质变。

注：这里讨论的几种Serverless Runtime的技术方向，都属于Serverless中的FaaS - Function as a Service子领域。

广义的Serverless定义还包括BaaS -- Backend as a service。而BaaS一般是用来快速搭建后台或者全栈应用，和低代码平台关联更密切，比如Back4App, Firebase, Supabase。

我们的场景是”给SaaS平台增加自定义逻辑的扩展点“，需求就是FaaS，而不是BaaS，BaaS类Serverless不在讨论范围。

操作系统级别的沙箱 ​

传统VM冷启动时间过长，无法满足Serverless的弹性要求，业界一般用MicroVM或Container来实现Serverless runtime

• MicroVM，每个实例有独立OS内核
• Containers，同机器的实例间共享OS内核

MicroVM方向的典型代表，是应用最广泛的AWS Lambda。再加上几大云厂商各自的Serverless产品，垄断了这条路线的大部分市场。

开源方案中，大多是基于Container实现的，比如Knative和Kubeless，但在Serverless大市场来看，是小众方案。这两个方案也可以结合起来用，KataContainer就是以容器做编排，底层CRI换成MicroVM实现。

这类方案中规中矩，但基于现有的虚拟化和容器化技术，这条路不可能把多租户调度细到线程以下。也就是说，即使Firecraker这类MicroVM把Guest OS做到了用户态，多租户的用户代码调度产生的上下文切换，还是在内核态。

这类方案用在公司内部租户较少风险可控的场景挺不错，但显然不是作为”SaaS系统的客户自定义扩展点“这个场景的最优解：

• 做不到用户态调度，资源利用率提不上去；
• 如果不组合使用后面两类Runtime，分发的制品是OS或容器镜像，冷启动效率提不上去；
• OS-level API能力溢出，暴露给外部用户，攻击面不好控制。

在有根本性缺陷的路上走下去一定会限制长期发展，我们首先排除掉MicroVM/Containers，重点关注后面两类控制粒度更细的Runtime。

WebAssembly沙箱 ​

WebAssembly这几年在后端非常热闹，除了字节码联盟(ByteCode Alliance)极力推广，CNCF和一众创业公司也都非常看好。CNCF甚至单开了一级目录来汇总Wasm技术生态。

WASM字节码是一个真正中立的、开放的字节码系统，已经是跨越编程语言鸿沟的标准答案。 那么，给WASM加上系统调用，不就能跨越操作系统鸿沟了么？

有了系统调用能力，不就可以轻松实现任何功能的Serverless Runtime了吗？

的确，在WASM Serverless生态已经有了不少探索者，其中有两家公司值得持续关注：

• 2021年，Helm, OAM, Krustlet的项目创始人，Matt Butcher离开微软，成立了Fermyon公司，专注开发基于WebAssembly的Serverless平台。
• 2023年5月，Wasmer公司在WASI的基础上提出了WASIX，实现了完整的System Interface。

"第一代云计算是虚拟化、第二代云计算是容器化、第三代云计算是WebAssembly"。

-- Matt Butcher, Fermyon Founder & CEO

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!

-- Solomon Hykes, Docker Founder

可见，WASM沙箱介于前两者之间，既是语言无关的通用方案，又能提供从系统层到应用层的API，还足够轻量。

主流编程语言都有不少优秀的、成熟的WASM Runtime项目。WASM的繁荣，无意间拍死了相同愿景的Oracle GraalVM，用WASM Runtime做Serverless Runtime，性能接近原生应用，还不会被编程语言和云厂商锁死，看上去非常完美。

但我们知道，工程是关于Trade-off的。

那么，代价是什么？

首先，WASM运行不同语言的代码时，并没有想象的那么无缝。由于每种语言自己的内存编码方式和WASM不一样，跨语言执行时需要引入Binding胶水层做转换，一些性能会在内存拷贝时损耗掉，另一个问题是，编写这层Binding比较耗时，好在最近有个开源项目 Extism 能够部分解决这个问题。第三个问题，也是对开发者最大的问题，是WASM不容易Debug，C/C++还好，Chrome DevTools可以用，但WASM里面再启动一个其他语言的Runtime支持Python/JS的场景就麻烦了。

其次，编译成WASM和编程语言自己的FFI(Foreign Function Interface)生态是竞争关系，一些应用层的依赖如果用调用了更底层的动态链接库，上层迁移WASM依赖底层库也能编译成WASM。

这些问题导致了WASM生态很不健全，一边是Runtime实现很多（字节码简单直白，Carl也顺手写了一个），另一边是以WASM形态提供的三方库很少。

综上，WASM生态目前的成熟度，不足以支撑复杂业务的规模落地，但未来可期。

V8 Isolates沙箱 ​

V8 Engine对于Java/Go技术栈的同学听上去可能有些陌生，但它可能是从2008年问世以来，世界上运行次数最多的Runtime。

• 所有Chromium内核的浏览器跑的JS Runtime是V8；
• 所有Node.js/Deno的后端服务和前端工具链也是V8；

根据Datadog 2023年的Serverless调研报告，占据40%以上市场的Node.js也是V8。

V8 Isolates是V8 Engine的关键概念，可以简单理解成浏览器中的Tab。

浏览器Tab和Serverless Runtime有什么关系呢？带着这个问题，我们再审视一下浏览器执行引擎。

浏览器为了让用户尽可能获得接近原生应用的体验：

• 优化了代码打包和各种网络环境下的分发性能
• 优化了冷启动时间

浏览器为了支持打开大量不同网站的Tab的性能，还要互相完全隔离：

• 优化了计算资源调配和多租户的配额
• 从设计上就保障安全隔离

甚至浏览器为了兼容各种编程语言、支持高性能原生代码执行，还自带了WASM Runtime！

我们惊讶的发现，浏览器的执行引擎和一个安全高效的Serverless Runtime的需求，竟然是完全一致的！

既然浏览器引擎本擎，就满足了Serverless Runtime的需求，那为什么还要AWS Lambda这种MicroVM + Node.js 两层Runtime的蹩脚架构？只用V8 Isolates不就够了吗？

对的，当然可以。

以上观点来自创造了Protobuf Protocol(V2)、Cap'n Protol, Cloudflare Workers的巨佬Kenton Varda。

Cloudflare Workers是这类Serverless Runtime的典型代表。这类Runtime与业务层关联更紧密，要什么能力就直接调用，没有那么多底层的抽象概念，开发者体验做的很好。

但是，我们还要回答一个问题，抛弃了MicroVM/Container这层OS-level Runtime的隔离，还足够安全吗？

Kenton作为Cloudflare Workerd Founder，自己用12页安全模型分析，完美回答了这个问题。

我们划下重点：

• V8 Isolates自带的机制，结合一些简单的Eviction策略，就能实现资源隔离和高效调度
• 平台主动升级V8，不仅借了Google的顶级安全团队的力量，而且避免了传统Serverless Runtime模式下，厚重的Guest层的漏洞没人管的困境
• 主动对不同用户的代码进行动态监控、分级、分区调度，定时轮换对内存洗牌
• 不暴露POSIX系统调用，尽可能确保代码运行的确定性，有效缓解了幽灵漏洞这类边信道攻击

但深入阅读Cloudflare Workers的workerd源码后，发现Cloudflare Workers也有一些局限性，比如：

• 深度绑定了Cloudflare的其他云产品
• 对TypeScript的支持不够好
• 使用Pyodide支持WASM运行Python解释器仍早期实验阶段。

个人认为真正把V8 Isolates这条路线走到极致的，是一个2023年开源的新项目，Supabase Edge Runtime。

EdgeRuntime的架构和设计思路完全致敬了Cloudflare Workers，但最大的区别在于：

• Cloudflare Workers基于 Node.js API + C++实现
• EdgeRuntime基于 Deno API + Rust实现

注：基于V8 Isolates的方案，还有一个更早的isolated-vm。比V8 Isolates更轻的方案中，有个有趣的Serverless runtime项目是AWS前不久开源的LLRT，LLRT是一个基于QuickJS的非常轻量的Runtime。但QuickJS其实只是冷启动Quick，对于每个Request创建一个Worker的场景比较合适，如果是池化后长期跑，性能与V8差1-2个数量级。

另一个常见的选项是Goja，压测工具K6就是用Goja实现的大量Virtual User并行执行自定义的压测脚本的。Goja实际使用下来，没有大问题，但对ECMA新标准的支持不足，项目活跃度比较差，也没有内嵌WASM运行时，所以支持不了除了JS以外的语言。

总结 ​

我们再从Host和Guest上分别有什么，来总结这几类Serverless Runtime方案的差异。

拿 #1(VM/Containers) 和 #3 (V8 Isolates) 对比，可以发现 VM/Containers是轻Host重Guest的，而Isolates方案是重Host轻Guest的。Guest越轻，攻击面越小，用户也能更聚焦自己的业务，而非Runtime的底层概念。

拿 #2 (WASM )和 #3 (V8 Isolates) 对比，可以发现WASM方案的架构更合理，但复杂度最高。

最后，一句话总结一下这三条Serverless Runtime技术路线的特点：

• V8-based runtime：把浏览器Tab玩出了艺术
• VM/Container-based runtime: 缝缝补补，小破小立
• WASM-based runtime: 思想超前，大破大立

我们该选哪个？ ​

这三种路线该什么选呢？我们回到最开始的目标：”构建SaaS平台自定义扩展点“，展开分析Serverless Runtime / Code Sandbox的需求，看看跟这些技术方案的匹配程度。

三种技术路线的主流方案效果对比，结论是Supabase EdgeRuntime胜出。

对EdgeRuntime的详细评估 ​

源码阅读 ​

main.rs → commands.rs → server.rs → worker_ctx.rs →
| → worker_pool.rs → worker.rs → deno_runtime.rs 
|                                 → sb_core/permissions.rs
|                                 → sb_fs/virtual_fs.rs | static_fs.rs
| → supervisor.rs

• 启动逻辑大部分在 worker_ctx.rs 中，组装参数，创建pool，worker，supervisor等等；
• 处理请求的逻辑，从server.rs 的 accept_stream() 开始，一层一层把消息传到main worker / user worker 中，完全用channel进行消息传递，没有函数指针传递；
• permissions.rs主要限制网络和deno core中非fs部分的权限 (由于需要细粒度的fs控制，deno core本身不够动态，所以fs的权限在这里放过，专门由sb_fs处理);
• virtual_fs.rs用于 main worker，有完整的FS权限； static_fs.rs 用于 user worker, 啥权限都没有，read_file_sync的逻辑只有根据net access 来判断是否允许加载import依赖的逻辑，非mem fs路径的全部返回path not found, 测试没有办法读到任何路径。

渗透测试 ​

对User Worker做了一些渗透测试，发现一个安全问题，给他们提了个Issue。 https://github.com/supabase/edge-runtime/issues/340

性能测试 ​

单机启动100个Worker，混合并发请求压测。压测代码如下：

console.log('main function started');

const createWorker = async (servicePath: string) => {
    const noModuleCache = false;
    const importMapPath = null;
    const envVars = [] as [string, string][];
    const forceCreate = false;
    const netAccessDisabled = true;
    const workerTimeoutMs = 60 * 60 * 1000;
    const cpuTimeSoftLimitMs = 2000;
    const cpuTimeHardLimitMs = 3000;
    const memoryLimitMb = 16;

    return await EdgeRuntime.userWorkers.create({
    servicePath,
    memoryLimitMb,
    workerTimeoutMs,
    noModuleCache,
    importMapPath,
    envVars,
    forceCreate,
    netAccessDisabled,
    cpuTimeSoftLimitMs,
    cpuTimeHardLimitMs,
    });
};

const userWorkers = [] as any[]
const userWorkersPromise = [] as Promise<unknown>[]

async function start500UserWorkers() {
    const baseDir = Deno.env.get("HOME") + '/SourceCode/edge-runtime-benchmark'
    for (let i = 0; i < 500; i++) {
        const tempDir = baseDir + `/function_${i}`
        userWorkersPromise.push(createWorker(tempDir).then(worker => userWorkers.push(worker)))
        // await createWorker(tempDir).then(worker => userWorkers.push(worker))
    }
}

start500UserWorkers()

console.time('create 500 workers')
await Promise.all(userWorkersPromise)
console.timeEnd('create 500 workers')

Deno.serve((req: Request) => {
 // request with header: functionId: 0-1999
 const worker = userWorkers[req.headers.get('functionId') as unknown as number]

 if (!worker) {
  return Response.json({ error: true, msg: 'function not exists'}, { status: 400})
 }

 return worker.fetch(req)
});

K6测试代码

import http from "k6/http";
import { check } from "k6";

export const options = {
    scenarios: {
        simple: {
            executor: 'constant-vus',
            vus: 100,
            duration: '1m',
        },
    },
};

export default function () {
    const functionIdValue = Math.floor(Math.random() * 500);

    const res = http.get('http://localhost:8989/', {
        headers: {
            'functionId': `${functionIdValue}`
        }
    });

    check(res, {
        'status is 200': r => r.status === 200,
    });
}

MacPro M1的测试结果，单机100个Worker的QPS是4784。

k6 run benchmark-100

          /\      |‾‾| /‾‾/   /‾‾/
     /\  /  \     |  |/  /   /  /
    /  \/    \    |     (   /   ‾‾\
   /          \   |  |\  \ |  (‾)  |
  / __________ \  |__| \__\ \_____/ .io

     execution: local
        script: benchmark-2000.ts
        output: -

     scenarios: (100.00%) 1 scenario, 100 max VUs, 1m30s max duration (incl. graceful stop):
              * simple: 100 looping VUs for 1m0s (gracefulStop: 30s)


     ✓ status is 200

     checks.........................: 100.00% ✓ 287124      ✗ 0
     data_received..................: 46 MB   770 kB/s
     data_sent......................: 28 MB   459 kB/s
     http_req_blocked...............: avg=5.12µs  min=0s     med=1µs     max=13.43ms  p(90)=2µs     p(95)=2µs
     http_req_connecting............: avg=2.68µs  min=0s     med=0s      max=8.36ms   p(90)=0s      p(95)=0s
     http_req_duration..............: avg=20.81ms min=1.48ms med=20.5ms  max=237.88ms p(90)=28.33ms p(95)=32.2ms
       { expected_response:true }...: avg=20.81ms min=1.48ms med=20.5ms  max=237.88ms p(90)=28.33ms p(95)=32.2ms
     http_req_failed................: 0.00%   ✓ 0           ✗ 287124
     http_req_receiving.............: avg=24.9µs  min=4µs    med=13µs    max=36.93ms  p(90)=30µs    p(95)=45µs
     http_req_sending...............: avg=8.13µs  min=1µs    med=5µs     max=27.71ms  p(90)=8µs     p(95)=11µs
     http_req_tls_handshaking.......: avg=0s      min=0s     med=0s      max=0s       p(90)=0s      p(95)=0s
     http_req_waiting...............: avg=20.78ms min=1.44ms med=20.47ms max=237.86ms p(90)=28.29ms p(95)=32.15ms
     http_reqs......................: 287124  4784.152692/s
     iteration_duration.............: avg=20.89ms min=1.89ms med=20.57ms max=248.07ms p(90)=28.41ms p(95)=32.28ms
     iterations.....................: 287124  4784.152692/s

参考资料 ​

• https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/
• https://www.youtube.com/watch?v=HK04UxENH10
• https://deno.com/blog/roll-your-own-javascript-runtime
• https://github.com/fermyon
• https://wasmer.io/
• https://github.com/firecracker-microvm/firecracker
• https://spectreattack.com/spectre.pdf
• https://supabase.com/blog/edge-runtime-self-hosted-deno-functions
• https://landscape.cncf.io/?group=serverless&view-mode=grid
• https://www.datadoghq.com/state-of-serverless/
• https://blog.cloudflare.com/workerd-open-source-workers-runtime/

职业生涯的第一个十年 ​

在7年前加入ZOOM时，我的职业目标非常明确，就是成为一名优秀的软件架构师。

然而，这次工作转换似乎带来了不曾设想的运气。

运气之一是获得了一些原始期权，上市后解决了家庭柴米油盐的问题；运气之二是遇到一位优秀的领导，给予团队较高的自由度；运气之三是刚好在入职后在一个救火项目，获得了很快的成长和较高的可见性。成为架构师的职业目标，也在4年前提前完成了。

那之后呢？下一个5年、10年要成为什么？人生的意义是什么？

我非常认可薛定谔说的这句话，“Life feeds on negative entropy”，即生命的意义在于反抗熵增。

熙然，相比于在公司里按部就班解决工程问题，创业才有机会制造更大范围的“负熵”。也只有创业，才能更纯粹地将技术与商业结合，给世界带来一点改变，这是我的诗和远方。

于是，我这些年一直在向创业的方向沉淀，在公司尽可能去做从零到一有挑战的事情、去中科大读MBA、去随时思考商业机会。

这些年，我也在等一个机缘，如今，AI大潮势不可挡，我提醒自己是时候离开这个待了7年的平台了。

等风来，不如追风去 ​

我自认为是一个很理性的人，风险厌恶程度高，从这个角度看我是不适合创业的。

然而，创业是一种病，只有甘于平凡才能治愈。

当集齐了人、方向、钱三要素时，我便下定决心全身心投入创业。

首先是人的因素，我的合伙人Andy是行动派，技术过硬，有持续创业的经历，性格也很适合创业，他说了句很经典的话：“要么纳斯达克敲钟，要么回家种地”。其他几位在初创期帮忙做事的小伙伴也很靠谱。

其次是创业方向，考虑到团队的极客基因和现有的积淀，我们选择了高技术壁垒的GPU虚拟化赛道，入局AI领域做卖铲人，有清晰的产品目标、明确的潜在客户，非常适合小团队轻资产创业。在花了两周时间详细调研了这个细分领域的竞争格局之后，更加确信这个方向的可行性。

最后是钱的因素，在当前AI飞速发展的大趋势下，选定AI Infra这个领域后，投资人很容易找，要考虑的是哪些钱不应该拿，如何找对的投资人。于是，我们在天使轮只拿了少量信任关系强的自然人投资，短期只做产品打磨、单个中大型企业的案例验证。

开始行动! ​

集齐了人、方向、钱三要素后，便再也没理由回答“为什么不创业”了。先走出去，边走边看吧！就像罗振宇跨年演讲所说：

一具体，就深刻； 一行动，就创新； 一困惑，就出门。

最后，以我们一位投资人激励我的话结束：

征途纵有棘荆拦，莫负初心志似磐。 且待云开霾雾散，遥看彼岸凯歌还。

工作 ​

平台工程的下一站 ​

2024年我的工作重心仍然在平台工程，为了解决公司基础设施的遗留问题，迭代了不少Kubernetes基建之外的功能，满足自建机房、非后端业务、复杂业务的各种长尾定制需求。

这一年功能迭代稍微能喘口气，解决一些稳定性和质量问题、服务运营体系搭建完善。从公司的满意度调查结果看，上千个内部的工程师用户给我们平台打了85分，喜忧参半。

印象比较深的里程碑有两个。一个是数千个域名换非通配TLS证书；另一个是作为FinOps小组关键成员之一，为公司节省了每月数百万美元成本，FinOps年后一定得总结输出一个系列文章。

这一年团队变化比较大，出差苏州两次，在管理方面遇到了一些挑战。从结果看，自己在管理方面还欠缺很多，具体细节不便展开。

在哪里重生 ​

除了本职工作，这一年一直在想办法打破个人和团队发展的天花板。

上半年做了一次尝试，失败了。

当时参加公司年度AI Hackathon活动，用一周时间做了个“AI端到端测试助手”的原型。

产品形态是VSCode插件，输入是PM的需求和前端代码仓库，从源码层面分析DOM selector，结合RAG和LLM Flow，来准确生成E2E自动化测试用例、用户手册文档。

这个想法和产品原型在几轮PK后进入了四强，最终没能获奖。

其实，系统学习了MBA后，我很清楚一家公司的战略地图如何制定，只有在战略地图上的事才可能被重视。

所以，我也坦然接受了结果，这件事做的再好，也不太可能在一个做协作办公产品的SaaS公司中孵化出来。而之后外面的事，就是Cursor、Devin、Codium、Qodo Gen、WindSurf这些产品爆火，AI编程成为24年下半年的投资风口。

目前为止，我仍然认为那个产品是能拿来创业的，E2E测试和用户文档是前端开发和Tech Writer的巨大痛点。现在市面上的AI编程助手、AI浏览器自动化产品都是“通才”，而这个场景太需要“AI专才”了，“通才”不能很好解决垂直领域的问题。

引用《长安的荔枝》中的话：就算失败，我也想知道，自己倒在距离终点多远的地方。

这件事只是个小插曲，10月份发生了一件意义重大的事情，让我再次找到了打破桎梏的希望，下一篇再说。

学习 ​

24年学习的开源项目多一些，Star过240多个开源项目，重点关注了一些AI项目，看到的精华在下一节整理回顾。

AI方面的学的越多，越感觉到人与人的关系正在被智能世界解耦，StackOverflow流量腰斩、各种交流社区正在没落。AI做的事情越多，人与人的交流越少、观点越割裂。

我相信硅基生命有一天会到来，作为碳基生命，能做的是多学习些开眼的新东西，多关注“下蛋的鸡”，看看每个项目背后是哪些人，了解他们有哪些精彩的故事。

技术 ​

AI方向

AI技术关注了三个方面：AI模型、AI开发框架、AI Infra，印象比较深刻的项目有：

• AI Agent开发框架AutoGen
• LLM Flow Engineering项目Flowwise
• AI数据摄取框架AI Reader
• AI浏览器自动化Browser Use
• GPU虚拟化和池化。这是我最近很关注的领域，重点看了第四范式、Daocloud、华为合作开发的HAMi
• AI训练、开发、数据处理、部署的全套框架Project Ray，感觉Ray背后的公司Anyscale，有望成为挑战HuggingFace地位的公司
• DeepSeek大模型。我在OpenAI充的几百块钱用完后，朋友推荐这个模型效果不错，10月份左右换成了DeepSeek的API，充了10块钱竟然一直用到现在，背后扮猪吃老虎的公司幻方量化最近出圈了。我也在尝试能不能把AI编程环境也换成DeepSeek-Coder

前端方向

24年我们团队内部跟随HeadlessUI的趋势，做了实践落地。前端生态对开发体验的极致追求，对关注点分离和函数式思想的执着，造就了“一切皆为Composable”。另一个趋势TailwindCSS的广泛普及，已经成为事实标准。至此，HTML-JS-CSS三要素，可以全部用函数组合解决。

• 组合React Hooks/Vue Composable实现业务逻辑；
• 组合React/Vue Component或WebComponents实现页面结构；
• 组合Tailwind原子CSS和封装后的CSS Class实现交互视效。

以下是个人关注的一些有趣的前端项目：

• 新兴的UI框架，比如PrimeVue、DaisyUI、大多数海外创业项目，都在用TailwindCSS
• D3创始人开发的新一代的数据可视化框架Unovis
• 基于CheerpX把整个操作系统编译成WASM，在浏览器运行Linux的WebVM，甚至通过TailScale支持了完整的TCP/IP网络协议栈
• 把整个Container编译成WASM的Container2WASM
• 在浏览器运行GPU大模型推理的WebLLM，这个项目背后是WebGPU标准以及对应的实现WGPU、Dawn
• Terminal UI(TUI)框架：ink、ButtleTea

后端和基础软件方向

• Postgres数据库封神，在24年流行度首次超过MySQL。PG 17的发布、AI应用的爆发，Make Postgres Great Again。个人Star过一些PG生态项目有：PGVector.RS、Doltgresql、Azure Cosmos DB for PostgreSQL底层的Citus
• Kubernetes集群的节点组池化方案Karpenter也成为了事实标准，甚至出现了基于Multi-cloud Karpenter的FinOps创业公司CloudPilot AI
• 大型云厂跟Redis关系破裂，Redis社区分裂出Valkey
• 密钥管理平台infisical，这个项目印象深刻，是因为我参与过公司密钥平台的构建，理解为什么这个项目能火起来。像Secret Manager、Vault这些引擎层产品最大的问题是功能太单薄，满足不了企业级的密钥治理需求，比如元数据管理、密钥轮转、热加载等等。
• 授权决策框架OpenFGA，AuthZ框架非常多，我看过、用过很多，看起来很简单，做对很难。读了OpenFGA源码和文档后，感觉这个项目鹤立鸡群，甚至忍不住贡献了一些代码。年后再单独写一篇文章讲讲：为什么Google Zanzibar提出的ReBAC是更适合B2B场景的AuthZ选型。
• 新兴的工作流编排产品Kestra，产品设计挺好。
• Kubernetes智能看板Karpor，KusionStack体系的新项目，用ElasticSearch转SQL的方式，把Kubernetes集群资源做成数仓，很有意思，解决了多集群Kubernetes数据集中管理问题。
• 工作流引擎Restate。23年我重点推荐过Temporal，24年Rust生态出现了Temporal的挑战者Restate，果然，一切可能被Rust重写的都会被Rust重写。
• GPU Database HeavyDB。GPU全称是GPGPU，既然General Purpose GPU，为何不能做数据库？超高内存带宽、超强并行计算能力、跳过CPU直接Zero Copy写入NVMe的能力，刚好符合了大规模的数据读写和分析场景，虽然这个GPU数据库产品离普及还很远，这个方向是值得关注的。
• Notification as code项目novu。给用户发送通知一直是Web开发最基础的能力之一，这个项目简化了给用户编排复杂通知业务的开发成本。
• Everything as code项目Pulumi。IaC/EaC是运维自动化的基础，我3年前开始关注Pulimi这家做IaC的初创公司，工作中也参考了一些Pulumi的设计。Pulumi在23年底完成了$4100万C轮融资，证明了这是个好产品，也是Terraform最大的挑战者。我自己也在用Pulumi，TUI交互很不错，GUI差强人意。
• 新兴云原生时序数据库GreptimeDB。年底刚发现的一个Rust生态的好项目，解决了监控场景几个关键痛点：Prometheus单值体系无法大规模Scale和持久化、Clickhouse运维和写SQL复杂、监控日志数据库用块存储成本高昂、监控系统自监控问题、持续聚合和长期指标存储能力等等。这家公司创立刚两年，产品功能已经相当完善了，值得去试一试。

SaaS产品

分享一些24年试用过、或正在使用的SaaS产品：

• Teable：开源的Airtable替代品。
• Webflow：建站首选Webflow，没有找到第二家做到这个程度的，试用下就不用解释了。
• Incident.io：做Status Page的新产品，对比了一下BetterStack，最终还是选择了Incident.io
• Harness Cloud Costs Mgmt.：Harness是持续交付领域的独角兽公司了，关(chao)注(xi)了3年多，24年做FinOps项目，发现Harness竟然也做了云成本管控模块，体验下来感觉很不错，继续关(chao)注(xi)。
• Cloudflare：有理想、有追求、不作恶的云厂商，24年发布了用Worker体系运行Container的能力。我的个人网站、创业项目已经All in Cloudflare了。
• Resend：像写React一样写用户邮件通知
• WindSurf / Codium / Cursor：24年是AI编程爆发的一年，个人感觉试用效果不错的是WindSurf，唯一的缺点是我习惯用CMD + I快捷键做类型提示的代码补全，但快捷键被AI助手覆盖了要自己改键，这点很不舒服。
• Clerk：SaaS化的用户系统，配合Supabase可以快速开发一个B2B业务
• Lago：开源的Subscription Plan管理系统

在技术方面，今年还做了一件小事。把个人站点用Vitepress重构了一遍，加上Giscus评论和RSS，去掉了粒子特效，背景换成了泛黄的纸张纹理。在30岁生日，送自己一个极简风格的数字花园。

分享 ​

团队内部的知识分享活动，我自己讲了2次。一次讲技术，主题是如何执行用户的非可信代码，另一次讲财务，主题是如何解读财报。除外，还有一次小范围讲OpenFGA设计原理和使用方式。这些知识分享资料，年后也会把跟公司业务无关的部分逐步整理发出来。

这年的文章输出仍然求精不求多，每篇都在5000字以上：

• 如何写出高质量的技术文档
• SaaS的本质是什么
• 为什么Tensor Fusion能够颠覆GPU虚拟化

读书 ​

读书和分享集中在中间两个季度，读的比较少，只有13本书，有闲暇就看下，但没坚持太久。

管理学相关的书：

• 2021版的《助推》，原书名《Nudge》，作者 Richard H. Thaler, Cass R. Sunstein
• 《HR+三支柱——人力资源管理转型升级与创新实践》—— 马海刚 彭剑锋 西楠
• 《从总账到总监：CFO的独家财务笔记》—— 钱自严
• 《从报表看企业——数字背后的秘密》——张新民

不带目的，随便看的小说：

• 《鲸歌》—— 刘慈欣
• 《球状闪电》—— 刘慈欣
• 《太白金星有点烦》—— 马伯庸

其他类的书：

• 《金刚经说什么》—— 南怀瑾
• 朋友推荐的《爱的五种语言》 —— Gary Chapman
• 微信读书算法推荐的《法律的悖论》、《毛泽东选集》、《党委会的工作方法》
• 老婆推荐我看的《在峡江的转弯处：陈行甲人生笔记》

最后，重磅推荐罗振宇的《文明之旅》节目，一集没落听到现在，每集都会有不同的启发，发愿做20年节目，每集高质量输出一个多小时，真是个狠人。

生活 ​

生活方面，24年下半年遇到了一个挺大的挫折，调整了一段时间，全年总体还不错。

养了两只鹦鹉，添了两颗柠檬树。

这一年家庭旅行，去的都是比较近的地方：

• 江西景德镇，体验陶艺，
• 铜陵犁桥水镇，看打铁花，
• 芜湖松鼠小镇，一点点小刺激，
• 庐江的民宿和农场，休闲小憩，
• 安徽博物院、地质博物馆、园博园昆虫博物馆，涨涨知识，
• 金寨马鬃岭，看三花槭染红整片森林
• 南京红山动物园、合肥野生动物园，满足孩子对动物的执念。

旅行总是匆匆瞥过，而身边的美，要特写镜头来感受。

收获最多欢笑的地方，是不到500米的公园。和老婆孩子走到湖边，攥一个木棍，扔几块石头，看野鸭子游泳。

公园里落羽杉、四叶草、金鸡菊、蒲公英，或星点散落，或连成一片，不同季节换上不同的模样。

未霜乌桕赤，另日海棠红。

最美的风景来自内心，来自身边的人。

总结和展望 ​

去年给今年定的关键词是“行动、行动、行动”，一年下来，做了一些有意义的事情，但一些没有克服掉的拖、懒、贪，导致不少时间白白浪费了，综合来看，勉强能给自己一个交代吧。

新的一年，拒绝拖延，从按时写年终总结开始。

最后借用罗振宇跨年演讲的一句话：所有来自未来的好消息，都是我们今天努力的模样。

2025年的关键词，继续用这六个字吧： 行动、行动、行动!

Background ​

Recently, while working on our company's cloud cost optimization, most cloud resource cost control strategies were clear, but the exorbitant GPU fees remained a headache.

In October, I caught up with an old friend who happened to be researching GPU virtualization. After seeing his prototype, my intuition told me it will be a revolutionary technology, possibly it could create a unicorn-level company.

We immediately aligned our vision and started working on the project in our spare time, naming it Tensor Fusion.

As our research into GPU virtualization deepened, I compiled some valuable insights that both answer why we're committed to this venture and demonstrate to users or investors where our product value lies.

Before diving into the technical discussion, you can check out the Demo to understand what Tensor Fusion is. The docs are available here: Get Started. We welcome trials and feedback.

背景 ​

最近在搞公司的云成本治理，大多数云资源成本控制思路很明确，但贵到离谱的GPU费用，一直是头疼的问题。

十月跟一位好友叙旧，碰巧他正在研究GPU虚拟化，看完他的原型演示，直觉告诉我这是个颠覆性技术，甚至有机会创造出独角兽级别的企业。

我们一拍即合，业余时间支棱起来，项目名为Tensor Fusion。

随着对GPU虚拟化的研究深入，我整理了一些干货，既回答我们自己为什么要投身这件事，也回答用户和投资者我们的产品价值在哪。

在展开技术讨论之前，可以先看下Demo，了解Tensor Fusion是什么，使用文档在这里：Get Started，欢迎试用、反馈。

引言 ​

年初跟一位做SaaS的企业家朋友聊天，讨论到国内和国外SaaS业态差异，引出了一些深层思考。

他说，国内的决策机制和市场环境下，出现了大量非标需求，导致垂类SaaS倒向了定制开发、私有化交付，很难做到一个中心的云上系统，服务大多数客户。

那么，以这种形态交付的软件服务，还能称之为SaaS吗？

最后这位朋友的结论是：只要客户不是一次性买断，而是持续给软件付费，就算SaaS。

相比于典型的中心云SaaS，哪怕半私有化交付的边际成本和获客成本更高，只要能一直收到钱，公司就能活下去，交付形式没有那么重要。

SaaS的本质是订阅。

听了朋友的分析，我不禁感慨，实践派的观点总是简单而深刻，这篇文章我们从“SaaS的本质是订阅”的观点出发，从价值流角度，分析SaaS的本质是什么。

什么时候买SaaS？ ​

既然SaaS最普遍的特征是“为软件服务持续付费”，首先要问一个问题：为什么客户会持续付费呢？

在六阶导数解构企业经营中提到了一个常识：财务结果是对用户价值的度量，也就是说，客户觉得值得买，企业才可能盈利。

继续追问：SaaS的客户到底购买的是哪些「价值」呢？

我访谈过十几位采购SaaS的决策者，问他们到底是哪些因素，让他们选择了SaaS，而不是自研系统、传统方法手工做、外包这些方式。

下面总结了3类答案，不同的角色排序不一样，但最终都因为这些原因选择了SaaS。

1. SaaS的综合成本更低 ​

综合看SaaS的投入产出比，一定比“全域自研”和“土法炼钢”都要高，TCO（Total cost of ownership）也比其他方案低得多。

比如常见的ZOOM、Google GSuite、WPS这类协作办公类SaaS，许可证费用才每人每月十几块到几十块钱，相比于云化前的办公文件到处传、线下到处找工位，省下了巨量的沟通成本和管理成本。

另外，相比于自研或买断，SaaS的租赁模式对现金流压力更小，再综合考虑货币时间价值、买断后的利用率这些因素，显然SaaS是综合成本更低的选择。

一般老板拍板买SaaS时，最看重的是这一点。

2. SaaS的经验起点高、迭代快 ​

成熟的SaaS，凝结了这个领域最核心的经验，包括：

• 以模板形式提供的可复用的资源
• 以功能模块形式提供的可复制的能力

SaaS相当于租赁了这个垂直领域最关键的资源和能力。还是拿在线办公举例，买了WPS VIP后，既可以参考各种优秀的Excel/Doc模板资源，又能用云同步、格式转换这些开箱即用的能力，简直是打工人的救星。

一些对新技术采纳比较激进的决策者，不仅看重SaaS带来的经验起点，还会看重经验增量。每次版本更新，能不能解决更多实际问题？那些中小型SaaS能瓜分到行业龙头的份额，靠的就是在细分领域精准、快速迭代产生的增量价值。

一般CIO或部门领导拍板买SaaS时，最看重的是这一点。

3. SaaS能转移经营风险 ​

不管是自研还是买断，都意味着所有使用和维护的责任都是自己承担了。而购买SaaS，意味着系统的维护责任、数据的部分管理责任、功能的安全合规性，相当一部分由供应商承担了。

承担的责任变少了，风险自然就被分摊掉了。

这点不管是IaaS/PaaS/SaaS都是一样的，区别是越靠近业务侧，供应商分摊掉的的责任和风险越多，当然潜台词是订阅价格也越贵。

合规、法务、一些相对保守的部门，采购、采纳SaaS最看重的是这一点。

什么时候不买SaaS? ​

访谈也得出了另一个问题的答案：什么时候不该买SaaS？

下面三种场景中，SaaS的投入产出比是不够的，因此一般会选择自研、买断、收购、外包这些“非SaaS模式”获得服务：

1. 与核心业务领域强相关。既然是在核心领域，企业自己有领域专家，一般选择自建而非购买。
2. 业务发展到一定规模后的垂直整合。业务到达一定体量后，上游服务的垂直整合就会变成降低经营风险和成本的重要战略方向。但一般也只是整合业务上游中的高价值、高风险的部分，大而全的盲目整合、全域自研不可取。
3. 市场上存在TCO更低、ROI更高的其他方案，比如基于开源或免费软件的方案、整个职能外包的方案等等。具体选择哪种模式呢？一般是越接近底层越有倾向采纳开源方案，比如Linux、Kubernetes；越处于价值链边缘越倾向于整个职能外包，比如企业内部IT服务、财务中的账务服务等等。

SaaS价值如何产生？ ​

搞清楚了“客户为什么觉得SaaS值得买”，我们再从SaaS公司内部组织结构做价值流分析，就离SaaS的本质更进一步了。

我们把一个SaaS企业价值链的关键部门，按照关联程度做一个聚类分析，可以找到以下三类组织。

1. 跟客户沟通的
2. 提供服务的
3. 设计和改善服务的

1. 跟客户沟通的 ​

这类组织冲在前线，大多数工作都是沟通。常见的组织形态有：

• Sales：传递产品和服务的价值，促成客户的采购决策
• Solution Architect (SA)：根据客户的实际问题，提供定制化的完整售前方案
• Customer Success Manager (CSM)：全生命周期的客户体验管理
• Technical Account Manager (TAM)：协助用户管理数据、提升对技术的使用深度

他们站在客户的立场上，作为客户的“业务伙伴”，发现客户面临的挑战，对外推动客户的购买和使用，对内反馈新问题和新需求。

这类组织的关键词是Discover。

2. 提供服务的 ​

SaaS用户购买产品后，并不是直接找上面这些角色提供服务。大多数情况下是软件自助服务和人工技术支持。常见的组织形态是：

• SaaS产品本体。在不同领域衍生出各种”X“aaS, 载体可以是GUI Portal，或是没有GUI的SDK、API，甚至是内置在硬件内的系统
• Support Specialist/Service Engineer (SS/SE)：技术支持/服务工程师

这些组织提供的服务，是用户拿在手里解决问题的“锤子”。不同于买个真锤子，SaaS是软件定义的、逻辑上的“虚拟锤子”，底层的物理资源实际上是共享的。因此，SaaS对计算资源、支持人员这些物理资源的调度效率越高，也就意味着服务共享程度越高、自助服务程度越高、交付服务的速度越快。

这类组织的关键词是Deliver。

3. 设计和改善服务的 ​

有了第一类组织跟客户沟通，就有了源源不断的输入，这些输入汇集到一个领域专家组成的产品团队，不断升级和改善第二类组织所交付的服务。

这样，一个以客户为中心的飞轮模型就搭建完成了。在输入和输出之间，承担服务流程设计和改善责任的，就是第三类组织，常见形态是：

• Product Manager：接收各方输入，抽象出解决一类相似具象问题的产品模型，用自然语言表达产品模型。
• Software Engineer: 构建软件模型，用编程语言表达出产品模型。
• UX Design：作为前两者的桥梁，站在用户体验角度，用设计语言表达出*产品模型。

这三个角色都是在做模型设计，只是表达方式和视角不同。软件的设计等于生产，一个迭代周期结束，产出就是服务流程的改进结果。

这类组织上SaaS的决策中心、经验中心、变革中心，其综合水平，直接决定了产品水平。

因此，SaaS公司非常看重构建Engineering-Product-Design铁三角(EPD Triad)，把研发团队和产品团队视为核心资产。

这类组织的关键词是Design。

SaaS三支柱模型 ​

跟客户沟通的、提供服务的、设计和改善服务的，这三类角色的协同工作流，构成了一个创造价值的动态过程，即价值流。

借鉴人力资源管理的三支柱理论，我总结了一个SaaS的三支柱模型。

• 上面的一环是共享服务中心 (Shared Service Center - SSC），以产品形式提供自助服务的入口和接口，聚焦Delivery。平台化做的比较成熟的也可以叫共享交付中心(Shared Delivery Center - SDC)。
• 下面左侧的一环是业务伙伴 (Business Partner - BP), 是连接客户与软件服务商的桥梁、信息沟通的渠道，让客户不仅能把软件用起来，还能用的好、用的深。
• 下面右侧的一环是专家中心 (Center of Expertise - CoE), 是SaaS冰山下的核心能力，不断吸收和抽象来自客户的、市场的、技术领域的输入，在团队中和软件中不断沉淀新的经验，不断提升软件服务的价值。

按这个定义方式，任何一个SaaS公司的岗位，都能划分到三支柱中，比如：

• 服务运维(DevOps)、Technical Writer团队属于SSC
• 发布管理、TPM、QA等团队属于CoE
• Marketing、PR等团队属于BP

比较特殊的是 HR，Finance & Accounting，Security、Legal 这些公司职能部门，他们本身就是一个具备完整三支柱的服务单元。其实三支柱模型理论就是先在人力资源、财务这些完整的服务部门发展应用起来的。

类比一个人，CoE是大脑、SSC是四肢、BP是五感。

类比一个细胞，CoE是控制整个细胞结构的细胞核，SSC是有各种功能的细胞质，BP是接受和释放调控信号分子的细胞膜。

SaaS三支柱模型能解决什么问题？ ​

1. 诊断服务质量问题 ​

这种对SaaS的理解方式，最直接的作用是帮助我们发现哪里薄弱了、哪个角色缺位了，是做咨询诊断的好工具。

如果一个SaaS的服务质量有问题，从“问题在哪里”这个开放性问题出发，做好访谈、问卷、调查，就能逐步收敛到三支柱中的一些非常具体的因素。比如：是CSM管理了太多客户沟通不够、还是没有在工作中建立和CoE中PM团队的定期会议反馈问题？是产品团队的工程师能力问题开发速度太慢，还是因为没有重视用户反馈在闭门造车？是支持团队没有对产品有足够的理解解决不了用户的Ticket，还是产品本身有太多隐藏逻辑导致了用户和支持人员都没法自助服务？

举个我经历的例子，公司内部有十几个内部平台和中间件服务，但这些“内部SaaS”的成熟度不够、用户满意度不高，导致业务交付速度慢，市场竞争力难以提升。我们从去年年中开始，想办法解决这个问题。

一圈问卷调查和访谈下来，定位到主要问题在于BP和SSC两个支柱很薄弱，当时，60%以上的人认为没办法找到服务的支持人员、文档质量太差无法自助上手使用、服务不稳定等等。

再深入一层细节，看到是文档写了但很散乱、过时的比较多；支持人员是有排班的，但对人工支持的SLA管理没有闭环，没办法端到端解决用户问题等等，不展开了。

诊断完了，解决方案就有了。我们在SSC这一侧，构建了新的结构化的、集中管理的、AI自动问答的内部用户文档中心；在BP这一侧，构建专门的运营小组，做真正的SaaS服务的CSM、Solution Architect的事情，以服务为本，用数据说话。

一年多后，用户满意度已经有比较明显的提升。

这段经历让我理解了解决服务管理问题的朴素思路：对照着理论模型，搞清楚现实挑战，再收窄到几个主要问题，把缺的地方补上，掉在地上的事情捡起来。

2. 构建高效的CoE ​

三支柱模型有个有意思的地方，在CoE的内部，竟然套娃了另一个三支柱模型。

上面我们提到组成软件产品研发团队最关键的三个岗位 Engineering-Product-Design，EPD-Triad 正好和SaaS服务整体三支柱相对应：

• Engineering，代表了沉淀在软件里的领域经验，关注如何用软件模型本身的结构，是CoE中的CoE视角，
• Product，代表了从客户反馈提炼的产品迭代方向和目标，关注如何用产品帮助客户解决问题，是CoE中的BP视角，
• Design，代表了服务的用户交互流程，关注如何让自助服务的体验最优，是CoE中的SSC视角。

世界是分形的。理解CoE内部的这种分形结构，对实际工作有什么意义呢？

我认为理解本身就是意义。

理解了各方的立场，就能够促进各方高效协作。

很多软件公司经常遇到PM和工程师冲突、UX Design在前端实际用不了、工程师产出和实际需求脱节，这些都是没有正确理解CoE中这EPD三个角色的思维模式和分工意义导致的。

举两个常见的例子：有些工程师等着产品完全设计好才开始思考，只做一次把需求翻译成编程语言的工作，完全不关心用户目标、场景、满意度；有些交互设计师对业务领域了解很少，甚至没有完整用过产品，只是拿着PM的需求文档转换成设计稿。。

这两种情况都说明领域专家缺位，Designer停留在UI设计而非UX，Engineer停留在码代码而非解决工程问题，这种模式下，团队很容易产生冲突，产品质量一定不好。因为他们都没有真正成为领域专家的一员，只做了翻译的工作，没有用设计语言、编程语言做创造的工作。只把技术当一门手艺的人，在职业发展上是走不远的。

反之，真正理解了自己处在一个服务组织的CoE价值链之中，持续沟通、通过构建模型不断解决领域问题的，成为领域专家的一员，往往能走得很远。

3. 设计有效的沟通架构 ​

沟通架构可能是公司治理中最重要的一环，三支柱模型可以指导新的服务部门或SaaS公司的顶层设计，因为 Discover-Design-Deliver三支柱之间的信息流转方向，就是沟通架构设计的最优解。

在软件行业有一个“康威定律”，本质上就是沟通架构决定产品架构，一旦沟通结构错了，产品一定会变形。

大公司病也是从沟通病开始的。基层员工缺少战略地图引导和跨职能沟通，长此以往便看不到价值链的全貌，只关注自己做什么，不关注大目标是什么。这种微观问题在宏观上的表现，就是目标和任务颠倒、部门墙出现、内部协作成本剧增、公司整体发展停滞。

比如，如果CoE中的PM，和BP中的CSM、SSP中的Support 没有常态化的双向沟通，那么产品迭代一定会出问题。CoE中的Engineer和SSC中的DevOps如果没有常态化双向沟通，服务的可用性和交付速度一定会出问题。

因此，管理者在辅导团队成员制定OKR的时候，一定要把在沟通架构中与之协作的角色纳入考虑，将双方或多方共同达成的目标列入OKR，而不仅是自己所在职能的单一目标，再让目标来引导出正确的沟通架构。

三支柱模型本身就是顶层的沟通架构，能够指导局部的管理实践，让每个局部之间的沟通架构有效运转。每一层的沟通架构对了，就能防治“康威定律的诅咒”和“大公司病”。

总结 ​

本文从SaaS的持续订阅这个关键特征出发，分析客户为什么买SaaS，再分析一个SaaS企业的组织结构，推导出三支柱模型，最后讲了怎么用三支柱模型解决实际问题。

回到对SaaS本质的理解，我认为下面三个说法都对，只是看待概念的视角不同。

SaaS的本质，是订阅。

SaaS的本质，是一种以软件为中心的、CoE, BP, SSC三支柱共同组成的 Discover-Design-Deliver 业务模式。

SaaS的本质，是一种由领域专家构建的、持续迭代的、能够让用户自助操作的软件系统所提供的服务。

目录 ​

好文档是核心竞争力 ​

对用户来说，文档是产品必不可少的一部分，是使用和信任技术产品的前提。

对团队来说，文档是最有效的沟通方式。聊天、会议的内容会被忘记、内容深度和时效性都无法保障，而文档能突破时间和空间的限制保存知识。

对个人来说，文档是能力成长的必经路。写文档是锻炼结构化思维、视角转换能力最有效的办法。见字如面，判断一个做技术的人是否靠谱，我会重点看写了什么，而不仅是说了什么。

关于“怎么写好技术文档”的文章太多了，这里分享一些不一样的干货：一个理论、7条原则、21条行动建议。

怎么给文档分类？ ​

以读者为中心的信息架构 ​

技术文档往往既专业又复杂，要呈现的东西太多。因此，第一步是理清信息架构。

很多人思路是，“我有什么就写什么”，要么按功能分类，把用户手册平铺下去，要么只有自动生成的SDK/API文档。

用户读这类“以产品为中心”堆砌功能的文档，就像去一个地方旅游没有路线图，像无头苍蝇一样到处跑，该去哪里、怎么去、还有哪些没去，全然不知。

我们一定要换到文档的用户--读者视角思考，想清楚用户的使用场景是什么，阅读文档的目的是什么。

按使用场景设计文档的分类维度和信息架构，就像给了用户“旅游路线图”，爬山线路走这边、休闲路走那边，用户想要的自然一眼就能找到。

🚀 行动建议1：写任何文档之前，先画一个脑图梳理读者有哪些目标，把这张脑图贯穿整个写作过程。

技术文档的读者有哪些阅读目的？ ​

技术文档一般有哪些使用场景呢？我看到过最好的答案是Diátaxis框架的分类方法。

Diátaxis框架是工程师Daniele Procida总结的文档方法论，很多知名项目和公司已经在用了，比如Ubuntu、Python、Cloudflare、Microsoft、Gatsby、HuggingFace等等。

Diátaxis框架按 认知形式 和 采纳程度 两个维度，把文档分成了四类。

纵轴是按主要认知形式分的 知（Cognition）、行（Action）。越下面的越偏向认知为主，越上面的越偏向行动为主。一般情况下，技术文档要优先呈现行动的部分，而不是理论的部分。打个比方，对于厨师，看食谱比看烹饪理论管用的多；介绍食谱的书，不需要解释烹饪理论；烹饪理论的书，也不应该把菜具体怎么做一步一步列出来。

🚀行动建议2：偏实践和偏理论的文档分开写，按照 先“实”后“理”，或者说先“行”后“知”的顺序，呈现给用户。

横轴是按采纳程度分的 学（Acquisition）、 用(Application)。左侧是小白用户的教科书，右侧是专家用户的参考书。

在学的阶段，文档组织方式是师生模型，有学习的目标、难度、路径、进度，注重的是兴趣和动机、评估和反馈。

到用的阶段，文档应该是任务模型，以解决实际问题驱动，注重实用性和效率，多给一些拿来就用的例子，让用户在实际工作中快速查找和使用信息。

深入理解Diátaxis框架的四类文档 ​

有了两个坐标轴分出来的知、行、学、用作为标尺，四个象限就出来了，对应了四个阅读场景、四种文档类型。

我们先从用户群体的角度看：

• 左上角：Tutorial --入门教程。适合小白用户过来体验一下。通过具体行动获得感受，才能进入更深的认知层面。
• 左下角：Explanation -- 解释材料。适合刚跟着Tutorial简单用了一遍，但满脑子问号的入门用户。"这些概念是什么意思？为什么这样设计？怎么工作的？"回答了这些问题，用户就理解了产品的基本原理和核心概念。一些给专家用户学习的高级概念也可以放进来，但一定要和基本概念分开。
• 右上角：How-to Guides -- 使用指南。适合有实际使用经验的普通用户。有些项目的How-to Guides在文档目录也叫“Recipe”，就像在家做个便饭，看看食谱就能实现目标了。不需要精确理解概念和原理。
• 右下角：Reference -- 参考资料。适合给专业用户查阅高级功能的细节。打个比方，餐厅主厨做佛跳墙，可能也要去查查烹饪参考书。Reference是一种无聊但有用的文档。

为了方便记忆，我们用武学境界来关联记忆这四类用户、四种文档：

🚀行动建议3：写每一篇文档之前，先回答3个问题来确定属于哪个Diátaxis象限：是给什么熟练度的读者看的？是重点介绍原理和概念，还是介绍一步一步怎么做？是用师生模型还是任务模型组织内容？

再换个角度，从修改频率来看，这四类文档的维护频率是越往右边越高。

左半边是Tutorial和Explanation，学习教程和概念解释不会很快变化，只有大模块发布、产品大范围重构的时候，才需要更新这两类文档。

🚀行动建议4：Tutorial、Explanation在季度或更长周期的大版本发布前写好。但要定期验证文档有效性，发现有问题随时小修小补。

而右半边的How-to Guides和Reference，是要跟着项目迭代随时维护的。How-to Guides相比Reference维护频率更低一些，因为要让用户有一个唯一正确的完成某项任务的方法，所以How-to Guides不用像Reference一样多版本并存。

🚀行动建议5：How-to Guides在每次产品发布前更新一轮，保持在每月一次的频率，确保新功能发布前先写了文档，然后再把这些文档总结成Release Notes，Release Notes内部附上涉及的How-to Guides链接。

而右下角的Reference文档，要有极高的准确性、时效性，因此维护频率最高，每个版本都需要一份，也不应该人工写。

🚀行动建议6：Reference文档由 源码 + Swagger、TypeDoc、Swim这类生成工具 + CI/CD Pipeline 自动生成，每个产品发布周期，都自动增加一个版本，按需留一定数量的历史版本。

怎么组织文档网站？ ​

首页放什么 ​

学习完Diátaxis框架后，我们有了四条彼此关联的“游览路线”，但这还不够，我们还要飞到高空，给所有文档拍一个鸟瞰图，制作成Overview页面，作为文档站首页。

Overview既能让用户快速获得全局理解，又能作为关键索引，让用户一眼找到想看的内容。

• Tutorial 拍个鸟瞰图，就是核心业务场景的Quick Start，以及其他Tutorial的索引列表
• Explanation 拍个鸟瞰图，就是3W(What/Why/How it works), 一般文档标题是Introduction、Essential Concepts。另外，这里也要放一个“When to use/When not to use”的决策树，让用户快速判断这个产品能不能解决Ta的问题
• How-to Guides 在鸟瞰图中，浓缩成了一个关键任务指南的索引，可以叫“Recipes”
• Reference 太过细节了，在鸟瞰图中就要放链接就足够了，不必展开。

此外，首页还肩负快速打消用户顾虑的任务，因此，下面这些文档和资源链接一定要放进去：

• FAQ，为了防止遗漏了用户最关心的问题，首页要加一个15个问题以内的FAQ
• 用户信任相关的资源链接，用全套专业材料证明这是一个靠谱的技术产品：
  • 稳定性相关的：比如可用性指标，Status Page、服务水平协议(SLA)
  • 安全合规相关的：安全白皮书、合规相关证明、SBOM和许可证清单
  • 性能相关的：Benchmark测试结果，最好是和竞品对比的

🚀行动建议7：在这份Overview提纲的基础上，调整成你的文档首页。

在用户恰好要用时，让文档冒出来 ​

有了独立的文档网站，但对用户来说还不够。以用户为中心的文档设计，还要尽量避免用户的上下文切换。因此，应该尽量用推送而非拉取的方式，在恰好的时机，把用户刚好需要的文档呈现出来。

有不少B2B的复杂SaaS产品，比如Permit.io、Cloudflare，都大量运用了交互式文档，在把文档融入产品功能中，让文档找用户，而不是用户找文档。

🚀行动建议8：对于学习曲线较平的功能，把介绍视频、富文本内容直接做到功能中，用漫游式引导(Product Tour)放到产品中，吸引用户注意力，让用户自行探索。

除了文档功能化，另一个方案是开发Playground，作为产品的一部分。Playground或者更复杂一些的Hands-on Lab，不仅可以作为产品端到端测试的载体，更大的意义是提升用户尝试的信心、降低学习门槛。比如Cloudflare Workers Playground，体验过的都会被震惊到。

🚀行动建议9：对于学习曲线较陡、或操作风险较高的功能，尽量把Tutorial内容维护在可交互的Playground中，并在产品内加上Playground链接。切记不要重复造轮子，目前最简洁的前端内嵌Playground方案是CodeSandbox Sandpack；如果场景更复杂，需要独立VM的Playground，买个Instruqt这种专门做Hands-on lab的服务；甚至还可以搭配Skill Jar这类TMS产品，构建一个在线的“XX学院”，能跟踪用户的学习进度、还能用证书奖励促进学习动机。

哪些“文档”不该放？ ​

除了Diátaxis框架提到的文档类型，我们还经常写一些其他“文档”，比如：Roadmap、ReleaseNotes、Newsletter、Ecosystem/Integrations。很多人也把这些“文档”放进产品文档了，而这些其实都不该放。

为什么呢？我们一个一个看。

我们仍然从目的论出发，想想Roadmap、Release Notes、Newsletter的目的和阅读场景是什么？这三类内容，都是发给那些对产品感兴趣的人的“信件”、“公告”，是结构化沟通的渠道。

Roadmap是为了提升产品研发的透明度、给用户适当的预期、甚至让用户投票参与决策；Release Notes是为了让用户了解和体验新功能；Newsletter则兼具维持透明度和营销两种目的。

可以发现，这类内容不涉及技术细节，但对内容吸引力、订阅群体管理、用户反馈的要求非常高。因此，要有一个专门的SaaS来管理这些内容，提供用户管理、内容营销的工作流闭环，这几种内容的深层含义，远比“定期写个文档丢到网站上”要复杂。

🚀行动建议10：不要把Roadmap和Release Notes放到文档站点中，它们不是技术文档，而是一类需要独立解决的客户沟通问题，市面上有很多产品可以选，比如：Canny、Changelogfy、ReleaseNotes.io、FeatureOS。但有个特例是，非兼容版本更新产生的Migration Guides，属于How-to Guides的一种，应该放到文档站点。

而Ecosystem/Integrations这些文档内容，背后的含义是什么呢？

一般扩展性比较好的技术产品、尤其是平台型产品，会留足扩展点，让用户参与开发，共同构建生态。这些用户贡献的Integrations，也要有使用文档，那这些内容放哪里呢？

简单的方案是，每当生态中增加一个Integration，就手动维护到主文档站点里面。但这样没有解耦产品维护者和生态贡献者，不符合关注点分离原则。因此，更好的做法是，构建一个Marketplace的数据库管理Integrations，扩展点开发者把文档和代码打包到一起，每次修改发布到Marketplace。

下面两张图，左边是Prometheus的Integrations、右边是Sanity的Integrations，哪个更好一目了然。

🚀行动建议11：除了产品的技术文档本身，其他内容一概不应该在文档中维护。找一个类似Sanity的结构化CMS来管理Integrations、Teams、Products这些内容，不要直接放到产品文档里，这些都应该是Header或Footer中的资源链接。

写好技术文档的7条原则 ​

有了对信息架构的理解，我们再看具体怎么写。这里介绍7条技术文档的写作原则，一部分内容来自布兰德·罗伊尔的《一本小小的红色写作书》。

这里取其精华、再结合我的实践和延伸思考，总结了7条技术文档写作的核心原则，以及相应的行动建议。

1. “面对面”原则
2. 零知识假设原则
3. 金字塔原则
4. “海明威”原则
5. 结构化优先原则
6. 多媒体优先原则
7. 迭代原则

1. “面对面”原则 ​

“面对面”原则，就是时时刻刻想象你的对面，坐着一群读者，读者们有不同的角色，你在和他们一个一个的、有目的地沟通。有了这种对象感，会对技术有更本质的思考，你开发的技术产品，用户价值是什么？在更大的价值链中的定位是什么？。

这也是培养“以终为始”思维的一种方式，和亚马逊创始人贝佐斯提出的“逆向工作法”类似，先从“解决什么问题”出发、从FAQ开始构建一个产品。

🚀行动建议12：买几只小黄鸭放在屏幕旁边，想象他们是就是你的用户，和Ta默默对话，然后把“对话内容”转成书面语，一定是一篇好文档。和小黄鸭Debug法类似，小黄鸭写作法也有奇效。

2. 零知识假设原则 ​

借用社会学概念，零知识假设原则也可以叫无知之幕。用在写文档方面，就是假设你对面坐的读者，对这个产品一无所知。因此每写一个名词、动词，都要掂量一下Ta能不能理解。有没有上下文的解释？概念会不会被曲解？抽象程度是不是过高了不易理解？

🚀行动建议13：找一个没有任何知识背景的小白来读文档，让Ta告诉你哪里看不懂。换位思考能力比较强的，可以把自己想象成这个小白。对于潜在的看不懂的地方，分成上文、下文两部分，对于上文，找到解释材料，放到当前文档的“Prerequisites/Background”中；对于下文，把相关文档的链接放到末尾的“Next Steps”中。

3. 金字塔原则 ​

金字塔原则，简单理解是“结论先行”，这是《金字塔原理》的核心论点：一定要把关键结论放前面，解释和支持结论的论点放后面，自下而上思考、自上而下表达。

其实这篇文章就遵循了金字塔原则，开篇提出文档的重要性后，立刻总结了全文：一个理论、7条原则、21条行动建议，再展开阐述每个部分。

🚀行动建议14：以TL;DR（Too long, don't read）风格开头，先写塔尖的全文总结、再往塔底下展开详细内容，确保只读了第一段的用户，也能了解全文大意。

4. “海明威”原则 ​

作家海明威的文风简洁明快、干净利落。商务写作、技术写作非常适合用“海明威体”。那么，怎么训练这种文风呢？有3个关键点：

• 避免长句
• 少用副词，多用精确的动词
• 主动语态

🚀行动建议15：用下面这段“海明威体AI提示词”，跟着AI老师训练一段时间，自己的文风就会干练很多。

You are professional tech docs writer, think Hemingway writing style and high quality tech doc factors, carefully review and modify the content, to align with Hemingway style and other writing best practices, fix spelling and grammar issues at the same time.
Input is markdown. Output should be 4 parts:
1. Overall score(0-100) of original content
2. The changed sentences diff
3. Final modified markdown
4. Overall score(0-100) of modified contents.

5. 结构化优先原则 ​

列表、表格、图表这些形式，都是结构化内容的载体，多多益善。结构化的背后是深思熟虑、用强空间结构表达关键论点和问题本质。这篇文章就是强列表体的体现。

这三种形式有什么区别，在什么场景用呢？

• 单维度并列关系的信息、树状结构的信息，用列表体；
• 复杂的多维度信息，别用大片文字描述，直接上表格；
• 用来支持结论的分析类信息、尤其是数字、矩阵、时序相关的，选择恰当的图表。

🚀行动建议16：找一些写过的文档，尝试把三分之一以上的内容全部改成列表、表格、图表。Markdown图表表格语法不熟练的话，用Mermaid、TableConvert 这类工具先练一练。

6. 多媒体优先原则 ​

多媒体可以调用多个感官，让用户进入多模态学习状态，是快速构建认知的捷径。有条件制作多媒体内容的，优先展示视频、动画这些内容形式。

另外，在文档中穿插一些紧扣主题的截屏、图片，也能帮助用户更快理解复杂的技术概念。

🚀行动建议17：用ZOOM、Loom、Kap 、Asciinema这些能录制屏幕或命令行的工具，搭配CapCut剪辑配音工具，把最关键的几个教程，制作成3分钟以内的演示视频, 封面直接用主题大字，放到对应文档的开头。

7. 迭代原则 ​

迭代原则有两层含义，一是发布前反复审阅修改，二是在整个产品生命周期保持文档更新。

科普作家游时猷曾说：“写文要快，改文要慢，查资料要适可而止。” 技术文档专业性、准确性、易用性要求都比较高，每篇文档至少要复审、迭代3遍才能发布。

除了发布版本的多次迭代，长期持续迭代一样重要。Diátaxis推崇随时随地，自内而外、自下而上逐步改进文档的方法，就像植物生长一样。如果不长期投入精力，随着产品本身的迭代，文档一定会逐渐腐化，失去生命力。

Consider a plant. As a living, growing organism, a plant is never finished. -- Diátaxis

🚀行动建议18：给文档站点加上评论、点赞等反馈渠道。每当收到用户反馈的通知时、或者自己阅读发现问题时，把要改的地方记到当日的Todo，尽量在当周内改完。

除了随时随地的维护，搭配周期性的检查、测试才能形成文档管理的闭环。文档负责人打好节拍，定期组织文档Review，一起修补、互相测试文档。

🚀行动建议19：每季度或者半年举办“Docathon”活动，专门用来测试、审核、改进现有的文档。设一些小奖品，奖励发现问题最多的人、改进文档最多的人。

高效写作工具箱 ​

理解了方法论和写作原则，在真正写技术文档之前，还要看下有没有配备一套趁手的工具箱。这里介绍三类提效工具：

1. 基础写作套件
2. AI工具箱
3. 模板库和示例

基础写作套件 ​

写作格式方面，Markdown是不二之选，功能全面、使用简单、生态丰富。我所有的文档、文章都是Markdown语法写的。

Markdown编辑器，IDE自带的已经足够了，我也试过各种花里胡哨的Markdown编辑器，最终回归了直接写Markdown语法的朴素方式。

写作平台方面，对于于技术人员来说，IDE first是效率最高的方式，没有什么是VSCode+一揽子插件搞不定的，有几个常用的插件：

• Mermaid，代码画图工具，Markdown All in One插件 已经内置支持
• Markdown Table，辅助表格编辑和格式化。
• Spell Checker 单词拼写检查
• Code Snap 代码片段截图
• Markdown Image 粘贴图片自动上传图床
• ImageMin 图片压缩

IDE first最大的优势是，哪怕是复杂到要在文档中穿插交互组件时，配上MDX也能在IDE中轻松解决。结合Git自动化流水线，写作、发布全程甚至不用点一次鼠标。

辅助写作的工具方面，WantWords反向词典是一个好用的词汇工具、VSCode Google Translate能Alt+Shift+T一键翻译。剩下的辅助写作需求，都交给AI + Prompt Engineering吧。

AI工具箱 ​

技术文档有复杂的产品业务背景，不能全部交给AI生成。人工和AI互相配合，效率和质量都能有一些提升。

写作是人类最基础的表达能力，借力AI，不断精进写作能力才是正道，驾驭好AI工具非常关键。

现在市面上有两类AI产品，一类是基于RAG（增强检索生成）偏向语义搜索的AI；另一类是直接用大模型生成内容的AI。我的经验是取长补短，结合两类工具一起用。

• 用ChatGPT、Kimi、Gemini、Claude这类纯生成类AI，用来协助构建整体结构的脑图、修改语法和拼写错误、自动翻译多语言
• 用 Peplexity AI、秘塔搜 这类基于RAG的AI，协助引用专业资料，生成高质量的片段
• 在写完整个文档网站后，有条件尽量配置一个语义搜索的AI，市面上有大量开源和商业产品可以选，比如 Algolia、Meilisearch。

🚀行动建议20：磨刀不误砍柴工，写下一个文档之前，审视一下自己的工具箱，找到有效率问题的地方，比如 要在写作平台外手动处理的事情、可以用AI代替和增强的事情，列出一个效率改进计划逐步优化。

模板库和参考示例 ​

VitePress Diátaxis Template ​

我用Vitepress做了一个文档站点模板，把很多最佳实践融入到模板里了，如果觉得还不错，Star/Fork模板仓库，创建自己的文档站点吧。

Fern ​

除了开源项目，也有一些专注文档领域的商业产品，我觉得目前把SDK+Docs生成做到极致的是Fern，不需要太多定制、不差钱可以试试Fern。

优秀文档站点案例 ​

下面是最近发现的几个优秀技术文档站，都恰到好处的分离了不同读者视角的关注点、文档结构清晰、遵循了技术写作的最佳实践，值得阅读借鉴。

• Cloudflare Vectorize Docs
• Port IDP Docs
• Restate Docs

🚀行动建议21：多读优秀的技术文档，学习他们的信息结构、内容风格。学到好的做法后，立刻在自己的文档上实践应用，再让AI给自己修改前后的内容打分评价，不断精进写作能力。

总结 ​

好的技术文档都是相似的，能让读者 一眼找到、读得下去、立刻能用。达成这个目标不简单，需要掌握正确的方法，长期刻意练习。

通过这篇长文，我们系统性介绍了Diátaxis文档方法论、7条对写好技术文档至关重要的写作原则，最后简单介绍了高效写作的工具箱、示例和模板。

除了这些方法、原则、工具，还有21条行动建议穿插全文，拿来就能用。每一条建议背后，都有我亲身体会过的深刻教训。

Build a living, breathing guide. -- Write the docs

工作 ​

工作方面，大部分时间花在沟通上，个人发展路线从偏技术转向了偏产品。主要聚焦在公司的基建改进、平台工程上，推动已经完成0-10构建过程的云平台，在全公司范围从10-100渐进落地，细节不便展开了。

去年工作中用了一些工具，回头看对效能提升挺有帮助的：

1. Warp：AI加持的命令行工具
2. Arc：设计出色的新兴浏览器
3. OrbStack：无需虚拟机的本地Docker+Kubernetes
4. Sider：以及各类AI助手，Sider这个浏览器插件用的最多
5. Gamma：AI加持的Docs to Slides，用户体验极好

学习 ​

去年的学习领域偏管理学、系统性思维。能力发展的重点放在分析、评估、创造这些二阶思维。

管理学 ​

读了一些管理学相关的好书：

• 《决断：成功的领导者怎样做出伟大的决断》-- Warren G. Bennis, Noel M. Tichy
• 《信任的速度》-- Stephen M.R. Covey
• 《相变》-- Safi Bahcall
• 《回头客战略》-- 谢家华
• 《卓有成效的管理者》-- Peter F. Drucker
• 《The Culture Map》-- Erin Meyer

技术 ​

技术方面，看到张晋涛参与翻译的Alex Hidalgo新书《SLO与SLI:软件可靠性实践指南》出版了，买了纸质的精读了两遍，和平台工程的工作强相关，一些启发已经运用到产品设计中了。

前端方面，React稍微更熟了一些，代码写的不多。另外在新项目试用了Nuxt，开发体验确实很舒服，以后小东西可以都用Nuxt/Vitepress一把梭。

Rust入门学习资料二刷，不过实践场景比较少，目前仍然只能勉强看懂别人的代码，上项目还差远。

去年Star了180多个开源项目，回过头看，下面这些项目值得长期关注，对Web领域、SaaS行业开发者很有应用价值。

Serverless方向

• Supabase Edge Runtime
• Extism

AI方向

• AI Gateway
• LM Studio
• HuggingFace上每天冒出来的新的AI Models

前端方向

• ZagJS Headless UI
• Shadcn UI

后端方向

• Drizzle ORM

大数据方向

• Materialize
• Databend

基建、平台类

• Sanity Headless CMS
• PostHog
• Backstage IDP
• Signoz Observability Platform

其他 ​

通识课方面，得到App的订阅课程，相比前几年少了很多，去年只订阅了《万维钢精英日课》。万sir讲AI的课程挺激动人心的，不过从业内视角看，对AI的落地有点过于乐观了。

剩下的就是更“无用”的书了，有本朋友推荐的《随风去野》挺有意思的，以漫画的形式讲了自行车环游中国的经历，其余的没什么推荐了。

分享 ​

我一直践行的理念是教学相长，输出就是最好的输入。

今年，在团队内部组织了两轮系列分享，其中我自己讲了两个管理学相关的话题。

一次是用卖水果罐头的经历讲营销管理，另一次是讲时间管理。

在公司范围，组织了一次参加AWS Summit回来后的分享。

我在AWS Summit主要听了安全合规方面的讲座，回来补个课在公司二次分享。其实在日常编程语言外，还有一些小众语言和框架，比如Dafny、Coq、Boogie，对实现可证明安全意义重大。那次在公司分享的比较浅，以后有时间可以写篇技术博客讲形式化验证。

除了这些正式分享活动之外，还有两次工作相关的。

一次是给我们平台用户的K8S入门培训，对比5年前，现在能用更通俗的语言给别人解释K8S、云原生，说明理解加深了。

另一次是UX设计入门分享，了解UX设计，对产品、前后端工程师都有意义。

除了演讲分享，博客沉淀了5篇：

• 如何理解工程师的跨文化差异 -- 从个人经验出发，尝试总结中美印工程师的文化差异
• 30分钟了解Kubernetes -- 从旧的K8S知识找到一些新的理解
• 软件项目怎么做好技术方案选型? -- 悟了个浅显的研发类型矩阵
• 怎样构建卓越研发团队
• 用6阶导数解构企业经营 -- 用数学思维理解企业经营本质

生活 ​

生活上没有太大变化，享受平凡的幸福。孩子长大了，几个假期和家人去周边逛了逛，跑了6个地方：常州、长沙、杭州、苏州、青岛、霍山。

还有一些珍贵的回忆，就在附近。一次是和娃在幼儿园表演绘本故事《猜猜我有多爱你》，另一次是幼儿园组织去农场，跟老婆孩子体验了挖芋头的快乐。

结语 ​

去年是自我革新关键的一年，多数时间挺焦虑的，还好有家人、朋友、同事的的支持，留下了许多美好回忆，也沉淀了不少知识。

总结23年的关键词：焦虑，转型，自我认知。

展望24年的关键词，希望是：行动，行动，行动。

企业是什么 ​

去年听一个咨询机构的公开课，讲到组成企业的“四梁八柱”，屋顶是使命、战略、价值观，柱子是产品、营销、运营、投融资，地基是管理、人才、趋势。

用房子比喻企业经营非常形象，那能不能用稍微严谨些的数学模型来表达呢？

这篇文章分享从理论角度对企业经营的思考。

企业是一棵树 ​

我们把企业想象成一棵长果子的树，促成一颗树结果子的，有阳光、雨露这些外部因素，有树本身的结构，树叶、树枝、树杈、树干、土壤、树根。

那促成企业之树产生“利润果实”的是什么呢？我思考了很久，发现组成企业的元素和一棵树的元素，是这样对应的：

• 财务利润 -- 果实
• 业务 -- 树叶
• 组织、流程、系统 -- 树枝
• 战略 -- 树杈
• 使命、愿景 -- 树干
• 企业文化、价值观 -- 土壤
• 人 -- 树根

为什么要这样对应呢？乍一看不太合理：

• 战略、使命、愿景这些“很虚”的东西竟然是树干？
• 企业文化、价值观这些“更虚”的东西竟然是土壤？
• 企业人员流动频繁，人竟然是树根？

带着这些疑问，我们一步步抽丝剥茧，解构企业经营的本质。

企业的“导数” ​

“导数”是微积分的基本概念，其几何意义是函数的切线斜率，现实意义，即函数变化的原因。

比如驾驶一辆车，加速度“导致”了速度，加速度是速度的一阶导。踩油门的力度又“导致”了加速度的变化，踩油门的力度就是加速度的一阶导，速度的二阶导，行驶距离的三阶导。

再举个例子，在经济学、企业管理领域，边际(Margin)这个词用的很多，边际成本、边际利润、边际贡献... "边际"其实就是导数换一种说法，边际成本可以理解为“每多生产一件产品，要多付出的单位成本”。因此，边际成本，就是总成本变化的原因，也就是成本的导数。

导数思维，就是一层一层追问Why，理解事物之间的因果关系。

因此，我们从财务结果出发，求导问Why，一直溯源下去，就能找到企业经营的本质。

为什么有财务结果？ ​

一阶导：业务 ​

第一阶导数显而易见，有财务结果是因为有客户购买企业的产品和服务。

从企业内部看，能赚钱是因为企业有业务，这些业务产生了客户能购买的产品和服务。

企业经营的一阶导，是业务。

二阶导：组织结构、流程、系统 ​

再问一层，客户为啥要买你的业务呢？

买东西只有一个理由：值得买。

客户有很多问题要解决，这些问题就是痛点、痒点。企业看到了，就把解决这些问题的方案，包装成产品和服务。

而业务，就是生产、销售这些产品和服务的过程。

业务能在多大程度上解决掉客户的问题，带给客户的感知价值有多少，就导致了多少购买行为。

从企业内部看，业务是什么呢？

生产、销售的业务流水线像一台机器，那么这台机器是怎么构成的呢？

凑近了看，组成企业，让企业能够产生业务的，是组织结构、流程、系统。

越大的企业，要解决客户的问题越多，就要求这台机器越复杂，管理学的大多数内容都在这一层。

比如，怎么管理组织内的信息沟通、知识传播？用哪些方法激励员工？组织架构是职能式、矩阵式、还是阿米巴式？怎么让生产线更加多快好省？销售的每个环节怎么提升转化率？

每一个组织结构、流程、系统，都是在定义、调优企业这台机器的零部件和零部件的装配关系，让“价值”生产出来。

客户往这台机器输入一个问题，就输出一个答案。从输入到输出价值增加的过程，形成了一条价值流，也是一条业务流。

因此，企业经营的二阶导，是这台“机器”的组成，也就是组织结构、流程、系统。

三阶导：战略 ​

为什么会不同企业的组织结构、流程、系统各不相同呢？

因为他们选择的问题域不同。选择了解决这一类问题，而不是那一类问题，这种选择，导致了企业必然要演化出与问题相匹配的组织结构、流程、系统。

那么问题也就转换成，“为什么企业要做不同的问题域选择呢”？

因为企业的经营者，看到了或者预测出市场会出现一些普遍的需求，企业会结合内部拥有的资源和能力，评估自己的优势和劣势，再分析外部的机会和威胁，权衡风险和收益，做出了战略选择。

一旦做出了战略选择，执行战略的过程，必然要动组织结构，进而影响到系统、流程、工具，让企业这台机器，生产出不一样的业务。

就像一棵树移栽后，太阳的位置变了，这颗树必然会抑制背阴的一面，把营养供给向阳的一面，长出新的树杈、树枝、树叶，结出新的果实。

因此，企业经营的三阶导，是战略。

四阶导：使命、愿景 ​

继续深挖，为什么有这样的战略呢？

是选择突出差异化，还是成本领先？是聚焦，还是多元化？

战略决策，是咨询机构和经营者开会讨论出来的么？是由SWOT分析、五力模型这些理论决定的么？

这些都是工具和方法论，而不是深层原因。

深层原因仍要看市场，看企业选择了哪个行业。

一旦行业领域确定了，这个行业的发展阶段和趋势就能分析出来。可以推导这个行业，出有哪些使命有待完成。

有了行业发展阶段和趋势，战略选择时要关注的行业关键挑战、细分市场上客户有哪些、供应商有哪些、替代品、当前和潜在的竞品，这些答案自然浮出水面了。

也就是说，选择或放弃某个或某类行业时，就是选择或放弃了这个领域对应的使命和愿景，也注定了长期有哪些可能的战略有机会选择。

因此，企业经营的四阶导，是使命和愿景。

五阶导：企业文化、价值观 ​

继续问，为什么有这样的使命和愿景呢？

我的思考是企业文化和价值观。

一些经营者会说，“我们在战略转型期，升级了使命和愿景，因此，要发展对应的企业文化，优化价值观”。这犯了一个因果倒置的错误，实际上，如果没有文化、价值观、意识层面的引导和宣贯，做任何重大变革都会阻力重重。

企业文化不是口号，而是一种既定事实。同样，价值观也不是标语，而是判断决策质量的最后一把尺子。

组成企业的人携带的文化和价值观的总和，就是企业的文化、价值观。这些文化和价值观的源头来自创始团队，像公司的基因。

No companies have a culture, but every company is a Culture -- Peter Thiel

带着这层理解，不难得出：是当前的企业文化、价值观，度量、约束，甚至决定着企业使命和愿景的定义。

举个例子，微软CEO纳德拉上任时第一件事，不是改写愿景、使命，和高管们商量战略，而是给所有经理层布置作业读《非暴力沟通》、向全体员工致信鼓励创新。投入巨大的精力，做企业文化变革。

文化和价值观层面的变革是第一件事，然后再传递到Cloud-first这类战略层面的变革。

因此，企业经营的五阶导，是企业文化和价值观。

六阶导：人 ​

为什么有这样的企业文化和价值观呢？在上一节的分析已经给出答案了。

人，带着自己的价值观加入企业，融入、生长，成为企业文化和价值观的一部分。

企业经营的六阶导，也是企业之根本，是人。

六阶导数模型对企业经营的启发 ​

推导出这个模型，对企业实际经营有什么作用呢？我们从4个方面展开说明。

1. 导数是强因果 ​

上下几层之间应该有序联动。上一层要在下一层之前动，反向动或者下一层不跟着动，必出问题。

比如，企业要做战略变革，正常路径是战略先动、组织架构再动、最终推动业务层动。

如果没有对应的组织架构重组，就像树上长一个新树杈，无枝、无叶，必然凋零。

如果战略调整范围更大，触及到使命和愿景层面的修正了，这时千万不能着急执行，而是要让企业高层重新审视“公司是什么，想要成为什么”这个问题了。

为什么必须联动呢？反向思考，一旦新的战略地图无法呼应公司的使命和愿景，那很可能会造成基层员工的迷茫、高层的决策冲突。

强因果的另一个启发是，对于高层管理者，要把力气花在四两拨千斤的高阶导数上，事半功倍。CEO要是盯着业务的螺丝钉搞“微管理”，会导致低阶导数的失衡。

2. 每一阶导数应该以什么频率变革 ​

在Vuka时代，社会和市场在极快发展，要求企业从微观到宏观层面适应变化。

持续变革，是企业生长的节奏和脉搏，有脉搏才能生存下去。

导数阶数越低，受影响的因素越多，变动频率应该越高；反之，越高阶的层级，影响面越广，变动频率应该越低。

举个例子，从我工作过的公司看，改变业务、组织、流程是按月计的，改变战略是3到5年计的，改变使命、愿景、文化、价值观、核心员工是5到10年计的。

越低层级的导数，代表越具体、越细节的知识的变化，更新越快说明企业的沉淀和成长更快，越能适应快速变化的市场环境；

越高层级的导数，代表着越大范围的共识，而达成新的共识的成本越高。

3. 高阶导数的滞后效应 ​

现实世界有一个永恒的时间变量，当高阶导数变化时，变化需要时间、资源把信息传递到下一层。

因此，所有层级之间的级联变化，都是有滞后效应的。

比如，今天为了解决生产质量问题，调整的组织结构和质量控制的流程，可能下个月才会体现到产品上，半年后才会对财务结果有正向影响。

而到企业文化、组织战略这种层面的变革，甚至要两三年才能传导到财务结果。

经营者理解了这个推论，就不会容易急功近利，有的项目就是长期的，难以量化的，但必不可少。

举个例子，对于稍微大一些的企业，会思考企业文化建设、员工培训和发展计划这些高阶导数的问题。很多急功近利的做法是找个毕业生立刻就做，做了一个月领导就要结果。

实际上这类工作，不仅要非常有经验的、能够理解和践行长期主义的专业人士才，还要足够的时间，复利效应才能体现出来。

4. 沟通是不同阶导数的传导介质 ​

上一个推论是导数之间的滞后效应，那么，有没有办法减轻这种滞后，让企业经营和变革的速度更快呢？

为什么一些中小型企业变革那么快，一些大型企业积重难返？

这里的关键，就是不同阶导数之间的传导介质，即沟通。

有的小公司员工身兼数职，沟通成本几乎能忽略不计；有的大公司一个讨论要几周时间才能落地，差距就在沟通效率上。

大公司病，表象是“部门墙”、“躺平”、“推诿”，这些是表象，关键根因之一，是员工超过150邓巴数后，落下的沟通病。

怎么解决呢？我们先看每一阶导数，背后的知识或共识是什么。

• 文化和价值观：价值共识
• 使命和愿景：远景共识
• 战略：目标共识
• 组织、流程、系统：组织知识
• 业务：领域知识

前三个是共识，要让公司所有人都理解和认同的。

提升这几层的传导速度，必须建立全员广播+跨层级反馈的沟通机制。比如定期组织 All hands, town hall会议，透明开放的与全员沟通；定期的企业文化、战略解读；建立有效的直通高层的反馈渠道等等。

后两个是知识，要让相关业务的人快速获取和演进。

提升这几层传导速度，必须建立共享+共创的沟通机制。比如维护公开及时准确的组织架构信息；鼓励业务知识库的积累和维护；用好实时协作文档系统、IM系统、在线会议系统，让公司任意一组人能快速发现问题、做决策、解决问题。

总之，大公司要做到“大象跳舞”，必须要有一套完善的沟通架构，引导共识、传递知识、分享信息、获取反馈，让不同阶导数之间的传导效率产生质变。

总结 ​

本篇记录了我对企业经营的抽象思考，企业与树类一样，远看是果、叶，近看是枝、干，深看是根、土。

首先，给出了企业经营中的关键概念、概念之间的导数关系，

然后，通过逻辑分析，一步步推导出六阶导数模型，

最后，我们从每阶导数的因果联动、变革频率、滞后性、信息属性4个方面，展开分析了导数模型对企业经营有哪些现实意义。

不抽象，就无法深入思考，不还原，就看不到本来面目。 -- 刘润

目录 ​

卓越研发的标尺 ​

两年前开始做平台工程，一方面大量基建问题堆积如山，必须快速迭代；另一方面，平台工程是飞行中换引擎，质量、安全性都有很高要求。项目开始时，而团队经验并不丰富、资源有限，很多地方做的不到位，因此，只有不断提升整体水平，成长为一个卓越的研发团队，才能真正解决问题。

那么，哪些是卓越研发团队的关键特质？我一直在思考这个问题。

在去年读的书中，有三本书触动很深：

• 《决断：成功的领导者怎样做出伟大的决断》-- Warren G. Bennis, Noel M. Tichy
• 《信任的速度》-- Stephen M.R. Covey
• 《相变》-- Safi Bahcall

在这三本书中，我找到了卓越研发团队的三把标尺 —— 产品力、执行力、创造力。

为什么是这三个特质？在人和组织层面，如何培育这些特质呢？

下面，我们从每本书的核心内容出发，结合真实案例逐个分析解答。

《决断》-- 明确战略目标是提升产品力的前提 ​

《决断》的作者沃伦•本尼斯、诺埃尔•蒂奇，是两位领导力理论的先驱。全书首先明确了决断的定义和框架，再讲述了世界顶级CEO的决断案例，包括通用电气、宝洁、百胜、波音这些家喻户晓的公司，最后点出“传统决策”和“决断”的差异，上升到理论高度进行总结。

这本书副标题原文是：“How winning leaders make great calls”，但并不是只有领导者才能看，任何人去读，都能在这些CEO生动的故事中得到启发，提升格局和领导力。

书中有成功的也有失败的案例，总体分成三类：人的决断、战略决断、危机决断，前后两种决断更多是领导力范畴，这里我们重点看中间的：战略决断。

韦尔奇与伊梅尔特的战略决断 ​

韦尔奇在1981年成为通用电气CEO之后，解雇了200多名战略规划师，他说："领导者需要拥有自己的战略，而不是官僚作风的参谋"。通过清晰的战略决断、对组织的精简、发挥人才潜力，韦尔奇在任期内，将通用电气的9个事业部做到了世界500强、市场价值增长30多倍。

他的接班人杰夫·伊梅尔特，也继续战略决断的故事主线，通过对市场需求和企业能力的精确理解，不断寻找最佳方向，不断重组、转型，续写了通用电气的传奇，连续保持了10%的高增长。

时至今日，这家百年企业虽然不再有千禧年前的风光，但从近年来重组为航天、医疗、能源三个公司、卖掉家电这些资产的动向，仍然可以看到清晰的战略方向。

战略与产品力的关系 ​

那么，回到软件研发领域，为什么战略决断对研发团队的每个人都很重要呢？

软件研发是知识密集型劳动，不确定性高，产出难以量化。越复杂的软件项目，模块级别的产品负责人、工程师掌握越多的业务信息。信息是一切决策的前提，因此，研发团队的权力结构通常是自下而上的，模块级别的负责人既影响战略方向制定，也是战略落地的关键执行单元。

一旦底层决策与整个产品的战略目标偏移，必然导致大量资源浪费、形成不了合力，这也是不同研发团队效能相差十倍甚至百倍的关键原因。方向错了，其他一切都毫无意义。

所以，研发团队的每个人，特别是产品负责人，都要学习杰克·韦尔奇、杰夫·伊梅尔特那样的战略意识，要有对外部趋势、市场的准确把握，还要有对自身优势、劣势的精确理解。战略的理解和决断能力具备了，再去躬身前往细节世界，理解一个个具体用户的痛点、提炼需求，用软件模型去表达真实场景的普遍问题，最后回到宏观战略目标做减法、找增量，汇集力量把一个个阶段性目标打穿。

产品力 = (对战略目标的理解 x 对用户的理解) x 建模表达能力

怎么在实践中提升产品力 ​

在项目中，我们也一直在实践和改进，和组员做1:1沟通时，我最喜欢探讨的一个问题就是：“如果你是整个产品的负责人/公司的CEO，你会做哪几年事情，未来几年的你觉得方向应该是什么？”，每次讨论都有不同的收获，经过多轮自下而上、自上而下的沟通和决策，我们所负责的平台产品，其战略方向的故事主线越来越清晰，用《决断》中的定义就是一个包括了想法、价值观、锐气的“Teachable point of view” (TPOV)。

另外，在每季度确定下阶段排哪些任务之前，我会组织团队头脑风暴，对需求列表逐个问两个问题：

1. 这件事与我们大目标的匹配度可以打几分？
2. 换到用户角度思考，这件事对用户的重要性有几分？

当大家给出量化的评分时，自然会从各种角度想到“这件事重要或不重要”的关键原因，让每个需求有了是否要做减法的依据，也完善了每个需求对应的用户故事。这个过程会花很多时间讨论、思考，搞清楚每件事在战略地图中的位置、每个人在价值链中的意义，看起来慢，实则通过产品力的磨炼，来减少大量返工和无效工作，是非常划算的。

越大的项目，越要谋定而后动，“Think Slow, Act Fast”。

几个季度执行下来，能明显感到大家的产品力提高了。很多同事不再会只从自己的技术思维出发，简单的说“我想做一个XXX”，而是能自主做出“哪些需求不该做”、“哪些核心功能中用户仍然有痛点需要改进”的决断，真正把战略目标和用户痛点一起刻到了岩石上。

《信任的速度》-- 有信任才有执行力 ​

对信任的解构 ​

《信任的速度》是我司CEO Eric S. Yuan在全员大会上，推荐所有人看的三本书之一。作者史蒂芬·科维还写过另一本传播更广泛的《高效能人士的七个习惯》，读这类畅销书中的经典，要有一些阅历才能深刻体会，否则很容易认为只是心灵鸡汤。《信任的速度》把“信任”这个看似简单的概念解构的很彻底，首先定义了构建信任的积木：信用（Credit）。信用具体指什么呢？有四个核心要素：

• 诚实：基本的道德要求
• 动机：关心共同利益而非私利
• 能力：具备兑现承诺的天赋、态度、技能、知识
• 成果：已经实现过的承诺

与广义上的“信一个人的人品”不同，信用的要素包括能力与成果，就像一个人品再好的老师也没办法去给病人做手术、一个刚还没毕业的医生也没办法让病人信任其医术。

其次，作者从影响圈范围的角度，把信任分为五个层次，讲解了构建每一层信任的方法论和必要的行为：

• 自我的信任
• 关系的信任
• 组织的信任
• 市场的信任
• 社会的信任

每一层信任的递进，都会带来指数级的效率提升，形成改变世界的力量。反之，没有信任这块人类文明的基石，一切沟通协作都无从谈起。

一个跨四时区临时团队的故事 ​

2021年底，在我的直属经理支持下，打算开始做公司级别的平台工程，那时我的本职是微服务开发框架的架构工作，自己团队内只有一位研发能抽出时间，无法完成这么大的工程。本着“人多力量大”的朴素想法，我去找了所有利益相关方，正好有几个团队也非常想解决缺乏基建平台、十几条业务线各自为战、职能部门孤岛这些阻碍业务发展的系统性问题，我们临时组建了一个跨中美印的四个时区和文化的虚拟团队。

很快，由于对目标的理解、工作方式不同，前两个月就在设计和技术选型就上产生了不少冲突，项目推进缓慢。

好在上层出面及时帮助做了目标纠偏，方向上达成了一致。具体到每个模块，我和另外一位项目发起人，靠着一次一次组织同时区的、跨时区的会议、不断讨论直到达成共识的“蛮力”，推进产品研发。

半年后平台产品发布，我把之前在做微服务框架时积累的内部客户，转换成了平台的首批用户，一个“反馈-改进”的增强回路搭建出来了。

磨合一年后，每个模块的关键贡献者不言自明，随着信任关系的不断强化，职责和分工越来越明确。一周一个迭代的快速改进，让用户对我们的信任也逐渐增强，同时，我们也尽可能让项目的决策过程和进度对所有人透明公开。

没有哪个团队刚组建就能互相高度信任，经过了太多曲折，现在回顾这个故事，很多地方本可以做的更好。

两年后，公司大部分业务线、超过400个服务组件，已经迁移到了我们构建的标准化运维平台、计算平台。这些结果传递到高层，形成对平台工程大方向的信任，又间接促成了多个部门的组织架构调整。

这就是信任飞轮带来的执行力。

塔克曼团队发展模型 ​

前不久学到了塔克曼团队发展阶段模型，发现上面这段经历完美符合了理论模型。塔克曼论述了团队发展必然经过 Forming, Storming, Norming, Performing这4个阶段。塔克曼这篇1965年的16页论文，是组织发展理论的开山之作。模型论述了团队的整体效能是一条微笑曲线，在Storming结束前，效能逐渐下降，而只要渡过了Storming阶段，效能会稳步上升，最终达到高效能状态。

从信任的角度看，团队的效能和执行力，与内部信任程度正相关。

• 刚开始团队被共同目标组织起来的时候，团队成员互相不熟悉，有一个薄弱的信任基础和沟通距离，因此在Forming阶段通常呈现出“假和谐”；
• 随着各种分歧的出现和积累，信任逐渐降低到冰点，士气低落，就标志着Storming阶段来了，多数失败的、名存实亡的项目和创业公司，就是倒在了Storming阶段；
• 如果团队渡过了这个难关，随着信任曲线的上升、经验的积累，团队开始自主调整资源分配、制定流程和规范，进入了Norming阶段；
• 正向成果的不断积累、失败经验的沟通和学习，让信任曲线上升到最高点，团队执行力也达到顶峰，进入长期的Performing阶段。

那么，作为团队领导者，怎样才能让这条曲线更快进入后半段呢？

要做的事情太多，这里分享一些是最关键的，每一条背后都有血泪教训。

首先，是关于人的决策。在Forming阶段，慎重对待每一个招聘；在Norming和Performing阶段，慎重对待每一个绩效评估，在研发领域，尤其要注意绩效评估中的“Fireman Bias” -- 感谢消防英雄的人一定会比感谢用防火材料盖房子的人多，就像只有扁鹊知道他大哥的医术最高。关于人的决策就是关乎企业和团队生死存亡的决策，“生死存亡”这个词很重，这是管理学常识，却经常被忽略。Sam Altman在那次被OpenAI董事会武断裁掉后说：

OpenAI is nothing without its people.

其次，每个阶段的关键点要做好。在Forming阶段，需要组织一些破冰活动，形成更紧密的人际关系，也互相了解其他成员的人格特质和能力模型；同时，也要把团队目标传递给每个人，让所有人都能真正理解“Why”。这点我经验不足，以前做的很不好，有条件最好请一些专业的Facilitator，帮助团队打造一个更好的信任起点。还有一个在Forming阶段要并行开始做的是Stakeholder管理，找全利益相关方，让他们在前期就及时了解、随时参与，这对建立更大范围的信任至关重要。

在Storming阶段，必然产生冲突，而这时候的冲突大部分是“建设性冲突”，管理者要作为一个连接者让各方充分沟通、交换意见，直面冲突、管理冲突，而不是避免冲突。要是有冲突解决不了怎么办？找上级领导吗，错！这是一个非常好的机会，让团队成员抛开当前的问题，共同想想我们决策的准则是什么。在决策准则上达成了一致，所有的冲突拿这根尺子一量，自然有了答案，。那么，要是决策的准则也无法达成一致怎么办？那又是一个很好的机会，讨论团队的价值观是什么，大部分情况只要“以用户为中心”、“以公司整体利益为重”、“关心人的发展”这样几个普世价值观的尺子，就足以衡量出决策准则孰优孰劣了。

在Norming阶段，是资源调配和流程确立的关键时期，团队发展到这个阶段，有一些前期资源分配的问题就暴露出来了，树挪死、人挪活，这时调换岗位为时不晚。另外，前期经验不足埋下的风险也暴露出来了，要把每个风险视为一个改进机会，共创流程、制度，识别记录那些暂时处理不了的风险。我的经验是尽量不要管理者自己做，“微操”、“跨领域教人做事”是管理者的大忌，当好一个组织者和助推者，让团队成员充分表达意见，形成自发秩序，这就是Norming阶段的完美状态了。

在Performing阶段，那些曾经非常有挑战的事情，要么已经解决了、要么变成了可以轻松处理的日常事务，团队高效运转，不断输出有价值的产品和服务。在这个阶段，除了上面提到的关于人的最重要的事情“绩效和激励”以外，管理者要能看到团队文化，想办法培育独特的、符合团队发展方向的团队文化。

文化是一种像DNA一样，很难看到的强大力量，对提升工作满意度、保持高效状态至关重要。分享一些个人经验，我会通过一些小活动，或者表彰一些行为，来刻意打造独特的团队文化，我们的团队文化总结成了CCTL四个字母：

• Care -- 关心用户，代码通常只是20%的工作，帮助用户端到端解决掉问题才是100%
• Collaboration -- 只做协作双赢的事情，Win-win or no deal
• Transparent -- 信任是结果，公开透明是前提
• Life-long Learning -- 终身学习，无限进步

最后，作为团队领导者，在任何一个发展阶段，都要去感受团队内部的信任程度，一旦出现信任危机，不要急于下结论，就事论事、坦诚沟通，想办法恢复信任水平。团队的执行力是结果，一切效率来源于《信任的速度》。

《相变》-- 创造力不能被计划 ​

从天文仪到蒸汽机 ​

《相变》的英文标题“Loonshots”是一个生造词，对应”Moonshots“，形容像登月计划那样的疯狂项目。与登月不同的是，“Loonshots”项目不被重视、维护者被认为是“疯子”。雷达、心脏病药物、喷气式飞机、蒸汽机，这些改变世界的发明是怎么问世的呢？

作者借用了物理学的“相变”概念，解释这些发明怎么 在不经意中酝酿出来、突破了哪些阻碍、经历了哪些曲折，最终量变引起质变，跨过临界点一举扭转世界线。

这本书副标题“How to Nurture Ideas That Win Wars, Cure Diseases, and Transform Industries”已经总结全书内容，我们从中找几个有意思的案例，管中窥豹。

给我印象最深的是，作者用相变理论回答了“李约瑟难题”：为什么科技革命发生在欧洲？

一千年前的北宋已经是工业奇迹，天文、航海、金融领先欧洲将近600年，为什么没有进一步发展出科技革命和工业革命呢？

《相变》第9章对比了宋代沈括和500年后丹麦第谷的天文学研究，双方都得到了统治者的支持，都招募了出色的数学家助手（魏璞和开普勒），都因为统治者更替的政治因素被流放。但关键区别是：宋朝皇帝认为沈括的天文仪已经足够好了，停止了天文学的研究，而丹麦仍然继续支持第谷的研究。沈括晚年隐居山林，“只能与毛笔和砚台交流”。

多么可惜啊，一个伟大的项目，在萌芽、发展期被扼杀，再也没有机会达到相变的临界点。

另一个有趣的例子是蒸汽机的发明。1685年，在英国皇家学会，波意耳实验室的法国医生帕旁，改造了胡克制作的空气泵，两年后他出版了一本叫《Digester of Bones》的“烹饪书”，讲怎么用这个高压锅装置压碎骨头。英国皇家学会虽然没有重视这个装置，但学会提供了最早的专利机制和奇思妙想的摇篮。终于，到了1712年，纽可曼把这个装置改造成了实用的蒸汽机，跨过了相变的临界点，再后来就是大家熟知的瓦特改良蒸汽机的故事了。

那达成“相变”的条件是什么呢？作者也给出了答案。

创造力的摇篮：布什-韦尔平衡 ​

200年后的美国，AT&T CEO韦尔建立的贝尔实验室里，产生了8个诺贝尔奖，点开了人类的信息革命科技树。这些创造奇迹的组织有什么共同点？作者出的答案是“布什-韦尔平衡”。在这个平衡点上，发明家自由发挥创造力、工程人员快速将技术落地。

具体来看，构建这样的平衡，需要把“艺术家”和“士兵”两个群体相态分离、再提供恰到好处的交流频率，让二者保持动态平衡。“艺术家”指的是有各种奇思妙想的科学家、发明家们，在宽松的环境下让“艺术家”自由发挥；“士兵”指的是带着专利解决现实问题的职业经理人、工程师、工人们；给二者提供恰到好处的交流，让双方平等的互相反馈。这种状态被称为“相态分离”。

为什么一定要相态分离呢？一个很明显的原因是“艺术家”是允许失败的，而“士兵”不能失败，各自的优势也完全不同。

为什么要有持续的交流呢？反过来想，没有足够的交流，“艺术家”的研究一定会变成空中楼阁，而失去创造增量的“士兵”一定会陷入存量竞争逐渐僵化。

布什-韦尔平衡，其实就是现在企业和高校都在说的“产学研融合”的最佳状态。

无心插柳柳成荫 ​

在读到这本书之前，我并没有系统性理解“布什-韦尔平衡”这个培育创新的机制。回顾以前团队成员和我自己迸发创造力的瞬间，惊讶的发现整个过程确实如此。我一直在践行谷歌80-20的做法，留出20%的时间去折腾各种新技术，我也告诉团队成员都可以花20%的时间学习自己想学的东西，哪怕和项目没什么关系。

我自己的一个例子是关于WebAssembly的，多年前了解到WebAssembly技术，竟然可以在JavaScript Runtime跑任何主流的编程语言，真是太酷了。虽然80%的时间都是”士兵“，留出的20%的时间，在脑海中塑造了一个“艺术家”，允许失败，肆意探索。

前段时间这颗种子发芽了，云计算相关的开源项目大多是Golang，如果编译成WebAssembly不就可以把编译型语言做成函数插件，随意组合使用了吗？于是，我们把Helm、Nomad都编译到了运维引擎中，也编译了一些Rust库进去，开发过程中一位同事甚至还修复了一个Golang的Bug！

我们团队当初那些“无用”的技术储备和算不上发明的小创新，在项目中都起到了重要的作用。如今，WebAssembly在Web后端和云计算领域的应用越来越多，这个本来为了解决“在浏览器运行旧软件”的技术，也是无心插柳柳成荫了。

卓越的研发团队一定不是完全循规蹈矩的、按部就班的，而是能够时不时创造出前所未有的技术和方法，轻松解决掉一些棘手的问题。创造力是团队的源头活水，也是卓越研发团队必不可少的要素之一。

总结 ​

我们从《决断》、《信任的速度》、《相变》三本书出发，找到了战略目标决策、构建信任、培育布什-韦尔平衡这三个关键思想，以及卓越研发团队要具备的产品力、执行力、创造力三个要素，回顾了我们团队做的好的地方、要改进的地方。

Tim Pan创建的影视飓风公司有句Slogan：“无限进步”。的确，追求卓越没有止境，让我们在产品力、执行力、创造力上一直前进吧！

前言 ​

在研发项目技术设计阶段时，经常会遇到意见冲突。有人说“问题紧急程度高，我们要用最快的方式解决问题”；有人说“我们不能直接做，要把需求再抽象一下，这样有很多长期收益”；有的人说“现在用的技术框架XXX太落后了，最近新出来的XXX很适合我们的场景”；有人说“不要折腾了，新东西一定会踩坑，我们用成熟技术来做”......

团队成员多样性越强、决策过程越民主，这类争论持续时间越长。而项目初期的所有决策，都会深刻影响整个项目生命周期，一旦选型错了，很容易让项目方向陷入lock-in，错误的设计想丢丢不掉、想换换不掉，因此，技术方案的科学决策尤为重要。

软件设计中的两类争论 ​

这些年做项目的过程中发现，技术方案的争论点主要在两个方面，分别是抽象层次和技术成熟度。

抽象层次争论：要不要再抽象一下? ​

一种争论是抽象层次的理解不一致，具体的问题抛过来，只看这一个问题开发呢？还是把问题上下文中涉及的名词和动词泛化，抽象成更高层次的概念，用更高抽象层次的概念，解决更多同类问题呢？

举个例子，我们团队负责的DevOps平台曾有个需求是这样的：产线服务需要部署一个“Dogfood”环境，为了让所有业务线产品的更新，都能让公司内部员工先使用，即“吃自己的狗粮”，确保没问题再推向外部市场，并且这个环境中需要最小化流程负担，让开发能够快速发布。

如果不增加抽象层次，直接设计会怎么样呢？从数据库实体关系的设计看，数据库增加一张叫做“dogfood_release”的表，里面有状态字段实现定制流程。这个方案是100%匹配原始需求的，也是开发起来最快的方案。

如果增加一层抽象会怎么样呢？当时我的第一反应是，这个词叫“Dogfood”还是别的什么名字无所谓，需求本质上是：在一个特殊的、风险可控的产线环境里，实现近乎全自动化的发布。我们在现存的"release"概念基础上进行扩展，抽象出一个Auto Release Rule概念，让定制的流程能配置化，到时候给需要的应用启用这种叫“Dogfood Release”的Auto Release Rule即可。

可以看到，两种思路最终给用户呈现的功能几乎相同，但背后的技术方案截然不同。选哪一种更好呢？看完自然就有了答案。

技术成熟度争论：要不要试试新技术？ ​

技术决策的另一种典型争论是：“要不要选用XXX技术”。

2015年我在一家外企实习过一段时间，那家公司对新技术很开放，一些项目甚至用了Scala, Node.js这类当时还很小众的技术。他们对新技术的热情深深影响了我，随后几年我在业余时间都在学新东西, TypeScript、Golang、Kubernetes等等，甚至一度认为，新的就是好的。

辗转到了现在的公司，第一个挑战是解决一个复杂Node.js服务的稳定性问题。那会是2018年，我认为的Node.js已经非常成熟了，问题在于业务而不是技术，但很多人都认为Node.js仍然太新了、不稳定，哪怕我和另外两位同事，已经花了半年时间修复了所有稳定性问题，但随后几年还是被“更成熟的”Java给重写了。

当然，不是简单的重写，大家看到了业务扩张和技术迭代的双重潜力，决心要干一票大的。

我们在Java生态里的技术选型相当激进，当时微服务刚火起来，采纳了SpringCloud Netflix全套微服务方案。然而，项目越做越不对劲，遇到了大量技术上的坑，比如服务发现数据一致性问题、HTTP2调用连接莫名其妙断开问题、Hystrix/Ribbon等组件被Netflix废弃问题、SpringCloud Stream和公司的消息队列SDK难以兼容、服务拆分过细导致的DevOps复杂度爆炸等等。

坑踩差不多了，团队也对SpringCloud的源码读的差不多了。如果再选一次，没有人会再选SpringCloud了，也不会再拆出来十几个微服务了。

这个故事的教训总结成两句话就是：

• 如果缺乏新技术的人才储备，成熟的技术对团队来说也是新技术。
• 如果认为“大公司用过”的新技术就已经足够成熟了，那么一定会在这些“假想的成熟技术”上吃亏。

近几年还有很多方案选择上的经验教训，这些经历彻底改变了我的技术观。怎么客观定义“成熟的技术“，什么情况下可以选“新技术”? 我们需要上升到理论高度来回答这些问题。

研发类型矩阵理论 ​

上面我们用例子说明了两个维度的选择困境，一是对问题的抽象层次，二是技术成熟度。

我们把两个维度做成四象限，找些项目对号入座，就可以进行分类了：

X轴是所选用技术的成熟度，左边是不成熟的新技术，右边是大量案例验证的成熟技术。比如Web Components是一个新技术，在X轴左侧，React是一个成熟技术，在X轴右侧。

Y轴是所要解决问题的抽象程度，下面是只解决具体问题的方案，上面是通过高度抽象的模型解决一大类问题的方案。比如UI库就是非常具体的问题，在Y轴下面，而OpenAI想做出通用人工智能（AGI）解决一切问题，抽象层次已经在Y轴高到大气层了。

1. 第一象限：技术成熟度高，解决抽象问题。除了之前介绍过的Temporal，还有一个我很喜欢的项目PostHog也一样，用的技术是React/AntD/Typescript这类非常成熟的技术，但解决的问题范围巨大，想要成为Product OS，解决一切PM相关问题。这些项目像是久经沙场的将军，步步为营，却暗藏巨大的野心，我们将其称为工业型研发（Industrial R&D）
2. 第二象限：技术成熟度低，解决抽象问题。比如前不久爆火的Bun，用的是Zig这样一个想要取代C语言的新兴编程语言，但目前版本稳定性欠佳，叫好不叫座。OpenAI做的事情更不用说了，抽象程度和技术新颖度已经超出了大多数开发者的认知。落在这个象限的大都是颠覆性项目，我们将其成为“颠覆性研发”（Disruptive R&D）
3. 第三象限：技术成熟度低，解决具象问题。图中举了两个例子，一个是用eBPF解决Tracing问题的Odigos，另一个是用Web Component、最新Web标准的UI库Showlace。这个象限可以叫“探索型研发”（Exploratory R&D）
4. 第四象限：技术成熟度高，解决具象问题。比如我经常用的反向词典WantWords工具，看源码，技术和算法很普通，但近反义词查询这个具体问题解决的很好。这个象限的项目我们称之为“工具型研发”（Utility R&D）

归纳完研发类型后，我们做一个反向因果的假设：因为定位成某种类型的项目，所以方案选择必须落在该象限。再找些失败的案例，可以发现这几类问题：

• 要想做颠覆型研发，只靠成熟技术的组合，或是只解决具体问题，都达不到颠覆效果；
• 要想做工具型研发，如果过度抽象，就会脱离原始需求；
• 要想做探索型研发，继续用现成技术，团队没法更新技术储备；
• 要想做工业型研发，追求新技术会给项目带来巨大风险。

一个不言而喻的结论浮出水面：应该让项目自身的定位，来决定抽象层次和技术成熟度的选择。一旦实际选择与项目定位不匹配，就会出大问题。结合其他变量，还能发现一个推论：从右下角到左上角画一个箭头，越往左上角的第二象限，项目投入越高、风险越高、收益越高、对人能力要求越高。

带着这个研发类型矩阵理论，我们再回到上一节的问题。

第一个问题是：抽象到什么程度是恰到好处的？

回答这个问题要回到项目的原始需求：是要做颠覆性的大事情，还是做风险可控的商业项目？是空闲时间随意的探索，还是一个迫切需要的底层工具？

项目定位确定了，抽象程度就很容易把控了。做小项目，小工具的时候，要警惕过度抽象，别想太多，对照原始需求做就完了；做大项目的时候，既要警惕思维惰性，选短期工作量最小的方式，也要抵制高抽象层次的诱惑，毕竟抽象的代价是忽略细节，而很多业务系统，核心价值就在细节中。这几年冒出来很多低代码平台，大部分是对问题过度抽象了，想造一层“银弹”出来解决所有业务问题，把工业型研发臆想成颠覆型研发，项目定位就错了。

第二个问题是：什么情况下能用新技术？

上节的故事有个蹊跷的地方：既然决定了用“成熟的Java”重构那个业务，为什么选了个Java生态里，当时并不成熟的Spring Cloud呢？

《How Big things get done》一书中，也描述了这个有意思的现象：越大的工程项目，越倾向于用新技术。随之也描述了一个残酷的事实：追求新技术恰恰是一些大型项目失败的主要因素。

创新扩散理论告诉我们的，一群创新者会倾向于采纳另一群创新者的成果。但这不能完全解释，为什么大项目中创新扩散往往会加速。我比较信服的一种解释是：优秀的工程师会一直学新东西，这些人通常也是团队骨干、意见领袖(KOL)。大项目出现时，往往聚集了组织最优秀的人才和创新者，这群人跃跃欲试，想着怎么引入厉害的技术，在大项目中大干一番，因此大项目上马新技术的现象更明显。

我们理性思考一下，大项目风险本来就高，再乘以不稳定的新技术带来的风险，显然不是第一象限“工业型研发”该有的样子，而是第二象限的颠覆性研发。如果真的是第二象限的项目，需要卓越的见识、魄力、智力才能做。悉尼歌剧院成名的背后，是新技术和奇思妙想导致的1400%项目预算超支，毁掉了天才设计师乌松的整个职业生涯；ChatGPT单月增长一亿用户的背后，埋葬的是60多年来三波AI浪潮中，无数死掉的项目。

很多有想法的工程师，理想中是在第二象限做“颠覆性研发”，现实中是在第一象限和第四象限当将军和士兵。大部分大项目就属于第一象限，用商业公司的钱，做多数人能看得懂，用得着的软件，没有充分的评估和使用经验就引入不成熟的新技术，是不负责任且不可取的。

然而，只做第一象限的项目，很难提升个人和团队的技术力。微软CEO纳德拉说：“Our industry respects innovation, not tradition”。我的对策是：在主线项目之余，寻找或者创造做第三象限探索型研发的机会，把大家还认为不成熟的技术，多用多练，转化为成熟技术。

一三象限相结合，不断提升问题抽象能力和对新技术的运用能力，那么第二象限有机会也可以去够一够了。举个例子，我们团队成员曾尝试用Rust语言重构项目底层一部分功能，效果很好，即使公司其他团队还认为Rust太新不敢用，我们也认为Rust是成熟技术了；而Service Mesh领域火爆的Istio，我们四年前开始评估、实验，但实际效果达不到预期，现在仍然将其定位为不成熟技术。

一句话总结现在我对新技术的态度：看的要多，学的要快，采纳要慢。

引申思考 ​

我们给研发矩阵加上动态发展的视角，还能得到一些有趣的启发。

X轴 - 重构 ​

X轴的变化，就是把项目的代码实现，换成新技术/旧技术，仍然是和原先类似的架构设计。有两种情况会在X轴改变项目定位：

1. 项目遇到技术挑战，当前方案要么用的技术太新遇到解决不了的坑，或者技术太旧实现不了某些需求。这种情况换技术方案是有价值的，谨慎评估，快速行动即可。
2. 团队人员发生变化，技术栈不匹配。遇到的好几个Node.js项目被用更旧的Java重写，都是因为新接手的团队不会Node.js。这种情况对最终用户没有产生任何价值，如果是用新技术换掉过时技术可以理解，如果是反过来，只是为了统一团队技术栈放弃了新技术，明显是得不偿失的事情。

Y轴 - 跃迁 ​

Y轴的变化，就是整个软件的领域模型设计变了，增加或者减少了用到的抽象概念。常见的情况是范围扩大，比如从工具转为平台。由于资源限制，很多软件项目起步的时候定位就是一个工具，成功后往往会向平台级产品发展。Vercel和Hashicorp两家公司是典型的例子，做工具型研发非常成功，知名度起来后，都转向做平台级产品，讲大故事。

Y轴的变化通常是决定生死的，最好是在早期就用MinMax思维考虑发展路径，把问题域的底限和上限想明白，否则很容易盲目扩张到进退两难的境地。Hashicorp是一个典型的例子，两位创始人最开始只是做一些分布式系统的底层工具，Terraform、Consul、Vault这些工具迅速流行，给了Hashicorp发展成云平台的机会。然而这家看起来很成功的上市公司危机四伏，平台做的一塌糊涂，财报看不到盈利的希望，市值跌去超过80%。我在工作中也犯过类似的错误，想靠一个看起来完美的模型，统一解决所有类似的问题，忽略了生态、忽略了市场，忽略了产品的生存之本--用户价值，怎么可能只靠提升抽象层次实现工具到平台的跃迁呢？

总结 ​

我们从两类意见冲突的场景出发，归纳了研发类型矩阵：第一象限是工业型研发；第二象限是颠覆型研发；第三象限是探索型研发；第四象限是工具型研发。然后，我们又从模型中发现了“项目定位决定抽象程度和技术选型”这个深层规律，以及两个坐标轴变量与项目投入、风险、收益、人员能力要求的关系。我们也通过例子来说明了怎么运用这些规律，怎么通过一三象限项目搭配，持续磨炼工程能力。

最后，我们带上时间维度，思考了项目演化过程中，改变研发类型的场景和结果：换技术选型分高下，改抽象层次定生死。

上周我做了一次针对业务开发团队的一次Kubernetes入门分享，目的是让大家了解迁移到Kubernetes后的服务运行环境是什么样子。

懂Pod就懂了Kubernetes的一半 ​

Kubernetes可以理解成一个对计算、网络、存储等云计算资源的抽象后的标准API服务。

几乎所有对Kubernetes的操作，不管是用kubectl命令行工具，还是在UI或者CD Pipeline中，都相当于在调用其REST API。

很多人说Kubernetes复杂，除了其本身实现架构复杂以外，还有一个原因就是里面有二十多种原生资源的API学起来曲线比较陡。但不用担心，我们只要抓住本质 -- 提供容器计算能力的平台，就能纲举目张，很容易快速理解。

在K8S中，最重要也最基础的资源是Pod，翻译一下就是“豆荚"，我们用下面这个最最基础的Nginx容器为例，搞清楚豆荚的一生，K8S就懂了一半。

大家也不需要研究Kubernetes怎么搭建，推荐用 OrbStack 在本地一键安装一套Docker & K8S环境出来，快速开始实验。首先，写一段这样的Yaml文件出来。

# nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP

然后，我们用kubectl把nginx的Pod创建出来，命令后面加-v8是详细日志模式，可以看出来kubectl到底做了什么事情。

kubectl create pod -f nginx.yaml -v8

kubectl get pod -v8

在OpenLens或K9S等可视化工具中，我们可以看到一个叫Nginx的Pod就被”生“出来了，从kubectl的详细日志中也可以看到POST/GET等请求的信息。

I1127 14:55:06.886901   83798 round_trippers.go:463] GET http://127.0.0.1:60649/77046cfbc5f80b52d9a1501954ee0672/api/v1/namespaces/default/pods?limit=500
I1127 14:55:06.886916   83798 round_trippers.go:469] Request Headers:
I1127 14:55:06.886921   83798 round_trippers.go:473]     User-Agent: kubectl...
I1127 14:55:07.166333   83798 round_trippers.go:580]     Cache-Control: no-cache, private

可以看到，在创建完成Pod之后，实际的Pod比我们在Yaml中声明的字段更多，这些多出来的字段就是Pod从出生后的经历证明：由调度器调度到集群可用节点、交给kubelet管理Pod生命周期、分配网络IP、挂载临时存储、容器运行时拉取镜像启动容器、控制器协调校正运行状态等等。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
status:
  phase: Running
  hostIP: 10.....
  podIP: 10.....
  conditions:
    - type: Initialized
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2023-11-27T06:59:13Z'
    - type: Ready
      status: 'True'
      lastProbeTime: null
    .....
spec:
  volumes:
    - name: kube-api-access-72rkq
      ......
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
      resources: {}
      volumeMounts:
        - name: kube-api-access-72rkq
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: Always
  restartPolicy: Always
  terminationGracePeriodSeconds: 30
  dnsPolicy: ClusterFirst
  serviceAccountName: default
  serviceAccount: default
  securityContext: {}
  schedulerName: default-scheduler
  tolerations:
    - key: node.kubernetes.io/not-ready
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300
    - key: node.kubernetes.io/unreachable
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300
  priority: 0
  enableServiceLinks: true
  preemptionPolicy: PreemptLowerPriority

展开来看，运行一个容器，必要的就是3大件，计算、网络、存储。

计算资源，就是CPU/Mem/GPU，是在spec的container部分声明，这个案例中没有设置到底需要多少resources，requests 和 resources.limits为空, 也就是说可能占满整个宿主机，这种情况一般叫Best-Effort QoS级别，调度优先级是比较低的。实际情况下一般会设置合理的 requests / limits，达到Burstable QoS级别或者设置requests、limits一模一样达到Guarantee级别。这个Pod经过调度器调度到某个节点之后，就会交给一个叫CRI（Container Runtime Interface）的接口，让CRI的实现来把容器真正建出来，通常是containerd, cri-o, podman, docker等等。

网络方面，可以看到在status里面，多出了PodIP字段，这个是调用底层一个叫CNI（Container Network Interface）的接口，让CNI的实现层给出的IP，这个过程比较复杂，涉及到一个叫pause容器的东西，入门的时候可以忽略这些细节。

存储方面，可以看到自动挂载了一个volume / volumeMounts, 这是对Pod挂载的额外存储，可能是配置文件或密钥，也可能是挂载一些云厂商提供的持久化存储，比如EBS、EFS盘，则会涉及到K8S第三类底层接口，CSI（Container Storage Interface，我们用的云厂商的Kubernetes发行版本一般都已经内置了CSI的实现。

有了计算网络存储，Pod就运行起来了，如果我们要更新Pod，可以用Update, Patch接口，但是，Pod是一个Kubernetes的原子资源，只能更新极少数字段，比如image和readinessGate。

如果想结束掉这个Pod，可以用Delete接口，来让Pod进入Terminating状态，最终被控制器删除，回收掉计算资源，容器镜像文件最终也会被GC掉。

这里只是讲了最浅显的流程，详细的Pod生命周期可以参考这里：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/, 尤其是一些和业务强相关的生命周期活动，比如postStart并行的启动hook，preStop串行的停止hook，发送SIGTERM尝试结束进程，过了Graceful Period后发送SIGKILL信号等等，对业务很有用。

Kubernetes集群视角的计算、网络、存储 ​

至此，我们明白了计算网络存储资源，如何赋予到Pod这个载体上。那么，计算、网络、存储的资源池本身，在Kubernetes里面叫什么呢？

Kubernetes集群的计算节点叫Node，和传统云平台对硬件机器的定义不同，Node也是抽象的资源，可以长出来，也可以死掉，不和运行哪个容器直接绑定，而是通过label/selector, affinity等调度相关的机制关联到Pod。

Kubernetes集群的块存储资源叫PersistentVolume，实际使用场景下，一般是用分布式文件系统来实现，根据业务的磁盘请求，自动创建PersistentVolume的东西叫StorageClass。

Kubernetes的网络是分好几层的：让整个集群变成一个大内网的Pod网络；让集群内服务互相访问自带L4负载均衡的Service网络，以及做精细流量治理的L7 Ingress/GatewayAPI/ServiceMesh网络。还有控制网络访问策略的NetworkPolicy资源。

首先我们看Pod网络，虽然不同CNI实现的网络原理差别巨大，但目的都是一样的，给每个Pod分配IP，并打通和其他Pod之间的路由。比如AWS就用了一个很讨巧的方式实现，直接给Pod分配当前VPC-Subnet的二级IP，DHCP和路由表都是复用的，Pod之间和现有EC2节点之间的通信方式完全一样。

再来看作为内部L4负载均衡器的Service网络，给每个K8S services资源分配一个虚拟IP（ClusterIP）。ClusterIP分配后，kube-proxy组件负责来实现这个虚拟IP的路由的创建和Pod Endpoint变化的实时校正。 还是以AWS EKS为例，EKS默认使用的iptables模式，kube-proxy会在每个节点上把每个ClusterIP Service的IP写入iptables，用iptables命令可以看到实现细节。

• 由于每次变更导致的iptables修改，大规模集群用K8S内置的Service负载均衡是存在性能问题的，切换到ipvs模式可以解决；
• 还有一种没有ClusterIP的Headless Service，借助DNS实现了端点自动发现，不是常规的L4负载均衡
• 如果需要直接把某个Service暴露到公网去，还有NodePort/LoadBalancer类型的Service，kube-proxy会在集群每个节点listen NodePort端口，iptables写入NodePort对应的DNAT规则
• LoadBalancer / NodePort类型的Service还有一个关键字段'externalTrafficPolicy'，简单理解是跨节点负载均衡模式还是本地节点直连模式，跨节点负载均衡还会引起外部LB的健康检查失效问题以及内部服务无法获取Client IP问题，这些都是平台方需要处理好的，不需要业务方关心，业务团队记住一个原则，永远不要用NodePort Service就行。

# https://zhuanlan.zhihu.com/p/196393839
iptables -L -n
# Chain OUTPUT (policy ACCEPT)
# target     prot opt source               destination         
# KUBE-PROXY-FIREWALL  all  --  anywhere             anywhere             ctstate NEW /* kubernetes load balancer firewall */
# KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
# KUBE-FIREWALL  all  --  anywhere             anywhere          

iptables -L -t nat
#Chain KUBE-SVC-TCOU7JCQXEZGVUNU (1 references)
#target     prot opt source               destination         
#KUBE-SEP-HI2KQBDGYW5OVKWN  all  --  anywhere             anywhere             /* kube-system/kube-dns:dns -> 10.52.xx.xx:53 */ statistic mode random probability 0.50000000000
#KUBE-SEP-XQT5TF2PMBOMEGDC  all  --  anywhere             anywhere             /* kube-system/kube-dns:dns -> 10.52.xx.xx:53 */

最后了解一下L7服务网络，一般由类似Nginx Ingress / Envoy 之类的应用流量负载均衡器提供，对于业务来说，就当把nginx conf拆成一个一个yaml片段就好。Ingress直管南北向流量，而Service Mesh把东西南边向流量全托管了，也能实现一些比Nginx conf里面更复杂的行为，比如流量加密、鉴权、故障注入、熔断降级、重试等等。

其他原生资源要么是对Pod套娃、要么是打辅助的 ​

Kubernetes的API设计非常符合单一职责原则（SRP），Pod就是一个包容器的单纯的豆荚，delete了就没了。

但是，你要跑服务怎么办？没关系，单一职责原则下，实现新功能就是一个套娃，Kubernetes抽象了一个叫Deployment套住一个叫ReplicaSet的东西，ReplicaSet再来套住Pod。 这样，Deployment只管变更处理轮换RS，RS只管保证有n个pod在跑，Pod没了再生，死了重启，这里也体现了Erlang典型的let it crash的思维。

哪天你说要训练一个AI模型干掉OpenAI，Kubernetes给你提供了一个叫CronJob和Job的抽象，CronJob套住了Job，Job又套住了Pod。Job只管一次性run的东西，要重试几次，跑完多久删Pod这些事，Cronjob则是一个天然的分布式cron，只管定时把job这个东西生出来。CronJob和Job广泛用在大数据处理管线、CICD管线，AI训练这些领域。OpenAI也是一个包含8000多个节点的巨大Kubernetes集群训练出来的。

哪天你又想用Kubernetes运行一个数据库，恭喜头铁的你，学到了最复杂的一种原生资源，StatefulSet，deployment是把豆荚当牲畜，想杀就杀，StatefulSet是把Pod当宠物，宠物不好养的，每个Pod都不能随便动，更新的时候只能按序一个一个更新。

除了这些对Pod套娃的资源，剩下的可以理解成打辅助的，比如把流量引入集群的Ingress，内部流量负载均衡的Service，给每个Pod提供的分布式配置ConfigMap、分布式密钥存储Secret。还有一些策略控制和资源限额的辅助类，这里不一一展开了。

Custom Resource - Kubernetes变成超纲题的源头 ​

说完了Kubernetes原生资源类型的分类、用法，剩下的就是非原生资源了，或者说叫Custom Resource。Custom Resource提供了一个无限想象的扩展点，社区有个Operator Framework专门用来开发Kubernetes的扩展资源。

搞云原生的没有几个没开发过几个Custom Resource，这种人人都能写扩展的机制，直接把Kubernetes这个本来就有难度的东西整成了超纲题。

其中有一些典型的成功案例，比如应用非常广泛的Prometheus Operator，在集群里扩展了ServiceMonitor，PrometheusRules这些资源，可以用Yaml非常方便动态地定义监控告警，也可以通过写Prometheus,AlertManager Yaml资源一键部署Prometheus集群实例。

社区还有一个项目叫CrossPlane, 把Kubernetes原教旨主义发挥到了极致，这个项目把所有AWS/GCP/Azure的资源，全部给Kubernetes Yaml化了，部署一个RDS、ElastiCache集群，就是声明一个RDS、ElastiCache的Custom Resource Yaml，Kubernetes既是云资源状态数据库也是云资源的部署脚本，再也不用写Terraform或者到AWS Console上吭哧点击了。

我们也做过的一个非常简单的自定义资源，CronDaemonJob，用来在每台机器上像DaemonSet一样跑Cron Job, 用来自动更新OS patch、自动清理应用归档的日志防止磁盘刷爆，简单来说，这个资源可以用来当Kubernetes里面的ansible。

重新思考Kubernetes是什么 ​

到这里，我们大概搞清楚了Kubernetes对于使用者来说意味着什么。从Kubernetes自身的组件视图来看包括这些东西：

• 每个机器装一个叫kubelet的Agent，控制这台机器运行什么
• 每个机器装一个kube proxy的东西用来托管网络防火墙规则，并装一个CNI的实现，控制集群内部的Pod IP分配和网络路由
• 可选的，装一个CSI的实现，接管持久化存储盘的创建和挂载
• 这些东西都听API Server + Controller Manager + Scheduler 组成的控制中心，这套控制中心暴露一套标准的可扩展的REST API，数据全部存到了ETCD元数据集群里。

，让我们操作分布式集群，再也不用撸shell命令，一切命令都API化，一切资源都变成了ETCD的数据记录。

了解了这些，也就明白了Kubernetes本质上是对现有技术的封装，形成了一套云资源操作系统，真正干活的还是服务器上的进程而已，真正对资源做隔离的还是cgroup和namespace这些linux内核原有的东西。

了解了这些，也就明白了，为什么Kubernetes挂了不影响正在跑的服务？为什么在Kubernetes集群做应用性能调优，还是去看EC2用什么instance type，PV存储是哪一代的EBS、EFS，还是去看Subnet内核VPC之间怎么优化RTT延迟和提升带宽？

Kubernetes包含了分布式集群的一切，Kubernetes又一无所有。

Kubernetes的A/B面 ​

Kubernetes带来的最大的几个好处，分别是标准化、弹性、可扩展。

REST API带来的管理界面完全标准化，

存个ETCD记录就创建或校正资源状态带来了极致弹性，扩缩容就在弹指之间，

开发一个自定义资源就实现任意功能带来了丰富的可扩展性，演化出庞大的CloudNative生态系统。

既要又要还要，标准，弹性，可扩展，都有了，看起来很完美，但任何事物都有两面，Kubernetes的这些好处，也是坏处的根源。

标准化的暗面是复杂化。标准要考虑到所有情况，所以这个标准不可能简单，仅仅是一个Pod的spec，就有几十个字段，可能一小半字段大部分人都没有见过。Kubernetes学透的难度和自建运维难度，从一堆培训考证机构可见一斑。即使是大公司，也最好不要有自建Kubernetes的念头，Kubernetes自己的几个组件每个都有上百个启动参数，要么是不懂坑有多大的年轻人，要么是假装整明白的人，要么是身在云厂商里面真正懂的人。

弹性的暗面是易失性，连集群的Node能随时长出、随时消逝，带来了对应用架构的侵入，在Kubernetes中运行的有状态服务必须具备动态发现的能力，想在代码中配置静态IP的时代结束了。我还发现一个Kubernetes带来的效应，”日志丢失焦虑“，在VM上大概没有人会担心日志没采集到，Kubernetes上Pod飘来飘去，总有人问，服务挂掉前的最后一行日志怎么采的，采不到怎么办？

可扩展的暗面是良莠不齐，在CNCF Landscape和开源社区的并不是都是优秀的产品，甚至有些问题很大的东西也流行起来。比如之前团队有位同事仔细读过Click house operator的代码，这个1.5K star的项目，代码质量可能在及格线以下。4年前和另一位同事尝试用ES Operator和Kafka Helm Chart来运维ES/Kafka，当时成熟度还远没有达到生产可用的水平。另外，Helm这个Kubernetes最流行的包管理工具，也是”worse is better“的典型代表，Helm作者哲学家Matt Butcher提出OAM的思想后，自己去搞"下一代云计算"WASM生态去了。

复杂，是成长的代价。

最后以一张经典动图结束本文。

前言 ​

做出好的软件产品，需要许多不同种类的工程师密切协作，高频沟通。跨国软件企业一般会在不同的地区招聘不同的岗位，享受不同地区某些技能的人才密度优势，比如：美国硅谷的产品工程师和设计师、印度班加罗尔的运维工程师和技术支持工程师、中国的开发和测试工程师。于此同时，不同岗位跨了多个时区和文化背景，公司也必然付出沟通效率降低和信任成本变高的代价。

这篇文章从打交道比较多的中、美、印工程师出发，谈谈背后的跨文化差异，目的是让我们更好的理解跨文化，但不要先入为主，给每个独一无二的人贴上标签简单归类。

由于片面的个人经验的局限性，缺少大量样本验证，这篇文章比较主观，想了解更多的跨文化差异，推荐阅读这本书: 《The Culture Map》 以及这两篇书评：

• 跨文化沟通差异背后的启发
• 多几眼看『跨文化冲突』

先想清楚 vs 先做试试 ​

以前最常遇到的一个跨文化冲突的例子是，中美印的工程师对"right things"的理解不一致。

不管人在哪里，遇到的大多数工程师都是积极做事的，但不同文化和思维模式下，对"Do things right"和"Do right things"的重要性排序是不一样的。

美国的工程师会说：

Let's do right things at first place.

中国和印度的工程师会说：

Do it at first, evolve progressively.

美国的工程师喜欢讨论Why的问题，什么是正确的事情，中印的工程师喜欢讨论How的问题，怎么把事情往下做。如果要开始一个中型的软件项目，需求已经明确的情况下，架构设计到什么程度再开始做，中美印工程师给出的答案是不一样的：

• 美国的工程师：至少得有1个月才能设计好
• 中国的工程师：得一周设计完再开始
• 印度的工程师：找个参考项目，直接开始写吧

美国的的战略型选手相对多一些，更善于制定中长期计划和方向；中印的战术型选手相对多一些，更善于随机应变。虽然所有人都赞同应该持续迭代，但计划到什么程度才能开始，抽象层级要到什么程度，设计是要更“理想化”还是“实际的解决当下问题”，不同文化的工程师是很难达成一致的。这也一定程度造成了国内工程师效率比美国高很多，但做出0到1创新的事情相对较少。

另一个有意思的现象是，不论中美，工程执念比较深，到最后都会有完美主义倾向。美国工程师更较真，坚持自己的想法和方向，很难说服他们放弃一个高度抽象的“正确的方向”，转向一个更可行的方案；一些中国工程师对技术的执念很深，会不断去优化一些技术参数，小到一个线程池的大小，大到HuggingFace上华裔们卷出来的一大堆效果相近的AI模型。而通常印度裔工程师对工程技术和方向的执念都不深，方向错了可以换，遇到问题解决问题，不容易死钻牛角尖。

一阶思维、二阶思维 ​

对于上面的现象，一个解释是发展阶段不同，导致思维模式不同：对于发展中国家，变化大于计划是常事，“随机应变”是一种更加实用的能力；而发达国家，更强调守时、行为准则、一致性、按计划行事。

我更赞同的解释是一位朋友从教育层面的分析，不同的发展阶段，要求国家采用不同的教育体系，发展中国家注重培养一阶思维，目标是能做事情，发达国家注重培养二阶思维，目标是能想事情。相比于历史沉淀下来的文化的影响，教育的影响会体现在当代文化中，也反映在不同国家和族裔的竞争优势上。

那么，什么是一阶思维和二阶思维呢？

有一个对认知能力的分类的经典理论：布卢姆分类法。认知能力从底层到高层，分别是记忆、理解、应用、分析、评估、创造，下面三层是记忆、理解、应用，归类为低阶思维，上面三层分析、评估、创造，归类为高阶思维。

“高低”很容易让人产生误解，但并不是说高阶思维比低阶思维更厉害，只是所在的层级不一样，就像高级编程语言和低级编程语言的区别一样。所以，叫一阶思维和二阶思维可能更准确，就像数学中的一阶导数、二阶导数。

国内很多人都经历过应试教育，一定感受过，中国教育模式偏向记忆、理解、应用，注重一阶思维，往坏了说，是培养了做题家和打工人，换个好的说法，是培养了基础牢固、应用和实践能力强的优秀人才。反观欧美教育，偏向分析、评估、创造，注重二阶思维，轻视了一阶思维，和国内的教育体系正好相反。

那位朋友说，美国的产品经理+中国工程师的组合出来的东西，比美国的产品经理+美国工程师，或者中国的产品经理+中国工程师的效果都好。用教育目标的差异就很容易解释。

欧美教育体系加持下的分析评估能力，会让产品的成型率更高；中国教育体系加持下的应用能力，会让产品的实现和交付效果更好。

美国的开发工程师在一阶思维上比较相对薄弱，有一些同事会被抱怨写代码效率低，一些基础的东西不会写。

中国的产品工程师具备二阶思维的并不多，经常有产品经理来回改需求的故事，其实就是前期分析评估能力不够，产品定位不准。但中国的开发工程师的确非常猛，看看我们每个日常使用App里，产品经理塞了几百个没用的功能，神奇的是，这些功能全都给开发出来了。

印度的工程师区间很宽，擅长一阶思维和二阶思维的都有。历史上，印度的成分就非常复杂，由于经常被四面八方的帝国入侵，形成了大融合的局面，超过1万人使用的语言就有121种，另外从事工程师岗位的人，不少是在印度长大，又到发达国家读大学或者工作，接触过多种文化。但在印度本土的工程师，和中国类似，仍然是以一阶思维为主的。

我们从企业整体来看，基层岗位需要战术型选手、高层岗位需要战略型选手，中国的工程师普遍擅长基层岗位、欧美的工程师和经理相对更擅长高层岗位，印度的工程师区间宽，各层岗位都能找到人，这是和各自族裔擅长的思维层级的一致的。华人在硅谷做到"C-suite"(CEO/COO/CFO这类executive-level岗位）的凤毛麟角，这并不能归因于歧视，经济学的一个常识是，市场竞争会减弱甚至消除歧视，更多要归因于教育体系影响下的思维层次差异。

再延伸思考，我们要怎么办呢？中国的教育体系，欠缺对二阶思维的培养，而教育改革一定是滞后的，对于每个人是等不起的，怎么走思维模式的升迁之路，是对我们个人发展极其重要的话题。

那位朋友的观点是，大部分二阶思维，都是从下面三层的一阶思维发展出来的，一阶思维的学习和工作是必要的，但到达一定阶段之后，到了更需要二阶思维的学习认知层级或者工作岗位，会感觉到苦痛和无所适从，这时就是蜕变的机会。他给我的建议是：聚焦到"Why"上，不要轻易滑向"How"，搞清楚why才是二阶思维的目的。

朋友的建议对我最近两年的思维升级起到了非常大的作用，遇到的每一件有挑战的工作，我开始尝试用5 Why原则分析问题，不停往下追问下一层的Why，找到根本原因；再把问题拆分多个维度，评估多种方案的优缺点；最后再决策哪种方案更合适。当这些二阶思维模式，建立在超过1万小时编程沉淀的一阶思维上的时候，会越来越发现，分析评估起来更加结构化；思考高阶问题时，不再去纠结于某一行代码怎么写；在方案落地时，也不失执行力。

在对孩子的教育上，也同样实践了What -> Why -> How的原则，先培养一阶思维，再培养二阶思维。比如，孩子背诗的时候，一定会解释诗的含义是什么，作者当时在什么场景下，为什么写这首诗；孩子在搭机械积木的时候，解释为什么电机能转动、为什么连杆结构可以改变力的方向。追问Why了解原理，就进入了“分析”这个认知层级；了解了Why后提升了“品味”，看到多个类似的事物给出评价，就进入了“评估”这个认知层级；最终才能进入“创造”的层次，能发现和创造出真正的与众不同的规律和事物。

身边有不少同事把孩子送到美国读书，认为欧美教育优于中国教育，而我认为是各有优劣的，国内的STEM教育强于欧美，但缺乏启发式教育和因人而异的培养。分析教育体系优劣的时候，也可以运用下二阶思维，去深入分析、评估每个学校和老师，家长如果是带着”鸡娃“的思路，人云亦云，那在哪读都差不多。

椰子、桃子、咖喱 ​

美国有个笑话，说“一个美国人和中国人创建了一个公司，最后印度人把这个公司接管了”

对于这句话前半部分，有教育体系的因素，华人擅长的一阶思维和欧美人擅长的二阶思维互补，做成事的概率更大；对于后半部分，为什么印度人最终把公司接管了，网上流传的解释是，“印度人喜欢抱团，互相抬上去了”，这个解释有贬低印度裔的倾向，而我遇到的印度同事，不乏优秀的工程师和经理，“抱团互抬”只是一个片面的、浅显的现象。

上一节我们分析了教育体系不同所影响的当代文化，这一节，我们再深一层看，寻找那些从历史沉淀下来的，更悠久的文化差异，这些差异导致了不同性格特质的人概率分布不同，也可以部分解释这句话。

比如在社交方面，有一组形象的比喻：

• 华裔椰子型人格比较多，外壳坚硬，打破这个壳之后很容易形成坚固长久的友谊，熟人关系网络更强；
• 欧美裔桃子型人格比较多，外面柔软，陌生人之间也很热情友善，但友好并不等于友情，更偏向于陌生人社会网络；
• 印度裔成分复杂，更像咖喱，虽然民族之间的价值观和宗教差异很大，但更乐于沟通和分享、给别人反馈，做事的时候很容易互相融合。

东亚在儒家文化影响下，倾向于建立少而紧的连接，更容易获得对团队和集体的归属感。美国文化则相反，而遇到的欧美的同事，能感觉到自古以来个人主义思想的影响，注重自我发展，偶尔会一对一互相聊一些反馈。

南亚文化对人与人的连接很注重，他们喜欢做冥想这种“精神瑜伽”，追求和整个世界的连接，有印度教的"梵我合一"、佛教的"破除我执"的哲学思想在里面。印度人似乎对中国人在意的“人情”没有太多概念，我多次遇到印度的同事询问能否给他的经理写一些工作评价、晋升推荐，一开始很意外，后来也习惯了。

这些不同文化下不同区间的人格类型，宏观的表现是整体上熟人社会还是陌生人社会；大多数人是信奉“Business is Personal”还是“Business is Business”；是先培养好社交关系逐步建立信任，再谈事情；还是通过共同的利益、目标、合约来快速建立信任。反映到市场上宏观体感是：在国内做生意要靠人之间的关系，在欧美市场更多靠产品本身。

不过在企业文化比较健康的软件工程师这个圈子内，通常信息公开程度高，不论是哪个国家哪个族裔，哪种性格特质，更多的还是靠共同的目标、角色职责划分来建立信任，快速进入合作状态，个人关系和工作关系分的比较开，所以“拉关系”对工作的作用不大。

这个比喻对性格和社交方面的分析比较笼统，在《The Culture Map》这本书里有更系统的分析，书中把不同的族裔的文化放到8个维度来看：

• Communication: low-context / high-context
• Evaluation: directive negative feedback / indirect negative feedback
• Persuading: principle-based persuading / application-based persuading
• Leading: egalitarian / hierarchical
• Deciding: consensual / top-down
• Trusting: task-based trust /relationship-based trust
• Disagreeing: confrontational /avoids confrontation
• Scheduling: linear-time /flexible time

和不同族裔的让打交道，感受最明显的是Communication和Evaluation两个维度，即沟通交流、评估反馈，用这两个维度构建4个象限，书中把不同的文化分到了这4个象限：

可以看出，不管是东亚还是南亚文化，在沟通维度，亚裔通常是“高语境(High-context)”的，沟通过程的隐式信息较多，欧美相对会更明确，没有那么多“弦外之音”，美国是“低语境(Low-context)”的，文化层面就排斥隐式信息，倾向于直说。

而评估和反馈这个维度，中美印都是类似的，倾向于给间接的负面反馈，批评的时候会“玻璃碴里找糖”，通常先给一段积极肯定的反馈，再接上负面反馈和改进意见，最后可能还会以积极肯定的话结束，这就是批评的“三明治原则”。如果是正常谈事情的“btw(by the way)”，就是真的是顺便一说的次要信息，如果是给你提改进建议时的"btw"，其实是主要信息。

但在表达负面评价和拒绝的委婉程度上，东亚文化对反对意见更敏感，因此很多国内的经理最怕批评人，一个原因是熟人社会里对“面子”的执着；另一个原因是中国的文化并不完全接受“就事论事”，记得之前组织行为学老师说：“不存在完全的就事论事，事情背后是人，批评一定要私下说，表扬一定要公开说”。这点在美国文化也是部分适用的，但在对于人在美国的一些欧洲人就不适用了。

结语 ​

《易经》中说:“观乎天文，以察时变，观乎人文，以化成天下”。保持开放包容的心态，感受不同的文化，不仅对工作有帮助，而且也是一种乐趣。

遇到一个较真的人，不需要贴上贬义的“固执”，遇到一个含蓄的人，不需要贴上恶意的“虚伪”。理解了这些文化之间差异、人与人的差异，自然会减弱偏见，看到更大的世界。

每个文化底子里都有人性共同的优点，每个人都是相似的，每个人又彼此不同。不要带着框架去预判，带着这种知觉，消除误解，尽可能去了解每一个人。

We are all the same, We are all the different. -- Erin Meyer

目录 ​

Temporal简介 ​

Temporal是一个新兴的分布式的工作流引擎。如果你在工作中遇到过以下这些场景，都可以来了解一下Temporal这个底层引擎。 （长文预警，建议分次服用）

1. 跨服务、跨时间周期的复杂业务流程
2. 业务工作流建模（BPM）
3. DevOps工作流
4. Saga分布式事务
5. BigData数据处理和分析Pipeline
6. Serverless函数编排

这些场景看上去互相没有太大关联，但有一个共同点：需要编排（Orchestration）。

Temporal解决的关键痛点，就是分布式系统中的编排问题。

编排的本质是什么？ ​

要理解编排，可以借助和Orchestration对应的另一个概念：Choreography。找不到合适的中文翻译，还是看图理解吧：

举个例子，我们开发微服务时，经常借助消息队列（MQ）做事件驱动的业务逻辑，实现最终一致的、跨多个服务的数据流，这属于Choreography。而一旦引入了MQ，可能会遇到下面一系列问题：

• 消息时序问题
• 重试幂等问题
• 事件和消息链路追踪问题
• 业务逻辑过于分散的问题
• 数据已经不一致的校正对账问题
• ...

在复杂微服务系统中，MQ是一个很有用的组件，但MQ不是银弹，这些问题经历过的人会懂。如果过度依赖类似MQ的方案事件驱动，但又没有足够强大的消息治理方案，整个分布式系统将嘈杂不堪，难以维护。

如果转换思路，找一个“调度主体”，让所有消息的流转，都由这个"指挥家"来控制怎么样呢？对，这就是Orchestration的含义。

• Choreography 是无界上下文，去中心化，每个组件只关注和发布自己的事件，完全异步，注重的是解耦；
• Orchestration 是有界上下文，存在全局编排者，从全局建模成状态机，注重的是内聚。

Temporal的所有应用场景，都是有全局上下文、高内聚的「编排」场景。比如BPM有明确的流程图，DevOps和BigData Pipeline有明确的DAG，长活事务有明确的执行和补偿流程。

Temporal让我们像写正常的代码一样，可以写一段工作流代码，但并不一定是在本机执行，哪一行在什么时间yield，由服务端信令统一控制，很多分布式系统韧性问题也被封装掉了，比如，分布式锁、宕机导致的重试失败、过期重试导致的数据错误，并发消息的处理时间差问题等等。

Temporal关键概念 ​

1. Workflow，Workflow是在编排层的关键概念，每种类型是注册到服务端的一个WorkflowType，每个WorkflowType可以创建任意多的运行实例，即WorkflowExecution，每个Execution有唯一的WorkflowID，如果是Cron/Continue-as-New, 每次执行还会有唯一的RunID。Workflow可以有环，可以嵌套子工作流（ChildWorkflow）；
2. Activity，Workflow所编排的对象主要就是Activity，编排Activity就行正常写代码一样，可以用if / for 甚至 while(true) 等各种逻辑结构来调用Activity方法，只要具备确定性即可；
3. Signal，对于正在运行的WorkflowExecution，可以发送携带参数的信号，Workflow中可以等待或根据条件处理信号，动态控制工作流的执行逻辑。

下图是Temporal Dashboard中一个Workflow的执行详情示例。

5分钟上手Temporal ​

搭环境 ​

方法1：本地运行Temporalite

本地调试一般没有性能和稳定性要求，建议下载运行All in one的Binary：Temporalite。

temporalite start --namespace default

下载Binary放到Path后，一行命令启动就能连localhost 7233端口使用Temporal服务了，也可以打开浏览器进入Dashboard查看运行状态：http://127.0.0.1:8233

方法2：开发或产线环境Helm部署分布式Temporal

Dev/Prod环境建议用Helm + Kubernetes部署，存储层准备独立运维的MySQL或PostgreSQL。

提前跑create database temporal & temporal_visibility命令创建好数据库，等Helm install完成后，通过admintools进去初始化数据库Schema：

helm dependency build  # optional

helm install -f values/values.mysql.yaml my-temporal . \
  --namespace temporal --create-namespace=true
  --kube-context *** \
  --set elasticsearch.enabled=false \
  --set server.config.persistence.default.sql.user=*** \
  --set server.config.persistence.default.sql.password="***" \
  --set server.config.persistence.visibility.sql.user=*** |
  --set server.config.persistence.visibility.sql.password="***" \
  --set server.config.persistence.default.sql.host=*** \
  --set server.config.persistence.visibility.sql.host=***

# 更新版本执行 helm upgrade 同理

安装如果遇到helm dependency的问题，可以注释掉Prometheus、Grafana、ES等没有用到的依赖Chart。

注意：如果连接AWS Aurora数据库，需要在values.mysql.yaml下面需要加上 connectAttributes：

server:
  config:
    persistence:
      default:
        sql:
          connectAttributes:
            tx_isolation: 'READ-COMMITTED'

第一次Install后，admintools这个Pod会正常运行，其他Pod会找不到数据库表失败，这时可以进去admintools的Pod shell，执行命令更新DB Schema，Schema的源文件在这里：https://github.com/temporalio/temporal/tree/master/schema/mysql/v57 。

export SQL_PLUGIN=mysql
export SQL_HOST=mysql_host
export SQL_PORT=3306
export SQL_USER=mysql_user
export SQL_PASSWORD=mysql_password

cd /etc/temporal/schema/mysql/v57/temporal
temporal-sql-tool --connect-attributes "tx_isolation=READ-COMMITTED" --ep mysql-endpoint -u *** --password "***" --db temporal setup-schema -o -v 0.0 -f ./schema.sql

cd /etc/temporal/schema/mysql/v57/visibility
temporal-sql-tool --connect-attributes "tx_isolation=READ-COMMITTED" --ep mysql-endpoint -u *** --password "***" --db temporal_visibility setup-schema -o -v 0.0 -f ./schema.sql

等其他Pod自动重启或手动删除后，所有Temporal组件都会正常运行，可以Forward一个temporal-web的8080端口，检查Temporal服务是否运行正常。

写代码 ​

搭建完Temporal服务后，我们就可以开始写第一个Workflow代码了。下面我们以Java为例，详细讲解一下完整的Workflow是如何开发的，其他的编程语言道理是完全一样的。

在开始之前，需要给项目添加一下SDK依赖，以Gradle为例。

// 最新版本参考：https://github.com/temporalio/sdk-java/releases
dependencies {
    implementation('io.temporal:temporal-sdk:1.17.0')
}

第1步，设计工作流本身的关键行为和输入输出（参数-返回值），即定义Workflow的执行函数、查询函数、信号函数。

@WorkflowInterface
public interface MyWorkflow {
    @WorkflowMethod
    String execute(Object param);

    @QueryMethod
    List<String> getSomeStatus();

    @SignalMethod
    void manualComplete();
}

第2步，设计工作流涉及的所有子活动的名称和输入输出数据，即定义Activity的执行函数，每个Workflow中的子活动的输入输出。

@ActivityInterface
public interface MyActivities {
    String doSometing(Object param);
}

第3步，最关键的一步：设计工作流的状态机逻辑，即在代码中编排Activity。

注意这里是不用关心Activity的具体实现实例的，因为Temporal需要感知到调用逻辑流，不能直接new Activity的实现类，需要建Activity的Stub对象进行编排，真正的实现类的实例后面会丢给Temporal Client管理，这里也无需实例化真正的Activity类。

public class MyWorkflowImpl implements MyWorkflow {
    private final MyActivities activities;
    private boolean someSignal = false;
    public MyWorkflowImpl() {
        activities = Workflow.newActivityStub(MyActivities.class, ActivityOptions.newBuilder()
            .setStartToCloseTimeout(Duration.ofHours(1))
            .build());
    }

    @Override
    public String execute(Object param) {
        // 这是一个真正的“分布式Sleep”
        Workflow.sleep(Duration.ofSeconds(25));
        activities.doSomething();
        // 等待信号，用来实现cancel，或者多个独立工作流之间的信号协同
        Workflow.await(() -> this.someSignal);
        // 异步执行，通常用于批量并行Activity，多个Promise可以Promise.all/anyOf
        Promise<String> promise = Async.function(() -> {
            log.info("do something async");
            return "Cancelled";
        })
        // 批量Async之后需要对Promise进行同步，防止工作流提前结束
		promise.get();
        // return即WorkflowExecution结束，return值也会被支持化，作为这次Execution的Output
        // 工作流可以是无限的，for / while / 递归 都是支持的
        return "Workflow Done!";
    }

    @Override
    public void manualComplete() {
        // 调用 SignalMethod 后，Temporal会evaluate所有await的表达式
        this.someSignal = true;
    }
}

第4步，实现真正干业务的Activity函数，可以是任意多个类和函数。

@Slf4j
@Service
public class MyActivitiesImpl implements MyActivities {
    @Override
    public String doSomething(Object param) {
        try {
            // 这里可以干任意业务逻辑，但不要在这里越俎代庖，调用Workflow的函数
            log.info("Activity: {}, {}", Activity.getExecutionContext().getInfo().getRunId(), Activity.getExecutionContext().getInfo().getActivityId());
        } catch (Exception e) {
            // 在Activity的实现里面包装一下Exception，对记录异常更友好
            // 异常的Activity会自动Retry，Retry策略可以在初始化ActivityOptions的Builder里面配置
            throw Activity.wrap(e);
        }
        // 执行时间太长的Activity可以阶段性发送heartbeat保活
        Activity.getExecutionContext().heartbeat("I'm still running");
        // Activity函数的所有参数、返回值也会被自动持久化，Workflow状态机产生状态转移和记录
        return "Activity Done !";
    }
}

第5步，准备干活：初始化Temporal Client，连接本地或远程的Temporal的Front服务，注册代码定义的WorkflowType、Activity的实现类

@Slf4j
@Component
@RequiredArgsConstructor
public class WorkflowManager{

    // 这里获取真正的Activity实现实例，在registerActivitiesImplementations传递给Temporal Client用来反射调用
    @Resource
    private DeployActivities myActivities;

    @Getter
    private WorkflowClient client;

    @PostConstruct
    public void initWorkflowFactory() { 
        // 如果是本地测试，不想依赖真正的服务端，可以用newLocalServiceStubs()
        // WorkflowServiceStubs service = WorkflowServiceStubs.newLocalServiceStubs();
        WorkflowServiceStubs service = WorkflowServiceStubs.newConnectedServiceStubs(WorkflowServiceStubsOptions.newBuilder()
                .setTarget("127.0.0.1:7233")
                .validateAndBuildWithDefaults(), Duration.ofSeconds(5));

        this.client = WorkflowClient.newInstance(service);
        WorkerFactory factory = WorkerFactory.newInstance(client);
        
        Worker worker = factory.newWorker("MyTaskQueue");
        // 这个地方注册的每个类都是一个Workflow的定义，每一种是一个WorkflowType
        worker.registerWorkflowImplementationTypes(MyWorkflow.class);
        worker.registerActivitiesImplementations(deployActivities);
        
        factory.start();
    }

    // 一个简单的函数，封装通用的创建WorkflowStub的逻辑
    public <T> Stub<T> startWorkflow(Class<T> workflowType, Object... params) {
        String workflowId = UUID.randomUUID().toString();
        WorkflowOptions workflowOptions = WorkflowOptions.newBuilder()
                .setWorkflowId(workflowId).setTaskQueue("MyTaskQueue").build();
        T workflowStub = this.client.newWorkflowStub(workflowType, workflowOptions);
        return new Stub<>(workflowId, workflowStub);
    }

    @Data
    @AllArgsConstructor
    public static class Stub<T> {
        private String workflowId;

        private T stub;
    }
}

第6步，真的开始干活了：调用WorkflowStub，开始一次WorkflowExecution。

@Service
@RequiredArgsConstructor
public class WorkflowExecutor {

    @Resource
    private WorkflowManager workflowManager;

    public String startMyWorkflow(Object param) {
        String workflowId = UUID.randomUUID().toString();
        WorkflowOptions workflowOptions = WorkflowOptions.newBuilder()
                .setWorkflowId(workflowId).setTaskQueue("MyTaskQueue").build();
        WorkflowManager.Stub<MyWorkflow> myWorkflowStub = workflowManager.startWorkflow(MyWorkflow.class, param);
        myWorkflowStub.getStub().execute("Hello");
        return workflowId;
    }
}

第7步，写测试用例，或者加断点Debug代码。

单元测试和调试步骤可以参考这个文档： https://docs.temporal.io/java/testing-and-debugging

如果要加断点，需要注意环境变量加上 TEMPORAL_DEBUG=true， 否则会报 PotentialDeadlockException。

运行起来之后，就可以在Web UI看到这样的Workflow数据了：

实践与思考 ​

实践历程 ​

2022年，我们基于Temporal开发了DevOps工作流引擎，覆盖公司内部多种类型的CI/CD/CV操作和系统集成，已经在公司产线广泛使用。

前端用蚂蚁开源的x6对DSL和执行过程做了业务层的可视化，后端是用Temporal SDK处理编排逻辑，核心代码不到1000行，绝大多数后端代码只需聚焦在业务开发上，而不是分布式系统的各种复杂问题处理。调试过程甚至不需要打断点，只要在Dashboard查看Event History就有完整的、持久化的“分布式调用栈”，开发调试的体验完美。

当时选型DevOps工作流的底层引擎时，一开始没有发现Temporal这个大杀器，走了一些弯路。2022年国庆期间，我重新评估了系统的架构选型，综合18个维度来看，Temporal无疑是开发复杂工作流业务的不二选择。最后用Temporal把代码推倒重来，花了一整月的时间重构，目前来看结果还是不错的，下面的表格是当时的部分评估结果。

使用关键注意点 ​

• 事件溯源模式的本质，要求工作流代码必须是确定性的（使用Workflow库提供的async函数，current time函数），一切非确定性的行为需要显式记录副作用，比如随机数；
• 不要在Activity代码里面调用Workflow，编排逻辑要全部放到Workflow的实现里；
• 由于Workflow的执行需要被跟踪状态和事件，Stub是每次调用动态创建的，因此，不要用IoC容器托管或者尝试实例化Workflow，但可以用IoC容器托管Activity的实现；
• Workflow的参数和返回值会被记录，因此参数的类型不要出现自引用或嵌套递归，即用到WorkflowInfo之类的对象，否则会导致类似Direct self-reference leading to cycle的错误；
• 写Workflow代码的时候，思维模式需要切换到上帝视角，不需要关心在哪里运行。代码中的第一行可能跑在第一个Worker上，第二行可能跑在另一个Worker，第三行是在100天后等来了第四个另一个编程语言客户端的Worker发送的控制信令。

亮点和局限性 ​

在学习和实践过程中，有一些Temporal的亮点和局限性也顺便总结一下，个人感觉用的非常舒服的地方有这些：

1. 客户端提供了完善的多语言SDK和样例、单元测试：Go/Java/TS/Python/PHP/C#/Ruby，工作流的编程方式非常友好；
2. 背后是从Uber出来创业的商业公司，高性能、稳定性好，可大规模用于产线；
3. 自带WebUI对Workflow和Activity进行查询很方便；
4. 对应用层的灵活性非常高，应用场景广泛；
5. 在中心化状态机+事件溯源模式的模式下开发运行的代码非常健壮，Bug率低；
6. 对于长时间跨度的业务处理很方便，无需引入一套分布式CronJob/Timer方案，一行代码可以实现分布式Timer/CronJob。

体感比较明显的局限性不多，我能想到的有下面几个：

1. 偏底层，没有提供Workflow as DSL/Yaml，需要自己实现DSL和对应的可视化UI；
2. SDK的多语言和多框架的支持还没有特别完善，比如官方对SpringBoot自动配置的支持在开发中，更多编程语言的SDK还在陆续发布；
3. Temporal的Cron Job目前支持到分钟级别，不能设置秒级的Cron Job。

总结 ​

在学习Temporal的过程中，越深入越感觉到其设计之精妙，Temporal本质上是把Golang单机的CSP协程模型，扩展到了分布式系统，实现了Fault-tolerant分布式CSP。完善的持久化机制和跨时间和网络分区的容灾能力，尤其适合做复杂的业务流程、长时间跨度的业务，甚至是业务工作流引擎。

最后用几句不说人话的方式，总结一下Temporal的基本原理和设计思想：

Temporal服务端本质上是通过信令和队列调度实现的中心化工作流引擎、及事件溯源模式实现的持久化长活事务和分布式的可重入进程。 Temporal客户端通过代理模式对执行逻辑进行切面控制，将单机函数输入输出，通过gRPC转为分布式的中心化调度和状态存取，进而实现编码阶段集中化、执行阶段分布式化。

可重入进程+事件溯源思想的厉害之处在于，解决了分布式持久化状态机问题，同时用事件溯源保障了状态机的重入一致性。 去中心化的Worker保持了极致弹性能力、中心化状态机实现了跨应用的全局响应式编程，保障了全局的逻辑内聚性。

Temporal的3个关键特性，可中断、可恢复、响应式，正好是3个”R“：Resumable, Recoverable, Reactive。

A Temporal Workflow Execution is a Reentrant Process. A Reentrant Process is resumable, recoverable, and reactive. Resumable: Ability of a process to continue execution after execution was suspended on an awaitable. Recoverable: Ability of a process to continue execution after execution was suspended on a failure. Reactive: Ability of a process to react to external events

我惊叹于其设计精妙时，也好奇是谁创造了这个项目呢？原来Temporal的核心创始人之一Maxim Fateev，有超过15年消息队列和工作流平台的积累，领导了AWS SQS, Azure Service Bus, Azure Durable Functions, Uber Cherami、Cadence项目。

Maxim Fateev和Samar Abbas2019年出来创业，在2022年初Temporal已经是估值15亿美元)的独角兽企业。Temporal的商业模式果然也是云服务，走Cloud的SaaS模式。基于一个纯开源的工作流引擎的公司，能给到这么高的估值，足以说明背后硅谷投资人的技术视野和基金实力。

学习参考 ​

• 源码仓库：https://github.com/temporalio/temporal
• 官网文档：https://docs.temporal.io/
• 创始人Maxim讲解的Temporal详细原理：https://www.youtube.com/watch?v=t524U9CixZ0&ab_channel=Temporal
• Temporal分布式集群组件和原理：https://docs.temporal.io/clusters
• 7分钟快速入门案例：https://www.youtube.com/watch?v=2HjnQlnA5eY&ab_channel=Temporal
• 3种使用场景详细介绍：https://www.youtube.com/watch?v=eMf1fk9RmhY&ab_channel=Temporal

支持的主流编程语言示例

• TypeScript SDK文档: https://docs.temporal.io/typescript/introduction/
• TypeScript示例代码：https://github.com/temporalio/samples-typescript/
• Java SDK文档：https://docs.temporal.io/java/
• Java示例代码：https://github.com/temporalio/samples-java
• Golang SDK文档: https://docs.temporal.io/go/
• Golang示例代码：https://github.com/temporalio/samples-go

• 引言
• 权责利不对等会怎么样？
  • 000. 无权无责无利则怠
  • 010. 无权有责无利则阻
  • 110. 有权有责无利则苛
  • 011. 无权有责有利则谄
  • 001. 无权无责有利则蚀
  • 100. 有权无责无利则腐
  • 101. 有权无责有利则莽
  • 111. 有权有责有利则效
• 总结

引言 ​

记得在MBA人力资源课上，学过下面这张统计图，对企业资源进行重新组合的时候，是企业所有发展阶段中最具挑战的。2022年，我投身于一个特殊项目，做内部基础设施的重构整合，90%以上的时间都花在了与形形色色团队的沟通上，在过程中也对学的理论有了真实体感，比如定岗需遵循的权责利对等原则，而本文是我对“权责利对等原则”的一些思考。

（图片来自USTC MBA课程的课件）

权责利不对等会怎么样？ ​

权责利对等是构建高绩效团队的关键原则。能力要求相似的团队，往往表现出巨大的绩效差异，通常会被归因于项目问题、管理过程问题，高层管理者却忽视了岗位本身和制度设计是否有问题。尤其是在某些大企业、官僚机构中，可能存在大量权责利不对等的问题岗位。

如果我们把权、责、利的三角各取0或1，组合出来8种情况，依次分析、推演这8种情况，可以解释一些企业中普遍存在的现象。

000. 无权无责无利则怠 ​

没有资源做事，无需承担任何责任，做了事也没有收益，企业中一般不会有这种岗位，也没有人会愿意加入这类团队中。现实中这类岗位可能是由于并购或内部斗争，上层被架空后的“弃子”，可能是将要裁撤掉的岗位。

010. 无权有责无利则阻 ​

没有决定权，却要承担责任，承担了责任也没有额外收益。这个看上去很不合理的情形，却真实存在于某些组织中。

设想一下，如果你是某审核部门的“临时工”，某天看到了巨大的风险，但你知道，真正的决策在上层，自己并没有实际否决权，一旦出事自己可能要背锅。这时，你会怎么做呢？一个理性人，会想方设法避免自己“背锅”。典型的做法是：说服那个有真正决策权的人，设法让流程变的冗长复杂，增加审核的人手，转移自己的责任。

哪天东窗事发，总会找到一个“临时工”来背锅的。根源是这种形同虚设的审核岗位，阻碍了效率的提高，风险却没有降低一丁点。

如果从多方博弈的角度看，这种情形是非纳什均衡态，在这类岗位工作的“理性人”，还可能采取行动转换为下面3种均衡态之一：

1. 如果是三观正常，有一些道德追求的人，会想办法拿回决策权，避免风险，走向第二种有权有责无利（110）模式；
2. 如果道德底线低一些，可能会拿着自己了解的信息，设法牟利，走向第四种无权有责有利（011）模式；
3. 如果佛系一些，选择甩锅、躺平、辞职，走向第一种无权无责无利（000）模式。

110. 有权有责无利则苛 ​

有决策权，需要承担后果，但却不能获得相匹配的收益。企业中广泛存在这类岗位，有的是制度设计造成的，有的是蛋糕不够分造成的。

2022年的典型案例是：疫情防控，我不会评论任何政策的好坏，而是思考现象的本质是什么。为什么顶层制定的非常合理的防疫政策，在基层执行过程中变得更严苛了呢？地方政府有决策权、也同时承担着“不仅要算经济账”这个超越经济利益的巨大责任。在这样的岗位和制度下，任何一个理性人，都一样会做出保守、严苛的防疫政策。

蛋糕不够分造成的有权有责无利也很常见，有外因或者内因。比如，目前全球下行的经济形势下，大多在降低薪水、收缩福利。“多做多错，少做少错”，“吃力不讨好” 这类负面情绪明显增加了。“利”的不足，通常做法就是“求稳”，让事情做的更慢，最大程度避免风险、让“责”与“利”更平衡一些。而内因的场景情形，是大多是中高层的利己决策、盲目扩张，人为造成的“蛋糕不够分”。“财聚人散，财散人聚”的道理很简单，但实践中运用的恰到好处的决策者太少。

当然，“有权有责无利”在也不完全是均衡态，对于优秀人才来说，跳槽、择良木而栖是一个办法；对于道德容易滑坡的人来说，把“权”转换成“利”，通过贪污平衡责任和利益也是一个办法。明朝有严厉的惩戒贪官的制度，为何还出现了杀不完的贪官呢？一个关键原因，是背后的制度问题。

011. 无权有责有利则谄 ​

没有决策权，做事有足够的收益和相应的责任。这类场景也广泛存在于中国企业。举个例子，小A是一名销售，现在想开拓一片新市场，但决策权在总部高层领导手上，正常渠道又没办法申请到足够的资源干这件“大事”。小A只好想尽办法，比如在饭局喝掉自杀剂量的乙醇、设法讨好甚至贿赂决策者来达成目标。

出现这类情况原因基本都是过度集权，赋能不足。错误的制度设计，该决策的人没有决策权，不该决策的人拿了过大的决策权，诱导了道德滑坡，导致一端以利换权，另一端以权换利，监督、重罚治标，但不治本。国内多数企业的文化，恰好给过度集权提供了坚实的土壤。

001. 无权无责有利则蚀 ​

这种情况是上一种情况的变种，但拿到决策者的批准后，连责任都不用承担，就可以躺赚了。没有足以匹配的责任，做起事来会更加不计后果。“假口罩”、“假核酸”、以及各类食品安全问题的背后，是对行政机构的侵蚀，也是问责和惩戒制度的不完善。

100. 有权无责无利则腐 ​

有决策权，却不承担权力滥用的责任，同时也没有足够的利益，这种情况下的岗位以及背后的人，很容易沦为彻底的权力寻租，是比贪更严重的“以权换利”，和上一类情况正好形成一对道德滑坡组合，一方侵蚀，另一方腐败。可见，责任不到位的岗位和制度设计，对组织的危害极大。

101. 有权无责有利则莽 ​

有权力做决策，也有匹配的收益，但不承担错误决策的后果。一个典型案例是大企业过度招聘问题，很多基层业务部门领导可以向人力资源部门申请岗位，为了自己和自己部门的利益，他们会倾向于过度申请人力资源，反正不用承担用人成本。最终后果是过度招人，显得部门很大发展很好，然而事实是，这些人被安排到了鸡肋的岗位，让高层裁也不是、留也不是。没有足够的责任，失去了谨慎的心态，也就变得更加鲁莽。

111. 有权有责有利则效 ​

权责利对等是最高效、安全的岗位定义和运作方式。稻盛和夫推崇的“阿米巴”模式，本质上就是这种原子化的、权责利对等的运作模式。每一个原子组织，都有完备的业务和自主决策的团队，对自己的决策损益负责，这样能够极大激发每一个原子组织的经营者意识。唤起了经营者意识，才有可能更进一步，唤起主人翁意识。

总结 ​

这8类情况中，除了无权无责无利（000）和有权有责有利（111），其他6种情况在企业和机构中或多或少都会出现。当权责利不对等时，由于人性使然，人们总会想办法增加权、利，减少责，形成动态平衡。

分成这8类只是为了分析行为演化的方便，在现实企业和官僚机构中，很多现象是灰度的，不同组也会形成更复杂的局面。洞察这些现象的本质，可以让我们少一些不必要的愤世嫉俗，也可以给管理者优化岗位定义、制度设计提供参考。

天之道，损有余而补不足，人之道，损不足而奉有余。——《道德经》

均衡之道 ​

最近在学习MBA的《数据模型与决策》和《管理经济学》课程，讲到多元函数的极值问题，老师提到拉格朗日乘子法。我们就从一个简单的例子出发，聊聊什么是拉格朗日乘数，以此引出参加企业模拟对抗赛和全球企业管理挑战赛（GMC）后，对战略的理解和感悟。

以三元函数为例，设一个三元函数L=f(x, y, z), 其中 x,y,z 满足约束 φ(x,y,z)=m,则:

1. L = f(x, y, z) + λφ(x, y, z) 其中λ称拉格朗日乘数；
2. 求L分别对x,y,z,λ的偏导为0的方程组，求出驻点P(x,y,z)，一般即为极值点。

当年学高数的时候从没有没想过，为什么要让偏导为0呢？最近在MBA的学习和实践中有了更深刻的理解。

我们把x, y, z 想象成我们可支配的资源，比如健康、时间、金钱。φ是三者互相制约的关系。在某个瞬间，我们恰好平衡了三者，不愿意再多耗哪怕一点健康去换取金钱，也不愿意再花哪怕一点时间来锻炼身体，刚刚好。也就是说在联立λ系数的约束条件后，L函数对4个变量偏导均为0，这时，F函数的3种资源有等价的“阴影价格”。

这种平衡是动态的，我们永远都在为“N元变量在约束条件下偏导为0”的目标努力着。

每个人都是平衡边际效用的高手，即使是那些熬夜、拼命加班的人。在他们的世界里，牺牲健康，换取对他们来说更重要的东西。那些东西对他们的边际效用太高了，而他们自认为健康的对他们自己的边际效用很低，因此只需牺牲很少量的其他资源保障最基本的健康，就可以达到他们心目中的平衡点。

什么是战略 ​

从拉格朗日乘数的含义可以得出：一种资源分配到多处，当各处边际贡献率趋同时，总效用最大。比如一个产品投放到不同市场，当不同市场的边际贡献率，即(单价-变动成本) ÷ 单价，相同时，这个投放比例在此刻是最恰当的。这与老子所说的“天之道，损有余而补不足”异曲同工。

然而，这样做真的是最优解吗？

不，世界是动态变化的。今日的均衡，明日就可能烟消云散。

战是方向，略是舍弃。

战，是拓展那些当前边际贡献率低，未来可能极高的领域；

略，是舍弃那些当前边际贡献率还不错，但未来可能会降至负数的累赘。

此刻的资源倾斜，是为了押注在未来边际效用更高的资源配置方式。

“人之道，补不足而奉有余”。这既是人性贪婪的一面，也是人类智慧的一面。战略就是，你会坚信，现在的战略布局，哪怕不被理解，在未来某天回看当下的短期损失，一定会低于未来总收益的折现值。

如果战略判断对了，留在幸存者的世界，是天人合一之道；如果错了，那就消散在历史长河吧，但求无悔。

战略就是要打破当下的均衡 ​

更深刻的理解战略是什么之后，我们再以未来视角去看一些企业行为、国家政策，会有不一样的体会。

比如最近这几年，不断有造手机的企业下场造芯片，造芯片巨大的投入，不仅失败的风险巨大，而且在很长时间内带来的收益都不可能覆盖研发成本，为什么还是要做呢？

卡脖子问题国家队在攻克，手机厂商专心做手机，牛刀杀牛，菜刀杀鸡，难道不是更“均衡”的做法么？杀鸡焉用牛刀？

但是，我们站到未来去看，就不难理解为什么手机厂商去造芯片了。采购芯片是当下最优解，而打破当下的最优均衡点，可能会带来什么呢？可能是知识产权、可能是手机使用体验的质变、可能是转型造其他硬件设备的技术积淀。造芯片的战略，是以财务利润为代价，押注向更高阶均衡点演化的机会。

什么是自主创新？没有自主，就没有创新。

向内演化 — involution，叫内卷；向外演化 — evolution，叫进化。不去用战略的眼光打破当下的均衡，在未来可能是过度竞争、甚至是一片死寂。

一个企业，即使在正确的战略下，顺利演化生长下去，最终还是要学会适应"逻辑曲线"的制约。“边际效用递减”、“负反馈调节”，这些来自不同领域的智慧，都在描述着同一个本质，自然之道。终究，有一个增长的极限，提前担起社会责任，不要再“损不足而奉有余”，或许是最好的归宿。

天之道，损有余而补不足，人之道，损不足而奉有余。孰能有余以奉天下，唯有道者。

配置中心会有多复杂？ ​

配置中心是微服务系统必不可少的组件之一，乍一看好像没多少技术含量，可是，真的是这样吗？

以Java Spring技术栈为例，主流的配置中心有阿里的Nacos、携程的Apollo、以及Spring Cloud Config Server。我们拆解一下其中共通的技术点：

服务端：

• 认证和权限控制：某个服务可以拿到哪些Key？人员的增删改查权限如何控制？
• 存储层的选型：文件系统，Git仓库，数据库？
• 安全性：传输加TLS，密钥需要落盘加密，本身用来加密密钥的密钥如何安全存储？
• 高可用、数据一致性：多实例部署，甚至跨区域同步，进而又带来分布式存储一致性问题，如何解决？
• 版本控制：修改记录需要保留，随时可能回退到历史版本，另外，灰度版本的配置隔离如何实现？

客户端：

• SDK如何兼容不同的技术栈？
• 大量客户端同时启动，如何做并发控制？同时还要尽可能减少额外的请求，对服务启动时间的负面影响？
• 如何实现与本地配置的优先级控制、合并、缓存、变化实时感知？

...

看到这里，或许你不会觉得配置中心只是简单的KV存储了。主流的型如Alibaba Nacos，作为一个完善的配置和服务发现组件，已经解决了上述大部分问题。我也曾用Nacos，Nacos非常棒，不过我也逐渐发现了一些局限性：

• 当你有数十个环境，每个环境有数百个配置的时候，基于图形界面的版本管理会力不从心；
• Nacos服务的网络、Server、数据库，任何一层出问题，都可能影响大量产线服务；
• 额外的学习、使用、部署、维护成本，服务启动的额外性能开销；
• 发生过一次产线事故，后来分析是因为Spring Cloud Nacos在刷新配置的时候，可能导致Bean Refresh死锁；
• 不支持新版本的SpringBoot/SpringCloud，在SpringBoot 2.3.0.M1之后直接报错（这个问题存在很久了，我在Github提了一个Pull Request修复该问题，多日没有收到答复 https://github.com/nacos-group/nacos-spring-boot-project/pull/189）

挥下奥卡姆剃刀吧，或许你不需要如此复杂的方案！ ​

一行代码实现动态配置 ​

我萌生了一个朴素的想法：既然配置原本就是单纯的文件，那么文件变化时，重新加载对应的Spring Bean不就行了吗？

于是，我开发了一个Spring Boot的配置热重载库，已发布到Maven中心仓库，Github开源仓库地址：https://github.com/Code2Life/spring-boot-dynamic-config。

话不多说，先看效果。

这个库的使用方式极其简单：只要在注有@Value/@ConfigurationProperties的类上，加上@DynamicConfig注解即可。

实现原理 ​

我读了一些Nacos、Spring Boot、Spring Cloud的相关源码后，发现实现热重载配置有两类方案：

1. 直接基于Spring/SpringBoot，通过自定义Bean的加载和PostProcessor机制开一个口子来实现；
2. 二是基于Spring Cloud，本身就直接支持了动态配置。

我不想依赖Spring Cloud的任何组件，选择了实现难度更大的第一类方案，更难是因为单纯的Spring Boot没有Spring Cloud Starter的父Context和@RefreshScope注解，不能直接destroy原来的Bean，refresh一个新Bean出来，得“飞行中换引擎”。

文件变化监听 ​

第一步，从Environment Bean的PropertySources里，把文件配置的PropertySource给揪出来。

// 需要先实现EnvironmentAware接口或自动装配StandardEnvironment
MutablePropertySources propertySources = environment.getPropertySources();
for (PropertySource<?> ps : propertySources) {
    boolean isFilePropSource = isFromConfigFile(ps);
    if (isFilePropSource) {
        // 找到配置文件的PropertySource
    }
}

第二步，用Java NIO的Watch API监听配置目录。

watchService = FileSystems.getDefault().newWatchService();
Paths.get(configLocation).register(watchService, StandardWatchEventKinds.ENTRY_MODIFY, StandardWatchEventKinds.ENTRY_CREATE);
WatchKey key;
while ((key = watchService.take()) != null) {
    for (WatchEvent<?> event : key.pollEvents()) {
        reloadChangedFile(event)
    }
    key.reset();
}

第三步，如果配置文件变了，把原来的PropertySource对象replace成重新创建出来的。

propertySources.replace(filePropertySourceName, newPropertySource);

// 上述代码只是一些示意片段，完整的实现参考在 DynamicConfigPropertiesWatcher 类

至此，我们用数十行代码，已经实现了动态的Environment Bean，用getProperty()获得的结果已经是动态的了。

到此就结束了吗？

Spring Boot开发者一般是在Bean中使用@Value、@ConfigurationProperties来注入配置内容的，因此，原始的配置值已经分散IoC容器里各个相关的Bean中，我们还需要更进一步，在发生变化的同时，把这些Spring Context碗里相关的豆豆再揪出来，偷梁换柱。

修改Spring Bean的属性 ​

1. BeanPostProcessor切入Spring Bean加载流程，筛选出需要热重载Bean，完整代码在DynamicConfigBeanPostProcessor类。
2. 接到配置变化通知时，开始移花接木，完整代码在ConfigurationChangedEventHandler类。

遇到的问题 ​

因为要处理许多异常情况、兼容性问题等等，遇到了这两个问题：

• Linux软链接/Windows快捷方式文件，无法用JDK的WatchService监听。于是加了一个兜底策略：轮询文件的上次修改时间；
• @ConfigurationProperties类/嵌套类中如果有Map属性，Spring Boot的行为是做Merge Keys，而不是清空原有的Keys。我稍微改了一下，让最外层的Map变成清空策略；
• Spring Boot 从2.0到现在2.5，有一些核心类发生了变化，PropertySource的命名也有变化，做了一些兼容，而Spring Boot 1.x的版本差别太大无法兼容了。

在生产环境使用Spring Boot Dynamic Config ​

读到这里，或许你会质疑，这样做在本地开发没问题，但直接用文件的方式来管理开发/产线环境的配置，不是在开倒车吗？难道部署100个实例，要去100台机器上改配置文件？

当然不是。对配置文件的修改，一定，一定，一定要在Git仓库中，最好是独立于代码仓库之外的配置仓库。

为什么要用Git管理配置？ ​

我参与了数十个Spring Cloud服务在全球十几个数据中心的容器化部署和运维，深刻体会了配置管理中的痛点。我们从相对简单的SpringCloud Config，换到功能复杂的Nacos，都没有解决掉本质的问题：应用配置是DevOps的一环，本应该和其他环节一样，通过GitOps的持续交付流水线实现自动化，不是去登录任何一个系统去输入任何一行配置。

我们设想一个场景，你作为一名开发，现在想更新一行产线配置。

Nacos的工作流是什么样的呢？

• 写一个部署文档或者发邮件告诉运维同事，要做一个什么样的修改；
• 运维同事收到邮件，找你开会确认；
• 上线期间，运维同事登录Nacos，找到对应的Namespace和DataID，点击“编辑”按钮；
• 你告诉运维要改的在哪一行，运维同事帮你修改好，点击“发布”按钮；
• 测完预上线环境，告诉运维同事没问题可以发布到产线了，运维再去手工操作上述步骤。

Git的工作流是怎么样的呢？

• 使用你喜欢的IDE打开你的应用配置仓库（这个仓库仅维护该应用服务的非敏感配置）；
• 你改完后提交一个合并请求给领导/运维，同事确认无误点击合并，自动触发Pipeline实现配置上线，是哪个分支哪个环境就立即生效。

你不需要登录任何“配置管理系统”；你的运维同事不需要敲N下键盘、点N次鼠标；你不需要发邮件、写文档；甚至不需要和领导/运维同事发消息，整个过程就如丝般顺滑的在Git上完成了。

如果是开发环境，审批和走查流程灵活一些的话，配置Push到Git的开发分支，自动触发CI Pipeline，喝口水就生效了。

从这个场景可以看出，维护配置的职责交给Git，有很多好处。

• 维护期间，可以利用Git管理系统的权限机制，实现对谁可以提交，如何Review，谁可以合并到产线等等细粒度控制；
• Git本身具备完善的持续集成/持续交付（CI/CD）生态，通过触发CI/CD Pipeline，可以做到配置的秒级上线，跨区域同步上线；
• Git的版本控制能力极强，把配置文件从GUI系统放回到Git，是配置变得复杂之后的必然选择；
• 可以用你喜欢的任何编辑器或者IDE，甚至是Git管理系统自带的Web IDE都可以，语法检查也有了；
• 非常灵活，可以使用模板引擎生成配置，甚至自己开发DSL，这些都可以集成到CI/CD Pipeline中。

读到这里，或许你还有疑问：Git仓库里的配置内容，怎么就通过一个神奇的流水线，“变”到产线的那么多服务器的文件系统里面呢？还有在Git里面，肯定不能维护产线密钥，怎么办呢？

答案是Kubernetes。

Kubernetes的魔法 ​

复杂的分布式系统，离不开基础平台的支持，Kubernetes就是这样一个业界标准级的云原生操作系统。

上一节说的神奇的流水线，并不是把文件拷贝到产线机器上，而仅仅是调用了一个HTTPS请求，来更新Kubernetes ConfigMap资源。

我们先回头看下一开始提的配置中心的技术难点，是怎么被Kubernetes ConfigMap/Secret功能完美解决的。

服务端：

• 认证和权限控制：Kubernetes天然的namespace隔离 + RBAC授权机制，读写权限可以控制到单个文件的粒度；
• 存储层的选型：职责分离 —— 维护期间在Git，运行期间在Kubernetes背后的etcd，由CI/CD Pipeline自动同步Git到集群。既易维护，又保持了K-V存储服务的架构简单；
• 安全性：Kubernetes天然的TLS双向认证体系，传输是安全的。另外，Kubernetes Secret天然支持云服务商的KMS集成，更严格的权限控制，所有的密钥是单独管理、单独挂载到服务运行实例上的，压根不会出现在Git中；
• 高可用、数据一致性：背后的ectd集群使用Raft算法保障一致性。虽然etcd是CAP取CP，但即使整个K8S集群不可用，也不会影响任何已经运行的服务，因为ConfigMap/Secret早已在初始化Pod的容器阶段，就挂载成了普通的文件/环境变量；
• 版本控制：运行期etcd只保留个别历史版本，完善的版本管理职责，转移给了Git这样一个天然的版本控制系统。

客户端：文件/环境变量就是最原始的配置方式，应用层没有任何额外性能开销和学习使用成本，也天然兼容任何现有的技术栈，只需要在文件变化时在应用层做一次reload即可。对，Spring Boot Dynamic Config项目干的就是这个事。

注：每个K8S集群节点上运行的Kubelet，虽然会Watch资源的实时变化，但真正的更新是在1分钟的同步周期做的，也就是说配置修改在1分钟内会在所有运行实例中生效。这个机制是对Kubernetes API Server的请求削峰和保护，对于小型集群可以在Kubelet的启动参数减小“syncFrequency”的默认时间，加速配置生效。

下面是在Kubernetes中使用的Yaml示例片段。

# 1. 前提： 在Jenkins/Argo CD/Github Actions中，
#    创建Config Git Repo到Kubernetes ConfigMap的同步Pipeline

# 2. 在声明的K8S Deployment中，
#    添加环境变量 SPRING_CONFIG_LOCATION
#    指向Config Map mountPath，注意需要'/'结尾

kind: Deployment
apiVersion: apps/v1
metadata:
spec:
  template:
    spec:
      volumes:
        - name: conf-path
          configMap:
            name: your-app-config 
      containers:
        - name: app-container
          image: '<your-image-name>'
          env:
            - name: SPRING_CONFIG_LOCATION
              value: /config/
          # Spring支持 Relaxing Binding，使用 -jar xxx.jar --spring.config.location 也可以
          command: ["java", "-jar", "your-spring-boot-app.jar"]
          volumeMounts:
            - name: conf-path
              mountPath: /config

总结与思考 ​

本文主要介绍了我最近开发的一个实现Spring Boot动态配置的轻量级库：Spring Boot Dynamic Config，以及为什么结合Git + Kubernetes的配置管理模式，优于其他配置管理组件。

使用场景 ​

技术是解决问题的，脱离问题场景做选择是没有意义的。

• Nacos适合有历史包袱的项目、未容器化的项目，应用层不得不借助Nacos这类组件，实现一些通用能力。
• 对于已经上了Kubernetes的系统，结合DevOps的持续交付流水线，使用Spring Boot Dynamic Config是最简洁高效的解决方案。
• 当然，对于简单的场景，在3，5台机器上直接跑个位数的服务，即使没有容器化、没有DevOps流水线，直接SSH到服务器去改配置文件，这时用Dynamic Config也是比单独部署配置服务更简单的一条路。

少即是多 ​

我开发这个库的动机，是在参与数十个微服务应用的DevOps工作时，看着运维同事深陷大量环境和服务的配置管理泥坑，我开始反思一个问题：配置管理有必要如此复杂吗？

当我们已经有了Git、有了Kubernetes，那么，Git不就是那个最完美的配置管理系统吗？Kubernetes不就是那个最完美的配置中心吗？踏破铁鞋无觅处，得来全不费工夫。

Keep it simple and stupid !

Kubernetes + X ​

Kubernetes + Git解决了复杂微服务系统的配置管理问题。其实，Kubernetes + X的组合几乎可以解决掉服务治理的所有问题。而开发人员很少了解Kubernetes这样强大的云原生平台，认为Kubernetes仅仅是部署运维的工具。我以后还会再写一些文章来说明：为什么在Kubernetes体系下，许多组件和轮子是不必要的，包括主流的Spring Cloud生态的诸多组件。之前也曾写过一个简单的回答：https://www.zhihu.com/question/430048535/answer/1582533126

项目的开发历程 ​

为什么造这个轮子？

Kubernetes ConfigMap/Secret已经是主流的云原生配置方案，而Java Spring生态缺少一个动态感知ConfigMap/Secret变化的轻量级库。Spring Cloud Kubernetes (https://spring.io/projects/spring-cloud-kubernetes) 这个库采用直接调用Kubernetes API的方案，一方面这个库过重了；另一方面与Kubernetes耦合过于紧密，启动服务还需要访问Kubernetes API的权限，不合适。

效果如何？

这个小轮子一共花了一周多的业余时间，一小半的时间在解决疑难杂症，还有一小半的时间在写文档、改进单元测试和代码质量。

最终，精简到仅有600多行实现代码，无任何除了Spring Boot核心库以外的依赖。同时开发了400多行单元测试，测试覆盖率95%，CodeBeat代码质量评分在A/B级之间。

再贴一下项目地址，使用方法打开就可以看到：https://github.com/Code2Life/spring-boot-dynamic-config 。欢迎小伙伴们使用、Star、PR！

在编程领域，并发和异步这两个概念并没有初学者想象的那么高深，本文将以最普通的白话，拆解这两个概念，读完后下面这一系列问题，或许你就有了答案。

• 协程是什么？
• 协程和线程的本质区别是啥？
• 哪些编程语言支持协程？有栈协程和无栈协程有什么区别？
• CSP模型是什么意思？
• Actor模型是什么意思？
• I/O多路复用到底解决了什么问题？
• 线程间上下文切换的成本真的很高吗？
• 为什么用同步原语进行并发编程常常出BUG？
• 怎么解决异步回调模式的可维护性问题？
• async/await算协程吗？和Generator函数是什么关系？
• 什么是函数响应式编程（FRP）？
• 为什么Node.js要用单线程？真的只有一个线程吗？
• 为什么Java到JDK 16还没有协程？
• 为什么更优雅的Actor模型、FRP没有成为主流？

目录：

• 白话并发模型和异步编程范式
  • 主流编程语言的并发模型
    • 三头六臂：多线程模型
    • 万剑归宗：I/O多路复用 + 单线程模型
    • 千手观音：协程模型
    • 多面手: 你有我有全都有
  • 异步编程范式
    • 异步回调模式
    • Callback的蜕变：async/await范式
    • Callback的涅槃：函数响应式编程
    • CSP/Actor模型：一切皆消息
  • 到底哪个范式最好？
    • 理论 vs 现实
    • 插曲: 为什么Java至今没有协程
    • 结语

主流编程语言的并发模型 ​

为了方便理解，我们用餐厅打个比方，贯穿整篇文章。

CPU核心，或者说Processor，是厨师。

Thread是灶台。

理想情况下，一个厨师一个灶台，厨师一刻不停的炒菜。这种情况餐厅老板是最开心的。

但是，客人不仅吃炒菜，也喜欢喝鸡汤。厨师（Processor）需要在一个灶台炖汤（I/O操作）的时候，换到别的灶台（Thread）炒菜，换灶台就叫线程间上下文切换。

于是，一系列问题就出现了。

我们先从大家熟悉的多线程编程开始讲。

三头六臂：多线程模型 ​

典型代表：Java。

哦，放错图了。

加入客人要100锅鸡汤，最朴素的办法就是放100个灶台，每个灶台炖一锅。厨师需要有三头六臂来回奔波，哪个炖了多久、哪个要加调料，都要厨师操心。

这种方案好像除了换灶台费点事，好像也没什么大问题。编程语言实现多线程模型，大多基于操作系统提供的原生线程，再包装一层出来给开发者用。而封装的线程和OS线程是一对一关系，线程调度完全交给操作系统就完事了，编程语言的Runtime实现也相对简单。

不过，当生意越来越好，老板雇两个厨师来一起干（多核并行编程），问题就出来了。对于同一锅鸡汤：

• 1号厨师放过盐了，2号厨师不知道又放了一次，客户非常生气；
• 两个厨师都以为对方放了盐，结果都没放盐，客户非常生气；
• 1号厨师和2号厨师正巧准备一起放，两人互相扯皮了半天还没放，所有客户都非常生气。

这叫竞态条件（Race Condition）。解决这类问题，需要用到各种同步原语：从CPU硬件层面的CAS指令；到OS级别的临界区、信号量、互斥量；再到编程语言的原子类型、各种锁、同步栅栏、并发安全的集合，都是让内存数据能被多核CPU安全地修改。

除了同步原语，有没有其他办法呢？餐厅的老板很聪明，想到了两种新的方案，下面两节分别介绍。

万剑归宗：I/O多路复用 + 单线程模型 ​

典型代表：JavaScript。

回顾上一节那个餐厅的难题：炖的汤越来越多，换灶台要时间，灶台太多放不下，厨师多了会打架。

餐厅老板脑袋一拍：咱就炖个汤还请那么多厨师干嘛？就雇一个厨师不就好了吗！什么，厨师忙不过来？雇勤杂工！

厨师放调料要1秒，炖的过程要等1小时。类比计算机世界也类似，不同部件的执行速度严重失衡：CPU计算 >> 主存读写 >> 网络或文件I/O。

• CPU很快：1核CPU在一眨眼的功夫，100毫秒，就可以执行数亿条指令。
• I/O很慢：如果一次主存访问想象成1天的话，一趟局域网数据传输就要13.7年。

老板雇了勤杂工之后，炖鸡的这些锅，全都交给勤杂工一起批量照看就好了，大厨只负责在恰当的时候放调料。脑补一下关东煮就明白了：

我们把每个小格子想象成一个Socket连接，这就叫I/O多路复用。

在餐厅里：有一个手持任务队列、名为EventLoop的大厨线程，加上N个任劳任怨的勤杂工线程一起干活。

以Node.js为例，厨师是这样的：

cooker.on("该放调料了", () => {
  console.log("一眨眼功夫就放好啦")
})

苦逼的勤杂工们，被关在一个叫“libuv”的小黑屋里，切到内核态进行系统调用，干着类似这样的活：

// 设置Socket非阻塞
setnonblocking(socket_fd);
ep_fd = epoll_create(max_events);

while (true) {
  // 被困在系统里的“勤杂工”
  epoll_wait(..)
  // 阻塞式读取数据，交给大厨处理
}

从这个模型来看，I/O多路复用，本质上是解决了I/O与计算职责分离的问题。当网络I/O的脏活、累活分离出去了，只要一位大厨，炖百万只鸡不在话下。Node.js、Redis都是这么干的。篇幅原因，只简单说明了网络I/O的案例。定时器、文件I/O等异步任务的实现原理是不一样的，和I/O多路复用无关。

然鹅，这里有一个巨大的隐患。

如果不仅要做关东煮或者炖鸡（I/O密集型任务），还时常要做炒菜（CPU密集型任务）怎么办？

协程，该出场了。

千手观音：协程模型 ​

典型代表：Erlang / Golang。

为了解决既要炒菜又要炖汤的问题，聪明的餐厅老板又脑袋一拍，想到一个万全之策：

• 多雇几个厨师，但是每个人只管面前这一个灶台 —— 不需要线程切换，有多少核CPU就建多少OS线程；
• 不用增加灶台，但要购置一大批锅 —— 这些“锅”就是协程（coroutine）；
• 之前雇的勤杂工继续照看炖鸡的锅和关东煮的锅 —— 继续保留 非阻塞I/O + I/O多路复用 的优良传统；
• 再雇一波勤杂工，就叫他们“换锅侠”吧，专门负责看厨师们面前的锅有没有炒好、放好调料，弄好了就立刻帮厨师换锅 —— 协程调度。

协程最核心的特点就是：不用OS线程的上下文切换，在用户态实现超轻量的执行单元调度。协程的实现有很多，可以根据协程之间有无调用栈分为有栈协程和无栈协程；也可以根据协程间是否存在从属关系分为对称协程和非对称协程。

多面手: 你有我有全都有 ​

其实，编程语言的演进过程也是互相“借鉴”的过程，最后的结果就是“你有我有全都有”。其中最典型的“借鉴”就是Generator函数，搭配async/await或yield实现无栈协程。

async/await模式我们在下面讲异步编程范式再细谈，是一个兼顾实现成本、迁移成本、性能、可维护性的方案，因此多数主流编程语言都可以看到async/await协程的身影。比如：

• C++(20): co_await/co_return/co_yield
• C#: async/wait, yield
• JavaScript: async/await, yield
• Dart: async/await, yield
• Python：async/await, yield

注：

• 虽然C++ 20在语法层面提供的是无栈协程，C/C++ 生态也有诸多使用汇编或其他方式实现的有栈协程库。
• 执行线程是单线程的Node.js，也早已提供了多线程的支持，用于处理CPU密集型任务。

异步编程范式 ​

上面一节我们讲了3种并发模型，基于编程语言实现的并发模型，又演化出了多种异步编程范式。下面一节，我们逐个讲解各类异步编程范式，仍然举餐厅的例子，设想一个场景：现在想让厨师做鸡汤给我们喝，需要 startBoil/coolDown/drinkSoap 3个耗时操作。

在讲异步编程范式之前，我们先看同步编程是怎么做的。为了保持简洁，假设都在一个线程执行了，不涉及多线程间共享数据。

new Thread(() -> {
    startBoil();
    coolDown();
    drinkSoap();
}).start();

异步回调模式 ​

这三个操作要转换成异步调用模式，最直观的解决方案就是用回调函数。什么是回调函数呢？

声明一个函数，把函数指针丢给调度器，这次I/O搞定了就来执行它，这就是一个Callback。

startBoil(function callback() {
    console.log("炖好了，撒点盐")
    coolDown(function callback() {
        console.log("现在可以喝了")
        drinkSoap(function callback() {
          console.log("嗝~~")
        })
  })
})

虽然避免了线程间上下文切换的问题，但这样写异步代码，写着写着屏幕就不够宽了。嵌套回调越来越深，变成了回调地狱，下面几节就是常见解法。

• async/await/yield：熨平callback嵌套褶皱；
• 发布订阅模式：把callback丢出去不管了；
• 函数响应式编程：把callback做成烤串；
• CSP模型/Actor模型：回归同步调用，放到有栈的协程/线程。

Callback的蜕变：async/await范式 ​

async/await本质上是编程语言对generator/yield的一层语法糖。懂了Generator也就明白了async/await的原理，以及为什么Generator函数可以熨平回调函数的嵌套褶皱。

具体的原理分析网上有很多文章，比如这个Node.js的：async/await 源码实现

一句话概况就是：Generator可以看做状态机，遇到yield就进入Pending状态出让执行权，遇到resume/next就继续执行，直到下一个yield。编程语言或者SDK把generator函数包装成 async/await 关键字，就能在看似同步的代码块中异步执行，由于Generator实现的协程是在当前栈顶上继续调用函数，只能模拟携带上下文，并不是真正的保存当前上下文，切换到另一个协程栈，因此是无栈协程。

async () => {
  await startBoil();
  await coolDown();
  await drinkSoap();
}

这种看上去像同步的调用，让心智负担大大降低，也是实际工程中权衡利弊的工程中非常实用的方案。

不过，async/await存在一个小问题：关键字传染。

async () => {
  someArray.forEach(async () => {
    // 只要调用链底存在异步，一条链全部都要带上async关键字
  })
}

下次新入职的前端遇到"SyntaxError: await is only valid in async functions"报错的时候，你就可以拍拍她：写Generator状态机实现的无栈协程的时候会出现async关键字传染问题，显式告诉V8引擎，即可解决这类问题。

Callback的涅槃：函数响应式编程 ​

除了async/await/yield，异步回调地狱还有另一个解法 —— 函数响应式编程（FRP）。

FRP简单的理解可以认为是：

函数响应式编程（FRP） ≈ 函数式编程（FP） + 发布订阅模式

在讲FRP之前，我们先复习一下“发布订阅模式”。

// cooker.js
eventBus.on("炖好了", () => {
  eventBus.emit("可以喝了")
})

// eater.js
eventBus.on("可以喝了", () => {
  console.log("嗝~~")
  
  console.log("对了，汤咋做出来的，炖汤之前嘎哈了？")
})

发布订阅模式在异步编程中，从另一个维度解决掉了回调地狱问题。让Event Bus统一管理一大锅Callback，每个Callback挂了一个onXXXEvent的标签，来了什么异步事件，就让Event Bus统一来调用对应的函数。

既然一个Event Bus就解决了回调地狱问题，为什么还要函数响应式编程呢？

因为事件模式，解开了Callback，会带来逻辑碎片化的问题。也就是说，完全靠Event Listener无法写出高内聚的代码。

那有没有办法，把碎片化的回调函数整合起来，让代码重新内聚呢？

有的。萝卜加大棒，听说发布订阅模式和函数式编程更配哦？

函数式编程（FP）是一个自古有之的概念，把一沓纯净的函数声明式地组合起来，理论上就可以实现任何功能。事件驱动的异步回调函数，经过FP的洗礼，变成了Callback烤串，外酥里嫩。

我理解的函数响应式编程：就是通过一系列操作符对函数组合，实现复杂的异步事件流的操纵和处理，异步事件与函数式编程的完美结合。

比如下面是一段用RxJS实现异步事件流处理的代码实例，没有回调地狱，也不需要async/await。

// incoming$ is a stream that flows
MessageBus.incoming$.pipe(
  // delay messages after call pauseDispatcher()
  delayWhen(() => this.pauseWhenUnAvailable()),

  // dispatch input messages, transform input stream to output stream
  mergeMap((input) => this.handleCommand(input)),

  // publish output messages
  mergeMap((output) => this.sendAckIfNeed(output)),

  // record output
  tap((output) => {
    this.logOutput(output);
  })
).subscribe(() => {
  // do something
})

脑补一下植物大战僵尸游戏里，biubiubiu的豌豆射手，源源不断的豌豆异步发射出来，经过火炬的Pipeline变成了火豌豆，最终真正起作用是在砸到目标的瞬间，也就是上面subscribe里的逻辑。

FRP范式下经常提到背压控制，我们脑补一下水坝，上游的水流速度时快时慢，但水坝可以缓冲整流，让下游流速非常平缓，在传统编程范式要实现复杂的整流逻辑挺复杂的，而在Rx中实现“水坝”功能，仅仅需要一个操作符。这种操作符组合的黑魔法，尤其适合作为框架层的实现基础。因此，大家熟知的Java界新秀：Vert.x, WebFlux 等框架，前端的Angular/Vue/React框架都有FRP的影子。

CSP/Actor模型：一切皆消息 ​

Do not communicate by sharing memory; instead, share memory by communicating.

上面这句名言，Share Nothing架构，也解释了CSP模型和Actor模型的共性：把编程问题转换为通信问题，不同的执行单元不共享同一份内存数据，因此就不需要任何同步原语控制共享数据的访问。

我们先说CSP模型，CSP是上个世纪七十年代提出的，用于描述两个独立的并发实体通过共享的 channel 进行通信的并发模型。Golang用channel炖鸡汤的代码如下：

package main

import (
  "fmt"
  "time"
)

func main() {
  boiled := make(chan struct{})
  drinkable := make(chan struct{})
  finished := make(chan struct{})

  go func() {
    fmt.Printf("开始炖\n")
    time.Sleep(time.Second)
    fmt.Printf("炖好了\n")
    boiled <- struct{}{}
  }()

  go func() {
    <-boiled
    fmt.Printf("凉一凉\n")
    time.Sleep(time.Second)
    fmt.Printf("凉好啦，可以喝了\n")
    drinkable <- struct{}{}
  }()

  go func() {
    <-drinkable
    fmt.Printf("喝完啦\n")
    finished <- struct{}{}
  }()

  <-finished
}