首页 文章 精选 留言 我的

精选列表

搜索[MSA技术],共10007篇文章
优秀的个人博客,低调大师

前端技术探秘-Nodejs的CommonJS规范实现原理 | 京东物流技术团队

了解Node.js Node.js是一个基于ChromeV8引擎的JavaScript运行环境,使用了一个事件驱动、非阻塞式I/O模型,让JavaScript 运行在服务端的开发平台,它让JavaScript成为与PHP、Python、Perl、Ruby等服务端语言平起平坐的脚本语言。Node中增添了很多内置的模块,提供各种各样的功能,同时也提供许多第三方模块。 模块的问题 为什么要有模块 复杂的前端项目需要做分层处理,按照功能、业务、组件拆分成模块, 模块化的项目至少有以下优点: 便于单元测试 便于同事间协作 抽离公共方法, 开发快捷 按需加载, 性能优秀 高内聚低耦合 防止变量冲突 方便代码项目维护 几种模块化规范 CMD(SeaJS 实现了 CMD) AMD(RequireJS 实现了 AMD) UMD(同时支持 AMD 和 CMD) IIFE (自执行函数) CommonJS (Node 采用了 CommonJS) ES Module 规范 (JS 官方的模块化方案) Node中的模块 Node中采用了 CommonJS 规范 实现原理: Node中会读取文件,拿到内容实现模块化, Require方法 同步引用 tips:Node中任何js文件都是一个模块,每一个文件都是模块 Node中模块类型 内置模块,属于核心模块,无需安装,在项目中不需要相对路径引用, Node自身提供。 文件模块,程序员自己书写的js文件模块。 第三方模块, 需要安装, 安装之后不用加路径。 Node中内置模块 fs filesystem 操作文件都需要用到这个模块 const path = require('path'); // 处理路径 const fs = require('fs'); // file system // // 同步读取 let content = fs.readFileSync(path.resolve(__dirname, 'test.js'), 'utf8'); console.log(content); let exists = fs.existsSync(path.resolve(__dirname, 'test1.js')); console.log(exists); path 路径处理 const path = require('path'); // 处理路径 // join / resolve 用的时候可以混用 console.log(path.join('a', 'b', 'c', '..', '/')) // 根据已经有的路径来解析绝对路径, 可以用他来解析配置文件 console.log(path.resolve('a', 'b', '/')); // resolve 不支持/ 会解析成根路径 console.log(path.join(__dirname, 'a')) console.log(path.extname('1.js')) console.log(path.dirname(__dirname)); // 解析父目录 vm 运行代码 字符串如何能变成 JS 执行呢? 1.eval eval中的代码执行时的作用域为当前作用域。它可以访问到函数中的局部变量。 let test = 'global scope' global.test1 = '123' function b(){ test = 'fn scope' eval('console.log(test)'); //local scope new Function('console.log(test1)')() // 123 new Function('console.log(test)')() //global scope } b() 2.new Function new Function()创建函数时,不是引用当前的词法环境,而是引用全局环境,Function中的表达式使用的变量要么是传入的参数要么是全局的值 Function可以获取全局变量,所以它还是可能会有变量污染的情况出现 function getFn() { let value = "test" let fn = new Function('console.log(value)') return fn } getFn()() global.a = 100 // 挂在到全局对象global上 new Function("console.log(a)")() // 100 3.vm 前面两种方式,我们一直强调一个概念,那就是变量的污染 VM的特点就是不受环境的影响,也可以说他就是一个沙箱环境 在Node中全局变量是在多个模块下共享的,所以尽量不要在global中定义属性 所以,vm.runInThisContext可以访问到global上的全局变量,但是访问不到自定义的变量。而vm.runInNewContext访问不到global,也访问不到自定义变量,他存在于一个全新的执行上下文 const vm = require('vm') global.a = 1 // vm.runInThisContext("console.log(a)") vm.runInThisContext("a = 100") // 沙箱,独立的环境 console.log(a) // 1 vm.runInNewContext('console.log(a)') console.log(a) // a is not defined Node模块化的实现 node中是自带模块化机制的,每个文件就是一个单独的模块,并且它遵循的是CommonJS规范,也就是使用require的方式导入模块,通过module.export的方式导出模块。 node模块的运行机制也很简单,其实就是在每一个模块外层包裹了一层函数,有了函数的包裹就可以实现代码间的作用域隔离。 我们先在一个js文件中直接打印arguments,得到的结果如下图所示,我们先记住这些参数。 console.log(arguments) // exports, require, module, __filename, __dirname Node中通过modules.export 导出,require 引入。其中require依赖node中的fs模块来加载模块文件,通过fs.readFile读取到的是一个字符串。 在javascrpt中可以通过eval或者new Function的方式来将一个字符串转换成js代码来运行。但是前面提到过,他们都有一个致命的问题,就是变量的污染。 实现require模块加载器 首先导入依赖的模块path,fs,vm, 并且创建一个Require函数,这个函数接收一个modulePath参数,表示要导入的文件路径 const path = require('path'); const fs = require('fs'); const vm = require('vm'); // 定义导入类,参数为模块路径 function Require(modulePath) { ... } 在Require中获取到模块的绝对路径,使用fs加载模块,这里读取模块内容使用new Module来抽象,使用tryModuleLoad来加载模块内容,Module和tryModuleLoad稍后实现,Require的返回值应该是模块的内容,也就是module.exports。 // 定义导入类,参数为模块路径 function Require(modulePath) { // 获取当前要加载的绝对路径 let absPathname = path.resolve(__dirname, modulePath); // 创建模块,新建Module实例 const module = new Module(absPathname); // 加载当前模块 tryModuleLoad(module); // 返回exports对象 return module.exports; } Module的实现就是给模块创建一个exports对象,tryModuleLoad执行的时候将内容加入到exports中,id就是模块的绝对路径。 // 定义模块, 添加文件id标识和exports属性 function Module(id) { this.id = id; // 读取到的文件内容会放在exports中 this.exports = {}; } node模块是运行在一个函数中,这里给Module挂载静态属性wrapper,里面定义一下这个函数的字符串,wrapper是一个数组,数组的第一个元素就是函数的参数部分,其中有exports,module,Require,__dirname,__filename, 都是模块中常用的全局变量. 第二个参数就是函数的结束部分。两部分都是字符串,使用的时候将他们包裹在模块的字符串外部就可以了。 // 定义包裹模块内容的函数 Module.wrapper = [ "(function(exports, module, Require, __dirname, __filename) {", "})" ] _extensions用于针对不同的模块扩展名使用不同的加载方式,比如JSON和javascript加载方式肯定是不同的。JSON使用JSON.parse来运行。 javascript使用vm.runInThisContext来运行,可以看到fs.readFileSync传入的是module.id也就是Module定义时候id存储的是模块的绝对路径,读取到的content是一个字符串,使用Module.wrapper来包裹一下就相当于在这个模块外部又包裹了一个函数,也就实现了私有作用域。 使用call来执行fn函数,第一个参数改变运行的this传入module.exports,后面的参数就是函数外面包裹参数exports, module, Require, __dirname, __filename。/ // 定义扩展名,不同的扩展名,加载方式不同,实现js和json Module._extensions = { '.js'(module) { const content = fs.readFileSync(module.id, 'utf8'); const fnStr = Module.wrapper[0] + content + Module.wrapper[1]; const fn = vm.runInThisContext(fnStr); fn.call(module.exports, module.exports, module, Require,__filename,__dirname); }, '.json'(module) { const json = fs.readFileSync(module.id, 'utf8'); module.exports = JSON.parse(json); // 把文件的结果放在exports属性上 } } tryModuleLoad函数接收的是模块对象,通过path.extname来获取模块的后缀名,然后使用Module._extensions来加载模块。 // 定义模块加载方法 function tryModuleLoad(module) { // 获取扩展名 const extension = path.extname(module.id); // 通过后缀加载当前模块 Module._extensions[extension](module); // 策略模式??? } 到此Require加载机制基本就写完了。Require加载模块的时候传入模块名称,在Require方法中使用path.resolve(__dirname, modulePath)获取到文件的绝对路径。然后通过new Module实例化的方式创建module对象,将模块的绝对路径存储在module的id属性中,在module中创建exports属性为一个json对象。 使用tryModuleLoad方法去加载模块,tryModuleLoad中使用path.extname获取到文件的扩展名,然后根据扩展名来执行对应的模块加载机制。 最终将加载到的模块挂载module.exports中。tryModuleLoad执行完毕之后module.exports已经存在了,直接返回就可以了。 接下来,我们给模块添加缓存。就是文件加载的时候将文件放入缓存中,再去加载模块时先看缓存中是否存在,如果存在直接使用,如果不存在再去重新加载,加载之后再放入缓存。 // 定义导入类,参数为模块路径 function Require(modulePath) { // 获取当前要加载的绝对路径 let absPathname = path.resolve(__dirname, modulePath); // 从缓存中读取,如果存在,直接返回结果 if (Module._cache[absPathname]) { return Module._cache[absPathname].exports; } // 创建模块,新建Module实例 const module = new Module(absPathname); // 添加缓存 Module._cache[absPathname] = module; // 加载当前模块 tryModuleLoad(module); // 返回exports对象 return module.exports; } 增加功能:省略模块后缀名。 自动给模块添加后缀名,实现省略后缀名加载模块,其实也就是如果文件没有后缀名的时候遍历一下所有的后缀名看一下文件是否存在。 // 定义导入类,参数为模块路径 function Require(modulePath) { // 获取当前要加载的绝对路径 let absPathname = path.resolve(__dirname, modulePath); // 获取所有后缀名 const extNames = Object.keys(Module._extensions); let index = 0; // 存储原始文件路径 const oldPath = absPathname; function findExt(absPathname) { if (index === extNames.length) { return throw new Error('文件不存在'); } try { fs.accessSync(absPathname); return absPathname; } catch(e) { const ext = extNames[index++]; findExt(oldPath + ext); } } // 递归追加后缀名,判断文件是否存在 absPathname = findExt(absPathname); // 从缓存中读取,如果存在,直接返回结果 if (Module._cache[absPathname]) { return Module._cache[absPathname].exports; } // 创建模块,新建Module实例 const module = new Module(absPathname); // 添加缓存 Module._cache[absPathname] = module; // 加载当前模块 tryModuleLoad(module); // 返回exports对象 return module.exports; } 源代码调试 我们可以通过VSCode 调试Node.js 步骤 创建文件a.js module.exports = 'abc' 1.文件test.js let r = require('./a') console.log(r) 1.配置debug,本质是配置.vscode/launch.json文件,而这个文件的本质是能提供多个启动命令入口选择。 一些常见参数如下: program控制启动文件的路径(即入口文件) name下拉菜单中显示的名称(该命令对应的入口名称) request分为 launch(启动)和 attach(附加)(进程已经启动) skipFiles指定单步调试跳过的代码 runtimeExecutable设置运行时可执行文件,默认是 node,可以设置成 nodemon,ts-node,npm 等 修改launch.json,skipFiles指定单步调试跳过的代码 将test.js 文件中的require方法所在行前面打断点 执行调试,进入源码相关入口方法 梳理代码步骤 1.首先进入到进入到require方法:Module.prototype.require 2.调试到Module._load 方法中,该方法返回module.exports,Module._resolveFilename方法返回处理之后的文件地址,将文件改为绝对地址,同时如果文件没有后缀就加上文件后缀。 3.这里定义了Module类。id为文件名。此类中定义了exports属性 4.接着调试到module.load 方法,该方法中使用了策略模式,Module._extensions[extension](this, filename)根据传入的文件后缀名不同调用不同的方法 5.进入到该方法中,看到了核心代码,读取传入的文件地址参数,拿到该文件中的字符串内容,执行module._compile 6.此方法中执行wrapSafe方法。将字符串前后添加函数前后缀,并用Node中的vm模块中的runInthisContext方法执行字符串,便直接执行到了传入文件中的console.log代码行内容。 至此,整个Node中实现require方法的整个流程代码已经调试完毕,通过对源代码的调试,可以帮助我们学习其实现思路,代码风格及规范,有助于帮助我们实现工具库,提升我们的代码思路,同时我们知道相关原理,也对我们解决日常开发工作中遇到的问题提供帮助。 作者:京东物流 乔盼盼 来源:京东云开发者社区 自猿其说Tech 转载请注明来源

