2023 年过去了，我不想怀念他。

这篇 2023 年的总结终于在 2024 年中旬开始动笔。一部分原因是由于懒惰，主要原因是由于这一年来属实精力捉襟见肘，抽不出大块的时间让我回首这一年的点点滴滴，临近毕业我终于可以开始动笔这一年的流水账，回首这段忙里偷闲的日子。

2023 年作为我人生的又一个关键节点，这一年中走的每一步都影响着但我走出校门迈入社会时到底要走向何方。面对这种关键又没有足够的把握的时刻时，往往都选择尽自己的最大努力而为，虽然往往就结果而言，最终取得的结果对我个人而言还算满意，但不免让人活得很累。以至于我一直深陷一件又一件需要投入精力的事情，无暇开始编辑这篇流水账。

就如上文所言，今年的大部分精力都被我投入到了找工作这件事，毕竟我这小镇做题家（还是比较垃圾的那种）寒窗 19 载（6+3+3+4+3）就是为了能找一份比较体面的工作，当一个比较体面的牛马。所以对于找工作这件事我还是投入了近 100%的精力。

从 2022 年底忙完毕业设计的开题，就开始着手投递实习，想要在寒假期间找一份实习，这时候我的准备还比较粗糙，虽然当时 leetcode 刷了一部分，但临场手撕还是会大脑空白，八股也只是潦草一看，东一榔头西一棒槌地看。不过比较幸运的是，我只面了两家就拿到了 SmartX 的实习 offer，虽然工作的部门是 SRE，但当时这家公司对我来说是带有光环的，我一直觉得这家公司是以技术见长的公司，当时想要走基础架构方向的我，对这样的初创还是抱有幻想的，加之当时公司同意我可以先线上实习，所以很愉快地接了 offer。

但不幸的是在 SmartX 的工作实在让我提不起兴趣，当是我在天心哥的带领下，基于 cgroup 开发一款可以对系统中的服务进行资源限制和监控的程序，当时基于的技术非常很底层，我需要从头了解 cgroup 的一些基本原理，Linux 中对 cgroup 技术的应用，导致我上手初期十分头大，开始开发后不仅功能测试困难，而且对于程序是否能正常运行我也是没什么信心的。好在我当时的任务压力并不大，加之当时已经准备跑路了，所以我每天的稍微做一些工作就开始摸鱼🐕（当时公司有一个可以站着办公的长桌，我当时特别喜欢站在桌子旁摸鱼，因为背靠窗户，没人知道我在干嘛）。就这样混到了二月底，负责的工作初见成效，我便找了个借口提了离职，准备回学校全心全意准备暑期实习的事宜，其实当时也可以留在 SmartX 转正，但当时我由于 2022 的开源经历，对云原生和开源充满了热情，想着有机会可以去阿里云继续做开源，所以很干脆地提出了离职。

回校之后，我便开始忙于刷题与背八股，希望在暑期实习阶段可以斩获满意的 offer。当时我憧憬着可以去阿里云的 KubeVela 组实习，后续如果秋招顺利的话，便可以留在这里开始我开源生涯，一想到可以全职做开源便不由觉得这样的工作太酷了。但当我觉得已经准备地足够充分将简历发给天元的时候，收到的却是噩耗：我的第一学历不足以让我通过阿里的简历筛选，即使投递的是实习岗位，这也意味着我的校招将和阿里彻底无缘，这个情况还是很让我焦虑的，因为当时女友已经先一步去了杭州工作，作为杭州互联网中心的阿里，无疑是我去杭州最好的选择，但无奈天不随人愿，经过向多个前辈的确认这件事的真伪后，我也不得不接收这个现实，好在我当时调整的还很快，没有过多纠结这个坏消息，很快投入到了其他公司的简历投递中。

不过没机会去阿里这件事现在看来也算是塞翁失马了。

我第一个面试也是第一个拿到的 offer 来自于快手的容器云部门，当时我的面试水平虽然比年初投递字节时好了很多，但是还是很菜，记得快手一面的时候对方给我出了一道二叉树相关的简单题，但我当时没想法厚着脸皮让对方换了一道，好在顺利的是最后顺利通过，二面也很随意，最终在 4 月初拿到了 offer。由于是第一个 offer，而且当时我由于顺利拿下了第一个 offer，所以对自己开始有了一定的信心，便和对方 HR 说了很多漂亮话把 offer 稳了下来，把它当作备胎继续骑驴找马，又继续投递了美团、百度、腾讯等国内一众国内互联网。比较幸运的是，我的简历相比于其他同学有两端实习经历，加之阿里的开源经历，所以面试时有 20-30 分钟的时间都是在和面试官聊项目，这样问八股的时间便比较少，所以面试的时候还算顺利，差不多在 4 月底的时候又拿到了美团和百度的 offer。后面我又集邮式地面试了腾讯、拼多多、Amazon 和 PayPal，最终拿到的 offer 一共有 5 个，在咨询了之前阿里的导师阳哥的意见后，选择接了美团的 offer，拒掉了百度、快手、Amazon 和 PayPal 的 offer。

具体的面试经历可以参考我的这篇博客：一名2024届毕业生的求职日记（暑期实习）

当时选择美团的 offer，一个原因是考虑到美团的转正率比较高，秋招的时候算是有一个保底的选择；另一个是当时我对做基础架构方向充满了向往，觉得一直做技术很酷。还有一个情况是，如果接了实习 offer 最后毁约不去，美团会直接拉黑对方，秋招没法再投递了，所以接了美团的 offer 之后我便没有继续邮递了。

现在看这个选择其实也不能算有很大的问题，抛出美团实习体验不佳之外，快手实习强度大，百度做的是业务方向，Amazon 和 PayPal 这两家外企，如果不想实习转正去的意义也不大。

现在想来，说实话我的暑期实习面试不能不说顺利，首先我选择的语言和赛道都非常小众，我的主力语言是 Golang，投递的主要方向是云原生。对于业务岗来说，相比于 Java 的海量岗位，和 C++的万金油，Golang 是一个被大家（学生）劝退的语言。基础架构方向，会设置一些 Golang 相关的岗位，但这些岗位不但只有大厂开设，而且竞争激烈，还要面临“职业选手”的竞争（有的实验室专门做相关方向），这导致我研一研二都在焦虑，要不要再学一个 Java 保底，虽然很焦虑但最后还是坚持走下来了，并且还通过了 Amazon 和 PayPal 这种机会屈指可数外企的面试（外企的工作氛围和国内互联网相比是真的无敌，奈何 23 年还处在 22 年裁员的余波之中，不太敢赌这种公司还能在国内活多久）。

BYR 论坛一篇很火的云原生的劝退贴：云原生劝退长文，秋招暴毙实录

虽然拿到实习 offer 让我很高兴，但后续暑期实习的那段时间，我真的算不上开心，我在美团实习时所在的组是：基础架构部-基础软件中心-弹性系统组（目前由于美团组织架构调整，已经改了名字），组内主要包含三个小组，我们小组开发和维护基础容器中运行的容器 Agent 软件，以及基于 Dragonfly 开发的镜像分发软件。我负责跟着晓凯和智凯参与开发容器 Agent，当时美团内部将容器分为轻容器和富容器两种，富容器可以看作容器化的虚拟机，从虚拟机迁移到容器的成本低，但基础进程和业务进程在一个环境中运行，会导致二者互相影响，所以美团内部想要把容器模式迁移至业务进程和基础进程隔绝的轻容器模式，这被认为是一种更为优雅的模式，我实习的那段时间目前正处于容器范式的迁移进程中。

这段实习经历给我的感触很深，也让我重新反思自己的职业生涯该如何选择。在美团的工作不同于跟着阿里那边做开源，是两种完全不同的模式和工作，开源软件开发中上层用户的话语权没那么重（至少不是爸爸级别的），不需要对所有的用户负责。但在企业中做基础架构开发，你需要对你所有业务客户负责，极度关注软件的稳定性，极度关注软件的性能损耗，负责响应业务客户的诉求，负责解决业务客户的问题，新增功能的重要性远低于软件稳定性的重要性。所以基础架构部门的工作中开发和 oncall 的比重不相上下，每开发一个功能都需要担心会不会造成事故，代码写的和走钢丝一样 🐶 。

这个时候我已经开始反思自己了，我一直不是一个很细心的人，基础架构岗位中这种几乎不能出错的要求对我来说压力很大，我开始思考自己是否适合这种岗位。

而且！当时美团正处于富容器到轻容器的过渡阶段，想把集群中的容器范式迁移至轻容器，以达到降本增效的目的，但这种大规模的重构无疑面临着包括同时维护两套代码，解决无数的 dirty work 等等任务，当时对于一个实习生来说 cover 目前的代码逻辑（大量适配的补丁代码）已经不是一件容易的事了，更别说开发新的功能并且考虑到代码在各种场景下的适配问题。加上当时的 ld 喜欢 PUA 我，当时我一边实习一边忙于导师的项目，因此需要每周请一天假，ld 对此很不满意，便用转正名额的问题来敲打我。我当时初入职场，对于这种鞭策还没能一眼识破，后续又从其他同事那里得知了部门内部的一切潜规则，遂对该部门很失望，对留在美团转正完全没热情。另外由于美团距离我们学校实在太远，美团打车要一个多小时才能到达位于望京的美团，每天接近三个小时的通勤让我本就因为上班疲惫的身体雪上加霜，每天感到特别疲惫，甚至萌生了去国企养老的想法，不过现在当时特别疲惫应该是新冠的后遗症带来的负面影响（但当时的糟糕体验真的让我萌生了对互联网的抵触，也影响了我秋招时的选择）。

奥对，我当时下班之后，还有帮我导师做他那个破项目，忙到晚上 12 点。

8 月中旬实习满 3 个月之后我便赶紧离开了美团，开始为后续的秋招做准备，当时急于离开的原因时已经有很多公司开始了提前批的招聘，甚至腾讯和字节的 HR 已经联系到了我，并跟我约了面试的时间，这两个公司也是我后面比较顺利拿到的 offer 中的两个，我想能比较顺利的通过面试也和当时面试候选人比较少，hc 尚且充足有很大关系。

我的秋招考虑到女朋友的原因，所以我只投递了杭州的公司，不过好在杭州的几个大厂（腾讯、字节、快手、华为、滴滴）都给了我面试的机会。腾讯和字节是两个最先找我约面试的公司，腾讯的是 CSIG 的数据库部门，负责数据库内核开发和其上的一些管控组件的开发，如果我最后入职应该也是做一些管控层面的开发，因为我对数据库内核确实是一窍不通。面试流程是我经历过最长的流程，4 面技术面+1 面 HR 面，好在我的实习经历帮了我大忙，当时的我算上阿里的经历已经可以算 4 段实习经历了，每次面试自我介绍+项目经历就会耗时 40 分钟左右，稍作八股考察再加一道算法题时间就到了，自然也不会暴露出太多的问题，一次面试也就顺利通过了。而字节的面试就稍微坎坷了一些，我遭遇了一次转部门的波折，我首先面试的是抖音的风控部门，面试经历了三面（最后一面让我写一个开放的问题，我当时真的没有任何思路，自知凶多吉少，感叹字节的难度确实高），后面被转到了抖音的创作者部门，本来我没抱多大希望（因为是转到新的部门，上一个部门没要，下一个部门要的希望也不大，没人会要其他人不要的东西吧），结果却峰回路转，上午面试完下午便被 HR 加了微信，然后经过一个简答的 HR 面，便给发了意向。有趣的是，当时 HR 面的时候，我表达我想去杭州而不是在北京的时候 HR 表示十分吃惊（因为以北邮的学历留在北京是有单列落户的户口资格的），但我却果断放弃了北京的选项。

由于北邮校园太小，找不到安静的房间面试，大家只能在寝室面试，8-9 月寝室每天都是被面试日程排满的。

后续我又参加了包括百度、滴滴、快手、华为、虹软等公司的面试，很幸运地拿到了百度、虹软和华为的 offer。百度和华为的面试体验还很不错，百度捞我的是音视频中台部门，面试官十分友，（二面是一个女组长，很温柔，三面的主管也比较随和，和我聊了很多有关规划、未来的话题）只是之后的工作可能涉及对老的平台做优化重构，以实现降本增效的目的，在美团经历过老代码重构的我对于这种工作可谓之避之唯恐不及，所以面试之后便没太关注。

而华为我投递的部门是华为云，我觉得国内除了阿里云以外，还有哪家云做的还像那么回事的话，那就是华为云了，华为对于云的投入不想腾讯那么犹疑，而且在 toG 市场华为的认可度很高，此外华为云在云原生的开源领域也有几个十分有名的项目，并且 HR 表示作为校招生也有机会去做相关项目的开发，这不禁又唤起了我对参与开源的向往，有趣的是当时最后的主管面，华为的主管看到我参与过 KubeVela 的开源建设，便问我关于这个项目的看法，并表达了自己对于这个项目的看法，现在看来他的看法真的非常精准，不由得让人佩服。这里就不由得不提及目前 KubeVela 的现状，项目冲击 CNCF Incubation 成功之后，阿里便渐渐放弃了对该项目的投入，社区的中的讨论变少，issue 的回复效率变低，项目组的核心成员也各奔东西，这件事让我觉得十分震惊，也让我意识到开源项目的商业化是多么困难的一件事，在目前的经济下行的周期内，技术、开源这种作为成本的物料完全会因为公司的一声令下而被抛弃，相比较之下业务方向反而是更稳妥的一种选择（如果还算是一个靠谱的业务的话）。

秋招的历程更像是一段马拉松和摔跤比赛，与体力、耐心、焦虑的比赛，过程中需要不断抵抗来自网络的焦虑，面对面试失利不断鉴定自己的信心，不断学习补齐暴露出的不足，在一场又一场的笔试和面试中做到更好。

详细的面试经历可以参考我的这篇博客：一名2024届毕业生的求职日记（秋招）

好在功夫不负有心人，历经近两个月的苦战，10 月中旬各家公司陆续发放 offer 并开始谈薪，最先开奖的是美团，不出我所料，美团给我了一个白菜价，我也十分干脆地拒绝了这份 offer，这份 offer 的价格以及美团的组内氛围实在没什么让我值得惋惜的。

后续又是漫长的等待，下一个为我给出 offer 薪水的是腾讯，算是一份不高不低的 offer，基础薪资比美团多 1 k，外加 4 k 的房补，算是一份在我心理预期之内的 offer 了，但人性都是贪婪的，我也不意外，我想观望一下字节薪资再做决定，所以我去催促了一下字节的 HR，希望他近期可以给一个结果，在我的反复催促下字节 HR 给出了字节的答案，基础薪资比美团多 8 k，是一份远超我预期的 offer，因为我事前和 HR 沟通的时候，我报出的价格甚至比这个少 2 k，所以我觉得这个价格让我觉得对方很有诚意，我也没做过多考虑便接下了这份 offer，事后看来当时的决定还是太过草率了，因为还收到了比眼下更高的 offer。

接下了字节的 offer 的同时，我和腾讯的 HR 表达了对 offer 薪资不太满意的想法，对方没说什么只是跟我说他向上反馈一下，让我耐心等待，又过了一周左右，幸福的烦恼落在了我身上。腾讯的 HR 跟我联系并给出了新的薪资，新的 offer 不但基础薪资和字节拉平，还多出了 4 k 左右的房补以及额外的股票和签字费。此外，华为的 HR 在咨询了我目前手上的 offer 情况后，也给出了一份基础薪资高于字节 offer 3 k，并且这份 offer 的职级给到了 15 级，这份 offer 真的很让我心动，真的是狠狠心动了，原有有以下几点：首先，因为就如我前文所说的，如果去华为那么可以继续做云原生基础架构相关的工作，还有机会做开源相关的工作；此外，华为的裁员压力也没有那么大；并且华为的薪资和职级给的很有诚意。如果是没有经历过美团实习的我肯定会义无反顾地接下了这份 offer，但现在我的心境发生了变化，我开始考虑更多的因素：“选择云原生、基础架构方向的工作是否适合我？”、“华为云的工作压力是否适合我？”。在纠结了这两点之后，我最终还是选择不舍地放弃了华为的 offer，直至今日落笔之时我还是会有点惋惜放弃这份工作，但人生没有那么多后悔的机会，也没有什么选择可以两全其美，只能说塞翁失马焉知非福走好目前的路才是我应该做的。此外我拒绝华为的原因还有很重要的一点，华为这份 offer 需要我去上海青浦报道，这是华为新建成的华东中心，集团的意志便是希望员工转岗到此，但我由于女朋友的因素去杭州的意向无比强烈，所以对于去上海还是很抵触的。

说起为了女朋友去杭州，就不得提起我今年在感情上的一系列变故，这个话题至今我都是不想面对的，因为直至现在我都没能处理好这件事。写至此处有很多话想说，但却不知从何下笔…

一言概之便是，这段感情面临一些来自现实因素的考验，让我对这段感情能否有一个圆满的结局没了信心，所以我做了一个决绝的决定提出了分手，但问题不出在我们两人身上，感情的牵绊两个人都无法割舍，说不清的羁绊下两个人又重新走到了一起，只是没有了原来的名分，在开启下一段感情前做填补彼此空白的 Parterner。但其实我们都知道，两个人只是两头不愿接受现实的鸵鸟。只是作为这段波折的始作俑者，我其实一直觉得很对不起对方，尤其是曾经她可以选择老家的岗位，也是为了和我在一起选择了杭州的工作。但我最终没能履行当初的约定。

在感情上出现波折后不久，中期答辩结束后，我便去到了杭州实习，这里也将是我接下来一段时间将会生活和工作的城市，我从来没想过会来杭州，就像我当时来北京读书前从来没想过一样。杭州这个城市对我来说不好不坏，它没有北方的粗犷，多了一份江南的温软，如果它的阴雨天可以少那么一些的话，我会多喜欢它一分。

实习的生活也不好不坏，工作有挑战性但不多，组内同事相处的也还算融洽，ld 相比之前在美团的要好不少，但能力欠佳的产品和自以为是的测试却让我忍不住骂人。我实习了近 5 个月（直至今天），也是忽然就过了那么久，组内的工作强度让我觉得满意，1095 的节奏，加上 5 分钟的通勤时长，在工作之余为我省去了很多不必要的疲惫，甚至中午还可以回家午睡一小时。

但听说字节的华东总部要建好了，到时候可能就要换一个工区了，所以我格外珍惜当下的工作氛围。

