• 关于 业务原生云平台 的搜索结果

回答

容器镜像服务 ACR 企业版是企业级云原生应用制品管理平台,提供容器镜像、Helm Chart 符合 OCI 规范制品的生命周期管理;支持大规模、多地域、多场景下应用制品的高效分发;与容器服务 ACK 无缝集成,帮助企业降低交付复杂度。本文将介绍 ACR 企业版的主要功能、使用场景以及不同版本规格区别。 产品功能 多样 OCI 制品托管:支持多架构容器镜像(如 Linux、Windows、ARM 等架构的容器镜像)、支持 Helm Chart v2/v3 符合 OCI 规范的制品管理。 多维度安全保障:云原生制品加密存储,支持镜像安全扫描及多维度漏洞报告,保障存储及内容安全;分别提供容器镜像和 Helm Chart 的网络访问控制管理,细粒度的操作审计,保障制品访问安全。 加速应用分发:支持全球多地域间同步,提高容器镜像分发效率;提供 P2P 分发加速方式,保障业务的极速部署和快速扩展。 提效云原生应用交付:提供云原生应用交付链功能,全链路可观测、可追踪、可自主配置;支持基于策略的自动阻断, 实现一次应用变更,全球化多场景自动交付,提升云原生应用交付效率及安全性。 使用场景 业务全球地域部署 在国内地域研发迭代,业务在全球多个地域部署,由于网络不稳定等因素,无法直接从国内地域拉取容器镜像。 ACR 企业版支持基于地域选购,并通过设置自定义规则实现镜像全球自动同步,满足业务拓展至全球时就近拉取容器镜像的需求,并可实现跨地域容灾。 业务大规模部署 业务大规模部署,在弹性场景或发布迭代场景下,无法快速获取容器镜像部署以应对峰值流量。ACR 企业版提供多实例规格,满足不同规模集群的并发拉取需求,支持多种大规模分发加速方式,保障容器业务的快速扩展和极速部署。 容器化 DevSecOps 提效 业务部署在容器服务 ACK 、容器服务 ASK、企业级分布式应用服务 EDAS、弹性容器实例 ECI 等平台,需要保障交付部署全链路的安全和效率。ACR 企业版提供云原生应用交付链功能,全链路可追踪、可观测、可自主配置。实现代码变更后,自动构建成云原生应用制品,自动触发安全扫描和安全加签。基于配置的安全策略,主动阻断存在安全风险的交付链流程。通过安全策略的制品自动触发全球化分发,最终实现多场景下的云原生应用的部署。基于云原生应用交付链,可以将安全内置到交付的全链路中,将 DevOps 全面升级成 DevSecOps,保证云原生应用制品更加安全、高效的交付上线。 搬站上云 在云原生搬站场景,云原生应用制品迁移是首要任务。ACR 企业版提供镜像极速导入功能,实现基于 OSS Bucket 极速导入企业版实例,提升迁移的效率和体验;也支持迁移工具,从 Google、Azure、AWS 等容器镜像服务平滑迁移至 ACR 企业版。 版本规格说明 ACR 企业版提供的版本规格说明如下。 功能归类 细分项 默认实例 企业版 基础版 标准版 高级版 制品管理 容器镜像 托管 支持 支持 支持 支持 命名空间限额 3 15 25 50 公开仓库限额 300 1000 3000 5000 私有仓库限额 构建 支持 支持 支持 支持 触发器 支持 支持 支持 支持 Helm Chart 托管 - 支持 支持 支持 命名空间限额 - 15 25 50 公开仓库限额 - 1000 3000 5000 私有仓库限额 安全增强 容器镜像 漏洞扫描 支持 支持 支持 支持 网络访问控制 - 支持 支持 支持 Helm Chart 网络访问控制 - 支持 支持 支持 操作审计 - 支持 支持 支持 应用分发 大规模分发 - - 支持 支持 全球同步 同步能力 - - 支持 支持 应用交付 云原生应用交付链 功能 - - - 支持 周边服务 ACK 集成 免密插件 支持 支持 支持 支持 迁云指导 镜像极速导入 - 支持 支持 支持

1934890530796658 2020-03-20 22:56:55 0 浏览量 回答数 0

回答

容器镜像服务 ACR 企业版是企业级云原生应用制品管理平台,提供容器镜像、Helm Chart 符合 OCI 规范制品的生命周期管理;支持大规模、多地域、多场景下应用制品的高效分发;与容器服务 ACK 无缝集成,帮助企业降低交付复杂度。本文将介绍 ACR 企业版的主要功能、使用场景以及不同版本规格区别。 产品功能 多样 OCI 制品托管:支持多架构容器镜像(如 Linux、Windows、ARM 等架构的容器镜像)、支持 Helm Chart v2/v3 符合 OCI 规范的制品管理。 多维度安全保障:云原生制品加密存储,支持镜像安全扫描及多维度漏洞报告,保障存储及内容安全;分别提供容器镜像和 Helm Chart 的网络访问控制管理,细粒度的操作审计,保障制品访问安全。 加速应用分发:支持全球多地域间同步,提高容器镜像分发效率;提供 P2P 分发加速方式,保障业务的极速部署和快速扩展。 提效云原生应用交付:提供云原生应用交付链功能,全链路可观测、可追踪、可自主配置;支持基于策略的自动阻断, 实现一次应用变更,全球化多场景自动交付,提升云原生应用交付效率及安全性。 使用场景 业务全球地域部署 在国内地域研发迭代,业务在全球多个地域部署,由于网络不稳定等因素,无法直接从国内地域拉取容器镜像。 ACR 企业版支持基于地域选购,并通过设置自定义规则实现镜像全球自动同步,满足业务拓展至全球时就近拉取容器镜像的需求,并可实现跨地域容灾。 业务大规模部署 业务大规模部署,在弹性场景或发布迭代场景下,无法快速获取容器镜像部署以应对峰值流量。ACR 企业版提供多实例规格,满足不同规模集群的并发拉取需求,支持多种大规模分发加速方式,保障容器业务的快速扩展和极速部署。 容器化 DevSecOps 提效 业务部署在容器服务 ACK 、容器服务 ASK、企业级分布式应用服务 EDAS、弹性容器实例 ECI 等平台,需要保障交付部署全链路的安全和效率。ACR 企业版提供云原生应用交付链功能,全链路可追踪、可观测、可自主配置。实现代码变更后,自动构建成云原生应用制品,自动触发安全扫描和安全加签。基于配置的安全策略,主动阻断存在安全风险的交付链流程。通过安全策略的制品自动触发全球化分发,最终实现多场景下的云原生应用的部署。基于云原生应用交付链,可以将安全内置到交付的全链路中,将 DevOps 全面升级成 DevSecOps,保证云原生应用制品更加安全、高效的交付上线。 搬站上云 在云原生搬站场景,云原生应用制品迁移是首要任务。ACR 企业版提供镜像极速导入功能,实现基于 OSS Bucket 极速导入企业版实例,提升迁移的效率和体验;也支持迁移工具,从 Google、Azure、AWS 等容器镜像服务平滑迁移至 ACR 企业版。 版本规格说明 ACR 企业版提供的版本规格说明如下。 功能归类 细分项 默认实例 企业版 基础版 标准版 高级版 制品管理 容器镜像 托管 支持 支持 支持 支持 命名空间限额 3 15 25 50 公开仓库限额 300 1000 3000 5000 私有仓库限额 构建 支持 支持 支持 支持 触发器 支持 支持 支持 支持 Helm Chart 托管 - 支持 支持 支持 命名空间限额 - 15 25 50 公开仓库限额 - 1000 3000 5000 私有仓库限额 安全增强 容器镜像 漏洞扫描 支持 支持 支持 支持 网络访问控制 - 支持 支持 支持 Helm Chart 网络访问控制 - 支持 支持 支持 操作审计 - 支持 支持 支持 应用分发 大规模分发 - - 支持 支持 全球同步 同步能力 - - 支持 支持 应用交付 云原生应用交付链 功能 - - - 支持 周边服务 ACK 集成 免密插件 支持 支持 支持 支持 迁云指导 镜像极速导入 - 支持 支持 支持

1934890530796658 2020-03-20 21:45:16 0 浏览量 回答数 0

回答

云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务等, 而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。 所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。云原生包括DevOps、持续交付、微服务、敏捷基础设施、康威定律等,以及根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。 CNCF(云原生计算基金会)认为云原生系统需包含的属性: 1、容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。 2、自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。 3、面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。 答案来源于网络

养狐狸的猫 2019-12-02 03:00:24 0 浏览量 回答数 0

新用户福利专场,云服务器ECS低至102元/年

新用户专场,1核2G 102元/年起,2核4G 699.8元/年起

回答

业界普遍认为,云原生架构能加快需求交付、降低运营成本、支持容量伸缩、保证业务连续,从而使组织能更从容地接入创新技术、促进渠道触达。金融分布式架构 SOFAStack 致力于提供一整套帮助广大金融场景落地云原生、分布式架构的产品和解决方案,而其中的应用 PaaS 平台,融合金融科技多年在大规模分布式系统和容器平台的实践经验,使用户在专注于业务价值的同时,提升研发效率和自动化水平,降低成本和业务技术风险。 SOFAStack 平台下的容器应用服务(Application Kubernetes Service,简称 AKS),全面集成 Kubernetes,提供完整的集群管控、认证授权、容器网络、持久卷存储等方面的平台能力。在兼顾标准化一致性的 Kubernetes 能力的同时,亦将源自实践的应用全生命周期的发布部署能力通过产品化的形式交付。针对金融级场景下大规模分布式系统的特点,提供了丰富的发布策略以满足不同的场景,如:分组发布、Beta 发布、灰度发布等,帮助传统架构平滑过渡,适应金融技术风险保障需求,实现大规模金融级运维场景下的容器服务落地。 容器应用服务致力于通过成熟的技术和最佳实践经验的支撑,使金融场景亦能从容地应对云原生开发、运维、架构的难题,解决金融系统应用容器化转型的需求,使容器技术真正的大规模应用于金融行业生产环境里,帮助传统应用以更高效、低成本的方式迁移到云原生微服务、容器化体系架构。

LiuWH 2020-03-24 22:27:22 0 浏览量 回答数 0

回答

我觉得有两个层面:业务层面和系统层面。业务层面我不是很好回答,因为这个业务层面肯定是跟你的业务逻辑有关系的,比如说财务系统和工作流系统,这两个数据要怎么打通?数据打通之后要支持什么样的应用?这些一定是跟你的企业的业务逻辑有强相关性的,它不是一个跟业务逻辑解耦的一件事。所以我没有办法直接说明这个在业务层面怎么操作。 但在系统层面,不根据业务逻辑,一个统一的平台一个接口层可以把一个多元异构的数据。比如说财务系统和工作流系统,甚至可以将两个底层的数据库系统都不一样,财务系统可能用的是一个OLTP的数据库MySQL或者PG,但在工作流系统用的是MongoDB一样的东西,这里面有个解决方案是说可以考虑用数据湖的概念把他们打通,也是我们的一个核心产品,也是业界现在比较火的技术。可以把传统的数据仓库像ADB它是一个云原生的数据仓库和数据湖的概念叠加在一起,可以支持多元异构的建仓然后去做查询和分析。向我们是把ADB和DLA结合起来,像的云原生数据库和云原生数据湖两者结合起来,完美的解决这个问题。DLA可以支持多元异构的数据支持和数据访问,它的特点是数据就可以待在原来的地方,这个是可以考虑的一个方向。

问问小秘 2020-05-22 11:53:09 0 浏览量 回答数 0

回答

