团队管理经验

很多人以为技术团队管理是一门很复杂的学问，但我自己带团队之后慢慢发现，其实很多事情没有想象中那么复杂。技术团队管理，说到底不是“管人”，而是 让团队能够稳定地把事情做好。 刚开始带团队的时候，我也走过一些弯路。最早的时候，我觉得只要自己技术能力强，很多事情亲自做就能解决。但后来慢慢发现，如果团队规模变大，靠一个人是撑不住的。技术负责人真正需要做的事情，其实是让团队整体能力提升，而不是自己变成团队里最忙的人。 这些年做技术管理，我逐渐总结出一些比较简单但很重要的经验。 先把事情想清楚，再让团队去做 很多技术团队效率低，其实不是因为工程师能力不行，而是事情本身没有想清楚。 以前我也遇到过这种情况：需求来了，大家马上开始开发，结果开发到一半才发现设计不合理，又要返工。后来我慢慢养成一个习惯，在项目开始之前一定要把 设计思路和整体方案想清楚。 例如一个系统要做什么功能、系统大概怎么拆分、核心模块怎么设计、哪些地方可能成为瓶颈。如果这些事情没有想清楚，团队越努力，可能走得越偏。 所以现在我通常会先做一件事情：把问题想明白，再安排团队做事情。这样不仅效率更高，也能减少

一级二级缓存设计

为什么需要多级缓存 在互联网系统中，随着业务规模不断增长，数据库往往会成为系统的性能瓶颈。大量请求如果直接访问数据库，不仅会带来高延迟，还会导致数据库压力过大，甚至出现连接耗尽、查询变慢等问题。因此，几乎所有高并发系统都会引入 缓存（Cache） 来提升系统性能。 最常见的缓存方式是使用 Redis 作为统一缓存层。客户端请求首先访问 Redis，如果缓存命中，就直接返回数据；如果缓存未命中，再访问数据库并将结果写入缓存。这种方式已经能够显著降低数据库压力。 但随着系统规模继续扩大，仅仅依赖 Redis 仍然可能出现新的问题。例如在高 QPS 场景下，大量请求同时访问 Redis，会产生网络开销和 Redis CPU 压力。同时，某些热点数据可能会被频繁读取，每次都经过网络访问 Redis，也会带来额外延迟。 为了解决这些问题，很多大型系统会引入 多级缓存架构（Multi-Level Cache），其中最常见的一种模式就是 一级缓存 + 二级缓存设计。

微服务架构设计

为什么会出现微服务架构 在早期的软件系统中，大多数应用都采用 单体架构（Monolithic Architecture）。所有功能模块都运行在同一个应用进程中，例如用户系统、订单系统、支付系统、库存系统等，都被打包在一个工程中统一部署。这种架构在系统规模较小时非常简单直接，开发效率也较高。 但随着业务不断增长，单体架构的问题逐渐显现出来。系统代码越来越庞大，一个项目可能包含几十万甚至上百万行代码，任何一次修改都需要重新构建和部署整个系统。同时，不同功能模块之间耦合严重，一个模块出现问题很可能影响整个系统运行。当访问量增长时，系统也无法只对某个热点模块进行扩展，只能整体扩容，资源利用效率很低。 在这种背景下，微服务架构逐渐成为大型系统的主流设计方式。微服务的核心思想是 将一个庞大的系统拆分为多个独立服务，每个服务负责一个明确的业务能力，并可以独立开发、部署和扩展。这样不仅可以降低系统复杂度，还可以提升系统的可维护性和扩展能力。 微服务架构的核心设计思想 微服务架构并不仅仅是把系统拆分成很多小服务，更重要的是围绕 业务能力（Business Capability）进

Cursor 的发展

IDE 编程工具的背景 在很长一段时间里，软件开发主要依赖传统 IDE，例如： * Visual Studio Code * IntelliJ IDEA * Eclipse 这些 IDE 的核心能力是： * 代码编辑 * 语法高亮 * 自动补全 * 调试工具 但真正的代码逻辑仍然需要 程序员自己编写。 直到 大语言模型（LLM）出现后，软件开发开始进入 AI 编程时代。 最早的一批 AI 编程工具包括： * GitHub Copilot * Tabnine 这些工具主要解决 代码补全问题。 但 Cursor 的目标并不是简单补全，而是： 构建一个 AI 原生（AI-Native）的开发环境。 Cursor 的诞生 Cursor 是一个 AI

PolarDB 存算分离