这一年我感觉过的很快，甚至觉得有点浑浑噩噩，一直在被一件又一件事情推着走，期待有片刻的安宁，有了机会休息却又觉得什么都没做休息日就结束了，我将这种状态归结为：缺少内心的安宁。我是开始迷茫了吗？我真的有这种感觉，活了 20 多年，我的梦想和对自己的期待一直在缩小，高中时候我有傻傻的远大的理想，大学时我的目标明确和可靠，但随着我离社会越近，我更清楚地认识到这个世界，我却越不知道自己以后应该为什么努力。我清楚自己想要改变世界、成为伟大的人、做出一番大事业已几乎是不可能的使，现在甚至是自由自在都变得那么困难。常听张雪峰说要以终为始，但随着我的理想不断修正，可能我已经和最初的终点渐行渐远，我只期待好好过完我的一生，守护好身边的人，但就这么简简单单的一个愿望，实现起来也并不容易。

我变得焦虑，开始怕走错每一步路，就像前面提到的我每次都要尽自己最大的努力去做。今年我又将士兵突击看了一遍，也许不是所有人都喜欢这部 10 多年前的军旅电视剧，但是我真的从中看到了很多剧情之外的东西，我很羡慕许三多的安分与不焦虑，无论是身处什么环境，都是那么的始终如一。初中的时候老师们总说我坐不住板凳，说我耐不住寂寞，心静不下来，这么多年下来看来我还是这样。

我常跟人说：“人贵有自知之明，我很讨厌对自己没逼数的人“，但我其实也知道，我对自己的认知也并不完全准确，不过我一直在修正对自己的认知。这么多年过去，我清楚地认知到我并不是特别聪明，也算不上多么优秀，这一年我见识了太多比我能力更强的同辈和前辈，望其项背；我清楚地认识到我不够细心和仔细，需要付出更多的精力专注做好事情不出错。

这一年的点点滴滴又让我对自己有了更清楚的认知。我认知到自己是一个勇于认错，但很少能拿出努力去改变自己问题的人，我这一点很容易让身边人失望；我认识到我并不算一个特别理性的人，我也有感性的一部分，我也会因为情绪上头做一些不冷静的事，说一些不冷静的话，很容易伤到人；我是一个没什么耐心的人，很容易不耐烦。

对我自己的分析，待续

写到此处，对我这一年做个总结吧。

• 参加笔试：8 次
• 参加面试：37 次
• 拿到 offer：5 个（暑期实习）+ 7 个（秋招）
• 实习：3 段（12-2 月、5-8 月、12 月-4 月）
• 新城市：青岛、杭州、嘉兴、长沙
• 新书：0.2（两本书，但都是草草看了一点）

回首看自己 2022 年总结中对 2023 年的展望，可以说完全没达成自己的计划（虽然这种计划基本都很难实现）。2022 年我说不想把自己逼得太紧，但还是忙忙碌碌度过了一年；2022 年我说想技术上再深入一点，这方面基本没什么进展，除了八股背的贼溜，其他非功利的技术基本没涉猎；2022 年我说想看点闲书，结果买的那本《北上》也只是翻开过一次。

即将迎来 2024 年，生活将开启新的篇章。在新的城市开始未知的新生活，我既没有太多的期待，也没有太多的恐惧，只希望工作不要太坎坷，不要太忙碌，心能稍微宁静一些，有一些时间思考自己的方向。如果可以的话，我希望能够补救一下 2022 年的那些未完成的计划。

通过

其他

快手容器云二面（2023-9-25）

1. 自我介绍
2. 介绍美团的实习经历
3. 详细介绍两个项目
4. 介绍 kubevela 的开源经历
5. 介绍 openkruise 的开源经历
6. 介绍 smartx 工作
7. 介绍 cgroup
8. cgroup 和 namespace 的关系和区别
9. 如果限制一个进程使用的 cpu 核数
10. cpu_quota 的原理
11. k 8 s 调度器流程
12. 是否有自己做过调度器和 apiserver 的二开
13. webhook 原理
14. csi & cni 原理
15. pod 创建时是如何分配 ip 的
16. 是否了解设计模式
17. 设计时如何提升程序扩展性
18. 做题: 复制带随机指针的链表

滴滴一面（2023-9-25）

1. 自我介绍
2. 美团实习经历介绍
3. kubevela 开源经历
4. openkruise 开源经历
5. smartx 实习经历
6. 采集了哪些指标
7. cgroup v 1 v 2 区别
8. k 8 s 中创建 deployment 的流程
9. 做题: 链表倒数第 n 个节点

虹软服务端二面（2023-9-21）

1. 做题：二分查找（递归和迭代两种做法）
2. 做题：二叉树中查找公共父节点
3. 物理题

字节创作者四面加面（2023-9-13）

1. 自我介绍
2. TinyKV 架构设计以及实现
3. 数据同步是如何实现的
4. MySQL 的主从复制是如何实现的
5. 为什么一定要使用 Raft 协议
6. 是否实现了分布式的共识
7. 是否存在数据落后的情况
8. 从节点数据落后情况下，如何解决？
9. 是否了解 Go 中的 sync.ones
10. 做题：SQL 题
11. 做题：最长递增子序列

腾讯云数据库管控四面（2023-9-7）

1. 觉得自己前面面试有什么答得不好的地方吗
2. 前面的面试官有什么问题，当时答得不好，后面回去了解过了吗
3. 还有什么公司在面
4. 对于 base 有什么期望吗
5. percolator 算法分布式事务实现原理
   6. cockroachDB 如何优化分布式事务
   7. 如果两个事务发生死锁如何处理，回滚事务的开销太大，如何不会滚
6. kubernetes 提交一个 statefulset 会发生什么
7. 了解 cgroup 底层是如何限制 CPU 的吗
8. 如何解决 CPU 长时间占用的问题
9. 了解操作系统中常用的 CPU 的调度算法吗
10. 可以来提前实习吗

快手容器云一面（2023-9-6）

1. 自我介绍
2. 美团容器设施架构
3. 容器模式的设计思路
4. 容器 agent 与其他组件的耦合程度，是否依赖其他组件
5. 容器控制面失效会怎么样
6. 容器 agent 版本异常兜底是怎么实现的
7. 对于 sidecar 容器美团这边是如何限制他的资源
8. 为什么不采用业务服务和基础组件在一个镜像中的模式
9. openkruise 中镜像预拉取是怎么实现的
   10. dragonfly 是怎么实现的有了解过吗
10. pod 的创建过程是怎样的
11. operater 的 informer 机制原理
    13. informer watch 的时候如果失败了应该怎么做
    14. informer watch 返回版本过老应该怎么处理
12. kubernetes 资源限制的实现原理
13. cgroup 原理
14. 对于一个容器如果限制他的资源是 1 C 1 G，那么实际上 cgroup 是怎么操作的
15. 1 C 是怎么限制的
16. 如何限制 CPU 调度到哪个上核上
    20. 了解 numa 吗
    21. numa 中 cache 的
17. free 命令返回的指标都是什么含义
18. 做题：反转链表

虹软云服务端一面（2023-9-6）

1. 自我介绍
2. goroutine 的原理
3. go 垃圾回收机制
4. 一个新的 goroutine，是如何决定使用放到 gmp 全局队列还是本地队列的
5. 一个新的 goroutine，是如何决定分配到哪个 p 的队列中
6. goroutine 的状态有哪些
7. 哪些操作会使 goroutine 陷入阻塞，之后运行时会进行哪些操作
8. 自旋锁和互斥锁的区别
9. CAS 的原理
10. CAS 有什么问题，一定会保证并发安全吗
11. 手写快排
12. 大文件外部排序去重思路
13. redis 如何解决数据不一致的问题
14. mysql 有哪些存储引擎
15. 什么是事务
16. 什么是存储过程

字节内容安全三面（2023-9-6）

1. 自我介绍
2. 介绍一段项目经历
3. 遇到的问题
4. kubevela 的经历介绍
5. 一道智力题
6. 两道 SQL 题
7. 一道设计题

百度音视频中台三面（2023-9-4）

1. 自我介绍
2. 美团实习的项目经历
3. Kubevela 项目经历
4. 开放性问题：如何看待现在大家这么卷
5. 如何看待百度
6. 对 chat gpt 如何看待
7. 介绍自己使用的场景
8. 是否了解他的原理和机制

腾讯云管控三面（2023-8-31）

1. 自我介绍
2. 做题：
   1. 对称二叉树
   2. 402. 移掉 K 位数字
   3. 386. 字典序排数
3. 第 1 道题，空间复杂度
4. 第 3 道题，是否可以使用 channel 优化
5. channel 原理
6. go 垃圾回收原理
7. go 内存分批原理
8. 会不会有内存碎片的问题
9. 美团 Hulk 团队工作内容
10. 工作是否涉及到了跨地域路由

百度音视频中台二面（2023-9-2）

1. 自我介绍
2. 介绍项目经历
3. 介绍对方部门工作
4. Go 语言并发设计
5. 协程和线程区别
6. Redis 哨兵集群
7. MySQL 索引种类
8. MySQL 索引总是需要回表吗
9. 做题：二叉搜索树转双向链表

京东零售一面（2023-9-1）

体验极差，不爱别伤害

1. 美团实习的工作
2. 对联合索引的理解
3. 两张表联查，是先查询第一个表然后再查第二个，还是两张表 join 之后查询
4. 翻页查询一个超大表，怎么对查询优化
5. Redis 缓存击穿、缓存雪崩、缓存穿透
6. 推荐我使用 Java，说这样路子广一点，言下之意说我现在语言选择的不行，给我挂了

百度音视频中台一面（2023-8-31）

1. 自我介绍
2. 实习经历介绍，学到了什么
3. Go 中 map 以及 sync.map 原理
4. Go

字节内容安全二面（2023-8-30）

1. 自我介绍
2. 介绍一个项目
3. 遇到的困难如何解决的
4. Redis 如何做分布式缓存相关
5. Redis 如何做到那么高效
6. 做题：一道 SQL
7. 做题：最长无重复子序列

腾讯云管控二面（2023-8-25）

1. 自我介绍
2. 全程项目

字节内容安全一面（2023-8-24）

1. 介绍实习经历
2. 是否遇到了问题，怎么解决的
3. go slice 原理
4. go slice 是否是并发安全的
5. 多个协程 slice 并发写入的问题
6. mysql 的隔离机制
7. rc 和 rr 的区别
8. 做题：股票买入的最佳时机，要求输出买入点和卖出点

腾讯云管控一面（2023-8-21）

1. 自我介绍
2. 做题：二叉树的最大深度
3. GMP 模型
4. Go 的垃圾回收机制
5. mysql 事务特性如何实现的
6. 为什么有 redolog 还要有 binlog
7. 操作系统的内存管理
8. linux 可以更改页的大小吗
9. 32 位机器和 64 位机器最大的内存
10. 用户空间可以访问全部的内存吗？（这里没答上）
    1. 32 位
    2. 64 位
11. TCP/IP 模型
12. TCP 存在的问题&QUIC 如何解决的
13. TCP 可靠传输实现
14. vela top 工作内容
15. 反问

• panic 能够改变程序的控制流，调用 panic 后会立刻停止执行当前函数的剩余代码，并在当前 Goroutine 中递归执行调用方的 defer。
• panic 只会触发当前 Goroutine 的 defer，panic 允许在 defer 中嵌套多次调用；
• recover 可以中止 panic 造成的程序崩溃。它是一个只能在 defer 中发挥作用的函数，在其他作用域中调用不会发挥作用；

数据结构

1
2
3
4
5
6
7
8
9
10

type _panic struct {
argp      unsafe.Pointer
arg       interface{}
link      *_panic
recovered bool
aborted   bool
pc        uintptr
sp        unsafe.Pointer
goexit    bool
}

1. argp 是指向 defer 调用时参数的指针；
2. arg 是调用 panic 时传入的参数；
3. link 指向了更早调用的 runtime._panic 结构；
4. recovered 表示当前 runtime._panic 是否被 recover 恢复；
5. aborted 表示当前的 panic 是否被强行终止；
6. pc 程序计数器；
7. sp 堆栈指针；
8. goexit 是为了配合 pc 和 sp 修复 runtime.Goexit 带来的问题引入的；

原理

defer

defer 是一个面向编译器的声明，他会让编译器做两件事：

1. 编译器会将 defer 声明编译为 runtime.deferproc(fn)，这样运行时，会调用 runtime.deferproc，在 deferproc 中将 defer 挂到 Goroutine 的 defer 链上；
2. 编译器会在函数 return 之前（注意，是 return 之前，而不是 return xxx 之前，后者不是一条原子指令），增加 runtime.deferreturn 调用；这样运行时，开始处理前面挂在 defer 链上的所有 defer。

deferreturn 会先判断链表有没有 defer，然后 jmpdefer 去做 defer 声明的事情。

panic

编译器会将关键字 panic 转换成 runtime.gopanic 该函数的执行过程包含以下几个步骤：

1. 创建新的 runtime._panic 并添加到所在 Goroutine 的 _panic 链表的最前面；
2. 在循环中不断从当前 Goroutine 的 _defer 中链表获取 runtime._defer 并调用 runtime.reflectcall 运行 defer 函数；
3. 如果循环退出，则调用 runtime.fatalpanic 中止整个程序；
4. runtime.fatalpanic 实现了无法被恢复的程序崩溃，它在中止程序之前会通过 runtime.printpanics 打印出全部的 panic 消息以及调用时传入的参数；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

func gopanic(e interface{}) {
gp := getg()
...
var p _panic
p.arg = e
p.link = gp._panic
gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))

for {
d := gp._defer
if d == nil {
break
}

d._panic = (*_panic)(noescape(unsafe.Pointer(&p)))

reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))

d._panic = nil
d.fn = nil
gp._defer = d.link
        
        ...
        
        pc := d.pc
        sp := unsafe.Pointer(d.sp)

freedefer(d)
if p.recovered {
gp._panic = p.link
for gp._panic != nil && gp._panic.aborted {
gp._panic = gp._panic.link
}
if gp._panic == nil {
gp.sig = 0
}
gp.sigcode0 = uintptr(sp)
gp.sigcode1 = pc
mcall(recovery)
throw("recovery failed")
}
}

fatalpanic(gp._panic)
*(*int)(nil) = 0
}

recover

到这里我们已经掌握了 panic 退出程序的过程，接下来将分析 defer 中的 recover 是如何中止程序崩溃的。编译器会将关键字 recover 转换成 runtime.gorecover：

1
2
3
4
5
6
7
8
9

func gorecover(argp uintptr) interface{} {
gp := getg()
p := gp._panic
if p != nil && !p.recovered && argp == uintptr(p.argp) {
p.recovered = true
return p.arg
}
return nil
}

该函数的实现很简单，如果当前 Goroutine 没有调用 panic，或 panic 已经被 recover 恢复过了那么该函数会直接返回 nil，这也是崩溃恢复在非 defer 中调用会失效的原因。

在正常情况下，它会修改 runtime._panic 的 recovered 字段，runtime.gorecover 函数中并不包含恢复程序的逻辑，程序的恢复是由 runtime.gopanic 函数负责的。

二者配合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

func gopanic(e interface{}) {
...

for {
// 执行延迟调用函数，可能会设置 p.recovered = true
...

pc := d.pc
sp := unsafe.Pointer(d.sp)

...
if p.recovered {
gp._panic = p.link
for gp._panic != nil && gp._panic.aborted {
gp._panic = gp._panic.link
}
if gp._panic == nil {
gp.sig = 0
}
gp.sigcode0 = uintptr(sp)
gp.sigcode1 = pc
mcall(recovery)
throw("recovery failed")
}
}
...
}

当 gorecover 设置了 p.recovered，gopanic 便会执行 p.recovered=true 对应的分支，它从 runtime._defer 中取出了 defer 的程序计数器 pc 和栈指针 sp 并调用 runtime.recovery 函数触发 Goroutine 的调度，调度之前会准备好 sp、pc 以及函数的返回值：

recovery

1
2
3
4
5
6
7
8
9
10

func recovery(gp *g) {
sp := gp.sigcode0
pc := gp.sigcode1

gp.sched.sp = sp
gp.sched.pc = pc
gp.sched.lr = 0
gp.sched.ret = 1
gogo(&gp.sched)
}

runtime.recovery 将调用 defer 的 pc 和 sp 设置到了当前 goroutine 的 sched 上，并且将 ret 设置为 1，然后执行 gogo 调度。

从 runtime.deferproc 的注释中我们会发现，当 runtime.deferproc 函数的返回值是 1 时，编译器生成的代码会直接跳转到调用方函数返回之前执行，

根据我们之前的在 defer 章节的论述（编译器会在函数 return 之前，增加 runtime.deferreturn 调用。

因此，程序会跳转到 runtime.deferreturn 调用，runtime.deferreturn 会开始处理下一个 defer，直到 defer 的链表为空，继续执行程序的正常流程，也即是退出。

小结

无法捕获的 panic

内存溢出

1
2
3
4
5
6
7
8
9
10
11

func main() {
defer errorHandler()
_ = make([]int64, 1<<40)
fmt.Println("can recover")
}

func errorHandler() {
if r := recover(); r != nil {
fmt.Println(r)
}
}

map 并发读写

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

func main() {
defer errorHandler()
m := map[string]int{}

go func() {
for {
m["x"] = 1
}
}()
for {
_ = m["x"]
}
}

func errorHandler() {
if r := recover(); r != nil {
fmt.Println(r)
}
}

栈内存耗尽

1
2
3
4
5
6
7
8

func main() {
defer errorHandler()
var f func(a [1000]int64)
f = func(a [1000]int64) {
f(a)
}
f([1000]int64{})
}

对于栈不熟悉的同学可以看这篇文章： 一文教你搞懂 Go 中栈操作 。下面我简单说一下，栈的基本机制。

在Go中，Goroutines 没有固定的堆栈大小。相反，它们开始时很小（比如4KB），在需要时增长/缩小，似乎给人一种 "无限 "堆栈的感觉。但是增长总是有限的，但是这个限制并不是来自于调用深度的限制，而是来自于堆栈内存的限制，在Linux 64位机器上，它是1GB。

尝试将 nil 函数交给 goroutine 启动

1
2
3
4
5

func main() {
defer errorHandler()
var f func()
go f()
}

所有线程都休眠了

正常情况下，程序中不会所有线程都休眠，总是会有线程在运行处理我们的任务，例如：