分布式中间件 蚂蚁分布式中间件的产品发展路径,一直秉承引领和拥抱业界先进标准和实践,同时亦能满足传统金融架构的平滑迁移、融合适配,以稳妥应对业务升级变更,并积极应对金融交易系统所面临的服务和数据扩展性、事务一致性、秒级容灾、弹性供给与调度等关键技术挑战。 双模微服务 提供实现经典 SDK 模式和 Service Mesh 两种微服务模式所需的各种组件,致力于帮助企业快速构建高可扩展、高性能、低成本、轻量无侵入的分布式系统。 消息队列 在蚂蚁金服关键链路中历经十年实战打磨,是一款具备高可靠、高吞吐量、高可用、事务强一致性、可稳定支撑亿级数据洪峰的金融级消息中间件。 任务调度 提供分布式任务调度框架,实现任务的分布式处理、统一调度和全方位的监控运维管理。 分布式链路跟踪 面向分布式架构、微服务架构和云原生架构的应用可观察性的金融级解决方案,帮助您快速发现并准确定位应用全生命周期的性能问题,具有全链路追踪、简单易用、扩展性强等特点。 多模应用 PaaS 平台 SOFAStack CAFE(Cloud Application Fabric Engine)云应用引擎,提供应用管理、发布部署、运维编排、监控分析、容灾应急等全生命周期管理的PaaS 平台能力,满足金融场景中经典和云原生架构的运维需求,帮助传统架构平滑过渡、保障金融技术风险 。 经典应用服务 基于应用视角、提供基于 VM 模式发布管控的可视化运维管理平台,满足数据中心级别的发布部署需求和灰度能力。 容器应用服务 满足金融级运维场景的云原生容器应用服务,在兼顾标准化一致性 K8S 能力的同时,提供源自蚂蚁实践的全生命周期应用发布部署能力。 监控分析平台 经过蚂蚁场景历练,兼容云原生标准,为大规模、复杂业务场景提供全方位可观测性和洞察分析能力。 研发效能套件 源于蚂蚁金服互联网金融领域研发背景和工程实践的深厚沉淀,为行业数字化转型客户提供金融级一站式智能研发平台,提供敏捷交付和稳妥创新兼顾的研发交付、风险防控和质量保障等能力,赋能金融产品高可用和研发效能的持续提升。 持续交付 基于 Gitflow 工作流的最佳实践,通过组件灵活编排,轻松实现代码扫描、代码评审、自动化测试、自动编译部署等核心功能,以持续交付实践不断提高研发效率。 项目协作 研发协作是一款专为软件研发项目团队打造的简洁、易用、整合的一站式协作平台,以项目为切入点,多维度集成管理需求、任务、缺陷、迭代、看板,提供轻量级支持敏捷开发等多种项目管理的实践方法。

LiuWH 2020-03-24 22:19:17 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

回答

您好,两款产品是不同类型的云产品哈。 MaxCompute是一款云原生、高效能的企业级数据仓库服务。 它构建在阿里云大规模计算、存储资源之上,以Serverless架构提供全托管的在线数据仓库服务,消除了传统数据平台在资源扩展性和弹性方面的限制,并最小化用户的运维投入。MaxCompute支持多种经典计算模型(批处理、机器学习、交互式分析等)和完善的企业管理功能,借助MaxCompute,企业可轻松集成和管理企业数据资产,简化数据平台架构,加速价值实现。 DataWorks(数据工场,原大数据开发套件)是阿里云重要的PaaS平台产品,为您提供数据集成、数据开发、数据地图、数据质量和数据服务等全方位的产品服务,一站式开发管理的界面,帮助企业专注于数据价值的挖掘和探索。 DataWorks为MaxCompute提供一站式的数据同步、业务流程设计、数据开发、管理和运维功能。 温馨提示:MaxCompute可以简拼为MC或MaxC。 如果可以的话,麻烦您把提问的错误拼写修改一下哈。 十分感谢。 如有其他疑问,您可以加入MaxCompute开发者社区钉群进行咨询。点击加入

亢海鹏 2020-07-02 16:45:55 0 浏览量 回答数 0

回答

阿里巴巴小马哥:个⼈对 Service Mesh 的看法是乐观偏谨慎的,一⽅⾯,作为从业人员,对于技术总有猎奇的心态。另外一⽅⾯,这个技术在设计上存在一些理想主义,比如,性能损耗以及稳定性,并且分布式场景中的典型问题并没有得到解决和改善,比如数据一致性、分布式事务等。 据我所知,国内不少的互联⽹公司,如阿⾥巴巴、蚂蚁⾦服以及美团等已经开始在生产环境试点 Service Mesh,听起来这是一件好事。前沿的技术总需要有⼈去探险,如果成功,前人栽树,后人乘凉。至于它能否成功,主要看市场是否愿意买单。 美团吴革:未来 Service Mesh 会在跨语言场景下大放异彩。Service Mesh 主要是基于云平台和多技术栈场景下的痛点进行的开发,短时间内不会有爆发性的增长。但是基于原生云架构系统的增多,未来 Service Mesh 会不断演进,最终变为云原生架构下的网络基础服务。 腾讯单致豪:Service Mesh 目前还处在早期发展阶段,其理念设计已经决定了性能及维护性上会是它最突出的短板。但有部分企业包括腾讯已经尝鲜,也有小量周边不重要非核心业务在上面跑。Service Mesh 有着优美的架构理念,但性能确实让人担忧,社区生态也至少需要三年以上的发展时间。 华为田晓亮:大环境来看,传统企业面临的挑战依然是业务系统如何向微服务转型,以构建自己的业务平台,在这其中微服务框架是一种手段。为了寻求更快速地微服务化,开发人员就会避免学习陡峭的开发框架,而转向使用 Service Mesh。开发者将结合轻量的 SDK(例如对接监控系统、配置管理、AI 平台,而不是微服务框架)与 Service Mesh 来实现自己的业务系统,从繁重的架构工作中解放出来。这个发展历程在我看来大概需要 2-3 年的时间。 而且,在我看来,最终站上舞台的并不是 Service Mesh,而是底层由 Service Mesh 提供支持的 Serverless 平台,用户感知不到 Service Mesh 技术的复杂性,否则将面临比开发框架更繁重的基础设施运维挑战。所以 Service Mesh 其实和 Serverless 的发展是绑定在一起的。Serverless 的普及和使用必然会帮助 Service Mesh 进行发展。

游客pklijor6gytpx 2019-12-02 03:11:40 0 浏览量 回答数 0

回答

• 强大的实时处理能力 阿里云实时计算集成诸多全链路功能,方便您进行全链路实时计算开发,包括: o 强大的流计算(实时计算)引擎。  阿里云实时计算提供Flink SQL(详情请参见Flink SQL概述),支持各类错误场景的自动恢复,保证故障情况下数据处理的准确性。  支持多种内置函数,包括:字符串函数、日期函数、聚合。  精确的计算资源控制,高度保证您的作业的隔离性。 o 关键性能指标为开源Flink的3到4倍。数据计算延迟优化到秒级甚至亚秒级。单个作业吞吐量可达到百万(记录/秒)级别,单集群规模达到数千台。 o 深度整合各类云数据存储。阿里云实时计算可以直接读写包括数据总线DataHub、日志服务LOG、云数据库RDS版、表格存储TableStore、分析型数据库MySQL版在内的各类数据存储系统,无需进行额外的数据集成工作。 • 托管的实时计算服务 不同于开源或者自建的流式处理服务,阿里云实时计算是完全托管的流式计算引擎。阿里云可以针对流数据运行查询,无需预置或管理任何基础设施。在阿里云实时计算,您可以享受一键启用的流式数据服务能力。阿里云实时计算天然集成数据存储、数据开发、数据运维、监控报警等功能,方便您以较小成本试用和迁移流式计算。同时,实时计算提供完全租户隔离的托管运行服务。从最上层工作空间,到最底层执行机器,提供高度有效的隔离和全面防护,让您放心使用实时计算。 • 低廉的人力和集群成本 大量优化的SQL执行引擎,提供比原生Flink作业更高效且更廉价的计算作业。在开发成本和运行成本方面,阿里云实时计算均要远低于开源流式框架。例如,项目预算时您需要考虑如下成本: o 编写一个复杂业务逻辑下Flink作业Java代码的人力成本。 o 针对作业的调试、测试、调优、上线工作成本。 o 后续长期用于Flink、Zookeeper等开源软件的运维成本。 如果使用阿里云实时计算服务,上述问题交由阿里云平台承担,您可以专注于业务。

LiuWH 2020-03-22 16:57:39 0 浏览量 回答数 0

回答

• 以应用为核心视角的 DevOps:提供应用全生命周期的 DevOps 自动化支持,将传统的以 IT 资源为核心的管理视角转换成以应用、业务为核心视角,使用户可以专注于业务价值的同时,提升研发效率、降低人为出错的可能。 • 可定制的自动化运维:以自定义的技术栈方案,为用户提供可定制的自动化运维,提升了云平台的灵活性和对用户存量系统的兼容支持性,方便用户在平台上使用自己熟悉的、非 SOFAStack 原生提供的技术框架。 • 强大的发布部署能力:提供分组发布、Beta 发布、灰度发布、单机房发布、蓝绿发布等多种灵活的部署策略,从各种需求层面,支持可视化、自动化、可重试、可回滚的发布部署。 • 灵活的运维管道能力:提供录入,执行用户自定义的运维命令和脚本通道,方便用户做自定义的运维指令操作。

LiuWH 2020-03-24 22:26:55 0 浏览量 回答数 0

回答

