• 关于

    公共变量如何看配置

    的搜索结果

回答

概述 1.1 媒体工作流的作用 媒体工作流支持截图、转码、转封装、水印、剪辑等功能,使您可以快速、灵活、按需搭建云端音视频处理流程;在媒体工作流开始执行和完成执行时,支持向指定的消息队列或消息通知发送工作流执行信息。具体包括以下功能:输入bucket路径,转码配置,截图配置,发布配置及消息通知配置。 消息服务检测到输入bucket路径中存在资源增量输入,就会触发媒体工作流中的转码或者截图任务进行转码及截图,对应的任务完成,如果您的输入配置中配置了消息服务的通知或者队列即会在工作流执行实例的开始和结束时通过消息服务发送消息供用户业务逻辑判断,而对应的转码或者截图结果将存储到工作流配置的输出bucket中。 1.2 媒体工作流配置流程 用户可以登陆控制台,在工作流管理中选择配置方案—>输入设置—>转码设置/截图设置/分析及转码设置—>发布设置—>配置cdn加速; 1 1.3 配置方案介绍 2 预置配置方案包括了:M3U8切片工作流,预置智能模板工作流,多码率多格式工作流,FLV多码率工作流,M3U8多码率工作流,MP4多码率工作流,以上工作流其实就是分析转码截图任务节点的组合,用户可以根据需求选择对应的组合或者自定义组合。 3 输入设置 2.1 输入设置基础设置 点击输入节点上的“铅笔”按钮—>进入输入配置页面—>选择输入bucket,转码管道,消息类别,填入输入路径,基础配置就完成了。 45 2.2 输入bucket设置 点击“选择”按钮可以进入到OSS文件管理页面,用户可以选择需求的bucket及bucket下的某个文件夹作为输入路径(文件夹选定后,会自动补全到输入路径的文本框中)。 6 输入bucket选择注意事项 在哪个区域新建工作流,对应的输入bucket也只能是对应区域的bucket,别的区域的bucket不能选择; 输入bucket中的可选择bucket,必须源自媒体bucket的输入bucket,媒体bucket如何添加,请看视频点播初始化设置文档; 输入路径是可编辑的,但注意目录的设置不需要以/结尾,如想存储资源到1目录下的2目录,那么对应的输入路径便为1/2/,而不是1/2; 目前工作流只支持在华东1,华东2,华北1,华南1 区域; 2.3 转码管道设置 转码管道,是处理转码作业的管道,选择对应的管道即可。关于管道的具体意义请参考:《视频点播的初始化设置》。 转码管道限制: 目前每个用户在每个服务可用域拥有1个管道; 每个管道可最多可容纳10000个排队作业; 每个管道最多可同时处理的作业不超过分配给该管道的转码资源数; 2.4 消息类别设置 其中消息类别分为:队列和通知。消息类别可以不进行设置。队列创建看【队列创建】; 通知创建看【通知创建】;队列与通知的区别请看【队列与通知的区别】;队列与通知的消息消费看【队列与通知的消息消费】;选择通知后,可以选择对应的通知名称,也可以增加通知。7选择队列后,可以选择对应的队列,也可以增加队列。8 转码设置 3.1 转码设置基础设置 点击转码按钮上的“铅笔”按钮—>进入基础配置页面—>选择转码模板,输出bucket,是否使用水印,填入输出路径,基础配置就完成了。1011 3.2 转码模板设置 点击选择按钮—>进入转码模板页面—>选择转码模板。转码模板分为预置静态模板及自定义模板。视频点播的转码模板源自媒体转码MTS的转码模板,也可以在视频点播初始化设置的时候添加。预置静态模板介绍看【预置静态模板】 12 转码模板选择注意事项 转码为不同的格式,建议选择转码模板,而不是转码封装模板,否则可能会有转码失败的可能。 3.3 输出bucket设置 点击选择按钮—>进入OSS文件管理页面—>选择输出bucket及对应的输出文件夹。13 输出bucket选择注意事项 在哪个区域新建工作流,对应的输出bucket也只能是对应区域的bucket,别的区域的bucket不能选择; 输出bucket中的可选择bucket,必须源自媒体bucket的输出bucket,媒体bucket如何添加,请看视频点播初始化设置文档; 输出路径是可编辑的,但注意目录的设置不需要以/结尾,如想存储资源到1目录下的2目录,那么对应的输出路径便为1/2/,而不是1/2; 目前工作流只支持在华东1,华东2,华北1和华南1 四个区域; 3.4 使用水印设置 水印设置是为用户的转码视频添加水印,用户可以选择对应的水印模板或者不使用水印。水印模板选择后,选择对应的水印图片—>进入OSS管理页面—>选择bucket中的图片。水印模板源自媒体转码MTS的水印模板,也可以在视频点播初始化设置的时候添加。14 注意: 水印图片所在bucket源自媒体bucket中的输出bucket。 4. 截图设置 4.1 截图设置基础设置 点击截图按钮上的“铅笔”标识—>进入截图页面—>选择是否进行多张截图,输出bucket,开始时间,是否设置为封面,是否截取关键帧,设置截图时间间隔,截图数量,输出路径,图片宽度,高度。1516 截图基础配置注意事项: 多张截图:表示是否开启多张截图,多张截图开启后,可以设置截图数量及截图间隔; 开始时间,表示从什么时间点开启截图,注意设置开始时间不要大于视频总时长,不然是不会截图的; 设置封面:表示对应的截图是否设置为封面,如果开启多张截图,默认第一张截图设置为封面; 关键帧:表示是否只截取关键帧的图片,截取非关键帧的图片,图片可能会存在模糊损坏的现象; 图片宽度高度表示截取图片的宽高; 4.1 输出bucket设置 点击选择按钮—>进入OSS文件管理页面—>选择输出bucket及对应的输出文件夹。17 输出bucket选择注意事项 在哪个区域新建工作流,对应的输出bucket也只能是对应区域的bucket,别的区域的bucket不能选择; 输出bucket中的可选择bucket,必须源自媒体bucket的输出bucket,媒体bucket如何添加,请看视频点播初始化设置文档; 输出路径是可编辑的,在选择bucket并选择文件夹后,对应的输出路径默认为:文件夹名称/ {RunId}/{SnapshotTime}/{Count}.jpg,{RunId}表示转码实例id, {SnapshotTime} 为截图时间点,单位为毫秒,此例中对视频第5秒截图,则变量取值为 5000,如果使用多张图片需要使用{Count}占位符,反之不需要; 目前工作流只支持在华东1,华东2,华北1和华南1 四个区域; 5. 分析/转码设置 5.1 分析/转码设置基础设置 点击转码按钮上的“铅笔”标识—>进入基础配置页面—>选择转码模板,输出bucket,是否使用水印,填入输出路径,基础配置就完成了。1819 5.2 转码模板设置 点击选择按钮—>进入转码模板页面—>选择转码模板。转码模板为预置智能模板,对应的转码任务要生效,得转码之前的分析作业执行后,分析得到到适用该视频的转码模板包含了转码设置中选择的模板,对应的转码任务才能执行,否则是不会执行,在执行实例中出现“跳过”的图示结果。预置智能模板介绍看【预置智能模板介绍】;如果想转码任务一定执行,请直接添加转码任务,不要加分析/转码任务并且使用MTS静态模板,不要使用MTS智能模板。 20 转码模板选择注意事项 转码为不同的格式,建议选择转码模板,而不是转码封装模板 5.3 输出bucket设置 点击选择按钮—>进入OSS文件管理页面—>选择输出bucket及对应的输出文件夹。21 输出bucket选择注意事项 在哪个区域新建工作流,对应的输出bucket也只能是对应区域的bucket,别的区域的bucket不能选择; 输出bucket中的可选择bucket,必须源自媒体bucket的输出bucket,媒体bucket如何添加,请看视频点播初始化设置文档; 输出路径是可编辑的,但注意目录的设置不需要以/结尾,如想存储资源到1目录下的2目录,那么对应的输出路径便为1/2/,而不是1/2; 目前工作流只支持在华东1,华东2,华北1和华南1 四个区域; 5.4 使用水印设置 水印设置是为用户的转码视频添加水印,用户可以选择对应的水印模板或者不使用水印。水印模板选择后,选择对应的水印图片—>进入OSS管理页面—>选择bucket中的图片。水印模板源自媒体转码MTS的水印模板,也可以在视频点播初始化设置的时候添加。22 注意: 水印图片所在bucket源自媒体bucket中的输出bucket。 6. 发布设置 点击发布边上的铅笔按钮—>进入发布页面—>选择媒体发布类型,基础配置就完成了。媒体发布类型分为自动及手动,默认为手动。2324 发布设置注意事项: 自动与手动的区别为:自动表示工作流处理后生成的object的acl 为default状态,这个状态表示object的权限继承自bucket的权限,当bucket是公共读的时候,object的acl 也是公共读,bucket私有,object acl 也是私有的;手动表示工作流处理后生成的object的acl为私有的,必须通过鉴权才能访问该object资源; 已有的媒体视频要修改发布状态,可以在媒体库中点击发布,进行发布;25 7. 配置cdn加速 点击下一步按钮—>进入配置内容分发网络(CDN)页面—>如果不存在cdn域名就点击添加,快速添加点播加速域名。26 注意:只有在新建工作流配置中有cdn 域名,对应转码输出后的资源才会带cdn域名地址的链接,如果当时创建工作流不存在CDN域名,之后在bucket中手动绑定域名并进行加速,这样的域名是不会在输出媒体地址中显示的。27
保持可爱mmm 2020-03-30 11:56:10 0 浏览量 回答数 0

