• 关于

    高稳定云原生计算

    的搜索结果

问题

【百问百答】《云原生架构白皮书》(下)

291阿里巴是如何看待架构企业战略视角? 292企业战略中业务战略与 IT 战略之间的关系是什么? 293阿里巴是如何看待架构业务发展视角? 294业务连续性诉求主要包括了什么?...
Pony马 2021-01-15 14:47:31 1 浏览量 回答数 0

回答

云服务器(Elastic Compute Service,简称ECS)是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS(Infrastructure as a Service)级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备,让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器,实现计算资源的即开即用和弹性伸缩。阿里云ECS持续提供创新型服务器,解决多种业务需求,助力您的业务发展。 为什么选择云服务器ECS 选择云服务器ECS,您可以轻松构建具有以下优势的计算资源: 无需自建机房,无需采购以及配置硬件设施。 分钟级交付,快速部署,缩短应用上线周期。 快速接入部署在全球范围内的数据中心和BGP机房。 成本透明,按需使用,支持根据业务波动随时扩展和释放资源。 提供GPU和FPGA等异构计算服务器、弹性裸金属服务器以及通用的x86架构服务器。 支持通过内网访问其他阿里云服务,形成丰富的行业解决方案,降低公网流量成本。 提供虚拟防火墙、角色权限控制、内网隔离、防病毒攻击及流量监控等多重安全方案。 提供性能监控框架和主动运维体系。 提供行业通用标准API,提高易用性和适用性。 更多选择理由,请参见云服务器ECS的优势和应用场景。 产品架构 云服务器ECS主要包含以下功能组件: 实例:等同于一台虚拟服务器,内含CPU、内存、操作系统、网络配置、磁盘等基础的计算组件。实例的计算性能、内存性能和适用业务场景由实例规格决定,其具体性能指标包括实例vCPU核数、内存大小、网络性能等。 镜像:提供实例的操作系统、初始化应用数据及预装的软件。操作系统支持多种Linux发行版和多种Windows Server版本。 块存储:块设备类型产品,具备高性能和低时延的特性。提供基于分布式存储架构的云盘、共享块存储以及基于物理机本地存储的本地盘。 快照:某一时间点一块云盘或共享块存储的数据状态文件。常用于数据备份、数据恢复和制作自定义镜像等。 安全组:由同一地域内具有相同保护需求并相互信任的实例组成,是一种虚拟防火墙,用于设置实例的网络访问控制。 网络: 专有网络(Virtual Private Cloud):逻辑上彻底隔离的云上私有网络。您可以自行分配私网IP地址范围、配置路由表和网关等。 经典网络:所有经典网络类型实例都建立在一个共用的基础网络上。由阿里云统一规划和管理网络配置。 更多功能组件详情,请参见云服务器ECS产品详情页。 以下为云服务器ECS的产品组件架构图,图中涉及的功能组件的详细介绍请参见相应的帮助文档。whatIsECS 产品定价 云服务器ECS支持包年包月、按量付费、预留实例券、抢占式实例等多种账单计算模式。更多详情,请参见计费概述和云产品定价页。 管理工具 通过注册阿里云账号,您可以在任何地域下,通过阿里云提供的以下途径创建、使用或者释放云服务器ECS: ECS管理控制台:具有交互式操作的Web服务页面。关于管理控制台的操作,请参见常用操作导航。 ECS API:支持GET和POST请求的RPC风格API。关于API说明,请参见API参考。以下为调用云服务器ECS API的常用开发者工具: 命令行工具CLI:基于阿里云API建立的灵活且易于扩展的管理工具。您可基于命令行工具封装阿里云的原生API,扩展出您需要的功能。 OpenAPI Explorer:提供快速检索接口、在线调用API和动态生成SDK示例代码等服务。 阿里云SDK:提供Java、Python、PHP等多种编程语言的SDK。 资源编排(Resource Orchestration Service):通过创建一个描述您所需的所有阿里云资源的模板,然后资源编排将根据模板,自动创建和配置资源。 运维编排服务(Operation Orchestration Service):自动化管理和执行运维任务。您可以在执行模板中定义执行任务、执行顺序、执行输入和输出等,通过执行模板达到自动化完成运维任务的目的。 Terraform:能够通过配置文件在阿里云以及其他支持Terraform的云商平台调用计算资源,并对其进行版本控制的开源工具。 阿里云App:移动端类型的管理工具。 Alibaba Cloud Toolkit:阿里云针对IDE平台为开发者提供的一款插件,用于帮助您高效开发并部署适合在云端运行的应用。 部署建议 您可以从以下维度考虑如何启动并使用云服务器ECS: 地域和可用区 地域指阿里云的数据中心,地域和可用区决定了ECS实例所在的物理位置。一旦成功创建实例后,其元数据(仅专有网络VPC类型ECS实例支持获取元数据)将确定下来,并无法更换地域。您可以从用户地理位置、阿里云产品发布情况、应用可用性、以及是否需要内网通信等因素选择地域和可用区。例如,如果您同时需要通过阿里云内网使用云数据库RDS,RDS实例和ECS实例必须处于同一地域中。更多详情,请参见地域和可用区。 高可用性 为保证业务处理的正确性和服务不中断,建议您通过快照实现数据备份,通过跨可用区、部署集、负载均衡(Server Load Balancer)等实现应用容灾。 网络规划 阿里云推荐您使用专有网络VPC,可自行规划私网IP,全面支持新功能和新型实例规格。此外,专有网络VPC支持多业务系统隔离和多地域部署系统的使用场景。更多详情,请参见专有网络(Virtual Private Cloud)。 安全方案 您可以使用云服务器ECS的安全组,控制ECS实例的出入网访问策略以及端口监听状态。对于部署在云服务器ECS上的应用,阿里云为您提供了免费的DDoS基础防护和基础安全服务,此外您还可以使用阿里云云盾,例如: 通过DDoS高防IP保障源站的稳定可靠。更多详情,请参见DDoS高防IP文档。 通过云安全中心保障云服务器ECS的安全。更多详情,请参见云安全中心文档。 相关服务 使用云服务器ECS的同时,您还可以选择以下阿里云服务: 根据业务需求和策略的变化,使用弹性伸缩(Auto Scaling)自动调整云服务器ECS的数量。更多详情,请参见弹性伸缩。 使用专有宿主机(Dedicated Host)部署ECS实例,可让您独享物理服务器资源、降低上云和业务部署调整的成本、满足严格的合规和监管要求。更多详情,请参见专有宿主机DDH。 使用容器服务Kubernetes版在一组云服务器ECS上通过Docker容器管理应用生命周期。更多详情,请参见容器服务Kubernetes版。 通过负载均衡(Server Load Balancer)对多台云服务器ECS实现流量分发的负载均衡目的。更多详情,请参见负载均衡。 通过云监控(CloudMonitor)制定实例、系统盘和公网带宽等的监控方案。更多详情,请参见云监控。 在同一阿里云地域下,采用关系型云数据库(Relational Database Service)作为云服务器ECS的数据库应用是典型的业务访问架构,可极大降低网络延时和公网访问费用,并实现云数据库RDS的最佳性能。云数据库RDS支持多种数据库引擎,包括MySQL、SQL Server、PostgreSQL、PPAS和MariaDB。更多详情,请参见关系型云数据库。 在云市场获取由第三方服务商提供的基础软件、企业软件、网站建设、代运维、云安全、数据及API、解决方案等相关的各类软件和服务。您也可以成为云市场服务供应商,提供软件应用及服务。更多详情,请参见云市场文档。 更多方案,请参见阿里云解决方案。
1934890530796658 2020-03-24 14:03:02 0 浏览量 回答数 0