1
2
3
4
5
6
7
8
9
10

func main() {
defer errorHandler()
go func() {
for true {
fmt.Println("alive")
time.Sleep(time.Second*1) 
}
}()
<-make(chan int)
}

能够被捕获的异常

数组 ( slice ) 下标越界

1
2
3
4
5
6
7
8
9
10
11
12
13
14

func foo(){
defer func() {
if r := recover(); r != nil {
fmt.Println(r)
}
}()
var bar = []int{1}
fmt.Println(bar[1])
}

func main(){ 
foo()
fmt.Println("exit")
}

空指针异常

1
2
3
4
5
6
7
8
9
10
11
12
13
14

func foo(){
defer func() {
if r := recover(); r != nil {
fmt.Println(r)
}
}()
var bar *int
fmt.Println(*bar)
}

func main(){
foo()
fmt.Println("exit")
}

往已经 close 的 chan 中发送数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

func foo(){
defer func() {
if r := recover(); r != nil {
fmt.Println(r)
}
}()
var bar = make(chan int, 1)
close(bar)
bar<-1
}

func main(){
foo()
fmt.Println("exit")
}

类型断言

1
2
3
4
5
6
7
8
9
10
11
12
13
14

func foo(){
defer func() {
if r := recover(); r != nil {
fmt.Println(r)
}
}()
var i interface{} = "abc"
_ = i.([]string)
}

func main(){
foo()
fmt.Println("exit")
}

参考

• https://draveness.me/golang/docs/part2-foundation/ch05-keyword/golang-panic-recover/
• https://ieevee.com/tech/2017/11/23/go-panic.html
• https://cloud.tencent.com/developer/article/1905179

垃圾回收器种类

GC 实现方式包括：

• 追踪式，分为多种不同类型，例如：
  • 标记清扫：从根对象出发，将确定存活的对象进行标记，并清扫可以回收的对象。
  • 标记 整理：为了解决内存碎片问题而提出，在标记过程中，将对象尽可能整理到一块连续的内存上。
  • 增量式：将标记与清扫的过程分批执行，每次执行很小的部分，从而增量的推进垃圾回收，达到近似实时、几乎无停顿的目的。
  • 增量整理：在增量式的基础上，增加对对象的 整理 过程。
  • 分代式：将对象根据存活时间的长短进行分类，存活时间小于某个值的为年轻代，存活时间大于某个值的为老年代，永远不会参与回收的对象为永久代。并根据分代假设（如果一个对象存活时间不长则倾向于被回收，如果一个对象已经存活很长时间则倾向于存活更长时间）对对象进行回收。
• 引用计数：根据对象自身的引用计数来回收，当引用计数归零时立即回收。

Go 的垃圾回收机制

Go 的 GC 目前使用的是无分代（对象没有代际之分）、不整理（回收过程中不对对象进行移动与整理）、并发（与用户代码并发执行）的三色标记清扫算法。原因 [1] 在于：

1. 不整理：Go 使用的是基于 tcmalloc 的现代内存分配算法，基本没有内存碎片问题，对对象进行整理不会带来实质性的性能提升。
2. 不分代：但 Go 的编译器会通过 逃逸分析 将大部分新生对象存储在栈上（栈直接被回收），只有那些需要长期存在的对象才会被分配到需要进行垃圾回收的堆中。因此在 Go 中性能提升不大，并且 Go 设计团队的关注点并不在这。

三色标记法

理解 三色标记法 的关键是理解对象的 三色抽象 以及 波面（wavefront）推进 这两个概念。

从垃圾回收器的视角来看，三色抽象规定了三种不同类型的对象，并用不同的颜色相称：

• 白色对象（可能死亡）：未被回收器访问到的对象。在回收开始阶段，所有对象均为白色，当回收结束后，白色对象均不可达。
• 灰色对象（波面）：已被回收器访问到的对象，但回收器需要对其中的一个或多个指针进行扫描，因为他们可能还指向白色对象。
• 黑色对象（确定存活）：已被回收器访问到的对象，其中所有字段都已被扫描，黑色对象中任何一个指针都不可能直接指向白色对象。

STW

垃圾回收的过程中涉及两种流程：赋值器和染色器，为了防止在染色的同时，某些对象之间的关系发生改变，进而导致垃圾回收发生错误，需要进行 STW。STW 可以是 Stop The World 的缩写，也可以是 Start The World 的缩写。通常意义上指的是从 Stop The World 到 Start The World 这一段时间间隔。垃圾回收过程中为了保证准确性、防止无止境的内存增长等问题而不可避免的需要停止赋值器进一步操作对象图以完成垃圾回收。这一动作发生时这一段时间间隔，即万物静止。

并发标记清楚法

传统的垃圾收集算法会在垃圾收集的执行期间暂停应用程序，一旦触发垃圾收集，垃圾收集器会抢占 CPU 的使用权占据大量的计算资源以完成标记和清除工作，然而很多追求实时的应用程序无法接受长时间的 STW。

并发（Concurrent）的垃圾收集不仅能够减少程序的最长暂停时间，还能减少整个垃圾收集阶段的时间，通过开启读写屏障、利用多核优势与用户程序并行执行，并发垃圾收集器确实能够减少垃圾收集对应用程序的影响：

但并发标记清除中面临的一个根本问题就是如何保证标记与清除过程的正确性。所以需要引入屏障技术保证染色器和赋值器可以正确工作。

屏障机制

写屏障是一个在并发垃圾回收器中才会出现的概念，垃圾回收器的正确性体现在：不应出现对象的丢失，也不应错误的回收还不需要回收的对象。

可以证明，当以下两个条件同时满足时会破坏垃圾回收器的正确性：

• 条件 1: 赋值器修改对象图，导致某一黑色对象引用白色对象；
• 条件 2: 从灰色对象出发，到达白色对象的、未经访问过的路径被赋值器破坏。

只要能够避免其中任何一个条件，则不会出现对象丢失的情况，因为：

• 如果条件 1 被避免，则所有白色对象均被灰色对象引用，没有白色对象会被遗漏；

• 如果条件 2 被避免，即便白色对象的指针被写入到黑色对象中，但从灰色对象出发，总存在一条没有访问过的路径，从而找到到达白色对象的路径，白色对象最终不会被遗漏。

• 强三色不变性：条件 1，条件 2 都不能出现。

• 弱三色不变性：可以允许条件 1 出现。

有两种非常经典的写屏障：Dijkstra 插入屏障和 Yuasa 删除屏障。

插入屏障（Dijkstra）- 灰色赋值器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 灰色赋值器 Dijkstra 插入屏障  
func DijkstraWritePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {  
    shade(ptr) //先将新下游对象 ptr 标记为灰色  
    *slot = ptr  
}  
  
//说明：  
添加下游对象(当前下游对象slot, 新下游对象ptr) {     
  //step 1  
  标记灰色(新下游对象ptr)     
    
  //step 2  
  当前下游对象slot = 新下游对象ptr                      
}  
  
//场景：  
A.添加下游对象(nil, B)   //A 之前没有下游， 新添加一个下游对象B， B被标记为灰色  
A.添加下游对象(C, B)     //A 将下游对象C 更换为B，  B被标记为灰色

Dijkstra 插入屏障的基本思想是避免满足条件 1 以保证垃圾回收的正确性。

缺点

• 由于 Dijkstra 插入屏障的“保守”，在一次回收过程中可能会残留一部分对象没有回收成功，只有在下一个回收过程中才会被回收。
• 在标记阶段中，每次进行指针赋值操作时，都需要引入写屏障，这无疑会增加大量性能开销。
• 为了避免造成性能问题，Go 团队在最终实现时，没有为所有栈上的指针写操作，启用写屏障，但需要标记终止阶段 STW 时对这些栈进行重新扫描。

1. 为何需要在一遍标记清扫后进行 STW 然后扫描一次栈？
   • 个人理解是：因为，由于没有对栈应用写屏障，导致如果存在栈上对象引用了白色的堆上对象，如果不 STW 重新扫描，会导致堆上正在使用的对象被错误回收。
2. 堆上的对象为什么会存在这个白色对象？
   • 个人理解是：对象不会凭空产生，这个对象是被其他对象创建的，和其它对象有引用关系，但在染色器尚未覆盖到的情况下，父对象便删除和它的引用，由于目前是纯插入屏障，没有删除屏障，因此会导致这个白色对象的产生。

删除屏障 （Yuasa）- 黑色赋值器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 黑色赋值器 Yuasa 屏障  
func YuasaWritePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {  
shade(*slot) 先将*slot标记为灰色  
*slot = ptr  
}  
  
//说明：  
添加下游对象(当前下游对象slot， 新下游对象ptr) {  
//step 1  
if (当前下游对象slot是灰色 || 当前下游对象slot是白色) {  
标记灰色(当前下游对象slot) //slot为被删除对象， 标记为灰色  
}  
//step 2  
当前下游对象slot = 新下游对象ptr  
}  
  
//场景  
A.添加下游对象(B, nil) //A对象，删除B对象的引用。B被A删除，被标记为灰(如果B之前为白)  
A.添加下游对象(B, C) //A对象，更换下游B变成C。B被A删除，被标记为灰(如果B之前为白)

另一种比较经典的写屏障是黑色赋值器的 Yuasa 删除屏障，其基本思想是避免满足条件 2。

缺点

1. 删除写屏障也叫基于快照的写屏障方案，必须在起始时，STW 扫描整个栈（注意了，是所有的 goroutine 栈），保证所有堆上在用的对象都处于灰色保护下，保证的是弱三色不变式。

2. 为何需要在初始状态时扫描整个栈？

   • 堆内存在被栈对象引用的白色堆对象，无法解决堆内黑色对象引用白色对象的问题。

混合屏障

实际上 Go 中并没有真正实现过删除写屏障，Go 在 v1.8 引入了混合屏障，混合屏障将插入屏障和删除屏障结合了起来。

1
2
3
4
5
6
7
8
9

// 添加下游对象的函数, 当前下游对象slot, 新下游对象ptr
func HybridWritePointerSimple(slot *unsafe.Pointer, ptr unsafe.Pointer) {
    // 1) 将被删除的下游对象标记为灰色
    shade(*slot)
    // 2) 将新下游对象标记为灰色
    shade(ptr)
    // 3) 当前下游对象slot = 新下游对象ptr
    *slot = ptr
}

混合写屏障逻辑如下：

• GC 开始时只需将当前栈上所有对象标记为黑色，无须 STW。
• GC 期间在栈上创建的新对象均标记为黑色。
• 将被删除的下游对象标记为灰色。
• 将被添加的下游对象标记为灰色。

优点

1. 由于结合了删除屏障和插入屏障，导致混合屏障没有了插入屏障扫描一次后 STW 的问题。
2. 由于结合了删除屏障和插入屏障，导致在初始时可以不初始化整个栈，而是只初始化一个 goroutine 的栈。

优化 1

优化 2

参考

• https://liangyaopei.github.io/2021/01/02/golang-gc-intro/
• https://colobu.com/2022/07/16/A-Guide-to-the-Go-Garbage-Collector/
• https://zhuanlan.zhihu.com/p/297177002
• https://liqingqiya.github.io/golang/gc/垃圾回收/写屏障/2020/07/24/gc5.html

互斥锁与自旋锁

• 互斥锁：互斥锁又被称为无忙等待锁，当获取不到锁的时候，线程会被阻塞，等待锁空闲后被唤醒，线程被阻塞是由操作系统实现的，这个过程涉及到由用户态陷入内核态，涉及线程的切换。
• 自旋锁：自旋锁又被称为忙等待锁，获取不到锁的时候，一直占用 CPU 进行自旋检测锁的状态。

自旋锁和互斥锁的选择也是一个值得考虑的问题。
如果一个资源被占用一次的时间过短，那么自旋等待的代价要低于加锁后进行线程切换的代价，这时最好选用自旋锁。反之，使用互斥锁让线程阻塞并让出 CPU 是更好的选择。

读写锁

对于一些操作由于他们不会修改数据，因此这种对于这类操作可以并行执行，但同时我们也要保证修改数据的操作不能与其他操作并行执行，这就需要更加细粒度的锁，进入引出了读写锁。
读写锁还可以继续细分为：读优先锁和写优先锁，这二者都无法做到兼顾到写者和读者不会出现饥饿的情况，因此更好的办法是使用一个公平读写锁，按照 FIFO 的方式处理读写操作。

悲观锁与乐观锁

悲观锁与乐观锁

• 悲观锁：假定发生冲突的概率会很高，因此读写数据前需要加锁，保证读写数据期间，数据不会被其他人修改，上文提到的互斥锁、自旋锁、读写锁都属于悲观锁。
• 乐观锁：假定发生冲突的概率较低，先修改完共享资源，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源则操作成功，如果发现有其他线程已经修改过这个资源，就放弃本次操作。

对于悲观锁和乐观锁的选择问题，只有在冲突概率非常低，且加锁成本非常高的场景时，才考虑使用乐观锁。

基本原语

Go 语言中提供了两种类型的锁：互斥锁 Mutex 与读写锁 RWMutex

Mutex

初版

Mutex 初版的实现比较简单，通过设置一个 key 字段上。key 的含义比较简单，就是一个标志位，等于 0 表示锁未被持有，1 表示被某个 goroutine 持有，等于 n 表示还有 n-1 个等待者。

加锁

• 加锁（Lock）的过程首先是给 key 加 1：
  • 如果 key 返回 1，则表示当前 goroutine 占有了这把锁，其它 goroutine 只能做候选者。
  • 如果 key 返回 n（n > 1），这说明当前有其它 gorutine 正在占用这把锁，所以接下来需要通过信号量机制将当前 goroutine 挂起，加到等待队列，进入阻塞状态。

解锁

• 解锁（Unlock）的过程是给 key 减 1：
  • 如果 key 返回 0，表示当前没有其它 goroutine 在等待，可以直接返回。
  • 如果 key 返回 n (n > 0)，说明还有其它 goroutine 在等待，因此需要通过信号量机制将等待队列中的其它 goroutine 唤醒。

问题

初版 Mutex 在实现的时候，有两个问题：

• Unlock 调用无限制。
• goroutine 唤醒机制性能低下。

Mutex ==本身并没有包含当前 goroutine 的任何信息==，因此 Unlock 方法能被任意的 goroutine 调用。这样会导致一个问题，如果某个 goroutine 不按套路来，随便调用 Unlock 函数，让标志位 key 清零，那么数据竞争的问题还是会出现。Mutex 的这个特性一直保留至今。因此使用 Mutex 的时候，一定要遵循 “==谁加锁，谁解锁==” 的原则。

第二版

这一版 Mutex 的核心特点是一个 goroutinue 被唤醒后，不是立即执行任务，而是仍然和其他 goroutine 重复一遍和抢占锁的流程，这样新来的 goroutine 就有机会获取到锁，这就是所谓的给新人机会。

问题

虽然这一版改进了第一版中只能按照 FIFO 方式进行抢锁，导致的后续的新来的锁等待时间过长的问题。但引入了新的问题：

• 在加锁解锁的过程中，涉及到 goroutine 阻塞和唤醒的过程，系统调用涉及到不小的系统开销。如果 Lock 和 Unlock 之间的代码耗时很短，那么让新来的 goroutine 或者是醒着的 goroutine 抢占锁失败后，不立即睡眠，而是再尝试几次，说不定就能拿到锁了，尝试一定的次数之后，再进行原有的逻辑。

第三版

这一版和第二版区别不大，改动是如果被唤醒的协程或者是新来的协程没有抢到锁，就会通过自旋的方式尝试检查锁是否被释放。尝试了一定的次数后，会再继续原有的逻辑。这里的自旋是指循环尝试。

问题

第三版在性能优化的道路上又前进了一步，几乎走到头了。但是有一种极端情况，新来的协程每次都能抢占到锁，那么等待中的协程就会一直处于等待之中，这就是所谓饥饿问题。

第四版

Go 语言的 sync.Mutex 由两个字段 state 和 sema 组成。其中 state 表示当前互斥锁的状态，而 sema 是用于控制锁状态的信号量。

1
2
3
4

type Mutex struct {
state int32
sema  uint32
}

state

在默认情况下，互斥锁的所有状态位都是 0，int32 中的不同位分别表示了不同的状态：

• waitersCount — 当前互斥锁上等待的 Goroutine 个数；
• mutexStarving — 当前的互斥锁进入饥饿状态；
• mutexWoken — 表示从正常模式被从唤醒；
• mutexLocked — 表示互斥锁的锁定状态；

正常模式与饥饿模式

正常模式

锁的等待者会按照先进先出的顺序获取锁。但是刚被唤起的 Goroutine 与新创建的 Goroutine 竞争时，大概率会获取不到锁，为了减少这种情况的出现，一旦 Goroutine 超过 1 ms 没有获取到锁，它就会将当前互斥锁切换饥饿模式。

因为锁被解锁的时候队头的 Goroutine 可能被阻塞了，这时候如果有一个正在获取锁的 Goroutine，为了提高吞吐量自然会交给这个正在运行且在索要锁的 Goroutine。

饥饿模式

互斥锁会直接交给等待队列最前面的 Goroutine。新的 Goroutine 在该状态下不能获取锁、也不会进入自旋状态，它们只会在队列的末尾等待。如果一个 Goroutine 获得了互斥锁并且它在队列的末尾或者它等待的时间少于 1 ms，那么当前的互斥锁就会切换回正常模式。

与正常模式不同的是，饥饿模式下锁会一直持有直到第一个等待者准备好获取锁。

评价

与饥饿模式相比，正常模式下的互斥锁能够提供 更好的性能，饥饿模式的能 避免 Goroutine 由于陷入等待无法获取锁而造成的 高尾延时。

加锁与解锁

CAS ： atomic.CompareAndSwapInt32(addr, old, new) bool 方法，这个方法会先比较传入的地址的值是否是 old，如果是的话就尝试赋新值，如果不是的话就直接返回 false，保证数据只会被修改一次。

我们在这一节中将分别介绍互斥锁的加锁和解锁过程，它们分别使用 sync.Mutex.Lock 和 sync.Mutex.Unlock 方法。

加锁

互斥锁的加锁是靠 sync.Mutex.Lock 完成的：

1
2
3
4
5
6

func (m *Mutex) Lock() {
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
return
}
m.lockSlow()
}

快速加锁

利用 CAS 函数，判断锁的状态是否处于初始状态，如果是则直接对锁上锁。