回答

生命周期:加载和实例化Servlet我们来看一下Tomcat是如何加载的: 1. 如果已配置自动装入选项,则在启动时自动载入。 2. 在服务器启动时,客户机首次向Servlet发出请求。 3. 重新装入Servlet时。 当启动Servlet容器时,容器首先查找一个配置文件web.xml,这个文件中记录了可以提供服务的Servlet。每个Servlet被指定一个Servlet名,也就是这个Servlet实际对应的Java的完整class文件名。Servlet容器会为每个自动装入选项的Servlet创建一个实例。所以,每个Servlet类必须有一个公共的无参数的构造器。 初始化 当Servlet被实例化后,Servlet容器将调用每个Servlet的init方法来实例化每个实例,执行完init方法之后,Servlet处于“已初始化”状态。所以说,一旦Servlet被实例化,那么必将调用init方法。通过Servlet在启动后不立即初始化,而是收到请求后进行。在web.xml文件中用<load-on-statup> ...... </load-on-statup>对Servlet进行预先初始化。 初始化失败后,执行init()方法抛出ServletException异常,Servlet对象将会被垃圾回收器回收,当客户端第一次访问服务器时加载Servlet实现类,创建对象并执行初始化方法。 请求处理 Servlet 被初始化以后,就处于能响应请求的就绪状态。每个对Servlet 的请求由一个Servlet Request 对象代表。Servlet 给客户端的响应由一个Servlet Response对象代表。对于到达客户机的请求,服务器创建特定于请求的一个“请求”对象和一个“响应”对象。调用service方法,这个方法可以调用其他方法来处理请求。 Service方法会在服务器被访问时调用,Servlet对象的生命周期中service方法可能被多次调用,由于web-server启动后,服务器中公开的部分资源将处于网络中,当网络中的不同主机(客户端)并发访问服务器中的同一资源,服务器将开设多个线程处理不同的请求,多线程同时处理同一对象时,有可能出现数据并发访问的错误。 另外注意,多线程难免同时处理同一变量时(如:对同一文件进行写操作),且有读写操作时,必须考虑是否加上同步,同步添加时,不要添加范围过大,有可能使程序变为纯粹的单线程,大大削弱了系统性能;只需要做到多个线程安全的访问相同的对象就可以了。 卸载Servlet 当服务器不再需要Servlet实例或重新装入时,会调用destroy方法,使用这个方法,Servlet可以释放掉所有在init方法申请的资源。一个Servlet实例一旦终止,就不允许再次被调用,只能等待被卸载。 Servlet一旦终止,Servlet实例即可被垃圾回收,处于“卸载”状态,如果Servlet容器被关闭,Servlet也会被卸载,一个Servlet实例只能初始化一次,但可以创建多个相同的Servlet实例。如相同的Servlet可以在根据不同的配置参数连接不同的数据库时创建多个实例。 各个方法:init()方法 在Servlet的生命周期中,仅执行一次init()方法,它是在服务器装入Servlet时执行的,可以配置服务器,以在启动服务器或客户机首次访问Servlet时装入Servlet。无论有多少客户机访问Servlet,都不会重复执行init(); service()方法 它是Servlet的核心,每当一个客户请求一个HttpServlet对象,该对象的Service()方法就要调用,而且传递给这个方法一个“请求”(ServletRequest)对象和一个“响应”(ServletResponse)对象作为参数。在HttpServlet中已存在Service()方法。默认的服务功能是调用与HTTP请求的方法相应的do功能。 destroy()方法 仅执行一次,在服务器端停止且卸载Servlet时执行该方法,有点类似于C++的delete方法。一个Servlet在运行service()方法时可能会产生其他的线程,因此需要确认在调用destroy()方法时,这些线程已经终止或完成。 下面来谈谈Servlet的生命周期,Servlet的生命周期是由Servlet容器来控制的,它始于装入Web服务器的内存时,并在终止或重新装入Servlet时结束。这项操作一般是动态执行的。然而,Server通常会提供一个管理的选项,用于在Server启动时强制装载和初始化特定的Servlet。 在代码中,Servlet生命周期由接口javax.servlet.Servlet定义。所有的Java Servlet 必须直接或间接地实现javax.servlet.Servlet接口,这样才能在Servlet Engine上运行。javax.servlet.Servlet接口定义了一些方法,在Servlet 的生命周期中,这些方法会在特定时间按照一定的顺序被调用。
小川游鱼 2019-12-02 01:50:40 0 浏览量 回答数 0