优秀的个人博客,低调大师

技术干货:解密最受欢迎的开源 Serverless 框架弹性技术实现

Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架,其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布以及事件驱动等。 弹性是 Serverless 中的核心能力,那么 Knative 作为 CNCF 社区最受欢迎的开源 Serverless 应用框架,提供了哪些与众不同的弹性能力呢?本文将带你深入了解 Knative 的弹性实现。(说明:本文基于 Knative 1.8.0 版本进行分析) Knative 提供了基于请求的自动弹性实现 KPA(Knative Pod Autoscaler),也支持 K8s 中的 HPA,此外 Knative 提供了灵活的弹性扩展机制,可以结合自身业务需要,扩展弹性实现。这里我们也会介绍与 MSE 结合实现精准弹性以及与 AHPA 结合实现基于请求的弹性预测。 首先我们介绍 Knative 原生最具吸引力的弹性:KPA。 基于请求的自动弹性 KPA 基于 CPU 或者 Memory 的弹性,有时候并不能完全反映业务的真实使用情况,而基于并发数或者每秒处理请求数 (QPS/RPS),对于 web 服务来说更能直接反映服务性能,Knative 提供了基于请求的自动弹性能力。要获得当前服务的请求数,Knative Serving 为每个 Pod 注入 QUEUE 代理容器 (queue-proxy),该容器负责收集用户容器并发数 (concurrency) 或请求数 (rps) 指标。Autoscaler 定时获取这些指标之后,会根据相应的算法,调整 Deployment 的 Pod 数量,从而实现基于请求的自动扩缩容。 图片来源:https://knative.dev/docs/serving/request-flow/ 基于请求数的弹性算法 Autoscaler 基于每个 Pod 的平均请求数(或并发数)进行弹性计算。默认情况下 Knative 使用基于并发数的自动弹性, 默认 Pod 的最大并发数为 100。此外 Knative 中还提供了一个叫 target-utilization-percentage 的概念,称之为目标使用率,取值范围 0~1,默认是 :0.7。 以基于并发数弹性为例,Pod 数计算方式如下: POD数=并发请求总数/(Pod最大并发数*目标使用率) 例如服务中 Pod 最大并发数设置了 10,这时候如果接收到了 100 个并发请求,目标使用率设置为 0.7,那么 Autoscaler 就会创建了 15 个 POD(100/(0.7*10) 约等于 15)。 缩容到 0 的实现机制 使用 KPA 时当无流量请求时,会将 Pod 数自动缩容到 0;当有请求时,会从 0 开始扩容 Pod。那么 Knative 中是如何实现这样的操作呢?答案是通过模式切换。 Knative 中定义了 2 种请求访问模式:Proxy 和 Serve。Proxy 顾名思义,代理模式,也就是请求会通过 activator 组件进行代理转发。Serve 模式是请求直达模式,从网关直接请求到 Pod,不经过 activator 代理。如下图: 模式的切换是由 autoscaler 组件负责,当请求为 0 时,autoscaler 会将请求模式切换为 Proxy 模式。这时候请求会通过网关请求到 activator 组件,activator 收到请求之后会将请求放在队列中,同时推送指标通知 autoscaler 进行扩容,当 activator 检测到由扩容 Ready 的 Pod 之后,随即将请求进行转发。而 autoscaler 也会判断 Ready 的 Pod,将模式切换为 Serve 模式。 应对突发流量 突发流量下如何快速弹资源 KPA 涉及到 2 个与弹性相关的概念:Stable(稳定模式)和 Panic(恐慌模式),基于这 2 种模式,可以让我们认识到 KPA 如何基于请求做到精细化弹性。 首先稳定模式是基于稳定窗口期,默认是 60 秒。也就是计算在 60 秒时间段内,Pod 的平均并发数。 而恐慌模式是基于恐慌窗口期,恐慌窗口期是通过稳定窗口期与 panic-window-percentage 参数计算得到。panic-window-percentage取值是 0~1,默认是 0.1。恐慌窗口期计算方式:恐慌窗口期=稳定窗口期 *panic-window-percentage。默认情况下也就是 6 秒。计算在 6 秒时间段内,Pod 的平均并发数。 KPA 中会基于稳定模式和恐慌模式 Pod 的平均并发数分别计算所需要的 Pod 数。 那么实际根据哪个值进行弹性生效呢?这里会依据恐慌模式下计算的 Pod 数是否超过恐慌阈值 PanicThreshold 进行判断。恐慌阈值是通过 panic-threshold-percentage/100 计算出来,panic-threshold-percentage 参数默认是 200,也就是恐慌阈值默认是 2。当恐慌模式下计算出来的 Pod 数大于或等于当前 Ready Pod 数的 2 倍,那么就会使用恐慌模式 Pod 数进行弹性生效,否则使用稳定模式 Pod 数。 显然,恐慌模式的设计是为了应对突发流量场景。至于弹性敏感度,则可以通过上述的可配置参数进行调节。 突发流量下如何避免 Pod 被打爆 KPA 中可以设置突发请求容量(target-burst-capacity)应对 Pod 被超预期的流量打爆。也就是通过这个参数值的计算,来调节请求是否切换到 Proxy 模式,从而通过 activator 组件作为请求缓冲区。如果当前 ready pod 数*最大并发数-突发请求容量-恐慌模式计算出来的并发数 <0,意味着突发流量超过了容量阈值,则切换到 activator 进行请求缓冲。当突发请求容量值为 0 时,只有 Pod 缩容到 0 时,才切换到 activator。当大于 0 并且 container-concurrency-target-percentage 设置为 100 时,请求总是会通过 activator。-1 表示无限的请求突发容量。请求也总是会通过 activator。 减少冷启动的一些技巧 延迟缩容 对于启动成本较高的 Pod, KPA 中可以通过设置 Pod 延迟缩容时间以及 Pod 缩容到 0 保留期,来减少 Pod 扩缩容频率。 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/scale-down-delay: ""60s" autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s" spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56 调低目标使用率,实现资源预热 Knative 中提供了目标阈值使用率的配置。通过调小该值可以提前扩容超过实际需要使用量的 Pod 数,在请求达到目标并发数之前进行扩容,间接的可以做到资源预热。例如,如果 containerConcurrency 设置为 10,目标利用率值设置为 70(百分比),则当所有现有 Pod 的平均并发请求数达到 7 时,Autoscaler 将创建一个新 Pod。因为 Pod 从创建到 Ready 需要一定的时间,通过调低目标利用率值可以做到提前扩容 Pod,从而减少冷启动导致的响应延迟等问题。 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/target-utilization-percentage: "70" spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56 配置 KPA 通过上面的介绍,我们对 Knative Pod Autoscaler 工作机制有了进一步的了解,那么接下来介绍如何配置 KPA。Knative 中配置 KPA 提供了两种方式:全局模式和 Revision 模式。 全局模式 全局模式可以修改 K8s 中的 ConfigMap:config-autoscaler,查看 config-autoscaler 使用如下命令: kubectl -n knative-serving get cm config-autoscaler apiVersion: v1 kind: ConfigMap metadata: name: config-autoscaler namespace: knative-serving data: container-concurrency-target-default: "100" container-concurrency-target-percentage: "70" requests-per-second-target-default: "200" target-burst-capacity: "211" stable-window: "60s" panic-window-percentage: "10.0" panic-threshold-percentage: "200.0" max-scale-up-rate: "1000.0" max-scale-down-rate: "2.0" enable-scale-to-zero: "true" scale-to-zero-grace-period: "30s" scale-to-zero-pod-retention-period: "0s" pod-autoscaler-class: "kpa.autoscaling.knative.dev" activator-capacity: "100.0" initial-scale: "1" allow-zero-initial-scale: "false" min-scale: "0" max-scale: "0" scale-down-delay: "0s" 参数说明: 参数 说明 container-concurrency-target-default 默认Pod最大并发数,默认值100 container-concurrency-target-percentage 并发数目标使用率,70实际表示0.7 requests-per-second-target-default 默认每秒请求数(rps),默认值200 target-burst-capacity 突发请求容量 stable-window 稳定窗口,默认60s panic-window-percentage 恐慌窗口比例,默认值为10,则表示默认恐慌窗口期为6秒(60*0.1=6) panic-threshold-percentage 恐慌阈值比例,默认值200 max-scale-up-rate 最大扩缩容速率,表示一次扩容最大数,实际计算方式:math.Ceil(MaxScaleUpRate * readyPodsCount) max-scale-down-rate 最大缩容速率,表示一次缩容最大数,实际计算方式:math.Floor(readyPodsCount / MaxScaleDownRate)。默认值2表示,每次缩容一半。 enable-scale-to-zero 是否开始缩容到0,默认开启 scale-to-zero-grace-period 优雅缩容到0的时间,也就是延迟多久缩容到0,默认30s scale-to-zero-pod-retention-period pod缩容到0保留期,该参数适用于Pod启动成本较高的情况 pod-autoscaler-class 弹性插件类型,当前支持的弹性插件包括:kpa、hpa、ahpa以及mpa(ask场景下配合mse支持缩容到 0) activator-capacity activator请求容量 initial-scale 创建revision时,初始化启动的Pod数,默认1 allow-zero-initial-scale 是否允许创建revision时,初始化0个Pod, 默认false,表示不允许 min-scale revision级别最小保留的Pod数量。默认0表示最小值可以为0 max-scale revision级别最大扩容的Pod数量。默认0表示无最大扩容上限 scale-down-delay 表示延迟缩容时间,默认0表示立即缩容 Revision 版本模式 在 Knative 中可以为每一个 Revision 配置弹性指标,部分配置参数如下: 指标类型 每个 revision 指标注解:autoscaling.knative.dev/metric 支持的指标:"concurrency","rps","cpu","memory"以及其它自定义指标 默认指标:"concurrency" 目标阈值 autoscaling.knative.dev/target 默认值:"100" pod 缩容到 0 保留期 autoscaling.knative.dev/scale-to-zero-pod-retention-period 目标使用率 autoscaling.knative.dev/target-utilization-percentage 配置示例如下: apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/metric: "concurrency" autoscaling.knative.dev/target: "50" autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s" autoscaling.knative.dev/target-utilization-percentage: "80" 对 HPA 的支持 对于 K8s HPA, Knative 也提供天然的配置支持,可以在 Knative 使用基于 CPU 或者 Memory 的自动弹性能力。 基于 CPU 弹性配置 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev" autoscaling.knative.dev/metric: "cpu" 基于 Memory 的弹性配置 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev" autoscaling.knative.dev/metric: "memory" 弹性能力增强 Knative 提供了灵活的插件机制(pod-autoscaler-class),可以支持不同的弹性策略。阿里云容器服务 Knative 当前支持的弹性插件包括:kpa、hpa、精准弹性扩缩容 mpa 以及 具有预测能力的 ahpa。 保留资源池 在原生的 KPA 能力之上,我们提供了保留资源池的能力。该功能可以应用在如下场景: ECS 与 ECI 混用。如果希望常态情况下使用 ECS 资源,突发流量使用 ECI, 那么我们可以通过保留资源池来实现。如单个 Pod 处理的并发 10,保留资源池 Pod 数为 5,那么常态下通过 ECS 资源可以应对不超过 50 的并发请求。如果并发数超过 50,那么 Knative 就会扩容新的 Pod 数来满足需求,新扩容出来的资源使用 ECI。 资源预热。对于完全使用 ECI 的场景,也可以通过保留资源池实现资源预热。当在业务波谷时使用保留实例替换默认的计算型实例,当第一个请求来临时使用保留实例提供服务,同时也会触发默认规格实例的扩容。当默认规格实例扩容完成以后所有新请求就会都转发到默认规格上,同时保留实例则不会接受新的请求,并且等保留实例所有接收到的请求处理完成以后就会被下线。通过这种无缝替换的方式实现了成本和效率的平衡,即降低了常驻实例的成本又不会有显著的冷启动时长。 精准弹性扩缩容 单个 Pod 处理请求的吞吐率有限,如果多个请求转发到同一个 Pod,会导致服务端过载异常,因此需要精准的控制单个 Pod 请求并发处理数。尤其对一些 AIGC 场景下,单个请求会占用较多的 GPU 资源,需要严格的限制每个 Pod 并发处理的请求数。 Knative 与 MSE 云原生网关结合,提供基于并发数精准控制弹性的实现:mpa 弹性插件。 mpa 会从 MSE 网关获取并发数,并计算所需要的 Pod 数进行扩缩容,而 MSE 网关可以做到基于请求精准转发。 配置示例如下: apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go spec: template: metadata: annotations: autoscaling.knative.dev/class: mpa.autoscaling.knative.dev autoscaling.knative.dev/max-scale: '20' spec: containerConcurrency: 5 containers: - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56 env: - name: TARGET value: "Knative" 参数说明: 参数 说明 autoscaling.knative.dev/class: mpa.autoscaling.knative.dev mpa表明使用MSE指标进行扩缩容,支持缩容到0 autoscaling.knative.dev/max-scale: '20' 扩容Pod数上限是20 containerConcurrency: 5 表示单个Pod能处理的最大并发数是5 弹性预测 AHPA 容器服务 AHPA(Advanced Horizontal Pod Autoscaler)可以根据业务历史指标,自动识别弹性周期并对容量进行预测,解决弹性滞后的问题。 当前 Knative 支持 AHPA(Advanced Horizontal Pod Autoscaler)的弹性能力,当请求具有周期性时,可通过弹性预测,实现预热资源。相比于调低阈值进行资源预热,通过 AHPA 可以最大程度的提升资源利用率。 此外由于 AHPA 支持自定义指标配置,Knative 与 AHPA 结合可以做到基于消息队列以及响应延迟 rt 的自动弹性。 基于 rps 使用 AHPA 配置示例如下: apiVersion: serving.knative.dev/v1 kind: Service metadata: name: autoscale-go namespace: default spec: template: metadata: labels: app: autoscale-go annotations: autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev autoscaling.knative.dev/target: "10" autoscaling.knative.dev/metric: "rps" autoscaling.knative.dev/minScale: "1" autoscaling.knative.dev/maxScale: "30" autoscaling.alibabacloud.com/scaleStrategy: "observer" spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1 参数说明: 参数 说明 autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev 指定弹性插件AHPA。 autoscaling.knative.dev/metric: "rps" 设置AHPA指标。目前支持concurrency、rps以及响应时间rt。 autoscaling.knative.dev/target: "10" 设置AHPA指标的阈值,本示例rps阈值为10,表示单个Pod每秒最大处理请求数10。 autoscaling.knative.dev/minScale: "1" 设置弹性策略实例数的最小值为1。 autoscaling.knative.dev/maxScale: "30" 设置弹性策略实例数的最大值为30。 http://autoscaling.alibabacloud.com/scaleStrategy:"observer" 设置弹性伸缩模式,默认值是observer。observer:表示只观察,但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据,因此创建服务默认是observer模式。auto:表示由AHPA负责扩容和缩容,把AHPA指标和阈值输入到AHPA,AHPA最终决定是否生效。 ta-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal"> 参数 说明 autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev 指定弹性插件AHPA。 autoscaling.knative.dev/metric: "rps" 设置AHPA指标。目前支持concurrency、rps以及响应时间rt。 autoscaling.knative.dev/target: "10" 设置AHPA指标的阈值,本示例rps阈值为10,表示单个Pod每秒最大处理请求数10。 autoscaling.knative.dev/minScale: "1" 设置弹性策略实例数的最小值为1。 autoscaling.knative.dev/maxScale: "30" 设置弹性策略实例数的最大值为30。 http://autoscaling.alibabacloud.com/scaleStrategy:"observer" 设置弹性伸缩模式,默认值是observer。observer:表示只观察,但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据,因此创建服务默认是observer模式。auto:表示由AHPA负责扩容和缩容,把AHPA指标和阈值输入到AHPA,AHPA最终决定是否生效。 e data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal"> 小结 本文从 Knative 典型弹性实现 KPA 出发进行介绍,包括如何实现基于请求的自动弹性、缩容到 0、应对突发流量以及我们在 Knative 弹性功能上的扩展增强,包括保留资源池,精准弹性以及弹性预测能力。 作者:元毅 点击立即免费试用云产品 开启云上实践之旅! 原文链接 本文为阿里云原创内容,未经允许不得转载。

