温柔的养猫人个人页面-阿里云开发者社区

前端故障演练的探索与实践 | D2分享视频+文章

作者 | 辰啸点击查看视频大家好，我是辰啸，来自阿里icbu互动与端技术团队，今天给大家分享的主题是前端故障演练的探索与实践。前端可用性的困局在于，一个看起来很体面的页面，有吸引力的视觉，友好的交互，但你不知道背后到底是什么情况。让我想起有一次走进某个机房，机柜上码着各种高端机器，一片祥和。但是走到背后，线头交错，你永远也不知道拔了这一根影响到的是哪几台机器，一旦出现问题，某些情况下连恢复都伴随着风险。而作为发生在客户端上的问题，先天上存在着感知相对弱一些的缺陷。别人家的事情肯定是不如自己家发生的事情容易观察到的。有这样明显的问题，但与此相悖的是，前端安全生产水位远远满足不了当前的诉求，发展上颇显迟钝。这背后反应的问题主要有3个：前端从业者对可用性的心智意识还是没能跟上前端领域自身的发展，对这块的重视度不够。相关的生态伙伴也没有能广泛地参与进来。大部分企业或开源社区的的质量保障基础设施的建设热点都与前端关联度不高。背后最核心的因素是没有一种常态化的度量能力，让大家能看清当前的水位，并形成一种推动力，促使大家去完善可用性的能力建设。这也是我们尝试探索前端故障演练的核心思路来源。整体而言这还是一个比较新的领域，今天更多地是分享一些我们在探索过程中的思考和感悟，会介绍我们的整体方法论混沌工程，过程中遇到的核心技术挑战，并结合一个演练实战让大家更有体感。其中有一部分思考路径上的产出，也可以在别的领域得到广泛使用，其意义超出了前端故障演练本身，希望能给到大家一些启发。混沌工程什么是混沌工程？Netflix在2012年发布了Chaos Monkey，向业界介绍了这个思想。引述一位业界先驱的话，混沌工程是一种深思熟虑的，经过计划来揭露系统弱点的试验。简单来说，就是将异常扰动注入已经呈现稳态的系统中，观测系统因此而产生的变化并作出对策，使今后系统面对同类异常扰动的变化delta在空间和时间维度上尽可能的小。混沌工程不是一次性的试验，通过验证、改进和再试验，形成一种往复性的提升机制。它在设计上强调了5大基本要素，在后面的介绍中会为大家再展开这一部分的讨论。故障演练就是混沌工程的实现方式之一。以往阿里内部的实践中，已经有比较成熟的故障演练体系了。但当时的故障演练关注的主要是诸如线程池满，数据库连接慢，断网断电，磁盘满坏慢等问题。概括来看，就是主要验证企业的在自己的物理设施范围之内，是否可以应对突发情况，对外提供持续可用的互联网服务能力。我们把它概括为在岸持续可用。那么前端故障演练有哪些不同？如果我们把BFF、Serverless等领域归结为这一类的后端演练，把话题聚焦到纯前端，我们会发现，实际前端的故障演练关注的代码、资源等数据，都是在离开企业的物理设施，来到客户端上以后才开始运作。因此前端故障演练的本质就转变为与此相对的概念即离岸持续可用。我们需要关注的是代码的生产过程是否能防御缺陷的混入，也关注故障发生时系统的发现能力和组织的响应能力。举几个例子，我们通过演练可以去验证CodeReview是否严肃，自动化用例的漏检和误检率处于什么水平，兼容性、国际化、性能问题的预防和发现能力表现如何，或者去评估前端的监控覆盖率、告警触达率以及人员的应急响应效率等等。在这样的思考之下，我们开始着手准备打造一个前端故障演练体系。这边也给大家分享一下我们当时遇到的一些核心挑战核心挑战演练的切面视角我们可以对刚才大家看到的前端需要关注的生产和消费过程再做细分，我这里简单划为4部分，也就是研发、工程、发现和响应4个需要验证的切面。因为前端的生产和消费链路整体是线性的，在前置切面引入的缺陷，会流经后续的切面。举例来说，研发环节不慎写的故障代码，会走过构建发布，在客户端上执行，会验证到系统的发现能力和组织的响应能力。也就是故障的注入具有贯通性。在设计故障注入能力时需要考虑到这种贯通性，刚才的举的例子就可以抽象为源码变异注入这种能力。当然，如果我们对某种注入能力做特殊的设计，也能做到让它的影响面限制在某个固定切面。比如CR变异注入，我们通过使变异的diff只在运行时零时产生而不实际产生落库的代码，做到了避免污染后续的切面。在这样的整体设计之下，我们会具备一个由一批贯通性的注入能力以及一批基础注入能力组成的立体注入体系。一个注入能力影响的切面越多，验证的链路越完整，但实施成本越高。业务应该根据自己需要验证的环节选择实施成本最低的注入方式。因为篇幅所限，无法一一介绍每种注入能力的实现，我这里就举一个例子。一天，小陈的老板说，又要大促了，需求很多，上得又仓促，有点问题在所难免，但还是希望有比较好的处理表现。小陈觉得，当下团队业务的主要问题是：监控接入情况不好监控项覆盖不全告警设置有问题响应太慢这种情况下，小陈考虑针对发现和响应两个切面做演练能力设计，这对应的就是上图贯通性的静态资源劫持能力。稳态假设对照混沌工程的5大要素，首先应该具备一个稳态假设。这里的稳态也就是各类能代表当前业务能力的关键指标的集合，并且他们在一个固定的业务周期里处于相对稳定的状态。现在大家或多或少也有自己的一些监控体系，系统监控关注物理设施的运行状况，业务监控关注业务指标的变化，而端侧监控通常在端上以主动上报的方式记录客户端上的关注点，也是前端可用性领域核心关注的一种监控类型。找到了稳态就可以制定一个假设，以小陈团队的某个xx管家业务为例，如果把主js搞挂，那么同比来看，xx管家首页js error数/率会飙升，并且首页主功能模块曝光率会骤跌。雏形示意于是一个静态资源劫持的注入方式雏形就诞生了。蓝军小陈把有问题的主js发到cdn上，页面引用了这个js，引起故障，错误日志上报至监控平台触发告警，由红军来跟进处理。但这个雏形存在着几个致命的问题：如何使影响范围可控？如果做个演练动不动就要搞个故障出来，很可能得不偿失。这个话题在混沌工程中可以归纳为最小化爆炸半径。我的个人看法是，前端目前安全生产水位暂时无法支持任何形式的生产环境有损演练，其收益风险比过低。有一部分同学表示，那如果仿照灰度策略，控制比例，让极小部分的用户受影响，是不是解决这问题了？但是这样会遇到一个新的问题。如何达到触发监控告警的量级？控制比例到极低，固然可以使影响范围也控制到极低，但多数以绝对值为触发方式的监控项将同时失去作用，也就起不到演练的作用了。那如果换个思路。独立出一套环境来演练，我们自己去模仿用户访问网站来触发故障，再放大一下倍数呢？问题是，多数业务对用户的角色、权限有明确划分，有些故障点的触发具有一定业务逻辑，比如需要通过一系列操作才能执行到相应的功能。亦即：如何仿真用户的线上访问？如何触发具有一定业务逻辑的故障点？解法让我们看一下这些问题如何解决。前端安全环境首先，为了保障业务的安全可控，我们确实需要一套与线上隔离的环境。资源故障不注入到线上的cdn，参与演练的客户端的资源请求都被劫持到drill cdn；为了使数据交互不会产生脏数据，数据请求都被劫持到drill server数据服务，当然这里数据服务是否有更轻量的实现方式后文会提到，这里我们先记录一下。这样一来，演练整体与线上能形成物理隔离，达到对业务的无损演练。整个参与演练的客户端，drill cdn以及数据服务三部分我们可以称之为三位一体的前端安全环境。在实现上，以PC场景为例，我们深圳团队落地了名为f2etest的webdriver云调度体系，依赖云端的虚拟机，及每机并发的复数个浏览器实例，实现了客户端数量上的弹性物理放大。假设有20台机器，每台起10个浏览器，我们可以并发的客户端数就达到了200。由这些浏览器发起对待演练页面的访问，相应的资源请求则通过ip代理方式，劫持到演练用cdn源站上。这个源站上实现了流量转发、资源版本控制、网络状态模拟、错误资源存储等能力，足以模仿绝大部分资源请求响应的可能遇到的情况。这套f2etest也可以承载功能验证，UI自动化等任务，已经上云，欢迎大家试用。右下角Hub Plan是为了解决我们上文中提及的用户和业务逻辑仿真以及数据服务的轻量实现而存在的，在下下页PPT中为大家介绍。运行时，因缺陷注入导致的页面故障，在有监控部署过的情况下，会产生日志上报。通过Whistle修改上报请求中与监控平台达成的协议部分，如上报次数、采样率、通道标志位等，使日志得以被监控平台采信并达到触发告警的量级。在下面这张PPT中也可以得到展示。蓝军的缺陷不再直接注入线上，而是注入前端安全环境，并通过内置的弹性物理放大，触发故障上报日志。为了保证大流量业务的使用，我们设计了双重的放大机制，在安全环境外通过与平台的上报协议锚定，包括反降噪协议和逻辑放大协议，保证量级满足。逻辑放大倍数N应取安全环境中参与上报的客户端数与页面正常线上PV比值的倒数。通过前端安全环境我们做好了最小化爆炸半径，以及触发监控量级的准备。接下去要解决的就是用户仿真、业务逻辑和数据服务的问题。流量构造这里思考这样一件事，过去我们在尝试ui自动化领域的实践中，认为保持业务的功能性逻辑f不变时，若用户数据x和用户行为y也不变，则应得到不变的页面反馈R，包括显示、交互等等。我们反面来看这个思考，如果保持用户数据x和用户行为y不变，R发生了变化，则都可以归因为f发生了变化。所以我们可以把用户数据、行为和反馈都存下来，通过回放的方式去触发相应的逻辑，一旦与原先的反馈产生不同或者说故障，都可以说是因为现在的页面逻辑有缺陷注入导致。这套机制能解决了我们上述提及的3个问题。我如果去考虑传统UI自动化方案，也就是书写用例的方式来做。会有几个老大难问题。编写成本：编写用例时间长时效性：业务逻辑更新后，通常需要一个比较长的周期才能更新用例覆盖率：依赖人工分析，部分逻辑分支和边界条件非常难以覆盖最后我们寻找到的钥匙是流量即用例，也就是上文提及的Hub Plan 在我们实现的这套机制中，将经授权许可的用户行为、资源以及原生api等数据通过serviceworker统一上报。行为经过数据聚合和清洗后得到经过精简的、但能覆盖页面绝大部分业务逻辑的核心用例，并存储起来。资源等其他数据也类似处理。当演练调度执行器要求回放时，将用户行为用例交给f2etest调度webdriver进行执行，针对执行过程中发起的请求，由service worker和whistle拦截后以之前存储的资源作为返回。整体形成了一个沙盒。这是用户行为用例和回放沙盒的截图示意。这些都由统一的演练调度设施管理。实际演练运行过程中演练发起和参与者都不需要关注这些，这套设施会无感执行，此处只做演示。之前我们提及到一个轻量的数据服务实现方式，通过Hub这一点也得到了解决。我们不需要去重新建设一个隔离的后端服务环境，那样做需要梳理的上下游依赖关系极其恐怖。取而代之的，我们将用户请求到的html、其他响应和原生API返回结果等数据也作为资源存储下来。当回放开始，浏览器对html的请求通过whistle拦截，返回的页面上包含了当时采集到的其他数据，这些数据被写到全局变量中；这样做的好处是显著提高了回放性能，避免了频繁的数据交互。此外页面上还被注入了一个请求匹配SDK，当前域的service worker，和其他下发的自定义拦截策略。当页面需要请求时service worker会根据拦截策略进行拦截，通过SDK寻找全局变量中相匹配的结果并返回结果。最后整体上，一个静态资源劫持的注入能力流程就如图所示。蓝军发起演练后，通过演练平台下发策略，在安全环境中调度起大量客户端实例，由这些客户端发起对待演练页面的访问。指定的静态资源请求会被劫持到高度定制的drill cdn模拟源站上，这个模拟源站可以返回任意指定的响应状态，包括但不限于资源加载失败、超时，甚至返回内含指定错误代码的JS。这些响应状态返回到客户端后，造成相应的故障。若监控部署准确，则会有告警通知到受演练的红军，进一步验证红军响应动作。若监控部署不当甚至未部署监控，则本次演练结果相当于红军直接失败。我们通过监控体系，安全环境，流量回放，支持到了稳态假设，最小化爆炸半径，生产仿真和多样化事件这4个混沌工程的核心要点，并且策略之间有重叠配合。另一个自动化持续我们也在逐步探索中，当下呢先抛出一些我们的思考。弱点诊断我们尝试通过总结过往故障、常见故障、其他业务故障甚至过往不达标的演练，推导出一个具有高质量的剧本池，其中的剧本各自运用了不同类型的注入方式，来验证各自切面的能力。通过循环往复的演练，我们能得到一块业务的总体得分，通常预防、发现、响应这几部分形成一张雷达图，便于我们针对薄弱环节挑选剧本反复演练。那么怎么做到自动化呢？我们预计会尝试在money test的领域探索，通过对稳态系统的破坏性注入尝试，发掘引起稳态变化剧烈的几次尝试，对应系统的薄弱环节，自动生成具体的演练方案，形成剧本，扩展剧本池，很好地解决了剧本需要人为补充的问题。演练实战了解了演练部分设计之后，让我们用一个实际的例子来描述下如何进行一次成功的演练。一次演练必须有定义明确的演练计划，小陈挑选了团队中一个名为某管家首页的业务，意图验证监控覆盖率、告警有效性及人员响应效率。注入方式就是刚才介绍的静态资源劫持，且对故障注入后的现象做了两个核心的稳态假设：首页JS Error数/率显著上升首页主功能曝光PV显著降低在方案配置过程中，演练平台按照小陈指定的演练目标，已将静态资源劫持作为推荐注入方式前排展示。在具体参数配置上，小陈决定将一段包含“未声明的变量调用”的错误代码注入到XX管家首页的主js，使主js执行抛出未捕获异常，以此达成使XX管家首页主功能模块丢失导致空白的演练预期。当注入正式开始后，很快相关监控就有了错误日志数的急剧飙升。11:30 告警项达到触发阈值，监控平台推出告警邮件。在这次演练中，红军小张较快地注意到了响应的告警邮件，并随即依照消防群中的消息提示，加入演练故障处理群进行故障跟进。11:39 小张定位到index.js中有一个名为drill的未声明变量被调用，导致抛出Uncaught ReferenceError: drill is not defined。蓝军引导小张上传响应截图证明至演练平台后，本次演练结束，注入主动退出，并开始安排复盘。复盘过程重点围绕Checklist中的各项问题展开，并评估得到一个最终的红军防御得分。本次演练中，小张最后的得分是发现70分，响应85分。特别值得一提的是，在发现能力这一项中，小张第一时间收到了监控平台的告警邮件，理应得到一个高分。但实际复盘过程中，XX管家关于JS Error数/率的告警项配置阈值过低，长期处于过灵敏的状态，告警邮件的推送相当频繁，已经造成了明显的疲劳效应。小张之所以第一时间注意到告警邮件，是因为当天他正在查看并尝试调整相关的配置，存在一定的运气成分。在响应能力这一项中，小张在响应故障的流程上仍有一定的不熟悉，也酌情扣了一些分数。展望未来要展望未来，需要先看前端故障演练带来的价值。上文提过，业务域通过自我系统和组织的演练，可以充分验证业务域安全生产能力。但在更大的组织视角来看，这种验证能力往验收的方向发生了转化。一家企业可以对旗下的各个业务的业务的安全生产水位做准确的评估，并以明确的指标来验收。在安全生产能力的视角来看，演练体系和保障策略矛与盾的关系。随着保障策略的提升，演练体系需要进一步补强注入能力或应对新的技术场景，追加新的注入能力；同时，随着演练体系的注入强度的提升，保障策略也需要更多的积累，才能经受住演练的考验。最终在螺旋式上升的过程中，业务能从过往重大故障的抵御入手，一步步进化到未知中小故障的抵御这个领域。此外，在组织视角来看，前端故障演将带来了安全生产能力的常态化度量，并进一步补充了前端安全生产领域的抓手。这将撬动开发者、业务安全生产负责人及相应的保障团队的积极性，使他们在前端安全生产这个命题下创造更多的产出。我们可以预见，其中有一部分人的角色可能发生一定的变化，甚至产生“混沌工程师”这样的角色，帮助业务寻找所有可能的薄弱环节并制定混沌实验方案。当然混沌工程是可能并不局限于前端，更可能的情况下，他会是一种具备全栈素养、拥有全局视野，兼具深度业务理解的角色。这也是我们期待发生的变化。第十五届 D2 前端技术论坛 PPT 集合已放出，马上获取关注「Alibaba F2E」回复「PPT」一键获取大会完整PPT

