QCon2018·北京站 参会小记

4.20 ~ 4.23 三天时间参加了 QCon2018·北京站 全球开发者大会

三天大会都是从早上9点开始,并且有2天都是周末,简直比上班还累╮(╯_╰)╭

坑爹的北京国际会议中心没有空调啊,这么多人的大会,没有空调简直热死个人啊╮(╯_╰)╭

大会涉及的议题太多了,整整3天 x 每天6个时间段 x 每个时间段9个场地同时开讲,可想而知这几天一共讲了多少议题。所有议题都可以在下面的链接查询,有的可以下载相关PPT,有的可以回看现场录像

QCon2018·北京站全球开发者大会日程

介绍一下我参加的几个议题,每个议题都留下了一定的记录和思考,也有一些评价和感受。

  • 移动端相关
    • 区块链技术助力移动AI
    • 美团移动端动态化实践
    • 增强现实的未来方向
    • 从Observer到Observable – 使用Functional Swift提升复杂iOS项目的可维护性
  • 前端相关
    • 浅谈前端交互的基础设施的建设
    • Lavas:PWA的探索与最佳实践
    • 面向未来的原生化Web开发
  • 服务器相关
    • 手Q性能优化的大数据实战
    • Reactive架构升级实践 – 淘宝全站业务的全异步流式架构升级
    • 唯快不破 – 高效定位线上Node.js应用内存泄漏

移动端相关议题

美团移动端动态化实践

美团带来的移动端动态化实践,因为我本身在大前端动态化方向也有很深的关注,这场议题也算是我比较有兴趣的场次之一。

这场分享,主要从布局动态,虚拟环境,插件化,web增强化四种面向不同场景动态方案来讲,简单的说美团把这四个方向都做了自己的技术规划与轮子架构与业务实践,并且最终4个方向都落地到了完全不同的业务团队中。

我个人也在根据自己的业务特点与技术储备,全面推动部门内实现自研的动态化方案,所以这段会议小记中会夹杂很多我个人的评论。

动态化技术方案总结

上面是美团对移动端动态化技术的一个四象限归纳总结,这里几个象限我想分别解释以及评论一下

  • 横坐标按着偏Native/偏H5来划分
  • 纵坐标按着开发模式是否需要迁移切换来划分

业务插件化

这个象限确实偏Native,他根本就是纯Native的。

这个象限的技术栈也是完全保持至原本的Android原生开发模式,因此是技术迁移成本最低的。

这个象限最大的问题在于,只有Android在往这个方向进行尝试,然而Android P的最新系统也在大幅度限制此类原生动态化的能力。

我的评论:

iOS在苹果的全面封禁打压下,这条路就真的没有希望了么?传说中的滴滴的 Dynamic Cocoa 与企鹅的 OCScript 都变成了闭源根本不会开放的内部私密项目,与此同时很多大厂也在进行很多保密内部项目研究,其实在深入编译原理的层面后,在LLVM面前很多苹果的限制已经无法阻挡底层人员的想象力了,虚拟机也是人写的,还有什么不可能?只可惜现在这块有实力的大厂都在秘密进行研究吧

嘿嘿,这里面其实有很多玩头,嘿嘿(留下了淫荡的微笑,啧啧)

这是美团对业务插件化的评分,其实多方面都挺平均的,也挺不错的,但只运用于安卓,缺乏跨平台性是个弱点

布局动态化

这个象限确实是更偏Native,下发各种JSON来描述各个界面元素的层级与样式,从而用Yoga也好,ComponentKit,其他FlexBoxLayout也好,将JSON数据排版成具体的界面元素坐标,最重创建原生的NativeUI进行绘制。

这个象限也确实是一种新的开发模式,因为开发中需要学习新的基于JSON的结构化描述语言,其实这就是一种DSL,每种DSL都有自己的学习成本,迁移成本。而不是直接使用传统Web的开发 or 传统Native开发。(布局描述协议上,可能稍微贴近一点Web开发)

我的评论

布局动态化的这个话题,我曾在很多自己的文章提到过这个观点,布局动态不等于功能动态,所以这个象限严格意义上讲,他并不能和其他四个象限的技术栈在同一起跑线上进行对比,其他象限其实是可以做到从UI界面到功能逻辑的动态化的,但这个象限,欠缺的功能逻辑能力永远是致命伤。