优秀的个人博客,低调大师

618技术揭秘 - 大促弹窗搭投实践 | 京东云技术团队

背景 618 大促来了,对于业务团队来说,最重要的事情莫过于各种大促营销。如会场、直播带货、频道内营销等等。而弹窗作为一个极其重要的强触达营销工具,通常用来渲染大促氛围、引流主会场、以及通过频道活动来提升频道复访等。因此,如果能将运营的策略及想法快速转化为弹窗的内容并触达给用户,这对于提升运营效率及玩法灵活性的是极其有意义的。 此前,在 JD 主站的大多弹窗业务应用中,XView 仅仅是作为一个 h5 的容器被使用,或基于 XView 提供的一些简单的配置化能力来配置一个弹窗。作为 h5 容器的方式虽然灵活,但需要研发的参与。而基于 XView 提供的配置化能力,虽然只需产品、运营侧配置,但是配置化逻辑繁琐、学习成本高、且对于弹窗样式有局限,不够灵活。因此,此前使用的俩种方式,弊端都可以归结为:使用成本高。 为了持续优化XView 性能, XView 从配置化的方式,升级为组件化搭建的方式,以一种更加直观的可视化拖拽元素组件搭建弹窗样式,而后附加投放的配置,其目标便是解决此前所面临的几个重点问题: •学习成本高 •不够灵活 •需要编码 升级完成后,本次 618 的一些重要弹窗均迁移到全新的搭投平台。 XView 618 实践 伴随着 XView 搭建投放的能力升级,从 5.23 开门红开始,持续为 618 期间提供了稳定、快速、便捷、可视化的弹窗搭建投放能力。 以下选取了本次 618 搭建并投放的一些重要弹窗案例的截图: 1.预热开场,氛围打造 2. T级互动 3.老罗直播底部通栏 4.新品小魔方、京东电器等频道红包雨 通过以上截图可更加直观的感受到弹窗的营销应用场景的多样性及重要性。接下来,将为大家介绍一下 XView是 如何实现弹窗的搭建和投放,以及业务如何使用。 XView 弹窗搭投升级 a. 应用场景分析 在实现搭建和投放的能力之前,首先从业务的角度对弹窗的应用场景及能力需求做一些分析是充分必要的。接下来将从现实中,将过去在 JD App 使用的一些弹窗案例进行一些梳理: 通过以上分类的梳理,从业务视角来看,功能性的弹窗在大促中的重要性是其次的,而主要是营销类的弹窗,它们往往具备以下特点: •突发创意/需求: 偶然的创意玩法,或突发的外部业务需求,时效性要求高,即上线时间不可逾期**。** •一次性 : 用一段时期就不用了 •能按需触达 : 可按需投放,投放到不同的业务,满足不同人群需要。 •要保障触达成功率: 如一些广告投放,品牌方有曝光率要求的。 b. 能力细化抽象 为了满足以上业务的诉求,从大的方向上看,XView 需要做到 •快:快速搭建 •准:精准投放 •稳:高效触达 因此,接下来我们将刨析一个弹窗从生产到应用的过程中所涉及到的一些环节,再来看看如何细化弹窗需要具备的能力。通过观察一些典型弹窗后不难发现,在不同业务中,它们的工作流程是极其相似的,其工作流程和应用场景可大致抽象成如下图所示: 首先确定需要投放的人群,而其他人群将不会命中,这里是为了防止对非必要触达人群的干扰。当弹窗的配置信息下发给客户端后,App 在适当时候、适当的页面触发弹出,而弹窗的展示形态可以是多样的,包括但不限于:全屏、半屏等。 另外,弹窗通常的样式比较简单,可能就是一些文字、图片、视频等,这些数据可以基于人工的录入配置,也可以来自于上游接口。最后,可以概括出来弹窗应具备的一些特质,它们主要包括: •**人群投放:**根据用户身份标签、地理位置等信息进行定投 •**触发场景:**进入页面、摇一摇 •**页面覆盖:**首页、会场... (原生、H5) •**动画能力:**淡入、淡出 •**元素覆盖:**文字、图片... •**布局形态:**全屏、半屏 •**点击事件:**跳转、接口请求 •**数据绑定:**静态配置数据、接口请求数据 c. 搭投平台设计 搭投平台的建设主要有俩个目标,一是支持高效的搭建弹窗预览内容,二是支持快速配置投放规则,以下是一个设计图: 最终搭建的产物被转化成了通天塔的 DSL,这是为了在客户端复用通天塔的 原生渲染 能力,并利用原生的渲染来确保弹窗的体验更佳。 可视化的搭建设计器如下图所示: d. 客户端设计 搭建好的产物最终会被投放到客户端,而客户端主要处理的重点是: 弹窗资源(预)加载、触发控制、内容渲染,以下为客户端的设计图,图中资源以图片资源为代表来说明: XView 通过对 App 以及页面的生命周期进行监控,感知页面上弹窗的弹出时机以及弹窗资源的加载时机,最终触发弹窗的弹出以及屏幕呈现。 e. 使用XView搭投 最后,我们将忽略大量细节部分,然后拉到整体视角来俯瞰一下运营是如何使用XView来搭建和投放弹窗到客户端的。 专题讨论 f. 动态数据绑定 在搭建设计器中,手动录入弹窗数据是易于配置和理解的,如配置一个图片组件,并上传图片文件生成图片的链接,或是配置一个文本组件,在输入框录入文本的文案,但这些属于预先配置的静态数据。 如果想要在弹窗弹出时,基于上游接口实时拉取数据,就需要支持动态数据的配置能力,这种应用的场景也很普遍,如弹窗上显示的奖励的京豆数额,红包金额等等。 对于动态数据的支持,会稍稍复杂一点点,大致流程如下: 1.定义变量及模型命名标准规范: 基于标准规范,便于程序理解变量输出的意义,如 title 可解释为标题 2.基于接口的编排能力输出标准变量: 整合上游接口,转化为标准输出 3.搭建设计器中配置数据源: 配置接口编号及请求参数 4.搭建设计器中配置输出变量与组件属性的绑定关系 在上图案例中,通过接口的编排和配置,XView 将图中所示 “接口1” 作为数据源,此接口输出标准化命名的变量,让搭建设计器可以识别变量的意义并展示为中文提示。然后组件的属性可以选择绑定这些输出的 “变量”。如下图所示,这是在设置一个文本组件的文本内容属性,这里选择绑定了输出的标准变量列表中的 “标题” : g. 使用动画提升效能 为了进一步提升弹窗的触达效能,考虑使用丰富的动画能力来实现提升曝光率和点击率。具体来说明就是通过动画替代大文件如视频获gif 可以有效减少文件大小,提升弹窗加载速度,从而提升曝光效率。 以下就是一个使用 Lottie 动画替代 gif 的案例,以这个动画为例,对比 GIF 的形式 lottie 的体积缩小了大约 90%。 写在最后 目前,XView 搭建的弹窗已经服务了众多的业务,包括首页、频道、互动等。通过本次 618 充分验证了XView 快速搭建投放的能力以及稳定性,我们始终保持开放的心态,将服务于更多的业务。 尤其后续一些考虑 h5 实现的弹窗,完全可以迁移到这套搭投系统中,通过对比 h5 弹窗开发(图左侧)及搭投的方式(图右侧),可以大致看到使用搭投系统的优势: 与此同时,会持续提升弹窗体验,提高曝光率、点击率,并不断探索更多的运营玩法及策略,支持运营实现更多的业务价值的提升。 作者:京东零售 王晰源 来源:京东云开发者社区