10万级大型场馆背后的绘选座技术 | D2分享视频+文章

作者 | 芃苏点击查看视频我是来自阿里巴巴文娱事业群的芃苏，目前在大麦做前端开发。很高兴能够在多样化专场中，给大家带来《10万级大型场馆背后的绘选座技术》这个主题。题目名字比较长，大家也可能会感觉比较陌生。没有关系，接下来我会从以下四个部分展开介绍：前置的行业信息、业务链路的背景信息。针对“10万”，我会对绘座、选座两个关节环节拆开来讲，从问题的分析，到性能、数据上一些思考和解法。未来的一些展望，关于WebGL、WebAssembly的一些看法。其实我接触这技术方向，也是最近两年的事情。2018年初加入阿里后，先后在影业、大麦做B类的产品，一直面向商家、企业，为他们提供日常经营的能力和相关服务。这其中会有很多围绕票务展开的技术能力，绘选座就是其中一个。当然除了这个技术方向，我也像很多同学一样，在持续关注中后台的工程能力和效能提升上的沉淀。说到票务行业，喜欢出行旅游的小伙伴，当你坐上世界最大的民航飞机A380，大概座位有861 个；喜欢看电影的小伙伴，如果你走到一个 30排 x 30列的 IMAX大厅，座位数也就 900 个。那么，如果….. 如果当我们要去看演唱会，或者是看大型的体育赛事、开闭幕式，需要走到一个巨大的场馆中。拿大家熟知的鸟巢体育馆为例，固定座位有8万多个，如果是安排临时座位可以达到11万。这样的场景，就存在于演出行业中。全国大概有5000多个面向剧院演出、演唱会和体育赛事的场馆，在2019年，有近5000万的人次走进这些大大小小的场馆，去体验现场娱乐的魅力。这也产生了一个超过200亿 GMV的巨大市场。在这个行业中，大麦服务过2019年的男子篮球世界杯、武汉世界军人运动会，也将为2022年的亚运会提供票务服务，同时大家熟悉的开心麻花和摩登天空，也是我们服务的对象。从商家后台到消费端，每一个项目需要先对座位图进行绘制，基于座位还要匹配上对应的票档、销售属性，最终在线下可以由售票员进行售出，或是大家熟悉的，通过像大麦这样的票务平台进行在线的选座下单。那么对这10万级超大规模座位的绘选，如何去呈现，又有哪些问题的思考和解法呢？ 10万绘座编辑器能力，提效是核心。绘制，首先它是一个编辑器的能力，既然要编辑，大家都希望能够快速、准确，提效也就成了使用场景中的核心诉求。我找了三个比较典型的问题，当做绘座编辑器问题的切口：编辑器开发是否用我们开发其他业务页面的思路也可以呢？比如，我们是否同样需要考虑组件化？当然，这是基本的抽象，比较容易想到，但在编辑器这个场景中做组件会有些不同。另外，耦合什么、解耦什么，业务数据和视图之间的关系如何？我们目前还是集中的在使用Canvas，因为核心是平面2D的场景。有意思的事情是，我们遇到过Canvas擦除擦不干净的情况，也有因为重绘导致卡顿的问题。像鸟巢这种椭圆形的场馆，肯定会有带弧度的区域，我们在这样的看台区域里怎么绘座呢？接下来我们依次来看看技术细节，先看一下功能场景，有一个直观的体感。这个界面是商家后台的操作界面，正要在一个svg底图上去绘制座位。左下角的弹窗是添加座位，其中会有座位属性、座位号、排号、以及座位的递增规律等设置。在我们针对 10万场馆绘座这个场景下，有一点很重要：一个场馆有多个看台（也就是大家看到的区块），每一次绘制操作时，我们都是针对某单个焦点看台，其它的区域则是 Canvas快照（如右下角所示，是多个看台、密集座位渲染的一个状态呈现）。 “10万”的问题，在绘座这个场景就有了两个解法上的拆解：业务中，单看台座位通常不会超过3500个，我们不用时刻面对“10万”去解题；即便需要视图中展示，也可以提供Canvas快照。如上所述，整个过程包含了svg底图、canvas快照等图形信息。那么我就来从视图组件化的层面聊一聊，它设计上和日常普通后台页面实现上的差异。大家现在看到的这个四层结构，并非是绘选座能力最初的样子。当时的业务实现可能是扁平化的，强耦合的。这个结果的产生，代码的历史债有一个从低到高、再通过结构化设计降低的过程。客观的合理性需要从优化改进中得出。同时，我们需要把细节处理上的成熟经验延续下来。第一层，关于原子和组件。大家能看到这个编辑器有多种能力：比如基本的座位显示，操作上的圈选、排选、块选、套索，还有后面将介绍到的变形工具，这些要被抽象。第二层，图层，我们的页面实现，不再扁平，不同的前端属性内容，我们在不同的分层去实现，比如HTML layer、Canvas Layer，svg Layer，GridLayer等，分层后可以堆叠多层，也意味着当业务属性有差异、不需要的时候，也可以仅注入所需要的图层，不会有冗余。前面讲到的图层，都会在容器中去做注册，也是我们对整个内容的初始化过程，其中还包括插件的注入、手势和滚动事件队列的注册。最终，呈现到使用者眼前的业务视图，即包含了上述的所有能力。说完了基本的分层设计，我们来看下第二个问题，也就是这么多座位在绘制过程中，我们怎么做批量的操作？最初，每个座位在批量移动是，都是独立的去从Canvas画布上抹除，然后在新的画布位置上重绘，图例中 6x6 的36个座位，也就意味着36个独立单位要完成重绘，如果是面对（我前面讲到的）单个看台 3500 个座位，那就有点恐怖了，fps超不过 20，会有比较明显的顿挫感。电影要做到24fps，才能欺骗肉眼、消除视觉延迟，游戏中可能需要做到30-40fps以上才可以、因为需要更高的即时反馈，比如射击游戏或者是多人在线RPG游戏。但是游戏中会有动态模糊等3D渲染技术做视觉辅助，我们目前面对的2D视图会直观的体现到是否线性顺滑上，60fps更是要求输入相应具备40-50ms的响应效率。所以有了“临时块”复制的概念，从代码语义化的命名上我们称之为 “temp-canvas-layer”，其实每一次批量的拖动，就变成1对1的canvas重绘，不再是从n到n。除了批量复制，还有就是我们提到的变形问题，每个看台的区域大小不同，边界也可能不规则，这需要我们编辑器有针对批量座位的变形能力。“区块”的操作，在这个场景下又出现了两个新的问题：因为要考虑恢复还原的问题，记录的块级信息，我们如果想从0度变成30度，再变成60度，需要先从30度恢复成0度，再从0度变化为60度，这个过程细节是有些令人尴尬的。约束还体现在了其它方面，所有的信息都是单个完整块级的，当面对多个块、或者是块的局部，都会被限制。所以基于此，新方案中，开始计算每个座位自己的斜率比，让每个座位根据自己斜率比生成的轨道去进行移动变形。其中关于弧度变形里用到了二阶贝塞尔曲线，算是应用数学和图形学中的基本操作。我们能看到多种变形能力已经基本具备，间距、弧度、倾斜这些都不成问题了，那还能做的更好么？当然可以，我们还可以一键实现变形。基本已经可以满足业务的日常需求了，再往前走，可能就需要整个座位的录入动作全部智能化，具备座位图识别的能力，而操作人员仅需要做微调编辑。这个是我们未来努力的一个方向。 10万选座对数据的思考，性能瓶颈的突破。选座的问题和绘座截然不同。其中涉及的10万级数据场景，在这里我们需要正面面对。首先，座位被绘制完，要售卖交易，一定具备多种属性，大家平时从演出的票纸信息上一定可以看到许多。这个对渲染性能的诉求是巨大的，但10万的数据信息一次要求我们请求完、渲染加载完，理想化的还要秒开，显然这个问题还需要再被拆解，不能一根筋的硬刚。这里面有非常多的突破，是可以和服务端同学一起来思考完成的。我们对数据本身要做一个区分，即静态的座位信息，和动态的属性标签信息。有一些信息我们可以本地缓存，有一些数据可以实时更新。第二点，我们前面提到的所有信息，包括座位地图、座位绘制，这些都是要加密保证安全性的，他们都属于商家的资产安全范畴。大麦对座位底图也有专门的保护技术，这里不展开，还是回到数据问题上。大家平时每天接触的 JSON 数据格式，其实好处非常多，比如语义可读性强，或者是在Node这样的Web Server中也可以无阻传递。但这两点都不是我们需要的，实话说，可读性强也和安全这个诉求背道相驰。诸多问题让我们考虑到了一种新的结构化数据：来自Google的Protocol Buffer。对比 JSON ，大幅提升了加密的效率，也对于 JSON 处理不好的 int floats 数据类型有了更好的支持。因为业务属性复杂，对服务间的数据传递，跨不同语言框架用工具生成时，基于proto结构也更加方便。整个数据拆分组合方式都比较清晰了，我们也做了非常多的数据比对，对于一个原始 2.5MB的座位数据进行Proto编码后，再进行无损压缩，体积比之前缩小了27%，在业务数据校验时，解压加上反序列化为对象的时间缩小了47%。前面说了很多前端和服务端之间的数据连接。当数据来当前端时，我们每一个操作事件其实都不是直接作用在视图上的，中间会有一层DataProxy的设计，这种设计在很多的技术方向上都有应用。基本的目的是为了把我们业务属性的数据和分层结构、组件插件的能力解耦掉，因为底层原子能力都是原生JS和Canvas，有了这一层，我们其实也不再关心业务上的差异、语言框架React还是Vue的问题，对未来的能力迁移和复用，会更加有益。右图的代码示例里，展示了如何添加、删除、还原一个座位数据，以及如何更新一个或多个座位的缓存数据。接下来，我们看下渲染性能。在绘座环节讲到了单看台的聚焦，其实选座有借鉴类似的思路，但不像绘图、我们可以增加一些限制，比如你画完一个区域、才能操作另一个区域。选座的时候，用户应该是随心所欲的。基本的选座链路上，首屏加载完、聚焦单看台，这时我们会考虑分区懒加载的问题，因为时刻要准备好用户对于焦点看台周边看台的操作，一旦用户大幅度的跨越看台做了操作，回到之前操作过的分区，还会有重绘的动作。整体的耗时，使用Chrome Performance性能分析工具，可以分析看出整个的操作链路大概需要近10秒的时间。其实解法的话，我简单说下其中三个重要的突破口：是我们底层的原子组件和插件本身，在实例化过程中有很大的提升空间，做了对应的优化。 Service Worker，这个技术大家都知道，但是可能场景受限、使用并不普遍。当同步加载一个焦点看台周边的多个看台时，因为线程池能力的丰富，可以同步对数据的请求加载、座位初始化带来大幅的性能提升。加载后的东西我们全部 Cache住，性能瓶颈的突破，也让我们对已加载过的区域不再需要重绘。整个总链路的耗时缩短了 70%，基本可以做到 3-4s完成从首屏到单看台、到周边区域、再回到原看台的所有操作，每一步操作做到秒级响应。在首次加载的环节，这么多座位的渲染，Canvas对CPU的压力实只是一方面，即便Chrome会自动开启少量的GPU加速，但瓶颈有一方面还来自于canvas画布尺寸的上线。所以我们对整个画布做了Grid块级的切分，这为我们多个体验性能提升动作带来了突破性的变化。其实依然是一种拆分的策略。下图中，大家可以看到在首次分区加载B看台2000个座位时，密密麻麻的效果，我们现在来看一下分区加载的技术细节。实际上10万级大型场馆，大多数情况下视窗里都不止有一个看台，每个看台千百个座位，那么我们在懒加载时，会多计算1.2倍的视窗范围，也正是这样的余量的预处理，让体验上面带来了大幅的提升。关于视窗，这里还有一个比较有意思的，就是鹰眼图。鹰眼图就是选座页面右上角的“缩略图”，需要将黄色可视范围热区里的所有看台边界进行计算，就有了上面这么多绿色的框线。计算之后，我们需要等比的缩放至鹰眼图中，用来辅助用户判断自己当前所在的场馆位置。代码细节里面展示了滚动时，我们是如何转换坐标点位置，对宽高重新进行位置定位、并重绘的。未来的展望智能、VR、WebGL & 更多可能性目前很多的工作是围绕基础能力沉淀建设展开的，希望能够赋能影演现场娱乐行业，去打造一个世界级的绘选座技术。从开发者能力来讲，目前虽然并非开源项目，但依然从基础的版本管理，再对分层、插件的生态在持续做建设。我们也和交互设计同学一直紧密连接，对于插件生态和图形工具，去做通用的能力建设。文娱的B端C端产品业务，一直都希望能够助力到行业的数字化、智能化建设，在今天我们分享的主题中，绘座和票务属性中还都有很多智能化场景可以去探索。对于前端同学来说，还有更多可以期待的：比如VR，我们在去年其实已经在C端产品中落地，观众在选座时，还能够模拟看到实际的观看效果、对于座位选座有更直观的体感。2020年业界也推出了 WebXR，这方面的能力和硬件连接的更加紧密。另一个就是 WebGL 方面的探索。比如在绘座和选座的时候，大家其实很希望知道自己在操作的是什么楼层的、更清晰的分层边界。能够立体的去看到。其实Canvas和WebGL已经不是近两年的产物了，也有非常多新的标准协议将取代原有的技术总承，如Canvas 2d，取代WebGL2.0的新方案等。最后，WebAssembly其实也是突破性能瓶颈、在思考方式上的“重新出发”。面向多端、跨业务属性能力复用，使用离机器更近的语言，或Rust这样的高级语言，去重塑底层能力的边界，也能够具备module imported 能力的标准，都在慢慢浮出水面。相信在未来，绘选座技术方向会有更多扎实的能力沉淀和输出、对业务场景上有更强力的支撑。也欢迎所有对这个技术方向感兴趣的小伙伴线下交流技术。第十五届 D2 前端技术论坛 PPT 集合已放出，马上获取关注「Alibaba F2E」回复「PPT」一键获取大会完整PPT

