开源之夏学生访谈——张冠璟：用行动让兴趣结晶

自我介绍

请简单介绍下自己以及自己的开源经历

大家好，我叫张冠璟，目前本科四年级，在苏州科技大学就读计算机科学与技术专业，爱好健身、玩音乐，座右铭是：“有转移环境之能力，而不为不良环境所屈服”，理想是成为行动力的化身，做自己所热爱之事。

虽然也称不上是接触开源，但我记得第一次使用 cmd 命令行小黑框和计算机打交道还是在上小学的时候：那时只能偶尔借用父亲的台式机，所以为了偷偷玩游戏，我就上网搜索了 Windows 隐藏文件夹的方法，使用 attrib +s +a +h +r 文件路径 这句命令，把游戏文件夹隐藏了起来，这样文件夹名称就起到了密码的作用，只有在文件管理器里输入正确路径才能进入。

因为这件小事，后来在我接触到 Linux 时，就感觉命令行的交互方式非常有趣，而兴趣正是驱动我学习的最大动力。于是从 Linux 开始，我逐渐深入学习云计算相关生态，比如 OpenStack 、 Docker 、 Kubernetes 等。

本次开源之夏选题也是出于类似的原因：当我看到有这样一个项目，技术要求包括我比较熟悉的 Kubernetes ，同时又有我未曾接触，但很感兴趣的 Serverless 和 CRD 相关内容，我就毫不犹豫地选择了这个项目。在参照项目基本信息以及官方文档进行了一些初步了解后，我就主动与导师联系，开始准备申请项目了。

你是如何理解和看待开源的？

在我看来，开源社区的运作就像一个水力发电站。首先有人基于自己的 idea 建起了一座大坝，然后他开始消耗自己的兴趣驱动力，推进这个开源项目。当有越来越多的人看到这个项目的价值，主动加入进来，这座水电站的流量就会增加，产出的电量也会不断增长。但如果没有足够多的水源持续注入，那其中的能源也迟早会枯竭。

为开源社区注入更多的驱动力可以有很多方式：

1. 企业全程投资支持，但如果这个开源社区不能尽快产出企业期望的价值，这也许不是一个稳定的选择；
2. 在行业中取得一定影响力，比如 Kubernetes 这样的大社区，已然成为行业标准，几乎所有人都以能为其贡献代码为荣，此时的社区已经可以良性循环，但这对刚起步的小社区并不适用；
3. 结合前两种方式，前期在一定的支持下起步，等到中期社区逐渐庞大，体系逐渐完善，应用也能落地时，自然会有更多的人主动加入贡献，后期也能收到来自各行各业的终端用户的反馈，不断迭代优化，形成理想的社区氛围；

简单概括这个发展过程，正是 CNCF 项目的三个发展阶段：孵化 → 沙盒 → 毕业。

我认为对于我们参加开源之夏的学生来说，参加沙盒阶段的项目是比较合适的，因为此时项目的底座已经打好，未来方向也有蓝图规划，项目核心开发人员也基本定型，正好有大量的工作等待完成，其中不乏难度适中，对于刚接触开源的学生来说，比较友好的项目。

关于开源之夏活动

请介绍一下你今年在开源之夏中选的项目

OpenFunction 是一个云原生的开源函数即服务（Functions-as-a-Service）平台，旨在让用户专注于他们的业务逻辑，而不必担心底层运行环境和基础设施。用户只需要以函数的形式提交业务相关的源代码，即可将服务按需运行在集群中。

OpenFunction 在 2022 年 4 月成为 CNCF Sandbox 项目，具有以下特点：

• 云厂商中立
• 同时支持同步与异步函数
• 支持直接从函数代码生成符合 OCI 标准的函数镜像
• 支持 0 与 N 之间的自动水平伸缩
• 既能运行函数，也能运行 Serverless 应用

在本次开源之夏 KubeSphere 社区的 OpenFunction 函数触发器 项目中，我的主要任务是为 OpenFunction 新增基于 keda-http-addon 实现的同步函数方案，这将有助于消除使用上的割裂感，在一定程度上取代 Knative ，统一 OpenFunction 核心架构，提高一致性。

项目开发期间，社区和导师给你带来怎样的帮助？

说起来还有点不好意思，自从我一开始在开源之夏的微信群里加上方阗导师，主动找他提问关于项目的方方面面，我和导师就一直保持着比较高的交流频率，高到我都担心打扰他正常工作，对此我也感到有些愧疚，但方阗导师非常有耐心，他建议我可以通过协作文档的形式（比如语雀），定期整理好自己的疑问，记录到在线文档中，然后他可以周期性地针对这些问题进行答疑。我觉得这样的形式很好，可以完美解决学生与导师作息时间的冲突。

除了 KubeSphere 社区开源之夏的双周例会之外，我和导师还另外约定了单周例会，用来同步进度，交流这一周内遇到的问题，以及规划下一周的工作内容。

在我们自己的单周例会过程中，往往可以高效地解决问题：通过文字长篇大论也解释不清的概念，屏幕共享画一张图，就能很快理解；在项目前期解释名词概念，尝试理解项目开发目的与步骤的过程中，这样的形式格外有效。每次例会结束后，我也会在会议文档中写下一段简短的总结，记录会议内容，以供自己反复思考。

在项目中后期，我提交的 PR 给 OpenFunction 社区的其他老师们 review 后，他们也给我提出了很多改进的建议，包括对 CRD 设计的优化、使用 Gateway 替换 Ingress 网关等。我自认为有比较清晰的自我认知，因此始终抱着谦虚的学习心态，对前辈们的建议都会认真思考，学习理解。在 OpenFunction 社区多人协作的开发过程中，还遇到了其他同学与我的 PR 产生代码冲突的情况，于是我们在开发群中交流，探讨，逐步解决问题，修改 BUG 、优化代码，这段参与开源的经历真的让我获益良多。