1
2
3
4
5

func (m *Mutex) Lock() {
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
return
}
}

慢速加锁

如果互斥锁的状态不是 0（初始状态） 时就会调用 sync.Mutex.lockSlow 尝试通过自旋（Spinnig）等方式等待锁的释放，该方法的主体是一个非常大 for 循环，这里将它分成几个部分介绍获取锁的过程：

1. 判断当前 Goroutine 能否进入自旋。
2. 通过自旋等待互斥锁的释放：一旦当前 Goroutine 能够进入自旋就会执行 30 次的 PAUSE 指令，该指令只会占用 CPU 并消耗 CPU 时间。处理了自旋相关的特殊逻辑之后，互斥锁会根据上下文计算当前互斥锁最新的状态。如果最终没有通过获得锁，不断尝试获取锁并陷入休眠等待信号量的释放，一旦当前 Goroutine 可以获取信号量，它就会立刻返回。

如何判断当前 Goroutine 能否进入自旋？

1. 互斥锁只有在正常模式才能进入自旋；
2. runtime.sync_runtime_canSpin 需要返回 true：
   1. 运行在多 CPU 的机器上；
   2. 当前 Goroutine 为了获取该锁进入自旋的次数小于四次；
   3. 当前机器上至少存在一个正在运行的处理器 P 并且处理的运行队列为空；

解锁

互斥锁的解锁过程相对简单，该过程会先使用 sync/atomic.AddInt32 函数快速解锁。

1. 如果该函数返回的新状态等于 0（回到了初始状态），当前 Goroutine 就成功解锁了互斥锁。
2. 如果该函数返回的新状态不等于 0，这段代码会调用 sync.Mutex.unlockSlow 开始慢速解锁。
   1. 会先校验锁状态的合法性：
      1. 如果当前互斥锁已经被解锁过了会直接抛出异常 sync: unlock of unlocked mutex 中止当前程序。
   2. 在正常模式下，上述代码会使用如下所示的处理过程：
      1. 如果互斥锁不存在等待者或者互斥锁的 mutexLocked、mutexStarving、mutexWoken 状态不都为 0，那么当前方法可以直接返回，不需要唤醒其他等待者；
      2. 如果互斥锁存在等待者，唤醒等待者，等待者按照正常模式的抢锁方法竞争锁。
   3. 在饥饿模式下，将当前锁交给下一个正在尝试获取锁的等待者，等待者被唤醒后会得到锁，在这时互斥锁还不会退出饥饿状态，通过判断条件确认是否退出饥饿模式。

RWMutex

读写互斥锁 sync. RWMutex 是细粒度的互斥锁，它不限制资源的并发读，但是读写、写写操作无法并行执行。

sync. RWMutex 中总共包含以下 5 个字段：

1
2
3
4
5
6
7

type RWMutex struct {
w           Mutex
writerSem   uint 32
readerSem   uint 32
readerCount int 32
readerWait  int 32
}

• w： 复用互斥锁提供的能力；
• writerSem 和 readerSem ： 信号量，分别用于写等待读和读等待写：
• readerCount： 存储了当前正在执行的读操作数量；
• readerWait ：表示当写操作被阻塞时等待的读操作个数；

写锁

加锁

1
2
3
4
5
6
7
8
9
10

func (rw *RWMutex) Lock () {
    // 首先解决其他 writer 竞争问题
    rw.w.Lock ()
    // 反转 readerCount，告诉 reader 有 writer 竞争锁
    r := atomic.AddInt32 (&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
    // 如果当前有 reader 持有锁，那么需要等待
    if r != 0 && atomic.AddInt32 (&rw.readerWait, r) != 0 {
        runtime_SemacquireMutex (&rw.writerSem, false, 0)
    }
}

首先调用互斥锁的 lock，获取到互斥锁之后：

1. atomic.AddInt32(&rw. readerCount, -rwmutexMaxReaders)  调用这个函数阻塞后续的读操作。
2. 如果计算之后当前仍然有其他 Goroutine 持有读锁，那么就调用 runtime_SemacquireMutex  休眠当前的 Goroutine 等待所有的读操作完成。

解锁

1
2
3
4
5
6
7
8
9
10
11

func (rw *RWMutex) Unlock () {
    // 告诉 reader 没有活跃的 writer 了
    r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
    
    // 唤醒阻塞的 reader 们
    for i := 0; i < int (r); i++ {
        runtime_Semrelease(&rw.readerSem, false, 0)
    }
    // 释放内部的互斥锁
    rw.w.Unlock ()
}

解锁的操作，会先调用 atomic.AddInt32(&rw. readerCount, rwmutexMaxReaders)  将恢复之前写入的负数，然后根据当前有多少个读操作在等待，循环唤醒

读锁

加锁

1
2
3
4
5
6

func (rw *RWMutex) RLock () {
    if atomic.AddInt32(&rw. readerCount, 1) < 0 {
        // rw.readerCount 是负值的时候，意味着此时有 writer 等待请求锁，因为 writer 优先级高，所以把后来的 reader 阻塞休眠
        runtime_SemacquireMutex (&rw. readerSem, false, 0)
    }
}

首先是读锁， atomic.AddInt32(&rw.readerCount, 1)  调用这个原子方法，对当前在读的数量加一，如果返回负数，那么说明当前有其他写锁，这时候就调用 runtime_SemacquireMutex  休眠 Goroutine 等待被唤醒。

解锁

1
2
3
4
5
6
7
8
9
10
11

func (rw *RWMutex) RUnlock () {
    if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
        rw.rUnlockSlow (r) // 有等待的 writer
    }
}
func (rw *RWMutex) rUnlockSlow (r int 32) {
    if atomic.AddInt32(&rw.readerWait, -1) == 0 {
        // 最后一个 reader 了，writer 终于有机会获得锁了
        runtime_Semrelease(&rw.writerSem, false, 1)
    }
}

解锁的时候对正在读的操作减一，如果返回值小于 0 那么说明当前有在写的操作，这个时候调用 rUnlockSlow  进入慢速通道。慢速解锁时，会先对 readerWait 减一，当该值为 0 说明没有在读的操作了，可以唤醒等待的写 Goroutine。

总结

Go 中的读写锁，写写冲突是通过封装在读写锁里的互斥锁解决的。读写冲突，是通过 readerCount 和 readerWait 这两个变量解决的。

• 写者获取锁：
  1. 写者获取到互斥锁后会将 readerCount 加负数最大值，并将原 readerCount 记录在 readerWait 中。
  2. 读者想要获取锁时，对 readerCount 加 1，发现为负则阻塞。
  3. 写者退出时，对 readerCount 取反，依次唤醒读者。
• 读者获取锁：
  1. 读者会对 readerCount 加 1。
  2. 写者这个时候会将 readerCount 加负数最大值，然后再取反根据取反值是否为 0，判断是否要阻塞。
  3. 但这个时候如果再有读者进来，对 readerCount 加 1，肯定发现为负则阻塞，因此即使现在是前面的读者持有锁，后面的读者也无法运行。
  4. 因此写者的优先级会高于读者，读者退出之后会优先唤醒写者，而后释放互斥锁，因此先被唤醒的写者会阻塞在他们之前的读者。

例子

• 初始：readerCount：0，readerWait：0。
• 读者 1：当有一个读者便会将 readerCount 变量加一，readerCount：1。
• 写者 1：如果这时候出现了一个写者，便会将 readerCount 的值，保存在 readerWait 中，然后将 readerCount 赋一个最大读者数量的负值，readerCount：-10000，readerWait：1
• 写者 2：这时候如果再出现一个写者，由于先前的写者 1 获取了互斥锁，因此写者 2 会直接阻塞。
• 读者 2：这样后续的再出现新的读者，后续的读者 readerCount 变量加一后这个变量也是负的，读者就知道存在一个写者，读者便会阻塞自己，readerCount：-9999，readerWait：1
• 读者 1 完成：读者 1 完成自己的操作之后，将 readerCount 减一，但发现这时候的值是负的，就会知道存在等待的写者，进入慢速解锁模式，将 readerWait 减一，减一后如果为 0 则唤醒写者 1。

参考

• Golang Mutex 的实现原理
• Go 中的 Mutex 设计原理详解（三）
• Go 中的 Mutex 设计原理详解（四）

Golang 不同于 Java，并不是完全面向对象的，他没有对象和类的概念。

而是如引入了 struct 和 interface 的概念，曾经看到过一个说法，我觉得说的还挺形象的，Go 没有面向对象只有字段集和方法集🐶。

鸭子类型

鸭子类型的设计哲学是：如果某个东西，它具备鸭子拥有的一切能力，那么这个东西他就是一只鸭子。也即是说一个 struct 如果他实现了一个 interface 对应方法集中的全部方法，那么就可以被认为实现了这个接口。

这种设计思路关注对象的行为，而不是类型。这是动态类型语言如 Python 崇尚的一种设计哲学。例如，在 Python 中当调用此函数的时候，可以传入任意类型，只要它实现了 say_hello() 函数就可以。如果没有实现，运行过程中会出现错误。

1
2

def hello_world(coder):
    coder.say_hello()

Golang 虽然本身又是一门静态类型语言，但在其设计时借鉴了动态类型语言的设计方式，也实现了这种设计。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

type duck interface {
eat()
swim()
}

type maleDuck struct {
name string
}
type femaleDuck struct {
name string
}

func (s maleDuck) eat() {
}
func (s maleDuck) swim() {
}
func (s femaleDuck) eat() {
}
func (s femaleDuck) swim() {
}

func beDuck(aDuck duck) {
    aDuck.eat()
    aDuck.swim()
}

func main() {
    var m maleDuck{"A"}
    var f femaleDuck{"B"}
    beDuck(m)
    beDuck(f)
}

方法调用

值类型与指针类型

在调用方法的时候，值类型既可以调用 值接收者 的方法，也可以调用 指针接收者 的方法；指针类型既可以调用 指针接收者 的方法，也可以调用 值接收者 的方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

package main

import "fmt"

type Person struct {
age int
}

func (p Person) howOld() int {
return p.age
}

func (p *Person) growUp() {
p.age += 1
}

func main() {
// qcrao 是值类型
qcrao := Person{age: 18}
// 值类型 调用接收者也是值类型的方法
fmt.Println(qcrao.howOld())
// 值类型 调用接收者是指针类型的方法
qcrao.growUp()
fmt.Println(qcrao.howOld())
// ----------------------
// stefno 是指针类型
stefno := &Person{age: 100}
// 指针类型 调用接收者是值类型的方法
fmt.Println(stefno.howOld())
// 指针类型 调用接收者也是指针类型的方法
stefno.growUp()
fmt.Println(stefno.howOld())
}

这其实是语法糖在起作用。

值接收者与指针接收者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

package main

import "fmt"

type coder interface {
code()
debug()
}

type Gopher struct {
language string
}

func (p Gopher) code() {
fmt.Printf("I am coding %s language\n", p.language)
}

func (p *Gopher) debug() {
fmt.Printf("I am debuging %s language\n", p.language)
}