问题

容器服务 发布历史

2017-10: 【新功能】原生Kubernetes支持上线 支持kubernetes 1.8.1。参见 Kubernetes概述。 【新功能】区块链解决方案公测 支持 Hyperledger Fabric。参见 区块链解...
青蛙跳 2019-12-01 21:32:38 622 浏览量 回答数 0

回答

前言 随着计算机技术和 Internet 的日新月异,视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青睐,而在当前, 云计算平台厂商的产品线不断成熟完善, 如果想要搭建视频点播类应用,告别刀耕火种, 直接上云会扫清硬件采购、 技术等各种障碍,以阿里云为例: image 这是一个非常典型的解决方案, 对象存储 OSS 可以支持海量视频存储,采集上传的视频被转码以适配各种终端,CDN 加速终端设备播放视频的速度。此外还有一些内容安全审查需求, 比如鉴黄、鉴恐等。 而在视频点播解决方案中, 视频转码是最消耗计算力的一个子系统,虽然您可以使用云上专门的转码服务,但在很多情况下,您会选择自己搭建转码服务。比如: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? 您有并发处理大量视频的需求。 您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长,自己搭建成本更低。 各种格式的音频转换或者各种采样率自定义、音频降噪等功能 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将它们再迁移到 OSS 上。 如果您的视频处理系统有上述需求,或者您期望实现一个 弹性、高可用、低成本、免运维、灵活支持任意处理逻辑 的视频处理系统,那么本文则是您期待的最佳实践方案。 Serverless 自定义音视频处理 在介绍具体方案之前, 先介绍两款产品: 函数计算 :阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询、性能监控、报警等功能。 函数工作流:函数工作流(Function Flow,以下简称 FnF)是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序,分支,并行等方式来编排分布式任务,FnF 会按照设定好的步骤可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 函数计算可靠的执行任意逻辑, 逻辑可以是利用 FFmpeg 对视频任何处理操作, 也可以更新视频 meta 数据到数据库等。函数工作流对相应的函数进行编排, 比如第一步的函数是转码, 第二步的函数是转码成功后,将相应 meta 数据库写入数据库等。 至此,您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求,接下来,本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统,并与传统方案进行性能、成本和工程效率的对比。 Simple 视频处理系统 假设您是对视频进行单纯的处理, 架构方案图如下: image 如上图所示, 用户上传一个视频到 OSS, OSS 触发器自动触发函数执行, 函数调用 FFmpeg 进行视频转码, 并且将转码后的视频保存回 OSS。 OSS 事件触发器, 阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数,当 OSS 系统捕获到指定类型的事件后,会自动调用函数处理。例如,您可以设置函数来处理 PutObject 事件,当您调用 OSS PutObject API 上传视频到 OSS 后,相关联的函数会自动触发来处理该视频。 Simple 视频处理系统示例工程地址 强大的监控系统: 您可以直接基于示例工程部署您的 Simple 音视频处理系统服务, 但是当您想要处理超大视频(比如 test_huge.mov ) 或者对小视频进行多种组合操作的时候, 您会发现函数会执行失败,原因是函数计算的执行环境有最大执行时间为 10 分钟的限制,如果最大的 10 分钟不能满足您的需求, 您可以选择: 对视频进行分片 -> 转码 -> 合成处理, 详情参考:fc-fnf-video-processing, 下文会详细介绍; 联系函数计算团队(钉钉群号: 11721331) 或者提工单: 适当放宽执行时长限制; 申请使用更高的函数内存 12G(8vCPU) 为了突破函数计算执行环境的限制(或者说加快大视频的转码速度), 进行各种复杂的组合操作, 此时引入函数工作流 FnF 去编排函数实现一个功能强大的视频处理工作流系统是一个很好的方案。 视频处理工作流系统 image 如上图所示, 假设用户上传一个 mov 格式的视频到 OSS,OSS 触发器自动触发函数执行, 函数调用 FnF,会同时进行 1 种或者多种格式的转码(由您触发的函数环境变量DST_FORMATS 参数控制)。 所以您可以实现如下需求: 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理,比如增加水印处理或者在 after-process 更新信息到数据库等。 当有多个文件同时上传到 OSS,函数计算会自动伸缩, 并行处理多个文件, 同时每次文件转码成多种格式也是并行。 结合 NAS + 视频切片, 可以解决超大视频(大于 3G )的转码, 对于每一个视频,先进行切片处理,然后并行转码切片,最后合成,通过设置合理的切片时间,可以大大加速较大视频的转码速度。 所谓的视频切片,是将视频流按指定的时间间隔,切分成一系列分片文件,并生成一个索引文件记录分片文件的信息 视频处理工作流系统示例工程地址 示例效果: gif 函数计算 + 函数工作流 Serverless 方案 VS 传统方案 卓越的工程效率 自建服务 函数计算 + 函数工作流 Serverless 基础设施 需要用户采购和管理 无 开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 并行&分布式视频处理 需要很强的开发能力和完善的监控系统来保证稳定性 通过 FnF 资源编排即可实现多个视频的并行处理以及单个大视频的分布式处理,稳定性和监控交由云平台 学习上手成本 除了编程语言开发能力和熟悉 FFmpeg 以外,可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码和熟悉 FFmpeg 使用即可 项目上线周期 在具体业务逻辑外耗费大量的时间和人力成本,保守估计大约 30 人天,包括硬件采购、软件和环境配置、系统开发、测试、监控报警、灰度发布系统等 预计 3 人天, 开发调试(2人天)+ 压测观察(1 人天) 弹性伸缩免运维,性能优异 自建服务 函数计算 + 函数工作流 Serverless 弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维,视频处理工作流系统 (FnF + FC) 压测;性能优异, 详情见下面的转码性能表 监控报警查询 ECS 或者容器级别的 metrics 提供更细粒度的 FnF 流程执行以及函数执行情况, 同时可以查询每次函数执行的 latency 和日志等, 更加完善的报警监控机制 函数计算 + 函数工作流 Serverless 方案转码性能表 实验视频为是 89s 的 mov 文件 4K 视频: 4K.mov,云服务进行 mov -> mp4 普通转码需要消耗的时间为 188s, 将这个参考时间记为 T 视频切片时间 FC转码耗时 性能加速百分比 45s 160s 117.5% 25s 100s 188% 15s 70s 268.6% 10s 45s 417.8% 5s 35s 537.1% 性能加速百分比 = T / FC转码耗时 从上表可以看出,设置的视频切片时间越短, 视频转码时间越短, 函数计算可以自动瞬时调度出更多的计算资源来一起完成这个视频的转码, 转码性能优异。 更低的成本 具有明显波峰波谷的视频处理场景(比如只有部分时间段有视频处理请求,其他时间很少甚至没有视频处理请求),选择按需付费,只需为实际使用的计算资源付费。 没有明显波峰波谷的视频处理场景,可以使用预付费(包年包月),成本仍然具有竞争力。 函数计算成本优化最佳实践文档。 假设有一个基于 ECS 搭建的视频转码服务,由于是 CPU 密集型计算, 因此在这里将平均 CPU 利用率作为核心参考指标对评估成本,以一个月为周期,10 台 C5 ECS 的总计算力为例, 总的计算量约为 30% 场景下, 两个解决方案 CPU 资源利用率使用情况示意图大致如下: image 由上图预估出如下计费模型: 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5 ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元 函数计算按量付费占整个计算量的占比 <= 10%,费用约为 3×864×10% = 259.2 元,(3G 规格的函数满负载跑满一个月费用为:0.00011108×3×30×24×3600 = 863.8,详情查看计费) ITEM 平均CPU利用率 计算费用 总计 函数计算组合付费 >=80% 998(246.27×3+259.2) <= 998 按峰值预留ECS <=30% 2190(10*219) >=2190 在这个模型预估里面,可以看出 FC 方案具有很强的成本竞争力,在实际场景中, 基于 ECS 自建的视频转码服务 CPU 利用甚至很难达到 20%, 理由如下: 可能只有部分时间段有视频转码请求 为了用户体验,视频转码速度有一定的要求,可能一个视频转码就需要 10 台 ECS 并行处理来转码, 因此只能预备很多 ECS 因此,在实际场景中, FC 在视频处理上的成本竞争力远强于上述模型。 即使和云厂商视频转码服务单价 PK, 该方案仍有很强的成本竞争力 我们这边选用点播视频中最常用的两个格式(mp4、flv)之间进行相互转换,经实验验证, 函数内存设置为3G,基于该方案从 mp4 转码为 flv 的费用概览表: 实验视频为是 89s 的 mp4 和 flv 格式的文件视频, 测试视频地址: 480P.mp4 720P.mp4 1080P.mp4 4K.mp4 480P.flv 720P.flv 1080P.flv 4K.flv 测试命令: ffmpeg -i test.flv test.mp4 和 ffmpeg -i test.flv test.mp4 mp4 转 flv: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 889 kb/s 24 11.2s 0.003732288 0.032 88.3% 高清 1280720 1963 kb/s 24 20.5s 0.00683142 0.065 89.5% 超清 19201080 3689 kb/s 24 40s 0.0133296 0.126 89.4% 4K 38402160 11185 kb/s 24 142s 0.04732008 0.556 91.5% flv 转 mp4: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 712 kb/s 24 34.5s 0.01149678 0.032 64.1% 高清 1280720 1806 kb/s 24 100.3s 0.033424 0.065 48.6% 超清 19201080 3911 kb/s 24 226.4s 0.0754455 0.126 40.1% 4K 38402160 15109 kb/s 24 912s 0.30391488 0.556 45.3% 成本下降百分比 = (某云视频处理费用 - FC 转码费用)/ 云视频处理费用 某云视频处理,计费使用普通转码,转码时长不足一分钟,按照一分钟计算,这里计费采用的是 2 min,即使采用 1.5 min 计算, 成本下降百分比基本在10%以内浮动 从上表可以看出, 基于函数计算 + 函数工作流的方案在计算资源成本上对于计算复杂度较高的 flv 转 mp4 还是计算复杂度较低的 mp4 转 flv, 都具有很强的成本竞争力。 根据实际经验, 往往成本下降比上表列出来的更加明显, 理由如下: 测试视频的码率较高, 实际上很多场景绝大部分都是标清或者流畅视频的转码场景, 码率也比测试视频低,这个时候计算量变小, FC 执行时间短, 费用会降低, 但是通用的云转码服务计费是不变的. 很多视频分辨率在通用的云转码服务是计费是有很大损失的, 比如转码的视频是 856480 或者 1368768, 都会进入云转码服务的下一档计费单价, 比如856480 进入 1280720 高清转码计费档,1368768 进入 19201080 超清转码计费档, 单价基本是跨越式上升, 但是实际真正的计算量增加可能还不到30%, 而函数计算则是真正能做到按计算量付费. 操作部署 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 详情见各自示例工程的 README Simple 视频处理系统示例工程地址 视频处理工作流系统示例工程地址 总结 基于函数计算 FC 和函数工作流 FnF 的弹性高可用视频处理系统天然继承了这两个产品的优点: 无需采购和管理服务器等基础设施,只需专注视频处理业务逻辑的开发,大幅缩短项目交付时间和人力成本 提供日志查询、性能监控、报警等功能快速排查故障 以事件驱动的方式触发响应用户请求 免运维,毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,性能优异 成本极具竞争力 相比于通用的转码处理服务: 超强自定义,对用户透明, 基于 FFmpeg 或者其他音视频处理工具命令快速开发相应的音视频处理逻辑 原有基于 FFmpeg 自建的音视频处理服务可以一键迁移 弹性更强, 可以保证有充足的计算资源为转码服务,比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完 各种格式的音频转换或者各种采样率自定义、音频降噪等功能, 比如专业音频处理工具 aacgain 和 mp3gain 可以和 serverless 工作流完成更加复杂、自定义的任务编排,比如视频转码完成后,记录转码详情到数据库,同时自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力 更多的方式的事件驱动, 比如可以选择 OSS 自动触发(丰富的触发规则), 也可以根据业务选择 MNS 消息(支持 tag 过滤)触发 在大部分场景下具有很强的成本竞争力相比于其他自建服务: 毫秒级弹性伸缩,弹性能力超强,支持大规模资源调用,可弹性支持几万核.小时的计算力,比如 1 万节课半个小时完成转码 只需要专注业务逻辑代码即可,原生自带事件驱动模式,简化开发编程模型,同时可以达到消息(即音视频任务)处理的优先级,可大大提高开发运维效率 函数计算采用 3AZ 部署, 安全性高,计算资源也是多 AZ 获取, 能保证每个用户需要的算力峰值 开箱即用的监控系统, 如上面 gif 动图所示,可以多维度监控函数的执行情况,根据监控快速定位问题,同时给用户提供分析能力, 比如视频的格式分布, size 分布等 在大部分场景下具有很强的成本竞争力, 因为在函数计算是真正的按量付费(计费粒度在百毫秒), 可以理解为 CPU 的利用率为 100% 最后一一回答一下之前列出的问题: Q1: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? A: 如工程示例所示,在虚拟机/容器平台上基于 FFmpeg 的服务可以轻松切换到函数计算, FFmpeg 相关命令可以直接移值到函数计算,改造成本较低, 同时天然继承了函数计算弹性高可用性特性。 Q2:您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF 等。 自己搭建成本更低。 A: 函数计算天生就是解决这些自定义问题, 你的代码你做主, 代码中快速执行几个 FFmpeg 的命令即可完成需求。典型示例: fc-oss-ffmpeg Q3: 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案),after-process 中可以做一些自定义的操作, 您还可以基于此流程再做一些额外处理等, 比如: 再增加后续流程 最开始增加 pre-process Q4: 您有并发同时处理大量视频的需求。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), 当有多个文件同时上传到 OSS, 函数计算会自动伸缩, 并行处理多个文件。详情可以参考 视频处理工作流系统 (FnF + FC) 压测 Q5:您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。A: 详情可以参考视频处理工作流系统 (FnF + FC) 压测, 可以通过控制分片的大小, 可以使得每个大视频都有足够多的计算资源参与转码计算, 大大提高转码速度。 Q6: 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF,后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), FnF 只负责编排调用函数, 因此只需要更新相应的处理函数即可,同时函数有 version 和 alias 功能, 更好地控制灰度上线, 函数计算版本管理 Q7: 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将他们再迁移到 OSS 上。 A: 函数计算可以挂载 NAS, 直接对 NAS 中的文件进行处理
1934890530796658 2020-03-27 18:21:36 0 浏览量 回答数 0