关于这块我真的推荐看一下我以前写的文章 动态界面:DSL&布局引擎,其实就是对比TangramJasonetteWebViewReactNative的差异,来全面阐述DSL与布局引擎的意义,并且里面也重点强调了DSL的学习成本与迁移成本带来的问题

这是美团对布局动态化的评价,可以看出迁移效率/开发效率,都是这类框架的弱点。

我的评价:
还有个最大的弱点就是我说的,无法动态化逻辑,只能动态化界面。

虚拟运行环境

他想把ReactNative类似的技术都归类在这一象限

这一象限确实是从偏向H5的Web技术发展而来的,很多人强调,RN是Native渲染,但so what?RN一整套技术架构里,最终的渲染环节只是一部分,渲染用Native的也改变不了他的整体设计更偏向Web技术栈这个事实,更何况Weex同时支持安卓/iOS/Wap 三种渲染,RN在携程和京东很多公司的支持下也能支持同时渲染H5与Native。

这一象限也确实需要切换新的开发模式,要知道只使用RN/Weex的自带组件,开发中很难满足定制化需求,也就是说免不了深度定制JS与Native业务组件,在这个过程中既需要前端与JS知识,也更需要安卓/iOS的原生开发知识,这种开发模式在业务定制度高的情况下,算是一种与Web/Native差异都很大的新开发模式了。

我的评论:

1 这个名字起的太尴尬了,我是觉得这样起名字非常不妥,他想表达的是类似ReactNative/Weex/Flutter等技术,但居然起了虚拟运行环境这样的名字,我一开始听这个名字,第一反应以为是介绍腾讯的OCScript项目:自研一套基于OC语言但是确是解释执行的虚拟机技术。

2 如果让我起名,我更愿意起名为解释执行原生渲染模式,虽然字数更长,但绝对定义精准的多,基于一种可下发,可以解释执行的脚本语言(Dart的AOT这个话题另说)实现动态更新代码,通过桥接解释执行环境与原生UI环境,进行原生渲染,这类方案其实游戏圈领先应用圈三四年,大名鼎鼎的cocos2dx+lua早在三四年前就已经是这种方案在全面推广了,具体可以看我的另一篇文章,“站在10年研发路上,眺望前端未来”:读后感,这是我在2年前看到一篇谈论大前端发展的文章的读后感

3 解释执行原生渲染其实是完全包含布局动态化这个象限的,这也是我说的他们不能站在同一起跑线进行对比的原因,ReactNative内部一定包含着一套布局动态化的框架,用JSX开发,经过Yoga.c进行排版计算,最后用坐标数据转化成原生UI进行渲染,但是ReactNative还拥有逻辑功能的能力,因为他多了一个JSCore可以下发逻辑,而不只是下发界面。只能说ReactNative是一个整体,比较庞大,如果你不想引入整个RN,而是只想布局一些丰富展现的电商发现页瀑布流的话,布局动态化这个象限才体现出价值,简单轻便的多

4 快应用确实是可以归类在解释执行原生渲染这个圈子里(很多文章表明,他确实是在安卓系统层面支持的但是原生UI渲染的方案),但快应用严格意义上在新老开发模式上,我认为他更偏向老开发模式,因为快应用不同于RN/Weex开放源码与组件,支持灵活扩展的模式,快应用是底层源码黑盒,不提供原生扩展的,所以在开发模式上,不存在当业务需要灵活定制的时候,同时需要Web开发与原生开发一期开发的开发模式。

这是美团对虚拟运行环境的评价,可以看出来,在迁移效率上是一个弱点。

我的评价:
我是觉得还有个更大的问题,整套框架的把控力研究力度,基础技术支持的成本。做RN和做Weex类似的大型业务,绝对免不了面对JS与Native业务源码定制能力的开发,以及JSBundle自研拆包分包,分发部署一整套部署系统架构。

Web容器增强

这个象限没什么歧义,简单说就是基于WebView,小程序/PWA也好,老牌PhoneGap也好,他都是基于WebView的,当然是偏向H5

至于开发模式上,纯前端开发就能搞定,不需要前端与原生配合开发,所以也放在老开发模式里

我的评论:

我个人对Web容器增强这个方向上非常看好,现在WebView在移动端可定制容器的前提下,潜力根本没有被发挥出来,大家还是停留在传统的PhoneGap,或者单纯写几个Bridge,依然还是老旧的Web性能的老思想下

狭义的Hybrid
也是现在大家普遍认知的,Hybrid就是一种给 WebView 增加一些js通信可以调用原生API的方式

广义的Hybrid
我能否认为,只要是前端的开发思路与客户端原生的开发思路相结合,就认为他是一种 Hybrid?我能否认为,通过原生的配合,把原本js or 前端开发做不到的事情做到了,用原生的方式增强了原本的前端技术能力,是否就是一种 Hybrid?如果说ReactNative以原生渲染被人著称,那么微信小程序一样做到了原生渲染部分组件,谁说WebView做不到?

webview慢?webview渲染卡?webview交互差?什么是Hybrid?Hybrid就是纯web做不到想尽一切办法用native补,别局限在一个用个jsbridge,掉几个oc函数就叫hybrid了,所有webview的痛点都能用Hybrid的思路让native补齐

Hybrid就相当于不依赖谷歌苹果支持,在自己的App壳里实现自己的能力更激进的PWA

Hybrid就相当于不依赖微信支持,让自己App壳里的WebView也做到像微信小程序一样的框架,拥有更好更快远超传统WebView的体验。

这是美团对于Web容器增强这方面的能力评价

我的评价:
其实在我看来,Web容器增强如果本着自研一套小程序能力级别的框架来做,他的流畅度得分不见得有这么低,流畅度虽然不会完全直追ReactNative那类,但也绝对会提高不少。并且也不见得只适合应用于节日类运营活动,与广告运营活动,可以运用在很多地方。

美团的动态化落地

来看下美团这4大方向的全景图,好家伙,每个方向都做了一整套比较深度的研发架构和工作流辅助平台,真可谓是每个方向都造了个大轮子啊,并且这些方向完全运用在不同的业务上,只能感慨,人真多,每个方向都自己造轮子。(不得不说公司大了这也是通病,俺们厂里也一样,跨大部门之间轮子被造了无数,选型也选了无数)

动态化的未来

这是一个很有意思的话题,并且这个话题我的看法和主讲嘉宾也是一致的!移动端的很多时候都似曾相识,那么回看PC年代的发展,客户端与Web技术的发展差异不就是CS/BS的发展差异么?什么样的业务在PC上还在坚持用客户端技术在实现,而什么样的业务在PC上已经全面Web技术化了(包含Electron等web包壳技术)

我在“站在10年研发路上,眺望前端未来”:读后感提到过这么一个看法

如果说标准WebView不能满足性能或者Native独有硬件设备上的需求,那么我们就参照借鉴Web标准,在native内重新打造一个,经过优化各种包袱后的 Web Native Runtime,毕竟Web的标准从灵活性上经历了那么久的考验,而客户端如果能改变一些内核策略,甩掉一些包袱,争取到适应当下移动设备性能并且兼顾动态性的最优体验,那就真的是客户端与前端的水乳交融的Hybrid了

所以,在探讨关于动态化未来上,PC端的现在可以侧面看移动端的未来这个观点没错,Native与H5在越来越相互靠近这一点是最重要的,但是如果不能四个方向都做,如果让我选择我们自己做动态化方案,我会选更贴近web的方案

从Observer到Observable – 使用Functional Swift提升复杂iOS项目的可维护性

这是@aaaron7莲叔带来的一场关于swift的函数式编程思想分享

Functional Thinking

心累想哭的代码,如何用函数式思想进行改造?如果把if的判空逻辑统一进行抽象,抽象出一个g,那么会怎样?

  • 通过抽象来更好的描述问题
    • 本质:非确定性 State ->确定性 State 的转换
  • 对于同构的场景提取模型
    • 普适的模型(input:a?,f:(a)->b?)->b?
  • 最终通过符合直觉的方式解决问题
    • 链式调用,顺序执行,无需维护中间变量逻辑分支

现在主流的 Functional 框架

  • ReactiveCocoa
  • RxSwift

自己亲自实现一个 Observable 框架

  • 动动手 实现一个 signal
  • 动动手 加入map filter功能