func main() {
var c1 coder = &Gopher{"Go"}
c1.code()
c1.debug()

    var c2 coder = Gopher{"Go"}
c2.code()
c2.debug() // fatal

当一个将一个结构体的 值 或者 指针 赋值给一个 接口 后，就会展示出值/指针类型的接收者是否真正实现了一个接口的方法，因为并没有直接调用方法，因此这个时候语法糖便无法起作用了，也就露出了小犄角：

• 实现了接收者是值类型的方法，页会隐含地也实现了接收者是指针类型的方法。
• 但实现了接收者是指针类型的方法，却不会实现了接收者是值类型的方法。

接口

iface 和 eface 都是 Go 中描述接口的底层结构体，区别在于 iface 描述的接口包含方法，而 eface 则是不包含任何方法的空接口：interface{}。

空接口的结构

1
2
3
4

type eface struct { 
_type *_type
data  unsafe.Pointer
}

• _type 是 Go 语言类型的运行时表示，表示的是赋给空接口的对象的类型，其中包含了很多类型的元信息，例如：类型的大小、哈希、对齐以及种类等。
• data 则指向接口具体的值，一般而言是一个指向堆内存的指针。

1
2
3
4
5
6
7
8
9
10
11
12
13

type _type struct {
size       uintptr
ptrdata    uintptr
hash       uint32
tflag      tflag
align      uint8
fieldAlign uint8
kind       uint8
equal      func(unsafe.Pointer, unsafe.Pointer) bool
gcdata     *byte
str        nameOff
ptrToThis  typeOff
}

• size 字段存储了类型占用的内存空间，为内存空间的分配提供信息。
• hash 字段能够帮助我们快速确定类型是否相等。

非空接口的结构

1
2
3
4

type iface struct {
tab  *itab
data unsafe.Pointer
}

iface 内部维护两个指针：

• tab 指向一个 itab 实体， 它表示接口的类型以及赋给这个接口的实体类型。
• data 则指向接口具体的值，一般而言是一个指向堆内存的指针。

1
2
3
4
5
6
7
8
9
10

type itab struct {
inter  *interfacetype
_type  *_type
link   *itab
hash   uint32 // copy of _type.hash. Used for type switches.
bad    bool   // type does not implement interface
inhash bool   // has this itab been added to hash?
unused [2]byte
fun    [1]uintptr // variable sized
}

• inter 它描述的是接口的类型。
• _type 同上文空接口中的 _type 字段。
• hash 同上文中空接口中的 hash 字段。
• fun 是一个动态大小的数组，存储了一组函数指针。虽然该变量被声明成大小固定的数组，但是在使用时会通过原始指针获取其中的数据，所以 fun 数组中保存的元素数量是不确定的。

重点看一下 interfacetype 类型，它描述的是接口的类型，可以看到，它包装了 _type 类型，_type 实际上是描述 Go 语言中各种数据类型的结构体。

1
2
3
4
5

type interfacetype struct {
typ     _type
pkgpath name
mhdr    []imethod
}

接口的动态类型和动态值

从源码里可以看到：iface 包含两个字段：tab 是接口表指针，指向类型信息；data 是数据指针，则指向具体的数据。它们分别被称为 动态类型 和 动态值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package main

import "fmt"

type Coder interface {
code()
}

type Gopher struct {
name string
}

func (g Gopher) code() {
fmt.Printf("%s is coding\n", g.name)
}

func main() {
var c Coder
fmt.Println(c == nil)
fmt.Printf("c: %T, %v\n", c, c)

var g *Gopher
fmt.Println(g == nil)

c = g
fmt.Println(c == nil)
fmt.Printf("c: %T, %v\n", c, c)
}

输出

1
2
3
4
5

true
c: <nil>, <nil>
true
false
c: *main.Gopher, <nil>

实际上对一个接口进行多次赋值的时候，实际进行修改的内容，也即动态类型与动态值这两个内容。

接口断言

非空接口

类型断言时会将目标类型的 hash 与接口变量中的 itab.hash 进行比较。

空接口

从 eface._type 中获取类型，仍然会使用 _type.hash 与变量的类型比较。

接口转换原理

从 iface 的源码可以看到，实际上它包含接口的类型 interfacetype 和 实体类型的类型 _type，也就是说生成一个 itab 同时需要接口的类型和实体的类型。

当判定一种类型是否满足某个接口时，Go 使用类型的方法集和接口所需要的方法集进行匹配，如果类型的方法集完全包含接口的方法集，则可认为该类型实现了该接口。例如某类型有 m 个方法，某接口有 n 个方法，则很容易知道这种判定的时间复杂度为 O(mn)，Go 会对方法集的函数按照函数名的字典序进行排序，所以实际的时间复杂度为 O(m+n)。

动态派发

动态派发（Dynamic dispatch）是在运行期间选择具体多态操作（方法或者函数）执行的过程，它是面向对象语言中的常见特性。Go 语言虽然不是严格意义上的面向对象语言，但是接口的引入为它带来了动态派发这一特性，调用接口类型的方法时，如果编译期间不能确认接口的类型，Go 语言会在运行期间决定具体调用该方法的哪个实现。

1
2
3
4
5

func main() {
var c Duck = &Cat{Name: "draven"}
c.Quack()
c.(*Cat).Quack()
}

1. 第一次以 Duck 接口类型的身份调用，调用时需要经过运行时的动态派发。
2. 第二次以 *Cat 具体类型的身份调用，编译期就会确定调用的函数。

参考

• 深度解密 Go 语言之关于 interface 的 10 个问题
• Go 语言设计与实现

2022 年过去了，我不想怀念他。

一年一更的年记（流水账），终于在大年初一开始动笔。最近先后忙于论文开题与实习，终于有精力抽出时间开始回首这一年的林林总总点点滴滴，每年一更的年记既是记录也是总结更是对自己的督促。

如果让我来评价我的 2022，我会用稳中向好来描述它，这一年不紧不慢地过去了。这一年由于疫情管控的原因，我的大部分时间都是在校园中度过的，校园生活相比以前可以出校浪荡的时光总是那么的单调乏味，好在我的生活可以被很多东西填满，因此这一年过的并没有想象中的那么无聊。但这一年也没有想象中的热火朝天忙得不可开交，一切都是有条不紊的进行，如果让我给 2022 年打一个分我觉得会是 6.8 分吧。

反反复复的疫情让我没有太多时间可以去校外放荡，因此这生活只能就只能在西土城路 10 号院这片小天底下展开了。我的校园生活现在想来是那么的单调，每天宿舍——食堂——实验室——体育馆几点一线，白天在实验室坐牢，午饭晚饭和女朋友厮守一下，晚饭后健身房羽毛球运动一下，洗完澡后和女朋友游戏电影，这一年下来几乎没有几天跳出了这个模板。对我来说这种生活是没什么的，可能本身我也算不上一个爱玩的人，但是女朋友时常的抱怨加之今年她并不顺利的求职经历，不由得让我担心是否应该尽量给她的生活注入一点欢乐？

摸索

自己看来我应该是一个对事业看的比较重的人，这一年大部分的时间都花在了提升自己能力上，2023 届毕业生的惨淡求职情况不由得不让人担心，因此丝毫不敢松懈，尽力为自己的简历再添上一点经历，以便自己可以在求职时有更多的选择。2022 年上半年对互联网的唱衰便此起彼伏，论坛里几百楼回复的那个关于劝退互联网的贴子至今仍可以轻易找到，不由得不让人对就业前景产生担忧，那时候技术上基本只停留在了低并发的 WEB 系统的开发上（🐶），于是想要开始尝试做一些能够提升自己能力的事，迷茫的我在 2021 年底开始接触分布式系统，翻了翻野猪书，也开始写 MIT 6.824，最后报名参与了 Talent Plan 开始写 TinyKV，但遗憾由于第一次接触相关内容在 Project 2 处花了大量时间最终没能完成，于是 2021 年记中给自己定下的目标便是可以完成 6.824 和 TinyKV 中的一个。

2022 年春节过后回到学校后无可事事的我，每天在实验室的生活便是代码随想录与 TinyKV，虽然不知道怎么做是最有用的，但起码不敢让自己停下来，就这样平淡的度过了开学前的两个月，慢慢悠悠的写着，到五月中旬的时候，我把之前的代码都梳理了一遍，也基本完成了 Project 2 的内容（参照了大量前人的文档，基本每天都花了大量时间在 debug 上），恰好这时候我听说了 GSOC 由于向往谷歌这块招牌，我对此跃跃欲试，但无奈浏览了相关的介绍后发现难度过大而且很多项目都是老外主导的，沟通起来也存在一定障碍，并且由于接收的是来自全世界学生的申请导致他们的要求比较高，对于第一次参加开源项目的我来说能够申请到的可能性并不高因此遗憾放弃。

不过巧的是后面在 Talent Plan 的群里又见到有同学推荐 开源之夏，这个相当于一个国内版的 GSOC，形式类似：报名申请——为开源项目贡献代码——结项发钱，不过由于申请者主要来自国内竞争压力小了很多，所以见到这个的第一时间我就决定要报名了，不想错过这次宝贵的机会，因为说起来研一结束的暑假是我开始实习之前最后一个可以用来做一个完整项目的时间了，那时候基本隔个几天就要打开项目列表的界面，看看又多了几个项目，有哪些项目是可以申请的，每个项目看起来都非常高大上，让我望而却步，但又由于想要挑战一下自己而跃跃欲试。

后面在 6 月初的时候豪哥又向我们安利了字节青训营，抱着试试看的心态也交了报名申请，很巧的是在组队的时候遇到了一个曾经翻过我博客的学弟，他也尝试参加过 Talent Plan，因此碰巧看到了我博客上的内容，正巧夏季的新一轮 Talent Plan 又开始了报名，因此不甘心的他又想拉着我参加这次的 Talent Plan，盛情难却最终我开始三线并行。

不由得让人感叹圈子真小，这一点我现在更有感触了。

通过认识一个这个圈子里的大佬，通过他的社交圈子，就会发现他的好友是你曾经关注过的另一位大佬。

我在开源之夏的导师阳哥便也参加过 Talent Plan 并且最终拿到了 90 多分的好成绩，阳哥在知乎发的文章我以前曾经看到过，但只见其文未见其人，这次真正结识了。

在申请项目的时候我也没有太明确的目标，只是筛选出一些技术要求我能够达到的项目，并且不需要太多的前置知识，由于我的主力开发语言是 Go 因此适合我的大多数项目都集中在了云原生领域。几经筛选之后我确定了几个项目，起初我对于申请项目还是很小心，为了确保在前期与项目导师交流的的时候可以有的放矢，我对于申请的项目都进行了研究，我首先看了看 Dubbo go 的 SDK 移植的任务，因为觉得 Dubbo 的名气比较大，如果可以承担这个任务后面可以算是很有含金量的项目，但看了下对于 rpc 理解不深的我并没有得出什么有意义的想法，然后又胡乱看了看混沌工程的项目，但最后也不了了之。最终由于我之前听说过 KubeVela 于是就将目光集中在了这个项目上，我首先尝试的是雾雾的项目：为 KubeVela 中的 Cue Actions 添加版本管理，我当时对于 CUE 是在 KubeVela 中发挥什么样的功能并没有一个很明确的概念，只是觉得既然是版本控制那似乎可以参照 Git 的实现原理来做，就给导师发了一封邮件大概说了下自己的想法，但加了微信详细交流后发现，似乎跟我想的相去甚远，于是备受打击觉得可能这个项目的申请可能要凉凉了。

不过我看了下后续申请者的申请书，他也提到了参照 Git 的原理来做，或许我的总体思路还没错？

由于当时已经简单看了 KubeVela 的文档，当时的项目的功能还没有现在这么多，大概看了下如何发布应用、组件、工作流等内容就大概清楚了该项目的主要作用。由于有了一定的基础所以就打算再看看社区的其他项目，这时候就看到了阳哥担任导师的项目：提升KubeVela生态下应用状态的可观测能力，其实我一开始也对这个项目具体要做成什么样没什么概念，但我看到了这个任务的雏形：Github 上有一个相关的 Issue，里面有关于这个任务的具体描述，这样我就对这个任务有了大致的想法。为了得到导师的认可，我去阅读了 VelaQL 的相关代码，然后给阳哥发了邮件，阳哥很快来加了我微信，并对我表示了赞许，后面交流中才知道，他对我一开始就有耐心看源码的行为很欣赏，这一点也是他后面选择我而不是其他同学的重要因素。

这里其实还有一个小插曲，我一开始以为我做的东西和 VelaQL 关联性很紧密所以就去翻看了相关的 Issue，我突然发现有一名中科院的同学在做相关的开发，这时候我就有点慌了，我担心她把这块工作做了那我后面岂不是没东西做了，如果做别的我可能还要重新上手。好在阳哥跟我说那个同学参加的是一个别的项目，他的工作完成的不太好，只做了很小一部分（甚至最终烂尾了），所以阳哥希望我后面可以把这个项目做好，以至于后来他对于我是否有在推进这件事很关心。

最终在和阳哥交流了几次后，我选择参加了 KubeVela 社区的活动。

KubeVela 是一个现代化的软件交付平台，它可以让你的应用交付在当今流行的混合、多云环境中变得更加 * 简单、高效、可靠。

KubeVela 目前是 CNCF SandBox 项目，但已经开始提交申请成为 Incubating 项目了。

成长

我负责的项目是为 KubeVela 开发一个类似一个 k9s 的 CLI 工具，该工具不与于 k9s 的是，该工具是与 KubeVela 资源层级紧密适配的，最终这个工具被命名为 vela top，在 KubeVela 1.6 版本中被推出，我作为该工具的维护者负责后续代码的维护工作。整个暑假以及开学初两个月的大部分时间我都花在了 vela top 的开发上，从 7 月初开始构建项目的雏形，到 8 月底完成了工具雏形提交了关于 vela top 的第一个 PR，再到 9 月 10 月不断迭代项目，逐渐完成了资源展示、资源筛选、YAML 查看、日志浏览、资源拓扑等一系列功能，原本以为会在 9 月份收尾的项目因为一直进行迭代，到项目截止前的 10 月底才算是基本完成。当然后续 11 月我又修复了资源拓扑由于网络 I/O 导致加载过慢的 bug，12 月完成了自定义主题的功能。

项目经验分享｜韩孟男：提升 KubeVela 生态下应用状态的可观测能力

我也真的很荣幸能有阳哥作为我的导师，虽然阳哥比较忙但是还是坚持让我隔一段时间汇报下进度，在和阳哥的交流过程中我学到了很多，阳哥不单在完成项目方面给了我一些指导，而且在职业发展方面也不吝啬于给我很多建议，在和他相处的过程中丝毫感受不到导师带来的压力。在完成项目的过程中，社区的其他成员也对我的工作表达了认可，虽然在我看来他们都是很厉害的大佬，并且自己完成的工作其实在技术上并算不得什么，但是他们还是对我这样一个开源小白表达了鼓励和认可，增加了我参与开源建设的热情。很荣幸项目负责人天元对我开发的工具表示了肯定，甚至还将我的 Demo GIF 发到了推特上，我也和 KubeVela 组内的同事都混了个脸熟。2022 年我一共向社区贡献了 27 个 PR，也很荣幸从社区 Member 成为了 Reviewer，又进一步成为了 Approver。

在得到社区认可的同时，社区向开源之夏的组委会推荐了我，进一步对我的工作给予了肯定，在社区的推荐下，我很荣幸获得了本届开源之夏的突出贡献奖。

今年除了参与开源之外，另外一件让我自己觉得还算成功的事情便是今年一直在坚持刷 leecode，虽然没能做到每天都刷，但是整体上也算是坚持了一年（最近开始松懈了，已经半个月没刷了😢），但自己感觉还是很菜，犹记字节一面反转链表写了半天没有 AC，希望能继续坚持把，至少保持现在的水平吧。

12 月初，在疫情管控解除也就是北京疫情大爆发前夕我从北京匆匆逃离，在和豪哥在牛街短暂合住一晚，并在第二天一早在街头就着清晨的冷风与晨曦吃过早饭后，我踏上了回家的旅途并顺利在到家的第三天被告知成为了一名密接，又在社区与疾控的来回踢皮球中度过了居家隔离的反复被蹂躏心态的一周。不过相比我的好多同学，我还算得上幸运感谢我的城市并没有兴建方舱，不然我也许也会和他们一样成为方舱的最后一批入住者。

居家隔离的一周，我也并没有闲下来，在准备面试和参加面试中度过了这一周，由于事发突然本来做好 1 月份放假的打算的我，在离校之前并没有投递太多的面试，因此在离校期间匆匆投递的几家公司，有回应的也寥寥几个，不过这也可能与寒假期间各家公司并没有太多招人的打算有关。最先联系我的是 smartx，对于以技术见闻的这家公司我早有耳闻因此对于这次面试也尽力好好准备，面试过程也还算顺利因为有前面两个看起来还不那么水的项目经历，因此除了一面以外对于八股的拷打并不算很多，因而我侥幸顺利通过了面试，一周 OC，由于当时 smartx 同意我年前可以先远程实习，此外考虑到我的寒假时间本就不多，加之我迫切想要在寒假添加一段实习，因此在顺利通过面试后我并没有太多犹豫就接下了 offer，在 12 月中旬入职了公司。

不得不说上班真的是太累了。

遗憾

虽然今年收获了很多，但也并不是没有遗憾，还好我对人生中遗憾才是常态已是了然，塞翁失马焉知非福，今日的遗憾改日看来也许是另一种幸运，因此我并不因为去年的遗憾而后悔，姑且记录而已。

1. TinyKV 烂尾：上半年在实验室的时间大部分花在了完成 TinyKV 上，但最后实际上也没有全部完成，Project3 的部分并没有全部实现，后来参加了新一届的 Talent Plan 花了一周时间搞定了 Project 4。算是有一些烂尾。
2. 实习计划搁浅：上半年时本打算找个实习，但也只是有这个想法，并没有实际的计划，只是觉得应该做点什么，让自己以后走的容易些，但迟迟没有行动，后来忙于先后参加了字节青训营、新一届 Talent Plan、开源之夏，加之准备的并不充分因此迟迟没有开始投递，最后这个计划也不了了之，不过后来听说蒋总找到了微软的实习不由得羡慕。💔
3. 字节青训营烂尾：这个在我预料之中，这种组队完成的项目需要队长需要对团队有较强的把控（团队分工、进度把控等），当时团队缺少一个这样的队长，我有心但苦于没有精力当这个队长，所以烂尾在意料之中。
4. 实习投递过少：由于离校突然没有投递太多简历，准备的也不充分，收到 smartx 的 offer 之后也没有太考虑便接下了。也许再试一试会有更好的也说不准？
5. 开题过于草率：这也是无奈之举，不过开题这件事身不由己，最后只得开了一个水题目，后续还不知道该怎么办。💔
6. 能力提升有限：今年这一年在技术上并没有太多的长进，接触到了 k8s 但也仅限于了解概念，对于内部的原理知之甚少，想要探究的 operater 也最终计划搁浅，假期想要补充一手 Java 计划也不了了之，恨自己精力有限也恨自己学习能力不行。

展望

2023 年对我来说也算是非常关键的一年，这一年实习、秋招、中期答辩会接踵而来，估计会是非常忙碌的一年很多重要的事情都会在这一年发生，但现在看来这些重要的事情我准备的一点都算不上充分，主要是实在精力有限，加之这两年愈发觉得健康比薪水更重要，所以还是打算不把自己逼得那么紧，一步一步慢慢来，真正重要的东西其实在我身边，舍本逐末并不可取，临渊羡鱼不如退而结网。

明年有精力的话我希望能够弥补的一个遗憾是多读一些闲书，看着身边的大佬们有时间完成工作任务的同时还有时间抽出来陶冶一些情操，对此我十分羡慕。今年基本没人怎么摸闲书，更别说完整看完一本书了，明年争取弥补这个遗憾吧。

除了闲书之外，技术方面我也希望可以再深入一点，想来目前在技术上游荡无所事事的主要原因还是没有一个很好的机会来深入接触某个领域，一个很好的例子便是，通过开源之夏帮我迅速加深了对 k8s 的理解，这段在 smartx 实习的经历也让我从零到一了解了 cgroup 相关的知识。所以 2023 年暑期实习的经历也许还会帮我深入接触某个领域。

此外，如果今年秋招顺利的话，我想在寒假再能有一个出游的机会，工作之后可能这样的机会并不多了，所以能有一次机会我觉得应该珍惜，至于是和朋友一起或是和女朋友一起就再决定了。

祝好，2023！

通过

其他

腾讯天美（2023-4-25）

1. 只记得自己最后反问技术栈，结果面试官问我会不会 C++，会不会高性能编程，当然是不会啦😧

腾讯计费一面（2023-4-13）

1. 自我介绍
2. 介绍一个 kubevela 的项目
3. 介绍遇到的困难，以及如何解决的
4. 介绍 kubevela 的作用
5. 介绍 k8s 的组件
6. 介绍调度器的原理
7. 介绍 k8s 集群中，Pod 的数量和 Node 的数量受什么影响（这个不太清楚）
8. 介绍 service 的原理，外界访问一个 Pod 的流程
9. 介绍 TinyKV 项目为什么要基于 etcd 的架构来做
10. 联合主键 (A,B,C)，查询 SELECT * FROM TABLE1 WHERE B=1 AND C=2，走不走主键
11. 查询 SELECT * FROM TABLE1 WHERE B=1 AND A=2，走不走主键（这个应该和优化器有关，答错了）

阿里本地生活 Golang 二面（2023-4-13）

1. 自我介绍
2. 介绍 vela top 的工作
3. 遇到的困难，如何解决的
4. 一直追问有了 WEB 的方式，并且 WEB 端已经支持了这种能力，为什么还要在 CLI 端做 vela top。
5. 上面的问题实际上一直在追问我如何理解 vela top 的需求。
6. 介绍 Raft 协议
7. Raft 协议中选举是如何做的

PayPal 二面（2023-4-12）

1. 自我介绍
2. slice 原理
3. map 原理
4. channel 原理
5. 做题：手写一个排序算法
6. 做题：两个排序数组找中位数

PayPal 一面（2023-4-10）

1. 自我介绍
2. 介绍 KubeVela 的项目
3. 介绍如何使用 KubeVela 交付一个应用
4. 介绍 vela top 项目的意义
5. 借助 KubeVela 如何实现滚动发布
6. 滚动发布需要借助 K8S 中哪种资源
7. Deployment 滚动升级的策略有哪些
8. Deployment 交付时的哪个组件起的作用
9. Scheduler 调度 Pod 的过程
10. Pod 被调度到节点之上后的过程
11. Ingress 原理
12. Endpoint 原理
13. 使用 Go 实现一个功能：获取一个 Linux 主机上全部的进程，并获取该进程的 cmd line。并暴露该指标成为一个服务，该服务需要提供一个接口，可以获取一个小时内的情况。

Amazon 二面（2023-4-07）

1. 自我介绍
2. 介绍一个项目
3. 介绍项目的难点以及如何解决的
4. 介绍实习中项目遇到的困难并且是如何解决的
5. 介绍 cgroup 这种技术
6. 如何获取一个 Linux 主机上的所有进程
7. 实现一个计算器
8. 反问

Amazon 一面（2023-4-07）

1. 自我介绍
2. 介绍一个项目
3. 介绍项目中的难点如何解决的
4. 删除链表的倒数第 N 个节点
5. HashMap 的实现原理
6. 反问

阿里本地生活 Golang 一面（2023-3-29）

1. 自我介绍
2. 叙述一下 Go 中的协程，协程是如何实现抢占式调度的
3. 叙述一下 Go 中 channel 的原理，有缓冲和无缓冲的区别
4. 叙述一下 Go 接口的原理
5. 叙述一下 Go 垃圾回收的原理
6. 介绍一下 Go 逃逸分析的过程
7. 介绍一下 defer 的原理，defer 的调用顺序，嵌套 defer 如何调用
8. 介绍一下 Go 中字符串拼接的几种方式，几种方式的性能开销如何排序（这个确实听说过，不记得了）
9. 介绍一下 K8S 的基本组件（基本都介绍了，但是他问我还有没有其他的，说不出来了）
10. etcd 为什么可以实现分布式一致性
11. etcd 可以单机部署吗
12. go-client 原理
13. WebHook 的原理（这个确实没了解过）
14. 介绍 KubeVela 的项目
15. 参与过程中遇到的最大的挑战，如何解决的
16. 如何把开源项目结合到实际的项目中

美团基础架构二面（2023-3-27）

1. 自我介绍
2. 介绍 KubeVela 这个项目
3. 项目过程中遇到了什么问题，如何解决的
4. 项目设计的过程中，社区成员有没有给一些指导
5. KubeVela 这个项目它为开发和运维人员提供哪些能力
6. 如何看待项目的成熟度，有哪些企业采用这个项目
7. 这个项目对这些企业带来了多少效率的提升，或者带来了多大的成本节省
8. 进程间通信方式，实际应用中是如何使用的
9. 消息队列的方式和共享内存的方式有什么区别
10. TCP 为什么会粘包
11. 你在 SmartX 和阿里云都体验过，你如何看待大公司和小公司
12. 你如何看待美团和阿里云
13. 你能说一下你人生的至暗时刻吗

腾讯笔试（2023-3-26）

5 道题：100%、100%、100%、32%、5%

小红书笔试（2023-3-26）

3 道题：100%、100%、100%

拼多多后端一面（2023-3-23）

出了一道 leetcode 上没有的链表相减😢

1. 自我介绍
2. 根据自我介绍中提到的内容，详细介绍一段经历，有无遇到什么问题，如何解决的
3. 介绍最近一段实习经历，业务场景是什么，最后离职的时候，做到什么程度
4. 手撕：链表相减

A-B 的场景下有可能出现两种情况：A > B 或 A < B，但后者处理明显难度更大，做的时候不知道该怎么解决这个问题，所以说要事先判断一下，保证大数减小数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

package main
import (
    "fmt"
)

type ListNode struct {
    val  int
    next *ListNode
}

func main() {
    array1 := []int{3, 4, 2, 7}
    array2 := []int{4, 6, 5}

    lst1 := initListNode(array1)
    lst2 := initListNode(array2)
    
    lst1 = reverseList(lst1)
    lst2 = reverseList(lst2)
    
    ans := subList(lst1, lst2)

    for ans != nil {
        fmt.Print(ans.val, " ")
        ans = ans.next
    }
}

func initListNode(array []int) *ListNode {
    newHead := new(ListNode)
    point := newHead

    for i := 0; i < len(array); i++ {
        newNode := &ListNode{
            val: array[i],
        }
        point.next = newNode
        point = point.next
    }
    return newHead.next

}

func reverseList(head *ListNode) *ListNode {
    if head == nil || head.next == nil {
        return head
    }
    ans := reverseList(head.next)
    head.next.next = head
    head.next = nil
    return ans
}

func subList(lst1, lst2 *ListNode) *ListNode {
    newHead := new(ListNode)
    point := newHead
    x, y, z := -1, -1, 0
    for x != 0 && y != 0 {
        if lst1 != nil {
            x = lst1.val
            lst1 = lst1.next
        } else {
            x = 0
        }
        if lst2 != nil {
            y = lst2.val
            lst2 = lst2.next
        } else {
            y = 0
        }
        tmp := x - y - z
        if tmp < 0 {
            tmp = 10 + tmp
            z = 1
        } else {
            z = 0
        }
        newNode := new(ListNode)
        newNode.val = tmp
        point.next = newNode
        point = point.next
    }
    return newHead.next

}

后面通知一面过了，但是考虑到这个是 PDD，加上已经有别的公司的 OC 了，放弃二面。

阿里巴巴笔试（2023-3-22）

3 道题：100%、50%、0%

美团基础架构一面（2023-3-21）

正好是做容器调度和限制的，所以方向比较契合，最后还问我感不感兴趣这个方向

1. 自我介绍
2. SmartX 实习经历，介绍背景、解决的问题、遇到的问题、如何解决的
3. cgroup 原理
4. 你提到了你们这个采集服务，最后也用 cgroup 进行资源限制，那么进行限制后不会出现采集数据不准确的问题吗
5. 使用的是 cgroup v1 还是 cgroup v2，知道他们的原理或者区别吗
6. 你们有没有遇到过服务启动较慢，然后没有来得及加入到 cgroup 管理中的情况，如何解决的
7. 那如果出现这个情况，没有加入到 cgroup 之前，不会出现短时间资源短时间不受控的情况吗
8. 介绍 kubevela
9. 遇到过什么问题吗，如何解决的
10. 了解 MySQL 中的 B 树与 B+ 树吗，这个两个的区别吗
11. 知道数据库的隔离级别吗
12. 了解 Redis 吗？除了使用还知道底层原理吗，知道跳表的原理吗（正好不知道，尴尬🐶）
13. 知道 go 的 map 吗？为什么是并发不安全的
14. 知道 go 的内存分配机制吗
15. go 多线程之间是如何通信或者共享内存的
16. 手撕： N 字形变换（没看懂题目的意思）
17. 场景题：1T 大小的文件，1G 的内存，如何排序

百度后端三面（2023-3-18）

一天连续三面，顶不住了，前面聊的挺好，反手出了道 Hard 😧

1. 自我介绍
2. 介绍 KubeVela 的工作
3. 项目中的难点是什么，如何解决的
4. 还在维护这个项目吗
5. 除了你之外还有人在维护这个项目吗
6. 平时的兴趣爱好
7. 以后的职业发展计划是怎么样的
8. 是想做业务还是做基础架构
9. 为什么不选择使用 C++ 作为主力语言
10. 研究生读的什么方向
11. 为什么不介绍实验室的项目
12. 保研的时候，为什么选择这个方向
13. 算法题：编辑距离

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

func minDistance(word1 string, word2 string) int {
    size1,size2:=len(word1),len(word2)
    dp:=make([][]int,size1+1)
    for i:=0;i<=size1;i++{
        dp[i]=make([]int,size2+1)
        dp[i][0]=i
    }
    for j:=0;j<=size2;j++{
        dp[0][j]=j
    }
    
    for i:=1;i<=size1;i++{
        for j:=1;j<=size2;j++{
            if word1[i-1]==word2[j-1]{
                dp[i][j]=min(dp[i-1][j]+1,min(dp[i][j-1]+1,dp[i-1][j-1]))
            }else{
                dp[i][j]=min(dp[i-1][j],min(dp[i][j-1],dp[i-1][j-1]))+1
            }
        }
    }
    // fmt.Println(dp)
    return dp[size1][size2]
}

  

func min(a,b int)int{
    if a<b{
        return a
    }
    return b
}

百度后端二面（2023-3-18）

1. 自我介绍
2. 介绍一下对云原生的理解
3. 云原生除了微服务、容器化这些点，还带来了哪些提升
4. 以往的企业中不上云的情况下，是怎么部署项目的，运维是怎么进行的
5. 云原生的缺点是什么
6. 介绍一下 KubeVela 的工作
7. 这个工作完全是你自己做的吗
8. 采集的数据的粒度是什么样的，主要采集的指标有哪些
9. 介绍一下 SmartX 的工作，这个公司是做什么的
10. 采集的指标的有哪些，粒度是怎么样的
11. 你做的工作涵盖面很广，但都没有特别深入，你是怎么考虑这件事的
12. 算法题：重排链表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

func reorderList( head *ListNode )  {
    // write code here
    if head==nil || head.Next==nil{
        return 
    }
    m:=middleNode(head)
    
    l1,l2:=head,m.Next
    m.Next=nil
    l2=reverseList(l2)
    mergeList(l1,l2)
}

func middleNode(head *ListNode)*ListNode{
    fast,slow:=head,head
    for fast.Next!=nil && fast.Next.Next!=nil{
        fast=fast.Next.Next
        slow=slow.Next
    }
    return slow
}

func reverseList(head *ListNode) *ListNode{
    var pre,cur *ListNode=nil,head
    for cur!=nil{
        tmp:=cur.Next
        cur.Next=pre
        pre=cur
        cur=tmp
    }
    return pre
}

func mergeList(l1,l2 *ListNode) {
    var tmp1,tmp2 *ListNode
    for l1!=nil && l2!=nil{
        tmp1=l1.Next
        tmp2=l2.Next
        l1.Next=l2
        l1=tmp1
        l2.Next=l1
        l2=tmp2
    }
}

百度后端一面（2023-3-18）

1. 自我介绍
2. PingCAP 的这个项目是在实习的时候做的吗
3. 这个项目的结构是怎样的
4. 既然项目结构完全参照了 etcd，那他的意义是什么
5. 你知道 PingCAP 基于 TiKV 又做了一个什么产品吗
6. 介绍 KubeVela 中做的工作
7. vela top 如何获取资源状态
8. 介绍 SmartX 实习的工作
9. 介绍 cgroup 原理
10. 介绍网易有道实习的工作
11. MySQL 索引的数据结构
12. 为什么使用 B+ 树，和 B 树的区别是什么
13. MySQL 中索引结构对 B+ 树做了什么优化
14. HTTP2 做了什么优化
15. 介绍一下 HTTP3
16. WebSocket 的原理
17. 为什么选择使用 WebSocket
18. WebSocket 和 HTTP2 的主动推送的区别是什么
19. go 中在数据冲突的情况下保证数据一致，平时是怎么做的
20. go 的 gmp 模型
21. 场景题：一个没有使用 k8s 的 PaaS 平台，有 8 个服务，怎么保证正常的服务数量，服务宕机之后可以恢复，该怎么设计
22. 算法题：二叉树的层序遍历

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

func levelOrder( root *TreeNode ) [][]int {
    // write code here
    if root==nil{
        return [][]int{}
    }
    
    ans:=make([][]int,0)
    nodes:=make([]*TreeNode,0)
    nodes=append(nodes,root)
    
    for size:=len(nodes);size!=0;size=len(nodes){
        tmp:=make([]int,0)
        for i:=0;i<size;i++{
            tmp=append(tmp,nodes[i].Val)
            if nodes[i].Left!=nil{
                nodes=append(nodes,nodes[i].Left)
            }
            if nodes[i].Right!=nil{
                nodes=append(nodes,nodes[i].Right)
            }
        }
        nodes=nodes[size:]
        ans=append(ans,tmp)
    }
    return ans
}

百度笔试（2023-3-12）

3 道题：100%、100%、0%
最后一道题有思路，也是正确的，可惜没做出来，恨！

拼多多笔试（2023-3-11）

4 道题：100%、100%、100%、75%

美团笔试第一次（2023-3-10）

5 道题：100%、100%、73%、55%、0%

快手容器云二面（2023-02-28）

• 自我介绍
• 介绍一个参与过的项目
• 参与项目中遇到的困难，是如何解决的？
• 了解数据库吗？了解索引吗？
• 了解联合索引吗？
• 联合索引的字段顺序会如何影响索引使用。
• 了解网络吗？介绍一个 HTTP 与 HTTPS 的区别。
• TLS 在网络中的那一层？
• TCP 是如何通信的？序列号的作用。
• 做题，根据一个父子节点的关系表，重建一棵多叉树。

OC 审批走流程

快手容器云一面（2023-02-23）

项目

• 自我介绍
• 介绍一个参与过的项目
• 过程中的遇到的困难
• 项目能够支撑的应用数量级别
• 实习经历
• cgroup 的理解

语言

• channel 原理
• 向一个空的 channel 写入数据，会发生什么？（分有缓存和无缓存两种）
• 向一个未初始化的 channel 写入数据，会发生什么？（这个没答好，提示写出来了）
• 向一个关闭的 channel 写入数据，会发生什么？
• context 原理
• context 作用
• go 的垃圾回收
• 什么时候会触发写屏障？
• go 垃圾回收的问题，平时需要注意什么避免 GC 带来的性能问题
• goroutine 的原理，线程模型理解
• 线程通信方式
• go 协程通信方式

操作系统

• 什么时候会从用户态陷入内核态
• 线程通信方式

计算机网络

• 拥塞控制的原理
• 慢启动阶段的作用

k8s

• kube-proxy 的原理
• kube-proxy 三种模式
• ivs 相比于 iptable 通过 hash 的方式带来了性能提升，那么还有什么方式可以提升性能？（不懂）
• schuduler 的原理

做题

• 二叉树任意两个节点间的最大距离（没思路 g）
• 最长递增子序列

字节跳动飞书后端一面（2022-12-13）

1. 自我介绍
2. KubeVela 介绍
3. Raft 选举原理
4. Raft 3 个节点的集群，挂掉一个两外两个节点可以选举出新的 Leader 吗
5. Golang Chan 的原理
6. HTTPS 原理
7. Hash 冲突的解决办法
8. 做题：链表求和（反转链表写的有 Bug…）
9. 做题：简单 SQL（太久没写不记得 HAVING 和 Group BY 了）

体验很好，自己傻逼，这种简单题都没顺利完成，给我机会我不中用啊。
不过后续通知我通过了，不过没兴趣，直接去 SmartX 了不面了。

SMARTX 分布式管理平台三面 （2022-12-9）

1. 自我介绍
2. 介绍一下在 KubeVela 社区所做的工作。
3. 工作中的难点？
4. 提到的对网络 IO 造成界面阻塞，那界面阻塞是什么原因造成的？
5. 既然界面阻塞是因为单线程阻塞，那么不能采用多线程的方式吗？
6. TinyKV 的主要内容？
7. 给定一个场景：5 个节点全部掉线，又全部同时恢复，在 Raft 协议下，会发生什么？
8. 掉线节点如何知道自己的身份？
9. 持久化 leader 的状态的作用是什么？
10. 重新选举是如何进行的？
11. 为什么在判断消息是否过时要同时使用 index 和 term？
12. 给定一个场景：3 台机器，两个存储副本该如何实现？
13. Go 中 channel 的原理？

一周 OC，还算顺利

SMARTX 分布式管理平台二面 （2022-12-8）

1. 自我介绍和从事开发的介绍。
2. KubeVela 社区做的主要工作。
3. KubeVela 如何做资源采集。
4. K8S 中的组件。
5. 控制器是如何通知调度器，进行相应操作的。
6. 在网易搭建性能测试平台时所做的主要工作。
7. Jenkins 是多实例的吗？
8. MySQL 和 MongoDB 的区别和业务选型上的考量。
9. Docker 是如何做资源隔离的。
10. 平时使用 Linux 从事哪些开发。
11. 使用 Linux 内核的版本。
12. Linux 主要使用哪些命令。
13. 如何配置一个网卡的静态 IP。
14. 统计出现频率最高的 K 个单词。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

package main

import (
    "fmt"
    "strings"
)

type HeapNode struct {
    word string
    fre  int
}

func main() {
    content := "a b c a b b s"
    ans := make([]string, 2)
    freCountMap := countFre(content)
    freArray := convertMapToArray(freCountMap)
    size := len(freArray)
    buildHeap(freArray)
    for i := 0; i < 2; i++ {
        ans[i] = freArray[0].word
        freArray[size-1-i], freArray[0] = freArray[0], freArray[size-1-i]
        justify(freArray, 0, size-1-i)

    }
    fmt.Println(ans)
}

  

func countFre(content string) map[string]int {
    countMap := make(map[string]int)
    words := strings.Split(content, " ")
    for i := 0; i < len(words); i++ {
        countMap[words[i]]++
    }
    return countMap

}

  

func convertMapToArray(m map[string]int) []HeapNode {
    array := make([]HeapNode, len(m)+1)
    index := 1
    for key, value := range m {
        array[index] = HeapNode{
            word: key,
            fre:  value,
        }
        index++
    }
    return array
}

func buildHeap(wordArray []HeapNode) {
    size := len(wordArray)
    for i := len(wordArray) / 2; i >= 0; i-- {
        justify(wordArray, i, size)
    }
}

func justify(wordArray []HeapNode, top, size int) {
    left, right, k := top*2, top*2+1, top

    if left < size && wordArray[left].fre > wordArray[k].fre {
        k = left
    }

    if right < size && wordArray[right].fre > wordArray[k].fre {
        k = right
    }
    if k != top {
        wordArray[k], wordArray[top] = wordArray[top], wordArray[k]
        justify(wordArray, k, size)
    }

}

SMARTX 分布式管理平台一面 （2022-12-5）

• Raft 主要的内容，并分别阐述。
• 为 KubeVela 贡献的内容？
• KubeVela 资源信息采集是怎么做的？
• K8s 组件都有哪些？
• K8s 上 POD 的部署过程。
• K8s 如何减少 etcd 和 apiserver 的通信？
• K8s Service 是怎么将一个请求从 Service 重定向到容器的。
• Linux 上容器是怎么实现的？
• Linux 内存分配。
• 如果内存不足了这时候再使用 malloc 分配会怎么样。
• Linux 上减少 I/O 的方式有哪些？
• cache 是怎么减少 I/O 的？
• HTTP 长连接如何是实现的？
• HTTPS 是如何实现加密通信的？
• 非对称加密出了加密还有什么用途？
• WebSocket 原理。
• TCP 三次握手。
• TCP 半连接攻击。
• 实现一个多线程的一个生产者多个消费者场景。生产者有 n 的任务，最多同时有 m 个消费者。
• 如果不使用锁如何实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

package main

import (
    "fmt"
    "sync"
)

type Task struct {
    sum           int
    finishJobNum  int
    RunningWorker int
    jobs          chan int
    workerSignal  chan int
    syncSignal    chan int
    wg            sync.WaitGroup
}

func main() {
    var n, m int
    t := Task{
        jobs:         make(chan int, n),
        workerSignal: make(chan int, m),
        syncSignal:   make(chan int, 1),
    }

    t.Productor(n)
    t.syncSignal <- 1
    
    for i := 0; i < m; i++ {
        t.workerSignal <- 1
    }

    t.wg.Add(n)

    for {
        <-t.syncSignal
        if t.finishJobNum >= n {
            break
        }

        t.syncSignal <- 1
        <-t.workerSignal

        select {
        case num := <-t.jobs:
            go t.Consumer(num)
        }
    }

    t.wg.Wait()

}

func (t Task) Consumer(num int) {
    t.sum += t.DoTask(num)
    <-t.syncSignal
    fmt.Println(t.finishJobNum, t.sum)
    t.finishJobNum++
    t.RunningWorker++
    t.finishJobNum--
    t.syncSignal <- 1
    t.workerSignal <- 1
    t.wg.Done()
}

func (t Task) Productor(n int) {
    for i := 0; i < n; i++ {
        t.jobs <- i
    }
}

func (t Task) DoTask(k int) int {
    return k + 1
}

因为实际上 I/O 操作实际上分为两个阶段：将数据从 I/O 设备复制到内核区，将数据从内核区复制到用户区。前四种模型无法做到在两个阶段都不需要阻塞等待，他们都需要在第二个阶段阻塞等待数据从内核中复制到用户区，只有异步 I/O 模型可以做到无阻塞因此才被成为异步。

阻塞 I/O

最简单的一种 I/O 模型，当用户线程发出 I/O 请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出 CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除阻塞状态。

非阻塞 I/O

当用户线程发起一个 I/O 操作后，并不需要等待，而是马上就得到了一个结果。如果结果指示错误，它就知道数据还没有准备好，于是它可以再次发送 I/O 操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。

在非阻塞 I/O 模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞 I/O 不会交出 CPU，而会一直占用 CPU。过程中会反复执行系统调用询问数据是否已经可以读取，这样会导致 CPU 占用率非常高。

I/O 多路复用

Select

select 是操作系统提供的系统调用函数，select 用来等待文件描述词（普通文件、终端、伪终端、管道、FIFO、套接字及其他类型的字符型）状态的改变。是一个轮循函数，循环询问文件节点，可设置超时时间，超时时间到了就跳过代码继续往下执行。

通过 select，我们可以把一个文件描述符的数组发给操作系统， 让操作系统去遍历，确定哪个文件描述符可以读写， 然后告诉我们去处理：

原理

select 中描述符集合 fd_set 通过 bitmap 的方式进行存储。

bitmap 的基本思想就是用一个 bit 位来标记某个元素是否存在，由于采用了 bit 为单位来存储数据，因此可以大大节省存储空间。

例如利用一个 32bit 的整数的每一个 bit 便可以表示 0~31 范围内的哪些数字存在哪些数字不存在。

fd_set 则是一个长度确定 unsigned long 数组，一共组成一个 1024bit 的连续空间，每一 bit 可以对应一个描述符 fd，因此一共可以对应 1024 个描述符。

1
2
3
4
5
6
7
8
9

#define FD_SETSIZE 1024 
#define NFDBITS (8 * sizeof(unsigned long)) 
#define __FDSET_LONGS (FD_SETSIZE/NFDBITS) 

// 数据结构 (bitmap) 
typedef struct { 
unsigned long fds_bits[__FDSET_LONGS]; 
} fd_set;

相关函数

1
2
3
4
5
6
7

int select(
int maxfdp ,
fd_set *readset , 
fd_set *writeset , 
fd_set *exceptset ,
struct timeval *timeout
);

参数

• maxfdp：被监听的文件描述符的最大值，它比所有文件描述符集合中的文件描述符的最大值大 1，因为文件描述符是从 0 开始计数的；
• readfds、writefds、exceptset：分别指向可读、可写和异常等事件对应的描述符集合。
• timeout：用于设置 select 函数的超时时间，即告诉内核 select 等待多长时间之后就放弃等待。timeout == NULL 表示等待无限长的时间，timeout == 0，select 立即返回

1
2
3
4

int FD_ZERO(int fd, fd_set *fdset); //一个 fd_set类型变量的所有位都设为 0 
int FD_CLR(int fd, fd_set *fdset); //清除某个位时可以使用 
int FD_SET(int fd, fd_set *fd_set); //设置变量的某个位置位 
int FD_ISSET(int fd, fd_set *fdset); //测试某个位是否被置位

例如

设置 fd_set 长度为 8，则对应 8 个 fd。

1. 执行 FD_ZERO(&set); 则 fd_set 用位表示是 00000000。
2. 用户传关注的文件描述符 fd＝5, 执行 FD_SET(fd,&set); 后 fd_set 变为 00010000(第 5 位为 1)。
3. 若再加入 fd＝2，fd=1，则 fd_set 变为 00010011。
4. 执行 select(6,&set,0,0,0) 阻塞等待。
5. 若 fd=1,fd=2 上都发生可读事件，则 select 返回，此时 set 变为 00000011。没有事件发生的 fd=5 被清空。

评价

1. select 本质上是设置与判断 bitmap 每一位上的值来判断对应描述符是否可以执行下一步的操作的。因为 bitmap 的大小是确定的，因此单个进程所打开的 fd 的数量是有限制的。
2. 每次调用 select，都需要把 fd 集合从用户态拷贝到内核态。
3. select 是采用轮询的方式判断描述符对应的硬件是否已经就绪，因此效率太低。

Poll

select 和 poll 系统调用的本质一样，poll 的机制与 select 类似，与 select 在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是 poll 没有最大文件描述符数量的限制（ 基于链表来存储的，但是数量过大后性能也是会下降）。

poll 和 select 同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。

1
2
3
4
5
6
7
8

int poll(struct pollfd *fds, nfds_t nfds, int timeout);


struct pollfd{ 
int fd; //文件描述符 
short events; //等待的事件 
short revents; //实际发生的事件 
};

参数

• fds ： 指向一个 pollfd 数组的指针，用于指定测试某个给定的 fd 的条件。
• nfds ： 指定 fds 数组元素个数 ，相当于要检查多少个文件描述符。
• timeout：指定等待的毫秒数，无论 I/O 是否准备好，poll() 都会返回。

在用户态时描述符是通过数组方式存储的，在复制进内核后会被转换为链表的形式存储，因此没有存储大小的限制。（关于poll的疑问？数组还是链表？）

每个结构体的 events 域是由用户来设置，告诉内核我们关注的是什么，而 revents 域是返回时内核设置的，以说明对该描述符发生了什么事件。

返回值

成功时，poll() 返回结构体中 revents 域不为 0 的文件描述符个数；如果在超时前没有任何事件发生，poll() 返回 0。

ePoll

epoll 没有对描述符数目的限制，它所支持的文件描述符上限是整个系统最大可以打开的文件数目，例如，在 1GB 内存的机器上，这个限制大概为 10 万左右。

epoll 只有 epoll_create，epoll_ctl 和 epoll_wait 这三个系统调用。

当某一进程调用 epoll_create 方法时，Linux 内核会创建一个 eventpoll 结构体，这个结构体也即是 epoll 对象的一个句柄，会通过 epoll_create 函数返回。

1

int epoll_create(int size); // 返回值就是 epoll 对象的句柄

1
2
3
4
5
6

struct eventpoll { 
// 监听列表：红黑树的根节点，这颗树中存储着所有添加到 epoll 中的需要监控的事件
struct rb_root rbr; 
// 就绪列表：双链表中则存放着将要通过 epoll_wait 返回给用户的满足条件的事件
struct list_head rdlist; 
};

每一个 epoll 对象都有一个对应的 eventpoll 结构体，用于存放通过 epoll_ctl 方法向 epoll 对象中添加进来的事件，这些事件都会挂载在红黑树中。

1

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); 