回答

互联网金融中台 以强大的业务中台为支撑,支持产品快速组合创新。 基于蚂蚁金服中台战略及架构的最佳实践,将企业级公共能力进行抽象,形成以客户服务、运营服务、分布式架构为基础的业务中台体系,实现开放、可扩展、组件化、分布式的业务架构,支持业务快速、高效、低成本创新,满足互联网场景化快速多变的业务发展需求。 强大的业务支撑能力 将企业级公共能力进行抽象,形成各大能力中心,并沉淀到业务中台,以更强大的复用技术提升业务敏捷性,支持业务快速、高效、低成本创新。 快速迭代创新能力 实践大中台战略,基于能力中心与分布式金融核心套件,支持产品快速组合创新。以强大的业务中台为支撑,快速实现产品迭代,满足多变需求。 标准化和可扩展能力 中台屏蔽技术复杂性,使得业务无感知,使得中台参与者能以统一的标准进行协同和技术开发,降低协作成本。能够基于已有的系统能力进行定制扩展或配置,提升复用性同时又满足差异性的要求。 分布式技术能力 提供金融级分布式框架和金融级分布式数据库,支持多租户,支持海量用户的高业务并发场景。提供大数据和人工智能的中台能力建设,支持分布式金融核心系统的异地多活架构。 金融级云原生应用 满足金融业务发展和严苛场景考验,让云计算更懂金融。 蚂蚁金服自主研发的金融级分布式架构平台,专注为金融用户提供全栈式的基础架构能力,保证风险安全的同时帮助业务需求敏捷迭代,同时满足异地容灾、低成本快速扩容的需求 解决传统集中式架构转型的困难,打造大规模高可用分布式系统架构,支撑金融业务创新。 资损防控、无损容灾 保证在分布式架构下承受高并发交易,在系统扩展、容灾恢复、更新发布时确保数据无损,服务可用。 异地多活、无限扩展 使系统容量能在多个数据中心内任意扩展和调度,充分利用服务器资源,提供机房级容灾能力,保证业务连续性。 全栈开放、开源共建 技术栈全面开源共建、保存社区中立、兼容社区 兼容开源生态,组件可插拔, SOFAStack 组件与其它开源组件可相互集成或替换。 异构应用融合迁移 面向未来架构的微服务平台。 微服务平台通过 SOFA 微服务和 Service Mesh 微服务,提供了既支持 SOFA 框架又支持 Service Mesh 架构的微服务管理和治理能力,解决用户在技术转型期间与未改造的遗留系统相互之间打通和过渡问题,帮助金融机构平稳的从传统的集中式、微服务架构演进到云原生架构。 多协议兼容 既能借助蚂蚁金服久经考验的微服务框架 SOFA 在云上构建微服务应用,也可以支持原生 Dubbo 和 Spring Cloud 上云,无需构建 ZooKeeper,Eureka,Consul 等微服务依赖的自建服务,极大降低运维成本。 跨平台无侵入 业务应用系统通过 Service Mesh 技术架构轻量级接入,实现对应用无侵入的服务注册与服务治理方案,减少改造成本。同时,该方案支持容器平台、虚拟机平台,能够满足企业用户未容器化的场景对 Service Mesh 架构转型的需求。 简单易用易维护 微服务平台提供集中式图形化易操作的管理平台,满足企业级高级特性需求,简化分布式应用的服务管理、服务治理、可观察性、配置管理等能力,让用户便捷的对应用服务统一管理和治理。 异地多活单元化架构 “三地五中心”部署模式的技术创新。 该架构解决方案下,可以避免跨机房、跨城市访问的延迟,真正实现异地多活部署,不但消除了传统“两地三中心”架构中的单独冷备中心,并提升了灾备高可用能力,无论在成本还是在伸缩性、高可用方面,都带来了巨大的优势。 保证数据安全和业务连续性 消除了传统架构下启用灾备时可能数据受损或丢失,因而无法保障金融级的数据完整性和一致性这一致命缺点。 多机房、多地域无损容灾 真正实现异地多活部署的单元化架构,支撑更稳定、更高效、更低成本的金融级服务,并极大提升了灾备能力到异地无损容灾级别。 提升机房资源利用率 消除了传统“两地三中心”架构中诸如存在平时不提供服务的单独冷备中心等不足,极大降低了运行成本。
LiuWH 2020-03-24 22:20:15 0 浏览量 回答数 0

