2025-06-24 07:14:49
读一本好书，就是和许多高尚的人谈话 - 歌德
第一次听闻李飞飞的名字，是在 2013 年与前公司 CTO 的中午干饭闲谈中。 彼时他正深耕 CUDA 并行计算领域，反复提及 ImageNet 竞赛与 AlexNet 的突破性表现， 而我对这场即将席卷全球的深度学习革命尚处懵懂——当时全身心投入业务系统优化， 面对「算法黑箱」既无暇探究，更难预见其对技术世界的重构力量。
如今读到李飞飞自传，方觉这场对话暗藏玄机：那个曾被视作实验室小众技术的计算机视觉项目， 竟成为改写 AI 发展轨迹的关键节点。在学科交叉处开疆拓土的战略眼光，在技术拐点期破除质疑的前瞻判断， 以及贯穿始终的"北极星"式价值锚点——这些要素如何在特定历史坐标中交汇， 最终塑造李飞飞成为改变机器认知方式的科学家。
李飞飞的成就源于多重维度的深度交织。其科研旅程始于对世界本质的探索欲。父亲带她 观鸟、捕捉昆虫的经历，在她心中种下好奇的种子，而母亲引导的跨学科阅读（涵盖海洋 生物、机器人、神话等）则拓宽了她的认知边界。中学时期她对航空航天等冷门领域的痴 迷，更展现出对抗性别偏见的独立思考能力。这种探索精神在普林斯顿大学攻读物理学时 得到深化，她将物理视为「西方科学最高深的创造性学科」，以此锤炼逻辑思维。这种对 知识本质的追求，成为她转向人工智能研究的底层动力。
逆境中的韧性塑造了她的核心竞争力。移民美国初期，语言障碍与经济压力如影随形。她 通过多重兼职（中餐馆打杂、家庭保洁、干洗店经营）维持生计，却仍以 SAT 数学满分的 成绩进入普林斯顿。更艰难的是母亲重病期间，她在手术室旁穿着隔离服完成学业，同时 充当医患翻译，展现出极限压力下的抗压与时间管理能力。外界质疑（如教师贬低女性数 理能力）反而强化了她「超越现实障碍」的信念。
顶尖平台的阶梯式跃迁为研究提供了关键支撑。普林斯顿时期奠定其学术基础，并促使她 转向计算机科学。加州理工学院攻读博士期间，她选择当时冷门的计算机视觉方向，在神 经科学与 AI 的交叉研究中确立「让机器理解人类视觉世界」的核心命题。斯坦福大学时 期，她创立人工智能实验室（SAIL），将 ImageNet 从构想变为现实。后续在谷歌的产业 实践，则加速了技术落地与应用转化。
把握技术拐点的决断力最终引爆突破。2006 年 AI 寒冬期，创建海量数据集被视为「学术 自杀」。面对终身教职可能受阻的警告，她创新采用亚马逊众包模式，发动全球数万人协 作标注，解决人工需耗时百年的难题。2012 年 ImageNet 竞赛中，GPU 算力支撑的 AlexNet 以压倒性优势胜出，验证了数据驱动路线的正确性，直接推动深度学习革命。
李飞飞独特的 AI 哲学观始终指引其技术路径。她批判当时学界对算法的过度专注，提出 计算机视觉的瓶颈在于缺乏「视觉常识」。ImageNet 的构建（1500 万图像/2.2 万类别） 本质是为机器建立认知世界的「视觉图谱」，其初衷是赋予 AI 感知现实的能力，而非单 纯追求技术指标。这种将人文认知融入技术设计的理念，后来成为斯坦福「以人为本人工 智能研究院」（HAI）的核心理念。
李飞飞的成长轨迹为家庭教育提供了深刻启示：她的父母并非教育专家，却以最朴素的方 式践行了「守护好奇心」与「培养独立人格」的核心理念。
关注孩子对自然世界的探索。父亲是李飞飞科学启蒙的「引路人」。他带着女儿在成 都街头观鸟、捕捉竹节虫、观察水牛，将自然视为开放的实验室。这种实践教育不仅培养 了她对生命现象的敏锐观察力，更塑造了「提问—探索—验证」的科学思维雏形。当同龄人 被规训于课本知识时，李飞飞已通过昆虫的复眼结构理解光学原理，从鸟类迁徙模式感知 生态系统的复杂性。这种源于真实世界的认知体验，远比抽象概念更深刻地影响了她日后 选择计算机视觉作为研究方向的决策。
母亲则是李飞飞精神世界的「守护者」。面对中学教师对其阅读《不能承受的生命之轻》 等「非主流书籍」的质疑，母亲断然反驳：「我的努力只是为了成为更好的自己」，并以 此教导女儿不必迎合外部标准。这种教育哲学解构了传统权威的绝对性——当老师公开 贬低女生数理能力时，母亲的态度成为李飞飞对抗偏见的心理支柱：「他们无法阻止我在 这里上场参赛，我暗下决心，一定要赢」。更关键的是，父母始终以行动传递价值观：在 移民美国后陷入经济困境时，他们拒绝向现实妥协，反而将生存压力转化为家庭凝聚力， 让李飞飞在干洗店账本间隙研读学术期刊成为可能。
回归到教育的本质 - 培育「反叛的底气」。20 后是 AI Native 小孩，需要去成功 AI Master 而不是 AI Slave，不要去被 AI 替代而要不 AI 赋能，很大的一个要点是要有 独立思考能力，有思辨、批判精神，从而去指挥 AI。李飞飞父母的教育智慧，在于将 探索精神与批判性思维内化为孩子的生存本能。他们既不刻意塑造「完美人设」，也不焦 虑于短期得失，而是通过持续支持孩子的兴趣选择（如允许剪短发、痴迷航空航天设 计），让独立人格在真实生活场景中自然生长。这种教育模式的当代启示在于：真正的素 质教育不是资源堆砌，而是父母能否在物质匮乏时仍坚持精神富养，在世俗标准前守护孩 子的独特性。正如李飞飞在 ImageNet 项目受质疑时所展现的韧性，其根源正是童年期形 成的「质疑—坚持—突破」的行为模式。
李飞飞在自传中反复提及指引她前行的「北极星」—— 一种超越短期利益与外界评价的内在驱动力。对她而言， 这颗星是对知识本质的追问与对人文价值的坚守的融合。 从成都街头的观鸟少年到斯坦福实验室的领航者，她始终以「探索未知」与「服务人类」 为双轴校准方向：在华尔街高薪诱惑前，她选择回归科学本心；在算法主导的 AI 浪潮中， 她坚持构建让机器理解现实世界的视觉常识库；当技术突破引发伦理争议时， 她强调「AI 的胜利必须是人文的胜利」。这种贯穿始终的清醒， 源于父母传递的价值观——母亲病榻上的灵 魂拷问「人工智能还能如何帮助他人」，最终化作她推动医疗环境智能研究的持久动力。
真正的北极星，从来不是某个具体目标，而是驱动人穿越迷雾的底层信念： 对李飞飞而言，那是永远追问「为什么」的好奇心，与永远不忘「为了谁」的责任感。
2025-01-11 13:52:48
地球不停息绕太阳一周，时光交替中，我们与生活擦肩，带着过去的记忆，迎接未来的未知。
去年，我给自己设立了一个关于生活的目标：家庭和陪伴。其中，一项是「高质量陪伴」，而另一项则是“学会摄影糖水片”。每次出行时，我希望通过照片记录下光与影的交织，捕捉那一瞬间的温度。今年，这个部分的主题便是 - Show me your photos。
2024 新年伊始，海边的灯塔。
春寒料峭，拎着一个喜气的龙灯出来转转。
从烟火气潮汕到宗教多元的泉州。
京都清水寺，小朋友许了一个有禅意的愿：我希望佛天天开心。
丽水，浙南梯田
壶口瀑布，红旗招展，黄河怒吼。
迪士尼，年末的花火。
草原上的加特林烟花。
去年，我从一名探索者转变为有组织推进系统演进的人。在年初的时候，我甚至隐隐觉得大厦的框架已经显现，接下来就是持续建设，让飞轮稳步前进，甚至开始规划探索 AIGC 上的一些新方向，想要在这个领域找到新的突破。
然而，现实很快给了我一个巨大的逼兜。随着 AIGC 急速发展，见证历史的同时，也面临着算力需求的剧烈增长。一波又一波的压力压下来，新需求和旧债交织在一起，给基础设施交付带来了巨大的挑战。这期间几位在这个领域的核心同僚几个月内相继离开。人走了，工作还得继续做。从 6 月份开始，我便与一群兄弟们直接走上了战场。
我甚至感到自己一度快要被压垮了，写了一系列关于「死亡行军」的故事。
痛苦总是让人深思，尤其在那些看似无法承受的时刻，它反而带来了更多的洞察。一切接近触底时反而能迎来反弹的力量。有一个瞬间我终于明白，问题是阶段性的，真正在持久修炼的是正面看待问题和以清明的心态面对困难的内心力量。
无需惧怕外界的评价，也不必厌倦合作中的复杂性，现状和问题本就存在于那里，解决的方案并非高深莫测，关键在于直面问题本身。保持平和的心态和现实的预期，便能在混乱中看到问题的根源，在困难中捕捉到机遇，在当下洞察到未来的可能。真正的力量，是从每一次挑战中提取智慧，从每一个困境中找到前行的勇气。
摄于苏州美人腿附近
今年被工作挤占了几乎所有的时间，也导致业务已经没有精力产出内容。只有两个很小的产品。
dbml-editor ，一个免费的 DBML 在线编辑器。
random-apple-music 是一个播放列表，随机挑选 Top250 的豆瓣音乐专辑，并且可以一键跳转到 Apple Music 播放。
今年在 X（Twitter）上面的最受欢迎的内容是：
今年，买了 Boox 文石之后，读书量一下子就上来了。总共读了 34 本书，大多数是非虚构类书籍，其中有 10 本我给了 5 星评价。Kindle 离开中国，只能拥抱微信读书。虽然无法拥有实体书，但读书成本大大降低，每月上传两本书，已经足够了。更有意思的是。我也逐渐改变了对听书的看法，曾经对它嗤之以鼻，但现在，我发现做家务或者在路上听书，成了提高大脑利用率的好方式。
太牛了，原来演员的词几乎不用改就能直接用。
妙趣横生。
华为的经营哲学与阿里巴巴的"六脉神剑"在客户至上和目标导向上有共通之处。尽管理念相似，但华为的手册缺乏案例支撑，而企业文化往往是在解决实际冲突中塑造的。书中强调的几个关键点，如明确方向、专业精神、执行力和自我批评，对企业成长至关重要。华为从网络设备市场起步，现已成为多元化的科技巨头，其硬件基因可能助其稳健发展。相比之下，阿里巴巴等互联网公司近年来在资本市场的表现略显逊色。
很推荐，讲述了宇宙的起源，生命的诞生和演进。让我想起了小时候看的一部纪录片，宇宙与人。如果有时间的话，我想仔细研究里面的术语，囊括了宏观物理、微观物理、化学、生物。
武林泰斗亲自下场，给新人们介绍秘笈心法。之前读论文比较枯燥，一些知识和细节理解不连贯，借本文可以梳理脉络。 关于 Transformer 注意力机制介绍的比较少，好在热心的读者评论里面提供了更多信息。
这是一本相当不错的深度学习入门书。不同于 How to use，本书着重 How to build，书中通过 Python 实现了一套简单的框架，并将这个框架应用在手写识别上。文章深入浅出非常详细的介绍每一层网络解决什么问题，相关的数学公式和原理是什么。 虽然已经出版了接近五年，但是书中内容并没有过期，甚至在最后面的展望描述的场景，包括物体识别，RNN（GPT 基础）在当下异常火热。
本书像是提供精神 massage，片刻愉悦之后还是得落到知行二字。 有时候精神困顿，也需要按摩解乏。比如读到情绪管理这章，就回忆起上周工作冲突失控愤怒上头怼人时刻。我并非不知道要点，也许早一点读到纳瓦尔这一章我就可以唤醒理性，好书还是需要常读常新。 财富和判断力这两章给我的输入和触动最大：做高杠杆效应事情，积累财富；使用稳定可靠心智模型，学习数学，特别是概率和统计。
作为政治家，有意愿有行动力，思想有深度视野开阔不受框架束缚已经是一流。 难能可贵是李光耀还如此坦诚。我想应该是和新加坡人口规模和民众素质有关系。 这本书是书友评论密度很高的一本书，靠书友补充了很多视角（以及后来发生的事情）。
这本书是一本神作，作者用相当大的尺度在讨论从建国到现在政治路线和经济路线的纷争。作为党史研究员，作者不避讳描述毛泽东，让我看到一位急迫地想一把到位共产主义，并且留下一个无阶级矛盾的国家，为此不断发起运动、斗争。好在邓公拨乱反正改革开放。 感慨，看过去一代人的牺牲，一个数字代表一个家庭的破碎。希望未来少一些宏大叙事，多一些关注日常民生。
从无人知晓过来。 文字之间跳跃着一股真诚质朴，数次为其感动眼眶湿润。被陈行甲正直、热情、生命活力感动。 有人质疑这是表演，我倒更愿意相信其诚朴，相信愿意相信的，坚持自己坚持的。
不败者，一本让我挺惊喜的国内科幻小说集。 墨熊的风格有一种深入宇宙边界的探索力，截取了一小段太空歌剧的碎片展现出来，将遥远星际故事拉到读者身边。 《信鸽》有种软硬结合的科幻感，被光速约束的理性和感性的理念交付。 《白鬼篇》有点爽文既视感。 《不可战胜者》让我想起了神秘博士里的哭泣天使，以一种跨越时间线方式进行绞杀。绞杀的方式和破解的方式都精巧且出乎意料。
期望新的一年可以热烈又恬静，深刻又朴素。
2024-01-08 23:38:59
时间已做了选择，太多感受，绝非三言两语能形容
这是第 35 个年头，我熟悉地扮演着多个角色，父亲、丈夫、儿子，每一刻都在陪伴和成长中交织。 生活的步伐似乎匆匆，但我努力让自己拥有一颗年轻的心，渴望保持对世界的好奇和激情。
时光大多被生活所占据，只有地铁上和饭桌上我能成为时间主宰。 好在我并未感到疲惫或沉闷，反而逐渐适应了这个身份的变化。 或许，正是在这些琐碎的日常中，我找到了一种生活的节奏，一种平和而温馨的状态。
今年我们走过了北京、汉中、西安、淳安、长沙、张家界、台州。 新年即将到来，准备给孩子办理一下护照，走出去看看。
在陪伴孩子的过程中，参与各种自然知识课程，参观各种展览，我发现在陪伴的同时，我们也在不知不觉中共同成长。 生活中的另一个领域，我从母亲那里薅了两只相机，终于决心好好学习摄像， 我把 Canon 6D 出售，保留了 SONY a6500 这支轻便的 APS-C 相机。 期望摄影成为我表达内心、记录生活的一种方式，每一张照片都是时光的凝固，是岁月的见证。
游戏的世界中，我似乎进入了一段电子阳痿期。购买的游戏几乎只能玩上一个小时就变得索然无味， 也许现实生活才是最引人入胜的游戏吧。
或许，人生就是一场不断变化的冒险。在时间的舞台上，我们扮演着各色角色， 演绎着属于自己的故事。
工作上一直压力和张力巨大，我开始进一步成为探索者。 这两年，我在工作中不断推动项目的上线，部门推出的新产品中的一半是我负责的，我很喜欢这个领域，也确实想把事情做好。
但有时候，我感觉自己有点像是公司招进来的清理工，身处于一个「散多垂」的状态， 面对复杂的环境，解决问题绝非易事。在整理垃圾的过程中还在自动产生垃圾，而清理的工作永远不会终结。 现实往往是，大家注意力持续被新事物（比如 AIGC）吸引走，对现存的问题更容易选择性忽视。
企业的大环境在不断变化，一些老朋友选择离开，大部门也经历了一些变革。 从面向风险的团队 re-org 到面向算力的基础设施团队。我认为这是一个好的信号， AI Infra将继续裹挟着整个 Infra 领域前进，算力管理将成为一个新的命题。
在 Github 数据的细碎图形中，映射出一年的自娱自乐，可惜的是，未给开源社区更多的贡献。
今年，我在开源领域主要的贡献是 alswl/excalidraw-collaboration。 这个 self-host 的 Excalidraw 版本集协作和中文化字体于一身。这个项目以及相关项目吸引了近300个 star，成为我个人最有影响力的开源项目之一，尽管它是一个前端产品。
在暑假期间，趁着家中小神兽不在，我开发了一个关于起名的小程序。虽然这款产品目前有点烂尾， 亏损严重，但我依然希望花更多时间进行开发和改进。一个美好的名字可以给家庭带来无限愉悦， 希望这个项目可以养活服务器资源~
另外，今年我重新活跃在 Twitter 上，分享一些技巧和心得。我的 Follower 从几百人增长到近 4000 人， 虽然离有影响力的推友还有差距，但与许多有趣的朋友交流本身就是一种有趣的事情。
今年一年最受欢迎的内容是：
今年最具价值的文章是介绍「许世伟的架构课」X，赚了几个月 Twitter 的订阅费。
今年我还重新开始听播客，聆听了一大半「内核恐慌」的存档，虽然未能赶上他们活跃的时期。 幸运的是，在外滩大会上我有机会参与了他们的聚会，与 Rio 和吴涛面对面交流。搞笑的是，虽然现场还有一位同事， 但我们却没有互相认出来，令人感叹在庞大的公司中，有时即便共事也未必能够相识（我们一起担任 Go 语言评委）。
除了内核恐慌，我还一直在听「硬地骇客」，一集都没拉，最近还开始听「有知有行」的播客。
在博客输出方面，我分享了两篇关于工程实践心得的文章，希望能够对读者有所帮助。
我最想分享的是 Obsidian Tasks 插件，详细信息可以在我的博客文章中找到， 从 Toodledo 到 Obsidian Tasks - 我的 GTD 最佳实践。我也很高兴成为 Obsidian Tasks 的 Sponser。
回顾一年的时间，我意识到自己在业余时光中的每周时间仅有10小时左右，非常宝贵。 期许着未来能够实现财务自由，以获得更多的自由时间，投入更多的兴趣爱好。
读书仍然大部分都是非虚构类书籍。
士可杀亦可辱；过去带来惆怅，现在带来迷惘，未来带来希望。
讲述做人做事的道理，古人的智慧。常读常新，尤其烦躁时候可以翻出来静一下。
就是为了看 中文的常态与变态。
老男爵举家迁新球，贵公子初入沙漠星。 老皇帝密授哈克南，雷托族全体遭判断。 小保罗掌权弗雷曼，杰西卡诞下遗腹子。 穆阿迪布反攻沙丘，娶伊勒朗再封帝位。
国、企、民、央、地。 悲观。
好希望自己能在 20 岁时候读到这本书。（现在的我已经不需要啦）。教读者如何和自己、周边、世界相处，如何和自己对话以及改变自己。和遇见未知的自己属于同一个路数。
治乱循环在反复。群体的无意识；民主和精英政治是否是解药？评估稳定性一个指标是贫富差距。极权下也孕育变革风险。
管理入门快速操作手册
这本书我给不出星级，超出了我的评价范围。 它可能是一个新学科（因果推断）理论，也可能是统计学中的一个星火闪烁。 作者 Pearl 是统计学大拿，也是人工智能领域权威专家，他确在晚年提出了反对自己过去一系列方法路线。 今天为我们所熟知的大部分机器学习技术，都是基于概率上相关性，从啤酒和尿布，到今天 GPT 大杀四方，AIGC 智能涌现。Peral 认为真正有意义的是提出「为什么」，即解释因果关系。因果关系的论述需要智能能够想象不存在的事物，而这正是当前人工智能无法理解的（Maybe？） 本书成于 2019 年，作者今年已经 87 高龄，不知道他对当前 AIGC 风起云涌是怎么看待的。
作者说的正确但是不全面。
高质量陪伴家人，放下手机，走向户外
执行了周三、周五家庭日给小朋友陪伴；每天早上送小朋友上学；周末一定有一天陪出行。
陪伴小孩这块我做的不如我老婆好，感谢老婆对家庭的贡献。
每月输出文章，特别是 Kubernetes / 研发设计领域可以写一些心得
今年输出 6 篇文章，达标率 50%。其中两篇 实用 Web API 规范 和 架构设计 the Easy Way 我都是很满意的。
经历了新冠，今年计划安排个私教教我健身房运动
没有完成。
投资收益率能做到 10%，今年新手阶段投资以股票型基金为主，投资收益 3.9%，跑赢了大盘和余额宝
今年投资收益率 -1.35%，刚出新手村就被暴击，我还是缺乏对市场和商业的理解。
新的一年 Flag：
每段经历，每次重逢，每本书籍，都是独特的命运线。新的一年已经来临， 期待着与家人、朋友一同继续探寻生活的真谛，去体验伟大与渺小。
往年总结：
2023-11-25 17:23:35
博客自 2012 年从 WordPress 迁移到静态站点后，就选择了 Disqus 作为评论系统。 但最近 Disqus 硬广告过于频繁，迫切寻找新的评论系统。
Disqus 官方 明确说明，要去掉广告就付费。
What if I want to remove Ads? If you’d like to remove Disqus Ads from your integration, you may purchase and ads-free subscription from your Subscription and Billing page. More information on Disqus ads-free subscriptions may be found here.
OK，那再见吧 Disqus，我会找到可靠、免费、易用的评论系统。 最后既然是寻找新的评论系统，现在 2023 年了， 我希望这个新系统充分使用云服务的便利，要做到 免费、可靠、易运维。
在进入探索之前，我先梳理一下自己的原则和选型要求：
从功能上面分析需要的能力：
非功能需求：
通过明晰这些原则和要求，可以更有针对性地选择合适的评论系统，确保满足核心功能和非功能需求。接下来，将根据这些原则，继续探讨如何选择和搭建评论系统。
现在我们初步试验一些方案并进行一些探索，以方便我们熟悉一下当前常见系统的特性和水准。
我同时还看了一些外部的一些方案评测报告：
根据初步方案探索，我可以明确部署形态基本如下：
这是一个横向对比表格，列举我一些关心的特性以及候选者在这些特性方面的表现。除了上述提到几款常见软件， 我还额外调研了海外常用的评论 SaaS 服务：
| Name | self-host | Official SaaS | SaaS Free | Star | Import Disqus | export data | Comments |
|---|---|---|---|---|---|---|---|
| Utterances | x | v | v | 7.8k | v | Github account required | |
| Cusdis | v | v | v? | 2.3k | v | v? | import from Disqus failed |
| Cactus Comments | v | v | 100 | Matrix Protocol, blocked | |||
| Commento | x | v | $10/month | v | v | ||
| Graph Comment | v | Free to $7 | |||||
| Hyvor Talk | x | v | $12/month | ||||
| IntenseDebate | v | ? | x | too old | |||
| Isso | v | x | 4.8k | v | sqlite storage | ||
| Mutt | v | $16/month | |||||
| Remark42 | v | x | 4.3k | v | v | full featured, one file storage | |
| ReplyBox | v | $5/month | |||||
| Staticman | v | 2.3k | v | using github as storage | |||
| Talkyard | v | €4.5/ month | |||||
| Waline | v | 1.5k | v | v | Multi Storage / Service Provider supported | ||
| Twikoo | v | x | 1.1k | v | v | FaaS / MongoDB |
根据横向对比我们可以得出几个结论：
小结
符合我需求的几款产品是：Utterances、Cusdis、Waline。
我最后选择了 utterances 和 Waline 进行 PoC， 其中我的英文博客使用了 utterances， 中文博客使用了 Waline。
为什么不选择 Cusdis 和 Twikoo？因为 Cusdis 使用 PostgreSQL， 而 Twikoo 存储使用腾讯云函数（免费额度有限）或者 MongoDB， 存储上 Waline 选择更多。 另外，作为同类型方案，Waline 是三者贡献者数量最多的，Commit 数量也最多， 社区更有保障。
一个搞笑的点，如果这里使用 h3 标题叫做「Waline」，会直接在这里插入一个当前博客的评论框
部署图：
具体操作，跟随官方文档即可：
AUTHOR_EMAIL
SENDER_NAME
SENDER_EMAIL
实施 PR（仅包含前端，因为后端代码包含了密钥，不便于分享）： feat: comments on waline · alswl/blog.alswl.com@e34e348
utterances 的部署则更为简单，一个 PR 就可以启用。 feat: comment using utteranc · alswl/en.blog.alswl.com@29028f6 (github.com)
也没有什么特色，主打简单省事，考虑我英文博客访问量极低，就简单方案。
最后我选择了 Waline / utterances 作为我的评论系统，两者的部署成本都是 0。
妥协牺牲了一些访问速度、安全性，但进一步增强了数据可控性，完成了 self-host。 从稳定性上面来看，尽管这个系统链路变复杂了，单机上也存在可用性风险， 但依托 Vercel / LeanCloud / Brevo 三家 SaaS 服务商，整体风险可控。
毕竟只是一个小小评论系统，0 成本 + 正常工作就行了。
欢迎在下面评测测试一下哦~
2023-09-23 18:22:27
image via shipvehicles
使用 GitOps 管理交付内容是一个常见的 DevOps 使用模式。 我们会使用 Git 进行版本管理， 并通过 Git Tag 来跟踪部署软件的版本。 虽然这看上去可以工作，但在云原生技术的推动下，版本的概念远非如此简单。
在引入 GitOps 到 DevOps 流程后，我们可以借助 GitOps 的能力进行持续集成和持续交付。 GitOps 解决了三个核心问题：内容、版本 和 协作。然而，我们经常将注意力集中在内容上，却经常忽略了版本管理问题。
在 GitOps 过程中，有哪些版本管理问题需要解决呢？
一套完整的 GitOps 解决方案包括内容描述（Manifest）、构建方案（Builder）和生效方案（Applier）。其中，内容描述衍生出多种描述语言，从最传统的 Ansible / Chef，到云计算和云原生流行起来的 Terraform、Helm、Kustomize 等。引入了这么多内容描述方式之后，当我们想要明确一个应用的版本时，变得非常复杂。
当提到版本时，我们是指应用源代码的版本？还是指镜像的版本？或者是指某个基础设施即代码（IaC）仓库的版本？进一步地，如果我们要发布一组相互关联的应用，例如前端和后端，或者由多个后端应用组成的系统，如何清晰地描述它们之间的版本依赖关系？
一旦版本描述不准确，就会引入一系列问题，例如错误的上线版本、混乱的应用依赖关系、无法回滚等。
大多数团队对于这个问题的解决方案比较模糊：发布最新的版本，先发布后端再发布前端。然而，在一个复杂的业务团队或需要同时保留多个稳定版本的团队中，这种粗暴的方案是无法接受的。
版本管理不仅解决了版本定位的问题，还可以用于管理应用之间的依赖关系。因此，GitOps 版本管理需要解决以下问题：
在所有的交付产品中，版本管理都是一个重要问题。我们将逐步拆分版本管理这个命题，并从原始问题过渡到 GitOps 的版本管理最佳实践。
在开始正文之前，我将简要介绍 GitOps，以避免对关键概念的理解出现分歧。
GitOps 最核心的技术是基础设施即代码（IaC），即使用声明式描述来取代命令式描述。 通常，IaC 的内容基于某种范式，用于描述特定目标的期望状态。这个范式可以是 Terraform、Kubernetes YAML、Pulumi，甚至是 Ansible。而特定目标可以是云服务、Kubernetes，甚至是物理机。 直观的说，通过使用 YAML 取代过去的 Bash 命令，我们可以大大提高变更的准确性和可控性。
对于 GitOps 来说，是否使用 Git 并不是最重要的，我们也可以使用 SVN 来实现 GitOps。只是 Git 具有更广泛的适用范围，并可以充分发挥 Git 仓库在团队协作和持续集成/持续部署中的能力。
引入 Git 仓库后，我们还同时拥有了基于 Git Revision / Tag / Branch 的版本管理能力，这体现在业务上就是版本记录、多版本并行管理等方面。
简单地基于 Git Revision 进行描述还不足以满足我们的实际需求。
在探索版本的源头时，我们会发现最原始的版本是代码的版本。
代码的版本是什么？是代码仓库的版本还是代码编译出来应用的版本。 这个版本并不是代码所在的版本管理系统（如 Git / Mercurial / SVN 等）的版本。尽管这两者经常相关，但事实上，一份代码本身只是一组代码文件，只要构建成功，就会有一个版本。如果没有定义，版本就是未知的，此时与仓库管理没有关联。
注意：下文我们不再区分 Git / Mercurial / SVN 多种版本管理方案，统一使用 Git 进行描述
还需要注意的是，中文中有两个概念（库 Libray 和仓库 Repository）。 无论是哪种定义，都没有表示一个库一定是一个版本化（Git / SVN）仓库， 这意味着我们并没有假设代码库一定是被版本化管理的。当我们将代码文件打包成一个 zip 文件时（GitHub 的 zip 下载就是这种形式），即使这个 zip 文件失去了所有的 Git 历史，它仍然是一个代码库。
代码的版本实质上是应用的版本，这是作者的意图表达。这个版本往往是 vx.y.z 这种形式，而不是 Git commit hash，
最常见的管理方案是基于语义化版本。
我推荐的版本存储方式是使用一个 VERSION 文件将版本存储在代码目录中。例如，Git 的 Version 文件可以清楚地看到当前 Git 的版本是：
GVF=GIT-VERSION-FILE
DEF_VER=v2.42.GIT
其中的 .GIT 也明确说明了这个代码是一个开发模式下的版本。如果我们切换到一个发布版本的代码，例如 v2.39.3 版本，我们可以看到 DEF_VER=v2.39.3，这是一个遵循标准的制品（Artifacts）格式。这里还有两个最佳实践：
dev 模式，只有在进行标记封版之后才会成为正式版本号。源代码的最终产物不仅包括二进制文件、可执行文件和动态库（.dll / .so / .dylib），还包括相应的启动配置文件。这些启动配置文件通常与对应的版本一起进行管理。例如，Nginx 的启动文件 nginx.conf 和 Redis 的启动文件 redis.conf，这些启动配置文件也应该纳入版本管理。
从源代码仓库构建出来的内容就是制品（Artifacts）。制品已经具有两个版本：
VERSION 文件中定义的版本。引入制品版本管理后，问题变得更加复杂，因为制品带来了更多的问题：
制品的概念非常重要，其中最核心的一个理念是：制品可以通过打包器形成新的制品。
由于制品具有版本，而新的制品将形成新的版本，我们将进入多层嵌套。为了避免最原始的版本信息丢失，我们将 Version 的概念扩展为 Upstream Version，这是软件作者人为指定的版本，是所有版本的源头。
为什么制品可以形成新的制品呢？我举一个 Kubernetes 容器环境下的例子。 容器是一种交付形式，它将可执行文件和启动配置文件写入镜像文件中，并可以在容器环境中运行。形成的镜像文件存在于镜像仓库中，本身也是一种制品。
另外，Helm / Kustomize 也是一种交付形式（打包工具链）。 每个构建层解决其特定问题，并且可以在特定环境（例如容器、Kubernetes、云基础设施）中运行。
每个制品都需要构建，过程中会有自己的额外描述信息（Packaging Info），这些额外的描述信息本身也会发生变化，因此会增加一个版本。在实践中，我们希望制品的版本与其上游版本绑定。每种打包机制可能会包含自己的一些定义配置，但仍然遵循上游的版本。例如，Kubernetes 的 Workload 包含一个镜像，Workload 的描述是附加信息，而镜像仍然受到上游控制。
Artifact + Packaging Info = New Artifact，制品经过打包可以形成新的制品。直到最后的 Installer 放置到相应的环境中生效。
如果这些制品可以通过文件（IaC）进行描述，就形成了各种 IaC 仓库，这些仓库成为了 GitOps 的核心对象。
让我们来理清一下这些略有晦涩的概念：
| 中文 | 英文 | 解释 |
|---|---|---|
| 源代码 | Source Code | 程序、应用的源文件集合 |
| 代码仓库 | Source Code Repo | 源代码放到版本管理系统中的管理单元 |
| 版本 | Version | 源代码对应的应用版本，人为定义，语义化，有些场景会说 Upstream Version |
| 可执行文件 | Executable File | 源代码构建出来的结果，一般是 ELF 可执行文件，也可以是 Lib 文件 |
| 启动配置文件 | Configuration File | 配套 ELF / Lib 的启动配置文件，区别于广泛意义上的配置文件（比如 Kubernetes YAML） |
| 制品 | Artifact | 包含可执行文件和启动配置文件的集合，可以运行在运行时下面，一般是文件形态。制品可以嵌套制品。 |
| 安装器 | Installer | 将制品安装到运行时的工具 |
| 运行时 | Runtime | 制品的运行环境，比如特定操作系统，Kubernetes，Docker Engine。 |
| 打包器 | Packer | 将制品打包成特定格式（新的制品）的工具 |
| 打包附属信息 | Packaging Info | 制品打包时候需要的额外信息，比如容器的操作系统，进程的运行容量，默认环境变量等 |
这些概念共同构成了制品版本管理的核心要素，帮助我们管理和跟踪制品的不同版本，以及它们之间的关联和依赖关系。
打包器是一种工具，通过打包操作（Packaging）将制品组织成特定的格式，形成全新的制品。 打包的过程涉及编译、链接、合并和存档等常见概念。
它通常以上游（Upstream）作为输入，上游可以是源码，也可以是其他系统生成的制品（Artifacts）。
例如，在打包 Docker Compose 时，输入是镜像（Image），而对于 Helm，输入则包括镜像、启动配置文件和 Helm 模板，而输出则是 YAML 文件。
制品是一种数据集合，可以在特定环境中运行。 它由可执行文件和启动配置文件等组成，通常以文件形式存在，并且可以在运行时环境下运行。制品具有嵌套的能力，可以包含其他制品。
最常见的形态是二进制文件（ELF），也可以是适用于特定环境的运行物，如容器镜像。
制品通常以文件形式进行传输。
安装器是一种工具，用于将制品安装到运行时环境中。 它负责将制品部署到目标环境并确保其正常运行。 例如，dpkg、Pacman 是常见的安装器工具，而在 Windows 平台上，我们常见自引导的安装器。
对于特定的环境如 Kubernetes，我们可以使用 kubectl 命令进行安装，而 Helm 则使用helm命令来进行安装。
当我们理解了这些概念后，我们或许会惊讶地发现，这些概念与 Linux 社区多年来的实践是如此相似。抛开云原生等新概念，Linux 社区早就拥有了完整的解决方案。
每一层制品都会引入新的配置（Config）/ 扩展（Extension）/ 值（Values）/ 环境变量（Env）等等，无论如何称呼， 我们统一称之为配置。 这些新加入的 Packaging Info 的描述在大规模集群管理下也带来了新的问题。
自豪地使用 ArchLinux。
Arch Linux 使用 Pacman 作为包安装器，并且拥有一套完整的构建方案。
在 Arch Linux 中，PKGBUILD link用于描述包的构建方式，它本身是 Bash 的子集，是描述包的核心文件。
版本管理方面，Arch Linux 提供了清晰明确的方案，并且设计了完整的制品嵌套解决方案。
在 PKGBUILD 中，pkgver 表示上游版本，并经过适当的修正，使用 _ 替代 -，并调整了时间戳的格式。而 pkgrel 则表示发布号，而不是构建号，每次发布都会增加该号码，用于管理 Arch Linux 的发布动作。当大部分 PKGBUILD 发生变化时，发布号都会发生变化。
此外，epoch 是一个强制构建版本的机制，默认为 0 并且隐藏起来。使用 epoch 是一种兜底的解决方案，通过破坏版本对比来强制进行新版本的升级。
另外，在 PKGBUILD 中，使用了版本依赖的方式来优雅地解决模块的问题。
例如，base-devel 包是对 26 个基础软件的依赖，而该包本身并没有具体的内容。这种方案非常优雅，避免了引入一个新的模型（比如叫做 Group / 产品）。
最后让我们回归到 GitOps 版本管理本身，让我们重新面对文中的几个问题，通过以上的分析和调研，是否已经解决了这些问题呢？
VERSION 文件来确定软件版本，也就是上游版本（Upstream Version）v1.2.3-afe12c 的形式来追踪 Git 仓库中的版本，使用 v1.2.3-afe12c-b1 来追踪镜像构建物的版本。版本管理的智慧，其实已经体现在当年的 RPM / DEB / PKGBUILD 中。 我们通过明确版本定义权交给应用作者，提出制品嵌套的概念，允许版本的概念进行多层嵌套。
我们希望，最后运行的制品版本仍然是原始应用版本（Upstream Version）的衍生。毕竟， 让每个运行的程序都知道自己来自何处、自己是谁，在大规模集群管理下已经变得相当重要。
2023-07-29 14:54:27
image via Pixabay
前几日，我在团队内部举行了一场技术分享，我介绍了关于架构设计的最佳实践。将这些实践凝练成了 20 字口诀：
我将顺口溜转到了 Twitter，不少朋友对这些顺口溜产生了浓厚兴趣，希望深入了解。因此，我将我分享中的观点扩展成了这篇文章。
让我们首先澄清 什么是架构设计和系统分析（简称系分）。有些朋友对前者很熟悉，对后者却不太了解。 不过没关系，以下是维基百科上的介绍：
架构，软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
系统分析，旨在研究特定系统结构中各部分（各子系统）的相互作用，系统的对外接口与界面，以及该系统整体的行为、 功能和局限，从而为系统未来的变迁与有关决策提供参考和依据。
来看一下英文定义可能会更清晰：
我们有时候提到的设计文档，可能涵盖整个设计过程，包括架构设计、系统分析以及其他设计活动（交流、PoC）。
软件架构（设计）= Software Architecture
系统分析 = System Analysis
最后，我来解释一下我对这两者边界的理解。实际上，我认为架构设计和系统分析并没有明显的界限。 一个系统或模块不管如何都会进行系统分析，而当出现以下几个特征时，就开始考虑架构设计问题：
在这里，我们讨论的是技术架构，不会涉及业务架构或产品架构等方面。 技术方面的讨论重点是如何更高效地利用技术能力和方法来解决特定类型的问题。
进一步地，技术架构可以分为两种：一种是从顶层向下看，包括业务、战略和框架划分； 另一种是关注工程实现（编码）层面需要解决的架构问题。
那些经验丰富的人常常有较宏观的视角，使用的常见名词有：全局、宏观、领域、战略、平衡、规划。我将这些词汇整理成了一个词云如下：
generted by https://tendcode.com/tool/word-cloud/
以上这些概念在架构设计和系统分析中都非常重要，因为它们帮助我们在整体上考虑问题，甚至超越技术层面， 从业务价值、商业策略和业务战略的角度思考问题。
另一种架构偏重于工程设计和实现。常见的关键词有：领域建模、UML、GoF23，SOLID，高内聚低耦合等等。对应的词云如下：
generted by https://tendcode.com/tool/word-cloud/
架构的话题非常广泛，本文选择从一个切入点出发：通过实践和方法论，使架构意识在日常工作中发挥作用，以满足 80%的工程设计开发场景。 我称之为「架构设计 the easy way」。
理解架构的第一步，也是最重要的一步，就是关注「问题」。也就是说，你遇到了什么问题，你将如何去解决它？
通常情况下，如果我们的业务和系统都稳定运行，没有遇到任何问题，我们就不太需要进行架构设计。但是，只要涉及到架构设计， 必定是因为我们遇到了问题。这些问题可能源自新的需求，也可能是外部环境的变化， 亦或是系统自身随着时间的发展而出现的。无论问题的来源如何，我们都遇到了问题。
遇到问题之后，我们该如何解决？就像将大象装进冰箱一样，需要分成几个步骤。
image via unkown
因此，解决问题也有三个步骤：第一步是将问题描述清楚，第二步是进行协商和决策达成一致，第三步则是着手解决问题。
我还想问一个听上去很愚蠢的问题：为什么不能直接解决问题？
因为问题是复杂的，有许多解决路径，不同的解决方案各有优劣和成本。在架构设计中，我们需要完成这些决策。
那为什么不直接进行决策，甚至直接开始动手？
首先可能涉及到职权问题，架构师未必有最终决策权，需要有决策权的人来做最后的决定。 第二个原因是架构师未必是方方面面的专家，设计一个复杂系统时候需要协调多个部分和领域专家来一起评估决策。
我举 Prometheus 的架构设计来作为例子。
image via Prometheus
这个架构图回答了很多问题，我举几个例子：
问题驱动架构变化，架构方案应对问题，架构评审统一解决方案。
关于决策拍板问题。我强烈推崇架构师根据自己具备的领域知识、对行业的判断以及对现状的了解， 做出自己的思考和独立判断。这些思考过程应该有因果关系的支持，一个优秀的架构师必定拥有自己的观点。
最后，我补充一个小问题：为什么这里没有提到架构分层、模块分层？
不是因为分层和框架不重要，而是在因为大家都很专业。分层和模块化已经是基本常识和技能，因此反而往往不会成为争论和决策的焦点。 如果分层和框架无法快速形成一致，有可能团队构成上存在问题，也可能问题过于复杂已经不是 80% case。
在本阶段，产出的成果包括架构图以及对问题、价值、成本、风险和分工达成一致的认识。
需求是对问题的解答。我个人喜欢用思维导图或白纸来画图，将需求讲清楚。 画什么内容呢？理清角色，并列出各种动作和行为。
那有什么技巧可以将事项都整理出来呢？我经常使用主谓宾状从的方法。 也就是说，明确哪些人，在什么场景（可选），以什么状态（可选）做着什么事情。
image via unkown
通过用例将需求清晰地拆解，并在这个过程中不断与需求提供方进行交流和沟通。
Demo 稿是产品经理的武器，而需求用例则是工程师的武器。
有些初入职场的研发人员会不自然地变成需求的执行者。我比较果断地判断，不了解业务的工程师和外包没什么区别。而需求分析环节是最重要的， 是对业务输入进行理解、梳理、重新设计的机会。通过用例的整理，我们可以将一些不切实际、不可靠的需求反馈给需求方。
这是少数可以推动（反馈）需求方的阶段，一定要珍惜。
这里有一个产品用例的范例：
image via 网易云音乐产品分析报告
实际上，这个用例是敌对势力那边总结的 😄，但仍然能够体现用例的重要性。
除了使用主谓宾的方式来进行设计，还有一些其他技巧：
本阶段的产出物包括：Demo 稿、用例图。
在我看来，设计的核心在于模型：模型确定了数据的载体和边界。而数据确定了组成部分，边界则确定了归属和职责。 在 UML 中，大量的 Entity 和 Object 用于确定模型的边界。 随着业务系统复杂程度的增加，建模也会面临更加复杂的挑战。
我总结了一下我建模的几个要点：
很多人对中英文术语表不屑一顾，但我却很在意这点。有一个效应叫做「外语陌生感」（Foreign Language Effect）， 就像博物学使用拉丁语 / 希腊语来描述物种一样。我们非英语母语的工程师，使用英文描述术语可以快速地聚焦问题。
始终牢记 80/20 原则的存在，特别是在设计阶段，一定要关注核心对象，将其放大而非过度关注细节。 一般来说，关注最核心的 20%模型就可以满足大部分场景。
在模型的提炼和抽象过程中要反复斟酌，并且可以将这个过程联动到前期的用例定义和后期的时序设计， 这需要大量领域知识的支持。我个人喜欢在这个阶段参考外部的代码和设计。
模型之间的关联关系主要是 1:1 / 1:N / M:N 关系，需要使用箭头清楚地标记主从关系。主从关系意味着从属关系， 这会影响后续一系列细节设计（如 URL、数据库、生命周期管理等）。 我个人推荐避免使用 M:N 关系，这种形式通常表明中间会有一个凭证（Credential）或关系（Relationship / Binding）。
除了关注静态的数据，还要关注模型的行为（极少量模型才有）。这个阶段可以进一步做一些识别，方便下一步的细节设计。
完成业务模型设计之后，同时要考虑数据模型。对于普通业务系统，这个转换会非常直观简单。业务系统通常是无状态系统， 完全依赖数据库进行存储。如果面临 DIA（Data Intensive Application）系统，就要考虑运行时数据的管理， 以及一系列复杂的生命周期管理和可用性管理（我估计有这个需求的朋友，不会看到这里了）。
我举例一个 Kubernetes 的 RBAC（Role-Based Access Control）系统，这是常见的 AuthZ 授权鉴权系统（注意，不是 AuthN 认证系统）。
image via Kubernetes RBAC - DEV Community
这里我抛几个问题：
这些答案都需要建模来回答的。
在我们的讨论中，更多关注的是业务模型，即用户能感知并产品能理解的模型，通常需要存储在数据库中。
但在基础设施领域，也是有模型的，有时候称之为"概念"（Concept）。基础设施领域的模型通常会简单得多， 而业务模型可能会非常复杂，因为世界本身就很复杂，而基础设施则专注于解决非常垂直领域的问题，因此相对简单。
此外，基础设施领域的特殊性会导致有很多抽象的建模，例如最简单到我们常常忽略的（Manager / Service）类别。 一些带有数据和状态的模型，比如 Executor，是常见的概念，而 Registry / Queue 也是常见的概念。
这是 Kubernetes的 Concepts，十几个子类，上百个概念更显这个系统的复杂性。
模型不仅仅是数据，还涉及边界，边界决定了其归属和职责。
模型的设计需要动静结合来看，静态方面关注其持有的内容，动态方面则关注其提供的功能。
在基础设施领域，模型的产出可能包括 UML Model 图、ER 图、数据库 DML、类文件、OpenAPI Swagger（部分）等。
程序设计 = 数据结构 + 算法 + 流程控制
在将设计转换为模型之前，最后一个重要的步骤是控制细节。对于需求方和决策者来说，这一步可能并不重要， 但对于实施方（开发团队）来说，这个步骤直接影响交付结果的质量和时间。
我认为细节应该在时序图上进行呈现。
通常我们有两种常用的图形来展示细节：流程图和时序图。两者实际上有很多相似之处， 但我个人更喜欢时序图，因为它不仅包含顺序的概念，还清晰地展示了流程和系统之间的交互边界。
我的技巧是，一般每个用例都会对应一个时序图。
这里以 AWS 一个官方博客作为范例：
在上图中，展示了 AWS 中使用 CloudFront 的一个时序图，从时序图中可以清晰地看到多个系统之间请求的流转以及多种异常状态的处理。
这里我总结一下时序图的小技巧：
一般来说，时序图画好了，就可以放心地交给项目团队开始实施，不会有大的错误。如果没有时序图，依赖的就完全是彼此之间的合作经验和信任度了。
产出：时序图、API 文档（Open API Swagger）、前端 service 生成（如果有）。
在这个阶段，尽管我们还没有开始编写代码，但已经清楚了需要做什么，以及实现的样子。 我们也有了类结构、API 定义、前端服务生成等产出。多个团队可以同时开始协作，没有明显的瓶颈。
如果未来需要汇报，汇报材料已经有了 1/3 的内容。如果需要撰写技术分享文档，也已经具备了 1/2 的内容。
如果这个项目是一个简单的 CRUD 应用系统，那么基本不会有什么难点。
如果是一个 DIA 系统（Data Intensive Application），则需要开始设计和实施数据存储部分，并考虑数据一致性和并发相关的问题。对于一个复杂的系统， 还需要继续实施多个系统连接处是否存在不确定性。如果在工程上面临同步方面的挑战，例如应用框架改造、通讯系统改造等， 也要提前进行风险排除。（我认为同时进行技术升级和业务开发并不明智）。
我有一套自己的画图工具套件，涵盖了系统架构图、流程图等绘制。 PS：我甚至还给自己的产品设计 Logo，或许这与我内心渴望成为一名设计师有关吧~
作为一名工程师，必须积累自己的画图 UI Kit，熟练掌握其技巧，构建一套属于自己的工具包， 从而能够将脑海中的构思快速还原到文档中。
我的画图工具组合相当丰富。用于绘制架构图的工具包括：
用来做工程设计（UML）的工具如下：
这里我再软广一下我维护的 Excalidraw（Fork），支持中文手写字体，保持风格的统一。
回到本次分享的出发点，给大家一份简单可行的架构设计方案。 但是对于你这样好学的人来说，肯定不会满足于如此简单的流程， 毕竟还有那 20% 的复杂场景无法完全涵盖。 我给你一个关键词列表和一些建议的书单，帮助你进一步加深学习：
以下是一些书单，可以帮助你深入学习：
