暑期腾讯mini项目小结~

31天前 · 代码 · 153次阅读

在大二和大三之间的暑假,有幸参与到了学校与腾讯CSIG的校企合作的mini项目的编写。在项目基本结束之余,也想稍微写几个字来记录一下这两个月的奋斗。

什么是mini项目

听学校负责该项目的陈老师和我所在的项目组的导师说,mini项目本质上是腾讯内的员工在日常开发头脑风暴中诞生的各种小想法,而验证想法的可行性的方案之一就是mini项目。在腾讯内如果提出了看似切实可行并且有足够价值的idea后,可以将idea申报为mini项目在一个小周期内开发来测试其具体的可行性和实用价值等。

我们学校和腾讯实行校企合作的其中一个环节就是以小学期的方式将腾讯内部一些mini项目分发给我们大数据院内经过选拔的学员来开发,学校方面希望在这过程中让学员们了解、体验和学习以腾讯为例的行业中大企业内部的日常工作方式。而腾讯CSIG的victor总监希望我们能够在大二转大三的这个假期,通过这次mini项目认识到我们在校所学离工作所需到底有多远,我们还需要在什么方面花更多的功夫。

具体实施

我们这次mini项目课程大概包括下面几个阶段

  1. 两轮选拔(两周)
  2. 前置学习(三周)
  3. 分组开发(两周)
  4. 汇报

腾讯这边给了6个mini项目,按平均每个组5人的情况来算,总共此次参与课程的学员数大约在30人左右。我们这一级大数据学院大概有两百多人,前来报名的有120人左右。简单来说需要从120人中选出30人。但是实际上更为复杂,因为6个项目做的东西各有差异,大家的报名意愿也和项目挂上了钩。学校给每个人三个选择,按照权重从高到低排序得到三个志愿。每个人可以根据自己的兴趣选择三个项目作为自己的入选志愿。

前两轮选拔主要是通过每周的自主学习&学习周报来对每个学员进行评估。主要考量的是学员对于文档撰写、文字表达、遇到问题的解决方案及其他一些基础能力。在第一周过后就已经去掉了40人了,大多数对编写周报和文档感到厌倦。剩下的80人在经过第二周的自主学习和周报编写后、在第二周的尾巴参加了最后一项的选拔——线上笔试。

线上笔试主要分为三个部分:客观题(考察学员的沟通&团队合作的基础能力)、编程题(考察学员的基础编码能力)和主观题(考察学员的思维)

刚考完试的我还是挺自信的,毕竟题对于我来说都不难,感觉应该是十拿九稳的时候。陈老师在群里发了一张图片,上面是各个项目的意向人数。我填报的第一志愿是「QAPM前端发布前后质量保障方案」(以下简称QAPM),而同样选择了QAPM的学员还有40多个,第一志愿的人数甚至还有20多个。这突然让我紧张了起来,由于我对其他项目实在是打不起兴趣,所以剑走偏锋,三个志愿只填了一个第一志愿。如果没能入选QAPM,我没有任何退路。

由于选择QAPM的人数实在过多,该项目的导师不得不再多加一轮电话面试。

还记得那天为那一通电话从早等到晚,最终还是没等到电话。就在我心灰意冷去找陈老师问情况的时候...

31662256255_.pic

成功突围

最终我们QAPM小组一共5人。组里的其他组员有两个是同班同学,还有一个之前微信上打过一些招呼,也是个开发好手。大家能进这个小组,水平都非常不错。所以我们一拍即合,直接跳过前置学习阶段,直接上手开发。

QAPM前端页面发布前后质量保障方案的主要需求是能够对前端页面在发布前后配合流水线提供一个视觉层的自动化对比。我们的服务最后建设在k8s集群上,通过暴露接口让流水线接入,最后通过企业微信机器人将报告反馈给开发者。这就是我们大致要干的事情。

在了解了需求之后,我们迅速对需求进行了划分,最初得出的模型大概是这个样子。

总体思路

我们的截图主要是通过puppeteer这个库配合chrome-headless实现,图像对比则是通过opencv来进行像素级别的比对。pod间的通信主要通过Kafka消息队列来实现。

我的部分

最终分配到我的任务是对整个架构的设计和运维、Koa服务pod和流水线插件。其中Koa服务的任务是在另一位学员的demo上重构的,相对会轻松一些。我的工作重心主要是在服务架构的设计和运维上,k8s对于我们5个大小伙子来说都是比较陌生的一个东西,所以相对于别的组员来说,我这边的进度可能会慢上不少。