而所有添加到 epoll 中的事件都会与设备驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫 ep_poll_callback，它会将发生的事件添加到 rdlist 双链表中。

参数

• epfd：如何确定将事件加入那个 epoll 对象呢？就是通过上文提到的句柄实现的。
• op：操作类型
  • EPOLL_CTL_ADD：注册新的 fd 到 epfd 中
  • EPOLL_CTL_MOD：修改已经注册的 fd 的监听事件
  • EPOLL_CTL_DEL：从 epfd 中删除一个 fd
• fd：需要注册监视对象文件描述符。
• event：告诉内核需要监听什么事件。

epoll_wait 的作用相当于 select，当调用 epoll_wait 检查是否有事件发生时，只需要检查 eventpoll 对象中的 rdlist 双链表中是否有事件元素即可。如果 rdlist 不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

1

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

参数

• epfd：epoll_create 函数的返回值，epoll 对象的句柄
• events：是分配好的 epoll_event 结构体数组，epoll 将会把发生的事件赋值到 events 数组中
• maxevents：告诉内核这个 events 数组有多大，这个 maxevents 的值不能大于创建 epoll_create 时的 size。
• timeout：是超时时间，如果函数调用成功，则返回对应 I/O 上已准备好的文件描述符数目，如果返回 0 则表示已经超时。

