今年本来没想着要去的，因为确实有点远，加上疫情之下不太方便，但是意料之外来了一张门票，那就必须去一下了，这次收获也不少，有了上次的经验，这次就听得很舒服，不像上次那样那么累了，这次能准确的知道什么应该仔细听，什么应该略过，所以这次的笔记就相对来说少一些，精炼一点。
这次去也面基了大佬，果然北京的都是大佬，都比我卷的厉害，以后还要多学习，哈哈哈，膜拜膜拜~
基于 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 有性能损耗，那就想办法手动减少了采样的时间
总结一下：整体优化过程就是一个问题的解决过程，中间有着各种思路，有的走了歪路，发现最后实现起来成本太高，有的很 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 把大量数据全部放在内存里面来加速搜索…）
- 直接监听 binlog 然后生成 json 格式数据，给 mq，然后 给集群消费，集群也可以全量做同步
- 建立索引加速查询
- 冷热数据交换
- 多级缓存
- 不同的淘汰策略
- 千万级内存对象，GC严重耗时，如何解决? 非常 hank 的方式直接将内存转到 c 里面避免 GC，然后通过 CGO 访问这些内存。这个思路真的可以，学到了。MemoryTile 然后在序列化和反序列化的时候定制了一把，即使是复杂的数据结构也可以。
- 优化链路，调用和下载链路分开，单个节点下载全量然后同步全网其他
- json 中的空值直接连 key 一起剔除，减少传输数据，这个也可以学到了。
- 尽可能将业务数据存放在内存中，做好冷热数据交换
- 主动监听数据的变化，并实时更新内存中的缓存数据
总结一下：利用 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 场，所以另外一边没有听到，不过也都是很不错的。
这次主要还是面基到了一起学习的小伙伴，小伙伴都非常厉害，也都非常努力的~ 希望下一次大会也能有幸继续参加吧，不早了洗洗睡了。