招募集合贴 | 有需求即随时更新 职责描述: 1、负责研发日常工作任务跟进; 2、负责公司系统新功能的开发,以及原有功能的维护; 3、根据需求文档完成相应的文档以及相应的开发; 4、协助产品部完成系统的规划,需求分析; 5、协助前端设计师完成系统的前端设计; 6、协助架构设计师完成系统的总体; 7、负责某个具体模块的设计、开发、单元测试、维护; 8、配合其他软件工程师共同完成某个模块或多个模块的设计、开发、单元测试、维护。 职位要求: 1、计算机相关专业本科及以上学历,4年以上的J2SE/J2EE实际开发经验;(全日制统招,学信网可查) 2、有一定的项目架构设计能力,能协助架构师搭建架构; 3、能独立封装组件、设计服务能力、并且能协助同事设计与开发; 4、熟练掌握OO的编程思想; 5、熟悉Java设计模式,以及UML的设计; 6、熟练掌握Spring,springBoot springCloud,myBatis/iBatis等开源框架;(主要使用springboot微服务框架) 7、熟练使用Eclipse Java IDE开发工具,熟悉 Tomcat,Resin等Web Server; 8、熟悉关系型数据库,有使用Oracle,Mysql的实际经验; 工作地点:蛇口网谷(2号线水湾) 工作时间:周末双休,早九晚六 薪酬:18-23K,十三薪,提供两餐 邮箱:hr.tech@ascend-global.com 阿里巴巴2020春季实习生求职意向表 一份好的工作,从实习开始,想要和大神一起共事,闲来无事一起探讨技术二三事吗?想要一毕业就就能拿出优秀的简历,让各个大厂争相送你offer吗?想要接受良好工作环境、实习期甩开同学们吗? 阿里2020春招实习生~值得申请 https://survey.aliyun.com/apps/zhiliao/jztLGve0?spm=a2c6h.14062461.J_1935739830.1.585b33e1EEaMqr 阿里校招+社招 业务团队-淘系技术部–多媒体算法团队-视频语义理解算法工程师/专家 我们团队依托淘系数十亿级的视频数据,有丰富的业务场景和技术方向! 我们持续以技术驱动产品和商品创新,不断探索和衍生颠覆型互联网新技术,技术成果获得国家科技进步二等奖! 我们不断吸引机器学习、视觉算法、音视频通信、端侧智能等领域人才加入,让科技引领面来未来的商业创新和进步! 岗位详情信息请查看https://tianchi.aliyun.com/forum/postDetail?spm=a2c6h.12873639.0.0.332bb953TEhTTr&postId=94418 简历请发送至andy.ybm@alibaba-inc.com,主题请注明社招/校招 饿了吗本地生活招聘了哦 阿里巴巴淘宝搜索推荐算法团队急招,绿色通道,直接面试 划重点:本人来自阿里巴巴淘宝搜索推荐算法团队,是整个阿里集团非常核心的团队,由于现在要启动大项目,实习hc特别多!!!有兴趣的朋友赶紧把简历投过来,保证1小时内回复!实习生有机会直接转正 岗位详情信息查看:https://tianchi.aliyun.com/forum/postDetail?spm=a2c6h.12873639.0.0.332bb953pkKhYQ&postId=88676 简历投递邮箱:xuming.panxm@alibaba-inc.com,格式【实习/校招-姓名】 阿里集团-阿里云智能事业群-阿里云-基础设施事业部-天基-集群智能运维团队校招 团队使命:为集团各大规模分布式服务和Web应用运维提供统一的基础架构、技术和人工智能服务。团队专注于提供一站式,自动化,智能化的资源服务开通,管控和运维能力。通过采用先进的人工智能系统和算法,实时监控和分析各类系统数据,并联动各相关系统进行运维操作,形成数据分析和反馈的完整闭环链路,持续优化集团资源运营和服务运维决策。天基团队的使命是为阿里巴巴各业务场景提供智能,快速,高效,稳定的DevOps平台,支撑和保障阿里巴巴全球化发展战略。 岗位详情信息查看:https://tianchi.aliyun.com/forum/postDetail?spm=a2c6h.12873639.0.0.332bb953zJzaiJ&postId=94133 投递邮箱:jiongzhou.ljz@alibaba-inc.com, mars.ly@alibaba-inc.com 阿里巴巴达摩院-语言技术实验室 [校招+实习生招聘] 我们是阿里巴巴达摩院语言技术实验室基础技术团队,致力于研究词法、句法、多语言、知识库建设等基础技术,并应用到文本挖掘技术(分类、聚类、情感、问答)以及相关业务(搜索、推荐、客服机器人、国际化等)中,全面支持阿里经济体相关应用的需求,提供的nlp服务目前每日调用超过万亿次。我们努力提升技术、驱动商业,目标是成为最有价值的商业自然语言基础技术团队。 我们在寻找自然语言处理相关校招生和实习生,一起深入探索文本背后的含义,挑战业界难题,提升阿里巴巴产品体验,服务亿万用户。 岗位详情信息查看:https://tianchi.aliyun.com/forum/postDetail?spm=5176.12282029.0.0.424425d0xxSL3d&&postId=94412 投递邮箱: chuanqi.tcq@alibaba-inc.com 阿里安全-智能认知/NLP团队招聘[校招+实习生] 自2009年成立集团安全部​以来,阿里安全就在随着业务升级和拓展,不断探索创新的安全技术能力,以及世界级的安全风险防御体系,保护阿里巴巴经济体内消费者和整个生态伙伴的安全。https://s.alibaba.com我们 智能认知团队 每天需要处理阿里经济体中海量商品、海量内容的各种风险,以及保障各业务中的数据安全,正在招聘此方向的优秀人才。 岗位详情信息:https://tianchi.aliyun.com/forum/postDetail?spm=5176.12282029.0.0.424425d0xxSL3d&&postId=94494 投递邮箱:stone.zhangr@alibaba-inc.com 阿里云-云原生应用平台基础技术中台招聘-社招-21届校招 云原生应用平台致力于打造稳定、标准、先进的云原生平台,推动行业面向云原生技术升级与革命。在这里,你将与来自云计算、大数据领域的顶尖技术专家亲密合作,在全球独一无二的场景与规模中从事 Kubernetes、Service Mesh、Serverless、Open Application Model(OAM)、Cloud Native Microservices 、OpenMessaging、Event Streaming等云原生生态核心基础技术及 Apache Dubbo,Apache RocketMQ, Nacos,Arthas 等顶级开源项目的研发与落地工作。在标杆级的平台上,既服务阿里巴巴全球经济体,更服务全世界的开发者用户。 岗位详情介绍:https://tianchi.aliyun.com/forum/postDetail?spm=5176.12282029.0.0.424425d0xxSL3d&&postId=94430 请以附件的方式发送pdf版简历至 xiangsheng.gh@alibaba-inc.com 邮件标题:云原生应用平台简历-{姓名} 阿里云-弹性计算招聘-社招-2020届校招 今年阿里云弹性计算实习生内推即将启动,我们是阿里云智能最核心的部门,在这里你将体验极致性能和架构的挑战,海量的数据,最前沿的算法问题挑战,简历亲自review,保障专人跟进,请对弹性计算感兴趣的同学发送简历给我们,直接内推进入系统。邮箱:chao.qianc@alibaba-inc.com 岗位详情信息:https://tianchi.aliyun.com/forum/postDetail?spm=5176.12282029.0.0.424425d0xxSL3d&postId=94508 阿里云-数据智能-基础产品研发-社招/2021届校招 基础产品研发团队为部门提供数据中台技术与产品,利用AI平台、数据分析与决策、数据可视化、知识图谱等技术为用户和ISV提供先进、高效的产品与工具,为“智能+”战略的落实提供卓越的基础设施。 作为后端研发专家,你将主要负责阿里云数据中台服务器端的研发工作,内部包括AI平台、数据分析与决策、数据可视化、知识图谱等多个领域方向的技术创新的研发工作,在这里你将致力于让“数据智能”普惠到各行各业,让行业用户也能拥有阿里巴巴强大的基于数据的分析、决策、展现能力。加入我们,共创产业AI, 让各行各业拥有智慧的大脑! 招聘岗位: Java后端工程师、前端工程师、大数据开发工程师、算法工程师 投递邮箱:jianxun.zxl@taobao.com 岗位详情请查看:https://tianchi.aliyun.com/forum/postDetail?spm=5176.12282029.0.0.424425d0xxSL3d&&postId=94734 2020淘宝技术部消息中台团队校招火热 岗位详情信息,请查看:https://tianchi.aliyun.com/forum/postDetail?spm=5176.12282029.0.0.424425d0xxSL3d&postId=94370 【阿里巴巴】【2021校招】【极速响应】【100%转正】阿里云-大数据&AI-团队直招 岗位详情信息,请查看:https://tianchi.aliyun.com/forum/postDetail?spm=a2c6h.12873639.0.0.332bb953ymPQtN&postId=94935

问问小秘 2020-04-01 18:18:22 0 浏览量 回答数 0

问题

阿里云中间件是什么

搞么罗 2019-12-01 21:51:58 1418 浏览量 回答数 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

回答

Serverless 应用引擎 SAE(Serverless App Engine)是面向应用的 Serverless PaaS 平台,能够帮助 PaaS 层用户免运维 IaaS、按需使用、按量计费,做到低门槛微服务应用上云。相对于其他 Serverless 产品,它抽象了应用的概念,并提供了一整套微服务解决方案,支持 Spring Cloud、Dubbo、HSF 等主流的微服务开发框架,实现了 Serverless 架构和微服务架构的完美结合。 产品架构 SAE 产品架构图如下所示。 SAE产品架构 底层基于 Kubernetes,实现了 Serverless 架构与微服务架构的完美结合。 支持 Spring Cloud、Dubbo、HSF 多种微服务框架、多种部署渠道(UI、云效、插件等)、多种部署方式(WAR 包、JAR包、镜像)。 说明 应用的源码管理与CI/CD集成暂不支持,敬请期待。 多方式部署应用 支持 Spring Cloud、Dubbo、HSF 等主流开发框架,支持零代码改造迁移到 SAE。您可以通过 WAR 包、JAR 包和镜像等多种方式部署应用。 命名空间 以应用的服务调用与分布式配置推送为视角,提供逻辑隔离的运行环境。例如使用命名空间隔离开发、测试和生产环境等不同环境。 配置管理 提供白屏化的分布式应用配置管理、订阅和动态推动能力,可以基于命名空间在不同环境间进行配置的隔离和同步。 服务注册调用 提供分布式架构的服务注册、调用功能,并提供服务列表可查询。 应用托管 提供一键式白屏化的应用生命周期管理能力,简化运维。 应用生命周期管理 提供了云应用从部署到运行的整个生命周期管理服务,包括应用的部署、启停、升级和扩缩容等。 一键启停开发测试环境 一键启停开发、测试和预发等环境的应用,即开即用,大幅降低闲置资源成本。 负载均衡 集成阿里云 SLB 产品,提供应用被公网访问、VPC 内其它应用访问的能力。 多发布策略 支持分批、灰度等多种发布策略,能够快速实现新版本的小规模验证,支持云应用快速迭代以及异常时一键回滚。 健康检查 支持应用实例存活检查和应用业务就绪检查两种健康处理策略,判断容器和用户业务是否正常运行,确保您的应用健康运行。 弹性伸缩 支持定时弹性伸缩和 CPU 和内存监控指标弹性伸缩,从容应对业务高峰期的突发流量洪流。 应用事件查看 支持查看 K8s 原生的事件,帮助您了解应用运行时的状态,方便快速聚焦问题。 NAS 存储 通过 NAS 存储持久化应用实例的数据、日志。 监控管理 通过多样化的监控分析能力,为您的应用运行时保驾护航。 日志管理 支持高性能日志采集,提供实时的标准输出日志,方便定位业务问题。 系统监控 提供系统级别的监控,如 CPU、内存、网络等。 应用监控 提供面向应用的实时监控,如 QPS、RT、接口调用量、错误数等。帮助您快速聚焦问题,发现系统瓶颈,大幅度提升诊断问题的效率。

1934890530796658 2020-03-27 11:54:37 0 浏览量 回答数 0

回答

传统应用微服务改造 通过微服务产品将传统金融业务系统拆分为模块化、标准化、松耦合、可插拔、可扩展的微服务架构,可缩短产品面世周期,快速上架,抢占市场待机,不仅可确保客户服务的效率,也降低了运营成本。 • 开发简单 提供高性能微服务框架,轻松构建原生云应用,具备快速开发,持续交付和部署的能力。 • 管理简单 框架自带服务治理能力,使用门槛低,可轻松管理成千上万个服务实例,保障服务高质量运行。 • 接入门槛低 完全托管的 SaaS 服务,轻资产,且无需自己部署及运维,有效降低投入成本。 高并发业务快速扩展 通过微服务产品开发互联网金融业务可提高研发效率,更灵活地响应业务变化,快速迭代创新产品,并针对热点模块进行快速扩展来提高处理能力,轻松应对突发流量,同时提高用户体验,为更多小微客户提供个性化的金融产品和交易成本较低的便捷金融服务。 • 高性能 提供基于事件驱动的架构以及自研二进制通信协议,轻松搭建低延迟、高吞吐的服务。 • 可扩展性强 支持无限水平扩展,无性能、容量瓶颈,在蚂蚁金服内部已支撑数万个节点规模的分布式应用架构。 • 可视化管理 在分布式系统中,面对爆发式增长的应用数量和服务器数量,提供图形化的集中式管理平台,简单易用,学习成本低。 多数据中心异地多活 通过微服务产品可快速构建高可扩展、高性能的金融级分布式核心系统,拥有弹性扩容和异地多活的能力,实现技术安全自主可控,突破业务发展瓶颈,并减少开发及运维成本。实现轻型银行,助力业务快速发展和持续创新。 • 异地多活 支持同城双活/异地多活架构,具备异地容灾能力。 • 弹性扩容 支持应用级,数据库级,机房级、地域级的快速扩展。 • 自主可控 基于支付宝的业务迭代衍生完全自主研发,产品拥有完全自主知识产权,自身开源开放,并兼容开源生态。

LiuWH 2020-03-24 22:35:22 0 浏览量 回答数 0

问题

云效平台——基于jmeter的轻量级性能测试平台

云效平台 2019-12-01 21:46:58 24033 浏览量 回答数 2

回答

