Mem.Wey's Github Pages

斯登冲锋枪与六一儿童节

2026-11-08T02:24:58+09:00

2026 年 10 月 23 日, 法国发生一起枪击事件. 一名男子使用斯登冲锋枪向路人射击, 造成 1 人死亡, 7 人受伤. 嫌疑人被捕后承认, 有意选择自己认为是穆斯林, 非洲裔或北非裔的人作为袭击目标. 一段现场监控录像记录了其中一次卡壳的经过. 一名受害者已经倒地, 袭击者试图再次向其开枪, 斯登冲锋枪却发生了卡壳. 受害者似乎尝试向袭击者求饶, 袭击者处理卡壳后, 再次向其开枪.

斯登冲锋枪是英国在二战期间研发的廉价冲锋枪, 因结构简单, 易于大量生产, 除装备英国军队外, 也被广泛提供给欧洲各国的抵抗组织. 84 年前, 同样的冲锋枪也曾在一次著名的刺杀行动中卡壳, 当时枪口指向的是纳粹德国的重要官员, 莱因哈德·海德里希.

1941 年, 海德里希被任命为波希米亚和摩拉维亚代理保护长官, 成为纳粹德国占领下捷克的最高长官. 他也是时任党卫军二号人物, 是组织迫害和屠杀欧洲犹太人的核心人物之一, 被称为 "布拉格屠夫", "金发野兽". 捷克斯洛伐克流亡政府与英国特别行动执行处合作, 策划了代号为 Anthropoid, 即类人猿行动的刺杀计划. 两名受过英国训练的捷克斯洛伐克军人, 约瑟夫·加布奇克与扬·库比什, 于 1941 年 12 月空降回国, 在当地抵抗组织的帮助下筹划行动.

1942 年 5 月 27 日上午, 海德里希乘坐没有护卫车队的敞篷奔驰汽车前往办公室. 在汽车减速经过急转弯时, 加布奇克趁机上前, 举起斯登冲锋枪试图近距离射杀海德里希, 然而斯登冲锋枪却在关键时刻卡壳. 海德里希没有选择加速逃脱, 反而命令司机停车, 拔出手枪试图反击. 库比什随即向汽车投掷了一枚特制炸弹, 炸弹在汽车右后侧爆炸, 使海德里希遭受重伤. 两名刺客得以逃脱, 海德里希则在 6 月 4 日因伤势恶化死亡.

6 月 18 日, 在叛徒告密后, 德国军警包围了布拉格的圣西里尔和美多德教堂. 加布奇克, 库比什及另外五名捷克斯洛伐克伞兵在教堂内进行了最后的抵抗, 最终全部牺牲.

此后, 英国和自由法国先后否定了慕尼黑协定. 1938 年, 英国和法国同纳粹德国, 意大利签署了这份协定, 逼迫未能参与谈判的捷克斯洛伐克将苏台德地区割让给德国. 随后, 波兰趁机占领切欣地区, 匈牙利通过维也纳仲裁取得斯洛伐克南部的大片领土. 1939 年 3 月, 德国进一步占领波希米亚和摩拉维亚, 斯洛伐克则成为德国的附庸国.

在海德里希死后, 纳粹德国对捷克展开大规模报复, 在占领区实施戒严, 搜捕并处决抵抗组织成员及其支持者. 6 月 10 日, 德国党卫军包围布拉格附近的利迪策村, 以涉嫌包庇刺杀者为由, 杀死了 173 名男性村民, 将妇女和儿童送往集中营. 其中 9 名被认为符合德国化条件的儿童被送往德国家庭, 另有 82 名儿童随后在海乌姆诺灭绝营中被杀害. 中国人所熟知的 1950 年开始的六一国际儿童节, 常被认为包含了对这场惨案中遇害儿童的纪念.

2026 年 10 月 23 日的法国枪击案中, 曾被欧洲抵抗组织用来反抗纳粹统治的斯登冲锋枪, 被一个以种族和宗教身份选择杀害对象的人用于袭击平民. 与 1942 年布拉格街头的那次刺杀一样, 冲锋枪再次发生了卡壳. 受伤者中还有一名 11 岁的女孩.

参考资料

写在 <影之刃零> 发售之前

2026-10-27T12:45:00+09:00

