分类目录归档：Golang

这些年参加过的双11

发表于由
回复

今年双11在波澜不惊上落下帷幕，这个周末是难得的一个修整机会。百无聊赖之中，对自己参加过的几次双11简单总结。

加上今年双十一，已经参加了三次现场双11。对于普通用户来说，每年的基本盘都是 买买买 ，但对于自己来说，每年的感受却不尽相同。

第一次参加双十一技术支撑保障是2018年。作为还没有转正的新同学，第一次进入作战室的时候更多是新鲜感和第一次亲临现场的兴奋。然而，没想到等待自己的却是各种万丈深渊旁的如履薄冰，如同那年成都伸手不见五指的雾霾，一路战战兢兢，磕磕绊绊完成了任务。好在当时一起搭档的同学非常给力，把现场的问题都快速解决。

事后复盘，数据链路年久失修+系统架构设计太多trck和临时方案是症结。我们不能将这种必然的问题还诉诸于来年的好运。于是，我们花了半年的时间来解决以上问题。在大公司做这样的事情往往是不太被认可的，放在我身上也不例外。更为甚者，还会受到很多业务上的挑战。当时，我选择了接受阶段性不被认可的结果，坚持一条道走到黑。如今想来，有许多更加圆滑的做法，但是如果把我重新放在当时那个位置，我应该还是会选择当时的做法，而这种选择不是认知和经验问题，仅仅是内心自我的坚持吧。

带着第一年复盘的调整结果，信心满满的走进了2019双十一的作战室。是年丈母娘装了新房，当晚的一级保障计划就是给丈母娘 买买买。然而，还没等第一瓶可乐喝完，业务反馈大屏上面一个实时数据的结果不正确，找到当时业务接口同学，她倒也是诚(hou)实(yan)直(wu)接(chi)：之前让验收数据的时候，回答是验收通过，其实并没有看数据。得嘞，这时手刃之祭天是没有任何作用的，而大屏数据又是部门万众瞩目的，那只能想办法现场把这个数据开发出来发布上线。抬头看了看时间，不要20点。

然而，因为双11封网一级保障的原因，实时任务开发平台无法新任务开发，沟通了将近1个小时也没有结论。好在想起之前作为集团实时任务计算平台的典型用户，与平台的owner有过一次还算愉快的内外论坛交流，于是直接联系他们解决了平台问题，只是受限于当时的关联系统管控原因，开发的计算任务无法调试，只是发布上线后结果。抬头有看了看时间，22点过了。

为了加快开发速度同时确保开发质量，我和当时搭档的同学每人负责一部分代码的编写，然后合并代码交叉review. 其实代码本身的复杂度不是太高，但是当时的高压环境和氛围让编写任何一个简单的逻辑似乎都变得不再简单。22:30 我们完成了代码编写，code review时候，我发现了一个代码的问题，跟搭档确认时，他也意识到了这是一个问题，不得不说，有时候高压真的会让动作变形。代码很快发布上线，没有调试的情况下，一次性上线成功，数据口径也符合预期。到此，问题解决了一半：由于需要追溯历史数据，因此，计算任务需要调回到今日凌晨开始计算，接下来的一个小时，我们就是盯着任务的追赶进度，终于在 23:45，成功追上了当前时刻的流式数据！

当时的直接主管老阿里也坦诚这是他参加过历次双11颠覆他认知的紧急发布。坦率讲，这次问题处理是有运气成分的，因为我和搭档事后都觉得计算任务不经过调试，一次性发布成功在日常开发中基本是不存在的。但是，过程中我觉得很重要的一个点是：技术自信。日常开发中，有问题我们可以面向google编程，但是当你的开发周期被限制在很小的时间窗口的时候，你日常所有的积累和基本功，当然还有欠下的技术债都会在短时间内爆发并如数奉还，童叟无欺。比如，这次review出来的问题我之前是研究过的，并且计算平台的文档我也是每一页都读过多次的，这个问题在哪些版本会出现也是心中嘹亮的。这些东西可能都称不上知识，只能算是信息和经验，但是假设没有这些助力，我们当晚必然需要二次发布，而时间是肯定不够的，然后也就没有然后了……另外，我很推崇的技术sense是对基础的重视：我们日常99%的问题都可以用基础的80%去覆盖和解决。因此，在追求20%的高精尖的时候（程序员歧视链的必然）永远不要放松对基础的积累和完善。