外卖app,我用美团来举例子吧:美团APP是目前国内最牛的一款聚合了吃、住、行、游、购、娱为一体的综合服务类APP,为消费者提供本地生活一站式O2O服务,覆盖电影、美食、酒店、外卖等多种品类。由于美团打造这样一个平台是由几百上千人研发团队,经过几年的反复迭代才得以完成的,总的研发投入少则几千万,多则会上亿元人民币,那么对于一个创业团队如果想要打造一款类似美团的APP软件,需要投入多少资金呢?如果采用常规的原生开发模式,至少需要配备云端后台开发工程师、Android开发工程师,iOS开发工程师、项目经理、产品经理、UI设计师以及测试人员等8-10人软件研发团队,估计开发周期至少需要6-12个月,如果平均工资按2.0万元/人月计算,至少开发费用也需要96-240万元人民币。因此采用原生开发模式从零开始开发这样一款APP至少需要上百万的资金投入,即使您有充足的资金可以投入,但是如果您的开发团队没有丰富的O2O移动电商APP的开发经验,也会存在很大的开发失败风险,导致您的前期研发投入打水漂,那么是否还有更好的方法可以低成本零风险地快速搭建类似美团的APP平台哪?答案是肯定的,目前在国内有一个长期专注O2O中间件平台研发的团队,已经成功推出了一款名为:O2O商圈的新零售移动电商中间件平台,它可以快速搭建吃、住、行、游、购、娱各种品类的本地生活服务和新零售移动电商的APP应用,速度快成本低,开发周期从原本的几个月缩短到1-2周时间,开发成本降到传统开发模式的1/10,大幅提升了开发效率,也大幅度降低了创业者的试错成本和前期风险,利用这种高科技的新零售移动电商中间件产品,可以助力传统中小实体企业零门槛低风险快速地转型新零售,快速搭建起属于自己品牌的新零售移动电商应用,避免企业重复投入造成浪费,解决传统实体企业转型新零售过程中的人才和技术匮乏的痛点,助力传统企业快速转型成功,为每个企业都可以节省几十万到上百万的APP研发成本,同时还可以节省业务转型过程中的时间成本和试错成本,让每个团队或企业都能快速找到适合自己的方法和路径,实现自己的创业梦想!文章参考:http://www.kmyunruan.com/

yangxuruio 2019-12-02 01:51:43 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

回答

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

回答

前言 随着计算机技术和 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

问题

使用HTTPDNS时该如何API访问

猫饭先生 2019-12-01 21:51:27 1353 浏览量 回答数 0

问题

安卓与iOS百问,开发者系统指南

yq传送门 2019-12-01 20:14:48 27317 浏览量 回答数 26

问题

【精品问答】性能测试 PTS

montos 2020-04-08 13:18:48 2 浏览量 回答数 1

问题

学术界关于HBase在物联网/车联网/互联网/金融/高能物理等八大场景的理论研究

pandacats 2019-12-18 16:06:18 1 浏览量 回答数 0

问题

荆门开诊断证明-scc

游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

问题

SaaS模式云数据仓库MaxCompute 百问百答合集(持续更新20200724)

亢海鹏 2020-05-29 15:10:00 8355 浏览量 回答数 1

回答

