今年本来没想着要去的，因为确实有点远，加上疫情之下不太方便，但是意料之外来了一张门票，那就必须去一下了，这次收获也不少，有了上次的经验，这次就听得很舒服，不像上次那样那么累了，这次能准确的知道什么应该仔细听，什么应该略过，所以这次的笔记就相对来说少一些，精炼一点。

这次去也面基了大佬，果然北京的都是大佬，都比我卷的厉害，以后还要多学习，哈哈哈，膜拜膜拜~

基于 Golang 构建高可扩展的云原生 PaaS 平台

端点 PaaS 介绍整个历程 主要是推 Erda，主要有以下几点个人觉得可以

  • 自定义 pipeline 开箱即用
  • 微服务治理 兼容 java 族（spring 那一套，还有 dubbo）
  • 可观察性数据采集

个人总结：写个这的一定是 java 过来的，autowired 很 java 味道

https://github.com/erda-project/erda

MOSN 云原生演进历程

MOSN 之前就有听说的，我觉得很像给 Envoy 加个 buff

  • CGO 并没有想的那么性能堪忧
  • 通过 hacker 的方式可以在调用链路中加一层 filter 实现
  • 想办法做到 zero copy 从 c 到 go 时减少内存拷贝，优化 1
  • 从 go 到 c 不能直接返回 go 中的内存，否则当 gc 时会导致 go 侧被回收，c 侧意外访问的问题
  • 非常 hack 的为每个 envoy 预留了 P 从而保证每个 G 来的时候都有 P，改 runtime，可以可以
  • 结构体内存对齐问题，没有细说，但是可以以后也是一个点

个人总结：让我之后可以尝试利用 CGO 来完成一些事情了，没有像以前一样那么抗拒它，并且提前知道了很多坑点

浅谈全链路监控: 从应用到数据库到 Runtime

所有演讲中我学到最多的一个，这个很值

从两个方面来评价这个：一方面是演讲能力，演讲者思路很清晰，并且可以将你代入整个优化和实现的思路，你好像亲身经历了整个优化过程，并且思路不快，你能很好的跟上，每一步衔接都很讲究；另一方面是整个选题贴近实际，整个实现思路很多是可以再别的地方相同类比的。

所以两个方面都是非常值得去学习的，果然大佬并不仅仅是技术牛，而且演讲能力也是一流。PS：PingCAP 好像每年都是干货。

  • 描述问题，当前链路追踪的问题有哪些？

  • 现在的开源方案有哪些实现，jaeger 确实挺好用的，基于现有的方案如何改进呢？

  • 其实普通的 trace 对于我们来说足够用了，因为他们是做数据库的 很多时候需要看到数据库内部执行的时候的链路，并非只看到最终执行的 sql 和 sql 执行时间就可以，还需要知道执行内部的链路方法调用等耗时，现在的 trace 没办法

  • 好像数据库是自己写的就有办法

  • 第一个想法就是加 tracerID 然后传递到 tidb 的内核里面

  • 但是显然还不够，还想知道是因为 go 调度的问题还是 sql 本身的问题

  • 于是想到 go tool trace，可以，但是开销大

  • 于是想到 hack runtime，就是改 runtime，前后加代码，可以，但是需要单独维护一个 go 分支

  • 于是想到 pprof，其中有个功能是 profiler label https://rakyll.org/profiler-labels/ 这个功能有点黑，可以再你的 pprof 上打标签，之前没有见到过，有了它就能给你就清晰到搞定你需要定制统计的 链路了，只需要将 label 随着 context 传递就可以

  • 全开 pprof 有性能损耗，那就想办法手动减少了采样的时间

    image-20210628234819590

总结一下：整体优化过程就是一个问题的解决过程，中间有着各种思路，有的走了歪路，发现最后实现起来成本太高，有的很 hank，最终找到了合适的思路。整体思路还是通过 context 传递 traceID 来实现整体链路的 trace，并且没有忘记初心。整个思路可以借鉴。

Improving Go Backend Developer Experience in Grab

因为我之前上一次已经听过一次 Grab 的分享了，这次的分享和上次有点重复，都是介绍在 Grab 里面代码生成和开发是如何的方便，在这不做赘述。

利用夜莺扩展能力打造全方位监控系统

这个之前我也听过，之前是秦大讲的，讲的很不错。整体夜莺确实对于监控领域来说是一个当前不错的开源解决方案。

我就说我在现场问的问题吧还有别人问的：

  • v3、v4 版本是从 Telegraf 的架构迁移到了 datadog 原因是：有 agent 里面多了 aggregator 这样客户端本地采集就优先对于采集数据做了一次降采样，这样上传的数据更加精炼
  • udp 端口如何做监控？因为如何直接访问，那么对于 udp 来说会影响业务，以为是别的正常请求，所以直接尝试 bind 这个端口如果说当前端口已经被 bind 则证明 udp 健康
  • 技术难点主要是在采集侧
    • 不确定的采集策略
    • 异构机型，不同语言
    • 传输压缩编码问题和错误重传问题

总结一下：对于我来说更多的是了解了 agent 上的设计思路，对于以后的采集相关的业务需求可能设计上会有新的考虑方式

Golang主动式内存缓存的优化探索之路