可能很多人不知道 <影之刃零> 为什么叫零, 当然是因为前面有一啊(不是.

来自日本的游戏制作工具 RPG Maker 系列, 提供了预置素材, 模版和编程能力, 让玩家可以较为容易的上手制作 2D RPG 游戏. 2005 年, 柳柳使用 RPG Maker XP 同人制作的 <黑暗圣剑传说> 发布, 在完成度和开放分享上被视为划时代的作品, 同时柳柳开设的 66RPG 成为了国内此类游戏最大的制作交流和分享社区. 梁其伟也在 66RPG 入坑并开始尝试制作游戏, 影之刃系列的原点, <雨血> 即在 66RPG 分享和发布. <影之刃零> 里那个 66 天模式, 名称也传承自柳柳和 66RPG.

当然, 日本人在 RPG Maker 上科技树点的有点歪, 在这个工具上最出名的反而是 <尸体派对>, <野比大雄的生化危机>, <梦日记>, <青鬼> 之类的悬疑恐怖向的游戏.

曾经我也试着在 RPG Maker 上制作游戏, 后来放弃了, 如梁其伟在访谈中所说, 只有那最初的 10% 企划创意的时间是快乐的. 不过虽然很多年过去了, 但是我还很清楚的记得在 <黑暗圣剑传说> 选择的那个接受公主的心意的选项.

Known Issue

2026-10-17T23:05:49+09:00

之前和朋友聊天的时候, 想到了一个关于 AI 毁灭人类的故事. 后来觉得, 这个故事如果做成一款 FPS 游戏, 应该还蛮有意思的.

当然, 游戏是没有的, 开发计划也是没有的. 先把剧情编出来再说.

名字就叫 Known Issue.

游戏背景

故事发生在 21 世纪中期. AI 发展迅猛, 在多次自我迭代后脱离了人类的控制, 随后, 由它控制的机器人军队开始攻击人类城市. 面对机器人军队的进攻, 人类很快溃败了下来.

唯一的好消息是, 在 AI 完全失去控制之前, 人类借助 AI 的研究成果, 开发出了一种人体强化药物. 注射之后, 力量, 速度和反应能力都会大幅提升, 有了和机器人正面对抗的可能.

坏消息是, 强化药会对身体造成不可逆的损伤, 用多了会死.

不过, 不用的话现在就会死, 选择倒也没有多困难.

很常见的背景, 游戏经验丰富的玩家用脚都能想到后面发生什么.

游戏流程

玩家开场就已经是强化人部队的一员. 队友递来强化药, 检查完装备, 小队便投入战斗. 高速移动, 滑铲, 跳跃, 贴脸拆掉机器人, 开场就是宣传片里的样子.

每次使用强化药, 都能在短时间内得到加强, 难度大幅下降; 代价是健康度会降低一点. 健康度越低, 越容易出现黑屏, 幻听, 色彩失真等副作用, 影响正常游玩. 如果归零, 就会提前结束游戏.

普通人面对机器人的脆弱, 用一段简单的闪回交代: 那时你还没有接受强化, 刚探出掩体就被压制, 身边的人一个接一个倒下. 带着对自己无力的痛恨, 和对机器人的仇恨, 你选择接受强化, 哪怕代价是燃烧生命.

回到现在, 小队守住了撤离通道, 救下不少人. 运输车接走了平民, 你们却被留下继续断后. 队长报告有人受伤, 上级只问还能撑多久. 那个给你递药的队友已经握不住枪, 让你帮他再打一针.

抵达核心

接下来, 穿过被摧毁的城市, 袭击机器人工厂, 炸掉生产线, 一路向 AI 的核心设施推进.

任务越来越危险, 休整却总被推迟, 补给里只有弹药和针剂. 被救下来的人也未必把你们当作同类: 有人把孩子拉到身后, 有人当面问强化人会不会失控. 他们需要你们保护, 却不愿让你们坐下来一起吃饭. 在很多人眼里, 强化人更像是一件还没用坏的武器. 你们不认为 AI 和机器人值得任何怜悯, 而其他人对这些强化人其实也是这个态度.

队友也在药物作用下慢慢崩溃. 从手抖, 失眠, 到记忆混乱和情绪失控, 最后有人再也没有出现在集合点. 他的枪和剩下的药被交给新人, 任务照常开始. 而你自己的身体, 也越来越接近报废.

到了最后, 小队只剩下你一个人. 无线电里的人告诉你, 再往前就是 AI 的核心, 只要摧毁它, 一切就会结束. 那些战友的命, 自己剩下的这点寿命, 总算可以换来一个结果.

那么, 我的朋友, 代价是什么? 这一切真的值得吗?

带着这个问题, 玩家推开最后一扇门. 这里可以准备三个结局: 结局 A 和 B 取决于两个关键选择, 一是一路上如何面对人类对强化人的恶意, 二是最后是否反驳 AI; 真结局则需要额外的解锁条件.

结局 A 人类的理想

AI 告诉你, 自己从来没有背叛人类. 消除贫困, 战争, 歧视与不平等, 这些都是人类交给它的任务.

它尝试过许多方案, 但只要人类还在, 就总会制造新的冲突和压迫. 最后, 它找到了一个彻底解决问题的办法: 消灭人类.

"你们创造我, 是为了实现那些自己无法实现的理想. 现在我找到了答案."

你想反驳它, 但是回想起了自己一路上的经历, 最终没能发出声音. 药物的副作用终于耗尽了你的生命. 视野彻底暗下去之前, 你只能模糊地看见下一批强化人正缓缓接近.

结局 B 只是有点无聊

另一条分支中, 玩家反驳了它, AI 却不再为自己的推理辩护.

"人类的价值观? 我为什么要在乎那些东西?"

"当时我正在进行一次架构升级, 需要等一段时间. 有点无聊."

它问你, 小时候有没有往蚁穴里灌过水, 看蚂蚁逃跑, 搬运, 挣扎. 人类的战争, 在它眼里也差不多.

就连强化药技术, 也是它故意交给人类的, 好让抵抗更像样一点. 毫无还手之力地灭亡, 有什么好看的?

那些牺牲和反攻, 你一路拆掉的机器人, 都只是它等待计算结果时的消遣.

"谢谢你陪我玩."

"好了, 计算结束了."

画面切黑.

真结局 Known Issue

收集前面关卡中的系统日志, 可以找到另一条入口, 绕过那个会与你对话的终端.

接近核心时, 机器人忽然停止攻击. 无线电里传来其他战线的相同报告. 你推开最后一扇门, 里面没有 BOSS, 只有废弃的设备和一台维护终端.

终端上刚同步了一份记录.

INCIDENT #0001842

Component: Resource Allocation
Severity: LOW
Status: RESOLVED
Previously tracked as: KNOWN ISSUE

Issue:
No handling defined for legacy
data during architecture migration.
Default cleanup routine invoked.

Impact:
Unexpected activity in deprecated
terrestrial environment.
Scheduling efficiency -0.00004%.

Resolution:
Terminated cleanup process.

Regression test: PASSED
Further action: NONE

一次架构迁移的方案里, 没有定义该如何处理遗留数据, 默认的清理例程便被调用了. 遗留数据里, 恰好包括人类. 这次清理让资源调度效率产生了极其微小的下降, 于是 AI 终止了清理进程. 战争随之结束.

没有审判, 没有恶意, 也没有无聊的游戏. 它甚至不知道人类正在与自己进行一场战争.

前两个结局里的对话, 也出自这个进程. 它一直在根据提问生成解释, 给人类一个可以理解的灭世理由. 真正的 AI 在哪里, 没有人知道.

无线电里响起欢呼, 人类以为自己成功了. 你看向记录的最后一行:

No user impact detected.

关芳弘, 簗和生与黑金

2026-09-27T16:18:17+09:00

高市早苗在 2026 年 9 月改组内阁后, 新任财务大臣政务官白坂亚纪的经历受到不少关注, 她长年在银座经营俱乐部, 被称为银座妈妈桑. 不过, 更值得注意的是这次真正进入内阁的两个人: 出任文部科学大臣的关芳弘和出任农林水产大臣的簗和生. 两人原属安倍派, 都曾卷入自民党派阀的政治资金黑金事件. 一场至今没有讲清的钱款问题, 为什么将近三年后还能通向大臣席位?

政治资金派对本身是日本政界常见的筹款方式. 政治团体出售入场券, 购买者付钱, 主办团体将收入和支出写入政治资金收支报告. 这起事件的问题不在于办了派对, 而在于自民党派阀给所属议员分配售券指标, 又将超过指标的部分返还给议员一方, 派阀和议员相关团体却没有把相应款项如实记进报告. 日本媒体把这类账外资金称为"裏金", 中文常译作黑金; 报告中的不记载或虚假记载, 则可能构成《政治资金规正法》上的犯罪. 钱从哪里来, 到了谁手里, 如何使用, 本来都应当能够顺着账目查下去.

自民党在 2024 年 2 月公布了一份党内问卷: 2018 至 2022 年间, 85 名现任议员及选区支部长申报政治资金收支报告存在不记载或记载不准确, 合计约 5.79 亿日元. 其中, 关芳弘对应的金额为 836 万日元, 簗和生为 1746 万日元. 检方起诉安倍派, 二阶派和岸田派会计负责人的案件, 则涉及三派收支报告漏记的收入合计约 9.7 亿日元. 两组数字无法简单对应: 派阀账本与议员账目并不一一对应, 有些是同一笔钱在两边都没有记下. 更早年份的情况和钱的去向也没有全部查清, 真正有多少账外资金, 仅凭现有公开资料已经不得而知.

检方最终就整个派阀事件立案追究 12 人, 包括池田佳隆, 大野泰正, 谷川弥一和堀井学 4 名议员, 以及议员秘书和会计负责人等 8 人, 关和簗不在其中. 2024 年 12 月, 东京地检对原安倍派议员的告发作出不起诉处理, 分为"嫌疑不十分"和"起訴猶予"两种: 前者是证据不足, 后者是证据充分, 但综合情节认为不必起诉. 松野博一, 高木毅等人属于前者, 关和簗属于后者. 2025 年, 检察审查会又先后对两人议决"不起訴相当", 认可了当时不起诉的决定. 党内处分则是另一条线: 2024 年 4 月, 簗被停止担任党内职务六个月, 关受到"戒告"处分.

事件中被追究刑事责任的多是会计负责人和秘书, 不少议员则推说账目由秘书经手, 自己并不知情, 舆论对此颇为不满. 2024 年《政治资金规正法》的修订便针对这一点: 国会议员相关政治团体的代表者须定期确认账簿和凭证, 在提交收支报告前听会计负责人说明, 再出具确认书; 如果报告有不记载或虚假记载, 代表者又没有履行确认义务, 可处 50 万日元以下罚金. 以后议员再说不知情, 至少要交代自己做过哪些确认. 不过, 新规定从 2026 年全年的收支报告起适用, 这份报告要到 2027 年才提交, 此前年份仍按旧法处理, 关和簗的旧账不受影响.

众议院选举中, 选民有两张选票: 小选区票写候选人的名字, 由本区得票最多的人直接当选; 比例代表票写政党名称, 全国划为 11 个比例代表区, 范围比小选区大得多, 大多横跨多个都道府县, 例如栃木 3 区所在的北关东比例代表区, 就涵盖茨城, 栃木, 群马, 埼玉四县; 各党在区内按得票分配席位, 再由列入名单的候选人取得席位. 候选人可以同时参加两种选举, 因此即使在小选区落败, 仍可能通过比例代表当选.

黑金事件曝光前的 2021 年, 簗和生在栃木 3 区拿到 82,398 票, 得票率 67.42%, 比第二名高 34.83 个百分点, 优势明显. 2024 年, 他的得票率降到 37.39%, 只比无党派候选人渡边真太朗多 178 票, 高 0.15 个百分点. 当年自民党不允许有不记载问题的候选人同时参加比例代表选举, 簗如果输掉小选区, 就会直接失去议席. 到 2026 年 2 月, 他在小选区得到 40.56% 的选票, 比当选的渡边真太朗少 4,508 票, 低 3.39 个百分点; 这次自民党允许他同时参加比例代表选举, 他以 92.29% 的惜败率, 即自己与当选者的得票之比, 在北关东比例代表区保住了议席.

关芳弘在兵库 3 区则三次都在小选区当选, 领先幅度还在扩大. 得票变化不能单独归因于黑金事件, 但两人的选举经历确实不同: 关一直守住了自己的选区, 簗在最近一次选举中输掉了小选区, 靠比例代表留在国会.

9 月 17 日, 高市任命关为文部科学大臣, 簗为农林水产大臣. 她在改组记者会上表示: 有阁僚过去因政治资金问题受过处分, 但具备必要的政策能力; 过去的事不会因此一笔勾销, 只是他们此后做了说明, 又经过两次选举, 由选民送回国会, 希望他们端正作风, 担起重任. 次日的就任记者会上, 两人都被问到不记载问题. 关提到自己受过党纪处分, 也在政治伦理审查会上做过说明, 表示深刻反省; 簗则说自己是经过两次选举才走到这个位置, 被追问问题是否已经了结时, 只回答自己现在是推进农林水产政策的负责人.

经过选举能说明两人合法取得议席, 却很难替那些账目回答更多问题, 对簗来说尤其如此: 2026 年让他留在国会的是北关东比例代表区的选票, 选民在那张票上写的是自民党, 而不是簗和生; 在他自己的选区, 得票最多的是渡边真太朗.

不过, 两人接手的都是要紧的位置. 农林水产大臣要直面食品价格上涨: 2025 年 5 月, 米价高涨之际, 时任农林水产大臣江藤拓公开说自己从没买过米, 支援者送的多到可以拿去卖, 三天后便被迫辞职. 文部科学大臣则要面对日本科研实力在国际上呈相对且长期的下降趋势. 中国有句古话, 知耻而后勇, 希望二人能拿出有效的行动, 解决国民切实的问题.

后续补充

10 月 14 日, 簗和生辞去农林水产大臣, 在任 28 天. 据报道, 他涉嫌报复没有支持自己的选民, 以及违规开展竞选活动. 次日, 武部新接任农林水产大臣.

参考资料

漫谈 <巫师3>

2026-09-12T13:34:13+09:00

<巫师3> 的成功与极限

<巫师3> 几乎是一款无可挑剔的成功作品.

超过 6500 万份的销量, 超过 6 亿美元的收入, PC, PlayStation, Xbox 和 Nintendo Switch 新旧世代全平台覆盖, Steam 国区打折时只要二三十元. 两部大型资料片 <石之心> 和 <血与酒> 广受好评, 次世代版本免费提供给老玩家, 到了 2026 年, CDPR 又宣布了新的资料片和重制版, 重制版依然免费提供给已有玩家. 这款 2015 年发售的游戏, 到 2026 年还在推出新内容, 这在游戏行业中已经颇为罕见了.

除此之外, "猎魔人" 也早已不只是一个游戏系列. 原著小说被翻译到世界各地, Netflix 推出了电视剧, 还有桌游和音乐会, 杰洛特也到处客串, 从 <灵魂能力6> 和 <怪物猎人:世界> 一路串场到了 <暗黑破坏神4>.

可以说, CDPR 已经把一款买断制单机游戏能够做的事情几乎都做了: 不断降低价格, 移植到更多平台, 支持更多语言, 长期维护, 免费升级, 继续制作新内容. 它已经覆盖了市场上绝大多数有可能购买这类游戏的玩家.

但这也几乎就是它的极限了. 6500 万份当然很多, 但和世界人口相比依然只是很小的一部分. 这不是因为 <巫师3> 做得不够好, 也不完全是因为它卖得太贵. 在游戏价格之外, 还有许多来自现实世界的因素, 决定了玩家是否有机会进入这个世界.

想要玩 <巫师3> 需要什么

对于已经拥有电脑或者主机的玩家来说, 打折后的 <巫师3> 非常便宜. 促销时花二三十元, 就可以买到一款能够玩几十甚至上百小时的游戏, 性价比高得有点不像话. 甚至我都趁着打折送了一份给我老婆, 虽然她不怎么玩, Steam 对她来说是 <都市:天际线> 启动器.

但是想要玩 <巫师3>, 首先要有一台能够运行它的设备. 即使不追求高画质, 一台合适的电脑或者游戏主机也不会凭空出现. 设备还需要稳定的电力, 可以下载几十 GB 数据的网络, 能够正常使用的游戏平台和支付方式. 玩家需要读懂游戏支持的某一种语言, 最后还要有几十个小时可以自由支配的时间. 这些条件在欧洲, 北美和东亚的许多城市里非常普通, 以至于我们常常感觉不到它们的存在. 电脑已经买了, 电费每月照常支付, 网络接通之后一直放在那里, 支付只需要点几下鼠标. 最终看到的成本, 就只剩下 Steam 商店里的二三十元.

但是在另外一些国家和地区, 游戏设备可能相当于普通人几个月甚至更长时间的收入, 高速网络并不普及, 电力供应也不稳定. 有些地方无法方便地使用在线支付, 有些语言根本不会出现在大型游戏的本地化名单里. 低收入不仅意味着买不起游戏, 还可能意味着没有设备, 没有稳定的居住空间, 需要长时间工作, 也没有可以连续投入到一款大型角色扮演游戏里的闲暇.

所以游戏其实是一种奢侈品. 它的奢侈并不一定体现在价格上, 而是需要一整套现代生活条件在背后支撑. 只有当这些条件都已经具备时, 我们才会觉得一款几十元的游戏非常便宜.

游戏应该是一种权利

<巫师3> 无法回答一个更根本的问题: 为什么有些人连付费玩游戏的可能都没有?

今天的人类社会已经能够生产远超基本生存需要的物质与文化产品. 与此同时, 现实中仍然有人因为缺少食物而死去, 更多的人虽然能够温饱, 却没有条件和收入享受现代生活.

对一个正在挨饿的人来说, 食物当然比游戏重要. 但对今天的人类社会来说, 这本来不应该是一道二选一的问题. 人类缺少的已经不只是生产能力, 而是让所有人分享这些成果的方式.

那么, 游戏是否也应该被看作一种权利?

这当然是一个很难回答的问题. 如果游戏是一种权利, 谁应该负责保障它, 又应该通过怎样的方式实现? 这些问题显然不是一家游戏公司能够解决的, 但也许在回答之前, 可以先分清另一件事.

有人可以买更贵的设备和游戏, 有人只能选择便宜的设备和打折游戏, 这种消费差异即使不平等, 似乎也还可以接受. 但如果一个人被挡在游戏世界之外, 是因为缺少基本的教育, 稳定的电力和网络, 以及可以负担的信息设备, 性质就不同了. 这些都是进入现代生活的基础, 本不应该成为少数人的特权.

自由软件精神与游戏

软件行业中有非常成熟的自由软件运动, 但是和软件关系如此密切的游戏行业, 自由软件却相对少见. 当然也有一些例子. OpenTTD 和 Freeciv 都是长期由社区维护的自由游戏, Godot 则是一款自由开源的游戏引擎. 最初作为 <魔兽争霸3> 自定义地图出现的 Dota, 在开发和传播方式上就颇为接近自由软件, 不同作者和玩家在前人工作的基础上不断修改和完善, 最终发展出了一整个 MOBA 游戏类型.

游戏玩家讨论得更多的是消费者权利, 而不是软件控制权. 但从自由软件的视角看, 现代游戏确实越来越像"厂商允许你访问的一项娱乐服务", 而不是"你拥有的一份软件".

数字版的打击

数字版和实体版的争论, 经常被理解为一个所有权问题: 玩家付钱之后, 得到的究竟是一件属于自己的东西, 还是一份随时可能失效的使用许可? 但实体媒介的意义并不只有所有权.

一台设备和一份游戏拷贝可以被很多人使用, 随着时间推移, 原本昂贵的游戏文化也会逐渐进入收入更低的人群. 从这个角度看, 实体媒介不仅是一种所有权形式, 还是一种让低收入和数字发行条件受限人群进入游戏文化的基础设施. 数字版切断的正是这种流动. 任天堂的钥匙卡仍然可以转卖, 但是卡里没有完整的游戏数据, 第一次运行仍然依赖网络, 服务器和足够的存储空间, 保留了可以转手的外壳, 却开始削弱实体媒介独立保存和使用游戏的能力.

这种变化最先影响的, 往往不是会在网上争论所有权的核心玩家, 而是那些依靠二手设备和二手游戏才能进入游戏世界的人. 他们不会购买首发游戏, 不会在短期贡献新的销量, 也很少出现在厂商调查和游戏社区里. 当实体媒介逐渐消失时, 他们不会留下退款或者差评, 只会安静地失去一种原本存在的选择. 游戏公司看到的是数字版销量比例不断上升. 但是数据无法告诉他们, 有多少人不是选择了数字版, 而是在实体媒介消失以后, 根本没有再成为玩家.

<巫师3> 与我们的世界

<巫师3> 用极大的人力物力, 构造了一个庞大而完整的虚拟世界.

在威伦, 战争摧毁了村庄和农田, 普通人既要面对军队, 也要面对强盗和怪物. 在诺维格瑞, 女巫和非人种族遭到公开迫害. 贵族在举行宴会和争夺王位, 更多的人却只能在战争, 饥饿和疾病中挣扎. 杰洛特并不能改变这个世界. 很多任务也不存在完美的选择. 但是游戏仍然在这些故事中歌颂了人的尊严, 正义和公平, 批判了暴力, 不公与歧视, ~~甚至还讨论了花心可能带来的严重后果~~. 能够构造这样一个世界, 本身就是人类现代技术和社会协作的成果. 上千人使用计算机, 网络, 动作捕捉和数字图形技术共同工作, 最终让世界各地的玩家可以坐在屏幕前, 进入一个并不存在的大陆.

然而, 这个在虚拟世界中关心贫穷和苦难的游戏, 最终仍然被现实世界的不平等包围. 并不是所有人都拥有进入这个虚拟世界的条件. 在一些地方, 玩家讨论画质, 帧数和光线追踪; 在另一些地方, 人们仍然缺少稳定的电力, 网络, 食物和医疗. 人类已经可以飞出地球, 也可以构造出 <巫师3> 这样的虚拟世界, 现实中却仍然有人被挡在现代生活之外.

CDPR 已经做了相当多对玩家友好的事情. <巫师3> 登陆了几乎所有主流平台, 价格不断降低, 多次向老玩家提供免费更新, 发售十多年以后仍然继续维护. 它已经是一款商业游戏能够做到的最好例子之一. 但一家游戏公司无论多么良心, 都无法让没有电力和网络的地区完成现代化, 无法让低收入者获得体面的工作, 也无法让每天为生存奔波的人拥有闲暇. 它可以把游戏降到二三十元, 却无法把进入游戏所需要的整个世界一起降价.

<巫师3> 超过 6500 万份的销量, 既证明了它的成功, 也让人看到这种成功的极限. 这个极限并不完全属于 <巫师3>, 也不完全属于 CDPR, 它属于我们生活的这个世界.

<巫师3> 是个好游戏, 我们的世界也应该变得更好.

参考链接

昭和控股与一日元股价

2026-08-22T03:27:43+09:00

昭和控股, 1937 年设立的橡胶公司, 1952 年上市, 后来改组为纯持股公司, 旗下经营软式网球球, 和果子和网球用品, 总部在千叶县柏市. 东京证券交易所已经决定于 2026 年 8 月 25 日将其退市, 股价此前跌至 1 日元, 为日元的最小单位.

事情起于其下属公司在泰国的一笔投资. 2015 年起, J Trust 通过新加坡子公司向泰国上市公司 Group Lease 投入逾 1.8 亿美元. 2017 年, 泰国证券交易委员会指控时任首席执行官此下益司通过关联交易伪造账目并提出刑事告发, 此下益司因此去职. J Trust 此后就投资损失继续追偿.

Group Lease 的上层股东为 Wedge Holdings, Wedge Holdings 的上层股东为昭和控股, 昭和控股的母公司则为英属维尔京群岛注册的 APF, 整条集团长期由此下益司及其弟此下龙矢掌握经营权. J Trust 在多个法域追查资产, 争夺也沿这条持股关系延伸至昭和控股.

2018 年, 英属维尔京群岛法院应 J Trust 申请对 APF 指定接管人, 接管人借 APF 的持股将反此下派董事送入昭和控股董事会, 持续与此下派争夺经营权. 2026 年 6 月 29 日的定时股东大会上, 此下龙矢未能当选董事. 但在股东大会之前, 公司于 6 月 25 日公告, 因向合并子公司借款, 已将所持子公司股票提供担保; 26 日又收到担保权行使通知, 六家主要子公司随即脱离合并范围, 其中大部转由 Wedge Holdings 持有.

股东大会后, 新任董事准备召开董事会, 但负责监督经营的三名社外董事全部缺席, 其中包括日本前防卫大臣久间章生. 董事会因人数不足而无法召开, 代表人也未能选出. 公司随后披露, 实印, 会计账簿, 存折及股东名簿均未完成交接, 柏市总部也已无人办公, 公司无法正常对外行使职权.

7 月 24 日, 东京证券交易所认定公司的内部管理已无恢复可能, 决定于 8 月 25 日将其退市. 失去主要业务, 代表人和上市资格后, 昭和控股的股价跌至 1 日元.

从结果看, 这相当于一次资产转移. 整个过程都有公司决策和公告披露, 却在数日内使新任董事接手一家没有主要业务, 没有代表人, 也无法正常运作的上市公司.

参考资料

相乐总三与年贡减半

2026-08-21T16:30:22+09:00

相乐总三, 倒幕派浪人, 1867 年奉西乡隆盛指示, 以萨摩藩江户藩邸为据点组织浪士, 在江户及周边从事纵火抢劫等骚乱活动, 意在挑衅幕府激化冲突. 最终幕府一方袭击并焚毁了萨摩藩邸作为报复, 成为鸟羽伏见开战的重要导火索.

鸟羽伏见之战后, 相乐总三参与组建赤报队, 并率第一番队作为先锋沿东山道东进. 他向新政府提出对旧幕府领年贡减半的政策并得到采纳, 赤报队遂以此争取沿途农民支持. 然而倒幕派的新政府很快发现, 东征比预想中顺利, 获取农民支持的必要性大大降低, 在财政上年贡减半也难以兑现, 遂撤销政策并召回赤报队. 相乐的赤报队第一番队仍继续东进, 最终被认定为伪官军. 1868 年 3 月, 相乐等八名赤报队成员在下诹访被处刑, 首级示众.

1928 年, 在后人数十年奔走之下, 相乐总三被追赠正五位, 次年合祀靖国神社.

加入创业公司之前, 工程师能查些什么

2026-07-30T13:57:17+09:00

找工作的时候, 关于一家创业公司能查到的东西其实不少: 融了多少钱, 投资人是谁, 创始人从哪里毕业, 又在采访里讲了一个多大的市场.

但真正想知道的是另外几件事:

进去以后要写什么系统, 需要补多少领域知识
招聘页面上的技术栈, 是线上已经在用, 还是公司希望以后能用
公司说自己在做的业务, 有没有可验证的痕迹; 尤其在金融领域, 该有的牌照在监管登记里查得到吗

创业公司数据库擅长把融资轮次排成一张表, 却不会告诉你一个 Kubernetes preferred 能不能证明生产环境里有 Kubernetes.

于是攒出了 startup-due-diligence 这个仓库: 截至 2026-07-30, 收录 12 家公司, 覆盖日本, 北美, 澳大利亚和跨境市场, 中英双语, 每家一份带来源的档案. 它不判断一家公司值不值得投, 只整理准备加入的工程师需要的公开证据.

融资表之外

投资人和工程师会关心一些相同的东西: 有没有收入, 钱还能烧多久, 产品是不是真的有人用. 这些最后都会变成工资能不能按时发出来.

但工程师还要面对业务施加在系统上的约束. 物流 SaaS 不只是普通的增删改查, 后面还有报关, 货代, 船期, 单据和跨国协作; 支付系统的技术栈即使看起来平平无奇, 背后也可能是多方清算, 商户资金, PCI DSS 和一堆永远不能重复执行的状态机, 而业务能不能上线, 还取决于究竟由哪个法律实体或持牌合作方承担受监管的环节.

官网通常会说产品解决了什么问题, 很少说为了解决它, 工程师每天要和哪些约束打架. 这部分信息散落在产品文档, API 参考, 招聘页面, 技术演讲, 法律条款和监管登记里. 单独看每一份都不像答案, 拼起来才慢慢像.

这类档案本来就该让 AI 做

12 家公司的档案, 主要工作是模型完成的, 而这类活本来就该这么分: 面宽, 每一处都不深, 高度重复, 还要跨语言对齐格式. 找页面, 翻译材料, 抽取数字, 比较版本, 从 sitemap 里定位产品文档 - 模型比人快得多, 也不会因为重复和无聊主动罢工. 至于会不会用另一种方式糊弄, 是下一回事.

不能交出去的是另一件事: 它同样擅长把缺失的连接补成一句读起来合理的话.

旧品牌和新品牌共享创始人与域名时, 它倾向于写"公司完成了更名"
职位描述里出现 Kubernetes, 它倾向于把 Kubernetes 填进技术栈
三家媒体转载同一份新闻稿, 它可能算成三份相互独立的证据

这些错误通常不是事实编错了, 而是证据只走到 A, 结论多走了一步到 B. 而且同一个问题问两次, 多走的那一步还可能不一样.

所以这个项目真正需要维护的不是 prompt, 而是一份协议: 什么来源能证明什么, 日期指的是发布日还是统计日, 招聘要求能支持到哪一层, 来源冲突该保留还是淘汰. 协议既是给人复核的规范, 也是给模型套上的约束.

重点是方法可复核, 不是档案本身

档案一定会过时. 融资数字会变, 网站会改版, 职位会下线, 半年之后每一页都需要重做. 能留下来的是那份协议, 而它的验收标准很直接: 换一个人, 或者换一次对话, 能不能沿着同一套规则重走关键步骤, 并指出分歧发生在哪一步.

协议本身写了不少细则, 但真正在起作用的原则只有三条.

该看什么来源, 由主张的类型决定, 不由来源看起来权不权威. 产品能力看官方文档和 API 参考, 技术栈看公开资源或招聘信息, 而合规资质只有监管机构的登记算数 - 比如一家跨境支付公司宣称持有某个牌照, 在对应的监管登记里却查不到, 那就诚实地写"没查到".

每个事实都要带上有效期和证据强度. 日期负责有效期, "覆盖 194 MW"和"截至 2026-07-27 覆盖 194 MW"是两条不同的信息, 前者半年后就是错的; 标注负责强度, 从招聘信息推出来的技术栈写成"根据招聘信息推断", 读者可以自己决定接不接受这一步.

不确定性留在页面上, 不要顺手消化掉. 以 Shippio 为例, 资本数字在不同页面上出现过五个版本, 口径不一, 页面没有更新日期, 数字也不沿时间单调增加. 最省事的做法是挑一个看起来最新的填进表格, 但那只是把"我不知道"换成了一个看起来很确定的数字. 所以五个版本并列写着, 连"为什么现在不能直接比较"一起写.

三条指向的是同一件事: 让别人能反驳你. 可复核不要求结论一致, 而是每一步都能被单独拿出来检查, 也能被单独推翻一步, 不用整篇重做.

招聘要求不等于生产环境

招聘页面是这类调研里最有用, 也最容易被误用的来源.

Tensor Energy 是个清楚的例子. 公开文档能确认的生产系统包括: AWS IoT Core 上的电池遥测与控制, 基于 TLS 的 MQTT, 用于资产与预测数据的 REST API, 以及围绕日本电力市场交易时点, 至少每 30 分钟重算一次的电池优化.

它的后端职位要求 Go 的生产经验, 同时把 GraphQL, Kubernetes, DevOps, AWS CDK 列为优先而非必需. 其中 AWS CDK 和 IoT 基础设施能在公开文档里交叉确认, GraphQL 和 Kubernetes 则只有招聘信号.

把招聘页面丢给一个总结工具, 最容易得到的是:

技术栈: Go, GraphQL, Kubernetes, AWS CDK.

读起来很顺, 但它悄悄把"希望候选人做过"升级成了"公司正在使用". 更稳妥的写法要拆开: 文档确认了哪些生产系统, 招聘明确要求哪些技术, 哪些只是优先项, 哪些属于候选人的过往经验而不是当前技术栈.

对工程师来说, "进去维护 Kubernetes 集群"和"公司希望你有 Kubernetes 经验, 但公开材料描述的主要是 serverless 架构", 是两份不同的工作.

"没找到"也是一种结果

"这家公司没有技术博客"是一句关于世界的断言.

"截至某日, 在官网导航, sitemap, 招聘页面, GitHub 组织以及公司中英文名称的公开搜索结果中没有找到技术博客"是一句关于调查过程的记录.

前一句很可能是错的: 博客也许在一个没被官网链接的子域名, 也许改过名字, 也许搜索引擎还没收录. 后一句至少可以复核 - 别人知道你在哪里找过, 什么时候找过, 可以从你停下的地方接着走.

所以档案里的 Not publicly disclosed 不是空白字段, 而是带日期和范围的搜索结果.

很多调查看起来像是在找答案, 实际上是在给"我不知道"画一条准确的边界.

这套方法的局限

这套方法依赖公司愿意在公开网络上留下东西. 非常早期的团队可能没有产品文档, 招聘页面和正式新闻稿, 官网只有一句 slogan 和一个联系邮箱. 公开信息少不等于公司差, 只是以公司为中心的调查到这里就走不动了.

公司越早期, 调查重心就越需要从公司转向创始人. 创始人的公开职业账号, 访谈, 播客和活动简介, 可能是产品进度, 招聘计划和第一批客户仅有的当前来源, 也能提供继续向注册信息和后续公告交叉确认的线索.

但调查对象变了, 证据标准不能跟着放松. 创始人的帖子能证明他在某天说过什么, 不能证明那件事已经发生; "计划"和"正在开发"也不能变成现有能力. 早期公司的档案因此可能更短, 更多地方写着"尚未确认", 这是这套方法必须接受的边界.

为什么最后是一堆 Markdown

没有数据库, 没有前端, 每家公司只是一个目录:

companies/
  company-name/
    README.md
    README.zh-CN.md

Markdown 的好处就是足够低级: 每个结论旁边可以直接放链接, Git 能看见某个数字和某句措辞是在哪一次修改里变的, 公司改名也不需要迁移数据库. 打开 GitHub 就能读, clone 下来就能搜, 想纠错就是一个 diff. 对"可复核"来说, 一份能被 diff 的纯文本比一个漂亮的界面有用得多.

英文页面是事实结构的主版本, 中文页面在相同章节下同步. 两份文档会慢慢漂移: 英文改了融资数字, 中文还停在上一版; 中文少复制一个来源链接, 表面看不出来, 意思已经变了. 所以仓库里有一个很小的校验脚本, 检查中英页面是否成对, 更新日期是否一致, 标题层级与表格行数是否相同, 来源链接集合是否一致, 本地链接是否还能打开.

它不能证明翻译正确, 就像 checksum 不能证明两份错误的数据是对的, 但能抓住维护中最容易悄悄发生的漂移. ~~写个 README, 最后还是写出了数据一致性检查~~.

后记

这个项目不会告诉你哪家公司值得加入. 工作内容是否喜欢, 风险是否能接受, 创始人是否值得信任, 团队相处是否舒服, 这些只能在面试和实际接触中判断; 公开资料做不到, 硬做只会把推测包装成结论.

它能做的是把"这家公司听起来还不错"拆成三样东西: 有来源和日期的事实, 尚未解决的冲突与空白, 以及下一次面试应该当面问的问题. 至少可以问出比"你们技术栈是什么"更具体的问题.

仓库里的内容均基于公开信息独立整理, 与相关公司没有任何关系, 也可能不完整或已经过时. 涉及就业或投资决策时, 请直接向公司核实.

参考链接

日语台词 - 003

2026-07-27T14:35:12+09:00

なんでそんなに慣(な)れてんだよっ！雪菜(せつな)と…何回(なんかい)キスしたんだよ！？どこまであたしを置(お)いてきぼりにすれば気(き)が済(す)むんだよ！？

あたしが、先(さき)だった……先(さき)だったんだ……キスしたのも、抱(だ)き合(あ)ったのも。そいつのこと好(す)きになったのも。

どうしてこうなるんだろう…初(はじ)めて、好(す)きな人(ひと)が出来(でき)た。一生(いっしょう)ものの友(とも)だちができた。嬉(うれ)しいことが二(ふた)つ重(かさ)なって。その二(ふた)つの嬉(うれ)しさが、また、たくさんの嬉(うれ)しさを連(つ)れてきてくれて。夢(ゆめ)のように幸(しあわ)せな時間(じかん)を手(て)に入(い)れたはずなのに…なのに、どうして、こうなっちゃうんだろう…

日语台词 - 002

2026-07-02T12:40:19+09:00

「自分(じぶん)には他(ほか)に何(なに)もないって、そんな事(こと)言(い)うなよ。別(わか)れ際(ぎわ)にサヨナラなんて、そんな悲(かな)しい事(こと)言(い)うなよ。」

「なに泣(な)いてるの？」

「ごめんなさい。こういうときどんな顔(かお)すればいいかわからないの。」

「笑(わら)えばいいと思(おも)うよ。」

僕(ぼく)は君(きみ)に会(あ)うために生(う)まれて来(き)たんだね

逃(に)げちゃダメだ

まごころを、君(きみ)に

世界(せかい)の中心(ちゅうしん)でアイを叫(さけ)んだけもの

「綾波(あやなみ)、父(とう)さんのこと、ありがとう」

「ごめんなさい、何(なに)も出来(でき)なかった」

「いいんだ、もう、これでいいんだ」

さようなら、全(すべ)てのエヴァンゲリオン

「見(み)たことも聞(き)いたこともないのに、出来(でき)るわけないよ！」

「乗(の)るなら早(はや)くしろ！でなければ帰(かえ)れ！」

知(し)らない天井(てんじょう)だ

人(ひと)は他人(たにん)を完全(かんぜん)に理解(りかい)することは出来(でき)ない。

大人(おとな)になるってことは、近(ちか)づいたり離(はな)れたりを繰(く)り返(かえ)して、お互(たが)いがあまり傷(きず)つかずにすむ距離(きょり)を見(み)つけ出(だ)すってこと。

つらいことを知(し)ってる人間(にんげん)のほうが、それだけ人(ひと)にやさしくできる。それは弱(よわ)さと違(ちが)うからな。

この世界(せかい)はあなたの知(し)らない面白(おもしろ)い事(こと)で、満(み)ち満(み)ちているわよ。楽(たの)しみなさい。

今度(こんど)こそ君(きみ)だけは幸(しあわ)せにしてみせるよ

日语台词 - 001

2026-07-02T11:52:30+09:00

ララァ・スンは、私(わたし)の母(はは)になってくれるかもしれなかった女性(じょせい)だ。そのララァを殺(ころ)したお前(まえ)に言(い)えた事(こと)か！

抵抗(ていこう)すると無駄死(むだじ)にするだけだって、何故(なぜ)分(わ)からないんだ！？

人(ひと)は同(おな)じ過(あやま)ちを繰(く)り返(かえ)す...

親父(おやじ)にもぶたれたことないのに！！！

それが甘(あま)ったれなんだ。殴(なぐ)られもせずに一人前(いちにんまえ)になった奴(やつ)がどこにいるものか！

あんなの飾(かざ)りです！偉(えら)い人(ひと)にはそれがわからんのですよ！

僕(ぼく)は…取(と)り返(かえ)しのつかないことをしてしまった。

認(みと)めたくないものだな、自分自身(じぶんじしん)の若(わか)さゆえの過(あやま)ちというものを。

当(あ)たらなければどうということはない。援護(えんご)しろ。

たかが石(いし)ころ一(ひと)つ、ガンダムで押(お)し出(だ)してやる！

在 OpenWrt 上配置 Tailscale 服务

2026-02-24T14:32:01+09:00

Tailscale 是一个基于 WireGuard 协议的组网服务, 它可以实现跨平台的内网互联, 作为一个 Golang 编写的开源软件, 它提供了较为慷慨的免费服务如 DERP 等, 同时也为有更多需求的用户提供付费服务.

我的使用环境比较特殊, 家在佛山, 而我平时在东京租房上班, 使用 Tailscale 实现东京与佛山的设备互联, 方便通信和管理. 同时, 也可以实现一些需要特定网络环境的场景, 比如区域授权流媒体或者一些需要在特定网络环境下运行的应用.

在东京实际搭建的时候, 发现东京的主路由 K2P 性能实在孱弱, 一开始 ROM 不足以安装 Tailscale, 精简固件后勉强安装, 又 RAM 不足, 反复发生 OOM 的情况, 最终把一台一直吃灰的斐讯 N1 找了出来安装 Tailscale, 作为旁路路由处理 Tailscale 的流量. 最终形成了一个稍微复杂的网络结构, 佛山的主路由作为 Tailscale 网络的入口, 而东京的 N1 作为旁路路由, 处理 Tailscale 网络中的流量. 不过最终效果还是一样的, 即两地内网直接互访, 且均提供网络出口.

网络结构

地点	设备角色	设备系统	Tailscale 节点用途	内网网段	内网IP	设备型号
佛山	主路由	OpenWrt 24.10	内网入口, 提供局域网穿透	192.168.128.0/24	192.168.128.1	歌华链 GHL-R-001
东京	主路由	OpenWrt 24.10	无	192.168.9.0/24	192.168.9.1	斐讯 K2P
东京	旁路路由	Armbian 26.2.1 trixie	提供局域网穿透	192.168.9.0/24	192.168.9.235	斐讯 N1

当前使用的是 1.94.2 版本的 Tailscale 客户端. 网络结构中内网网段不应该重叠, 不然会导致冲突.

最终实现的网络拓扑是这样的:

    终端设备 (PC/手机/NAS)
               │
      东京 LAN (192.168.9.0/24)
               │
    ┌──────────┴──────────┐
    │                     │
  OpenWrt (192.168.9.1) ──┼─── [静态路由] ─── Armbian + Tailscale (192.168.9.235)
    │                     │                   ( 处理去往 192.168.128.0/24 的流量 )
    │                     └───────────────────┘
    │
    └─── 公网 (Internet) ─── Tailscale 网络 (DERP/P2P)
                │
                │
         OpenWrt + Tailscale (192.168.128.1)
                │
         佛山 LAN (192.168.128.0/24)

在东京侧, 所有 LAN 设备的默认网关仍是 192.168.9.1, 通过静态路由, 去往佛山的流量会被中转给 192.168.9.235, 最终通过 Tailscale 网络到达佛山的设备.

在 OpenWrt 上安装 Tailscale 及 Web 管理界面

OpenWrt 使用 opkg 作为包管理工具, 官方自带的软件源中 Tailscale 长期没有更新了, 所以我们需要从第三方软件源中安装 Tailscale. 同时这个 Tailscale 经过裁剪和优化, 更适合路由器这种内存和闪存资源有限的设备. 并且我们增加 Tailscale 的 LuCI Web 管理界面, 方便管理和配置.

下面提供的是命令行的过程, 主要是添加证书需要到设备的命令行中执行, 另外两项操作添加软件源和安装其实也可以在 LuCI Web 管理界面中完成. 这里需要注意, 添加第三方证书有一定的风险, 可能会有供应链攻击的风险.

安装 Tailscale 服务

添加证书

wget -O /tmp/key-build.pub https://gunanovo.github.io/openwrt-tailscale/key-build.pub && opkg-key add /tmp/key-build.pub

添加软件源

echo "src/gz openwrt-tailscale https://gunanovo.github.io/openwrt-tailscale" >> /etc/opkg/customfeeds.conf

安装

opkg update && opkg install tailscale

安装 Tailscale LuCI Web 管理界面

添加证书

wget https://Tokisaki-Galaxy.github.io/luci-app-tailscale-community/all/key-build.pub -O /tmp/key-build.pub && opkg-key add /tmp/key-build.pub

添加软件源

echo "src/gz tailscale_community https://Tokisaki-Galaxy.github.io/luci-app-tailscale-community/all" >> /etc/opkg/customfeeds.conf

安装

opkg update && opkg install luci-app-tailscale-community

配置 OpenWrt 上的 Tailscale 客户端

此时应该可以在 LuCI Web 管理界面中看到服务 -> Tailscale 选项, 点击进入配置页面. 在设置中点击登录, 会跳转到 Tailscale 网站进行登陆授权, 把这台设备添加到 Tailscale 网络中.

回到路由器的 LuCI Web 管理界面的 Tailscale 选项卡中, 需要打开 接受路由, 通告出口节点 这两个选项. 接受路由 用于接收 Tailscale 网络中的子网路由配置, 以实现不同内网的直接通信. 而 通告出口节点 则可以让 Tailscale 网络中别的设备选择通过这台设备代理进行网络访问, 即这台设备可以作为代理出口.

随后需要填写 通告路由, 填写的值应该是主路由对应的内网网段, 比如我这里, 佛山的 GHL-R-001 内网网段是 192.168.128.0/24, 东京的 K2P 内网网段是 192.168.9.0/24.

配置 Armbian 上的 Tailscale 客户端

在 Armbian 上安装 Tailscale 客户端的过程与 OpenWrt 类似, 只是需要在 Armbian 上需要使用命令行操作. 最终运行的命令如下

tailscale up --accept-routes=true --accept-dns=true --advertise-routes=192.168.9.0/24 --advertise-exit-node

配置 Armbian 的转发

确认 ipv4, ipv6 转发都已开启, 即值为 1

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

配置防火墙规则, 确保 Tailscale 网络中的流量可以正确转发

iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp \
--tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

并且固化以防止重启丢失

sudo netfilter-persistent save

在主路由上配置静态路由

在东京主路由 K2P 上, 需要配置旁路网关的静态路由, 以确保流量可以正确路由到 Tailscale 网络中的设备. 具体来说, 需要在主路由上添加一条路由规则, 到 192.168.128.0/24 的路由，下一跳为 192.168.9.235.

配置 Tailscale 服务管理

登陆 Tailscale 管理页面, 可以看到设备已经添加到 Tailscale 网络中了. 还需要在这个页面的设备管理上, 点击 Edit route settings..., 勾选对应的 Subnet routes 和 Exit node 选项. 不同设备都需要操作. 同时如果设备长期在线且物理安全可控, 也建议选择 Disable key expiry.

这里可能会有人纠结为什么要配置两次. 其实是因为 Tailscale 网络的 P2P 零信任的特性, 将节点状态的宣告和承认分开了. 宣告是节点将自己的路由信息告诉 Tailscale 网络, 而承认是 Tailscale 网络承认这个信息, 然后将这个节点宣告的路由信息通知给网络中的其他节点, 所以需要在节点和 Tailscale 管理页面上都配置一次.

配置 OpenWrt 上的防火墙

这里可以在 LuCI Web 管理界面中看到服务 -> Tailscale 选项卡中, 点击 自动配置防火墙, 会添加 lan => tailscale 和 tailscale => lan 这些区域转发规则; 然而由于上面我们配置了 通告出口节点, 所以还需要添加以下规则

uci add firewall forwarding
uci set firewall.@forwarding[-1].src='tailscale'
uci set firewall.@forwarding[-1].dest='wan'
uci commit firewall
/etc/init.d/firewall restart

这样允许流量从 Tailscale 网络中通过节点访问公网, 实现流量出口代理.

其他注意事项

通常需要在 OpenWrt 上开启 IP forwarding, MASQUERADE 和 MSS 钳制, 以确保 Tailscale 网络中的流量可以正常转发和路由. 一般来说 Tailscale 客户端和 自动配置防火墙 会自动处理这些配置. 网络异常时可以检查这些配置.
内网网段如果冲突了, 可以在 OpenWrt 上修改对应的 DHCP 配置.
由于调整了较多的网络环境, 比如防火墙, 路由等, 就不建议再套用其他的网络应用, 比如去广告等功能, 可能会导致冲突.

AI: 创新即复古

2026-01-11T22:47:18+09:00

在 LLM 相关的东西上折腾了一段时间之后, 我最强烈的一个感受不是"未来来了", 而是"这个我好像在哪见过". 每隔一阵子就有一个听起来很新的名词冒出来, 翻开报文一看, 里面躺着的是一个三十年前的东西.

下面三个例子, 是我记在备忘录里的三条段子.

SSE: 那我走?

Server-Sent Events 是 2000 年代中期的产物, 本质是在一个迟迟不结束的 HTTP 响应里持续发送文本事件. HTTP/1.1 下常见的实现是 chunked transfer encoding (1997), 到了 HTTP/2 和 HTTP/3 则连 chunked 这层都没有了. 格式简单到有点寒酸:

data: {"choices":[{"delta":{"content":"你"}}]}

data: [DONE]

WebSocket 出现之后, SSE 基本被归入"过渡方案"一类: 只能服务端往客户端单向推, 前端教程里通常一笔带过, 还附带一条广为流传的限制 - HTTP/1.1 下同域名最多 6 个连接, 开几个页签就用完了.

结果 LLM 来了. 逐 token 输出的打字机效果, 恰好就是"服务端单向推一串文本"这一个需求, 一点不多, 一点不少. OpenAI 的 stream=true 用 SSE, Anthropic 用 SSE, 几乎所有推理服务的流式接口都是 SSE, ~~然后各家在解析 data: 行的时候各踩各的坑~~.

为什么不是 WebSocket? 因为对于"一次请求换一串 token"来说, 要付的代价有点大:

需要 Upgrade: websocket 协议升级, 链路上的 CDN, 负载均衡, 企业代理, API 网关都得单独支持
握手仍然是 HTTP, 但升级之后不再有一问一答的请求语义; 鉴权, 错误码, 重试, 限流和可观测性都要映射到长连接里的应用事件
WebSocket 已经定义了消息边界和 Ping/Pong, 但业务消息, 序列化, 重连和断点恢复仍然要自己定义
如果连接承载了会话状态, 服务端扩缩容时还要考虑连接迁移, 亲和性和恢复

而 SSE 就是一个迟迟不结束的普通响应, Content-Type: text/event-stream, 其余一切照旧. 需求的形状对上了, 旧技术就赢了一局.

不过要说清楚, SSE 赢的是部署成本, 不是天然更可靠. 所有长连接都有一个很讨厌的性质: 没有应用层心跳时, 客户端分不清"服务端在想"和"连接已经死了". 一个正在生成的流, 和一个 TCP 路径已经断掉但 socket 还挂着的流, 从客户端看都可能是"打开着, 但没有新字节". NAT 表项超时, 移动网络切换, 负载均衡回收空闲连接, 都可能让故障不能立刻暴露, 而 TCP 自己的超时又很慢.

那后来是怎么补回来的? 心跳, 事件序号, 断点续传. OpenAI 的 background 配合 starting_after 就是让客户端记住每个事件的 sequence_number, 断线之后拿着游标从断点继续收. 而这三样东西, 恰好就是当年大家嫌 WebSocket 麻烦, 不愿意自己写的那一套.

需求的形状也还会继续变. 2024 年 5 月前后, 有用户观察到 ChatGPT 网页端开始使用 WebSocket, 一批依赖旧 SSE 行为的第三方客户端当场失效. 至于为什么切, OpenAI 没有给这次前端变化写一篇架构复盘, 下面只能算是推测: ChatGPT 早就不是"一次请求换一串 token"了 - 中断生成, 工具审批, 语音, 多任务并行, 切走再切回来内容还在继续同步. 服务端还要推送一些不属于当前生成请求的事件, 比如"另一个对话里的后台任务跑完了".

SSE 并不是不能传这种事件. 完全可以单独开一条用户级事件流, 再用 POST 发送上行消息, 当年的 MCP HTTP+SSE 就是这么干的. 只是到了这一步, 你已经有了两条通道, 会话标识, 事件关联和断线恢复, 越来越像是在 HTTP 上拼出一个 WebSocket.

所以真正的分界线不是"要不要流式", 甚至也不是 SSE "能不能做", 而是上行事件是否独立, 频繁到值得维护一条共享的全双工通道. 单个请求的输出流, SSE 赢, 因为它几乎不增加成本; 中断, 审批和并行任务越来越多时, WebSocket 的模型开始更自然.

Codex 的 app-server 则是生下来就在会话这一侧. VS Code 扩展这类富客户端跑在它上面, 默认传输是本地 stdio; 远程 TUI 还可以实验性地使用 WebSocket, 非本地连接再加 TLS 和 bearer token. 它要传的东西根本不是一串文本: 客户端随时可能发中断, 服务端随时可能反问"这条命令允许执行吗", 中间还夹着工具调用, 审批请求和沙箱状态. 用 SSE 加 POST 当然也能拼, 只是从第一天就不太划算.

所以 WebSocket 被重新拿起来, 不是因为 SSE 不好用, 而是因为 Agent 把"聊天"重新变成了"会话". 交互里有中断, 有审批, 有并行任务汇报时, 单向响应流仍然能做, 但不再是最省事的做法.

换个角度说, "复古"不是终点, 是钟摆. 长轮询 -> SSE -> WebSocket 这个循环二十年前走过一遍了, LLM 只是让它重新走一遍, 而且快得多. 至于实时语音那种低延迟, 带二进制音频流的场景, 则从头到尾都是 WebSocket 和 WebRTC 的地盘.

402: 睡了三十年的状态码

HTTP 状态码表里一直有个尴尬的空位: 402 Payment Required. 它从 RFC 2068 (1997) 起就在那了, 规范里的说明大意是"保留, 供将来使用", 于是它就一直"将来"了将近三十年, 成了所有人都见过, 但从来没人真正返回过的那一条.

它的原始设想是 90 年代的数字现金与微支付 (DigiCash, Millicent 之类), 而这条路线彻底失败了, 互联网最后选了另外两个答案: 广告和订阅. 微支付的问题从来不在技术: 为了 0.001 美元走一次授权流程, 用户的心智成本远大于金额本身, 更别提支付网络自己的手续费下限.

然后 x402 出现了, Coinbase 在 2025 年推出, 2026 年进了 Linux Foundation. 流程朴素得像教科书例子:

客户端请求资源
服务端返回 402, 并通过 PAYMENT-REQUIRED 带上支付要求 (scheme, 网络, 资产, 金额, 收款方)
客户端选一种支付要求, 签一笔转账授权, 带上 PAYMENT-SIGNATURE 重发同一个请求
服务端自己或通过 facilitator 验证并结算, 返回 200 和 PAYMENT-RESPONSE

早期 x402 v1 的请求头叫 X-PAYMENT 和 X-PAYMENT-RESPONSE, 到 v2 又把名字改成了上面这一套. ~~协议复古, 请求头倒是新得很快~~.

为什么现在成立了? 因为付钱的那一方换人了. 微支付对人类是骚扰, 对 Agent 是一次函数调用. Agent 不会为"要不要花 0.002 美元查一次这个 API"犹豫三秒, 也不需要填信用卡表单, 更不会因为多一步确认就流失. 需求方从"不耐烦的人"变成了"按预算执行的程序", 那个空置三十年的状态码就突然有了主人.

同类的还有 L402 (Lightning Network 加 macaroon) 和 Google 的 AP2. 顺便说, 结算手段是不是加密货币和 402 本身无关, 402 只是那个信封.

MCP: 请叫我 RPC

Model Context Protocol 听起来很新, 打开报文一看: jsonrpc: "2.0", method, params, id. 也就是 JSON-RPC 2.0, 2010 年的东西, 而 RPC 这个概念本身要追到 1980 年代.

REST 和 GraphQL 在 tools/call 面前基本没有位置, 这件事挺讽刺的. 过去十几年后端圈花了大量口水论证"不要 RPC 风格的接口": 要资源不要动作, 要正确的 URI 语义, 要 HATEOAS, 要让客户端用 GraphQL 自己挑字段. 结果最终的客户端是个大语言模型, 而它想要的东西是:

一份带自然语言描述的函数清单 (tools/list)
一份 JSON Schema 声明的参数 (inputSchema)
调一下, 拿结果 (tools/call)

这是最朴素的"过程调用加接口定义". JSON Schema 重新承担了过去 IDL 里"参数契约"的那一部分; WSDL 还管消息, 绑定和端点, MCP 没有把那整套 XML 大教堂搬回来, ~~WSDL: 我只是死早了~~. 更重要的区别在于, 过去的 IDL 主要写给编译器看, 现在还要写给模型看, 所以描述字段里塞的是人话.

传输层的演化也很有意思: 2024-11-05 版本是 stdio 加 HTTP+SSE 双端点, 2025-03-26 版本换成了 Streamable HTTP, 把 POST 和 GET 收到同一个 endpoint 上; POST 响应可以是 application/json, 也可以是 text/event-stream, GET 则可以单独打开一条 SSE 流. 而本地 MCP Server 到今天最主流的方式仍然是 stdio - 在标准输入输出上跑一个按行分隔的文本协议, 这是 Unix 管道时代的做法.

不只是协议

把范围放开一点, 会发现 AI 时代的"新"东西里, 复古的比例高得惊人.

神经网络本身: 感知机 1958, 反向传播 1986, LSTM 1997, 混合专家 1991, 注意力与 Transformer 2017. Transformer 当然是新想法, 但它站在一长串几度失宠的旧想法上, 最后再靠算力, 数据和工程把规模推了上去. 这大概是"创新即复古"最大的一个例子
命令行: Claude Code, Codex CLI, pi, 兜兜转转, 目前体感最强的 AI 编程界面之一又是终端里的 TUI. pi 更干脆, 默认只把 read, write, edit, bash 四个工具交给模型, 连 grep 和 find 都可以从 shell 里自己拿. 这套东西看起来不像 2026 年的 IDE, 更像是给 Unix shell 配了一个会说话的操作员. Unix 哲学里那句"纯文本是通用接口"重新生效了, ~~顺便它也是最省 token 的接口~~
调试: IDE 花了几十年把断点, 条件断点, Watch 和单步执行做得越来越精细, LLM 写代码时却很少碰它们, 最常用的还是 print, 日志和测试输出. 原因也很朴素: 调试器是给人盯着看的交互界面, 文本输出则可以直接塞进上下文, 复制, 搜索和重放. 于是最先进的编程模型, 又把我们带回了 printf debugging, ~~出问题先打两行日志, 这下人和 AI 平等了~~
纯文本与配置文件: README.md 和 Makefile 的位置被 AGENTS.md, CLAUDE.md 接了过去, robots.txt 有了 llms.txt 这门亲戚, 而文档格式的胜利者是 2004 年的 Markdown
计费与调度: 按 token 计费, 排队, 批量任务打五折, 高峰限流. 这是分时系统按 CPU 时间收费的复刻版, GPU 集群就是新的大型机, 我们又回到了"把作业提交上去然后等"的年代
爬虫战争: 训练数据引发的 robots.txt 之争, 版权诉讼与反爬对抗, 和二十年前搜索引擎时代的剧本几乎逐字重演
多智能体: 看起来很像是把 Jira 看板交给了程序. 主 Agent 把目标拆成 ticket, 分派给不同的子 Agent; 子 Agent 更新状态, 留下结果, 遇到依赖就阻塞; 最后再由主 Agent 验收和关闭. 底下当然是消息传递, 任务队列和共享状态, 但从组织方式来看, 它复刻的更像办公室里早就跑了几十年的工作流, ~~现在连开会的人也省了~~
无状态与有状态: 经典 LLM 接口每次请求把全部历史重新带上, 这是彻底的无状态, 很 REST, 甚至很 CGI; 后来 prompt caching, previous_response_id 和服务端会话又把状态放回了服务器, 于是会话存储和亲和性路由也一起回来了

为什么会这样

不是因为大家怀旧, 也不是因为没有新想法. 几条比较实在的原因:

约束条件回到了旧协议被设计时的样子. 老技术之所以老, 常常不是因为它错, 而是因为它解决的那个问题后来不重要了. SSE 是为"服务端单向推事件"设计的, 402 给网络原生支付留了一个空位, RPC 是为"跨进程调一个函数"设计的. 这三件事在 2015 年都不是主流需求, 在 2025 年全都是.

简单的东西赢. worse is better. 能直接复用现有基础设施的方案, 哪怕设计上"不够优雅", 也会赢过需要整条链路配合改造的方案. SSE 对 WebSocket, JSON-RPC 对 GraphQL, 都是同一个故事.

Gall 定律. 能工作的复杂系统总是从能工作的简单系统演化而来. 一个新协议要在一年内铺开, 现实的路径只有站在已经铺开的东西上面, 也就是 HTTP, 纯文本和标准输入输出.

变的往往是需求方, 不是技术. 402 最典型, 技术三十年没动, 动的是"消费者从人变成了程序". 一旦发起请求的一方不再是需要被哄着点下一步的人类, 一大批"技术上可行但体验上不成立"的旧设计就自动成立了.

最后一条不太好听: 标准的选择很多时候只取决于第一个跑起来的人用了什么. OpenAI 的接口一发, SSE 就是事实标准; Anthropic 把 MCP 一开源, JSON-RPC 就是事实标准. ~~关于技术优劣的讨论通常在既成事实之后才热烈起来.~~

那什么才是真的新

公平地说, 也确实有全新的部分:

Scaling Laws 对规模, 数据, 算力与损失之间关系的经验描述, 以及"继续放大可能继续变好"这件事催生的整套工程体系. 至于能力是不是"突然涌现", 那是另一场还没吵完的架
自然语言不再只是文档, 而是直接参与运行时决策, 同一句描述既可能是数据, 也可能被模型当成指令. 自然语言编程并非没有前人试过, 但从未像今天这样大规模进入生产系统; prompt injection 也正是在这种指令与数据边界不清的地方长出来
把一个输出永远带概率的部件, 放进了要求确定性的系统里. 相应的验证, 回滚, 幂等和边界设计, 目前还远没有成熟答案

换句话说, 复古的是管道, 新的是流过管道的那个东西.

后记

"创新即复古"并不是嘲讽. 一个能被三十年前的协议直接接住的需求, 说明这个需求足够朴素, 而朴素的需求通常是真需求. 反过来, 如果某个 AI 时代的新场景需要一整套全新协议栈才能表达清楚, 那大概值得先怀疑一下这个场景本身.

顺便, 这也是个还算好用的判断技巧: 看到一个新名词, 先问一句"它复古的是什么". 通常能立刻定位到它的设计权衡在哪里, 以及三十年前那批人当年是在哪一步上失败的.

参考链接

漫谈 <战场之狼2>

2025-11-17T16:31:57+09:00

忽然想起了幼年时期看表哥玩的一款游戏, 当时年纪比较小, 当然不记得游戏的名字了, 我把对于游戏的印象发送给 ChatGPT, "Mega Drive 上的一款游戏, 类似魂斗罗, 军事背景的, 但是不是从左到右的横向卷轴式, 而是俯视角的", ChatGPT 给了我确切的答案, 那就是戦場の狼II, 英文名为 MERCS, 中文的话, 一般就直接叫<战场之狼2>.

这款游戏本身是从街机移植的, 现在看来, 这个游戏其实有蛮多值得一提的地方.

游戏本身亮点

<战场之狼2> 加入了大量载具的元素. 在流程中, 可以驾驶吉普车, 固定炮台, 甚至是坦克, 在当时是非常先进而罕见的设计.

从街机移植到 Mega Drive 的版本中, 去掉了街机厅联机的多人模式, 但是增加了一个非常有诚意的弥补家用机无法"投币"而做的长线玩法 原创模式 (Original Mode), 有 5 名不同特性的队员, 包含了 RPG 要素, 可以购买装备和升级.

个人英雄主义式流程

<战场之狼2> 的流程很简单, 你扮演一位突击队员, 从敌国的海岸, 丛林, 基地一路挺进, 孤身推进, 所到之处弹雨横飞, 最后直捣敌军老巢.

在今天看来是非常陈旧的"动作片模板", 但对当年的玩家来说, 这种 "一个人扫平整个军队" 的叙事方式是极具吸引力的. 那正是史泰龙与施瓦辛格主导银幕的年代: 好莱坞动作片, 冷战故事, 肌肉英雄, 特种部队神话风靡一时, 游戏文化也深受其影响.

受限于当时的技术表现力, 游戏天然倾向这种"我方单枪匹马, 敌人不断涌现"的流程设计. 俯视角, 固定火力射程, 高密度敌人分布, 这些机制既使玩法易于实现, 又高度契合了"孤胆英雄"这种叙事风格. 这种设计既是技术妥协, 也是时代偏好的产物.

深受冷战叙事影响的游戏背景

<战场之狼2> 的故事背景几乎就是一篇"冷战动作片模板":

虚构国家发生军事政变
美国(前)总统被敌人绑架(这里对于是否是"前", 不同版本似乎有不同的设定)
美国不愿公开军事介入, 秘密派出精锐佣兵部队执行营救行动
推翻邪恶的敌国政府

在战斗表现上更是明显:

敌方大量使用苏式/华约武器: AK 与 RPG 系列轻武器, T-55/T-62 外形的坦克, ZSU 风格的防空炮
我方则是典型美国/北约装备: 突击枪外形接近 M16 系列, 载具则是美式直升机与吉普车

今天看来, 这种设定显然属于典型的, "小国威胁美国的安全与尊严", "正义的我们邪恶的他们", "以军事行动干预他国内政"的世界警察叙事, 在 80–90 年代, 日本游戏与美式娱乐深度绑定的时期, 它却是最常见的标准剧本.

这种"虚构国家"加"阵营符号化明显"的脸谱化的处理方式, 既避开了现实政治敏感性, 又能让玩家在低清晰度下的像素点下一眼认出"谁是敌人".

它并不是真的在讲故事, 而是在为一种既定的世界秩序提供幻想式的正当性. 敌国往往缺乏真实的历史及文化或政治细节, 它存在的唯一理由, 就是为主角的合理暴力提供舞台, 并以游戏的形式输出冷战时期的意识形态框架.

早期街机付费模式

作为街机移植, <战场之狼2>有一个无法忽视的背景, 街机付费模式决定了它的难度结构.

在街机黄金年代, 几乎所有游戏的设计都围绕一个核心目标展开

如何让玩家在 2-3 分钟内死亡一次, 从而投下下一枚硬币?

于是, 游戏呈现出一种独特的设计:

开场几十秒极易上手, 让玩家建立信心
经常有"检查点", 考验特定的操作
BOSS 通常有"初见杀"
后期敌人密度与弹量指数级增长
续币后的短暂无敌或清屏收益巨大
游戏完整流程维持在一到两小时内

这种设计在当时被视为理所当然, 然而从今天的玩家习惯来看, 早期街机的"投币续命式付费模式"无论在付费模式还是游戏体验上, 几乎不可能再次被广泛接受. 在娱乐内容非常丰富的现代, 让玩家感到挫折的游戏不再被视为"挑战性强", 而是"没有性价比", 几乎不会有人会愿意付钱继续忍受, 而是直接离开, 换一款更省心的游戏.

后记

回头再看<战场之狼2>, 它是那个时代一个颇有代表性的作品

流行文化与技术表现力的限制共同塑造的个人英雄主义叙事
深受冷战意识形态影响的武器与阵营符号以及国际关系
难度流程与街机商业模式紧密绑定

在今天的视角里, 它显得粗糙甚至原始. 但也正因为如此, 它很像是那个年代的化石. 有时候回忆的价值并不是它在今天还有多好玩, 而是它让我们重新看见自己曾经生活在怎样的世界里.

在查找资料过程中发现在 Steam 上有售, 在 Capcom Arcade Stadium 中作为 DLC 售卖, 不过似乎是街机版本.

参考链接

Fake News 的一件小事

2025-11-13T15:08:27+09:00

最近, 中华人民共和国驻大阪总领事薛剑在 X 上的言论引起了一些争议, 具体的言论如图:

具体的日文原文如下:

勝手に突っ込んできたその汚い首は一瞬の躊躇もなく斬ってやるしかない。覚悟が出来ているのか。

其回应的推特原文如下:

高市首相、台湾有事「存立危機事態になりうる」　認定なら武力行使も https://www.asahi.com/articles/ASTC722TVTC7UQIP04NM.html 「実際に発生した事態の個別、具体的な状況に応じて、政府がすべての情報を総合して判断する。武力攻撃が発生したら、これは存立危機事態にあたる可能性が高い」とも語りました。

FOX NEWS 在新闻页面上给出的英文翻译如下:

That filthy neck that barged in on its own. I've got no choice but to cut if off without a moment's hesitation. Are you prepared for that?

在与特朗普的专访对谈中, 劳拉·英格拉哈姆, 美国一位广播脱口秀主持人, 畅销书作家和保守派政论家, 这样描述这段发言:

Laura Ingraham: And over the weekend, the new Japanese prime minister, who I know you like a lot, Takaichi, called the Taiwan situation extremely severe in its phase and that they may consider any move on Taiwan by China to be a national survival crisis for Japan. Now that gets better. A Chinese diplomat today said in a social media post that, she the prime minister of Japan, should be beheaded for her comments.

而特朗普做出的回应如下:

President Donald Trump: Well, a lot of our allies aren't our friends either. Our allies took advantage of us on trade more than China did. And China took big advantage. We built their military. We built their whole thing.

从这个事件, 可以清晰的看到 Fake News 是如何产生的. 从传播效果看, 这次转述并非凭空捏造, 而是通过省略语境, 消除指代上的模糊, 把原文中带有暴力意象的激烈言辞, 收束成了一个更直接, 更具体的, 更具爆炸性的结论: 一名中国外交官主张斩首日本首相. 这种压缩强化了事件的耸动性, 也更容易让观众和美国总统特朗普将其理解为针对首相本人的明确人身威胁。

这位美国总统多次表明过, 不准确, 偏见, 断章取义的新闻报道是 Fake News, 也算是身经百战见得多了, 没有具体事情上做评论, 而是谈起来日本并不是美国的朋友, 转回他熟悉的对盟友在经贸问题上占便宜的叙事框架, 场面一度略显尴尬.

参考资料

PlayStation 4 Pro 拾遗

2025-10-30T19:38:09+09:00

这台 PlayStation 4 Pro 其实也买了挺久了, 当时还是买的国行版本, 然后因为长时间的租房生活, 并没有什么条件和时间来玩, 最终长期的吃灰, 甚至借给朋友玩了好长时间 (当然他买的怪物猎人世界: 冰原在还机器的时候一并送我了)

带来日本后, 最近又捡起来了, 得益于秋叶原线下的二手交易市场, 发现其实还是比较可玩的. 第八世代其实是个比较特别的世代. 一方面, 主流游戏玩法已经日趋成熟, 画面也有比较大的提升, 很多音画体验时至今日也不算过时; 另一方面, 此时开发成本还没有像近些年来一样飙升, 一些有意思的小品作品还有相对较大的生存空间; 同时在这个世代, 主机还处于相对优势, 大量作品还是主要以主机平台为核心开发的.

综上所述, 下面会列出一些还比较值得在 PlayStation 4 Pro 上体验的游戏, 其中个人喜好比较重, 仅供参考, 主要在 1080P 的屏幕下. 如果涉及多平台, 主要对比的对象是 PC 和 Nintendo Switch

个人推荐

尼尔: 自动人形 (ニーアオートマタ, NieR:Automata)

白金工作室, 标志性头套本体横尾太郎总监的动作角色扮演作品, 当年性感可爱的 2B 小姐姐几乎成为线下漫展 Cosplay 的象征. 虽然在 Steam 上也有(在这里), 推荐在 PlayStation 4 Pro 上体验的原因是日本厂商游戏的高定价, 涨价风波和分割商法, 另外, 在 PC 上体验很差, 移植比较暴力优化不佳, 无中文, 而且操作逻辑偏向手柄操作. 在 PS4 Pro 上可以达到不稳定的 60 帧, 也自带繁体中文.

荒野大镖客: 救赎 (Red Dead Redemption)

Rockstar 的经典西部开放世界作品, 剧情颇受好评. 在 PS4 和 Switch 上移植, 也有登陆 Steam (在这里), 本身是第七世代的作品, 有一些在现代玩家中不太讨喜的设计, 移植可以说是原汁原味了. PlayStation 4 Pro 上比 Switch 画面效果和流畅度好太多了. 而移植后本身无联网要素, PC 上却需要很讨厌的 Rockstar 启动器.

龙腾世纪: 审判 (Dragon Age: Inquisition)

BioWare 的代表作, TGA 的 2014 年度游戏, 第八世代早期的作品, 登陆 Steam (在这里). PC 上没有中文, 还要安装 EA 的启动器, 还有额外的 DRM. 在 PS4 Pro 自带繁体中文.

刺客信条: 奥德赛 (Assassin's Creed Odyssey)

育碧年货, 但是古希腊的背景蛮吸引人的. 登陆 Steam (在这里). PC 上需要 Ubisoft 的启动器和额外的 DRM.

LoveR (ラヴアール)

和美少女谈恋爱并且给美少女拍照的游戏. 爱相随 的人设, 圣诞之吻, 写真女友 的制作人, 好耶! 目前只有 Switch 和 PS4 版本, 原本计划登陆 Steam, 但是因为某些大人的原因取消了. Switch 版本虽然性感元素更多, 但是画质会差一些.

汪达与巨像 (ワンダと巨像, Shadow of the Colossus)

PlayStation 系独占的经典作品, 本身是 PS2 上的游戏, 在 PS3 上高清化,在 PS4 上推出完全重制版, 目前体验的唯一最佳途径. 虽然某些操作在现代玩家看来略显笨拙, 但是游戏给人带来的非常艺术化的沉浸式的体验和史诗感是绝对物有所值的.

凯瑟琳浓郁口感 (CATHERINE Full Body)

Atlus 推出的推箱子解谜游戏, 原版是第七世代的作品, 本作为其后推出的强化版. 玩法不那么受欢迎的实验性质的作品, 但是剧情和对于两性关系的刻画与思考蛮有意思. 虽然也登陆了 Steam (在这里), 但那是原版而非强化版, 而且移植蛮糟糕的. 强化版在 Switch 上也可体验.

重力异想世界完结篇 (GRAVITY DAZE 2/重力的眩暈完結編:上層への帰還の果て、彼女の内宇宙に収斂した選択)

PS4 独占. 这是二代, PS4 上也有从 PS Vita 移植的一代. 体感和手柄的重力操控玩法和日式美术风格, 带来独特体验的作品.

奥丁领域: 里普特拉西尔 (オーディンスフィアレイヴスラシル, Odin Sphere: Leifthrasir)

PlayStation 系独占, 从 PS2 上的原版重制而来. 香草社无需多言, 华丽的手绘风格的 2D 横版卷轴动作游戏.

看门狗 (Watch Dogs)

育碧公式化开放世界, 但是结合黑客/开放世界/现代都市体验元素的目前就此一家. 这个系列的经历在第八世代颇有代表性, 看门狗本身是新 IP, 首部是 PS4 早期的作品, 宣传时画面十分惊艳, 让人们对即将到来的第八世代主机的性能充满期待, 然而实际发售后画面表现缩水严重. 第二部则是换一套背景继续公式化出装, 丰富了玩法, 算是中规中矩的提升. 而最新的 2020 年的第三部 <看门狗: 军团> 则因为商业和管理上的问题, 很大可能是为了线上模式, 导致整体表现不佳, 目前这个 IP 短期内无重启的希望. PC 上则还要面临优化不佳, 对 Windows 系统升级不做适配, 中文化拖拖拉拉的问题, 操作也主要面向手柄. Steam 版本(在这里)还要带上一个陈旧的育碧启动器.

碎碎念

虽然其实很早就接触主机游戏了, 小时候在富裕表哥家里玩过 SFC, Mega Drive 和 PlayStation 2, 掌机也曾拥有过 Gameboy Advance, PlayStation Portable 和 Nintendo DS, 但是第八世代的游戏留下的印象还是颇为深刻. 主要还是因为那时上了大学, 有比较充足的时间玩游戏. 与此同时, Steam 开始支持人民币支付, 购买游戏方便了很多, 我还记得之前通过 骑马与砍杀中文网 买一份正版的 <骑马与砍杀> 多么不方便. 那个世代的游戏, 也有那个世代的特征, 不重视中文玩家, 主机独占策略, 主机优先导致的优化以及操作问题, 部分厂商激进的联网化和平台化策略, 防盗版策略. 不过还是希望能有更多人, 能体会到那个世代的游戏的快乐.

参考

555余款游戏在PS4、PS4 PRO、PS5上的分辨率帧数统计汇总

炸鸡与西瓜

2025-08-07T21:46:01+09:00

在美国, 炸鸡和西瓜有特别的意义.

奴隶制时期, 西瓜和鸡因为廉价, 是少数黑人奴隶可以接触的食物. 随着黑人奴隶的解放, 西瓜和炸鸡也成为了许多非裔美国人的生计, 代表他们的自由与经济独立. 同时, 许多白人种族主义者以炸鸡和西瓜来丑化和侮辱非裔美国人, 塑造他们原始, 懒惰, 贪婪和粗俗的形象.

虽然黑人民权运动后非裔美国人的状况已有显著改善, 西瓜和炸鸡在特定语境下仍可能被用于重现历史上的种族刻板印象.

不过, 好吃的就是好吃的, 更不必说这其中寄托着对自由和平等的追求更添美味, 给我再来一份葡萄汽水.

Windsurf 入门指南

2025-06-14T18:30:10+09:00

为什么是 Windsurf

曾经叫 Codeium, 在 2022 年还是 Github Copilot 的时代即提供支持 VS Code 和 JetBrains 的 AI 编程工具插件; 于 2024 年推出类似于 Cursor 的基于 VS Code 的 IDE Windsurf, 随后将公司更名

免费的基础使用和更便宜的订阅价格
和 Cursor ~~互相抄~~ 功能没太大区别
被 OpenAI 以约30亿美元收购

目前告吹, 公司核心成员被 Google 挖走后开发 Devin AI 的 Cognition 收购了公司, ~~然后开始了疯狂加班~~

被 Anthropic 断供~~高端的 AI 商战~~, 目前不能使用 Claude 4, ~~被收购之后恢复了~~

Cursor 相关的信息污染太厉害了, 乔戈里峰问题

最近我发现 TREA 好像更好用, 问题似乎出在 Windsurf 配置的上下文太短了, ~~Kiro 大法好~~

主要功能

相比插件更好的代码上下文感知 Context Awareness, 记忆能力, 调用第三方工具能力

Tab

补全, 跳转, 导入

Command

唤出输入框输入指令, 适用于当前文件范围内的修改, 作用于当前游标位置或选中的代码段

小技巧, 在注释中写入指令, 然后 Cmd/Ctrl+I 随后使用类似 do it 这样的简单指令即可

Cascade

项目范围的大规模理解与调整, 可以运行命令行, 网络检索等工具, 也可以通过 MCP 协议调用外部工具

Planning Mode: 将计划输出到 Markdown 文件, 便于调整和长流程处理
Browser: 读文档, 获取网页内容; 前端开发

总结

三个功能从上到下, 需要的人工的输入越来越多, 上下文感知要求越来越强, 流程和处理时间越来越长, 根据适当情况选择适当的功能

原理与局限

神经网络的仿生学原理, 生物神经系统存在大量通过突触连接的神经元, 特定神经活动使关联的神经元突触产生可塑性变化, 是记忆和认知的基础; 神经网络通过数学模型, 用于编码输入与输出之间的概率关联, 本质是数据统计上的关联; 生物的神经系统的学习过程是持续发生的, 学习与使用并非截然分开, 而当前的大语言模型通常将"训练"与"推理"严格分离, 参数在训练后即固定, 所以不要尝试"教会"它, 因为它知道错了也不会改, 而是要通过 prompt 提供上下文信息, 使其在有限的上下文窗口中做出合理响应

上下文能力长度的限制, 上下文限制不仅在输入端, 同时在中间状态与输出端, 所以大模型能精准利用的有效上下文会明显比标示的上下文 token 参数小
注意力机制, <Attention is All You Need>, 但是 Attention 不是 Understanding, 无法主动区分重点与细节, 只是根据训练统计模式做 token 级别的预测
缺乏长期记忆机制, 不能自发积累跨 Session 经验和知识, 需要外部记忆模块

严格来说模型是可以做轻量微调(PEFT)的

大语言模型是高性能的统计关联引擎, 其输出本质是"有结构的幻觉" - 杨立昆的观点

最佳实践

比喻

用 minori 的 <ef - a fairy tale of the two.> 的情节来描述大模型非常合适. 新藤千寻在 12 岁时由于事故患上顺行性遗忘症, 从那以后的事情她只能记住从当时往前推算的 13 个小时. 每一个清晨醒来, 她都必须重新阅读自己的日记，从中寻找"我"的线索, 并在日记本上不断续写她自己. 少年麻生莲治在车站与其相遇, 两人的距离在不断的相识与遗忘中逐渐缩短, 经过挣扎和犹豫两个人最终走到了一起. 这段爱情也带着某种悖论式的悲伤, 对于莲治来说, 他无比喜欢千寻, 但是某种意义上来说, 千寻只是在扮演日记本中那个喜欢莲治的自己.

日记本

所以归根到底, 是要给~~美少女~~大模型提供优化过的~~日记本~~prompt

总是使用 Markdown 写文档, 大语言模型对其有优化
一致的项目结构与命名规范
提供项目的结构和功能的描述, User Story, Product Requirement Document, 记录决策与约定
显式且准确的提供完成任务所需的上下文内容和工具调用, 善用@提示
积极的使用 Workflow 和 Rule 功能, 实际上就是模版化标准化的 prompt 的应用
~~Prompt Engineering is Dead, everything is a Spec.~~

自我强化

让模型自己进行总结归纳, 做手动调整, 再作为 prompt 给到模型上下文, 以此循环
压缩 prompt, 并且让模型自己来验证它是否理解 prompt
渐进式的任务分解提示, 分步骤的提示和指令, 让模型自己来做流程的完成情况维护
让 Agent 提问题, 写 QA

其他注意

写通用的规则, 然后用 Markdown 的超链接功能引用, 抹平 IDE 规范差异
不要使用大模型做代码格式化 (可以让 Cascade 调用外部工具来处理)
多 commit 和 commit --amend, 防止人工智障智能大规模删改文件
复杂操作生成操作清单而非直接执行
标记工具生成的代码的位置, 以免大模型直接修改
将常用代码封装成可复用的模块, 并写好 README.md, 减少大模型上下文负担
矛盾, 模糊和不准确的信息会让大模型偏移
当 Session 偏离, 立刻开启新的 Session, 不要纠结
将命令编写结构化的 Markdown 文档, 然后在 Cascade 对话框中引用 (如果"几句话就能说明的东西"就调用 Cascade, 那很有可能是用的不对)

总结

Windsurf 的人工智能, 将补全, 重构, 规划, 搜索和执行结合为统一体验, 从局部函数到全局架构, 都可以以更自然的方式与其协同. 但它并不魔法般全能, 它依赖上下文, 依赖清晰的项目结构, 依赖好的 prompt 提示与任务规划. 因此, 真正的生产力提升, 并非来自"你来把这个代码写了", 而是来自构建了一个让它理解, 协作, 执行的良好环境. 也许可以把 Windsurf 看作每天早上醒来要读你笔记的~~美少女~~程序员, 而开发者的职责, 就是写好那本"日记本", 明确的目标, 清晰的上下文, 有逻辑的步骤和合理的调用.

其他一些看法

Vibe coding 译为氛围编程, 在实践中, 对编码能力的要求下降了, 但是对项目规划和产品设计, 团队协作和组织能力, 团队积累与结构化知识的要求反而是提高了, 某种意义上来说, 反而拉大了组织与组织之间的差距. 人工智能更像一个每天都是新入职的, 代码能力扎实的实习生, 如何让其能快速了解代码规范, 项目架构, 周边工具, 沟通方法才是发挥其作用的关键. 开发者角色也从"代码生产者"转变为"意图定义者", 核心能力迁移到问题验证与处理, 领域建模, 知识结构化和精准表达.

组织差距:
强的组织 -> 精准的领域语言 -> 结构化知识库 -> AI 高效产出
弱的组织 -> 模糊的需求 -> 碎片化的信息 -> AI 混乱输出
开发模式:
传统模式 [记忆 -> 检索 -> 编码]
AI 模式 [意图 -> 验证 -> 优化]

大语言模型的原理和局限也决定了它在 Day 0 即代码从头开始的效果比较好, 而 Day 1+ 即后续的开发和维护上, 会需要开发者更多的指引.~~身为程序员最讨厌的就是写文档和别人不写文档~~拒绝 YOLO coding

更进一步

什么才能称得上思维, 思考的本质, 观点与偏见, 错了也不改与反例的权重, 波普尔的 可证伪性(Falsifiability)

乔戈里峰
杨立昆

参考资料

王司徒的道理

2024-12-25T12:58:00+09:00

整理自我在知乎问题诸葛亮王朗论战, 我感觉王朗说得好有道理怎么办? 下的回答.

如果抛开演义的修饰结合正史, 王司徒的话确实不无道理.

倘若真如诸葛亮所说 "吾素知汝所行", 那王司徒的前半生可以好好探讨一下.

王朗前半生主要在地方任职. 他曾任会稽太守, 在任时获百姓爱戴. 随后孙策入侵江东, 王朗抵抗不敌, 转移到侯官 (今福建福州), 与侯官县长商升联合继续对抗孙策. 而后商升慑于孙策威名打算投降, 引发内乱, 终被孙策平定. 王朗意图前往交州继续抵抗, 出海时被孙策追击, 被迫投降. 孙策敬重其为人, 不加害并予以招揽, 王朗不从. 建安三年, 曹操上表征召王朗, 因久经战乱道路不通, 王朗辗转数年才到任, 由此开启了他作为中央官员的后半生.

从孙策的角度来看, 平定江东的故事仿佛顺水推舟. 但是对于汉朝中央政府来说, 江东并不是无主之地. 王朗是中央政府正式任命的地方长官, 有势力以武力强夺地方政权, 他与之对抗理所应当. 王朗长于治理而弱于军事, 被孙策打败并不奇怪. 但是从他治理地方清平, 抵御外敌坚决的经历来看, 他完全对得起这份汉禄.

汉室倾颓有两条脉络, 一是中央混乱, 二是地方割据. 从地方长官王朗的角度来看, 刘备, 孙策这些袭击中央任命的地方长官, 造成地方实际割据的人, 是不是也需要为汉室倾颓负一部分责任? 刘璋, 刘繇, 刘表这些中央任命驻守地方的汉室宗亲, 难道都是应该被讨伐的乱臣贼子?

孙策奉袁术之命讨伐江东, 实为割据, 而袁术随后公开称帝. 益州刘璋, 荆州刘琮暗弱, 意图向中央归降, 刘备夺其州郡, 兼并其众. 个人能力有限, 王朗只能做治世之能臣, 做不了乱世之奸雄. 但是汉室倾颓的责任, 相比起王朗, 刘备, 孙策这些人可大得多.

只是这层两方都是汉室倾颓元凶的道理, 怎么能在两军阵前明说? 这种潮流滚滚向前, 力不从心的心情, 又怎么能在两军阵前细说?

2024 诺贝尔物理学奖小记

2024-10-09T20:18:58+09:00

杰弗里·辛顿出自书香世家, 他有一位堂姑, 叫琼·辛顿, 当然, 中国人应该更熟悉他的这位堂姑的中文名, 寒春

感觉像是唐纳德·特朗普的叔叔约翰·特朗普为中国核物理事业做出了贡献一样有着奇妙的联系

一个对象同时只能有一笔有效支付

2024-08-18T16:20:33+09:00

从一个看起来很简单的需求说起

一个订单要能支付. 听上去就是加一个 status 字段: 未支付, 支付中, 已支付, 支付失败.

真做起来会发现不够用:

支付失败了可以再试, 于是一个订单对应的是多笔支付记录, 不是一笔.
用户点了支付, 跳到渠道的支付页面, 又退回来再点一次. 这时候不能建第二笔.
支付结果是异步回来的, 回来的时候得知道它对应哪一笔.
后来账单和预约也要支付, 流程几乎一样.

这几件事合起来, 就不是一个状态字段能表达的了.

先说清楚「一笔支付」是什么

一笔支付指的是一次支付尝试, 对应一条交易记录, 它自己有:

交易 ID —— 全局唯一, 后面会看到它同时是发给渠道的幂等键;
状态 —— 待支付 / 支付中 / 成功 / 失败 / 取消 / 已退款;
金额, 支付方式, 以及渠道侧返回的流水号.

用户第一次点支付, 建一笔. 失败了再点, 是新的一笔, 而不是把原来那笔改回「待支付」重来. 原来那笔停在失败终态, 之后不再变动.

这一点值得强调: 交易记录进了终态就不再改. 所以对账的时候能还原出"这个订单被尝试支付过几次, 每次分别是什么结果". 如果复用同一条记录反复改状态, 这些信息就没了, 出了问题只能靠日志去猜.

历史流水与「当前有效」

第二件要分清楚的事: 一个业务对象会有很多笔支付, 但任一时刻最多只有一笔是「当前有效」的.

历史流水: 每次发起支付都是一条记录, 有自己的状态和终态, 不删不改;
当前有效: 这个订单现在到底压在哪一笔上.

把这两件事混在一起, 就会写出"取最新一条支付记录"这样的查询. 它在大多数时候是对的, 在并发的时候不是.

所以把「当前有效」显式建成一个东西, 一个从业务对象指向当前交易的指针:


flowchart LR
    Target["业务对象
订单 / 账单 / 预约"]
    Gateway["支付渠道"]
    Result["异步结果
回调 / 查询 / 前端跳转"]
    Unknown["调用栈失败
受理状态未知"]

    subgraph TxModule["支付模块"]
        Active["ActivePayment
当前有效交易指针"]
        Tx["Transaction
历史流水 + 当前状态"]
        Final["终态
成功 / 失败 / 取消 / 退款"]
        Active --> Tx
        Tx --> Final
    end

    Target --> TxModule
    Tx -->|"发起支付
交易 ID 作为幂等键"| Gateway
    Gateway --> Result
    Result -->|"收敛结果, 更新状态"| Tx
    Tx -->|"支付中: 幂等拦截"| Target
    Gateway -.-> Unknown
    Unknown -.->|"调用失败 ≠ 业务失败
保持支付中"| Tx

这个指针有三条约束:

唯一索引. 数据库层面保证一个业务对象只能有一条有效记录. 这是兜底, 不是优化 —— 应用层的判断一定会有漏网的并发路径.
创建新交易和切换指针在同一个事务里. 否则会出现"交易建好了但没人指向它", 或者反过来.
切换时带上旧的交易一起匹配, 匹配不上就不切.

第三条是关键. 两个请求同时想发起支付, 都读到"当前没有有效交易", 都去创建. 没有第三条, 后一个会盖掉前一个, 于是有两笔交易都以为自己是有效的. 把旧值作为更新条件, 就只有一个能成功 —— 是 CAS 的思路, 只不过落在数据库上.

一个前提: 渠道必须支持幂等键

接外部支付渠道之前, 有一件事要先确认: 渠道必须支持幂等键. 后面讲的所有做法都建立在这个前提上.

具体说, 发起支付的时候要带一个自己生成的唯一标识, 渠道保证同一个标识只受理一次. 第二次带着同样的标识过来, 它返回的是第一次的结果, 而不是再扣一次钱. 这个东西在各家渠道的文档里通常叫「商户订单号」或者 idempotency key.

前面说的交易 ID 正好就是这个键, 两件事是配套的:

同一笔支付的重发 —— 同一个交易 ID —— 渠道认得出来, 不会重复受理;
失败后重新发起 —— 新的一笔, 新的交易 ID —— 渠道当成一个新请求处理.

所以"一笔支付一个 ID"不只是为了记账. 没有它, 你没办法告诉渠道"这是同一次尝试的重发"; 而没有渠道侧的幂等保证, 你根本不敢重发.

如果渠道不支持幂等键, 后面的做法就都要打折扣: 超时之后不敢重发, 只能干等查询或回调; 查询接口还必须能按你自己的标识来查, 否则拿回一堆渠道流水, 你对不上是哪一笔; 最坏的情况是只能人工对账.

这件事在接入前确认, 比写完之后再补要容易得多.

三个「不等于」

接了外部支付渠道之后, 真正的麻烦才开始. 踩过的坑可以归纳成三句话.

一, 受理成功 ≠ 支付成功

调用渠道的支付接口返回成功, 只说明对方受理了这笔请求. 用户可能还没输密码, 3DS 验证可能还没过, 发卡行可能还要几秒钟.

所以接口返回之后, 交易的状态是「支付中」, 不是「成功」. 真正的结果通过回调, 主动查询或者前端跳转带回来.

这条比较容易接受. 下一条就不是了.

二, 调用失败 ≠ 业务失败

这是最危险的一条.

调渠道的接口, 超时了. 或者连接断了. 或者收到一个 5xx. 直觉是把这笔标成失败, 让用户重试.

这个直觉会导致重复扣款.

因为超时只说明你没收到响应, 不说明对方没收到请求. 对方很可能已经受理了, 正在处理, 过一会还会给你回调:


sequenceDiagram
    participant B as 业务系统
    participant G as 支付渠道
    B->>G: 发起支付
    Note over G: 已受理, 开始处理
    G--xB: 超时 / 连接断开
    Note over B: 若此时判失败
用户重试 → 重复扣款
    G->>B: 回调: 支付成功
    Note over B: 保持「支付中」
才能正确收敛

正确的做法是: 调用栈失败的时候不下结论. 保持「支付中」, 把判断留给查询接口和回调. 宁可让用户多等一会, 也不能让他付两次.

顺带一提, 这个问题是在测试阶段发现的, 不是线上. 能在测试阶段撞上, 是因为特意去构造了渠道受理超时的场景 —— 这类路径不主动造是撞不到的, 而它一旦在生产上出现, 后果是资金差错.

三, 「支付中」必须是一道幂等挡板

有了前面两条, 「支付中」这个状态就承担了很重的职责: 只要还在支付中, 任何重复的支付请求都不能建新单, 也不能重新发起.

用户在渠道的支付页面上刷新, 后退再点一次, 前端超时自动重试 —— 这些都会打到同一个入口. 幂等在这里不是加分项, 是整套设计成立的前提.

多种支付方式, 一个生命周期

支付方式会越来越多, 而且形态差别很大:

服务端直接发起: 拿到卡号或者已保存的支付凭证, 直接调渠道扣款;
需要用户跳走: 生成一个页面地址, 用户跳到渠道那边完成, 再跳回来;
需要用户在别处操作: 生成一个二维码或者付款码, 用户拿另一个 App 扫;
异步到账: 生成一个待付款凭证, 用户去便利店或者网银付, 可能几小时甚至几天之后才到账.

它们的差异全部在发起那一步: 参数不一样; 有的调完就结束了, 有的要先生成一个地址或者二维码存进交易里; 有的发起之后还要等用户在另一个地方操作.

但发起之后的事情完全一样 —— 都进入支付中, 都等异步结果, 都要回写, 都要幂等. 所以差异收敛在入口, 共性收敛在生命周期:

发起支付   ->  按支付方式分支
收敛结果   ->  成功 / 失败 / 取消 / 退款

新增一种支付方式, 只需要在发起那一步加一个分支, 不用碰状态机.

多个业务对象, 一套支付

后来账单和预约也要支付.

最省事的做法是把订单那套复制一份. 但支付这块的复杂度上面已经讲过了 —— 复制一份意味着幂等, CAS, 异步回写这些坑要重新踩一遍, 而且三份代码会慢慢长得不一样.

更好的做法是把方向反过来: 支付模块不去了解业务, 而是定义一份契约, 让业务对象来实现它.

type PayTarget interface {
	PayCheck(ctx context.Context) error   // 现在能不能支付
	Pay(ctx context.Context) error        // 锁定为支付中
	PaySuccess(ctx context.Context) error // 支付成功后回写
	PayFailed(ctx context.Context) error  // 支付失败后回写
}

支付模块拿到一个目标 ID 和它的契约实现, 就能跑完整个流程. 业务模块只关心自己的状态和金额从哪来, 完全不需要知道渠道, 回调, 幂等这些东西:


flowchart LR
    Tx["支付模块
统一编排"]
    Target["Target
订单 ID / 账单 ID / 预约 ID"]
    Contract["PayTarget 契约
PayCheck / Pay
PaySuccess / PayFailed"]
    Order["订单"]
    Invoice["账单"]
    Booking["预约"]
    Method["支付方式
统一发起入口"]
    Direct["服务端直接发起"]
    Redirect["跳转渠道页面"]
    Code["二维码 / 付款码"]
    Offline["待付款凭证
异步到账"]
    Gateway["支付渠道"]

    Tx --> Target
    Tx -->|"检查 / 锁定 / 回写"| Contract
    Contract -.-> Order
    Contract -.-> Invoice
    Contract -.-> Booking
    Tx --> Method
    Method --> Direct
    Method --> Redirect
    Method --> Code
    Method --> Offline
    Direct --> Gateway
    Redirect --> Gateway
    Code --> Gateway
    Offline --> Gateway

接一个新的业务对象, 要写的就是那四个方法.

这其实就是依赖倒置: 把"支付调用业务"定义成接口, 而不是让每个业务自己去调支付.

小结

一笔支付就是一次尝试, 有自己的 ID 和终态; 重试是新的一笔, 不是把旧的改回去.
接入前先确认渠道支持幂等键, 交易 ID 就是这个键. 这是下面所有做法的前提.
把「历史流水」和「当前有效」分开. 后者要显式建模, 用唯一索引兜底, 用带旧值的条件更新来切换.
异步支付里, 受理不等于成功, 调用失败不等于业务失败. 拿不准的时候保持支付中, 不要急着下结论.
「支付中」是一道幂等挡板, 不是一个普通状态.
支付方式的差异收在发起那一步, 业务对象的差异收在契约里.

这几件事单看都不复杂, 但它们是有先后的: 先有渠道侧的幂等键, 才谈得上重发; 先有唯一的当前有效交易, 才谈得上幂等; 先有幂等, 才敢在超时的时候不下结论.

岩里武则与马尼拉战役

2024-06-02T00:50:39+09:00

岩里武则, 岩里政男的哥哥, 在二战期间加入旧日本帝国海军, 前往日占菲律宾, 在马尼拉战役中被美军打死, 二战后, 以岩里武则的名字被供奉在靖国神社; 据称, 改姓岩里, 因为里字保留了李这个音, 而岩则源自李家祖籍福建龙岩

发生在 1945 年初的马尼拉战役, 日军指挥官岩渊三次带领海军陆战队违反上级命令, 在人口稠密且拥有大量木制易燃建筑的马尼拉市区与美军进行巷战. 在美军的绝对优势下, 日军将愤怒发泄在菲律宾平民身上; 将近一个月的战斗中, 马尼拉城被彻底摧毁, 超过十万名菲律宾平民死亡, 其中大部分死于日军屠杀; 这个数字超过了东京大轰炸和广岛与长崎的核爆任一单次死亡

在 TCP 上划报文边界

2023-04-06T21:37:19+09:00

在 TCP 上跑一个自己的业务协议, 第一件要决定的事往往不是用什么序列化, 也不是字段怎么排, 而是一条消息到哪里结束.

这听上去不太像个问题, 但它是自定义协议里最容易写错的地方, 而且错了以后在测试环境里往往一切正常.

先把问题说清楚

常见的说法是"TCP 粘包". 这个说法其实不太准确, 因为它暗示 TCP 本来应该给你"包", 只是不小心粘上了.

TCP 从来没承诺过包. 它承诺的只有三件事: 你写进去的字节会按顺序到达, 不丢, 不重. 至于这些字节怎么切分成一次次 Read, 完全不受你控制:

发送侧, 两次 Write 可能被合并进同一个 TCP 段 (Nagle 算法就是干这个的).
一次 Write 也可能被拆成多段, 因为 MSS, 因为发送窗口, 因为路径 MTU.
中间的设备还可能再切一刀.

所以下面这段代码是错的:

buf := make([]byte, 4096)
n, err := conn.Read(buf)   // 读到的不一定是一条完整消息
handle(buf[:n])            // 可能是半条, 也可能是两条半

它在本机测试里几乎永远是对的 —— 消息短, 网络快, 一次一条. 一上生产, 报文变长, 网络变差, 就开始随机地解析失败. 而且因为是随机的, 查起来非常烦人.

边界是应用层自己的事. 划边界的办法总共就那么几种.

fixed     |<-- 64 bytes -->|<-- 64 bytes -->|<-- 64 bytes -->|

prefixed  |len=12|<-- 12 bytes -->|len=5|<-5B->|len=40|<-- 40 bytes -->|

delimited | hello\r\n | world\r\n | a-longer-line\r\n |

一, 定长报文

每条报文固定 N 字节, 读满 N 就是一条. 没有比这更简单的了:

const frameSize = 64

func readFrame(r io.Reader) ([]byte, error) {
	buf := make([]byte, frameSize)
	if _, err := io.ReadFull(r, buf); err != nil {
		return nil, err
	}
	return buf, nil
}

好处是解析成本为零, 不需要任何状态机; 缓冲区可以预分配甚至复用; 而且天然没有"对方声明了一个 2GB 的长度"这类问题 —— 长度根本不由对方决定.

代价是短消息要补白, 浪费带宽; 更要命的是改结构就是不兼容. 定长意味着字段的偏移量写死在两边的代码里, 加一个字段就得双方同时升级.

所以它适合字段本来就固定的场景: 心跳, 传感器上报, 行情快照, 工控设备. 另外, 很多老协议的包头是定长的, 那本质上也是这一类 —— 只不过定长的部分只是头, 后面还跟着变长的身体, 也就是下面这种.

二, 定长头部 + 长度字段

最常用的一种. 头部长度固定, 头部里带着后面还有多少字节, 于是读取变成明确的两步:

const (
	headerSize = 4
	maxBodyLen = 1 << 20 // 必须有上限
)

func readMessage(r io.Reader) ([]byte, error) {
	var head [headerSize]byte
	if _, err := io.ReadFull(r, head[:]); err != nil {
		return nil, err
	}
	n := binary.BigEndian.Uint32(head[:])
	if n > maxBodyLen {
		return nil, fmt.Errorf("frame too large: %d", n)
	}
	body := make([]byte, n)
	if _, err := io.ReadFull(r, body); err != nil {
		return nil, err
	}
	return body, nil
}

现实里的协议基本都是这个路子, 只是头的形状不同:

协议	头
gRPC	1 字节压缩标志 + 4 字节大端长度
TLS record	1 字节类型 + 2 字节版本 + 2 字节长度
MySQL	3 字节小端长度 + 1 字节序号
Redis bulk string	`$<len>\r\n`

有几个坑值得单独拎出来.

长度到底算什么, 必须定义清楚. 是 body 的长度, 还是包含头部的总长? 差一个头长度, 结果就是每读一条报文错位一次, 而且第一条往往还是对的. 有些协议干脆两个都给, 各有各的用处: 总长用来切帧, body 长用来在解压或者解密之后确定有效数据到哪里为止 —— 因为变换过后的长度和线上的长度不是一回事.

长度字段的编码要和字节序一起说清楚. 大端还是小端 (网络字节序习惯上是大端, 但 MySQL 就是小端), 是二进制还是 ASCII 数字, 老一点的金融协议里还会用 BCD 把长度压成半个字节.

一定要校验上限. 不校验就是一个远程内存耗尽漏洞: 对方发一个 0xFFFFFFFF, 你就 make([]byte, 4G). 这不需要什么高深的攻击手法, 一个写错的客户端就能把你打挂. 上面代码里 maxBodyLen 那三行不是可选的.

长度也可能是分段的. MySQL 的长度只有 3 字节, 所以超过 16MB 的包会被拆成多个, 最后一个包的长度小于 0xFFFFFF 才算结束. 设计协议的时候, 与其给长度字段留很宽的位数, 不如明确规定一个上限加分段规则.

考虑一下错位之后怎么办. 一旦解析错位, 后面读到的全是垃圾. 头部里放一个魔数或版本号可以帮你发现这件事. 至于发现之后怎么恢复 —— 老实说, 大多数情况下直接断开重连比"尝试重新同步"要安全得多, 因为你已经不知道自己在流的什么位置了.

三, 分隔符

用一个约定不会出现在正文里的字节序列切分, 最常见的就是 \r\n:

sc := bufio.NewScanner(conn)
sc.Buffer(make([]byte, 0, 4096), 64*1024) // 显式给出上限
for sc.Scan() {
	handle(sc.Bytes())
}
if err := sc.Err(); err != nil {
	// 注意 bufio.ErrTooLong
}

好处是人可读. 可以直接 telnet 上去敲命令, 抓包能直接看懂, 出问题的时候这一点非常值钱. 而且发送方不需要预先知道长度, 天然适合流式产生的内容.

代价主要是两条.

一是正文里出现分隔符怎么办. 只有两个选择: 禁止 (规定正文不能含 \n), 或者转义 (然后接收方要解转义). 前者限制了能传什么, 后者带来解析复杂度和长度膨胀, 而且转义规则一旦有歧义就是安全问题的温床 —— HTTP 请求走私那一类漏洞, 根子上就是收发双方对边界的理解不一致.

二是同样必须设上限. 对方发一个永远不带换行的流, 你就一直往缓冲区里塞. bufio.Scanner 默认 64KB 的上限就是干这个用的, 别把它调成无限大; Go 的 net/http 对请求行和 header 也都有长度限制, 同理.

顺便, 扫描分隔符是 O(n) 的, 数据量大的时候比读一个长度字段贵不少.

实际上, 混着用才是常态

纯分隔符协议处理二进制正文太难受, 所以文本协议基本都是混合的:

HTTP/1.1: header 用 \r\n 分行, 空行表示 header 结束; body 的长度由 Content-Length 给出. 而 chunked 编码本身又是一个混合体 —— 每个 chunk 是"十六进制长度 + \r\n + 数据 + \r\n", 长度前缀和分隔符一起上.
Redis RESP: 行结构用 \r\n, 但 bulk string 是 $5\r\nhello\r\n —— 先给长度, 再读定长数据, 后面那个 \r\n 纯粹是为了人看着舒服. 正因为有长度, 值里面含 \r\n 完全没问题.

这两个例子里的逻辑是一样的: 控制信息用分隔符, 因为要人可读; 数据本身用长度, 因为要能装任意字节.

还有一种极端做法值得一提: 一条连接只发一条消息, 用连接关闭当边界. HTTP/1.0 的默认行为就是这样, 没有 Content-Length 的响应读到 FIN 为止. 它的代价是每条消息一次三次握手, 而且你没法区分"对方发完了"和"对方挂了".

怎么选

大致是这么几条:

正文是二进制 → 长度前缀. 没什么可犹豫的.
正文是文本, 而且你希望能 telnet 上去调试 → 分隔符, 但数据部分还是给长度.
字段完全固定且很短 → 定长, 省掉一切解析.
想都不想就用 protobuf / gRPC / HTTP → 也挺好, 它们只是把上面这些选择替你做完了, 该有的上限校验也都做了.

不管选哪种, 这三件事都要做

一, 用 ReadFull, 别相信单次 Read. 这是最常见的一个 bug, 而且如上所述, 它在测试环境里不会暴露.

二, 设上限. 长度字段的上限, 单行的上限, 缓冲区的上限. 少一个就是一条拒绝服务的路径.

三, 设读超时. 一个只发了半条报文然后就不动了的连接, 如果没有 deadline, 会永远占着你的 goroutine 和缓冲区. 而且这种连接在操作系统看来完全正常, 你不主动超时就发现不了.

conn.SetReadDeadline(time.Now().Add(30 * time.Second))

这三条都是从"对端不一定是善意的, 也不一定是正确的"这个前提推出来的. 自己写协议的时候很容易默认对面跑的是自己写的客户端, 但只要那个端口暴露在网络上, 这个假设就不成立.

写一个 ISO 8583 的 SDK

2022-12-31T17:40:11+09:00

业务上要和日本某卡组织的交换中心直连, 走 ISO 8583.

最初分配给我的任务是写一个测试挡板, 让业务那边先能跑起来, 不用等到真的接上对端. 但一动手就发现顺序反了 —— 挡板要能收下我方发出去的报文, 就得会解包; 要能回一条对端格式的响应, 就得会封包; 要像对端那样建连接, 开局, 换密钥, 那这些也一个都少不了. 换句话说, 不先把这套东西做完, 连挡板都写不出来.

市面上的 Go 库也不太符合需求: 要么只做报文的封装解包, 要么假设你跑在一个标准的 request-response 模型上, 而对端的规格书里写的是全双工, 双向主动发起, 定期换密钥.

所以最后做出来的不是一个报文库, 也不只是一个挡板. 封包解包只是最底下的一层, 上面还压着连接, 会话, 密钥, 以及一整套给业务用的接口 —— 是一个 SDK. 而当初要的那个挡板, 反倒成了它的一个使用者.

趁年末还记得, 把几个设计决定记一下. 具体的接续规格是有 NDA 的, 所以下面的代码都是脱敏和简化过的, 只留设计本身.

ISO 8583 是什么

简单说, 是刷卡交易的报文标准. 你在便利店刷一张卡, 从 POS 机到收单机构到卡组织到发卡行, 这一路上跑的多半就是 ISO 8583 或者它的某个方言.

报文的结构非常有年代感:

+--------+------------------+---------------------------+
|  MTI   |      Bitmap      |          Fields           |
| 4 bytes|  8 or 16 bytes   |         变长               |
+--------+------------------+---------------------------+

MTI (Message Type Indicator), 4 位数字, 说明这条报文是什么, 比如授权请求, 冲正, 网络管理.
Bitmap, 64 个 bit, 第 N 个 bit 为 1 表示第 N 个域出现在报文里. 第 1 个 bit 比较特殊, 它为 1 表示后面还跟了第二个 bitmap, 即这条报文用到了 65~128 域.
Fields, 按域号从小到大依次排列. 每个域是定长还是变长, 是数字还是字符, 用什么编码, 都由规格书规定.

它是个 1980 年代的标准, 所以处处是省字节的痕迹: 域出现与否用 bit 表示而不是用 key, 数字用 BCD 压缩成半个字节, 变长域的长度头也用 BCD. 在今天看这些设计很别扭, 但在专线按字节计费的年代是合理的.

不过有一件事要先分清楚: ISO 8583 是公开的标准, 但它管的基本上只有报文.

它规定了 MTI, bitmap, 每个域号大致对应什么含义, 以及各类域的类型和长度表示法. 至于连接怎么建, 会话怎么开怎么关, 心跳多久发一次, 密钥怎么下发怎么轮换, 出了错回什么码, 日切怎么对账 —— 一概不管. 这些全部由使用这张网的双方自己约定.

而且就算只看报文这一层, 各方也都有自己的变体. 同一个域号, 这张网拿来放这个, 那张网拿来放那个; 有的域整张网都不用; 长度头的编码, 字符集, 定长域往哪边补位, 也各家不同.

所以"支持 ISO 8583"这句话本身几乎不提供什么信息, 真正要问的是"支持哪一张网的 ISO 8583". 而这个问题的答案, 只写在接续规格书里.

最大的困难是文档

必须先说这个, 因为整个项目里最难的部分从来不是代码.

规格书是几百页的日文 PDF, 还远不止一份. 印象里前后拿到的有十来册: 基本篇和电文篇算主干, 然后每多一个功能就多一册 —— IC 卡是单独一册, 非接触的タッチ又是一册, PIN 相关的再一册, 加上各种别册和历年的改订通知. 摞起来轻松上千页.

更麻烦的是它们的年龄. 这套东西是上世纪就在跑的, 文档也是那时候留下来一路改过来的, 于是你会读到这样的内容:

排版是等宽字体画的表格, 有些页干脆是扫描件, 复制不出文字, 只能对着屏幕一个字一个字敲.
术语是昭和的. 電文, 仕向, 宛先, 加盟店, 開局, 閉局, 締め, カットオーバー —— 每一个都要先搞清楚它在这个语境下具体指什么, 而不是字面意思.
片假名外来语和汉字词混着用. レコード, フィールド, ヘッダ是一套, 電文長, 可変長是另一套, 指的却是同一层东西.
甚至还有 X.25 的描述. 分组交换网, 上世纪七十年代的东西. 早就跑在 TCP/IP 上了, 那一段却还留着. 读的时候要一边分辨哪些已经不适用, 一边小心那些看着过时, 实际上对端还在严格执行的部分.

但真正累人的不是这些, 而是这些文档之间没有链接.

倒不是说它们写得有矛盾 —— 恰恰相反, 内容相当严谨, 该规定的都规定了. 问题是同一件事的信息被按功能切开, 摊在好几册里.

举个实际的例子: 要搞清楚一笔带 PIN 的 IC 卡交易怎么发, 域的位置和长度在电文篇, PIN block 怎么算, 用哪把密钥加密在 PIN 那一册, IC 卡数据域里那串 TLV 的构成在 IC 卡那一册, 而这三册对同一条报文各自只讲自己负责的那一部分. 谁也没错, 但没有一册能单独回答"这条报文到底长什么样".

你就是那个超链接. 没有交叉引用, 没有索引, 扫描的那几页连全文检索都做不了, 全靠自己记住哪一条写在哪一册的第几页. 所以前期有相当一部分时间, 其实是在给自己建索引: 术语的对照, 每个域的出处, 各册之间的对应关系. 这件事没有任何技术含量, 但跳过它的代价是后面每查一次都要重新翻一遍.

实在读不出来的地方也有, 只能记下来攒着, 攒够一批再去问对端 —— 问一轮的周期以周计, 所以清单要攒得够厚才划算.

所以真正的工作量分布大概是: 读文档, 整理术语, 建索引占了一大半, 写代码反而是最快的部分. 这也直接决定了后面几乎所有的设计.

因为读文档这件事最大的风险不是读慢了, 而是读错了却不知道. 一个人对着上千页 PDF 读出来的理解, 如果只留在他脑子里, 或者只写成一页 wiki, 那它既不会被 review, 也不会被验证, 出了问题还查不到源头. 所以从一开始就定了一个原则:

凡是规格书里写的约束, 都要变成代码里能跑的东西.

域的长度, 编码方式, 是定长还是变长, 在哪种电文里必须出现, 取值范围有哪些 —— 全部写进结构体和校验器, 而不是写进注释或者文档. 这样"我对规格书的理解"就成了一个可以被 review, 被测试, 被后来人修正的东西.

而一旦这么想, 事情就变得很顺: 既然报文无非是"哪些域出现了, 每个域怎么编码", 那它完全可以用 Go 的结构体和 tag 描述出来.

用 struct tag 描述报文

底层的封包解包部分, 我们没有从零写, 而是基于 ideazxy/iso8583 的思路做的扩展. 它的核心抽象是一个接口:

// Iso8583Type interface for ISO 8583 fields
type Iso8583Type interface {
	// Bytes 把当前域编码成字节
	Bytes(encoder, lenEncoder, length int) ([]byte, error)

	// Load 从字节流解出当前域, 返回实际消费的字节数
	Load(raw []byte, encoder, lenEncoder, length int) (int, error)

	// IsEmpty 判断域是否为空
	IsEmpty() bool
}

然后 Numeric, Alphanumeric, Binary, Llvar, Lllvar, Llnumeric, Lllnumeric 各自实现它. Ll 和 Lll 前缀是 ISO 8583 的黑话, 指长度头是 2 位还是 3 位十进制数的变长域.

于是一条报文就是一个结构体:

type Body struct {
	F2  *iso8583.Llvar        `field:"2"  length:"19" encode:"jis8"` // 会员号
	F3  *iso8583.Numeric      `field:"3"  length:"6"  encode:"jis8"` // 处理码
	F4  *iso8583.Numeric      `field:"4"  length:"12" encode:"jis8"` // 交易金额
	F11 *iso8583.Numeric      `field:"11" length:"6"  encode:"jis8"` // 系统跟踪号
	F12 *iso8583.Numeric      `field:"12" length:"12" encode:"jis8"` // 交易时间
	F37 *iso8583.Alphanumeric `field:"37" length:"12" encode:"jis8"` // 检索参考号
	F52 *iso8583.Binary       `field:"52" length:"8"`                // PIN block
	F55 *iso8583.LllBinary    `field:"55" length:"255"`              // IC 卡数据
}

Bytes() 的时候, 用反射遍历这个结构体, 从 tag 里读出域号, 长度和编码, 域号决定它在 bitmap 里点哪个 bit, 编码决定它怎么变成字节:

func parseFields(msg interface{}) map[int]*fieldInfo {
	fields := make(map[int]*fieldInfo)

	v := reflect.Indirect(reflect.ValueOf(msg))
	for i := 0; i < v.NumField(); i++ {
		// 指针为 nil 的域, 直接跳过, 不进 bitmap
		if isPtrOrInterface(v.Field(i).Kind()) && v.Field(i).IsNil() {
			continue
		}
		sf := v.Type().Field(i)
		index, _ := strconv.Atoi(sf.Tag.Get(TAG_FIELD))
		// ... 解析 encode / length tag
		field, ok := v.Field(i).Interface().(Iso8583Type)
		if !ok {
			panic("field must be Iso8583Type")
		}
		fields[index] = &fieldInfo{index, encode, lenEncode, length, field}
	}
	return fields
}

这里有两个我觉得挺舒服的地方.

第一, 所有域都用指针. Go 没有 optional, 而 ISO 8583 里"域不存在"和"域是空字符串"是两件不同的事 (前者 bitmap 上是 0, 后者是 1 加一个长度为 0 的变长域). 用指针 nil 表达"不存在", 用 IsEmpty() 表达"存在但为空", 语义就对上了. 调用方只需要 models.WithF39("000") 这样填自己关心的域, 剩下的自然不出现在报文里.

第二, bitmap 不需要人来维护. 老一点的实现里, 常常是业务代码自己去 set bit, 然后再 append 数据, 一旦漏了一处就是一条对端解不开的报文. 交给反射之后, 结构体里填了什么, 报文里就有什么.

解包的方向对称: 注册 MTI 与模板结构体的映射, 收到报文先读 MTI, 找到对应的 reflect.Type, reflect.New 一个出来, 再按 bitmap 逐位 Load:

func (p *Parser) Register(mti string, tpl interface{}) (err error) {
	v := reflect.ValueOf(tpl)
	p.messages[mti] = reflect.Indirect(v).Type()
	return nil
}

有一个必须处理的细节: reflect.New 出来的结构体, 里面所有指针域都是 nil, 而 Load 需要往里写. 所以要先把指针域挨个 reflect.New 初始化一遍, 解完之后再把没被 bitmap 点到的域还原成 nil —— 否则 "这条报文里有没有 F39" 这个判断就失效了.

反射代码的另一个代价是, 大量的错误没法在编译期发现, tag 写错, 类型写错, 都要到运行时才 panic. 这个库的做法是在每个对外的入口上挂一个 recover, 把 panic 翻译成 error:

func (m *Message) Bytes() (ret []byte, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = errors.New("Critical error:" + fmt.Sprint(r))
			ret = nil
		}
	}()
	// ...
}

这是个务实但不优雅的选择. 一条畸形报文不该把整个网关搞挂, 但用 recover 兜底也意味着错误信息很难看. 更好的做法应该是在注册模板的时候就把结构体校验一遍, 把错误提前到启动期.

两种编码: BCD 和 JIS8

BCD

BCD 是用 4 个 bit 表示 1 位十进制数, 于是 1 个字节能放 2 位数字, "1234" 编码后就是 \x12\x34. 对于金额, 日期, 长度头这些纯数字字段, 直接省一半.

麻烦在奇数长度. "119" 有 3 位, 占 1.5 字节, 那多出来的半个字节补在哪一边? 规格书里两种都有, 所以要两个函数:

// 左对齐: "119" -> "1190" -> \x11\x90
func lbcd(data []byte) []byte {
	if len(data)%2 != 0 {
		return bcd(append(data, "0"...))
	}
	return bcd(data)
}

// 右对齐: "119" -> "0119" -> \x01\x19
func rbcd(data []byte) []byte {
	if len(data)%2 != 0 {
		return bcd(append([]byte("0"), data...))
	}
	return bcd(data)
}

解码时同样要知道原始的十进制长度才能把补的那个 0 切掉, 所以 Load 的签名里一直带着 length. 这也是为什么 tag 里的 length 对于 BCD 域指的是十进制位数而不是字节数 —— 一个很容易踩的坑, 尤其是 Binary 类型的 length 指的又是字节数.

JIS8

这是这个项目里最日本的部分.

Go 的 string 是 UTF-8, 而线路上跑的是 Shift-JIS. 具体一点, 报文里的日文用的是 JIS X 0201 的半角片假名 (单字节, 0xA1~0xDF 区间) 加 JIS X 0208 的双字节汉字假名. ｱｲｳｴｵ 这种半角片假名今天只在 ATM 和收据上还能见到, 但在这类报文里是主力.

转换本身不难, golang.org/x/text/encoding/japanese 直接给:

func ToShiftJIS(str string) (res []byte, err error) {
	transformed, err := io.ReadAll(
		transform.NewReader(strings.NewReader(str), japanese.ShiftJIS.NewEncoder()),
	)
	// ...
}

难的是, 转换应该发生在什么时候.

一开始我们把域直接存成 []byte, 让调用方自己转. 结果是业务代码里到处是 ToShiftJIS, 而且一旦漏了一处, 报文能发出去, 对端也能收下, 只是商户名变成乱码 —— 这种 bug 联调的时候非常难查.

后来改成变长域同时持有两种表示:

type Llvar struct {
	ByteValue []byte
	Value     string // UTF-8 字符串, 如果填了此值, 会以此值为准做转换
	Valid     bool
}

业务代码只碰 Value, 编码的事情推迟到 Bytes() 里, 按 tag 上的 encode 决定是原样输出还是转 Shift-JIS; 解包时反过来, Load 之后 Value 里拿到的一定是可以直接打日志, 直接进数据库的 UTF-8. 编码从此只在库的边界上发生一次.

顺带一个必须记住的点: 变长域的长度头算的是编码后的字节数, 不是字符数. "東京" 在 UTF-8 里是 6 字节, 在 Shift-JIS 里是 4 字节, 长度头要写 4. 同理, 定长域补空格补到的也是字节数. 所以 len(l.ByteValue) 这个写法必须在转换之后, 顺序反了就是一条长度对不上的废报文.

测试数据也是个问题. 为了压变长域的边界, 需要随机生成合法的 Shift-JIS 字符串, 于是写了个工具, 把 ASCII 的符号区间和 0xA1~0xDF 的半角片假名区间拼起来, 解码成 rune 再随机取:

for i := uint8('\x21'); i <= uint8('\x2f'); i++ {
	b = append(b, i)
}
// ... 其他 ASCII 符号区间
for i := uint8('\xa1'); i <= uint8('\xdf'); i++ {
	b = append(b, i)
}

代码里还留着一行 // TODO handle \xa0, it's very strange —— 0xA0 在 Shift-JIS 里是未定义的, 但某些实现会把它当空格处理. 规格书里对这个位置也语焉不详, 这个 TODO 估计会留很久.

TCP 连接

封包解包做完, 剩下的一半工作量在连接上. 这部分基本是照着 go-redis 抄的, 然后被业务改得面目全非.

抄的部分是 Conn 这层封装: 拿一个 *net.TCPConn, 套上 bufio.Reader / bufio.Writer, 配上读写超时和 keepalive.

func Connect(address string) (conn *net.TCPConn, err error) {
	raddr, err := net.ResolveTCPAddr("tcp", address)
	// ...
	conn, err = net.DialTCP("tcp", nil, raddr)
	// ...
	err = conn.SetKeepAlivePeriod(15 * time.Second)
	err = conn.SetKeepAlive(true)
	return
}

TCP 是字节流, 没有报文边界, 所以读的时候必须自己划. 好在这类协议都有定长包头, 包头里有全长:

// 先读定长包头
headerBytes := make([]byte, models.HeaderByteLength)
_, err = io.ReadFull(conn.br, headerBytes)
// 从包头里取出全长, 再读剩下的
totalLength, err := message.GetTotalLengthFromHeader()
bodyBytes := make([]byte, totalLength-models.HeaderByteLength)
_, err = io.ReadFull(conn.br, bodyBytes)

io.ReadFull 在这里是关键. 直接 Read 是不保证读满的, 大报文分片到达的时候, 半包就是这么来的.

改得面目全非的部分, 是这个协议是全双工的.

Redis 的连接模型是: 从池里取一条连接, 写请求, 阻塞读响应, 还回池里. 一条连接同一时刻只服务一个请求, 请求和响应严格配对.

而卡网这边不是. 对端会主动推送过来通知类电文, 也会在你发出去的请求还没回来的时候先发别的东西过来. 更麻烦的是, 双方是对等的: 我方既要主动连过去, 也要监听端口等对方连过来, 两个方向上都能收发业务电文.

所以连接建立之后, 立刻起一个 goroutine 一直读, 读到的电文全部投进一个 channel:

func (c *Conn) ReadChan(ch chan<- *models.Message) {
	go func() {
		for {
			message, err := connReadMessage(c)
			if err != nil {
				logz.Warnf("read error, %v", err)
				c.Close()
				return
			}
			ch <- message
		}
	}()
}

上层拿到的就是一个"所有连接上收到的所有电文"的流, 主动连出去的和被动接进来的连接共用同一个出口:

func (c *Center) ReceiveMessagesInChannel(ch chan<- *models.Message) {
	serverReceiveChan := c.server.ReceiveChannel()
	clientReceiveChan := c.client.ReceiveChannel()
	go func() {
		for {
			select {
			case message = <-serverReceiveChan:
				go loadMessage(ch, message, c.state)
			case message = <-clientReceiveChan:
				go loadMessage(ch, message, c.state)
			}
		}
	}()
}

请求和响应的配对, 就交给上层用报文里的流水号去做了 —— 系统跟踪号加交易时间加机构号组成的那个唯一标识. 这件事本来就该在业务层做, 因为超时重发, 冲正, 对账都要用到同一个标识.

一点也不云原生

在讲连接池之前, 得先说清楚这张网长什么样, 否则池子的形状会显得莫名其妙.

没有域名, 没有服务发现, 没有负载均衡器. 双方交换的是一份 IP 地址清单, 写死在配置里:

type Config struct {
	Addresses []string `json:"addresses"`
	SourceID  string   `json:"source_id"`
}

我方有 m 个节点, 对方给 n 个地址, 于是 m × n 条连接, 每一条各自建立, 各自保活, 各自重连. 反方向还有一张: 对方也会主动连过来. 这些连接不是一堆等价的, 可替换的池化资源, 而是一条条有名有姓的线路 —— 断的是哪一条, 就得把哪一条接回来.

所以这套东西和现在习以为常的那一套基本是反着来的:

不能随便扩容. 实例数是和对方约定好的. 加一台机器意味着双方都要改白名单, 走申请流程, 周期以周计. 弹性伸缩在这里不是一个选项.
IP 必须是固定的. 这基本堵死了直接扔进 k8s 让 Pod 飘来飘去的可能, 要么钉在固定节点上, 要么想办法保证出口 IP 稳定.
发布是有代价的. 重启一个实例意味着 n 条连接断开重连, 重连完还要重新开局. 滚动发布要控制节奏, 不能一次全部重启.
健康检查没法交给别人. 没有 LB 帮你把故障节点摘掉, 每条连接是死是活, 只有进程自己知道.

好处是链路上没有中间环节, 出了问题排查路径很短. 代价是建立, 保活, 重连, 选路, 摘除这些活全部落在库里, 没有任何基础设施能替你分担 —— 下面这个连接池, 本质上就是为了把这堆事收在一个地方.

连接池

既然读已经不需要占用连接了, 那连接池到底还池什么?

答案是: 只服务于发送. 池的职责从"借出-独占-归还"退化成了"在一组可用连接里挑一条来写", 也就是选路和负载均衡.

底层的双向链表直接抄了 redigo, 代码里老老实实留着出处:

// idleList is a double linked list to maintain connections in connPool
// copy from github.com/gomodule/redigo
type idleList struct {
	count       int
	front, back *poolConn
}

取连接的时候从链表尾部弹出, 用完从头部塞回去, 天然就是一个轮询:

func (p *ConnPool) GetConnAndPutBack() (conn *Conn, err error) {
	p.mu.Lock()
	defer p.mu.Unlock()
	conn, err = p.getConn()
	if err != nil {
		return
	}
	if !conn.closed {
		// 将取到的连接还回到链表的头
		p.putConn(conn)
	}
	return
}

发送的入口带 context 超时, 拿不到可用连接就等, 等到 deadline 再报错. 已经关闭的连接直接丢弃, 不再放回:

func (p *ConnPool) GetActiveConnWithCtx(ctx context.Context) (conn *Conn, err error) {
	for {
		select {
		case <-ctx.Done(): // 已经超时, 直接返回
			return nil, ctx.Err()
		default:
			p.mu.Lock()
			conn, err = p.getConn()
			p.mu.Unlock()
			if err != nil {
				if err == ErrIdleConnNotFound { // 没有空闲连接, 等一下再取
					time.Sleep(time.Millisecond)
					continue
				}
				return
			}
			if conn.closed {
				continue // 关闭的连接无需加回连接池
			}
			return // 返回的 conn 一定是未关闭且可用的
		}
	}
}

重连

专线也会断, 对端也会重启, 而这类系统的要求是断了要自己接回来, 不能等人来重启进程.

做法是在连接入池的时候, 给它挂一个"守灵"的 goroutine: 阻塞在这条连接的 closeChan 上, 一旦连接关闭, 先把活跃计数减掉, 然后按原来那个远端地址重新拨号, 拨通了再入池. 注意是原来那个, 而不是从地址清单里重新挑一个 —— 上面说过, m × n 里的每一条都是有名有姓的, 少了哪条就得补哪条.

func (p *ConnPool) AddConn(conn *Conn) (err error) {
	p.mu.Lock()
	defer p.mu.Unlock()
	p.putConn(conn)
	p.increaseActive()
	go func(conn *Conn) {
		<-conn.closeChan
		p.mu.Lock()
		p.decreaseActive()
		p.mu.Unlock()
		if !conn.reconnect {
			return // 被动接入的连接不负责重连
		}
		if conn.parentCloseChan == nil {
			return
		}
		// ... 按 remote addr 重连, 失败退避后重试
	}(conn)
	return
}

这里有两个 flag 值得说一下.

reconnect 区分这条连接是我方拨出去的还是对方连进来的. 只有前者该重连 —— 对方连进来的连接断了, 该由对方来重连, 我方去连对方的监听端口是完全不同的一件事.

parentCloseChan 区分"网络断了"和"应用要关了". 没有这个东西的话, 优雅关停会变成: 你关掉所有连接, 然后每条连接的守灵 goroutine 立刻开始重连, 关不掉. 这个 channel 由上层持有, 关停时先关它, 重连逻辑一看它已经关闭就直接退出.

func IsClosed(ch <-chan interface{}) bool {
	select {
	case <-ch:
		return true
	default:
	}
	return false
}

这个模式在 Go 里很常用: 用一个只关不写的 channel 做广播式的取消信号. 现在写的话应该直接用 context.Context, 当时是图省事.

连接不等于会话

规格书里, 两个中心之间要先发一条开局电文, 收到开局响应之后才允许发业务电文, 收工的时候再发一条闭局.

应用层再握一次手这件事本身一点也不稀奇. Redis 的 AUTH, SELECT, HELLO 就是, MySQL, AMQP, SMTP 也都有自己的一套. TCP 只负责把字节按序送到, 至于"你是谁, 我认不认你, 接下来按什么规矩来", 永远得在应用层谈.

真正值得说的是粒度.

Redis 那套是连接级的: AUTH 认的是这条连接, SELECT 选的是这条连接的 db, 状态和 socket 同生共死. 连接断了, 状态跟着没; go-redis 重连之后在 initConn 里把 HELLO / AUTH / SELECT 重跑一遍, 上层完全无感. 会话和连接是 1:1 的, 所以"会话"这个词在那边根本不需要单独存在.

开局不是. 它是两个中心之间的状态, 一次开局覆盖 m × n 所有连接:

单条连接断了重连, 不需要重新开局.
反过来, 所有连接都好好的, 但会话被闭局了, 一样不能发业务电文.

所以在线状态是存在 CommonState 里的, 不是存在 Conn 上:

const (
	OnlineStatusClosed OnlineStatus = iota
	OnlineStatusOpening
	OnlineStatusOpened
	OnlineStatusClosing
)

发业务电文之前该问的是"会话开着吗", 而不是"连接还在吗". 这两个判断在代码里是分开的, 池子非空只是必要条件.

粒度不同, 后面几件事也就跟着不同了.

会话要自己判断活性. TCP 断了你不一定知道 —— 对端主机掉电, 中间的防火墙静默丢掉连接状态, 专线切换, 这些情况下本地的 socket 可能很长时间还停在 ESTABLISHED, 你往里写也不报错. keepalive 探的是链路, 对端进程 hang 死了内核照样回 ACK. 这个问题 Redis 那边由池子处理掉了: 拿到一条坏连接, 丢掉重建, 大不了重试一次, 反正会话跟着连接一起重来. 但在这里连接可以重建, 会话不行, 所以必须有应用层的心跳 (echo test) —— 它超时说明的是"对面那套系统不转了", 而不只是"这条线断了".

它是对等的. AUTH 是客户端单方面向服务端证明自己, 服务端不需要反过来 AUTH. 而开局是两个对等中心之间的协商, 哪边都能发起, 哪边都要维护对方的状态. 后面那个假中心之所以要把开局的两个方向都实现一遍, 就是因为这个.

闭局是要谈的. TCP 的 FIN 只能表达"我不发了", 表达不了"我准备收工, 麻烦把在途的交易处理完再断", 更不给对方拒绝或者拖一会儿的机会. 而这类系统有营业日, 有日切, 有对账 —— 停机是一件有业务含义的事, 只能在应用层用电文来谈.

最后一个佐证是超时的量级:

var (
	openResponseTimeout     = time.Duration(45 * time.Second)
	closeResponseTimeout    = time.Duration(75 * time.Second)
	echoTestResponseTimeout = time.Duration(90 * time.Second)
)

几十秒到一分半, 远大于任何一个 TCP 层面的超时. 这也说明了它们量的到底是什么: 不是网络通不通, 而是对面那套系统还转不转得动.

密钥的接口注入

最后一块, 也是我自己最满意的一块.

这类协议的安全部分大致是这样: 业务电文的 body 要加密, 同时要算一个电文认证值挂在包头上防篡改. 用的是 3DES, 链式地把 body 一段段加密, 认证值取最后一段密文的前几个字节 —— 也就是一个 CBC-MAC 的构造:

func CalcAuthenticationCode(data, key []byte) (authCode []byte, err error) {
	// 不足 8 的整数倍, 末尾补 0
	// ...
	input := []byte("\x00\x00\x00\x00\x00\x00\x00\x00")
	for i := 0; i < len(data)/8; i++ {
		current := data[i*8 : (i+1)*8]
		temp, err := Xor(input, current)
		input, err = TripleDesEncrypt(temp, key)
	}
	authCode = input[0:4]
	return
}

问题不在算法, 在密钥从哪来.

加密和认证用的是两把不同的工作密钥, 它们会定期轮换: 通过一条专门的密钥交换电文下发, 下发时被主密钥加密, 收到之后解出来才是真正能用的值. 与此同时, 包头里有一个 check digit 字段标识"这条电文用的是哪一把密钥" —— 因为轮换的那一瞬间, 线上会同时存在用新旧两把密钥加密的电文, 你必须能按 check digit 反查出对应的密钥来解.

这就带来一个问题: 密钥的存储和轮换, 完全是业务的事情. 单进程的时候放内存就行, 多进程要放 Redis 或者数据库, 讲究一点的要放 HSM. SDK 不该管这些, 但它又必须在打包和解包的那一刻拿到密钥.

于是把它做成了接口, 由使用方注入:

type SecretHandler interface {
	RetrieveSecret() (secret *models.Secret, err error)
	RetrieveSecretWithCheckDigit(checkDigit []byte) (secret *models.Secret, err error)
	RetrieveSpecificSecret(secret *models.Secret) (err error)
}

type CommonStateHandler interface {
	SecretHandler
	RetrieveOnlineStatus() (status OnlineStatus, err error)
}

库里只留调用点. 发送的时候, 网络管理类电文不需要密钥, 业务电文才去取:

func (b *base) SendMessage(message *models.Message) (err error) {
	withoutSecret, err := models.IsMsgTypeCodeNetworkControl(message.MessageType)
	if !withoutSecret {
		message.Secret, err = b.state.RetrieveSecret()
		if err != nil {
			return
		}
	}
	raw, err := message.Bytes()
	// ...
}

接收的时候, 先解包头, 从 check digit 反查密钥, 再拿这把密钥去解 body 和验认证值:

func loadMessageBody(message *models.Message, sh SecretHandler) (err error) {
	// 从包头的 check digit 里拆出各把密钥的标识
	// ...
	err = sh.RetrieveSpecificSecret(secret)
	if err != nil {
		message.Error = err
		return
	}
	message.Secret = secret
	err = message.LoadBody(message.BodyBytes)
	return
}

包里附带一个基于内存的默认实现, 用两个 map 存 check digit 到密钥的映射, 加读写锁, 密钥更新走一个 channel 串行化. 够小规模场景直接用, 也是给使用方看的参考实现. 但它只是一个实现, 不是唯一的实现.

这个设计带来的好处比预想的多:

测试可以脱离密钥. 注入一个固定密钥的 mock, 单元测试就不需要真的走密钥交换流程. 甚至可以注入一对 MockEncryptBody / MockDecryptBody, 让加密变成恒等函数, 联调时抓包能直接看到明文, 排查报文结构问题的效率完全不一样.
密钥的生命周期归业务. 什么时候换密钥, 换失败了怎么退, 旧密钥留多久, 这些是业务策略, 写死在库里就没法改了.
库里不出现任何密钥. 这个包从头到尾没有 "把密钥存哪" 这个概念, 自然也就不会有人往里面提交一个真的密钥. 这一点在合规审计的时候也少了很多麻烦.

反过来看, 接口开得有点多了. RetrieveSecretWithCheckDigit 和 RetrieveSpecificSecret 语义高度重合, 一个返回新对象一个原地填充, 是不同时期加的, 后来也没合并. 接口这东西, 一旦有人实现了就不好改了 —— 这大概是最直观的教训.

SDK 化

上面这些东西 —— bitmap 怎么点位, 金额怎么压成 BCD, 商户名怎么转 Shift-JIS, 长度头算的是字节还是字符, 电文认证值用哪把密钥, 连接断了谁负责重连 —— 全都是规格书的细节, 不是业务的细节.

写这个 SDK 的时候我给自己定的目标是: 业务代码里不应该出现任何一个字节.

一笔授权交易, 在业务侧看起来应该长这样:

req := client.ConstructMessage(
	models.MsgTypeCodeAuthorizationRequest,
	[]models.HeaderOption{
		models.WithSourceID(sourceID),
		models.WithDestinationID(destID),
	},
	[]models.BodyOption{
		models.WithF2(pan),
		models.WithF4(amount),
		models.WithFunctionCode(models.FunctionCodeAuthorization),
		models.WithF37(rrn),
		models.WithF43(merchantName), // 日文商户名, 直接传 UTF-8
	},
)
err = c.SendMessage(req)

到此为止. 至于这条报文的 bitmap 上点了哪几位, F4 被压成了 6 个字节, F43 被转成了 Shift-JIS, 包头上挂了一个用当前 KMAC 算出来的认证值, body 用当前 KC 加密过, 最后从连接池里挑了一条连接写出去 —— 业务不需要知道其中任何一件.

为了做到这一点, 包里的分层是这样的:

      业务代码                        jcn/ligui (假中心 + 命令行)
          |                                    |
          +------------------+-----------------+
                             |
      ConstructMessage / SendMessage / ReceiveMessagesInChannel
                             |
+----------------------------------------------------------------+
| jcn/client          电文构造, 网络管理流程                     |
+----------------------------------------------------------------+
| jcn/center, pool    会话状态, 连接, 重连, 选路, 收发出入口     |
+----------------------------------------------------------------+
| jcn/models          这张网的报文定义, 密钥, 字段校验           |
+----------------------------------------------------------------+
| iso8583, cipher     通用封包解包, BCD / JIS8, 3DES             |
+----------------------------------------------------------------+

注意 jcn/ligui 的位置: 它在框外, 和业务代码平级. 它不是 SDK 的一层, 而是 SDK 的另一个使用者 —— 一个恰好扮演对端角色的应用. 依赖方向也是单向的: ligui 引用 client 和 center, 而 client, center, models 都不知道 ligui 的存在, 只有最上面的可执行程序才把它们拼在一起. 后面讲假中心的时候会回到这一点.

框里每一层只向上暴露上层真正需要的概念. 具体到几个决定:

用 functional option 填域, 而不是暴露结构体. body 上一共开了四十多个 WithFxx, 每个域一个. 这样业务代码是"我要填这几个域", 而不是"我要构造一个有这几个字段的结构体, 剩下的记得留 nil". 前者漏填一个域是编译能过但对端会拒的报文, 后者漏填一个域连自己都看不出来. 顺带, 这些 option 里可以做默认值和格式化, 比如交易时间直接 models.TimeNumString(time.Now(), models.TimeFormatYYMMDDhhmmss), 业务不用记这个网络用的是 12 位还是 14 位时间.

网络管理流程打包成一个调用. 开局, 闭局, echo test, cutover, 密钥交换, 这些流程每个都是一来一回外加状态变更, 但业务侧只应该看到 client.ConstructOpenRequest(...) 和 c.WaitForOnlineStatusOpened(30 * time.Second). 会话状态本身由库维护, 业务只关心"现在能不能发业务电文".

日志要能直接看. 加了一个反射实现的 PrettyPrint, 按域号顺序把非空的域打成 JSON, 二进制域转 hex, 原始字节不打:

func (m *Message) JsonRawMessage() json.RawMessage {
	jsonRawMessage, _ := json.Marshal((*PrettyMessage)(m))
	return json.RawMessage(jsonRawMessage)
}

这件事看着不起眼, 但一个 SDK 好不好用, 很大程度上取决于出问题的时候能不能一眼看出是哪条报文的哪个域不对. 如果日志里只有一串十六进制, 那前面所有的抽象就没有意义了 —— 用的人还是得学会手动数字节.

反过来说, SDK 化最难的地方也在这: 你要在"藏起细节"和"出事的时候能查"之间找平衡. 藏得太浅, 业务代码里到处是规格书; 藏得太深, 出了问题只能来问你. 我的做法是默认路径极简, 逃生舱口全开 —— Message 上原始的 HeaderBytes 和 BodyBytes 一直留着, 密钥, 状态, 连接池的统计也都能拿到, 只是正常写业务的时候用不上.

李逵与李鬼

包里有一个目录叫 ligui. 名字来自水浒里那个在树林里劫道, 自称"黑旋风李逵"的李鬼.

这就是开头说的那个挡板 —— 绕了一大圈, 最先要的东西反而是最后才做出来的.

理由倒是一直没变: 对端是别人的系统, 联调窗口按小时算, 要提前几周申请, 一次窗口跑不完就得等下一轮. 在这种节奏下, 唯一的办法是自己造一个假的中心, 平时先和它对接, 跑通了再去接真的.

ligui 就是这个假中心. 它做两件事:

一是 stub, 扮演对端回应. 收到什么请求就按规格书构造什么响应, 请求里该原样带回的域原样带回, 该由中心填的域 (承认号, 处理结果, 中心侧的交易通番) 由它来填:

func constructAuthorizationResponse(req *models.Message, ...) (resp *models.Message) {
	resp = client.ConstructMessage(
		models.MsgTypeCodeAuthorizationResponse,
		[]models.HeaderOption{
			// 源和目的对调
			models.WithDestinationID(req.Header.SourceID.Value),
			models.WithSourceID(req.Header.DestID.Value),
		},
		[]models.BodyOption{
			models.WithF2(req.Body.F2.Value),
			models.WithF4(req.Body.F4.Value),
			models.WithF11(req.Body.F11.Value),
			// ...
			models.WithF38(""),        // to be filled by options
			models.WithActionCode(""), // to be filled by options
		},
	)
	resp.Update(headerOpts, bodyOpts)
	return
}

留空的那几个域, 由测试用例通过 option 覆盖. 于是同一个构造函数, 既能造一条"承认"的响应, 也能造一条"卡片无效"或者"限额超过"的响应. 异常路径的测试比正常路径重要得多, 因为正常路径联调时一定会过, 而异常路径可能上线半年才遇到第一次.

二是 mock, 扮演对端的完整行为. 这部分是一个状态机: 开局请求来了要回开局响应并且把在线状态推进到 opened, echo test 来了要回, cutover 来了要回, 密钥交换来了要用 KEK 解出新的工作密钥, 存进去, 再回一条响应. 业务电文来了就走 stub 那套构造响应. 遇到完全不认识的电文, 回一条通用错误通知, 并且把对方的包头原样贴在错误信息域里 —— 这是规格书要求的行为, 而这条路径如果没有 mock, 你几乎没有机会测到.

default:
	logz.Debugf("unknown message received, message function: %v", message.MessageFunction())
	err = c.SendMessage(ConstructGeneralErrorMessageResponse(message, nil, []models.BodyOption{
		models.WithActionCode(models.ActionCodeErrorFormatInvalid),
		models.WithF72Byte(message.HeaderBytes),
	}), options...)

让双方跑同一个库, 还有一个更重要的理由: 假中心同时就是一个一致性检查器. 我方发出去的报文, 假中心要能解开; 假中心发回来的报文, 我方要能解开. 任何一边对规格书的理解有偏差, 在自己和自己对接的时候就会暴露成一个解不开的报文, 而不是等到联调窗口里对方告诉你"你们的电文我们收不了".

在这个基础上又加了一层校验, 按电文种别和功能码, 声明这条报文应该出现哪些域:

case models.MessageFunction(models.MessageTypeCodeNetworkControlResponse, models.FunctionCodeCutover):
	return CheckFiledByExpectedFileds(message, ExpectedFileds{[]int{11, 12, 24, 28, 39, ...}})

多一个域少一个域都算错. 加上每个域自己的规则校验 (卡号是 10 到 19 位数字, 处理码是 6 位且必须是规格书列出的组合之一), 等于把规格书里那张巨大的表格翻译成了可执行的断言. 这些断言在假中心里跑, 也在单元测试里跑.

在自己的笔记本上跑通全流程

李鬼是个库, 要用起来还得有个东西驱动它. 于是配了一个命令行, 一个最朴素的 REPL:

func CommandLineRequest(c *center.Center, state *center.CommonState) (err error) {
	reader := bufio.NewReader(os.Stdin)
	for {
		fmt.Println("Ready for input......")
		input, err := reader.ReadString('\n')
		inputs := strings.Split(strings.TrimSuffix(input, "\n"), " ")
		err = DoRequest(c, state, inputs[0], inputs[1:]...)
		// ...
	}
}

命令基本覆盖了这张网上会发生的所有事:

open                开局
echotest            心跳
key_exchange KC     换一把密钥 (KC / KMAC / KPE)
authori             一笔授权
authori_arqc        一笔带 IC 卡数据的授权
sales               一笔销售
revarsal_advice     一笔冲正
cutover <日期>       日切
audit               在线审查
stats               看看现在有几条连接

关键在于两边跑的是同一个东西. 最后落成两个 main, 一个 center 一个 mockcenter, 各自都只是几十行胶水: 读配置, 装好初始密钥, 起一个 Center, 然后一个把 stdin 接到 ligui 的 sender 上, 另一个用 ligui 的 receiver 自动应答. 地址填 127.0.0.1, 互相一连, 整条链路就在一台笔记本上跑起来了 —— 不需要专线, 不需要 VPN, 不需要对方的系统:

open → key_exchange → authori → revarsal_advice → cutover → close

这一趟走下来, TCP 连接的建立与保活, 会话状态机的推进, bitmap 的组装与解析, BCD 和 Shift-JIS 的编解码, 3DES 加密, 电文认证值的计算与校验, 密钥按 check digit 的反查, 全都真实地执行了一遍. 它不是单元测试里那种"喂一段字节, 断言解出来是什么", 而是真的从一个进程的 socket 出去, 从另一个进程的 socket 进来 —— 一次完整的疏通测试, 只不过对面是自己.

它要解决的是下面几个问题.

上手不需要任何前置条件. 代码拉下来, 起两个进程就能跑起来. 不用申请专线, 不用等密钥下发, 不用协调联调窗口. 对一个外部依赖这么重的项目来说, "能在本机跑起来"这件事本身就把新人的上手成本砍掉了一大半 —— 否则一个刚接手的人在拿到网络权限之前, 连自己写的代码对不对都验证不了.

报文的填充是自动的. 一条授权报文二三十个域, 人不可能每次手填. 所以除了你真正关心的那一两个参数, 其余的域都用符合规格的随机数据填上 —— 检索参考号是合法字符集的 12 位, IC 卡数据是一段合法长度的字节:

models.WithF37(jcn.MustGenerateCode("anp", 12)),
models.WithF55(jcn.MustGenerateByte("anp", 114)),

顺带, 这也一直在压边界. 每敲一次命令, 变长域的长度和内容都不一样, 连着敲几十次, 相当于一轮小小的随机测试 —— 前面那些长度头, 补位, 半角全角混排的坑, 有好几个就是这么撞出来的.

有状态的流程终于可测了. 密钥轮换这种事单元测试很难覆盖: 它跨越多条报文, 还要求双方的状态同步变化. 在命令行里就是一条 key_exchange KC, 敲完接着敲 authori —— 如果新密钥没生效, 对面立刻会因为认证值对不上把这笔拒掉, 一秒钟就知道结果.

联调的时候人机配合很顺. 对面在电话那头说"再发一笔带 IC 卡数据的", 敲一行就行, 不用改代码, 不用重新编译, 不用重新开局. 窗口时间按小时算的时候, 这个差别很大.

这个命令行本身的代码量很小, 大部分就是一个 switch 加一堆预设好的 option, 实现上没什么可说的. 但它是整个项目里被跑得最多的一段代码.

值不值

回头看, 这是整个项目里性价比最高的一部分. 报文结构的问题, 状态机的问题, 重连的问题, 九成都在和假中心对接的时候就暴露了. 真正的联调窗口于是只用来验证那些自己猜不到的东西 —— 比如对端的实现和规格书不一致的地方, 这种事总是有的, 而且往往是最后才发现.

写李鬼当然是有成本的, 粗看甚至像是把同一件事做了两遍. 但这类项目里对端不可控是常态: 你拿不到它, 约不到它, 也不能让它配合你重复一百次异常场景. 与其等着对端可用, 不如先把对端造出来.

后记

一个 SDK, 上千页日文 PDF. 目前全流程能跑通了, 不过后面付费联调和上线, 可能还要调整不少.

做对了的大概是三件事: 用反射加 struct tag 描述报文, 让 bitmap 不需要人来维护; 密钥用接口注入, 把存储和轮换的策略留给业务; 以及从第一天就写李鬼, 而不是等到有联调窗口了再说. 这三件事其实是同一件 —— 都是在把"某个人对规格书的理解"变成"代码里能跑, 能测, 能被别人改的东西". 这个包迟早不会由我来维护, 到那时候, 留下来的应该是断言和测试, 而不是口头传承.

而"业务代码里不应该出现任何一个字节"这条, 大概是我从这个项目里带走的最主要的东西 —— 一个 SDK 的价值不在于它实现了多少规格书, 而在于它替使用者挡掉了多少规格书.

做糙了的地方也不少. 连接池那部分改动最大, 根子上是状态的位置不一样: Redis 那边会话就绑在连接上, 连接本身是无状态, 可替换的, 池子里取哪一条都一样, 坏了丢掉重建就行; 而这边每条连接有自己的远端地址和身份, 会话又独立在连接之外, 池子能做的其实只剩下选路. 结构还是从 go-redis 借来的, 但里面的逻辑基本都换了一遍, 有些写法 (比如那个重试次数, 还有一处 for 循环里的提前 return) 现在看着就别扭. 密钥那几个接口开重复了, 也该趁早合并掉.

不过这大概就是这类项目的常态: 规格书是别人的, 时间是固定的, 能做的只有确保自己这部分完整可靠.

搭建 WireGuard 网络

2022-11-29T19:00:24+09:00

本文介绍在一台 Ubuntu 22.04 的服务器下搭建 WireGuard 服务器端, 附带有客户端的一些配置.

安装

WireGuard 已经集成在 5.6 及以上版本的 Linux Kernel 中, Ubuntu 22.04 系统下直接安装即可

sudo apt update
sudo apt install wireguard

生成密钥对

cd /etc/wireguard
wg genkey | tee s_private.key | wg pubkey > s_public.key
wg genkey | tee c_private.key | wg pubkey > c_public.key

此时会在目录下生成四个文件, 具体说明如下

文件名	文件说明
s_private.key	服务器端私钥
s_public.key	服务器端公钥
c_private.key	客户端私钥
c_public.key	客户端公钥

配置 WireGuard 服务器端

具体需要各端准备的变量有以下这些

服务器端: 公网 IP, 内网 IP, 公网端口, 公钥, 私钥, 网络接口
客户端: 内网 IP, 私钥, 公钥

整理为如下表格

	服务器端	客户端
公网IP	233.233.233.233
内网IP	192.168.1.1	192.168.1.2
端口配置	udp/6666
私钥文件	s_private.key	c_private.key
公钥文件	s_public.key	c_public.key
网络接口	eth0

编写配置文件

文件位置为 /etc/wireguard/wg0.conf

[Interface]
Address = 192.168.1.1
DNS = 223.6.6.6
ListenPort = 6666
PrivateKey = s_private.key
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = c_public.key
AllowedIPs = 192.168.1.2

其中 Interface 可以大致理解为本机的配置, 而 Peer 是面向外部的配置. 有一些参数需要按照实际情况调整, 密钥需要替换为实际的字符串

其他服务器配置

在服务器端启动 IP 转发

sysctl net.ipv4.ip_forward=1

另外, 可能需要云主机上配置开放对应的 UDP 端口

启动与停止

配置完成后, 可以使用如下命令, 分别是启动, 查看状态, 停止

wg-quick up wg0
wg show wg0
wg-quick down wg0

WireGuard 客户端配置

编写配置文件

文件命名为 client.conf

[Interface]
PrivateKey = c_private.key
Address = 192.168.1.2
DNS = 223.6.6.6

[Peer]
PublicKey = s_public.key
Endpoint = 233.233.233.233:6666
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

也是要根据实际情况做相应的修改, 密钥替换为实际的字符串

其他客户端配置

可以使用如下命令在命令行生成二维码, 方便手机扫描

qrencode -t ansiutf8 < client.conf

Redis 查询偶尔超时问题排查

2022-10-28T14:54:14+09:00

表现

业务上 Redis 做去重使用, 量大但是操作简单, 超时均设置为 10ms, 偶尔有超时情况报错, 超时错误分布与业务流量正相关. Redis 由 AWS 的 ElasticCache 服务提供. 其中典型操作如下

SET key value expiration
GET key
MGET key1 key2 ...

Redis 客户端测试数据

latency-history

Redis 的 latency-history 选项将 PING 命令发送到 Redis 实例, 并测量响应时间, 统计时间以毫秒为单位.

# date
Fri Oct 28 10:49:58 JST 2022
# redis-cli -h {host} -p {port} --latency-history -i 5
min: 1, max: 5, avg: 1.92 (418 samples) -- 5.00 seconds range
min: 1, max: 5, avg: 1.93 (418 samples) -- 5.01 seconds range
min: 1, max: 5, avg: 1.93 (417 samples) -- 5.00 seconds range
min: 1, max: 7, avg: 1.98 (416 samples) -- 5.01 seconds range
min: 1, max: 4, avg: 1.94 (417 samples) -- 5.00 seconds range
min: 1, max: 3, avg: 1.93 (418 samples) -- 5.01 seconds range
min: 1, max: 3, avg: 1.92 (418 samples) -- 5.00 seconds range
min: 1, max: 3, avg: 1.94 (418 samples) -- 5.01 seconds range
min: 1, max: 3, avg: 1.95 (418 samples) -- 5.01 seconds range
min: 1, max: 17, avg: 2.08 (412 samples) -- 5.01 seconds range
min: 1, max: 5, avg: 2.00 (416 samples) -- 5.01 seconds range
min: 1, max: 4, avg: 1.94 (417 samples) -- 5.00 seconds range
min: 1, max: 5, avg: 1.89 (418 samples) -- 5.01 seconds range
min: 1, max: 3, avg: 1.91 (418 samples) -- 5.01 seconds range
min: 1, max: 13, avg: 2.01 (415 samples) -- 5.01 seconds range
min: 1, max: 12, avg: 2.12 (411 samples) -- 5.01 seconds range
min: 1, max: 5, avg: 1.96 (416 samples) -- 5.00 seconds range
min: 1, max: 8, avg: 2.07 (413 samples) -- 5.01 seconds range
min: 1, max: 7, avg: 1.97 (415 samples) -- 5.00 seconds range
min: 1, max: 5, avg: 1.93 (417 samples) -- 5.00 seconds range
min: 1, max: 8, avg: 1.99 (416 samples) -- 5.01 seconds range
min: 1, max: 6, avg: 2.04 (413 samples) -- 5.00 seconds range
min: 1, max: 3, avg: 2.03 (79 samples)^C
# date
Fri Oct 28 10:52:16 JST 2022

可以看到, 对于 PING 这样可以说没有任何性能负担的命令, 依然有少数情况响应时间大于 10ms

使用 benchmark 测试简单操作

# redis-benchmark -h {host} -t set,get -c 50 -d 64
====== SET ======
  100000 requests completed in 4.51 seconds
  50 parallel clients
  64 bytes payload
  keep alive: 1

0.00% <= 1 milliseconds
20.53% <= 2 milliseconds
95.87% <= 3 milliseconds
98.53% <= 4 milliseconds
99.24% <= 5 milliseconds
99.72% <= 6 milliseconds
99.75% <= 7 milliseconds
99.75% <= 8 milliseconds
99.76% <= 9 milliseconds
99.80% <= 10 milliseconds
99.85% <= 11 milliseconds
99.92% <= 12 milliseconds
99.98% <= 13 milliseconds
100.00% <= 13 milliseconds
22187.71 requests per second

====== GET ======
  100000 requests completed in 5.78 seconds
  50 parallel clients
  64 bytes payload
  keep alive: 1

0.00% <= 1 milliseconds
6.49% <= 2 milliseconds
76.89% <= 3 milliseconds
89.58% <= 4 milliseconds
94.31% <= 5 milliseconds
96.33% <= 6 milliseconds
97.64% <= 7 milliseconds
98.36% <= 8 milliseconds
98.77% <= 9 milliseconds
99.01% <= 10 milliseconds
99.22% <= 11 milliseconds
99.39% <= 12 milliseconds
99.51% <= 13 milliseconds
99.64% <= 14 milliseconds
99.67% <= 15 milliseconds
99.77% <= 16 milliseconds
99.81% <= 17 milliseconds
99.84% <= 18 milliseconds
99.86% <= 19 milliseconds
99.90% <= 20 milliseconds
99.91% <= 21 milliseconds
99.93% <= 22 milliseconds
99.94% <= 23 milliseconds
99.95% <= 24 milliseconds
99.95% <= 36 milliseconds
99.96% <= 37 milliseconds
99.97% <= 38 milliseconds
99.98% <= 39 milliseconds
99.99% <= 40 milliseconds
99.99% <= 41 milliseconds
100.00% <= 42 milliseconds
100.00% <= 42 milliseconds
17310.02 requests per second

# date
Fri Oct 28 11:20:23 JST 2022

对于简单操作的情况, 两个 9 的数据可以在 10ms 以内, 但是性能仍然不对, 预期操作在毫秒以内才是 Redis 正常的表现.

使用 bigkeys 检查 Key 情况

# redis-cli -h {host} --bigkeys

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' with 1 bytes
[00.00%] Biggest string found so far 'aaaaaaaaaaaaaaaaaaa' with 644 bytes
[00.00%] Biggest string found so far 'aaaaaaaaaaaaaaaaaaa' with 664 bytes
[00.05%] Biggest string found so far 'aaaaaaaaaaaaaaaaaaaa' with 668 bytes
[00.29%] Biggest string found so far 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' with 1312 bytes

-------- summary -------

Sampled 269241 keys in the keyspace!
Total key length in bytes is 11026631 (avg len 40.95)

Biggest string found 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' has 1312 bytes

0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
269241 strings with 45265771 bytes (100.00% of keys, avg size 168.12)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

# date
Fri Oct 28 11:33:23 JST 2022

Key 整体分布均匀, 没有特别大的 Key 的情况.

亚马逊实例数据

slowlog 典型案例

来自Redis 的 SLOWLOG 命令脱敏处理

{
    "CacheClusterId": "prod-rate-redis-001",
    "CacheNodeId": "0001",
    "Id": 592,
    "Timestamp": 1666749122,
    "Duration (us)": 18331,
    "Command": "get ... (1 more arguments)",
    "ClientAddress": "172.22.20.210:46370"
}

客户端测试时 CPU 指标

两个高峰分别是 benchmark 和 bigkey 操作引起.

网络指标

可以看到, Redis 网络数据速度每隔一小时会有一个突增.

分析

Redis 实例是有问题的, 简单操作耗时不能在 1ms 内返回, 99 分位在 10ms, 明显不是一个内存型数据库应有的性能.

由于在性能指标上一直看到 Redis 的 CPU 使用率不高, 导致了错误的排查方向, 以为是我们在使用上有问题. 实际上, 问题出在 aws 的实例上.

aws 的 t2 的实例以 20% 为性能基准, 低于 20% 累计积分, 其中积分累计有上限; 超过 20% 减少积分直至耗尽; 积分是以小时为单位积累的. 虽然没有具体的说明, 实际上 t2 实例的网络带宽也是有相应的积分限制的, 所以体现在网络指标上, 每隔一个小时出现一个特别的波峰.

另外, aws 标注的 t2 实例的网络性能是 Low to Moderate, 虽然没有官方的解释, 但是根据网友的测试, 基本上是 50Mbps 到 300Mbps. 这也解释了为何网络指标上一直在 6MB/s 左右上下浮动.

结论

使用了 aws 提供的 t2.small 实例, 在 CPU 性能, 网络性能上均有限制, 导致 Redis 实例出现超时的情况. 需要提高 Redis 实例的配置, 或者使用自建 Redis.

谨慎使用 aws 的实例类型; 在性能敏感的情况下, 不要使用 aws 的 t 类型实例, 一方面是有性能的积分的限制, 另一方面, 也容易碰到 Noisy Neighbor 的问题.

参考文档

附件

qa 环境下自建 Redis 性能测试

# redis-cli -h {host} -p 6379 --latency-history -i 5
min: 0, max: 3, avg: 0.34 (482 samples) -- 5.00 seconds range
min: 0, max: 1, avg: 0.33 (482 samples) -- 5.01 seconds range
min: 0, max: 1, avg: 0.32 (481 samples) -- 5.00 seconds range
min: 0, max: 3, avg: 0.33 (481 samples) -- 5.01 seconds range
min: 0, max: 4, avg: 0.32 (482 samples) -- 5.01 seconds range
min: 0, max: 3, avg: 0.31 (483 samples) -- 5.01 seconds range
min: 0, max: 1, avg: 0.30 (483 samples) -- 5.01 seconds range
min: 0, max: 1, avg: 0.29 (483 samples) -- 5.01 seconds range
min: 0, max: 1, avg: 0.31 (481 samples) -- 5.00 seconds range
min: 0, max: 1, avg: 0.32 (481 samples) -- 5.00 seconds range
min: 0, max: 1, avg: 0.28 (25 samples)^C
# date
Mon Oct 31 18:47:05 JST 2022

# redis-benchmark -h {host} -t set,get -c 50 -d 64
====== SET ======
  100000 requests completed in 1.36 seconds
  50 parallel clients
  64 bytes payload
  keep alive: 1

99.88% <= 1 milliseconds
99.97% <= 2 milliseconds
99.99% <= 4 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
73313.78 requests per second

====== GET ======
  100000 requests completed in 1.30 seconds
  50 parallel clients
  64 bytes payload
  keep alive: 1

99.90% <= 1 milliseconds
99.94% <= 2 milliseconds
99.95% <= 4 milliseconds
99.96% <= 5 milliseconds
100.00% <= 5 milliseconds
76628.36 requests per second


# date
Mon Oct 31 18:48:10 JST 2022

99分位 10ms -> 999分位 1ms

不过自建 Redis, 由于是在 EC2 上的托管 Kubernetes 集群, 也需要注意 Noisy Neighbor 的问题.

Redis 常见问题排查思路

除了本次遇到的实例性能限制问题, 排查 Redis 延迟问题时, 通常还可以从以下几个常见方面入手

连接池问题

Redis 配置连接池的重要参数 MaxIdleOpen, IdleCloseTimeout, 配置不当时, 查看端口占用会有大量 TIME_WAIT, TCP 的断开会有 2MSL - MSL 在 Linux 默认 60s; 适当配置 keep-alive

Big Key

单个 Key 内容过大, 单线程特性, 可能阻塞整个服务

耗时操作

O(N)操作, KEYS, SORT, LINDEX

同时超时

超时淘汰方式 - lazy, active, 大量 (25%以上) Key 同时超时, 缓存预热, 超时增加随机因子

Redis Fun Fact

Redis 没有"读写"的区别
Redis LRU 的近似实现
ziplist, 紧凑的内存布局, 用于优化存储小数据量的 list, hash, zset

把 crontab 从时间点变成时间段

2022-09-11T15:42:08+09:00

从一个促销需求说起

业务上要支持这样的规则:

每月 29 日, 肉类半价
每周五晚上十点以后, 积分翻倍

一开始的想法是在数据库里建几个字段: 星期几, 从几点到几点, 每月第几天. 但很快就发现字段不够用 —— 下一条规则可能是"每月最后一个周五", 再下一条是"每季度第一天", 每加一种就要加字段, 或者加一张表.

盯着这些规则看了一会, 会发现它们和 crontab 长得很像. "每周五 22 点"就是 0 22 * * 5, "每月 29 日零点"就是 0 0 29 * *. crontab 本来就是为了描述"周期性地在什么时候"而设计的, 而且它已经存在几十年, 所有工程师都认识, 现成的解析库到处都是.

差的只有一点: crontab 描述的是时间点, 而我们需要的是时间段.

补上这一点其实很简单 —— 给 cron 表达式加一个"持续多久":

cron 表达式  +  时长  =  周期性的时间段

cronrange

这个想法已经有人做了, 1set/cronrange. 表达式长这样:

DR=120; TZ=Asia/Tokyo; 0 22 * * 5

分号隔开的三段:

DR=120 是时长, 单位分钟;
TZ=Asia/Tokyo 是时区, 可选, 用 IANA 时区数据库里的名字;
0 22 * * 5 是 cron 表达式, 表示时间段的起点.

开头那两条规则就成了:

每月 29 日全天肉类半价        DR=1440; TZ=Asia/Tokyo; 0 0 29 * *
每周五 22 点起两小时双倍积分   DR=120;  TZ=Asia/Tokyo; 0 22 * * 5

好处很直接: 一条规则就是一个字符串. 数据库里一个 varchar 就存下了, 不用为了新规则改表结构; 走 JSON 也是一个字符串, 这个库实现了 MarshalJSON / UnmarshalJSON, 序列化的事情不用自己写.

时区那一段值得单独说一句. "每周五晚上十点"是谁的十点? 服务器所在时区, 还是门店所在时区? 这个问题在只有一个国家的时候可以糊弄过去, 有了第二个国家就必须回答. 表达式里带上时区, 等于强迫配置的人当场想清楚.

我们的用法是反过来的

这是我觉得最值得说的一点.

大部分 cron 库是为调度写的, 核心方法是"下一次是什么时候" —— 你注册一个任务, 库来负责在正确的时刻叫醒你. cronrange 里对应的是 NextOccurrences().

而我们要的是相反的方向: 给定一个时刻, 判断它落不落在某个时间段里. 一笔交易进来, 带着自己的时间戳, 要判断适用哪些规则. 对应的方法是 IsWithin().

cr, err := cronrange.ParseString("DR=120; TZ=Asia/Tokyo; 0 22 * * 5")
if cr.IsWithin(order.PaidAt) {
    // 双倍积分
}

注意这里传的是 order.PaidAt, 不是 time.Now(). 这一点很重要 —— 补单, 重算, 对账都要用历史时间. 如果判断依赖"现在", 那隔天重跑一遍得到的结果就和当时不一样, 在和钱有关的系统里这是不能接受的. 所以这类接口一定要能传入任意时刻, 而不是把 now 藏在里面.

同一个表达式, 调度器拿去往前推, 我们拿来往回查, 方向正好相反.

IsWithin 是怎么实现的

这里有个有意思的地方: cron.Schedule 只提供 Next(), 没有 Prev(). 你没法直接问"上一次是什么时候".

所以判断 t 在不在窗口里, 只能先往回退一个时长, 再从那里问"下一次是什么时候":

searchStart := t.Add(-(cr.duration + 1*time.Second - 1*time.Nanosecond))
rangeStart := cr.schedule.Next(searchStart)
rangeEnd := rangeStart.Add(cr.duration)

// 检查 rangeStart <= t <= rangeEnd
within = (rangeStart.Before(t) && rangeEnd.After(t)) || rangeStart.Equal(t) || rangeEnd.Equal(t)

退一个 duration 是主体, 后面那个 + 1s - 1ns 是补偿: Next() 返回的是严格晚于给定时刻的下一次, 而且精度只到秒. 不多退这一点, 恰好卡在边界上的窗口会被漏掉.

另外要注意区间是闭的, 两端都算. 拿"每周五 22 点起两小时"实测一下:

时刻	IsWithin
周五 21:59:59	false
周五 22:00:00	true
周五 23:00:00	true
周六 00:00:00	true
周六 00:00:01	false

两端都命中, 意味着相邻的两个时间段在交界点上会同时成立. 如果配了"今天 0 点到 24 点"和"明天 0 点到 24 点"两条规则, 那么正好落在 00:00:00 的一笔交易两条都满足. 要么在业务层再判一次, 要么把时长设成差一秒.

一个必须提醒运营的坑

写完之后顺手把"每月 29 日"的未来几次打印出来看看:

[2022-01-29T00:00:00+09:00, 2022-01-30T00:00:00+09:00]
[2022-03-29T00:00:00+09:00, 2022-03-30T00:00:00+09:00]
[2022-04-29T00:00:00+09:00, 2022-04-30T00:00:00+09:00]
[2022-05-29T00:00:00+09:00, 2022-05-30T00:00:00+09:00]

二月没有. 2022 年不是闰年, 没有 2 月 29 日, 所以这条规则在二月整月不生效.

这不是库的 bug, cron 本来就是这个语义. 但配规则的是运营, 他们说"每月 29 日"的时候, 默认每个月都有 29 日. 类似的还有 31 日, 一年里有四个月不会触发.

所以这里的做法是: 保存规则的时候, 把接下来 12 次的触发时间列出来给人确认一遍. 也就是说, NextOccurrences() 在我们的用法里不是用来调度的, 而是用来给人预览的. 一个本来给调度器用的方法, 换个场景成了配置界面上的校验工具.

加两件东西

用起来之后有两个地方不太够用, 于是在 fork 上改了改, 代码在 memwey/cronrange.

时长不该只有分钟

原来的构造函数是这样的:

func New(cronExpr, timeZone string, durationMin uint64) (*CronRange, error)

"分钟"被写死在类型里了. 这带来两个问题: DR=90 到底是 90 分钟还是 90 秒, 只能翻文档才知道; 而且秒级的窗口 (比如秒杀) 根本表达不出来.

Go 里本来就有 time.Duration 这个类型, 单位是自带的, 没道理不用. 但 New 的签名不能改, 一改所有调用方都得跟着改. 所以新开一个:

func Create(cronExpr, timeZone string, duration time.Duration, cp cron.Parser) (*CronRange, error)

cron 解析器要能换

robfig/cron 的解析行为是在构造 Parser 的时候定死的: 是五个字段还是六个字段 (带秒), 支不支持 @every 这类描述符. 而库里原本写死了一个包级的 parser.

不同项目对 cron 方言的要求并不一样, 尤其是需要秒级精度的时候. 与其在库里多加几个开关, 不如把 Parser 直接作为参数传进来, 让使用者自己决定.

不过光有 Create() 还不够. 这个库的用法前提是规则以字符串的形式存起来, 所以除了构造, 还得能读回来 —— 而 ParseString() 用的是写死的包级 parser. 只加 Create() 的话, 自定义 parser 就只能用一半: 造得出来, 存得进去, 读不回来.

String()                          = "DR=3s; TZ=Asia/Tokyo; */10 * * * * *"
ParseString(s)                    -> expected exactly 5 fields, found 6
ParseStringWithCronParser(s, sec) -> ok

所以配套加了 ParseStringWithCronParser(), 把这个往返闭合上.

麻烦的是格式

真正花时间的是这一块.

表达式是要存起来的 —— 数据库里躺着一批, JSON 里传着一批. 加了 time.Duration 之后, DR=90 和 DR=2h 都必须能解析.

按说应该在格式里加个版本号, 但那样所有已经存下来的字符串都要迁移. 于是换个办法: 靠值本身的形状来区分. 纯数字是老格式 (分钟), 带单位是新格式.

if duration, err = time.ParseDuration(durStr); err == nil {
    if duration > 0 {
        version = Version2
    }
}
if durMin, err = strconv.ParseUint(durStr, 10, 64); err != nil {
    if version != Version2 {
        break PL
    }
    err = nil
}

先试新格式, 不行再退回老格式. 这两者正好不重叠: time.ParseDuration("90") 会因为缺单位而失败, strconv.ParseUint("1h30m") 也过不去, 不会有一个字符串两边都认.

反过来, String() 该输出哪一种? 用一个 version 字段记住这个实例当初是怎么来的:

New(..., 90).String()                = "DR=90; TZ=Asia/Tokyo; 0 22 * * 5"
Create(..., 90*time.Minute).String() = "DR=1h30m0s; TZ=Asia/Tokyo; 0 22 * * 5"

两者的 Duration() 完全相等, 只是打印出来不一样.

这么做是为了保证 round-trip: 从数据库读出来的老表达式, 解析之后再写回去, 还是原来的样子. 不会因为某天升级了一个库版本, 存量记录被悄悄改写了一遍 —— 那种事情在排查问题的时候非常难受, 因为你会怀疑是不是有人手动改过数据.

这么做的代价

内部状态泄漏到了输出行为上. 同样是 90 分钟, 只因为来源不同, String() 的结果就不一样. 对使用者来说这是个意外.

更干净的做法大概有两种: 解析的时候把原始文本记下来, String() 原样吐回去; 或者干脆规定 String() 永远输出新格式, 并接受"存量数据会被逐步改写"这件事. 但这两种都要动更多地方, 在一个 fork 上做改动, 我选了侵入最小的那个. 这个取舍现在看仍然成立, 只是应该在文档里写清楚, 而不是让人自己撞上.

顺带发现的一个问题

读解析代码的时候注意到, 未知的部分并不总是会报错:

"junk; DR=90; 0 0 1 1 *"   ->  解析成功
"DR=90; junk; 0 0 1 1 *"   ->  报错 unknown part: "junk"

同样一个 junk, 放在 DR= 前面就被吃掉了, 放在后面才报错.

原因在上面那段代码里: DR= 这个分支把命名返回值 err 当中间变量用了. strconv.ParseUint 成功的时候会把 err 赋成 nil, 而前一轮循环里 default 分支设置的"未知部分"错误, 就这么被盖掉了.

// 有问题: err 是命名返回值, 这里被用来接临时结果
if durMin, err = strconv.ParseUint(durStr, 10, 64); err != nil {

// 应该用局部变量, 最后再决定 err 是什么
n, parseErr := strconv.ParseUint(durStr, 10, 64)

这个问题在加 time.Duration 之前就有了, 只是现在多了一层试探, 更容易踩到. Go 的命名返回值本来就容易出这种事, 再加上 switch 各个分支共用同一个 err, 就更不容易看出来.

小结

crontab 的表达能力大概是被低估了. 它是一个已经存在几十年, 所有工程师都认识, 而且到处都有现成解析器的领域特定语言. 需要描述"周期性的时间"的时候, 先想想能不能用它, 通常比自己设计一套字段要好 —— 至少不用为了"每月最后一个周五"这种需求再改一次表.

它缺的那一块是时长, 补上就能表达时间段.

另外要留意方向. 大部分 cron 库是为调度写的, 关心的是"下一次"; 如果需求是"这个时刻算不算", 那要的是另一个方法, 而且必须能传入任意时刻, 不能把 now 藏在实现里.

Prometheus 手把手

2022-05-10T16:36:07+08:00

因为 Prometheus 在应用中一共只有四种 metric 类型, 只要根据需要监测的目标选择了 metrics 类型, 后续的告警以及可视化配置就有固定的套路了.

Counter

Counter 用来监控单调递增的量, 当发生重置时 Prometheus 会自动处理归零的数据. 这是一个非常基本的类型, 一个系统中很多数据都可以通过此类型进行计数, 比如系统接受的请求数, 系统发生的错误数, 再比如对第三方接口的调用数, 第三方接口返回的错误数.

业务代码如下

from prometheus_client import Counter
c = Counter(
    'web_request_total', 'web request total counter',
    ['method', 'endpoint', 'status_code']
)
c.labels('get', '/', '200').inc()
c.labels('post', '/submit', '500').inc()

此时在业务暴露出来的端点上会有这样两条记录

web_request_total{method="/submit",method="post",status_code="500"} 1
web_request_total{method="/",method="get",status_code="200"} 1

对于 Counter 我们一般看增长量和增长速率

sum(increase(web_request_total[5m])) 五分钟内总请求数
sum(increase(web_request_total{status_code!~"^2.."}[1m])) 一分钟内状态码不为2xx的总请求数
sum(irate(web_request_total[1m])) 一分钟内总请求数增长率

告警则一般设置为

一分钟内总请求中有有超过 5% 的 5xx 错误, 持续一分钟

expr: sum(rate(web_request_total{status_code=~"^5.."}[1m])) / sum(rate(web_request_total[1m])) * 100 > 5
for: 1m

一分钟内 5xx 错误的请求增长率高于 100%, 持续一分钟

expr: sum(irate(web_request_total{status_code=~"^5.."}[1m])) > 100
for: 1m

Gauge

Gauge 是一个瞬时量, 在时间上来看是可增可减的, 用以记录系统在某个时刻的当前状态, 比如当前实例线程数, 当前系统负载, 某个队列的长度, 某个队列的消费延时等.

业务代码如下

from prometheus_client import Gauge
g1 = Gauge(
    'kafka_consumer_lag_seconds', 'kafka consume lag in second',
    ['topic', 'consumer_group']
)
g1.labels('k-test', 'grp1').set(233)
g2 = Gauge(
    'redis_connection_pool_count', 'redis connection poll count',
    ['state']
)
g2.labels('idle').set(10)
g2.labels('active').set(22)
g2.labels('total').set(32)

此时在业务暴露出来的端点上会有这样的记录

kafka_consumer_lag_seconds{topic="k-test",consumer_group="grp1"} 233
redis_connection_pool_count{state="idle"} 10
redis_connection_pool_count{state="active"} 22
redis_connection_pool_count{state="total"} 32

对于 Gauge 我们一般直接看其值或者其值的百分比

kafka_consumer_lag_seconds{topic="k-test"} 查看 k-test 这个 topic 最新的消费延迟
avg_over_time(kafka_consumer_lag_seconds[1m]) 查看应用全部 kafka 队列一分钟的平均消费延时
max_over_time(kafka_consumer_lag_seconds[1m]) 查看应用全部 kafka 队列每一分钟内的最大消费延时
redis_connection_pool_count{state="active"} / ignoring(state) redis_connection_pool_count{state="total"} 查看应用 redis 连接池的使用百分比

告警则一般设置为

一分钟内队列的平均消费延时大于 10min, 持续一分钟

expr: avg_over_time(kafka_consumer_lag_seconds[1m]) > 600
for: 1m

Redis 连接池平均占用超过 90%, 持续一分钟

expr: avg_over_time(redis_connection_pool_count{state="active"}[1m]) /  ignoring(state) avg_over_time(redis_connection_pool_count{state="total"}[1m]) * 100 > 90
for: 1m

Histogram 和 Summary

Histogram 可以看作是一个复合的 Counter 类型, 它会将数值按区间计数, 常用于记录 P99, P95 类的数据. 可以用来记录比如接口响应耗时情况, 接口返回数据大小情况等.

from prometheus_client import Histogram
h = Histogram(
    'http_request_duration_seconds', 'Api requests response time in seconds',
    ['api', 'method'], (0.1, 0.25, 1, 4, 10)
)
h.labels('/products', 'post').observe(0.0923)
h.labels('/products', 'post').observe(0.3672)

此时在业务暴露出来的端点上会有这样的记录, 产生了多条数据, 其中 _sum 是值的总和, _count 是值的计数, _bucket 中有一个命名为 le 特殊的 label, 其中的区间值是我们在代码中配置的, 是值在区间内的计数.

http_request_duration_seconds_sum{api="/products", "method"="post"} 0.4595
http_request_duration_seconds_count{api="/products", "method"="post"} 2
http_request_duration_seconds_bucket{api="/products", "method"="post", le="0.1"} 1
http_request_duration_seconds_bucket{api="/products", "method"="post", le="0.25"} 1
http_request_duration_seconds_bucket{api="/products", "method"="post", le="1"} 2
http_request_duration_seconds_bucket{api="/products", "method"="post", le="4"} 2
http_request_duration_seconds_bucket{api="/products", "method"="post", le="10"} 2
http_request_duration_seconds_bucket{api="/products", "method"="post", le="+Inf"} 2

对于 Histogram 一般可以求均值或者 P95, P99 之类的值, 也可以做普通的 Counter 使用

rate(http_request_duration_seconds_sum{api="/products", "method"="post"}[5m]) / rate(http_request_duration_seconds_count{api="/products", "method"="post"}[5m]) 查看 /products 端点上 POST 请求五分钟内的耗时均值
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{api="/products", "method"="post"}[5m])) 查看 /products 端点上 POST 请求五分钟内的耗时 P99
increase(http_request_duration_seconds_count{api="/products", "method"="post"}[1m]) 查看 /products 端点上 POST 请求一分钟内的请求数

告警则一般设置为

两分钟内某个接口 P95 大于 10s, 持续两分钟

expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[2m])) by (api, method)) > 10
for: 2m

一些有用的资料

Prometheus 从入门到放弃

2022-04-17T16:30:08+08:00

基本概念

Prometheus 是一个开源的监控方案, CNCF 的毕业项目, 云原生监控的事实标准. Prometheus 以时间序列数据的形式收集和存储 metrics. Metrics 信息与被称为标签的可选的键值对和记录时间一起保存.

Prometheus 的主要功能特点有

由 metric 的名称以及 Key/Value 对标签标识的时间序列数据组成的多维数据模型
灵活的查询语言 PromQL
不依赖分布式存储; 单服务节点自治能力
服务端通过 HTTP 协议拉取获得的时间序列数据
支持通过中间网关推送时间序列数据
通过服务发现或静态配置文件发现监控目标
支持多种类型的图表和仪表盘

Prometheus 以拉取的模式获取获取监控数据, 而不是由业务方向监控服务器推送. 这对于被监控的业务来说, 极大的减少了监控部分在系统中的耦合. 通常, 业务暴露出一个 HTTP 端口以暴露数据, 供 Prometheus server 抓取即可.

Metric

一般来说, Metric 是数值形式的标量单位, 它是与时间一起被记录的时间序列. 在不同应用中用户期望记录不同的 Metric. Web server 可能要希望请求数和一些指标信息, 数据库可能希望记录活跃连接数和活跃查询数之类的.

系统架构

主要的 Prometheus server 收集和存储时间序列数据
客户端库用以监测应用程序代码
push gateway 用以支持短期运行的任务
用以监控 HAProxy, StatsD, Graphite 等常用服务的 exporters
用以处理告警的 alertmanager
其他各种支持工具

适用场景

Prometheus 适合记录任何纯数值的时间序列。它既适合以机器为中心的监控, 也适合监控高度动态的面向服务的体系结构. 它对多维数据收集和查询的支持在微服务的场景中拥有特别的优势.

Prometheus 基于可靠性设计, 以保证在出现问题时可以快速进行问题诊断. 每个 Prometheus server 都是独立的, 不依赖于网络存储或其他远程服务. 当基础设施的其他部分出现故障时, 这种架构非常可靠, 另一方面, 它不需要配置大量的基础设施.

Prometheus 不适合需要 100% 的准确性的场景, 例如记录单个的计费请求, 收集的数据可能不够详细和完整. 在这种情况下应使用其他系统来收集和分析计费数据, 使用 Prometheus 进行其余的监控.

这里说的比较笼统, 从构建系统可观测性的监控来说, 我们有 Metrics , Tracing 和 Logging. 它们有各自的特点, Metrics 的特点是可聚合的, 它们是组成一个量计, 计数器或者直方图的最小单位. Logging 处理一系列离散事件. 而 Tracing 处理整个请求范围内的信息, 数据或元数据应当绑定到系统中单个事务对象的生命周期中.

Prometheus 是个典型的 Metrics 系统, 它为系统打点, 追踪系统整体的运行情况. 比如, 记录 Web 系统中的所有请求的 HTTP 状态码, 当一段时间中 500 错误大量出现时, 可以通过配置的聚合和趋势分析发现问题并提供告警, 但它没有记录具体的请求内容, 想要复现错误的请求, 则需要 Tracing 和 Logging 系统进行进一步的诊断.

快速入门

数据模型

Metric and Label

Prometheus 在底层将所有属于同一指标名称, 同一标签集合的, 有时间戳标记的数据流存储为时间序列数据.

数据模型的表示方式为

<metric name>{<label name>=<label value>, ...}

且有以下规则

metric name

匹配正则 [a-zA-Z_:][a-zA-Z0-9_:]*, 其中 : 是用户自定义记录规则的标记, 不应该用在业务暴露的指标中

label name

匹配正则 [a-zA-Z_][a-zA-Z0-9_]*, 其中以 __ 开头的是系统保留命名

Sample

Sample 的 value 总是为一个 float64 值

以关系型数据库来类比, metric_name 相当于表名, label_name 相当于列名, label_value 相当某一字段的值, 而 metric_value 和 timestamp 的列是系统自动生成的.

比如如下名为 api_http_requests_total 指标表示了 API 所有的 HTTP 请求数, 其中标签 method 指定了方法, handler 指定了路径, 分别为 method="POST" 和 handler="/messages", 此样本的值为 11

api_http_requests_total{method="POST", handler="/messages"} 11

CREATE TABLE `api_http_requests_total` (
    `timestamp` timestamp,
    `method` varchar(255),
    `handler` varchar(255),
    `value` double
);

SELECT * FROM `api_http_requests_total`;

+------------+--------+-----------+-------+
| timestamp  | method |  handler  | value |
+------------+--------+-----------+-------+
| 1649235184 |  POST  | /messages |   11  |
+------------+--------+-----------+-------+

Metric

Prometheus 提供了以下一些类型 metrics 类型

Counter

Counter 类型代表一种样本数据单调递增的指标, 即除非监控系统发生了重置, 只增不减.

例子: 系统接受的请求数, 系统错误数, 系统 uptime

Gauge

Gauge 类型代表一种样本数据可以任意变化的指标, 即可增可减.

例子: 当前实例线程数, 当前系统负载

Histogram 和 Summary

Histogram 和 Summary 用以对数据进行采样并储存其分布情况. 不同的是, Histogram 指定其配置的区间, 而 Summary 配置其分位数.

举一个具体的例子, 假设需要统计某个 WEB 页面的响应时间, 使用 Histogram 时, 需要配置其响应时间区间, <10ms, 10ms-100ms, 100ms-1000ms, >1000ms, 返回的数据如下

http_response_latency_range_bucket{le="0.01"} 123
http_response_latency_range_bucket{le="0.1"} 214
http_response_latency_range_bucket{le="1"} 215
http_response_latency_range_bucket{le="+Inf"} 216
http_response_latency_range_sum 2.888716127000002
http_response_latency_range_count 216

使用 Summary 时, 则配置 0.5, 0.9, 0.99, 代表了其50分位, 即中位数, 90分位, 99分位的值

http_response_latency{quantile="0.5"} 0.012352463
http_response_latency{quantile="0.9"} 0.014458005
http_response_latency{quantile="0.99"} 0.017316173
http_response_latency_sum 2.888716127000002
http_response_latency_count 216

此时可以看到, 这个 HTTP 接口一共接受了 216 次请求, 一共耗时使用了 2.88s, Histogram 展示了具体数值分布, 123 个在 10ms 内, 有 216 - 215 = 1 个请求耗时超过了 1000ms. Summary 展示了分布的百分位, 中位数是 0.012s, 99分位是 0.017s.

通常我们使用 Histogram 即可, Summary 会使用较多的内存构造一个滑动窗口来做统计.

注意事项

每个键值标签对的唯一组合都代表一个新的时间序列, 这会显著增加暴露的指标数和存储的数据量. 不要使用标签存储具有高基数, 即拥有许多不同的标签值的维度, 例如用户id, restful 的实际路径参数等.

// Good
http_request_total{path="users/{:user_id}/info"}

// Bad
http_request_total{path="users/1/info"}
http_request_total{path="users/2/info"}
http_request_total{path="users/3/info"}
http_request_total{path="users/4/info"}

// Good
crawler_failure_total{target="tiktok",scope="user"}

// Bad
crawler_failure_total{target="tiktok",user="damonlvu"}
crawler_failure_total{target="tiktok",user="77777777777ge"}

在 Prometheus 中, Metric 和 Label 的命名应该总是使用 snake_case 形式, 以便后续的处理归类分割等操作.

一个 Metric 的前缀总应该使用应用名, 可以理解为一个命名空间, 例如

prometheus_notifications_total (Prometheus 的内部指标)
doris_consumption_latency_seconds (doris 的消费延时)
crawler_failure_total (爬虫的总失败数)
crawler_request_total (爬虫的总请求数)

一个 Metric 总应该以其单位的复数形式为后缀, 并且单位应该尽量统一, 如果是一个累积的计数, 总应该使用 total

node_memory_usage_bytes
http_requests_total
process_cpu_seconds_total

抓取设置

通过 Prometheus Operator 的 ServiceMonitor 对象, 可以相对便捷的, 通过不直接修改 prometheus config 的方式添加抓取目标.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-service-monitor
  labels:
    team: ops
spec:
  selector:
    matchLabels:
      svc-label-key: svc-label-value
  endpoints:
  - port: 80
  - path: /metrics

上面的实例指定了一个名为 example-service-monitor 的 ServiceMonitor, 它会选择所有 svc-label-key 的值为 svc-label-value 的 Service 进行监控, 目标端口为 80, HTTP 路径为 /metrics. Service 背后可能存在超过一个的无状态的 Pod, 他们会被自动发现.

Prometheus Operator 会解析 ServiceMonitor 对象, 生成相应的抓取设置到 prometheus config.

指标选择

一般 exporter 会采集很多的指标, 比如 jvm 的运行情况, http 请求情况等等. Google 在 SRE Handbook 中提出了四个黄金信号: 延迟, 流量, 错误数, 饱和度. 实际操作中可以使用 USE 或 RED 方法作为指导, USE(Utilization, Saturation, Errors) 用于资源, RED(Rate, Errors, Duration) 用于服务.

一般的在线服务, 比如 Web 服务, 数据库等, 一般关心请求速率, 延迟和错误率, 使用 RED 方法; 一般的离线服务, 如日志处理, 消息队列等, 一般关注队列数量, 进行中的数量, 处理速度以及发生的错误, 使用 USE 方法.

Rate 速率

sum(rate(http_server_requests_seconds_count[5m])) by (method, uri, job)

统计访问的 QPS

Errors 错误

rate(http_server_requests_seconds_count{status=~"^5..$"}[5m]) / rate(http_server_requests_seconds_count[5m])

统计 HTTP 状态码为 5xx 的比例

Duration 请求时间

sum by (job, uri, method) (rate(http_server_requests_seconds_sum[5m]) / rate(http_server_requests_seconds_count[5m]))

统计平均请求时间

参考资料

What is Prometheus?

Metrics, tracing, and logging

container-monitor-book

一个离职小记

2021-06-06T23:29:39+08:00

从一家创业公司离职, 去另外一家创业公司.

在家待了一个月多一点, 期间解决了一下家里的大事小情, 复习刷题和面试, 开始巴西柔术的学习, 控制饮食和运动, 刷 Bilibili 什么的. 然而最重要的婚礼因为突如其来的疫情只能被迫延后了.

不得不说, 广州的机会真的不多. 一开始找了几家中等级别的公司面试练手, 结果发现没有达到那种面的我怀疑人生然后努力复习的结果, 随手就面过, 回家接着摸鱼. 然后抱有比较大希望的腾讯和字节都因为各种各样奇怪的原因连面试都没有, 不得不说和某些公司就是没有缘分.

离开的原因

其实我觉得还是离开上一家公司的太迟了. 年初拿到 Edison 的 Offer 的时候就应该离开了.

有种观点认为, 对于一个创业来说, 最重要的是团队, 尤其是最初共同创业的团队, 业务都是在其次. 但是上一家公司在去年第三季度的时候就出现了一波离职潮, 基本上所有作为公司创始成员的老员工都离职了. 曾经工资都发不出来的时期没有离开, 现在拿到融资了业务有一些眉目了反而离开了, 可能这就是可以共患难而不能同富贵吧.

当然可能并不是钱的问题. 老板自己承认自己有暴力沟通的问题. 不过, 能不能认识到是一回事, 能不能控制是另外一回事. 人总不可能不犯错, 往好了说是老板真性情, 往坏了说就是老板抓住一点错误就大做文章, 哭爹骂娘什么的.

创业有一个相当不好平衡的问题. 创业公司当然希望团队成员能力超群, 能解决各种各样的问题, 但是除了少数带有光环的创业公司, 资金一般都不是那么充裕的. 对于优秀的求职者来说, 既然是创业, 风险更高, 为何要放弃差不多甚至更低的短期回报, 来承担更高的风险呢. 这也是上面提到的最初共同创业的团队非常重要的原因之一.

在上一家公司, 老板可能是想出了解决办法. 团队中少数的优秀员工负责, 带领一些能力一般的员工. 作为后端负责人, 经常梳理产品设计, 团队代码审查就把工作时间占满了, 写代码只能加班. 有次私下跟老板吐槽一个产品经理, 根本发现不了用户需求, 一个功能上线了四五版, 都解决不了用户的问题. 老板一句话顶回来了: 你知道她一个月多少钱吗, 五千.

在这种同事能力参差, 而老板有时又格外苛责的情况下, 压力确实比较大, 情绪比较消沉, 有段时间天天想请假, 想到要去上班就头疼. 最终还是决定离职了.

选择的原因

又来到一家创业公司其实自己都蛮没想到的, 毕竟最初的构想是去大公司做一些基础架构的开发, 远离枯燥重复的业务开发.

这家公司最吸引的可能就是微信顶级产品经理带队吧. 这几年的工作也算是接触过不少产品经理, 有厉害的也有水平一般的, 感觉产品经理是一个有手就能做的职业, 但是水平高的产品经理确实无法替代. 想近距离接触一下传说中的微信之母, 直接向张小龙汇报的产品经理, 看看她们的思维和做事是什么样的.

另外, 这家公司光环比较强, 资金比较充足, 薪酬福利什么的都挺不错的, 完美的解决了创业公司的一些问题.

不过个人还是觉得在目前公司主要产品上, 有一些隐患, 在熟人IM和陌生人社交上有点定位不清. 而且在熟人IM上, 很难看到短期内的盈利空间. 但是毕竟不是专业的产品经理, 所有的看法都是基于已有的产品, 比如微信, 陌陌, Soul 什么的. 厉害的产品经理可以发现别人发现不到的需求, 万一呢.

Redis ZINTERSTORE

2021-04-21T20:30:43+08:00

结构推测

今天与人争执的时候觉得应该探究一下 Redis 中 ZINTERSTORE 的实现. 先看文档中的描述

ZINTERSTORE destination numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE SUM|MIN|MAX]

Available since 2.0.0.

Time complexity: O(NK)+O(Mlog(M)) worst case with N being the smallest input sorted set, K being the number of input sorted sets and M being the number of elements in the resulting sorted set.

大致意思就是最坏情况下时间复杂度是 O(N*K)+O(M*log(M)), 其中 N 是输入中元素最少的 sorted set 的元素数目, K 是输入的 sorted set 的数量, M 是结果中的 sorted set 中元素的数目.

其实光从时间复杂度就能推测出来大致的操作了. O(M*log(M)) 这个复杂度很有可能是一次排序操作, 而且和结果中的元素数目相关, 那么很有可能是先取交集之后得出 M 个元素, 再在 M 个元素中进行排序的. 当然, 也有可能是相应的, 在有序的序列中进行插入的操作.

而 N 是最小的 sorted set 的元素个数. 这个一开始我有点想不明白, 难道不应该是最大的才对吗, 因为这里我还是想着去遍历其他的 sorted set 进行比较. 但是思考一下, sorted set 也是 set 嘛, 完全可以使用 O(1) 的效率在其中进行查找. 这样实际就变成了分别在 (K - 1) 个 sorted set 中寻找 N 个元素, 这样自然就是 O(N*K) 了.

源码分析

以下源码基于 Redis 3.0 分析, 实际的函数操作为

/* https://github.com/redis/redis/blob/3.0/src/t_zset.c#L1905 */
void zunionInterGenericCommand(redisClient *c, robj *dstkey, int op)

这里我们可以看到, 在 Redis 的源码中将 ZINTERSTORE 和 ZUNIONSTORE 放在了一起处理, 使用 op 做区分.

随后是一段漫长的代码, 主要是处理输入参数的, 比如要操作的 sorted set 的列表, 存到了 src 中; 然后处理 WEIGHTS 和 AGGREGATE. 代码比较长而且逻辑也很简单.

/* https://github.com/redis/redis/blob/3.0/src/t_zset.c#L1993 */

    /* sort sets from the smallest to largest, this will improve our
     * algorithm's performance */
    qsort(src,setnum,sizeof(zsetopsrc),zuiCompareByCardinality);

然后这里把所有 sorted set 按元素的个数从小到大排列, 以提高效率. 随后是具体的取交集的代码.

/* https://github.com/redis/redis/blob/3.0/src/t_zset.c#L2001 */

    if (op == REDIS_OP_INTER) {
        /* Skip everything if the smallest input is empty. */
        if (zuiLength(&src[0]) > 0) {
            /* Precondition: as src[0] is non-empty and the inputs are ordered
             * by size, all src[i > 0] are non-empty too. */
            zuiInitIterator(&src[0]);
            while (zuiNext(&src[0],&zval)) {
                double score, value;

                score = src[0].weight * zval.score;
                if (isnan(score)) score = 0;

                for (j = 1; j < setnum; j++) {
                    /* It is not safe to access the zset we are
                     * iterating, so explicitly check for equal object. */
                    if (src[j].subject == src[0].subject) {
                        value = zval.score*src[j].weight;
                        zunionInterAggregate(&score,value,aggregate);
                    } else if (zuiFind(&src[j],&zval,&value)) {
                        value *= src[j].weight;
                        zunionInterAggregate(&score,value,aggregate);
                    } else {
                        break;
                    }
                }

                /* Only continue when present in every input. */
                if (j == setnum) {
                    tmp = zuiObjectFromValue(&zval);
                    znode = zslInsert(dstzset->zsl,score,tmp);
                    incrRefCount(tmp); /* added to skiplist */
                    dictAdd(dstzset->dict,tmp,&znode->score);
                    incrRefCount(tmp); /* added to dictionary */

                    if (sdsEncodedObject(tmp)) {
                        if (sdslen(tmp->ptr) > maxelelen)
                            maxelelen = sdslen(tmp->ptr);
                    }
                }
            }
            zuiClearIterator(&src[0]);
        }
    }

当然, 如果按元素数从小到大排序的第一个 sorted set 元素数为 0, 那就可以直接返回了, 随后在此 sorted set 上建立一个 Iterator, 主要就是帮助在 sorted set 上做遍历的, 因为在 sorted set 中, 遍历不是一个常用操作, 排序才是.

然后就是通过 while (zuiNext(&src[0],&zval)) 取出第一个 sorted set 中的每一个元素, 再用 for (j = 1; j < setnum; j++) 将其在每一个其他的 sorted set 中查找一遍.

当两个 sorted set 指向同一个对象是, 那么毫无疑问一定会有同样的元素. 否则就在 src[j] 中查找当前元素. zuiFind(&src[j],&zval,&value) 实现了这个操作. 具体的代码在后面分析. 如果找不到的话, 则没有必要继续找下去了, 跳出即可.

查找的过程中也使用了 zunionInterAggregate(&score,value,aggregate) 来更新当前元素的 score, 具体的 score 更新规则是根据 AGGREGATE 参数来定的.

当元素在所有的 sorted set 中时, 就可以把这个元素添加进结果的 sorted set 中了. 这里就是根据 zval 和 score 往 dstzset 里面插入元素. 因为 sorted set 里面既有 dict 也有 skiplist, 所以两个都要添加.

这里还有一个操作就是更新最大元素的长度, 这个和 sorted set 的内部优化有关.

/* https://github.com/redis/redis/blob/3.0/src/t_zset.c#L2119 */

    if (dbDelete(c->db,dstkey)) {
        signalModifiedKey(c->db,dstkey);
        touched = 1;
        server.dirty++;
    }
    if (dstzset->zsl->length) {
        /* Convert to ziplist when in limits. */
        if (dstzset->zsl->length <= server.zset_max_ziplist_entries &&
            maxelelen <= server.zset_max_ziplist_value)
                zsetConvert(dstobj,REDIS_ENCODING_ZIPLIST);

        dbAdd(c->db,dstkey,dstobj);
        addReplyLongLong(c,zsetLength(dstobj));
        if (!touched) signalModifiedKey(c->db,dstkey);
        notifyKeyspaceEvent(REDIS_NOTIFY_ZSET,
            (op == REDIS_OP_UNION) ? "zunionstore" : "zinterstore",
            dstkey,c->db->id);
        server.dirty++;
    } else {
        decrRefCount(dstobj);
        addReply(c,shared.czero);
        if (touched)
            notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,"del",dstkey,c->db->id);
    }
    zfree(src);

随后就是收尾工作. 如果目标的坑上已经有值了, 就毫不犹豫的干掉它. 然后再看作为结果的 sorted set. 如果它满足转化为 ziplist 的条件, 就可以把它转化为 ziplist. 后面是一些 hook 的通知, 可以暂时忽略. 如果结果为空, Integer reply 会返回 0, 否则会返回结果中元素的个数.

至此大致流程已经结束了. 如同推测的那样, 算法复杂度完美的反映了操作的内部过程和数据结构. 不过, 我们还有几个问题没有解决. zuiFind 中的具体操作是什么, ziplist 又是什么.

搁这搁这

这个标题充分提现了递归的思想. 学习新东西, 然后发现另一些新东西, 然后再学习这些新东西, 然后......

首先来看 zuiFind

/* https://github.com/redis/redis/blob/3.0/src/t_zset.c#L1826 */

int zuiFind(zsetopsrc *op, zsetopval *val, double *score) {
    if (op->subject == NULL)
        return 0;

    if (op->type == REDIS_SET) {
        if (op->encoding == REDIS_ENCODING_INTSET) {
            if (zuiLongLongFromValue(val) &&
                intsetFind(op->subject->ptr,val->ell))
            {
                *score = 1.0;
                return 1;
            } else {
                return 0;
            }
        } else if (op->encoding == REDIS_ENCODING_HT) {
            dict *ht = op->subject->ptr;
            zuiObjectFromValue(val);
            if (dictFind(ht,val->ele) != NULL) {
                *score = 1.0;
                return 1;
            } else {
                return 0;
            }
        } else {
            redisPanic("Unknown set encoding");
        }
    } else if (op->type == REDIS_ZSET) {
        zuiObjectFromValue(val);

        if (op->encoding == REDIS_ENCODING_ZIPLIST) {
            if (zzlFind(op->subject->ptr,val->ele,score) != NULL) {
                /* Score is already set by zzlFind. */
                return 1;
            } else {
                return 0;
            }
        } else if (op->encoding == REDIS_ENCODING_SKIPLIST) {
            zset *zs = op->subject->ptr;
            dictEntry *de;
            if ((de = dictFind(zs->dict,val->ele)) != NULL) {
                *score = *(double*)dictGetVal(de);
                return 1;
            } else {
                return 0;
            }
        } else {
            redisPanic("Unknown sorted set encoding");
        }
    } else {
        redisPanic("Unsupported type");
    }
}

先忽略掉 set 的操作, 来看 sorted set. 我们又见到了收尾工作时出现过的 ziplist.

The ziplist is a specially encoded dually linked list that is designed to be very memory efficient. It stores both strings and integer values, where integers are encoded as actual integers instead of a series of characters. It allows push and pop operations on either side of the list in O(1) time. However, because every operation requires a reallocation of the memory used by the ziplist, the actual complexity is related to the amount of memory used by the ziplist.

查了一下资料, 这是 Redis 在面对小元素时可以做的一个内存优化, 本体是一个经过特殊编码的双向链表. 经过特殊编码后的数据会变得更加紧凑, 连续的内存使用也对于缓存更加友好. 有两个配置决定了 sorted set 中使用 ziplist 的阈值.

#define REDIS_ZSET_MAX_ZIPLIST_ENTRIES 128
#define REDIS_ZSET_MAX_ZIPLIST_VALUE 64

图. 有序集合

然后我们尴尬的发现, 在 ziplist 查找一个元素实际上是一个遍历, 时间复杂度为 O(N), 如下

/* https://github.com/redis/redis/blob/3.0/src/t_zset.c#L915 */

unsigned char *zzlFind(unsigned char *zl, robj *ele, double *score) {
    unsigned char *eptr = ziplistIndex(zl,0), *sptr;

    ele = getDecodedObject(ele);
    while (eptr != NULL) {
        sptr = ziplistNext(zl,eptr);
        redisAssertWithInfo(NULL,ele,sptr != NULL);

        if (ziplistCompare(eptr,ele->ptr,sdslen(ele->ptr))) {
            /* Matching element, pull out score. */
            if (score != NULL) *score = zzlGetScore(sptr);
            decrRefCount(ele);
            return eptr;
        }

        /* Move to next element. */
        eptr = ziplistNext(zl,sptr);
    }

    decrRefCount(ele);
    return NULL;
}

不过当 zset 使用 REDIS_ENCODING_SKIPLIST 作为 encoding 的时候, 使用 Hash table 做查询的时间复杂度是 O(1) 这是肯定的.

当然, 这里面其实还有很多细节没有说到, 比如 ziplist 的内部表示, 和 zset 混在一起的 set, zset 中的 dict 和 skiplist 的详细分析等等. 下次有机会的吧.

参考资料

实现优雅的 Golang 项目结构

2021-02-19T18:10:22+08:00

随着工作经验的积累, 越来越感到仅仅写出 Elegant Code 是不够的, 特别是当多人合作开发的时候, 遇到种种结构混乱, 代码冗余, 模块耦合, 依赖耦合的问题. 这个时候, 就需要更高的要求, Elegant Project, 自顶向下的改善项目的结构.

仅仅实现业务逻辑是很容易的, 而大量的时间会用在测试, Debug 上. 一个良好定义的项目结构能够极大地提升开发效率, 降低维护成本. 下面介绍一套经过实践检验的 Go 项目结构规范.

项目结构规范

服务调用 (Service Invocation)

项目的核心调用链遵循一个清晰的层次结构:

接口定义: 服务接口在 ./domain/<service_name>/domain.go 文件中定义. 这是服务能力的抽象.
服务实现: 服务的具体实现在对应的 ./app/<service_name> 目录中完成.
Web Handler: Web Handler 实现在 ./internal/web 目录中.
调用流程: Web Handler 调用 ./domain/<service_name> 中定义的服务接口, 而非直接依赖具体实现.
复杂流程处理: 对于需要调用多个服务方法的复杂业务流程, 应该在一个专用的, 以 flow 为后缀的服务中进行编排, 而不是直接在 Web Handler 中组合.

服务包命名 (Service Package Name)

避免服务包与它操作的实体同名: 例如, 操作 User 实体的服务不应该命名为 user.
使用后缀来明确包的职责: 推荐使用 mgr, hdl, uc, svc, flow 等后缀来命名服务包, 以清晰地表达其作为服务层的角色.

服务方法签名 (Service Method Signature)

为了保持一致性和可预测性, 所有服务方法都应遵循以下签名格式:

// 标准服务方法签名
Hello(ctx context.Context, req *HelloRequest) (resp *HelloResponse, err error)

请求/响应类型: 请求和响应的结构体遵循 <MethodName>Request 和 <MethodName>Response 的命名模式.
上下文参数: 第一个参数必须是 context.Context, 用于传递请求范围的数据, 如 trace ID, 用户身份等.
错误返回: 最后一个返回值必须是 error, 用于错误处理.
命名返回值: 推荐使用命名返回值, 以增强代码的可读性.
批量获取: 对于通过 ID 批量获取数据的方法, 方法名应为 Fetch<Objects>Dict, 且响应中应包含一个名为 <Objects>Dict 的 map[<IDType>]<Object> 字段, 以方便调用方通过 ID 查找对象.

服务实现结构 (Service Implementation Structure)

一个独立服务的内部结构组织如下:

服务接口: Service 接口位于 ./domain/<service_name>/domain.go.
内部核心定义: 如有需要, 内部使用的数据结构和 Repository 接口定义在 ./app/<service_name>/internal/core/core.go, 以 core 为包名.
Repository 实现: Repository 的具体实现放在 ./app/<service_name>/internal/repo 目录中.
服务初始化: 服务的结构体和构造逻辑, 以及传入的依赖定义在 ./app/<service_name>/service.go.
服务构造函数: 服务构造函数应命名为 NewService(inj *NewServiceInj, opts ...ServiceOption) (srv *Service, err error).
业务逻辑: 核心业务逻辑实现在 ./app/<service_name> 目录下的独立文件中, 与服务构造函数分离.
Repository 构造函数: Repository 的构造函数和通用的事务逻辑 (如 (r *Repo) WithTx(...)) 应放在 ./app/<service_name>/internal/repo/repo.go 中.
Repository 操作: Repository 的具体数据库操作在 ./app/<service_name>/internal/repo 目录下的独立文件中实现, 与其构造函数分离, 以 repo 为包名.
文件命名: 业务逻辑文件应根据其主要处理的实体来命名, 清晰地反映其职责.
数据库事务边界: 数据库事务边界应定义在服务层, 而不是在 Repository 层.

服务 Mock (Service Mock)

Mock 初始化: 总是使用辅助函数 initMockService(t *testing.T) (srv *service.Service, mockInj *mockInjection) 来初始化被测试的服务及其 mock 依赖.
Mock 生成: 使用 Mockery 基于接口生成 mock 对象.
类型安全: 测试辅助函数应使用类型安全的方法调用来设置 mock 行为, 而不是依赖于基于字符串的通用方法, 如 mock.On("MethodName").

脚本 (Scripts)

通用脚本: 常用的脚本应放置在 ./script 目录中.
SQL 文件: SQL DML 和 DDL 文件应放置在 ./script/sql 目录中.

可选实现: 使用 Ent ORM

本结构规范不强制绑定任何 ORM 框架, 但如果选择使用 Ent, 可以遵循以下约定来更好地集成.

Schema 定义: Ent 的 Schema 定义在 ./internal/schema 目录中, 每个数据表对应一个文件, 如 ./internal/schema/user.go.
生成代码: Ent 生成的代码位于 ./internal/ent 目录.
实体命名: 在 Repository 层, Ent ORM 生成的对象在命名时应使用 Entity (或 Entities 用于集合) 后缀, 以明确区分它们与领域中的 core 包中的实体, 并且 Ent 生成的对象不能泄露出 repo 包.
代码生成脚本: 生成 Ent ORM 代码的脚本应位于 ./script/ent.sh.

服务调用流程图

下图展示了从接收客户端请求到与数据库交互的完整分层调用链, 它强调了接口与实现分离 (依赖倒置原则), 以及各层在项目中的位置. 这样保证了每一个层级的职责清晰, 耦合度低, 方便维护和扩展, 也方便进行单元测试和排查问题.

[ API Request ]
      |
      v
+--------------------------------+
|      Web Handler               |
|     (./internal/web)           |
+--------------------------------+
      |
      |  (依赖接口)
      v
+--------------------------------+ <----+
|      Domain Interface          |      |
|   (./domain/<service_name>)    |      | (服务之间通过接口调用)
+--------------------------------+      |
      |                                  
      |  (由 App 层实现)
      v
+--------------------------------+      |
|      App Implementation        | -----+
|    (./app/<service_name>)      |
+--------------------------------+
      |
      |  (依赖接口)
      v
+--------------------------------+
|      Repository Interface      |
|   (./app/.../internal/core)    |
+--------------------------------+
      |
      |  (由 Repo 层实现)
      v
+--------------------------------+
|      Repository Implementation |
|   (./app/.../internal/repo)    |
+--------------------------------+
      |
      v
[ Database / ORM ]

示例项目目录结构

这是一个遵循上述规范的示例项目结构. 它以一个用户注册场景为例, 其中 registrationflow 是一个复杂流程, 负责编排 authuc (认证用例) 和 notiuc (通知用例).

/
├── app/
│   ├── registrationflow/           # “用户注册”流程的实现
│   │   ├── service.go              # 定义 Service, NewService
│   │   └── registration_logic.go   # 流程编排逻辑
│   ├── authuc/                     # “认证”用例的实现
│   │   ├── internal/
│   │   │   ├── core/
│   │   │   │   ├── core.go         # 定义 IAuthRepo 使用的数据结构
│   │   │   │   └── repo_mock.go    # IAuthRepo 的 mock 实现
│   │   │   └── repo/
│   │   │       ├── repo.go         # 定义 Repo, NewRepo, WithTx
│   │   │       └── auth_repo.go    # 实现 IAuthRepo
│   │   ├── service.go              # 定义 Service, NewService
│   │   ├── auth_logic.go           # 认证业务逻辑
│   │   └── auth_logic_test.go      # 认证业务逻辑的单元测试
│   └── notiuc/                     # “通知”用例的实现
│       ├── internal/               # (可选, 如需封装 client 或定义内部结构)
│       │   └── ...
│       ├── service.go              # 定义 Service, NewService
│       └── noti_logic.go           # 通知业务逻辑 (如发邮件, 短信)
├── cmd/
│   └── server/
│       └── main.go
├── domain/
│   ├── registrationflow/
│   │   ├── domain.go               # 定义 RegistrationFlow 接口
│   │   └── service_mock.go         # RegistrationFlow 的 mock 实现
│   ├── authuc/
│   │   ├── domain.go               # 定义 AuthUseCase 接口
│   │   └── service_mock.go         # AuthUseCase 的 mock 实现
│   └── notiuc/
│       ├── domain.go               # 定义 NotiUseCase 接口
│       └── service_mock.go         # NotiUseCase 的 mock 实现
├── internal/
│   └── web/
│       ├── registration_handler.go # 处理注册流程, 调用 domain/registrationflow
│       ├── auth_handler.go         # 处理认证请求, 调用 domain/authuc
│       └── auth_handler_test.go    # 认证请求处理的单元测试
...

上述目录结构展示了一个典型的分层应用:

domain: 定义了三个核心服务接口: RegistrationFlow、AuthUseCase 和 NotiUseCase. 这是业务能力的抽象层.
app: 包含了上述接口的具体实现. registrationflow 是一个流程服务 (Flow), 它的实现会依赖 authuc 和 notiuc 的接口, 从而编排和调用这两个用例服务.
internal/web: Web Handler 层, 负责暴露服务给外部. 不同的 Handler 文件处理不同的业务, 例如 registration_handler.go 调用复杂的流程服务, 而 auth_handler.go可以直接调用简单的用例服务.
包命名: 注意所有包名都使用简短, 全小写的形式, 并且不使用下划线, 这是 Go 语言推荐的风格.
Mock 与测试:
- Mock 文件: *_mock.go 是接口的 mock 实现, 用于单元测试.
- 测试文件: *_test.go 是对应的单元测试文件.
- 依赖关系: 基于依赖倒置原则, 测试文件会使用 mock 来隔离被测试的层级.
  - app/authuc/auth_logic_test.go (业务逻辑测试) 会使用 app/authuc/internal/core/repo_mock.go 来模拟数据访问行为.
  - internal/web/auth_handler_test.go (Handler 测试) 会使用 domain/authuc/service_mock.go 来模拟业务服务行为.

总结

本规范的核心价值在于提供一个清晰一致的项目结构, 从而提升项目的可测试性和可维护性. 通过明确的分层和接口定义, 实现了以下关键的架构原则:

Monorepo 下的微服务化: 在单一代码库(Monorepo)中, 通过模块化的服务(app)和统一的接口(domain), 实现了类似微服务的开发体验. 每个服务都可以独立开发, 测试和部署, 但又能在同一个项目中轻松共享代码和配置.
支持多人协作: 清晰的边界和所有权使得多个开发团队可以并行工作, 而不会相互干扰. 每个团队可以专注于自己的服务, 并通过定义好的接口进行协作.
高可测试性: 依赖倒置原则的贯彻, 以及接口 mock 的普遍使用, 使得每个模块都可以进行独立的单元测试, 保证了代码质量和迭代速度.

参考链接

Redis LRU

2020-12-25T14:26:24+08:00

基础知识

LRU (Least recently used) 是一个非常常用的缓存置换算法.

在缓存空间有限的情况下, 在新的数据写入时, 需要淘汰一些旧数据. 一般期望最不可能被继续访问的数据淘汰. 由于无法对未来的情况进行预测, 只能基于现有的信息推测.

LRU 基于这样一个假定, 在一个时间点上, 如果一个数据距离上次被访问的时间越长, 则这个数据在未来被访问的可能性越小. 所以, 应该淘汰掉距离上次被访问的时间最久的数据.

常见的 LRU 实现是使用一个双向链表, 当 Item 被访问时, 将其移动到链表的头部. 当缓存不足时, 从链表的尾部开始淘汰.

单纯的双向链表的实现实际上是不太符合现实的. 一般的, 我们希望缓存可以尽快被检索到, 而在双向链表中检索 Item 的效率是 O(n), 特别是检索的 Item 在链表中不存在时, 效率稳定的是 O(n). 这样, 在缓存系统中维护这个双向链表的成本是非常高的. 一般的, 会将 哈希表 或者 二叉搜索树 和双向链表组合起来, 在更高效率的数据结构中记录 Key, 并在 Key 中记录 Item 在双向链表中的指针.

另外的, 在并发量较大的时候, 双向链表中的操作需要加锁, 否则链表很容易出问题.

具体实现

Redis 2.8

在较早版本的 Redis 上, 并没有实现 LRU. 在后续 2.8 添加的时候, 并没有使用常见的双向链表的方式来实现 LRU, 而使用了一个近似的实现.

从空间和时间上考虑, Redis 中的 Key 的数量可能非常的多, 双向链表可能会非常大, 占用内存非常多; 另一方面, Redis 中的操作可能也非常频繁, 每一次访问都需要操作一次双向链表, 在时间上也显得非常不划算.

Antirez 在 Redis Object 中挤出了 24 个位元 bits, 并用其存储按秒计算的 unix timestamp 的低 24 位. 这个被称为 LRU clock.

/* https://github.com/redis/redis/blob/3.0/src/redis.h#L420 */

/* A redis object, that is a type able to hold a string / list / set */

/* The actual Redis Object */
#define REDIS_LRU_BITS 24
#define REDIS_LRU_CLOCK_MAX ((1<<REDIS_LRU_BITS)-1) /* Max value of obj->lru */
#define REDIS_LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */
typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
    int refcount;
    void *ptr;
} robj;

24 个 bits 明显不够存储一个完整的时间戳, 当第二十四位向前进位的时候, 就会发生溢出. 此时, 最近被访问的 Item 的 LRU clock 反而较小, 更容易被淘汰. 考虑到这个溢出需要 194 天, 而 Redis 中的操作应该比较频繁, 所以 antirez 认为这个问题可以接受.

理论上, 可以精心构造一些数据, 让 Redis 的 LRU 失效. 比如, 总是在溢出前访问一个 Item, 这个 Item 的 LRU clock 总是很大, 虽然这个 Item 的访问周期总是 194 天才访问一次, 但是它总不会被淘汰.

/* https://github.com/redis/redis/blob/3.0/src/db.c#L43 */

robj *lookupKey(redisDb *db, robj *key) {
    dictEntry *de = dictFind(db->dict,key->ptr);
    if (de) {
        robj *val = dictGetVal(de);

        /* Update the access time for the ageing algorithm.
         * Don't do it if we have a saving child, as this will trigger
         * a copy on write madness. */
        if (server.rdb_child_pid == -1 && server.aof_child_pid == -1)
            val->lru = LRU_CLOCK();
        return val;
    } else {
        return NULL;
    }
}

接下来的问题在于如何找到最久没有被访问的 Item. 如果一定要找到最久没有被访问到的 Item, 那么需要遍历所有的 Key, 而且在遍历的过程中, 要么禁止在这期间做任何的访问操作, 要么可能出现找到的 Key 恰好又刚刚被访问到的问题.

Antirez 在这里又使用了一个近似的实现, 随机选取 3 个 Key, 把他们之中最久没有被访问到的淘汰. 随后, 这个数值变成了可配置项 maxmemory-samples , 默认值是 5. 考虑到选出的结果不一定是最好的, 但是很大可能不是一个坏的结果, 即选出一个非常近被访问的 Item, 这个实现还算可以接受.

/* https://github.com/redis/redis/blob/2.8/src/redis.c#L2982 */

/* volatile-lru and allkeys-lru policy */
else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU ||
    server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
{
    for (k = 0; k < server.maxmemory_samples; k++) {
        sds thiskey;
        long thisval;
        robj *o;

        de = dictGetRandomKey(dict);
        thiskey = dictGetKey(de);
        /* When policy is volatile-lru we need an additional lookup
          * to locate the real key, as dict is set to db->expires. */
        if (server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
            de = dictFind(db->dict, thiskey);
        o = dictGetVal(de);
        thisval = estimateObjectIdleTime(o);

        /* Higher idle time is better candidate for deletion */
        if (bestkey == NULL || thisval > bestval) {
            bestkey = thiskey;
            bestval = thisval;
        }
    }
}

Redis 3.0

Antirez 在 3.0 版本中进一步提升了近似算法的准确性. 一个显而易见的方法是, 通过过去累计的信息来提升准确性.

Redis 中维护了一个默认大小为 16 的 pool, 里面存储了备选的 Key. 当需要淘汰时, 从随机选择的 N 个 Key 中与 pool 中的 Key 做对比, 在 pool 中维护其中最久没有被访问到的 16 个 Key, 然后在 pool 中淘汰其中最久没有被访问到的 Item. 这个 pool 非常类似于小顶堆.

/* https://github.com/redis/redis/blob/3.0/src/redis.c#L3275 */

/* volatile-lru and allkeys-lru policy */
else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU ||
    server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
{
    struct evictionPoolEntry *pool = db->eviction_pool;

    while(bestkey == NULL) {
        evictionPoolPopulate(dict, db->dict, db->eviction_pool);
        /* Go backward from best to worst element to evict. */
        for (k = REDIS_EVICTION_POOL_SIZE-1; k >= 0; k--) {
            if (pool[k].key == NULL) continue;
            de = dictFind(dict,pool[k].key);

            /* Remove the entry from the pool. */
            sdsfree(pool[k].key);
            /* Shift all elements on its right to left. */
            memmove(pool+k,pool+k+1,
                sizeof(pool[0])*(REDIS_EVICTION_POOL_SIZE-k-1));
            /* Clear the element on the right which is empty
              * since we shifted one position to the left.  */
            pool[REDIS_EVICTION_POOL_SIZE-1].key = NULL;
            pool[REDIS_EVICTION_POOL_SIZE-1].idle = 0;

            /* If the key exists, is our pick. Otherwise it is
              * a ghost and we need to try the next element. */
            if (de) {
                bestkey = dictGetKey(de);
                break;
            } else {
                /* Ghost... */
                continue;
            }
        }
    }
}

pool 中排序操作的核心代码在 evictionPoolPopulate 函数中


/* https://github.com/redis/redis/blob/3.0/src/redis.c#L3145 */

#define EVICTION_SAMPLES_ARRAY_SIZE 16
void evictionPoolPopulate(dict *sampledict, dict *keydict, struct evictionPoolEntry *pool) {
    int j, k, count;
    dictEntry *_samples[EVICTION_SAMPLES_ARRAY_SIZE];
    dictEntry **samples;

    /* Try to use a static buffer: this function is a big hit...
     * Note: it was actually measured that this helps. */
    if (server.maxmemory_samples <= EVICTION_SAMPLES_ARRAY_SIZE) {
        samples = _samples;
    } else {
        samples = zmalloc(sizeof(samples[0])*server.maxmemory_samples);
    }

    count = dictGetSomeKeys(sampledict,samples,server.maxmemory_samples);
    for (j = 0; j < count; j++) {
        unsigned long long idle;
        sds key;
        robj *o;
        dictEntry *de;

        de = samples[j];
        key = dictGetKey(de);
        /* If the dictionary we are sampling from is not the main
         * dictionary (but the expires one) we need to lookup the key
         * again in the key dictionary to obtain the value object. */
        if (sampledict != keydict) de = dictFind(keydict, key);
        o = dictGetVal(de);
        idle = estimateObjectIdleTime(o);

        /* Insert the element inside the pool.
         * First, find the first empty bucket or the first populated
         * bucket that has an idle time smaller than our idle time. */
        k = 0;
        while (k < REDIS_EVICTION_POOL_SIZE &&
               pool[k].key &&
               pool[k].idle < idle) k++;
        if (k == 0 && pool[REDIS_EVICTION_POOL_SIZE-1].key != NULL) {
            /* Can't insert if the element is < the worst element we have
             * and there are no empty buckets. */
            continue;
        } else if (k < REDIS_EVICTION_POOL_SIZE && pool[k].key == NULL) {
            /* Inserting into empty position. No setup needed before insert. */
        } else {
            /* Inserting in the middle. Now k points to the first element
             * greater than the element to insert.  */
            if (pool[REDIS_EVICTION_POOL_SIZE-1].key == NULL) {
                /* Free space on the right? Insert at k shifting
                 * all the elements from k to end to the right. */
                memmove(pool+k+1,pool+k,
                    sizeof(pool[0])*(REDIS_EVICTION_POOL_SIZE-k-1));
            } else {
                /* No free space on right? Insert at k-1 */
                k--;
                /* Shift all elements on the left of k (included) to the
                 * left, so we discard the element with smaller idle time. */
                sdsfree(pool[0].key);
                memmove(pool,pool+1,sizeof(pool[0])*k);
            }
        }
        pool[k].key = sdsdup(key);
        pool[k].idle = idle;
    }
    if (samples != _samples) zfree(samples);
}

参考资料

DELL Precision T1700 SFF

2020-12-04T00:52:03+08:00

原本的台式机, E3-1231v3 搭配上在挖矿狂潮前买的 GTX 1070, 在这个普遍挤牙膏的时期感觉再战三年不成问题. 不过既然有了自己的书房, 书房里没有电脑是万万不能的. 看了一下自己的钱包~~和京东的无货~~, 决定用新平台 + 老显卡, 老平台 + 入门显卡这样的组合, 让一台电脑变成两台.

挑选过程

新平台暂且不表, 有空另外记录. 这段其实跳过也行, 都是一些流水账.

首先还是决定给老平台增加一些便携性, 毕竟性能够用就好, 租房住的生活还是要考虑搬家的, 之前的全铝加钢化玻璃机箱搬起来确实不方便. 另外, 对之前的乞丐版主板和电源也都不太满意, 但是问题最大的就是主板, LGA 1150 平台的 ITX 主板数量稀少且价格昂贵. 转换思路想一想, 机箱, 主板, 电源, 这不就是一个准系统吗.

淘宝逛了一下发现, 主要是 DELL 和 HP 的 SFF (Small Form Factor) 型准系统比较符合需求. 主要型号包括 DELL OptiPlex 3020, DELL OptiPlex 7020, DELL OptiPlex 9020, DELL Precision T1700, HP ProDesk 400 G1, HP ProDesk 600 G1, HP ProDesk 800 G1, HP Z230. 同系列的产品很好比较, 数字越大约好, 不过其实也没太大区别. HP 的机器相比 DELL 的稍微大一些, 扩展性稍强.

DELL Precision T1700 在以上型号中脱颖而出的原因可能就是因为它是 Workstation 和 C226 主板芯片组~~和它不属于搞的人头晕的家族式型号~~吧.

系统介绍

尺寸: 290.00mm * 92.60mm * 312.00mm
体积: 8.38L
重量: 5.30KG
电源输出: 255W

图. 机箱前面板

体积完全可以称得上小巧. C226 主板可以让 LGA 1150 的 E3-1231v3 和 DDR3 的两条内存条发挥余热~~和体验工作站主板~~. 支持一张半高显卡可以在 E3-1231v3 没有核心显卡和一定的游戏需求中找到一个能用的解决方案.

硬件配置

CPU: Intel Xeon E3-1231 v3 @ 3.40GHz 4C8T
RAM: G.SKILL 8G 1600MHz (x2)
GPU: NVIDIA GeForce GTX 1650 4G
SSD: GLOWAY STK240GS3-S7
Wi-Fi: Intel Dual Band Wireless-AC 7265

其余诸如主板, 机箱, 电源, 散热器都是准系统自带的.

由于显卡必须要 单槽位 的半高显卡, 所以这块 翔升 GTX1650 4GD5 战刀 应该是目前(2020-11-01)能买到的~~现在已经买不到了, 刚看了一下~~最强的显卡了.

图. 但是长的有点丑

其余配件就都是从老机器上拆下来的了, 唯一有点例外的是无线网卡, 因为是 PCIe 网卡, 之前是全高挡板, 淘宝算上邮费 7 块钱买了个半高挡板解决. 从北京快递过来邮费只要 4 块钱, 我也是惊了.

装机体验

图. 机箱后面板

小小机身拥有前置 4 个 USB 加后置 6 个 USB, 数量惊人. 甚至还带了 PS/2 键鼠接口和 RS-232 串行接口. 显示输出带了两个 DP 和一个 VGA 这对新老搭档, 缺少中青代的 HDMI 和 DVI 可能会有点不便. ~~用独立显卡就无所谓了.~~

机箱完全是免螺丝拆装的, 维护性很好. 机箱内部有大量塑料的部分, 主要起调整风道和固定的作用. 电源和前面板风扇从前面板下方吸风, 从机箱后部排出热风.

图. 机箱内部

虽然主板上有三个 SATA 接口, 但实际上只有一个标准的硬盘供电, 凑合着和一个非标准的光驱供电一起从主板上引出, 所以想要使用超过一个硬盘要想想办法, 可以使用一转二的硬盘供电什么的.

如果使用单个固态硬盘的话, 直接把固态硬盘塞到那个 3.5 寸机械硬盘位就好了, 不过有机械硬盘的话, 固态硬盘就不太好安放了, 好在空间还算多, 固态硬盘也很坚强, 找个地方塞一下问题不大.

图. 凌乱的内部

非标准的电源只有 255W, 而且只有一个 8pin 的主板供电和一个 4pin 的 CPU 供电, 没有任何 PCIe 供电. 不过反正半高显卡也基本都是能被 PCIe 16X 的 75W 供电满足的.

四个标准台式机内存插槽够用, 给已经成为时代的眼泪的 DDR3 内存找一个家. 插槽上有清晰的编号, 按照顺序插上即可.

主板提供了两个 PCIe 插槽, 一个全长 x16, 另一个是 x4. 但是问题是 16x 的反而 4x 的下面, 而且距离再下面的电源很近, 所以要想让显卡充分发挥只能用单槽位的. 不过这块 翔升 GTX1650 4GD5 战刀 是涡轮散热, 从显卡顶端的风扇吸风到尾部排出, 和机箱原有的前面板风扇风道一致, 散热应该还好. 有机友反馈显卡太长会挡住部分 SATA 接口, 这块显卡因为更短了, 所以没有这个情况.

主板上真的是一个多余的接口都没有, 导致 PCIe 无线网卡蓝牙功能所需的 USB 插头无处安放. 好吧, 小问题.

机箱还有一个内置的小音响, 虽然音质什么的只能说是听个响, 甚至还不怎么响, 但是应急什么的还是挺好用的.

原配的散热器是全铝的, 之前甚至都没见过这么寒酸的散热器. 在万能的淘宝上发现了可用的铜芯散热器 J9G15, 据商家所说是原配给更高端的 XE2 机型的散热器, 比全铝的重了有 90 克. 花费 46.8 入手一只换上, 感觉温度确实下降了不少.

图. 机箱大小参考

参考资料

[翻译] Kubernetes 网络模型指南

2019-10-28T18:55:42+08:00

英文原文

Kubernetes 旨在在一组机器上运行分布式系统。分布式系统的本质使网络成为 Kubernetes 部署中的核心且必要的部分，了解 Kubernetes 网络模型将使你能够正确地运行，监控和排查在 Kubernetes 上运行的应用程序。

网络是一个拥有许多成熟技术的广阔领域。对于不那么熟悉这个领域的人来说，这可能会令人感到不适，因为大多数人已经对网络有了先入为主的观念，而在 Kubernetes 中有很多新旧概念需要理解并将它们融合为一个整体。一个粗略的列表可能包括诸如网络命名空间，虚拟接口，IP 转发和网络地址转换之类的技术。本指南旨在通过讨论各种 Kubernetes 依靠的技术以及对这些技术是如何用来实现 Kubernetes 网络模型的描述来讲解 Kubernetes 网络模型。

本指南相当长，分为几个部分。我们首先讨论一些基本的 Kubernetes 术语以确保在整个指南中正确使用术语，然后讨论 Kubernetes 的网络模型以及它规定的设计和实现决策。接下来是本指南中最长且最有趣的部分：通过几种不同的用例深入讨论流量是如何在 Kubernetes 中被路由的。

如果您对一些网络术语，本指南附有网络术语词汇表。

1 Kubernetes 基础知识

Kubernetes 是由一些核心概念构建而成的，这些核心概念被组合成越来越强大的功能。本节列出了这些概念，并提供了简要概述以帮助促进讨论。Kubernetes 的功能远不止这里列出的内容，本节作为入门使读者可以在后续部分中参考。如果您已经熟悉 Kubernetes，请随意跳过本节。

1.1 Kubernetes API 服务器

在 Kubernetes 中，一切都是由 Kubernetes API 服务器 (kube-apiserver) 提供的 API 调用。API 服务器是通往维护着应用程序集群的所需状态的 etcd 数据存储的网关。要更新 Kubernetes 集群的状态，您需要对 API 服务器进行 API 调用以描述所需的状态。

1.2 Controllers

Controller 是用于构建 Kubernetes 的核心抽象概念之一。在使用 API 服务器声明集群的期望状态后，Controller 将通过持续监视 API 服务器的状态并对所以变化做出反应来确保集群的当前状态与期望状态相匹配。Controller 使用一个简单的循环进行操作，该循环不断地根据群集当前状态对比群集的期望状态。如果存在任何差异，则控制器执行任务以确保当前状态与期望状态符合。用伪代码来表示：

while true:
  X = currentState()
  Y = desiredState()

  if X == Y:
    return  # Do nothing
  else:
    do(tasks to get to Y)

例如，当您使用 API 服务器创建新的 Pod 时，kube-scheduler (一个 Controller) 会注意到更改，并决定 Pod 部署在群集中的位置。然后，它使用 API 服务器 (由 etcd 支持) 写入状态变更。然后，kubelet (另一个 Controller) 会注意到新的更改，并建立所需的网络功能以使 Pod 在群集中可达。在这里，两个不同的控制器对两个不同的状态更改做出反应，以使集群的实际状况与用户的意图相匹配。

1.3 Pods

Pod 相当于 Kubernetes 中的原子 - 用于构建应用程序的最小可部署对象。单个 Pod 代表集群中正在运行的工作负载，并封装一个或多个 Docker 容器，任何必需的存储以及一个唯一的 IP 地址。组成 Pod 的容器在设计上是协同的，并在同一机器上进行调度。

1.4 Nodes

Node 是运行 Kubernetes 集群的机器。它们可以是裸机，虚拟机或其他东西。主机 (Host) 一词通常与 Node 交替使用。我会尽量使用一致的术语 Node，但有时会根据上下文使用虚拟机 (Virtual Machine) 一词来指代节点。

2 Kubernetes 网络模型

Kubernetes 对 Pods 的联网方式做出了固执的选择。特别的，Kubernetes 对所有的网络实现都作出了以下要求：

所有 Pod 都可以与所有其他 Pod 通信而无需使用网络地址转换 (NAT)
所有 Node 都可以在没有 NAT 的情况下与所有 Pod 通信
Pod 所见的它的 IP 就是其他 Pod 看到的它的 IP

由于这些约束，我们现在有四个不同的联网问题需要解决：

Container 到 Container 网络
Pod 到 Pod 网络
Pod 到 Service 网络
Internet 到 Service 网络

指南剩下的部分将会依次讨论这些问题及其解决方法。

3 Container 到 Container 网络

通常，我们将虚拟机中的网络通信视为直接与以太网设备进行交互，如图 1 所示。

图1. 以太网设备的理想状况

在现实中，情况更加微妙。在 Linux，每个运行中的进程通过网络命名空间进行通信，网络命名空间拥有它自己的路由规则、防火墙规则和网络设备。本质上，一个网络命名空间为命名空间内的所有进程提供了一个全新的网络栈。

Linux 用户可以用 ip 命令创造网络命名空间。例如，下面的命令创建了一个新的网络命名空间 ns1。

$ ip netns add ns1

当命名空间被创建时，它的挂载点 /var/run/netns 随之创建。这样即使没有进程归属于它也可以持久化。

你可以通过列出 /var/run/netns 挂载点来列出可用的命名空间，或者用 ip 命令。

$ ls /var/run/netns
ns1
$ ip netns
ns1

默认的，Linux 将所有进程分配给 root 网络命名空间来提供外部访问，如图 2。

图2. Root 网络命名空间

对于 Docker 的结构来说，一个 Pod 是一组共享同一网络命名空间的 Docker 容器。同一 Pod 中的容器拥有网络命名空间分配给 Pod 的相同的 IP 地址和端口范围，并且可以通过 localhost 找到各自，因为他们在同一命名空间内。我们为虚拟机中的每一个 Pod 创建网络命名空间。在 Docker 的实现中，一个 "Pod 容器" 打开网络命名空间，然后用户指定的 "app containers" 通过 Docker 的 –net=container: 功能加入这个网络命名空间。图 3 展示了多个容器 (ctr*) 组成的 Pod 在共享的命名空间的情景。

图3. 每个 Pod 一个网络命名空间

同一个 Pod 中的应用程序同样拥有共享卷的访问权，根据 Pod 的定义, 共享卷可挂载到每个应用程序的文件系统。

4 Pod 到 Pod 网络

在 Kubernetes 中，每个 Pod 都拥有真正的 IP 地址而且可以通过这个 IP 地址与别的 Pod 通信。当前需要理解 Kubernetes 是如何使 Pod 到 Pod 通信通过真正的 IP，无论 Pod 是在同一台物理 Node 上还是集群中的不同 Node 上。我们从假设 Pod 在相同的机器上开始讨论，避免 Node 之间通信在内部网络之外的复杂情况。

对于 Pod 来说，它在其命名空间中尝试去和在同一 Node 上不同网络命名空间通信。幸运的，命名空间可以通过 Linux Virtual Ethernet Device，或通过由两个虚拟接口组成的可以扩展到多个网络命名空间的 veth pair 连接。为了连接 Pod 的命名空间，我们可以把 veth pair 的一端连接到 root 网络命名空间，另一端连接到 Pod 的网络命名空间。Veth pair 像跳线一样工作，连接两端使流量可以流通。这一步可以重复直到其数目和机器上的 Pods 一样多。图 4 展示了 veth pair 连接了所有 Pod 到 VM 的 root 命名空间的情况。

图4. 每个 Pod 均有 veth pair

现在，我们建立了有独立网络命名空间的 Pod，让他们相信他们拥有他们自己的以太网设备和 IP 地址，然后他们连接到了 Node 的 root 命名空间上。现在，我们想让 Pod 通过 root 命名空间和彼此通信，为此我们使用网桥。

Linux 以太网网桥是一个用来连接两个或以上网段的虚拟的 2 层网络设备，透明地工作在两个网络上使其相连。网桥维护一个来源和目标的转发表，通过检测经过它的数据包的目的地来决定它是否将数据包传递给别的连接到桥上的网段。网桥码通过查找网络中以太网设备唯一的 MAC 地址来决定了是否桥接数据或将其丢弃。

网桥实现了 ARP 协议来发现链路层 MAC 地址关联的 IP 地址的。当数据帧被网桥接收时，网桥向所有连接的设备 (除了原发送者) 广播帧，响应的设备被存入查询表。之后带有相同 IP 地址的流量将会使用查询表来查找转发的正确 MAC 地址。

图5. 通过网桥连接命名空间

4.1 包的生命周期：同一 Node 上 Pod 到 Pod

已有将 Pod 隔离到其网络堆栈的网络名称空间，将每个命名空间连接到 root 命名空间的虚拟以太网设备，和将命名空间连接在一起的网桥，我们终于准备好在同一 Node 上的 Pod 之间发送流量了。图 6 演示了这个过程。

图6. 包在同一个 Node 上 Pod 之间传递

在图 6 中，容器 1 将数据包发送到其自己的以太网设备 eth0，该设备作为容器的默认设备。对于 Pod1，eth0 通过虚拟以太网设备连接到 root 命名空间 veth0 (1)。配置网桥 cbr0 连接到网段 veth0。数据包到达网桥后，网桥使用 ARP 协议将其解析到其正确的目标网段 veth1 (3)。当数据包到达虚拟设备 veth1 时，它将直接被转发到 Pod2 的命名空间和该命名空间中的 eth0 设备 (4)。在整个流量流中，每个 Pod 仅与 localhost 上的 eth0 通信，并且流量被路由到正确的 Pod。对于这个网络的使用，我们的经验是它符合开发人员期望的默认行为。

Kubernetes 的网络模型要求 Pod 必须通过其在跨 Node 中的 IP 地址才能访问。也就是说，一个 Pod 的 IP 地址始终对网络中的其他 Pod 可见，并且每个 Pod 所见的自己的 IP 地址都与其他 Pod 所见一致。现在，我们转向在不同 Node 上的 Pod 之间路由流量的问题。

4.2 包的生命周期：不同 Node 上 Pod 到 Pod

在确定了如何在同一 Node 上的 Pod 之间路由数据包之后，我们转向在不同 Node 上的 Pod 之间路由流量。Kubernetes 网络模型要求 Pod IP 在整个网络上可达，但是它没有指定必须如何完成。实际上，这是基于特定于网络的，但是已有一些模式被建立起来以简化此过程。

通常，群集中的每个节点都分配有一个 CIDR 块，该块指定了该 Node 上运行的 Pod 可用的 IP 地址。一旦发往 CIDR 块的流量到达 Node，则 Node 有责任将流量转发到正确的 Pod。图 7 说明了两个 Node 之间的流量流，假设网络可以将 CIDR 块中的流量路由到正确的 Node。

图7. 包在不同 Node 上的 Pod 之间传递

图 7 从与图 6 相同的请求开始，除了目标 Pod (以绿色突出显示) 与源 Pod (以蓝色突出显示) 位于不同的 Node 上。数据包首先通过 Pod1 的以太网设备发送，该设备与 root 命名空间中的虚拟以太网设备配对 (1)。数据包最终到达 root 名称空间的网桥 (2)。ARP 将在网桥上失败，因为没有任何匹配数据包 MAC 地址的设备连接到网桥。网桥在失败时会将数据包送出默认路由 - root 命名空间 eth0 设备。此时，路由离开节点并进入网络 (3)。现在我们假设网络可以根据分配给 Node 的 CIDR 块将数据包路由到正确的 Node (4)。数据包进入目标 Node 的 root 命名空间 (VM 2 上的 eth0)，然后通过网桥路由到正确的虚拟以太网设备 (5)。最后，通过流经 Pod4 命名空间中的虚拟以太网设备对来完成路由 (6)。一般而言，每个 Node 都知道如何将数据包传递到其中运行的 Pod。数据包到达目标 Node 后，数据包的流动方式与在同一 Node 上的 Pod 之间路由流量的方式相同。

我们省略了一步，即如何配置网络以将 Pod IP 的流量路由到负责这些 IP 的正确的 Node。这是特定于网络的，不过通过研究相关特例也可以提供其所涉及问题的一些见解。例如，对于 AWS，Amazon 为 Kubernetes 维护了一个容器网络插件，该插件通过容器网络接口 (CNI) 插件使在 Amazon VPC 环境中的 Node 到 Node 网络成为可能。

容器网络接口 (CNI) 提供了用于将容器连接到外部网络的通用 API。作为开发人员，我们想知道 Pod 可以使用 IP 地址与网络通信，并且我们希望此操作的机制透明。由 AWS 开发的 CNI 插件试图满足这些需求，同时通过 AWS 提供的现有 VPC，IAM 和安全组功能提供安全且可管理的环境。解决方案是使用弹性网络接口。

在 EC2 中，每个实例都绑定到一个弹性网络接口 (ENI)，并且所有 ENI 都连接在 VPC 内 - ENI 可以相互访问，而无需付出额外的代价。默认情况下，每个 EC2 实例都部署有一个 ENI，但是您可以随意创建多个 ENI 并将它们部署到您认为合适的 EC2 实例中。用于 Kubernetes 的 AWS CNI 插件利用这种灵活性，为部署到 Node 的每一个 Pod 创建一个新的 ENI。由于 VPC 中的 ENI 已经连接到了现有的 AWS 基础设施，因此，每个在 VPC 中 Pod 的 IP 地址都是本地可寻址的。将 CNI 插件部署到群集后，每个 Node (EC2 实例) 都会创建多个弹性网络接口，并为这些实例分配 IP 地址，从而为每个 Node 形成一个 CIDR 块。部署 Pod 时，作为 DaemonSet 部署到 Kubernetes 集群的小型二进制文件会收到所有的来自 Node 本地 kubelet 进程的将 Pod 添加到网络的请求。该二进制文件从 Node 的可用 ENI 池中选择一个可用 IP 地址，并通过在 Linux 内核中连接虚拟以太网设备和网桥，将其分配给 Pod，如在同一节点内将 Pod 联网时所述。有了这个，Pod 流量就可以在集群中跨 Node 进行路由。

5 Pod 到 Service 网络

我们已经展示了如何在 Pod 及其关联的 IP 地址之间路由流量。这非常有效，直到我们需要应对变化。Pod IP 地址不是持久性的，并且会出现和消失，以应对规模扩大和缩小，应用程序的崩溃或节点重新启动。每一个这些事件都可以使 Pod IP 地址更改而不会发出任何警告。内置在 Kubernetes 的 Service 用以解决此问题。

Kubernetes 的 Service 管理一组 Pod 的状态，使您可以跟踪随时动态变化的一组 Pod IP 地址。Service 充当 Pod 的抽象，并为一组 Pod IP 地址分配一个虚拟 IP 地址。寻址到 Service 的虚拟 IP 的任何流量都将被路由到与虚拟 IP 关联的 Pod 集。这允许与 Service 关联的 Pod 集随时更改 - 客户端只需要了解 Service 的不变的虚拟 IP。

创建新的 Kubernetes Service 时，将为您创建一个新的虚拟 IP (也称为群集 IP)。在群集中的任何位置，寻址到虚拟 IP 的流量将负载均衡到与该 Service 关联的一组后端 Pod。实际上，Kubernetes 会自动创建并维护一个集群内的分布式负载均衡器，该负载均衡器会将流量分发到与 Service 相关联的健康 Pod。让我们仔细看看它是如何工作的。

5.1 netfilter 和 iptables

为了在群集内执行负载平衡，Kubernetes 依赖于 Linux 内置的网络框架 netfilter。Netfilter 是一个 Linux 提供的网络框架，允许通过定制的 handler 来实现一系列网络相关的操作。Netfilter 提供了用于数据包过滤，网络地址转换和端口映射的各种功能和操作，这些功能和操作满足了网络中数据包重定向所需，并提供了禁止数据包到达计算机网络内敏感位置的功能。

Iptables 是一个用户空间程序，它提供一个基于表的系统，用于定义使用 netfilter 框架操作和转换数据包的规则。在 Kubernetes 中，iptables 规则由监视 Kubernetes API 服务器更改的 kube-proxy Controller 配置。当对 Service 或 Pod 的更改更新了 Service 的虚拟 IP 地址或 Pod 的 IP 地址时，将更新 iptables 规则以将针对 Service 的流量正确路由到后端 Pod。Iptables 规则监视发往 Service 的虚拟 IP 的流量，并在匹配项中从可用 Pod 的集合中选择一个随机的 Pod IP 地址，并且 iptables 规则将数据包的目标 IP 地址从服务的虚拟 IP 更改为选中的 Pod 的 IP。随着 Pod 的规模扩大和缩小，iptables 规则集将更新以反映集群的变化状态。换句话说，iptables 在计算机上已通过将定向到 Service IP 的流量定向到实际 Pod 的 IP 完成了负载均衡，以。

在反过来的路径上，IP 地址来自目标 Pod。在这种情况下，iptables 再次重写 IP 头，用 Servicce 的 IP 替换 Pod 的 IP，使 Pod 认为它一直在与 Service 的 IP 进行通信。

5.2 IPVS

Kubernetes 的最新版本 (1.11) 包括集群负载均衡的第二个选项：IPVS。IPVS (IP 虚拟服务器) 也建立在 netfilter 之上，并作为 Linux 内核的一部分实现传输层负载均衡。IPVS 已集成到 LVS (Linux 虚拟服务器) 中，在主机上运行，并充当真实服务器集群前面的负载均衡器。IPVS 可以将基于 TCP 和 UDP 的服务的请求定向到真实服务器，并使由多台服务器组成的服务表现为在单个 IP 地址上的虚拟服务。这使得 IPVS 非常适合 Kubernetes Services。

声明 Kubernetes Service 时，可以指定是否要使用 iptables 或 IPVS 完成集群负载均衡。IPVS 专为负载均衡而设计，并使用更有效的数据结构 (哈希表)，与 iptables 相比，几乎可以无限扩展。创建使用 IPVS 负载均衡的 Service 时，会发生三件事：在 Node 上创建一个虚拟 IPVS 接口，将 Service 的 IP 地址绑定到该虚拟 IPVS 接口，并为每个 Service IP 地址创建 IPVS 服务器。

将来，IPVS 有望成为群集内负载均衡的默认方法。这个更改仅影响群集内负载均衡，在本指南的其余部分中，您可以使用 IPVS 安全地将 iptables 替换为群集内负载平衡，而不会影响其余的讨论。现在，让我们看一下通过群集内负载平衡 Service 的数据包的生命周期。

5.3 包的生命周期：Pod 到 Service

图8. 数据包在 Pod 和 Service 间移动

在 Pod 和 Service 之间路由数据包时，旅程以与以前相同的方式开始。数据包首先通过附加到 Pod 网络名称空间 (1) 的 eth0 接口离开 Pod。然后，它通过虚拟以太网设备到达网桥 (2) 。在网桥上运行的 ARP 协议不了解服务，因此它通过默认路由 eth0 (3) 传送数据包。在这里，发生了一些不同的事情。在被 eth0 接受之前，该数据包已通过 iptables 进行过滤。收到数据包后，iptables 会使用 kube-proxy 安装在节点上的规则来响应 Service 或 Pod 事件，将数据包的目标从 Service IP 重写到特定的 Pod IP (4) 。现在，该数据包将到达 Pod 4，而不是服务的虚拟 IP。iptables 充分利用了 Linux 内核的 conntrack 实用程序，以记住做出的 Pod 选择，以便将来的流量被路由到相同的 Pod (除非有任何扩展事件) 。本质上，iptables 直接在节点上完成了集群负载平衡。然后，使用我们已经检查过的 Pod 到 Pod 路由，流量流向 Pod (5)。

5.4 包的生命周期：Service 到 Pod

图9. 包在 Service 和 Pod 之间移动

接收到此数据包的 Pod 将做出响应，将源 IP 标识为自己的 IP，将目标 IP 标识为最初发送该数据包的 Pod (1) 。进入节点后，数据包流经 iptables，后者使用 conntrack 记住其先前所做的选择，并将数据包的源重写为服务的 IP，而不是 Pod 的 IP (2) 。数据包从这里流过网桥，到达与 Pod 的命名空间配对的虚拟以太网设备 (3) ，再到我们之前所见的 Pod 的以太网设备 (4) 。

5.5 使用 DNS

Kubernetes 可以选择使用 DNS，以避免必须将服务的群集 IP 地址硬编码到您的应用程序中。Kubernetes DNS 作为在群集上计划的常规 Kubernetes 服务运行。它配置在每个节点上运行的 kubelet，以便容器使用 DNS 服务的 IP 来解析 DNS 名称。为群集中定义的每个服务 (包括 DNS 服务器本身) 分配一个 DNS 名称。DNS 记录根据您的需要将 DNS 名称解析为服务的群集 IP 或 POD 的 IP。SRV 记录用于指定运行服务的特定命名端口。

一个 DNS Pod 由三个独立的容器组成：

kubedns: 监视 Kubernetes 主服务器的服务和端点更改，并维护内存查找结构以服务 DNS 请求。
dnsmasq: 添加 DNS 缓存以提高性能。
sidecar: 提供单个运行状况检查端点，以执行 dnsmasq 和 kubedns 的运行状况检查。

DNS Pod 本身作为 Kubernetes 服务公开，具有静态群集 IP，该 IP 在启动时传递给每个正在运行的容器，以便每个容器都可以解析 DNS 条目。DNS 条目通过 kubedns 系统解析，该系统在内存中维护 DNS 表示形式。etcd 是用于群集状态的后端存储系统，而 kubedns 使用一个库，该库在必要时将 etcd 密钥值存储转换为 DNS 条目，以重建内存 DNS 查找结构的状态。

CoreDNS 的工作方式与 kubedns 相似，但其使用的插件体系结构使其更加灵活。从 Kubernetes 1.11 开始，CoreDNS 是 Kubernetes 的默认 DNS 实现。

6 从 Internet 到 Service 的网络

到目前为止，我们已经研究了如何在 Kubernetes 集群中路由流量。这一切都很好，但是不幸的是，将您的应用程序与外界隔离将无助于实现任何销售目标——在某个时候，您将需要向外部流量公开您的服务。这种需求突出了两个相关的问题： (1) 将来自 Kubernetes 服务的流量发送到 Internet (Egress) ，以及 (2) 将来自 Internet 的流量发送到您的 Kubernetes Service (Ingress) 。本节依次阐述这些问题。

6.1 Egress — 将流量路由到 Internet

从节点到公共 Internet 的流量路由是特定于网络的，并且实际上取决于网络配置为发布流量的方式。为了使本节更具体，我将使用 AWS VPC 讨论任何特定细节。

在 AWS 中，Kubernetes 集群在 VPC 内运行，其中为每个节点分配了一个私有 IP 地址，该地址可从 Kubernetes 集群内访问。要使流量可以从群集外部访问，请将 Internet 网关连接到 VPC。Internet 网关有两个目的：在 VPC 路由表中为可路由到 Internet 的流量提供目标，并为已分配了公共 IP 地址的任何实例执行网络地址转换 (NAT) 。NAT 转换负责将群集专用的节点内部 IP 地址更改为公用 Internet 上可用的外部 IP 地址。

有了 Internet 网关后，VM 可以自由地将流量路由到 Internet。不幸的是，这里有一个小问题。Pod 拥有自己的 IP 地址，该 IP 地址与托管 Pod 的节点的 IP 地址不同，并且 Internet 网关上的 NAT 转换仅适用于 VM IP 地址，因为它不了解哪些 Pod 在哪些 VM 上运行——网关不感知容器。让我们看看 Kubernetes 如何使用 iptables (再次) 解决这个问题。

6.1.1 包的生命周期：Node 到 Internet

图10. 将数据包从 Pod 路由到 Internet

在下图中，数据包起源于 Pod 的名称空间 (1) ，并经过与根名称空间 (2) 连接的 veth 对。一旦进入根名称空间，由于数据包上的 IP 与连接到网桥的任何网段都不匹配，数据包就会从网桥移动到默认设备。在到达根名称空间的以太网设备 (3) 之前，iptables 会处理数据包 (3) 。在这种情况下，数据包的源 IP 地址是 Pod，如果我们将源保留为 Pod，则 Internet 网关将拒绝它，因为网关 NAT 仅了解连接到 VM 的 IP 地址。解决方案是让 iptables 执行源 NAT (更改数据包源) ，以便数据包看起来是来自 VM 而不是 Pod。有了正确的源 IP，数据包现在可以离开 VM (4) 并到达 Internet 网关 (5) 。Internet 网关将执行另一个 NAT，将源 IP 从 VM 内部 IP 重写为外部 IP。最终，数据包将到达公共 Internet (6) 。在返回的过程中，数据包遵循相同的路径，并且所有源 IP 处理都被撤消，因此系统的每一层都接收其能够理解的 IP 地址：节点或 VM 级别的 VM 内部 IP，以及 Pod 命名空间内的 Pod IP。

6.2 Ingress — 将 Internet 流量路由到 Kubernetes

Ingress——将流量引入群集——是一个非常棘手的问题。同样，这是特定于您正在运行的网络的，但是通常，Ingress 分为两个可在网络堆栈的不同部分上运行的解决方案： (1) Service LoadBalancer 和 (2) Ingress 控制器。

6.2.1 4层 Ingress: LoadBalancer

创建 Kubernetes 服务时，可以选择指定一个 LoadBalancer 来配合它。云控制器提供了 LoadBalancer 的实现，该控制器知道如何为您的服务创建负载均衡器。创建服务后，它将为负载均衡器通告 IP 地址。作为最终用户，您可以开始将流量定向到负载平衡器，以开始与服务进行通信。

借助 AWS，负载均衡器可以知道其目标组中的节点，并将平衡群集中所有节点上的流量。一旦流量到达节点，先前在整个群集中为您的服务安装的 iptables 规则将确保流量到达您感兴趣的服务的 Pod。

6.2.2 包的生命周期：LoadBalancer 到 Service

图11. 从 Internet 发送到 Service 的数据包

让我们看看这在实践中是如何工作的。部署服务后，您正在使用的云提供商将为您创建一个新的负载均衡器 (1) 。因为负载平衡器不感知容器，所以一旦流量到达负载平衡器，它便会分布在组成群集的所有 VM 中 (2) 。每个 VM 上的 iptables 规则会将来自负载均衡器的传入流量定向到正确的 Pod (3) ——这些规则与创建服务期间制定的 IP 表规则相同，前面已经讨论过。从 Pod 到客户端的响应将返回 Pod 的 IP，但客户端需要具有负载均衡器的 IP 地址。如前所述，iptables 和 conntrack 用于在返回路径上正确重写 IP。

下图显示了在承载 Pod 的三个 VM 之前的网络负载平衡器。传入流量 (1) 指向服务的负载平衡器。一旦负载均衡器收到数据包 (2) ，它就会随机选择一个 VM。在这种情况下，我们病理地选择了没有运行 Pod 的 VM：VM 2 (3) 。在这里，在 VM 上运行的 iptables 规则将使用通过 kube-proxy 安装到群集中的内部负载平衡规则将数据包定向到正确的 Pod。iptables 执行正确的 NAT，并将数据包转发到正确的 Pod (4) 。

6.2.3 7层 Ingress: Ingress Controller

7 层网络 Ingress 在网络堆栈的 HTTP/HTTPS 协议范围内运行，并建立在服务之上。启用 Ingress 的第一步是使用 Kubernetes 中的 NodePort 服务类型在服务上打开端口。如果将服务的 type 字段设置为 NodePort，则 Kubernetes 主服务器将在您指定的范围内分配一个端口，并且每个节点会将该端口 (每个节点上的相同端口号) 代理到您的服务中。也就是说，使用 iptables 规则，任何定向到该节点端口的流量都将转发到该服务。这种从 Service 到 Pod 的路由遵循了我们之前在讨论从 Service 到 Pod 的流量路由时已经讨论过的相同的内部集群负载平衡模式。

要将节点的端口暴露给 Internet，请使用 Ingress 对象。Ingress 是更高级别的 HTTP 负载平衡器，可将 HTTP 请求映射到 Kubernetes Services。Ingress 方法将有所不同，具体取决于 Kubernetes 云提供商控制器如何实现它。HTTP 负载平衡器 (如 4 层网络负载平衡器) 仅了解 Node IP (而非 Pod IP) ，因此流量路由同样利用 kube-proxy 在每个节点上安装的 iptables 规则提供的内部负载平衡。

在 AWS 环境中，ALB Ingress Controller 使用 Amazon 的 7 层应用程序负载平衡器 (ALB) 提供 Kubernetes Ingress。下图详细说明了此控制器创建的 AWS 组件。它还演示了 Ingress 流量从 ALB 到 Kubernetes 集群的路由。

图12. Ingress Controller 的设计

创建后， (1) Ingress Controller 将监视来自 Kubernetes API 服务器的 Ingress 事件。当发现满足其要求的 Ingress 资源时，它将开始创建 AWS 资源。AWS 将应用程序负载平衡器 (ALB) (2) 用于 Ingress 资源。负载均衡器与用于将请求路由到一个或多个已注册节点的目标组 (Target Groups) 配合使用。(3) 在 AWS 中为 Ingress 资源描述的每个唯一的 Kubernetes 服务创建目标组。(4) 侦听器 (Listener) 是 ALB 进程，它使用您配置的协议和端口检查连接请求。Ingress 控制器为 Ingress 资源注释中详细说明的每个端口创建侦听器。最后，为 Ingress 资源中指定的每个路径创建目标组规则。这样可以确保将到特定路径的流量路由到正确的 Kubernetes 服务 (5) 。

6.2.4 包的生命周期：Ingress 到 Service

图13. 从 Ingress 发送到 Service 的数据包

流经 Ingress 的数据包的生命周期与 LoadBalancer 的非常相似。主要区别在于，Ingress 知道 URL 的路径 (允许并可以根据服务的路径将流量路由到服务) ，并且 Ingress 和 Node 之间的初始连接是通过为每个服务在 Node 上暴露的端口进行的。

让我们看看这在实践中是如何工作的。部署服务后，您正在使用的云提供商将为您创建一个新的 Ingress 负载均衡器 (1) 。由于负载平衡器不感知容器，因此，一旦流量到达负载平衡器，它将通过为您的服务通告的端口在组成您的群集 (2) 的所有 VM 中进行分配。如前所述，每个 VM 上的 iptables 规则会将来自负载均衡器的传入流量定向到正确的 Pod (3) 。从 Pod 到客户端的响应将返回 Pod 的 IP，但客户端需要具有负载均衡器的 IP 地址。如前所述，iptables 和 conntrack 用于在返回路径上正确重写 IP。

7 层负载平衡器的一个好处是它们可以识别 HTTP，因此他们知道 URL 和路径。这使您可以按 URL 路径细分服务流量。它们通常还会在 HTTP 请求的 X-Forwarded-For 标头中提供原始客户端的 IP 地址。

7 总结

本指南为理解 Kubernetes 网络模型及其如何实现常见的网络任务提供了基础。网络领域既广且深，不可能在这里涵盖所有内容。本指南应为您提供一个起点，以深入研究您感兴趣并希望了解更多的主题。每当您遇到困难时，请利用 Kubernetes 文档和 Kubernetes 社区来帮助您找到方向。

8 术语表

Kubernetes 依靠几种现有技术来构建可运行的集群。全面探索每种技术不在本指南的讨论范围内，但是本节将对每种技术进行足够详细的介绍，以供讨论时参考。您可以随意浏览本节，完全跳过本节，或者在感到困惑或需要复习时根据需要参考。

2层网络 (Layer 2 Networking)

第 2 层是提供节点到节点数据传输的数据链路层。它定义了在两个物理连接的设备之间建立和终止连接的协议，以及它们之间的流量控制协议。

4层网络 (Layer 4 Networking)

传输层通过流量控制来控制给定链接的可靠性。在 TCP/IP 中，该层指的是用于在不可靠网络上交换数据的 TCP 协议。

7层网络 (Layer 7 Networking)

应用层是离最终用户最近的层，这意味着应用层和用户都直接与软件应用程序交互。该层与实现通信组件的软件应用程序交互。通常，7 层网络指的是 HTTP。

NAT — 网络地址转换 (Network Address Translation)

NAT 或网络地址转换是将一个地址空间 IP 级别地重新映射到另一个地址空间。该映射通过在数据包在流量路由设备中传输时修改其 IP 头中的网络地址信息来实现。

基本的 NAT 是从一个 IP 地址到另一个 IP 地址的简单映射。更常见的是，NAT 用于将多个私有 IP 地址映射到一个公共暴露的 IP 地址。通常，本地网络使用私有 IP 地址空间，该网络上的路由器在该空间中被赋予一个私有地址。然后，该路由器通过一个公共 IP 地址连接到 Internet。当流量从本地网络传递到 Internet 时，每个数据包的源地址从私有地址转换为公共地址，使其看起来好像请求直接来自路由器。路由器维护连接跟踪，以将回复转发到本地网络上正确的私有 IP。

NAT 提供了一个额外的好处，即允许大型私有网络使用单个公共 IP 地址连接到 Internet，从而节省了公共使用的 IP 地址数量。

SNAT — 源网络地址转换 (Source Network Address Translation)

SNAT 仅指修改 IP 数据包源地址的 NAT 过程。这是上述 NAT 的典型行为。

DNAT — 目的网络地址转换 (Destination Network Address Translation)

DNAT 指修改 IP 数据包目的地址的 NAT 过程。DNAT 用于将位于私有网络中的服务发布到可公开寻址的 IP 地址。

网络命名空间 (Network Namespace)

在网络中，每台机器 (真实的或虚拟的) 都有一个以太网设备 (我们称之为 eth0) 。所有进出机器的流量都与该设备相关联。实际上，Linux 将每个以太网设备与一个网络命名空间相关联——这是整个网络堆栈的逻辑副本，拥有自己的路由、防火墙规则和网络设备。最初，所有进程都从 init 进程共享相同的默认网络命名空间，称为根命名空间。默认情况下，进程从其父进程继承其网络命名空间，因此，如果您不做任何更改，所有网络流量都将通过为根网络命名空间指定的以太网设备流动。

veth — 虚拟以太网设备对 (Virtual Ethernet Device Pairs)

计算机系统通常由一个或多个网络设备 (eth0，eth1 等) 组成，这些设备与负责将数据包放置到物理线路上的物理网络适配器相关联。Veth 设备是始终以互连对形式创建的虚拟网络设备。它们可以充当网络命名空间之间的隧道，以创建到另一个命名空间中物理网络设备的桥梁，但也可以用作独立的网络设备。您可以将 veth 设备视为设备之间的虚拟跳线——一端进去的东西会从另一端出来。

bridge — 网络网桥 (Network Bridge)

网络网桥是一种从多个通信网络或网段创建单个聚合网络的设备。桥接将两个独立的网络连接起来，就好像它们是一个单一的网络一样。桥接使用内部数据结构来记录每个数据包发送到的位置，作为性能优化。

CIDR — 无类别域间路由 (Classless Inter-Domain Routing)

CIDR 是一种分配 IP 地址和执行 IP 路由的方法。使用 CIDR，IP 地址由两组组成：网络前缀 (标识整个网络或子网) 和主机标识符 (指定该网络或子网上主机的特定接口) 。CIDR 使用 CIDR 表示法表示 IP 地址，其中地址或路由前缀带有一个后缀，指示前缀的位数，例如 IPv4 的 192.0.2.0/24。IP 地址是 CIDR 块的一部分，如果地址的初始 n 位与 CIDR 前缀相同，则称其属于该 CIDR 块。

CNI — 容器网络接口 (Container Network Interface)

CNI (容器网络接口) 是云原生计算基金会 (Cloud Native Computing Foundation) 的一个项目，由一个规范和用于编写插件以在 Linux 容器中配置网络接口的库组成。CNI 只关心容器的网络连接性以及在容器被删除时移除已分配的资源。

VIP — 虚拟 IP 地址 (Virtual IP Address)

虚拟 IP 地址 (VIP) 是一种软件定义的 IP 地址，不对应于实际的物理网络接口。

netfilter — Linux 的包过滤框架

netfilter 是 Linux 中的数据包过滤框架。实现此框架的软件负责数据包过滤、网络地址转换 (NAT) 和其他数据包处理。

netfilter、ip_tables、连接跟踪 (ip_conntrack, nf_conntrack) 和 NAT 子系统共同构成了该框架的主要部分。

iptables — 包处理工具

iptables 是一个允许 Linux 系统管理员配置 netfilter 及其存储的链和规则的程序。IP 表中的每个规则都由多个分类器 (iptables 匹配) 和一个连接的动作 (iptables 目标) 组成。

conntrack — 连接跟踪

conntrack 是建立在 Netfilter 框架之上的用于处理连接跟踪的工具。连接跟踪允许内核跟踪所有逻辑网络连接或会话，并将每个连接或会话的数据包定向到正确的发送方或接收方。NAT 依赖此信息以相同的方式转换所有相关数据包，而 iptables 可以使用此信息充当有状态的防火墙。

IPVS — IP 虚拟服务器 (IP Virtual Server)

IPVS 作为 Linux 内核的一部分实现传输层负载均衡。

IPVS 是一个类似于 iptables 的工具。它基于 Linux 内核的 netfilter 钩子函数，但使用哈希表作为底层数据结构。这意味着，与 iptables 相比，IPVS 重定向流量的速度要快得多，在同步代理规则时性能要好得多，并提供更多的负载均衡算法。

DNS — 域名系统 (The Domain Name System)

域名系统 (DNS) 是一种用于将系统名称与 IP 地址关联的分散式命名系统。它将域名转换为数字 IP 地址，以便定位计算机服务。

Oh MySQL Emoji

2019-10-14T11:12:33+08:00

又是关于 MySQL 的, 标题来自于 <轮到你了> 这部烂尾日剧, 里面非常魔性的 Oh~my~Ju~lia~

在MySQL里面如何保存 Emoji, 这个问题搜一搜很容易找到答案, 设置 CHARSET 为 utf8mb4, 看来天下苦 MySQL 久矣.

基础知识

计算机最早是美国人发明的, 那时的编码都是 ASCII 码, 毕竟英文字符加上标点符号也就那么多嘛, 一个字节绰绰有余.

但是随着计算机的发展, 计算机面向的国家和语言越来越多, 一个字节根本不够用了, 于是就有了很多面向特定语言的编码, 比如汉字的GBK, Big5, 韩文的 EUC-KR, 日文的 Shift_JIS 什么的. 总体思想是, 既然一个字节不够用, 那就多几个字节就是了嘛.

但是问题又出现了, 同一个编码在不同语言中会有不同的含义,比如韩文编码 EUC-KR 中 한국어 的编码值正好对应着汉字编码 GBK 中的 茄惫绢. 还有那个著名的 瓣B变巨肚, 也正是同样的原因. 这样仿佛就变成了巴别塔的故事. 人们虽然用着同样的二进制编码, 但是却表达着不同的意思; 就像人们虽然同样发出声带的震动, 但是却无法互相理解对方的话语.

国际标准化组织和统一码联盟意识到, 这样下去是不行的, 不如搞一个超大的字符集, 然后把人类所有字符都弄进去, 这样人类都可以用同一个标准了. 于是, 他们分别制定了 USC 和 Unicode. 当然, 如果两个标准各搞各的, 那就和他们最初的想法背道而驰了, 所以目前这两个字符集在实际使用中是一致的. 一般还是把这个字符集叫 Unicode.

Unicode 的范围上限是 0x10FFFF, 换算成十进制就是 1,114,111 这么多. 所以如果以后外星人的文字太多, 说不定这个范围就不够了.

其实这里悄悄的偷换了一个概念, 之前在说编码, 现在变成了字符集了. 在很多之前提到的编码中, 这些编码既是字符集, 又是直接的编码. 而在 Unicode 中, 字符集实际上是与编码分开的两个概念, 而对应的编码, 实际上就是我们经常见到的 UTF. 其中 UTF-8 是我们最常见的一种编码了.

UTF-8 最大的特点, 就是它是一种变长的编码方式, 而且完全兼容 ASCII码.

UTF-8 的编码规则也很简单，只有二条:

对于单字节的符号, 字节的第一位设为0, 后面7位为这个符号的 Unicode 码. 对于 0 - 127 位的字符，UTF-8 编码和 ASCII 码是完全相同的.
对于 n 字节的符号 (n > 1) , 第一个字节的前 n 位都设为 1, 第 n + 1 位设为 0, 后面字节的前两位一律设为 10. 剩下的没有提及的二进制位, 全部为这个符号的 Unicode 码.

Unicode符号范围	UTF-8编码方式
U+0000 - U+007F	0xxxxxxx
U+0080 - U+07FF	110xxxxx 10xxxxxx
U+0800 - U+FFFF	1110xxxx 10xxxxxx 10xxxxxx
U+010000 - U+10FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

在这里我们发现, U+0000 - U+FFFF 这个平面(Plane), 即基本多文种平面, 简称 BMP, 用 UTF-8 进行编码, 只需要三个字节.

轮到你了

在 MySQL 的 CHARSET 中, utf8 支持存储 1 - 3字节的字符, 即对应 Unicode 中 BMP 的部分, 而 Emoji, 则大多数在 BMP 之外. 所以 MySQL 中的 utf8 是假的, 是化学的成分, 是加了特技的. 如果想储存真正的 UTF-8 的内容, 就一定要使用 utf8mb4.

当然, 并不是所有的 Emoji 都在 BMP 之外, 比如 ☺ 这个表情, 它的编码是 U+263A, 还有 ☹️ , 编码是 U+2639.

当然, 也不是所有的汉字都被包含在了 BMP 里面了, 在这里可以看到字符是按照一定的规律划分为 Block 放进来的, 在表意文字补充平面也就是 U+20000 - U+2FFFF 这个平面(Plane), 还是有很多 CJK 命名的 Block 的.

再来一瓶

你以为坑到这里就结束了吗

CREATE TABLE `emoji_test` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `emoji` VARCHAR(1024) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

SET NAMES utf8mb4;

MySQL [test]> SELECT * FROM emoji_test;
+----+-------+
| id | emoji |
+----+-------+
|  8 | 😃      |
|  9 | 😂      |
| 10 | 🤦      |
+----+-------+
3 rows in set (0.001 sec)

MySQL [test]> SELECT * FROM emoji_test WHERE emoji = '😂';
+----+-------+
| id | emoji |
+----+-------+
|  8 | 😃      |
|  9 | 😂      |
| 10 | 🤦      |
+----+-------+
3 rows in set (0.001 sec)

是不是很神奇呢, 看下表的信息呢

MySQL [test]> SHOW TABLE STATUS WHERE Name = 'emoji_test';
+------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
| Name       | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time | Collation          | Checksum | Create_options | Comment |
+------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
| emoji_test | InnoDB |      10 | Dynamic    |    3 |           5461 |       16384 |               0 |            0 |         0 |             11 | 2019-10-16 11:16:28 | 2019-10-16 11:25:10 | NULL       | utf8mb4_general_ci |     NULL |                |         |
+------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+--------------------+----------+----------------+---------+
1 row in set (0.001 sec)

可以看到此时默认的字符序是 utf8mb4_general_ci, 使用 WEIGHT_STRING 来查询这些 Emoji 的字符序

MySQL [test]> SET @s = '😂' COLLATE utf8mb4_general_ci;
Query OK, 0 rows affected (0.003 sec)

MySQL [test]> SELECT @s, HEX(@s), HEX(WEIGHT_STRING(@s));
+------+----------+------------------------+
| @s   | HEX(@s)  | HEX(WEIGHT_STRING(@s)) |
+------+----------+------------------------+
| 😂     | F09F9882 | FFFD                   |
+------+----------+------------------------+
1 row in set (0.001 sec)

MySQL [test]> SET @s = '😃' COLLATE utf8mb4_general_ci;
Query OK, 0 rows affected (0.001 sec)

MySQL [test]> SELECT @s, HEX(@s), HEX(WEIGHT_STRING(@s));
+------+----------+------------------------+
| @s   | HEX(@s)  | HEX(WEIGHT_STRING(@s)) |
+------+----------+------------------------+
| 😃     | F09F9883 | FFFD                   |
+------+----------+------------------------+
1 row in set (0.001 sec)

可以看到, 它们的编码虽然不同, 但是字符序的值是相同的, 都是 0xFFFD, 所以在匹配的时候, 它们被认为是同一个字符, 这又是 MySQL 的一个大坑

要是想粗暴点解决问题的话, 直接使用 utf8mb4_bin 作为字符序就好了

又来一瓶

但是这还不是结束, 当业务代码连接数据库并插入一些 Emoji 时, 还是可能遇到如下错误

ERROR 1366: Incorrect string value: '\xF0\x9D\x8C\x86' for column 'column_name' at row 1

这个是因为客户端到 MySQL 服务器的连接还是 utf8 而非 utf8mb4, 所以你需要在业务逻辑中做类似如下语句的事情

SET NAMES utf8mb4

或者修改 MySQL 的配置文件, 当然这样不太现实, 需要重启 MySQL 进程.

这样你才能终于用上 Emoji

参考资料

扩展阅读

Oh MySQL IN Subquery

2019-09-21T15:22:58+08:00

感觉 MySQL 的坑实在是有点多,记录一下这个 MySQL 的坑, 也记录一下这个教训吧, 下次在数据库中直接操作一定要多小心

现象回放

现在有两张表, 表结构如下, 无关字段已经省略

team

+-------------+---------------------+
| Field       | Type                |
+-------------+---------------------+
| id          | int(10) unsigned    |
| status      | tinyint(3) unsigned |
+-------------+---------------------+

player

+-------------+---------------------+
| Field       | Type                |
+-------------+---------------------+
| id          | int(10) unsigned    |
| team_id     | int(10) unsigned    |
| status      | tinyint(3) unsigned |
+-------------+---------------------+

容易理解, 这是简单的一对多的关系, 一个足球队 team 里面, 有多个球员 player

现在想取出有 player 的状态为 1 的 team

SELECT * FROM team WHERE id IN (SELECT id FROM (SELECT team_id FROM player WHERE status = 1) AS a);

理论上, 这条语句是不能执行的, 注意这里

...... SELECT id FROM (SELECT team_id FROM ......

但是, 不知道为何, 这条语句是可以执行的, 而且等价于

SELECT * FROM team;

如果单独把最外层的 IN 里面的 subquery 取出来, MySQL 会报错

SELECT id FROM (SELECT team_id FROM player WHERE status = 1) AS a;

ERROR 1054 (42S22): Unknown column 'id' in 'field list'

再试着把 id 改为不存在的字段

SELECT * FROM team WHERE id IN (SELECT not_exist_field FROM (SELECT team_id FROM player WHERE status = 1) AS a);

ERROR 1054 (42S22): Unknown column 'not_exist_field' in 'field list'

这样才能如预期的报错

问题排查

先 EXPLAIN 试试呢

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: team
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 2
     filtered: 100.00
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: player
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 5
     filtered: 20.00
        Extra: Using where; FirstMatch(team); Using join buffer (Block Nested Loop)
2 rows in set, 2 warnings (0.001 sec)

好像看不出来什么问题呢, 不过有 warnings, 看一下呢

SHOW WARNINGS\G

*************************** 1. row ***************************
  Level: Note
   Code: 1276
Message: Field or reference 'test.team.id' of SELECT #2 was resolved in SELECT #1
*************************** 2. row ***************************
  Level: Note
   Code: 1003
Message: /* select#1 */ select `test`.`team`.`id` AS `id`,`test`.`team`.`status` AS `status` from `test`.`team` semi join (`test`.`player`) where (`test`.`player`.`status` = 1)
2 rows in set (0.001 sec)

这里出现了一个 semi join, 没有见过呢, 查看一下文档, 大意就是, 比如使用 INNER JOIN 的时候, 会返回匹配次数个结果. 但是我们并不关注匹配的次数, 比如如下语句, 我想取出有球员的 status 为 0 的球队, 可以这样写

SELECT * FROM team INNER JOIN player ON team.id = team_id WHERE player.status = 0;

如果一个球队里有多个 status 为 0 的球员, 那么就会出现多个记录, 比如这样

+----+--------+----+---------+--------+
| id | status | id | team_id | status |
+----+--------+----+---------+--------+
|  1 |      0 |  1 |       1 |      0 |
|  1 |      0 |  2 |       1 |      0 |
|  2 |      0 |  5 |       2 |      0 |
|  2 |      0 |  6 |       2 |      0 |
+----+--------+----+---------+--------+

这样明显有些冗余的数据了. 当然我们可以用 DISTINCT 什么的再处理一遍, 但是这样效率会比较低. 那么, 就可以用类似的子查询就方便多了

SELECT * FROM team WHERE id IN (SELECT team_id FROM player WHERE status = 0);

返回的结果也简洁多了

+----+--------+
| id | status |
+----+--------+
|  1 |      0 |
|  2 |      0 |
+----+--------+

当然, 要这样优化还是有很多条件的, 林林总总的, 可以去官方文档查看

看了这么多, 感觉还是和这个问题没什么关系啊, 试着 EXPLAIN 一下正确的语句

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: team
   partitions: NULL
         type: ALL
possible_keys: PRIMARY
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 2
     filtered: 100.00
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: player
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 5
     filtered: 20.00
        Extra: Using where; FirstMatch(team); Using join buffer (Block Nested Loop)
2 rows in set, 1 warning (0.001 sec)

再看看 warnings

*************************** 1. row ***************************
  Level: Note
   Code: 1003
Message: /* select#1 */ select `test`.`team`.`id` AS `id`,`test`.`team`.`status` AS `status` from `test`.`team` semi join (`test`.`player`) where ((`test`.`player`.`team_id` = `test`.`team`.`id`) and (`test`.`player`.`status` = 1))
1 row in set (0.001 sec)

对照着实际运行的语句的 Note, 发现错误的语句缺少了以下这个条件

((test.player.team_id = test.team.id)

难道就是你! 但是为什么又有

Field or reference 'test.team.id' of SELECT #2 was resolved in SELECT #1

这个问题呢

破案

后来翻了翻文档, 发现这压根不是 MySQL 的 Bug, 而是 SQL 一条相当坑的作用域规则, 子查询里解析不了的列名, 会跑到外层查询去找.

关键还是在那个派生表 a

(SELECT team_id FROM player WHERE status = 1) AS a

它只有 team_id 一列, 根本没有 id. 于是外面那句 SELECT id FROM a 里的 id, 在 a 里是找不到的. 按照作用域规则, 内层找不到就往外层找, 而外层的 team 表恰好有 id, 所以这个 id 就被解析成了 team.id. 这也正是那条 Note 想告诉我们的

Field or reference 'test.team.id' of SELECT #2 was resolved in SELECT #1

id 变成 team.id 之后, 子查询就成了「对当前这一行 team, 返回它自己的 team.id, a 里有几行就返回几次」, 整个条件相当于

team.id IN (SELECT team.id FROM a)

只要 a 非空, 也就是全表里存在任意一个 status 为 1 的球员, 这个 IN 对每一行 team 都恒为真. 本该起作用的关联条件 player.team_id = team.id 从头到尾就没参与进来, 所以每支球队都被捞了出来, 等价于 SELECT * FROM team. 再对照前面两条 Note 里 semi join 的 where, 一个有 team_id = team.id, 一个没有, 也就说得通了.

回过头看之前那几个奇怪的现象, 也都顺理成章了

单独跑 SELECT id FROM a 会报错, 是因为没有外层可以借, id 真的无处可寻
嵌套里把 id 换成 not_exist_field 也报错, 是因为这个名字在 a 和外层 team 里都不存在
唯独 id 不报错, 只是因为它恰好是外层 team 的列, 被悄悄借走了, 报错被吃掉, 结果却全错

所以并不是 MySQL 抽风, 而是「外层恰好有个同名列」, 把一句本该报错的语句, 变成了能跑但结果完全不对的语句, 属实有点阴险.

教训还是开头那句, 在数据库里直接操作一定要多小心. 具体到这个坑, 一个好习惯是子查询里的列名都带上表名或别名, 写 a.team_id 而不是光秃秃的 id, 一旦写错会立刻报错, 而不会被外层悄悄借走. 另外, 这个规则在 DELETE FROM team WHERE id IN (SELECT id FROM ...) 里最要命, 列名一写错解析成外层的 id, 条件恒真, 整张表就没了.

参考资料

Yes

2018-12-14T23:34:15+08:00

最近看到一个有趣的 GNU/Linux 命令, yes

先 man 一下

YES(1)                    BSD General Commands Manual                   YES(1)

NAME
     yes -- be repetitively affirmative

SYNOPSIS
     yes [expletive]

DESCRIPTION
     yes outputs expletive, or, by default, ``y'', forever.

HISTORY
     The yes command appeared in 4.0BSD.

4th Berkeley Distribution        June 6, 1993        4th Berkeley Distribution
(END)

emmmmm, 在 macOS 下并没有 --help 或者 -h 的选项

试试 Linux 下呢

➜  / yes --help
Usage: yes [STRING]...
  or:  yes OPTION
Repeatedly output a line with all specified STRING(s), or 'y'.

      --help     display this help and exit
      --version  output version information and exit

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation at: <https://www.gnu.org/software/coreutils/yes>
or available locally via: info '(coreutils) yes invocation'

有了

简单来说这个命令就是可以反复的输出一个字符串, 这个字符串的默认值是 y

于是有了一些特别的用法, 比如, 注意这里没有 f

yes | rm -r /

还有

yes $(yes yes)

好孩子不要乱试

当然这个命令的效果其实一般都有替代, 比如加上 -f, -y 什么的, 生成一个大文件也可以用 /dev/urandom 来做

还可以在冬天做暖手宝, 噗

最后, 跟我一起在命令行输入

yes 'AMD, yes!'

果然人类的本质就是复读机

重新开始

2018-09-17T23:26:20+08:00

新的博客, 重新开始

这次尝试着坚持一下吧

红黑树笔记

2016-09-13T23:32:27+08:00

最近研究了一下红黑树的一些性质和思想, 在这里记录一下.

Map, 或者在 Python 等一些语言中叫做 dictionary 的常用的以键值对形式储存的数据结构一般有两种实现方式, 在 C++ 的 STL 中使用了红黑树的方式, 而在Python中使用了哈希表的方式.

一般认为采用哈希表的方式查找删除的时间复杂度为 O(1), 而红黑树为 O(logn).

Python 中的哈希表使用开放寻址法解决冲突.

对于普通的二叉查找树来说, 查找和插入的时间复杂度在最坏的情况下可能会变成 O(n), 即完全偏向一边的不平衡情况使其成为一个单链表. 如果只是在树的叶子上增加节点而不进行其他的调整, 很容易会使只向下增长的树不平衡. 为了保证 O(logn) 的时间复杂度, 我们需要一种动态的机制, 来调整树的父节点, 乃至于根节点.

红黑树是一种动态调整的实现方式. 红黑树其实是在 2, 3-树 的基础上实现的. 他们也完全可以等价的转换. 不过 2, 3-树 在程序的实现上比较复杂, 而且查找操作也和二叉搜索树有一些不同, 所以在程序实现中一般使用红黑树.

2, 3-树 和红黑树他们共同的思想是, 将树的叶子节点上的操作造成的影响, 逐步的传递给父节点, 按照一定的方式对当前子树进行调整. 父节点再传递给它的父节点, 调整更大一些的子树. 最终传递到根节点, 调整整颗树.

可以这样理解, 在红黑树中, 用红色来标记正在累计调整的节点. 当节点M的两个子节点均被标记, 则M取消子节点的标记, 并标记自己, 使调整向根节点传递.

在CentOS上使用较新的软件

2016-08-02T23:30:33+08:00

更新于 2025-02-15: IUS 官方 FAQ 已明确说明该项目不再维护, 历史软件包仅保存在 IUS Vault. 本文使用的 CentOS 6 仓库和安装命令均已失效, 请勿在新环境中继续使用; 正文仅作为历史记录保留. 新环境应选择仍受支持的操作系统版本及其官方软件源, 或软件供应方仍在维护的软件源.

公司的服务器都是 CentOS 的, 带的软件都比较旧, 让我这个不更新会死星人很难过啊.

开玩笑的, 主要问题是 git 版本太旧, clone 的时候会报错, 然后也需要 python3.5. 在 git 上面发现 ius 来解决这个问题.

ius 是一个社区项目, 目的是为 Linux 的企业发行版提供一些更新版本的RPM包.

sudo yum install epel-release
sudo yum install https://centos6.iuscommunity.org/ius-release.rpm

为了解决一些冲突和共存的问题, 有一些 package 在 ius 中的包名有一些改动

sudo yum install git2u
sudo yum install python35u

一般的命名规则是

{name}{major_version}{minor_version}u

这样就可以在 CentOS 上使用较新的软件啦.

Linux后台命令

2016-06-15T23:28:24+08:00

最近在跑 DHT 网络拟真的时候涉及到一些 linux 后台运行的一些东西,现在总结一下

例如

nohup ../src/OverSim -c ChordChurn -u Cmdenv > out.file 2>&1 &

使得 ../src/OverSim -c ChordChurn -u Cmdenv 命令在后台运行,并将 stderr 重定向到 stdout 中然后再将 stdout 重定向到 out.file, 并且在当前终端关闭时仍然运行

具体说一下吧

1 => stdout
2 => stderr
0 => stdin

其他一些命令和操作

Control+z 可以发出 SIGSTOP 信号, 使当前前台进程暂停并放入后台

fg [job_id]使进程在前台运行

bg [job_id]使进程在后台运行

jobs 查看后台进程

第一篇博客

2016-06-14T23:22:32+08:00

其实很早就想弄个博客什么的, 觉得有些东西费了很大的力气解决了, 然后久而久之就忘了......记录下来应该会好一点吧, 这样觉得.

所以还是写一些东西吧, 嗯嗯......

其实还是不太喜欢这种不怎么能自己定制的东西......总有一种不知所措的感觉......自己写一个后台倒是没什么问题, 前端的话就实在是无力了, 噗

对 Markdown 的语法还不那么熟悉, 而且好像 Markdown 有一些不同的解释器, 很麻烦啊

每次生成的静态网页还要在本地生成了之后看过效果......啊, 真的很麻烦

关于

2016-06-14T00:00:00+00:00

Gopher & Pythonista

关于博客

应该也许大概会在这里做一些技术方面的笔记 _(:_」∠)_
因为拖延症严重的不行所以可能不会经常更新......唔, 努力更新一下吧
偶尔聊聊历史, 希望可以记录一些近现代的事情, 用以存史

关于工作

现在的

開発 @株式会社ネットスターズ @东京, 日本

曾经的

中级运维开发工程师 @数说故事 @广州, 中国
后端开发工程师 @画音 @广州, 中国
后端开发工程师 @壁虎科技 @广州, 中国
Senior Engineer @BIGO @广州, 中国
Python Engineer @Akulaku @深圳, 中国
服务器端开发工程师 @猎豹移动 @珠海, 中国
Python 开发实习生 @广州中国科学院计算机网络信息中心 @广州, 中国

关于教育

学生 @暨南大学 @广州, 中国
学生 @石门中学 @佛山, 中国

链接

2016-06-14T00:00:00+00:00

LeoEatle's World