用 Signal 解决实际的业务问题

  • 中间层的消息传递

  • delegate逐级上传
    • 弊端:一个简单改动要改N个地方
  • 通知中心
    • 全局通知Name表,无法反应依赖调用关系

用Signal解决

  • 与 delegate 的⼀一对⼀一不不同,panSignal 可以被任意多个对象订阅
  • 新增事件,只需要新增⼀一个 signal,中间层⽆无需修改
  • 子view内部的控件⽆需暴露,只需暴露 signal,保证了了封闭性
  • 依赖关系清晰,⽆无需维护全局通知列列表

MVVM是Signal绝佳的使用场景

背后的设计模式

Monad - 关于“顺序结构”的设计模式

  • 名字来源于 Category theory(犯愁论)
  • 面向对象的视角:当一个类以及其方法满足是⼀个 Monad 时,代表其可以被⽤来将⼀些 “⾮顺序” 结构的代码,改造为“顺序”结构
  • 经典的⾮顺序结构代码:event handler 和 async operation

一个简单的需求转化为 Function Programing

  • 点击按钮,开始计时, 倒数30秒
  • 倒计时完毕后提交记录到服务器器
  • 请求成功返回后更更新⽂文本框提示

收获

抛开学习曲线陡峭的巨型轮子RAC RxSwift,莲叔带着听众一步步从自己实现一个基础能力得signal,到用这个signal解决业务中常见问题,再到函数式概念的理解,真的是深入浅出循序渐进

区块链助力移动AI

这一场标题又讲AI又讲区块链,初看感觉很像一个大噱头,但实际上干货十足,来讲的杨林博士式是AI与硬件芯片方面的专家泰斗,简洁精炼的从算力的发展史来剖析未来AI的发展方向,以及现在的落地

AI的发展需要什么? 数据/算法/算例

数据就是客观现况
算法就是人的先验经验
算力就是芯片

算力的是什么?

  • 专属算力
    • 搜索算力 CPU
    • 娱乐算力 GPU
    • 通信算例 专用集成电路
    • 挖矿/AI算力

算力的发展遵循着,CPU -> GPU ->专用集成电路的发展趋势,现在AI也面临新的算力需求,平行算力/并行算力 + GPU,未来一定会发展到专用电路

算力为什么这么重要

一个小芯片 3个T的算力(教授他们公司的自主芯片)
为未来算力提供基础

算力问题如何解决

  • 手机算力也越来越强,1个神州太湖相当于100w个手机,但是中国有几亿手机。
  • 随着手机的普及,有太多算力处于闲置

算力问题如何解决

区块链如何解决算力问题

  • 区块链 打比方:打麻将记公分 白天干活晚上记 谁胡谁记
  • 比特币 打比方:打酱油买酱油,不花钱可以花公分

区块链来共享算力,衡量工作量,分布式全民参与的算力,并产生价值

专用集成电路如何解决算力问题

有了区块链式的软件服务,还有低成本研发芯片能大幅提升软件开发者的ai移动开发能力

强算力下的移动AI愿景

广大应用开发者参与进来,一起玩AI,除了大公司做AI,应用开发者做AI的硬件平台+分布式软件平台已经趋近成熟

增强现实的未来方向

这是一场由老外带来的未来增强现实的大会场,全程英语交流,我听的还真是有点吃力,好累╮(╯_╰)╭,不过也算坚持下来了。这一场开始介绍了AR现况与市场发展趋势,然后就开始介绍还在实验室中的神奇技术了

Augmented Reality Present

以下内容为简单PPT翻译,需要可以去文章顶部的Link下载App

  • 真实与虚拟影像结合
  • 虚拟内容可以进行交互
  • 虚拟内容展现在真实空间中

AR市场的增长非常之快,是VR的3倍

Augmented Reality Future

未来AR技术还将在这些方向深入进行研究

  • 更广阔的空间探测,深度探测
  • 植入隐形眼镜的虚拟显示屏技术
  • 更精准的自然手势识别交互
  • 语音/手势/眼神等多模输入
  • 三维空间的追踪探测还原识别(机器人视觉)
  • 广阔户外空间的追踪探测还原识别
  • 情感探测/眼球追踪

前端相关议题

浅谈前端交互的基础设施的建设