背景 随着互联网业务规模不断扩大，传统关系型数据库架构逐渐暴露出一些瓶颈，例如扩展能力不足、存储成本高、读写压力集中等问题。为了应对这些挑战，云厂商开始设计一种新的数据库架构模式：存算分离（Storage-Compute Decoupling）。 PolarDB 是阿里云推出的一款云原生数据库，其核心设计理念之一就是 计算层与存储层解耦。这种架构使数据库具备更强的弹性扩展能力和更高的资源利用率。 () 本文将从架构角度分析 PolarDB 的存算分离设计，并与 AWS Aurora 以及传统 MySQL 架构进行对比。 传统 MySQL 架构的问题 在传统 MySQL 架构中，数据库通常运行在单个服务器上： MySQL Server ├── CPU ├── Memory └── Local Disk 计算和存储都在同一台机器上。 这种架构在早期互联网时代已经足够，但随着业务规模扩大，会出现几个明显问题： 1 存储扩展困难 数据库数据通常存储在本地磁盘中，当数据量增长时，只能通过： * 升级磁盘 * 更换更大的机器 这种方式扩

Flink 理解

前言 在大数据系统的发展过程中，一直存在一个核心问题： 数据越来越多，但处理速度越来越慢。 传统的数据处理方式，大多数是 离线处理。 例如： 每天晚上跑一次任务： * 统计用户行为 * 计算广告数据 * 生成报表 * 分析业务指标 这种方式叫： Batch Processing（批处理） 典型工具例如： * Hadoop MapReduce * Hive * Spark 这些系统适合处理 海量历史数据。 但是随着互联网的发展，很多业务开始需要： 实时数据处理。 例如： * 实时风控 * 实时推荐 * 实时监控 * 实时广告竞价 * 实时日志分析 这些场景有一个共同特点： 数据必须“边产生边处理”。 不能等到第二天。 于是就出现了一个新的计算模式： Stream Processing（流式计算）。 为什么需要 Flink 早期实时计算系统主要依赖： * Storm * Spark Streaming 但这些系统都有一些问题。 例如：

ETCD 探索

在分布式系统中，经常会遇到这样的问题： * 服务节点需要共享配置 * 系统需要做服务发现 * 分布式锁需要一个协调中心 * 集群需要一个一致性的状态存储 这些问题，本质上都需要一个 可靠的分布式协调系统。 而在现代云原生体系中，最常用的组件就是 etcd。 例如： * Kubernetes * CoreDNS * service mesh * 分布式配置中心 这些系统的底层都依赖 etcd。 etcd 是什么 简单来说： etcd 就是一个高可靠的分布式 Key-Value 数据库。 但它和普通数据库最大的区别是： 它是为“分布式协调”而设计的。 它的主要特点有： * 强一致（Strong Consistency） * 支持分布式集群 * 提供 Watch 监听机制 * 支持事务 * 提供租约（Lease）机制 很多分布式系统都会用 etcd 做： * 服务注册中心 * 配置中心 * 分布式锁 * Leader

Redis分布式锁

很多人在刚接触分布式系统的时候，都会遇到一个问题： 多个服务实例同时处理同一件事情，如何避免数据被重复处理？ 例如： * 用户抢优惠券 * 定时任务执行 * 库存扣减 * 订单状态更新 如果系统只有一个进程，其实很简单，用 本地锁（mutex） 就能解决。 但在微服务架构或者集群部署之后，问题就变了。 系统可能有： * 10个服务实例 * 100个Worker * 甚至多个数据中心 这时候，本地锁就完全失效了，因为不同进程之间根本不知道彼此的锁状态。 于是就出现了一个概念： 分布式锁（Distributed Lock） 分布式锁的目标很简单： 在分布式环境下，保证某一时刻只有一个节点能执行某段逻辑。 为什么 Redis 可以做分布式锁？ 在实现分布式锁的时候，很多人第一反应是数据库。 例如： select ... for update 但数据库锁的问题是： * 性能差 * 锁粒度大 * 并发高时压力很大 于是大家开始寻找一个更适合做锁的系统。 Redis就非常合适。 原因很简单：

Netty 深入学习

在分布式系统、微服务架构中，网络通信是最基础也是最重要的一部分。 很多高性能框架（如 Dubbo、gRPC、RocketMQ、Elasticsearch 等）底层都依赖 Netty 来完成网络通信。 理解 Netty，首先要理解它背后的 NIO 网络模型设计思想。 传统网络编程的问题 在早期 Java 网络编程中，大多数程序使用的是 BIO（Blocking IO） 模型。 例如： 服务器每接入一个客户端连接，就创建一个线程。 一个连接 = 一个线程 如果连接很多，比如： 1万连接 = 1万个线程 这会带来几个严重问题： 线程资源消耗巨大 线程本身需要内存和调度成本。 线程上下文切换开销大 CPU需要频繁在不同线程之间切换。 系统扩展性差 连接数量一多，系统就容易崩溃。 因此，传统 BIO 并不适合 高并发网络服务。 NIO