回答

原版英文链接:点击这里 作者 | Md Kamaruzzaman 译者 | 无明 策划 | 小智 基础设施:条条道路通云端 对于云厂商来说,2019 年是硕果累累的一年。不仅初创公司在使用云计算,那些很注重安全的“保守派”公司(如政府机构、医疗保健机构、银行、保险公司,甚至是美国五角大楼)也在迁移到云端。这种趋势在 2020 年将会继续,大大小小的公司都将(或者至少有计划)迁移到云端。Gartner 公司最近发布了一个数字: 如果你是一个还在考虑要不要迁移到云端的决策者,不妨重新审视一下你的策略。如果你是一个独立开发者,并且还没使用过云基础设施,那么完全可以在 2020 年尝试一下。很多大型的云厂商(如亚马逊、微软、谷歌)都提供了免费的体验机会。谷歌在这方面做得特别大方,它提供了价值 300 美元的一年免费服务。 策划注:阿里、腾讯、华为等国内云厂商同样有免费云服务试用产品。 云平台:亚马逊领头,其他跟上 作为第一大云厂商,亚马逊在 2019 年可谓风生水起。凭借其丰富的产品组合,亚马逊将把它的优势延续到 2020 年。Canalys 发布的 2019 年第三季度报告指出,大型云厂商(AWS、Azure、GCP)占据 56% 的市场份额,其中 AWS 独享 32.6%。 其他云厂商也在努力缩短与 AWS 之间的差距。微软把主要目标转向了大型企业。最近,微软打败了亚马逊,从美国五角大楼拿到了一个 100 亿美元的大单子。这个单子将提升 Azure 的声誉,同时削弱 AWS 的士气。 谷歌一直在推动 CNCF,实现云计算运维的标准化。谷歌的长期目标是让云迁移变得更容易,方便企业从 AWS 迁移到 GCP。IBM 之前斥资 360 亿美元收购了 RedHat,也想要在云计算市场占有一席之地。 在亚太地区,阿里云市场规模超过了 AWS、Azure 的总和,全球排名第三。中国国内腾讯云等企业的增长势头也十分迅猛。 2020 年将出现更多的并购。当然,很多初创公司将会带来新的想法和创新,例如多云服务。因为竞争激烈,这些公司只能从降价和推出更多的创新产品来获取利润。 容器化:Kubernetes 将会更酷 在容器编排领域,虽然一度出现了“三足鼎立”(Kubernetes、Docker Swarm 和 Mesos),但 Kubernetes 最终脱颖而出,成为绝对的赢家。云是一个分布式系统,而 Kubernetes 是它的 OS(分布式的 Linux)。2019 年北美 KubeCon+CloudNativeCon 大会的参会者达到了 12000 名,比 2018 年增长了 50%。以下是过去 4 年参会人数的增长情况。 在 2020 年,Kubernetes 不仅不会后退,只会变得越来越强,你完全可以把赌注压在 Kubernetes 身上。另外值得一提的是,Migrantis 最近收购了 Docker Enterprise,不过收购数额不详。 几年前,人们张口闭口说的都是 Docker,而现在换成了 Kubernetes。Docker 在它的全盛时期未能盈利,反而在优势渐退几年之后才尝试变现。这再次说明,在现代技术世界,时机就是一切。 软件架构:微服务将成为主流 谷歌趋势表明,微服务架构范式在 2019 年持续增长了一整年。 随着软件行业整体逐步迁移到云端,微服务也将成为占主导地位的架构范式。微服务架构崛起的一个主要原因是它与云原生完美契合,可以实现快速的软件开发。我在之前的一篇博文中解释了微服务架构的基本原则及其优势和劣势。 https://towardsdatascience.com/microservice-architecture-a-brief-overview-and-why-you-should-use-it-in-your-next-project-a17b6e19adfd 我假设现在也存在一种回归到单体架构的趋势,因为在很多情况下,微服务架构有点过头了,而且做好微服务架构设计其实很难。微服务架构有哪些好的实践?在之前的另一篇博文中,我也给出了一些大概,希望对读者有用。 https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee2 编程语言(整体):Python 将吞噬世界 机器学习、数据分析、数据处理、Web 开发、企业软件开发,甚至是拼接黑洞照片,Python 的影子无处不在。 在著名的编程语言排行榜网站 TIOBE 上,Python 位居最流行编程语言第三位,仅次于 Java 和 C 语言。 更有意思的是,在 2019 年,Python 的流行度翻了一番(从 5% 到 10%)。 Python 的崛起将在 2020 年延续,并缩短与 Java 和 C 语言之间的差距。另一门无所不在的编程语言 JavaScript 正面临下行的风险。为什么 Python 的势头会如此强劲?因为它的入手门槛低,有一个优秀的社区在支持,并受到数据科学家和新生代开发者的喜爱。 编程语言(企业方面):Java 将占主导 之前的 TIOBE 网站截图显示,Java 仍然是一门占主导地位的编程语言,并将在 2020 年继续保持这种地位。JVM 是 Java 的基石,其他编程语言(如 Kotlin、Scala、Clojure、Groovy)也将 JVM 作为运行时。最近,Oracle 修改了 JVM 的许可协议。 新的许可协议意味着使用 Java、Kotlin、Scala 或其他 JVM 编程语言的公司需要向 Oracle 支付大额费用。所幸的是,OpenJDK 让 JVM 继续免费。另外,还有其他一些公司为 JVM 提供企业支持。 因为体积和速度方面的问题,基于 JVM 的编程语言并不适合用在今天的无服务器环境中。Oracle 正在推动 GraalVM 计划,旨在让 Java 变得更加敏捷和快速,让它更适合用在无服务器环境中。因为除了 Java,没有其他编程语言可以提供企业级的稳定性和可靠性,所以 Java 将在 2020 年继续占主导地位。 企业版 Java:Spring 继续发力 曾几何时,在企业开发领域,Spring 和 JavaEE 之间存在着白热化的竞争。但因为 Oracle 在 JavaEE 方面没有作为,在竞争中惨败,这导致了“MicroProfile”计划的形成,并最终促成了 JakartaEE。 虽然所有的政策和活动都是围绕 JavaEE 展开,但 Spring 事实上已经赢得了这场企业 JVM 之争。2020 年,Spring 将成为 JVM 生态系统的头牌。 有两个正在进展中的项目,它们旨在减小 Java 的体积,让它更适合用在无服务器环境中。 其中一个是 Micronaut(https://micronaut.io/)。 另一个是 Quarkus(https://quarkus.io/)。 这两个项目都使用了 GraalVM,它们在 2020 年将会得到 Java 社区更多的关注。 编程语言:后起之秀的突破 2000 年代,编程语言的发展出现了停滞。大多数人认为没有必要再去开发新的编程语言,Java、C 语言、C++、JavaScript 和 Python 已经可以满足所有的需求。但是,谷歌的 Go 语言为新编程语言大门打开了一扇大门。在过去十年出现了很多有趣的编程语言,比如 Rust、Swift、Kotlin、TypeScript。导致这种情况的一个主要原因是已有的编程语言无法充分利用硬件优势(例如多核、更快的网络、云)。另一个原因是现代编程语言更加关注开发者经济,即实现更快速更容易的开发。在 Stackoverflow 提供的一份开发者报告中,排名靠前的现代编程语言如下所示(Rust 连续 4 年名列第一)。 在之前的一篇博文中,我深入探讨了现代编程语言,对比 Rust 和 Go 语言,并说明了为什么现在是采用这些语言的好时机。 https://towardsdatascience.com/back-to-the-metal-top-3-programming-language-to-develop-big-data-frameworks-in-2019-69a44a36a842 最近,微软宣布他们在探索使用 Rust 来开发更安全的软件。 亚马逊最近也宣布要赞助 Rust。 谷歌宣布将 Kotlin 作为 Android 官方开发语言,所以,在 JVM 领域,Kotlin 成了 Java 的主要竞争对手。 Angular 使用 TypeScript 代替 JavaScript,将其作为主要的编程语言,其他 JavaScript 框架(如 React 和 Vue)也开始为 TypeScript 提供更多的支持。 这种趋势将在 2020 年延续下去,很多巨头公司将会深入了解新一代编程语言(如 Rust、Swift、TypeScript、Kotlin),它们会站出来公开表示支持。 Web:JavaScript 继续占主导地位 曾几何时,JavaScript 并不被认为是一门强大的编程语言。在当时,前端内容主要通过后端框架在服务器端进行渲染。2014 年,AngularJS 的出现改变了这种局面。从那个时候开始,更多的 JavaScript 框架开始涌现(Angular 2+、React、Vue、Meteor),JavaScript 已然成为主流的 Web 开发语言。随着 JavaScript 框架不断创新以及微服务架构的崛起,JavaScript 框架在 2020 年将继续主导前端开发。 JavaScript 框架:React 闪耀 虽然 React 是在 AngularJS 之后出现的,但在过去十年对 Web 开发产生了巨大的影响,这也让 Facebook 在与 Google+ 的竞争中打了一场胜战。React 为前端开发带来了一些新的想法,比如事件溯源、虚拟 DOM、单向数据绑定、基于组件的开发,等等。它对开发者社区产生了重大影响,以至于谷歌放弃了 AngularJS,并借鉴 React 的想法推出了彻底重写的 Angular 2+。React 是目前为止最为流行的 JavaScript 框架,下图显示了相关的 NPM 下载统计信息。 为了获得更好的并发和用户体验,Facebook 宣布完全重写 React 的核心算法,推出了 React-Fiber 项目。 2020 年,React 仍然是你开发新项目的首选 Web 框架。其他框架(如 Angular/Angular 2+ 或 Vue)呢?Angular 仍然是一个不错的 Web 开发框架,特别适合企业开发。我敢肯定谷歌在未来几年会在 Angular 上加大投入。Vue 是另一个非常流行的 Web 框架,由中国的巨头公司阿里巴巴提供支持。如果你已经在使用 Angular 或 Vue,就没必要再迁移到 React 了。 App 开发:原生应用 在移动 App 开发方面,有关混合应用开发的炒作有所消停。混合开发提供了更快的开发速度,因为只需要一个开发团队,而不是多个。但原生应用提供了更好的用户体验和性能。另外,混合应用需要经过调整才能使用一些高级特性。对于企业来说,原生应用仍然是首选的解决方案,这种趋势将在 2020 年延续。Airbnb 在一篇博文中非常详细地说明了为什么他们要放弃混合应用开发平台 React Native。 https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a 尽管 Facebook 尝试改进 React Native,谷歌也非常努力地推动混合 App 开发平台 Flutter,但它们仍然只适合用于原型、POC、MVP 或轻量级应用的开发。所以,原生应用在 2020 年仍将继续占主导地位。 在原生应用开发方面,谷歌和苹果分别将 Kotlin 和 Swift 作为各自平台主要的编程语言。谷歌最近再次重申了对 Kotlin 的支持,这对于 Kotlin 用户来说无疑是个好消息。 混合应用开发:React Native 在很多情况下,混合应用是个不错的选择。在这方面也有很多选择:Xamarin、Inoic、React Native 和 Flutter。Facebook 基于成熟的 React 框架推出了 React Native。就像 React 在 Web 框架领域占据主导地位一样,React Native 在混合应用领域也占据着主导地位,如下图所示。 React Native 和 React 有共同的基因,都提供了高度的代码重用性以及“一次开发,到处运行”的能力。React Native 的另一个优势是 Facebook 本身也用它来开发移动应用。谷歌在这个领域起步较晚,但在去年,谷歌的混合应用开发框架 Flutter 获得了不少关注。Flutter 提供了更好的性能,但需要使用另一门不是那么流行的编程语言 Dart。React Native 在 2020 年将继续占主导地位。 API:REST 将占主导地位 REST 是 API 领域事实上的标准,被广泛用在基于 API 的服务间通信上。当然,除了 REST,我们还有其他选择,比如来自谷歌的 gRPC 和来自 Facebook 的 GraphQL。 它们提供了不同的能力。谷歌开发的 gRPC 作为远程过程调用(如 SOAP)的化身,使用 Protobuf 代替 JSON 作为消息格式。Facebook 开发的 GraphQL 作为一个集成层,避免频繁的 REST 调用。gRPC 和 GraphQL 都在各自的领域取得了成功。2020 年,REST 仍然是占主导地位的 API 技术,而 GraphQL 和 gRPC 将作为补充技术。 人工智能:Tensorflow 2.0 将占主导地位 谷歌和 Facebook 也是深度学习 / 神经网络领域的主要玩家。谷歌基于深度学习框架 Theano 推出了 TensorFlow,它很快就成为深度学习 / 神经网络的主要开发库。谷歌还推出了特别设计的 GPU(TPU)来加速 TensorFlow 的计算。 Facebook 在深度学习领域也不甘落后,他们拥有世界上最大的图像和视频数据集合。Facebook 基于另一个深度学习库 Torch 推出了深度学习库 PyTorch。TensorFlow 和 PyTorch 之间有一些区别,前者使用的是静态图进行计算,而 PyTorch 使用的是动态图。使用动态图的好处是可以在运行时纠正自己。另外,PyTorch 对 Python 支持更好,而 Python 是数据科学领域的一门主要编程语言。 随着 PyTorch 变得越来越流行,谷歌也赶紧在 2019 年 10 月推出了 TensorFlow 2.0,也使用了动态图,对 Python 的支持也更好。 2020 年,TensorFlow 2.0 和 PyTorch 将齐头并进。考虑到 TensorFlow 拥有更大的社区,我估计 TensorFlow 2.0 将成为占主导地位的深度学习库。 数据库:SQL是王者,分布式SQL是王后 在炒作 NoSQL 的日子里,人们嘲笑 SQL,还指出了 SQL 的种种不足。有很多文章说 NoSQL 有多么的好,并将要取代 SQL。但等到炒作的潮水褪去,人们很快就意识到,我们的世界不能没有 SQL。以下是最流行的数据库的排名。 可以看到,SQL 数据库占据了前四名。SQL 之所以占主导地位,是因为它提供了 ACID 事务保证,而 ACID 是业务系统最潜在的需求。NoSQL 数据库提供了横向伸缩能力,但代价是不提供 ACID 保证。 互联网公司一直在寻找“大师级数据库”,也就是既能提供 ACID 保证又能像 NoSQL 那样可横向伸缩的数据库。目前有两个解决方案可以部分满足对“大师级数据库”的要求,一个是亚马逊的 Aurora,一个是谷歌的 Spanner。Aurora 提供了几乎所有的 SQL 功能,但不支持横向写伸缩,而 Spanner 提供了横向写伸缩能力,但对 SQL 支持得不好。 2020 年,但愿这两个数据库能够越走越近,或者有人会带来一个“分布式 SQL”数据库。如果真有人做到了,那一定要给他颁发图灵奖。 数据湖:MinIO 将要崛起 现代数据平台非常的复杂。企业一般都会有支持 ACID 事务的 OLTP 数据库(SQL),也会有用于数据分析的 OLAP 数据库(NoSQL)。除此之外,它们还有其他各种数据存储系统,比如用于搜索的 Solr、ElasticSearch,用于计算的 Spark。企业基于数据库构建自己的数据平台,将 OLTP 数据库的数据拷贝到数据湖中。各种类型的数据应用程序(比如 OLAP、搜索)将数据湖作为它们的事实来源。 HDFS 原本是事实上的数据湖,直到亚马逊推出了对象存储 S3。S3 可伸缩,价格便宜,很快就成为很多公司事实上的数据湖。使用 S3 唯一的问题是数据平台被紧紧地绑定在亚马逊的 AWS 云平台上。虽然微软 Azure 推出了 Blob Storage,谷歌也有类似的对象存储,但都不是 S3 的对手。 对于很多公司来说,MinIO 或许是它们的救星。MinIO 是一个开源的对象存储,与 S3 兼容,提供了企业级的支持,并专门为云原生环境而构建,提供了与云无关的数据湖。 微软在 Azure Marketplace 是这么描述 MinIO 的:“为 Azure Blog Storage 服务提供与亚马逊 S3 API 兼容的数据访问”。如果谷歌 GCP 和其他云厂商也提供 MinIO,那么我们将会向多云迈出一大步。 大数据批处理:Spark 将继续闪耀 现如今,企业通常需要基于大规模数据执行计算,所以需要分布式的批处理作业。Hadoop 的 Map-Reduce 是第一个分布式批处理平台,后来 Spark 取代了 Hadoop 的地位,成为真正的批处理之王。Spark 是怎样提供了比 Hadoop 更好的性能的?我之前写了另一篇文章,对现代数据平台进行了深入分析。 https://towardsdatascience.com/programming-language-that-rules-the-data-intensive-big-data-fast-data-frameworks-6cd7d5f754b0 Spark 解决了 Hadoop Map-Reduce 的痛点,它将所有东西放在内存中,而不是在完成每一个昂贵的操作之后把数据保存在存储系统中。尽管 Spark 重度使用 CPU 和 JVM 来执行批处理作业,但这并不妨碍它成为 2020 年批处理框架之王。我希望有人能够使用 Rust 开发出一个更加高效的批处理框架,取代 Spark,并为企业省下大量的云资源费用。 大数据流式处理:Flink 是未来 几年前,实现实时的流式处理几乎是不可能的事情。一些微批次处理框架(比如 Spark Streaming)可以提供“几近”实时的流式处理能力。不过,Flink 改变了这一状况,它提供了实时的流式处理能力。 2019 年之前,Flink 未能得到足够的关注,因为它无法撼动 Spark。直到 2019 年 1 月份,中国巨头公司阿里巴巴收购了 Data Artisan(Flink 背后的公司)。 在 2020 年,企业如果想要进行实时流式处理,Flink 应该是不二之选。不过,跟 Spark 一样,Flink 同样重度依赖 CPU 和 JVM,并且需要使用大量的云资源。 字节码:WebAssembly将被广泛采用 我从 JavaScript 作者 Brandon Eich 的一次访谈中知道了 WebAssembly 这个东西。现代 JavaScript(ES5 之后的版本)是一门优秀的编程语言,但与其他编程语言一样,都有自己的局限性。最大的局限性是 JavaScript 引擎在执行 JavaScript 时需要读取、解析和处理“抽象语法树”。另一个问题是 JavaScript 的单线程模型无法充分利用现代硬件(如多核 CPU 或 GPU)。正因为这些原因,很多计算密集型的应用程序(如游戏、3D 图像)无法运行在浏览器中。 一些公司(由 Mozilla 带领)开发了 WebAssembly,一种底层字节码格式,让任何一门编程语言都可以在浏览器中运行。目前发布的 WebAssembly 版本可以支持 C++、Rust 等。 WebAssembly 让计算密集型应用程序(比如游戏和 AutoCAD)可以在浏览器中运行。不过,WebAssembly 的目标不仅限于此,它还要让应用程序可以在浏览器之外运行。WebAssembly 可以被用在以下这些“浏览器外”的场景中。 移动设备上的混合原生应用。没有冷启动问题的无服务器计算。在服务器端执行不受信任的代码。 我预测,2020 年将是 WebAssembly 取得突破的一年,很多巨头公司(包括云厂商)和社区将会拥抱 WebAssembly。 代码:低代码 / 无代码将更进一步 快速的数字化和工业 4.0 革命意味着软件开发者的供需缺口巨大。由于缺乏开发人员,很多企业无法实现它们的想法。为了降低进入软件开发的门槛,可以尝试无代码(No Code)或低代码(Low Code)软件开发,也就是所谓的 LCNC(Low-Code No-Code)。它已经在 2019 年取得了一些成功。 LCNC 的目标是让没有编程经验的人也能开发软件,只要他们想要实现自己的想法。 虽然我对在正式环境中使用 LCNC 框架仍然心存疑虑,但它为其他公司奠定了良好的基础,像亚马逊和谷歌这样的公司可以基于这个基础构建出有用的产品,就像 AWS Lambda 的蓬勃发展是以谷歌 App Engine 为基础。 2020 年,LCNC 将会获得更多关注。
茶什i 2019-12-26 11:57:03 0 浏览量 回答数 0

问题

【阿里云产品评测】个人WP站的云体验

1 ECS 首先来说说我自己,一直对计算机颇有兴趣,高中的时候就开始研究了些PHP的东西, 05年上大二的时候,注册了自己的域名www.cnsjw.cn  ,并开通了自己...
cnsjw 2019-12-01 20:54:27 22207 浏览量 回答数 25

问题

厉华:写一个开源容器引擎会是什么样的体验? 热:报错

2013年,Docker.Inc 开源了一款应用容器引擎 Docker。开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到相同内核的任何 Linux 机器上部署运行。这种集装箱式的应用开发和部署方...
kun坤 2020-06-10 10:01:12 3 浏览量 回答数 1

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务