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