需要一个 极致的性能 内存缓存（当时就让我想到了 google 把大量数据全部放在内存里面来加速搜索…）

  1. 直接监听 binlog 然后生成 json 格式数据，给 mq，然后 给集群消费，集群也可以全量做同步
  2. 建立索引加速查询
  3. 冷热数据交换
  4. 多级缓存
  5. 不同的淘汰策略
  6. 千万级内存对象，GC严重耗时，如何解决? 非常 hank 的方式直接将内存转到 c 里面避免 GC，然后通过 CGO 访问这些内存。这个思路真的可以，学到了。MemoryTile 然后在序列化和反序列化的时候定制了一把，即使是复杂的数据结构也可以。
  7. 优化链路，调用和下载链路分开，单个节点下载全量然后同步全网其他
  8. json 中的空值直接连 key 一起剔除，减少传输数据，这个也可以学到了。
  9. 尽可能将业务数据存放在内存中，做好冷热数据交换
  10. 主动监听数据的变化，并实时更新内存中的缓存数据

总结一下：利用 cgo 去避免 GC 这个思路之前没有听过，学到了。期待开源。

如何用Go模拟CPU

利用 go 来实现了一个 CPU 的所有功能

整个演讲告诉我了一个道理：其实 CPU 的架构并没有你想象的那么复杂，它的功能也就是一个循环读取纸带而已~

演讲者有一句话经常提到：原话我忘记了，大概是说，概念都是人提出来的，有了概念才让事情变得复杂，当我们抛弃很多概念的时候事情就会变得简单。所以在整个演讲中，从一开始的没有几个单元，到后面每次追加一个概念，难度就提升不少。

对于硬件知识强大的大佬来说，应该挺有意思的。我嘛，其他听起来就有点难咯。

一开始的 bug 真的是一只飞蛾~

深入理解BFE

之前也听过 BFE 的演讲，这次主要是 https://github.com/baidu/bfe-book 从这里来的。同样也就不过多赘述。

基于Kubernetes的私有云实战

这个思路是利用 k8s 做个私有云，其实就是利用 k8s 去创建 pod，然后把 pod 做成和虚拟机几乎一模一样

  • 使用 FAT 容器，容器本身啥都带了
  • 网络方案使用的是 Macvlan 这个有点意思 我很想知道 macvlan 的缺点是什么，后面可能会详细出个博客写一下，有点东西（挖坑）
  • 集群方案是在所有 k8s 上套了一层调度层来管理调度，屏蔽 k8s 各类资源

遇到的问题

  • go 在容器内可以看到宿主机的 96 核，那会创建过多的 P M 导致调度时间长 （go.uber.org/automaxprocs）
  • Go不是NUMA友好的 没办法绑核
  • 宿主机负载不均衡，然后自己基于先有的 cpu 调度器改了一个自己的调度器，插上
  • 提问环节问道只能支持无状态的部署，有状态的就不行了

Go 如何助力企业进行微服务转型

将单体和微服务转型的，因为已经是微服务很多年了，当你也是从单体淌水过来的，里面的辛酸对比一清二楚，很有 b 数，毫不夸张，所以就不多说了

字节跳动在 Go 网络库上的实践

这个非常非常烧脑，虽然全程跟下来了，但是演讲者速度超快，真的很佩服这种思路清晰脑子好用的大佬，膜拜一下（回答问题的时候也是思路超级清晰）

主要是由于 go 原生的 net 包不满足需求，所以要做一个，net 包问题是

  • 难以探活
  • BIO 开销大

改造

改造成 netpoll 使用 epoll 改成事件，水平触发

优化调度

这里的分析很到位，分析出具体的瓶颈是在 read 上而非 handle 上

想办法优化系统调用，直接改 syscall 为 rawSyscall 去掉了 enter_runtime 和 exit_runtime

动态判断 msec 参数，加快调度速度（没事情就别占着位置）

优化 buffer

当前很多都是 ringbuffer 实现的零拷贝，但是容量有限制，扩容会成为瓶颈

所以使用无锁的 linkbuffer 来实现，syncPool 来复用节点，利用链表解决扩容问题，利用 atomic 解决 datarace

重新实现 readv 和 wirtev

高级特性

  • 单连接多路复用，这个太难了，没听懂….
  • 改了内核，增加了 multisyscall.read 方法将多个读合并为一个操作进行（我也想要一个内核组）
  • 使用 io_uring 做改掉原来的 epoll 实现异步调用

总结一下：想办法改 NIO，想尽一切办法优化调度，想尽一切办法优化 buffer，即找到关键瓶颈去做优化；这是我第一次觉得 BIO 和 NIO 模型讲解的如此简单…大佬牛逼

io_uring 后面可以仔细研究（挖坑）

无锁 linkedbuffer 实现可以（挖坑）

总结

这次大会我自己明显感觉到和之前那次不一样，之前那次我算是理解并不深入，所以很多东西都需要听，输入量巨大；这次很多知识点都明白了，也就听的很顺利，之前就是讲师提到一个点我记下一个点，现在是提到一个点我就点点头表示已经知道了。

整个大会上还有其他几个讲师的内容也很不错，因为分了 AB 场，所以另外一边没有听到，不过也都是很不错的。

这次主要还是面基到了一起学习的小伙伴，小伙伴都非常厉害，也都非常努力的~ 希望下一次大会也能有幸继续参加吧，不早了洗洗睡了。