这是由winter寒冬大神讲的交互基础建设,很朴实的从view框架发展讲起,最后聊到web下如何与native交融,在高频复杂交互下如何进行合理的js与native通信融合,最后引出了本场重头戏-前一段时间开源的BindingX

交互的发展与演变

UI架构演变

界面也在同时发展

视图职责在演变

计算机功能也在演变

交互的本质

由输入一系列信号

  • 屏幕触摸
  • 陀螺仪传感器
  • 时钟
  • ……

进行输出

  • 图形变化
  • 渲染
  • ……

将输入与输出连接在一起的就是一种交互设计表达式

以触摸手势为例

人脑中的触摸是指

  • 拖拽
  • 滚动
  • 点击

而输入信号中的触摸是指

  • Touch Start
  • Touch Down
  • Touch Move
  • Touch End

如何将Touch信号转化为人脑中可以理解的手势这个过程就是一种输入表达式,这些能力被封装在了系统原生API中,iOS你可以直接使用手势API UIGestureRecognizer 也可以直接使用触摸API TouchEvent

如何将原生触摸的交互能力赋予JS - Binding X

传统的设计方式是指

  • 在Native发生触摸手势行为(Native)
  • 传递给JS进行手势处理(JS)
  • JS对手势识别处理后作用于UI VDomCompare(JS)
  • VDomUI变化结果传递回Native得原生UI(Native)

实现的交互也被Bind到了JS里,从而让JS能够动态灵活的控制定制界面交互,但这里存在着问题,原生触摸手势会随着TouchMove等高频触发的手势频繁进行JS与Native通信,从而导致卡顿问题

修改后的 Bind X 思想

  • JS将手势处理抽象为表达式,注册给原生(JS)
  • 原生发生触摸手势行为,根据注册的表达式,自行进行手势处理(Native)
  • 原生手势处理后作用于原生UI(Native)
  • 原生UI变化同步给JS的VDom(JS)

淘宝终端交互技术

Lavas:PWA的探索与最佳实践

PWA Lavas专场,由我厂的PWA大神分享的实践,现场展示的PWA方式设计的页面很是令人惊艳,PWA其实只是一些浏览器能力的增强,如果想发挥出最大的PWA效果,必然还要带来着前端开发模式的开发思维的转变,无论是SPA还是AppShell还是AppSkeleton,整体的设计思路会更像原生的编写思路,去年只有4个浏览器支持,现在已经几乎主流浏览器都在支持了

PWA都包括哪些技术__

  • Web App Manifest (主屏图标)
  • Service Worker (离线可⽤用)
  • Notification API & Push API (离线通知,国内不可用)

PWA设计模型

  • App Shell & App Skeleton 设计模型
  • PRPL Pattern (Push, Render, Pre-cache, Lazy-load)
  • 安全 HTTPS 交互 & 动画

PWA通常都是SPA,单页应用(现在很多Wap站采用多页应用的应该还有不少吧?)

采用 App Shell 设计模式,这个设计模式我是第一次听说,对他进行相关搜索也都伴随着 PWA 的业务实践而生,他代表着一种界面骨框架的设计思想

推荐两篇文章可以进一步了解一下

Service Worker + App Shell

  • 缓存 App Shell 所需静态⽂文件
  • 拦截⻚页⾯面请求,均返回 App Shell 对应 HTML
  • App Shell 判断当前 URL,渲染不同⻚面
  • 判断当前请求状态,返回不同的页面

通过Service Worker的缓存API,将整个SPA的都离线化,做到极致的打开速度与离线能力,应用内容通过数据请求打开内容页面。

Service Worker 与 SSR

SSR代表着后端渲染,后端将数据与界面框架渲染在一起输出给前端,从而便于SEO与网站访问速度加快。。

但是SPA与AppShell明显是一种缓存界面骨架,用前端拉取内容再进行前端渲染的方式,与SSR明显设计出发点都不同,那么在这种情况下网站如何兼顾SSR与Service Worker呢?

SSR中正确的使用Service Worker

第一次请求(也包括爬虫请求),请求云端SSR界面,并且注册Service Work,然后预缓存AppShell