算法：基础知识

什么是算法？ 算法，本质上就是 解决问题的一套步骤。 只要是： 输入一组数据 按照一定规则处理 得到结果 这整套处理过程，就是算法。 算法的理解 为什么程序员需要关心算法？因为同样一个问题，不同的算法效率可能差很多。有的做法可能几秒就能算出来，有的可能要跑好几分钟甚至更久。当数据量变大时，这种差距会越来越明显，所以很多系统性能好不好，其实和算法设计关系很大。 算法通常不会单独存在，它往往和数据结构一起使用。数据结构负责把数据组织好，比如数组、链表、树、哈希表这些；而算法则负责对这些数据进行操作。简单来说，一个负责存数据，一个负责处理数据，两者配合起来，程序才能高效运行。 在现实系统中，算法其实无处不在。比如搜索引擎要根据算法排序网页，短视频平台要用算法推荐内容，导航软件要用算法计算最短路线，电商平台也会用算法做商品推荐和排序。很多我们每天使用的软件，其实背后都有各种算法在工作。 学习算法并不是为了刷多少题，而是为了培养解决问题的思路。当遇到一个问题时，能快速想到几种解决方式，然后选择效率更高的一种，这才是算法真正的价值。很多经验丰富的工程师，其实都是在不断优化解决问

go-lynx设计思路

前言 github.com/go-lynx 的设计目的是为了可以快速帮助企业构建微服务体系的基础框架，其中我把整个仓库（包括组织 go-lynx 下 29 个 repo）进行了拆分，分为了lynx架构基座，和各种lynx插件模块。 https://github.com/go-lynx 亮点就是：Plug-and-Play（真正开箱即用），把复杂微服务架构变成“搭积木”。 它不是从 0 造轮子，而是站在巨人肩膀上： * 核心运行时借 Kratos（B 站那套开源框架） * 服务发现/治理用 Polaris（腾讯云原生服务网格），Nacos （阿里开源） * 分布式事务用 Seata，DTM 等 * 然后我自己加了一套插件管理系统 + 事件总线 + 控制平面，实现真正热插拔。 对比 Kratos：Kratos 是“

AI的发展史

AI到底是怎么一步一步发展起来的？ 很多人觉得 AI 好像是这几年突然冒出来的，其实不是。AI的发展已经走了 70多年，可以简单理解为三个阶段。 第一阶段：AI概念诞生（1950—1980） 1950年，英国科学家 图灵（Alan Turing） 提出一个问题： “机器能不能像人一样思考？” 于是他提出了一个著名的测试 （图灵测试）。 简单说就是： 如果人类和机器聊天，分不出来谁是机器，那机器就算“有智能”。 1956年，美国召开了一次会议，第一次正式提出： Artificial Intelligence（人工智能） 从那时起，AI成为一个正式研究领域。 不过当时的计算机很弱，数据也少，所以AI主要停留在理论研究阶段。 第二阶段：AI开始有点用（1980—2010） 随着计算机越来越强，一些AI技术开始真正落地，比如： * 语音识别 * 机器翻译 * 推荐系统 很多互联网产品，其实早就用了AI，例如：

运维历史演进与 K8S 之后趋势

背景 过去三十多年，服务器运维其实一直在做一件事：让人越来越少地去“手动管机器”。 早期的运维非常原始。服务器买回来要自己上架、装系统、配置网络、改配置文件。机器出了问题，就 SSH 登录上去排查，很多时候靠的是经验和记忆。那时候的运维，本质上就是“人盯机器”。 但当服务器数量越来越多，这种方式很快就撑不住了。 问题主要有两个：重复劳动和配置混乱。 重复劳动很好理解，比如同一个服务要部署到几十台机器，每次都要手动执行一堆命令；规模一大，运维每天都在做这些重复的事情。在 SRE 体系里，这类工作有一个专门的名字，叫 toil （可以自动化、重复、但长期价值不高的工作）。 另一个问题叫 配置漂移。今天在一台机器上临时改了个参数，半年后没人记得；不同机器的配置慢慢变得不一样，系统也越来越难维护。 为了解决这些问题，运维开始走向自动化。 最早是各种 Shell 脚本，后来发展成 配置管理工具（比如

OpenClaw 使用记录

OpenClaw 是一个 开源的 AI Agent 自动化执行框架。 它的核心目标是让 AI 不仅仅停留在“对话”，而是能够 自动规划任务、调用工具、执行操作并持续迭代完成复杂目标，最近使用下来总结了一些内容。 简单来说，OpenClaw 可以理解为： 一个可以自动写代码、执行命令、分析项目并持续迭代任务的 AI 工程助手。 与普通的 ChatGPT 或 Claude 不同，OpenClaw 的设计目标是： * 让 AI 具备任务执行能力 * 可以 拆解复杂目标 * 自动 调用工具和执行命令 * 持续 迭代直到任务完成 因此，它更像是一个 AI 自动化开发助手（AI Software Engineer）。 OpenClaw — Personal AI AssistantOpenClaw