今年双11保障基本面很早就进行了部署和实施，11.1的作战室现场也是波澜不惊。但是，因为11.3黑色事件与双11有重叠时间的原因，业务层面在10号早上提了新需求。而再过几个小时就是双十一了……而我选择了接下这个需求，除了所谓的 价值观，还有一个原因是我觉得这是一个与其他同学进行技术PK的好机会。中午放弃了午休开始编码，下午3点过完成了开发，业务验收通过，然后关联业务方得知以后似乎觉得我这里的开发是不要钱的，又追加了一个需求……当然，在迟到了几分钟进作战室，都毫无意外的完成开发，并发布上线。

其实很多老人都觉得这个时候接这种需求很容易搬石头砸自己脚，其实我也是这样认为的。只是我评估业务需求后，我没有走跟我PK同学相对比较笨重的java技术路线，而是选择了Golang，在编译和调试速度上都占尽了优势，同时凭借自己平时维护的标准扩展库，很多任务都是一行代码可以解决。典型的现场现状是：我比其他线的技术同学提前了好几个小时把任务开发完发布上线，反馈问题修改也是在分钟级搞定。另外，大家可能有个疑惑：为什么没有像去年那样交给下面的人一起合作去做？一方面是因为这条技术线路在短时间内只有自己最熟悉，跟合作同学简单沟通后发现其技术面还未覆盖这些领域，我这个时候只能选择跟我上的方式，功劳大家分；另一方面，这个事情除去价值观，我有私心，我就是要用技术的方式PK一些日常看不惯的技术同学。我深知，这其实也是某种不成熟, 只是，时间久了，有些东西只是变味了，未必是成熟了。

总结下来，参加这几年双11的几点感悟：

  • 未雨绸缪，实践检验真理。
  • 不要把偶然的运气当做实力。偶然的好运学会感恩和感谢，必然的倒霉也不必气馁，区分好概率和实力。
  • 养兵千日，用兵一时。高压之下，要有自负的技术自信。
  • 日常学会辨别气味相投的人，并投资积累信用，而不是表面上nice的人。
  • 技术人要学会通过技术做表达，从技术的力量视角去理解商业的本质。

1024搬砖之IG密码加密方案分析

发表于由
回复

10.24本来是普通的日子，但却有机会让你很容易的区分的两种人：程序猿与其他。

正好周六，于是把之前 side project 中的一个临时方案修改一下。其中一个关键问题点是：用 go 生成 Instagram 登录时需要用到的加密密码。

C# 版本代码如下：

扫了一下整体结构，发现IG的这段加密设计还是很好的体现了大厂典范：

  1. 密码加密使用到了 aes-256-gcm, 不是野生程序员上来就是base64或者来一个自欺欺人的哈希函数（MD5, SHA1等）。这两者本身不应该一起提，因为本身是用途完全不一样的东西，只是国内看过很多方案是后者，有时候还觉得自己加了salt更安全。AES结合GCM在解决数据加密问题的同时，也解决是数据完整性校验的问题。此外，加密操作中引入time作为附加数据，因此也可以校验数据的时效性，防止重放攻击。
  2. AES是一种对称加密，因此涉及的密钥分发的问题。上述方案中，使用了SealedPublicKeyBox 这种常用且规范的源于。即通过接收者的公钥来解密AES的对称密钥，得到密钥的密文。而这个密钥密文只有接收者使用自己的私钥才能解密。
  3. 从私钥密钥去中心化以及管理维护成本出发，应该是同时启用了多对公私钥对(可通过keyId识别)。
  4. 密文bytes构造上采用经典简洁的length.content设计。
  5. 最终构造的 enc_password 格式中包含了平台、版本、时间戳、密文。如果你也设计过密码加密的方案，你应该能看到这几个要素没有一点废话，基本就是教科书的标准格式示范。调研了一圈，发现的唯一业务上的槽点是版本为某个特定值时，其实是允许传输明文密码的。这从语义上来说是矛盾的，推测是从前向兼容的一种妥协。
  6. golang中可以通过 NewGCM 实现 aes-256-gcm, 但是认证标签(authentication tag) 没有单独输出，是append在密文之后的。因此可以通过 cipherText[len(cipherText)-16:] 获取。
  7. golang中没有 SealedPublicKeyBox 原语。可以用 package golang.org/x/crypto/nacl/box 中的 SealAnonymous 代替。