回 1楼(liam_fantasy) 的帖子 您好, 如果忽略以上内容的信息提示,可以顺利完成其它步骤吗? ------------------------- 回 5楼(hengic) 的帖子 您好, 我没有直接的判断经验,但我可以尝试迟些为您在Debian 7 的测试机里试试。 ------------------------- 回 5楼(hengic) 的帖子 您好, 我在阿里云公共镜像里的Debian 7 64位测试,好象可以。 您在配置了 he-ipv6 接口后,有没有重启网络服务(service networking restart)? ------------------------- 回 8楼(hengic) 的帖子 您好, 请问您使用的Web是哪种软件呢,是nginx吗? 有的Web默认不监听IPv6的端口喔。 您可以使用 netstat 的命令,或检查一下Web的配置文件,确认除了IPv4的80端口外,是否在IPv6的端口也有监听喔。 ------------------------- 回 10楼(hengic) 的帖子 您好, 按照apache的说明文档,或许您需要在配置文件中添加一个类似这样的内容: http://httpd.apache.org/docs/current/bind.html Listen [2001:470:18:898::2]:80 然后您在系统中能查看到tcp6的80端口也是在监听状态。 ------------------------- 回 14楼(三少.) 的帖子 您好, 欢迎来到阿里云论坛。 请问您在什么系统上尝试配置IPv6隧道地址上遇到疑问了呢?是CentOS 6系统吗? ------------------------- 回 16楼(ahy) 的帖子 您好, 欢迎来到阿里云论坛。 如上图,个人觉得算是成功了。 ------------------------- 回 18楼(weiykj胡伟) 的帖子 您好, 欢迎来到阿里云论坛。 是和哪位遇到的现象差不多呢,是16楼吗? ------------------------- 回 20楼(hlq) 的帖子 您好, 欢迎来到阿里云论坛。 请问您在系统里,能看到IPv6的隧道地址,能否ping通本地的测试地址::1呢? ::1 ------------------------- 回 28楼(magicmoment) 的帖子 您好, 个人来看,如果前两项测试成功,那应该可以了。 是的,有时可能境内的公共网络无法访问IPv6的地址。 ------------------------- 回 30楼(leonandandy) 的帖子 您好, 应该是 Client IPv6 Address。 ------------------------- 回 32楼(评心静气) 的帖子 您好, 您是想让80端口在tcp6上监听吗? 请问您使用的是哪种Web呢?是nginx,apache? ------------------------- 回 36楼(评心静气) 的帖子 您好, 好象我通过 wget -6 的命令来测试,能获取到您的站点首页(ok的内容): root@los:~/test# wget -6 [ http://apiv.beloved999.com] [ http://apiv.beloved999.com]: Scheme missing. root@los:~/test# wget -6 http://apiv.beloved999.com converted 'http://apiv.beloved999.com' (ANSI_X3.4-1968) -> 'http://apiv.beloved999.com' (UTF-8) --2016-09-29 00:14:06--   http://apiv.beloved999.com/ Resolving apiv.beloved999.com (apiv.beloved999.com)... 2001:470:39:4a6::2 Connecting to apiv.beloved999.com (apiv.beloved999.com)|2001:470:39:4a6::2|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: 'index.html' index.html                       [ <=>                                            ]       2  --.-KB/s   in 0s 2016-09-29 00:14:08 (107 KB/s) - 'index.html' saved [2] ------------------------- 回 37楼(leonandandy) 的帖子 您好, 如果提示 No route to host ,那可能漏掉了例子中的某一步了,如是否曾成功执行以下的这条命令呢? ip route add ::/0 dev he-ipv6 ------------------------- 回 41楼(评心静气) 的帖子 您好, 首先要确认您使用wget所在的系统里是支持IPv6的喔。 ------------------------- 回 44楼(关关007) 的帖子 您好, 我在外网ping不通您的ipv6地址喔,请问您的ubuntu是否有设置了防火墙呢? root@los:~# ping6 ipv6.playalot.cn PING ipv6.playalot.cn(guanguan007-1-pt.tunnel.tserv22.tyo1.ipv6.he.net) 56 data bytes --- ipv6.playalot.cn ping statistics --- 51 packets transmitted, 0 received, 100% packet loss, time 50006ms ------------------------- 回 46楼(关关007) 的帖子 您好, 一般在ECS里,可能有两个因素会影响到: a. 系统的防火墙,如iptables b. ECS的安全组, https://help.aliyun.com/document_detail/25471.html ------------------------- 回 48楼(关关007) 的帖子 您好, 从现有的帮助说明文档来看,好象“安全组”目前仅支持IPv4。 您可以尝试完全关闭iptables的服务后,再对比结果。 ------------------------- 回 50楼(kevin0317) 的帖子 您好, 从图中信息来看,看起来,apache已经在ipv6的80端口上监听了(:::80)。 但我现在从一个香港的机子上,ping不通您的 2001:470:c:b30::2 地址 。 root@hk:~# ping6 ipv6.google.com PING ipv6.google.com(tg-in-x66.1e100.net) 56 data bytes 64 bytes from tg-in-x66.1e100.net: icmp_seq=1 ttl=47 time=22.4 ms 64 bytes from tg-in-x66.1e100.net: icmp_seq=2 ttl=47 time=22.1 ms 64 bytes from tg-in-x66.1e100.net: icmp_seq=3 ttl=47 time=22.4 ms --- ipv6.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 22.129/22.336/22.442/0.146 ms root@hk:~# ping6 2001:470:c:b30::2 PING 2001:470:c:b30::2(2001:470:c:b30::2) 56 data bytes --- 2001:470:c:b30::2 ping statistics --- 8 packets transmitted, 0 received, 100% packet loss, time 7000ms ------------------------- 回 54楼(kevin0317) 的帖子 您好, 感谢您的更新回复喔。 ------------------------- 回 56楼(hancock99) 的帖子 您好, 请问您已经完成操作步骤的第一步了吗? 您的操作系统是 CentOS 7 吗? ------------------------- 回 59楼(dianjilv) 的帖子 您好, 欢迎来到阿里云论坛。 当您看到形如下边的监听状态时,很可能,nginx已经在tcp6的80端口上监听了喔。 tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      22458/nginx           tcp        0      0 :::80                       :::*                        LISTEN      22458/nginx   因为第一行中的0.0.0.0可以理解监听tcp4的80端口,而第二行:::表示监听tcp6的80端口。这可能是因为系统版本不同,有的系统没有显示tcp6的字样,但形如::开头的IP,应该是表示ipv6的。 我现在用lynx并不能打开:http://[2001:470:35:10f6::2]/ root@hk:~# lynx [2001:470:35:10f6::2] Looking up  '[2001:470:35:10f6::2]' first Looking up [2001:470:35:10f6::2] first Looking up [2001:470:35:10f6::2] Making HTTP connection to [2001:470:35:10f6::2] Alert!: Unable to connect to remote host. lynx: Can't access startfile http://[2001:470:35:10f6::2]/ ------------------------- 回 61楼(dianjilv) 的帖子 您好, 如果事情不急,是可以再等等。 如果急,也可以直接找原生支持Ipv6的环境,如美国的机子。 ------------------------- 回 63楼(dianjilv) 的帖子 您好, 看具体的需求啰。 假如您的主站,是国内用户访问的,那就首选阿里云国内的地域啊。 您的子站,如下载或需要使用IPv6,主要是国外用户访问的,那可以综合考虑,看除了阿里云,是否还存在更佳的选择。 虽然阿里云整体上已经很好了,但如国内大环境IPv6条件还不成熟的前提条件下,或许客户需再特殊考虑一下。 ------------------------- 回 65楼(eason_zhang) 的帖子 您好, 请问您的系统版本是 CentOS 7 吗? ------------------------- 回 66楼(一直在等) 的帖子 您好, 好象 nginx 提示您在当前的平台上,不支持ipv6。 您能ping通本地的IPv6地址吗(::1)? ------------------------- 回 69楼(eason_zhang) 的帖子 您好, 本帖子的例子,是在CentOS 7 版本上测试完成的,可能并不适合 CentOS 6 的环境喔。 如果您目前还没有在 CentOS 6 里配置好Ipv6,我也可以为您找机子来测试一下。 ------------------------- 回 71楼(eason_zhang) 的帖子 您好, 好哩。我现在为您试试。 如果完成测试,会在帖子里回复您。 ------------------------- 回 74楼(eason_zhang) 的帖子 您好, 抱歉让您久等了。 为您写了一个例子的帖子,希望能帮得上您:《为阿里云ECS(CentOS6)配置IPv6隧道地址》 - https://bbs.aliyun.com/read.php?tid=299254 ------------------------- 回 77楼(yongzhang52545) 的帖子 您好, 欢迎来到阿里云论坛。 我为您找找资料。请稍等。 ------------------------- 回 77楼(yongzhang52545) 的帖子 您好, 为您写了这一个例子帖子,希望对您有用喔:《在CentOS 7系统里设置开机自动执行脚本systemd》 - https://bbs.aliyun.com/read.php?tid=301042 ------------------------- 回 82楼(木头2121) 的帖子 您好, 如果提示网络访问失败,那可能没有成功在系统里设置好IPv6隧道地址喔。 您在系统里运行 ifconfig 查看有IPv6的隧道地址信息吗? ------------------------- 回 84楼(木头2121) 的帖子 您好, 截图上传,可能因为宽度过长,论坛程序为了整体的美观,自动降低相素和比例了,但下载后看是您原来上传的尺寸大小,不影响查看图片内容的。 ipv6-test.com 里的第三项是检查项目应该是 ipv6-only 的,这不符合现有的环境,国内ipv6的环境还不成熟。但如果通过第一和第二项,应该不影响您基本使用,如可通过苹果对于APP要有有效ipv6地址访问的要求。 ------------------------- 回 86楼(木头2121) 的帖子 您好, 有可能是因为HE免费提供的隧道网络(如果您选择的是香港的节点),互联可能不是很流畅。 ------------------------- 回 88楼(木头2121) 的帖子 您好, 这么奇怪? 如果要一直ping,或许您可用个screen在后台跑着。 我个人是仅用于测试,当时选择的是HE香港的节点。 ------------------------- 回 90楼(热尔特人) 的帖子 您好, 如果您的系统里没有 he-ipv6 的虚拟网卡,可能在本地都不能使用ipv6的环境喔, 您运行 ping6 ::1 ,会有什么样的结果呢? ------------------------- 回 92楼(热尔特人) 的帖子 您好, 如果能ping通本地的::1地址, 请问能否ping通您申请到的IPv6隧道地址(如2001:470:18:401::2 这样的), 或能否ping通外网的IPv6地址,如 ping6 ipv6.google.com ? ------------------------- 回 94楼(热尔特人) 的帖子 您好, 请问您的系统确认是CentOS 7版本的吗? 我照着例子重新操作了一次,正常的喔。 [root@iZ23jyp275rZ php]# ip -6 routeunreachable ::/96 dev lo  metric 1024  error -101unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -101200:2:9f6a:794b:: dev he-ipv6  metric 0    cache2001:470:18:401::/64 dev he-ipv6  proto kernel  metric 256unreachable 2002:a00::/24 dev lo  metric 1024  error -101unreachable 2002:7f00::/24 dev lo  metric 1024  error -101unreachable 2002:a9fe::/32 dev lo  metric 1024  error -101unreachable 2002:ac10::/28 dev lo  metric 1024  error -101unreachable 2002:c0a8::/32 dev lo  metric 1024  error -101unreachable 2002:e000::/19 dev lo  metric 1024  error -101unreachable 3ffe:ffff::/32 dev lo  metric 1024  error -101fe80::/64 dev eth0  proto kernel  metric 256fe80::/64 dev eth1  proto kernel  metric 256default dev he-ipv6  metric 1024[root@iZ23jyp275rZ php]# ping6 ipv6.google.comPING ipv6.google.com(tsa03s01-in-x0e.1e100.net) 56 data bytes64 bytes from tsa03s01-in-x0e.1e100.net: icmp_seq=1 ttl=55 time=389 ms64 bytes from tsa03s01-in-x0e.1e100.net: icmp_seq=2 ttl=55 time=390 ms [root@iZ23jyp275rZ php]# ifconfigeth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500        inet 10.117.40.202  netmask 255.255.248.0  broadcast 10.117.47.255        inet6 fe80::216:3eff:fe00:3e22  prefixlen 64  scopeid 0x20<link>        ether 00:16:3e:00:3e:22  txqueuelen 1000  (Ethernet)        RX packets 19203  bytes 27666872 (26.3 MiB)        RX errors 0  dropped 0  overruns 0  frame 0        TX packets 5745  bytes 339979 (332.0 KiB)        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500        inet 121.43.110.72  netmask 255.255.252.0  broadcast 121.43.111.255        inet6 fe80::216:3eff:fe00:1a3b  prefixlen 64  scopeid 0x20<link>        ether 00:16:3e:00:1a:3b  txqueuelen 1000  (Ethernet)        RX packets 204694  bytes 278187033 (265.2 MiB)        RX errors 0  dropped 0  overruns 0  frame 0        TX packets 67036  bytes 10194365 (9.7 MiB)        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0he-ipv6: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1480        inet6 fe80::792b:6e48  prefixlen 128  scopeid 0x20<link>        inet6 2001:470:18:401::2  prefixlen 64  scopeid 0x0<global>        sit  txqueuelen 0  (IPv6-in-IPv4)        RX packets 18  bytes 1592 (1.5 KiB)        RX errors 0  dropped 0  overruns 0  frame 0        TX packets 19  bytes 1360 (1.3 KiB)        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536        inet 127.0.0.1  netmask 255.0.0.0        inet6 ::1  prefixlen 128  scopeid 0x10<host>        loop  txqueuelen 0  (Local Loopback)        RX packets 102  bytes 9177 (8.9 KiB)        RX errors 0  dropped 0  overruns 0  frame 0        TX packets 102  bytes 9177 (8.9 KiB)        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 ------------------------- 回 96楼(热尔特人) 的帖子 您好, 当您能ping通ipv6.google.com时,应该说明ipv6的隧道地址已经设置好了, 这个时候,如果测试您的站点还不能通过ipv6隧道地址访问,您得检查一下Web服务是否在ipv6的地址是监听喔(如运行 netstat -noa | grep 80 的命令查看一下)。 当您重启网络服务或重启系统后,ipv6的隧道地址已经失效了的,因为这个环节的命令仅当次有效的,请参考: https://bbs.aliyun.com/read/301042.html ------------------------- 回 98楼(热尔特人) 的帖子 您好, 您要将域名设置AAA记录到 2001:470:18:a8b::2 而不是 fe80::216:3eff:fe00:54f9 喔: # curl [2001:470:18:a8b::2] -so - | grep -iPo '(?<=<title>)(.*)(?=</title>)' LNMP一键安装包 by Licess ------------------------- 回 100楼(热尔特人) 的帖子 您好, 您可以按之前的步骤,一步步来排查呢。 如可以先检查本地的IPv6隧道地址设置是否正常,Web监听状态是否正常。 ------------------------- 回 103楼(taihehaode) 的帖子 您好, 欢迎来到阿里云论坛。 在网上找到两条命令,您可以试试: firewall-cmd --permanent --zone=public --add-port=80/tcp假如您默认的区域是  public ,现在需放行 80 的 tcp 端口。 之后,再用 reload 的命令重新加载下 firewalld: firewall-cmd --reload 参考: http://www.codero.com/knowledge-base/content/10/377/en/how-to-manage-firewall-rules-in-centos-7.html ------------------------- 回 108楼(ffffffffffffv) 的帖子 您好, 看您的最后的一个截图, IPv6隧道地址的站点,已经可以访问了喔,恭喜。 ------------------------- 回 110楼(taihehaode) 的帖子 您好, 对于CentOS 7里的firewalld防火墙设置例子,可看一下第104楼回帖里的内容喔。 ------------------------- 回 112楼(taihehaode) 的帖子 您好, 抱歉延时回复。 请问您已经解决问题了吗? ------------------------- 回 113楼(网际码工) 的帖子 您好, 抱歉延时回复, 请问在您的应用环境里,除了nginx,还有其它Web服务软件吗? 一般来说,nginx默认是使用80端口的。 ------------------------- 回 116楼(网际码工) 的帖子 您好, 那您的网站访问地址是什么呢? ------------------------- 回 118楼(lyan) 的帖子 您好, 欢迎来到阿里云论坛。 请问您的程序(web)里配置监听所有的可用端口,如 nginx 里可以填写如下的配置内容: listen [::]:8091r ------------------------- 回 121楼(cenfee~) 的帖子 您好, 请问您正使用的系统(MacBook?)是否支持IPv6的网络呢? ------------------------- 回 120楼(fedorjia) 的帖子 您好, 请问您的服务器是否禁ping了? ------------------------- 回 124楼(cenfee~) 的帖子 您好, 可以ping得通您的ipv6地址喔, PING 2001:470:a:c8e::2(2001:470:a:c8e::2) 56 data bytes 64 bytes from 2001:470:a:c8e::2: icmp_seq=1 ttl=55 time=327 ms 64 bytes from 2001:470:a:c8e::2: icmp_seq=2 ttl=55 time=331 ms 64 bytes from 2001:470:a:c8e::2: icmp_seq=3 ttl=55 time=328 ms ------------------------- 回 126楼(cenfee~) 的帖子 您好, 可以访问哩,如下图: ------------------------- 回 129楼(hhs_) 的帖子 您好, 欢迎来到阿里云论坛。 第二项检测不过头,那可能无法通过ipv6地址访问到内容。 是否有防火墙阻止了ipv6的80端口访问呢? ------------------------- 回 131楼(hhs_) 的帖子 您好, 好象两个IPv6地址都ping不通喔。 PING 2001:470:c:10b0::2(2001:470:c:10b0::2) 56 data bytes --- 2001:470:c:10b0::2 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4004ms root@ipv6tunnel:~/test# ping6 2001:470:c:10b1::2 PING 2001:470:c:10b1::2(2001:470:c:10b1::2) 56 data bytes --- 2001:470:c:10b1::2 ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 5999ms root@ipv6tunnel:~/test# ping6 ipv6.google.com PING ipv6.google.com(lax17s05-in-x0e.1e100.net) 56 data bytes 64 bytes from lax17s05-in-x0e.1e100.net: icmp_seq=1 ttl=57 time=0.589 ms 64 bytes from lax17s05-in-x0e.1e100.net: icmp_seq=2 ttl=57 time=0.705 ms ------------------------- 回 133楼(hhs_) 的帖子 您好, 如果可以,请提供 tunnelbroker.net 分配给您的 IPv6隧道地址配置信息。 和服务器的登录信息(请通过站内信发送),我为您登录查看。 ------------------------- 回 135楼(hhs_) 的帖子 您好, 好象提示SSL证书错误喔。 --2017-04-13 01:17:47--  https://[2001:da8:20d:400::3ccd:ffa]/ Connecting to [2001:da8:20d:400::3ccd:ffa]:443... connected. ERROR: The certificate of '2001:da8:20d:400::3ccd:ffa' is not trusted. ERROR: The certificate of '2001:da8:20d:400::3ccd:ffa' hasn't got a known issuer. The certificate's owner does not match hostname '2001:da8:20d:400::3ccd:ffa' ------------------------- 回 137楼(余得水) 的帖子 您好, 因为例子中的配置是当时有效,没有写入配置文件,重启后会失效的。 ------------------------- 回 138楼(余得水) 的帖子 您好, 如果ECS的宽带类型是“专有网络”,本帖中的配置方法不适用喔。 ------------------------- 回 141楼(hhs_) 的帖子 您好, 苹果好象说是您的APP在IPv6的环境中加载不到内容。 或许您需要检查一下您的Web日志,看看有没有相应的错误信息。 ------------------------- 回 143楼(wangsili) 的帖子 您好, 现在测试,好象正常哩。 ------------------------- 回 146楼(淘拍拍) 的帖子 您好, 第二项是Web访问, 请问您的业务类型是http的吗? ------------------------- 回 148楼(淘拍拍) 的帖子 您好, 请问您运行如 netstat -noa | grep 80 的结果会有哪些信息呢? ------------------------- 回 151楼(lifetin) 的帖子 您好, 请问您使用的web服务器是什么呢? 或许您需要在Web服务器里绑定您的域名或IPv6地址到具体的站点喔。 ------------------------- 回 153楼(ifaceparty) 的帖子 您好, 从国外的测试机,好象ping不能您设置的ipv6地址喔, PING 2001:470:23:11f6::2(2001:470:23:11f6::2) 56 data bytes --- 2001:470:23:11f6::2 ping statistics --- 82 packets transmitted, 0 received, 100% packet loss, time 81185ms ------------------------- 回 154楼(ifaceparty) 的帖子 您好, 个人没发现有可行的解决办法,因为国内的大环境限制,阿里云即使是技术跟得上,也无法实现IPv6接入互联网。 如果仅是应对APP审核,或许可以尝试其它的办法,如临时换用国外支持IPv6的CDN商家。 ------------------------- 回 158楼(ifaceparty) 的帖子 您好, 如果您的配置方法有效,那可以提醒一下其他网友尝试。 ------------------------- 回 160楼(weinie) 的帖子 您好, 欢迎来到阿里云论坛。 上午我曾成功注册过一个tunnelbroker.net账号哩。 invalid registration data,字面上意思好象填写的账号申请信息有错误喔。 ------------------------- 回 162楼(weinie) 的帖子 您好, 很高兴听到您已经解决问题了喔。 欢迎有空时再来论坛逛逛。 ------------------------- 回 164楼(等火车) 的帖子 您好, 欢迎来到阿里云论坛。 很高兴帖子的内容能给您带来帮助喔。 ------------------------- 回 166楼(goldplusgold) 的帖子 您好, 欢迎来到阿里云论坛。 个人没有在SLB的环境里测试喔,但您可以先自行测试一下。 ------------------------- 回 168楼(goldplusgold) 的帖子 您好, 在HE网站申请隧道地址时,填写的是公网IP地址喔, 之后在您的实例里执行命令时,需要将示例中的公网IP换成内网IP的喔。 ------------------------- 回 170楼(灵动在线) 的帖子 您好, 现在我从境外的机子测试您的子域名网站,可以正常访问到内容的喔: converted 'http://wjdipv6.18183g.cc' (ANSI_X3.4-1968) -> 'http://wjdipv6.18183g.cc' (UTF-8) --2017-06-09 09:03:57--   http://wjdipv6.18183g.cc/ Resolving wjdipv6.18183g.cc (wjdipv6.18183g.cc)... 2001:470:35:660::2 Connecting to wjdipv6.18183g.cc (wjdipv6.18183g.cc)|2001:470:35:660::2|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3700 (3.6K) [text/html] Saving to: 'index.html.1' ------------------------- 回 176楼(aii_dev) 的帖子 您好, 在后台用一个ping6命令保持ipv6隧道地址的“运行”状态,如:nohup ping6.ipv6.google.com & ------------------------- 回 178楼(umerxiaowang) 的帖子 您好, 欢迎来到阿里云论坛。 请问您的接口是通过http访问的吗? 这样: converted 'http://service.umer.com.cn' (ANSI_X3.4-1968) -> 'http://service.umer.com.cn' (UTF-8) --2017-06-13 09:39:58--   http://service.umer.com.cn/ Resolving service.umer.com.cn (service.umer.com.cn)... 2001:470:c:38b::2 Connecting to service.umer.com.cn (service.umer.com.cn)|2001:470:c:38b::2|:80... connected. HTTP request sent, awaiting response... 404 2017-06-13 09:39:59 ERROR 404: (no description). ------------------------- 回 179楼(aii_dev) 的帖子 您好, 我暂时没有根治的方法,但对比中,Windows Server系统好象没有这个现象。 ------------------------- 回 182楼(匠巴巴) 的帖子 您好, 欢迎来到阿里云论坛。 是的,是这个意思。 是一个什么样的“同样结果”呢?您在CentOS 7里使用浏览器访问 ipv6-test.com 来测试吗? ------------------------- 回 185楼(donatello) 的帖子 您好, 欢迎来到阿里云论坛。 目前多数人配置的,是使用ipv6隧道地址,即HE.net提供的6in4的隧道地址,这种实现方式好象是封闭成ipv4包来收发的。 ------------------------- 回 187楼(peanut888) 的帖子 您好, 欢迎来到阿里云论坛。 现在测试,您的ipv6地址在ping6一段时间后,可以ping6通喔。 64 bytes from 2001:470:18:9c2::2: icmp_seq=188 ttl=63 time=359 ms 64 bytes from 2001:470:18:9c2::2: icmp_seq=189 ttl=63 time=365 ms 64 bytes from 2001:470:18:9c2::2: icmp_seq=190 ttl=63 time=405 ms --- 2001:470:18:9c2::2 ping statistics --- 190 packets transmitted, 9 received, 95% packet loss, time 190449ms rtt min/avg/max/mdev = 351.692/363.540/405.073/15.177 ms ------------------------- 回 189楼(rexue) 的帖子 您好, 可尝试用 nohup 的命令,令ping6长驻后台运行, 至于原因,我不确定。可能需要咨询一下隧道供应商HE。 ------------------------- 回 192楼(zoan) 的帖子 您好, 欢迎来到阿里云论坛。 是的,因为配置时,是用命令执行,当次有效,没有写进配置文件里的, 所以重启网络的服务后,ipv6隧道地址不会自动再次配置。 您可以尝试将这些配置ipv6的命令写到自动执行的脚本时,这样,重启系统或重启网络后,可以自动再次配置ipv6隧道地址。 ------------------------- 回 194楼(踩你哦) 的帖子 您好, 现在从外网测试 ,可以ping6通您的域名喔: PING zhangzezheng.cn(zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net) 56 data bytes 64 bytes from zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net: icmp_seq=1 ttl=63 time=328 ms 64 bytes from zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net: icmp_seq=2 ttl=63 time=328 ms 64 bytes from zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net: icmp_seq=3 ttl=63 time=333 ms 64 bytes from zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net: icmp_seq=4 ttl=63 time=328 ms ------------------------- 回 194楼(踩你哦) 的帖子 您好, 能ping6通,但访问不了web,建议检查web服务。 liujia@hk2:~/test5$ ping6 zhangzezheng.cn PING zhangzezheng.cn(zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net) 56 data bytes 64 bytes from zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net: icmp_seq=1 ttl=63 time=328 ms 64 bytes from zhangzezheng-5-pt.tunnel.tserv20.hkg1.ipv6.he.net: icmp_seq=2 ttl=63 time=328 ms --- zhangzezheng.cn ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 328.299/328.353/328.407/0.054 ms liujia@hk2:~/test5$ wget -6 zhangzezheng.cn                                          --2017-10-12 22:32:58--   http://zhangzezheng.cn/ Resolving zhangzezheng.cn (zhangzezheng.cn)... 2001:470:18:9f::2 Connecting to zhangzezheng.cn (zhangzezheng.cn)|2001:470:18:9f::2|:80... failed: Connection re fused. ------------------------- 回 199楼(hjlapp) 的帖子 您好, 欢迎来到阿里云论坛。 如果可以ping通ipv6的主机地址,但不能访问web, 可能需要检查: a. web是否在ipv6的网络接口上监听使用 b. ECS实例的安全组是否允许外网访问相应的端口 ------------------------- 回 201楼(hjlapp) 的帖子 您好, 因为目前安全组的规则仅是ipv4, 所以建议您先尝试放行全部的协议后,再来看看能否从外网访问隧道地址。 ------------------------- 您好,很高兴听到您已经解决了问题。希望有空时,多来论坛转转喔。 ------------------------- 回 205楼(异乡人_北) 的帖子 版主回复: 请问您使用的是公共镜像里的CentOS 7系统吗? ------------------------- 回 207楼(异乡人_北) 的帖子 版主回复: 如果是 CentOS 6.5 的,或许可参考一下这个帖子里的操作顺序: https://bbs.aliyun.com/read/304532.html ------------------------- 回 209楼(异乡人_北) 的帖子 版主回复: 上边内容的话,仅在第二行添加 # 符号,注释掉后,应该就可以了。 ------------------------- 回 211楼(youdy) 的帖子 版主回复: 尝试添加IPv6隧道地址的方法,仅是可行性测试,并不是100%能让APP成功上架的喔。 因为苹果的文档里,侧重于APP在构建过程中 考虑到IPv6网络的访问,并不是强制要求APP一定有IPv6地址,建议您让程序员参考苹果的文档喔: https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html ------------------------- 回 213楼(北京小戚戚) 的帖子 版主回复: 按he提供的帮助说明页,如果经过NAT设备,或许需要您的上游设备允许41协议。 ------------------------- 回 214楼(菜鸟小白白) 的帖子 版主回复: 请问您的ECS实例是否有分配公网IP地址呢? 能否截图,看看您的ECS实例网络信息?

