> 关于最近搭建后端报警系统的一些总结


xingpeng Oct 15th at 18:02
@channel
当前我们基于 promethues 的报警体系正在搭建，有些问题想跟大家一起讨论下：
对于报警来说，有几个比较重要的点：
- 第一是报警维度：不能什么都报，因为数量太多会淹没掉关键信息，而且会麻痹接收报警的人；也不能报的太少，不然不能及时的反馈问题。所以我们尽量做 critical 的报警，这个可以后续慢慢优化。
- 第二是报警处理流程：流程还是比较重要的，不然就会很混乱，我这里列举几点：
    - 一个报警应该发到哪里？由 SRE 接收？但 SRE 实际上还是会人肉将它路由到各项目；按项目接收？就需要能够在逻辑上对报警信息做划分，然后发到各项目组独立的 slack channel，建议这种方式，因为正好可以利用 k8s namespace 的能力，也意味着各项目要按照一定的规范将服务部署到各自项目组对应的 namespace，方便在配置路由规则的时候设置统一的正则去匹配。
    - 收到一个报警由谁来处理？一个报警大家都看到了，A 以为 B 会处理，B 以为 C 会处理，结果大家都没处理，所以就需要一个机制来对报警做 ack。建议是值班人制度，每个项目组每天或者每周换值班人，由值班人驱动报警解决。
    - 怎么标记一个报警正在被某个人处理？当前临时的方式是我们这边通过 slackbot 做了一个功能，当值班人在 slack 上收到报警后，点击 `Claim` 按钮，slackbot 会自动会开启一个 thread 并在里面回复报警由该用户认领，值班人即可在该 thread 中处理该报警。如下图：
    - 如何保证报警暴露的问题已被解决或者在项目内部和所有人都同步过？建议可能是值班人制度对报警做一个总结并向同组所有人同步。
以上是我们当前的一些想法，初步打算是按照这样去构建流程，欢迎补充和讨论。

以上是我们当前的一些想法，初步打算是按照这样去构建流程，欢迎补充和讨论


zengxian  7 days ago
补充一个目前这个提案的TLDR；下午可以线下讨论：
报警接收方式：按k8s namespace前缀划分各个业务的报警分组，每个分组有一个slack channel，该相关同事需要加入这个channel
值班制度：业务组同事轮流在channel里值班，负责跟踪每个故障，指派给相关同事解决，值班人要对每个报警的分配和关闭负责。其他同事发现业务问题的也可以人工发到channel


zengxian  3 days ago
这里讨论下值班制度和值班人责任：
```

themez commented 3 days ago
值班人责任：

- 按业务和infra划分值班人，初期先对即刻项目和infra采用轮班，其他业务松散自由安排
- 值班人值守期间必须打开相关故障群/channel的通知
- 值班人不一定直接处理故障，最重要的责任是接收和追踪故障的生命周期，需要at出解决问题的人，必要时电话联系，在故障反馈源头同步接收/处理中/已解决状态
- 其他同事无论事情大小可以随时打扰值班人
- 在故障群收到报警并确认后立即转移到其他群讨论，保证故障群敏感性

值班人工作流程：

- 在开始值班前打开#alert-业务channel和微信故障群的通知，平时留意下各个群/channel反馈的问题
- 发现监控报警/同事反馈故障，先claim
- 如果找到故障owner，确保通知他开始处理，并在相关的群里告知其他同事已经在处理了
  - 如果是不合理的报警，记录下来，告知 @xingpeng 调整报警规则
  - 对于在跟踪的故障，定时和故障owner同步处理进度，如果得到修复，在相关群/channel告知关心的同事。如果暂时无法修复，记录下来，方便后续值班同事查阅了解情况。
- 在结束值班周期后，整理值班总结，记录前面提到的误报，暂时未解决等问题，发布到ph上，通知下一个值班的同事开始新的值班周期

stanxing commented 2 days ago
我想补充一点关于报警处理原则的观点：

值班报警处理原则：

每个报警报出来肯定是需要处理的，如果某个报警报出来了，分析完之后发现不需要处理，请反馈，应该想办法绕过这个报警或者删掉（禁掉）这个报警。
遇到任何觉得不合理或欠缺的报警规则请反馈。
总结这一周（一天）的报警，比如有多少是重复问题导致的，比较难修复的问题，应该有相应的 issue 记录，不然问题就会越积越多，下个值班的人仍然会遇到。
报警优先级的定义这块当前定义的比较随意，只有 warning 和 critical，长远看不太合理，后续我在考虑用 p0 p1 p2 p3 这样的代替，按 namespace（beta，prod） + 业务（重要性）两个维度做优先级，但是不管怎样，我觉得报出来就是应该要处理的，不然就没必要报，应该选择删掉它。
```

> 一些产品分享