回答

准备工作 使用 BatchCompute-cli 命令行工具,您可以快速提交作业,可以很方便的管理作业和集群。 注意:本工具只在 python2.7, 3.4, 3.5 版本测试通过,其他python版本慎用。 提交作业 1. 提交作业 (1) 最简单的作业 如果您已经按照准备工作里的步骤配置了默认镜像、实例类型和网络类型,可以通过以下的简单命令提交一个作业。 bcs sub "echo 123" # 提交一个单任务作业,运行: echo 123 如果您没有对命令行工具进行过默认配置,需要在提交的时候指定更多的选项。 bcs sub "echo 123" -t ecs.sn1ne.large -i img-ubuntu-vpc --vpc_cidr_block 192.168.0.0/16 文档的其余示例假设您已经执行了默认的配置步骤。 (2) 提交一个python脚本作业 bcs sub "python test.py" -p ./test.py # -p 表示在作业提交前,将 test.py 打包到 worker.tar.gz,然后上传到OSS. (3) 提交一个目录(多文件)的作业 一般这种情况:src目录下有多个文件, 如: src |-- test.py |-- dep.py 而 test.py 需要依赖dep.py, 则可以将整个目录一起打包 bcs sub "python test.py" -p ./src/ # 将src目录下的所有文件打包到 worker.tar.gz, 然后上传到OSS,再提交作业 当然,您也可以一次指定多个文件(逗号隔开): cd src #进入 src 目录 bcs sub "python test.py" -p test.py,dep.py # 将这个2个文件打包到 worker.tar.gz 如果您没有进入src目录, 则需要这样提交: bcs sub "python test.py" -p src/test.py,src/dep.py # 将这个2个文件打包到 worker.tar.gz 然后您可以使用命令查看worker.tar.gz的内容: tar -tvf worker.tar.gz 应该是这样的: test.py dep.py (4) 使用挂载任务程序的方式提交作业 如果我把 test.py 上传到 oss://mybucket/test/test.py,我可以把oss://mybucket/test/ 挂载到VM的本地目录如: /home/admin/test/, 然后我就可以使用 “python /home/admin/test/test.py” 命令运行了。 这么提交即可: bcs sub "python /home/admin/test/test.py" -r oss://mybucket/test/:/home/admin/test/ 其中参数 -r oss://mybucket/test/:/home/admin/test/ ,表示只读挂载,将oss://mybucket/test/ 挂载到 /home/admin/test/. 这样就无需打包成 worker.tar.gz了。 更多提交作业的信息请用: bcs sub -h 查看帮助 其他技巧 (1) 挂载输入数据 假如我的数据已经上传到 oss://my-bucket/inputs/ 目录下面. bcs sub "python test.py" -p ./src/ -r oss://my-bucket/inputs/:/home/admin/inputs/ -r 表示只读挂载,将 oss目录oss://my-bucket/inputs/ 挂载到 /home/admin/inputs/, 你的程序可以向读取本地文件一样读取/home/admin/inputs/目录下面的文件 所有挂载的目录,不能是系统目录, 如: /bin, /usr等,建议挂载到/home/下面. 如要挂载多个目录,使用英文逗号隔开, 如: -r oss://my-bucket/inputs/:/home/admin/inputs/,oss://my-bucket/inputs2/:/home/admin/inputs2/ 如果是 Windows 镜像,可以使用下面的命令来挂载: bcs sub "python test.py" -p ./src/ -r oss://my-bucket/inputs/:D (2) 程序运行结果使用挂载自动上传 我的程序会将运行的结果写到 /home/admin/outputs/ 目录下,我想把这个目录下面的所有数据上传到oss。 bcs sub "python test.py" -p ./src/ -r oss://my-bucket/inputs/:/home/admin/inputs/ -w oss://my-bucket/outputs/:/home/admin/outputs/ -w 表示可写挂载,写入到这个目录下的数据,将会在程序运行完后,由系统自动上传到对应的 oss 目录下。 所有挂载的目录,不能是系统目录, 如: /bin, /usr等,建议挂载到/home/下面. 如要挂载多个目录,使用英文逗号隔开, 如: -w oss://my-bucket/outputs/:/home/admin/outputs/,oss://my-bucket/outputs2/:/home/admin/outputs2/ (3) 使用自定义镜像和实例类型 bcs sub "python test.py" -p ./src/ -c img=img-ubuntu-vpc:type=ecs.sn1ne.large -c 表示使用集群,后面可以指定集群ID,也可以指定AutoCluster配置。 其中AutoCluster配置格式如:img=${ImageId}:type=${InstanceType}。 img=img-ubuntu-vpc 表示使用镜像,您也可以指定自定义镜像。 type=ecs.sn1ne.large 表示使用实例类型,可以用bcs it查看支持的实例类型列表。 可以只指定-c img=${ImageId} 或者只指定 -c type=${InstanceType}, 不指定则使用使用默认镜像和默认实例类型。 (4) 使用集群 bcs sub "python test.py" -p ./src/ -c cls-xxxxxxx -c cls-xxxxxxx 表示使用集群ID cls-xxxxxxx 更多请看如何使用集群. (5) 使用Docker bcs sub "python test.py" -p ./src/ --docker myubuntu@oss://my-bucket/dockers/ myubuntu 是 localhost:5000/myubuntu 的简写, oss://my-bucket/dockers/ 表示oss docker 镜像仓库的路径。 有关如何使用Docker的详细信息请参考使用 docker。 (6) 自定义磁盘 bcs sub "python test.py" --disk system:cloud_efficiency:50,data:cloud_efficiency:200 只在使用AutoCluster时有效, 支持系统盘配置和一块数据盘(可选)的配置, 使用方法如: —disk system:cloud_efficiency:40,data:cloud_efficiency:50:/home/disk1, 中间用逗号隔开。也可以只指定系统盘,或只指定数据盘。如:—disk system:cloud_efficiency:40 默认只挂载一个系统盘,大小为40GB。 系统盘配置格式: system:< cloud_efficiency|cloud_ssd>:<40-500>, 举例: system:cloud_efficiency:40, 表示系统盘挂载40GB的高效云盘。 数据盘配置格式: data:< cloud_efficiency|cloud_ssd>:<5-2000>:,举例: data:cloud_ssd:50:/home/disk1, 表示挂载一个50GB的SSD云盘作为数据盘, Windows下只能挂载到驱动,如挂载到E盘: data:cloud_ssd:50:E. 注意:对于bcs开头的老专有实例,磁盘类型请使用ephemeral,数据盘大小的取值范围限制为:[5-1024]GB)。 查看作业 查看我的作业列表 bcs job # 查看作业列表, 或者使用简写 bcs j joblist 所有的命令都可以在后面加 -h 查看帮助, 如: bcs j -h 2. 查看作业详情 bcs j 1 # 查看列表中第1个作业详情 注意: 凡是使用序号代替ID的命令,都要在获取列表之后运行,因为获取列表后才缓存序号和ID的对应关系 jobdetail 当然,你也可以使用 bcs j job-00000000573590DB0000224F00000107,效果同 bcs j 1。 3. 查看任务详情 bcs j 1 1 # 查看作业的第1个任务详情 taskdetail 当然,你也可以使用 bcs j job-00000000573590DB0000224F00000107 task,效果同 bcs j 1 1。 4. 查看实例详情 bcs j 1 1 0 # 查看作业的第1个任务的instanceId为0的实例详情,和日志 instancedetail 当然,你也可以使用 bcs j job-00000000573590DB0000224F00000107 task 0,效果同 bcs j 1 1 0。 5. 查看作业日志 bcs log 1 # 查看作业日志 joblog 当然,你也可以使用 bcs log job-00000000573590DB0000224F00000107,效果同 bcs log 1。 多任务支持 单个任务支持 job.cfg 内容: [taskname] cmd=python test.py job_name=demo cluster=img=img-ubuntu:type=ecs.sn1.medium description=test job nodes=1 pack=./src/ read_mount=oss://bucket/input/:/home/input/ write_mount=oss://bucket/output/:/home/output/ 这个配置文件含有一个section: [taskname], 这个taskname将作为task名提交。 除了cmd 和 job_name 外,其他的选项, 都是通过 bcs sub -h 看到的长选项名称, 等同于使用命令—${option}。 2. 多任务支持 config 文件也可以配置多个任务,可以指定任务间依赖关系。 job.cfg 内容: [DEFAULT] job_name=log-count description=demo force=True deps=split->count;count->merge #下面是任务公共配置 env=public_key:value,key2:value2 read_mount=oss://bucket/input/:/home/input/ write_mount=oss://bucket/output/:/home/output/ pack=./src/ [split] cmd=python split.py cluster=img=img-ubuntu:type=ecs.sn1.medium nodes=1 [count] cmd=python count.py cluster=img=img-ubuntu:type=ecs.sn1.medium nodes=3 [merge] cmd=python merge.py cluster=img=img-ubuntu:type=ecs.sn1.medium nodes=1 [DEFAULT] section中指定job级别的配置, 其他section指定task配置, 其他section名为task名 配置项优先级: 直接在命令行中的—${option}; 优先级最高,其次task section中指定的,最后是DEFAULT section中指定的。 env, read_mount, write_mount, mount 这4个配置项, 可merge, 其他配置项遇到高优先级直接被覆盖 deps=split->count;count->merge 指定依赖, split任务运行完成后,再运行count,count运行完成后,再运行merge. cluster配置用的img和type,不同region支持是不一样的,请根据当前region具体情况设置。 (1) 关于deps 如果DAG如下: DAG 则deps配置: deps=split->count1,count2;count1->merge;count2->merge 每个dep是一对多的形式: task1->task2,taks3 多个task之间用逗号隔开,多个dep用分号隔开。 (2) 关于 pack ./src/ |-- split.py |-- ... 如果指定目录:pack=./src/, 则打包src下面的所有文件到 worker.tar.gz, 指定cmd时,需要从 ./src/目录下开始指定,如: cmd=python split.py 如果指定文件: pack=./src/split.py, 则只打包文件到worker.tar.gz, 指定cmd时,只需要指定文件名, 如: cmd=python split.py pack可以在[DEFAULT]这个section中配置,也可以在每个task中配置, 当然也可以在命令行中指定。 (3) 关于 mount read_mount 为只读挂载,将oss目录挂载到运行程序的虚拟机的文件系统中,linux可以挂载为一个目录,window下只能挂载为一个Driver,如:”E:”。 如果挂载多个,可以使用英文逗号隔开,如:read_mount=oss://bucket/input/:/home/input/,oss://bucket/input2/:/home/input2/。write_mount和mount也是如此。 write_mount 为可写挂载,将oss目录映射到运行程序的虚拟机的目录,只能映射为一个目录,如果这个目录不存在,需要程序创建一下。写入到这个目录的所有文件将会被上传到相应的oss目录。 mount可以用于 NAS 的挂载,比如: mount=nas://xxxxxx-yyy50.cn-shenzhen.nas.aliyuncs.com:/:/home/mnt/:true vpc_id=vpc-xxxxxxxxxxyyyyyy vpc_cidr_block=192.168.0.0/16 注意:使用 NAS 时要指定 vpc_id 和 cidr_block。 这里mount信息中的 true/false 指的是是否支持可写。 (4) 关于cluster 有2种格式: AutoCluster格式: cluster=img= :type= AutoCluster指定任务运行时会自动创建相应配置的集群,运行完成后自动释放掉。 Cluster格式: cluster= 运行:bcs c 可以查看我的集群,如果没有,可以自行创建。 如: bcs cc -i -t -n 3 -n 3 表示期望启动3台虚拟机来运行程序 -i img-id 指定image ID -t instance-type 指定实例类型,可以使用 bcs it 查看可用的实例类型 其他选项可以使用 bcs cc -h 查看说明。 使用集群可以大大缩短作业启动时间,但是由于集群是一直运行着的,会一直计费,请自行权衡。 (5) 关于docker 格式如: docker=myubuntu@oss://bucket/dockers/ 使用docker,需要支持docker的ImageId才能运行成功。如果你没有指定cluster,默认的imageId是支持Docker的,或者你显式指定也行,或者使用clusterId,但是这个cluster的ImageId也要支持docker才行。 这里的myubuntu全名为:localhost:5000/myubuntu,制作docker镜像的时候,前缀必须为localhost:5000/, 因此这里可以省略掉前缀。后面的oss目录,是OSS私有docker镜像仓库目录,详情请看如何使用docker。 (6) 关于nodes nodes 表示指定使用多少台虚拟机运行任务程序。 (7) 关于force force 为 True,表示如果某台虚拟机运行程序出错,整个作业不会失败,继续运行。为False,则整个作业失败。默认为False。 多实例并发 1. 说明: 本例子将启动一个作业(job),该作业包含一个任务(task), 该任务将启动2个instance,并行在2个VM中运行。 2个VM中运行的程序是一样的,都是任务sum中指定的命令”python sum.py”, 程序中使用环境变量中的 BATCH_COMPUTE_DAG_INSTANCE_ID 获取InstanceId, 用来区分Input数据。 InstanceId是从0开始递增的。 每个VM中任务程序处理完 ${InstanceId}-input.txt 数据后,将结果写入到 /home/outputs/${InstanceId}-output.txt 文件, 系统会自动上传到对应的oss目录:oss://your-bucket/sum/outputs/ 目录下。 当2个VM中的程序都运行完成后,任务结束,作业结束。 例子可以在这里下载。 上传数据文件到OSS 数据文件在 data 目录下: 0-input.txt和1-input.txt。 0-input.txt的内容: 1 20 45 1-input.txt的内容: 5 85 103 将 0-input.txt和1-input.txt 上传到: oss://your-bucket/sum/inputs/0-input.txt oss://your-bucket/sum/inputs/1-input.txt 可以使用下面的命令上传: cd data bcs oss upload 0-input.txt oss://your-bucket/sum/inputs/ bcs oss upload 1-input.txt oss://your-bucket/sum/inputs/ 查看是否上传成功 bcs oss ls oss://your-bucket/sum/inputs/ 3. 启动任务 bcs sub --file job.cfg 4. 查看结果 结果数据在 oss://your-bucket/sum/outputs/中。 可以用下面的命令查看: bcs o ls oss://your-bucket/sum/outputs/ bcs o cat oss://your-bucket/sum/outputs/0-output.txt bcs o cat oss://your-bucket/sum/outputs/1-output.txt 使用集群 使用默认的AutoCluster方式提交作业,作业等待时间可能较长。 而如果使用集群的方式,可以避免等待,大大缩短等待时间。 详细介绍,请看使用AutoCluster还是Cluster。 查看我的集群 bcs cluster # 查看我的集群列表,或者简写 bcs c创建集群 (1) 创建一个默认配置的集群 bcs cc my-cluster 默认配置:使用默认镜像和默认实例类型 ,1台机器。 (2) 创建多台机器 bcs cc my-cluster -n 3 -i img-ubuntu -t ecs.sn1.medium -n 3 表示 3台机器 -i img-ubuntu 表示使用 img-ubuntu镜像,更多镜像请看这里 -t ecs.sn1.medium 表示使用 ecs.sn1.medium 实例类型(运行:bcs it 可以查看更多)删除集群 bcs dc cls-xxxxxxx 其他请加 -h 查看帮助
1934890530796658 2020-03-30 14:54:45 0 浏览量 回答数 0