信号驱动 I/O

在信号驱动 I/O 模型中，当用户线程发起一个 I/O 请求操作，会给对应的 I/O 操作注册一个信号函数，然后用户线程会继续执行，当内核数据就绪时会发送一个信号给用户线程，用户线程接收到信号之后，便在信号函数中调用中断程序，中断原本正在执行的操作，转而进行实际的 I/O 请求操作。

信号驱动 I/O 的前半部分是异步进行的，不需要阻塞等待 I/O 设备数据的写入，也不需要通过轮询的方式判断数据是否就绪，但将数据从内核种复制出来的过程，依然需要中断原本的操作，转而去读取数据，这部分的操作导致这种模型依然不是全异步的。

异步 I/O

Reactor

在 Reactor 模式中，会先对每个 client 注册感兴趣的事件，然后有一个线程专门去轮询每个 client 是否有事件发生，当有事件发生时，便处理每个事件，当所有事件处理完之后，便再转去继续轮询。从这里可以看出，多路复用 I/O 就是采用 Reactor 模式。

Proactor

在 Proactor 模式中：当检测到有事件发生时，会新起一个异步操作，然后交由 内核线程 去处理，当内核线程完成 I/O 操作之后，发送一个通知告知操作已完成；可以得知，异步 I/O 模型采用的就是 Proactor 模式。

异步 I/O 模型是理想的 I/O 模型，在异步 I/O 模型中，当用户线程发起读取数据的操作之后，立刻就可以开始去做其它的事。因此不会对用户线程产生任何阻塞。

内核收到 read 请求之后，会生成一个内核线程，该线程会等待数据准备完成，然后将数据拷贝到用户区，当这一切都完成之后，内核会给用户线程发送一个信号，告诉它 read 操作完成了。

用户线程甚至不用阻塞去到内核区拷贝数据，因为内核线程已经将数据拷贝至用户区了。因此异步 I/O 才是真正的异步实现，在两个阶段都做到了异步。

参考

Linux 网络编程的5种IO模型：异步IO模型

IO多路复用API总结

彻底理解 IO 多路复用实现机制

Linux I/O 多路复用，select / poll / epoll 详解

控制器启动

Application 控制器是 OAM 控制集中的一个控制器，在控制器启动的流程中，通过调用了 OAM 控制集的启动，间接启动了该控制器。

1
2
3
4
5
6
7
8
9
10
11
12

// Setup adds a controller that reconciles AppRollout.
func Setup(mgr ctrl.Manager, args core.Args) error {
reconciler := Reconciler{
Client:   mgr.GetClient(),
Scheme:   mgr.GetScheme(),
Recorder: event.NewAPIRecorder(mgr.GetEventRecorderFor("Application")),
dm:       args.DiscoveryMapper,
pd:       args.PackageDiscover,
options:  parseOptions(args),
}
return reconciler.SetupWithManager(mgr)
}

启动控制的最后一步，将初始化的控制器安装至控制器管理器。

安装至管理器

将控制器安装至管理器的流程如下图所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// SetupWithManager install to manager
func (r *Reconciler) SetupWithManager(mgr ctrl.Manager) error {
// If Application Own these two child objects, AC status change will notify application controller and recursively update AC again, and trigger application event again...
return ctrl.NewControllerManagedBy(mgr).
Watches(&source.Kind{
Type: &v1beta1.ResourceTracker{},
}, ctrlHandler.Funcs{
...
}).
WithOptions(controller.Options{
...
}).
WithEventFilter(predicate.Funcs{
            ...
}).
For(&v1beta1.Application{}).
Complete(r)
}

Watch函数是一个较低层次的，用于被监控资源类型的函数，For 函数与 Own 函数的功能也可以使用 Watch 函数实现。但不同的是，Watch 函数可以自行提供 Handler 函数。此处Watch函数关注的ResourceTracker类型，用于实现垃圾回收。

For 函数的对象是 reconcile 的对象，该类型的对象的 create、delete、update 事件会触发对应的Reconcile函数，一个 controller builder 中不能不存在 For 函数。

Reconcile

Reconcile函数会在控制器对应类型对象的状态与声明状态不符时自动被调用。下图是Reconcile的流程示意图。

appfile

生成 parser

生成parser的过程比较简单，较为关键的是parser实例化的过程中tmplLoader装载了一个LoadTemplate函数，这个函数作为一个回调函数会在后续的流程中调用，用于解析component、workflowStep等的定义。

该函数会根据传入capability definition的类型，获取对应的definition，然后生成对应的template。

生成appfile有两种途径，一种是从appRevision生成，另一种是从app生成，appRevision可以看作是app的一种快照。生成appfile前首先需要判断一下，当前的appRevision的版本是否与发布app的版本对应，若是则选择从appResion生成，否则则选择从app生成。

为何有了appRevision这一中间产物，为什么不每次都从app生成，这个答案可以从两者结构体的不同中找到答案。

• app.Spec

  1 2 3 4 5

  type ApplicationSpec struct { Components []common.ApplicationComponent Policies []AppPolicy Workflow *Workflow }

• appRevision.Spec

  1 2 3 4 5 6 7 8 9 10 11 12 13

  type ApplicationRevisionSpec struct { Application Application ComponentDefinitions map[string]ComponentDefinition WorkloadDefinitions map[string]WorkloadDefinition TraitDefinitions map[string]TraitDefinition ScopeDefinitions map[string]ScopeDefinition PolicyDefinitions map[string]PolicyDefinition WorkflowStepDefinitions map[string]WorkflowStepDefinition ScopeGVK map[string]v1.GroupVersionKind Policies map[string]v1alpha1.Policy Workflow *v1alpha1.Workflow ReferredObjects []common.ReferredObject }

appRevision.Spec相当于是对app.Spec进行了一个拆解转化，这个过程需要一定的运算，后续步骤中进行的运算也即是进行这个过程，这个运算的消耗可以通过快照的方法进行节省，所以在判断快照的版本合法的情况下直接从快照生成appfile。

从 app 生成 appfile

我们可以通过官网提供的一个定义 app 的 yaml 文件与源码中 Application 结构体相对应来了解 app 的数据结构。

此处我们以从app生成为例，分析appfile的生成流程。

workload

其中比较重要的步骤为parseWorkload，在装载步骤步骤中的三种Definition也是来自解析出的workload。

parseWorkload的作用可以从函数的注释中获取到，其作用是”解析一个 ApplicationComponent 并生成一个包含 Appfile 所需的所有信息的 Workload ”。

parseWorkload resolve an ApplicationComponent and generate a Workload containing ALL information required by an Appfile.

1. 生成workload的过程中，首先需要利用我们上文 parser 提到的 LoadTemplate函数，此处使用该函数是传入的capability definition 为 componentDefinition，因此是生成 component 对应的 template。

2. 然后使用 template 解析 component 中的参数将其转化为 workload，也即component.properties部分。参数详细信息参照：https://kubevela.io/zh/docs/next/end-user/components/references。

   

3. 加载部分参数，包括加载 trait，加载scope。

workflowStep

parseWorkflowSteps是另一个较为重要的步骤，关于工作流的详细信息可以参照官网文档：https://kubevela.io/zh/docs/next/end-user/workflow/overview。

• loadWorkflowToAppfile的设计非常巧妙，使用了函数链式调用的设计，将多个步骤进行了串联：

  

  • 其中DeployWorkflowStepGenerator会将 policy，转换为deploy类型的 step，这里进行转换的 policy 的类型为 override 与 topology 两种类型。

  • ApplyComponentWorkflowStepGenerator则将会将app.component转换为apply-component类型的 step。

• parseWorkflowStep则遍历上文生成的 step，获取对应类型的definition，将其装载至 appfile 的RelatedWorkflowStepDefinitions字段中。

workflow step

生成 taskRunner

这部分对应的函数是GenerateApplicationSteps及相关函数，这里所做的处理是将上文 的step （v1beta1.WorkflowStep），转换为一种新类型的 step（wfTypes.TaskRunner）。

在生成 taskRunner 之前，首先要注册数个Provider，这些 Provider 会提供相应的能力，后续会使用他们的能力去实现相应的操作。

在 taskDiscover 的过程中，实际上在其内部还封装了一个 TaskLoader，这二者的作用都是在下面的流程中加载tempplate。

GetTaskGenerator 的过程中，会使用分别使用上文提到的taskDiscover 与 TaskLoader 加载 CUE 类型的 template，并作为参数传入 makeTaskGenerator，makeTaskGenerator 的逻辑比较复杂，这里它并没有直接运行任何函数，而是返回了一个闭包函数，这个函数被赋值给 genTask 变量，接下来会执行 genTask，进而调用这个闭包函数。

这个闭包函数中主要创建了 taksRunner 类型的变量 tRunner，并初始化了他的三个字段，其中我们重点关注run 这个字段，该字段为一个函数类型的字段，这里会将一个匿名函数赋值给他，tRuner 作为返回值进行返回，至此便将 step 成功转换为了 taskRunner。

执行 task

该过程对应ExecuteSteps所进行的操作。执行该函数时会初始化一个 workflow 的 engine，然后调用 engine 的 Run 方法。Run 方法会运行上文生成的 taskRunner ，执行方式有两种：StepByStep 顺序执行以及 DAG 并行执行，关于 workflow 的执行方式的详细信息可以参考：https://kubevela.io/zh/docs/next/end-user/workflow/overview。

这两个执行方式最后都会遍历 taskRunner，然后调用其 Run 方法，该方法实际上也即上文我们在创建 taksRunner 时，设置在其 run 字段上的函数。

现在我们可以回头重新来分析一下，这个 run 字段上的函数做了怎样的操作：

实际上该函数的操作分为两大部分：渲染CUE value与解析CUE value执行相应操作。

渲染CUE value前会将上文我们获取到的workflowStep definition的与workflow.Properties（参数）组合在一起，这两个部分组合在一起模板+参数就构成一个确定的workflowStep，之后将其加载为CUE value。

解析参数并执行相应操作的过程，主要由doStep函数完成，该函数的主要思路即为根据CUE value中的相关定义，获取相应的Provider中的相应能力（函数），执行相应的能力（函数）。

KubeVela以应用为中心，通过OAM（开放应用模型）作为核心API进行构建，同时KubeVela也是OAM的最佳实践。

KubeVela中将应用拆分为各种细粒度的组件，并通过CRD注册到K8S中。同时KubeVela通过引入CUE作为模板引擎，提供了对CRD的抽象，用户可以用过编写CUE定义的应用模板，将多种K8S资源组装在一起构成应用。

控制器启动

我们从cmd/core/main.go文件的main函数入手，这里是核心资源以及控制器启动的入口。控制器启动是一个漫长的过程，有很多步骤，下图是控制器启动的流程示意图。

绑定变量

从命令行读入参数或采用默认值绑定至变量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// 是否开启 Admission Webhook
flag.BoolVar(&useWebhook, "use-webhook", false, "Enable Admission Webhook")
// Admission webhook 证书目录
flag.StringVar(&certDir, "webhook-cert-dir", "/k8s-webhook-server/serving-certs", "Admission webhook cert/key dir.")
// Admission webhook 监听端口
flag.IntVar(&webhookPort, "webhook-port", 9443, "admission webhook listen address")
// Prometheus exporter 监听地址
flag.StringVar(&metricsAddr, "metrics-addr", ":8080", "The address the metric endpoint binds to.")
// 是否开启控制器主阶段选举。开启之后同一时间只允许一个控制器处于激活状态， 其他副本控制器将处于休眠状态。
flag.BoolVar(&enableLeaderElection, "enable-leader-election", false,
             "Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.")
// 定义主节点选举 configmap 所在 namespace 默认处于 default namespace 下
flag.StringVar(&leaderElectionNamespace, "leader-election-namespace", "",
               "Determines the namespace in which the leader election configmap will be created.")
