GpingFeng/gopal-blog

2021 GIAC 大前端专场思考总结（下篇）

Opened this issue · 0 comments

GpingFeng commented

这是去年我有幸参与 GIAC 全球互联网架构大会大前端专场的一些零散的思考与总结。可能不是很系统，尽可能表达出我自己的思考，希望也能对大家有一些帮助。

快手 Node.js 监控排障服务的架构与实现

主讲人：

周鸿轩。2019年加入快手，目前主要从事快手 KNode 与 Nodejs 基础组件的相关开发与探索工作。加入快手之前在百度从事一些探索型业务前端开发和部门内基础服务的开发工作。

背景

在 Node.js 服务快速增⻓的情况下，前端的运维经验和排障经验不丰富， Node.js 进程维度的基础监控 成为亟待补齐的短板。

Node.js 服务需要 哪些监控与保障？将问题拆解以下，Node 服务中包括：

  • 业务代码

  • Node.js 框架如 egg 和 Node.js 组件

  • Node.js 运行时(进程)

  • 容器运行平台(容器)

前面业务代码、Node.js 框架如 egg 和 Node.js 组件和容器埋点可以借助框架等去实现上报埋点等。但是在 Node.js 运行时，出现问题，很难排查

比如以下三个问题很难排查：

  • 内存泄露

  • 服务器不响应

  • CPU 高耗

出现问题之后，我们需要思考以下的问题：

  • 有没有 Node.js 进程的堆内存 / CPU / Event Loop 等详细监控?

  • 能不能 做堆内存 / CPU / Event Loop 等问题的排查?

  • 排查线上问题 快不快，能否保留现场?

为了回答以上的问题，我们就需要做 Node.js 监控排障

Node.js 运行时采集方案选型

一个监控排障服务由哪些部分组成？

大部分的监控会分为以下几个部分

  • 采集层。数据的采集

  • 数据层。数据链路，数据存储

  • 服务层。暴露 API ，将能力暴露

  • 应用层。监控平台、诊断报告

最重要的模块是采集层，Node.js 和 其他服务语言比如 Java，最大的差异就是采集层，其他的都有所类似。

如何采集Node.js 运行时的内部状态和信息?

Node.js 运行时包括 Node 的一些基础模块和 C++ 实现的模块。

如何采集 Node.js 运行时的内部状态和信息？以下方案都可以：

1、使用 Node.js 暴露到 JavaScript 层的 API

2、使用 C/C++ 的 public API，实现在 add-on 层面

3、直接做在 runtime 中，定制 Node.js 源码

4、基于操作系统提供的能力获取进程状态信息

几种方案的对比如下，主要从能力受限度、业务接入成本和维护成本几个方面进行考虑。

注意：没有最优，只有最合适

KNode 选择 Node.js 源码定制的方案， 来实现不受限的能力拓展与零成本接入。

运行时状态采集的技术实现

现有 KNode 功能实现分成三个部分：

  • 基础监控

  • 按需日志

  • 线上代码调试

在线代码调试?

通过断点，运行到该处，采集到调用栈和作用域信息。

Node 调试的原理是通过进程之间的通信完成，但一般的断点会阻断程序运行。

在 v8 中，可以在 deps/v8/src/inspector/v8-debugger.cc 中，做一些能力的增强。（还是有一定的成本）

基于隐藏类的内存分析

在 V8 中，把隐藏类又称为 map，每个对象都有一个 map 属性，其值指向内存中的隐藏类。隐藏类其实是对象的一种形状，统计对象这种形状占用多少内存，进行统计。这种方式有如下特点：

  • 较为轻量级(耗时 ↓ 30%)

  • 生成的“快照”体积小(↓ 90%+)

缺点：

  • 信息量比较少

KNode 数据链路与整体架构

服务的数据链路

监控排障系统的基本流程模型如下：

常规日志的监控链路?

特点：

  • 较为实时性的数据链路，最后展示出来

  • 数据量不是特别大

左侧为两个容器其中包括 log collect，中间是一个消息队列，以及存储一个是监控数据存储（内存信息），另外一个是服务状态存储（服务节点状态、服务进程）还有服务原信息存储

如何实现按需日志的监控链路?

特点：

  • 数据量很大，不需要查询分析，对实时性还是有一定的要求

主要是通过下发配置到 klog service，通知 Config Service 更新， log collect 监听到之后进行上传完成

如何实现实时日志的数据链路?

特点：

  • 对实时性的要求会更强

  • 没有那么强的查询分析需求

实现上将消息放在一个队列 kafka 中，并发布到 Channel 中（如 Redis），通过长连接服务进行订阅。

总结

KNode 的架构如下:

  • 运行逻辑。（采集）

  • 数据链路和数据存储

  • 平台服务，提供各项能力

  • 应用层。各个平台和其他服务打通

移动开发:基于小程序体系的移动端演进分享

主讲人：

王磊。蚂蚁集团 mPaaS 容器&离线包核心开发者，目前聚焦将支付宝原生 Hybrid 方案解耦输出，并基于多样的业务场景做持续迭代和优化。

小程序能力介绍

小程序，是一种依赖 Web 技术，集成了原生能力的，新的移动应用程序格式。具有以下特点：

  • 获取便捷

  • 连接稳定

  • 安全可靠

  • 体验优秀

支付宝小程序的开发架构如下所示：

另外，支付宝小程序生态能力覆盖开发、诊断、发布、运维几个基础而且重要的环境

在体验上，进行核心链路优化

PreChache 能力，可以通过用户的信息，比如说地理位置。通过阿里的算法等信息，进行一个离线包的预缓存，进而提升性能。（没讲具体实现）

安全

  • 权限安全。完整的权限管理体系，逻辑层和渲染层权限分离

  • 存储安全。钉钉提供的存储方案，做到每个用户每个小程序安全隔离

  • 数据安全。阿里巴巴无线保镖 + 国密

质量

  • 巨神兵-自研云引擎:模拟真机和端容器实现的

  • 全方位检测能力:性能、稳定性、合规、安全各方面。分成相关报告，进行反馈，持续优化

  • 全链路解决:开发自检、集成卡口、线上巡检全链路解决方案

总结——小程序优点

  • 效率为王:实现代码一次编写，多端复用，快速发布

  • 体验良好:性能优秀，同层渲染，稳定性好

  • 安全可靠:统一开发标准;连接更多生态平台，丰富自身场

基于小程序构建自有开放生态

移动端前中台分离

• 移动前台：借助小程序容器、flutter 容器、H5 容器等移动前台容器，打造真正的“移动前台”:各个业务模块按照体验、动态性等要求，使用不同的技术栈， 完成移动前中台分离提升研发效能的同时，让端上架构更开放、更灵活。 • 移动中台：其他能力则通过中台能力进行沉淀，结合业务，衍生不同的场景。 • 底层框架：底层框架则通过插件化架构、路由，完成动态插件化和组件化设计。

多场景并存的前台构建

每一种技术都有相应的场景

  • 首页。性能最好的技术——Native 开发，体验最佳，性能最优。冷启动，全球 APP 最快

  • 独立应用/三方应用/Single Page Tab ⻚。小程序开发，兼顾体验与动态性

  • 账单，详情⻚。自渲染引擎开发，体验佳，跨端研发效能高

  • 活动⻚。外链:HTML5 开发，通用跨端技术栈

小结

介绍了支付宝小程序的发展以及它的能力，基于小程序构建自有开放生态。其中对于支付宝中多场景生态，运用移动端前中台分离职责更加明确和灵活，在前台使用不同的技术完成不同的职责。