其实密码加密方案有很多基本的概念和原则，国外大厂也有很多规范的设计。只要不是一开始就想当然，其实是能找到或者设计出一个符合业务需求且安全高效的加密方案的。

特殊的一天，在老家楼上分析了一段有意思的代码，完整了方案的重构，还开着遥控车在农村撒欢越野。 What a beautiful day!

GopherChina 2019 keynote 点评

发表于由
回复

今年的 GopherChina 大会如期而至，没能亲临现场，但是 keynote 绝不会错过。一如往常，谢大第一时间放出了今年的keynote。今年的 keynote 中有不少老面孔，不知道以后大会是否会把固定若干老面孔作为惯例。如果你错过了去年的 keynote, 可以参见鄙人拙文《GopherChina 2018 keynote 点评》。

整体上，今年的演讲主题跟往年所涉及的领域和覆盖的范围区别不大，无论你是关注架构、微服务、语言细节，还是数据库、存储、业务及应用系统构建，都能从中找到自己感兴趣的内容。

1.1 大型微服务框架设计实践 – 杜欢

如果你曾经想用比较hack的方式获取goroutine id, 那么你有很大可能性使用过杜欢的goroutine. 也因为写Golang 获取 goroutine id 完全指南的缘故，跟杜欢结识。看到这个keynote，心里还是有种从未谋面，但是久违的熟悉感。在大概3年前，我其实也做过类似的框架设计和开发。很多理念和原则的确是 cant't agree more. 其中，“框架和业务正交”的原则也是充分发挥了golang自带的正交特性。

在框架中，隔离层的思想很朴素，但是很实用。我曾经因为在设计之初没有引入隔离层，自己手动修改了多个数据库驱动库，以满足框架某个特性的引入。如今想想，真的是血与泪的教训。

1.2 用Go打造Grab的路径规划和ETA引擎

不得不感慨，Grab 的业务才是真的大型生活类服务。从形态上看，已经约等于国内滴滴+美团+顺丰组合了。演讲内容偏向算法。对地图路径规划（无论是游戏地图还是现实地图）感兴趣的同学，可以看看算法到实际工程落地之间的gap如何弥补和解决。

1.3 Go practices in TiDB – 姚维

印象中，PingCAP 出来的speaker分享质量一直都挺高。姚维老师的这次分享也保持了PingCAP一如既往的高水准，深入浅出，以小见大。一直比较好奇TiDB这种对软件质量要求极高且分布式的领域是如何做测试的，看了其Schrodinger 和 gofail 的介绍，无论从主观体感还是技术信赖都TiDB加分不少。failpoint 在实现层面是基于golang AST 做的，编译时被转换为一个 IF 语句，整体设计简单直接有效，是我喜欢的风格。

另外一个比较有意思的点是使用 chunk 来优化内存使用。以前只知道使用整块连续的内存分配策略比碎片化的内存分配更有效率，但是不知道连续内存带来的矢量化执行优势。如果你是做高性能数据库的，这个点一定不能不知道。

1.4 Testing; how, what, why – Dave

Golang官方人员 Dave 大胡子老师出品，必属精品。关于golang如何做测试的资料，看这一个就够了。

1.5 Go 业务开发中 Error & Context – 毛剑

在 golang 1.x 中，错误处理一直是一个不太舒服点。因此才有去年 Rethinking Errors for Go 2 对golang 2.x 错误处理的预览和展望。但是，golang 2 是没有具体时间表的，当前阶段，如果你在实际业务系统中对错误处理有疑惑，可以看看毛剑的处理方式。

Context 其实算是一个老生常谈的话题了，但是毛剑总结了很多实际使用中的最佳实践，分享内容还是诚意满满的。