// 日志落盘目录
flag.StringVar(&logFilePath, "log-file-path", "", "The file to write logs to.")
// 日志最大体积
flag.Uint64Var(&logFileMaxSize, "log-file-max-size", 1024, "Defines the maximum size a log file can grow to, Unit is megabytes.")
// 是否开启debug日志
flag.BoolVar(&logDebug, "log-debug", false, "Enable debug logs for development purpose")
flag.IntVar(&controllerArgs.RevisionLimit, "revision-limit", 50,
            "RevisionLimit is the maximum number of revisions that will be maintained. The default value is 50.")
// 没有使用应用的版本，可能用于垃圾回收，下同
flag.IntVar(&controllerArgs.AppRevisionLimit, "application-revision-limit", 10,
            "application-revision-limit is the maximum number of application useless revisions that will be maintained, if the useless revisions exceed this number, older ones will be GCed first.The default value is 10.")
flag.IntVar(&controllerArgs.DefRevisionLimit, "definition-revision-limit", 20,
            "definition-revision-limit is the maximum number of component/trait definition useless revisions that will be maintained, if the useless revisions exceed this number, older ones will be GCed first.The default value is 20.")
flag.StringVar(&controllerArgs.CustomRevisionHookURL, "custom-revision-hook-url", "",
               "custom-revision-hook-url is a webhook url which will let KubeVela core to call with applicationConfiguration and component info and return a customized component revision")
flag.BoolVar(&controllerArgs.AutoGenWorkloadDefinition, "autogen-workload-definition", true, "Automatic generated workloadDefinition which componentDefinition refers to.")
// 健康检查接口监听地址
flag.StringVar(&healthAddr, "health-addr", ":9440", "The address the health endpoint binds to.")
// 如果spec没有发生变化，不允许进行apply操作
flag.StringVar(&applyOnceOnly, "apply-once-only", "false",
               "For the purpose of some production environment that workload or trait should not be affected if no spec change, available options: on, off, force.")
// 是否禁用的内置功能列表
flag.StringVar(&disableCaps, "disable-caps", "", "To be disabled builtin capability list.")
// Application 文件存放的存储介质，默认为本地存放
flag.StringVar(&storageDriver, "storage-driver", "Local", "Application file save to the storage driver")
flag.DurationVar(&commonconfig.ApplicationReSyncPeriod, "application-re-sync-period", 5*time.Minute,
                 "Re-sync period for application to re-sync, also known as the state-keep interval.")
flag.DurationVar(&commonconfig.ReconcileTimeout, "reconcile-timeout", time.Minute*3,
                 "the timeout for controller reconcile")
...

配置日志设置

1
2
3
4
5
6
7
8
9

if logDebug {
    _ = flag.Set("v", strconv.Itoa(int(commonconfig.LogDebug)))
}
...
if logFilePath != "" {
    _ = flag.Set("logtostderr", "false")
    _ = flag.Set("log_file", logFilePath)
    _ = flag.Set("log_file_max_size", strconv.FormatUint(logFileMaxSize, 10))
}

pprof 服务启动

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// pprof server setup
if pprofAddr != "" {
    // Start pprof server if enabled
    mux := http.NewServeMux()
    mux.HandleFunc("/debug/pprof/", pprof.Index)
    mux.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)
    mux.HandleFunc("/debug/pprof/profile", pprof.Profile)
    mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
    mux.HandleFunc("/debug/pprof/trace", pprof.Trace)
    pprofServer := http.Server{
        Addr:    pprofAddr,
        Handler: mux,
    }
    klog.InfoS("Starting debug HTTP server", "addr", pprofServer.Addr)

    go func() {
        go func() {
            ctx := context.Background()
            <-ctx.Done()

            ctx, cancelFunc := context.WithTimeout(context.Background(), 60*time.Minute)
            defer cancelFunc()

            if err := pprofServer.Shutdown(ctx); err != nil {
                klog.Error(err, "Failed to shutdown debug HTTP server")
            }
        }()

        if err := pprofServer.ListenAndServe(); !errors.Is(http.ErrServerClosed, err) {
            klog.Error(err, "Failed to start debug HTTP server")
            panic(err)
        }
    }()
}

加载restConfig

各个控制器作为API-Server的客户端，这里加载的配置即为API-Server与客户端交互的配置，这些配置会影响客户端与API-Server之间的交互。

这里对UserAgent设置的目的是为了方便在日志中排查是哪个 pod 对 API-server 发起了请求。对 QPS 和 Burst 的设置限制了 API-Server 从客户端收到请求的每秒最高并发数，通过限制从客户端处进行限流保证 API-Server 的处于一个可用的状态，不会因为某些控制器的高频请求而导致整个集群的宕机。

1
2
3
4
5

restConfig := ctrl.GetConfigOrDie()
restConfig.UserAgent = types.KubeVelaName + "/" + version.GitRevision
restConfig.QPS = float32(qps)
restConfig.Burst = burst
restConfig.Wrap(auth.NewImpersonatingRoundTripper)

多集群环境配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// wrapper the round tripper by multi cluster rewriter
if enableClusterGateway {
    client, err := multicluster.Initialize(restConfig, true)
    if err != nil {
        klog.ErrorS(err, "failed to enable multi-cluster capability")
        os.Exit(1)
    }

    if enableClusterMetrics {
        _, err := multicluster.NewClusterMetricsMgr(context.Background(), client, clusterMetricsInterval)
        if err != nil {
            klog.ErrorS(err, "failed to enable multi-cluster-metrics capability")
            os.Exit(1)
        }
    }
}

控制器管理器初始化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

mgr, err := ctrl.NewManager(restConfig, ctrl.Options{
    Scheme:                     scheme,
    MetricsBindAddress:         metricsAddr,
    LeaderElection:             enableLeaderElection,
    LeaderElectionNamespace:    leaderElectionNamespace,
    LeaderElectionID:           leaderElectionID,
    Port:                       webhookPort,
    CertDir:                    certDir,
    HealthProbeBindAddress:     healthAddr,
    LeaderElectionResourceLock: leaderElectionResourceLock,
    LeaseDuration:              &leaseDuration,
    RenewDeadline:              &renewDeadline,
    RetryPeriod:                &retryPeriod,
    // SyncPeriod is configured with default value, aka. 10h. First, controller-runtime does not
    // recommend use it as a time trigger, instead, it is expected to work for failure tolerance
    // of controller-runtime. Additionally, set this value will affect not only application
    // controller but also all other controllers like definition controller. Therefore, for
    // functionalities like state-keep, they should be invented in other ways.
    NewClient: ctrlClient.DefaultNewControllerClient,
})

注册健康检查

1
2
3
4

if err := registerHealthChecks(mgr); err != nil {
    klog.ErrorS(err, "Unable to register ready/health checks")
    os.Exit(1)
}

检查被禁用控制器是否合法

1
2
3
4

if err := utils.CheckDisabledCapabilities(disableCaps); err != nil {
    klog.ErrorS(err, "Unable to get enabled capabilities")
    os.Exit(1)
}

加载控制器应用模式

控制器存在三种应用模式：applyOnceOnly、ApplyOnceOnlyOn、ApplyOnceOnlyForce。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

switch strings.ToLower(applyOnceOnly) {
case "", "false", string(oamcontroller.ApplyOnceOnlyOff):
controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyOff
klog.Info("ApplyOnceOnly is disabled")
case "true", string(oamcontroller.ApplyOnceOnlyOn):
controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyOn
klog.Info("ApplyOnceOnly is enabled, that means workload or trait only apply once if no spec change even they are changed by others")
case string(oamcontroller.ApplyOnceOnlyForce):
controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyForce
klog.Info("ApplyOnceOnlyForce is enabled, that means workload or trait only apply once if no spec change even they are changed or deleted by others")
default:
klog.ErrorS(fmt.Errorf("invalid apply-once-only value: %s", applyOnceOnly),
"Unable to setup the vela core controller",
"apply-once-only", "on/off/force, by default it's off")
os.Exit(1)
}

注册资源发现客户端

K8S资源

这个函数返回一个DiscoveryMapper，根据他的注释可以将其看作一个从GVK获取资源的客户端。

DiscoveryMapper is a interface for refresh and discovery resources from GVK.

1

dm, err := discoverymapper.New(mgr.GetConfig())

CUE资源

这个函数注册了从K8S集群中获取CUE包的客户端。

PackageDiscover defines the inner CUE packages loaded from K8s cluster

1

pd, err := packages.NewPackageDiscover(mgr.GetConfig())

注册Webhook

1
2
3
4
5
6
7
8

if useWebhook {
    klog.InfoS("Enable webhook", "server port", strconv.Itoa(webhookPort))
    oamwebhook.Register(mgr, controllerArgs)
    if err := waitWebhookSecretVolume(certDir, waitSecretTimeout, waitSecretInterval); err != nil {
        klog.ErrorS(err, "Unable to get webhook secret")
        os.Exit(1)
    }
}

注册控制器集

OAM控制器集

内部包含很多核心控制器，包括application、trait、component、policy、workflow多个控制器。

1
2
3
4

if err = oamv1alpha2.Setup(mgr, controllerArgs); err != nil {
    klog.ErrorS(err, "Unable to setup the oam controller")
    os.Exit(1)
}

Vela控制器集

1
2
3
4

if err = standardcontroller.Setup(mgr, disableCaps, controllerArgs); err != nil {
    klog.ErrorS(err, "Unable to setup the vela core controller")
    os.Exit(1)
}

启动应用指标检测

1
2
3
4
5

informer, err := mgr.GetCache().GetInformer(context.Background(), &v1beta1.Application{})
if err != nil {
    klog.ErrorS(err, "Unable to get informer for application")
}
watcher.StartApplicationMetricsWatcher(informer)

控制器管理器启动

1
2
3
4

if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
    klog.ErrorS(err, "Failed to run manager")
    os.Exit(1)
}

KubeVela本身是一个比较新的项目，正处于高速发展期，因此很多设计可能会在短时间内就迎来变化，因此本文介绍是V1.4~V1.5版本时KubeVela内部加载一个插件的流程。

插件目录结构

自定义插件 | KubeVela

以上暂时是KubeVela V1.4版本的插件结构，在V1.5版本后会将插件使用的VelaQL实例view文件单独渲染，因此引入了一个新的文件目录views，下文都是以新的目录结构进行论述。新的插件目录结构如下：

1
2
3
4
5
6
7

├── resources/
├── definitions/
├── schemas/
├── views/
├── README.md
├── metadata.yaml
└── template.yaml

插件渲染流程

加载安装包

EnableAddon

pkg/addon/helper.go

1
2
3
4
5
6
7
8
9
10
11
12

func EnableAddon(ctx context.Context, name string, version string, cli client.Client, discoveryClient *discovery.DiscoveryClient, apply apply.Applicator, config *rest.Config, r Registry, args map[string]interface{}, cache *Cache) error {
h := NewAddonInstaller(ctx, cli, discoveryClient, apply, config, &r, args, cache)
pkg, err := h.loadInstallPackage(name, version)
if err != nil {
return err
}
err = h.enableAddon(pkg)
if err != nil {
return err
}
return nil
}

这里比较重要的是两个函数：loadInstallPackage 和 enableAddon

loadInstallPackage

pkg/addon/addon.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

func (h *Installer) loadInstallPackage(name, version string) (*InstallPackage, error) {
var installPackage *InstallPackage
var err error
if !IsVersionRegistry(*h.r) {
...
var uiData *UIData
uiData, err = h.cache.GetUIData(*h.r, name, version)
...
// enable this addon if it's invisible
installPackage, err = h.r.GetInstallPackage(&meta, uiData)
...
} else {
versionedRegistry := BuildVersionedRegistry(h.r.Name, h.r.Helm.URL, &common.HTTPOption{
Username: h.r.Helm.Username,
Password: h.r.Helm.Password,
})
installPackage, err = versionedRegistry.GetAddonInstallPackage(context.Background(), name, version)
...
}

return installPackage, nil
}

这个函数首先检查安装插件的仓库是否是一个支持多版本的仓库，这个检查也很简单直接判断是否设置了helm字段。

若不支持多版本（本地或者OSS），则直接安装插件，否则构建一个多版本的仓库对象，然后根据需要的addon的name和version安装插件。

加载插件安装包

不支持多版本安装包

GetInstallPackage

pkg/addon/source.go

1
2
3
4
5

// GetInstallPackage get install package which is all needed to enable an addon from addon registry
func (r *Registry) GetInstallPackage(meta *SourceMeta, uiData *UIData) (*InstallPackage, error) {
...
return GetInstallPackageFromReader(reader, meta, uiData)
}

GetInstallPackageFromReader

pkg/addon/addon.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// GetInstallPackageFromReader get install package of addon from Reader, this is used to enable an addon
func GetInstallPackageFromReader(r AsyncReader, meta *SourceMeta, uiData *UIData) (*InstallPackage, error) {
addonContentsReader := map[string]func(a *InstallPackage, reader AsyncReader, readPath string) error{
TemplateFileName: readTemplate,
ResourcesDirName: readResFile,
DefSchemaName:    readDefSchemaFile,
ViewDirName:      readViewFile,
}
ptItems := ClassifyItemByPattern(meta, r)

// Read the installed data from UI metadata object to reduce network payload
var addon = &InstallPackage{
Meta:           uiData.Meta,
Definitions:    uiData.Definitions,
CUEDefinitions: uiData.CUEDefinitions,
Parameters:     uiData.Parameters,
}

for contentType, method := range addonContentsReader {
items := ptItems[contentType]
for _, it := range items {
err := method(addon, r, r.RelativePath(it))
...
}
}

return addon, nil
}

该函数将template、resource、schema、view分别加载进相应的字段中，用于下面启动插件时加载用。

多版本安装包

GetAddonInstallPackage

pkg/addon/versioned_registry.go

1
2
3
4
5
6
7
8

func (i *versionedRegistry) GetAddonInstallPackage(ctx context.Context, addonName, version string) (*InstallPackage, error) {
// 加载插件，重要
wholePackage, err := i.loadAddon(ctx, addonName, version)
if err != nil {
return nil, err
}
return &wholePackage.InstallPackage, nil
}

loadAddon

pkg/addon/versioned_registry.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

func (i versionedRegistry) loadAddon(ctx context.Context, name, version string) (*WholeAddonPackage, error) {
versions, err := i.h.ListVersions(i.url, name, false, i.Opts)
if err != nil {
return nil, err
}
if len(versions) == 0 {
return nil, ErrNotExist
}
sort.Sort(sort.Reverse(versions))
addonVersion, availableVersions := chooseVersion(version, versions)
if addonVersion == nil {
return nil, fmt.Errorf("specified version %s not exist", version)
}
for _, chartURL := range addonVersion.URLs {
if !utils.IsValidURL(chartURL) {
chartURL, err = utils.JoinURL(i.url, chartURL)
if err != nil {
return nil, fmt.Errorf("cannot join versionedRegistryURL %s and chartURL %s, %w", i.url, chartURL, err)
}
}
archive, err := common.HTTPGetWithOption(ctx, chartURL, i.Opts)
if err != nil {
continue
}
bufferedFile, err := loader.LoadArchiveFiles(bytes.NewReader(archive))
if err != nil {
continue
}
addonPkg, err := loadAddonPackage(name, bufferedFile)
if err != nil {
return nil, err
}
addonPkg.AvailableVersions = availableVersions
addonPkg.RegistryName = i.name
return addonPkg, nil
}
return nil, fmt.Errorf("cannot fetch addon package")
}

loadAddon是一个很重要的代码，被反复使用。

1. 主要的逻辑为首先使用*ListVersions*函数加载插件的多个版本

   ListVersions

   1 2 3 4 5 6 7

   func (h *Helper) ListVersions(repoURL string, chartName string, skipCache bool, opts *common.HTTPOption) (repo.ChartVersions, error) { i, err := h.GetIndexInfo(repoURL, skipCache, opts) if err != nil { return nil, err } return i.Entries[chartName], nil }

   该函数首先获取chart repo的index.yaml文件，该文件对象的类型为*repo.IndexFile该类型的结构为：

   1 2 3 4 5 6 7 8

   type IndexFile struct { ServerInfo map[string]interface{} `json:"serverInfo,omitempty"` APIVersion string `json:"apiVersion"` Generated time.Time `json:"generated"` Entries map[string]ChartVersions `json:"entries"` PublicKeys []string `json:"publicKeys,omitempty"` Annotations map[string]string `json:"annotations,omitempty"` }

   该对象的Entries字段为一个map对象，该map的<key,value>对为addon名和该addon的多个版本。

2. 然后对多个版本进行由大到小的排序，然后根据version信息确定要获取的对应版本的addon。

3. 根据该版本addon的url，获取对应的压缩包文件，然后解压缩后将meta.yaml对应的字节码加载进*WholeAddonPackage类型的addonPkg对象中。

4. loadAddonPackage 从压缩包的schemas、resources、views目录中加载相关组件信息。

   loadAddonPackage

   1 2 3 4 5 6 7 8 9 10

   func loadAddonPackage(addonName string, files []*loader.BufferedFile) (*WholeAddonPackage, error) { mr := MemoryReader{Name: addonName, Files: files} metas, err := mr.ListAddonMeta() ... meta := metas[addonName] addonUIData, err := GetUIDataFromReader(&mr, &meta, UIMetaOptions) ... installPackage, err := GetInstallPackageFromReader(&mr, &meta, addonUIData) ... }

   GetInstallPackageFromReader

   pkg/addon/addon.go

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

   // GetInstallPackageFromReader get install package of addon from Reader, this is used to enable an addon func GetInstallPackageFromReader(r AsyncReader, meta *SourceMeta, uiData *UIData) (*InstallPackage, error) { addonContentsReader := map[string]func(a *InstallPackage, reader AsyncReader, readPath string) error{ TemplateFileName: readTemplate, ResourcesDirName: readResFile, DefSchemaName: readDefSchemaFile, ViewDirName: readViewFile, } ptItems := ClassifyItemByPattern(meta, r) // Read the installed data from UI metadata object to reduce network payload var addon = &InstallPackage{ Meta: uiData.Meta, Definitions: uiData.Definitions, CUEDefinitions: uiData.CUEDefinitions, Parameters: uiData.Parameters, } for contentType, method := range addonContentsReader { items := ptItems[contentType] for _, it := range items { err := method(addon, r, r.RelativePath(it)) ... } } return addon, nil }

   该函数将template、resource、schema、view分别加载进相应的字段中，用于下面启动插件时加载用。

5. addonPkg对象的AvailableVersions字段中还存储了该addon中全部可用的版本信息。