• 关于

    公共云原生API

    的搜索结果

回答

云服务器(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

问题

【精品问答】微消息队列 MQTT 版

montos 2020-04-08 12:20:13 3 浏览量 回答数 1

回答

DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile)。传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求。于是,DevOps 作为一种打破研发和运维之间隔阂、加快软件交付流程、提高软件交付质量的文化理念和最佳实践 逐渐普及至今。 DevOps 的现状 DevOps 的流行得益于业界对于应用软件敏捷开发、高质量交付的诉求,所以为开发和运维开辟了一块“公共的空间”,让双方可以在这里紧密合作。那时软件研发依旧属于一个新兴行业,人们习惯于向成熟的制造业学习,制造业解决大规模生产的方式,就是构建流水线,通过流水线规范化每个步骤对接的内容,而流水线上的工人们则只需要各司其职,快速熟练的完成自己这部分生产内容。 所以,DevOps 借鉴了制造业的经验,开始构建持续集成 / 持续交付(CI/CD)的流水线,催生出了一系列自动化 / 半自动化工具(如 puppet、chef、ansible 等),结合编写脚本的可扩展能力,将研发和运维的大量操作规范化,从而达到彼此协作的目标。但是最终还是要有人投入到这些工具的构建中,于是就出现了 DevOps 团队。DevOps 团队构建的工具和平台,帮助研发更容易地接近生产环境,让研发在持续集成、持续交付的过程中可以一键部署、快速试错,从而很大程度提前暴露和避免了软件在实际运行过程中的问题。 从本质上讲,DevOps 是为运维服务的。 它把生产环境的运维流程通过自动化的工具提供出来了,屏蔽了基础设施细节,同时让软件本身的问题更容易暴露,从而把这些问题尽量提前交给研发去解决。这些,其实都是在帮助运维减轻负担。 这一套模式在一开始运转良好,但是问题也随着时间的推移慢慢暴露出来了。DevOps 本身不为企业带来直接的利润,也不增加产品的功能,它们是企业的成本中心,所以许多企业不愿意为 DevOps 投入太多的成本。久而久之,DevOps 的能力便无法与研发人员增长的需求所匹配,不愿意继续伴随着云和开源社区的发展向前演进,反而成为软件研发的瓶颈。试想一下,有多少大公司的技术人员,对自己公司里的“研发效能”工具表示满意呢? 云计算的普及 聪明的企业总能从自己的需求中发现业界共有的需求,AWS 便是这么诞生的,他们早在 2006 年便首次把软件部署需要的网络、计算、存储等基础设施当做服务提供给用户,允许任何人在不购买服务器等物理硬件的情况下构建互联网应用程序,规模化使得整体的成本比用户自建更低。而云计算 IaaS、PaaS、SaaS 的概念也正是在那一年开始逐渐清晰的。 云计算的初期,用户主要使用的是 IaaS 服务,如虚拟机、存储等,使用云计算服务的企业依旧需要运维来管理这一类基础设施,只是运维管理的对象从物理机切换到虚拟机而已,并没有太本质的区别。 而随着云计算的快速发展,云的能力不断补充、增强,渐渐将原先由运维提供的方方面面的能力都转换成为了云上的服务,这其中自然包含了管理软件完整生命周期的各类服务,从代码托管、持续集成、持续交付,到监控、报警、自动扩缩容等一系列的能力,均能在云上找到对应的服务。品类之多、数量之巨,令人瞠目结舌。 但是 DevOps 依然有着用武之地。云的对接难度实在太大了,涉及到的云服务又多,不同云厂商提供的服务还不统一,为了使用云上的产品不得不投入大量的时间学习,而为了防止云厂商的绑定又不得不做多厂商的适配,DevOps 依旧需要像过去一样为开发屏蔽实际环境的复杂性,只不过这次他们要负责管理的基础设施变成了云资源。 改变一切的 Kubernetes Kubernetes 的本质是现代应用基础设施,它关注如何将应用与“云”天然地集成在一起,将“云”的最大价值发挥出来。Kubernetes 强调让基础设施能更好的配合应用、以更高效的方式为应用“输送”基础设施能力,而不是反之。在这个过程中,Kubernetes 、Docker、Operator 等在云原生生态中起到了关键作用的开源项目,正在在把应用管理与交付推上一个跟以前完全不一样的境况:Kubernetes 的使用者只通过声明式的方式描述自己应用的终态是什么,然后一切就结束了。Kubernetes 会处理后面的所有事情。 这也是为什么 Kubernetes 非常强调声明式 API。通过这种方式,Kubernetes 本身接入的基础设施能力越强,Kubernetes 的使用者能够声明的终态就越丰富,他的职责也就约单纯。现在,我们不仅能够通过 Kubernetes 声明应用的运行终态,比如;“这个应用需要 10 个实例”,我们还能够声明应用的很多运维终态,比如:“这个应用使用金丝雀发布策略进行升级”,以及 “当它的 CPU 使用量大于 50% 时,请自动扩展 2 个实例出来”。 这就让传统的 DevOps 工具和团队受到了挑战:如果一个业务研发自己只需要通过声明式 API 声明他的应用的所有终态甚至包括完整的 SLA,后面的一切就都会有 Kubernetes 来自动的搞定,那么他还有什么理由去对接和学习各式各样的 DevOps 流水线呢? 换句话说,长久以来,DevOps 实际上是在充当研发与基础设施之间的那一层“胶水”。而现在,Kubernetes 通过它极具生命力的声明式 API 和无限接入的应用基础设施能力,正在完美的扮演这个“胶水层”的作用。这也提醒了我们,上一个正在被 Kubernetes 体系强烈挑战的“胶水层”,其实叫做“传统中间件”:它正遭受到 Service Mesh 的巨大冲击。 DevOps 会消失吗? 近几年,Kubernetes 项目经常被描述成 DevOps 的“最佳拍档”。类似的观点认为, Kubernetes 跟 Docker 一样,解决的是软件运行时的问题。这意味着 Kubernetes 更像一种“时髦”的 IaaS,只不过运行时从虚拟机变成了容器。所以,只要能够将现有 DevOps 思想和流程对接到 Kubernetes 上来,就可以享受到容器技术带来的轻量级与弹性。这对于提倡“敏捷”的 DevOps 来说,显然是最好的组合。 不过,至少目前看来,Kubernetes 的发展路径并不是一个类 IaaS 的角色。它虽然关注接入底层的基础设施能力,但它本身却又不是基础设施能力的提供方。而且,相比于软件运行时,Kubernetes 似乎更关心软件的生命周期和状态流转。不仅如此,它还提供了一种叫做“控制器模型”的机制来将软件的实际状态与期望状态不断逼近,这显然都已经超出了一个“软件运行时”的范畴。 Kubernetes 项目对应用本身的“额外关注”,让它与一个类 IaaS 基础设施有着明显的区别,也让它“胶水”的定位更加明显。而如果 Kubernetes 的能力足够强大,那么作为研发与基础设施之间现有的“胶水层”, DevOps 是否还有必要存在?在所谓的云原生时代,应用研发与交付是不是真的会走向“一次声明”就可以“撒手不管”,从而让 DevOps 彻底消失呢? 不过,至少目前看来,Kubernetes 项目距离这个愿景,还有不少困难需要克服。 “Platform for Platform” API 的局限性 Kubernetes 是一个典型的 “Platform for Platform”项目,所以它的 API,距离纯研发视角还是非常遥远的。就比如一个 Deployment 对象,就既包括了研发侧关心的镜像,也包括了基础设施侧的资源配置,甚至是容器安全配置。此外, Kubernetes API 并没有提供出对“运维能力”的描述与定义方式,这也使得声明之后的“撒手不管”变得遥不可及。这也是为什么目前 DevOps 依然被需要的原因:Kubernetes 的大多数字段,还是必须经过研发和运维共同协作的流程来进行填充。 无法对更多的云资源进行描述 K8s 的原生 API 只包含了云资源的很少一部分,比如用 PV/PVC 表达存储,用 Ingress 表达负载均衡,但这对于一个完全声明式的应用描述来说是完全不够的。比如,研发希望在 K8s 上找到一个概念来表达数据库、VPC、消息队列等需求的时候,就会感到非常困惑。而现有的所有方案则完全依赖于云厂商的实现从而带来了新的 vendor lock-in 困惑。 Operator 体系缺乏互操作性 Kubernetes 的 Operator 机制是这个项目的能力能够无限增长的公开秘密。但令人遗憾的是,目前所有 Operator 之间的关系,就像是一个又一个的烟囱,互相之间没有任何交互与协作的可能。比如,我们把云上的 RDS 通过 CRD 和 Operator 扩展到了 K8s 声明式 API 的体系中,但是当第三方希望写一个定时备份 RDS 持久化文件的 CRD Operator 去配合的时候,却往往无从下手。这就又需要 DevOps 的体系介入来解决问题。 未来? 显然,现在的 Kubernetes 项目,依然需要借助 DevOps 体系来真正完成软件的高效迭代与交付工作。这是不可避免的:尽管 Kubernetes 声称自己是“以应用为中心”的基础设施,但它作为一个从 Google Borg 衍生出来的系统级项目,其本身的设计和工作层次还是更多的基础设施领域徘徊。但另一方面,我们绝不可否认的是,Kubernetes 在它的关键路径上,始终保持着对研发侧 “NoOps” 的追求。这种渴望,从它第一天提出“声明式应用管理”理论的时候就已经“昭然若揭”,而 CRD 和 Operator 体系的建立,更让这种应用级别的关心终于有了落地的机会。我们已经看到很多 DevOps 流程正在“下沉”为 Kubernetes 里的声明式对象与控制循环,比如 Tekton CD 项目。 如果 Kubernetes 的未来是 100% 的声明式应用管理,那么我们有理由相信 DevOps 最终会从技术领域消失然后彻底蜕变成一种文化。毕竟,那个时候的运维工程师,可能都会成为 Kubernetes Controller/Operator 的编写者或者设计者。而研发呢?他们可能根本不会知道原来 Kubernetes 这个东西曾经如此显赫的存在过。

有只黑白猫 2020-01-07 11:35:38 0 浏览量 回答数 0

阿里云高校特惠,助力学生创业梦!0元体验,快速入门云计算!

学生动手场景应用,快速了解并掌握云服务器的各种新奇玩法!

问题

容器镜像服务

黄一刀 2020-04-04 03:52:47 64 浏览量 回答数 1

问题

容器服务 发布历史

青蛙跳 2019-12-01 21:32:38 622 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站