dongshan8 2019-12-02 01:51:12 0 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 34170 浏览量 回答数 10

回答

你好,这里有208份资料,详情请参考:https://github.com/ty4z2008/Qix/blob/master/ds.md 《Reconfigurable Distributed Storage for Dynamic Networks》介绍:这是一篇介绍在动态网络里面实现分布式系统重构的paper.论文的作者(导师)是MIT读博的时候是做分布式系统的研究的,现在在NUS带学生,不仅仅是分布式系统,还有无线网络.如果感兴趣可以去他的主页了解. 《Distributed porgramming liboratory》介绍:分布式编程实验室,他们发表的很多的paper,其中不仅仅是学术研究,还有一些工业界应用的论文. 《MIT Theory of Distributed Systems》介绍:麻省理工的分布式系统理论主页,作者南希·林奇在2002年证明了CAP理论,并且著《分布式算法》一书. 《Notes on Distributed Systems for Young Bloods》介绍:分布式系统搭建初期的一些建议 《Principles of Distributed Computing》介绍:分布式计算原理课程 《Google's Globally-Distributed Database》介绍:Google全球分布式数据介绍,中文版 《The Architecture Of Algolia’s Distributed Search Network》介绍:Algolia的分布式搜索网络的体系架构介绍 《Build up a High Availability Distributed Key-Value Store》介绍:构建高可用分布式Key-Value存储系统 《Distributed Search Engine with Nanomsg and Bond》介绍:Nanomsg和Bond的分布式搜索引擎 《Distributed Processing With MongoDB And Mongothon》介绍:使用MongoDB和Mongothon进行分布式处理 《Salt: Combining ACID and BASE in a Distributed Database》介绍:分布式数据库中把ACID与BASE结合使用. 《Makes it easy to understand Paxos for Distributed Systems》介绍:理解的Paxos的分布式系统,参考阅读:关于Paxos的历史 《There is No Now Problems with simultaneity in distributed systems》介绍:There is No Now Problems with simultaneity in distributed systems 《Distributed Systems》介绍:伦敦大学学院分布式系统课程课件. 《Distributed systems for fun and profit》介绍:分布式系统电子书籍. 《Distributed Systems Spring 2015》介绍:卡内基梅隆大学春季分布式课程主页 《Distributed Systems: Concepts and Design (5th Edition)》介绍: 电子书,分布式系统概念与设计(第五版) 《走向分布式》介绍:这是一位台湾网友 ccshih 的文字,短短的篇幅介绍了分布式系统的若干要点。pdf 《Introduction to Distributed Systems Spring 2013》介绍:清华大学分布式系统课程主页,里面的schedule栏目有很多宝贵的资源 《Distributed systems》介绍:免费的在线分布式系统书籍 《Some good resources for learning about distributed computing》介绍:Quora上面的一篇关于学习分布式计算的资源. 《Spanner: Google’s Globally-Distributed Database》介绍:这个是第一个全球意义上的分布式数据库,也是Google的作品。其中介绍了很多一致性方面的设计考虑,为了简单的逻辑设计,还采用了原子钟,同样在分布式系统方面具有很强的借鉴意义. 《The Chubby lock service for loosely-coupled distributed systems》介绍:Google的统面向松散耦合的分布式系统的锁服务,这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁,Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的,所以Chubby实际上是Google分布式事务的基础,具有非常高的参考价值。另外,著名的zookeeper就是基于Chubby的开源实现.推荐The google stack,Youtube:The Chubby lock service for loosely-coupled distributed systems 《Sinfonia: a new paradigm for building scalable distributed systems》介绍:这篇论文是SOSP2007的Best Paper,阐述了一种构建分布式文件系统的范式方法,个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文. 《Data-Intensive Text Processing with MapReduce》介绍:Ebook:Data-Intensive Text Processing with MapReduce. 《Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System》介绍:Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System. 《Distributed Query Processing》介绍:分布式查询入门. 《Distributed Systems and the End of the API》介绍:分布式系统和api总结. 《Distributed Query Reading》介绍:分布式系统阅读论文,此外还推荐github上面的一个论文列表The Distributed Reader。 《Replication, atomicity and order in distributed systems》介绍:Replication, atomicity and order in distributed systems 《MIT course:Distributed Systems》介绍:2015年MIT分布式系统课程主页,这次用Golang作为授课语言。6.824 Distributed Systems课程主页 《Distributed systems for fun and profit》介绍:免费分布式系统电子书。 《Ori:A Secure Distributed File System》介绍:斯坦福开源的分布式文件系统。 《Availability in Globally Distributed Storage Systems》介绍:Google论文:设计一个高可用的全球分布式存储系统。 《Calvin: Fast Distributed Transactions For Partitioned Database Systems》介绍:对于分区数据库的分布式事务处理。 《Distributed Systems Building Block: Flake Ids》介绍:Distributed Systems Building Block: Flake Ids. 《Introduction to Distributed System Design》介绍:Google Code University课程,如何设计一个分布式系统。 《Sheepdog: Distributed Storage System for KVM》介绍:KVM的分布式存储系统. 《Readings in Distributed Systems Systems》介绍:分布式系统课程列表,包括数据库、算法等. 《Tera》介绍:来自百度的分布式表格系统. 《Distributed systems: for fun and profit》介绍:分布式系统的在线电子书. 《Distributed Systems Reading List》介绍:分布式系统资料,此外还推荐Various articles about distributed systems. 《Designs, Lessons and Advice from Building Large Distributed Systems》介绍:Designs, Lessons and Advice from Building Large Distributed Systems. 《Testing a Distributed System》介绍:Testing a distributed system can be trying even under the best of circumstances. 《The Google File System》介绍: 基于普通服务器构建超大规模文件系统的典型案例,主要面向大文件和批处理系统, 设计简单而实用。 GFS是google的重要基础设施, 大数据的基石, 也是Hadoop HDFS的参考对象。 主要技术特点包括: 假设硬件故障是常态(容错能力强), 64MB大块, 单Master设计,Lease/链式复制, 支持追加写不支持随机写. 《Bigtable: A Distributed Storage System for Structured Data》介绍:支持PB数据量级的多维非关系型大表, 在google内部应用广泛,大数据的奠基作品之一 , Hbase就是参考BigTable设计。 Bigtable的主要技术特点包括: 基于GFS实现数据高可靠, 使用非原地更新技术(LSM树)实现数据修改, 通过range分区并实现自动伸缩等.中文版 《PacificA: Replication in Log-Based Distributed Storage Systems》介绍:面向log-based存储的强一致的主从复制协议, 具有较强实用性。 这篇文章系统地讲述了主从复制系统应该考虑的问题, 能加深对主从强一致复制的理解程度。 技术特点: 支持强一致主从复制协议, 允许多种存储实现, 分布式的故障检测/Lease/集群成员管理方法. 《Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads》介绍:分布式存储论文:支持强一直的链式复制方法, 支持从多个副本读取数据,实现code. 《Finding a needle in Haystack: Facebook’s photo storage》介绍:Facebook分布式Blob存储,主要用于存储图片. 主要技术特色:小文件合并成大文件,小文件元数据放在内存因此读写只需一次IO. 《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》介绍: 微软的分布式存储平台, 除了支持类S3对象存储,还支持表格、队列等数据模型. 主要技术特点:采用Stream/Partition两层设计(类似BigTable);写错(写满)就封存Extent,使得副本字节一致, 简化了选主和恢复操作; 将S3对象存储、表格、队列、块设备等融入到统一的底层存储架构中. 《Paxos Made Live – An Engineering Perspective》介绍:从工程实现角度说明了Paxo在chubby系统的应用, 是理解Paxo协议及其应用场景的必备论文。 主要技术特点: paxo协议, replicated log, multi-paxo.参考阅读:关于Paxos的历史 《Dynamo: Amazon’s Highly Available Key-Value Store》介绍:Amazon设计的高可用的kv系统,主要技术特点:综和运用一致性哈希,vector clock,最终一致性构建一个高可用的kv系统, 可应用于amazon购物车场景.新内容来自分布式存储必读论文 《Efficient Replica Maintenance for Distributed Storage Systems》介绍:分布式存储系统中的副本存储问题. 《PADS: A Policy Architecture for Distributed Storage Systems》介绍:分布式存储系统架构. 《The Chirp Distributed Filesystem》介绍:开源分布式文件系统Chirp,对于想深入研究的开发者可以阅读文章的相关Papers. 《Time, Clocks, and the Ordering of Events in a Distributed System》介绍:经典论文分布式时钟顺序的实现原理. 《Making reliable distributed systems in the presence of sodware errors》介绍:面向软件错误构建可靠的分布式系统,中文笔记. 《MapReduce: Simplified Data Processing on Large Clusters》介绍:MapReduce:超大集群的简单数据处理. 《Distributed Computer Systems Engineering》介绍:麻省理工的分布式计算课程主页,里面的ppt和阅读列表很多干货. 《The Styx Architecture for Distributed Systems》介绍:分布式系统Styx的架构剖析. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上面的一个问答:有哪些关于分布式计算学习的好资源. 《RebornDB: The Next Generation Distributed Key-Value Store》介绍:下一代分布式k-v存储数据库. 《Operating System Concepts Ninth Edition》介绍:分布式系统归根结底还是需要操作系统的知识,这是耶鲁大学的操作系统概念书籍首页,里面有提供了第8版的在线电子版和最新的学习操作系统指南,学习分布式最好先学习操作系统. 《The Log: What every software engineer should know about real-time data's unifying abstraction》介绍:分布式系统Log剖析,非常的详细与精彩. 中文翻译 | 中文版笔记. 《Operating Systems Study Guide》介绍:分布式系统基础之操作系统学习指南. 《分布式系统领域经典论文翻译集》介绍:分布式系统领域经典论文翻译集. 《Maintaining performance in distributed systems》介绍:分布式系统性能维护. 《Computer Science from the Bottom Up》介绍:计算机科学,自底向上,小到机器码,大到操作系统内部体系架构,学习操作系统的另一个在线好材料. 《Operating Systems: Three Easy Pieces》介绍:<操作系统:三部曲>在线电子书,虚拟、并发、持续. 《Database Systems: reading list》介绍:数据库系统经典论文阅读列,此外推送github上面的db reading. 《Unix System Administration》介绍:Unix System Administration ebook. 《The Amoeba Distributed Operating System》介绍:分布式系统经典论文. 《Principles of Computer Systems》介绍:计算机系统概念,以分布式为主.此外推荐Introduction to Operating Systems笔记 《Person page of EMİN GÜN SİRER》介绍:推荐康奈尔大学的教授EMİN GÜN SİRER的主页,他的研究项目有分布式,数据存储。例如HyperDex数据库就是他的其中一个项目之一. 《Scalable, Secure, and Highly Available Distributed File Access》介绍:来自卡内基梅隆如何构建可扩展的、安全、高可用性的分布式文件系统,其他papers. 《Distributed (Deep) Machine Learning Common》介绍:分布式机器学习常用库. 《The Datacenter as a Computer》介绍:介绍了如何构建仓储式数据中心,尤其是对于现在的云计算,分布式学习来说很有帮助.本书是Synthesis Lectures on Computer Architecture系列的书籍之一,这套丛书还有 《The Memory System》,《Automatic Parallelization》,《Computer Architecture Techniques for Power Efficiency》,《Performance Analysis and Tuning for General Purpose Graphics Processing Units》,《Introduction to Reconfigurable Supercomputing》,Memory Systems Cache, DRAM, Disk 等 《helsinki:Distributed Systems Course slider》介绍:来自芬兰赫尔辛基的分布式系统课程课件:什么是分布式,复制,一致性,容错,同步,通信. 《TiDB is a distributed SQL database》介绍:分布式数据库TiDB,Golang开发. 《S897: Large-Scale Systems》介绍:课程资料:大规模系统. 《Large-scale L-BFGS using MapReduce》介绍:使用MapReduce进行大规模分布式集群环境下并行L-BFGS. 《Twitter是如何构建高性能分布式日志的》介绍:Twitter是如何构建高性能分布式日志的. 《Distributed Systems: When Limping Hardware Is Worse Than Dead Hardware》介绍:在分布式系统中某个组件彻底死了影响很小,但半死不活(网络/磁盘),对整个系统却是毁灭性的. 《Tera - 高性能、可伸缩的结构化数据库》介绍:来自百度的分布式数据库. 《SequoiaDB is a distributed document-oriented NoSQL Database》介绍:SequoiaDB分布式文档数据库开源. 《Readings in distributed systems》介绍:这个网址里收集了一堆各TOP大学分布式相关的课程. 《Paxos vs Raft》介绍:这个网站是Raft算法的作者为教授Paxos和Raft算法做的,其中有两个视频链接,分别讲上述两个算法.参考阅读:关于Paxos的历史 《A Scalable Content-Addressable Network》介绍:A Scalable Content-Addressable Network. 《500 Lines or Less》介绍:这个项目其实是一本书( The Architecture of Open Source Applications)的源代码附录,是一堆大牛合写的. 《MIT 6.824 Distributed System》介绍:这只是一个课程主页,没有上课的视频,但是并不影响你跟着它上课:每一周读两篇课程指定的论文,读完之后看lecture-notes里对该论文内容的讨论,回答里面的问题来加深理解,最后在课程lab里把所看的论文实现。当你把这门课的作业刷完后,你会发现自己实现了一个分布式数据库. 《HDFS-alike in Go》介绍:使用go开发的分布式文件系统. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上关于学习分布式的资源问答. 《SeaweedFS is a simple and highly scalable distributed file system》介绍:SeaweedFS是使用go开发的分布式文件系统项目,代码简单,逻辑清晰. 《Codis - yet another fast distributed solution for Redis》介绍:Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 《Paper: Coordination Avoidance In Distributed Databases By Peter Bailis》介绍:Coordination Avoidance In Distributed Databases. 《从零开始写分布式数据库》介绍:本文以TiDB 源码为例. 《what we talk about when we talk about distributed systems》介绍:分布式系统概念梳理,为分布式系统涉及的主要概念进行了梳理. 《Distributed locks with Redis》介绍:使用Redis实现分布式锁. 《CS244b: Distributed Systems》介绍: 斯坦福2014年秋季分布式课程. 《RAMP Made Easy》介绍: 分布式的“读原子性”. 《Strategies and Principles of Distributed Machine Learning on Big Data》介绍: 大数据分布式机器学习的策略与原理. 《Distributed Systems: What is the CAP theorem?》介绍: 分布式CAP法则. 《How should I start to learn distributed storage system as a beginner?》介绍: 新手如何步入分布式存储系统. 《Cassandra - A Decentralized Structured Storage System》介绍: 分布式存储系统Cassandra剖析,推荐白皮书Introduction to Apache Cassandra. 《What is the best resource to learn about distributed systems?》介绍: 分布式系统学习资源. 《What are some high performance TCP hacks?》介绍: 一些高性能TCP黑客技巧. 《Maintaining performance in distributed systems》介绍:分布式系统性能提升. 《A simple totally ordered broadcast protocol》介绍:Benjamin Reed 和 Flavio P.Junqueira 所著论文,对Zab算法进行了介绍,zab算法是Zookeeper保持数据一致性的核心,在国内有很多公司都使用zookeeper做为分布式的解决方案.推荐与此相关的一篇文章ZooKeeper’s atomic broadcast protocol: Theory and practice. 《zFS - A Scalable Distributed File System Using Object Disk》介绍:可扩展的分布式文件系统ZFS,The Zettabyte File System,End-to-end Data Integrity for File Systems: A ZFS Case Study. 《A Distributed Haskell for the Modern Web》介绍:分布式Haskell在当前web中的应用. 《Reasoning about Consistency Choices in Distributed Systems》介绍:POPL2016的论文,关于分布式系统一致性选择的论述,POPL所接受的论文,github上已经有人整理. 《Paxos Made Simple》介绍:Paxos让分布式更简单.译文.参考阅读:关于Paxos的历史,understanding Paxos part1,Understanding Paxos – Part 2.Quora: What is a simple explanation of the Paxos algorithm?,Tutorial Summary: Paxos Explained from Scratch,Paxos algorithm explained, part 1: The essentials,Paxos algorithm explained, part 2: Insights 《Consensus Protocols: Paxos》介绍:分布式系统一致性协议:Paxos.参考阅读:关于Paxos的历史 《Consensus on Transaction Commit》介绍:事务提交的一致性探讨. 《The Part-Time Parliaments》介绍:在《The Part-Time Parliament》中描述了基本协议的交互过程。在基本协议的基础上完善各种问题得到了最终的议会协议。 为了让人更容易理解《The Part-Time Parliament》中描述的Paxos算法,Lamport在2001发表了《Paxos Made Simple》,以更平直的口头语言描述了Paxos,而没有包含正式的证明和数学术语。《Paxos Made Simple》中,将算法的参与者更细致的划分成了几个角色:Proposer、Acceptor、Learner。另外还有Leader和Client.参考阅读:关于Paxos的历史 《Paxos Made Practical》介绍:看这篇论文时可以先看看理解Paxos Made Practical. 《PaxosLease: Diskless Paxos for Leases》介绍:PaxosLease:实现租约的无盘Paxos算法,译文. 《Paxos Made Moderately Complex》介绍:Paxos算法实现,译文,同时推荐42 Paxos Made Moderately Complex. 《Hadoop Reading List》介绍:Hadoop学习清单. 《Hadoop Reading List》介绍:Hadoop学习清单. 《2010 NoSQL Summer Reading List》介绍:NoSQL知识清单,里面不仅仅包含了数据库阅读清单还包含了分布式系统资料. 《Raft: Understandable Distributed Consensus》介绍:Raft可视化图帮助理解分布式一致性 《Etcd:Distributed reliable key-value store for the most critical data of a distributed system》介绍:Etcd分布式Key-Value存储引擎 《Understanding Availability》介绍:理解peer-to-peer系统中的可用性究竟是指什么.同时推荐基于 Peer-to-Peer 的分布式存储系统的设计 《Process structuring, synchronization, and recovery using atomic actions》介绍:经典论文 《Programming Languages for Parallel Processing》介绍:并行处理的编程语音 《Analysis of Six Distributed File Systems》介绍:此篇论文对HDFS,MooseFS,iRODS,Ceph,GlusterFS,Lustre六个存储系统做了详细分析.如果是自己研发对应的存储系统推荐先阅读此篇论文 《A Survey of Distributed File Systems》介绍:分布式文件系统综述 《Concepts of Concurrent Programming》介绍:并行编程的概念,同时推荐卡内基梅隆FTP 《Concurrency Control Performance Modeling:Alternatives and Implications》介绍:并发控制性能建模:选择与意义 《Distributed Systems - Concepts and Design 5th Edition》介绍:ebook分布式系统概念与设计 《分布式系统设计的形式方法》介绍:分布式系统设计的形式方法 《互斥和选举算法》介绍:互斥和选举算法 《Actors:A model Of Concurrent Cornputation In Distributed Systems》介绍:经典论文 《Security Engineering: A Guide to Building Dependable Distributed Systems》介绍:如何构建一个安全可靠的分布式系统,About the Author,Bibliography:文献资料,章节访问把链接最后的01换成01-27即可 《15-712 Advanced and Distributed Operating Systems》介绍:卡内基梅隆大学的分布式系统博士生课程主页,有很丰富的资料 《Dapper, Google's Large-Scale Distributed Systems Tracing Infrastructure》介绍:Dapper,大规模分布式系统的跟踪系统,译文,译文对照 《CS262a: Advanced Topics in Computer Systems》介绍:伯克利大学计算机系统进阶课程,内容有深度,涵盖分布式,数据库等内容 《Egnyte Architecture: Lessons Learned In Building And Scaling A Multi Petabyte Distributed System》介绍:PB级分布式系统构建/扩展经验 《CS162: Operating Systems and Systems Programming》介绍:伯克利大学计算机系统课程:操作系统与系统编程 《MDCC: Multi-Data Center Consistency》介绍:MDCC主要解决跨数据中心的一致性问题中间件,一种新的协议 《Research at Google:Distributed Systems and Parallel Computing》介绍:google公开对外发表的分布式系统与并行计算论文 《HDFS Architecture Guide》介绍:分布式文件系统HDFS架构 《ActorDB distributed SQL database》介绍:分布式 Key/Value数据库 《An efficient data location protocol for self-organizing storage clusters》介绍:是著名的Ceph的负载平衡策略,文中提出的几种策略都值得尝试,比较赞的一点是可以对照代码体会和实践,如果你还需要了解可以看看Ceph:一个 Linux PB 级分布式文件系统,除此以外,论文的引用部分也挺值得阅读的,同时推荐Ceph: A Scalable, High-Performance Distributed File System 《A Self-Organizing Storage Cluster for Parallel Data-Intensive Applications》介绍:Surrento的冷热平衡策略就采用了延迟写技术 《HBA: Distributed Metadata Management for Large Cluster-Based Storage Systems》介绍:对于分布式存储系统的元数据管理. 《Server-Side I/O Coordination for Parallel File Systems》介绍:服务器端的I/O协调并行文件系统处理,网络,文件存储等都会涉及到IO操作.不过里面涉及到很多技巧性的思路在实践时需要斟酌 《Distributed File Systems: Concepts and Examples》介绍:分布式文件系统概念与应用 《CSE 221: Graduate Operating Systems》介绍:加利福尼亚大学的研究生操作系统课程主页,论文很值得阅读 《S4: Distributed Stream Computing Platform》介绍:Yahoo出品的流式计算系统,目前最流行的两大流式计算系统之一(另一个是storm),Yahoo的主要广告计算平台 《Pregel: a system for large-scale graph processing》介绍:Google的大规模图计算系统,相当长一段时间是Google PageRank的主要计算系统,对开源的影响也很大(包括GraphLab和GraphChi) 《GraphLab: A New Framework for Parallel Machine Learning》介绍:CMU基于图计算的分布式机器学习框架,目前已经成立了专门的商业公司,在分布式机器学习上很有两把刷子,其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟; 《F1: A Distributed SQL Database That Scales》介绍:这篇论文是Google 2013年发表的,介绍了F1的架构思路,13年时就开始支撑Google的AdWords业务,另外两篇介绍文章F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business .Google NewSQL之F1 《Cockroach DB:A Scalable, Survivable, Strongly-Consistent SQL Database》介绍:CockroachDB :一个可伸缩的、跨地域复制的,且支持事务的数据存储,InfoQ介绍,Design and Architecture of CockroachDb 《Multi-Paxos: An Implementation and Evaluation》介绍:Multi-Paxos实现与总结,此外推荐Paxos/Multi-paxos Algorithm,Multi-Paxos Example,地址:ftp://ftp.cs.washington.edu/tr/2009/09/UW-CSE-09-09-02.PDF 《Zab: High-performance broadcast for primary-backup systems》介绍:一致性协议zab分析 《A Distributed Hash Table》介绍:分布式哈希算法论文,扩展阅读Introduction to Distributed Hash Tables,Distributed Hash Tables 《Comparing the performance of distributed hash tables under churn》介绍:分布式hash表性能的Churn问题 《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web》介绍:分布式系统的CAP问题,推荐Perspectives on the CAP Theorem.对CAP理论的解析文章,PODC ppt,A plain english introduction to CAP Theorem,IEEE Computer issue on the CAP Theorem 《F2FS: A New File System for Flash Storage》介绍:闪存存储文件系统F2FS 《Better I/O Through Byte-Addressable, Persistent Memory》介绍:微软发表的关于i/o访问优化论文 《tmpfs: A Virtual Memory File System》介绍:虚拟内存文件系统tmpfs 《BTRFS: The Linux B-tree Filesystem》介绍:Linux B-tree文件系统. 《Akamai technical publication》介绍:Akamai是全球最大的云计算机平台之一,承载了全球15-30%网络流量,如果你是做CDN或者是云服务,这个里面的论文会给你很有帮助.例如这几天看facebook开源的osquery。找到通过db的方式运维,找到Keeping Track of 70,000+ Servers: The Akamai Query System这篇论文,先看论文领会思想,然后再使用工具osquery实践 《BASE: An Acid Alternative》介绍:来自eBay 的解决方案,译文Base: 一种Acid的替代方案,应用案例参考保证分布式系统数据一致性的6种方案 《A Note on Distributed Computing》介绍:Jim Waldo和Sam Kendall等人共同撰写了一篇非常有名的论文“分布式计算备忘录”,这篇论文在Reddit上被人推荐为“每个程序员都应当至少读上两篇”的论文。在这篇论文中,作者表示“忽略本地计算与分布式计算之间的区别是一种危险的思想”,特别指出了Emerald、Argus、DCOM以及CORBA的设计问题。作者将这些设计问题归纳为“三个错误的原则”: “对于某个应用来说,无论它的部署环境如何,总有一种单一的、自然的面向对象设计可以符合其需求。” “故障与性能问题与某个应用的组件实现直接相关,在最初的设计中无需考虑这些问题。” “对象的接口与使用对象的上下文无关”. 《Distributed Systems Papers》介绍:分布式系统领域经典论文列表. 《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》介绍:Consistent Hashing算法描述. 《SIGMOD 2016: Accepted Research Papers》介绍:SIGMOD是世界上最有名的数据库会议之一,最具有权威性,收录论文审核非常严格.2016年的SIGMOD 会议照常进行,上面收录了今年SIGMOD收录的论文,把题目输入google中加上pdf就能找到,很多论文值得阅读,SIGMOD 2015 《Notes on CPSC 465/565: Theory of Distributed Systems》介绍:耶鲁大学的分布式系统理论课程笔记 《Distributed Operating System Doc PDF》介绍:分布式系统文档资源(可下载) 《Anatomy of a database system》介绍:数据库系统剖析,这本书是由伯克利大学的Joseph M. Hellerstein和M. Stonebraker合著的一篇论文.对数据库剖析很有深度.除此以外还有一篇文章Architecture of a Database System。数据库系统架构,厦门大学的数据库实验室教授林子雨组织过翻译 《A Relational Model of Data for Large Shared Data Banks》介绍:数据库关系模型论文 《RUC Innovative data systems reaserch lab recommand papers》介绍:中国人民大学数据研究实验室推荐的数据库领域论文 《A Scalable Distributed Information Management System》介绍:构建可扩展的分布式信息管理系统 《Distributed Systems in Haskell》介绍:Haskell中的分布式系统开发 《Large-scale cluster management at Google with Borg》介绍:Google使用Borg进行大规模集群的管理,伯克利大学ppt介绍,中文版 《Lock Free Programming Practice》介绍:并发编程(Concurrency Programming)资料,主要涵盖lock free数据结构实现、内存回收方法、memory model等备份链接 密码: xc5j 《Distributed Algorithms Lecture Notes for 6.852》介绍:Nancy Lynch's的分布式算法研究生课程讲义 《Distributed Algorithms for Topic Models》介绍:分布式算法主题模型. 《RecSys - ACM Recommender Systems》介绍:世界上非常有名的推荐系统会议,我比较推荐接收的PAPER 《All Things Distributed》介绍:推荐一个博客,博主是Amazon CTO Werner Vogels,这是一个关注分布式领域的博客.大部分博文是关于在工业界应用. 《programming, database, distributed system resource list》介绍:这个Git是由阿里(alibaba)的技术专家何登成维护,主要是分布式数据库. 《Making reliable distributed systems in the presence of sodware errors》介绍:Erlang的作者Joe Armstrong撰写的论文,面对软件错误构建可靠的分布式系统.中文译版 《CS 525: Advanced Distributed Systems[Spring 2016]》介绍:伊利诺伊大学的Advanced Distributed Systems 里把各个方向重要papers(updated Spring 2015)列举出来,可以参考一下 《Distributed Algorithms》介绍:这是一本分布式算法电子书,作者是Jukka Suomela.讲述了多个计算模型,一致性,唯一标示,并发等. 《TinyLFU: A Highly Efficient Cache Admission Policy》介绍:当时是在阅读如何设计一个缓存系统时看到的,然后通过Google找到了这一篇关于缓存策略的论文,它是LFU的改良版,中文介绍.如果有兴趣可以看看Golang实现版。结合起来可能会帮助你理解 《6.S897: Large-Scale Systems》介绍:斯坦福大学给研究生开的分布式系统课程。教师是 spark 作者 matei. 能把这些内容真正理解透,分布式系统的功力就很强了。 《学习分布式系统需要怎样的知识?》介绍:[怎么学系列]学习分布式系统需要怎样的知识? 《Distributed systems theory for the distributed systems engineer》介绍:分布式系统工程师的分布式系统理论 《A Distributed Systems Reading List》介绍:分布式系统论文阅读列表 《Distributed Systems Reading Group》介绍:麻省理工大学分布式系统小组,他们会把平时阅读到的优秀论文分享出来。虽然有些论文本页已经收录,但是里面的安排表schedule还是挺赞的 《Scalable Software Architecture》介绍:分布式系统、可扩展性与系统设计相关报告、论文与网络资源汇总. 《MapReduce&Hadoop resource》介绍:MapReduce&Hadoop相关论文,涉及分布式系统设计,性能分析,实践,优化等多个方面 《Distributed Systems: Principles and Paradigms(second edtion)》介绍:分布式系统原理与范型第二版,课后解答 《Distributed Systems Seminar's reading list for Spring 2017》介绍:分布式系统研讨会论文阅读列表 《A Critique of the CAP Theorem》介绍:这是一篇评论CAP定理的论文,学习CAP很有帮助,推荐阅读评论文章"A Critique of the CAP Theorem" 《Evolving Distributed Systems》介绍:推荐文章不断进化的分布式系统.

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