第二次请求,由于AppShell已经被缓存完毕,由ServiceWork触发(爬虫无法触发),直接加载缓存的AppShell,然后再发起数据请求到云端渲染内容

  • 采用 SSR 的站点也能完全离线
  • 缩短⽩屏时间
  • 解决 SEO 的问题
  • ⼤幅降低服务器的压力

Lavas

  • 依然不知道PWA为何物
  • iOS 添加到桌⾯怎么办?
  • Service Worker 这么复杂!!
  • 如何把 Skeleton 注⼊入到 HTML?
  • App Shell 怎么剥离?
  • SSR 会不会服务器压力很大啊?怕怕
  • PWA 怎么做 SEO?
  • SPA 页⾯转场动画怎么做? Service Worker 更新逻辑? Service Worker 更新这么复杂,要不就不处理了吧

Lavas 基于 Vue.js 的 PWA 解决方案

面向未来的原生化Web开发

这是关于WebAssembly议题,主要介绍了一些WebAssembly的开发现状,api支持程度,速度对比上看wasm确实比js提升了四倍左右,但光语言支持还不够,大量api依赖于wrapper通信回js借助浏览器api,眼下还是有非常多需要做的,下一步最希望能够直接获得操作Dom/Canvas的能力。PS:Rust真是不遗余力支持wasm

  • 2013年 asm.j

将C/C++代码,编译成js代码,在浏览器中进行解释执行

  • 2015年 WebAssembly

将C/C++/Rust等语言,编译成字节码,在浏览器中执行

WASM开发

  • 异步
  • 受限的IO
    • 文件IO 受限的FS API
    • 网络IO BSD sockets API (WebSocket backend)
      • emscripten_async_wget
      • emscripten_fetch
  • 图形界面
    • DOM
    • Canvas
  • 事件循环
    • emscripten_set_main_loop
    • emscripten_pause_main_loop
    • emscripten_cancel_main_loop
  • 使用C库

Rust WASM生态圈

  • stdweb:js rust交互 DOM操作封装
  • yew:MV*框架 虚拟Dom
  • rust-sdl2:硬件加速的2D画图API封装
  • rust-wasm-loader:webpack loader
  • wasm-bindgen:对象绑定
  • serde:序列化
  • future:异步

WASM实战

  • WASM可以和JS完美结合
  • WASM与JS互调涉及到写Wrapper和指针操作

举例了一个Web股票K线图 WASM 重构的例子

WASM收益与未来

  • WASM的收益
    • 游戏/视频类Web
    • 重CPU型Web,加密,编解码
    • webapp:virtual dom diff
    • node c++ addon
    • Canvas App
  • WASM的未来
    • 直接操作 Web API/Dom
    • 多线程
    • ES6 Module
    • 垃圾回收
    • ……

服务器相关议题

手Q性能优化的大数据实战

这是一场在移动端专场听到的关于大数据方面的分享,由手Q质量部带来的针对移动端App性能优化实战,从PPT里可以看到他始终围绕着卡顿来进行分析,重点解决,说他是移动端相关的,但其实介绍的是以大数据分析来解决移动端场景下的性能问题

  • 千万量级的堆栈反混淆
  • 快速部署快速扩容的反混淆服务
  • 定义卡顿优化的指标
  • 聚合/逆序聚合

千万量级的堆栈反混淆

大家都知道发生了卡顿,Crash,就要收集当时的界面调用堆栈进行上报,从而分析出卡顿对应的代码段落,但当面临手Q上亿级别的数据量吞吐的情况下,如何快速的进行堆栈反混淆就成了棘手难题之一

手Q给出的解决方案

  • 基于开源的atosl(符号反解工具) + redis
  • 修改atosl,散列缓存 + 增量存储

重新设计修改了atosl的方案,用散列缓存对符号表查找进行了区块分割,加快查找定位速度,用增量存储方式解决不同版本代码diff对内存空间的开销,最终形成了一整套反混淆系统总体架构

部署能快速扩容的反混淆服务

基于 k8s + docker 的容器技术,在腾讯云上快速横向部署反混淆服务

  • 发布方便,回滚方便
  • 自动监控,自动恢复
  • 服务彼此不影响
  • 自动伸缩

定义卡顿优化的指标