在项目进行中遇到的印象最深刻的问题是什么？如何解决的？有什么收获吗？

在项目进行的过程中，其实很多时候都需要我自己去摸索、猜想：应该怎么做？这样设计是否合理？在与导师探讨后，再尝试通过实践验证其可行性。

实际上在一开始申请项目的阶段，我就坦诚地告诉导师，我是行动派的类型，更擅长在反复动手实践的过程中学习、理解其原理。而对于刚开始接触这个未知项目的我来说，该做什么，怎么做，是最优先需要解决的困惑，只要有了方向，后面能靠努力解决的事，就都能迎刃而解。

于是方阗导师给了我一个建议：先提交一个 Proposal ：

1. 对项目需求进行分析；
2. 给出解决方案并进行验证；
3. 在 Proposal 中进一步解释为什么要这样做，并列出关联的 issues 、要达成的目标、具体的设计与开发步骤、对这些步骤的详细拆解等。

而为了验证项目可行性，就可以先结合各个官方文档中的 QuickStart ，尝试自己完成一个简单的 Demo ，在 OpenFunction 例会上演示交流，这个 Proposal 也可以与开发并行，逐步完善，有了这个 Proposal 的理论实践指导，开发也会变得非常顺利。

到现在我都很感谢方阗导师的这个建议，这也可以说这是一种因材施教，对我这样喜欢动手的学生来说是再适合不过的方案了，而且有了清晰的实践案例指导，对于这些组件运行过程中生成的工作负载等资源的生命周期，我也能够有个参照，从而进行更具体、更细节的设计与开发。

之前积累的专业知识和项目经验对你完成此次的项目任务有什么帮助吗？

在参与这次项目之前，我学习了一些 Golang 基础，积累过一段时间 k8s 运维相关的经验。在项目开发初期，为了动手实践 KEDA 、Dapr 、OpenFunction 等相关项目的 QuickStart ，我需要在本地用虚拟机准备环境，在这过程中踩了不少坑（各项目之间依赖的最低 k8s 版本可能不同、有的还需要加装额外组件等），还自己总结了一份环境部署文档，随着逐个排坑的过程不断迭代优化，反复做过不下几十遍集群搭建，后来在导师的推荐下尝试使用 KubeKey 装集群，发现还是比较方便快捷的。

但我想自豪地说，五一假期那段时间，靠着我当时的知识储备，把所有项目的 QuickStart 全做了一遍，再结合官方文档和我自己搜寻的学习资料，对 Serverless 整个体系已经形成了自己的初步认识与理解。凭借这些努力，我让导师看到了我积极认真的态度，我认为这份态度也是我中选的主要原因。世上无难事只怕有心人，我觉得只要付出足够多的精力，再多的困难，也能一个个解决，再高的山峰，也能一步步逾越。

社区成长经历

通过开源之夏活动，在社区的帮助下，你认为自己获得了哪些成长？

这次参与开源的经历让我对开源社区的运作模式有了初步的理解与认知，学习了借助 Github 参与多人协作的项目开发流程，在参与开源方面也算是初出茅庐。我认为对于求知若渴的自己来说，开拓视野很重要，多看看大佬们在做什么，是怎么做的，总是能给自己带来很多的启发。

更直观地说，开源之夏这段经历为我原本平平无奇的简历增添了亮眼的一笔，光是凭借这一个项目，我就能跟别人聊上半小时；因为完成这一个题目后，我发现自己对整个 OpenFunction 已经有了比较完整的理解，可以聊很多的技术、设计思想等，虽然还很浅显，但比起从前的自己，已经有了非常明显的成长，让我有一种丰收的喜悦，那些努力的汗水与付出是值得的、有回报的。

后续会继续参与社区吗？

作为我人生中参与的第一个开源项目，我已经与 OpenFunction 结下了不解之缘，看着他不断迭代更新，甚至也许有朝一日能成为毕业项目，一定是件很有成就感的事，所以只要有机会，我很愿意继续参与项目贡献。

事实上除了 OpenFunction 之外，我还有想法参与 KEDA http-addon 的源码贡献：在我项目开发的后期，原以为不能使用 Gateway 来做 KEDA http-addon 的网关，因为社区的相关 issues 里已经有人多次提出这个想法，但自从 2022 年 5 月至今都没有人做这件事，没想到在社区和导师的指引下，我自己参照文档，摸索出了具体的实现，而这件事完全是意料之外的收获，也让我心中燃起了更多兴趣的火苗，我也希望将这份成果反馈给开源社区。

开源之夏项目导师简介和寄语

导师简介

方阗，OpenFunction 社区 Maintainer

导师寄语

当社区创立该项目的时候，事实上项目的主要目标已经由社区其他贡献者基本完成了，我们于是将项目的实际内容调整为基于前一目标的进阶目标，即基于新的函数触发器特性，研发新的同步函数驱动引擎（keda-http-addon）。

在这一背景下，张冠璟同学表现出了很大的热情和积极性。在项目尚未开始前他已开始对可行性方案进行调研，并向我提出很多问题。这也是我决定选择张冠璟同学完成该项目的主要原因。

在我看来，该项目实际的难度应该是要高于之前预定的“简单”级别，同时张冠璟同学之前并没有开源项目相关的经验，本以为整体过程会比较艰难，但最终张冠璟同学还是超预期地完成了该项目，并且参与了社区的其他 issue 的解决。

希望张冠璟同学也可以从本次项目中获得经验和成长；希望张冠璟同学可以持续参与 KubeSphere 社区和 OpenFunction 项目的建设以及秉持开源的精神砥砺前行。

本文由博客一文多发平台 OpenWrite 发布！