四火的唠叨

本頁 50 篇

• 软件工程，还有未来吗？

  • #ai
  • #Critical Thinking
  • #抽象
  • #软件工程

  我是08年毕业的，到现在，已经过去了超过18年。但是，我开始学软件的时间，要早得多，并且是从VB开始的，正儿八经接触的第一门编程语言是C，毕业使用的是Groovy on Grails做的网站（可远不如现在的毕业生们使用的高大上技术了），在这篇文字里面有所介绍。如今在AI火遍全世界的年代，我会想起当时我是怎样学写软件的，更感慨的是，对于选择软件工程师作为职业的我来说，真的幸运地赶上了好时代。这个时代的激动人心，是前无古人的。 跳出琐碎的具体事件，如果我们站到非常高的视角，想想整个世界软件工程的演进，可以分成这么几个阶段： 首先是五六十年代的手工业时代，硬件是催化剂，随着硬件性能提升，极易崩溃的软件称为了瓶颈，这才有了把工程化从传统产业搬到软件上的第一个阶段。在这个阶段末，北约会议中提出了“软件工程”的概念。 接着是结构化编程时代，相当于是七八十年代，标志性的事件是C语言和Unix OS的诞生，Dijkstra（就是那个最短路径算法的作者）提出了goto语句的害处。从此大家都认可软件应该自顶向下、模块化编写。这段时间很多的观点也是我大学里面逐步接触到的。 接着九十年代到2010年代中期，互

  2026/9/28 12:29四火https://www.raychase.net/8347

• 为什么我不买大盘，只坚持投资个股

  • #Business and Investment
  • #大盘
  • #市场
  • #投资
  • #标普

  投资美股已经有些年了，之前也基于自己的体会和理解陆陆续续写了一些文章，每个持续投资的人都会有自己的理念和方法论，我也不例外。今天想来谈论一个有意思的话题，为什么我美股投资，对于我主要的资金（401k以外的），多年来都不买大盘（标普500），只投资个股，并且是坚持持续地投资个股。 巴菲特曾经说过，对于大多数人来说，标普500指数，是一个最佳的选择。一些在争论是不是应该投资大盘的时候，经常听到这样的回答——“费那么大劲，还不如直接买标普500呢”。这其实是一个普遍的问题，但是不见得参与讨论的人都说得清楚。如果某段时间的投资收益高于标普，尚且会被如此评论，如果这段时间的收益低于标普，那就更得被奚落了。但是我思考了几次这个问题，我觉得对于个股的投资，于我来说，有着诸多清晰且不可替代的好处。 首先，要理解的一点是，为什么投资标普500那么值得推崇？ 投资大盘的逻辑其实很简单，就是相信未来，相信这最具代表性的五百家企业，同时，在相信的同时也接受平庸。 我非常同意这就是大多数人的最佳选择。因为买了标普，就放弃了超越市场获取α收益的可能性，获得的是根上市场平均收益β的确定性。对于没有时间去研究板块和公

  2026/9/14 13:33四火https://www.raychase.net/8305

• Run:ai 学习记录

  • #ai
  • #Machine Learning and Artificial Intelligence
  • #Kubernetes
  • #Run:ai
  • #Scheduler

  工作上的原因，最近学习了一下Run:ai，也考察了一下它的替代技术。在这里记录一下。 Run:ai功能特性 Nvidia当年收购Run:ai，还是很有前瞻性的。并且它并没有阻拦开源版本的继续演进，只不过，商业分支提供了更强大的能力。 Run:ai是一个企业级的AI基础设施编排和管理平台，核心能力就是最大化GPU的资源利用和调度能力，在它的主页上，列出了四大特性： AI-Native Workload OrchestrationDynamic GPU AllocationPolicy-Driven GovernanceOpen Architecture 抛开那些商业宣传和拥抱开源等等方面，我们只讨论技术层面，我觉得拥有核心竞争力的feature主要是： Dynamic Quotas and Pooling，因为原生Kubernetes的资源分配是静态的，有一个简单的排队机制。但是Run:ai的scheduling支持一个复杂得多的规则系统，比如可以保证每一个team或者project的基础配合，但是也可以超额借用，而对于资源竞争的情况，还允许定义preemption的方式，把低优先级的任

  2026/8/7 06:10四火https://www.raychase.net/8295

• 笔记：在 Mac Mini 本地跑 LLM 大模型

  • #Mac
  • #Machine Learning and Artificial Intelligence
  • #LLM
  • #Ollama
  • #大模型
  • +1

  这些笔记是在自己的Mac Mini上面折腾了一些记录，主要是安装一些重要的大模型工具，把这些工具连接起来，建立自己的私有本地知识库等等，以备查阅。后续不定时更新。 安装OrbStack OrbStack是专门为MacOS设计的快速、轻量级的虚拟化工具，可以作为本地Docker、K8s和Linux VM的超容易替代品。因为它丢掉了跨平台的包袱，直接在系统内核级别支持虚拟机指令，动态分配内存等等做法，让它变得超快。就以Docker为例，它可以把冷启动速度从几十秒优化到一两秒。 我是在Apple M4芯片的Mac mini上面折腾的，首先要保证我的应用全部都是M4芯片直接支持的，而不是通过Rosetta 2兼容性转换过来的。在检查Homebrew的时候，发现brew命令的路径在/usr/local/bin/brew，这就是说brew在Intel CPU的模拟路径上，因此重新安装了Homebrew，修改PATH以后检测发现brew已经在ARM的原生路径上了：/opt/homebrew/bin/brew。 这再安装OrbStack就行了： brew install --cask orbstack

  2026/6/1 12:03四火https://www.raychase.net/8180