形容一个App是否卡顿的指标,大家很容易想到了FPS,FPS低于一定值就会认为发生了卡顿,发生了掉帧。但问题在于有时候卡顿掉帧的次数并不高,但用户会觉得卡,有时候统计上报的卡顿次数比较高,但用户体验感知上却没那么强烈,归根接地在于

指定贴近用户的大数据指标

单纯用掉帧的数量并不能完全表现出用户觉得卡顿的感受,掉帧时长的分布,单位时间内掉帧频次以及持续时间,能更丰富的表现用户对卡顿的感知。

同时还要过滤大量脏数据,有时候占比非常小的一部分脏数据,却能把最终数据统计结果影响的非常非常之大,因此对脏数据是必须要有一定的过滤策略

  • 流畅度的数值
    • 耗时
      • 超过3600s 直接去掉
      • 各区间掉帧比较,相差20%去掉
    • 各区间掉帧数
      • 全0 直接去掉
      • 与耗时比较,相差20%去掉
  • 非数值类
    • 命中SQL注入判断正则,去掉

聚合/逆序聚合

  • 只聚合顶层业务
    • 优点:直观发现需要优化的业务
    • 缺点:不明白调用关系,定位不便
  • 聚合完整堆栈
    • 优点:调用关系清晰明了
    • 缺点:聚合结果项过多
  • 给出的方案:关键方法聚合

通用组件问题如何发现?很多通用组件在业务各处被引用,即便是关键方法聚合,也会不容易定位具体是哪个业务从而进行分类

  • 给出的方案:逆序聚合

Reactive架构升级实践 – 淘宝全站业务的全异步流式架构升级

来自淘宝的架构师带来了从客户端/前端/服务端的reactive全流式架构分享,FRP式编程在移动端前端都有着比较快的尝试,但我觉得在服务会有着更大的价值,就是无状态的数据流动让并行分布式调度可以被发展到极致,讲师立的一个flag,好的架构就是时时刻刻能把cpu打满

因为我对服务器没那么了解,我的截图会多一些,多多包含╮(╯_╰)╭

现有架构的问题

  • 同步等待(大量线程/高Load)资源利用率低
  • 业务一直在拆分(微服务)在架构边界上不能按着业务流程依赖并行/RT积累
  • 为了隔断RT积累引入Cache,结果每个服务都在设置超时,业务复杂化

架构升级的效果

天生的异步架构 - 流





阿里的应用技术架构图

全流式架构升级

  • 先面相应用级升级
    • 应用实施为升级推进核心
    • 聚焦性能做Case
    • 补⻬设施能力
    • 积累业务升级改造经验
  • 架构级升级
    • 规模化后 架构级收益会显现

实现难点

  • 团队
    • 缺乏技能
    • 缺乏意识
  • 业务
    • 缺乏动力
  • 技术
    • 缺乏工具

flag:好的架构就是时时刻刻能把cpu打满

唯快不破 – 高效定位线上Node.js应用内存泄漏

阿里带来的Node.js高效内存追查专场,现场分析了V8的新老两套GC工作模式,通过HeapSnapShot截取内存图,再通过支配树算法分析可疑内存对象,最终提供一个可视化的内存问题分析平台,实时查看内存图状况和支配树分析结果,这个平台免费但很可惜必须运行在阿里云自己的Node Runtime里

很多关于内存算法的讲解可疑看这篇详细博文

快速定位线上 Node.js 内存泄漏问题

深入分析Node V8内存分配

  • 新生代垃圾回收(Scavenge 算法)
  • 老⽣代垃圾回收(Mark-Sweep/Mark-Compact 算法)

老生代垃圾回收算法俗称三色标记算法,被广泛使用在很多VM的垃圾回收算法里(笔者看Lua的垃圾回收,也是从三色标记衍生出来的)

堆内存快照


根据对内存快照构建 Node.js 性能平台

定位内存泄露可疑点

  • 构建内存引用关系树(内存图)
  • 定位泄露点(支配树算法)

泄露实战

从这个 Node.js 性能平台可以看出,整套内存分析泄露定位算法可以可视化的在这个平台上进行展现,从而快速的定位内存问题

通过这个平台可以看到

  • Node的内存增长时间状况
  • 堆内存快照图
  • 类视图
  • 算法分析出来的可疑泄露点

TIPS:这个平台免费但很可惜必须运行在阿里云的Node Runtime里