温柔的养猫人个人页面-阿里云开发者社区

个人介绍

擅长的技术

2021 年前端趋势预测

跨端的另一种思路 | D2分享+文章

前端故障演练的探索与实践 | D2分享视频+文章

如何建设灰度跨端监控 | D2分享视频+文章

10万级大型场馆背后的绘选座技术 | D2分享视频+文章

2021 年前端趋势预测

跨端的另一种思路 | D2分享+文章

前端故障演练的探索与实践 | D2分享视频+文章

如何建设灰度跨端监控 | D2分享视频+文章

10万级大型场馆背后的绘选座技术 | D2分享视频+文章

盒马中后台跨端方案探索 | D2 分享视频+文章

高密度部署实践 | D2 分享视频+文章

前端智能化实践— P2C 从需求文档生成代码 | D2 分享视频+文章

重磅下载！来自阿里巴巴双11的云原生大规模落地指南

手把手教你开发互动游戏，看 EVA 互动技术体系在金币小镇的实践

测试

2021 年前端趋势预测

跨端的另一种思路 | D2分享+文章

前端故障演练的探索与实践 | D2分享视频+文章

如何建设灰度跨端监控 | D2分享视频+文章

10万级大型场馆背后的绘选座技术 | D2分享视频+文章

盒马中后台跨端方案探索 | D2 分享视频+文章

高密度部署实践 | D2 分享视频+文章

前端智能化实践— P2C 从需求文档生成代码 | D2 分享视频+文章

测试

重磅下载！来自阿里巴巴双11的云原生大规模落地指南

手把手教你开发互动游戏，看 EVA 互动技术体系在金币小镇的实践

PPT 来啦！第十五届 D2 线上直播圆满结束～

免费下载！玩转云服务器，就看这5本电子书！

Java工程师必下载！Java开发手册+成神指南，史上最全阿里工程师实践精华！

舒文：浅谈阿里前端的多样化

Rax 小程序运行时方案解密与思考

从需求生成代码？D2 最具争议的分享，你值得来瞄一眼

秦粤：“和你聊聊 JS 历史和今年 D2 的语言框架专场”

我在阿里巴巴做 Serverless 云研发平台

居家隔离+一起学习！21天打卡养成习惯，坚持就拿“大礼包”！

【大咖问答】对话阿里云 MVP刘洪峰之二――阿里云物联网平台属性、事件，服务详解