• 笔记：把新域名应用到 Blog 和 Email 上

  • #dns
  • #Tools Frameworks and Libs
  • #Resend
  • #Squarespace
  • #域名
  • +1

  raychase.net 这个域名是好些年前申请的，最近申请了个更适合作为我个人标签的 rayxiong.me，简单记录下我把新域名应用到blog（新、老域名都可以访问blog），以及创建并使用新域名的邮件地址收发邮件的操作。 Blog 配置 在Squarespace上面配置好DNS的两个A记录： 其中@表示不带任何前缀，它和www前缀这样被视为两条独立的记录。没法再简单了，不过需要等几个钟头生效。 在网站的Nginx配置文件上面添加： server_name www.rayxiong.me rayxiong.me; 以及： if ($host = rayxiong.me) { return 301 https://$host$request_uri; } if ($host = www.rayxiong.me) { return 301 https://$host$request_uri; } 做完之后检查一下有没有语法错误： /usr/local/nginx/sbin/nginx -t 我已经忘记之前证书怎么处理的了，重新安装acme.sh： curl https://get.ac

  2026/5/25 08:04四火https://www.raychase.net/8205

• 写在暗黑 2 术士资料片发售一个多月之际

  • #Video Games
  • #微软
  • #暗黑破坏神
  • #暴雪
  • #术士

  作为一个老暗黑粉，二十年前，写过一点关于它的碎文。那时候我还在读书，《暗黑破坏神2》应该是对我影响最大的一款游戏。还记得第一次接触到暗黑的那天——在家乡暑假的某个阴沉的下午，窗外雨绵绵，一进入游戏，第一幕的罗格营地，就被呼应的下雨细节打动，音乐、雨滴声，还有可以追随地散布的鸡，一切都让我觉得有巨大的沉浸感。于是我一遍又一遍地杀到城外去，杀到地下洞穴去。暗黑游戏的视觉效果我相信不是最好的，但是游戏性和耐玩度却是顶级的。在这以后，也玩过不少类暗黑的游戏，比如《流放之路》（那时候还写过一点关于它游戏中通货膨胀的思考），再没有一款能给我带来那样的体验。 后来我慢慢知道，原来有这样感受的不止我一人。《暗黑破坏神2》是整个电子游戏历史上具里程碑意义的作品，它几乎凭借一己之力奠定了整个ARPG的游戏框架和标准，如今的ARPG砍杀的游戏方式，就是从它开始的。暗黑2的装备系统、技能树，还有怪物系统等等，在当时都是首创，并且都引领了后来的游戏发展方向。比方说，从暗黑2开始，装备的颜色分级制和词缀系统开始流行开来，也是从暗黑2开始，一类被称为“刷子游戏”的游戏类型，也开始被玩家逐渐认识；再比方说，技能树和后

  2026/3/23 07:38四火https://www.raychase.net/8168

• AI 到底会怎样取代我们的工作

  • #ai
  • #Machine Learning and Artificial Intelligence
  • #SaaS
  • #程序员
  • #软件工程师

  这是一个很多人都讨论的大问题。 我一直在思考，也一直没有一个足够确信的答案。去年这个时候，写了一点体会，如今的体会更深了。但是我觉得，我可以把凌乱的内容整理出来。 一些事件 在一两周前，Google Genie 3出来的时候，因为demo展示了它可以很容易地生成一整个可以游玩的世界，游戏引擎Unity的投资者就被吓坏了，疯狂抛售，一天就跌了二、三成。Unity的CEO站出来喊话，核心观点还是——AI再强大它也是概率性的，而Unity程序员的工作，却是追求确定性的。因此AI应该是软件开发的加速器，帮助提升创作的真实性和速度，而非替代者。 朋友推荐我这篇《The Eternal Return of Abstraction: Why Programming Was Never About Code》，这篇读起来有些费劲，不过它的核心思想大概是，编程一直以来的本质是什么？它的本质是把人的意图转化为机器可以理解的形式。它的意义比代码高多了，因为代码只不过是表达这个意图的一种形式而已，还有什么形式？有了AI，自然语言就可以是这个新的形式。大语言模型的一个功绩在于提升了抽象级别，以前我们必须要准确地

  2026/2/16 13:09四火https://www.raychase.net/8155

• 聊聊商业模式——迪士尼

  • #Business and Investment
  • #Disney
  • #IP
  • #商业模式
  • #护城河

  打算把我相对能看得懂的公司商业模式捋一遍，今次讲讲迪士尼。老规矩，内容都是来着我自己这个老股东的理解，从开始建仓到现在，核心仓位拿了很多年了，也是我较大仓位长持的公司中整体回报率最低的一家。我一直奉行只买自己熟悉和（相对能）看得懂的公司这样一个基本原则，因此职业的关系手里大部分持仓都是科技股，像迪士尼这样的公司显得比较另类。 迪士尼是一家传统媒体公司，核心就是内容创作和内容分发，不过和它的竞争对手比起来，它也是向科技激进转型（并且挣扎的）的“新媒体”。如果说传统媒体有Comcast或者Paramount，纯粹的新媒体像是Netflix，那么迪士尼就好像是夹在中间。 就像之前分析阿里巴巴这艘商业巨轮一样，要去理解迪士尼的商业模式，可以从这样三个部分来分别审视： 第一版图：娱乐。它贡献了不到一半的营收和不到三成的利润，包括流媒体和电视网络，以及内容授权。第二版图：体验。略微不到四成的营收，却贡献了接近六成的利润，这其实就是乐园和游轮了，也包括一些周边商品和服务。第三版图：体育。营收和利润都占小头，基本就是ESPN。 护城河 迪士尼大概是地球上护城河最宽的非必须消费类公司之一，它的乐园、游轮

  2026/2/1 13:22四火https://www.raychase.net/8140

• 聊聊商业模式——阿里巴巴

  • #ai
  • #Business and Investment
  • #投资
  • #商业模式
  • #云
  • +2

  之前聊到过拼多多，今天聊一下阿里巴巴。阿里巴巴作为中概元老，很多人都讨论过，我只发表从我的角度浅显的看法。作为利益相关者，我持有阿里巴巴个股，且在中国科技相关的ETF和基金中的被动持有仓位。 首先，要理解阿里巴巴，需要从它的五块构成来分别理解： 国内电商：现金流的奶牛，大概占阿里巴巴营收的一半，增速回暖。基本上属于竞争激烈，并且市场份额逐渐被吞噬的部分。阿里云：营收占比大概只有15%左右，但是增速超过三成，而且站在AI风口。电商出海：营收目前占比比阿里略低，增长能到两位数，属于第二曲线。其它业务：包括菜鸟、饿了么和优酷等等，占到百分之十几的营收，处于亏钱状态。投资和现金：包括最重要的蚂蚁集团。 国内电商 这是我对阿里最初的印象。中国是互联网电商发展最快的国家之一，阿里巴巴作为时代的开拓者，当然也吃到了其中的红利。不过，现在看起来要守住市场份额也开始烧钱了，一旦一家公司要在某个成熟的业务上大手笔地烧钱，我认为这可能就是一个极其危险的信号。凡是进行价格战的生意，基本都很难说是好生意，真正有护城河的生意，是不屑于降价的。 这个烧钱，说到底，主要是为了和拼多多抗衡，打出了百亿补贴的牌。但是阿里

  2026/1/26 13:18四火https://www.raychase.net/8126

• 聊聊商业模式——Atlassian

  • #ai
  • #GitHub
  • #Business and Investment
  • #投资
  • #Atlassian
  • +1

  所谓投资，就是好公司+好价格，仅此而已。作为普通人，和基金和机构比起来，优势之一便是拥有自己独特的认知，这些认知，无论是多么小众，还是听起来多么“常识”，如果用得好的话就是优势，是能够帮助投资变现的。 就我自己而言，符合这一条件的，我可能也能找出个别几家公司来，而Atlassian便是其中之一。我相信大多数人，特别是那些所谓的金融分析师对它未必了解，而作为软件工程师的我，则一直以来都使用它的产品，有的时间段内甚至是重度用户，自然对它我有我自己的认识。这支股票一直在我的列表上，截止本周五，Atlassian的股价（TEAM）跌到一个非常诱人的程度（120刀以下），我认为是一个非常好的机会。本来我一直就想写一些我对不同公司商业模式的看法，那正好这是一个很好的机会，就来聊一聊Atlassian。这些都是我自己的观点，未必正确。 我对Atlassian产品的使用 将近十年前离开Amazon以后，我经历的每家公司都使用Atlassian的产品，尤其是Jira和Confluence，有时还有BigBucket。尤其是在Oracle工作期间，我是真正的重度用户，每天接触大量的Jira tickets

  2026/1/18 07:24四火https://www.raychase.net/8115

• 回国感悟

  自我上次 2018 年回国已经过去超过 7 年了，这次回国呆了超过两周，感触还是很丰富的，整理得不够系统，简单把它们罗列下来。我虽然长期不生活在国内，但是我始终是中国人，也始终用简单的 “国内” 两字替代 “中国国内”，我非常热切地想了解中国国内的变化。当然，时间关系，我的观察不会很深刻，因此我的观点未必都是正确的。 关于出行 中国的基建搞得真的很棒，要说出行恐怕中国是最便捷的国家了。期间坐了公交、高铁、卧铺、游轮、出租、网约车，或者是干脆步行……都很方便。我想，这应该是得益于中国超强的基建能力。这是让我无比自豪的一点，虽说以前在国内待着的时候并没有深刻体会。 关于网约车，我的记忆还停留在那个滴滴和快滴烧钱拉客的年代。后来我知道的是，滴滴独打天下了。如今我看到的是，滴滴也似乎未必能玩得过竞争对手了。因为它的竞争对手早就变了，已经是高德地图这样的流量入口。当年阿里下错了很多步棋，但是阿里没有下错高德地图这步棋，这是少有的流量入口应用。我拿高德地图搜网约车，就会显示一堆可选项，来自不同的网约车公司，接着直接对接支付宝，这个平台把端到端做得真是不错。说起高德地图，想起那时候百度地图是通配，再

  2026/1/6 12:20https://www.raychase.net/8072

• 聊聊商业模式——拼多多

  作为业余爱好，一直很喜欢研究企业的商业模式。我以往觉得电子商务这个赛道竞争很激烈，生意很难做，尤其是中国当前的环境下，近些年在商业模式上也没有太多有意思的创新。快两年前，写过一点关于拼多多的，但主要是批评，我不喜欢它的生意模式，我觉得它的壮大会打压中国的品牌成长。这个观点至今依然成立，不过，除此以外，那个时候我对于拼多多的理解还是比较浅薄的。随着这两年拼多多的成功，我觉得我看到了它越来越多以前没有看到的东西。这些东西让我越来越觉得，黄峥，真的是个眼光很长远，执行上也很厉害的人。 最早的时候，我以为拼多多的核心就是低质量、低价的策略。后来我渐渐明白，所谓的低价策略，只是最肤浅的一个表象。 如果退到十年以前，应该很少有人能同意，在如此激烈的电子商务赛道上，已经有了老牌的阿里巴巴，还有重供应链的京东，拼多多能够挤进来，分到一杯羹。而如今，不仅如此，它的增长居然已经让这两家都难以望其项背。 说到阿里巴巴，如今看，它还是犯了一个企业扩张以后变得局限、傲慢的通病。早些时候马云就评论京东说这种重资产玩不转，到后来张勇则认为拼多多只会帮助阿里巴巴教育用户和开拓市场，阿里巴巴错过了太多的机会。 拼多多的

  2025/11/24 11:30https://www.raychase.net/8063

• OAuth2.0 的几种授权流程

  首先，从高维度看，OAuth 是要解决什么问题？ OAuth 要解决的是客户端在不知道和不使用用户密码的情况下，怎么样安全访问并获取用户所拥有的资源的问题。 顺带说一句，经常和 OAuth 一起谈到的 OIDC 则是解决了用户信息（profile）获取的问题。简单说，OAuth 解决了 Authorization 的问题，OIDC 解决了 Authentication 的问题。 OAuth 有几种角色： Resource Owner：资源的拥有者，比方说终端用户； Resource Server：资源服务器，比如用户想要调用的 API； Client：就是用户来进行鉴权和资源操作的客户端，比方说浏览器或者 CLI； Authorization Server：就是专门授权的服务器。 所以 OAuth 就是用户想通过某种机制，通过 Client 和 Authorization Server 交互来获得能够访问资源的 token。 对于 OAuth2.0 的授权流程，可以根据 grant type 来做个归类。下面的图示全部都来自 Auth0 的官方文档。 1. Authorization

  2025/7/27 10:55https://www.raychase.net/8015

• 初涉 ML Workflow 系统：Kubeflow Pipelines、Flyte 和 Metaflow

  入职 Coupang 两个月了，第一个月主要上手和开发 BOS（Business Operating System）系统，第二个月开始调研选型 ML Workflow 平台。前者目前来说相对比较简单，后者对我来说是一个新坑，也比较有意思，随便写写技术上的体会。 先扯点题外话，其实这次求职有几个比较符合我预期的机会，可在思考之后，我基本上毫不犹豫就选择了 Coupang 这一家。最主要的原因，并非因为雇主，而是因为要做的事情。一个相当规模的团队，在大干一场的早期阶段，要在搭建起属于自己相当规模的 AI infra 来。 我觉得软件行业的巨大的变革，新世纪以来就三次，第一次是互联网应用的崛起，我太小没能做啥；一次是十几年前的 cloud，看着它从爆发式增长到如同水和电一样进入我们的生活，可我算是错过了它比较早期的阶段，即便相当长的时间内我在 Amazon，但是我却并不在 AWS；而这一次，当 AI 的浪潮再来的时候，我就很想行动起来，真正投身其中。程序员的一生能有几个赶这样大潮的机会呢，我不想再错过了。虽说我没有 AI 的技术背景，但我知道 ML infra 到 AI infra 却是个我

  2025/5/19 07:18https://www.raychase.net/7965

• 关于近期求职的近况和思考

  自去年秋天裸辞之后，一直在考虑职业生涯的问题。之后加入求职大军，目前进展还算顺利，作为软件工程师的下一站也将很快确定下来。但是这一次的 career break，虽说时间不算长，却给了我莫大的启发，我也有了一些思考。 从 fullstack engineer 到 platform engineer 其实在去年年初的时候就简要叙述过这个事情。熟悉我的朋友都知道，我的职业生涯有点奇怪，从 Huawei 开始，我是一个全栈工程师（fullstack engineer），从网页设计、前端开发到后端开发都是一锅端的，当时也非常喜欢这个方向，这也是我后来在极客时间上写 《全栈工程师修炼指南》这门课的原因之一。 不过后来这个兴趣点也在慢慢迁移，在加入 Amazon 之后，我陆续经历了两个大的 data platform 团队，一个是做销量预测（demand forecasting）的，一个是为 retail 一侧计算成本和利润的。在这两个 team 中，都要和大数据打交道，和 scientists 和 analysists 一起合作，而我作为一个 engineer 的基础工作，就是把 infra 维

  2025/2/21 05:23https://www.raychase.net/7928

• 聊一聊分布式系统中的时间

  今天聊一下时间的话题。在分布式系统中，“时间” 是一个挺有趣，但是很难处理的东西。我把自己的理解简单整理下来。 不可靠的物理时钟 首先，单一节点的物理时钟是不可靠的。 物理时钟本身就有偏差，可是除此之外，可以引起节点物理时钟不准确的原因太多了，比如 clock jump。考虑到 NTP 协议，它基于 UDP 通信，可以从权威的时钟源获取信息，进行自动的时间同步，这就可能会发生 clock jump，它就是说，时钟始终会不断进行同步，而同步回来的时间，是有可能不等于当前时间的，那么系统就会设置当前时间到这个新同步回来的时间。即便没有这个原因，考虑到数据从网络传输的延迟，处理数据的延迟等等，物理时钟是非常不可靠的。 如果一个分布式系统，多个节点想要仅仅依赖于物理时钟来完成什么操作，那么只能祈祷运气足够好了。在 《从物理时钟到逻辑时钟》这篇文中，我已经介绍了对于物理时钟不可靠的问题，我们有一个解决的办法，就是引入 Lamport 逻辑时钟，或者使用向量时钟，这里就不赘述了。 超时 分布式系统中什么样的执行结果最难处理，成功还是失败？其实都不是，最难处理的结果是超时，因为执行超时了，但是系统却

  2024/10/21 08:41https://www.raychase.net/7857

• 几个有意思的分布式系统设计模式

  分布式系统有它特有的设计模式，无论意识到还是没有意识到，我们都会接触很多，网上这方面的材料不少，比如 《Catalog of Patterns of Distributed Systems》，还有 《Cloud Design Patterns》等等。这里简单谈谈几个我接触过的，也觉得比较有意思的模式。 LSM Tree 对于这个话题，基本上第一个在我脑海里蹦出来的就是 LSM 树（Log Structured Merge Tree）。其实，LSM 树本来只是指一种数据结构，这种数据结构对于大吞吐量的写入做了性能上的优化（比如日志写入），同时对于根据 key 的读取也有不错的性能。换言之，对于读写性能的平衡，大幅优化了写入，而小幅牺牲了读取，现在它也不再被局限于数据结构本身，而是泛化为能够提供这样特性的一种机制。 整个写入过程分为两个部分，为了追求极致的写入速度，写入方式都被设计成追加的： C0：这一层其实就是内存中写入的 buffer，它的实现可以用 RBTree，或者是 SkipList，这种树状有序的结构，它的写入和范围查询都很快。在 Bigtable 的设计中，它被称为 Memt

  2024/10/2 08:46https://www.raychase.net/7710

• 本地部署 Minikube + Docker 记录

  我有 Mac 和 Windows，这些年折腾软件方面的环境 Linux 用得比较多，最近想安装一个 Kubernetes 的本地环境，本着 “生命不息，折腾不止” 的精神，打算在 Windows 上动手。了解到可以尝试 Minikube，在此简单记录一下。 首先得要安装 Docker，但是在 Windows 下跑 Docker 有两种方式，WSL（Windows Subsystem for Linux）或者 Hyper-V。我首先把这些 Windows 组件都勾上： 我两条路都去走了一下，为了使用 Hyper-V，我还去 BIOS 里面打开虚拟化支持的选项。不过，后来才知道，因为操作系统版本是 Windows 10 Home，虽说 Windows 上面跑 docker 有两种方式： 一种是使用 WSL 另一种是使用 Hyper-V 但在 Windows 10 Home 版本上只支持第一种。由于 Hyper-V 本质上是额外的虚拟机，而 WSL 更新，是虚拟化的 Linux 环境，是 Windows 操作系统原生支持的，性能要好一些。 其实，在 Docker 的设置里面也有说了： 可以列

  2024/9/27 06:52https://www.raychase.net/7724

• 谈谈分布式锁

  不要使用分布式锁 就像 Martin Fowler 说的那样，“分布式调用的第一原则就是不要分布式”，谈分布式锁也要先说，不要使用分布式锁。原因很简单，分布式系统是软件系统中复杂的一种形式，而分布式锁是分布式系统中复杂的一种形式，没有必要的复杂性就不要引入。 有的逻辑是没有副作用的（纯函数代码），那就可以无锁执行；有的数据经过合理的 sharding 之后，可以使用单线程（单节点）执行，那就单线程执行。 比如一种常见的模式就是使用 queue（比如 Kafka），任务全部放到队列中，然后根据 sharding 的逻辑，不同的 consumer 来处理不同的任务，互相之间不会干扰冲突。 还有一个例子是 Kotlin Coroutine，通过指定一个单线程的 dispatcher，也可以保证它执行的操作之间互相不会有多线程的冲突问题。 有了这样的原则以后，再来谈谈几种分布式锁。 数据库锁 分布式系统中，我觉得我们最常见的锁就是使用一个中心数据库来做的。 一种是悲观锁，就是 “select xxx … for update” 这样的，相应的数据行会被锁上，直到 commit/rollback

  2024/9/19 07:33https://www.raychase.net/7671

• 我裸辞了

  我裸辞了。 工作差不多十六年了，从来没有以离职后休假的方式休息过。今年还是比较特别的，我做了很多新的尝试，想改变一下自己，包括这最近发生的一件事情。事情发生得很快，我辞职了，在作为 engineer 加入 Doordash 一年零十个月后。 记录一下。 原因 我不是在二十岁的年纪，做决定容易缺乏思考，其实，我已经想了这件事情好久了。在这期间，我也和不同的朋友和同事讨论过，他们有的还在 Doordash，而有的也已经离开了。说起来，大致有三个原因： 第一个，是兴趣的不匹配。 郭德纲说过，如果你每天做的事情是你喜欢做的，那就是老天爷赏饭吃。这样的情况只在少数人身上发生，而我大致就是这样的少数人——不能说每天如此，但是在我职业生涯八成以上的时间，我工作做的事情，恰恰就是我喜欢做的。不过，今年我从一个做平台的 Gateway 组换到了一个做产品的 Order 组，我察觉到情况有了变化，这里面原因有些复杂，但明确的是，impact 是有，但做这个产品工程师并不是我所喜欢的。回头想起来，过往一直都是一个 platform engineer，这算是我第一次做 product engineer，也许这

  2024/9/16 11:10https://www.raychase.net/7655

• 谈谈拼多多和品牌

  最近有些思考，想在这里随便聊一下拼多多和品牌的话题，记录一下。 我不是学经济的，也不是学商业的，但是关于品牌和商业模式的话题，很多人都有自己的思考。我想聊聊这个事情是由最近拼多多市值超过阿里的事情引起的。 首先一点，电子商务的红利期早就过去，现在看来，电子商务真的算不得什么好生意，也很难谈什么扎实的护城河。电子商务，最多就是套着已经黯淡马甲的零售业，没有什么本质区别。 也许在十五年前，电子商务是能给人无限遐想空间的商业模式。阿里巴巴这些年可以说把一副好牌打坏，电商成功了，但不能躺在功劳簿上，于是它尝试了大量的 “第二曲线”，可是基本上输多胜少，臃肿的人员不说，投资也是一塌糊涂。阿里巴巴有护城河吗？当然！但是它最核心的零售业，护城河却是被高估的，有人说它现在是处于 “大而不能倒” 的状态。 我想起自己家乡的大型超市，基本上都是每隔几年就有一个新的冒出来，然后就是人头攒动，再接着就是几年后倒闭，几十年了，仿佛就是跳不出这个循环。灯火辉煌的时候人们永远都不会去想象它几年后落魄的样子，但是市场的变化往往比人们想象要快。 曾经有人争论重物流和轻物流带来的区别，可是看看京东，一样在过苦日子。电子商

  2024/2/20 04:06https://www.raychase.net/7567

• 关于软件行业未来和职业生涯的一点思考

  关于行业未来 软件行业裁员到处是风声鹤唳，关于行业，关于职业，关于未来，平日里总有一些零散的想法，可是总体来说，始终是忙碌太多，而思考太少。于是，这个周末静下心来，想努力把这些碎片串起来——可是似乎这并不是一件很容易做的事情，那就先把这些想法记录下来。 首先，关于软件行业。很显然的是，任何行业都有周期，软件行业也不例外，软件行业已经过了最疯狂的时间段，现在整个市场都在高利率下，在高昂的借贷成本下冷静下来。我依然记得最疯狂的时候，大概就是在疫情大放水期间，小红书上都有各种行业的牛鬼蛇神 “三个月转码” 的小作文，那些就让我想起了好多年前，我刚读大学的时候，听说招计算机专业的毕业生，因为需求火爆、一将难求而面试大量走过场（那个时候还没有软件专业毕业生）的故事。和做 manager 的朋友聊天，他也说，那段时间招进来的程序员能力整体上很明显下降了一个档次，而对于公司和团队来说，消化这些人的代价又显得很巨大。 软件行业是夕阳产业吗？显然不是。但软件行业是新兴行业吗？说真的，也不太适合谈什么 “新兴” 了。我认为，现在的软件产业依然再走着明确的上坡路，但是市场很明显很理性了。长远看，这是一个太正

  2024/1/16 13:46https://www.raychase.net/7524

• 关于经济和投资，再见，有趣的 2023 年

  2022 年末 2023 年初的时候，中国顶尖的投资银行中金公司（中国国际金融股份有限公司）对于中国宏观经济做了十大宏观预测。如今到了年末，回头一看，了不得，居然全错。要知道，能把这十道题全部做错和把十道题全部做对一样，都是只有非同寻常的人才能做到的。 不过，我倒不是想强调中金公司搞宏观分析的团队有多么得不靠谱，而是说，预测宏观本来就是一件无比困难的事——事实上，华尔街的分析师也好不到哪去： 股票策略师 Mike Wilson 预测，标准普尔 500 指数即将暴跌。在美国银行，Meghan Swiber 及其团队表示，要为美国国债收益率暴跌做好准备。在高盛，包括 Kamakshya Trivedi 在内的策略师都在谈论中国资产，因为中国经济终于从疫情封锁中复苏。 16 家大行对标普 500 指数到 2023 年的目标点位，预测值从 3675 点到 4500 点不等。可是结果呢，今天是 2021 年的最后一个交易日，标普最终停留位置是 4769.83。换言之，诸位大师们，全错。 所以，我最终想说明的是，我觉得对于任何一个热衷于投资的朋友，都要有着清醒的头脑，就是不要把自己对于宏观经济的判

  2023/12/31 03:04https://www.raychase.net/7492

• 音频：我不是码农，我是程序员，我和你一样，为理想而奋斗

  和不慌不 MANG 播客的主播 FANG FANG 聊了一下程序员的话题，音频放在这里。下面是 Spotify 和苹果 Podcast 的嵌入代码，国内的小宇宙链接在此。 Show notes： 02:36 “码农” 是不经意的自嘲还是妄自菲薄？ 04:45 十年前写下《致那些自嘲码农的苦逼程序员》文章的机缘 11:32 要意识到自己所讲述的故事 narrative 对自己的暗示， “自我验证预言” 与现实的交互影响 15:38 误解之一： 程序员是无趣的人？ 17:23 误解之二： 程序员的工作单调乏味？ 24:17 程序员也需要全面的能力， 写程序只是工作中的一部分 30:08《你不适合做程序员》？ 做程序员的必备特质 34:10 在转码的潮流背景下， 这些程序员的必备特质是自带的天赋还是后天可以培养的？ 37:56 “程序员需要独立解决问题，程序员解决问题不是民主选举。世界上绝大部分优秀的系统的绝大部分，总是由很少的人设计出来的” 那么作为普通程序员， 可以享受到什么样的乐趣？ 40:33 如何看待一辈子只做程序员？ 这是一种无奈的被动选项吗？还是也可以是一种认清楚自己喜好之后的

  2023/9/10 12:09https://www.raychase.net/7415

• 关于时间管理的一点新的感悟

  从读书，到工作，都离不开时间管理，我相信只要不是属于无比随性的少数人，应该都有自己的体会。因为这件事情太重要了，它贯穿于每日的生活和工作之中。好久以前就写过一点关于时间管理的体会，后来又补充了一些，现在重新开一篇短小的文字，记录一点新的感悟。 变化 随着年岁的增长，我却越来越感到时间管理这件事情在不断地变得更加重要，因为整体的事务数量和复杂度都提升了。 关于其中的原因，我仔细思考过。大致上，在年纪轻一点的时候，兴许每天需要筹划实施五件事，但是现在呢，每天需要筹划实施十件事。相应地，年轻的时候，兴许可能这五件事里面，最终能完成三件；而现在，这十件事里面，也最多能完成五件，看似完成的更多了，却留下了更多的待办事项。 那接着的问题就变成了，为什么现在的事情更多？ 一方面是因为年纪增长，本身就需要承担更多的责任，比如需要处理孩子的事情，家人的事情等等，而这样的事情简直太多了。读书的时候，虽然忙，但是事情的类型相对单纯，而现在的忙，则是掺杂了生活、家庭、工作、学习等等各种各样类型的事情。我记得有一句话说，“成年人的世界里没有童话”，繁忙就是常态。 至于另一方面，则是因为科学技术的发展，尤其是信息

  2023/8/27 13:28https://www.raychase.net/7384

• 闲聊投资：亲自体验和护城河

  闲聊一点美股投资。以前讲过一点我投资美股的原则（有些想法有了变化），今天想接着再补充说一些。 上周五的时候，和同事闲聊聊到了投资，他提到，巴菲特建议大多数人只需要买指数就好了，因为投资个股对于大多数人来说都是一件长期收益小于投资指数的事情。即便不买指数，还有那么多基金，都很方便购买——事实上，市场上大部分的资金都来自于专业机构，他们有高级的工具，有专业的人员，市场在某种程度上就是一个零和游戏，那凭什么自己做的投资决策能击败他们？如果不能，那为还不如就买相应的基金就好了。我很赞同这样的看法，可是，投资个股也有好处，其中之一就是有乐趣，可以保持自己对于经济、公司等等的敏感性，让自己持续学习。而且，如果寻找到合适的方法，散户有自己的优势，比如散户资金量小，进出非常容易，而且散户有自己的视角，而这方面如果做得好的话，也是可以获得很有竞争力的收益的。 亲自体验 谈及 “自己的视角”，那就必须要保证自己对于投资标的有着一定的认识。而要做到这一点，就必须做到 “亲自体验”，就是说，只考虑自己看得懂的，体验过的。 有很多原则和方法都在过往不断更新，比如估值，但是这一条却没有改变。举例来说，过往两年我还

  2023/7/31 12:41https://www.raychase.net/7365

• 学习 OpenAPI 的一点记录

  我记得在毕业以前，就大致明白这样一件事情，系统之间、模块之间的交互，要确定协议，要定义接口，兜兜转转这些年过去了，我觉得对这件事情认识当然越来越深刻，也说不清其中的程度。最近做的项目中，开始大量地和 OpenAPI 打交道，一方面要最先使用 OpenAPI 来定义接口，让多个其他交互的模块都遵循它来开发，就是 “OpenAPI Driven Development” 的意思，这没啥特别的；但另一方面，系统中还需要把 Protobuf 接口定义转换成 HTTP 接口定义，并实施地使用 swagger-core 来动态创建 OpenAPI Spec，这就比较好玩了。 gRPC 到 HTTP 的协议转换 先来说说这第二件，动态创建 OpenAPI Spec。我们的网关系统需要大量地涉足两种接口，一种是对内调用 gRPC 接口，需要使用 Protobuf 来描述它们；另一种则是对外开放 HTTP 接口，需要使用 OpenAPI 来描述它们。这就牵涉到了两个事情： 一个是需要设计一种机制，允许用户只用某一种描述语言（可以是 Protobuf，也可以是 OpenAPI）做出接口定义，然后这个定义会

  2023/6/18 02:01https://www.raychase.net/7260

• 一些皓哥和我的故事——谨此纪念陈皓先生

  好久没动笔了，昨日得知左耳朵耗子陈皓先生突然离世的消息，颇为震惊和难过，也感到非常惋惜。他曾经是我在亚马逊时期团队中的经理，更重要的是，他是对我在软件工程师这条道路上影响最深的几个人之一，我觉得我应该写一点纪念性的文字。 要说和陈皓的联系，大概从十来年前说起，之前也关注酷壳博客，2011 年底的时候，在南京的我我正在找工作，想去北京，我写邮件给他，附上我的简历和我当时还在 ITEye 的 blog，问他招不招人。那时我只是一个工作三年多的程序员，和我想象的不同，陈皓回邮件很快，也没有什么架子，我们来来回回讨论了不少技术问题。之后赶在年前跌跌撞撞过了面试，两月份我就加入了北京亚马逊，在一个把负责商品在欧洲进行跨国配送的研发团队，他当时是我的主管。 于是我离开南京，来到了北京，可是亚马逊业务调整，我们原有的业务线解散，在选择新团队的几个选项中，我们加入了商品的销量预测团队，这也是后来我在亚马逊期间呆了好几年的团队。在北京的时候，我们团队的氛围很好，基本上工作日每天都在中午一起下楼吃饭，时不时地大家一起打台球、楼下瞎扯淡，私下里我们称呼他 “皓哥”。 工作中皓哥努力推行的团队文化非常鲜明，给

  2023/5/16 15:39https://www.raychase.net/7297

• 入职后一些零散的感受和思考

  有些时候自己会有一些想法，但是过于零散，想把它们记录下来，可是又找不到一个清晰脉络可以把它们串起来。入职已经两周了，我还记得快要五年前加入 Oracle 的时候，我也写了一篇类似零散的文字，不过那个时候是在入职一个月左右的时候。 Facebook 的唏嘘 我记得在五年前谈 offer 的时候，Facebook（现在改名叫 Meta 了）也给了 offer，他们的 recruiter 当然是尽力试图说服我加入他们，而不是加入 Oracle。当时有一句话我依然记得，大致是说不只要看当下 compensation 的价值，要考虑到股票的潜力，因为 Facebook 的股票的潜力是 Oracle 所不能比的（北美软件工程师的 offer 往往都包含固定薪水和股票两个部分）。 其实他这话某种意义上也没错，爆发中的世界最大的 SNS 公司，当时 FB 股价 $175，一直被称作市值最被低估的 FANNG 巨头，最高涨到去年比那时候翻倍了都不止，而今年的低谷则比那时是接近腰斩，这一进一出简直太过疯狂。疫情可以说强行憋出一堆泡沫，接着就是把它们一个个刺破，那些不盈利的公司都雪崩了，大科技是最后倒下的，

  2022/11/20 04:54https://www.raychase.net/7174

• 近况更新：第三次换工作

  最近发生了太多的事情，也没有更新 blog，来冒个泡。 我基本上是一个很长时间才会换一次工作的人，说好听点就是爱惜羽毛（工作经历），注重长期积累而非短期回报，说难听点那叫懒得动弹。 记得在 2012 年初的时候，我在人生中第一次换工作，从华为跳到亚马逊，那时候我已经在华为干了三年半了，其中的主要动机一个是想开阔眼界，另一个是可以不那么辛苦。 接着就是 2018 年初，在亚马逊干了六年之后，第二次换工作，从亚马逊跳到甲骨文，主要动机有两个，一个是我想在职业生涯有个突破，去参与云计算的浪潮；第二个是我觉得当时我的薪水已经严重偏离市场能给我的待遇了，所以想去谋取一份更合理的薪水。 这一次，在甲骨文干了 4 年 9 个多月，第三次换工作，下一站是一家相对较小的公司 DoorDash。这次的主要动机有三个，一个还是职业生涯方面的，如今干的事情越来越偏离我认为工程师最应该干的事情，做很多的 process management，很多的协调和扯皮，很多的项目和任务管理，以及很多的 ops，而在技术方面也缺乏足够多有意思的挑战；第二个则是在 compensation 方面遭遇了一个出乎我意料的大 cl

  2022/11/7 05:00https://www.raychase.net/7150

• 常见分布式应用系统设计图解（十五）：支付系统

  支付（Payment）系统可以很复杂，比如可以和银行打交道，和信用卡系统打交道。如果我们考虑用户在一家电商买东西，在结账的时候，借助电商支持的支付系统（Payment Service Provider）来完成支付行为。 支付系统需要结合商家（包含卖家和买家）一起来看。最典型的一种需求是，卖家在电商网站挂了东西卖，买家挑选了货物，结账并支付，电商依赖于支付系统来完成支付，并通知买家支付成功。 图中用两条虚线分隔出了 3 列，最左边是用户，中间是电商系统（比如 Amazon），右边是 Payment Service Provider（PSP，比如 PayPal）。支付操作需要保证幂等性，从而在重试的过程中保证不会被重复扣钱。 有的电商自己会存储用户具体的支付信息，比如信用卡信息和银行账号信息，但是这样的数据管理成本由于安全需求的原因非常高，因此也有很多电商省掉这个麻烦，选择让 PSP 来管理。图中就是对于这种情况的示意。 图中用户在 checkout page 结账页面，store 向 PSP 发送一个 registration 请求，得到一个 token，这个 token 就可以后续用来

  2022/9/3 14:10https://www.raychase.net/7140

• 常见分布式基础设施系统设计图解（八）：分布式键值存储系统

  Key-value 存储系统大概是分布式存储系统中最常见的一种类型了。从功能需求的角度说，最核心的包括： 可以创建一张表和删除一张表，同时对于表的数据可以进行： 读，即 get(key) 返回 value 写，即 put(key, value) 删除，即 delete(key) 当然，也有一些其它的功能需求，比如支持事务性，支持 key 排序查询，range key 或者特定列索引，支持同一 key 下 value 的 version 等等。 从非功能需求的角度说，凡是存储系统，Durability 是最重要的，数据不能丢失；其次是 Availability；再次是 Performance，这样的系统需要考虑 throughput 和 latency 二者。 宏观上看，实线是数据流，虚线是控制流。 get 或是 put 请求被发送到 Request Manager（Request Dispatcher），而 Request Manager 会询问 Metadata Service 来获知这个请求应该被送到哪一个 Replication Group 去。 每一个 Replication

  2022/8/28 02:21https://www.raychase.net/7121

• 常见分布式应用系统设计图解（十四）：日志系统

  典型的互联网应用的日志系统，从功能需求上看主要包括收集，存储和分析，以及展示这样三个部分，因此整个系统我觉得也可以按此思路大致可以分为三个部分： 日志收集，从宿主机上采集业务应用的日志，发送给远端的日志系统； 日志存储、分析和后期处理； 日志查询和分析数据展示。 非功能需求方面，我觉得可以考虑这样几个要点： Durability：这是最重要的，尽可能不要丢失日志，到服务端的日志不要丢，在客户端的日志，也是如此，即便服务端不可用或连接断开，客户端的日志也要保存在本地。 Availability：其次是可用性，要保证高可用。 Performance：相较来说，日志系统的 performance 主要是吞吐量而非延迟，而且网络带宽需要特别算一下。 Scalability：业务应用增减引起的 scale 变动会非常频繁。 图中虚线为控制或辅助的逻辑，实线为实际的日志数据，或处理过的日志数据的流向。 客户端日志需要分片，日志的客户端采集和处理策略存储在客户端，可以通过配置文件修改，或者通过一个第三方的系统统一将数据同步过去。 本地的分片日志经过部署在客户端宿主机上的 Log Collector

  2022/8/15 01:21https://www.raychase.net/7087

• 再谈谈互联网外企在中国的失败

  最近亚马逊将要关闭 Kindle 中国区业务的新闻唤起了我的感慨，这则新闻在朋友圈刷屏了。这件事情作为触媒，让我联想到很多东西，我就想，要不然理一理思路，写一点东西吧。 这件事情，基本上就是说，亚马逊宣布将于一年之后即 2023 年 6 月 30 日，在中国停止 Kindle 电子书店的运营，被媒体称作 “时代的眼泪”。众所周知，亚马逊曾经也在中国有着雄心壮志，不可谓目光不长远。建仓储和物流的基础设施，要与淘宝一争高下，可如今只能灰溜溜地撤出了原本在中国主营的零售业务，只留下了跨境电商，令人唏嘘。 我在 2012 年初以软件工程师的身份加入了亚马逊，一直到 2018 年初离开。很喜欢亚马逊的工程师文化，也很喜欢亚马逊在云计算的野心。即便抛开这个特殊的身份，我一直很喜欢在亚马逊网站上买东西，可能是因为我是一个程序员，亚马逊网站清楚、简洁，质量有保证，退货零担忧，只要不去计较那三块五毛的零头钱，简直是省心的典范，于是我就一年又一年地心甘情愿地交着 Prime 会员费。 但是，它在中国的发展，我却一直都不看好，而且这个 “不看好” 并非针对特定的一家外企，而是全部这些互联网巨头们。在 201

  2022/6/5 10:30https://www.raychase.net/6974

• 软件工程师成长的一个误区

  挺久时间没有更新了，最近脑海中有几个化为文字的想法，但是都比较散，也就没有落笔。不过忽然有一个念头冒了出来，就是这些想法里面，有几个其实都是关于软件工程师成长的一个 “误区”。可以说，从 2008 年步入职场以来，这个误区导致的坑，或早或晚我踩过不少，我觉得把它们总结一下，写出来，兴许能给一些朋友们带来一点帮助。 “我对技术感兴趣，我只想做技术，走技术路线。” 这句话是不是很听过呢？请不要误会，这句话本身没有问题，但是说出这句话的软件工程师中，十有八九有一个误区，就是高估了技术本身在个人职业生涯中，起作用的占比。而我，曾经是其中之一。 我多次听到来自家长这样的评论，说是他/她的孩子不善言辞，缺乏沟通技巧，然而罗辑思维缜密，对于软件技术充满热情，想做一个出色的程序员。 我觉得，这样的言论，既对又不对。对的是，如果刚踏入职场，相当一个优秀的程序员，我觉得上述的优缺点，都很 “契合”，或者说，也许只需要学好技术，把确定的任务做完、做好，就能找得到工作的褒奖，就能胜任岗位。但是，随着你继续在职业生涯的道路上向上突破，基本坚定地走着技术通道（譬如我），上述能力的缺失，而造成的 “短板效应”，会越

  2022/5/9 13:51https://www.raychase.net/6965

• 英文能力与独立思考

  好久没动笔了。 在 2015 年和 2012 年的时候曾经写过一点对于英语学习的认识，在那以后，我对于它的认知也在不断进化，今天我想稍微再写一点。比较起来，如今我印象最深的一点是，英语对我影响最大的，还并非关于信息的获取，而是在日益熟练的情况下，对于更多独立思考的促成。 首先，什么才可以称之为 “熟练”？ 是不是英语考试考高分就是熟练了？是不是掌握一万个词就是熟练了？是不是可以无字幕看美剧就是熟练了？是不是可以流利对话就是熟练了？是不是中文说得好好的，因为号称 “用英文思考” 的关系，隔三差五地蹦出几个英文单词就是熟练了？ 我觉得都不是。 顺带地，我想吐槽一下上述最后一种情况。我见过的凡是中文是母语的，讲中文的时候，英文单词乱蹦的，基本都是英文说得谈不上非常流利的。第二语言英文流利到能够比较接近母语的程度，反而中文英文使用的场合分得清清楚楚，才不会大量混合使用。从我自己这个兴许不够客观的角度来说，在合适的场合讲好自己的母语，尽量不要使用其他人不熟悉的英文单词，也算是一种礼貌和尊重。 回到前述的话题。这个可以说是 “熟练”，甚至 “相当熟练” 的阶段，我觉得可以这样表述：在这个阶段，对于

  2022/3/7 12:29https://www.raychase.net/6902

• 我的美股投资原则

  说起美股市场，和 2020 年相比，2021 年真是动荡的一年，起码对我来说是这样。还记得年初的时候我写了一点心得，现在到了年末，我想接着聊一下。在不断地学习和实践中，我也逐渐形成了自己的一套小小的投资体系，其中最重要的是几条选股和投资的原则，虽说这个过程可以说相当崎岖。 市场上有无数的方式可以赚到钱。我知道美股市场上有两大类人，一类是分析基本面的，一类是看技术指标的。这两类人都能取得成功，但是做法却大相径庭。前者在标的大跌的时候往往会分批加仓，而后者则在跌破一个位置后止损离场。我两种思路都尝试过，但是对我来说，经过实践，明显还是前者更加适合我。因此下面我说的，都是奔着长期投资的思路来的，仅供参考，未必适合你。 选股和投资原则 我们在生活中不要吹毛求疵，但对于选股来说，却要挑剔，非常挑剔，永远抱着 “宁可错过” 的态度，去寻找自己最置信的，被当前市场所错杀或尚未被足够认可的生意。 1. 做自己熟悉的标的，有一套系统的估值体系。 自己要熟悉，这可以是因为自己对于目标公司的生意有过研究，或者是自己使用它的产品等等。2022 年除了大科技，我还看好医疗板块，但我对这部分领域不熟悉，我就只能避

  2022/1/1 13:13https://www.raychase.net/6846

• 2021 年旅行的简单回顾

  水文预警。 有段时间没有更新了，今天打算来写一点，本来想写写一年的回顾的，可想想似乎今年似乎内容并不丰富，印象最深的除了疫情就是旅行了，那就干脆随便聊聊今年的旅行吧。要说到这一点，主要原因还是因为去年疫情憋得太久，去年一整年，加上今年的上半年，直到 5 月中旬，印象中除去短程的、当天来回的郊游以外，只在夏天的时候全家搭帐篷在营地过了一夜。作为一个非常喜欢出去 “跑路” 的人来说，以往每年都要出去三、四趟，去年这一年多真的是太不寻常了。 我理解为了疫情控制的原因要减少非必要的旅行，但我本人还是非常反感一刀切 “杜绝” 人口流动的。所有的出行活动都有风险，但是为了避免冒险天天宅在家里也真不是一个好主意，我一直在寻求这其中的一个平衡点。今年 5 月初我完成了两针辉瑞疫苗，在这两周以后就开始陆续旅行了。无论去哪里，我还是尽量避开人口密集的室内场所，因此总的来说，自然景观接触得多一点，人文景观接触得少一点。以往很喜欢的各种类型的博物馆，这次也去得不多。 旅行其实并不是一件完全放松的事情，或者说，起码对牵头的那个人不是。规划行程是一件辛苦活儿，不过我还是比较能够乐在其中的。我的习惯是，在出行的一个

  2021/12/27 14:07https://www.raychase.net/6827

• 眼界和边界

  极客时间四周年的时候搞了个活动，让作者们都写一点最近的思考，我想了想，就写了一些关于 “眼界” 的。这个话题其实我以前也有写到，但是随着阅历的增加，这个词正变得越来越重要。我写的那几段话是： “每个人都有自己不同的能力和特质，有的是先天具备的，比如有的人天生就记忆力出色；有的是后天努力的，比如通过坚持不懈的奋斗做成一件大事。可是，有的特质却既非先天可具备，又非后天可努力得到，在我们朴素的教育背景中，它们往往总被忽略。它们的其中一个，就是眼界。在投资领域，大概有这样一句话，把一个问题如果放到十年、二十年的维度上去看，问题就会简单很多。倒不是说要宣扬佛系心态，而是说，要有够大的眼界，能够 ‘忽略’ 掉那些纷纷扰扰的细枝末节，而专注于主要的因素。” “毕业工作以来，随着经验的积累，我的心态也在不断变化。在我刚踏入职场的时候，我对自己特别自信，我相信自己具备足够的天赋能够成功；几年之后，我觉得自己通过坚持和努力能够做到自己梦想的事情；而现在，我越来越觉得，眼界，似乎是它才能决定一个人长久职业发展的天花板。一些人能够做到足够大的事情，一个必不可少的原因是他们其实本来就已经站得够高，本来就见过很多

  2021/10/11 05:54https://www.raychase.net/6770

• 多吹牛，少写代码

  来，说点大逆不道的。 代码是程序员的基础能力，毫无疑问。Linus 说，“Talk is cheap, show me the code.”。软件工程师，归根到底是要做工程的，代码写不好，就谈不上把工程做出来。 可是我觉得，越来越多勤奋的程序员，是写代码写得太多了，而不是太少了。 胡扯！读书百遍，其义自见。书山有路勤为径！代码也是如此，没有足够的积累，怎么能写得好代码？ 可是，写代码真的需要那么勤奋地练习，那么大量的积累吗？ 我想说一个现象，那就是很多公司每年都会举行调研，一个很常见的问题是，作为程序员，一年工作时间里面，写代码的比重有多少？ 有一个很朴素的想法，就是如果编码时间的比例不足够高，那基本上就意味着程序员的时间都用去扯皮、流程，或者 ops……总之就是做一些内耗严重而缺乏实际产出效率的事情。进一步地，很多程序员就会抱怨，我想写代码，我不喜欢开会，不喜欢搞流程，不喜欢项目管理和人员管理。 可是，这真的 “正确” 吗？ 来看看所谓的软件工程师的基础素质里面，写代码占了多大的比重？沟通、合作、学习，问题分析、解决，系统设计、算法，代码实现、测试、ops……到底有多少部分是 “写代

  2021/6/28 03:36https://www.raychase.net/6634

• 曼联，索尔斯克亚，2020-2021 赛季

  好久没有写一点关于曼联的文字了，上次已经是 2019 年年初了，作为一名铁杆曼联球迷，这期间倒是一场比赛都没有落下过。我看比赛已经过了十多年前那样尽量看直播的阶段了，如今虽说一场不落，每一场却只看录播。老实说，对我来说这很舒服，我可以跳过那些没有营养的赛前、中场休息等等环节。 这过去的一年里面，大家的目光和注意力都被疫情打击得面目全非的英超比赛形式给吸引了，譬如反复的延期，疯狂的赛程，以及缺失的场内观众。但是对于很多球队来说，这既是机会，也是挑战。我猜想今年暑期的转会市场，应该不会再有那些疯狂的转会大单了，疫情导致的球会损失将使得大家花钱都更谨小慎微。从长远来看，我决定这其实是好事，资本的力量很强大，但是资本也往往会冲昏很多人的头脑，那么今年夏天，正好冷静一下，看看球队的哪些位置是最迫切需要进补的。 对于曼联来说，过去的这个赛季，无疑是有些复杂的，总的来说，可以认定它是一个成功的赛季，但如果以奖杯论英雄，拿出过去的成就簿一番，也可以说，“喏，比比看，实不怎么样”。截止今天，还有最后一项欧联杯可供争夺，如果它也失手，那就可谓四大皆空的赛季了，但即便夺冠，恐怕一欧联杯的冠军，其分量也足以让

  2021/5/19 21:42https://www.raychase.net/6539

• 新写了一个极客时间专栏《技术面试官识人手册》

  最近 blog 没怎么更新，是因为忙于写一个新的专栏——《技术面试官识人手册》。 你有没有听过这样一句话，“招聘是研发团队日常活动的第一要务”。这么说并不夸张，做好面试，匹配到合适的优秀人才，是组建高效能团队的大前提，这会大大降低后期的管理成本。 通常来说，技术面试的环节更多，难度更大，主导或者参与的过程中，你或多或少会遇见这样的问题： 作为技术组长，手中项目急缺人，如何快速补齐岗位？ 招怎样的人好，是能立马干活的，还是有潜力的？ 技术面试应该怎样问系统设计问题？ 是不是拿算法题让候选人做就好了？如果他恰好做过这个题目怎么办？ 如何综合团队视角，评估候选人水平，决定其去留？ 这些问题都是团队 Leader 的切身痛点，也是众多技术骨干晋升后所面临的第一关。而市面上有关候选人面试的资料，你随便一搜就能找到大量的刷题经验以及 “面霸” 分享，但从面试官视角系统、完整讲解如何主导技术面试的内容却非常少。 课程设计包括这样三个部分： 面试准备/计划篇：面试前，解决软件工程师的面试方案、策略问题，和你探讨应该覆盖哪些面试角度，以及面试官该怎样去设计面试题。 面试进行/实践篇：面试中，结合实例剖析

  2021/4/14 23:24https://www.raychase.net/6529

• 美股市场上学到的道理

  我不知道有多少朋友和我一样，业余搞一搞股票，觉得生活很充实。但是作为典型的散户，或多或少都有着韭菜的特质，在股市里面折腾，做出一些成功的决策，然后得意；或者做出一些失败的决策，然后后悔。 事先声明，我持有美股股票好多年了，但是正儿八经 “玩” 美股其实没多久，下面记录的是一些我自己的心得体会，仅此而已。 1. 把最多的时间花在寻找和研究一个好生意上面，而不是花在用技术去分析那些自己不了解的股票上面。 我觉得这是最重要的一条。我觉得，和机构和庄家比，散户们总是在弱者一侧，他们有强大的工具，有灵通的消息，有快速的执行，有理性的规划；而散户呢？这些什么都没有，散户有的优势，可能就是特定某一方面，或者某些方面具备的 “眼光”，这种眼光未必总是正确，但是如果能保持独特，做交易就比较能够赚钱了。 举例来说，我是一个十多年的程序员，我对于科技行业，特别是互联网行业相对比较熟悉，观点和思考也比较多，那么我就可以从从中找到一些尚未被市场足够认可的好生意，了解清楚以后，这方面的投资胜率可能就会高一些。每个人的投资风格不一样，我比较喜欢去寻找那些有颠覆性的生意，如果还有一定的护城河，那就很好了。 当然，寻找

  2021/2/14 12:54https://www.raychase.net/6470

• 常见分布式应用系统设计图解（十三）：短网址系统

  短网址系统可能是最常见的分布式系统设计问题之一了，本身从业务需求上说，读远多过写，而且数据结构确定且简单，数据量小，还易于使用缓存，因此本身难度在分布式系统的问题里面算是比较低的。另外，这个系统本身 “分布式” 的特性也比较弱，而且从组件图的角度来说，没有多少是 “可画的” ，因此之前也就没有介绍它。不过后来我改变想法了，我觉得还是可以总结总结，特别是可以把一些相关的特殊需求考虑进去。 短网址服务就像是 bit.ly 这样的，给一个长长的 URL，它给你吐出一个较短的 URL，往后访问这个 URL 就可以做到 302 重定向到原来那个长 URL 了。 图中上半部分是写的部分，无论是 API 直接调用还是通过某一个 UI 去调用，Write API 会进行鉴权操作。另外，如果源 URL 已经是经过短网址服务处理过的，就需要返回失败，否则就陷入了一个递归服务的窘境。 其中写部分的 Cache 是用来防止一些过度的访问，比如由于某种原因，短时间内对某一个特定 URL 来生成短网址的请求特别多，那么就可以通过它来发现并阻止。 Key Generator 用来生成短网址中变化的部分（key），这

  2020/12/29 07:46https://www.raychase.net/6460

• 常见分布式应用系统设计图解（十二）：证券交易系统

  这篇讲的是证券交易系统，这类系统包含的内容很多，但是我们还是把目光放在核心的交易部分，比如说股票交易。在某个可交易时间，如果卖家 A 要以至少 y 的价格卖掉股票 x，卖家 B 愿以至多 y 的价格买入股票 x，那么这个交易就可以发生。 虽说是交易系统，但是它和任何一个支付平台的交易系统有着显著的不同，它的核心是一个竞价匹配的机制，而非货币支付的机制，简单地说，这个机制包含了这样四个步骤： 挂单（可以是买单，也可以是卖单） 匹配（或者叫做撮合） 成交 清算 从非功能的角度看，有这样几条需求是这样的系统尤其要强调的： Consistency，从单个交易的角度来说，主要就是事务性，这是交易系统最最基本的要求。系统不能用了是个灾难，但是如果交易数据错误了这就是个大得多的灾难。 Durability，交易数据必须要持久化。 Throughput，很多股票市场都是对全球开放的，吞吐量意味着对于交易高峰的接纳能力。 Latency，和吞吐量关系密切，可以放在一起讨论。大型交易系统的延迟的最小单位都是按微秒论的。从架构上看这类系统具备一些异步系统（比如下单支付系统）的特点，但是低延迟的要求决定了它的

  2020/12/27 02:09https://www.raychase.net/6453

• 常见分布式基础设施系统设计图解（七）：分布式实时流处理系统

  今天这篇是关于实时流处理（real-time stream processing）的，这一类的系统这几年比较多了，但相对而言并没有之前提到的几类基础设施系统常见。为什么说这类系统如今更为常见呢？因为一般说来，或者说曾经有一个普遍的认知，就是 throughput 和 latency 难以兼得的事实： 同步系统适用于响应实时性要求高的请求，处理实时性要求高的数据，速度快，处理过程中关注的数据粒度小，吞吐量也相对受限； 异步系统适用于响应实时性要求低的请求，处理实时性要求低的数据，处理过程中关注的数据粒度大，但是吞吐量往往要大得多。 可是，越来越多的系统需要大量的数据处理，往往需要上面二者 “鱼和熊掌兼得”，或者说，至少能够达成一个很好的平衡。分布式实时流处理系统就是这样的一个典型。 总的来说，流处理系统，都可以视作从一个基于消息队列的 pub-sub 系统演进而来的。实际应用方面，其实有很多例子。比如实时的数据分析，带有机器学习的日志分析。通用框架的话，像 Apache Storm 和 Spark Streaming 都属于这一大类。 上面这张图简单表示了其中的一种典型的组件分布，上半部

  2020/11/20 07:11https://www.raychase.net/6444

• 常见分布式应用系统设计图解（十一）：数据监控系统

  这篇是讲数据监控系统的，常见的包括 Datadog 和 Prometheus 等等。一个比较完整的数据监控系统要包括数据采集和数据展示两个部分。在此基础上，还可以具备告警和其它数据处理的功能。 对于监控的数据， 通常包括两类，一类是操作系统层面的数据，比如 CPU、内存、IO 等等；还有一类是应用相关的数据，这些数据就具备明确的业务意义了。 大体上，图中虚线表示控制流，而实现表示实际的统计数据流向。 用户通过 Web UI 来查看数据、定义规则，这些元信息存储在图中上方的元数据库中。 Cluster Manager 和不同集群内的 cluster agent 通信，agent 通过心跳的方式和 manager 保持连接。 每个集群中，每个节点都有 node agent 负责采集数据，并将它们汇报给 cluster agent，cluster agent 汇总后写到一个队列中，也可以使用专门的数据流处理服务，后者实时性更高。 这个队列或是数据流有多个订阅者，它们从中读取数据并执行相应的操作，比如生成压缩数据，或者生成时序数据。 时序数据既可以被用作主要的数据展示数据来源，又可以被 Mon

  2020/11/18 05:37https://www.raychase.net/6439

• 常见分布式应用系统设计图解（十）：电商秒杀系统

  这篇是关于电商平台秒杀系统的。 首先，我觉得 “秒杀” 是一个中国色彩浓重的词，这样的概念在西方电商系统中也有，但只有在中国，本来业务量就已经如此之巨大了，还将其如此发扬开来。因此顶尖的秒杀高并发场景，还真是基本上只有在中国的电商平台系统中，才能见得到。 其次，我觉得对于系统设计的学习，电商秒杀系统这样的极致，即便再精彩，还是应当放在第二位的。扎扎实实地把常规的高并发系统设计做好，才是最重要的。因为无论秒杀系统使用怎样的特殊技巧和手段，高并发分布式系统才是一个秒杀系统工作的根基。 有了以上说明，现在再来谈论电商秒杀系统。电商秒杀系统，它首先是一个电商系统，因此一个大型的电商系统一般要至少包括这样几个功能： 商品浏览 商品入购物车 下订单 结算支付 因此，对于上面这张图，先从电商系统的角度来看。为了实现电商系统的基本功能，应该具备这样几个服务： Product Service，包含产品元信息。 User Service，包含用户信息。 Storage Service，包含产品库存信息。 Payment Service，提供专门的支付服务。 Order Service，订单服务。 当然还有

  2020/11/17 03:11https://www.raychase.net/6434

• 常见分布式应用系统设计图解（九）：协同编辑系统

  这里讲的 “协同编辑”，指的是 “Collaborative Editing”，多个人同时一起编辑同一个文件，比如说 Google Docs，国内的有有道云协作、石墨文档之类的。这样的系统倒不如我们前面提到的那些应用系统那么 “火”，但是，依然具备相当的典型性。 第一印象，这样的一个系统，我们可以简单做出如下归类： 这是一个文件编辑系统，这是最最基础的一个功能性需求，它就好像是 Windows 下的记事本，只不过它是在线的。 这是一个分布式系统，客户端/浏览器可以在不同的地方，通过网络和服务端联结，用户的编辑行为转化为请求发送给服务端。 这是一个异步系统，编辑编辑过程中，事件都是由不同用户的浏览器/客户端上对文件的来触发的。 因此，根据上面的三条，我们可以 “没什么新意” 地归纳出一些相应的需求和限制，不过，这个系统里面还隐含了这么几个特殊的要求： 自动保存：所见即所得，所见即所存。因此文件的变更需要自动同步到服务端保存，并且显然一般情况下，这是一个增量同步。这个增量同步是双向的，既有客户端到服务器，也有服务器到客户端。 冲突处理：在多数情况下，系统要能够自动处理合并多人对于同一个文件

  2020/11/13 01:14https://www.raychase.net/6429

• 常见分布式基础设施系统设计图解（六）：分布式 MR 系统

  其实对于 MR（Map Reduce）系统来说，可能更重要的是分治和分步处理的思想，因为现在的基于 MR 的数据处理框架或者平台，在实现上数据处理往往已经和最经典的对于 MR 的理解（最早应该是来自 Google 的那篇论文）有了不少区别。当然，我还是按照之前的做法，把一个典型的 MR 系统简单图示画出来了，这个图相对比较简单。 还是老规矩，虚线表示控制流，实线表示数据流。 上半部分用户向 Master 这个 job 管理节点提交一个 job 的请求，这个请求被拆解为若干个 task，下半部分的 slave 节点完成 task 的跟踪和执行。 具体执行逻辑上： 首先的输入文件，可以是多个已经拆分了的小文件，也可以是一个大文件，但是支持随机块读取。这个文件存储系统可以是 HDFS，也可以是 S3、GFS。 输入文件的每一个 split 块被读取到每个 Mapper 上面去，Mapper 按照规则对数据进行映射转换。 在 shuffle 阶段，数据根据 hash 的归类规则被投递到相应的 Reducer 上面去。 在 Reducer 上，数据被 reduce 成为最终结果的一部分，并写入输

  2020/11/3 02:17https://www.raychase.net/6422