而且前三周在激情备战科目三

项目初期(7.13~8.1)

在最开始的时候,由于科目三的原因,我在k8s上的投入较少,为了不阻塞其他组员的进度(他们需要将自己的镜像部署到k8s上测试),我跟着网上3小时速成的视频简单学了学,就上手帮他们部署上线了。在这段边学边干的过程中,我渐渐对k8s有了一个大概的认识,也渐渐被其吸引住了。k8s的灰度更新,负载均衡等特点让我这个对运维比较感兴趣的前端选手开了开眼界。

其次,为了优雅地实现我们集群内各个pod之间的通信,我们用上了重量级的Kafka。使用Kafka是导师提出的,在项目初期,我们对使用kafka这个决定感到非常不解,我们只是一个小demo项目,至于用上这么重的东西吗。对于对k8s和kafka同时陌生的我来说,想要让kafka在k8s上跑起来又是一件更为困难的事情。废了老鼻子劲,终于把kafka搬上集群后,问题还没有结束。由于我们对Kafka中消费者、消费者组、话题和话题分区的一些概念只有一些简单的了解,我们使用的KafkaJS在使用中频繁报出各种相关方面的问题,其他组员也是叫苦不迭,开发进度也收到了不小影响。

项目中期(8.8~8.18)

从全局出发,不要拘泥于细节!

在拿到驾照返校后,我开始全身心地投入项目。首先要解决的是KafkaJS的报错问题,它究竟是什么原因导致的这些报错,Kafka的消息订阅和分发机制到底是怎么样的?我们发现,将我们的报错信息copy到百度搜索,都是些牛头不对马嘴的东西,既然找不到,那就只能去看官方文档了。

Kafka的官方文档全英文,又臭又长又全是一些专业名词,捏着鼻子勉强看了几章之后,终于在Producer、Consumer和Topic相关章节的时候发现了我们代码中的端倪。Kafka中的消费者和消费者组、Topic和Partition之间有着一些我们不了解的机制。例如a消费者属于消费者组test订阅了test-topic1,同时同样属于消费者组test的消费者b去订阅了test-topic2,那么就导致两个消费者都会收到test-topic1test-topic2的消息。由于在开发中我们相关细节的沟通不当,导致我们各个pod之间消费者组出现了重名的现象,进而导致了我们内部信息流出现了倒流的现象。

我才不会说其实是大家复制我给的demo代码的时候忘记改了呢

又例如消费者组中消费者的数量和topic的分区数又是有所关联。简单来说是这个样子

  • 当分区数大于消费者数量时,每一个消费者会被分配来自一个以上的分区的消息,以保证所有分区的消息都有地方消费
  • 当分区数量等于消费者数量时,一个消费者对应一个分区
  • 当分区数量小于消费者数量时,可能有消费者会被闲置。

总之就是确保每一个分区的消息都有消费者消费,但是不保证每一个消费者都有活干。并且kafka有一个机制,每当有新的消费者加入既有的group时,就会选举一个leader。由leader来按照上述规则分配哪个消费者对应哪个分区。

这又出现了一个让人哭笑不得的问题,由于不同的pod因为沟通不当的问题,加入了同一个消费者组。在开发过程中,a组员正在本地跑demo,突然b组员也开始运行自己的pod,导致新的消费者加入了消费者组,开始选举新leader,两边的控制台都开始疯狂输出Info和Error,组员a和b都惊呆了。

上面两个例子是比较有代表性的问题,当我们将Kafka的一些逻辑组件梳理明白了之后,大部分的问题都迎刃而解了。

解决完了kafka的问题,接下来是k8s。当时我们的服务只能算是用kafka把集群当中的几个零散pod串了起来,不论是从部署还是从运维的角度来看都非常不合理。导师也说我们需要有一个更加优雅的部署方式,于是我的下一个任务便是将我们的服务打包为一个chart。

chart可以理解为k8s集群的软件包,可以通过helm工具将服务快速部署到k8s集群中。

当时我对k8s的理解仅限于将docker镜像部署到k8s上以及用helm部署简单的chart包,突然就让我自己编写chart还是有些吃力的。但是k8s对于我的吸引力非常大,就算项目中不做要求,可能项目结束后我也会自己去折腾这些东西,只不过导师的要求加速了这一过程。

