
技术人不可错过的年度重磅百宝书来了! 复制该链接到浏览器完成下载或分享:https://developer.aliyun.com/topic/download?id=1080 作为阿里巴巴新零售技术的王牌军,基于淘系丰富的商业和业务形态,淘系技术在大前端、音视频、端智能、用户增长、客户端架构、服务端架构、云原生、技术质量、以及AI类等技术领域有着丰富的思考和沉淀。 淘系技术将2020一整年的精华内容梳理合并,重磅推出【淘系技术2020技术年货】。在这本书中,你将看到: 各技术栈下时新前沿的技术讲解与方法技巧 淘系技术大牛的职场成长经验&学习问答实录 年度精选技术人员必读书单 淘系经典开源项目介绍 2020淘系顶会 paper 全文 点击此处立即下载《技术人的百宝黑皮书》 目录 本书内容页数 1500+,全部内容将近 40w 字。作为一群年轻热情有活力的技术er,我们深知,输入重要,输出同样重要。我们热衷于分享和交流,不止于内部团队,不止于业务形态相似,我们期望在不同业态、不同背景的碰撞和交流中,给彼此带来更深的技术理解。 我们怀抱着开放自由的交流心态,希望小伙伴们在新的一年里收获满满,成长多多。 也欢迎大家转给有相同兴趣的同事、朋友,一起切磋,共同成长。 复制该链接到浏览器完成下载或分享:https://developer.aliyun.com/topic/download?id=1080 关注「淘系技术」微信公众号,一个有温度有内容的技术社区~
2007年,Jeff Atwood 提出了一个著名的观点, 戏谑又似认真地称其为 Atwood's Law(https://blog.codinghorror.com/the-principle-of-least-power/):any application that can be written in JavaScript, will eventually be written in JavaScript. 时间快速穿行13年到今天,仿佛在印证戏言成真:在互联网软件工业的疆域上,以ECMAScript 为圆点朝各个方向射出一箭,凡目力所及的范围内,皆似洒落上了这一箭之威。 而在阿里,也像在诠释着这些上述断言,前端技术如初生牛犊般从蛮荒时代的PC Web 踏入到多个领域,在许多重要战场中发挥着重要作用。 本文,简单分享几个前端领域在阿里的应用场景,附带一些我对前端技术领域的一些思考,期待能够和众多的行业同仁们有交流互动的机会。 从 Web 互动到媒体互动 在早期,Web上的互动是为提升页面氛围作为附庸而存在的,为此有一个专用词“网页特效”作为代称。 曾经很长一段时间,互联网上存在大量的特效代码库、特效网站专门服务于开发者。而这些特效的基础原理就是通过 Javascript来变换样式和操作DOM实现的。 随着标准组织和浏览器厂商的不断努力,现代化互动的基础开始成型。除了硬件性能提升外,HTML5/CSS3,Canvas、WebGL让互动的开发显得更为标准、更高效可行,而非各种原理古怪、性能堪忧的Hack技巧。这也让在Web上实现大型互动成为可能性 - 可是要知道,曾几何时,Flash几乎是“双十一狂欢城” 唯一的选择。 今天,互动产品及对应的互动前端技术早已成为各大互联网公司的标配: 在技术上:继承了Web的优势,能够调整迭代,无需发版,天生跨端的同时还能兼具不错的性能。 在商业形态上:更游戏化的互动包括不限于“蚂蚁森林”、“淘宝人生”、“天猫农场”等类社交游戏产品使“人与人”、“人与平台”之间的互动具备了更好的可玩性、用户黏性,从而具备了更高的商业价值。 2020年,互动技术也成为阿里经济体前端技术的重点发力方向。 以淘系互动技术为例,它构建在一个大型、完备的前端基座上:一体化的工程、构建、容器、框架、发布系统、渲染引擎。互动前端技术的核心简单地大概分为三部份: (互动)框架:基于游戏领域的通用构架,自底到顶的分层实现-Render/Render OBJ/Design Pattern/Utils,具备加载器、ECS、场景、插件化扩展等基础能力。 (互动)素材中心:接收并处理互动展示层所需要的资源并输出成型的互动素材,并通过SaaS化服务进行管理。 (互动)研发平台:面向互动生产者的工作平台,它具备包括不限于编码、拼装、编排在内的构建能力。 基于这套互动技术体系,冷冰冰的商业化产品开始具备了越来越多的趣味性和创意体验。 当互联网基础设施不断完善,硬件与带宽成本持续降低,直播/短视频逐渐形成获取用户时间的主流产品形态,也成为人&人、人&机互动的新场景。 传统的解决方案是在视频媒体上“遮盖”一层Web页面,内嵌在页面中的互动(如领取红包)和视频内容没有事实上的关联,而是通过预置的逻辑进行触发,“伪装”成视频与互动同步的用户体感。这种方式成本低廉,但代价则是牺牲了创意和灵活性,缺少想像空间,没有未来。 而媒体智能互动则是更合理的解决方案:通过智能化手段进行手势、表情等识别,互动素材与效果均与视频内容强关联,并在视频流上完成素材渲染。 从实时渲染角度来看,核心技术环节在:图像采集、数据处理、算法识别、渲染计算、端渲染展示 从研发生产角度来看,关键流程在:玩法生产、应用管理、玩法使用、端渲染展示 上述每个节点都涉及到各个关联技术及工具/产品,正是这些能力组成了媒体智能的技术体系。 从长远来看,无论在互动的自身形态、输入方式、承载媒介还是玩法创意,都必将有长足地发展,对于前端体系的从业人员,只要持续关注用户&终端、熟悉业务、不断学习必定会获得长足的技术竞争力和创造力! 搭建,不止于提效 过去几年,我在负责面向消费者端的搭建体系:把形形色色、千奇百怪的页面都看作组件们的集合,然后用极致简单的搭积木方式将它进行可视化组装。 如果拿冰山举例,我们尽量让用户们(运营、开发者)只看到露出海面的那一段,把概念和实操尽一切可能地简化,而被屏蔽在冰山下面的东西,包括了一系列的交付 高度被抽象的 界面+数据描述标准 ,我们称之为模块; 兼顾性能和灵活性的 客户端+服务端渲染架构 ; 离线的、简洁的 零代码可视化平台; 提供线上服务的 页面渲染引擎 + 数据网关; 有了这些交付物(以及基于它构建的大型生态),前端、设计师、后端(多数时候甚至不需要)围绕着高度可被复用的产品模块即可进行页面组装,将业务发布上线。这个方案简单又高效。以至于在很长时间,这套构架最终产生成了数以百万计的各种页面,其中包括不限于双十一,我们在阿里系各种App看到的很多页面都是基于这样的方案出来的。 然而这并不是终点。 其实道理也很简单:当效率上达到一定临界点后(通常是边际效应开始递减),对应的技术方案都越界碰触到另一个领域。 搭建技术也一样 - 一个业务的运行通常不是搭建一个页面就完成了 - 它涉及到整个业务的执行周期。好比一个线下商场要做一场年货活动,上架商品 这个任务只是工作中的一部份,其他包括不限于选商家、选货品、制造氛围、顾客动线都是必须得完成的工作。 而线上业务的运行亦如此,除了“搭建页面” 这个看似简单的动作外,还有各种上下游环节,包括不限于 - 数据哪来(选品)、以什么规则展示(算法千人千面)、抵达什么用户(人群规则)、界面是怎样的(新式交互)、在哪儿展示(跨端渲染)、浏览体验是否又快又好(性能&质量)、业务效果如何(数据看板)等等,每个环节都或多或少地关联着前端相关技术。 基于此,我们根据业务的实际需要拓展了系统的功能边界。慢慢地,原本的面向效率、被高度抽象化的工具系统成为了一个解决具象业务的产品。 在这个转变过程中,原本核心工作是完成前台页面的前端程序员,逐渐成为了一个面向业务的技术工程师,而其工作职责从原来的高效交付扩大到了方方面面,技术视野、技术能力都得到了很大的提升。这时,我们也很难单纯用技术栈来界定这位程序员是前端抑或是后端工程师。 相信在未来,这样的前端工程师会越来越多,也会成为前端发展的一个方向。 技术栈从来不是技术人的桎梏! Serverless,孕育新的生产关系 还是得谈谈这个话题,如果说越发完善的研发工程体系在提升交付整备质量、周全的性能故障监控系统在改进交付效果,那么 Serverless 就是在尝试着在最合适的环节来优化生产关系。 想必很多初入 CRUD 阶段的前端同学都尝试写过一个形如 Todo、blog-like等应用,基于广受各类教程推荐的 Express/Koa+MongoDB+ReactJS/VueJS 套件方案实现。 然而写完应用后的踌躇满志在遇到技术面试/业务应用时则一片茫然:怎么和预想的不一样? - 性能调试、高可用、容量规划、多应用调用、数据库优化、跨栈中间件等等都是未曾太多考虑的问题,但若稍加深入思考,无需很久就进入新一阶段的灵魂拷问:为什么我要使用Node而不是其他工业化程度更高的语言技术栈? 而云原生下的Serverless 让多数前端们开始解除束缚: 便捷可弹的BaaS服务 弱/低运维成本 现代化的函数计算 高速交付 无用赘谈太多的优势,只需缓解运维成本、稳定可弹的计算资源,在完备地BaaS下,离终端用户足够近的前端们就能快速的进行多栈开发,而这则很大机会带来的生产关系的变革,重新定义前后端的边界 - 把原来以 BFF 层为界碑的研发模式重新刷新一遍。 在这个基础上,一部份的前端职能会发生深刻的变化,他们为成为离业务更近的产品工程师,既可以实施商业小程序/轻应用,也能主导一场营销大促、也能驱动一个新业务场景的诞生。 当然,围绕着这种生产关系的周边生态,如职业定义、招聘要求、未来前景、企业人才规划都会随之发生变化。 也期待着这一天的到来。 关注「淘系技术」微信公众号,一个有温度有内容的技术社区~
作者|豆豆、定源 都说憋大招需要时间的积累,一位刚踏出校园入职阿里巴巴淘系技术质量才一年多的新同学,凭什么登上测试行业最高讲台之一的MTSC大会主会场做分享?他是怎么做到的?让我们来看看他的成长故事吧。 ▐ 自我介绍 大家好,我叫黄俊,阿里花名豆豆。从毕业那刻起变加入了阿里巴巴淘系技术质量团队,有幸加入到团队AI智能化测试方向的研究探索中。经过这一年多的成长,从对业务的融入、理解、思考,到质量建设上的构思、试错、突破,我受益良多。感谢于良师益友的老板指导,还有一对一师兄的辅导,更有一群志同道合的同学一起并肩作战,与善人居,如入芝兰之室,久而不闻其香,超nice的团队决定了我的现在。 对于即将毕业或者想来阿里做测试开发行业的新同学,如果你还在迷茫或者有疑问,不妨继续往下看看我的心路历程: 初入职场的迷茫 主动出击,找到切入点 下钻深入思考 聚焦并落地拿结果 ▐ 初入职场,偶遇丝迷茫 还记得你的第一个测试开发场景吗?这里附上我的第一个需求&质量建设: 新人时期,我的第一个接手需求是手淘消息的搜索(如上图所示);第一次完整走完流程的需求是手淘消息的智能push,包含了评审、排期、开发、联调、提测、测试、灰度、bugfix、全量等等;第一个质量保障工具是手淘消息客户端日志的上报。 总的来说,我的新人时期,在不断学习识别业务需求的过程中,时刻洞察质量建设突破点,逐渐完成了从学生到职场的转变。不过随着业务的深入,虽然可以在相关业务上独当一面,但是如何找到测试技术和业务结合的切入点?我不禁陷入了迷茫。现在回头来看,这应该是很多测试开发的新人都会遇到的一个问题。 好在这一时期并没有太长,之后我开始多和师兄、主管、团队老同学的交流,主动走出去和不同部门的同学交流,阿里真的是一个很大的舞台,高手如林,我的眼界和思维被迅速打开,经过和师兄以及主管的反复对焦,我开始逐渐找到适合自己的场景。 ▐ 主动出击,寻找点切入 在经过一段时间的适应和转变后,自身对整体消息场景已经有了一定的基础见解,对切入点的感觉开始变得懵懵懂懂,渴望着将一些新的技术融入于现有的业务场景,便踏上了寻找可以将想法落地的场景之路。 19年的春季,正值手淘消息全链路监控排查体系之际打造如火如荼之际,也是我第一次接触测试右移的道路,在和消息测试团队的师兄师姐们一起研发的同时,逐步开始沉淀通用能力,例如诸多系统间错综复杂的链路如何秒级定位能力、统一降级、统一采样等等。 随后在团队重点研究的AIOps领域,确定了多个研究方向,而其中的“智能异常检测”方向,在当时还是新兴领域,集团还没有特别好的解决方案,而异常检测本身其实是实际业务中的一项关键性需求。在Devops领域,指标监控是系统稳定性的关键,也是监控/运维平台成功的关键,成功的异常检测有助于发现异常后及时提醒用户采取相应的措施,避免更大故障的发生。 通过对国内外现状展开调研,并与达摩院同事进行了交流与合作,对智能异常检测行业现状的了解和摸底,我们的研究内容开始逐步有了线索。虽然这个任务技术挑战很大,也没有太多可以参考的先例,但是我觉得可以发挥我有算法基础喜欢技术钻研的优势,便义无反顾地ALL in到这个任务的研究探索中,并且在过程中我发现自己找到了技术和业务结合可以落地的切入点。 找到切入点并不容易,结合对阿里“六脉神剑”价值观的践行,阶段性总结一下有以下几个方面的成长: 1、经济基础决定上层建筑,业务理解决定质量建设。 2、不要怕折腾,多沟通,少情绪,有耐心。 3、Keep Learning,不为失败找借口,只为成功找方法,全力以赴拿结果。 ▐ 深入思考,聚集智能化监控 在测试右移智能化的道路上,逐步找到切入点后,便开始在这个领域深入研究。如果将一个产品的上线一分为二,左移是往测试之前的开发阶段移,右移则是往上线之后移,这就要求测试开发同学需要做好指标监控。指标的监控关乎稳定性,但随着数据量的增加,加上指标的复杂周期性和模式变化的动态性,基于传统监控的阈值/同比环比的规则难以适用,而且复杂的领域知识导致为每条指标配置相应的规则费时费力,无法应用在大规模数据监控上。 在很多时候,给我的感触是,右移比左移更具有挑战性。因此,我们迫切希望传统监控向智能化监控进行转型,基于团队前期对海量系统日志数据实时计算的基础上,我通过结合百余种实时数据,尝试了20多种异常检测算法,一个全新的智能化异常检测平台呼之欲出。 然而聚焦和深入到智能异常检测方向的研究并非一帆风顺,中间经历了不少曲折克服了不少困难,比如: 场景1、在面临百余种数据类型时,当现有的业务数据跑出一个还不错的模型,而换在另外一种业务数据效果就大打折扣,如何保障这么多数据类型都有一个不错的效果? 解决思路:随着基于对业务数据的深入理解,基于团队前期对海量系统日志数据实时计算的基础上,结合百余种实时数据,尝试了20多种异常检测算,逐渐探索出对于业务数据的算法场景化能力。 场景2、当面临大量业务指标的接入,或者是一个全新场景,没有那么多时间来训练拟合该指标的模型,如何保障业务可以顺利地快速接入使用? 解决思路:提前将场景化的基础模型作为快速接入的选项,并结合无监督学习,配合完成新指标的接入使用,随后再进行逐步迭代,以适应新指标的快速接入。 场景3、当在实时检测有了一定的沉淀能力后,越来越多的业务方反馈,Holmes的报警能不能再提前一点? 解决思路:真实的业务现状使我们体会到单有检测能力是远远不够的,晚一分钟发现问题,往往也是致命的,致使我们踏上了预测的研究道路。 经过不懈的努力,智能化异常检测平台(Holmes)终于落地,并且在淘系核心战役巴拿马项目上线以及双十一大促备战的过程中发挥了作用。下面就展开简单介绍一下这个平台: ▐ 聚焦落地,福尔摩斯(Holmes)-- 淘系智能化监控平台 Holmes是一款智能化、轻量级、易接入、可扩展的异常检测平台,使用基于AI的异常检测算法,替代传统的规则监控方案。解决规则告警系统准确率低、时效性低、规则配置复杂与耗费人力等诸多问题。 特点: 学习历史数据,分析当前指标曲线趋势是否异常 基于以往数据,进行预测未来指标走势 优势: 算法检测代替规则检测 告警准确率高 更早发现异常情况 可适应业务发展带来的趋势变化 解决的异常场景: MSTC大会-主会场分享 基于Holmes的落地,我和师兄董福铭(吾铭)一起在MTSC 2020大会申报了议题《手淘AIOPS实战-消息全链路智能监控》,结合Holmes平台的实战做经验分享。 介绍如何通过SDK实现应用内链路日志聚合、采样率控制、统一降级开关等功能,打通客户端到服务端链路,实现IM端到端秒级排查。通过实时计算实现消息核心指标到达率/时延的实时监控。使用AI检测算法,替代传统的规则监控方案,解决规则告警准确率低、时效性低、规则配置复杂与耗费人力等诸多问题。通过NLP进行舆情智能分类,并结合全链路数据对预警问题进行分析定位,打造全链路智能监控排查平台。 ▐ Holmes异常检测平台 配置化指标接入流程 通过4步简单配置进行指标的接入和算法选择,轻松开启智能异常检测。 基本算法概览 机器学习上有一个定理,叫没有免费午餐定理(No Free Lunch,NFL),表示的是在机器学习上,不存在一种通用的最优的算法可以解决所有问题,因此在面对各类数据时,Holmes将算法场景化。 在实时检测方面,集成了无监督学习和有监督学习,主要运用了高斯分布、STL、孤立森林、XGBoost等; 在数据预测方面,集成了LSTM、Prophet、三次指数平滑等。 实践效果 目前Holmes异常检测平台已经在集团内部开放接入和运行,支持集团内常用数据源,帮助接入业务方的开发测试同学构建智能监控体系,减少繁琐的规则配置,有效提高了线上质量监控的覆盖率。今年的多次大促期间,Holmes的准确性方面也进一步得到验证,有效保障了大促的稳定性质量。 覆盖应用:淘宝、千牛、优酷、钉钉、淘宝直播、闲鱼等 接入指标:核心业务指标 300+ 提前预警:有效提前预警线上问题 50+ 算法调用:5000W+ 展望 Holmes异常检测平台是淘系技术质量团队打造,在智能化测试领域的一次实践,未来我们希望利用AI算法实现业务全方位智能化监控和问题定位。覆盖更多的数据类型,打造通用的算法模型,同时我们也在全链路监控排查、智能舆情处理等多方面进行探索,期待后续跟大家分享。 ▐ 主管点评 豆豆同学19年4月份硕士毕业后,加入阿里巴巴淘系技术质量团队,仅仅通过一年多的时间就成长为团队技术骨干之一。针对豆豆同学的特点,以及团队将19年的整体打法做了分解,将团队AIOps领域探索的智能化异常检测(智能化监控中的重要组成部分)安排给豆豆。对他有两个期望:一方面期望这个能力可以有纵深的下钻,作为整个IM消息测试中台中测试右移的主要武器之一。另一方面也期望可以横向扩展,未来逐步在阿里集团内进行推广使用。作为主管也明白这个技术探索对新人来说有一定的落地风险,当时并没有太多可以参考的先例,而且对同学的AI算法能力和工程化落地能力均有很大的挑战。这也是豆豆加入淘系技术质量团队后的第一个测试技术创新开发任务。 面对压力和挑战,我们很欣喜地发现,豆豆同学并没有被压垮。他迎难而上,查阅了大量业界和阿里集团的资料,调研开源算法、阅读论文,结合师兄吾铭的指导和消息测试团队的反复讨论,豆豆不断优化和完善技术方案,先后克服了多项技术难题。最终Holmes智能异常检测平台在手淘消息场景落地使用,为第一年阿里生涯交出一份漂亮的答卷。新财年,豆豆继续发力,不仅扩大了算法支持的场景个数、准确率,还多次提前预警线上问题,并将支持的业务系统从淘系扩大到了阿里集团多个BU,受到广泛好评。 对于豆豆来说,精彩才刚刚开始,Holmes的落地只是一个起点。今年双十一之后,一个新的保密技术创新项目又开始酝酿,豆豆同学届时又会憋一个什么样的大招?让我们拭目以待! 这里也简单展开一下,新同学除了学习基本功之外,新同学也可以在师兄和主管的引导下,逐步养成思考的好习惯。比如,如何让自己和团队产生更多的链接(多看多沟通多思考)?如何与所在团队的大方向结合(埋头干活的同时也抬头看路)?如何站在团队研究基础之上进一步构建自己的创新产品(借力)?等等,我觉得是新同学们可以思考方式上去做一些转变的。 豆豆同学只是整个淘系技术质量团队(极测)中的一位典型代表,这样优秀的新同学在我们部门还有很多。我们有非常体系化的极测新人培训课程,以及阿里非常著名的“百阿”新人培训,淘系技术质量团队(极测)会针对每一位入职的新人安排一对一的师兄指导,也会针对同学的特点设计和规划职业发展方向。在部门技术驱动的理念下,不仅会对同学的业务理解培养,同时还会在技术创新上给予同学相应的发力场景和落地辅导。结合上一对一师兄和主管在日常工作、生活中对具体的问题和项目实战中的点滴进行具体指导,相信新加入的同学们一定也会像豆豆一样快速成长! MTSC2020中国互联网测试开发大会深圳站现场 淘系技术部-(极测)质量团队-诚招英才 我们负责所有淘系业务的质量保障。在这里:可以经历双十一等超大并发场景;可以接触到全链路压测、海量的数据处理、人工智能推荐算法等领域;可以学习到业界最前沿的测试技术、一对一指导的师兄辅导机制、定期而丰富的技术分享;还可以与层层选拔的各路优秀同学共同战斗,共同成长!我们以技术驱动,构建业界领先的质量体系。 我们的使命是让测试更简单,让研发更高效 ,让用户体验更极致。 还在等什么,快来加入我们吧!AI智能化测试新赛道,你就是下一个明日之星!邮件发送至:dingyuan.jh@alibaba-inc.com
自 2019 年 4 月在 Github 开源以来,淘系技术部-端智能团队自研的 MNN 推理引擎,因为其高性能、易用性以及优秀兼容性受到不少开发者的支持和喜爱。我们也把这份支持化作不断前进的动力,仅最近半年就推出了包括但不限于如下的诸多亮眼特性: 几何计算。通过 MNN 自研的“硬核”技术,将多后端算子实现这项枯燥但必要的工作成本大幅降低。正是基于这项技术,MNN 重写了目前所有的硬件后端。引入几何计算之后 GPU 后端算子的覆盖率大幅增加,在GPU 后端性能普遍获得约 20% 提升,并新支持了 TensorRT 和 CUDA 后端。 基于 Transformer 结构的 ASR 模型的支持。为了应对这类大量涉及 Control Flow、Dynamic Shape和Zero Shape等特性的模型结构,MNN 在框架层面进行了大幅度重构从而对其进行支持和完善。 关于 MNN 的强大,能说的还有很多,但我们不想再一次通过秀肌肉来证明 MNN 的领先独到。相反,我们希望通过这篇文章来说明更重要的一件事:来自开发者的声音,我们听见了。 在 MNN 开源的这一年多里,随着 MNN 被越来越多的开发者、企业所了解并使用,我们与社区之间的交流也愈加紧密频繁。在这之中,有一类的呼声经常被提起: “MNN 很强了,就是希望 iOS / Android Demo 更多一点。Python 还是有点不熟悉” “教教我们这些小白怎么上手呗。MNN 能干些啥呀~” “五子棋牛逼,支持五神!老板我也想搞端智能!” 没错,很多人对机器学习的陌生来自于未知,而正是因为这个未知让大家想象不到能用 MNN 实现什么。 所以我们在想,如果用一门更熟悉的语言,带大家走入端智能的大门,为自己的职业生涯开辟一道新的口子,这样是不是对大家更有帮助? 今天,对着广大的移动开发者,我们要大声的宣布:MNN for Swift 正式来啦!伴随着这个项目一同发布的,还有系列实践性教程 -《MNN x Swift 机器学习实战》。 通过这两个项目,希望能给各位带来清晰的端智能学习路径。 能从课程中收获什么 相信大家都对网上质量参差不齐、没有实际干货的课程感到深恶痛绝。所以在设计系列教程的时候,我们首要考虑的两个要素就是: 免费 硬核技术和动手实践结合 基于此,我们会以每两周一次的方式进行 5 次的系列课程教学,结合 MNN 工作台 AI For Everyone 的低实践门槛,带来值得期待的知识分享。 ✿ 系列直播预告 插段广告,如果你还不知道 MNN 工作台是什么,那就赶快前往 MNN 官网 www.mnn.zone 去下载吧。MNN 工作台是淘系技术部 - 端智能团队在今年 10 月份对外公测的一站式端侧 AI 平台。它是集低门槛预训练模版、开箱即用算法集、多端一键部署于一体的机器学习工具箱,通过 MNN 工作台,每个人都可以在几分钟内完成模型训练并部署到手机上运行看到应用效果。 整体的课程大纲如下: Introduce to MNN For Swift 介绍移动端机器学习现状 MNN For Swift 整体概览 MNN For Swift 实现原理 C++ 至 C 到 Swift 开发流程的最佳实践 MNN For Swift API 设计思路 MNN For Swift 进阶 - 玩转 Swift 自定义操作符 玩转 MNN 工作台 For Swit (一)- 模型预测 MNN For Swift 推理 API 使用介绍 手把手玩转 MNIST 手写数字预测 高级进阶 - 从 MNN 工作台获取更多高级模型 玩转 MNN 工作台 For Swift(二)- 模型训练 MNN For Swift 训练 API 使用介绍 用 MNN Swift 构建 MINST 数字识别模型 高级进阶 - 通过 MNN 工作台训练更多模型 MNN For Swift 应用实战 OCR - 光学字符识别简介 MNN 工作台 OCR 开箱即用模型简介 使用 MNN For Swift 部署 OCR 模型 完整应用案例展示 怎么样?看完大纲后是不是对使用 MNN For Swift 进行机器学习充满了好奇?那就敬请期待我们后续的课程吧! 当然有人会问:“付出那么多,你们想从这个课程中收获什么?” 很简单,我们希望通过这个课程让大家了解端智能是什么、如何把端智能和自身的日常工作进行结合。对那些积极参与《MNN x Swift》系列课程的朋友,如果您对 MNN 和 Swift 有什么独到的见解或者建议,也会邀请您参与到我们的直播中,共同打造 MNN For Swift 的社区生态! 只有更多人一起来玩端智能,这个新兴的领域才能受到更多的关注、获得更长足的发展。 Why Swift 最后我们还想来谈谈为什么 MNN 会选择在这个时间点支持 Swift。 一直以来,因为其强大的社区活力和易用的特性,Python 始终把控着机器学习社区语言的头把交椅(虽然 Julia 也发展的很迅猛)。Tensorflow、PyTorch 以及最新推出的 MNN 工作台等主流的机器学习框架或工具更是和 Python 这门语言紧紧的交织在一起。 但是将 Python 搬到移动端上却不是一件非常容易的事,引用 Tensorflow 对于移动端应用 Python 的观点来看: 部署麻烦,运行时依赖太多。 没有编译期类型检查。这导致很多错误要到运行时才能发现,在移动端,这些不可忽视的错误常常导致严重的应用崩溃等重大用户体验问题。 性能太差,并发困难。而机器学习模型对算力的贪婪需求,迫切需要靠并发缓解。 而自 2014 年 WWDC 正式发布之后,Swift 已经逐渐成为了苹果开发者生态中的主流开发语言。作为一门比 Objective-C 更加现代化、更加安全的编程语言,Swift 已经获得了国内外广大开发者的喜爱。同时,应用 Swift 可以让我们“免费”享受到苹果工程师持续不断的性能、稳定性优化成果。 更重要的一点是,当我们基于 Swift 实践了部分机器学习开发工作后,我们惊讶的发现,Swift 竟然在机器学习领域有着与 Python 相媲美的表达特性。 用如下一段 Python 和 Swift 的 MNN 编程片段进行简单对比: Python 代码: # F = MNN.expr input_data = F.placeholder([1, 3, image_height, image_width], F.NCHW, F.float) input_data.write(image_data) input_data = F.convert(input_data, F.NC4HW4) outputs = ocr_det_net.forward([input_data])[0] outputs = F.convert(outputs, F.NCHW) data = outputs.read() 同样的代码在 Swift 中: var input_data = Expr.placeholder(shape: [1, 3, image_height, image_width], dataFormat: .NCHW, dtype: Float.self) input_data.write(data: image_data) input_data = Expr.convert(input: input_data, format: .NC4HW4) var output = ocr_det_net.onForward(inputs: [input_data])[0] output = Expr.convert(input: output, format: .NCHW) let data = output.read() 毫不夸张的说,如果不加以提示,可能根本不会感受到二者的异同,可见二者在语法表达上十分接近。 除了同样充分的表达性以外,Swift 在移动开发领域天然的优势(苹果大力支持)以及语言自身的安全特性都让 Swift 比起 Python 而言更适合移动端机器学习。 这也是我们为什么下定决心要开展 MNN For Swift 的重要原因。 在内部项目中,我们已经用 MNN For Swift 与 SwiftUI 完成了机器学习应用的编写,91% 的代码均为 Swift。由此可见 Swift 在移动端机器学习领域是能让开发者快速上手,降低开发者的开发门槛的一门优秀语言。所以不要犹豫,赶紧把 MNN For Swift 学起来。 结语 纸上得来终觉浅,绝知此事要躬行。不要再为自己每天还在糊 UI、画 Label 、组装 TableView 而感到焦虑。通过《MNN x Swift 机器学习实战》,我们希望让大家感受到深度学习不止是从事算法专业人员的“独门武器”、也不是大厂宣传秀肌肉的利器,而是让所有爱好技术的人都能参与实践的自我提升手段。 也希望借助 MNN For Swift 项目及系列课程,让大家感受到 MNN 积极拥抱社区、响应开发者呼声的热情与决心,给开发者们缓解一丝冬季的焦虑。 关注「淘系技术」微信公众号,一个有温度有内容的技术社区~
背景 “今年的双11是全球极大内容电商场的超级爆发,消费者、技术、内容与商业生态之间每一秒都在产生激烈共振,实时性、复杂性和持续峰值的叠加令其成为全球技术顶峰。2020年双11,阿里巴巴峰值交易达到了58.3万笔/秒,其背后的商家链路也承受着史无前例的压力”阿里巴巴副总裁汤兴如此描述今年的双11。 阿里商家业务域涉及集团近20条业务线,100多个场景,400+链路,部分业务深度融入在导购、交易链路中。商家链路业务涵盖淘系的上千万商家及数百家核心三方服务商的伙伴。以往由于平台和商家IT基础设施存在“水位差”,平台很难帮助商家进行系统的改造升级和全链路验收。随着阿里面向商家与生态伙伴推出了新一代数字化基建体系,借助云原生技术引擎与云IT治理能力,帮助商家与生态伙伴重构系统的高可用基线,使得越来越多的商家具备了和阿里同等量级的超大规模数据处理能力。 常规备战中各个业务依靠单链路压测,缺少互通联动,缺少全局把控,容易有质量盲点,隐患容易被忽视,风险较高。商家链路出现问题,直接影响商家生产经营能力,对商家和消费者造成重大的体验伤害。业内的全链路压测普遍面向C端场景,B端场景往往重视度不够。商家端的场景结构极其庞杂,涉及内部系统还涉及众多三方系统,开展全链路压测面临着诸多挑战。为有效预防风险,提升各个业务以及三方合作伙伴系统稳定性,提升用户体验,今年我们克服了重重困难首次面向商家链路开展了全链路压测。 挑战 ▐ 核心难点 商家业务涵盖商家工具、消息、多媒体、算法等多种业务形态,各应用间调用错综复杂,如何理清核心链路的依赖,保障核心链路不遗漏是开展压测的首要挑战。 压测实施上,如何模拟数百个场景流量的叠加耦合,并留好应对突发情况的操作空间,且在同一时间批量将流量拉到峰值是压测执行的一大挑战。 商家业务涉及众多合作伙伴服务商的系统,阿里生态的复杂性,使得接入阿里平台的服务商系统架构存在异构化、多样化、性能差异大等多方面技术挑战,每个服务商对于稳定性的认知存在差异。 ▐ 解决方案 针对上述挑战,我们的核心解决方案为: 统一流程规范标准、压测组织协同、统一验收复盘。 工具支撑压测一体化。 压测涵盖预案、限流、演练、监控等内容,模拟大促真实情况。 全链路压测方案 1、统一流程规范 各个业务参与全链路压测明确准入准出标准。全链路压测的基本准入原则:每个场景单链路压测通过后才能进入全链路压测。准出标准包括:系统水位、流量比例、响应时间、缓存命中率、限流、jvm指标等。服务商系统与阿里系统标准一致。 流程上统一进行场景review、链路评审、全链路压测以及复盘,复盘中的问题同步优化解决。 2、工具支撑一体化 在集团已有的压测能力基础上,我们重点在商家链路分析,流量评估,压测模型、结果校验自动化等方面建设一站式压测工具,解决商家全链路压测的核心问题。 链路分析 压测场景选取的基本原则: 大流量场景 核心链路场景 复杂业务链路场景 流量扩散场景。 参照以上原则,在我们在集团中间件支持的基础上,开发了链路分析场景推荐工具,用人工+工具check双保险的方式进行链路模型生成。示意原理如下图,应用A某接口的一次调用,我们可以获取其下游应用的trace,访问的数据库或者缓存,并且分析出1次调用对下游流量的放大。 链路示意图 其工作流程如下: 统计流量调用的服务,存储等指标,获取对下游的调用次数,得到对下游请求的放大。 获取流量大于某阈值的入口链路。 获取调用链路深度或者依赖调用大于某阈值的链路。 获取翻倍调用大于某阈值的链路。 流量评估 常规流量评估通常是根据监控和上游调用来评估接口流量,评估比较理想化,容易产生误差。如果前期流量预估不充分,会导致压测无法达到目标或远超目标值,靠压测来发现这些问题成本太高。对此我们引入了深度机器学习,利用算法能力来做智能预测,更加精确的进行流量评估。其主要的工作原理如下: 抓取应用的出入口流量、RT、QPS、错误率、应用系统水位等信息。 应用深度机器学习,对基础数据进行分析学习,产生该应用的算法模型。该模型可以根据入口流量,预估出口流量、应用系统水位等信息。效果如图所示。 接口流量模拟对比图 其核心思想为: 算法每天根据线上真实数据持续学习,持续优化,生成可靠模型。 用户输入接口预估流量,平台输出预估的下游接口流量、存储QPS、机器数和系统水位等信息。 模型构建 结合业务场景,我们建立了两种压测模型:0点模型和非0点模型。0点模型涉及场景在大促0点流量达到峰值,非0点模型场景峰值则在其他时间达到峰值,压测模型的设计不是简单的覆盖业务,还需要考虑各个业务之间的流量耦合。有上下游关系的链路,下游的压测流量也是来自上游。除了考虑商家域内的流量耦合,还要考虑集团其他域的流量耦合。因此,与之配合的还有非常多的压测预案,用以控制压测流量的准入准出。 有流量的耦合就要考虑耦合流量不足的情况,不是每次压测上游都会有充足流量打到下游。在保障能够耦合上游流量的同时,下游业务自身还要具备流量补充能力,当来自上游的流量不足时,自身可以补充足够的流量,满足自身系统的验证。 3、压测执行 压测数据准备采用淘系技术质量部自研凤凰平台[见附1]录制线上流量做“平移”,场景数据更加真实有效。录制化也提升了数据准备的效率,一次录制多次使用。场景管理上做到了1人1键执行所有的场景,极大的节约人力。每次全链路压测商家和交易、导购都会同步开展,0点流量全部打到100%,以验证跨业务域的流量依赖和叠加的情况。从压测开始到流量拉到100%时间非常有限,在压测初期,这个过程中通常会伴随着⾮常多的问题。这些问题在前期准备过程中很难发现,主要问题有以下⼏类: 压⼒分布不均。 模型紧急调整。 数据⽂件紧急修正。 个别压测机异常。 受压测管控影响,服务调⽤受限。 压测任务紧急管控。 执行⼈员需要⼀边控制不受影响的业务继续按计划加压,同时需要迅速对出现的问题作出判断,给出解决方案。对于能够快速修正的场景,⾸先将其从压测活动中单独摘掉,调整完成后重新关联到压测任务中。对于⽆法快速修正的场景,要迅速协调业务同学进⾏单链路操作。受上述问题影响,现场需要制定不同的应对策略,主要包括以下几种情况: 压测过程中某个场景需要紧急卸载压⼒,其他场景保持。 压测过程中某个场景没有达到⽬标,但系统资源已经出现瓶颈,需要保持压⼒⽔位排查问题,其余业务继续加压。 压⼒拉到100%个别业务没达到预期需要继续增加压⼒。 这⼏类问题在前期压测过程中出现频率⾮常⾼,如果前期准备不到位会阻塞压测节奏。 此外全链路压测具备从客户端(成功率、错误量、舆情等)到服务器(接口成功率、中间件成功率、水位等)的完整监控体系,避免出现只关注到服务可用性而忽视客户端及用户实际体验受损的盲区。 在数百个商家全链路压测场景中,消息、开放、小程序是几个典型的非常规压测场景,压测实施难度大,接下来重点介绍一下这几个场景的全链路压测实践。 ▐ 核心场景1: IM消息体系的端到端全链路压测 传统服务端压测通常是http或者tcp类型的短链接压测,也就是客户端请求一次,拿到返回后,连接就关闭了。但是这种方式并不适用于IM消息系统的压测,IM的系统与服务端建立的是长连接,用户A发送消息给用户B的时候,用户B是被动收到服务器的推送,而不是主动拉取数据,这个模式对压测的实施非常有挑战。 为了解决这个问题,我们基于NIO开发了手淘和千牛的瘦客户端,模拟真实用户与服务端保持长连接在服务端,并将部分业务逻辑做了参数化,集成到了瘦客户端中。比如瘦客户端在收到消息推送后,回复ACK,表示收到了消息,并且根据已读比例对该消息进行已读设置。 长连接瘦客户端 消息链路压测需要模拟客户端登录后保持长连接,目前业内常规压测工具对消息场景都不适用,需要独立开发工具。核心方案如下: 开发瘦客户端集成到压测引擎中模拟端到端的场景 模拟消息回复 模拟消息已阅读 模拟消息漫游 压测引擎部署到CDN节点上模拟真实用户收发消息 创建长连接模拟用户真实保持长连接在线 长连接压测架构图 全链路消息业务打通 消息全链路除了包含消息上下行,消息已读未读,消息内容模型(文本、卡片、多媒体消息),消息漫游等基础消息业务,也在集团二方和合作伙伴三方中衍生出了如机器人智能辅助、订单核对,修改地址,智能客服等消息业务。 消息业务图 由于消息业务的复杂性,导致我们在压测的时候需要协调各个业务方的压测数据,来调整实际压测时各业务方的压力。例如某个账号开通了A业务也开通了B业务,发送给该账号的消息走到了两个业务,导致流量叠加,最后的压测结果不准确。为了解决这一问题,我们统一收口了消息业务压测脚本,通过统一分配账号,通过统一开通业务,统一发起流量等方法,解决了流量叠加互相干扰以及各业务线脚本无法复用等一系列问题。 ▐ 核心场景2: 三方服务商全链路压测 淘系电商业务是一个覆盖消费者、平台、商家、三方服务商的生态链路。借助平台开放的接口,三方服务商可以开发出客户管理、订单管理、互动营销等方向的电商支持工具,帮助商家提升运营效率。要实现商家全链路保障,就需要驱动并赋能三方服务商一起参与到全链路压测中来。 淘系电商生态交互图 订单推送全链路压测 在涉及三方的众多场景中最核心的是订单场景,订单推送全链路覆盖了消费者在淘宝下单后到收到货物的整个过程。链路涵盖多个内外部系统,直接关系到消费者的购物体验,压测重要性不言而喻。 订单推送全链路交互图 订单推送全链路压测面临以下痛点: 服务商数量众多,没有统一的压测工具。 压测订单模型构造难度大、准确性差 压测结果收集困难,数据分析工作量大、标准不统一。 为此我们开发了订单推送全链路压测平台赋能服务商,平台具有以下特点: 基于历史订单数据一键生成压测模型,方便、精准 用户只需指定历史订单的起止时间,系统会自动分析该时间段内的线上订单数据,并根据订单的买家、优惠、商品等信息模拟生成压测订单模型。 订单推送压测模型 压测结果数据自动收集、分析,全面、直观 工具会自动从监控数据中收集相关压测指标,在报告分析阶段跟历史数据进行比对、根据压测标准计算出压测质量分、产出压测结论、给出优化建议。 订单推送压测报告生成示意图 支持Service Mesh技术,生产环境压测更简单、安全 压测平台支持云原生的Service Mesh技术,对于生产环境压测改造只需修改POD节点的相关配置,无需对系统业务代码进行改造,大大降低生产环境压测成本,同时减少代码改造可能带来的安全风险 ▐ 核心场景3:三方小程序压测 小程序是淘系在APP端开放的重要形式,由于三方小程序集成在手淘、千牛等淘系APP中,其稳定性关系到淘系APP的稳定和用户体验。受技术和安全上的限制,三方服务商无法自主对小程序接口进行线上压测,为此我们开发了小程序压测平台为服务商伙伴们提供高效、易用的官方压测工具。 三方小程序压测平台使用简单、易上手、自动化程度高,大大降低了技术门槛和服务商的压测成本,其核心能力如下: 系统根据线上接口流量自动分析、创建、下发压测任务。 服务商只需编辑压测参数,执行压测任务即可。 压测通过并提交报告后,系统会根据压测流量值设定限流保护值。 三方小程序压测流程图 此外,我们还组织了头部核心服务商联合预演。通过全链路压测,模拟业务峰值流量,演练了各种应急预案和沟通机制,以应对大促中可能出现的异常和突发状况,形成了压测、封网、预演的完整保障链路: 在全链路压测的同时对核心三方小程序进行压测,模拟更真实的双十一环境。 在压测的同时进行异常情况演练:人工模拟引入问题、故障。 对问题、故障进行紧急处理,演练沟通、协同机制和应急处理流程。 总结 全链路压测期间总计发现130+内部系统问题,大促前所有问题都得到了有效解决。整个大促期间商家业务系统0故障、商家问题反馈较往年降低了50%,商家以及消费者感受到了如丝般顺滑,捍卫了商家利益与体验。 一百多家核心的ISV参与了全链路压测验收,全链路压测帮助商家与生态伙伴重构了系统的高可用基线,使商家在信息处理和数据处理的水平上,和淘宝拉到同一个水位,使得商家具备了和阿里一样的超大规模数据应用能力,帮助商家系统发现并修复上千个性能问题,在效率和能力上大幅度提升商家系统稳定性。 未来我们计划将在三个方面持续优化,为商家和合作伙伴提供更优质的服务: 1、基于算法能力的智能化压测。 2、场景、预案、限流、压测结果等全方位的自动化分析。 3、多维度监控、海量告警信息的智能分析定位处理。 附1: 凤凰生态利用JVM-Sandbox提供的统一底层能力,大家奇思妙想产生模块原子能力生态,提供开放、快速的模块开发、管理、鉴权、部署能力(魔方平台),通过对模块能力的组合,衍生出录制回放、故障注入、强弱依赖梳理、系统Mock、快速问题定位、测试质量评估等上层产品模块(凤凰平台2.0),并对各个环节产生的数据、标准能力都开放API和能力,在业务回归、攻防演练、架构治理等领域输出方案,致力于快速、高效的提升系统整体稳定性。 开源地址: https://github.com/alibaba/jvm-sandbox-repeater?spm=ata.13261165.0.0.11ee30bfW4qEoF JVM-Sandbox属于基于Instrumentation的动态编织类的AOP框架,通过精心构造了字节码增强逻辑,使得沙箱的模块能在不违反JDK约束情况下实现对目标应用方法的无侵入运行时AOP拦截。 开源地址: https://github.com/alibaba/JVM-Sandbox?spm=ata.13261165.0.0.5a094b01By8WRH 淘系技术部-质量团队-诚招英才 负责保障整个淘宝和天猫主站的业务质量,在这里有丰富多样的业务场景和技术挑战。在这里你能够了解世界级双十一是如何保障的,面对双十一海量峰值流量,沉淀最具挑战的大促稳定性保障产品,在这里可以为过亿DAU的互动产品保驾护航,感受行业最复杂的营销玩法技术魅力,在这里可以近距离了解目前炙手可热的内容电商,见识李佳琦、薇娅等是怎样成为带货红人,在这里还可以探索大数据驱动下的前线业务和增长策略,在3D、AI、5G等新技术加持下打造一个个电商领域的新赛道。 在这里你还会和一群优秀的伙伴共事,这里有对技术的极致追求,使用业界最前沿的研发技术和理念,创新质量保障的方法、工具和平台,提升研发测试效能,不断完善用户体验,以技术驱动,构建业界领先的质量体系。我们的任何一点优化改进都将使数亿用户受益,期待你的加入,欢迎加入我们一起共同打造淘系的技术质量!联系方式:dahai@taobao.com 关注「淘系技术」微信公众号,一个有温度有内容的技术社区~
2021年01月
2020年12月
2020年11月