1.6 Go并发编程实践 – 晁岳攀

从源码级别探究Go在并发层面的基础库实现。跟去年的深入CGO编程一个风格，内容非常全面和丰富，有细节有深度。如果想深入golang源码，一定不可以错过。

1.7 百度APP Go 语言实践 – 陈肖楠

从ppt内容看，算是一个大厂在小场景的golang实践。涉及的问题，以鄙人浅见：使用golang落地1年以内的创业公司都会遇到。给出的解决方案和踩过的坑已经远看不到国内巨头的风范了。如果百度再被扣上技术不行的标签，那就是哪都不行了……

1.8 Golang to build a real-time interactive SaaS Cloud – 董海冰

golang 在 WebRTC 场景下的工程实践。以前对 WebRTC 比较模糊，细致看了分享内容以后，才发现这块的内容和涉及的技术如此广博。前端时间，提供视频会议解决方案的 zoom 上市了，日后我们应该有很大概率看到更多 golang 和 WebRTC 的落地方案。

2.1 基于MINIO的对象存储方案在探探的实践 – 于乐

作者用 golang 撸了一个支持多集群的分布式对象存储系统。有两个技术细节值得技术投资和持续关注：

  1. Reed-Solomon，一种低冗余，高可靠的纠删码。golang 版本的实现可以参见reedsolomon.
  2. The Linux Storage Stack Diagram. 能让你系统全面的了解 IO，并且知道 Direct IO, page cache 的本质。

2.2 从零开始用 Go 实现 Lexer & Parser – 何源

作者编译原理的底子还是在的。想当年，我们该课程的期末课程设计就是编写一个编译器。不过大部分时候，如作者所言，如果不是万不得已，不要自己写 parser. 毕竟，在不使用正则表达式的前提下，golang 提供了非常完善易用的 AST 基础库支持。

2.3 高性能高可用的微服务框架TarsGo的腾讯实践 – 陈明杰

golang和微服务经过这几年的演进发展，无论是基础框架还是周边生态，已经达到了水乳交融的程度。鹅厂的这个实践从当前时间点看，没有什么亮点，更没有什么突破。本以为会有一些 service mesh 方面的尝试，但是比较遗憾，这方面从分享内容看还走得比较靠后。

2.4 闪电网络—BTC小额支付解决方案 – 方圆

不知道这个方圆老师跟去年代表罗辑思维做分享的speaker是不是同一个人？如果是的话，真的是选错了行业风口呀。币圈有风险，跳巢需谨慎。

2.6 用Go构建高性能数据库中间件- 徐成选

一个使用golang打造中间件的实践。文末提到了一些优化方案和细节，挺受用。

2.7 花椒直播基于golang的中台技术实践 – 周洋

周洋老师也是老面孔了，第一次出现在gopher大会应该是大表360做IM长连接的分享。听那一次分享自己几乎是跪着听完的，因为在那之前自己要解决的问题和场景跟其非常类似，只是碍于当时的人手和自己的技术栈储备，我没能做出周洋那样的方案和架构，而是用了一个比较trick的方案。晃眼间，4年过去了，周洋对于中台的思考又给了自己很多启发。感谢 GopherChina 这样的平台，感谢周洋老师的分享。

2.8 知乎社区核心业务 Golang 化实践 – 杜旭

作者分享了知乎从 python 迁移到 go 的历程。巧合的是，三年前，我们也做了同样的事情，同样是从 python 迁移到 go. 不过作者有几点做得比当时的我们更好：

  1. 在接口验证环节上，我们当时希望靠尽可能覆盖全面的单元测试和QA验证来保证；知乎在额外还引入了python和go版本的接口交叉校验。test case的丰富和覆盖程度应该比我们当年更好。
  2. 引入了静态代码检查。如果用强类型语言不适用静态代码检查，那么就损失了强类型语言一般的优势。道理都知道，但是碍于当时CI/CD流程不够完善，我们这个环节一直是缺失的。

注意

以上内容只是看完keynote以后的个人观感。因为没有去现场，细节肯定有所缺失，有些观点也未必跟现场同学的反馈吻合。希望后面放出大会现场视频以后，自己能够进一步完善以上内容。