这一次我一改在解决kafka问题上使用的方案,直接上去啃文档。从全局开始,循序渐进地去了解整个k8s。我花了将近两天将k8s和helm的文档通读了一遍,文档中的一些设计思想也让我对我们的服务架构有了一些全新的思考。最终,我将我们的服务架构重新设计了一遍,并且将船新版本的服务打包成了chart,并且配置了负载均衡、自动伸缩等功能。

大体设计

在对服务架构的重新设计期间,我是越来越喜欢kafka和k8s了。k8s允许我们的服务在小并发的时候保持一个基本的副本数量,不会过度消耗集群资源;在高并发的时候,根据CPU和内存的占用率来自动地去控制我们服务中各个pod的副本数量。而任凭我的pod副本数量怎么变,kafka都能平稳地将我们的消息分发到位。有时也会去想,kafka的消息分发让我写,我会怎么去实现呢?

kafka的消息分发

项目后期&汇报(8.19~8.22)

项目后期我们主要的工作就是写文档和排练啦。文档其实在我们编写项目的过程中都有所沉淀,只需要最后稍微缝合一下就好。不得不说,我们小组的大家都有很好的文档编写习惯。

8.22下午,我们去到了松日大厦参加了汇报,我们组不论是从项目整体情况还是汇报来说应该都是肉眼可见的第一名。最后和导师恰了餐晚饭,mini项目也差不多结束啦。

后续

就当我以为项目已经差不多结束的时候,陈老师联系我们说我们的项目希望能够在腾讯内部落地,不知道我们有没有继续开发和完善的打算。我们小组的5个兄弟就又被召集了起来继续来完善这个项目。导师给我们定的时间是差不多一周完成重构&交付,留三个星期在内部试运行看看有没有什么问题。如果三个星期后没有问题的话就算是交付完成啦。

总结

从7.13到8.22,说长不长说短不短,收获了很多,也留下了些遗憾。

在这次项目中接触到的k8s和kafka帮我打开了新的一扇窗,除了学习到的相关运维指示的收获意外。更重要的事让我不单单是从一个前端的角度去思考问题,有时候也会从整个架构的角度去思考问题,让我思考时的维度、视角更多了。

同时,遇到了负责本次项目的Doris chen陈老师也是一件非常幸运的事情,她和我在大学中遇到的其他老师真的不一样,非常关心我们,会和我们分享很多职场或者其他方面的知识。真的感觉为了我们她也操了很多心,当我意识到我们最后汇报的效果似乎不错的时候,我第一个想法是没有辜负陈老师对我们的期待,我们做到了。

遗憾的事情主要是没有去主动争取组长的职务,锻炼自己的领导能力。总说要走出舒适圈,在该出手时却又沉默了,实在是不应该。

不过总体来说,这一次的mini项目真的是收获颇多,最后再次感谢学校和腾讯能够给我们这样一个机会,让我们在大二到大三的这个暑假让我们对我们未来要面对的和我们未来所需的东西都有了更加充分的认识,感谢!

👍 8

腾讯 深圳技术大学 mini项目

还没有修改过

评论

贴吧 狗头 原神 小黄脸
收起

贴吧

  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡
  • 贴吧泡泡

狗头

  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头
  • 狗头

原神

  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神
  • 原神

小黄脸

  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  • 小黄脸
  1. 墨安平 4天前

    lei 我是废物

  2. 华仔 5天前

    在大学能有这样的机会真的非常不错,博主也抓住了机会真的很棒!

  3. 若志奕鑫 5天前

    这才是大学生 guai

  4. Given 10天前

    好强! huaji_han

    1. 季悠然 9天前

      taikaixin

  5. 理智君 10天前

    悠然也在最后一张图里面吗 huaji_shang

    1. 季悠然 10天前

      猜猜我是谁

  6. SomeBottle 30天前

    太棒了!做了这种项目肯定能获得不少经验 huaji_pc

    1. 季悠然 30天前

      感觉更重要的是开阔眼界了 tushe

  7. hueng 30天前

    棒啊悠然宝 zhenbang

目录

avatar

季悠然

寻找有趣的灵魂

134

文章数

2002

评论数

3

分类

好热啊

arknights!

二八原则:做最关键的20%,就可以解决80%的问题。

刘媛媛

421