Redis 线程模型

Redis 以高性能著称，其核心原因之一就是其独特的 线程模型设计。很多人听说 Redis 是“单线程”，但实际上 Redis 的线程模型在不同版本中已经发生了演进。理解 Redis 的线程模型，对于理解其高性能原理、以及在高并发场景中的使用方式非常重要。 本文将从 Redis 单线程设计、事件驱动模型、IO 多路复用以及 Redis 6 之后的多线程改进几个方面进行介绍。 Redis 为什么选择单线程 Redis 早期版本（Redis 6 之前）的核心执行模型是 单线程处理命令。 也就是说： * 所有客户端请求 * 所有命令执行 * 数据读写 都由 一个主线程完成。 但需要注意的是： Redis 的单线程 只指命令执行单线程，并不是整个 Redis 进程只有一个线程。例如： * RDB 持久化

数据结构：二叉树

二叉树（Binary Tree） 是一种常见的数据结构，它由若干节点组成，每个节点最多只有 两个子节点： * 左子节点（Left Child） * 右子节点（Right Child） 因此称为 二叉树 每个节点通常包含三个部分： Node { value left right } 简单结构示例： A / \ B C / \ \ D E F 其中： * A 是 根节点（Root） * B、C 是 A 的 子节点 * D、E 是 B 的 子节点 满二叉树（Full Binary Tree） 如果一棵树的 所有节点要么有两个子节点，

Istio-限流配置

Istio Envoy Proxy 在微服务架构中，系统通常会通过 Istio IngressGateway 对外提供统一入口。当系统流量突然增加（例如活动流量、爬虫攻击、接口被刷等情况）时，如果没有限流机制，后端服务可能会出现以下问题： * 接口被高频调用，导致服务 CPU 或数据库压力过大 * 突发流量导致系统雪崩或级联故障 * 某些核心 API 被恶意刷接口，影响正常用户访问 因此，需要在 网关层统一进行限流控制，在请求进入后端服务之前进行流量治理。 Istio 基于 Envoy Proxy 实现流量管理能力，可以通过 Envoy RateLimit + Redis 实现全局限流，对特定接口或路径进行访问频率控制。 什么时候会用到 Istio 限流 通常在以下场景中会配置 Istio 限流 /api/login /api/send-code /api/

阿里云实时数仓

前言 使用阿里云现有的产品生态体系，可以解决企业自建集群复杂，难维护，部署成本高的问题。基于这些情况我们可以使用目前阿里云已有的产品进行开通，来满足企业业务需求。 目前面临痛点 1、底层数据库无法承载海量数据，根据后续企业发展，10T，100T，以及PB，EB数据量无法承载，以及无法支撑快速查询响应，数据分析以及数据挖掘等工作。 2、实时计算性能存在一定不足，需要通过可靠计算引擎进行毫秒级实时计算，并且数据质量可靠，可控，可遥测。 3、数据模型调整效率不够快速，不能够非常灵活的调整数据模型结构，快速的提供业务场景报表需求。 应用场景 * 基于Flink和规则引擎的实时风控解决方案 * 基于实时计算（Flink）与高斯模型构建实时异常检测系统 * 基于实时计算（Flink）打造一个简单的实时推荐系统 实时数仓 总体数据开发流程 数据拉取->数据缓冲->实时计算->下沉落库 组件选型 Flink 阿里云实时计算 Flink 版阿里云基于Apache Flink构建的企业级、高性能实时大数据处理系统，由Apache Fl

Grpcs TLS 自签证书

由于微服务通讯需要进行数据加密以保证内网通讯安全。故此记录一下自签证书的生成过程。 以下是在 Linux 或 MacOS 系统上使用 OpenSSL 命令行工具生成自签名证书的步骤。这个过程将创建一个新的根证书（CA），然后使用这个根证书签名一个新的服务器证书。 先简明说明整体流程： 根证书： 1、生成根私钥 2、通过根私钥生成根证书 服务证书 1、生成服务私钥 2、通过服务私钥生成服务CSR 3、通过服务.csr 文件 + 根证书 + 根证书 key 签名出服务证书.crt文件 生成根证书的私钥 openssl genrsa -out ca.key 2048 这个命令将生成一个新的 RSA 私钥，长度为 2048 位。这个私钥将被保存到名为 ca.key 的文件中。 生成根证书