福州城乡建设发展总公司官方网站,建设信用卡秒批网站,3x3x3x域名,潍坊方圆网站建设作者#xff1a;王彬、朱磊、史明伟
得益于互联网的发展#xff0c;知识的传播有了新的载体#xff0c;使用在线学习平台的学生规模逐年增长#xff0c;越来越多学生在线上获取和使用学习资源#xff0c;其中教育科技企业是比较独特的存在#xff0c;他们担当的不仅仅是…作者王彬、朱磊、史明伟
得益于互联网的发展知识的传播有了新的载体使用在线学习平台的学生规模逐年增长越来越多学生在线上获取和使用学习资源其中教育科技企业是比较独特的存在他们担当的不仅仅是教育者的角色更是让新技术的创新者和实践者。作为一家在线教育高科技企业杭州铭师堂成立十余年来一致致力于用“互联网教育”的科技手段让更多的学生能享有优质的教育促进他们的全面成长在不断汇聚优质的全国各地教育资源的同时杭州铭师堂深度聚焦教学效率的提升深耕先进技术促进其在学校教育智能化领域、个性化学习领域广泛应用。
目前网上教学需求的常态化教师在线审阅作业需求量急剧增大为了减轻老师的审批工作量提升教学效率杭州铭师堂教育基于 Serverless 创造性的开发了学习笔记评优系统, 提升弹性效率并大幅度降低成本。
01 峰值流量破万后如何更好处理任务处理的实时性问题
杭州铭师堂业务涵盖全国 20 多个省份成立十余年来杭州铭师堂不断汇聚优质的全国各地教育资源并展开先进科学技术在学校教育智能化领域、个性化学习领域的应用研究。在教育信息化 2.0 趋势下公司致力于促进线上教育与线下教育的高度融合以学校为核心场景与学校携手共建互联网学习空间为学校与学生提供学习解决方案极大促进教学效率的提升。
K8s 消息系统难以处理数据并行度问题
学生做完作业后会将作业拍照然后上传到作业批阅系统后端系统此时会有多个动作 将作业照片上传到 OSS 将用户作业信息落到数据库 发送一条消息到阿里云消息队列 Kafka
其中第 3 步发送消息到阿里云消息队列 Kafka 后通过消息队列 Kafka 的 connector 功能驱动函数计算简称 FC 进行数据处理。函数计算作为业务的计算平台承载了所有的处理逻辑通过图像识别和数据分类算法自动识别作业的完成情况。
在一年的大多数时间里业务流量都比较平稳但在寒暑假时一般会迎来一年中的高峰在过去的 2022 年暑假期间平均每天需要处理 100 多万的作业图片处理峰值流量更是达到了万级别。
作业图片的处理程序原先部署在 Kubernetes(简称 K8s)程序通过订阅 Kafka 的 topic获取数据路径从 OSS 获取数据进行处理这一部分涉及到数据并行度的处理主要存在两方面问题 Kafka 的消费端并发度受限于 topic 的 partition消费端个数最多只能跟 partition 数齐平消费端数量超过 Kafka topic partition 数会导致超过 partition 数目的消费端没法订阅数据也就没有实际的意义 每个消费端消费到数据之后会将数据发到处理线程处理处理线程在最好的情况下是可以根据业务流量动态调整当然更多的线程就需要更多的资源这又涉及到任务资源的水平扩容和垂直扩容问题。实际实现时杭州铭师堂消费端个数与 topic partition 保持一致消费线程数经过调优之后保持了固定数量在绝大多数时间里程序能够很好的满足数据处理的的实时性要求但对于高峰期由于处理能力的限制还是会经常出现任务积压的情况。
为了能够更好的实现任务处理的实时性要求杭州铭师堂架构组寻求新的架构经过对云产品的对比之后最终选择了阿里云函数计算 FC。
02 兼顾弹性和成本选定函数计算新方案
通过基于函数计算的新方案很好的解决了老架构存在的问题同时开发迭代速度运维效率和成本都得到了很大的优化新老方案对比如下 通过以上对比可以看出函数计算对于杭州铭师堂学习笔记评优系统还是非常合适在解决弹性痛点的同时资源成本开发运维效率都得到了一定的提升。
03 杭州铭师堂的 Serverless 落地之路
在技术架构的实施过程中最初也遇到了一点问题
Java 冷启动的问题第一个问题是语言的问题原来的后端程序采用 Java 微服务框架整个服务中有多个接口刚开始直接将整个服务部署到函数计算。由于 Java 程序启动的特性加上整个服务框架加载的模块和数据较多导致冷启动时间比较长触发冷启动时没法很好的满足业务接口响应要求。
对于这个问题杭州铭师堂开发同学主要做了两个迭代首先将代码粒度拆细在函数计算平台部署真正的处理代码第二步将 Java 语言的代码替换成 TypeScript。替换成 TypeScript 一是因为开发同学比较熟悉 TypeScript二是因为 Node.js 启动速度很快。通过这两次迭代使得函数的弹性效率大大提升冷启动的情况下也能够达到 50ms 内完成单次请求。
资源利用率问题第二个问题是资源的利用率由于把函数逻辑拆分很细单个请求对 CPU 和 Memory 的需求都很小微了提高利用率选择开启函数计算的单实例多并发通过 PTS 的压测在并发度和资源上的到了很好的平衡资源利用率高达 70%。
超出预期的惊喜执行时间快和弹性效率高
通过解决这两个问题整体开发流程顺利项目上线后也达到不错的效果在一些小的方面还有超出预期的表现主要惊喜来自于执行时间快和弹性效率高。
执行时间快在原来服务部署在 K8s 时业务高峰期单个请求响应时间在 100200ms 左右放到函数计算后在高峰期请求处理时间也能够维持在 50ms 左右这是大大超出预期的分析其中的原因主要是函数计算运行资源比较独立每个实例处理固定的并发上限超过部分通过弹出新的实例承载所以高峰期请求脉冲到来时也不会出现资源争抢。
弹性效率高之前在架构设计时很担心函数计算的冷启动问题因为冷启动涉及到软硬件资源的初始化。但在实际运行表现看这点担心也是可以忽略的。函数计算后端机器是神龙服务器单台机器配置很高单台机器可以切分出很多的运行实例并且函数计算在镜像拉取实例热备方面都有优化运行实例拉起速度非常快再加上 Node.js 启动速度的优势在遇到冷启动时请求也能够在 100ms 以内响应这一点对于实时业务非常友好。
业务接口上线到函数计算后很好的解决了之前高峰期的堆积问题并且通过函数计算内置的监控和日志服务在出现问题时可以更好的辅助问题的排查最重要的一点通过函数计算的实时弹性不再需要提前规划资源和部署冗余服务使得资源成本也有一定降低。
04 为客户带来更多价值杭州铭师堂继续探索 Serverless
通过这次项目函数计算在杭州铭师堂内部的应用得到了更大的推广将高脉冲和高资源要求的接口剥离出原服务统一放到函数计算平台承载对内部系统完成了一次 Serverless 架构的升级。
在整体使用过程中杭州铭师堂架构团队也对函数计算提出了一些不足点
产品集成割裂在调用链路中Kafka 数据通过 Kafka connector 触发函数计算的调用Kafka 触发器与函数计算的使用界面有点割裂具体表现为 Kafka 侧的订阅消费情况在 Kafka 控制台显示函数计算的调用和监控需要跳转到函数计算当出现问题时排查问题需要两边控制台跳转使用体验很不友好。
部署系统对接不够顺滑杭州铭师堂经过多年发展内部有成熟的 CICD 系统中间加入函数计算之后需要将函数计算纳入到自有的 CICD 系统中这方面起初采用函数计算的 Open api后来经过升级采用了 Serverless Devs 工具虽然对接体验有了一定提升细节方面还需要继续打磨。
未来杭州铭师堂将与阿里云函数计算团队一道在集成体验和技术深度等方面持续深耕一起探索 Serverless 在实际业务的落地以科技服务教育用互联网改变教育让中国人都有好书读。
开始使用函数计算
函数计算是事件驱动的全托管计算服务。使用函数计算客户无需采购与管理服务器等基础设施只需编写并上传代码或镜像。函数计算即可准备好计算资源弹性地、可靠地运行任务并提供日志查询、性能监控和报警等功能。
函数计算主要包含服务、函数、运行环境、触发器、层、应用中心等功能组件具体产品组件架构图如下所示。 函数计算底层借助阿里云基础设施如神龙服务器网络通信存储安全组件等构建安全可靠高性能的服务。弹性伸缩负载均衡流量控制租户隔离容灾等能力采用自研系统保证了函数计算的计算密度弹性效率计费精度等核心竞争力。
函数计算的使用流程如下 创建函数编写代码。 将第 1 步中编写好的代码以函数的形式部署到函数计算。 函数计算支持通过触发器快速构建事件驱动架构业务流程的能力。 函数计算支持按请求付费的模式在函数有调用时后端会弹出真实的计算资源当同时有多个请求打到函数计算函数计算会并发的弹出多个计算实例进行并行处理每个启动计算实例都会保持一定时间的在线超过一定时间系统会回收计算实例。 最终收费时按照实际函数运行的时间收费。
通过函数计算的平台客户只需要专注业务代码面向函数极简编程可选多种编程语言通过函数计算提供的 SDKServerless Devs 工具丰富的云产品事件驱动触发器可以快速构建完整的调用链路。开发者不再需要直面 IaaS 资源和容器资源通过将云上业务拆分到函数级别多个函数组成服务多个服务构建应用让开发者从小处处着手快速实现业务落地。
整体调用链路如下 处理步骤细节 用户提交作业出发提交流程将请求打到后端服务。 后端服务将用户提交的作业图片上传到 OSS并将 OSS 地址作为一条消息发送到 Kafka。 函数计算的 Kafka 触发器实时的感知 Kafka topic当有新数据到达实时触发函数处理。 函数计算函数获取到触发请求中的数据从 OSS 获取数据并对数据进行处理将处理结果发回到 Kafka topic。 后端程序订阅 Kafka topic对处理结果进行存储和下一步的展示。
点击此处直达函数计算