优秀的个人博客,低调大师

技术:通过指纹跟踪技术追踪恶意软件开发者

我们经常会遇到一些臭名昭著的恶意组织,他们使用相同的恶意软件针对不同的受害者。在这种情况下,关注焦点通常是受害者公司的团队不同版本的开发软件。 最近的一个例子是星际风暴恶意软件的变种,它从针对Windows和Linux发展到感染Android和MacOS。 有时候退后一步,辨别出团体中那些暗中观察、拥有特异技能的别有用心者非常重要,并且在一定情况下对他们的特殊身份给予相应的监控也是极为重要的。 记住这个框架的思想,最近检查点的研究人员发明了一个方法来将这些特定身份的恶意软件开发者进行辨别:分出谁是特定利用的幕后黑手,并辨别这些始作俑者开发的其他软件的暗门是什么。 为了做到这一点,他们关注了2个以各种零日攻击著称的威胁者: Volodya AKA BuggiCorp Playbit AKA luxor2008 看到他们不同的开发功能,他们能够识别出每个开发者特有的特征。然后,利用这些特征进行寻找,只要发现类似的案件,就表明这些案件的背后都是同样的始作俑者。研究人员在一份研究报告中解释了背后的故事: 当分析一个针对我们的客户的复杂攻击时,我们注意到一个非常小的64位可执行程序被恶意软件执行。包含一些不寻常的调试字符串,它们指向试图利用受害机器上的漏洞。 使用这个64位二进制文件,他们开始了指纹识别的整个过程,其中收集了最初简单的工件,如“字符串、内部文件名、时间戳和PDB路径”。 通过指纹追踪恶意软件开发者 研究人员在一个开发过程中寻找不同人为痕迹 通过使用这些文件,他们发现了与另一个32位可执行文件类似的匹配,不久之后,他们就记下了来自同两个因素下产生的16个不同的Windows LPE漏洞因素。 此外,由于这16款中有15款是在2015至2019年推出的,这也将证明是对Windows LPE 开发市场的一次打击。 一个接一个之后,几十个样本的出现,我们改进了狩猎规则和方法。仔细分析的样品,我们能够理解哪些样品利用了CVE,创建了一个时间表,基于它,可以理解哪一些开发程序被加零日漏洞,或是被掺杂基于不同补丁的一日漏洞 综上所述,这为专业人员追踪恶意软件背后的犯罪分子提供了一种很好的方法,而不仅仅是寻找被动防御机制、使得系统免受恶意软件攻击。 在此之前,已经使用了一些创新的方法,比如我们报道的案件中,警察利用一个毒品贩子手的照片来描绘出他的指纹,然后追踪他。 不仅如此,事实上,3D打印机已经被发现可以复制指纹,使模仿变得非常容易,并构成另一重威胁。因此,在先进方法上保持进行是很重要的,因为它们是网络安全的最终目的地。 【责任编辑: 赵宁宁 TEL:(010)68476606】

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册