WangSiyuan Yesterday at 15:22
https://miro.com/
看到Medium在用这个网站，做在线协作。特点应该是实时/异步协作，有一个无限白板，也可以和非常多的网站集成，同时有视频分享。
![image.png](https://image-qiniu.jellow.site/FuaC93cniJT0g2EoAnKrbO8vwCmG.png)

大核桃  1 day ago
还有个类似产品是：https://www.mural.co/
大核桃  1 day ago
不过我觉得这类产品是figma捎带手就能做出来的，依托于性能强大的画布和协作功能

xidong  1 day ago
做得非常好啊


> 最近流行去苹果化，有同事尝试在换用windows作为主力开发本

WangSiyuan  10:55
有什么好用的windows软件和开发经验

WangSiyuan  10:57
listary不错 https://www.listary.com/ (edited) 

formula  10:58
tuneblade不错 http://www.tuneblade.com/
可以在Windows上连HomePod

WangSiyuan  10:58
https://github.com/Awesome-Windows/Awesome

panqianyu  10:58
powerToys 不错，可以勉强替代 karabiner
https://github.com/microsoft/PowerToys (edited) 

Renzh  11:22
https://jmeubank.github.io/tdm-gcc/

呆唯  11:58
现在Win本真的白菜价 

Renzh  14:08
http://www.lingoes.cn/
Lingoes 灵格斯词霸 是一款简明易用的词典与文本翻译软件，支持全球超过80多种语言的词典查询、全文翻译、屏幕取词、划词翻译、例句搜索、网络释义和真人语音朗读功能。同时还提供海量词库免费下载，专业词典、百科全书、例句搜索和网络释义一应俱全，是新一代的词典与文本翻译专家。 (edited) 
以前学新东方的时候，老师推荐的

WangSiyuan  14:12
@Renzh 你的类似alfred的是什么app呀？

Renzh  14:13
PowerToys
只用于启动，不干别的

zhangxuhui  14:14
https://u.tools/

panqianyu  14:23
感觉Windows上的终端还是hyper比较好，比ms自家的好

大核桃  14:42
https://getquicker.net/
还可以，就是UI丑

WangSiyuan  14:45
想到这个了：https://www.autohotkey.com/
非常好用

大核桃  14:46
还有经典的Everything

WangSiyuan  14:54
LinusTechTips的剪辑师的AutoHotKey脚本repo：
https://github.com/TaranVH/2nd-keyboard
他常用的script
https://www.youtube.com/watch?v=OqyQABySV8k

WangSiyuan  17:14
问一下，不同的windows之间有什么文件同步的好方案吗？不用网盘，在公网 (edited) 

panqianyu  17:19
resilio sync

WangSiyuan  17:28
这个不错
https://github.com/c0re100/qBittorrent-Enhanced-Edition
可以订阅tracker列表 (edited) 

> Node.js v15.0.0 released 

https://nodejs.medium.com/node-js-v15-0-0-is-here-deb00750f278
- AbortController
- N-API Version 7
- npm 7
- Throw on unhandled rejections
- QUIC (experimental)
- V8 8.6

> 这周有什么好笑的

![haha.png](https://image-qiniu.jellow.site/FrD5CWCguYyhkik6lZrc_7QAxvqA.png)

IFTech BE Weekly #4

国庆长假刚刚结束一周，于是又见面了。

虽然这个专栏的名字是**BE Weekly**，但实际要看近期是否有足够多有趣的东西，实际更新周期可能在两周一次，内容也不一定全是Backend领域的，比如这次就有挺多前端相关的分享和讨论。

对内容有任何想法和建议也欢迎回信来反馈呀

>虽然都知道typescript的类型系统很强大，但这个演示ts 4.1版本新特性的demo还是让人惊叹

**wong2:** GitHub - codemix/ts-sql: A SQL database implemented purely in TypeScript type annotations.
https://github.com/codemix/ts-sql

>npm cli 发布了大更新7.0，甚至直接支持了yarn.lock

**panqianyu:** https://github.blog/2020-10-13-presenting-v7-0-0-of-the-npm-cli/
The GitHub BlogThe GitHub Blog
Presenting v7.0.0 of the npm CLI - The GitHub Blog
We’re releasing v7.0.0 of the npm CLI, which includes exciting new features such as Workspaces, automatically installed peer deps, and more!
**Renzh:**
Workspaces: a set of features to the npm CLI that provide support to managing multiple packages from within a singular top-level, root package
package-lock v2 and support for yarn.lock: Our new package-lock format will unlock the ability to do deterministically reproducible builds and includes everything npm will need to fully build the package tree. Prior to npm 7 yarn.lock files were ignored, the npm cli can now use yarn.lock as source of package metadata and resolution guidance.
**Renzh:**
打击lerna和yarn

>adblock 插件的分享

**xidong:** 哪个版本的adblocker最好用啊
**panqianyu**:
https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm
chrome.google.comchrome.google.com
uBlock Origin
Finally, an efficient blocker. Easy on CPU and memory.
**xidong:**
现在各种版本实在太多了，这个好在哪里啊
**panqianyu:**
开源，干净
**xidong:**
试试看 谢谢
**呆唯:**
给一个对比，比较商业化的
https://adguard.com/zh_cn/welcome.html
web插件是免费的
**xidong:**
可以连续选择elements吗
**呆唯:**
adguard不行
**WangSiyuan:**
uBlock的性能也是adblock的好多倍
**xidong:**
好用。。
**xidong:**
现在很多网站屏蔽adblocker也很严重，希望ublock可以漏网之鱼。特别是英国对媒体网站
**WangSiyuan:**
给个例子呢
**xidong:**
我之后打开了发你，泰晤士/每日电讯这些吧
**WangSiyuan:**
一般做法屏蔽adblocker的做法：
- 创建一个必然会被adblock的元素。比如 `<div id="ad">`
- 检查这个元素是不是被屏蔽了
- 如果发现这个元素被删了/隐藏了，基本就说明你装了屏蔽插件
- ...

👍1
**xidong:**
https://m.jstore.site/product/5f742615d00565001850022d 推荐了
**呆唯:**
…

>后端和前端的友好交流

### 回合一

**WangSiyuan：** https://remirror.io/
现在remirror做的真好，基于prosemirror和react，用typescript开发的。
今年2月份我做新的Hedwig编辑器时还不太成熟。（感兴趣的也可以看看这个基于prosemirror的block编辑器(*内部地址隐去*)，demo: https://hedwig-editor-demo.surge.sh/
感觉基于prosemirror做的编辑器，稳定性真的好，Bug也少。
**formula:**
狼外公当初考虑过DraftJS吗
**WangSiyuan:**
考虑过，放弃了..
**formula:**
可以讲讲原因么，小宇宙这边的ShowNotes编辑器用了DraftJS，考虑是看起来自定义程度很高而且和React很亲和
**formula:**
不过Bug很多，主要是涉及到IME的部分
**WangSiyuan:**
回顾一下9个月前...
今天在试slate.js，纯react.js写的。0.4x版本很稳定了。
但是作者20多天前开始彻底重写slate.js -> slate.ts了。。。各种api和底层数据结构全变了。
社区里的所有插件几乎全不能用了...
如果当时Slatejs稳定的，可能会用它。
Draft.js我当时看是觉得定制差，而且我看的时候Draftjs维护频率不高，似乎最近fb又开始维护了。然后还是0.11.x，很可能会有api重构，就很难...

Newsletter的需求：
- 输入或者粘贴markdown语法的文本，能自动转成对应样式。粘贴google doc/word的文本，也能自动转成类似markdown的样式
- 类似notion/medium的，选中文字后，出现一个toolbar，里面设置样式。
- 可能会往里插入其它组件：比如embedded twitter之类的。

本来一开始也排除了prosemirror，但后来看到remirror和基于vue的tiptap (https://tiptap.dev/ )，tiptap几乎完整的满足了我的需求。所以就把这个从vue转成react写了。
我觉得的Prosemirror的优势：
- 作者靠谱，codemirror、acorn(js parser)的作者。
- Prosemirror的api非常稳定
- Prosemirror的架构很好。比如contentEditable很多坑，他有一个prosemirror-view把这层的坑填平了，再这个基础上基于view/model/schema来开发编辑器。
- 模块化非常好
- 几乎没遇到过bug。感觉它IME处理的也不错
- substack基于prosemirror

另外，basecamp的trix也很好，把contenteditable当成一个I/O设备处理，这个思路也使得它的Bug很少。缺点是定制化有些麻烦，基于coffeescript写的
**formula:**
上次看slate.js和draft.js有一样的bug，很好复现。在中文输入法状态下随便输入什么，全选，然后再输入点东西就会崩溃
https://www.slatejs.org/examples/richtext
**WangSiyuan:**
绝了。。。。。
**WangSiyuan:**
https://hedwig-editor-demo.surge.sh/
试了一下，我这个没这个问题...
**formula:**
最后选draft.js是发现知乎编辑器体验还可以，不过处理了常见的IME bug，所以当时感觉问题不大
**formula:**
https://podcaster.xiaoyuzhoufm.com/editor
**WangSiyuan:**
Atlassian全家桶好像也在用ProseMirror：Jira/Confluence/Bitbucket/Stride/Hipchat...
纽约时报也在用。
再加上codemirror的成熟度，就觉得prosemirro不错。
而且prosemirror无所谓什么框架，schema的概念也非常适合存到数据库里(不想存html/或者raw markdown)
**formula:**
draftjs存的倒也不是html。
ProseMirror这些写插件的时候就不能写React了吧？这是让我觉得会痛苦的点
**WangSiyuan:**
比如要在正文里渲染一个React组件，它有一个 nodeViews 参数，在这里写react组件就行。
随便找了一个例子：https://github.com/johnkueh/prosemirror-react-nodeviews
**formula:**
像tooltip这些也可以吗？
**WangSiyuan:**
这种吗？
![image](https://image-qiniu.jellow.site/Ftc8_M0CzaMNBAeZP3rSs6CrsyrE.png@middle)

**formula:**
是的
**WangSiyuan:**
这种还挺好处理的。我这里就是这样。这个renderMenuBubble是一个函数，里面有编辑器当前的一些状态（比如selection的位置，被选中的区域，都有哪些inline元素），然后我在这个函数里来决定要不要显示就好。
![image](https://image-qiniu.jellow.site/FtcWsFZYo0CEukPzOY6wd6R_mxoi.png@middle)
**formula:**
学习了
**WangSiyuan:**
定义一个节点类型就很方便。比如我这里定义了一个代码块。
出现三个反引号，会自动转成代码块。
从别的html里粘贴过来，因为dom里包含了 <pre><code> ，也会转成代码块。
按快捷键 Shift+Ctrl+\ 也会转成代码块。
并且，这个代码块里面的内容，是 test* 也就是纯文本。
![image](https://image-qiniu.jellow.site/Fsj037PZntzmPBoXSIAID5NU0dB4.png@middle)
**WangSiyuan:**
如果用remirror的话，和react集成的会更好些。
https://remirror.io/docs/guide/hello-remirror
**formula:**
没有全选的Bug 太好了
**WangSiyuan:**
恩，至少prosemirror我还没遇到什么Bug。有Bug的基本都是我自己写出来的。。。
**formula:**
FB吃💩
**xxj 杨学昊:**
💩
### 回合二
**xxj 杨学昊:**
最近又用了一下recoiljs，非常好用。个人觉得适合组件树很深，但是又不想花时间去关心去优化状态更新有没有不小心导致多余的组件被更新的case（这一点在react eu2020 recoil上用一个类似figma编辑器一样的画布应用来举例子的）。缺点也比较明显，因为和react强绑定而且必须用hooks，所以在非组件里区更改状态之类的。
https://github.com/facebookexperimental/Recoil
**WangSiyuan:**
所以在非组件里区更改状态之类的。
这个是什么意思？是说必须用hook，没办法在组件外改状态吗
**xxj 杨学昊:**
对的，比如我有一个js文件里面是类似socket代码监听某个事件的时候去修改状态这种，redux直接store.dispatch就行但是recoil不行。看见相关issue在讨论了，好像有非常麻烦的解决办法= =
**WangSiyuan:**
对，我刚刚也想到这个场景了。或者electron的render process和main process的通信
**xxj 杨学昊:**
还有就是 比如我在根组件获取用户信息并且放到状态里，这个场景因为根组件的代码在`<RecoilRoot>`之外所以也不行。。。
**xxj 杨学昊:**
只有在正常组件里用起来很爽，要等他再发展一下了
**WangSiyuan:**
恩...recoil方便生成patch和snapshot吗
**xxj 杨学昊:**
好像是有的，可追溯
**WangSiyuan:**
比如一个多人协作的App。
A操作了 -> 产生一个patch -> 发给B -> B apply这个Patch。
C进来以后 -> 直接apply snapshot
**WangSiyuan:**
看到了，可能是这个：https://recoiljs.org/docs/guides/persistence
**xxj 杨学昊:**
那还挺牛逼的
**WangSiyuan:**
之前用mst的时候，patch/snapshot这个太好用了。还可以有middleware去拦截
**xxj 杨学昊:**
学到了

>一些有趣的工具分享

**zengxian:** https://retool.com/ 这个看着挺不错的，拖拽组件来生成一些内部工具前端

**大核桃:** https://vika.cn/
airtable的国内版
**Renzh:**
有点东西https://vika.cn/template/tpc000/tplfmkWm9t2fl/fodijRlqVita3

>好笑的

**WangSiyuan:** https://twitter.com/Baconbrix/status/1315999130951573504?s=19

Evan Bacon 🥓Evan Bacon 🥓 @Baconbrix
pro tip: alias any to TODO to make people think you plan on fixing it later. ![](https://pbs.twimg.com/media/EkNd3jHXcAEpwl4.jpg)

IFTech BE Weekly #2

#### 上次关于mongo objectID的激烈讨论后续：
**ziyu:**
这个话题过去一段时间了，但还是再补充一下我的观点吧：
我并不认为mongoose它这个函数的实现里混用12和24的长度判断的做法是好的（这里说清楚我并没有要和图图争）。很多coder会习惯让抽象出来的函数能够兼容更多的场景，所谓通用性。但作为校验函数而言，这样的做法反倒使得函数本身的功能界定模糊，从而导致没有看过源码的使用者无法正确利用它达成校验的目的。我非常支持像@Renzh 提的PR，将 24 字节表征的 hex string 单独作为一种校验对象，清晰准确，代表了上层业务逻辑的使用方式。
虽然说校验函数写得不好，但是还是希望大家能够理解 12 个字节长度这个点。ObjectId 的规范里并没有规定一定要使用 24 个字符的 hex string 。所以用来存储 12 个字节长度的 binary string，也需要能够理解它的合法性。
我当时有提到在 socket 场景下会存在用 string 来存储并处理 binary 的可能性。原因是我曾使用 nodejs 写过一些设备的通信协议栈，其中有种设备就是共享单车的蓝牙锁协议。它是通过 socket 发送一连串 16 进制的编码。在它的通信协议里，有个很重要的编码分割段：`0x7E` 标识一段结构体的起始位置 `0x7F` 标识它的结束位置，其中还有掺杂一些其他特殊定义的编码需要处理。相比于直接处理 Buffer 数组，将它直接 `toString(‘latin1’)` 后 （注意不是 `toString(‘hex’)`，to hex 会使得字符串长度翻倍，同时你处理一些特殊编码时必须得连取 2 位字符，非常麻烦），可以利用正则表达式以及 replace 方法快速批处理很多转义事务。JS 本身并没有 binary 类型，但 string 是可以作为 binary string 来用的，并且在特定场景下是非常方便的。
👍8
**Sean:**
3 确实是我没想到的
**zengxian:**
学习了
**xxj 杨学昊:**
3这个有点巧妙
**WangSiyuan:**
3这点学习了
不知道3这种用法有没有可能：content里出现 `0x7E` 或者 `0x7F` 导致出现问题
之前做rtmp协议解析时，因为content长度写在header里，就只能从头读到尾...
**ziyu:**
思远提到的问题很好，协议里解决方式是有一个 转义编码的，具体忘了是啥，假设叫 0x7a 吧 你理解成`\` 就行了。
👍1
**ziyu:**
然后转义编码连续出现的时候解析为原本的字符，也就是 \\ => \
**Sean:**
巧妙谈不上吧，我想了一下我要怎么按三的方式去处理逻辑。
我得先去查一下 `0x7E` 对应的ascii字符是什么，刚看了一下是 ~
所以你这里写了一个正则去匹配 /^~(.+)\\$/ ，这里我只有一个问题，这真的是大家想要的解决方案么？
👀1
**Sean:**
我其实观点是，三点里提到的1，2我想整个后端是没有疑问的
**Sean:**
但你不应该去过度合理化一些不合理的行为
**Sean:**
我确实没想到js的binary处理这么不方便，但知道这个结论后我会觉得就多一个js可complain的点。
想想这个思路是否合理：
因为一个语言的限制，我们不得不使用一种非常hack的方式来处理代码。
这种hack的方式被不需要的地方沿用了，给一部分人造成了误解
因为这种方式的存在所以合理化这种方式。
**Sean:**
我个人觉得，“用string来表示一段非二进制的binary”这种行为，无论在哪门语言里都是不应该被推荐的
**ziyu:**
我并不认为这个方式是hack的，反倒是一种很自然的处理方式。
你指的沿用是指哪里？
这种处理的确是合理的。
看起来图图的观点是停留在类型是一种表示对吧。但要注意的是，这里确切的说不是用 string 来表示一段非二进制的binary，而是使用 String 对象来处理一段 binary 数据。这就是我说的类型只是抽象，我们真正处理的是底层数据。类型是告诉了编译器内存长度的分配方方式和使用方式，而这里我们不是用string做可读的表征，而是做了运算
**Sean:**
我觉得比较好的方式如：
不抽象，例如c/c++/rust 语言里的 u8[]
抽象，例如elixir里的BitString
**WangSiyuan:**
（二进制确实不方便... 但也能接受。多一些位运算之类的
ziyu提的那种办法在某些场景下是能大幅度让其方便的。
我接触到的协议一般都是按照三段的方式定义。
```
fixed header: 定长头，一般可以读到当前消息类型，以及变长头的长度。
变长header：按照 fixed header给的长度直接 .readBuffer(N) 。用于获取data区域的长度，如果更复杂的协议，可能data区域还有别的东西。
content: 一般根据变长header给的信息来读取。
```
因为是tcp协议，所以实际上就是一个stream流。中间读错了的话，要么是解包代码写错了，要么是对方发错了
我当时的写法就是
```
fixedHeader = await socket.read(FIX_HEADER_LENGTH)
{ messageType, len } = parseFixedHeader(fiexHeader)
header = await socket.read(len)
content = await socket.read(parseHeader(header).len)
```
里面用的 socket.read 方法是自己实现的，因为数据不见得能在一个packet里发完整。
至于如何读取 Header Buffer里的信息，就有各种办法了。
比如用string、或者一个字段一个字段的读，也可以像Python那样
https://docs.python.org/3/library/struct.html#examples
```
record = b'raymond   \x32\x12\x08\x01\x08'
name, serialnum, school, gradelevel = unpack('<10sHHb', record)
```
**Sean:**
我的 “表示” 其实意思是 “代表“， represent。
我觉得不应该用string represent a slice of binary是有很严密的逻辑的：
string是包含语义的，其实我们处理上他的语义是字符数组（而非字节数组）
string包含很多处理string特有的方法，而这些方法对于binary未必适用
比如我们常用的 string#length 取的是字节长度么？
不是的，即使在node里 "我我".length === 2 而不是比如真实的6个字节。
下面的输出是什么？
`"你好".slice(1)`
你去遍历string的时候期待的到底是
`for const char of string`
还是
`for const bit of string`
**Sean:**
js在string的处理上其实很不好，反而“易于“你去用他处理binary了
**Sean:**
关于string的一些特点可以看看
https://mortoray.com/2013/11/27/the-string-type-is-broken/
> Musing MortorayMusing Mortoray | mortoray
> The string type is broken
> My previous article, “We don’t need a string type“, caused a bit of stir. Though the feedback is mixed, there is a common theme of a string being a useful feature. After doing a bit more research I can determine only one thing: most current string types are broken!
> Many of us believe our strings are capable of more than what they actually do. We rely on their functionality without actually checking that its valid. This can easily lead to programs which do not work correctly, particularly with respect to internationalization. In most cases it seems we would be better off without a string type.
> Evaluate
> I looked at how strings behave in a few basic situations. I’ll go over… 

**ziyu:**
你对我的观点还是有些过度解读了。你说的这些点都是对的，JS的string的确存在很多的不足，我的视野里当然也是默认大家都知道这样的问题，比如对中文编码的长度。
**ziyu:**
关于如何理解 binary string 可以看这里：
https://developer.mozilla.org/en-US/docs/Web/API/DOMString/Binary
澄清一下最开始的回复里面：
1. `.toString() toString('latin1')`
2. `0x7E,0x7F` 只是我记忆中的编码，由于时间久远，可能不够准确，但正则式里面是支持用 `\xhh` 的写法，不用写出 ascii 字符

> MDN Web DocsMDN Web Docs
> Binary strings
> JavaScript strings are UTF-16 encoded strings. This means that each code unit requires two bytes of memory and is able to represent 65535 different code points. A subset of these strings is represented by UTF-16 strings containing only ASCII characters (i.e., characters whose code point does not exceed 127). For instance, the string "Hello world!" belongs to the ASCII subset, while the string "ÀÈÌÒÙ" does not. A binary string is a concept similar to the ASCII subset, but instead of limiting the range to 127, it allows code points until 255. Its purpose however is not to represent characters, but binary data. The size of the data so represented is twice as big as it would be in normal binary… 

**Sean:**
是跑远了，反过来我发现我刚那段和你之前说的
“要理解抽象类型背后的本质“其实是一样的“正确的废话“。
我感觉是我们同样理解了“抽象类型背后的本质“后，我认为类型依然重要，你认为不那么重要。
回去一句一句对着回答的话
> 看起来图图的观点是停留在类型是一种表示对吧。但要注意的是，这里确切的说不是用 string 来表示一段非二进制的binary，而是使用 String 对象来处理一段 binary 数据。

不是，我想表达的是“代表“所以利用string来处理binary也是一样的。
> 类型是告诉了编译器内存长度的分配方式和使用方式，而这里我们不是用string做可读的表征，而是做了运算

我其实不理解后半句想表达的意思。
我上面那段话本质上是想举一些string不便处理binary的场景以证明用string代表binary的不合理性。当然我也注意到了你说的是：在特定的场景下使用string会特别的方便。
**Sean:**
你给我发的文章最后赫然写着
> JavaScript typed arrays provide a mechanism for accessing raw binary data much more efficiently.

**ziyu:**
是的，但是不够用
**ziyu:**
它的优势是access，而我们还有其他上层运算，只能说是对它再进行一了层抽象，以二进制字符串的形式来处理
**ziyu:**
在那个场景下，数组类型这层抽象就是不够用的。需要再对它的类型进行抽象，就是二进制字符串了。我并不是认为类型不重要，而是认为在特定场景下用符合语言特性的特定类型，来处理特定事务，是合理且自然的。（很多「特定」限制了它的传播范围） 
**Sean:**
是，这是js的问题，你因此使用string是不得已而为之或者取巧。
我的观点是，不要合理化这种迫不得已。
你看这篇文章的论点其实很清楚
js里没有设计binary string，
但因为web app的需求，过去不得不使用string来处理binary，但这“slow and error-prone”
因此才引入 typed arrays
**ziyu:**
如果规则上有更优的方式，那么谁还会迫不得已呢？
**ziyu:**
既然是规则下的，那么不是合理且自然的么？
**Sean:**
自然不是
**Sean:**
规则下可做的事情多了去了。。。我们不还是制定了更多规则避免做一些“不合理“的行为么 (edited) 
**Sean:**
比如js规则里string，number，object随便传，自动转换，
如果这合理且自然为什么有type announcement，有ts，即使raw js的库里也写了各种type guard呢。
**ziyu:**
这句话倒也没错。确实是需要制定更多规则。但似乎还是在于对 binary string 的定义上认为它不合理。但在我看来，它只是不那么好，而不是不合理。
**Sean:**
fine，我觉得表达的清楚了，感觉后面应该就是各自坚持了，不如就到此为止？
**ziyu:**
对于使用 UINT32 类型来作为最多能支持 32 种开关 FLAG 的变量，来说，你会不会觉得不合理？
👍1
**Sean:**
挺好的问题。
让我想想
**Sean:**
唉我虽然能想到些用32位int来表示32flag的弊端，但总体来说又觉得合理（因为有很多位处理操作符）
**Sean:**
不过想这个的时候想提一下binary和bitstring在erlang里有完全独立的类型，可能是因为其是为电信通信设计的，从一开始就考虑了二进制处理的问题。
👍2





#### 关于rust的讨论
**xxj 杨学昊：**
https://twitter.com/haoel/status/1308243550761443328?s=12
> Hao ChenHao Chen @haoel
> 对我来说，Rust的那些所有权，lifetime，trait等都是很好的东西。然而，我想用Rust尝试写个链表，写个并发排序，代码写完后，各种编译不过，一次次挫败后，在某个地方找到个“秘籍”（是的，就是那种不为人知的秘籍），才顺利通关。后面发现需要N多这种秘籍才能把程序写下去……这才是Rust最大的问题……
> TwitterTwitter | Sep 22nd

看来不止我一个拿rust做oj（
**knight42:**
rust 标准库里就有一个双向链表的实现 https://doc.rust-lang.org/std/collections/struct.LinkedList.html。并发也有 rayon https://docs.rs/rayon/1.4.0/rayon/ 能提供比较 high level 的 API
☕️2
**knight42:**
rust 想要在编译期保证 memory safe 自然是要做很多 trade-off 的，这也导致它跟很多主流语言的心智模型不太一样，所以不能参考以前的经验，可能这也是让人觉得需要很多“秘籍“的原因

#### 一些文章分享
**呆唯:**
https://blog.cloudflare.com/moobot-vs-gatebot-cloudflare-automatically-blocks-botnet-ddos-attack-topping-at-654-gbps/
cloudflare如何检测ddos
**zengxian:**
在线上使用canary测试的时候，如果有bug即使很快发现自动回滚也会影响到少量用户，这篇文章介绍了“dark” canary这个方法，把线上流量复制到dark canary部署，丢弃response和对数据库的写操作，对用户无感知，不过dark canary部署的维护难度比较高 https://engineering.linkedin.com/blog/2020/production-testing-with-dark-canaries
☕️2👍1
**zengxian:**
https://mp.weixin.qq.com/s/Ovq8LPZJDdoe7L-9F9pstg
这篇介绍mongo4.4新特性挺完整的，很多很好的小feature和优化比如hidden index，降低了复制延迟，simultaneous indexing，resumable initial sync，time-based oplog
👍7
**ziyu:** 
https://ai.googleblog.com/2020/09/advancing-nlp-with-efficient-projection.html
@wentao 刚提到的谷歌最新的NLP模型进展，是基于 PRADO 改进的 pQRNN 模型，效果媲美 BERT 但参数量更少。他们开源了 PRADO 模型。
👍5
**WangSiyuan:** 这篇论文解析蛮好的：
https://draveness.me/papers-maelstrom
本文要介绍的是 2018 年 OSDI 期刊中的论文 —— Maelstrom: Mitigating Datacenter-level Disasters by Draining Interdependent Traffic Safely and Efficiently1，Facebook 通过流量管理系统 Maelstrom 转发数据中心的流量，在出现一个或者多个数据中心故障时，减轻故障对业务造成的影响。
**Renzh:**
动画演示HyperLogLog http://content.research.neustar.biz/blog/hll.html
👍2
**zengxian:** newrelic刚发了篇文章介绍如何通过三个阶段搭建可观测性体系，有挺强的实践参考意义，里面也包含一些关于Observability的基本概念介绍
https://newrelic.com/resources/ebooks/3-phased-approach-to-observability
**punky:**
编辑器之争可能真的可以告一段落了
https://blog.robenkleene.com/2020/09/21/the-era-of-visual-studio-code/

> 这个专栏用来分享即刻后端团队日常工作中的技术讨论和阅读分享，主要内容摘选自Slack中的发表和评论。如果对某条内容有什么想法，也欢迎大家通过回复邮件来参与讨论。

#### 一次关于bson objectId valid的讨论，评论内容只选了一部分
呆唯：把用户昵称识别成objectID了
![image](https://image-qiniu.jellow.site/FuztbHvHh1TssabKfR-8UZaa8qjT.png@middle)
**Sean:**
bson 的 ObjectId.isValid() 应该不会把
**panqianyu:**
话说这个好像就是合法的 objectId
**ziyu:**
12 bytes in length
**WangSiyuan:**
```
lib/index.js:993-995
  if (typeof v === 'string' && (v.length === 12 || v.length === 24)) {
    return true;
  }
```
**zhangxuhui:**
被坑过。。。
用的这
`ObjectId.isValid(id) && new ObjectId(id)).toString() === id`
**Renzh:**
12 bytes in length 应该是指二进制表示，这样的话没毛病
**Renzh:**
我们其实是想要一个ObjectId.isValidHexString()
**ziyu:**
类型是抽象概念
**Sean:**
就，为什么要支持这个string是个raw数据的可能
**Sean:**
但我们/这个库也是运行在这个抽象层面上的
**ziyu:**
socket
**Sean:**
socket拿到的不是buffer么？
**ziyu:**
buffer也是抽象概念
**Sean:**
不能因为是抽象概念就忽略
**WangSiyuan:**
https://github.com/Automattic/mongoose/issues/1959
\#1959 Best way to validate an ObjectId
I'm inserting some objectIds as references and I want to make sure that they are valid objectids (right now I'm getting a crash when they aren't valid ids).
I'm checking to see if they refer to valid objects by just doing a find() call.
How should I check if the strings are in the correct format? I've seen some regexs that check if the string is a 24 character string and stuff like that - seems like a hack. Is there an internal validator on the ObjectId? I couldn't figure out how to use it. Thanks so much!
**WangSiyuan:**
an Object ID is any 12 byte long value so any 12 byte long string is a valid ObjectId
**Sean:**
如果说因为底层是一样的就可以把两种类型混为一谈或者忽略类型，那从一开始就不要分开类型好了，像C++一样都是u8\[\]
**WangSiyuan:**
就objectId的问题，就是任意12字节的值，都认为是objectid
**ziyu:**
是这个理解的
**ziyu:**
string 只是对12字节值的一种表征方式
**Renzh:**
我们是把ObjectId.isValid()当ObjectId.isValidHexString()用了
**Sean:**
是但是我们的工作是建立在这种表征方式之上的
**Sean:**
我们是在处理string or buffer
**Sean:**
不是在处理12个字节
**WangSiyuan:**
我们是把ObjectId.isValid()当ObjectId.isValidHexString()用了
是的，问题在这
**ziyu:**
c/c++程序员不是这么想问题的
**Sean:**
我们不是c/c++程序员  
**Sean:**
这个库也不是写给c/c++用的
**WangSiyuan:**
24位hex字符串是对于我们目前的使用场景吧。
可能对于mongo/mongoose这种库，在 isValidObjectID  这个API上，可能还是符合官方定义比较好。可以再有一个 isValidHexString 方法来针对字符串判断 `^[0-9a-fA-F]{24}$`
**WangSiyuan:**
另外bson本身就是二进制的，所以以12字节来定义objectID也算合理吧
至于库为什么用 12bytes 。我觉得是因为使用的是BSON类型，而不是JSON类型。
BSON本身就是二进制的格式（虽然日常使用感受不到他的二进制），所以里面的每个字段都是以二进制表现的。
http://bsonspec.org/spec.html
**ziyu:**
用24个字节去处理12个字节问题才是不科学的思考方式。不管什么语言程序员，第一堂课肯定会是类型以及其对应的存储空间吧。存储是很重要的，不能因为语言特性就忽略了这个。
**Sean:**
bson本身就是二进制
显然
所以以12字节来定义objectID也算合理吧
错误的推导
**Sean:**
也许isValid本身就是个错误
**Sean:**
但用string来表示二进制（非base64的string）也一定是个错误
**Sean:**
知道其背后的存储结构不代表你就应该绕过前面的抽象，一个非string的二进制数据用 二进制对应的string来表达和传递，这对应到c/c++里就是强制类型转换，从来就不是一件正确的操作
**Sean:**
bson可以fromString，这个string在几乎所有语境下都是hexString。在这个大前提下如果真实想用二进制底层数据来表示，在node的语境下就应该用buffer。
如果说因为底层一样所以就可以换着用，那我是不是还可以用string来代表object？
**Sean:**
我的这个观点建立在ObjectId的toString语义只有hex string一种的前提下，如果说其实不是这样的官方就是说其实有两种，那我只能说好吧，这很傻，我没办法。
但我不可能认同因为他底层一样因此就是一个东西这样的观点 

#### 一个mongo driver导致的内存泄露问题
**panqianyu:**
这段时间即刻部分服务出现了缓慢但明显的内存泄漏。通过对比服务的每小时内存快照，发现是因为 mongodb driver 的 replica set topology 根据 node timer 的 _called  字段，判断是否需要销毁定时器。但是在 node12 当中，此字段被移除了，导致定时器无法被销毁。
参见相关 [issue](https://jira.mongodb.org/browse/NODE-2460) 和[源码](https://github.com/mongodb/node-mongodb-native/blob/v3.5.3/lib/core/topologies/shared.js#L229)
解决方法就是及时升级新版 mongodb/mongoose 库，以及开启 useUnifiedTopology
修改之后的服务，目前为止内存用量平稳
👍18

#### 胖虎发布了一个redis管理工具，使用和mongood同样的技术开发
**Renzh:** 
一个Redis GUI：
https://github.com/RenzHoly/sider
👍7



#### 0neSe7en在后端周会上的分享
**https://staffeng.com/guides/staff-archetypes 这个系列文章以及作者的博客值得一看。作者是Calm的CTO。**
这篇文章把工程师的发展方向分成四个类别，觉得很恰当：

Tech Lead：一般来讲和一个Manager合作，带领一个小团队去完成任务等等。
Architect架构师：负责在某些关键领域设置方向、质量评估、以及实现方法。会综合技术限制、用户需求、组织内的Leader等
Solver问题解决者：一般是去深入解决一个复杂的问题，找到解决问题的方向。一般来讲找到解决办法后，就会去解决下一个问题。然后把这些方法交给其他团队继续维护和迭代。
Right Hand右手：就类似权游的那种

**关于年龄焦虑，尤其是国内的35岁焦虑**
最近看到rsms从figma离职，就去看了一下他的博客，发现他很酷。http://rsms.me/
99年毕业从事设计工作，作为设计师工作了七年。
2006年(30多岁)去了Spotify作为初始员工之一，当设计负责人。在Spotify也做了一些C++的工作，写了高性能的后端和一些基础设施，也是Nodejs早期的核心开发者。
四年后(35岁吧)离开Spotify去了Facebook当设计师，在Facebook期间，是iOS/Messenger/Facebook Home等产品的设计师，也是开发，还参与创造了GraphQL。
然后13年去了Dropbox，工作了两年半。
然后2016年去了Figma(40多岁)，那时候Figma刚开始不久。比如一起设计了Figma的Logo以及编辑器等等。
同时也在探索wasm、编译器、编程语言等等东西。


即刻后端Newsletter

IFTech BE Weekly #4

IFTech BE Weekly #2

IFTech BE Weekly #2

IFTech BE Weekly #1