阿里云域名特惠专场,热门域名1元抢购!

全网低价特惠,顶级域名低至1元,更有96元/年服务器限时抢购!

回答

为什么你的代码是一个单体? 除了已经实现了微前端的应用之外,所有前端应用本质上都是单一的应用。原因是如果您正在使用 React 库进行开发,并且如果您有两个团队,则两个团队都应该使用相同的React 库,并且两个团队应该在部署时保持同步,并且在代码合并期间始终会发生冲突。它们没有完全分离,很可能它们维护着相同的仓库并具有相同的构建系统。单体应用的退出被标志为微服务的出现。但是它适用于后端! 什么是微服务? 对于微服务,一般而言最简单的解释是,它是一种开发技术,允许开发人员为平台的不同部分进行独立部署,而不会损害其他部分。独立部署的能力允许他们构建孤立或松散耦合的服务。为了使这个体系结构更稳定,有一些规则要遵循,可以总结如下:每个服务应该只有一个任务,它应该很小。所以负责这项服务的团队应该很小。关于团队和项目的规模,James Lewis 和 Martin Fowler 在互联网上做出的最酷解释之一如下: 在我们与微服务从业者的对话中,我们看到了一系列服务规模。报道的最大规模遵循亚马逊关于Two Pizza Team的概念(即整个团队可以由两个比萨饼供给),意味着不超过十几个人。在规模较小的规模上,我们已经看到了一个由六人组成的团队支持六项服务的设置。 我画了一个简单的草图,为整体和微服务提供了直观的解释: 从上图可以理解,微服务中的每个服务都是一个独立的应用,除了UI。UI仍然是一体的!当一个团队处理所有服务并且公司正在扩展时,前端团队将开始苦苦挣扎并且无法跟上它,这是这种架构的瓶颈。 除了瓶颈之外,这种架构也会导致一些组织问题。假设公司正在发展并将采用需要 跨职能 小团队的敏捷开发方法。在这个常见的例子中,产品所有者自然会开始将故事定义为前端和后端任务,而 跨职能 团队将永远不会成为真正的 跨职能 部门。这将是一个浅薄的泡沫,看起来像一个敏捷的团队,但它将在内部分开。关于管理这种团队的更多信息将是一项非常重要的工作。在每个计划中,如果有足够的前端任务或者sprint中有足够的后端任务,则会有一个问题。为了解决这里描述的所有问题和许多其他问题,几年前出现了微前端的想法并且开始迅速普及。 解决微服务中的瓶颈问题:Micro Frontends 解决方案实际上非常明显,采用了多年来为后端服务工作的相同原则:将前端整体划分为小的UI片段。但UI与服务并不十分相似,它是最终用户与产品之间的接口,应该是一致且无缝的。更重要的是,在单页面应用时代,整个应用在客户端的浏览器上运行。它们不再是简单的HTML文件,相反,它们是复杂的软件,达到了非常复杂的水平。现在我觉得微型前端的定义是必要的: Micro Frontends背后的想法是将网站或Web应用视为独立团队拥有的功能组合。每个团队都有一个独特的业务或任务领域,做他们关注和专注的事情。团队是跨职能的,从数据库到用户界面开发端到端的功能。(micro-frontends.org) 根据我迄今为止的经验,对于许多公司来说,直接采用上面提出的架构真的很难。许多其他人都有巨大的遗留负担,这使他们无法迁移到新的架构。出于这个原因,更柔软的中间解决方案更加灵活,易于采用和安全迁移至关重要。在更详细地概述了体系结构后,我将尝试提供一些体系结构的洞察,该体系结构确认了上述提议并允许更灵活的方式。在深入了解细节之前,我需要建立一些术语。 整体结构和一些术语 让我们假设我们通过业务功能垂直划分整体应用结构。我们最终会得到几个较小的应用,它们与单体应用具有相同的结构。但是如果我们在所有这些小型单体应用之上添加一个特殊应用,用户将与这个新应用进行通信,它将把每个小应用的旧单体UI组合成一个。这个新图层可以命名为拼接图层,因为它从每个微服务中获取生成的UI部件,并为最终用户组合成一个无缝 UI,这将是微前端的最直接实现朗 为了更好地理解,我将每个小型单体应用称为微应用,因为它们都是独立的应用,而不仅仅是微服务,它们都有UI部件,每个都代表端到端的业务功能。 众所周知,今天的前端生态系统功能多样,而且非常复杂。因此,当实现真正的产品时,这种直接的解决方案还不够。 要解决的问题 虽然这篇文章只是一个想法,但我开始使用Reddit讨论这个想法。感谢社区和他们的回复,我可以列出一些需要解决的问题,我将尝试逐一描述。 当我们拥有一个完全独立的独立微应用时,如何创建无缝且一致的UI体验? 好吧,这个问题没有灵丹妙药的答案,但其中一个想法是创建一个共享的UI库,它也是一个独立的微应用。通过这种方式,所有其他微应用将依赖于共享的UI库微应用。在这种情况下,我们刚刚创建了一个共享依赖项, 我们就杀死了独立微应用的想法。 另一个想法是在根级共享CSS自定义变量( CSS custom variables )。此解决方案的优势在于应用之间的全局可配置主题。 或者我们可以简单地在应用团队之间共享一些SASS变量和混合。这种方法的缺点是UI元素的重复实现,并且应该对所有微应用始终检查和验证类似元素的设计的完整性。 我们如何确保一个团队不会覆盖另一个团队编写的CSS? 一种解决方案是通过CSS选择器名称进行CSS定义,这些名称由微应用名称精心选择。通过将该范围任务放在拼接层上将减少开发开销,但会增加拼接层的责任。 另一种解决方案可以是强制每个微应用成为自定义Web组件(custom web component)。这个解决方案的优点是浏览器完成了范围设计,但需要付出代价:使用shadow DOM进行服务器端渲染几乎是不可能的。此外,自定义元素没有100%的浏览器支持,特别是IE。 我们应该如何在微应用之间共享全局信息? 这个问题指出了关于这个主题的最关注的问题之一,但解决方案非常简单:HTML 5具有相当强大的功能,大多数前端开发人员都不知道。例如,自定义事件(custom events) 就是其中之一,它是在微应用中共享信息的解决方案。 或者,任何共享的pub-sub实现或T39可观察的实现都可以实现。如果我们想要一个更复杂的全局状态处理程序,我们可以实现共享的微型Redux,通过这种方式我们可以实现更多的相应式架构。 如果所有微应用都是独立应用,我们如何进行客户端路由? 这个问题取决于设计的每个实现, 所有主要的现代框架都通过使用浏览器历史状态在客户端提供强大的路由机制, 问题在于哪个应用负责路由以及何时。 我目前的实用方法是创建一个共享客户端路由器,它只负责顶级路由,其余路由器属于相应的微应用。假设我们有 /content/:id 路由定义。共享路由器将解析 /content,已解析的路由将传递到ContentMicroApp。ContentMicroApp是一个独立的服务器,它将仅使用 /:id 进行调用。 我们必须是服务器端渲染,但是有可能使用微前端吗? 服务器端呈现是一个棘手的问题。如果你正在考虑iframes缝合微应用然后忘记服务器端渲染。同样,拼接任务的Web组件也不比iframe强大。但是,如果每个微应用能够在服务器端呈现其内容,那么拼接层将仅负责连接服务器端的HTML片段。 与传统环境集成至关重要!但是怎么样? 为了整合遗留系统,我想描述我自己的策略,我称之为“ 渐进式入侵 ”。 首先,我们必须实现拼接层,它应该具有透明代理的功能。然后我们可以通过声明一个通配符路径将遗留系统定义为微应用:LegacyMicroApp 。因此,所有流量都将到达拼接层,并将透明地代理到旧系统,因为我们还没有任何其他微应用。 下一步将是我们的 第一次逐步入侵 :我们将从LegacyMicroApp中删除主要导航并用依赖项替换它。这种依赖关系将是一个使用闪亮的新技术实现的微应用:NavigationMicroApp 。 现在,拼接层将每个路径解析为 Legacy Micro App ,它将依赖关系解析为 Navigation MicroApp ,并通过连接这两个来为它们提供服务。 然后通过主导航遵循相同的模式来为引导下一步。 然后我们将继续从Legacy MicroApp中获取逐步重复以上操作,直到没有任何遗漏。 如何编排客户端,这样我们每次都不需要重新加载页面? 拼接层解决了服务器端的问题,但没有解决客户端问题。在客户端,在将已粘贴的片段作为无缝HTML加载后,我们不需要每次在URL更改时加载所有部分。因此,我们必须有一些异步加载片段的机制。但问题是,这些片段可能有一些依赖关系,这些依赖关系需要在客户端解决。这意味着微前端解决方案应提供加载微应用的机制,以及依赖注入的一些机制。 根据上述问题和可能的解决方案,我可以总结以下主题下的所有内容: 客户端 编排路由隔离微应用应用之间通信微应用UI之间的一致性 服务端 服务端渲染路由依赖管理 灵活、强大而简单的架构 所以,这篇文章还是很值得期待的!微前端架构的基本要素和要求终于显现! 在这些要求和关注的指导下,我开始开发一种名为microfe的解决方案。在这里,我将通过抽象的方式强调其主要组件来描述该项目的架构目标。 它很容易从客户端开始,它有三个独立的主干结构:AppsManager, Loader, Router 和一个额外的MicroAppStore。 AppsManager AppsManager 是客户端微应用编排的核心。AppsManager的主要功能是创建依赖关系树。当解决了微应用的所有依赖关系时,它会实例化微应用。 Loader 客户端微应用编排的另一个重要部分是Loader。加载器的责任是从服务器端获取未解析的微应用。 Router 为了解决客户端路由问题,我将 Router 引入了 microfe。与常见的客户端路由器不同,microf 的功能有限,它不解析页面而是微应用。假设我们有一个URL /content/detail/13 和一个ContentMicroApp。在这种情况下,microfe 将URL解析为 /content/,它将调用ContentMicroApp /detail/13 URL部分。 MicroAppStore 为了解决微应用到微应用客户端的通信,我将MicroAppStore引入了 microfe。它具有与Redux库类似的功能,区别在于:它对异步数据结构更改和reducer 声明更灵活。 服务器端部分在实现上可能稍微复杂一些,但结构更简单。它只包含两个主要部分 StitchingServer 和许多MicroAppServer。 MicroAppServer MicroAppServer 的最小功能可以概括为 init 和 serve。 虽然 MicroAppServer 首先启动它应该做的是使用 微应用声明 调用 SticthingServer 注册端点,该声明定义了 MicroAppServer 的微应用 依赖关系, 类型 和 URL架构。我认为没有必要提及服务功能,因为没有什么特别之处。 StitchingServer StitchingServer 为 MicroAppServers 提供注册端点。当 MicroAppServer 将自己注册到 StichingServer 时,StichingServer 会记录MicroAppServer 的声明。 稍后,StitchingServer 使用声明从请求的URL解析 MicroAppServers。 解析M icroAppServer 及其所有依赖项后,CSS,JS和HTML中的所有相对路径都将以相关的 MicroAppServer 公共URL为前缀。另外一步是为CSS选择器添加一个唯一的 MicroAppServer 标识符,以防止客户端的微应用之间发生冲突。 然后 StitchingServer 的主要职责就是:从所有收集的部分组成并返回一个无缝的HTML页面。 其他实现一览 甚至在2016年被称为微前端之前,许多大公司都试图通过 BigPipe 来解决Facebook等类似问题。如今这个想法正在获得验证。不同规模的公司对该主题感兴趣并投入时间和金钱。例如,Zalando开源了其名为Project Mosaic的解决方案。我可以说,微型和 Project Mosaic.遵循类似的方法,但有一些重要的区别。虽然microfe采用完全分散的路由定义来增强每个微应用的独立性,但Project Mosaic更喜欢每条路径的集中路由定义和布局定义。通过这种方式,Project Mosaic可以实现轻松的A/B测试和动态布局生成。 对于该主题还有一些其他方法,例如使用iframe作为拼接层,这显然不是在服务器端而是在客户端。这是一个非常简单的解决方案,不需要太多的服务器结构和DevOps参与。这项工作只能由前端团队完成,因此可以减轻公司的组织负担,同时降低成本。 已经有一个框架叫做 single-spa。该项目依赖于每个应用的命名约定来解析和加载微应用。容易掌握想法并遵循模式。因此,在您自己的本地环境中尝试该想法可能是一个很好的初步介绍。但是项目的缺点是你必须以特定的方式构建每个微应用,以便他们可以很好地使用框架。 最后的想法 我相信微前端话题会更频繁地讨论。如果该主题能够引起越来越多公司的关注,它将成为大型团队的事实发展方式。在不久的将来,任何前端开发人员都可以在这个架构上掌握一些见解和经验,这真的很有用。 关于本文 译者:@Vincent.W 译文:https://zhuanlan.zhihu.com/p/82965940 作者:@onerzafer 原文:https://hackernoon.com/understanding-micro-frontends-b1c11585a297 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 阿里云开发者社区
茶什i 2020-01-06 17:57:24 0 浏览量 回答数 0

问题

MathML 介绍:报错

MathML 是一个 W3C 推荐标准,旨在为标记数学表达式定义一个 XML 词汇表。版本 1 作为一个 W3C 推荐标准发布于 1998 年,就在 XML 规范发布后不久。MathML 已作为推荐标准发布的另外...
kun坤 2020-06-08 11:09:17 2 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板