关于阿里云开发者:阿里云-EMAS-魔笔6月产品动态

简介: 阿里云挪动研发平台EMAS & 低代码开发平台魔笔 6月产品动静已更新:EMAS Suite 公布HBuilderX打包插件、挪动测试 云真机反对折叠屏、魔笔 更新多种性能、优化多种体验链路等。内容摘要EMAS Suite 公布HBuilderX打包插件云构建 Android,IOS&H5动态代码扫描性能公布挪动测试 云真机反对折叠屏EMAS Serverless 云存储控制台反对CDN配置、目录治理魔笔 优化步骤条组件、文本组件以及自定义组件等魔笔 更新多种性能、优化多种体验链路产品动静 产品体验EMAS体验:提供音讯推送、挪动测试、挪动监控、热修复、域名解析等收费应用阈值,点击“立刻开明”即可体验EMAS!EMAS帮忙文档:https://help.aliyun.com/product/434086.html 魔笔体验:提供模型驱动、扩大灵便的低代码开发平台!魔笔试验Demo:1小时疾速搭建待办事项治理平台收费评测得罗技键盘鼠标:魔笔评测局魔笔学习课程:https://www.mobiapp.cloud/link/academy 技术交换欢送退出钉钉技术交换群:EMAS技术交换:35248489 魔笔技术交换:32946835

July 10, 2023 · 1 min · jiezi

关于阿里云开发者:EMAS-12月产品动态

内容摘要● 优化安卓替换版本插件● 近程调试反对经纬度模仿定位● 接入操作审计● 修复热修复续费相干问题● Android SDK2.1.1 隐衷爱护改良,移除了sim卡、wifi信息的获取 ● 开发者训练营开发结束,预计1月中旬上线● Android SDK 3.7.3公布,反对vivo新版本,payload、setColor等个性 产品动静产品私有云挪动DevOps优化安卓替换版本插件 / 优化流水线模版(指定jdk加到了默认的流水线模版中)挪动测试近程调试反对经纬度模仿定位 / 近程调试安卓反对二维码扫码 / 安卓机型筛选反对cpu32/64位筛选 / 安卓解体日志减少更欠缺的堆栈信息解体剖析接入操作审计 / 反对react native及相应符号表治理性能剖析接入操作审计 / 反对react native及相应符号表治理近程日志接入操作审计 / 反对react native及相应符号表治理挪动热修复修复热修复续费相干问题HTTPDNS-Android SDK2.1.1 隐衷爱护改良,移除了sim卡、wifi信息的获取EMAS Serverless开发者训练营开发结束,预计1月中旬上线 / 云函数反对多Nodejs版本 / 云函数反对定时触发 / 云函数反对HTTP触发挪动推送Android SDK 3.7.3公布,反对vivo新版本,payload、setColor等个性欢送退出EMAS开发者钉钉交换群群号:35248489

January 21, 2022 · 1 min · jiezi

关于阿里云开发者:2021ISIG中国产业智能大会低代码峰会即将开幕钉钉宜搭叶周全受邀出席

简介:2021年12月8-9日,“2021ISIG中国产业智能大会” 将在上海举办。阿里巴巴资深技术专家,钉钉宜搭创始人叶周全将作为特邀嘉宾缺席大会。 2021年12月8-9日,由中国电子技术标准化研究院、苏州市金融科技协会、中国计算机用户协会政务信息化分会领导,企智将来科技(RPA中国、LowCode低码时代、信创中国)、机械工业出版社华章分社、CSDN、亿欧EqualOcean等单位联结举办的“2021ISIG中国产业智能大会” 将在上海举办。 阿里巴巴资深技术专家,钉钉宜搭创始人叶周全将作为特邀嘉宾缺席大会,并在 “2021低代码技术利用与倒退峰会”上以《钉钉宜搭:云钉低代码,减速构建企业“酷”利用》为主题,分享钉钉宜搭在低代码赛道的思考与积淀。 叶周全(花名勇猛),阿里巴巴资深技术专家,钉钉宜搭创始人。10+年企业数字化转型实践经验,是阿里团体从信息化到数字化的外围推动者。阿里前端技术委员会外围委员、阿里巴巴低代码发起人,目前负责钉钉宜搭低代码平台。 钉钉宜搭是阿里巴巴自研的云钉低代码平台,深度交融了钉钉和阿里云的能力,成为“云钉一体”策略中重要组成部分。从往年1月,宜搭首次亮相钉钉6.0发布会以来,宜搭平台上的利用数已冲破100万,笼罩新批发、医疗、生产制作、能源、教育、酒店、金融、运输等支流行业。低代码让越来越多的企业和组织找到了高效、低成本的数字化翻新门路,也让个体的需要失去了满足,让集体更有取得感。   利用可视化搭建,定制灵便:宜搭提供了可视化拖拽操作界面,将繁琐、简单的网页元素封装为业务组件,将业务规定、权限等封装为规定配置,用户通过拖拽以及配置,无需编写任何代码即可疾速实现符合实际业务需要的利用搭建。 钉原生:宜搭作为钉钉官网低代码利用搭建平台,和钉钉能力默认买通。宜搭默认应用钉钉企业通讯录,流程审批可基于组织架构,不便、快捷。反对钉钉音讯、钉钉待办,确保重要事项音讯必达。搭建好的利用可疾速接入钉钉工作台,高效实现在线协同、挪动办公。 云原生:用宜搭搭建利用,用户只需关注业务自身。数据存储、运行环境、服务器、网络安全等,平台为你全副搞定。此外,借助阿里云,宜搭还提供了弱小的弹性计算、动静扩容能力,为你的业务高效、稳固的运行保驾护航。 模板核心:借助模板核心用户只须要一分钟即可实现利用的创立,并主动适配电脑端和挪动端;用户在搭建完利用后,可一键公布至钉钉工作台。目前,模板核心已笼罩了政务、医疗、教育、餐饮、制作、修建等支流行业,用户还能够在模板的根底之上进行二次编辑开发。 往年10月的云栖大会上,钉钉宜搭公布了3.0版本,带来了在连接器、数据大屏以及平安方面的重磅更新:3大连贯能力套件,让业务互联互通;更低门槛的数据BI能力,一键生成酷炫数字大屏;全局水印、独立域名等平安能力,为用户提供国密级专属平安。 连贯的效率和深度,决定了企业的生产力。宜搭3大连贯能力套件:Excel一键降级企业数字化利用,宜搭连接器以及跨组织流程审批和利用散发,实现了利用与利用之间,利用与人之间,企业上下游之间的全链路连贯,宜搭搭建的利用在钉钉上人造互联互通。 业务数据全面买通,一键生成酷炫大屏。本次宜搭全新公布了20多款罕用报表可视化组件,提供10多款开箱即用的可视化炫酷大屏模版,涵盖销售、人事、生产制作等诸多畛域,可宽泛用于展现汇报、指挥决策,业务剖析等场景。反对100万数据量的表与表关联,和一亿数据量的海量数据处理能力。 全局水印,独立域名,提供全面平安保障。爱护客户的数据安全是第一准则,宜搭平台依靠钉钉全面的平安防护策略,取得公安部信息系统三级等级爱护认证,数据享受国密级别平安爱护。宜搭上线利用全局水印性能,一旦产生信息透露可疾速追溯起源。对立风控账号体系+独立企业域名,筑起平安高墙,为企业提供专业级平安防护。 “让人人都具备开发利用的能力,让工作中的每件事件都可被数字化。”是宜搭的致力方向。 阿里云智能总裁、达摩院院长张建锋在刚刚闭幕的2021年云栖大会上指出:将来面试,会用低代码或将成为必备技能。他认为随着低代码的提高,大型软件可能会更向专业化细分倒退,越来越多的应用软件将由企业本人来开发,企业本人开发利用时将由业务部门应用低代码开发,而非企业的IT部门。 能够预感,将来低代码开发能力将成为集体职场竞争力的重要组成部分。就像明天人人都会应用Office办公软件一样,今天,低代码开发将成为人人必备的技能。作为职场人,把握新生产力工具,晋升自我价值,能力紧跟社会倒退,成为企业数字化转型的外围人才。 为此,钉钉宜搭推出了低代码开发师的官网认证: 钉钉宜搭先后推出了“低代码开发师”的高级和中级认证,为低代码开发者的技术水平认证制订了行业标准。开发者通过考取官网认证,能够成为当下热门的低代码开发师,晋升职场竞争力。宜搭心愿通过大家独特的致力,造就更多合乎市场需求的低代码人才。 将来,宜搭将在云原生和钉原生能力的加持下,继续深耕低代码畛域,携手更多的生态搭档,助力百行千业的组织实现更低成本的数字化转型,人人都是低代码开发者。  低代码开发师(中级)认证炽热进行中! 晒认证证书还有机会获赠阿里动物园盲盒徽章! 理解流动详情>>> 立刻返回认证>>> 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 26, 2021 · 1 min · jiezi

关于阿里云开发者:里工实业用宜搭自主搭建MES系统实现生产全流程管理

简介:里工实业是寰球智能制作AIoT配备市场的创新者,用宜搭自主搭建MES零碎,实现了生产全流程治理。 “除了它(钉钉)的第三方利用零碎之外,咱们还是比拟中意应用宜搭低代码平台。咱们甚至因为有了这样一个好的工具,特意为它建设了数字核心这样一个数字化推动部门,将咱们生产、制作的理论需要转变为标准化、定制化的流程。” ——里工实业经营总监 Monica Huang 里工实业是寰球智能制作AIoT配备市场的创新者,在一直深入数字化治理的过程中,里工实业也给了所有中小企业示范:应用钉钉宜搭低代码平台治理公司的生产和经营,实现高定制化和低成本。 里工实业成立于1985年,次要业务是设计、开发并制作和销售无人值守合作机器人和自主挪动合作机器人、深度学习设施。通过里工的产品,技术和商业模式翻新,为寰球工业企业提供平安,易用,经济高效的人工智能物联网解决方案。 图:里工智能工厂车间 在其36年的继续迭代中,里工原有业务和新业务就像DNA双螺旋构造一样,互相赋能又相互促进,这就是里工人每一天都须要面对的双元工作。尤其考验里工人的是定制业务的产品种类繁多并且批量不大,自主机器人业务则是以最大的标准化应答最宽泛的非标需要,因而疾速定制、快捷交付是贯通于里工生产治理的主题。 对于一家执着于精益治理的24小时运行的智能工厂而言,ERP和MES等重型软件系统尽管可能解决不少资源调度和生产执行的问题,但正是因其绝对并重型、偏制式的系统软件定位,在企业业务、流程等疾速倒退迭代过程中,其灵活性与快捷变更方面都会在都不肯定能实时反馈着实时状况。 有没有一种可能反对自主开发、又能够在挪动互联网平台上运行的零碎?这成为了里工数字化路线上始终想要答复的问题。 2020年5月,因为钉钉独有的开放性和OA深度交融特点,里工开始启用应用钉钉,使公司外部治理更加透明化、进步审批速度、增强外部协调。宜搭的呈现,更让里工终于有机会自主开发一个适合本人的MES零碎。 图:里工应用宜搭搭建的利用 宜搭的低代码劣势是把每一位参加企业运行,工厂制作的人教训和办法,通过表格和设置流程先跑起来。小跑迭代是里工多年来研发的一个心得,不求一次终极地解决问题,而是后行,再优,后固化。  宜搭和钉钉都很好地让里工的团队在流程上先自我买通逻辑,而后再通过数据的重复收集提优,不到一个月的工夫,宜搭上的生产治理利用曾经迭代屡次,推动着里工的数字化过程。在降级钉钉到专业版后,宜搭的后劲又再被里工数字化团队挖出来。里工还专门成立了一个名叫“数字核心”的数字化推动部门,专门负责应用宜搭开发利用以及员工培训。 始终以来,里工24小时运作的车间都存在数据难以实时把握、同步难的问题。如果专门找人员做数据录入,既不高效也老本不低。去中心化的数据录入和自主数据穿插验证在宜搭中有了实在的作用。应用宜搭后,生产的各个环节能够在后盾高深莫测的进行治理,疾速排查异样。如果碰到紧急工单,也能够通过零碎疾速调配资源,高效实现工作。 图:里工MES零碎生产跟踪页面 图:里工MES零碎生产治理数据页 里工原先车间外面工人的生产日志、交班日志都是通过手填的形式在纸质表单进行填写。每个月的交班数据还须要文助录入电脑,不仅工作量微小还容易出错。里工应用宜搭开发了交班零碎,不仅实现了交班的线上化、自动化,还能够进行审批治理和数据分析。这也让里工的一线员工真正领会到了宜搭的快捷不便。 图:里工发展宜搭应用的员工培训   过来里工在进行巡检时都是手动填写评分表,月底须要专人汇总得分,巡逻时发现问题后还要当面转达给相干部门。当初巡检人员只需应用宜搭搭建的“7S评分治理”利用,巡检同时记录评分及上传须要整改之处,零碎就会主动地统计得分,并且主动把整改倡议同步到相应部门。月底的时候关上数据汇总,就能间接取得得分排名,开释了人力老本。 图:里工的“7S巡检评分”利用 图:里工的“7S巡检评分”利用数据报表 过往,里工每台设施都须要配置专属点检表记录其运行状态,管理人员如需监督点检执行状况,必须亲自返回每台设施前翻阅点检记录。随着应用工夫的缩短,点检表堆积如山,还需投入大量人工成本整顿归档。在宜搭上搭建“点检零碎”利用后,一机一码、钉钉扫码就能轻松实现点检,设施的固定信息可一键带出,无需每次反复录入,即高效又便捷。 图:里工过来应用的纸质点检表 图:一机一码,扫码实现点检 图:一机一码,扫码实现点检 最近里工把无人值守机器人连贯到钉钉和宜搭上,也就是把整个智能工厂要移植到钉钉的平台上。这是一个大胆的冒险,这也是里工人坚信的一件事:在挪动互联世界里,仅须要一个接口就能接通物联网世界。给智能制作一个新的入口,也给了所有中小企业示范:智能制作有钉钉宜搭这样新的平台能够赋予大家更好的数字化能力。 为了继续助力百行千业的组织实现更低成本的数字化转型,帮忙更多企业造就数字化外围人才。钉钉宜搭先后推出了“低代码开发师”的高级和中级认证,为低代码开发者的技术水平认证制订了行业标准。开发者通过考取官网认证,能够成为当下热门的低代码开发师,晋升职场竞争力! 低代码开发师(中级)认证炽热进行中! 晒认证证书还有机会获赠阿里动物园盲盒徽章! 理解流动详情>>> 立刻返回认证>>> 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 26, 2021 · 1 min · jiezi

关于阿里云开发者:Kubernetes-已经成为云原生时代的安卓这就够了吗

简介:本文将介绍如何在 Kubernetes 上构建新的利用治理平台,提供一层形象以封装底层逻辑,只出现用户关怀的接口,使用户能够只关注本人的业务逻辑,治理利用更快更平安。作者:司徒放 审核&校对:田玮靖、溪洋 编辑&排版:雯燕 导语:云原生时代,间接应用 Kubernetes 和云基础设施过于简单,如用户须要学习很多底层细节、利用治理的上手老本高、容易出错、故障频频。随着云计算的遍及,不同云又有不同的细节,进一步加剧了上述问题。 本文将介绍如何在 Kubernetes 上构建新的利用治理平台,提供一层形象以封装底层逻辑,只出现用户关怀的接口,使用户能够只关注本人的业务逻辑,治理利用更快更平安。 云原生时代是一个十分好的时代,咱们所面临的是整体技术的颠覆性变革,全面地对利用做端到端重构。目前,云原生在演进过程中产生了三个关键技术: 一是容器化,容器作为标准化交互的介质,在运维效率、部署密度和资源隔离性方面相比传统形式有很大改良,据 CNCF 最新调研报告显示,目前已有 92% 的企业生产零碎在应用容器;二是 Kubernetes,它对基础设施进行了形象和治理,现已成为云原生的标配;三是 Operator 自动化运维,通过控制器和定制资源的机制,使 Kubernetes 不仅能够运维无状态利用,还能够执行由用户定义的运维能力,实现更简单的自动化运维利用进行自动化部署和交互。这三项关键技术其实是逐步演进的关系,另外,在利用交付畛域,也有与之对应的实践在追随上述技术一直地演进。云原生的崛起,带来了交付介质、基础设施治理、运维模型和继续交付实践的全面降级和冲破,减速了云计算时代的到来。 图 1 云原生技术全景图(详情可点击此处查看) 从 CNCF 公布的云原生技术全景图(见图 1)中,能够看到云原生的蓬勃生态,细数图中这 900 + Logo,其中不乏开源我的项目、守业公司,将来云原生的技术都会在这些中央诞生。 云原生 “操作系统” Kubernetes带来的利用交付挑战上文提到,Kubernetes 已成为云原生的标配,其对下封装基础设施的差别,对上反对各种利用的运维部署,如无状态利用、微服务,再如有状态、批处理、大数据、AI、区块链等新技术的利用,在 Kubernetes 下面都有方法部署。Kubernetes 曾经成为了现实意义的 “操作系统” 。它在云原生的位置正如挪动设施中的 Android。为什么这样讲?Android 不仅仅装在咱们的手机上,它还进一步渗透到汽车、电视、天猫精灵等智能终端里,挪动利用能够通过 Android 运行在这些设施上。而 Kubernetes 也有这样的后劲或发展趋势,当然它不是呈现在智能家电中,而是呈现在各家私有云、自建机房,以及边缘集群。能够料想,Kubernetes 将来会像 Android 一样无处不在。 那么,有了 Kubernetes 这层交付当前,容器 + Kubernetes 这层界面是不是就能够解决掉所有的交付问题了?答案必定不是。试想,如果咱们的手机中只有 Android 零碎,它可能满足咱们工作和生存需要吗?不能,必须有各种各样的软件应用才行。对应到云原生,它除了 Kubernetes 这个 “操作系统” 外,也须要一套利用的交付能力。在手机中,软件应用能够通过相似“豌豆荚”这样的利用以便用户装置,同样在云原生时代,咱们也须要将利用部署到不同的 Kubernetes 集群上。但因为 Kubernetes 海量琐碎的设施细节与简单各异的操作语言,导致部署过程中会遇到各种各样的问题,这时就须要云原生的“豌豆荚”来解决这个问题,也就是利用治理平台,去屏蔽交付的复杂性。 利用治理平台在业界有两种支流模式,第一种是传统平台模式,在 Kubernetes 上 “盖一个大帽子” ,将所有复杂度屏蔽,在此之上,再依据需要本人提供一层简化的利用形象。通过这种形式,尽管利用平台变得易用了,但新的能力须要由平台开发实现,也就带来了扩大难、迭代迟缓的问题,无奈满足日益增长的利用治理诉求。 ...

November 25, 2021 · 2 min · jiezi

关于阿里云开发者:最受欢迎五大技术图谱出炉看看大佬们都在学什么

简介:阿里云开发者学堂15个技术图谱,哪些最受开发者们喜爱?小助手曾经帮你整顿出榜单了,快来学习吧!阿里云开发者学堂共推出了15张技术图谱供开发者们学习,15个热门畛域,涵盖课程、配套图书、直播、上手体验云资源,从学到练一站式从高级工程师为高级工程师进阶。在泛滥课程中帮忙开发者们整顿出学习门路,助力开发者们成长。 这15大技术图谱中最受欢迎的前五名是哪些呢?榜单如下: NO.1 Python 工程师进阶学习路线(累计86000+人订阅)Python 作为极其容易上手的计算机编程语言,提供了高效的高级数据结构,还能简略无效地面向对象编程,是大数据、人工智能时代的首选编程语言。200+的课时带你学习3大知识点。 图谱地址:https://developer.aliyun.com/graph/python NO.2 Alibaba Java 技术图谱(累计76000+人订阅)Java 作为编程语言不仅简略易用而且功能强大。Alibaba Java 由“Java 课程专家组”倾力打造的行业权威图谱,12个知识点 ,近千课时,体验场景练习上手更快。从新手入门,到高级工程师进阶,从实践学习,到实际利用,一张图谱讲透Java ! 图谱地址:https://developer.aliyun.com/graph/java NO.3 弹性计算技术图谱(累计60000+人订阅)无处不在的“算力”,千人学习的弹性计算技术图谱,由阿里云弹性计算专家团队出品,从根底产品入门到进阶,从场景实战到最佳实际,带您轻松学习和玩转阿里云弹性计算。 图谱地址:https://developer.aliyun.com/graph/ECS NO.4 前端开发技术图谱(累计40000+人订阅)创立WEB 页面或者APP 等前端界面出现给用户的前端开发技能全笼罩 ,HTML / CSS / JavaScript / jQuery / Vue / React / Angular / NodeJS。 图谱地址:https://developer.aliyun.com/graph/frontend NO.5 Alibaba Cloud Linux技术图谱(累计38000+人订阅)Linux 零碎性能稳固的开源软件。基于 Alibaba Cloud Linux,联合阿里巴巴工程师的一线实战经验,邀请行业退职运维工程师授课,课程内容涵盖 Linux 基础知识、罕用业务服务保护、自动化运维、自动化运维监控、KVM 虚拟化等相干常识。 图谱地址:https://developer.aliyun.com/graph/linux 更多技术图谱可见学习核心技术图谱:https://developer.aliyun.com/learning 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 25, 2021 · 1 min · jiezi

关于阿里云开发者:和-VMware深信服天翼云招商云专家一起聊聊云原生边缘计算

简介:11 月 27 日 【KubeMeet 开发者沙龙·云原生边缘计算专场】正在凋谢报名!快来参加吧!随着 5G、loT、音视频、直播、CDN 等行业和业务的倒退,越来越多的算力和业务开始下沉到间隔数据源或者终端用户更近的中央,从而取得更好的响应工夫,降低成本。边缘计算也因而区别于传统的核心云计算模式,并被宽泛地利用于汽车、农业、能源、交通等各行各业。 OpenYurt 作为阿里巴巴首个开源的边缘云原生我的项目,波及到边缘计算和云原生两个畛域。该我的项目自开源以来始终受到开发者的关注。 11 月 27 日,由云原生基金会与阿里云同城会联结主办的开发者沙龙 KubeMeet 将在深圳站举办“云原生边缘计算”专场,CNCF OpenYurt 我的项目发起人、阿里云高级技术专家 & 凋谢原子基金会 TOC 成员黄玉奇、 VMware 主任工程师刘武明、电信天翼云研发工程师张力方、深服气云计算开发工程师赵震、招商云Paas平台部总经理段嘉将齐聚 KubeMeet,与现场 100 名开发者独特探讨无关“云原生边缘计算”的那些事儿,并分享 OpenYurt 的落地实际。 KubeMeet 深圳站,咱们聊什么?咱们为什么须要 云原生的边缘计算 ?其落地现状和挑战如何?OpenYurt 是什么?为什么说它是云原生边缘计算生态兼容场景下的首选我的项目?如何开启 边缘设施 的云原生治理能力?OpenYurt 如何帮忙用户在边缘场景领有与核心云 统一的 利用治理体验?面对边缘场景下的 弱网挑战 ,如何确保服务失常运行?如何基于成熟的边缘容器技术,疾速落地 云边一体化基础设施平台 ?工夫流动 & 地址流动工夫:2021年11月27 日(周六) 13:30—18:00 流动地址:深圳-阿里核心 · 深圳后海 T4- 3F 天满城 流动残缺议程 现场互动,社区精美周边送不停11 月 27 日 【KubeMeet 开发者沙龙·云原生边缘计算专场】正在凋谢报名,流动现场,你不仅能理解当下最受开发者欢送的开源我的项目最新进展、企业应用实际,结交酷爱开源的开发者搭档,现场还有大量 OpenYurt 社区精美周边派发,咱们将在现场抽取侥幸开发者,送出惊喜礼品哦!名额有限,快扫描海报二维码报名吧! 流动直播间已正式上线,点击此处即刻锁定! 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 25, 2021 · 1 min · jiezi

关于阿里云开发者:阿里云-CDP-公开课-直播预告来袭

简介:扫描海报上的钉钉群二维码入群,线上观看直播,还能够与来自阿里云和 Cloudera 的技术专家交换~背景介绍CDP(Cloudera Data Platform)是 Cloudera 和 Hortonworks 合并后,抉择原 CDH 和 HDP 中的精髓组件,合并成新一代数据平台。阿里云与 Cloudera 联结打造了阿里云上的半托管状态 CDP 企业数据云平台,以及基于 On- Premise 部署的 CDP 大数据平台、CDF 流计算、CDSW 机器学习平台的专有云输入。 该平台能够灵便地运⾏各种企业⼯作负载,⽀持从边缘计算到⼈⼯智能的多功能数据分析,提供企业级的平安模型来保障客户数据安全。 0元收费测试:https://ac.aliyun.com/application/cloudera 快来申请把~直播预报为了让更多开发者理解并应用 CDP,由阿里云和 Cloudera 联结打造的业余公开课【阿里云 CDP 公开课】来啦~ 公开课第一讲--【阿里云Cloudera CDP产品介绍】将于11月25日本周四下午14点准时开讲!钉钉扫描文章底部二维码进钉钉群,间接在线观看,另外记得锁定钉群及时关注直播动静哦~ 更有阿里云和 Cloudera 技术专家在线答疑,欢送小伙伴们加群探讨技术问题~ 详情参见以下海报 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 25, 2021 · 1 min · jiezi

关于阿里云开发者:奖金翻倍Flink-Forward-Asia-Hackathon-最新参赛指南请查收

简介:奖金翻倍,赛程缩短!愿各位开发者都可能获得好问题。首届 Flink Forward Asia Hackathon 曾经正式启动。本次新鲜的开放式命题失去了宽广开发者的关注,目前在 GitHub 上有不少团队曾经提交了参赛我的项目 issue,其中不乏有充斥创意的想法和构思。 为了回馈各位开发者的激情,本次 Flink Forward Asia Hackathon 将会进行奖金追加,全面降级!愿各位开发者都可能获得好问题。 一、奖金降级奖金总额翻倍,让创意发光! 奖金降级前 奖金降级后 二、彩蛋降级Pravega 鼎力相助,额定奖金等你来! 本次较量取得了 Pravega 社区(pravega.io)的鼎力支持,如果选手在参赛我的项目中应用 Pravega,将会有 Pravega 的专家提供技术帮忙。同时,最终取得冠军/亚军/季军的队伍如果应用了 Pravega,将会额定取得处分 10000 元。 三、赛程降级赛程缩短,让更多选手能够施展本人的创意! 四、参赛指南3 步参加,轻松快捷! Step 1 点击较量主页,注册报名。 报名地址:https://www.aliyun.com/page-source//tianchi/promotion/FlinkForwardAsiaHackathon Step 2 进入 GitHub 专题页,公布计划 issue。 公布地址:https://github.com/flink-china/flink-forward-asia-hackathon-2021 Step 3 实现以上操作,即可进入投票环节啦~ 舒适提醒:Apache Flink 社区 Contributor 认可很重要哦! 本次初赛采纳 Hackathon 评委投票 + Flink 社区投票形式评比。 Hackathon 评委会打分占 50% 权重。取得的 Apache Flink 社区 Contributor 票数占 50% 权重。欢送进入赛事官网理解更多信息: ...

November 25, 2021 · 1 min · jiezi

关于阿里云开发者:离线实时一体化数仓与湖仓一体云原生大数据平台的持续演进

简介:阿里云智能研究员 林伟 :阿里巴巴从湖到仓的演进给咱们带来了湖仓一体的思考,使得湖的灵活性、数据品种丰盛与仓的可成长性和企业级治理失去有机交融,这是阿里巴巴最佳实际的贵重资产,是大数据的新一代架构。**林伟,阿里云智能研究员、阿里云智能通用计算平台MaxCompute、机器学习PAI平台技术负责人** 本篇内容将从三个局部为读者讲述离线实时一体化数仓与湖仓一体—云原生大数据平台的继续演进。通过从数据湖到数仓的历史,反思为什么要做湖仓一体,以及湖仓一体在明天这个阶段为什么开始做离线和实时湖仓一体化的数仓。 湖仓一体离线在线数仓一体化智能数仓心愿这次的分享让大家进一步了解咱们为什么做湖仓一体。 一、湖仓一体(1)   阿里巴巴从数据湖到数仓历程2007年的宁波策略会议确定建设一个开发、协同、凋敝的电子商务生态系统,其中生态系统的外围是数据。但这个时候各个业务部门都在垂直式倒退数据能力,用数据撑持商业的决策服务。这些数据中台撑持了业务部门的倒退。但咱们倒退到一个阶段的时候,心愿进一步挖掘出各个业务部门数据之间的关联性,从而利用这些高阶数据分析开掘更高商业价值,咱们遇到了很多的艰难,因为数据来自不同的部门,不同的人会提供你不同的数据集,没有清晰数据品质监控,你也不晓得这些数据是不是残缺的,你就须要破费很多工夫不停的去校准数据。这个过程耗时太长且少数状况会做了十分多的无用功,这样其实整体降落了公司的效率。 所以到了2012年,咱们决定将所有的业务部门的数据都关联起来,信心做『One Data,One Service』。其实这个过程就是典型一个数据湖降级到数仓的过程,然而因为咱们不足很好湖仓一体的零碎积淀,这个过程十分艰巨,咱们称之这个过程为“登月”。大家能够从这个名字可见两头的艰巨。在这个时间段,各个团队甚至须要停下日常的本身业务倒退来配合整顿数据,把所以原来已有的数据分析过程,搬到对立一套数仓零碎下面。最终咱们历经18个月,在花了十分大的代价,于2015年的12月实现建设了对立大数据仓库平台建设,这就是阿里巴巴的MaxCompute。通过这个对立数仓平台,无论是业务团队、服务商家还是物流或其它环节都能够不便,迅捷,更好的开掘商机。所以大家能够看到在阿里巴巴对立的大数据平台实现后,业务成长也进入了快车道。这正是因为有更好的数据撑持,才使得商家、客户都能疾速的进行一些商业决策。 (2)  数据仓库和数据湖的关系从开发人员的角度看,数据湖更为灵便,更喜爱这种得心应手的模式,任意的引擎都能够去读、写,没有束缚,启动也非常容易。 从数据管理者角度看,数据湖能作为起步,但达到特定规模时,把数据当作资产或者须要做更大的商业决策的时候,都心愿有一个很好的数仓。 (3)  数据仓库和数据湖零碎的增长曲线 上图的增长曲线,基本上也是阿里倒退的曲线,最开始也是数据湖状态,各个业务部门独立倒退,起步快、灵活性强。但当达到特定规模时,数据无人治理、每个业务部门的数据的逻辑语言不统一,很难对齐。所以过后花了50%、80%的有效工夫在校验数据,随着规模的不断扩大,这样的损耗越来越大,迫使咱们推动公司对立数据仓库的建设。 (4)  湖仓一体 正是因为咱们经验过堪比“登月”的苦楚,所以咱们不心愿MaxCompute将来的企业客户也经验这么苦楚过程,所以咱们构建湖仓一体的开发平台。当公司规模较小的时候,能够使用数据湖能力更快定制本人的剖析。公司成长到肯定的阶段,须要更好的数据管理和治理形式的时候,湖仓一体平台能够无缝把数据以及数据分析进行无效的降级治理,使得公司对于数据管理更加标准。这就是湖仓一体整体设计背地的核心思想。 咱们把湖的零碎和仓的零碎有机联合在一起,一开始是没有元数据,你想要建设数仓的时候,咱们有能够在湖下面来抽取这个元数据,这个元数据是和仓的元数据放在一个一体化的元数据的剖析平台下面。在这个元数据之上能够建设很多数据仓库的数据管理平台。 同时,在数据仓库湖仓一体的平台下面,咱们无效反对很多剖析引擎,有工作型的计算引擎,包含像MaxCompute是批处理、Flink是流式解决、机器学习等,还有开源的组件能够剖析咱们的数据;也有服务性质数据引擎能够反对交互式查问服务,可能去更加实时性很好的展现咱们的数据,从而使得用户能够在这个服务性引擎下来构建本人数据服务利用。 在引擎之上咱们构建丰盛数据管理工具从而可能让业务部门可能进行高效整体的数据治理。而这都得益于咱们把湖和仓的数据买通,这也是整体湖仓一体设计的外围。 二、离线在线数仓一体化现今社会越来越便捷,客户须要更快的做出商业决策。在双十一GMV实时大屏、春晚直播实时大屏等数据分析,以及机器学习从离线模型走向在线模型的趋势中咱们都能够看到。这些需要推动了实时数仓的倒退。 其实实时数仓和离线数仓有着类似的倒退过程。过后实时零碎倒退的晚期,咱们首先思考的是引擎,因为只有先有引擎了你才能够进行实时数据分析,所以阿里巴巴把研发精力放在Flink这样的流计算引擎上。然而只有流计算引擎,相似数据湖的阶段,咱们不足将剖析进去的后果数据进行治理,所以到了第二阶段,咱们利用咱们离线数仓产品来治理这些剖析后果,从而把剖析后果纳管到咱们整体数据仓库和数据管理中。然而把实时剖析之后的后果放在离线数仓外面,显然这样是对于实时商业决策是不够的及时。所以咱们当初倒退第三个阶段:实时数仓。 咱们会把流式引擎的剖析后果后果实时的写到实时数仓Hologres外面,从而可能让剖析的后果更实时的进行BI的剖析,从而无效的反对客户实时商业决策。 这就是离线和在线数仓一体化的设计。 总结一下,原有的剖析在离线和在线的数仓一体化之前是一个很纷纷的过程,有离线、有在线的、有很多不同的引擎,当初把它总结到或者简化成上图的架构。咱们会用实时的引擎做预处理,做完预处理后,咱们把这些数据写入到MaxCompute离线的数仓,也能够同时写入到Hologres实时数仓中外面,从而能够做更加实时的服务化的BI剖析。而MaxCompute离线的数仓存储的老本更低,吞吐的性能更好,能够做大量的离线数据分析,这就是离在线数仓一体化的设计。 有了一体化的设计,就能够给客户带来一个十分均衡的零碎。依据数据的场景或者是业务的场景,你能够用批处理。并且通过数据的压缩、冷存,数据依据热和冷的形式做不同梯度的存储,就能够失去更低成本的离线剖析。 当对于数据的实时性的价值更加器重,能够用流计算的引擎去做。同时又心愿有很快的交互式,心愿疾速通过各种形式的、各种维度、角度去察看已生成好的报表。这时候能够利用交互式引擎,在高度提纯过数据后的进行各个维度的洞察。 心愿用湖仓一体化平台就可能达到一个好的均衡,依据理论的业务体量、要求、规模老本达到更好点。 总的来说,心愿湖仓一体零碎上,不论是离线还是在线。通过不同的剖析引擎,反对各类剖析,同时通过在线服务型引擎可能实时进行BI,可能达到低成本、自定义能力,以及实时和在线服务的各种均衡。让客户可能依据理论业务场景抉择。 三、智能数仓有了对立的数仓平台,咱们就能够在此之上建设弱小的数据治理或者是剖析平台,这个就是咱们的DataWorks。在这个平台下面有很多数据建模工具,提供数据的品质和规范、提供血统的剖析、提供编程助理等等。正是因为湖仓一体在线和离线的一体化的底座能力,才赋予了咱们有这样的可能性去做到大数据开发和治理平台更加智能化的形式。从而将更多通过验证过无效数据治理教训分享到咱们企业客户上。 更多对于大数据计算、云数据仓库技术交换,欢送扫码查看征询。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 25, 2021 · 1 min · jiezi

关于阿里云开发者:阿里大规模业务混部下的全链路资源隔离技术演进

简介:本文作为混部实际系列开篇,本篇文章将介绍资源隔离技术在混部中的重要性、其落地挑战及咱们的应答思路。作者:钱君、南异 审核&校__对:溪洋、海珠 编辑&排版:雯燕 混部顾名思义,就是将不同类型的业务在同一台机器上混合部署起来,让它们共享机器上的 CPU、内存、IO 等资源,目标就是最大限度地进步资源利用率,从而升高洽购和经营等老本。 2014 年,阿里开始了第一次摸索混部,通过七年磨难,这把将资源利用率大幅晋升的利剑正式开始商用。 通过计算资源、内存资源、存储资源、网络资源等全链路的隔离以及毫秒级的自适应调度能力,阿里能够在双十一的流量下进行全时混部,通过智能化的决策与运维能力,撑持着外部百万级的 Pod 混部,不论是 CPU 与 GPU 资源,一般容器与平安容器,包含国产化环境各种异构基础设施,都能实现高效混部,这让阿里外围电商业务生产集群老本降落了 50% 以上,同时让外围业务受到的烦扰小于 5%。 针对云原生时代的资源效力晋升问题,咱们将基于大规模场景下的混部实际推出系列文章,具体介绍并分享对于混部技术的细节,及大规模生产中碰到的种种落地的理论问题。作为系列开篇,本篇文章将介绍资源隔离技术在混部中的重要性、其落地挑战及咱们的应答思路。 混部和资源隔离之间的关系:资源隔离是混部的基石混部通常是将不同优先级的工作混合在一起,例如高优先级的实时工作(对时延敏感,资源耗费低;称为在线)和低优先级的批处理工作(对时延不敏感,资源耗费高;称为离线),当高优先级业务须要资源时,低优先级工作须要立刻偿还,并且低优先级工作的运行不能对高优先级工作造成显著烦扰。 为了满足混部的需要,在单机维度的内核资源隔离技术是最为要害的一项技术,阿里云在内核资源隔离技术上深耕多年,积攒了许多业界当先的教训,咱们将这些内核资源隔离技术次要波及的范畴概括为内核中的调度、内存和 IO 这三大子系统,并且在各个子系统畛域依据云原生的混部场景进行了深刻的革新和优化,包含 CPU Group Identity、SMT expeller、基于 Cgroup 的内存异步回收等。这些要害的技术使客户有能力在云原生混部场景中依据业务特点给出最优解决方案,无效进步用户的资源使用率并升高用户资源的应用老本,十分实用于容器云混部场景,同时也是大规模化混合部署计划所强依赖的关键技术。 下图是资源隔离能力在整个混部计划中的地位: 为什么须要资源隔离,资源隔离会遇到哪些拦路虎假如咱们当初有一台服务器,下面运行了高优的在线业务以及离线工作。在线工作对响应工夫 (Response Time, RT) 的需要是很明确的,要求尽可能低的 RT,故被称之为提早敏感型 (Latency-Sensitive, LS) 负载;离线工作永远是有多少资源吃多少资源的,故此类负载被称之为 Best Effort (BE)。如果咱们对在线和离线工作不加干预,那么离线工作很有可能会频繁、长期占用各种资源,从而让在线工作没有机会调度,或者调度不及时,或者获取不到带宽等等,从而呈现在线业务 RT 急剧升高的状况。所以在这种场景下咱们须要必要的伎俩来对在线和离线容器进行资源应用上的隔离,来确保在线高优容器在应用资源时能够及时地获取,最终可能在晋升整体资源使用率的状况下保障高优容器的 QoS。 上面让咱们一起看看在线和离线混跑时可能呈现的状况: 首先,CPU 是最有可能面对在离线竞争的,因为 CPU 调度是外围,在线和离线工作可能别离会调度到一个核上,互相抢执行工夫;当然工作也可能会别离跑到互相对应的一对 HT 上,相互竞争指令发射带宽和其余流水线资源;接下来 CPU 的各级缓存必然是会被消耗掉的,而缓存资源是无限的,所以这里波及到了缓存资源划分的问题;即便咱们曾经完满解决了各级缓存的资源划分,问题依然存在。首先内存是 CPU 缓存的下一级,内存自身也相似,会产生争抢,不管在线或离线工作,都是须要像 CPU 缓存一样进行内存资源划分的;另外当 CPU 最初一级缓存 (Last Level Cache, LLC) 没有命中的时候,内存的带宽(咱们称之为运行时容量,以有别于内存大小划分这种动态容量)会变高,所以内存和 CPU 缓存之间的资源耗费,是相互影响的;假如 CPU 和内存资源都没问题,对于本机来说当初隔离曾经做得很好了,然而在线高优的业务和离线工作的运行过程中都是和网络有亲密的关系,那么很容易了解,网络也可能是须要隔离的;最初,线上局部机型对 IO 的应用可能会产生抢占,咱们须要无效的 IO 隔离策略。以上就是一个很简略的资源隔离流程的思路,能够看到每一环都有可能会呈现烦扰或者竞争。 ...

November 24, 2021 · 2 min · jiezi

关于阿里云开发者:如何让智能客服成为企业的生产力工具

简介:2021年10月21日,阿里巴巴达摩院“新一代企业智能服务论坛”在杭州圆满举办。达摩院产品翻新核心阿里云智能客服业务总经理王巍巍分享了阿里云智能客服最新进展,包含全渠道全场笼罩的云上产品矩阵,从智能服务向智能营销场景延长的解决方案,国内首创的智能策略核心;号召客户和生态搭档独特探讨智能服务行业将来倒退动向。一、阿里云智能客服最新进展 1、倒退轨迹及利用成果:智能客服作为生产力工具经验了从算法的具体成果到实战中降本增效的层面转换;2015-2016年左右,智能客服的特色次要体现在算法成果 ,在各个行业客户一直解决和验证的过程中,有的企业能够达到50%降本增效的成果,这也就意味着原来有1000位人团队负责的工作,当初500位就能够解决同样的问题,余下的坐席人员能够投入到营销、用户增长等层面下来; 阿里云智能客服近期在《IDC MarketScape:2021年全球通用对话式AI平台厂商评估》成为国内惟一入选的厂商。无论是在产品力、支出规模和长期倒退策略上都博得了国际化分析师的认可; 2、智能客服落地须要解决的难题:通过长时间的摸索倒退下来,除了面向经营者视角的提效降本已被宽泛验证外;依然有几个问题没有解决,比方:B端客户是一个经营链条,外面有客户、常识经营人员、销售/客户代表、坐席人员、管理者等不同角色;以下三个维度咱们仍然有很长的路要走; 面向客户视角的完满体验:客户是否领有精准、疾速解决问题的良好体验,在现阶段客服环境下,服务离不开人,服务过程中离不开坐席人员的参加;用户潜意识仍然是转接人工跟进解决;是否有更好的解决方案促成人机联合,关照用户的产品体验,使答复疑难问题越来越精准,沟通过程效率越来越高;面向常识经营人员的低成本经营:过来次要依赖FAQ或者文档为主,当初融入了更多的知识结构,像常识图谱、TableQA,甚至图片常识;在这个过程中常识经营人员迎来十分大的挑战,2017年初智能客服业务刚落地,标注量非常宏大,尽管当初有一些降落,但还没有降落到让经营人员十分轻松的境地;面向客户经理贴身助手:业务变动十分迅速,常识变动也随之飞快,坐席团队流失率居高不下,有些甚至达到100%以上,这也就意味着,坐席人员在服务过程中亟需弱小无力的辅助工具来解决效率和学习的问题。二、阿里云智能客服矩阵降级及劣势 针对咱们察看到的这些比拟普遍存在景象,阿里云智能客服是如何逐渐来解决的呢? 1、不懈谋求客户视角的完满体验 惊艳的智能语音对话能力;面向C端场景时,如何继续晋升服务体验?问答过程中的拟人度和对于简单要害信息的收集,像人名、身份证号等;咱们当初的语气承接的拟人度相比原来有了较大晋升,同时在简单要害实体信息的提取收集上可通过多轮对话实现,更贴近于理论的交互体验,尤其在长数字辨认利用上,可用性十分高; 灵便多变的Chat UI:除一体化残缺解决方案外,C端客服体验在智能客服畛域关注度较少;面对头部客户时,就会呈现一个问题,阿里云智能客服所有能力是组合在一起的,前端局部会邀请供应商独特参加;通过一年多的打磨,咱们心愿用户在C端体验是所见即所得,灵便可配置,并为客户与搭档提供便捷、可经营的交互体验,疾速满足客户差异化的产品需要; 数据驱动的人机交融: 坐席与被服务的C端对象如何造成一个更好的组合关系,更快度的解决问题,晋升客户满意度。通过智能调配与施行举荐能力,在人机联合场景上,基于客户画像与历史行为表现,汇合以后线路的忙闲、技能组等状况进行综合制订;咱们能够很大水平上让客户的问题能匹配到以后最适宜解决这个问题的坐席身上,缩短解决问题工夫的同时,兼顾晋升客户满意度,极大开释坐席人员效力。 2. 常识经营人员的提效利器「全链路经营工具」 工作式对话半自动化构建:基于人工会话日志自动化构建工作式对话流,包含用意、构造、流程;多轮对话场景下。作为企业外部的常识运营者,垂直业务可能只有几位坐席,在面临整体复杂度较高,蕴含数千个细分场景的业务时。一个人可能承当着好几个角色,多轮对话的常识树构建便成为有挑战的工作。利用先进的NLP技术开掘企业之前的海量沟通记录、历史日志等数据源,主动生成业务大图;在此基础上,不便对业务品种、频度进行优化调整,不便业务疾速上线;沟通过程中的情绪辨认不久也将上线语音辨认;自动化常识开掘:从会话日志、网页、文档开掘FAQ,从非结构化文档中开掘常识图谱三元组。面向同样文档、日志数据源的非多轮对话场景下,咱们能够挖掘出FAQ、常识图谱等信息,常识经营人员只需疾速复核即可入库,缓解业务冷启动时的常识匮乏; 智能荐句:基于荐句算法,自动化生成及举荐类似问。在创立一个新知识点时,须要很多关联的扩大问来晋升准确率;在短少数据参考的状况下,基于公开、可获取的数据集上联合客户企业外部所有可获取的数据,主动生成举荐扩大问,疾速构建常识;语音语义一体化交融标注:语音语义一体化线上标注零碎,实时聚类语义标注,实时标注数据回流,模型训练一键拉取数据。标注作为绝对标配的能力,后续进行训练、做小样本、小流量测试最初上线;将语音语义离开标注相结合,同时对两者进行标注,晋升整体效率;也反对在原有标注工具的根底上进一步晋升体验。3. 常识经营人员的提效利器「白皮书方法论和课程」 阿里巴巴08-09年开始组建客服业务,2014年成立CCO,咱们将一线落地的产品经理、人工智能训练师,客户代表们的积攒教训进行积淀和交融,不仅要解决智能客服遇到的问题,也要解决客户原有客服业务问题;通过多年摸索致力,梳理打造出一套3-5天的课程体系;在工具之外帮忙客户们进一步晋升效力;进步运行与落地效率。 4、让客户经理信手拈来「智能辅助、对话洞察和剖析」 常识经营人员在这个办法的领导和工具的帮忙下,能够疾速推动过程,长线来看,咱们要解决客户的产品、服务和营销需要。面向于客户经理和一线坐席,咱们当初能有哪些工具和产品能够帮忙到大家? 自我进化的智能辅助:基于坐席采纳反馈和服务成果反馈的自我进化的常识和SOP开掘模型,升高坐席负荷同时进步了满意度和转化率。外围解决企业外部常识生产匮乏,缩小人力积淀常识比重;将问答常识、用意常识、SOP常识等通过技术进行提炼,联合人工参加到业务;使企业外部知识库实时更新、流动起来; 实时对话洞察和剖析:基于舆情剖析,通过双向剖析客户和坐席情绪辨认服务过程中的情绪异常情况,为治理和干涉提供领导,辨认VOC中的高频词汇及话题,疾速理解客户的关注点。通话内容分析,借助NLP能力,剖析海量复电的次要表白内容,深挖反复复电的具体内容和客诉类电话的次要起因。还能够做到话术执行监督,智能化判断对话场景,依据场景判断话术执行状况是否符合要求,造成剖析总结,辅助坐席针对性改良晋升。最初,它会依据客户统计数据挖掘,以在线、热线会话记录为数据源,别离生成客户统计数据,基于类别对客户进行智能营销;造成剖析总结,辅助坐席针对性改良晋升。并将会话内容生成客户统计数据反哺到其余业务零碎,实现呼叫核心的数据资产增值。 三、技术产品翻新与生态搭档互相成就 除了下面介绍的产品维度外,技术维度上有很多大家在应用过程中无奈感知的底层技术,占据达摩院智能客服投入的最大局部。咱们各种引擎能力在寰球都获得了十分好的成果,大幅升高人工标注老本;在WikiSQL、Spider、SParC、COSQL四大国内榜单长期排名第一,成绩斐然; 多引擎能力继续打破纪录:咱们打造的大规模预训练对话模型,书面语语言了解准确率晋升5%。大幅升高30%人工标注老本,在QA对问答引擎方面,多模态FAQ问答首次超过人类基准80.83%,准确率达到了81.26%。下一步多模态VQA即基于图片的问答将持续整合融入。 开掘私域客户的价值,向产品和经营要增长:将企业营销从教训驱动转变为数据驱动,过来只能靠人力积淀数据,总结经验;当初咱们的算法加上过往历史数据能够比人工教训洞察更多信息,为客户提供个性化举荐,匹配更优质的坐席进行服务;未来算法会随同数据进行自主进化和学习,用数据迭代模型能力,服务满意度和营销转化率在原有根底上进一步晋升;在批发场景比方店铺、商家、商品法人信息等。咱们能提供撑持智能客服的一些能力,心愿从服务向营销畛域做的一些延长。所以咱们提出了服务式营销:用客户经营思维,构建”始于客户、终于客户”的营销闭环,帮忙客户找到更适合解决问题的客户经理。 赋予品牌具化的拟人形象:交互技术在实时变动,像最近炽热的Metaverse元宇宙概念;不可能所有直播都靠人力承载,这对很多商家来说不是最经济的形式,咱们做了具备互动成果的交互状态,赋予品牌化的拟人形象,现阶段场景中,利用数字人技术能够很大水平上解决交互体验拉近间隔的问题。 四、阿里云智能客服矩阵架构 如下图所示, 智能客服的产品能力架构底层是沟通通信能力,中间层是达摩院各个实验室的先进AI技术,往上是智能客服产品矩阵;咱们领有一个十分好的开放度,并已笼罩阿里云的所有行业;在对外落地过程中丰盛的凋谢形式反对客户间业务互相买通。 之前获得的问题都与生态搭档非亲非故。在过来的几年,有几十个搭档与咱们一起为客户提供服务。大家在各个行业耕耘多年,具体到行业中,具体到客户的细分场景里,像税务、法律、金融等业务;其中奉献最多、最重要能力有三个:交付能力;产品/计划能力;渠道销售能力。 咱们把阿里云智能客服的产品、技术劣势与合作伙伴的综合能力无效联合在一起,让服务发明出更多企业价值,实现商业增长。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 24, 2021 · 1 min · jiezi

关于阿里云开发者:Flink-CDC-21-正式发布稳定性大幅提升新增-OracleMongoDB-支持

简介:Flink CDC 2.1 正式公布, 更稳固,更弱小 本文作者徐榜江 (雪尽) 以下视频为伍翀 (云邪) 分享的 Flink CDC 前世今生: https://www.bilibili.com/video/BV1jT4y1R7ir/ 前言CDC (Change Data Capture) 是一种用于捕获数据库变更数据的技术,Flink 从 1.11 版本开始原生反对 CDC 数据(changelog)的解决,目前曾经是十分成熟的变更数据处理计划。 Flink CDC Connectors 是 Flink 的一组 Source 连接器,是 Flink CDC 的外围组件,这些连接器负责从 MySQL、PostgreSQL、Oracle、MongoDB 等数据库读取存量历史数据和增量变更数据。Flink CDC Connectors 是一个独立的开源我的项目,从去年 7 月份开源以来,社区放弃了相当高速的倒退,均匀两个月一个版本,在开源社区的关注度继续走高,也逐步有越来越多的用户应用 Flink CDC 来疾速构建实时数仓和数据湖。 在往年 7 月份,Flink CDC Maintainer 徐榜江 (雪尽) 在北京的 Flink Meetup 首次分享了 Flink CDC 2.0 的设计。随后的 8 月份,Flink CDC 社区公布 2.0 版本,解决了诸多生产实践上的痛点,Flink CDC 社区的用户群也随之迅速壮大。 ...

November 24, 2021 · 3 min · jiezi

关于阿里云开发者:敏捷版全链路压测

简介:PTS 联合 10 多年来阿里的全链路压测的教训,让阿里云的用户能够如同享受满汉全席般的享受全套规范的全链路压测,也能够依据本人的需要,抉择最适宜本人的形式。作者:子矜 审核&校__对:风波、雨芙 编辑&排版:雯燕 客户的故事全链路压测被誉为大促备战的 “核武器” ,如果之前有关注过阿里双 11 相干的技术总结,对 “全链路压测” 肯定不会生疏,这个词的出场率简直 100%。从对双 11 稳定性的价值来看,用 “核武器” 来形容全链路压测毫不为过。 在某出名电商大促中,该电商平台也想用全链路压测来为本人的大促提前排除危险。然而他遇到几个艰难: 全链路压测是一个须要多角色参加的流动:业务方,测试,运维,研发,数据库,都须要参加进来。然而可能像阿里具备成熟的组织体系,能够强有力的推动各种不同的角色,都是须要较长时间来积攒的。全链路压测,经常波及到框架的革新:而该电商平台的业务简单,做构造梳理与业务革新并不事实。那这个出名电商平台,有什么方法能够在 1 个星期之内,不进行业务革新,不扭转业务部署,就可能用上全链路压测呢? 接下来的内容,咱们会从全链路压测的原理开始,并引入基于同样原理的 “麻利版” 全链路压测,让该出名电商平台可能在 2 周之内就能用上全链路压测的计划。 全链路压测首先,咱们来看看阿里的全链路压测,到底解决了什么问题: 全链路压测实际上解决的问题是:在线上的压测。线上压测,可能最快、最间接的发现线上的问题。然而,线上压测会带来数据净化的问题:如何把压测数据和实在数据辨别开来,是压测里至关重要的一点。那么,阿里是怎么做的呢?咱们一起来看下图: 阿里的全链路压测具备一套成熟又简单的零碎:压测的梳理、构建、筹备、发送。然而,这套体系对于一个云上的用户是须要长期建设失去的。那咱们如何可能让用户疾速,麻利的享受这套技术呢? 在这里,PTS 把整个流程进行积淀,都以标准化的输入来提供给云上的用户。用户能够间接享受一整套的全链路压测体系,也能够在压测的关键环节:例如场景梳理、申请构建、压测环境、压测等步骤中,依据本人的需要来定制本人想要的压测成果。 场景梳理业务场景,即对应的是压测的输出申请。这是压测第一步,也是最重要的一步。最常见的是把波及到业务的 URL 进行梳理,汇总。例如下图就是一个常见的场景汇总: 然而,这是不够的。当若干个 URL 汇总成一个场景之后,URL 之间的比例、工夫距离,也是影响业务场景的要害。用常见的场景打一个比如:一个用户的下单,可能背地蕴含着 10 个用户登录,每个用户均匀浏览了 4 个商品,每个商品中均匀被浏览了 5 个评估,最初一个用户在 10 点大促开始的时候,购买了一个商品。 这些 URL 之间的关系、工夫点,须要人员有丰盛的业务知识能力梳理分明。为此,PTS 提供服务端流量录制的性能,不便用户来录制流量,并且轻松的失去其中不同维度的比例关系: 如上图所示,用户能够清晰的失去 URL 之间的比例关系、用户 URL 之间的工夫行为等等。基于这个梳理好的数据模型,用户能够在这个根底上进行裁剪。 测试数据结构接下来,就是结构用户数据了。这一步波及的角色最多,也最为繁琐。整个数据结构由三个步骤形成,如下图所示: 首先是数据发现。通常,咱们能够通过人工业务梳理,失去该业务所波及到的所有表,并进行剖析。PTS 为罢黜这个懊恼,和DMS买通,提供表构造预览,让测试人员不便的看清楚和场景相关联的构造,大大的晋升效率。 如果还是感觉太简单,PTS将提供数据录制工具,装置了这个 agent 之后,该业务所波及的表,都会被残缺的记录下来: 有了这些工具,测试人员就能够毋庸 DBA 的帮助,轻松的失去场景关联的表信息了。 ...

November 24, 2021 · 1 min · jiezi

关于阿里云开发者:阿里云-EventBridge-事件驱动架构实践

简介:咱们认为 EventBridge 是云原生时代新的计算驱动力,这些数据能够驱动云的计算能力,发明更多业务价值。作者:周新宇 审核&校__对:白玙、佳佳 编辑&排版:雯燕 本文内容整顿自 中国开源年会 演讲首先做一个自我介绍,我是 RocketMQ 的 PMC member 周新宇,目前负责阿里云 RocketMQ 以及 EventBridge 的产品研发。明天我的分享次要包含以下几局部: 音讯与事件、微服务与事件驱动架构阿里云 EventBridge:事件驱动架构实际基于 RocketMQ 内核构建阿里云对立的事件枢纽云原生时代的新趋势:Serverless+ 事件驱动事件驱动架构的将来瞻望音讯与事件、微服务与事件驱动架构首先,咱们先讲一下音讯跟事件的区别:大家都晓得 RocketMQ 外面的音讯,它是十分泛化的概念,是一个比事件更加形象的概念。因为音讯的内容体就是 Byte 数组,没有任何一个定义,是个弱 Data,所以它是十分通用的形象。 与之相同的,事件可能是更加具象化的。个别状况下,它有一个 Schema 来精准形容事件有哪些字段,比方 CloudEvents 就对事件有一个明确的 Schema 定义。事件也往往代表了某个事件的产生、某个状态的变动,所以十分具象化。 从用处来讲,音讯往往用于微服务的异步解耦的架构。但这一块的话,事件驱动跟音讯是略微相似的。音讯的利用场景往往产生在一个组织外部,音讯的生产方晓得这个音讯要将被如何解决。比如说在一个团队里,音讯的生产者跟发送者可能是同一个团队同一块业务,对这个音讯内容有一个十分强的约定。相比之下,事件更加松耦合,比如说事件发送方也不晓得这个事件将被投递到什么中央,将被谁生产,谁对他感兴趣,对事件被如何解决是没有任何预期的。所以说,基于事件的架构是更加解耦的。音讯的利用往往还是脱离不了同一个业务部门,即便一些大公司里最多波及到跨部门单干。音讯的应用通过文档进行束缚,事件通过 Schema 进行束缚,所以咱们认为事件是比音讯更加彻底解耦的形式。 接下来,微服务架构跟 EDA 架构有什么区别? 首先是微服务架构,微服务作为从单体利用演进而来的架构,比如说把一个单体利用拆成了很多微服务,微服务之间通过 RPC 进行组织和串联。过来一个业务可能是在本地编排了一堆 function,当初通过一堆 RPC 将之串起来。比如说用户去做一个前端的下单操作,可能后盾就是好几个微服务进行订单操作,一个微服务去新建订单,一个微服务去对订单进行解决,解决完再调另一个微服务去把订单已实现的音讯告诉进来,这是一个典型的 RPC 架构。 但纯正的 RPC 架构有很多问题,比方所有业务逻辑是耦合在一起的,只是把本地办法调用换成了近程调用。当业务增速达到肯定阶段,会发现各个微服务之间的容量可能是不对等的,比如说短信告诉能够通过异步化实现,却同步实现。这就导致前端有多大流量,短信告诉也须要筹备同样规模的流量。当筹备资源不短缺,上下游流量不对等时,就有可能导致某个微服被打挂,从而影响到上游,进而产生雪崩效应。 在这种状况下,大家个别就会引入音讯队列进行异步解耦。这个架构已十分靠近于事件驱动架构了,还是以用户前端创立一个订单举例,订单创立的事件就会就发到事件总线、event broker、 event bus 上,上游各个不同订阅方去对这个事件做监听解决。 不同之处在于音讯订阅者基于消息中间件厂商提供 SDK 的去做音讯解决,业务往往须要进行革新,也会被厂商提供的技术栈绑定;事件驱动架构中订阅者属于泛化订阅,即不要求订阅方基于什么样的技术栈去开发,能够是一个 HTTP 网关,也能够是一个function,甚至能够是历史遗留的存量零碎。只有 event broker 兼容业务的协定,就能够把事件推送到不同订阅方。能够看到,泛化订阅的用处更加宽泛,更加解耦,革新老本也最低。 阿里云 EventBridge:事件驱动架构实际Gartner 曾预测, EDA 架构未来会成为微服务支流。在 2022 年它将会成为 60% 的新型数字化商业解决方案,也会有 50% 的商业组织参加其中。 ...

November 24, 2021 · 2 min · jiezi

关于阿里云开发者:首次统一调度系统规模化落地全面支撑阿里巴巴双-11-全业务

简介:往年双 11 首次规模化亮相的对立调度,通过一套调度协定、一套零碎架构,对立治理底层的计算、存储、网络资源,超大规模、高效率、自动化的资源弹性,实现了业界新的冲破。在离线混部、离在线混部、新的快上快下技术,缩小数万台服务器洽购,带来数亿计的资源老本优化和大促效率晋升。01 背景对立调度我的项目 1.0 胜利反对 2021 年双 11 大促,对立调度计划实现了从容器调度到快上快下全流程的全面降级和优化。项目组 100 多位核心成员,胜利走过了立项、POC、计划评审设计、关闭开发测试、大促冲刺各个阶段,历经考验胜利上线。 作为阿里巴巴的外围我的项目,阿里云(容器团队和大数据团队)联结阿里巴巴资源效力团队、蚂蚁容器编排团队,历时一年多研发和技术攻坚,实现了从“混部技术”到明天“对立调度技术”的全面降级。 明天,对立调度已实现阿里巴巴电商、搜推广、MaxCompute 大数据和蚂蚁业务的调度全面对立,实现了 pod 调度和 task 高性能调度的对立,实现了残缺的资源视图对立和调度协同,实现了多种简单业务状态的混部和利用率晋升,全面撑持了寰球数十个数据中心、数百万容器、数千万核的大规模资源调度。 云原生产品家族 02 对立调度技术全面降级云计算的实质,就是把小的计算碎片变成更大的资源池,充沛削峰填谷,提供极致的能效比。对数据中心低碳节能、绿色环保、科技倒退、更高效运行的谋求下,阿里巴巴对技术的摸索永无止境。阿里的技术人有一个现实,让数据中心的算力成为水、电、气一样的基础设施,开箱即用。 为了让业务间峰谷互补的劣势施展到最大,过来咱们构建了混部技术,突破多资源池的割裂,不同计算畛域的多调度大脑协同共用资源;老一代的混部技术带来了资源的对立和利用率的微小晋升,但多调度器的实质让咱们的谋求受限。 阿里巴巴继续谋求构建可撑持更多简单工作无差别混部、极致弹性互补、当先的新一代调度技术,实现极致的全局最优调度,提供更高质量的算力。往年咱们在技术上达到一个新的临界点,容器服务 ACK 牵头并协同泛滥团队,启动了基于 ACK 的新一代对立调度我的项目。 容器产品家族 往年双 11 首次规模化亮相的对立调度,通过一套调度协定、一套零碎架构,对立治理底层的计算、存储、网络资源,超大规模、高效率、自动化的资源弹性,实现了业界新的冲破。在离线混部、离在线混部、新的快上快下技术,缩小数万台服务器洽购,带来数亿计的资源老本优化和大促效率晋升。 往年首次引入大规模数据智能来进一步丰盛调度能力,提供了包含实时的负载感知,主动规格举荐(VPA),差异化 SLO 工作负载编排,CPU 归一化,反对周期性预测的 HPA,分时复用等,提供了更多维度的老本优化技术和高牢靠的容器运行时保障。 围绕着新一代的对立调度,阿里巴巴电商、搜寻、大数据等泛滥平台、不同类型的简单计算资源都以统一的形式申请资源,兼顾的额度治理和资源布局,数十万核资源借用秒级即可实现。基于对立调度,阿里云与蚂蚁也实现了调度技术交融,蚂蚁生态全面降级为对立调度。调度平台为将来带来更多设想空间,例如,咱们能够通过泛滥伎俩,例如价格杠杆等经济因素,驱动阿里外部的业务更正当应用各个数据中心的资源,确保数据中心全局资源水位尽可能均衡,以改良数据中心的能效比。 阿里云容器服务 ACK 对规范 Kubernetes 进一步加强,更高性能吞吐和更低的响应提早构建稳固牢靠的超大规模单集群能力,安稳撑持了 1.2 万节点超 100 万核的超大规模集群、为对立调度大资源池化的生产运行提供了松软的基座。阿里巴巴泛滥类型的简单资源也实现了基于容器服务底座 ACK 的全面交融降级。 除电商、搜寻、大数据等阿里经典场景外,对立调度也极大的赋能了新型的技术创新。以直播电商场景为例,决策对实时计算的需要很高,比方薇娅双 11 直播间 9 千多万在线观看人数的产生的浏览、交易等实时数据的秒级数据分析。往年阿里将实时计算引擎 Blink 降级为基于对立调度的新一代引擎,在老本、性能、稳定性以及用户体验上取得大幅提高,大规模作业拉起性能相比 Yarn 提速 40%,谬误复原效率晋升 100%,通过对立调度技术在双 11 大促备战接节俭数十万 CPU,在集群 CPU 水位超过 65% 时,实现全局零热点,保障了各直播推流的时效性。 ...

November 23, 2021 · 1 min · jiezi

关于阿里云开发者:重拾面向对象软件设计

简介:从上个世纪五十年代冯·诺依曼发明第一台计算机开始,始终到当初只有短短70年工夫,从第一门计算机语言FORTRAN,到当初咱们罕用的C++,JAVA,PYTHON等,计算机语言的演进速度远超咱们所应用的任何一门自然语言。从最早的面向机器,再到面向过程,到演变为当初咱们所应用的面向对象。不变的是编程的主旨,变动的是编程的思维。 作者 | 聂晓龙 起源 | 阿里技术公众号 你还在用面向对象的语言,写着面向过程的代码吗? 一 前言在欧洲文艺复兴期间,一位平凡的数学家天文学家-哥白尼,在过后提出了日心说,批驳了以地球为宇宙核心的天体思维,因为思维极其超前,直到半个世纪后开普勒伽利略等人通过前期钻研,才逐渐认可并确立了过后哥白尼思维的先进性。 独一无二,在软件工程畛域也演出着同样的故事。半个世纪前 Kristen Nygaard创造了Simula语言,这也是当初被认同的世界上第一个明确实现面向对象编程的语言,他提出了基于类的编程格调,确定了"万物皆对象"这一面向对象实践的"终极思维",但在过后同样未受到认可。Peter Norvig 在 Design Patterns in Dynamic Programming 对此予以了批驳,并表述咱们并不需要什么面向对象。半个世纪后 Robert C.Martin、Bertrand Meyer、Martin Fowler等人,再次印证并升华了面向对象的设计理念。编程思维的演进也不是欲速不达,但在这一个世纪失去了飞速的倒退。 二 编程思维的演进从上个世纪五十年代冯·诺依曼发明第一台计算机开始,始终到当初只有短短70年工夫,从第一门计算机语言FORTRAN,到当初咱们罕用的C++,JAVA,PYTHON等,计算机语言的演进速度远超咱们所应用的任何一门自然语言。从最早的面向机器,再到面向过程,到演变为当初咱们所应用的面向对象。不变的是编程的主旨,变动的是编程的思维。 1 面向机器 计算机是01的世界,最早的程序就是通过这种01机器码来管制计算机的,比方0000代表读取,0001代表保留等。实践上这才是世界上最快的语言,无需翻译间接运行。但弊病也很显著,那就是简直无奈保护。运行5毫秒,编程3小时。因为机器码无奈保护,人们在此基础上创造了汇编语言,READ代表0000,SAVE代表0001,这样更易了解和保护。尽管汇编在机器码上更可视更直观,但实质上还是一门面向机器的语言,仍然还是存在很高的编程老本。 2 面向过程 面向过程是一种以事件为核心的编程思维,相比于面向机器的编程形式,是一种微小的提高。咱们不必再关注机器指令,而是聚焦于具体的问题。它将一件事件拆分成若干个执行的步骤,而后通过函数实现每一个环节,最终串联起来实现软件设计。 流程化的设计让编码更加清晰,相比于机器码或汇编,开发效率失去了极大改善,包含当初依然有很多场景更适宜面向过程来实现。但软件工程最大的老本在于保护,因为面向过程更多聚焦于问题的解决而非畛域的设计,代码的重用性与扩展性弊病逐渐彰显进去,随着业务逻辑越来越简单,软件的复杂性也变得越来越不可控。 3 面向对象 面向对象以分类的形式进行思考和解决问题,面向对象的外围是抽象思维。通过形象提取共性,通过封装收敛逻辑,通过多态实现扩大。面向对象的思维实质是将数据与行为做联合,数据与行为的载体称之为对象,而对象要负责的是定义职责的边界。面向过程简略快捷,在解决简略的业务零碎时,面向对象的成果其实并不如面向过程。但在简单零碎的设计上,通用性的业务流程,个性化的差别点,原子化的性能组件等等,更适宜面向对象的编程模式。 但面向对象也不是银弹,甚至有些场景用比不必还糟,所有的本源就是形象。依据 MECE法令 将一个事物进行分类,if else 是软件工程最谨严的分类。咱们在设计形象进行分类时,不肯定能抓住最合适的切入点,谬误的形象比没有形象复杂度更高。里氏替换准则的创始人Barbara Liskov 谈形象的力量 The Power of Abstraction。 三 面向畛域设计1 真在“面向对象”吗// 捡入客户到销售私海public String pick(String salesId, String customerId){ // 校验是否销售角色 Operator operator = dao.find("db_operator", salesId); if("SALES".equals(operator.getRole())){ return "operator not sales"; } // 校验销售库容是否已满 int hold = dao.find("sales_hold", salesId); List<CustomerVo> customers = dao.find("db_sales_customer", salesId); if(customers.size() >= hold){ return "hold is full"; } // 校验是否客户可捡入 Opportunity opp = dao.find("db_opportunity", customerId); if(opp.getOwnerId() != null){ return "can not pick other's customer"; } // 捡入客户 opp.setOwnerId(salesId); dao.save(opp); return "success";}这是一段CRM畛域销售捡入客户的业务代码。这是咱们相熟的Java-面向对象语言,但这是一段面向对象代码吗?齐全面向事件,没有封装没有形象,难以复用不易扩大。置信在咱们代码库,这样的代码不在少数。为什么?因为它将老本放到了将来。咱们将此称之为“披着面向对象的外衣,干着面向过程的勾当。” ...

November 23, 2021 · 3 min · jiezi

关于阿里云开发者:1204-深圳站-Serverless-Developer-Meetup-开放报名啦

简介:Serverless Developer Meetup 深圳站来啦! 继 2021 北京、上海、杭州站胜利举办后,这一次“最适宜中国开发者的 Serverless 实操沙龙”来深圳啦! 12月4日(周六)岁末夏季与你相约阿里核心,咱们邀请了来自阿里云、1688、开源中国的 Serverless 一线技术专家以及极客工夫 Serverless 滞销课程讲师,分享应用 Serverless 技术打造研发团队的教训,分析简单业务场景下 Serverless 降本增效实际,破解定制专属 Serverless 利用部署难题,解析 K8s Serverless 落地实际关键点。收费报名即可加入,咱们在现场筹备了超多周边礼物,等你一起来 Serverless! 流动日期:2021年12月04日 13:30-16:40 流动地点:深圳-阿里核心 · 深圳后海 T4-3F 天满城 流动亮点: 如何应用 Serverless 技术,打造小而美的研发团队?1688 简单业务场景下,Serverless 降本增效之路一线技术专家详解 Serverless Kubernetes 落地实际如何定制属于本人的 Serverless 利用部署流程?放心被绑定,开发者应如何解决 Serverless 跨云部署难题?报名有礼扫描下方二维码即可进入报名页面 http://hdxu.cn/OxToF 关注 Serverless 公众号参加流动报名,将11月17日文章转发至朋友圈公开(不设分组)24h,截图发送给 Serverless 对话框留言,即可取得抽奖码参加“报名有礼” 有机会取得阿里云公仔、挪动充电宝和定制数据线哦!12月4日开奖,中奖的小伙伴能够当天找 Serverless 小姐姐现场支付呦~ 讲师阵容&议题流程13:30-14:00 《Serverless 正过后》 秦粤 极客工夫《Serverless入门课》作者 蒲松洋(秦粤)极客工夫《Serverless入门课》作者。Serverless 和 Node.js 布道者,目前负责阿里巴巴前端委员会标准化小组,低代码小组--中后盾搭建,Node.js 利用微服务架构。在微服务、Serverless 以及中台我的项目中有着丰盛教训。 14:05-14:35 《FaaS 在简单业务场景下的提效实际》 远岩 1688 Serverless&工程效力 负责人 ...

November 23, 2021 · 1 min · jiezi

关于阿里云开发者:阿里云发布云原生加速器携手生态企业拥抱数字时代

简介:继去年推出云原生合作伙伴打算之后,阿里云正式公布云原生加速器,携手生态企业拥抱数字时代。明天,千行百业都在拥抱云计算、拥抱云原生,进行数字化翻新降级。作为国内最早实际云原生的企业,阿里巴巴在 2006 年就开始了在云原生畛域的摸索。为了更好地助力云原生畛域生态搭档的倒退,继去年推出云原生合作伙伴打算之后,阿里云正式公布云原生加速器,携手生态企业拥抱数字时代。 与成员企业能力交融,价值共塑阿里云此次公布云原生加速器,旨在开掘云原生畛域的优良企业,通过阿里云弱小的业务整合能力,助力搭档在阿里云上造成百花齐放的云原生生态体系。 第一期云原生加速器将面向云原生利用、云原生 PaaS、云原生根底技术三大方向开启招募,由出名投资人、阿里云顶级技术专家、业务专家、阿里战投等组成业余的评委团队,最终将有 30 家企业入围首期云原生加速器。 招募方向包含,云原生利用:通用和垂直行业 SaaS、工具类 SaaS 等;云原生 PaaS:中间件、边缘计算、AI、物联网、低/无代码、行业 PaaS、iPaaS、低碳等;云原生根底技术:容器、微服务、可观测、DevOps、Serverless、容器存储、容器平安等。 在一年期减速成长打算中,将通过 2 次集结 +N 次业务对接,凋谢阿里云生态和业务资源,提供技术和产品反对,打造阿里云云原生加速器 “朋友圈” ,帮忙搭档疾速成长。 在产品技术层面,阿里云云原生加速器将整合阿里云云原生技术产品线,与成员进行产品和解决方案共创,将为成员提供更高效、易用的平台和服务。入选成员还有机会成为阿里云云原生 MVP,助力成员取得更多资源与倒退机会。 在业务层面,阿里云云原生加速器将协同不同行业及区域业务线,基于成员理论需要提供多元的单干模式与商业机会,独特拓展云原生利用场景。 在资本层面,阿里云云原生加速器将协同阿里体系投资机构为成员深度连贯海量投资机构与业余的财务顾问,帮忙成员疾速、精准取得投资,全链条赋能企业融资。 在“内功”方面,阿里云云原生加速器将为成员解读行业政策与产业趋势,扩充品牌势能与市场规模,从战略规划与施行、人才组织与团队治理等全方面帮忙成员实现能力降级。 宏大的创投导师阵容阿里云云原生加速器将协同弱小的顶级投资机构资源,邀请红杉资本中国基金合伙人邹家佳,GGV 合伙人吴陈尧,深创投董事总经理伊恩江,启明创投合伙人叶冠泰,云锋基金合伙人朱艺恺,银杏谷创始人陈向明作为创投导师,基于云原生畛域相干细分赛道,从投资角度分析产业发展趋势,为成员梳理将来的时机与挑战。同时,IDG、嘉御资本、蓝驰创投、北极光、元璟资本、线性资本、戈壁创投、金沙江创投、明势资本、英诺天使、真格基金、湖畔山南、元禾原点、九合创投、盈动资本等创投机构的合伙人与董事也将受邀作为嘉宾,分析行业价值,深度链接更多单干机会。  此外,阿里巴巴副总裁、阿里云智能根底产品事业部负责人蒋江伟,阿里巴巴副总裁、阿里云智能计算平台负责人贾扬清,阿里云智能副总裁、阿里巴巴达摩院秘书长刘湘雯,阿里巴巴研究员、阿里云智能云原生利用平台负责人丁宇等,也将与成员分享阿里云在生态构建与技术利用等方面的策略布局,与成员共商单干、共创行业将来。  点击此处,申请报名阿里云云原生加速器! 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 23, 2021 · 1 min · jiezi

关于阿里云开发者:速递|100上云2021双11阿里云数据库技术快报

简介:云上双11,阿里云数据库打造寰球最大规模的云原生数据库实际,让小伙伴们的剁手更稳、更快!2021天猫双11 阿里巴巴100%跑在公共云上 整体计算成本三年降落30% 阿里云数据库全面云原生化 再次胜利扛住了寰球规模最大的流量洪峰 通过技术创新,赋能用户体验降级 云上双11 阿里云数据库 打造寰球最大规模的云原生数据库实际 让小伙伴们的剁手更稳、更快! 相干浏览: 阿里云自研数据库撑持双11,助力电商客户订单峰值冲破每秒20万笔 独家 | 揭秘2021双11背地的数据库硬核科技 双十一特惠|阿里云数据库ACA认证新用户专享5折 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 23, 2021 · 1 min · jiezi

关于阿里云开发者:阿里云自研数据库支撑双11助力电商客户订单峰值突破每秒20万笔

简介:阿里云自研数据库产品家族全面撑持双11流动,帮忙客户从容应对流量顶峰。记者采访获悉,日前阿里云自研云原生数据库PolarDB、云原生数据仓库AnalyticDB等数据库产品家族全面撑持双11流动,帮忙客户从容应对流量顶峰。其中,助力电商SaaS ERP服务商聚水潭的订单解决峰值冲破每秒20万笔。 双11是一次大规模的全社会合作,要想让商品流、领取流、资金流等做到顺畅、及时和精准地在整个双11零碎中实现数据的同步和读写,数据库是十分要害的技术环节。 往年双11是首个100%云上双11,云原生数据库技术更是失去广泛应用,帮忙诸多电商客户应答流量顶峰。电商SaaS ERP服务商聚水潭外围零碎采纳PolarDB、RDS、AnalyticDB等阿里云数据库产品,总使用量近2000个实例。2021双十一期间订单解决峰值达到20万+笔/秒,提供大规模OLAP查问高达数百万次,为全国80多万商家提供了稳固牢靠的服务,通过云原生个性帮忙商家降本增效,实现精准化和智能化治理。 通过采纳云原生分布式数据库PolarDB-X以及云原生数据仓库AnalyticDB,数云赢家2.0全域CRM平台在双11期间对客户洞察和细分、自动化营销等外围性能进行全面降级。基于阿里云数据库的云原生、资源池化和冷热数据拆散能力,研发周期比平常缩短39%,整体老本降落50%,经营效率晋升3倍,解决了洽购施行老本过高难题,助力商家疾速响应业务变动,降本增效成绩显著。 据悉,往年双11期间,阿里云自研云原生数据库PolarDB、云原生数据仓库AnalyticDB(ADB)、云原生内存数据库Tair、一站式在线数据管理平台DMS等数据库产品组合,全面撑持了高并发海量订单的解决和交易、历史订单搜寻、实时交易家库同步、购物车等外围业务场景。 其中,PolarDB+ AnalyticDB(ADB)+ DMS的数据库产品技术组合,让订单搜寻查问性能同比晋升50%;云原生内存数据库Tair,通过长久内存存储等最新技术,让用户在购物车页面对商品实付价高深莫测。 阿里云数据库产品事业部负责人李飞飞 阿里云数据库产品事业部负责人李飞飞示意:“往年双11交易中,阿里云数据库通过全面云原生化而开释的技术红利,无效助力阿里本身以及客户业务实现了更多翻新和更大价值。咱们将会继续投资,加大技术自研翻新力度,进一步引领技术倒退新门路。” 据权威市场调研机构IDC公布的2020年中国关系型数据库市场钻研报告显示,阿里云以超过28%的市场份额,力压传统数据库厂商,排名行业第一。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 23, 2021 · 1 min · jiezi

关于阿里云开发者:媒体声音-阿里云王伟民阿里云数据库的策略与思考

简介: DTCC 2021大会上,阿里云数据库事业部 产品与解决方案部总经理 王伟民(花名:唯敏)发表主题演讲《云原生数据库2.0,一站式全链路数据管理与服务》,并承受IT168企业级&ITPUB执行总编 老鱼 专题采访,本文内容就现场采访整顿而成。受访嘉宾:阿里云数据库事业部 产品与解决方案部总经理 王伟民(花名:唯敏) 采访人:IT168企业级&ITPUB执行总编 老鱼 (本文依据DTCC 2021大会现场采访整顿) 记者:请介绍下您目前在阿里云数据库所负责的日常工作 王伟民:首先介绍一下本人,我先后经验过Oracle、Microsoft、华为等企业在这些企业外面都是从事数据库相干的工作,负责过不同的岗位。 往年退出了阿里云,目前我次要负责四个方面的工作。 第一局部是产品治理,和我以前的工作是齐全一样的,次要是以市场、客户需要为导向,去看咱们须要研发哪些产品。 第二局部是解决方案,为产品的商业胜利负责,包含行业、区域和国内市场。 第三局部是产品体验,包含文档、体验设计等,次要是为了让用户有更好的体验并更高效地应用咱们的产品和服务。 第四局部是品牌和生态,品牌方面包含要继续对行业内构筑产品的影响力。生态方面,数据库作为根底类软件,在PaaS层,不像计算、网络存储、平安这些通用能力,大家都须要;也不像SaaS利用那样自带流量入口。所以,独自去推广数据库不是特地高效,咱们须要通过生态的形式去做市场、推广,和搭档们一起去更疾速地推广和复制到各大利用场景。 以上是目前我在阿里云的工作。 记者:相当于OLAP、OLTP还有NoSQL,研发针对各自产品做集成与研发,你这边就变成产品化的。 王伟民:对,客户需要都是到咱们团队。咱们会去布局产品,研发来承接需要、投入资源、按产品布局的路标来推动产品上市。另外产品的商业模式、定价等GTM工作,也都是在咱们团队负责。 记者:您明天的演讲主题是“云原生数据库2.0,一站式全链路数据管理与服务”。为什么会抉择这个主题,这个主题您感觉对于参会的人来说,它可能取得哪些收益? 王伟民:咱们首先强调的是“一站式”,这个“站”是“One Stop”的意思,不是“技术栈”的“栈”,这个叫“Stack”。咱们当初做的是云服务,各类引擎上架后实现了多样化的供应;每一款产品或引擎是为特定的用户场景做定制优化的,这也是经典的General Purpose(GP)和Special Purpose(SP)之间的trade-off。有很多公司尝试用General Purpose的形式解决所有的问题,但目前为止,它可能在某些场景里是最优解的,但在所有其余场景里都是次优解。当然General Purpose有个益处,对产品研发团队来说,它的ROI是最高的,持续性投入打造一款产品试图解决所有场景。 但其实存在一个问题,咱们看到有很多为专用场景设计的产品,比方缓存、嵌入式的IoT场景、边缘场景、多模,都不是GP产品能很好地解决的。到目前为止,千行百业都在做数字化转型和上云,想用一款产品解决所有的问题,从哲学上来讲,这是一种过于现实的状态,是不可能实现的。咱们想用的形式是用产品和产品的组合去满足各类业务场景的需要,相当于咱们是GP+SP的模式去做。所以这是咱们选这个主题的起因。 其次要强调“全链路”,咱们做过调研,绝大部分企业里,各类产品和解决方案都是十分纷繁复杂的,但目前它们之间的拉通和协调仍存在很大问题。咱们用云的形式可能能解决“烟囱”的问题,但其实只是解决了资源的“烟囱”,业务和数据上依然没有买通。既然数据是新的生产资料,就须要有一个数据的操作系统,咱们想用DMS来实现DataOS。这是咱们的想法,也是咱们始终致力的方向。 到目前为止,丰盛的业务场景以及外面不同的业务负载个性,使得很难用一款产品最终解决所有问题,这是咱们最大的洞察。所以咱们心愿能够带来理论的变动。 记者:您正好提到了这个观点,和我上面问到的趋势是一样的。专用数据库、多模数据库方面,显然你们的专用数据库是相似于亚马逊的,而非像微软的“一库包打天下”——一套产品利用于所有场景。当初所有的厂商其实都在聊云原生,你们的云原生架构和友商的,在演进时候有什么不一样吗? 王伟民:首先,像微软和Oracle其实只是品牌比拟聚焦和对立,但它其实也是GP、SP相组合的,Oracle有比拟多的品牌,比方面向缓存场景的叫Oracle TimesTen ,面向高可用场景的是Oracle RAC,所以Oracle有一级品牌和二级品牌之分。同样微软针对剖析、报表、集成等有SSIS、SSAS、SSRS,面向多模有Azure CosmosDB; 所以我认为大家之所以不谋而合地抉择了“迈向云原生2.0”这条路,外围起因是大家都看到负载的多样性对底层根底软件的设计太挑战了,无奈用一个架构、一套code去cover所有。 提到和友商的差别,在云原生1.0那个既往时代,大家其实曾经把产品化和服务化做完了,根本都已实现基础设施池化了,在管控上做到多租户、按需应用、按量计量,而且可能做不同水平的扩缩容。 而云原生2.0时代,更看重产品与服务之间的联动。在我方才的分享中(第十二届中国数据库技术大会)提到七个客户案例,其中没有一个场景是用单款产品去应答的。为了满足客户的转型需要,根本都须要交易型、剖析型、数据实时入仓、库仓一体等很多需要,都须要实现数据的发现、洞察和价值变现。 在咱们看来,云原生2.0时代可能会朝两个方向演进,第一,继续一直夯实、加强单品的差异化竞争力。第二,多种产品之间的高效协同和体验晋升。 记者:单品方面,要持续强化本人的劣势。整体上,你们也会强调整体解决方案的劣势,不论是OLTP、OLAP还是NoSQL,所有产品寻求更好地协同。 王伟民:咱们当初有一个想法,即把解决方案产品化。比方客户想要一个在线电商零碎,咱们能够间接提供一个有缓存和交易,两头带着链路,像一个小型数仓一样已就绪的零碎。因为起步的时候可能没有那么多数据,所以这个数仓是可扩缩容的。 尽管是在云上,但也是垂直的,业务是烟囱,资源是程度拉通的,这是咱们正在做的尝试。 解决方案产品化,其实业界有很多公司都做过。咱们可能也只能在通用计划下来做,想要联合行业畛域know how去做,可能还是比拟艰难的。 记者:如果要用一个比较简单的形式、一句话两句话去形容“云原生数据库2.0”,应该怎么去说呢?让他人一下就能了解“云原生数据库2.0”的概念。 王伟民:“一站式全链路”还是绝对偏技术术语,如果用业务术语来讲的话,应该是多引擎的高效组合,以满足客户多样化的业务负载。另外一种提法是“全场景”、“数据全生命周期”,但这些绝对偏Marketing术语。 记者:对,对于非技术人员来说,了解起来还是有点艰涩。下一个问题,其实来源于TiDB黄东旭曾提到的一个观点,他认为目前所谓的云原生数据库都不是真正的云原生,但凡能回归到线下部署的都不叫云原生。您怎么看这个观点? 王伟民:这个观点挺新鲜的,之前的确没听说过。咱们遇到过一类上云的客户会要求数据可回流、随时能够下云。客户有这个诉求的外围起因是放心云是一个超级的lock in,放心“我上了你的云,除非我挂了,否则今生今世在你这下面”。 在与客户交换的过程中,会发现有些客户比拟抵制差异化个性,放心因为差异化个性而对某厂商产生依赖。当然,在这方面也有很多不同的技术流派,有些客户在写SQL时候用的并不必数据库专用语法,它两头有一层形象层,能够适配底层的MySQL,也能够换成SQL Server或者Oracle,对他来说不可见。业界其实有这样的产品,比方Source Pro,可能对下层利用屏蔽底层数据库的差异性,所以我不太同意这个论断。 数据库产品化和云化应该是两个阶段,它能够是一个产品,这个产品能够provision在on-premise,也能够在云上,然而在云上可能施展资源弹性伸缩等很多云上所特有的能力,但并非只能在云上。 比方,RDS MySQL不能下云吗?它肯定能下云,如果依照方才的规范,它就不是云原生数据库。但如果给它做理解耦,变成AWS Aurora那样,计算和存储解耦了,Aurora是很难下来的。 是否属于“云原生”,应以客户业务场景和需要登程去思考,而非从技术实现下来判断,毕竟很多客户的要求是不一样的。比方拎包入住酒店,明天入住这个酒店,今天入住那个酒店,但酒店并不能不让客户走。 记者:你感觉他的说法是否是基于国外市场得出的论断?像您说的这种既能上又能下的,是否是国内市场特有的需要?还是说,这是寰球市场的需要?其实最近我看到一篇文章,其观点是“国外都不必分布式,所以国内要用分布式”。 王伟民:对于您提到的,这是否是国内市场的非凡状况?我感觉,将来私有云成为支流,肯定会呈现用户如何思考平台中立、云中立的问题。当初曾经看到很多相似需要了,比方客户的主站在A云,容灾在B云;另一种是穿插的,一部分业务生产在A,备份或Standby在B,另一部分业务主站在B,备站在A。客户的需要在未来可能会继续一直的变动,咱们的理念是“客户第一”,这是咱们必须思考的事件。东旭的观点目前来说比拟新鲜,但你说TiDB可不可以线下部署?必定是能够的。 对于最近看到这篇文章指的是InfoQ最近才实现底层数据库的分库,之前都是单库。就产品及其架构实现而言,首先云厂商自身是有指标市场抉择的,比如说AWS不做线下市场,它不做on-premise部署,最多有一个Outposts边缘部署,只提供受限的能力,可能是他客户抉择的问题。 记者:东旭的观点比拟超前,他们好多客户在国外,国外的市场对于私有云的拥抱水平很高,但对国内来说,显然对线下部署、混合云、公有云等,要比对私有云的拥抱水平更高,至多在金融、电信等行业奉献小户来说,相对来说是这样的。 王伟民:在私有云的大趋势方面,我的判断跟东旭是一样的。对于国内金融、电信行业很大业务负载还没有在私有云上,我认为可能有两个起因:第一,国内在信息安全、行业监管、合规遵循等方面的政策要求;第二,客户在系统软件运维治理方面的自主可控需要。 ...

November 23, 2021 · 1 min · jiezi

关于阿里云开发者:前沿分享|上海市新能源汽车数据平台-王成名-车联网全景监控数据时空超融合数据库方案

简介:本篇内容为2021云栖大会-企业级云原生数据库最佳实际论坛中,上海市新能源汽车数据平台 王成名对于“车联网全景监控数据时空超交融数据库计划”的分享。 上海市新能源汽车公共数据采集与监测钻研核心技术总监——王成名 本文将通过三个局部来介绍车联网全景监控数据时空超交融数据库计划。(基于2021云栖大会“企业级云原生数据库最佳实际”分论坛演讲内容整顿而成) 一、数据中心平台业务简介 二、平台技术架构 三、平台愿景与指标 一、数据中心平台业务简介首先,我简略介绍下咱们的组织以及咱们所做的业务。咱们是做上海市新能源汽车数据中心。咱们所做的业务是接入全上海市所有新能源汽车的数据,蕴含乘用车、商用车、物流、大巴等电动汽车数据的全接入。目前咱们平台接入数据量靠近60万辆车。咱们的数据规模曾经靠近1.5个PB,上图是咱们的监管大数据平台。 咱们数据接入是依照新能源汽车安全监管32960进行数据采集,其中蕴含38项静态数据和80多项的动态数据。包含以车辆VIN码为根底的整车数据、动员电机、驱动电机、电池以及报警等8大类数据。这些数据是典型的物联网时序数据。咱们须要对这些数据进行存储剖析并利用。 同时,咱们是多元的数据架构,咱们岂但有政府委托的数据采集治理,还有国内合作项目。咱们有新能源汽车数据平台、氢能源车站一体化平台、电池溯源治理平台、可再生能源治理平台以及智能网联汽车治理平台。咱们的指标是要致力建设成为世界级汽车产业核心的外围数据中心。 咱们基于数据面向政府,为政府政策的制订、执行和后评估提供无效数据撑持,比方新能源汽车推广报告、政府公共充电桩的选址和部署、节能减排功效评估、安全事故回溯等场景提供数据撑持。咱们还面向市场和行业提供增值服务,比方汽车后市场二手车销售、电池回收以及保险产品的设计等场景提供数据产品服务。咱们也面向高校和科研机构提供数据凋谢的服务,咱们心愿咱们的数据可能更大程度服务行业。 二、平台技术架构整体数据架构,咱们基于开源Hadoop体系构建,数据链路里应答不同场景抉择不同的架构。咱们的数据是多源异构的,有结构化数据,半结构化数据,物联网时序数据,文件数据等。依据不同的数据个性,咱们抉择不同的存储引擎。咱们构建了多协定数据采集平台。咱们有基于netty实现的数据网关接入,音讯队列( Kafka ),文件日志( flume )和数据接口API。数据存储有静态数据(RDS ),高速缓存( Redis ),热存储( Hbase ),温存储(HDFS),冷存储(OSS)等。而后咱们提供基于spark引擎的数据分析和场景化利用。 上图是咱们原有的技术架构(基于Hadoop构建的数据仓库),以后大部分互联网行业大家都会选用相似架构。很难有对立引擎解决掉数据存储问题。除此之外,现有技术无奈对时序数据进行无效剖析。为了无效剖析,咱们须要把物联网时序数据转化成构造数据来实现数据分析,这样能够简化剖析,且能够满足咱们绝大部分的业务场景。 咱们应答不同的场景抉择的这些架构,但这些架构也遇到了很多问题与挑战。大略有四个方面。第一,技术栈简单,多组件交融搭配导致技术栈高度简单,保护老本高。第二,存储碎片化。数据同步机制实现和保护,数据查问保护以及数据生命周期治理导致数据高度冗余。第三,开发门槛高。不同技术栈所用不同开发语言及工具开发门槛高,难以标准化。第四,平台扩展性挑战。咱们在容量布局,资源利用率,扩缩搬迁都有很多挑战。 通过多个产品的比照之后,咱们最终选用了阿里云Lindorm平台。外围数据存储应用多模数据存储到Lindorm(结构化、半结构化、时序数据等),数据分析仍然应用Lindorm平台提供的spark模块。阿里云Lindorm的劣势在于低成本,高可用,弹性灵便,主动数据冷热拆散,并且满足低提早。 阿里云Lindorm平台零碎架构实现了端到端的产品一体化,大幅缩小开发与保护老本,晋升易用和稳定性。反对HBase的增量数据实时主动归档为Parquet格局,并定期合并、荡涤,供Spark剖析。Spark剖析后果以 BulkLoad回流到HBase。能力产品化封装,反对通用API调用,并具备主动容错、分布式扩大、监控报警、高性能等能力。 三、平台愿景与指标 咱们举一个案例谈谈汽车数据的价值,咱们已经做过一个场景,咱们基于数据做了一个交通事故的还原,咱们把车和路网联合匹配,通过数据分析,发现车主在某个工夫点,既踩了油门又踩了刹车导致了事变的产生。如果没有这个数据的剖析,很难定责是车辆故障问题、还是用户驾驶行为问题。相似场景在事变鉴定中常常碰到,数据的价值也得以体现。 另外新能源汽车服役,它具备肯定的剩余价值。但要怎么去评判新能源汽车的剩余价值?咱们利用汽车的数据能够对用户驾驶行为和电池性能做剖析。所以咱们和合作伙伴共同开发一个app,基于咱们的数据去对汽车做残值评估。首先须要作为集体受权你的汽车数据,而后咱们能够预测你的车子还能够跑多少公里,电池残值还有多少,从而服务于汽车后市场,这是一个很典型的利用。 接下来说说咱们的愿景和指标。咱们心愿基于大数据利用开放平台构建一个凋谢的数据生态。一个基于新能源汽车、智能网联汽车数据的数据中台。咱们致力于将有价值的数据以及具有特征标签的数据,再加上咱们的数据算法包,都集中在这个平台之上。咱们心愿上下游包含政府、钻研机构及其相干产业都能够用咱们的数据和平台,互利共赢。 随着新能源的全面遍及,大数据在交通安全、以及节能减排等畛域起到很重要的作用。咱们心愿在交通安全、能源各个层面以共建,共享,共治的形式,和大家独特构建这个平台,为行业赋能。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 23, 2021 · 1 min · jiezi

关于阿里云开发者:KubeMeet-深圳站完整议题出炉快来-get-云原生边缘计算硬核技术干货

简介:11月27日 KubeMeet 深圳站,将以「云原生边缘计算」为主题,围绕业界第一个以无侵入形式延长原生 Kubernetes 到边缘计算畛域的我的项目——OpenYurt 开展技术分享和企业实际经验交流。11月27日 KubeMeet 深圳站,将以「云原生边缘计算」为主题,围绕业界第一个以无侵入形式延长原生 Kubernetes 到边缘计算畛域的我的项目——OpenYurt 开展技术分享和企业实际经验交流。 在 5G、物联网等新技术的继续推动下,边缘计算产业未然走向大风口,将来越来越多的品种,越来越大的规模和越来越简单的利用和工作负载都会被部署到边缘侧。 本场流动聚焦云原生和边缘计算交融难题,帮忙开发者解决大规模利用场景下的交付、运维、管控等挑战,让开发者能更好地应答云原生边缘计算的规模化落地。流动将邀请阿里云高级技术专家,Kubernetes Member,CNCF OpenYurt 我的项目发起人,凋谢原子基金会 TOC 成员,黄玉奇、招商云 PaaS平台部总经理,段嘉、深服气云计算开发工程师,赵震、电信天翼云研发工程师,张力方以及 VMware 主任工程师,刘武明,独特为大家分享云原生在边缘的实际与利用。 流动工夫&地址流动工夫 2021 年 11 月 27 日(周六) 13:30—18:00 流动地址 深圳-阿里核心 · 深圳后海 T4-3F 天满城 分享嘉宾及议题介绍14:00-14:20 | OpenYurt 简介及近期社区倒退与布局 黄玉奇|阿里云高级技术专家,Kubernetes Member,CNCF OpenYurt 我的项目发起人,凋谢原子基金会 TOC 成员。 领有丰盛的云原生畛域教训,多年来致力于继续摸索云原生技术新场景,新边界。 曾主导多个大型边缘计算我的项目的云原生转型,整体负责阿里云边缘计算云原生产品 ACK@Edge。 议题简介:OpenYurt 是 CNCF 官网的边缘计算云原生我的项目,由阿里云在 2020 年 5 月份主导捐献。致力于成为“一个延长原生 Kubernetes 到边缘计算的智能开放平台“,减速边缘计算云原生生态构建。本次分享次要内容包含:OpenYurt 的诞生背景、近期社区动静、落地行业案例以及社区倒退布局等。 14:20-15:00 | OpenYurt v0.5:开启边缘设施的云原生治理能力 刘武明|VMware 主任工程师 VMware OCTO,边缘计算实验室, 次要从事 Kubenretes 和边缘计算相干我的项目研发。议题简介:OpenYurt v0.5 中引入的新个性,开发者能够通过 Kubernetes-native 操作 CR(客户资源)一样的形式去管制边缘设施,让云原生治理边缘设施成为事实。 15:00-15:40 | 深刻了解 OpenYurt 张力方|电信天翼云研发工程师 天翼云研发工程师,目前从事 CDN,边缘云,容器产品的研发工作。议题简介:OpenYurt 是一个基于原生 Kubernetes 构建的开放平台,旨在对其进行扩大以及无缝反对边缘计算场景。在边缘计算场景下,原生 Kubernetes 面临着诸多挑战,通过 OpenYurt 来治理边缘应用程序,用户能够取得与核心式云计算利用治理统一的用户体验。本次分享将深入分析 OpenYurt 的原理以及架构,揭发 OpenYurt 是如何在放弃一致性体验的同时,来应答这些挑战。 ...

November 22, 2021 · 1 min · jiezi

关于阿里云开发者:从消息到数据湖看-Apache-RocketMQHudiKyuubi-最新进展

简介:聚焦音讯队列 & 数据湖场景,Apache RocketMQ with Hudi & Kyuubi上海的开发者小伙伴们,12 月 18 号,Apache RocketMQ & Apache Hudi & Apache Kyuubi (Incubating)三社区 Meetup 来了,打造最强音讯传输、实时计算、数据入湖一体化解决方案专场。 本场流动聚焦 Apache  RocketMQ 及 Hudi,Kyuubi 数据湖联合,帮忙开发者能更好地应答业务挑战。流动将邀请喜马拉雅、安全证券、网易、阿里云的泛滥技术专家,独特为大家分享 Apache RocketMQ with hudi & Kyuubi 实际与利用。 相干我的项目介绍Apache RocketMQApache RocketMQ 是由阿里巴巴开源的音讯产品,历经多年双十一流量洪峰严苛考验,具备低提早、高性能、高可靠性、万亿级容量和灵便的可扩展性。目前,寰球超过上万家企业都在应用 Apache RocketMQ,不仅包含字节、快手、小米、滴滴、同城艺龙等来自互联网的头部企业,也包含来自于头部银行、券商、保险,基金等一系列要求极为严苛的金融公司。 Apache RocketMQ 通过过来几年的倒退,曾经成为微服务畛域业务音讯的首选,随同着云原生时代的到来以及实时计算的衰亡, 生于云、长于云的 Apache RocketMQ 5.0 应运而生,全新降级为云原生音讯、事件、流交融解决平台,帮忙用户更容易地构建下一代事件驱动和流解决利用。 Github 地址: https://github.com/apache/rocketmq Apache HudiApache Hudi 是 Apache 软件基金会顶级我的项目,是新一代的流式数据湖平台,反对数据插入、更新、删除和增量数据处理;可助力构建高效的企业级数据湖。 GitHub 地址:_http://github.com/apache/hudi_ Apache Kyuubi(Incubating)Apache Kyuubi (Incubating)是一个 Thrift JDBC/ODBC 服务,目前对接了 Apache Spark 计算框架,反对多租户和分布式等个性,能够满足企业内诸如 ETL、BI 报表等多种大数据场景的利用。Kyuubi 能够为企业级数据湖摸索提供标准化的接口,赋予用户调动整个数据湖生态的数据的能力,使得用户可能像解决一般数据一样解决大数据。我的项目已于 2021 年 6 月 21 号正式进入 Apache 孵化器。从社区以后阶段的倒退指标来看,它的次要方向是依靠自身的架构设计,围绕各类支流计算框架,打造一个面向 Serverless SQL on Lakehouse 的服务。Apache Kyuubi (Incubating)是一个 Thrift JDBC/ODBC 服务,目前对接了 Apache Spark 计算框架,反对多租户和分布式等个性,能够满足企业内诸如 ETL、BI 报表等多种大数据场景的利用。Kyuubi 能够为企业级数据湖摸索提供标准化的接口,赋予用户调动整个数据湖生态的数据的能力,使得用户可能像解决一般数据一样解决大数据。我的项目已于 2021 年 6 月 21 号正式进入 Apache 孵化器。从社区以后阶段的倒退指标来看,它的次要方向是依靠自身的架构设计,围绕各类支流计算框架,打造一个面向 Serverless SQL on Lakehouse 的服务。 ...

November 22, 2021 · 1 min · jiezi

关于阿里云开发者:前沿分享|阿里云数据库解决方案资深专家-李圣陶云原生数据库解决方案-加速企业国产化升级

简介: 本篇内容为2021云栖大会-企业级云原生数据库最佳实际论坛中,阿里云数据库解决方案资深专家 李圣陶对于“云原生数据库解决方案 减速企业国产化降级”的分享。 本文从几大视角来解读云原生数据库如何减速企业的国产化降级。 一、产品大图1)场景视角云计算:外围实质是资源的池化解耦,包含明天曾经大规模应用的存储于计算拆散,以及在计算外部进一步讲CPU 与 Memory 拆散,以及在存储外部,网络外部的进一步解耦。 云原生:代表一种架构,可能把资源池化后的能力施展进去。 云数据库在企业零碎架构降级转型过程中给企业带来价值。上半局部是从场景视角看阿里云数据库的具体产品,下半局部是数据的全生命周期来看阿里云数据库的产品,包含了数据生产、集成、解决、剖析和发现,开发治理,映射到TP产品、AP产品以及服务等工具平台等。在企业中阿里云数据库能够笼罩数据的全生命周期治理,撑持政企金融类客户数字化转型,包含明天的国产化、搬站、异地多活、数据中台和金融风控等等场景。 2)技术视角 上图左侧是云厂商和云数据库产品提供的根本技术能力,右侧是笼罩政企和金融类客户的业务场景。阿里云数据库提供从技术外围到云原生再到云服务的政企金融客户的一站式反对。 二、云原生数据库2.0:一站式全链路数据管理与服务 一站式全链路数据管理与服务2.0笼罩了整个数据资产、数据库设计、开发、集成和数据库服务,提供数据的全生命周期治理,反对开源、阿里云自研和商业数据库引擎。 三、笼罩数据生产解决生产全流程的自研数据库生态 上图案例是咱们自研数据库的生态状况,技术实例和技术影响力取得了多项国内和国内的大奖。 四、云数据库平台建设解决方案—实现业务零碎平滑上云, “上好云,用好云” 如何让传统IDC政企金融客户的数据库平滑上云并享受云数据库的技术红利?云数据库平台建设解决方案为企业提供平滑上云服务,使客户可能享受到丰盛且强劲的云数据库引擎、一站式治理服务,客户取得开箱即用、按需弹性,功能丰富、性能强劲的技术价值。在政府、批发、游戏、娱乐和交通物流等行业曾经获得了丰盛的胜利客户案例。在这个过程中,客户最关怀迁徙上云过程中是否平滑、云原生零碎是否须要原零碎大规模革新,针对这些问题咱们在数据迁徙环节提供前置评估工具,可能把业务原来用的数据库个性进行扫描后与指标云数据库进行比照,前置评估数据库性能、字段类型、存储过程等的兼容性,以及如何改、工作量评估,让客户可能做到成竹在胸。并且用较短时间就可能取得成果,业务切换后丰盛的数据库产品提供多模数据库能力。 五、自研云数据库产品—— 解决各行各业全链路应用国产核心技术诉求 阿里云自研数据库产品是通过公共云最大规模实际,也是通过阿里巴巴自有业务最大规模实际的企业级数据库。反对客户简单且丰盛的多样性业务场景。在政府、能源、金融、运营商行业都获得了良好的成果,阿里云数据库岂但数据库软件做到了国产化,同时全面反对从服务器芯片到操作系统的全站式国产化。满足国家技术自主可控的诉求,帮忙企业零碎实现高兼容平滑迁徙,反对丰盛的业务场景挑战。同时,阿里云作为大型云厂商,在国产化技术路上的长期投入,会从根本上解决客户国产化技术断供危险。 明天,大家都在拥抱开源,什么样的开源才是真正有意义的开源?开源绝不仅仅是把代码凋谢进去,更要有凋敝的开源生态,更要有大厂玩家。否则几百万行的源代码,在头部玩家退出后,整个开源会迅速萎缩,对企业而言就是失去了技术支持,面临不得不从新抉择技术路线的危险,这种没有生命力的开源是没有意义的开源。明天的MySQL开源生态体系里有阿里、腾讯、华为等泛滥开源大厂,我认为这个开源生态是凋敝的,多撑持的,在这个生态内的所有企业是可能取得长期技术支持的。 六、数据中台解决方案——“数字化转型”数据驱动业务翻新 考验企业数字化能力很重要的指标包含数据的实时性和数据应用的老本,业务数据从生产到剖析再到领导生产,这个环路有多短决定了实时性,数据应用是否可能下发到一线业务小二并帮忙小二疾速验证各种业务模型决定了咱们可能施展出多大的数据价值。只有把应用数据的能力配发到对数据有感知人的人员能力施展数据的价值。是否能疾速返回模型剖析论断,并一直试错修改数据模型才是考验企业应用数据的能力。当初阿里提供低门槛对立存储交融剖析的能力,能做到千亿级数据毫秒级返回。海量数据面临的下一个问题是低成本存储,热的数据用ESSD,比拟冷的数据用OSS,再冷的数据用OAS,再冷的数据能够存在不加电的设施中。数据分层存储计划很好的解决了海量数据的低成本存储问题。 数据中台解决方案在落地过程中帮忙金融、电商、数字娱乐和物流行业的客户很好的施展了数据价值。 七、案例:1)保险行业:数据库迁徙替换我的项目 明天的保险行业曾经不再那么传统,引入很多互联网化的业务,比方通过APP帮忙大家一起健身、疫情期间在线签单、在线买保险、保险常识在线培训等等。随同着业务的倒退,保险行业也逐渐从传统IDC机房开始向云上迁徙,保险行业应用云数据库产品背地的三个诉求: 实现数据大集中,存储空间可能灵便弹性解脱对国外数据库厂商的依赖,升高软件受权费用疾速实现国产化,实现技术自主可控客户用Polar DB计划落地后客户也失去明确的成绩: 实现了外围零碎替换满足了国产化自主可控。解决能力晋升,Polar DB弹性能力为业务提供了很好的撑持。欠缺的管控平台、监控体系、内核、云上研发反对人员实时响应,大幅晋升了运维效率。2)税务行业:数据中台数据库解决方案 在税务管理系统演进的过程中,客户对咱们的产品提出了挑战: 稳定性诉求,简单国家级利用,影响每个报税人的利益,波及到国计民生。高性能诉求,要求业务秒级响应速度,撑持全国税务机关进行实时查问、剖析,进行各项税务业务管理。2、计划劣势: 通过成熟的云数据库产品和容灾架构,提供9999的稳定度保障通过强劲的剖析引擎产品,实现交互式剖析的查问能力,帮忙税务管理人员疾速剖析数据,实时白屏化界面进行勾选剖析。对立数据安全治理和冷热数据分层存储,解决老本和平安问题。3)运营商行业:实时数仓解决方案 几大运营商通过几十年IT零碎建设,曾经具备了欠缺的运行管理机制,但随同业务的倒退,运营商提出了两个典型诉求: 1.强烈要解脱国外传统架构。 2.施展数据价值,把数据间接赋能给一线人员帮忙实现业务增长。 阿里云解决方案: 帮忙运营商实现了全国产化的链路实时扩缩容和弹性的外围劣势。多租户技术,解决省级市级公司数据隔离问题。买通数据通路的卡点,能够笼罩26种以上数据源类型。通过低成本的存储和应用升高运营商在应用过程中的老本。八、深耕企业级客户需要,提供通用解决方案随同企业业务的疾速倒退,对业务翻新冲破的诉求越来越强烈,阿里云数据库越来成为大家的一个不错选项,这里总结了一些更加通用的场景和对应的产品,便于大家在将来的工作中参考: 云化+自主可控诉求 :公共云—MyBase 混合云—DBStack。数据无缝流动,数据在线利用与开发诉求 :在线数据资产治理平台—数据传输。数据安全的诉求 :数据脱敏、加密、多方平安计算。智能化+云原生运维诉求 :AI4DB - K8S+容器化部署云原生DBPaaS+DAS; DB4AI-非结构化数据处理。凋谢生态的诉求 :RDS, PolarDB, AnalyticDB, Tair开源生态社区领导力,开发者生态的建设。云原生+分布式+企业级能力降本增效诉求 :Serverless, 多租户,共享内存,Multi-Master, 资源隔离。信创+国产化诉求:Oracle数据迁徙,传统数仓降级需要(PolarDB+DTS+ADAM+AnalyticDB联结解决方案)。用户体验+稳定性诉求: Open API,Terraform, 文档,控制台优化,备份上云,SLA降级等。九、云原生分布式数据库,铸就行业榜样 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 22, 2021 · 1 min · jiezi

关于阿里云开发者:前沿分享|阿里云数据库高级技术专家-宋利兵阿里云企业级自治数据库RDS详解

简介:本篇内容为2021云栖大会-企业级云原生数据库最佳实际论坛中,阿里云数据库高级技术专家 宋利兵对于“阿里云企业级自治数据库RDS详解”的分享。 本文将从2方面为大家介绍企业级的自治的数据库系统。 RDS MySQL 产品RDS MySQL 自研内核 一、RDS MySQL 产品1)阿里云RDS - 云原生自治数据库 阿里云RDS是国内起步最早的RDS服务,基于阿里巴巴的MySQL分支AliSQL。在阿里巴巴实现IOE指标后,阿里巴巴整个电商业务由RDS撑持。RDS的可靠性和稳定性是通过了双十一这样极其刻薄的事实场景的验证的。通过十几年的倒退,除了在稳定性、性能等方面有长足的倒退之外,阿里云RDS也在动摇的向云原生和智能化的方向迈进,当初RDS整体架构基于云原生K8S进行部署和治理,底层依靠于阿里云的高性能ECS和高吞吐的ESSD分布式云存储,真正做到了计算和存储的拆散。基于人工智能的技术和专家的教训,实现DAS的 RDS自治能力。 2)RDS MySQL 产品 - 服务高可用 从产品层面看,高可用是MySQL生态里经典的架构,通过binlog进行复制,RDS提供跨可用区的高可用,能够做到4个9的可用性和秒级的切换。 除了经典的两节点架构,RDS还基于多数派协定提供了三节点高可架构。在三节点高可用架构中,包含主和备两个数据节点和一个日志节点,让用户的数据0失落做到RPO等于0。这个复制不是用MySQL原生binlog复制,而是采纳本人实现的多数派协定(Consensuse)进行binlog的散发。 除了热备、RDS也提供了冷备的能力。RDS能够周期性做全量数据备份、以及实时binlog的备份,并把数据上传到OSS上。如果有数据恢复需要时,能够疾速通过OSS进行数据恢复。 3)RDS MySQL 产品 – 资源池化和云原生 在计算与存储拆散的架构下,RDS实例能够提供高达32TiB的存储量。全量数据备份采纳的是快照的形式进行的,无论用户数据有多大,都能够做到秒级备份,真正做到用户无感。基于秒级的数据快照能力,RDS做到了分钟级的实例创立。创立只读实例大略在两三分钟就能够实现。 4)RDS MySQL 产品 – 主动读写拆散 只读节点是MySQL里经典的架构,通过创立只读实例扩大读的能力,阿里云的RDS上提供两头介让用户利用不做批改主动实现读写拆散。提供多地址的读写拆散能够把不同的业务用不同的地址拜访,益处是业务之间不会相互影响和地址的隔离性能十分好。 5)RDS MySQL 产品 – 企业级数据安全 当初平安越来越被器重,云上有很多用户有合规、审计等需要,RDS为用户提供了全链路加密的能力、以及审计日志等平安能力,除此之外,用户还能享受到阿里云网络层面和操作系统层面的平安设施。从整体看,能够做事前、事中、预先十分严格的平安合规要求。 6)RDS MySQL 产品 - 整体架构 RDS不只有MySQL的内核还有很多模块一起为用户服务,用户只需通过控制台进行管制,或者通过OpenAPI来创立或者治理实例就能够了,剩下的工作由RDS主动实现。 二、RDS MySQL 自研内核1)实用性:在线固化SQL执行打算 在线上应用RDS的时候会用户会遇到SQL特地慢的状况,因为一些起因SQL可能没有抉择到最优执行打算,MySQL提供hint的性能,用户能够在SQL语句里加hint来提醒MySQL是否要应用索引,或者是否开启某一项优化器的策略。通过Hint来进步SQL的执行效率。 为什么这个性能用户用得很少?因为当发现SQL慢的时候,利用曾经在线运行了。这时批改利用里的SQL、可能须要一个漫长的过程、甚至不可能批改。SQL Outline让用户能够在RDS服务器侧为SQL语句增加Hint。只须要调用一个存储过程。比方加一个Index Hint,只需在add\_index\_outline中指定这个SQL语句,以及对应的索引策略即可。在做规定匹配时,Where条件中的值会主动疏忽掉,同样的语句不同的值,都会匹配到这条规定。用户的利用不须要做任何变动,加上规定后会立刻失效,这是十分实用的性能 。 2)实用性:可诊断、可度量 咱们加了大量的监控和诊断信息,可分为实例级别、对象级别、语句级别三大类。 实例级别的指标十分多,把MySQL和零碎里的指标以秒为单位存储到表里去,让用户十分不便地通过MySQL语句查问。包含实例的CPU应用状况、内存应用状况、磁盘IO状况、Server层连贯数量、网络拜访状况,曾经InnoDB中的大量状态信息。RDS把这些状态信息以秒为单位记录下来,呈现问题时很容易通过状态的变动精确地定位出问题。 对象级别增加加了对表应用和Index应用的统计,为咱们做数据结构的调整提供了根据。 语句级别MySQL有一个语句级别的统计信息表,RDS在这个表里增加了一些十分实用的信息。比方:语句应用CPU的工夫,MDL、InnoDB锁期待的工夫,Mutex的spin、wait的统计信息,Read/Write IO的统计信息。这些统计项帮忙用户准疾速精准的定位SQL的问题。 3)稳定性:Buffer Pool优化 云原生下须要可能做到在线规格的调整,Buffer Pool就是很重要的资源。当规格、内存变动的时候Buffer Pool也须要跟着变动,MySQL提供在线调整Buffer Pool大小的能力。在测试中,咱们发现MySQL Buffer Pool Resize会对业务流量造成肯定的影响。业务流量抖动的频率和幅度都很大(绿色线条)。阿里云RDS在Buffer Pool Resize上做了优化,优化后、Buffer Pool Resize对业务流量的影响就好了很多(蓝色线条). 4)稳定性:并发管制 线上常常碰到某些SQL语句会应用大量的CPU资源或者内存资源。如果不做限度,可能会耗光CPU、内存资源,导致整个实例不稳固。并发管制这个性能能够用来限度特定SQL的并发数量。并发管制的策略能够分为三个维度:操作类型、操作对象、关键字。操作类型指的是SELECT、INSERT、UPDATE、DELETE四种类型。操作对象指的是库、表。并发管制和SQL Outline差不多,都是在RDS服务侧配置的。 5)安全性:通明数据加密 通明加密反对AES加密算法和国秘算法SM4。因为有些单位有合规要求,必须应用国密算法。 6)安全性:回收站 回收站是表级的数据疾速找回的工具。当用户删除表或者Truncate表的时候,表不是间接从磁盘上删除,而是放到回收站里。用户能够设置多长时间后主动在后盾把表真正删除,当产生了误操作,谬误的删除或者清空了表时,能疾速从回收站中找回表。 7)安全性:Flashback Query Flashback Query提供了疾速找回数据行的能力。行级数据找回的性能利用了Undo外面的历史数据。RDS能够以秒为单位,为历史数据建设快照。RDS提供了基于工夫的快照查问机制,通过Undo的记录回溯到指定工夫的历史数据。当产生了误操作、或者有回档需要时,用户能够通过SELECT查问到指定工夫点的历史数据。 8)高性能 – Binlog In Redo ...

November 20, 2021 · 1 min · jiezi

关于阿里云开发者:2021云上架构与运维峰会将于12月4日在上海举办五大精彩看点不容错过

简介:本次峰会,心愿通过分享云上架构与运维的最佳实际,促成业内DevOps与IaC理念的落地,帮忙企业“用好云管好云”,开释云的技术红利。报名链接 12月4日,2021云上架构与运维峰会,将在上海静安洲际酒店3层奢华宴会厅举办。 (峰会原定于11月6日北京举办,因疫情起因延期并改地点到上海,北京的同学欢送持续在官网预约或观看直播) 本次峰会,心愿通过分享云上架构与运维的最佳实际,促成业内DevOps与IaC理念的落地,帮忙企业“用好云管好云”,开释云的技术红利。 云计算所领有的“软件定义所有”的个性,推动了麻利弹性、DevOps、智能运维和基础设施即代码等自动化运维趋势。云计算,曾经是任何一个运维人员、架构师,甚至是程序员必备的专业技能和常识。 小编为你总结了本次峰会的五大看点: 上手体验云端自动化工具,支付精美礼品阿里云技术大咖,分享云原生时代架构与研发运维体系进化方向云上自动化运维(CloudOps)成熟度模型公布,帮忙企业自测CloudOps阶段优良企业分享云上架构与运维的最佳实际,欢送互相学习、交流经验资深技术从业人员,探讨国内运维与DevOps现状、分享从业发展前景心动不如口头,点击报名链接或扫描下方海报底部的二维码,即可报名 更多嘉宾介绍和材料下载,欢送进入大会官网 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 19, 2021 · 1 min · jiezi

关于阿里云开发者:1024创造营精彩课程回顾

简介:开发者学堂联结多个团队发展的【1024发明营】圆满结束,精彩课程回顾已打包,请查收!1024 万人发明营,笼罩低代码、云原生、人工智能、视频云、运维等畛域,通过coding 扭转世界,保持对于常识、技术和翻新谋求的程序员们示意致敬。万人发明营的课程也失去了参加学员的宽泛认可,为不便更多用户能够学习,咱们将此次训练营的课程整顿好分享给大家! 【1024发明营】大咖“文言”ServerlessServerless 架构在一直的倒退,也在一直的更新迭代,然而在以后阶段Serverless 架构是 什么样子的,为什么能够作为云计算的必然产物,在倒退过程中目前面临了哪些艰难和挑 战?大咖“文言”Serverless 训练营,让你疾速从入门走向Serverless 实际。 阿里云策略级开源我的项目ServerlessDevs 发起人和负责人江昱带你“文言”Serverless。 课程地址:https://developer.aliyun.com/learning/course/890 【1024发明营】4天定制混合云利用交付流水线训练营阿里云高级技术专家,CNCFAppDeliverySIGCo-chair、OAM/KubeVela 社区 负责人带你攻破K8s 难点,定制混合云利用交付流水线。 课程地址:https://developer.aliyun.com/learning/course/893 【1024发明营】4天Docker 实战开发者学堂联结马哥教育,从根底到实际全方位讲透Docker。 分析Docker 及在运维工作中的位置和作用,讲述Docker、微服务、k8s的分割,Devops 和Docker 的关系。并介绍容器,镜像和仓库概念。包含容器和虚拟化、劣势和劣势、底层外围相干常识。学习Docker 利用常识、常用命令、镜像原理、Dockerfile 利用、Docker 永恒存储和网络通信等,还会手把手带你搭建一台公有仓库,实现一个案例。 课程地址:https://developer.aliyun.com/learning/course/892 【1024发明营】AI语音技能云开发从【Hello World】技能应用环境筹备,进入技能后能够失去一个欢送语,到【小百科实战】以小百科技能为例,走一个残缺的实际流程。天猫精灵利用平台开发大神手把手带你学习。 课程地址:https://developer.aliyun.com/learning/course/897 【1024发明营】钉钉搭-氚云低代码训练营低代码作为一种软件开发新趋势,凭借独有的生产力劣势和外围价值,正在被越来越多的企业应用开发者关注和应用。钉钉搭是国内首个一站式低代码聚合平台,联结头部低代码厂商氚云,带你把握低代码搭建技术,取得业务场景数字化思维及搭建能力。 课程地址:https://developer.aliyun.com/learning/course/896 【1024发明营】面对运维的 python 脚本速成Python 作为一个编程语言,具备简略、易学,对运维敌对的个性,对于运维工程师来说,学习Python 能够帮忙运维工程师更好的实现运维工作,晋升运维和开发的效率。 Linux 中国技术社区技术负责人,资深技术专家带你学习Python 脚本速成。 课程地址:https://developer.aliyun.com/learning/course/895 【1024发明营】DEEPVIDEO 智能视频生产技术训练营阿里云智能视频云技术专家、智能视频云高级产品专家、智能视频云高级算法专家联结出品,把握视频云技术畛域的典型场景——视频智能生产的技术架构,并且配合实际课程,可能让开发者疾速把握目前智能视频生产中的核心技术和技能。 课程地址:https://developer.aliyun.com/learning/course/902 【1024发明营】基于Mysql和MongoDB的Java Spring Boot 2.6.0电商网站开发实战基于最新的springboot2.6.0实战,蕴含mysql8.0数据库实战开发,蕴含mongodb数 据库实战,涵盖高并发缓存redis6.0。 课程地址:https://developer.aliyun.com/learning/course/903 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 19, 2021 · 1 min · jiezi

关于阿里云开发者:云原生-DevOps模型化应用交付能力很重要

简介:DevOps 文化及其撑持其落地实际的自动化工具与平台能力在云原生架构渐为遍及的背地,施展了要害的价值。撰稿:溪洋 审核校对:_天元、_海珠 编辑&排版:雯燕 云原生正在成为企业业务翻新和解决规模化挑战的加速器。 云原生带来的改革绝不限于基础设施和利用架构等技术层面,更是对于研发理念、交付流程和 IT 组织形式的改革,也在推动企业 IT 组织、流程和文化的改革。在云原生架构渐为遍及的背地, DevOps 文化及其撑持其落地实际的自动化工具与平台能力,施展了要害的价值。 云原生带来的研发与运维合作界面相较于云原生,DevOps 并不是什么陈腐的事件,其实际早已深刻企业古代应用程序架构。DevOps 强调团队间的沟通和疾速反馈,通过构建自动化的继续交付(Continuous Delivery)及流水线的利用公布形式,达到疾速响应业务需要、交付产品和进步交付品质的目标。随着容器技术在企业的规模化利用,云计算可编程基础设施和 Kubernetes 申明式的 API 等能力减速了开发和运维角色的交融。 云原生的大势所趋使上云成为企业标配,围绕云原生去定义下一代研发平台成为必然,也倒逼着 IT 组织形式进一步发生变化——新的平台工程团队开始浮现。在这样的背景下,如何在云原生的环境下更高效地实际 DevOps 成为一个新的课题和诉求。 下一代 DevOps 平台演进趋势随同着 Kubernetes 生态从底层到应用层能力的逐步完善,平台工程团队能够更不便地基于业务场景和终端用户理论需要来构建不同的利用平台,却也为下层利用开发者带来了挑战和困扰。 Kubernetes 生态自身的能力池诚然丰盛,然而社区里却并没有一个可扩大的、方便快捷的形式,为云原生架构下混合、分布式的部署环境引入统一的下层形象来为利用交付进行建模。利用交付过程下层形象能力的缺失,使 Kubernetes 的复杂性无奈做到向利用开发人员屏蔽。  下图展现了一个云原生下的 DevOps 流水线的典型流程。首先是代码的开发,代码托管到 Github,再接入单元测试的工具 Jenkins,此时根本研发已实现。再接着到镜像的构建,波及到配置、编排等。云原生中能够用 HELM 打包利用。打包好的利用部署到各个环境中。但整个过程中会面临很多挑战。 首先,在不同的环境须要不同的运维能力。其次,配置的过程中要创立云上数据库,须要另外关上一个控制台来创立数据库。还须要配置负载平衡。在利用启动当前还须要配置额定的性能,包含日志、策略、平安防护等等。能够发现,云资源和 DevOps 平台体验是割裂的,外面充斥着借助内部平台创立的过程。这对老手来说是十分苦楚的。 在容器呈现之前的传统的 DevOps 模式须要不同的流程和工作流。容器技术是以 DevOps 的视角构建的。形象的容器所提供的性能会影响咱们如何对待 DevOps,因为随着微服务的呈现,传统的架构开发将发生变化。这意味着要遵循在 Kubernetes 上运行容器的最佳实际,并将 DevOps 的理念向 GitOps、DevSecOps 扩大,使云原生下的 DevOps 更加高效、平安、稳固、牢靠。 OAM(Open Application Model) 试图提供一种云原生利用的建模语言,以实现研发和运维的视角拆散,使 Kubernetes 的复杂性无需透传至研发,运维通过提供模块化、可移植、可扩大的个性组件,撑持各种简单的利用交付场景,从而实现云原生利用交付的敏捷性和平台无关性。其在 Kubernetes 上的残缺实现 KubeVela,曾经被业界认为是构建下一代继续交付形式及 DevOps 实际的外围工具。 ...

November 19, 2021 · 2 min · jiezi

关于阿里云开发者:ALB-Ingress-发布轻松应对云原生应用流量管理

简介:阿里云容器服务 ALB Ingress Controller 基于应用型负载平衡 ALB(Application Load Balancer)之上提供全托管免运维的 Ingress 流量治理。依靠阿里云容器服务 Kubernetes 产品,兼容 Nginx Ingress 语义,具备配置以及治理简单业务路由的能力,证书主动发现,流量入口可观测,同时反对多种应用层协定(QUIC 等),具备大规模七层流量解决能力,让用户轻松应答云原生利用流量治理。作者:元毅 审核校对:溪洋、海珠 编辑&排版:雯燕 背景随着云原生利用微服务化、Serverless 化,用户须要面对简单路由规定可配置、反对多种应用层协定(HTTP、HTTPS 和 QUIC等)、服务拜访的安全性以及流量的可观测性等诉求。传统的基于四层 SLB Ingress ,已无奈满足这些诉求。 阿里云容器服务 ALB Ingress Controller 基于应用型负载平衡 ALB(Application Load Balancer)之上提供全托管免运维的 Ingress 流量治理。依靠阿里云容器服务 Kubernetes 产品,兼容 Nginx Ingress 语义,具备配置以及治理简单业务路由的能力,证书主动发现,流量入口可观测,同时反对多种应用层协定(QUIC 等),具备大规模七层流量解决能力,让用户轻松应答云原生利用流量治理。 ALB 产品应用型负载平衡 ALB(Application Load Balancer)是阿里云推出的专门面向 HTTP、HTTPS 和 QUIC 等应用层负载场景的负载平衡服务,具备超强弹性及大规模七层流量解决能力。 ALB 个性弹性主动伸缩:ALB 同时提供域名与 VIP(Virtual IP address),反对对多台云服务器进行流量散发以扩大利用零碎的服务能力,通过打消单点故障来晋升利用零碎的可用性。ALB 容许您自定义可用区组合,并反对在可用区间弹性缩放,防止单可用区资源瓶颈。高级的协定反对:ALB 反对利用传输协定 QUIC,在实时音视频、互动直播和游戏等挪动互联网利用场景中,访问速度更快,传输链路更安全可靠。ALB 同时反对 gRPC 框架,可实现海量微服务间的高效 API 通信。基于内容的高级路由:ALB 反对基于 HTTP 标头、Cookie、HTTP 申请办法等多种规定来辨认特定业务流量,并将其转发至不同的后端服务器。同时 ALB 还反对重定向、重写以及自定义 HTTPS 标头等高级操作。平安加持:**ALB自带分布式拒绝服务 DDoS(Distributed Denial of Service)防护,一键集成 Web 利用防火墙(Web Application Firewall,简称 WAF)。同时 ALB 反对全链路 HTTPS 加密,能够实现与客户端或后端服务器的 HTTPS 交互;反对 TLS 1.3 等高效平安的加密协议,面向加密敏感型业务,满足 Zero-Trust 新一代平安技术架构需要;反对预制的安全策略,您能够自定义安全策略。云原生利用:在云原生时代,PaaS 平台将下沉到基础设施,成为云的一部分。随着云原生逐渐成熟,互联网、金融、企业等诸多行业新建业务时抉择云原生部署,或对现有业务进行云原生化革新。ALB 与容器服务 Kubernetes 版(Alibaba Cloud Container Service for Kubernetes,简称 ACK)深度集成,是阿里云的官网云原生 Ingress 网关。弹性灵便的计费:ALB 通过弹性公网 IP(Elastic IP Address,简称EIP)和共享带宽提供公网能力,实现公网灵便计费;同时采纳了更先进的、更适宜弹性业务峰值的基于容量单位(LCU)的计价计划。阿里云容器服务 ALB Ingress Controller阿里云容器服务 ALB Ingress Controller 是基于阿里云应用型负载平衡 ALB(Application Load Balancer)之上提供更为弱小的 Ingress 流量治理形式,兼容 Nginx Ingress,具备解决简单业务路由和证书主动发现的能力,反对 HTTP、HTTPS 和 QUIC 协定,齐全满足云原生利用场景下对超强弹性和大规模七层流量解决能力的需要。 ...

November 19, 2021 · 2 min · jiezi

关于阿里云开发者:今年双-11阿里业务-100-上云云原生有哪些技术亮点

简介:2021天猫双11是首个100%的云上双11,整体计算成本三年降落了30%。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 19, 2021 · 1 min · jiezi

关于阿里云开发者:EDAS-40-助力企业一站式实现微服务架构转型与-K8s-容器化升级

简介:EDAS 正式来到 4.0 时代,公布多项重磅新能力;同时联结新产品—云原生利用设计开发平台 ADD 1.0,一起公布云原生利用研发&运维 PaaS 产品家族,助力企业应用架构现代化降级。作者:安绍飞 审核&校对:营火 编辑&排版:雯燕 前言近年来,企业的数字化随着互联网的遍及倒退越来越快,技术架构也是几经更迭,尤其是在线业务局部。最开始企业的需要就是将业务尽可能在线化、线上化,产生了晚期的在线业务利用架构,即单体利用,次要就是由 Web 利用中减少业务逻辑及后端数据存在数据库。 随着在线业务的减少,以及更多的拜访增长,发现单体利用曾经支撑不了业务了,进而逐渐演进到分布式应用。同时,前端加上了负载平衡来承接日渐增长的申请,两头也引入了更多音讯、缓存等中间件和数据库。 随着云计算的倒退演进到云原生时代,企业的利用也开始面向云进行容器化、微服务化的构建,在这个过程中,就带来了和之前阶段不同的变动,形象来看次要是利用的开发设计、利用交付、线上运维方面的变动。 云原生应用服务的新诉求在云原生利用日益成为支流的技术架构下,云原生利用如何更好的利用云服务,实现面向云服务的架构设计、让业务更麻利的研发,疾速的联调验证就尤为重要。这就要求平台能够提供一站式的 PaaS 产品来进行撑持。 1)首先是开发设计:从原来的层次化/模块化单体架构,演进到全面的微服务化,应用 SpringCloud、Dubbo、Servicemesh 这一些技术栈来构建微服务,那这个过程中,研发人员须要进行面向微服务的架构设计、测试人员须要面向微服务架构设计测试用例,编写实现自动化测试、同时随着环境上云,也要求着开发环境与云端环境可能实现联通调试。 2)接着是利用交付:从之前的虚拟机&批量脚本来实现部署交付,到通过容器、K8s 等技术实现通用的标准化交付,这个过程中,也呈现了一些新的需要,比方批量的通过利用模板来疾速部署交付、以及通过利用跨集群来实现多场景的治理交付。 3)第三局部是线上运维的变动:从原来的虚拟机维度运维,演进到容器集群维度的运维,须要有更高的视角来帮忙企业的开发运维同学,这里咱们提出鸟瞰式运维理念,通过利用视角鸟瞰 K8s 所有资源,运维治理的不再是独自针对 Deployment、Service、Ingress 这些 K8s 原子资源进行,而是鸟瞰式的对立监管控实现运维。 EDAS 4.0 全面降级 &ADD 1.0 重磅公布针对下面提到的生命周期三个阶段新场景演进产生的新诉求,EDAS 正式公布了 4.0 版本,新增多集群利用治理、微服务 API 治理与测试、端云联调 3.0 等新能力。同时重磅公布新产品 --- 云原生利用开发设计平台 ADD v1.0,大大晋升云原生利用的开发效率。 接下来将为大家逐个具体介绍。 云原生应用设计开发平台 ADD 1.0公布针对开发设计阶段的需要,云原生利用设计开发平台 ADD 这个产品应运而生。ADD 产品的设计初衷就是为了晋升企业在云原生利用开发设计阶段的工作效率,进步生产力。它有 6 大特色: 可视化利用架构设计:帮忙企业不便的积淀与保护原来在线下白板上的架构探讨设计;前端网页利用拖、拉、拽设计:实现前端“无代码”开发;后端代码在线开发与调试:保障代码平安;一站式集成面向接口的测试用例治理与自动化执行配置能力:实现在线自动化测试;集成支流项目管理工具:进步云原生化开发项目管理效率;业务利用组件高效复用:借助利用组件商店,实现全面的资产复用; EDAS 4.0 全新降级——微服务 API 治理与测试在微服务化的过程场景里,咱们总结出这样三个挑战: 多环境的适配挑战:因为微服务有不同的研发团队,环境也是多种多样,在面对相应的微服务环境时,就须要做专门的配置适配,比方测试的参数、自动化用例的抉择等等。利用的可测性挑战:随着企业的资源逐步云化治理,利用也大都部署在公共云或当初专有云环境,这样就带来了很多可测性挑战,比方阿里云的 VPC 环境内无奈间接外网拜访,须要弹性 IP 或其余买通计划;并且随着利用容器化,在 K8s 内的网络拓扑也会带来相应的复杂度。用例生成的挑战:很多状况下,开发会专一于业务研发,无形中给测试同学带来了沟通合作的老本,因为不了解微服务接口的契约,就无奈很快的实现用例生成。为了解决以上挑战,咱们提供云上微服务一键测试工具(API 治理与测试)针对性的解决相应问题: ...

November 18, 2021 · 1 min · jiezi

关于阿里云开发者:如何用20分钟就能获得同款企业级全链路灰度能力

简介:MSE 微服务引擎将推出服务治理专业版,提供开箱即用且残缺业余的微服务治理解决方案,帮忙企业更好地实现微服务治理能力。如果您的零碎也能够像本文形容的那样,疾速具备残缺的全链路灰度能力,并基于该能力进行进一步的微服务治理实际,不仅能够节俭主观的人力与老本,还能够让您的企业在微服务畛域的摸索更加有底气。作者:十眠 审核&校__对:望陶、亦盏 编辑&排版:雯燕 往年双 11,云原生中间件实现了开源、自研、商业化三位一体,全面降级到中间件云产品。MSE 微服务治理通过 Dubbo3.0 撑持了阿里团体外围业务双 11 的流量洪峰,截止目前团体内 50% 的用户曾经习惯应用 MSE 微服务治理 HSF 和 Dubbo3.0 利用,明天咱们来细聊一下 MSE 服务治理专业版中的全链路灰度能力,以及它在生产大规模实际的一些场景。 背景微服务架构下,有一些需要开发,波及到微服务调用链路上的多个微服务同时产生了改变,须要通过灰度公布形式来更好地管制新版本服务上线的危险和爆炸半径。通常每个微服务都会有灰度环境或分组来承受灰度流量,咱们心愿通过进入上游灰度环境的流量,也能进入上游灰度的环境中,确保 1 个申请始终在灰度环境中传递,即便这个调用链路上有一些微服务没有灰度环境,这些利用申请上游的时候仍然可能回到灰度环境中。通过 MSE 提供的全链路灰度能力,能够在不须要批改任何您的业务代码的状况下,可能轻松实现上述能力。 MSE 微服务治理全链路灰度特点全链路灰度作为 MSE 服务治理专业版中的拳头性能,具备以下六大特点 可通过定制规定引入精细化流量除了简略地依照比例进行流量引入外,咱们还反对 Spring Cloud 与 Dubbo 流量按规定引入,Spring Cloud 流量可依据申请的 cookie、header、param 参数或随机百分比引入流量,Dubbo 流量可依照服务、办法、参数来引入。   全链路隔离流量泳道1) 通过设置流量规定对所需流量进行“染色”,“染色”流量会路由到灰度机器。 2) 灰度流量携带灰度标往上游传递,造成灰度专属环境流量泳道,无灰度环境利用会默认抉择未打标的基线环境。 端到端的稳固基线环境未打标的利用属于基线稳固版本的利用,即稳固的线上环境。当咱们将公布对应的灰度版本代码,而后能够配置规定定向引入特定的线上流量,管制灰度代码的危险。 流量一键动静切流流量规定定制后,可依据需要进行一键停启,增删改查,实时失效。灰度引流更便捷。 低成本接入,基于 Java Agent 技术实现无需批改一行业务代码MSE 微服务治理能力基于 Java Agent 字节码加强的技术实现,无缝反对市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本,用户不必改一行代码就能够应用,不须要扭转业务的现有架构,随时可上可下,没有绑定。只需开启 MSE 微服务治理专业版,在线配置,实时失效。 具备无损高低线能力,使得公布更加丝滑利用开启 MSE 微服务治理后就具备无损高低线能力,大流量下的公布、回滚、扩容、缩容等场景,均能保障流量无损。 ...

November 18, 2021 · 6 min · jiezi

关于阿里云开发者:干货分享细说双-11-直播背后的压测保障技术

简介:阿里云 PTS 站在双 11 伟人的肩膀上,是阿里全链路压测的延长。PTS 通过伸缩弹性,轻松发动用户百万级别的流量,免去机器、人力老本;PTS 对流量的管制,可能实时脉冲,精准管制; 是应答视频直播疾速攀升的流量脉冲的优良计划。作者:子矜 审核&校对:风波 编辑&排版:酒圆 “往年 1 月到当初,淘宝直播的用户超过了 5 亿,到 8 月份流量也增长了 59%,在最外围的商家 GMV 上增长了 55%。双 11 是从 10 月 20 日晚开始的,咱们心愿淘宝直播作为主场去承接这件事件。”日前,淘宝事业群直播事业部负责人程道放在承受 21 世纪经济报道记者采访时走漏,过来一年的直播堪称冷落,往年会更加专业化。 如此大的用户体量下,直播类利用给后端服务带来了一些什么不一样的挑战呢?咱们明天来介绍一些直播的架构,以及针对这个架构,给咱们的利用架构带来的挑战。  直播的架构咱们通常看到的有上面几种直播:  1. 单人直播,例如淘宝直播,通常随同着秒杀,弹幕,送火箭等业务逻辑; 2. 多人同时直播,例如连麦,会议; 3. 录播,对于局部直播场景如培训、会议等,须要将现场直播视频保留以进行流传、留存等应用,有对直播进行录制的需要。这种往往对实时性要求不高。 而当用户观看直播时,如果服务接入了 CDN,若接入 CDN,播放端抉择就近的 CDN 节点进行拉流播放,此时拉流压力在 CDN;若未接入 CDN,播放端从直播源站进行拉流。 下图是一个比拟常见的视频流的架构和两条数据走向: 1. 视频流推拉逻辑,如蓝色线所示 2. 惯例的业务逻辑,如黄色线所示 能够看到有四个次要模块: 1. 推流端:次要的作用在于采集主播的音视频数据推送到流媒体服务端; 2. 流媒体服务端:次要作用在于把推流端传递过去的数据转换成指定格局,同时推送到播放端不便不同播放端用户观看,当然目前云产商也流媒体服务端的一整套解决方案; 3. 业务服务端:次要解决一些常见的业务逻辑,如秒杀,弹幕等等; 4. 播放端:播放端简而言之就是拉取音视频进行播放,把相应的内容出现给用户。 四个要害的模块的协定其实就是流媒体传输协定。大部分直播的构造都采取上图的格局,较大的区别是是否引入 CDN。一般来说,咱们倡议客户引入 CDN 来缩小直播流量对服务器的冲击。四个模块之间的协定并不着重强调一致性。 接下来,咱们沿着这个架构来讨论一下,在这其中比拟软弱的危险有哪些,以及咱们如何提前通过压测来排查这些危险点。 直播中的挑战挑战一:视频流给流媒体服务端的压力在这个推拉的逻辑中,因为波及视频的流量较大,通过的路线较长,对流媒体服务器都会造成冲击;通场的做法是引入 CDN,当用户开始收看视频的时候,会先就近去 CDN 拉取流,如果这个时候视频内容还没有缓存在 CDN 的时候,CDN 就回源到流媒体服务端。  ...

November 18, 2021 · 1 min · jiezi

关于阿里云开发者:无处不在的-Kubernetes难用的问题解决了吗

简介:从第三方的调研数据看,容器和 Kubernetes 曾经成为云原生时代支流的抉择,但理论落地的时候,却陷入了窘境。咱们尝试去总结了一些共通点,以及应答计划,兴许能为正在落地容器技术的企业提供一些参考。作者:望宸、木环、溪洋 等 审核&校对:不瞋、宏良、张磊、志敏 编辑&排版:酒圆 容器实质是一项隔离技术,很好的解决了他的后任 - 虚拟化未解决的问题:运行环境启动速度慢、资源利用率低,而容器技术的两个外围概念,Namespace 和 Cgroup,恰到好处的解决了这两个难题。Namespace 作为看起来是隔离的技术,代替了 Hypervise 和 GuestOS,在本来在两个 OS 上的运行环境演进成一个,运行环境更加轻量化、启动快,Cgroup 则被作为用起来是隔离的技术,限度了一个过程只能耗费整台机器的局部 CPU 和内存。 当然,容器技术之所以能风行,更因为他提供了标准化的软件开发交付物 - 容器镜像。基于容器镜像,继续交付这件事才可能真正落地。 咱们还能列举出许多应用容器技术的理由,这里就不再一一赘述。 同时,云计算解决了根底资源层的弹性伸缩,却没有解决 PaaS 层利用随根底资源层弹性伸缩而带来的批量、疾速部署问题。于是,容器编排零碎应运而生。 从第三方的调研数据看,容器和 Kubernetes 曾经成为云原生时代支流的抉择,但理论落地的时候,却陷入了窘境。咱们尝试去总结了一些共通点,以及应答计划,兴许能为正在落地容器技术的企业提供一些参考。 难用在哪?容器和 Kubernetes 的先进性毋庸置疑,但当大量的企业在开始拥抱容器编排畛域的事实标准 Kubernetes 时,却陷入了窘境。“K8s 就像一把双刃剑,既是最佳的容器编排技术,同时也存在相当高的复杂性和利用的高门槛,这个过程中往往会导致一些常见性谬误”。就连 Kubernetes 的创立者和外围推动者 Google 自身都抵赖这个问题。 一次采访中,阿里巴巴高级技术专家张磊剖析了 Kubernetes 的实质,他指出,“Kubernetes 自身是一个分布式系统而不是一个简略的 SDK 或者编程框架,这自身曾经将其复杂度晋升到了零碎级分布式开源我的项目的地位。此外,Kubernetes 第一次将申明式 API 的思维在开源基础设施畛域遍及开来,并以此为根底提出了一系列诸如容器设计模式和控制器模型等应用范式,这些具备肯定先进性和前瞻性的设计也使得 Kubernetes 我的项目被公众承受时会存在肯定的学习周期。” 咱们大抵总结了 Kubernetes 的 4 大复杂性。 1、认知简单:他和原有的后端研发体系不同,延长出一套全新的实践,并提供了一系列全新的技术概念,并且这些概念,例如 Pod、sidecar、Service、资源管理、调度算法和 CRD 等等,次要是面向平台研发团队而非应用开发者设计,提供很多弱小灵便的能力。然而,这不仅带来了平缓的学习曲线,影响了利用开发者的应用体验,甚至在很多状况下了解不当还会引发错误操作,乃至生产故障。 2、开发简单:K8s 应用申明式办法来编排和治理容器。为了实现这一点,须要配置一个 YAML 文件,但再简单的应用程序中,引入新环节影响了开发者的生产力和敏捷性。此外,不足内置的编程模型,开发者须要依赖第三方库来处理程序间的依赖关系,这些都会影响到开发效率,并减少不必要的 DevOps 开销。 3、迁徙简单:将现有的应用程序迁徙到 K8s 比较复杂,尤其是非微服务架构,在很多状况下,必须重构特定组件或整个架构,并且须要应用云原生原理重构应用程序,例如状态依赖,如写本地目录、有程序,网络依赖,如写死 IP,数量依赖,如正本固定等等。 ...

November 18, 2021 · 2 min · jiezi

关于阿里云开发者:聚焦云原生阿里云与-CNCF-共话云未来新可能

简介:12 月 9 日,一场属于中国开发者的年度技术盛宴行将拉开帷幕 —— 由云原生计算基金会 CNCF 主办的 KubeCon + CloudNativeCon + Open Source Summit China 2021 将以线上直播的形式与中国开发者们见面。12 月 9 日,一场属于中国开发者的年度技术盛宴行将拉开帷幕 —— 由云原生计算基金会 CNCF 主办的 KubeCon + CloudNativeCon + Open Source Summit China 2021 将以线上直播的形式与中国开发者们见面。 作为云原生技术畛域的顶级盛会,历年的 KubeCon + CloudNativeCon + Open Source Summit China 都汇聚了国内外最沉闷的开源云原生社区、最先进的技术代表与行业的最佳落地实际,推动云原生计算畛域的常识更新和技术提高。阿里云作为本届大会的钻石赞助商,为 CNCF 提供了鼎力的反对,取得了大会主办方的高度认可。 自 2017 年以来,阿里巴巴在云原生技术畛域投入了巨大力量,深度参加到 etcd、Kubernetes、ContainerD 等多个顶级开源我的项目的开发与保护当中,并通过云原生技术栈实现了整体基础架构体系的自我降级。截至 2020 年底,阿里巴巴已有 KubeVela、OpenYurt、Fluid、OpenKruise 等超过 10 个我的项目进入 CNCF;对 Kubernetes 我的项目的奉献量也位居寰球前 10。 不能错过!来自 10+ 阿里云技术专家的云原生翻新实际在本届大会中,来自阿里云的一线云原生技术专家带来了丰盛的演讲议题,有超过 10 个议题通过主办方的严格筛选,内容涵盖云原生利用交付、云原生 AI、 Kuberentes 集群治理、容器运行时、CNI、故障监测、Serverless 等云原生细分技术畛域,在议题入选数量、话题丰盛度方面都表现出色。 ...

November 18, 2021 · 3 min · jiezi

关于阿里云开发者:前沿分享|阿里云数据库事业部资深技术专家生态工具产品部负责人-陈长城一站式在线数据管理平台DMS技术解读

简介:本篇内容为2021云栖大会-企业级云原生数据库最佳实际论坛中,阿里云数据库事业部资深技术专家、生态工具产品部负责人 陈长城对于“一站式在线数据管理平台DMS技术解读”的分享。本篇内容将从3个局部为读者介绍一站式在线数据管理平台DMS,心愿通过一站式数据管理理念,让企业麻利建仓,通过低门槛数据开发疾速施展数据价值,欢送大家应用和体验。      企业数据管理的痛点云原生2.0一站式数据管理DMS解决方案与最佳实际 一、企业数据管理的痛点1) 数字化转型是企业倒退的战略重点 在国家提出供应侧改革的模式下,企业在倒退过程中,很多行业一直往头部集中,咱们看到最近的经济报告,中国数字经济的GDP的占比逐年回升,企业本身也存在经营效益晋升的诉求,因而在政策的导向和企业诉求的双轮驱动下,数字化转型也在疾速推动。 2) 数据在业务中的全生命周期 在整个业务倒退过程中数据的生命周期是从生产到存储、解决、剖析、利用的一连串流程。企业外部多个业务会依据本身特点应用不一样的数据库,导致数据库应用类型十分多,而数据仓库也是独立建设为主,在企业外部零碎中就会存在多种不同的数据存储系统和数据平台。明天十分不足笼罩数据生命周期的一站式治理平台,同时为了让这些数据对立治理,实时数据趋势成为将来的大趋势,有预测2025年新业务的实时数据占比会达到50%以上。 3) 企业数据价值化过程中遇到的痛点 企业外部有特地多品种的数据形成的数据孤岛、数据加工链路简单、数据治理和平安治理艰难,都成为施展数据价值的痛点。 二、云原生2.0一站式数据管理DMS1) 数据管理服务DMS 如何进行数据的对立平安治理,更快施展数据价值? 在此背景下咱们提出一站式数据管理平台,一站式数据管理平台DMS把企业数据资产对立串联起来,通过底层对接所有异构数据源对立治理起来,再从数据的生产端进行切入,从数据库的设计、开发、利用、公布,到数仓构建和数据服务,建设成笼罩数据生命周期的对立平台。通过这个形式,企业数据管理生命周期就能全副串联起来。这是十分新的理念,让企业在线数据处理和剖析的整个周期都串联起来。 DMS产品在阿里团体外部积淀了12年以上,咱们从数据管理、数据安全、数据库的DevOps,数据传输这些底层根底建设逐渐把数据生命周期全笼罩。 2) 一站式数据管理DMS 技术架构 技术架构次要有三层: 底层根底服务是构建全域对立的数据资产、开发运维体系和平安管理体系;两头是管制立体和数据立体的撑持引擎,管制立体是面向数据安全和数据库DevOps场景的撑持引擎,比方工单执行引擎、平安规定引擎和稳固变更引擎;数据立体包含数据全量传输、增量以及ETL解决和转换的算子,包含联邦查问的多源异构对立查询处理,这些都是数据立体的引擎。最下面是面向各场景的业务性能,撑持数据安全、数据库DevOps、数据集成与开发,通过对这些场景的反对造成一站式全链路数据生命周期治理。   接下来开展介绍一下DMS的三个局部外围个性。 3) DMS核心技术个性数据管理DMS-数据资产与平安 数据资产是把全域数据对立治理起来,让企业疾速晓得有哪些数据,数据在哪里,数据治理状况,不便施展数据价值。这里介绍两个技术点: 一个技术是常识图谱构建,将多源异构的物理元数据和相干业务逻辑对应起来。通过对元数据定义和语义学习到字段关联关系,联合在咱们平台应用过程中工单零碎人和数据的关系,造成构建数据图谱的输出,把数据会集起来后构建成全域数据资产的关系图谱,让数据工程师进行低门槛数据的建仓,他能够通过指定几个外围业务字段,零碎联合关联关系主动构建数仓宽表,帮忙低门槛建仓和全域所有数据品质的施行。 在数据安全方面,咱们反对包含GDPR在内的五个以上数据安全法案,让企业在抉择数据安全法案后,能够分级分类进行敏感数据的辨认。在数据生命周期的数据生产、数据集成、数据开发、价值开掘过程,数据脱敏都会贯通其中,反对15种以上的数据脱敏。 DevSecOps在云上有10万以上的开发者和沉闷的用户。平台提供十分多数据库开发者工具集,基于这些开发者工具,将数据变更,库表设计DDL与平安规定引擎联合,使企业通过DevSecOps在保障平安下最大化开释业务开发人员的工作效率,让他们自主进行数据库的库表设计和变更公布。 平安规定引擎内置200多个平安规定模板,不同数据库引擎有不同的最佳实际,企业能够依据模板定义适合的平安规定,以操作人、数据库对象、具体品行为三者作为因子定义标准的规定。比方数据一次勘误的数量,一次查问的数量,人员的字段拜访权限,都是基于平安引擎设计的。 变更平安是对DevSecOps研发自主的变更动作进行保障和兜底,比方在做大批量数据操作的时候会切成屡次小批量操作,有锁变更主动变成无锁变更。通过研发设计平安规定检测和拦挡的标准让变更安全可靠,把这些能力开释给企业开发人员,能进步自主研发迭代的效率。 企业数字化转型面临的问题是如何进行对立数据集成和施展数据价值,咱们心愿通过流批一体数据集成和低代码开发能力给到开发者便捷的体验。 数据底层的外围链路是基于DTS产品实时异构的数据传输能力,在数据迁徙、同步、订阅方面有比拟成熟的积淀。 在传输链路外部实现AnyToAny的技术架构后,新数据源作为一个插件,疾速跟原有的多种异构数据源进行实时买通。同时对非结构化数据可通过语义辨认和类型映射,进行结构化入库后的价值开掘。 在外部构建数据流批一体的集成链路后,通过对立的内存转换模块,反对用户自定义算子和脱敏算法,流和批的数据只有通过一次定义就能实现统一转换,所有的全量数据初始化都复用转化逻辑。在DMS进行建仓,链路主动把表构造主动在指标进行初始化,全量数据和增量数据迁过去,两头的转化只有做一次定义。在源端进行数据库切换或DDL变更都能够无缝将源端变更同步到指标数仓,实现库仓一体的技术架构。内置100多个数据转化的算子使用户数据的链路极大收敛,使整个链路更加稳固,极大简化了数据链路的运维老本。 在实现数据集成后,通过利落拽的形式,使数据源、跨库查问引擎和数据传输链路的流和批都能作为操作节点,让用户用自主定义数据加工流程,通过运维工具、平安治理和对立治理的能力能让企业进行批量生产工作创立。 三、解决方案与最佳实际1) 某金融基于DMS+RDS构建数据安全生产计划 该金融公司基于DMS+RDS构建的数据安全生产计划。企业外部有600多个数据库实例,面向十分多的火线业务开发者,业务开发要做变更公布和数据库操作的时候,沟通问题、数据安全问题和效率问题通过DMS治理数据源、提供对立数据安全变更使得前端业务开发效率晋升,同时数据安全和变更稳定性失去保障。 2) 某运营商基于DMS+PolarDB-X构建异地多活 上图是运营商通过DMS和Polar DB-X构建异地多活解决方案。传统数据库的灾备机房基础设施投入无奈承当业务流量,或者只能承当无限的业务流量。这些基础设施投入很难施展价值,导致运营商物理机房电力限度,无奈撑持业务更大倒退。通过DMS+PolarDB-X帮忙降级为异地多活架构,实现了容灾疾速切换,同时承当了业务流量,满足了业务拓展诉求。 3)寰球多活数据库 因为很多企业对异地多活架构有很强的诉求,本次咱们公布RDS寰球多活数据库,通过RDS控制台可一键购买寰球多活数据库,主动创立多个数据中心的RDS并实现架构搭建,通过多活接口让业务切流变得更简略,升高企业异地多活的施行老本和治理复杂度。 4)某银行基于DMS+ADB构建T+1的数据仓库 上图是某银行案例,基于DMS+ADB构建T+1的数据仓库。该企业周期性数据批量集成导致生产库呈现大的业务负载,影响业务稳定性,定时报表无奈撑持业务流动的实时决策。基于这样的痛点,咱们构建T+1的数据仓库,拉链表对源库生产影响很小,第一次进行全量后都是增量的实时数据,通过定时合并产出周期性报表,在流动时基于ADB实时产生生产报表,而且通过在本地进行构建还能回溯任意工夫点的历史数据快照,帮忙企业同时解决了定时报表和实时剖析的诉求。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 17, 2021 · 1 min · jiezi

关于阿里云开发者:关注出行及工业智能硬件的小伙伴来

简介:侬好,上海!新智能硬件翻新沙龙&大赛 11月25日首站将在上海启动 本次沙龙聚焦出行&工业行业的智能硬件翻新 解锁智能硬件翻新明码 现场赠送开发板及物联网平台收费应用 仅限80席    先到先得! 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 17, 2021 · 1 min · jiezi

关于阿里云开发者:收藏|2021年阿里云开源镜像站最热门镜像王全梳理附下载链接和Top20镜像王排名

简介:阿里云开源镜像站的初衷在于宣传自由软件的价值,进步大家的开发效率,帮忙大家更快地进行利用创立。全面、疾速、稳固、可信作为程序员必定要和开源软件打交道,很多状况须要用到相干的代码库,而依赖和软件包的下载是最耗时最节约精力的事件。阿里云开源镜像站是从外部的服务孵化而来,心愿能够帮忙开发者大幅缩小工夫的节约,把精力集中在更有意义的中央。尽管说软件的品种千千万,镜像站不可能笼罩所有的应用场景,通过几年的建设,收录的镜像的数量曾经靠近150个,根本满足用户的罕用需要,争取做国内最全面、最疾速、最稳固可信的开源镜像站。 全面 笼罩了支流操作系统 CentOS、Ubuntu,Fedora,Gentoo,Debian,FreeBSD、优麒麟、Rocky Linux、OpenAnolis等,常见的编程语言和构建依赖包和工具,例如npm、Maven、PyPI、Composer、Jenkins等,以及云原生等畛域的支流软件Kubernetes、Docker、MangoDB、MariaDB等,曾经累计收录了近150个开源软件的镜像。 疾速 阿里云开源镜像站利用云服务上的劣势,提供疾速、稳固的镜像散发服务,提供收费的CDN减速服务。更新频率高,基本上一天一更新,对于Centos/Ubuntu/PyPi等外围仓库2小时一更新。 稳固 开源镜像站每天承载几亿的下载量,为千万的开发者继续提供不间断的服务。 可信 与CentOS、RockyLinux、优麒麟、npm、Maven等国内外官网源站间接进行单干。 2021年镜像站全新改版作为国内最富盛名的镜像站之一,2021年镜像站全新改版,进一步在晋升用户体验,带来搜寻能力、npm镜像站独立域名两大降级。 搜寻能力降级基于阿里云OpenSearch的搜寻能力,开源镜像站为开发者高效的开源软件包搜寻服务。开发者能够对外围的镜像仓库一键搜寻, 更快更精准地找到本人想要的软件包。 npm镜像站升级成独立域名站点网址降级为https://www.npmmirror.com/, 间接从一级域名进行拜访。Registry 全面重构,晋升稳定性,升高同步失败率;CLI 优化,晋升装置速度,去掉软连贯等带来的兼容性问题。淘宝npm镜像站原网址将于 2022 年 05 月 31 日零时起进行服务,请大家及时保留和更新新的域名。 镜像版的国王排行最受欢迎的20个镜像还次要集中供暖在操作系统和语言类的镜像源上(排名没有包含npm镜像和maven镜像)。CentOS、Ubuntu、和EPEL分列前三,语言类的Python、PHP、Go紧随其后。在TIOBE编程语言排行榜上,Python力压Java和C成为最受欢迎的编程语言,反映在镜像的下载上也同样实用。国内的优麒麟操作系统也位列前20中。 重点镜像大梳理(附下载地址和配置阐明)一、操作系统1、CentOS:https://developer.aliyun.com/mirror/centos CentOS,是基于 Red Hat Linux 提供的可自在应用源代码的企业级 Linux 发行版本。尽管CentOS 8曾经发表行将停服,然而依然是最受欢迎的镜像源。 2、RockyLinux:https://developer.aliyun.com/mirror/rockylinux Rocky Linux 是 CentOS 的一个分支,往年6月才开始首发它位于 Red Hat Enterprise Linux(RHEL) 的上游。与 CentOS 一样,它提供了非常适合服务器的稳定版 Linux,旨在作为 CentOS 的齐全兼容替代品。 3、Anolis:https://developer.aliyun.com/mirror/anolis Anolis OS 8 是 国内龙蜥社区推出的齐全开源、中立、凋谢的发行版,它反对多计算架构,欠缺适配 Intel、飞腾、海光、兆芯、鲲鹏、龙芯等芯片,也面向云端场景优化,100% 兼容 CentOS 8 软件生态。 4、EPEL:https://developer.aliyun.com/mirror/epel EPEL (Extra Packages for Enterprise Linux),是由 Fedora Special Interest Group 保护的 Enterprise Linux(RHEL、CentOS)中常常用到的包,是十分受欢迎的镜像源之一。 ...

November 17, 2021 · 2 min · jiezi

关于阿里云开发者:钉钉宜搭入选Forrester中国低代码平台市场分析报告

简介: 最新:钉钉宜搭入选Forrester《中国低代码平台市场剖析报告》! 11月12日,寰球出名钻研机构Forrester公布《中国低代码平台市场剖析报告(The State Of Low-Code Platforms In China)》,钉钉宜搭入围。报告整体剖析了中国各类低代码平台的特点,并对低代码技术如何帮忙中国企业减速数字化转型进行了深入探讨。报告指出,宜搭与阿里云、钉钉能力的深度交融,所产生的利用人造与钉钉利用深度集成,让组织内外的协同更高效。 “低代码”这一概念由Forrester在2014年正式提出。7年来,低代码技术在中国逐步成为支流趋势。钉钉宜搭等当先的低代码平台正在服务各垂直畛域的企业,晋升应用程序交付效率、升高经营老本,扩充低代码开发者人群规模并激发集体的创新力。低代码技术在中国的疾速倒退,使其成为企业放慢数字化转型、适应将来的关键技术策略。 Forrester的报告指出:中国公司的商业及技术决策者在数字化转型过程中优先思考低代码技术。58%的人正在采纳低代码平台和工具进行软件开发,16%的人正打算这样做。低代码平台与人工智能、物联网的协同作用使其在将来更为适宜撑持企业的外围竞争力。 放慢数字翻新,进步老本效益。低代码平台和工具升高了翻新团队尝试新想法的阻碍。低代码平台提供可配置的UI、预置模板以及自动化能力,以不便疾速交付应用程序和自定义流程,帮忙企业低成本翻新并为业务发明价值。 图:钉钉宜搭提供的200+模板 业务人员也能疾速上手。为了响应市场和客户需要的变动,企业须要批改或扩大现有的业务应用程序,甚至构建新的应用程序。低代码平台呈现后,企业业务人员能够应用各类预配置解决方案,从而进步生产力。 图:用钉钉宜搭“利落拽”即可搭建利用 动静反对弹性经营。企业能够通过采纳云原生架构的低代码平台,开发应用程序实现弹性经营。低代码平台可确保应用程序平安、可治理且可扩大,帮忙企业构建灵便的能力来应答危机和事件。新冠肺炎疫情减速了这些实际,并证实了低代码工具的价值。 图:疫情期间,钉钉宜搭均匀1.5天上线一个利用 Forrester在报告中还举例说明了低代码平台在中国各类行业:如银行、保险、批发、医疗保健、政府、制作、电信和修建等畛域的广泛应用场景。Forrester在报告中写道:“家居批发企业竟然之家应用阿里巴巴旗下产品宜搭,开发了400多个治理和财务应用程序,将经营效率晋升了60%。” Forrester在报告中指出,公共云服务提供商提供云生态系统协同能力,可实现多样化的云环境部署。例如阿里巴巴的宜搭联合了阿里云和钉钉的独特劣势,所开发的利用人造与钉钉内其余利用集成,让组织内外协同更高效。用宜搭来构建企业专属利用,你只需关注业务自身,其余例如数据存储、运行环境、服务器、网络安全等,平台为你全副搞定。此外,借助阿里云,宜搭还提供了弱小的弹性计算、动静扩容能力,为你的业务高效、稳固的运行保驾护航。 宜搭作为钉钉官网低代码利用搭建平台,和钉钉原生能力默认买通。宜搭默认应用钉钉企业通讯录,流程审批可基于组织架构,不便、快捷。反对钉钉音讯、钉钉待办,确保重要事项音讯必达。搭建好的利用可疾速接入企业工作台,高效实现在线协同、挪动办公。 宜搭近期公布的3.0版本,带来了在连接器、数据大屏以及平安方面的重磅更新:3大连贯能力套件,让业务互联互通;更低门槛的数据BI能力,一键生成酷炫数字大屏;全局水印、独立域名等平安能力,为用户提供国密级专属平安。 连贯的效率和深度,决定了企业的生产力。宜搭3大连贯能力套件:Excel一键降级企业数字化利用,宜搭连接器以及跨组织流程审批和利用散发,实现了利用与利用之间,利用与人之间,企业上下游之间的全链路连贯,宜搭搭建的利用在钉钉上人造互联互通。 业务数据全面买通,一键生成酷炫大屏。本次宜搭全新公布了20多款罕用报表可视化组件,提供10多款开箱即用的可视化炫酷大屏模版,涵盖销售、人事、生产制作等诸多畛域,可宽泛用于展现汇报、指挥决策,业务剖析等场景。反对100万数据量的表与表关联,和一亿数据量的海量数据处理能力。 全局水印,独立域名,提供全面平安保障。爱护客户的数据安全是第一准则,宜搭平台依靠钉钉全面的平安防护策略,取得公安部信息系统三级等级爱护认证,数据享受国密级别平安爱护。宜搭上线利用全局水印性能,一旦产生信息透露可疾速追溯起源。对立风控账号体系+独立企业域名,筑起平安高墙,为企业提供专业级平安防护。 低代码技术已成为中国企业减速数字化转型和适应将来策略的要害局部,钉钉宜搭将会始终陪伴在用户身边,通过低代码这一新生产力工具,一直激发集体和组织的创造力,全面减速企业的数字化转型。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 17, 2021 · 1 min · jiezi

关于阿里云开发者:云原生体系下-Serverless-弹性探索与实践

简介:SAE 通过对弹性组件和利用全生命周期的一直优化以达到秒级弹性,并在弹性能力,场景丰盛度,稳定性上具备外围竞争力,是传统利用 0 革新上 Serverless 的最佳抉择。作者:竞霄 Serverless 时代的降临 Serverless 顾名思义,是一种“无服务器”架构,因为屏蔽了服务器的各种运维复杂度,让开发人员能够将更多精力用于业务逻辑设计与实现。在 Serverless 架构下,开发者只须要关注于下层应用逻辑的开发,而诸如资源申请,环境搭建,负载平衡,扩缩容等等服务器相干的简单操作都由平台来进行保护。在云原生架构白皮书中,对Serverless 的个性有以下概括: 全托管的计算服务,客户只须要编写代码构建利用,无需关注同质化的、累赘沉重的基于服务器等基础设施的开发、运维、平安、高可用等工作;通用性,可能撑持云上所有重要类型的利用;主动的弹性伸缩,让用户无需为资源应用提前进行容量布局;按量计费,让企业应用老本得无效升高,无需为闲置资源付费。 回顾整个 Serverless 的倒退历程,咱们能够看到从 2012 年首次提出 Serverless 概念为终点,再到 AWS 推出 Lambda 云产品的这段时间内,人们对 Serverless 的关注度呈现了爆发式的增长,对无服务器的期待和畅想逐步引爆整个行业,但 Serverless 的推广和生产落地的过程却不容乐观,Serverless 理念与实操生产的过程中存在 Gap,挑战着人们固有的应用体验和习惯。 阿里云深信 Serverless 将作为云原生之后确定性的倒退方向,相继推出了FC,SAE 等多款云产品来笼罩不同畛域,不同类型的利用负载来应用 Serverless 技术,并且一直在推动整个 Serverless 理念的遍及与倒退。 就以后 Serverless 整个市场格局而言,阿里云曾经做到了 Serverless 产品能力中国第一,寰球当先,在去年 Forrester 评测魔力象限中能够显著的看到阿里云在 Serverless 畛域曾经与 AWS 并驾齐驱,于此同时,阿里云 Serverless 用户占比中国第一,在 2020 年中国云原生用户调研报告中整个阿里云 Serverless 用户占比曾经达到了66%,而在 Serverless 技术采纳状况的调研中表明,曾经有越来越多的开发者和企业用户将 Serverless 技术利用于外围业务或者将要利用于外围业务之中。 Serverless 弹性摸索 弹性能力作为云的外围能力之一,所关注的问题是容量布局与理论集群负载间的矛盾,通过两幅图的比照能够看到,如果采纳事后布局的形式进行资源安顿,会因为资源筹备量和资源需求量的不匹配导致资源节约或者资源有余的状况,进而导致老本上的过多开销甚至业务受损,而咱们冀望极致弹性能力,是筹备的资源和理论需要的资源简直匹配,这样使得利用整体的资源利用率较高,老本也随业务的增减和相应的增减,同时不会呈现因容量问题影响利用可用性的状况,这就是弹性的价值。 弹性其实现上分为可伸缩性和故障容忍性,可伸缩性意味着底层资源能够参照指标的变动有肯定的自适应能力,而故障容忍性则是通过弹性自愈确保服务中的利用或实例处于衰弱的状态。上述能力带来的价值收益在于降老本的同时晋升利用可用性,一方面,资源使用量贴合利用理论消耗量,另一方面,晋升峰值的利用可用性,进而灵便适应市场的一直倒退与变动。 上面将对以后较为广泛的三种弹性伸缩模式进行论述和剖析。 首先是 IaaS 弹性伸缩,其代表产品是各云厂商云服务器弹性伸缩,如阿里云ess,能够通过配置云监控的告警规定来触发相应的 ECS 增减操作,同时反对动静增减 Slb 后端服务器和 Rds 白名单来保障可用性,通过健康检查性能实现弹性自愈能力。ESS 定义了伸缩组的概念,即弹性伸缩的根本单位,为雷同利用场景的 ECS 实例的汇合及关联 Slb,Rds, 同时反对多种伸缩规定,如简略规定,提高规定,指标追踪规定,预测规定等,用户的应用流程为创立伸缩组和伸缩配置,创立伸缩规定,监控查看弹性执行状况。 ...

November 16, 2021 · 2 min · jiezi

关于阿里云开发者:独家-揭秘2021双11背后的数据库硬核科技

简介:往年双11,阿里云数据库技术有什么不一样?2021年,是阿里巴巴首个100%云上双11 双11峰值计算成本 相比去年降落50% 作为寰球规模最大的数字工程之一 双11无疑是对阿里技术人的“大考” 在又一次技术“严考"背后 阿里云数据库团队再次递交了诚意满满的年度答卷 在双11背地,凝聚着有数同学致力的身影 为所有奋战在火线的数据库小伙伴们打Call! 除了保障稳固顺滑的根本盘 往年,阿里云数据库全面云原生化 继续通过技术创新赋能用户 为消费者和商家提供了全方位降级的购物体验 引领技术倒退门路 每一笔不起眼的订单背地 都须要弱小的技术撑持 往年双11,阿里云数据库有哪些不一样的硬核技术? 让咱们一起看看完整版成绩单吧 P.S.: 《2021双11数据库技术最佳实际》系列技术干货文章 将于下周上线“阿里云数据库”公众号 欢送大家继续关注! 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 16, 2021 · 1 min · jiezi

关于阿里云开发者:前沿分享|数澜科技联合创始人副总裁-江敏基于云原生数据仓库AnalyticDB-PostgreSQL的最佳实践

简介:本篇内容为2021云栖大会-云原生数据仓库AnalyticDB技术与实际峰会分论坛中,数澜科技联结创始人&副总裁江敏对于“基于云原生数据仓库AnalyticDB PostgreSQL的最佳实际”的分享。 本篇内容将通过四个局部来介绍基于云原生数据仓库AnalyticDB PG的最佳实际。 一、背景介绍 二、计划介绍 三、客户实际—某商业团体 四、公司介绍 一、背景介绍以后我国数据中台行业处于从萌芽转向高速倒退的过渡期,随同着数据星的爆发式增长,数据处理技术的提高,以及企业数字化转型驱动市场需求一直减少,行业增长势头显著,市场规模疾速扩张。目前,数据中台在行业头部已逐步薄地,而对于数据中台能力要求绝对简略的中小企业,为其提供标准化、轻量化的整体解决方案将是日前市场的次要诉求。 咱们去构建整个数据中台的能力的时候,其实会碰到一些问题。比方,底层架构简单。传统数据中台架构思维,导致客户在选型和部署大数据组件,开发和调度数据工作和运维和经营数据须要多方进行衡量思考,架构简单,应用门槛过高。其次,运维老本高。随同着传统統数据中台底层架构的复杂性,随之而来的是简单的IT人员体系以及昂扬的运维老本。第三,响应时效挑战大。随着数据量的一直减少以及业务需要的一直迭代,如何疾速响应业务人员需要、缩小数据分析的等待时间、让业务人员有更好的体验将成为数据中台胜利的要害指标。 二、计划介绍 咱们基于ADB PG这个版本去构建整个轻量级数据中台的时候,你会发现底下就一个ADB PG。两头的话,咱们是一个轻量级数据中台的套件。这样两套零碎就能够去撑咱们下层的业务建设。 从整个的业务架构来说,底层是咱们现有的各种数据源的零碎。而后咱们会在数据中台会搭建一个技术体系,在技术体系里包含了ADB。之后再构建咱们整个的数据体系跟服务体系。在数据中台的技术体系上,就是咱们的数据流。它会通过一个数据建模的过程。对于轻量化的中小微企业来说,当须要轻量化的计划时,咱们会把它放到ADB里。在这过程中,就不须要去思考搬迁数据的问题,我所有的数据都在这个体系外面。ADB的数据量,其实可能撑持大部分企业的数据量应用。 企业只有在这里构建整个数据模型,咱们会有相应的工具来撑持,包含数据同步,环境治理,模型开发,模型监测,包含数据治理的一些性能。对于数据及服务来说,咱们在构建数据模型的时候,针对企业的对象,咱们会去构建一些具体的指标,相应的底细体系也会建设起来。比方,咱们从客户的视角,构建客户的画像体系。从供应商的视角,构建供应商的画像体系。数据构建完之后,咱们就能够去做洞察,营销,精准匹配等。所以从数据层面看,它可能撑持利用场景。 针对具体的场景来看,咱们分成几大块。第一个,财务畛域。财务报表有时候会跟企业的经营报表口径对立,大部分企业在面临财务审计的时候,对于企业来说是一个十分强的需要。第二个,企业的应收应酬和人力资源的治理。对员工的洞察,也须要通过数字化的伎俩去治理员工叫数字员工。更加精细化的去对员工做一些考核,包含一些相应的指标剖析。第三,咱们目前在一些畛域做实时数据的剖析。依据轨迹去做态势的剖析,包含一些碰撞的剖析。第四,加密数据库的能力。这种场景能够基于ADB的底座去构建。数据的可用不可见,让咱们对数据能够更加高效的治理。 三、客户实际—某商业团体咱们次要讲一个商业团体的案例。这个商业团体,次要是治理高速服务区。原先服务区,每个服务区本人建设零碎。当初随着智能化服务区概念的提出,须要对进出服务区的治理进行对立。在建设之初,咱们也遇到了一些问题。比方,数据收集难,50对+服务区,各自独立,只能收集局部统计数据;多种信息系统单独建设,归口各不对立;无奈无效取得周边路段的数据;数据孤岛问题显著。数据管理凌乱,各位数据笆理部门不一,没有造成对立的资产目录; 数据规范不一,数据质参差不齐;跨部门数据应用协调繁琐。数据应用弱,数据大部分处于沉唾状态。对于管理者的经营监控、经营决策等方面短少必要的智能洞察。 在解决这些问题的时候,要思考到对于各个服务区的这个站点,怎么可能升高保护老本?怎么能够开箱即用?,对于它外面建设场景方才其实也简略介绍过。第一个,服务器里会有很多视频剖析的场景。波及到要害信息,要实时抓取,写到道数据库里。比方人流的状况,车流的状况,拥挤的这种状况,人员进来之后,对什么样的商品有需要?对于服务区总体的管控来说,咱们在预测服务区的流量,一些供需关系,一些治理的时候。它须要把数据汇聚到总部来,做对立的治理,对立的剖析。 从客户价值出现的角度来说,第一,智能化。咱们通过对各类数据的采集、加工、治理及利用,并联合成熟的业务模型,开释数据价值,撑持业务的智能化。第二,轻量化。咱们简化传统中台架构,用ADB代替Hadoop生态,升高企业资源存储及计算的复杂度和老本;为多维分析决策提供保障。第三,场景化。咱们以具体的业务场最为切入点,自下而上,围绕场景发展数据治理,构建数据资产,撑持数据利用需要,贴近价值。 四、公司介绍数澜科技成立于2016年6月,自成立之日起,秉持”让数据用起来”的使命,帮忙企业继续数据资产化,赋能业务翻新。数澜科技总部位于杭州,在华北(北京)、华南(深圳)、华西(成都)、华中(武汉)设有本地化团队,核心成员均来自阿里巴巴、华为、IBM、 百度、金蝶、甲骨文等一线企业,是国内较早-批大数据服务翻新实践者。截止目前,数澜科技应用旗下外围产品”数栖平台”, 已为1000+企业客户提供数据中台建设服务,帮忙客窖户应用数据中台作为要害数字技术推动企业的数字化改革。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 16, 2021 · 1 min · jiezi

关于阿里云开发者:前沿分享|阿里云资深技术专家-魏闯先AnalyticDB-PostgreSQL年度新版本发布

简介: 本篇内容为2021云栖大会-云原生数据仓库AnalyticDB技术与实际峰会分论坛中,阿里云资深技术专家 魏闯先对于“AnalyticDB PostgreSQL年度新版本公布”的分享。 本篇内容将通过三个局部来介绍AnalyticDB PG年度新版本公布。 一、AnalyticDB PG云原生架构 二、云原生架构核心技术分析 三、演进路标 一、AnalyticDB PG云原生架构阿里云自研高性能、海量扩大数据仓库服务、兼容局部Oracle/Teradata语法生态,大量利用于阿里巴巴团体外部电商,物流,娱乐,广告等业务部门,服务于阿里云的金融、政企、互联网等各行业用户,反对疾速构建新一代云化数据仓库服务。 它具备以下四个特点:第一,PB级数据秒级响应。采纳向量化计算以及列存储和智能索引,当先传统数据库引擎性能3x倍。新一代SQL优化器,实现简单剖析语句免调优。第二,稳固牢靠简化运维。飞天平台基于阿里多年大规模集群零碎构筑教训打造,智能硬件治理,故障监控诊断自复原,反对MPP数据库实现简单集群零碎高牢靠,自运维。第三,高SQL兼容性。反对SQL 2003,局部兼容0racle语法,反对PL/SQL存储过程, OLAP窗口函数,视图等,具备齐备性能和生态,可实现利用疾速适配和迁徙。第四,数据多模剖析。通过PostGIS插件反对地理信息数据分析,内置100+机器学习算法库,实现数据智能摸索。反对高维向量检索算法,实现视频/图像检索以图搜图性能。 咱们为什么要降级云原生架构?从80年代开始,数据库逐渐由单机向云原生架构逐渐演进。80年代,数据库采纳存储计算耦合的单点数据库服务架构。90年代开始,通过共享存储的能力做到了一份存储多份计算。随着计算节点线性减少,它的存储逐步成为瓶颈。到2000年当前,随着大数据的倒退,数据程度切成多个分片,每一个节点负责一个分片数据的计算和存储。2010年开始,随着云计算的迅速倒退,数据库开始向云原生方向演变。 对于数据仓库的业务来说,它天生适宜存算拆散架构并反对弹性伸缩。第一,数据量自身存在波峰波谷,数据量在某些天呈现激增,数仓须要做到疾速扩容。第二,实时剖析。咱们须要数据做到实时反馈,刚刚产生的数据,可能立即剖析。第三,数据仓库既要提供历史数据分析,又要提供实时剖析,这就要求数仓必须具备好的资源隔离能力。第四,当初的部门数据越来越简单,跨部门之间须要数据共享。咱们的数据仓库须要做到一份存储,多部门共享,缩小部门之间数据扭转带来的业务简单。 二、云原生架构核心技术分析咱们的以后ADB是两层构造,下层是master节点,底层的是计算节点,通过云盘的弹性能力去解决存储弹性的问题。这种架构的次要痛点问题是,计算节点有状态,一旦有状态,在扩容等过程中,就会面临着数据搬迁慢的问题,所以咱们在新的云原生架构把计算节点从有状态变成无状态或者弱状态。状态包含实在数据和元数据两个层面,实在数据放在共享存储中,元数据放在分布式KV中,存储和计算齐全解耦,做到无状态,这样就能够疾速地实现秒级的弹性能力。在开发测试过程中,发现了很多性能问题。第一个问题是,原来的云盘或者是本地盘换成了共享存储后,共享存储响应性能比本地盘差一个数量级或两个数量级,咱们采纳分布式的多层缓存来解决共享存储的性能问题。第二个,共享存储具备十分好的吞吐能力,但须要存储引擎适应这个个性,因而咱们设计了行列缓存的架构,并做了大量的面向高吞吐的性能优化。 对一般客户来说,最重要的事件就是做到老本的升高。因为采纳的共享存储的价格比原先应用本地盘或云盘的老本有一个数量级的降落,所以整个原生版本在老本上会有个大幅降落。 云原生架构有四个特色:第一个特色是弹性,能够实现计算和存储独立的伸缩。第二个是实时,保留实时能力,反对高并发的实时写入。第三个是高吞吐,具备好的多维分析性能,并可线性扩大。第四个是数据共享,能够实现数据跨实例的实时共享。 首先咱们介绍一下扩容的过程。假如开始只有两个计算节点,数据有八个分片。扩容前,每个计算节点负责四个分片数据,映射关系保留在元数据库中,所有的数据都放在共享存储下面。扩容过程就是将映射关系从原来的一个节点对四个分片改成一个节点对两个分片,扩容过程无需数据迁徙,只须要批改元数据,整个过程能够做到秒级弹性。 高吞吐实时写入是实时数仓的一个重要个性。次要通过以下三种形式:一、Batch和并行化进步吞吐。二、本地行存表实现事务ACID。三、分布式缓存减速。 另一个重要技术点是离在线一体行列混存。咱们设计一个面向吞吐的行列混存的存储引擎,充分发挥共享存储高吞吐的特色。行列混存利用数据的有序性,反对计算下推,失去了10倍以上的性能晋升。同时针对多维分析任意列查问的场景,设计了多维排序功能,能够保障多个维度的任意查问都能达到毫秒级的响应。 ADBPG原先采纳火山计算模型,在云原生版本中将火山模型降级为向量化模型。向量化引擎的实质是将原来的一条条计算,改成批计算,每批数据采纳列式向量化计算。绝对于火山模型,向量化引擎具备CPU Cache命中率高、流水线并行、低函数调用开销、缩小内存碎片等劣势。测试结果显示,向量化计算引擎绝对原来的火山模型有三倍以上的性能晋升。 计算存储拆散架构的第一个演进个性是数据共享。元数据可分成零碎表和可见性表,存储在KV零碎中。被共享的实例将元数据同步到KV零碎中,共享实例实时查KV零碎,拿到最新表的元数据和可见性信息,再依据元数据访问共享存储中的数据,从而实现数据的实时共享。 下一个演进个性是细粒度弹性。通过后面介绍的计算存储拆散架构,曾经实现了计算节点的无状态化。下一步的工作就是把节点再细拆为存储服务化节点和计算节点。存储服务化节点次要负责数据实时写入和缓存,计算节点实现齐全无状态,从而实现极致弹性能力。 三、演进路标将来一年的演进门路。10月份云原生架构降级,反对极速扩缩容。12月份,上线跨实例数据共享性能,并反对分时弹性性能。明年6月份,上线存储服务化和计算无状态。22年10月份,反对算子级弹性和主动挂起/启动性能。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 16, 2021 · 1 min · jiezi

关于阿里云开发者:前沿分享|阿里云数据库解决方案架构师-王宏宇云原生数据仓库AnalyticDB在零售行业的深度应用和业务价值

简介:本篇内容为2021云栖大会-云原生数据仓库AnalyticDB技术与实际峰会分论坛中,阿里云数据库解决方案架构师 王宏宇对于“云原生数据仓库AnalyticDB在批发行业的深度利用和业务价值”的分享。更多前沿分享,点击云栖大会视频回放链接即可获取。 本篇内容将通过三个局部来介绍基于云原生数据仓库AnalyticDB MySQL的最佳实际。 一、批发行业的发展趋势 二、AnalyticDB的外围能力 三、AnalyticDB在批发中的利用 一、批发行业的发展趋势从最早的商超、百货以及到当初的电商、新批发,都是围绕三个外围因素来发展的:人、货、场。传统的批发大都是从场开始的:先有批发场合的创立,而后再等用户前来生产;消费行为始于批发场合,也终止于批发场合。 然而随着数字化和信息化的利用,人、货、场之间的关系正在被数据所重构产生了粗浅的变动:批发从新回归到“以人为本”的理念上——用户的需要在哪里,批发就产生的哪里,如办公室的无人货柜、共享充电宝等等;同时逐步造成了以“人为外围”的平面网络——交易行为冲破了时空的限度,变得随时随地都能够产生,而且消费行为的生命周期也会更长。 批发行业的数字化体现在三个中央: 第一,“人”的数字化。不论是线下万达商铺还是线上的淘宝商城,它实质都在于吸引用户流量——吸引用户进店,之后剖析用户流量,最初生产用户流量,所以人的数字化其实就在于用户流量的剖析和生产。 商家能够通过不同的路径去获取到用户数据,比方自有电商平台的数据、微博粉丝数据或者微信公众号朋友圈等等。在实现数据收集之后,商家会借助不同的数据挖掘算法,从各种维度对用户画像进行剖析,提取用户行为标签进行分类,最初针对不同的客户群体制订不同的营销计划。如何实现人群的精准剖析将会给批发产生十分重要的影响,如客流将决定着店铺的地位抉择。 第二,“货”的数字化。货的数字化次要围绕整个供应链的优化发展的,包含多渠道铺货/下单、订单治理以及履约交付等各环节的数字化。全域买通与治理就会给批发行业带了一些挑战:包含线上/线下多个渠道之间采纳怎么的铺货策略/销售策略、库存如何对立治理、如何实现疾速交付、如何晋升回购等等。 比方每年双11从发货到交付到消费者手上的速度是越来越快,这背地正是货的数字化施展着神奇的力量:双11前,淘宝/天猫/京东等电商平台,会剖析用户最近一段时间的消费行为,并进行提前预判——剖析哪些商品复购率比拟高、哪些商品的购买具备地区属性等等,而后就会提前将这些商品搁置到离消费者更近的前置仓;消费者下单后,间接从前置仓进行发货。同时,物流行业外面,通用的电子面单零碎,也是将物流的各个环节进行了数字化,这也极大晋升了货物的流通速度。 第三,“场”的数字化。次要比拟线上和线下不同渠道之间各自的劣势/劣势,而后利用彼此的劣势实现信息流和资金流的重构。线下门店能够充沛体验产品,但整体老本缺比线上店铺高很多。 于是很多企业就将线下门店和线上电商店铺联合起来一起做,比方小米之家&小米商城、TATA木门的线下体验店&天猫旗舰店等,都极大晋升了坪效。 批发行业的数字化,实现了全渠道商品/订单的对立治理、也积攒了大量用户数据、使得营销成果更加直观,然而也导致了数据量的极速增长。如何在海量数据中实现用户数据的实时/精准剖析、商品报表以及营销成果的及时疾速展示,也是零售商家所面临的问题和挑战。 二、AnalyticDB的外围能力 上述是原生数据仓库AnalyticDB在整个数据链路的架构图。 自下而上,数据如结构化/非结构化数据、日志数据、对象存储上的文件数据,都能够通过不同的工具,实时或者离线汇聚到AnalyticDB中;而后利用AnalyticDB简单查问的性能劣势实现数据统计分析;最初借助开源或商业化的BI展现工具,或者业务程序,进行图形化或者交互式展示。当然,也能够借助数据开发/调度工具,如DMS、DataWorks实现数据的ETL批处理,实现在/离线一体化数仓。 AnalyticDB的外围能力次要体现在三块:查问性能快,能够实现实时化剖析以及简略易用。 AnalyticDB使用新一代超大规模的MPP+DAG交融引擎,采纳行列混存、智能索引等技术,极大了晋升查问性能。简单SQL查问速度相比传统的关系型数据库快10倍以上,较传统数仓产品也有几倍的晋升。借助DTS实时同步工具,能够讲业务库的变更及时地被传输到ADB外面,从数据变更到剖析再到展示,整个链路提早在秒级。高度兼容MySQL和PG协定,通过规范SQL和罕用BI工具、以及ETL工具平台即可轻松应用,极大升高了数仓的构建老本以及保护老本。 AnalyticDB作为一款新型的OLAP产品,通常有两个常见的利用场景: 交互式BI剖析。如天猫双11大屏,涵盖总的交易额、类目标TOP、地区等相干统计。劣势:查问性能高,能够达到万亿级数据分析亳秒级响应,查问速度约为MySQL100倍。l  日志剖析。如游戏经营剖析和IT运维日志剖析等。劣势:实现结构化和非结构化数据的交融剖析,同时冷热拆散使得存储老本极大升高。三、AnalyticDB在批发中的利用AnalyticDB是如何帮忙批发行业客户晋升业务价值的呢?咱们来看几个客户案例。 第一个案例来自于客户云。客如云是给餐饮、批发、美业等本地生存服务业商家提供SAAS计划的服务商。 客户次要有三个诉求: 报表实时展示。传统数据仓库个别只能做到T+1展示,可能会导致商家隔天能力查看经营状况,进而导致补货、资源调配存在提早影响失常销售。画像剖析增值服务。客如云的商家心愿其提供更加精准的画像剖析服务,这样能够为不同的目标群体提供更贴心的餐饮服务,例如情侣套餐、经济套餐、满减打折券等。稳定性和扩展性。比方情人节、七夕、圣诞节等节假日用餐顶峰,须要保证系统的顺畅。 这个是架构降级之后的架构图。 PolarDB MySQL代替了传统MySQL,承当业务流量,具备极致弹性能力。 DTS将业务库中的数据变更实时地同步到AnalyticDB外面,实现业务库跟剖析库的解藕及实时同步。 AnalyticDB帮忙客户实现了实时报表剖析、简单交互式查问和用户画像剖析等性能。 通过这个架构降级,AnalyticDB帮忙客如云拓展了商业边界,找到了新的营收增长点:推出商户报表VIP套餐,报表更新从天升高到小时级别;同时也开发了用户画像精准营销服务,两项新性能给客如云每年新增几亿的营收。同时七夕、国庆、圣诞节等节假日用餐顶峰,零碎运行十分的晦涩,没有任何卡顿。 第二个案例来自于北京蜂创科技。北京蜂创科技中国企业级营销一体化治理 SaaS 平台。旗下领有营销流动治理平台、CRM用户关系治理平台、社区经营零碎、精准营销投放平台等多个产品平台。 次要面临几个问题: 查问性能差。表数据量大,单表数据量过亿甚至数十亿,并且多表关联/多维交互查问场景较多。而且广告主对于营销展示时效性要求十分高。传统数仓架构简单。波及的组件多、数据链路长、人员学习老本运维老本大。扩展性。能够承载将来3-5年数据的增长,不须要做架构再次降级。 联合业务场景,采纳了PolarDB-X+DTS+AnalyticDB的解决方案:分布式PolarDB-X做分库分表承当业务高并发;数据通过DTS实时传输到AnalyticDB;同时AnalyticDB也能够间接读取OSS上数据进行联结查问。这样就构建了一个数据汇聚、数据荡涤、ETL计算和实时查问服务的数据分析平台。 架构实现之后,AnalyticDB的引入使得多维分析查问性能都在秒级返回,营销成果展现更加及时。同时,AnalyticDB的疾速弹性以及数据冷热拆散,使得整体老本更可控。 第三个案例来自于上海分尚网络,国内鲜花电商领导品牌,发明了“线上订阅+产地直送+增值服务”的日常鲜花订阅模式。 次要面临的问题是:业务库和剖析库都应用传统MySQL,剖析场景如订单、商品流量、洽购、业务转化率、商品售罄报警等查问速度较慢甚至查问不进去的状况;业务倒退很快,数据量增长迅猛;技术团队对MySQL生态比拟相熟,传统数仓组件多学习老本高;另外就是思考将来数据进一步增长的状况下,零碎的扩展性。 起初OLAP剖析搁置到了AnalyticDB上:利用AnalyticDB优异的查问性能,报表和BI剖析速度有2-10倍的晋升,整体业务响应度和顾客服务体验也失去很大晋升。同时,利用ADB的数据冷热拆散以及资源组弹性性能,更高的扩展性和灵活性,IT收入老本升高30%以上。 还有更多的批发行业的客户,如飞鹤、竟然之家、生意顾问等等,也都在应用AnalyticDB承载简单的报表统计以及交互式剖析场景,通过数字化转型开掘更多的商业价值。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 16, 2021 · 1 min · jiezi

关于阿里云开发者:Serverless-下的微服务实践

简介:开发者基本不须要去关怀 Server ,只须要去专一业务逻辑即可,本文将详解微服务体系与平台化的 Serverless 架构交融的过程。微服务架构介绍微服务架构诞生背景在互联网晚期即 Web 1.0 的时代,过后风行的是单体利用,研发团队比拟小,次要是内部网页,而后新闻门户等;到了新世纪的互联网期间 Web 2.0 时代,网民数量大幅激增,相继呈现电商、社交这样巨无霸级别的互联网产品,呈现了几百人甚至上千的研发团队在一个场景下,流量及业务复杂度相较于上一个时代有了质的变动,因而单体服务的弊病:例如研发效率等问题便显现出来。 此时呈现了一个叫 SOA 的架构,其架构思路与微服务很像,它有相似于 ESB 这种中心化组件,阿里的 HSF,包含起初开源的 Double,都是在此阶段诞生的。 挪动互联网时代呈现之后,各种各样的 APP 诞生,生存也开始全面互联网化。大流量高并发以及规模化的研发团队变得越来越寻常,相应对高技术、生产力的要求也在逐渐晋升,此时微服务的概念应运而生。 微服务其实始终贯通在整个架构的倒退过程中。在 Java 的技术栈,相似于 Spring Cloud 、Double 这些框架都曾经十分风行。不难发现整个社会曾经步入数字化高速倒退阶段,此时更大的问题蕴含其中,如流量升高、利用复杂度晋升,研发团队扩充、对于效率的要求增高等等。 单体期间 1.0 版本 大部分的公司或晚期业务都会经验过这样的过程(如图所示):先是客户端,此时须要通过一个入口拜访,上图中 SLB 是阿里云一个负载平衡服务,它相当于一个网络入口,能够对应到 ECS(ECS 为阿里云的虚拟机)打到对应的单体的服务中,而此时他们会共用一个数据库,这是第一个期间。 单体期间 2.0 版本 到第二个期间 SOA 架构:此时呈现了分治的思维,它会将一些业务进行拆分。但它并未做到服务与底层的拆分,如存储数据库的拆分,其本质上还是共用一套数据库,因而它还是单体的架构。 微服务期间 而到微服务期间,如若客户端通过 SLB 拜访网关(如图所示),随后会转发对应的服务,且服务与服务之间会产生一些调用;每个服务会对应一个独自的数据库或缓存,且每个服务会通过相似于 Nacos 这种的服务进行注册、发现以及配置管理。 微服务引入之后,尽管解决了架构业务的拆散,可能让研发团队在某一个畛域、业务可能做到精专,不过从整体架构来看便会发现,相较于之前它其实是更为简单的,所以也带来一些运维上的问题。 在单体架构中于单体利用而言,会产生边界不清晰、模块耦合、共享代码库容易抵触的问题,同时如果团队规模较大,此时的合作效率也会绝对较低。然而微服务架构的外围就是解耦,如果做到拆分之后的解耦,就能够开释开发团队效率。 云原生时代微服务架构倒退微服务技术在云原生时代的技术引进云原生是一个很宏观的概念,如果咱们以微服务为终点来看云原生给微服务带来的变动与演进,能够更好地帮忙咱们了解什么是云原生。 微服务和单体利用的实质是什么呢?(如图所示)它其实是把单体利用从一个巨型的利用拆分成数个渺小的服务,合作来实现原先单体利用等效的业务服务。此时微服务与微服务之间会造成一个依赖关系,它须要部署至一个或多个资源上,这时的资源便是计算资源。 过来单体利用与资源之间的关系非常简略,单体利用的协同也都是一些外部协同,不存在内部动静的依赖。但架构转换到微服务之后,因为内部依赖和节点数量的爆炸,整个体系会变成网状,治理起来十分复杂。超过 50% 的企业会感觉采纳微服务架构,最大挑战是简单的运维,即整个服务生命周期的治理。 现在,比拟公认的一点是云原生的根基在于容器与容器的治理编排(K8S)。而容器与 K8S 的技术可能帮忙咱们解决微服务体系中所存在繁冗运维的问题。 首先不同的微服务之间会存在异构,即一个团队,在微服务体系下为了施展最大效力,可能会容许不同小团队采纳不同的编程语言、运行环境去运行微服务。因而最后咱们在运维和治理微服务时,是没有对立的规范去解决这些异构环境的。这便促发了云原生容器技术的风行,因为这项技术的作用就是通过一层标准化的运行时和封装来限度微服务部署。这样从生命周期与治理角度来看,每一个微服务之间的差别变少,非常有利于资源的调度。 随后。基于容器调度衍生出了容器平台。容器平台就是治理容器的,就 K8S 来说,它能够规范便捷地将微服务运行到底层的资源上,随后存储计算网络能够通过 K8S 这层来进行对立封装,一层形象与封装,它相似于云原生时代的操作系统。 它具体会提供哪些帮忙呢?在 K8S 中有个概念叫 POD ,POD 是一组容器的联合,与微服务实体生命周期的耦合,在一个 POD 外面,它能够运行一个或者是多个容器。 ...

November 15, 2021 · 1 min · jiezi

关于阿里云开发者:Serverless-工程实践-快速搭建-Kubeless-平台

简介:Kubeless 是基于 Kubernetes 的原生无服务器框架。其容许用户部署大量的代码(函数),而无须放心底层架构。疾速搭建 Kubeless 平台Kubeless 简介Kubeless 是基于 Kubernetes 的原生无服务器框架。其容许用户部署大量的代码(函数),而无须放心底层架构。它被部署在 Kubernetes 集群之上,并充分利用 Kubernetes 的个性及资源类型,能够克隆 AWS Lambda、Azure Functions、Google Cloud Functions 上的内容。 Kubeless 次要特点能够总结为以下几个方面。 反对 Python、Node.js、Ruby、PHP、Go、.NET、Ballerina 语言编写和自定义运行时。Kubeless CLI 合乎 AWS Lambda CLI。事件触发器应用 Kafka 音讯零碎和 HTTP 触发器。Prometheus 默认监督函数的调用和延时。反对 Serverless 框架插件。因为 Kubeless 的性能个性是建设在 Kubernetes 之上的,因而对于相熟 Kubernetes 的人来说非常容易部署 Kubeless。其次要实现是将用户编写的函数在 Kubernetes 中转变为 CRD(Custom Resource Definition,自定义资源),并以容器的形式运行在集群中。 Kubeless 部署在已有的 Kubernetes 集群上进行 Kubeless 服务的创立: export RELEASE=$(curl -s https://api.github.com/repos/kubeless/kubeless/releases/ latest | grep tag_name | cut -d '"' -f 4)kubectl create ns kubelesskubectl create -f https://github.com/kubeless/kubeless/releases/download/$RELEASE/ kubeless-$RELEASE.yaml创立胜利后如图所示 ...

November 15, 2021 · 1 min · jiezi

关于阿里云开发者:基于-OpenYurt-EdgeX-Foundry-的云边端一体化解决方案

简介:近日,OpenYurt 与 EdgeX Foundry 社区单干,实现了集成对接:从 v0.5.0 版本开始,OpenYurt 将正式反对部署和治理 EdgeX Foundry,并以云原生的形式治理端设施,单方将独特帮忙开发者轻松、高效地解决物联网边缘计算场景下端设施治理和运维的挑战。作__者|_VMWare 主任工程师:_刘武明、_浙江大学 SEL 实验室研究生:_陈涛__ 审核&校对:溪洋、海珠 编辑&排版:雯燕 背景介绍边缘计算区别于传统的核心云计算模式,并被宽泛地利用于汽车、农业、能源、交通等各行各业。Gartner 将边缘计算分为 "Cloud" 、"Far Edge"  、"Near Edge" 三局部,别离对应常见的公共云/公有云、云下 IDC/CDN 节点以及设施终端;即常说的 “云、边、端” 三层构造。随着算力和业务的逐级下沉,网络环境越来越简单,设施资源越来越受限,设施架构越来越丰盛,这些变动给运维治理边缘节点、设施,进步边缘利用的可靠性、资源的利用率等方面,都带来了微小的挑战。 近日,OpenYurt 与 EdgeX Foundry 社区单干,实现了集成对接:从 v0.5.0 版本开始,OpenYurt 将正式反对部署和治理 EdgeX Foundry,并以云原生的形式治理端设施,单方将独特帮忙开发者轻松、高效地解决物联网边缘计算场景下端设施治理和运维的挑战。 1、OpenYurt:非侵入式的边缘云原生智能平台OpenYurt 基于原生 Kubernetes 构建,由阿里云于 2020 年 5 月开源,并于同年 9 月份入选 CNCF SandBox 我的项目,是业界首个对 Kubernetes 无侵入的边缘计算云原生开源平台。OpenYurt 主打 “云边一体化” 的概念,针对边缘计算场景中的网络环境简单、大规模利用交付、运维艰难等痛点,提供了边缘自治、云边运维通道、单元化部署、一键式集群转化等能力,通过将云边节点对立治理,使得边缘节点领有与云端雷同的能力,帮忙开发者轻松实现在海量边缘资源上的大规模利用交付、运维、管控。 2、EdgeX Foundry:边缘物联网治理平台EdgeX Foundry 是一款由生态系统提供强力反对的边缘物联网即插即用型、开放式软件平台。它具备高度灵便和可扩展性,能够大大的升高利用与边缘设施,传感器等硬件互操作的复杂性。EdgeX Foundy 采纳分层和服务的设计,从下至上别离是设施服务,外围服务,反对服务,应用服务以及平安和治理两个辅助服务。EdgeX Foundry 的分层和服务为边缘设施/节点和云/企业应用之间提供了一个双向转换引擎。能够将传感器和节点数据按特定格局传输到利用,也能够将利用指令下发到边缘设施。 设施服务层:设施服务将“物”即传感器和设施连贯到 EdgeX 的其余部分。设施服务是与 “物” 交互的边缘连接器,包含但不限于警报系统、家庭和办公楼中的供暖和空调零碎、灌溉系统、无人机、自动化运输(例如一些铁路零碎)等等。外围服务层:外围服务包含外围数据库,外围元数据,配置和注册表以及外围命令/管制四个服务。他们是对各类设施的一层形象,保留和收集传感器的数据和元数据,以及来自利用的命令/管制以及配置。反对服务层:次要包含警报服务、告诉服务、打算服务,以及规定引擎。应用服务层:应用服务负责从 EdgeX 提取、解决、转换和发送感测数据到用户抉择的断点或者流程。EdgeX 当初提供了很多应用程序服务示例以将数据发送到一些次要的云提供商。平安服务层:爱护 EdgeX 治理的设施、传感器和其它物联网对象的数据以及管制。EdgeX 的平安性能建设在凋谢接口、可插拔、可更换模块的根底之上。治理服务:为内部管理系统提供对立的借口以便于其启动、进行、重启 Edgex 服务、获取服务的状态或者相干指标,以便于 EdgeX 服务能够被监控。拓展 “端” 的能力根据上述介绍能够看到,OpenYurt 善于以非侵入的形式,实现云边资源的对立治理和运维,使得边缘节点领有云端雷同的能力。但随着将相干纳管能力拓展至 “ 端 ”这一层时,因为近端设施异构资源反对简单、通信形式多样、散布地位扩散等特点,会呈现以下问题: ...

November 12, 2021 · 2 min · jiezi

关于阿里云开发者:基于-Istio-的全链路灰度方案探索和实践

简介:本文介绍的基于“流量打标”和“按标路由” 能力是一个通用计划,基于此能够较好地解决测试环境治理、线上全链路灰度公布等相干问题,基于服务网格技术做到与开发语言无关。同时,该计划适应于不同的7层协定,以后已反对 HTTP/gRpc 和 Dubbo 协定。作者|曾宇星(宇曾) 审核&校对:_曾宇星(宇曾)_ 编辑&排版:雯燕 背景微服务软件架构下,业务新性能上线前搭建残缺的一套测试零碎进行验证是相当费人费时的事,随着所拆分出微服务数量的一直增大其难度也愈大。这一整套测试零碎所需付出的机器老本往往也不低,为了保障利用新版本上线前的性能正确性验证效率,这套零碎还必须始终独自保护好。当业务变得宏大且简单时,往往还得筹备多套,这是整个行业独特面临且难解的老本和效率挑战。如果能在同一套生产零碎中实现新版本上线前的性能验证的话,所节约的人力和财力是相当可观的。 除了开发阶段的性能验证,生产环境中引入灰度公布能力更好地管制新版本软件上线的危险和爆炸半径。灰度公布是将具备肯定特色或者比例的生产流量调配到须要被验证的服务版本中,以察看新版本上线后的运行状态是否合乎预期。 阿里云 ASM Pro(相干链接请见文末)基于 Service Mesh 所构建的全链路灰度计划,能很好帮忙解决以上两个场景的问题。 ASM Pro 产品性能架构图: 外围能力应用的就是上图扩大的流量打标和按标路由以及流量 Fallback 的能力,上面具体介绍阐明。 场景阐明全链路灰度公布的常见场景如下: 以 Bookinfo 为例,入口流量会带上冀望的 tag 分组,sidecar 通过获取申请上下文(Header 或 Context) 中的冀望 tag,将流量路由散发到对应 tag 分组,若对应 tag 分组不存在,默认会 fallback 路由到 base 分组,具体 fallback 策略可配置。接下来详细描述具体的实现细节。 入口流量的 tag 标签,个别是在网关层面基于相似 tag 插件的形式,将申请流量进行打标。 比方将 userid 处于肯定范畴的打上代表灰度的 tag,思考到理论环境网关的抉择和实现的多样性,网关这块实现不在本文探讨的范畴内。上面咱们着重探讨基于 ASM Pro 如何做到全链路流量打标和实现全链路灰度。 实现原理 Inbound 是指申请发到 App 的入口流量,Outbond 是指 App 向外发动申请的进口流量。上图是一个业务利用在开启 mesh 后典型流量门路:业务 App 接管到一个内部申请  p1,接着调用背地所依赖的另一个服务的接口。此时,申请的流量门路是 p1->p2->p3->p4,其中 p2 是 Sidecar 对 p1 的转发,p4 是 Sidecar 对 p3 的转发。为了实现全链路灰度,p3 和 p4 都须要获取到 p1 进来的流量标签,能力将申请路由到标签所对应的后端服务实例,且 p3 和 p4 也要带上同样的标签。关键在于,如何让标签的传递对于利用齐全无感,从而实现全链路的标签透传,这是全链路灰度的关键技术。ASM Pro 的实现是基于分布式链路追踪技术(比方,OpenTracing、OpenTelemetry 等)中的 traceId 来实现这一性能。 ...

November 12, 2021 · 3 min · jiezi

关于阿里云开发者:加速SaaS规模化演进餐道基于K8s的云上创新底座

简介:餐饮正在成为数智化转型在实体经济使用中的最大试验场,推动着 SaaS 演进为餐饮行业新的基础设施。作为国内最早一批涉足餐饮 SaaS 的企业,餐道正在以云原生的形式帮忙餐饮企业进一步解决老本管制、效率晋升等需要。通过将业务平台迁徙至阿里云容器服务 ACK,使服务器资源利用率晋升超过 30%,扩容效率晋升近 80%,版本公布周期缩短近 40%,并以 0 集群故障为业务连续性提供充沛保障。作者|溪__洋、蔡金辉 审核&校对:溪洋、海珠、叶仔 编辑&排版:雯燕 “民以食为天”,这是一句刻在每个中国人 DNA 里的老话。餐饮行业也素来不乏强烈的竞争。生产降级和领取习惯变动、人力和经营老本攀升、由疫情带来的不确定性等种种趋势的一直蔓延,使餐饮企业对老本管制、效率晋升、精细化经营等需要越来越迫切。  全云开发新趋势与 SaaS 的演进 《2020 年中国企业级 SaaS 行业钻研报告》显示,到 2022 年,中国企业 SaaS 市场的规模预计将冲破千亿元。与此同时,餐饮 SaaS 等深耕垂直畛域的企业服务曾经进入规模化利用阶段。  作为国内最早一批涉足餐饮 SaaS 的先行者,餐道创始人李振宏认为,传统餐饮走向互联网化是顺应时代的必然选择。这也带动了餐饮 SaaS 逐步成为餐饮企业加强管理水平、优化老本构造的重要抉择。现在,哪怕是街边一个小吃摊,都在用互联网进行着结算;各大商圈的餐饮门店,也简直都在应用 SaaS 的收付款零碎。从技术上而言,餐饮 SaaS 曾经能从最后的洽购,贯通到顾客买单、顾客保护、外卖订单、骑手配送、人力治理以及供应链、数据中台等各个环节。  云计算是 SaaS 倒退的根基。在云原生带来的全云开发新趋势下,下一代 SaaS 将向何处演进?本文将通过餐道基于阿里云容器服务 ACK 的实际案例,分享以 Kubernetes 为根底的云原生架构如何助力餐饮 SaaS 实现更加稳固、牢靠的服务,并进一步帮忙企业优化资源和人力老本。  餐道打造基于 ACK 的交融翻新云上底座餐道将本身定位为餐饮新批发行业“连接器”。截至 2021 年 10 月,其服务已笼罩了全国 400+ 个城市,80000+ 家门店,日解决订单 350 万+。在餐道看来,将来餐饮企业肯定会以“数据服务化”、“全渠道服务化”和“新业务拓展麻利化”的融合与翻新为倒退方向。  为了帮忙商家建设全链路业务的一站式治理形式,实现降本增效,餐道基于 SaaS 架构打造了一体化数据智能利用,可能对接外卖平台、商家自建零碎、收银零碎、会员零碎、配送供应商、后厨、ERP 零碎、线上领取零碎等。   餐道业务架构图 餐道非常重视客户对服务的体验,并将零碎稳定性、业务性能的迭代效率、问题的疾速定位和解决视为构建外围竞争力的基石。餐饮行业业务流量的波峰波谷景象显著,且常常会通过促销流动的形式来吸引顾客,如果因为资源分配不合理导致顶峰期间订单溢出、运力有余,会极大影响顾客和商家的体验;此外,餐道提供了订单管理系统、CDBI、小程序、聚合配送、DMS、代经营等诸多垂直业务性能,在市场需求的疾速变动下,产品性能翻新和迭代效率问题也是对技术架构的一大挑战。  这些现状的解法和云原生架构带来的外围能力不约而同。餐道将次要的业务利用,包含前端 Web 容器、网关、后端微服务通过 Kubernetes 集群部署,以云原生的形式帮忙业务疾速迭代,灵便响应商业需要。  ...

November 12, 2021 · 1 min · jiezi

关于阿里云开发者:基于-KubeVela-的-GitOps-交付

简介:KubeVela 是一个简略、易用、且高可扩大的云原生利用治理和交付平台,KubeVela 背地的 OAM 模型人造解决了利用构建过程中对简单资源的组合、编排等治理问题,同时也将前期的运维策略模型化,这意味着 KubeVela 能够联合 GitOps 治理简单大规模利用,收敛因为团队与零碎规模增长导致的零碎复杂度问题。作者|董天欣(雾雾) 审核&校对:溪洋、海珠 编辑&排版:雯燕 KubeVela 是一个简略、易用、且高可扩大的云原生利用治理和交付平台,能让开发人员方便快捷地在 Kubernetes 上定义与交付古代微服务利用,无需理解任何 Kubernetes 基础设施相干的细节。 KubeVela 背地的 OAM 模型人造解决了利用构建过程中对简单资源的组合、编排等治理问题,同时也将前期的运维策略模型化,这意味着 KubeVela 能够联合 GitOps 治理简单大规模利用,收敛因为团队与零碎规模增长导致的零碎复杂度问题。 什么是 GitOps它的核心思想是将利用零碎所需的基础架构和利用配置申明性形容寄存在Git仓库中,并配合一个自动化流程,使每次仓库被更新后,自动化过程都能逐步将环境更新到最新配置。 这样的形式容许开发人员通过间接更改 Git 仓库中的代码和配置来主动部署利用,应用 GitOps 的形式能够为利用研发带来诸多价值,例如: 进步生产效率。通过主动的继续部署可能放慢均匀部署工夫,减少开发效率。升高开发人员部署的门槛。通过推送代码而非容器配置,开发人员能够不须要理解 Kubernetes 的外部实现,便能够轻易部署。使变更记录可追踪。通过 Git 来治理集群,能够使每一次更改都可追踪,增强了审计跟踪。可通过 Git 的回滚/分支性能来复原集群。KubeVela 与 GitOpsKubeVela 作为一个申明式的利用交付管制立体,人造反对以 GitOps 的形式来应用,并使用户更显著地感触到由 GitOps 带来的好处,和端到端的利用交付与治理体验,包含: 利用交付工作流(CD 流水线)即:KubeVela 反对在 GitOps 模式中形容过程式的利用交付,而不只是简略的申明终态;解决部署过程中的各种依赖关系和拓扑构造;在现有各种 GitOps 工具的语义之上提供对立的下层形象,简化利用交付与治理过程;对立进行云服务的申明、部署和服务绑定;提供开箱即用的交付策略(金丝雀、蓝绿公布等);提供开箱即用的混合云/多云部署策略(搁置规定、集群过滤规定等);在多环境交付中提供 Kustomize 格调的 Patch 来形容部署差别,而无需学习任何 Kustomize 自身的细节;…… 在本文中,咱们次要解说间接应用 KubeVela 在 GitOps 模式下进行交付的步骤。 GitOps 工作流GitOps 工作流分为 CI 和 CD 两个局部: ...

November 12, 2021 · 4 min · jiezi

关于阿里云开发者:消息队列RocketMQ应对双十一流量洪峰的六大武器

简介:音讯队列 RocketMQ 是如何帮忙各企业交易系统扛住霎时千万级 TPS、万亿级流量洪峰的冲击,并放弃各个利用之间的音讯通顺的呢?下文将为您介绍音讯队列 RocketMQ 应答双十一流量洪峰的“六大武器”。作者:不周 审核&校对:岁月、明锻 编辑&排版:雯燕 “ 4982 亿,58.3 万笔/秒 ”的背地在新冠肺炎疫情催化下,数字化生存形式渐成新常态。“4982 亿,58.3 万笔/秒”是 2020 天猫双 11 寰球狂欢节(简称:天猫双 11 )对数字经济的先发劣势和微小潜能的直观体现。 面对千万级并发、万亿级的流量洪峰,背地无力撑持的便是双十一交易外围链路的官网指定产品:音讯队列 RocketMQ 。 双十一交易场景业务痛点随着双十一的逐年升温,保障交易场景的稳定性已成为各企业在双十一业务中的要害,每年双十一流动的凌晨,是“万民狂欢”的日子,同时也是各企业交易系统备受考验的时候,保障外围交易系统的业务解决能力、有效应对每秒数十万笔的交易订单成为重中之重,若不能进行流量缓冲将间接引发这些零碎的解体。防止零碎解体的外围“秘诀”便是音讯队列 RocketMQ。 音讯队列 RocketMQ 是如何帮忙各企业交易系统扛住霎时千万级 TPS、万亿级流量洪峰的冲击,并放弃各个利用之间的音讯通顺的呢?上面为您介绍音讯队列 RocketMQ 应答双十一流量洪峰的“六大武器”。 音讯队列 RocketMQ 的“六大武器”双十一的流量洪峰到底会给用户和商家零碎业务带来哪些问题?音讯队列 RocketMQ 的“六大武器”是如何解决这些问题的呢?小编带您初探一二: 武器一:“异步解耦”背景:双十一的夜晚,当用户在手机上“指点江山”时,可曾想,一个小小的购物 APP 背地其实是一个个宏大的零碎,从用户选购商品的那一刻起,就要和成百个业务零碎打交道,每一笔交易订单数据都会有几百个上游业务零碎的关联,包含物流、购物车、积分、直充、流计算剖析等等,整个零碎宏大而且简单,架构设计稍有不合理,将间接影响主站业务的连续性。面对如此简单且宏大的零碎,防止零碎业务之间互相耦合影响,便要用到音讯队列 RocketMQ 的“异步解耦”性能,通过音讯队列 RocketMQ 实现上、上游业务零碎松耦合,松耦合能够升高零碎的复杂度,缩短用户申请的响应工夫(将原多个步骤的所需工夫之和压缩到只需一条音讯的工夫),保障上游某个子系统的故障不影响整个链路。 武器二:“削峰填谷”背景:在解决完交易业务背地宏大的零碎所带来的耦合性问题后,从用户视角登程来看,双十一期间 0 点这个工夫有成千盈百万的用户在同时点击着购买页面,因为用户海量申请,导致流量激增,面对如此大量的拜访流量,上游的告诉零碎可能无奈承载海量的调用量,甚至会导致系统解体等问题而产生漏告诉的状况。为解决这些问题,就要用到音讯队列 RocketMQ 的“削峰填谷”性能,可在利用和上游告诉零碎之间退出音讯队列 RocketMQ,RocketMQ 反对高并发的音讯低提早写入,以及有限的沉积能力,能够防止超高流量的冲击,确保上游业务在平安水位内平滑稳固的运行。 武器三:“分布式事务音讯”背景:通过后面的介绍理解到,通过音讯的异步解耦,可实现音讯的分布式解决,在传统的分布式事务处理形式中,用户创立了一条新的订单信息,伴着这条订单信息的变更,在整个业务链条中的购物车、用户表、积分等都须要变更,零碎须要借助分布式事务协调组件来保障多个业务调用的事务一致性。传统的分布式事务组件谋求强一致性,性能吞吐低,零碎简单。那如何能力既实现分布式事务,同时又不使零碎过于简单?这个时候音讯队列 RocketMQ 的“分布式事务音讯”的性能便起到了关键作用,通过原创的轻量级订单流转事务协调能力,只需发送一条音讯,就能够实现音讯最终一致性的分布式事务,同时确保订单状态长久化和上游调用统一。 武器四:“音讯过滤”背景:通过以上介绍会发现从客户下单到客户收到商品这一过程会生产一系列音讯,按音讯品种能够分为交易音讯、物流音讯、购物车音讯等,如何保障各个品种的音讯进行无效投递并被精确生产?这时候就要用到音讯队列 RocketMQ 的“音讯过滤”性能,能够通过 Tag 给不同品种的音讯定义不同的属性,依据音讯属性设置过滤条件对音讯进行过滤,只有合乎过滤条件的音讯才会被投递到生产端进行生产。比方给物流音讯定义地区属性,依照地区分为杭州和上海: 订单音讯物流音讯物流音讯且地区为杭州物流音讯且地区为上海 武器五:“定时音讯”背景:除了以上零碎级别中可能呈现的问题外,用户本人在购物过程中可能都遇到过一些小细节,比方在点击了购买按钮后,会呈现“请您在 30 分钟内实现领取”的提醒,如果超过 30 分钟未领取,订单就会主动敞开。这个业务用到的是音讯队列 RocketMQ 的“定时音讯”性能,音讯队列 RocketMQ 能够实现自定义秒级精度距离的定时音讯,通过音讯触发一些定时工作,比方在某一固定工夫点向用户发送揭示音讯,最终实现海量订单状态变更超时的核心调度。 ...

November 11, 2021 · 1 min · jiezi

关于阿里云开发者:双十一特惠|阿里云数据库ACA认证新用户专享5折

简介:阿里云数据库ACA认证,助力广大客户、合作伙伴、开发人员和DBA乘云而上。双十一新用户专享 阿里云数据库ACA认证5折优惠!随着云计算疾速倒退,传统的商业数据库曾经难以满足和响应疾速变动、持续增长的业务诉求。将来,越来越多的企业将会采纳云数据库。阿里云数据库ACA认证,助力广大客户、合作伙伴、开发人员和DBA乘云而上! 双十一新用户专享阿里云数据库ACA认证5折优惠!点击链接进入购买链接 下拉页面至「阿里云认证学习」 抉择「云数据库助理工程师ACA认证」  什么是阿里云数据库ACA认证? 阿里云数据库ACA证书  阿里云云数据库助理工程师认证(Alibaba Cloud Certified Associate - Cloud Database)是面向学生、开发者和运维人员的阿里云在线认证,取得此认证可证实您把握了阿里云数据库产品的外围性能和利用技能,能够在阿里云生态取得更好的就业机会。 为什么要考阿里云数据库ACA认证? 如果你是客户,你能够: 理解阿里云数据库外围产品的性能个性、架构原理及次要利用场景。具备较强的数据库选型意识,晋升客户对云数据库产品的抉择能力。纯熟应用阿里云数据库产品,帮忙企业更释怀、更安心地构建数据库根底服务。如果你是合作伙伴,你能够: 向企业、内部用户解说阿里云数据库产品的产品体系、产品外围性能及其实用场景。把握阿里云各类数据库的操作(如:迁徙、日常运维、性能调优等),帮忙企业客户晋升业务稳定性。为客户提供基于云数据库的架构方案设计,帮忙更多的客户疾速平滑上云,晋升整体交付能力。如果你是高校学生&社会在职人员,你能够: 把握阿里云数据库外围产品的从业基础知识,取得阿里云认证优先待业通道,职业倒退的久远抉择!如果你有阿里云数据库ACA认证相干问题或合作意向,请通过上面的形式分割咱们:training@service.aliyun.com  阿里云认证官网学习钉钉群号:33715706 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 11, 2021 · 1 min · jiezi

关于阿里云开发者:网易云音乐音视频算法的-Serverless-探索之路

简介:网易云音乐最后的音视频技术大多都利用在曲库的数据处理上,基于音视频算法服务化的教训,云音乐曲库团队与音视频算法团队一起合作,一起共建了网易云音乐音视频算法解决平台,为整个云音乐提供对立的音视频算法解决平台。本文将分享咱们如何通过 Serverless 技术去优化咱们整个音视频解决平台。作者:_廖祥俐_ 策动:望宸 审核&校对:潇航 编辑&排版:雯燕 网易云音乐最后的音视频技术大多都利用在曲库的数据处理上,基于音视频算法服务化的教训,云音乐曲库团队与音视频算法团队一起合作,一起共建了网易云音乐音视频算法解决平台,为整个云音乐提供对立的音视频算法解决平台。本文将分享咱们如何通过 Serverless 技术去优化咱们整个音视频解决平台。 本文将从三个局部向大家介绍: 现状:音视频技术在网易云音乐的利用状况,引入 Serverless 技术之前遇到的问题;选型:调研 Serverless 计划时的思考点;落地和瞻望:咱们进行了哪些革新,最终的落地成果和将来布局。现状作为一家以音乐为主体的公司,音视频技术被广泛应用于网易云音乐的泛滥业务场景里,为了更形象的让大家感触到,这里列举了 5 个常见的场景: 默认状况下,用户听到的是咱们采纳音频转码算法事后转好的标准化码率的音质,但因为流量无限或本身对于音质更高的要求,想要切换到差一些或更好的音质。用户能够应用云音乐 APP 外面的听歌识曲性能去辨认环境中的音乐,这背地应用到了音频指纹提取及辨认技术。在平台上的一些 VIP 歌曲,为了能给用户更好的试听体验,咱们会做副歌检测,让试听间接定位到低潮片段,这里用到了副歌检测算法。在云音乐的 K 歌场景里,咱们须要对音频的音高进行展现并辅助打分,这里咱们用到了音高生成算法去欠缺 K 歌的根底数据。为了更好的满足云音乐平台上,小语种用户的听歌体验,咱们为日语、粤语等提供了音译歌词,这里用到了主动罗马音的算法。从下面的场景能够看到,音视频技术被广泛应用于云音乐的不同场景外面,施展了重要的作用。 从咱们的音视频技术做一个简略划分,能够分为三大类:剖析了解、加工解决、创作生产,这些一部分是以端上 SDK 的形式,在端上进行解决;而更多的局部,是通过算法工程化的形式,采纳后端集群部署治理,以服务的模式提供通用的音视频能力,而这部分是咱们明天分享的重点。 音视频算法的服务化部署工作中,须要理解很多相干音视频算法的特点,如部署环境、执行工夫、是否反对并发解决等,随着咱们落地算法的减少,咱们总结了以下法则: 算法的执行工夫长:执行工夫往往与原始音频的时长成正比,云音乐很多场景下音频、视频的时长 Range 范畴是很大的,基于这个特点,咱们在执行单元的设计上,往往都采纳异步化的模式。音视频算法具备多语言个性:云音乐的算法包含了 C++、Python 等语言,对接环境上下文会带来极大的困扰,为了解决这个问题,咱们采纳标准化约定及镜像交付的形式,解耦各类环境筹备的工作,所以后续对于是否反对镜像部署,会成为咱们技术选型的一个重点考查。弹性的诉求正在变大:云音乐平台的歌曲,从我入职时候的 500w,到当初在线超过 6000w,增量 vs 存量的 gap 越来越大,当咱们疾速施行一个算法时,不仅要思考增量的接入,更要思考存量的疾速解决,所以在零碎设计中,会独自把执行单元的最小粒度剥离进去,便于疾速的扩容。基于咱们对工程化的了解,及音视频算法解决的特点,云音乐的音视频解决平台的整体架构如下: 对于不同音视频算法解决的独特局部,咱们做了对立的设计,包含算法解决的可视化、监控、疾速试用和解决数据统计等,对于资源的调配也设计了对立可配置的管理模式,让整个零碎的公共局部能够尽可能形象并复用。 整个音视频算法解决平台最要害的,也是明天的分享重点,是执行单元的交互与设计。云音乐通过对立的对接规范、采纳镜像交付的形式,解决了很多对接和部署上的效率问题。针对资源的应用,因为咱们一直有新算法、存量/增量服务的存在,在上云之前,用的是外部公有云云主机申请/回收、内容容器化的形式。 为了更好的形容云音乐执行单元的运行流程,咱们将它更细化下,如下图所示: 通过音讯队列去解耦了执行单元与其余零碎的交互,在执行单元外部,咱们通过管制音讯队列的并发度去适配不同并发性能的算法,尽量管制执行单元的次要工作仅用于算法的计算,这样最终在零碎扩容的时候,咱们可能做到最小粒度的扩容。 在这个模式下,咱们落地了 60 多种音视频算法,尤其是在近一年来,服务化的算法占到了一半,这些算法向云音乐 100+ 的业务场景提供了服务能力。但更简单的算法、更多的业务场景,对咱们的服务化效率、运维部署和弹性能力都提出了更高的要求,在咱们上云之前,在外部曾经用到了 1000 台以上不同规格的云主机及物理机。 选型随着业务场景和算法复杂度的减少,尽管通过了很多形式去简化了外部业务场景、算法等的对接,但越来越多夹杂存量、增量解决的算法,不同流量的业务场景规模,以及不同业务场景可能会复用同一类算法的,让咱们在解决机器资源的工夫,远比咱们在开发的工夫更多。 这个也促使咱们开始去思考更多的形式办法,去解决咱们遇到的问题,最间接的有三个痛点。 第一个是存量和增量的差别变大,和新算法落地的增多,咱们花在解决存量和增量的资源协调工夫越来越多;其次是随着算法复杂度的增高,咱们在申请/洽购机器的时候,须要关注机器的整体规格、利用率等;最初是,咱们心愿存量的解决可能放慢,在解决存量的时候有足够大的资源,在海量音视频数据处理时候,可能压缩存量与增量不统一的工夫。总的来讲,咱们心愿可能有足够大规模的弹性资源,让音视频算法服务不必再多去关注机器治理。 然而,理论革新不仅仅是关注最终服务能力,还须要综合思考投入的 ROI。具体来看: 老本:蕴含两方面,革新的施行老本和计算资源的老本。前者能够联合具体计划进行评估,失去所需投入的人日,此外,革新后在将来的灵便拓展性,也是咱们须要思考的点。后者能够通过云厂商官网给出的费用计算模型,联合咱们的执行数据,估算进去。咱们在老本方面的选型要害是,在革新老本可能承受的状况下,将来的 IT 老本不会大额的减少。运行环境的反对:后面提到过,云音乐的运行环境比拟多样化,是以镜像交付的形式进行部署的;团队外部都有绝对欠缺的 CICD 反对,这个要求将来的降级、部署事务,例如规格配置上,是否可能简化开发人员对于机器等的关注。咱们心愿在革新后,不须要在此类事项上破费过多的工夫和精力,更多的关注算法执行自身。弹性能力:除了云厂商提供的计算资源池的规模,咱们还会关注弹性算力的启动速度,是否可能对固定场景进行实例预留,以及是否提供更合乎业务诉求的灵便弹性能力,以更好的反对业务的倒退。这些其实都合乎 Serverless 的定义,构建和运行应用程序都不须要对服务器进行治理、弹性能力出众等。综合以上的考量,咱们抉择了私有云函数计算的形式,它能直观的映射咱们目前的计算执行过程,同时也能满足后续想尝试通过 Schema 进行算法的编排。上面我会重点分享下引入函数计算 FC 的过程。 ...

November 11, 2021 · 1 min · jiezi

关于阿里云开发者:全面升级-Apache-RocketMQ-50-SDK-的新面貌

简介:长久以来,RocketMQ 易于部署、高性能、高可用的架构,撑持了数十年来团体内外海量的业务场景。时至今日,为了迎接现在云原生时代的新挑战,咱们重磅推出了 RocketMQ 5.0 新架构。作者 | 凌楚 引言长久以来,RocketMQ 易于部署、高性能、高可用的架构,撑持了数十年来团体内外海量的业务场景。时至今日,为了迎接现在云原生时代的新挑战,咱们重磅推出了 RocketMQ 5.0 新架构。 在 5.0 新架构中,咱们更新了整个 RocketMQ 的网络拓扑模型,着眼于将更下层的业务逻辑从 broker 中剥离到无状态的 proxy ,这样独立的计算节点能够无损地承当日后的降级公布工作,与此同时将 broker 解放出来承当纯正的存储工作,为将来打造更强的音讯存储引擎做好铺垫。通信层方面,出于标准化,多语言的思考咱们摒弃了 RocketMQ 应用多年的 RemotingCommand 协定,采纳了 gRPC 来实现客户端与服务端之间的通信逻辑。 针对于用户侧,咱们心愿尽可能少的叨扰客户进行降级,维持逻辑轻量,易于保护,可观测性良好,可能能够达到“一次性把事件做对”。 目前,保障了接口齐全兼容的,基于 RocketMQ 5.0 的商业化版本 Java SDK 曾经在私有云 release 实现,开源版本也行将 release。SDK 将同时反对云上 proxy 架构的云上版本和开源版本的 Broker。上面将开展叙述 RocketMQ 5.0 新架构下的 SDK 做了哪些迭代与演进。 全面异步化1、异步的初衷因为波及诸多的网络 IO,因而 RocketMQ 对音讯发送凋谢了同步和异步两套 API 提供给用户应用。旧有架构从 API 针对于同步和异步保护了两套相似的业务逻辑,十分不利于迭代。思考到这一点,此次新架构 SDK 心愿在底层就能够将它们对立起来。 以音讯发送为例,一个残缺的音讯发送链路包含获取: 获取 topic 对应的路由;依据路由抉择对应的分区;发送音讯到指定的分区,如果发送到该分区失败,则对下一个分区进行发送重试直到达到最大重试次数;如果发送胜利,则返回发送后果。其中从远端获取 topic 对应的路由是一个重 IO 操作,而发送音讯自身也是一个重 IO 操作。在以往的发送实现中,即便是异步发送,对于路由的获取也是同步的,路由的获取自身并没有计入用户的发送耗时中,用户自身是能够自主设置音讯发送的超时工夫的,而因为自身音讯的发送是同步的,无奈做到超时工夫的精准管制,而在应用异步 Future 之后,能够十分不便地通过管制 Future 的超时工夫来做到。 ...

November 11, 2021 · 4 min · jiezi

关于阿里云开发者:专业版再增强-MSE-无缝兼容-Eureka-协议性能提升50

简介:MSE 注册配置核心专业版齐全兼容了 Eureka 协定,并对其读写性能、实例容量进行了大幅优化。作者:涌月 审核&校对:彦林、草谷、望宸 编辑&排版:酒圆 Eureka 是一款优良的注册与发现产品,其作为 Netflix 公司重要的开源我的项目,曾经成为 Spring-cloud-netflix 生态默认的注册核心。在过来的数年中,Eureka 为大量的中国互联网公司提供了开箱即用的注册核心服务解决方案。 但因为 Eureka 开源社区进行保护,并且在业务规模增大的时候存在性能问题,因而须要寻找一个可代替的高性能注册核心,进行平滑迁徙和演进。 Eureka 的性能问题随着业务的倒退,Eureka 逐渐暴露出一些性能问题。上万量级实例的频繁变更、洪水般的流量申请,即使通过部署高配服务器,也无奈解决 Eureka 的性能瓶颈: 1、服务状态更新滞后:因为 Eureka 存在缓存机制,基于其搭建的微服务零碎通常会呈现服务状态更新滞后,30-60s 才可能获取到精确的服务实例列表; 2、同步速度慢:当业务流量大时,为了保障高可用和高性能,通常 Eureka 须要以集群模式运行。然而,Eureka 集群之间的读写同步速度绝对迟缓,即在一台 Eureka 上注册实例,须要期待较长提早之后,能力在另一台机器上查问到相干信息,导致了业务呈现常常线上 Bug。 Eureka的社区问题除了上述的性能问题外,Eureka 社区以后曾经发表进行保护(如下图),锁死在一个不倒退的社区上有很高的技术危险和不确定性。 MSE注册配置核心专业版的劣势为了升高 Eureka 技术体系进行保护的不确定性,并加强 Eureka 注册核心的稳定性和高并发能力,咱们首次在 MSE 注册配置核心专业版(以下简称专业版)上齐全兼容了 Eureka 协定,并对其读写性能、实例容量进行了大幅优化。 某大型教育机构用户反馈,绝对于开源 Eureka,专业版性能大幅晋升,目前曾经在其业务场景中落地。专业版的外围能力和性能体现如下: 1、多协定反对:用户应用 Eureka 注册核心的实例,齐全能够应用 Nacos 协定进行发现,保障用户技术栈的多层次兼容性; 2、高性能反对:极大地优化了读写同步速度,使得基于此搭建的微服务零碎具备更高的性能和易用性;依据实验室的压测数据,MSE-Nacos 下的 Eureka 注册核心的读写性能、实例容量均晋升达 50%以上。 3、融入服务网格生态:通过反对 MCP 协定和 XDS 协定,服务网格生态畛域已齐全兼容专业版的 Eureka 协定,为 Istio 接入 Eureka 提供零侵入、高性能的微服务以及网关解决方案。 1、比照压测报告咱们对开源 Eureka 和专业版,在读写性能、容量评估上进行了压测,次要包含如下两个场景。 ...

November 11, 2021 · 1 min · jiezi

关于阿里云开发者:前后端多语言跨云部署全链路追踪到底有多难

简介:残缺的全链路追踪能够为业务带来三大外围价值:端到端问题诊断,零碎间依赖梳理,自定义标记透传。作者 | 涯海 全链路追踪的价值链路追踪的价值在于“关联”,终端用户、后端利用、云端组件(数据库、音讯等)独特形成了链路追踪的轨迹拓扑大图。这张拓扑笼罩的范畴越广,链路追踪可能施展的价值就越大。而全链路追踪就是笼罩全副关联 IT 零碎,可能残缺记录用户行为在零碎间调用门路与状态的最佳实际计划。 残缺的全链路追踪能够为业务带来三大外围价值:端到端问题诊断,零碎间依赖梳理,自定义标记透传。 端到端问题诊断:VIP 客户下单失败,内测用户申请超时,许多终端用户的体验问题,追根溯源就是因为后端利用或云端组件异样导致的。而全链路追踪是解决端到端问题最无效的伎俩,没有之一。零碎间依赖梳理:新业务上线,老业务裁撤,机房搬迁/架构降级,IT 零碎间的依赖关系盘根错节,曾经超出了人工梳理的能力领域,基于全链路追踪的拓扑发现,使得上述场景决策更加麻利、可信。自定义标记透传:全链路压测,用户级灰度,订单追溯,流量隔离。基于自定义标记的分级解决&数据关联,曾经衍生出了一个凋敝的全链路生态。然而,一旦产生数据断链、标记失落,也将引发不可预知的逻辑劫难。全链路追踪的挑战与计划全链路追踪的价值与笼罩的范畴成正比,它的挑战也同样如此。为了最大水平地确保链路完整性,无论是前端利用还是云端组件,无论是 Java 语言还是 Go 语言,无论是私有云还是自建机房,都须要遵循同一套链路标准,并实现数据互联互通。多语言协定栈对立、前/后/云(多)端联动、跨云数据交融是实现全链路追踪的三大挑战,如下图所示: 1、多语言协定栈对立在云原生时代,多语言利用架构越来越广泛,利用不同语言个性,实现最佳的性能和研发体验成为一种趋势。然而,不同语言的成熟度差别,使得全链路追踪无奈做到齐全的能力统一。目前业界的支流做法是,先保障近程调用协定层格局对立,多语言利用外部自行实现调用拦挡与上下文透传,这样能够确保根底的链路数据残缺。 然而,绝大部分线上问题无奈仅通过链路追踪的根底能力就可能无效定位并解决,线上零碎的复杂性决定了一款优良的 Trace 产品必须提供更加全面、无效的数据诊断能力,比方代码级诊断、内存剖析、线程池剖析、无损统计等等。充分利用不同语言提供的诊断接口,最大化的开释多语言产品能力是 Trace 可能一直向前倒退的根底。 透传协定标准化:全链路所有利用须要遵循同一套协定透传规范,保障链路上下文在不同语言利用间可能残缺透传,不会呈现断链或上下文缺失的问题。目前支流的开源透传协定包含 Jaeger、SkyWalking、ZipKin 等。最大化开释多语言产品能力:链路追踪除了最根底的调用链性能外,逐渐衍生出了利用/服务监控,办法栈追踪,性能分析等高阶能力。然而不同语言的成熟度导致产品能力差异较大,比方 Java 探针能够基于 JVMTI 实现很多高阶的边缘侧诊断。优良的全链路追踪计划会最大化的开释每种语言的差异化技术红利,而不是一味的谋求趋同平庸。2、前后云(多)端联动目前开源的链路追踪实现次要集中于后端业务应用层,在用户终端和云端组件(如云数据库)侧不足无效的埋点伎俩。次要起因是后两者通常由云服务商或三方厂商提供服务,依赖于厂商对于开源的兼容适配性是否敌对。而业务方很难间接染指开发。 上述情况的间接影响是前端页面响应慢,很难间接定位到后端哪个利用或服务导致的,无奈明确给出确定性的根因。同理,云端组件的异样也难以间接与业务利用异样划等号,特地是多个利用共享同一个数据库实例等场景下,须要更加曲折的伎俩进行验证,排查效率非常低下。 为了解决此类问题,首先须要云服务商更好的反对开源链路规范,增加外围办法埋点,并反对开源协定栈透传与数据回流(如阿里云 ARMS 前端监控反对 Jaeger 协定透传与办法栈追踪)。 其次,因为不同零碎可能因为归属等问题,无奈实现全链路协定栈对立,为了实现多端联动,须要由 Trace 零碎提供异构协定栈的买通计划。 异构协定栈买通为了实现异构协定栈(Jaeger、SkyWalking、Zipkin)的买通,Trace 零碎须要反对两项能力:一是协定栈转换与动静配置,比方前端向下透传了 Jaeger 协定,新接入的上游内部零碎应用的则是 ZipKin B3 协定。在两者之间的 Node.js 利用能够接管 Jaeger 协定并向下透传 ZipKin 协定,保障全链路标记透传完整性。二是服务端数据格式转换,能够将上报的不同数据格式转换成对立格局进行存储,或者在查问侧进行兼容。前者保护老本绝对较小,后者兼容性老本更高,但绝对更灵便。 3、跨云数据交融很多大型企业,出于稳定性或数据安全等因素思考,抉择了多云部署,比方国内零碎部署在阿里云,海内零碎部署在 AWS 云,波及企业外部敏感数据的零碎部署在自建机房等。多云部署曾经成为了一种典型的云上部署架构,然而不同环境的网络隔离,以及基础设施的差异性,也为运维人员带来了微小的挑战。 因为云环境间仅能通过公网通信,为了实现多云部署架构下的链路完整性,能够采纳链路数据跨云上报、跨云查问等形式。无论哪种形式,指标都是实现多云数据对立可见,通过残缺链路数据疾速定位或剖析问题。 跨云上报链路数据跨云上报的实现难度绝对较低,便于保护治理,是目前云厂商采纳的支流做法,比方阿里云 ARMS 就是通过跨云数据上报实现的多云数据交融。 跨云上报的长处是部署成本低,一套服务端便于保护;毛病是跨云传输会占用公网带宽,公网流量费用和稳定性是重要限度条件。跨云上报比拟适宜一主多从架构,绝大部分节点部署在一个云环境内,其余云/自建机房仅占大量业务流量,比方某企业 toC 业务部署在阿x云,企业外部利用部署在自建机房,就比拟适宜跨云上报的形式,如下图所示。 跨云查问跨云查问是指原始链路数据保留在以后云网络内,将一次用户查问别离下发,再将查问后果聚合进行对立解决,缩小公网传输老本。 跨云查问的长处就是跨网传输数据量小,特地是链路数据的理论查问量通常不到原始数据量的万分之一,能够极大地节俭公网带宽。毛病是须要部署多个数据处理终端,不反对分位数、全局 TopN 等简单计算。比拟适宜多主架构,简略的链路拼接、max/min/avg 统计都能够反对。跨云查问实现有两种模式,一种是在云网络外部搭建一套集中式的数据处理终端,并通过内网专线买通用户网络,能够同时解决多个用户的数据;另一种是为每个用户独自搭建一套 VPC 内的数据处理终端。前者保护成本低,容量弹性更大;后者数据隔离性更好。 其余形式除了上述两种计划,在理论利用中还能够采纳混合模式或仅透传模式。 ...

November 11, 2021 · 1 min · jiezi

关于阿里云开发者:MSE-阿里巴巴云原生网关三位一体的选择与实践

简介:三位一体是阿里巴巴“自研”、“开源”、“商业化”采纳的对立技术体系,心愿以开源做内核、联合阿里巴巴外部丰盛的业态和业务需要,通过自研进一步打磨软件的性能与高可用性,最终造成三位一体的旋转飞轮。作者 | 如葑 三位一体是阿里巴巴“自研”、“开源”、“商业化”采纳的对立技术体系,心愿以开源做内核、联合阿里巴巴外部丰盛的业态和业务需要,通过自研进一步打磨软件的性能与高可用性,而后以云上商业化服务的模式,向所有用户凋谢,同时也会向开源社区继续奉献,最终造成三位一体的旋转飞轮。阿里云云原生团队所撑持的团体业务,分为三层:BaaS、Runtime、Serverless,各层以开源软件为内核,在开源内核上进行集成和扩大,经大规模生产验证后,推向商业化。 开源具备生态、凋谢的劣势,自研具备性能高、可用性强的劣势,而商业化则具备易用、平安的劣势,基于三位一体的技术体系,能够将开源、自研与商业化都有其各自的长处联合在一起,施展出最大的劣势。 云原生网关在阿里巴巴的倒退轨迹1、诞生背景云原生网关的创立,源于团体外部的“本地生存战斗”,该战斗始于“支付宝 2020 合作伙伴大会”,在此大会上支付宝发表降级为数字生存开放平台。该战斗的核心技术指标,是实现阿里巴巴业务域与蚂蚁业务域之间 RPC 间接调用,但因阿里巴巴与蚂蚁业务域网络是隔离的,即网络是不通的,很天然想到利用网关来解决此问题。 2、技术选型利用网关来解决阿里巴巴与蚂蚁跨业务域 RPC 互通问题,首先要对网关做技术选型。 置信大家也都或多或少晓得,阿里巴巴开源的反向代理程序 Tengine。Tengine 在阿里外部对立接入网关 AServer 中被应用,咱们团队过后就是负责开发运维 AServer 的,同时咱们团队也在负责阿里巴巴 Service Mesh 的落地,不论是对 Tengine 还是对 Istio + Envoy 这套架构都比拟相熟。 在选型时,尽管也调研过一些其余的软件,但思考到网关对性能、可靠性的高要求,在联合咱们本身的网关运维教训,决定看看 Tengine 与 Envoy 是否能够满足咱们的业务需要,在比照时咱们列举了四个要害要点,其比照如下: 这里提一下“为什么咱们认为配置的热更新,是十分重要的”? Tengine/Nginx 的配置更新须要 reload,reload 须要重启 worker 过程,重启时会引起流量抖动,对长连贯影响尤为显著。在网关的集群规模十分大时,更是不能随便的做 reload,这时就会引发一个矛盾点:业务向网关提交配置后,心愿能疾速验证,但受限于 reload 机制和稳定性要求,无奈满足业务疾速验证与疾速试错的诉求。 如何解决这点呢? 一是采纳两层网关,即流量网关 + 业务网关;二是实现网关原生反对配置热更新。除了比照不同计划的优劣势,咱们也调研了 Envoy 作为网关在业界的趋势,论断是目前 Envoy 作为 K8s 中的 Ingress Provider 增长最快的事实(Ingress Provider 指 K8s Ingress 标准具体实现,因 K8s Ingress 本身只是标准定义,是 K8s 下内部流量进入集群外部的网关标准定义),咱们最终抉择了 Envoy 来实现两层网关。 ...

November 10, 2021 · 2 min · jiezi

关于阿里云开发者:基于-RocketMQ-构建阿里云事件驱动引擎EventBridge

简介:阿里云事件总线 EventBridge 作为云上的事件枢纽,最外围的能力是连贯。无论是在线业务场景、IoT 场景、还是大数据场景,无论是阿里云、其余云厂商,还是公有 IDC 机房,咱们都将提供安全可靠的集成形式。作者 | 六翁 以 Kubernetes 为基础设施的云原生技术,彻底改变了咱们的开发和思维模式。事件作为云原生畛域的一等公民,曾经无处不在,是云原生架构体系松耦合、灵活性的根底。 作为 Gartner 定义的 10 大策略技术趋势之一,事件驱动架构(EDA)逐步成为支流技术架构。依据 Gartner 的预估,到 2022 年,在新型数字化商业的解决方案中,将有 6 成应用 EDA,在商业组织参加的技术栈中,EDA 有一半的占比。 本文将介绍事件、事件驱动架构、阿里云事件驱动引擎 EventBridge 及其在事件的标准化、中心化、事件驱动架构上的能力。 事件及事件驱动架构1、事件事件是曾经产生的事实,并且是不可变的。相比而言,音讯是一个服务为了另一个服务的生产或存储而生产的原始数据,音讯是能够被批改的。 事件的生产者如实地产生和投递事件,它不关怀这个事件将由谁、因何,以及怎么去解决。而音讯的生产者是晓得谁来生产的,并且晓得封装哪些因素到音讯中,以便消费者解决。 事件的 Broker 被设计为提供事实日志。事件在超时工夫后被删除,这个超时工夫是由组织或者业务定义的。而音讯的 Broker 被设计为解决各类问题的,当消费者感知到音讯后,音讯即可被删除。 <span class="lake-fontsize-1515">事件</span><span class="lake-fontsize-1515">音讯</span><span class="lake-fontsize-1515">Data</span><span class="lake-fontsize-1515">曾经产生的事实,并且不可变(Immutable)</span><span class="lake-fontsize-1515">为生产或存储而生产的原始数据</span><span class="lake-fontsize-1515">Producer/Consumer</span><span class="lake-fontsize-1515">生产者不晓得消费者是谁以及如何解决</span><span class="lake-fontsize-1515">生产者晓得消费者是谁以及如何解决</span><span class="lake-fontsize-1515">Broker</span><span class="lake-fontsize-1515">提供事实日志超时工夫后,事件被删除</span><span class="lake-fontsize-1515">解决各类问题被消费者感知后,音讯被删除</span>* 离散事件:形容状态(state)的变动 可执行的* 间断事件:形容处于怎么的状态(condition) 可剖析的 通常,事件是离散的,用于形容一个事物的状态变动,能够被执行。消费者依据离散事件所形容的状态,执行相应的动作。 事件也能够是间断数据流中的一部分,用来形容一个事物以后处于某种状态下。这些间断的事件是可剖析的,消费者能够依据这些状态的变动,剖析出某种趋势及背地的起因。 事件该当被设计为最小尺寸、最简类型、繁多目标。这里要着重介绍下 CloudEvents。CloudEvents 在 2018 年 5 月进入 CNCF 基金会的沙箱我的项目,而后只用了1年多工夫就成为 CNCF 的孵化我的项目,其倒退速度十分快。CloudEvents 将会成为云服务之间,事件通信的标准协议。同时要强调的是,CloudEvents 曾经公布了多个消息中间件的绑定标准。 CloudEvents * 2017 年 12 月 启动* 2018 年 05 月 CNCF 沙箱我的项目* 2019 年 10 月 1.0 CNCF 孵化我的项目* 2020 年 12 月 1.0.1 ## 2、事件驱动### 事件驱动架构是一种围绕着事件的生产、探测、生产,及响应的软件架构范式。为云原生利用的分布式和伸缩性,提供了根底保障。事件驱动架构人造的异步个性,使云原生利用在设计上,能够依据 DDD 实践,清晰地划分出服务间的上下文边界,优雅地实现松耦合。 ### 1) 事件的传递模式 咱们走近事件驱动,来看一下事件的传递模式。与申请驱动不同,事件驱动的两端不是直连的。 事件的传递模式蕴含如下三种。 基于队列的生产者-消费者模式。这是一种繁多接收者的模式,用于两个服务之间的事件传递。生产者服务并不关怀消费者服务如何处理事件。 基于队列的异步申请-回调模式。这种模式和申请驱动的 request-response 相似,是异步的 request-reply 或者叫 request-callback,同样用于两个服务之间的事件传递。生成者服务会关怀消费者服务随后生产的响应事件。 基于主题的发布者-订阅者模式。这是一种多对多的模式。发布者服务可能生产不同类型的事件,并将其传输给不同的主题,订阅者服务可能订阅一个或者多个主题,以实现对不同类型事件的解决。 ### 2) 事件的服务定义模式 咱们再来理解下事件的服务定义模式。 咱们曾经晓得,事件的生产者并不知道消费者是谁,因而不能像音讯那样事后定义音讯的格局。因而,在事件驱动架构中,须要一个 Schema Registry 为生产者提供序列化根据,为消费者提供反序列化根据。 Schema 相似 gRPC 中的 proto 定义。在申请驱动模式下,gRPC 的服务端和客户端会别离依据 proto 定义,生成 stub 模板代码。而后将模板代码提供给本人的下层代码调用,从而实现序列化和反序列化。 与之相似,在事件驱动模式下,消费者在获取事件后,能够依据 CloudEvents 标准协议,解析出 Schema 和 Content(通常是二进制),而后通过消费者调用 Schema Registry 服务,将 Content 反序列化为事件体。 能够看到,事件的服务定义模式,能够将事件的生产者和消费者充沛地解耦。## 3、EventBridge 通过下面的介绍,置信你曾经对事件和事件驱动的概念有了较清晰的意识。接下来我介绍下 EventBridge。 EventBridge 是为用户提供构建松耦合、分布式的事件驱动架构的 Serverless 事件总线服务。EventBridge 的事件传输和存储遵循 CloudEvents 协定。 在 EventBridge 中,事件的生产者称为事件源,传输和存储事件的介质称为事件总线,事件的消费者称为事件指标。事件由事件规定转换、匹配、聚合,并路由到事件指标。 EventBridge 连贯了事件生产和生产的两端,利用云原生基础设施的能力及 Serverless 按需生产的特点,为用户提供了低代码、松耦合、高可用的事件处理能力。用户能够以极简的投入,实现强响应能力的 EDA 云原生利用。 同时,EventBridge 基于规范的事件协定,有利于促成各类事件源的事件规范对立,使事件孤岛逐渐交融进残缺的事件生态体系之中。因而,EventBridge 正成为云原生事件驱动架构的规范范式。 那么,EventBridge 是如何联合 Serverless 实现极简的 EDA 利用的呢?在接下来的事件总线范式及利用场景中,我将会具体介绍。 # 事件总线 ## EventBridge 的一大特点是规范事件协定的管道。那么,咱们一起来看一下,阿里云事件总线 EventBridge 实现这个管道能力的各个组成部分。### ## 1、EventBridge的组成 ### 1)事件源阿里云 EventBridge 的事件源无所不包。能够是阿里云的各类云产品、阿里云第三方SaaS 服务,也能够是阿里云用户本人的服务,甚至能够是其余云厂商、边缘服务、公有机房内的服务。用户应用 CloudEvents 的 SDK,即可将事件推送到阿里云事件总线,从而实现事件上云。 ### 2)事件总线为了提供开箱即用的云产品事件处理能力,阿里云 EventBridge 为每个用户提供了租户隔离的默认事件总线。用户所应用的云产品产生的事件,会由这条事件总线传输和存储。 用户能够通过自定义事件总线对接各类事件源,将不同的数据源产生的事件对立采集、存储和响应。 ### 3)事件规定EventBridge 的事件规定的两端别离是事件总线和事件指标。用户通过配置匹配规定、转换规则等,以低代码甚至无代码的形式,实现从事件总线到事件指标的事件过滤、转换和路由。 ### 4)事件指标事件指标是事件被最终解决的中央。阿里云 EventBridge 目前曾经反对了多种事件指标,为用户带来开箱即用的体验。咱们能够为一个告警事件指定钉钉机器人,能够将一个订单事件通过 HTTP 网关传输给用户服务,也能够将事件投递给音讯服务实现事件上云。 当然,云原生的经典事件指标是由 Serverless 服务,因为 Serverless 服务充沛展示了云原生的劣势。 * Serverless 的资源是按需生产的,将弹性施展到极致* 轻量级的函数具备低提早、高可用的能力,且无运维老本* 用户编写事件处理函数的学习门槛低、开发代码量小#### ### 5)举个例子 我这里给大家展现个小例子,一起感触下 EventBridge+Serverless 实现 EDA 的轻量化。 首先咱们自定义一个事件总线,将 Kubernenets 容器服务作为事件源,将 Serverless 服务(函数计算)作为事件指标。 而后咱们为容器内的资源状态变动事件定义一个事件规定,当这类事件进入事件总线后,将被路由到函数计算服务。 最初,咱们编写并部署一个解决这类事件的函数到函数计算服务,在函数内,首先接管到 CloudEvents 标准协议的事件,通过 Schema Registry 解析事件,最初由函数本身实现事件处理——比方调用容器服务的 API,对资源进行相干操作。 从这个小例子中,咱们能够看到,EventBridge+Serverless 能够让用户以很低的老本疾速实现一个事件驱动的业务。四两拨千斤。 接下来,我将介绍两种事件驱动架构的编排模式,并给出相应的例子,抛砖引玉,心愿能激发你的脑洞,联合本身业务,失去就地取材的事件总线最佳实际。 ## 2、事件驱动架构的编排模式 #### ### 1)调停者模式 对于解决较简单的事件驱动场景,调停者模式能帮忙咱们井井有条地对事件进行拆解和剖析,并最终执行指定的动作。调停者模式由三个角色组成:内部服务、调停者、执行者。 首先,内部服务作为一个事件总线的事件源,将事件传输给事件总线。作为调停者的微服务或者函数是这个事件总线的事件指标,接管并解决来自某个事件源的事件。 调停者函数在执行过程中,会将事件处理的多个中间状态作为新的事件,传输到对应的事件总线。此时,调停者是作为这些事件总线的事件源。作为执行者的函数是这些事件总线的事件指标。这些函数从事件总线中接管并处理事件,而后产生一个回调事件并传输到相应的事件总线中。能够看出,这里调停者和执行者之间,是后面讲到的异步申请-回调模式。 调停者接管到回调事件后,执行调解逻辑,并将后果作为回调事件,通过事件总线,传输给内部服务。 ### 2)示例:智能家居接下来,我来展现一个应用调停者模式实现智能家居的例子。 在这个例子中,咱们将 IoT 设施/传感器作为外部服务,将用户的全屋零碎作为调停者,将用户在函数计算中创立的函数作为执行者。 首先,传感器产生一条"空气质量超标"事件,并将其传输到用户自定义的"空气质量"事件总线。 用户的全屋零碎接管到这个事件后,别离计算室内外空气质量,得出室外空气超标,而后将窗内外空气质量事件发送到用户自定义的"窗内外空气"事件总线,窗户管制函数作为执行者,向 IoT 服务收回关窗指令,而后传输窗户状态事件。 全屋零碎得悉窗户都已敞开后,持续依据用户定义的全屋逻辑,向新风管制、灯控等对应的事件总线发送相应的事件,以实现全屋管制。 调停者模式的示例就介绍到这儿。接下来,我来介绍管道和过滤器模式。 ### 3)管道和过滤器模式管道和过滤器模式由三个角色组成:源服务、管道函数、指标服务。 源服务产生的事件,经验多个事件总线,被相应的管道函数执行转换、过滤、聚合等操作,最终将新的事件,经事件总线传输给指标服务。 ### 4)示例:在线学习 接下来,我来展现一个应用管道和过滤器模式实现人工智能服务在线学习的例子。 咱们都晓得,AI 的衰亡源自大数据。咱们明天所应用的各类人工智能服务,背地都有一个或多个业务算法模型。这些模型通常是由算法架构+离线的、批量的大数据重复训练而成的。因为这些服务具备人造的数据相关性,因而实时产生的在线数据会对模型的改良有肯定的帮忙。 这里,咱们假设出行举荐零碎为源服务,出行模型训练服务为目标服务,两头的各个函数为管道函数。出行举荐零碎将实时的路况事件传输到实时交通事件总线。 实时交通事件总线的事件指标是两个性能不同的函数。 * 第一个函数负责实现数据荡涤和特征提取,而后生成特色事件,传输到特色事件总线。* 第二个函数负责数据标注,将原始数据打标后,生成标注数据事件,传输到标注数据事件总线。 特色数据事件总线的事件指标同样是两个性能不同的函数。这里不再冗述。 最终出行模型训练服务会依据实时数据,训练出一个新的模型。这里省去了模型回归等工业化流程细节。 # 事件核心 ## 到这里,咱们对 EventBridge 作为事件传输、存储和路由的管道能力有了肯定意识。接下来,我将介绍 EventBridge 的另一大特点,事件的中心化查问、展现、剖析能力。 如前所述,EventBridge 基于规范的事件协定 CloudEvents,正逐渐将事件孤岛对立、交融到一起,造成残缺的事件生态体系。 在这个生态体系下,事件核心将用户应用的云产品、第三方 SaaS 服务、用户服务、云下服务所产生的事件对立到一起,为用户提供全方位的事件查问、可视化和剖析能力。 * 事件核心以租户维度,为用户提供一个或者多个事件总线的查问和剖析。* 针对事件特色显明的服务或者云产品,事件核心提供了大盘和图表,不便用户实时观测。* 同时,事件核心提供了事件告警和事件卡片,实现用户以0代码的形式解决特定的事件。 事件核心让事件的价值最大化,从事件角度为用户的云原生服务提供可追踪、可度量、可观测性。 # 瞻望 ## 阿里云事件总线 EventBridge 作为云上的事件枢纽,最外围的能力是连贯。无论是在线业务场景、IoT 场景、还是大数据场景,无论是阿里云、其余云厂商,还是公有 IDC 机房,咱们都将提供安全可靠的集成形式。 将来,EventBridge 会重点倒退生态网络。云时代下这么宏大的神经中枢零碎,不是一日能够建成的,咱们须要并期待与你一起共建云原生事件驱动架构生态。 ﹀﹀﹀ 搜寻钉钉群号 31704055 退出技术交换群,可获取云原生具体解决方案材料与专家答疑。 > 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 10, 2021 · 2 min · jiezi

关于阿里云开发者:阿里云性能测试服务PTS新面貌-压测协议施压能力全新升级

简介:性能测试 PTS(Performance Testing Service)是一款阿里云 SaaS 化的性能测试工具,到当初曾经走过了 10 个年头。每年反对全团体范畴的几万次压测工作,是阿里外部双十一技术架构的"提前验证者"。作者 | 笛墨 引言性能测试 PTS(Performance Testing Service)是一款阿里云 SaaS 化的性能测试工具,从最早为了精准模仿双十一流量洪峰诞生,到当初曾经走过了 10 个年头。每年反对包含双十一在内的全团体范畴的几万次压测工作,是阿里外部双十一技术架构的"提前验证者"。 作为 SaaS 化的性能压测工具,PTS 反对按需发动压测工作,可提供百万并发、千万 TPS 流量发动能力。同时还能 100% 兼容 JMeter。提供的场景编排、API 调试、流量定制、流量录制等性能,可疾速创立业务压测脚本,通过全国上百城市笼罩各运营商节点,可精准模仿不同量级用户拜访业务零碎,帮忙业务疾速晋升零碎性能和稳定性,已广泛应用在批发、金融、在线教育等多个畛域。 明天 PTS 能力再次降级。压测协定的降级,进一步扩充了压测协定反对的范畴以及实用场景,让您无需再为不同的技术架构无奈压测懊恼;推出的低门槛的海量流量自助施压能力,让压测工具团队免去开发、运维的懊恼,点击启动压测,轻松就具备百万并发的自助压测能力;平安、无侵入的生产环境写压测的产品化能力,只需简略接入探针即可具备生产环境写压测能力,让每一个业务场景在生产环境压测时都不“落伍”,更全面精确的评估零碎性能、容量。 新公布/降级性能如下: 反对 HTTP 2 协定。反对流媒体 RTMP/HLS 协定。反对 Websocket 协定。反对 MQTT 协定。反对 SpringCloud/Dubbo 微服务协定。最大 100W 并发自助压测能力。平安、无侵入的生产环境写压测。压测反对协定降级协定作为利用零碎交换的“语言”,明天在面对多样化的场景时,不同类型零碎采纳的协定正悄悄产生扭转。HTTP 协定作为利用最为宽泛传输协定,次要传输的是文本内容,承载了过来互联网的支流流量。当咱们明天面对多样化富文本的内容时,HTTP 协定显然不再是咱们技术服务惟一的抉择了。流媒体相干协定承当了你看视频内容的搬运工角色,看视频的时候看敲下“YYDS”的跟服务端走的是 Websocket 协定,你手上戴的智能化手表、家里的智能电气,没准是通过 MQTT 协定跟云端的服务在放弃着数据同步,哪怕你还是在浏览文本内容,搬运工交换的服务协定也正从 HTTP 1.1 到 HTTP 2、到HTTP 3 等协定在产生转变。 作为技术、开发、测试人员,在面对疾速业务迭代的时候,要去了解每一个交互协定自身是个很头痛的事件。压测场景也同样相似,咱们显然无奈承受为每个零碎定制一个压测工具的老本。PTS 作为压测工具,在压测反对协定方面,为大家带来了全新降级,具体如下: 反对 HTTP 2 协定。反对流媒体 RTMP/HLS 协定。反对 Websocket 协定。反对 MQTT 协定。反对 SpringCloud/Dubbo 微服务协定。  ...

November 10, 2021 · 2 min · jiezi

关于阿里云开发者:7张图揭晓RocketMQ存储设计的精髓

简介:RocketMQ 作为一款基于磁盘存储的中间件,具备有限积压能力,并提供高吞吐、低提早的服务能力,其最外围的局部必然是它优雅的存储设计。RocketMQ 作为一款基于磁盘存储的中间件,具备有限积压能力,并提供高吞吐、低提早的服务能力,其最外围的局部必然是它优雅的存储设计。 存储概述RocketMQ 存储的文件次要包含 Commitlog 文件、ConsumeQueue 文件、Index 文件。 RocketMQ 将所有主题的音讯存储在同一个文件中,确保音讯发送时按程序写文件,尽最大能力确保音讯发送的高可用性与高吞吐量。 但消息中间件个别都是基于主题的订阅与公布模式,音讯生产时必须依照主题进行帅选音讯,显然从 Commitlog 文件中依照 topic 去筛选音讯会变得及其低效,为了进步依据主题检索音讯的效率,RocketMQ 引入了 ConsumeQueue 文件,俗成生产队列文件。 关系型数据库能够依照字段属性进行记录检索,作为一款次要面向业务开发的消息中间件,RocketMQ 也提供了基于音讯属性的检索能力,底层的外围设计理念是为 Commitlog 文件建设哈希索引,并存储在 Index 文件中。 在 RocketMQ 中程序写入到 Commitlog 文件后,ConsumeQueue 与 Index 文件都是异步构建的,其数据流向图如下: 存储文件组织形式RocketMQ 在音讯写入过程中谋求极致的磁盘程序写。所有主题的音讯全副写入一个文件,即 Commitlog 文件。所有音讯按到达程序顺次追加到文件中,音讯一旦写入,不反对批改。Commitlog 文件的具体布局如下图所示: 基于文件编程与基于内存编程有一个很大的不同是在基于内存的编程模式中咱们有现成的数据结构,例如 List、HashMap,对数据的读写十分不便,那么一条一条音讯存入文件 Commitlog 后,该如何查找呢? 正如关系型数据会为每一条数据引入一个 ID 字段,在基于文件编程的模型中,也会为一条音讯引入一个身份标记:音讯物理偏移量,即音讯存储在文件的起始地位。 正是有了物理偏移量的概念,Commitlog 的文件名命名也是极具技巧性,应用了存储在该文件的第一条音讯在整个 Commitlog 文件组中的偏移量来命名,例如第一个  Commitlog 文件为  0000000000000000000,第二个文件为 00000000001073741824,而后顺次类推。 这样做的益处是给出任意一个音讯的物理偏移量,例如音讯偏移量为 73741824,能够通过二分法进行查找,疾速定位这个文件在第一个文件中,而后用音讯的物理偏移量减去该文件的名称所失去的差值,就是在该文件中的相对地址。 Commitlog 文件的设计理念是谋求极致的音讯写,但咱们晓得音讯生产模型是基于主题的订阅机制,即一个生产组是生产特定主题的音讯。如果依据主题从 commitlog 文件中检索音讯,咱们会发现这绝不是一个好主见,只能从文件的第一条音讯逐条检索,其性能可想而知,故为了解决基于 topic 的音讯检索问题,RocketMQ 引入了 consumequeue 文件,consumequeue 的构造如下图所示。 ConsumeQueue 文件是音讯生产队列文件,是 Commitlog 文件基于 Topic 的索引文件,次要用于消费者依据 Topic 生产音讯,其组织形式为/topic/queue,同一个队列中存在多个文件。 ...

November 10, 2021 · 2 min · jiezi

关于阿里云开发者:淘宝-NPM-镜像站切换新域名啦

简介:用CNPM/淘宝源的开发者们请留神,淘宝NPM 镜像站喊你切换新域名啦。新的Web 站点:https://npmmirror.com,Registry Endpoint:https://registry.npmmirror.com。随着新的域名曾经正式启用,老 http://npm.taobao.org 和 http://registry.npm.taobao.org 域名将于 2022 年 05 月 31 日零时起进行服务。(望周知,求转发)源起淘宝 NPM 镜像站(npm.taobao.org)自 2014 年 正式对外服务,一开始只是想简略地做 NPM 的中国镜像站点,回馈国内前端社区,人不知;鬼不觉居然始终运行到当初。当年参考 Ruby Gems 淘宝镜像 的形式,跟阿里开源组织申请了 taobao.org 的二级域名,镜像站点名称也自然而然地取名为 淘宝 NPM 镜像站 (下称 CNPM)。 图片起源:https://time.graphics/line/579718 如上图,从 2014 年 CNPM 正式提供服务到明天,NPM 包从 10 万 → 178 万,CNPM 的包下载回源量从 1 亿 → 200 亿,这还只是 CDN 回源站的量,算实在下载量就更多了。 能够毫不虚心的说, CNPM 见证了国内前端蓬勃发展的这 8 年,将来咱们心愿持续陪伴中国的前端开发者继续走上来。 PS:尽管外围参与者大部分来自国内大厂,不过 CNPM 自身是一个中立的公益我的项目,日常微小的运维费用均来自社区捐献。 新的起航随着前端的蓬勃发展, NPM 包数据量和内容复杂度仍在一直地减速增长,CNPM 当年的架构曾经很难满足当今的局势。 为了提供更稳固、更平安、更符合国家法律法规要求的镜像服务,咱们往年启动了 CNPM 的优化工作: 启动新的域名。Registry 全面重构,晋升稳定性,升高同步失败率。CLI 优化,晋升装置速度,去掉软连贯等带来的兼容性问题。积淀自企业级大规模利用的应用教训手册。等等。。。应该有不少开发者曾经发现,拜访淘宝 NPM 曾经会主动 301 跳转到 npmmirror.com 新域名,这是咱们独立注册和备案的域名。 ...

November 10, 2021 · 1 min · jiezi

关于阿里云开发者:系统架构面临的三大挑战看-Kubernetes-监控如何解决

简介:随着 Kubernetes 的一直实际落地,咱们常常会遇到负载平衡、集群调度、程度扩大等问题。归根到底,这些问题背地都暴露出流量散布不均的问题。那么,咱们该如何发现资源应用,解决流量散布不均问题呢?明天,咱们就借助三个具体场景聊聊这一问题以及相应的解决方案。作者|炎寻 审核&校对:白玙 编辑&排版:雯燕 大家好,我是阿里云云原生利用平台的炎寻,很快乐能与大家持续分享 Kubernetes 监控系列公开课。前两期公开课咱们讲到了 Vol.1《通过 Kubernetes 监控摸索利用架构,发现预期外的流量》、Vol.2《如何发现 Kubernetes 中服务和工作负载的异样》。  如何应用 Kubernetes 监控的拓扑来摸索利用架构,应用产品采集的监控数据配置告警来发现服务性能问题。明天咱们将进行第三讲《应用 Kubernetes 监控发现资源应用,流量散布不平均的问题》,大家能够钉钉搜寻钉群 31588365,退出 Kubernetes 监控答疑群进行交换。  随着 Kubernetes 的一直实际落地,咱们常常会遇到越来越多问题,诸如负载平衡、集群调度、程度扩大等问题。归根到底,这些问题背地都暴露出流量散布不均的问题。那么,咱们该如何发现资源应用,解决流量散布不均问题呢?明天,咱们就借助三个具体场景聊聊这一问题以及相应的解决方案。  零碎架构面临的挑战一:负载平衡 通常来说,对于一个业务零碎,架构会有很多层,每层蕴含很多组件,比方服务接入、中间件、存储,咱们心愿每个组件的负载都是平衡的,这样性能和稳定性都是最高的,但在多语言多通信协议场景下,疾速发现以下问题具备肯定难度,比方: 应用服务器解决的申请是否平均?应用服务器对中间件服务实例的拜访流量是否平均?数据库各个分库分表实例读写流量是否平均?…咱们在理论工作实际中会遇到的典型场景就是负载不平衡,线上的流量转发策略或者流量转发组件本身有问题,导致应用服务各个实例接管到的申请量不平衡,局部实例解决的流量显著高于其余节点,导致这部分实例的性能绝对于其余实例来说显著好转,那么路由到这部分实例上的申请无奈失去及时的响应,造成零碎整体的性能和稳定性升高。 除了服务端不平均场景之外,云上用户大多应用云服务实例,在实践中会呈现应用服务各个实例解决的流量平均,但拜访云服务实例的节点呈现流量不平均,导致云服务实例整体性能和稳定性降落。通常在利用运行时整体链路梳理和特定问题节点上下游剖析时,会进入该场景。 那么,咱们如何疾速发现问题、解决问题呢? 针对这一问题,咱们能够从服务负载、申请负载这两个方面对客户端、服务端进行问题发现,判断各个组件实例服务负载和对外申请负载是否平衡。 (1)服务端负载 对于服务端负载平衡问题排查,咱们须要理解服务详情,对任意特定的 Service,Deployment,DaemonSet,StatefulSet 进行更具针对性的排查。通过 Kubernetes 监控服务详情性能,咱们能够看到 Pod 列表局部会列出后端的所有 Pod,在表格中咱们列出了每个 Pod 在抉择时间段内的申请数聚合值和申请数时序,通过对申请数一列进行排序,咱们能够分明地看到后端的流量是否平均。 (2)客户端负载对于客户端负载平衡问题排查,Kubernetes 监控提供集群拓扑性能,对于任意特定的 Service,Deployment,DaemonSet,StatefulSet,咱们都能够查看其关联的拓扑,入选定关联关系之后,点击表格化会列出所有与问题实体关联的网络拓扑,表格每一项都是应用服务节点对外申请的拓扑关系,在表格中咱们会展现每一对拓扑关系在抉择时间段内的申请数聚合值和申请数时序,通过对申请数一列进行排序,能够分明地看到特定节点作为客户端对特定的服务端拜访是否流量平均。 零碎架构面临的挑战二:集群调度在 Kubernetes 集群部署场景下,将 Pod 散发到某个节点的过程称之为调度,对于每个 Pod 来说,其调度过程蕴含了“依据过滤条件找候选节点”以及“找最好的节点”两个步骤,“依据过滤条件找候选节点”除了依据 Pod 和 node 的污点,忍耐关系来过滤节点,还有一点十分重要的就是依据资源预留的量来过滤,比方节点的 CPU 只有 1 核的预留,那么对于一个申请 2 核的 Pod 来说该节点将被过滤。“找最好的节点”除了依据 Pod 和 node 的亲和性来抉择,个别是在过滤出来的节点外面抉择最闲暇的。 ...

November 9, 2021 · 1 min · jiezi

关于阿里云开发者:基于消息队列-RocketMQ-的大型分布式应用上云最佳实践

简介:Apache RocketMQ 作为阿里巴巴开源的撑持万亿级数据洪峰的分布式消息中间件,在泛滥行业广泛应用。在选型过程中,开发者肯定会关注开源版与商业版的业务价值比照。 那么,明天就围绕着商业版本的音讯队列 RocketMQ和开源版本 RocketMQ 进行比拟,并联合实际中场景全面展现大型分布式应用的上云最佳实际。作者|绍舒 审核&校对:岁月、佳佳 编辑&排版:雯燕 前言音讯队列是分布式互联网架构的重要基础设施,在以下场景都有着重要的利用: 利用解耦削峰填谷异步告诉分布式事务大数据处理并波及互动直播、挪动互联网&物联网,IM 实时通信、Cache 同步、日志监控等多个畛域。 而本文次要围绕着商业版本的音讯队列 RocketMQ,和开源版本 RocketMQ 进行比拟,并联合一些实际中的场景来展现大型分布式应用的上云最佳实际。 外围能力商业版本音讯队列 RocketMQ 相比拟开源版本 RocketMQ 和其余竞品,次要有以下几点劣势。 开箱即用、功能丰富高性能、有限扩大能力可观测、免运维能力高 SLA 和稳定性保障 开箱即用、功能丰富音讯队列 RocketMQ 提供了定时、事务、程序等多类型音讯的反对,且反对播送、集群两种生产模式;另外在协定层面,提供 TCP/HTTP 多协定反对,还提供了 TAG/SQL 属性过滤性能,极大水平地拓宽了用户的应用场景。 高性能、有限拓展能力音讯队列 RocketMQ 禁受了阿里外围电商历年双十一洪峰的考验,反对千万级 TPS 音讯收发和亿级音讯沉积的能力,并且可能为音讯提供毫秒级端到端提早保障,另外还提供分级存储,反对海量音讯的任意保留工夫。 可观测、免运维能力音讯队列 RocketMQ 提供了一个可观测性大盘,反对细粒度数据大盘,提供了音讯全链路生命周期追踪和查问能力,对各个指标提供了相应的监控报警性能;此外,还提供了音讯回溯和死信队列性能,可能保障用户的音讯可能随时回溯生产。 高 SLA 和稳定性保障音讯队列 RocketMQ 的稳定性是咱们一贯、继续、稳固投入的重要畛域,提供了高可用部署和多正本写入性能;另外也反对同城多 AZ 容灾和异地多活。 产品剖面接下来,咱们会从以上的产品外围能力中筛选几个剖面,并且联合具体的场景和实际来做进一步的介绍。 多音讯类型反对高可用程序音讯商业版本音讯队列 RocketMQ 应用的程序音讯咱们称之为高可用程序音讯。在介绍高可用程序音讯之前,首先简要介绍下开源版本 RocketMQ 的程序音讯。 程序音讯分为两种类型,全局程序音讯和分区程序音讯。 全局程序音讯:在 RocketMQ 存储层只会调配一个分区,也就是说全局程序 Topic 的可用性跟繁多正本的可用性强相干,且不具备可扩大的能力。分区程序音讯:所有音讯依据 Sharding Key 进行分区。同一个分区内的音讯依照严格的 FIFO 程序进行公布和生产。Sharding Key 是程序音讯中用来辨别不同分区的关键字段。下图是分区程序音讯的利用场景,order ID 即为此时程序音讯的 Sharding Key。 ...

November 9, 2021 · 2 min · jiezi

关于阿里云开发者:如何在实际场景中使用异常检测阿里云Prometheus智能检测算子来了

简介:异样检测作为智能运维(AIOps)零碎中根底且重要性能,其旨在通过算法主动地发现 KPI 工夫序列数据中的异样稳定,为后续的告警、主动止损、根因剖析等提供决策依据。那么,咱们该如何在理论场景中应用异样检测呢,而异样检测又是什么,明天咱们就进行一次深刻解说。作者|梵登、白玙 审核&校对:白玙 编辑&排版:雯燕 背景异样检测作为智能运维(AIOps)零碎中根底且重要性能,其旨在通过算法主动地发现 KPI 工夫序列数据中的异样稳定,为后续的告警、主动止损、根因剖析等提供决策依据。那么,咱们该如何在理论场景中应用异样检测呢,而异样检测又是什么,明天咱们就进行一次深刻解说。 什么是异样检测?在所有开始前,咱们首先须要理解什么是异样检测。异样检测是指从工夫序列或者事件日志中,去辨认出不失常的事件、景象等。咱们这里讲的异样检测特指工夫序列的异样检测。通过对工夫序列的值大小,曲线状态等进行综合断定,能够发现曲线异样点。异样的体现个别是指工夫序列产生了不合乎预期的回升、降落或者稳定。 举例来说:某台机器的内存使用率指标始终在 40% 左右的水位稳定, 忽然飙升至 100%;某个 Redis 数据库的连接数失常程度始终在 100 数量左右, 忽然产生了大规模的上涨至 0 的景象;某个业务的在线人数在 10 万左右稳定,忽然上涨到了 5 万等等。  什么是工夫序列?工夫序列是指一组依照工夫产生先后顺序进行排列的数据点序列,通常一组工夫序列的工夫距离为一恒定值(如 1 分钟、5 分钟)。 以后开源 Prometheus 是如何做异样检测的?目前开源版本的 Prometheus 检测能力还是基于设定阈值规定形式进行,而这种依赖阈值设定的形式就引出了以下问题。 常见问题问题 1:面对数以万计的指标数量,如何疾速又正当的实现检测配置?因为不同类型指标的含意差异大,对应设定的正当阈值也不太一样。哪怕是同一种类型指标,因为业务状态不一样,往往不能用雷同阈值。因而,在配置阈值时,运维人员须要依据对应的业务状况去配置自认为正当的阈值。因为运维人员认知程度和工作教训存在差别,因而不同人员配置的阈值也存在差异。其次,很多指标没有明确正当的范畴定义,这导致很多阈值配置都是“拍脑袋”确定的,随机性比拟强。 举例来说:某在线人数指标, 必须仔细观察剖析历史指标曲线的数值散布和变化趋势,能力设置出正当的阈值。 问题 2:随着业务的演变,如何进行检测规定的保护?对于绝对稳固的业务,业务指标长期处于稳固状态,这种状况下配置的阈值能够施展比拟长时间作用。但对于时刻变动的业务, 随同业务的一直演变,指标的水位和走势也是在一直变动。这些变动很容易导致一开始设定的阈值检测,通过一段时间则不太满足检测现状。这时候则须要运维专家定期核查检测阈值是否还合乎以后检测需要,对不合理的配置进行保护与批改。因而,动态阈值形式存在着保护老本高的问题。 举例来说:某 IO 吞吐量一开始稳固在 1 万的量值左近稳定,一开始设定了检测阈值为超过 2 万则告警。但随着业务倒退,IO 吞吐量已稳固在 2.5 万左右,这时候一开始设定的阈值就导致了源源不断的告警叨扰。 问题 3:数据品质不佳如何解决?数据品质不佳体现为几种具体景象:采集提早大、数据缺失值多、数据毛刺点比拟多(反馈在曲线上则是不够平滑)。对于后面俩种, 更多的是从采集、聚合侧进行针对性优化。ARMS-Prometheus 继续在采集能力进行优化。而对于数据毛刺点很多的数据品质问题,动态阈值形式无奈无效的躲避。而在 ARMS- 托管版 Prometheus 的智能算子中, 咱们则针对多毛刺点进行了无效的辨认,保障了毛刺点不会造成有效告警, 缩小用户侧/运维侧造成叨扰。 阿里云 Prometheus 监控是怎么解决这些问题面对以上问题,阿里云 Prometheus 监控的检测配置能力除了反对原生的设定阈值检测形式,全面新增反对模板设定检测阈值形式与智能检测算子形式。 业务价值 1:高效高质量的告警配置(1)针对明确的利用场景配置检测规定,阿里云 Prometheus 监控提供成熟的告警配置模板化,用户无需人工设定阈值, 只须要抉择对应的模版即可。例如:机器指标场景下, 配置“机器指标的 cpu 使用率 >80%”的模板。模板的形式解决了配置中明确异样且业务比较稳定的利用场景痛点。 ...

November 8, 2021 · 1 min · jiezi

关于阿里云开发者:SaaS模式云原生数据仓库应用场景实践电子书重磅来袭-激活数据生产力让分析产生价值

简介:在数据成为生产因素的明天,领有充分的算力是全面挖掘和开释数据价值的先决条件。在数据成为生产因素的明天,领有充分的算力是全面挖掘和开释数据价值的先决条件。本书基于阿里巴巴自研SaaS模式云数仓MaxCompute,重点介绍搜寻、用户增长、业务增长、人群圈选、实时数据处理、半结构化数据处理、大规模数据科学分析、湖仓一体八个经典场景实际,使得企业数据资产的价值在业务倒退中得以最大化彰显。 点击下载 《SaaS模式云原生数据仓库利用场景实际》 精彩内容领先看 复制该链接到浏览器实现下载或分享: https://developer.aliyun.com/topic/download?id=8142 搜寻始终是电商行业流量起源的外围入口之一,基于传统数据库或开源引擎尽管可能搭建根底搜寻服务,但随着商品数据的增多和业务流量的增长,难免会遇到性能和成果瓶颈。另一方面,随着电商、直播、云计算等技术的一直倒退,越来越多的传统批发企业正在进行互联网云上转型,特地是受近两年疫情等因素的影响,APP、小程序曾经成为批发企业重要的业务增长起源。在此背景下,如何疾速搭建高效搜寻服务成为批发行业上云及转型的难题。 为解决这两个问题,阿里云推出基于MaxCompute和凋谢搜寻的电商、批发行业搜寻解决方案,实现商品存储、建库、搜寻、调优的搜寻开发平台。 您能够通过本书理解云原生数据仓库的经典场景案例实际, 帮您更好的基于云数据仓库来实现企业的业务价值。 阿里云开发者藏经阁 汇聚阿里巴巴技术实际精髓,涵盖云原生、物联网、大数据、AI 等技术畛域,深度分享阿里工程师实战经验,顶级技术内容一手把握。点击进入藏经阁,畅游技术陆地。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 8, 2021 · 1 min · jiezi

关于阿里云开发者:看见新力量第二期免费下载-带你走进数十位科技创业者背后的故事

简介:这是一本正在进行中的科技创业者的记录,书中波及的创业者还都奔跑在路上。然而,他们的所思所做,已足以令一些产业产生渺小而无效的变动,令数字经济时代下人们的生存变得更加智能。阿里云翻新核心作为科技创业者动摇的陪伴者,心愿可能通过记录的形式,让大家听到创业者实在的声音,看见科技翻新的力量。第一期《看见新力量》电子书公布当前,受到了创业者的宽泛关注。在过来的一段时间,咱们持续采访了数十位在科技领域耕耘的创业者,他们从阿里云主办的守业大赛的上千家参赛企业中怀才不遇,用创业者的视角带咱们走进他们的企业,理解技术与商业上的翻新,讲述他们守业路上的酸甜苦辣。他们在5G、大衰弱、区块链、汽车互联网等赛道上不断创新,从 90 后守业新兵到年过半百的守业老兵,他们都有一颗谦虚和坚韧的心田,动摇地置信通过他们的技术能够为社会带来更多的价值。 点击收费下载《看见新力量》第二期 复制该链接到浏览器实现下载或分享:https://developer.aliyun.com/topic/download?id=8172 扫码下载第二期《看见新力量》 本书适用人群:本书实用于所有对守业及科技翻新感兴趣的用户 通过本书你能够理解:创业者和企业翻新背地的故事,多视角、多纬度的价值报道,让你听到创业者的实在声音,看见科技翻新的力量。 精彩福利 福利1:阿里云翻新核心官网——翻新企业福利申领 2021双十一守业节如期而至!爆品抄底价,优惠券等你领! 还可抽取天猫超市卡、苹果电脑等大礼 守业不易,咱们陪你,立即赶往2021双十一守业节 福利2:阿里云开发者藏经阁 汇聚阿里巴巴技术实际精髓,涵盖云原生、物联网、大数据、AI 等技术畛域,深度分享阿里工程师实战经验,顶级技术内容一手把握。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 8, 2021 · 1 min · jiezi

关于阿里云开发者:Serverless-架构模式及演进

简介:Serverless 架构从应用技术上有计算,数据存储,音讯通信,咱们可从运维性,安全性,可靠性,可扩展性,老本几个角度来掂量架构的优劣。本文会介绍一些常见的业务场景,探讨如何应用 Serverless 架构来反对这些场景。Serverless 架构依照 CNCF 对 Serverless 计算的定义,Serverless 架构应该是采纳 FaaS(函数即服务)和 BaaS(后端服务)服务来解决问题的一种设计,这个定义让咱们对 Serverless 的了解略微分明了一些,然而可能也造成了一些争执。 1. 随着需要和技术的倒退,业界呈现了一些 FaaS 以外的其它状态的 Serverless 计算服务,比方 Google CloudRun,阿里云推出了面向利用的 Serverless 利用引擎服务,这些服务也提供了弹性伸缩能力和按应用计费的免费模式,具备 Serverless 服务的状态,能够说进一步扩充了 Serverless 计算的营垒。 2. 为了解决冷启动影响,FaaS 类如阿里云的函数计算和 AWS 的 Lambda 也相继推出了预留性能。 3. 另外一些基于服务器(Serverful)的后端服务也推出了 Serverless 状态产品,比方 AWS Serverless Aurora,阿里云 Serverless HBase 服务。 因而,Serverless 的界限是有些含糊,然而云服务是在 Serverless 方向上一直演进的。一个含糊的货色如何领导咱们解决业务问题呢?Serverless 有一个最基本的理念是:让用户最大化的专一业务逻辑。其它的特色如不关怀服务器,主动弹性,按应用计费等等都是为了实现这个理念而服务。Serverless 的理念能够让咱们更好地用无限的资源解决真正须要解决的问题,正是因为咱们少做了一些事件,转而让他人做这些事件,咱们才能够在业务上做的更多。 驰名的 Serverless 实践者 Ben Kehoe 这样形容 Serverless 原生心智: 1. 我的业务是什么? 2. 做这件事件能不能让我的业务超群绝伦? 3. 如果不能,我为什么要做这件事件而不是让他人来解决这个问题? 4. 在解决业务问题之前没有必要解决技术问题。 在实际 Serverless 架构时,最重要的心智不是抉择哪些风行服务和技术,攻克哪些技术难题,而是时刻铭记在心专一业务逻辑,这样更容易让咱们抉择适合的技术和服务,明确如何设计利用架构。 ...

November 5, 2021 · 1 min · jiezi

关于阿里云开发者:演进实录|不同阶段的企业如何搭建监控体系

简介:企业业务倒退越来越迅速,对 IT 的要求也愈发严苛且简单。这不仅仅体现在运维团队架构与工作流程上,也体现在工具选型与平台搭建上。 明天咱们好好聊一下工具选型与平台搭建思路与实际关键点。来看看阿里云会给出如何的最佳实际!作者|涯海 审核&校对:白玙 编辑&排版:雯燕 在陪伴泛滥企业独特经验业务上云与云上原生之后,咱们能够看到每个企业的运维监控体系搭建过程都非常艰苦。这是因为企业业务倒退迅速,对 IT 的要求也愈发严苛且简单。这不仅仅体现在运维团队架构与工作流程上,也体现在工具选型与平台搭建上。只管不同阶段不同规模的企业须要面对各种各样事实问题,但依然有些最佳实际有迹可循,明天咱们好好聊一下工具选型与平台搭建思路与实际关键点。 工具选型与平台搭建必然趋势要特地阐明的是,监控平台不是轻易下载一个开源监控工具就能够,它须要依据监控的业务特点进行整合与二次开发,以达到与理论业务状况相吻合。通过大量实际后,咱们发现企业普遍存在的监控体系需要与倒退方向: 自动识别与采集云原生带来了跨技术栈与高动静的技术架构。因而面向复杂多变的被监控环境,采集器尽可能做到对环境的自动识别,对指标的自主采集成为所有的开始。数据都无奈采集,如何监控? 数据管理能力一直强化云、容器和微服务的呈现使被监控的对象数量减少了几个数量级。当业务飞速发展,面对几亿甚至十亿级别时序数据,咱们该如何治理? 数据看板体系成为刚需随着数据量爆发式增长,传统的线图、直方图、散点图等数据展现办法很难让运维人员找到数据背地的异样或暗藏瓶颈。如何针对不同业务或者不同监控对象,找到更适合的数据看板以及展示模式,成为了每个运维人员的必修课。 中台枢纽作用随着技术飞速发展,监控零碎在整体运维零碎的中台枢纽作用越来越显著,运维监控从传统的流程驱动转变为数据驱动。如何更便捷的与其它泛滥运维子系统对接整合,也是运维团队在监控体系搭建之初须要思考的问题。 企业监控体系演进历程联合上述特点,咱们讲企业监控体系的演进历程演绎为以下阶段。 推广期:服务器数量 50~100 台之间这个阶段因为服务器数量较少、业务规模较小,因而,运维团队对监控的需要也绝对简略。可能实现根本的告诉问题、疾速定位与解决问题即可。此时的平台搭建次要是让研发、运维等同学可能逐步相熟产品应用,并通过体验和反馈,确认是否满足企业 IT 运维以及业务特色需要,这其中几个要害特点包含: (1)部署简略,有成熟的文档与服务体系,上手易用; (2)稳固运行,SLA 保障; (3)告警体系的告诉模式不必太丰盛,但确保绝对及时、可用; (4)低成本费用或收费。 基于以上需要,很多初创企业可能会抉择 Nagios,Cacti,Zabbix,Ganglia 等开源工具。热门的开源监控产品文档绝对残缺,可疾速上手且有大量企业实际可供参考。但这里存在问题就在于开源产品的性能、应用场景无奈满足随着业务场景的倒退以及业务量增长,进而呈现各种各样的问题。与此同时,高可用成为致命问题,毕竟开源社区不会时刻有志愿者帮咱们排查故障。 暴发期:服务器数量 200~1000 台之间 这个阶段因为服务器数量变多、技术架构产生了变动、组件越发丰盛,监控需要也开始变得复杂。但面对泛滥服务模块或运维零碎,咱们须要分批次有序接入,在保障稳定性的前提下,疾速上量、对立技术栈。监控零碎次要用于告警告诉,发现问题并防止同样问题再次发生。这其中具备几个要害特点: (1)监控内容汇总与分类 因为监控对象以及信息随着技术架构与业务规模扩充而增多,须要针对软硬件、业务等不同维度的数据实现全笼罩式监控。并针对不同监控用处,须要对监控进行分类汇总,比方零碎根底监控数据、网络监控数据和业务监控数据。尽可能多的监控笼罩,尽快发现重要问题,确保业务稳固运行。 (2)多种告警形式,及时无漏报 依据监控对象的重要水平、紧急水平进行分类,并通过邮件、微信、短信、电话等不同级别不同形式进行告警告诉,每个监控对应到不同责任人,确保每个告警都有人及时跟进解决。 (3)告警策略优化与信息收敛 因为须要监控的服务越来越多,告警信息数量激增,每天都可能收到上千封报警邮件。过多的告警信息就失去了精准告知的意义。如何对告警策略进行配置和优化,尽量减少不必要的告警邮件,成为策略设置的外围。  成熟期:服务器数量 1000 台以上因为业务持续增长,对服务器的需要越来越大,当服务器超过 1000 台当前,意味着外围零碎须要全副接入,并构建新的稳定性保障体系,包含监控大盘、告警告诉、应急值班等。能力确保整个业务与技术大盘的稳固。这其中,须要关注: (1)监控延时与告警滞后 当业务规模越老越大,因为组件或服务的耦合关系,很可能因为部分的细小故障导致整个业务零碎的瘫痪。因而,及时发现问题成为了所有的大前提。但如果还在抉择时开源产品,这时可能就有不小的麻烦。以 Zabbix 举例,当规模达到一定量后,有时候会呈现监控数据不能及时显示,告警延时等问题。咱们的确能够通过各种优化形式进行调整。但业务呈现问题而造成的损失并不能挽回。 (2)监控零碎本身的 SLA 当收集运维数据飞速增长,监控零碎本身的高可用也成为了重要关注点。毕竟,失去了监控零碎意味着对整个技术与业务的运行状态失去了管制。 更具性价比的解决方案:利用实时监控服务 ARMS面对上述不同阶段的痛点,ARMS 成为了最佳的解决方案。与此同时,阿里云推出 ARMS 3.0 普惠打算旨在通过更灵便的计费计划,帮忙不同类型的用户在不同应用阶段,以更正当的老本获取更高性价比的可观测体验。在 2021 年 10 月行将推出的利用监控根底版(按量计费)模式反对 0 元用:指标收费存储 3 天,调用链根底采样收费存储 1 天,性能与原有根底版保持一致,可按量付费缩短存储周期或进步链路采样。详情可参考利用监控根底版性能列表或产品计费阐明。  根据上述阶段的用户诉求,ARMS 3.0 利用监控推出了配套的灵便计费策略: ...

November 5, 2021 · 1 min · jiezi

关于阿里云开发者:治理企业数据悬河阿里云DataWorks全链路数据治理新品发布

简介:10月19日,在2021年云栖大会上,阿里云重磅公布DataWorks全链路数据治理产品体系,基于数据仓库,数据湖、湖仓一体等多种大数据架构,DataWorks帮忙企业治理外部一直上涨的“数据悬河”,开释企业的数据生产力。10月19日,在2021年云栖大会上,阿里云重磅公布DataWorks全链路数据治理产品体系,基于数据仓库,数据湖、湖仓一体等多种大数据架构,DataWorks帮忙企业治理外部一直上涨的“数据悬河”,开释企业的数据生产力。 阿里巴巴团体副总裁 阿里云智能计算平台事业部高级研究员贾扬清现场分享 “当数据量变得越来越大,单位数据的价值会变得越来越小,全链路数据治理让数据从低质低效向高质高效流动。” 阿里巴巴团体副总裁,阿里云智能计算平台事业部高级研究员贾扬清在现场示意。黄河泥沙的淤积使河床一直贬低,造成了河高于地立体的“地上悬河”,在河南开封,最高的悬河达到10米,并且河床每年都会以10厘米的速度增高,而随之而来的,两边的堤坝也在一直地增高。在企业的数字化转型中,数据量变得越来越大,机器变得越来越多,团队变得越来越大,数字化转型真的变得越来越好吗?对于企业来说,表象的凋敝不代表将来不会产生一场“洪水”。在阿里巴巴,双11曾经成为了日常,2021年大数据计算服务MaxCompute的日常数据处理的水位线曾经超过2020年双11的峰值,一直增长的数据量曾经造成了极大的老本与效率的压力。 机器的效率+人的效率\=数据的效率面对每年如此收缩的数据,阿里巴巴的解法是通过大数据+AI一体化平台的能力,让数据效率成为企业的外围指标。在机器的效率层面,MaxCompute作为离线数仓,单日数据处理量曾经达到1.7EB,然而除了数据量,更应该关注的是MaxCompute仅用10%的机器增长,就撑持了75%的数据量增长。这外面是MaxCompute在底层的存储和性能一直地谋求极致的优化,并且间断5年突破TPCx-BigBench 100TB规模性能世界记录。同时Hologres作为实时数仓,峰值每秒写入5.96亿条,单表存储高达2.5PB,基于万亿级数据对外提供多维分析和服务,99.99%的查问能够在80ms以内返回后果。Hologres与MaxCompute组成离线、实时、剖析、服务一体化的数据仓库,从底层就极大地简化了大数据架构的复杂度。机器层面的效率往往容易被掂量,然而人的效率却很难被量化。DataWorks从2009年开始成为阿里巴巴团体对立的大数据开发治理平台,实现阿里巴巴数据中台的搭建。对一个平台的欠缺性与易用性,用户往往会用脚投票。目前在DataWorks上构建的大规模协同数据中台的每日沉闷用户数曾经超过5万,均匀每3个阿里巴巴员工就有1个在应用DataWorks,服务阿里巴巴外部简直所有部门,积淀的全链路数据治理外围能力超过数百项。FY2020,阿里巴巴通过数据治理的综合收益超过10亿元,能够说大数据开发治理平台DataWorks与计算引擎MaxCompute、Hologres组成了大数据架构下的“Wintel联盟”,共同提高企业数据的效率。 建设教训:从小作坊到大平台到麻利制作数据治理也好、数据中台也好,素来也不是一个从象牙塔里想进去的产品,而是通过很多年磨进去的。阿里巴巴的数字化转型也经验过刀耕火种的年代,每个业务团队保护多套Hadoop集群,像一个个小作坊:有什么用什么,须要什么加什么,各种技术组件像搭积木一样逐步堆砌起来。而在这个过程中,常常会十分苦楚,平台公布了一个新的性能,不晓得什么起因把另一个组件搞挂了,而后技术人员花很长时间去排查另一个组件有什么问题,修复了一个组件,公布了一下,又把另一个搞挂了,问题一直冒出就像“按下葫芦浮起瓢”,如同永远没有止境。于是,阿里巴巴开始轰轰烈烈的平台对立打算,搭建起了大平台,把开源的架构改成自研的架构,数据逐步都迁徙到MaxCompute上。这个时候数据中台的概念也开始在团体内推广,逐步将3个ONE的数据中台方法论落地到DataWorks,实现了阿里巴巴整个数据中台的搭建。至此,从外围的电商天猫淘宝,到饿了么、优酷、盒马等各个业务团队都在同一套大平台上进行一站式的协同数据开发。然而随着大平台的遍及,应用的人数越来越多,数据的治理也会越变得更加简单。在一直产生成千上万张表中,企业无奈晓得有多少条不标准的语句像白蚁一样正在耗费大量的计算资源;有多少张表正在反复地被复制,制作表象的“数据凋敝”;有多少脏数据在一直生产净化数据的品质;有多少张表正在被一直申请权限应用,面临数据安全的危险。这些问题都对大平台提出了严厉的挑战。于是,大平台逐步往麻利制作一直演进,通过全链路的数据治理能力,以全局的视角进行管控,并同时实现数据的决策的下放。 DataWorks全链路数据治理新品公布2021云栖大会全链路数据治理峰会,DataWorks在十二年积攒的数百项数据开发治理能力之上,重磅公布全链路数据治理系列新品。 数据治理核心数据治理对于企业的大数据团队,不单是一个技术问题,更是组织和治理问题。对于整个组织来说,如何来掂量数据治理最终的成果?如何更好地施展组织的主动性?在一些企业当中,会成立了专门的数据委员会,制订一些数据治理的标准,然而发现平台并不能很好地反对这些标准,又或者说企业购买了一个数据平台,然而却不晓得如何通过平台来实现数据治理的工作。在阿里巴巴外部常常会参考一个衰弱分的概念,从组织设计上,数据委员会上面有平台团队,业务团队,以及风控、财务等协同团队。那对于某个业务团队来说,会制订一个往年的指标比如说把衰弱分从80分晋升为90分,从计算、存储等方面动手,不单从业务侧、生产侧发展治理优化工作,有需要也会提给数据平台团队,对引擎和数据平台产品进行优化演进,大家一起朝这个指标致力。组织有了可测量的形式,这些部门就能够把这些数字放到本人的指标里去。同时各类的数据治理战斗,各个团队的比武等等长效的经营工作,也能够通过衰弱分做一直地延展,达到组织数据协同的目标,施展数据治理组织的主动性。 DataWorks全新公布的数据治理核心,针对企业计算、存储、研发、品质、平安五个方面造成企业数据治理衰弱分,以问题驱动的理念,笼罩事先、事中、预先的全链路主动式数据治理和数据治理衰弱度评估。企业的数据治理不再一个 “阶段性我的项目”,而是一个“可继续的经营我的项目”。 智能数据建模企业建了一个平台,做了很多标准治理,对于业务人员的价值到底是什么?省了多少老本,治理了多少问题,对于业务人员绝对是无感的。业务方只心愿更快地拿到想要的数据,于是原先的数据仓库建设形式更多的是自底向上小步快跑,疾速满足需要为先。而现在的全链路数据治理,让数据仓库的建设向规范化,可继续倒退方向演进,强调面向业务视角自顶向下进行标准建模与面向开发视角自底向上构建数仓并行不悖。 DataWorks全新公布智能数据建模,积淀阿里巴巴数据中台建设方法论,从数仓布局、数据规范、维度建模、数据指标四个方面,以业务视角对业务的数据业务进行诠释。智能数据建模反对疾速数据建模,蕴含正向建模与逆向建模,提供分钟级的模型创立能力。同时买通数据开发,能够间接将数据模型公布到多个引擎,一键生成品质规定,间接公布表并主动生成ETL简代码。企业的业务人员能够不便地理解数据全貌,疾速获取所需的数据指标以及基于数据模型进行数据分析和探查,企业内所有的员⼯能够实现“数同⽂”的疾速了解与流通,让数据决策能够实现真正无效的下放! 盒马鲜生通过DataWorks智能数据建模落地新批发行业数据模型Rex-LDM 同时,现场还公布了DataWorks数据集成实时同步能力、智能数据查问、隐衷平安计算、DataWorks开放平台、数据作业迁云工具与迁云专家服务等多项性能。 中国信通院在2021年9月公布的《寰球数字经济白皮书》报道,去年我国的数字经济规模曾经达到5.4万亿美元,占比GDP近1/3。在数字经济时代,数据曾经成为要害生产因素,就像在农业经济时代和工业经济时代中,土地、劳动力是要害的生产因素。DataWorks通过智能数据建模、全域数据集成、高效数据生产、被动数据管理、全面数据安全、疾速数据服务六大全链路数据治理的能力,承载千行百业数字化转型的可能。目前,DataWorks曾经在数字政府、新金融、新批发、能源、工业、交通、游戏、教育、数字营销等行业落地数千家客户。 国家电网大数据中心通过DataWorks实现总部+27家省(市)公司PB级数据的对立治理,通过全链路数据中台的治理与监测经营体系,放慢电网整体数字化转型降级。 创梦天地基于开源的EMR引擎,用DataWorks替换自研调度零碎,企业外部的技术人员能够更加专一业务,助力游戏行业的数据化经营。 亿滋中国通过DataWorks智能数据建模进行全链路的数据模型治理,极大晋升数据中台的自服务能⼒,让企业数据决策实现下放,开释新批发的数字化力量。 企业数字化转型正在进入的深水区,“数据悬河”将逐步成为企业的“达摩克斯之剑”,阿里云正在与各行各业的客户与合作伙伴一起,通过全链路数据治理,管得好数据、用得好数据,让数据向先进生产力会聚! DataWorks产品官网:https://www.aliyun.com/product/bigdata/ide 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 5, 2021 · 1 min · jiezi

关于阿里云开发者:双-11云服务器1核2G低至43元年更有千元大奖等你来赢

简介:阿里云云服务器ECS双11爆款清单, 20余款热门型号服务器 ECS等你来选,更有无影云电脑爆品9.9元特卖~ 这个双11  ⛅阿里云 · 必须 · 加足马力 共享型服务器 ECS 计算型服务器 ECS 通用型服务器 ECS 内存型服务器 ECS GPU 云服务器 轻量利用服务器 突发性能实例 无影云桌面 ......  20余款热门型号服务器 ECS 任你选 ! 门户网站 企业应用 办公零碎 小程序满足集体、企业多样化的上云需要 通通 打 “骨” 折! .png") 无影云桌面爆品特卖 双11爆款9.9元起 新老用户同享 无影硬件终端特卖8折起 挑战全年最低价 怎么参加?戳下图 ↓↓↓ .png") 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 5, 2021 · 1 min · jiezi

关于阿里云开发者:AIoT原生技术带来更好的应用开发

简介:共论云原生!在10月22日举办的云栖AIoT原生技术与实际峰会上,来自阿里云IoT与机械九院等机构的专家们,分享了如何利用AIoT原生技术带来更好的利用开发,让垂直行业的开发者不再放心基础设施的问题,分心做好产品翻新。 阿里云IoT技术总监胡俊锋分享了阿里云在物联网原生技术方面的思考和动作,并就阿里云IoT推出的Cloud AIoT Native架构进行全面解读。他指出当下市场曾经无奈满足对于物联网设施智能化的需要,因而须要有一套工具来升高设施网联智能化的门槛。Cloud AIoT Native是阿里云IoT面向物联网智能设施翻新推出的一套技术架构和产品矩阵,并基于此架构在设施端、边缘计算、物联网云平台、利用开发、平安防护等方面公布了一系列的次要工具平台和服务。如IoT Studio,阿里云物联网平台,IoT平安核心等,帮忙开发者高效便捷进行智能硬件开发,为整个物联网设施的开发和运行环境提供最高等级的平安保障。此外,还向大家介绍了Cloud AIoT Native的最佳实际,如,反对语音交互、在线云狗、实时路况播报,帮忙客户疾速实现智能化降级的同时,也为客户提供了后向经营能力的4G联网智能行车记录仪。能够做到疾速唤醒0.5s出图,比个别linux版本出图快了3~5s的低功耗摄像头等。 阿里云智能IoT事业部技术总监王进在“Cloud AIoT Native设施管理系统降级的关键技术解读”演讲中提出,自建设施管理系统往往面临诸多的技术挑战,例如投入高产出低、平安危险高、稳定性保障难、数据不足结构化以及寰球部署等。他示意为了帮忙企业解决这些通用的技术挑战,阿里云基于Cloud AIoT Native云端一体架构,研发了阿里云物联网平台,并分模块介绍了物联网平台外围劣势:反对多种支流语言且可灵便裁剪的LinkSDK,高牢靠高平安的连贯平台、反对海量并发的音讯散发平台、以及丰盛的智能运维AIOPS服务等。在它们的协同作用下,能够为企业用户提供一个高牢靠、高平安、低成本、低时延的设施管理系统,让企业专一于本人外围业务的研发。 阿里云IoT技术总监龙一民示意物联网正在逐步笼罩生产生存中的每一个角落,其中视频视觉与边缘计算贯通始终。阿里云提供的LinkVisual智能视频产品,在视频视觉和边缘计算两个畛域同时推动智能化过程:面向视频视觉场景,LinkVisual具备海量接入、传输体验好、智能加持、稳固平安以及出海便捷五大特点;边缘计算场景,LinkVisual打造了高可用,高平安,高精准全笼罩,低提早,云边协同,软硬一体及一站式开发等劣势。此外,阿里云在边缘计算畛域频频发力,曾经推出了多个行业属性的边缘产品,如文旅Vlog、车辆一体机、仓储一体机等。 阿里云IoT高级技术专家毛熠璐在会上隆重公布了“HaaS2.0物联网设施云端一体开发框架”,并对它进行了技术解读。本次HaaS 2.0为了解决物联网设施碎片化问题,采纳了自研的AliOS Things弹性内核,通过轻利用的易开发,还有“一站式开发工具”HaaS Studio。他示意这个框架的核心思想是将积木式开发做到极致,重点公布性能点在于轻利用开发模式,升高开发门槛,让开发者甚至小白用户都能通过组装软、硬件积木,疾速构建出多种多样的IoT智能设施。 阿里云IoT高级技术专家刘彦玮重点解析了阿里云AIoT物联网利用开发工具IoT Studio。IoT Studio是一个企业级的物联网生产工具,有6大外围劣势:低门槛、免部署、一站式、高牢靠、可扩大、 可集成,能让物联网场景定制化变得更加简略,晋升了物联网利用开发的效率,升高了开发成本。此次公布的iot studio新增了面向物联网场景建设能力,如面向水解决、温室、供水、工业,变电站,纺织,设施运维等场景畛域建设利用模板和场景组件,并以污水处理做了举例。当初,IoT Studio用户数已冲破10万,笼罩农业、工业、修建、城市等多个场景,为企业级市场的各行各业提供物联网轻利用解决方案。 机械工业第九设计研究院股份有限公司(简称机械九院)智能事业部产品总监助理杨浩指出,数字化浪潮席卷各行各业,汽车行业转型势在必行。他示意九院和阿里云严密单干,将阿里云的技术和九院的行业常识转化为实用于工业场景的IoT产品,并且胜利利用在一汽红旗的数字工厂中,把工厂搬到虚拟空间里。利用数字化、信息化、网络化、智能化等技术手段,建设全面感知体系、数据治理体系、业务利用零碎、智能利用零碎及数字孪生零碎,使人人都是数字化工程师,进一步晋升服务效率,助力数字化转型。 数字化转型是一个继续过程,阿里云IoT团队也将持续携手更多的生态搭档,用最新的技术,最好的产品做好服务,减速企业智能化,让数字原生疾速倒退。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 5, 2021 · 1 min · jiezi

关于阿里云开发者:云栖回顾|首届阿里云云原生生态合作伙伴大会与伙伴能力融合加速企业数字创新

简介:因云而生,共创将来,咱们期待更多的生态搭档退出到云原生生态合作伙伴打算,携手阿里云,成为千行百业数字翻新背地的驱动力量。日前,以“因云而生,共创将来”为主题的首届阿里云云原生生态合作伙伴大会在杭州云栖大会期间圆满举办。本次闭门会公布了多款全新降级的云原生产品,与泛滥合作伙伴共聚一堂,探讨企业数字翻新的门路与生态单干的思考。其中,14 家生态搭档被授予云原生外围合作伙伴资质。  合作伙伴授牌典礼 会上,阿里云云原生利用平台总经理丁宇分享了云原生时代的生态倒退新势能。丁宇提到,阿里巴巴领有十五年云原生实践经验,随着云原生技术的成熟,咱们看到了更多的市场机会。去年,阿里云提出云原生合作伙伴打算,通过一年的建设,曾经获得了十分丰硕的成绩。咱们的单干理念是与搭档能力交融,共塑价值,为客户提供更残缺、更有竞争力的产品、解决方案、客户服务体系。  阿里巴巴研究员,阿里云云原生利用平台总经理 丁宇 阿里云始终以来都非常重视在生态侧的投入,云原生生态单干负责人王荣刚提到,从 2016 年第一届 ALIWARE 生态单干大会,到往年举办首届云原生生态合作伙伴大会,云原生生态倒退十分迅速,整体营收和外围搭档数量增长了数十倍,在产品和解决方案丰盛度上都有了很大的晋升。 阿里云云原生利用平台生态单干负责人 王荣刚 往年,云原生在生态政策上还是连续以往的劣势,以产品业绩返佣为外围激励措施,退出云原生合作伙伴打算,能够享受阿里云云原生提供的技术和服务反对。除此之外,阿里云会提供品牌营销、市场流动、培训赋能、人才认证等全方位的资源,助力生态搭档疾速成长。  除了公布最新的搭档激励,阿里云在云原生产品侧也进行了全新降级。阿里云云原生利用平台产品负责人李国强分享了云原生产品的演进路线,笼罩容器、音讯队列、利用 PaaS、可观测、高可用、Serverless 等产品,阿里云领有国内最丰盛的云原生产品家族,通过打造弱小的技术底座,引领云原生市场发展趋势,助力企业数字化翻新降级。 阿里云云原生利用平台产品负责人 李国强 阿里云云原生生态架构师负责人冯天豪公布了针对生态搭档的混合云激励,退出云原生合作伙伴打算且有线下我的项目输入能力的搭档都能够参加,云原生生态激励体系全面笼罩公共云、专有云、混合云。 阿里云云原生生态架构师负责人 冯天豪 搭档分享北京乘云至达销售负责人常亮分享了乘云的云原生之路。常亮提到,云原生的拓展不是一帆风顺的,新趋势要落地是最难的,然而只有你找对办法,站在客户的视角思考,带来的成果也很显著,云原生在乘云的营收奉献在一年工夫里翻了 6.5 倍。             北京乘云至达销售负责人 常亮 广州青莲科技有限公司技术负责人李廷鸿分享了青莲如何撑持传统大 B 企业数字化转型降级的教训。在李廷鸿看来,帮忙大 B 企业做云原生转型,不仅须要弱小的技术服务能力,更须要让企业高层认同云原生的理念和价值。 广州青莲科技有限公司技术负责人 李廷鸿  西方通首席架构师李志鹏介绍了云原生和西方通的单干产品 EDAS Tongweb 版。李志鹏提到,西方通是国内最早研发中间件产品的公司之一,对于云原生的倒退有本人的亲身经历与了解,抉择与阿里云单干是技术的联合,趋势的碰撞,生态的单干。 西方通首席架构师 李志鹏 数字化转型的实质是一场业务改革,须要与搭档技术共生、能力交融、市场共建、模式翻新,能力构建更加凋敝的生态,更好地服务客户,发明更大的市场空间。因云而生,共创将来,咱们期待更多的生态搭档退出到云原生生态合作伙伴打算,携手阿里云,成为千行百业数字翻新背地的驱动力量。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 4, 2021 · 1 min · jiezi

关于阿里云开发者:互动赠书-云上云下K8s多集群如何实现集群管理和安全治理的一致体验

简介:本文将次要为您介绍如何实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群统一体验的集群治理和平安治理。作者| 郝树伟(流生) 以 Kubernetes 为代表的云原生技术不仅屏蔽了各个云厂商和数据中心在基础设施上的差异性,还使得利用能够在不同的云上应用标准化的形式形容和部署运行。在此基础之上,咱们才能够低成本治理处于任何地理位置的 Kubernetes 集群。本文将次要为您介绍如何实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群统一体验的集群治理和平安治理。 ACK 注册集群平安架构要实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群统一体验的集群治理和平安治理,就必须先将其对立到同一管制立体,ACK 注册集群容许处于任何地理位置的自建 Kubernetes 集群通过公网或私网(云上云下网络买通)连贯端点接入阿里云容器服务管理系统。上面是 ACK 注册集群的架构示意图: 在 ACK 注册集群架构示意图中,次要包含以下几个组成部分: ACK 容器服务控制台。ACK 注册集群 Agent 组件:Agent 组件以 Deployment 的模式部署在自建 Kubernetes 集群中(或者其余云厂商的容器集群中),用于接管 ACK 注册集群 Stub 组件(应用 ACK 容器服务控制台或 ACK 注册集群 kubeconfig)下发的申请,并将其转发给指标集群的 Kubernetes API Server,同时接管 Kubernetes API Server的响应并将其发送回 Stub 组件。ACK 注册集群 Stub 组件:Stub组件部署的容器服务管控侧,每一个注册集群都对应一个 Stub 组件,用于代理转发 ACK 容器服务控制台或 ACK 注册集群 kubeconfig 拜访集群产生的申请,转发到 Agent 组件并接管来自 Agent 组件的响应,最终返回响应到用户端。Kubernetes API Server:指标自建 Kubernetes 集群或其余云厂商容器集群的 Kubernetes API Server。单向注册双向通信后面咱们提到,ACK 注册集群能够接入处于任何地理位置的自建 Kubernetes 集群,数据中心内自建的 Kubernetes 集群有一个特点就是通常状况下,这些自建集群处于一个受限的公有网络环境下,只能集群出公网拜访外部环境。ACK 注册集群为了解决这个问题,将 Stub/Agent 组件设计为 Agent 被动单向注册到 Stub 组件,Agent 连贯 Stub 时,会带上事后生成的 token 和证书等信息进行验证,整个通信链路采纳 TLS 协定确保数据加密。 ...

November 4, 2021 · 2 min · jiezi

关于阿里云开发者:Thoughtworks-正式成为阿里云云原生核心合作伙伴携手共创数字新未来

简介:乘着放慢数字化转型的东风,Thoughtworks 将与阿里云继续推动单干,将 Thoughtworks 在金融、高科技制作、批发等行业的实际,与阿里云云原生技术以及相干产品进行深度交融,提供联结解决方案。Thoughtworks 将与阿里云携手,推动云原生技术的利用与推广,为行业数字化降级贡献力量,共创云原生数字新将来。日前,每年一度的云栖大会在杭州落下帷幕。在这场寰球规模最大的科技盛会上,Thoughtworks 作为阿里云云原生外围合作伙伴,携云原生数字畛域最新翻新与实际,与阿里云及业内重要生态企业,开展深入探讨与交换,独特勾画云计算新轮廓。  企业数字化转型不仅是本届云栖大会的热点话题,也是将来十年的重要发展趋势。随着后疫情时代的到来,数字化转型对业务的要求越来越高,这就要求企业的IT零碎必须具备高可靠性、敏捷性、高弹性以及易扩大,能够保障在业务不中断的状况下,实现对产品的迭代更新。而云原生技术架构中的很多特色,恰好能够满足这些业务需要,助力更多企业实现数字化转型。 10 家企业被授予云原生外围合作伙伴 在这场峰会上,Thoughtworks 正式成为阿里云外围合作伙伴之一,将来单方将在多方面建设深度单干。作为全球性软件及技术咨询公司,Thoughtworks 近年来始终致力于拥抱云计算以及云原生技术,以技术的提高与科技的翻新,助力各行各业改良软件开发办法,驱动企业业务倒退,进一步推动数字化转型。  正如阿里云智能云原生利用平台总经理丁宇在云原生峰会公布中提到:“从去年提出云原生合作伙伴打算,通过一年的建设,曾经获得了十分丰硕的成绩。云原生产品线销售团队服务了 160 万家,服务了 20 万生态客户,认证了 3500 名云原生专业人才。在解决方案生态上,咱们联结 150 家解决方案生态合作伙伴,共创 300 个联结计划,笼罩了 16 个次要垂直行业;在产品生态上,领有 20 家外围优良的合作伙伴,一起把产品集成、整合,输入到线下,为客户提供更残缺、更有竞争力的产品体系。笼罩了云端开发、可观测、容器、中间件、运维,包含数据类、低代码类等丰盛的产品体系。在征询和服务生态上,过来一年倒退了 60 家征询和服务合作伙伴,也为 500 家大 B 客户提供征询和交付,将来咱们心愿和生态搭档独特成长,减速企业数字化翻新降级。”  会上,Thoughtworks 中国区生态单干总监李铸示意,当今数字化转型驱动着技术和业务一直交融,不论是行业当先企业还是中小企业,都面临很多未知的时机和挑战,这意味着商业的翻新以及技术架构的重构。而云原生的微服务、容器化、继续交付和 DevOps 等技术,能够帮忙企业疾速、牢靠、继续、规模化地交付有价值的产品,疾速响应企业业务的变动。  Thoughtworks 中国区生态单干总监李铸 Thoughtworks 是一家集策略、设计和工程于一体的全球性软件及征询公司,致力于用科技驱动商业改革,客户遍布寰球汽⻋、金融保险、医疗、游览、运输、批发、电商、能源等畛域,在17个国家/地区设有 48 个办事处,领有 10000余员工,目前在中国已设立北京、上海、深圳、成都、西安、武汉及香港等 7 个办公室。作为分布式麻利的最后开拓者之一,Thoughtworks 在数据策略、人工智能、软件工程等方面有着丰盛的实践经验,以及卓越的体验设计和产品能力,在与阿里云的深度单干中,可助力解决云技术服务中的诸多挑战,减速阿里云原生技术的落地。 乘着放慢数字化转型的东风,Thoughtworks 将与阿里云继续推动单干,将 Thoughtworks 在金融、高科技制作、批发等行业的实际,与阿里云云原生技术以及相干产品进行深度交融,提供联结解决方案。Thoughtworks 将与阿里云携手,推动云原生技术的利用与推广,为行业数字化降级贡献力量,共创云原生数字新将来。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 4, 2021 · 1 min · jiezi

关于阿里云开发者:恭喜我的同事黄玉奇入选开放原子开源基金会TOC

简介:近日,凋谢原子开源基金会技术监督委员会(TOC)举办第 32 次例会。通过投票,阿里云云原生利用平台高级技术专家黄玉奇正式入选为凋谢原子开源基金会 TOC 成员。近日,凋谢原子开源基金会技术监督委员会(TOC)举办第 32 次例会。通过投票,阿里云云原生利用平台高级技术专家黄玉奇正式入选为凋谢原子开源基金会 TOC 成员。 黄玉奇,阿里云高级技术专家,Kubernetes Member,CNCF 边缘计算云原生我的项目 OpenYurt 负责人。领有丰盛的云原生、容器、分布式系统相干技术积攒, 深度参加 CloudFoundry、Mesos、Docker、Kubernetes、Istio 等云原生相干技术开源社区。领有丰盛的云原生畛域我的项目落地和商业化教训,多年来致力于继续摸索云原生技术新场景,新边界。曾主导多个大型边缘计算我的项目的云原生转型工作,目前整体负责阿里云云原生边缘计算产品。 凋谢原子开源基金会 TOC 成员 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 4, 2021 · 1 min · jiezi

关于阿里云开发者:Serverless-工程实践-自建-Apache-OpenWhisk-平台

简介:OpenWhisk 是一个开源、无服务器的云平台,能够在运行时容器中通过执行扩大的代码响应各种事件,而无须用户关怀相干的基础设施架构。OpenWhisk 简介OpenWhisk 是基于云的分布式事件驱动的编程服务。OpenWhisk 提供一种编程模型,将事件处理程序注册到云服务中,以解决各种不同的服务。其能够反对数千触发器和调用,能够对不同规模的事件进行响应。 OpenWhisk 是由许多组件构建的,这些组件让 OpenWhisk 成为一款优良的开源 FaaS 平台。 Apache OpenWhisk 组件构造 OpenWhisk 部署试验机器操作系统为 Ubuntu 18.04 Desktop。应用 GitHub 上所提供的 incubator-openwhisk 进行装置,如果本机没有装置 Git,须要先装置 Git: apt install git接下来克隆 repo 到本地目录: git clone https://github.com/apache/incubator-openwhisk.git openwhisk克隆实现之后,显示如图所示。 Apache OpenWhisk 我的项目 Clone 进入 OpenWhisk 目录,并且执行脚本。OpenWhisk 是由 Scala 开发的,运行须要装置 Java 环境。上面的脚本实现了 Java 环境的装置,以及其余的所须要的软件: cd openwhisk && cd tools/ubuntu-setup && ./all.shApache OpenWhisk 装置配置如图所示。 Apache OpenWhisk 装置配置 OpenWhisk 应用 ansible 进行部署,环境变量定义在 ansible/environments/group\_vars/all 下: ...

November 4, 2021 · 2 min · jiezi

关于阿里云开发者:最佳实践丨构建云上私有池虚拟IDC的5种方案详解

简介:云上公有池系列终篇终于来了,本文将重点介绍构建云上的公有池(虚构IDC)的多种计划和各自的优缺点,并给出相干的性价比优化倡议。本文作者:阿里云技术专家李雨前 摘要 围绕公有池(虚构IDC)的价值、获取、选购、容量布局、落地构建这几个方面,咱们以专题文章模式来一一介绍。例如从业务确定性、连续性角度介绍了公有池的价值、如何获取;接着从业务Workload特色登程,联合各种需要特色,给出相应的选购计划倡议;对公有池价值、获取、选购计划理解后,理论购买公有池的时候,须要首先晓得资源的容量,咱们介绍了云上资源容量如何布局和施行。这篇文章,咱们重点介绍构建云上的公有池(虚构IDC)的多种计划和各自的优缺点。 01 谁须要云上公有池 公有池的外围特点:资源交付确定性,保障业务连续性,专属应用,业务方灵便的资源共享等。另外,这里说的公有池是云上的资源池,与之绝对应的是自建IDC的资源池。如下图1客户服务抉择的大抵分类,在云上构建公有池适宜企业级客户。 企业级客户,如果业务的资源交付需要确定性,外围业务连续性须要保障,那么云上公有池非常适合。另外一些超级大客户,具备自建机房的实力,这些客户也举荐在云上构建公有池。起因剖析如表1 所示。 图1-客户服务抉择大抵分类 传统自建IDC 和基于云的OnCloud 构建公有池比照剖析如下表1所示。 表1-自建IDC和OnCloud比照 更多信息参考 [1] 如何建设一个idc机房? https://www.zhihu.com/question/19861355 [2] 丁常彦, 践行“双碳”指标,华为如何减速IDC产业绿色倒退? https://t.cj.sina.com.cn/articles/view/1730695047/67284f8700100sd0v [3]焦易圈, IDC——数据中心行业产业链构造及老本形成 https://www.weibo.com/ttarticle/p/show?id=2309404449364213891307 [4]2021年中国IDC行业剖析报告-市场现状与倒退商机前瞻 http://baogao.chinabaogao.com/hulianwang/547125547125.html 02 如何构建云上公有池 在分布式云的大背景下,公有池也体现分布式的特点。 如图2所示,公有池整体的布局也有多种状态。不同的客户,最终在核心、边缘、本地、现场等不同‘地位’有本人的‘公有算力’。核心、边缘的共享规模更大,本地和现场共享规模较小。 图2-公有池布局 在云平台上,目前不管核心还是边缘都有相干的产品服务,这些服务反对客户‘公有池’资源交付。例如阿里云提供了弹性保障、立刻失效容量预约、存储专属集群、云展、云盒等能够抉择的商品服务。 在计算资源这块,联合多种付费模式,能够抉择包年包月的DedicatedHost、ECS服务器包年包月、ECS服务器按量+SavingPlan组合、弹性保障+SavingPlan组合、立刻失效容量预约+SavingPlan组合等来反对构建计算资源的云公有池。上面进行逐个剖析: 一.基于DedicatedHost构建公有池 评估业务对资源的容量需要资源容量需要折算为DedicatedHost数量需要购买DedicatedHost服务器(按量或者包年包月)基于DedicatedHost 创立实例资源,例如超卖部署、自定义规格部署等这个模式简略了解:批量购买云上物理机(不须要关注物理机和机房的运维管控,以商品化、服务化、在线化API 应用物理服务器),基于这些物理机进行利用资源的自主编排服务。这些服务包含:业务负载平衡、业务负载混合部署、业务负载超卖、资源分时共享等等。 这个模式适宜大型企业,企业内有本人的资源交付、资源编排、资源管理优化团队,并实际可编程的基础设施。原来自建机房、机房供电、平安、服务器网络管理等等撑持性的工作全副交给了云平台,业务方聚焦算力资源、聚焦业务倒退,更好地反对业务迭代。业务方充分利用外部利用画像深入分析数据,构建与利用workload特色相匹配的编排、运维体系,无效、可控地晋升资源利用率,节约老本。例如XX科技团体在阿里云上购买了大量DedicatedHost,基于这些DedicatedHost 构建的云上集群,实现了自主二次调度和资源利用率晋升。 二.基于ECS服务器包年包月构建公有池 评估业务对资源的容量需要购买和业务相匹配的ECS实例规格、数量,包年包月长期持有这个模式简略了解:长期持有具体资源实例,这种资源实例不开释,从而反对业务面向具体资源实例的部署、编排。 这个模式适应性十分广,各种规模的资源需要都能够满足。同时也能够将这些具体资源交给PaaS平台,由PaaS平台进行容量化编排部署,从而实现底层包年包月资源的共享应用。这个模式要求长期持有资源,适宜业务稳固、长期倒退的场景,不适宜突发资源诉求的场景。 三.基于ECS服务器按量+SavingPlan组合构建公有池 评估业务对资源的容量需要购买和业务相匹配的ECS实例规格、数量,按量长期持有购买按量资源实例规格簇、数量匹配的SavingPlan(节俭打算)这个模式简略了解:长期持有具体资源实例,这种资源实例不开释,从而反对业务面向具体资源实例的部署、编排。 这个模式和包年包月十分相似,都是通过长期持有换取优惠的购买折扣,依附固定的保有资源构建‘公有池’。这个模式是各支流云厂商大力推广的模式。在这个模式下,解耦资源和费用,且兼具灵活性、低成本的特点。 同时,如果对资源的确定性有要求,也能够搭配立刻失效的容量预约,来保障确定性、灵活性、低成本。 四.弹性保障+SavingPlan组合构建公有池 后面构建的公有池有一个潜在的“约定”:长期保有的场景;而对于短期的资源公有、资源确定性交付的场景,弹性保障比拟适宜。 评估业务周期性法则、周期内应用时长(例如一个月内累计时长占比小于40%)针对周期性局部进行实例规格、数量评估购买弹性保障(随时开启资源实例)购买SavingPlan(可选)这个模式简略了解:在云上预订了一个公有池,在须要应用的时候开启资源,不须要的时候开释资源。预约费用一次性收取,开启资源机会用户自行管制。 这个模式匹配周期性开启的业务场景,毛病是要承当肯定的资源预约费用(一次性收取)。以后资源应用时长月占比小于40%,在保障资源确定性交付前提下,相比包年包月老本有优惠。 五.立刻失效容量预订+SavingPlan组合构建公有池 这种模式更加灵便,兼具费用优化。 评估业务对资源的需求量购买随时能够开释的立刻失效容量预约购买匹配按量资源的SavingPlan这个模式简略了解:在须要资源确定性时,从云上预订了一个公有池,不须要随时开释。只有在公有池呈现闲暇容量的时候,收取计算资源的按量费用。当容量全副用完的时候,无额定的费用开销。当呈现闲暇容量,又不须要应用的时候,能够对容量预约做缩容解决。 这个模式的最佳实际是购买SavingPlan,同时预约立刻失效容量预约,在获取费用灵活性的同时,也能够获取资源的确定性。 03 如何晋升公有池性价比 晋升公有池的性价比,实质: 购买形式上,通过长周期持有,获取绝对优惠的折扣;资源利用上,通过分时复用,晋升资源利用率。针对下面介绍的几种构建公有池形式,上面给出相应的性价比优化措施如表2所示 表2-公有池性价比优化 总结 在云上,客户须要保障本身业务服务的连续性,这就须要实现云上算力资源交付的确定性。联合多种购买模式,阿里云提供了面向不同行业、不同Workload 负责特色的‘公有池’产品服务,反对用户在资源交付与共享的灵活性、确定性、老本管制等要害因素上自主定制专属的云上公有池。 阿里云的资源保障服务汇合(弹性保障、立刻失效容量预订、包年包月实例候补购买、包年包月大规模资源报备、按量大规模资源报备、个性化资源购买计划举荐等),这些服务覆短周期、长周期、有显著法则、无显著法则、大量、大量等Workload的资源确定性交付。 ...

November 4, 2021 · 1 min · jiezi

关于阿里云开发者:媒体声音|阿里云数据库一站式全链路数据管理与服务引领云原生20时代

简介:引领云原生数据库技术继续翻新这几年,云原生已成为阿里云的另一个标签,不仅最早布局云原生技术,领有大量客户实际,更打造出丰盛的云原生产品家族。尤其是数据库产品线,已进入云原生2.0阶段,通过全链路的技术撑持能力,奔向更远的星辰大海。 云原生数据库进入2.0时代 从狭义概念来看,所谓云原生,是指全面应用云服务构建软件;而广义的云原生,是指通过容器、微服务、Serverless等全新技术构建利用,它不仅影响着计算架构、开发和部署形式,更是对整个基础设施和平台能力的一种考验。 所以,数据库的云原生之路个别从IT基础设施云化、外围场景的互联网化开始。这也是阿里云智能数据库事业部总负责人 李飞飞,在多个公开场合定义的云原生数据库1.0阶段。这一阶段的典型特色是,基于云的整个IaaS能力,晋升数据库自身的性能和服务体验。那么,云原生数据库2.0时代,产生了怎么的变动?有哪些新特点?阿里云数据库的云原生之路演进到何种水平了?阿里云数据库高级产品专家 蔡冬者 (花名:江柳),在DTCC大会期间承受IT168记者采访时,进行了具体解读。 阿里云数据库高级产品专家 蔡冬者 (花名:江柳) “1.0阶段,更强调的是单品能力,比方:如何基于MySQL打造最佳业务实际;2.0阶段,用户须要的是一个能集成多种引擎的全面的数据库解决方案,尤其在挪动互联网、IoT、5G技术趋势的加持下,数据的利用场景变得越来越丰盛,更须要一个从生产到利用的全过程产品体系。” 蔡冬者强调,阿里云云原生数据库,已过了底层基础设施和平台云化的1.0阶段,当初正向更高服务水平进军,通过全链路的技术撑持能力,引领云原生2.0时代,把数据库服务施展到极致。 全链路撑持能力背地的产品家族 在云原生数据库2.0理念下,阿里云在刚刚过来的云栖大会上公布了一系列产品的重磅更新版本,包含云原生关系型数据库 PolarDB 和分布式版本 PolarDB-X,云原生数据仓库 AnalyticDB,云原生多模数据库Lindorm、企业级自治数据库RDS,以及一站式在线数据管理平台DMS。对于PolarDB 、分布式版本 PolarDB-X,云原生数据仓库 AnalyticDB、云原生多模数据库Lindorm,业界关注度比拟高,已有大量相干材料,这里不做过多赘述,本文次要对RDS以及与之密切相关的利用DMS做重点剖析。 从大的数据库分类来看:一类是,OLTP事务型数据库;另一类是,OLAP剖析型数据库,起初又衍生出HTAP混合型事务剖析治理。阿里云RDS,就属于事务型数据库,也是整个云数据库市场规模最大、用户最多的一个根本业务。提到RDS,可能有人会感觉这是一款各家都有的“常规化产品”,应用体验都差不多。其实,绝对同类产品,阿里云RDS具备几个重要特色。 一、领有弱小的企业级数据自治能力。阿里云RDS是基于开源以及在商业化内核根底上构建的全托管式产品状态,不仅兼容了开源数据库MySQL的内核,还做了更深度的内核优化,尤其在数据库主动驾驶层面有更卓越体现。阿里云数据库的自治能力已处于行业领先地位,不论是自治的深度、引擎反对的覆盖度,还是利用规模上,其余厂商都无奈等量齐观。 二、能通过内核以及相干产品的管控能力,给用户带来更快、更稳、更平安的数据库服务。为了满足互联网利用的动静负载、高并发、永不停服等业务特色,,RDS提供一体化读写拆散、计算存储无缝扩大的解决方案,帮忙用户动静调整读写比例或存储计算资源,解决企业在读多写少状态下的扩展性问题。为了确保高可用性,阿里云提供三正本以及两地三核心的解决方案,满足游戏、电商、运营商、金融、政府类企业对数据库的利用要求。备份复原上,RDS可在分钟级实现TB级数据的疾速复原,解决企业业务故障状况下的疾速业务回滚诉求。同时,通过深度内核优化,RDS相较于开源版本性能最高可晋升80%。 三、全链路的数据安全劣势,包含拜访平安、存储平安、传输平安以及审计平安。 值得一提的是,阿里云认为真正的云数据库也能像生存中的水和电一样,只关怀下层利用,而不须要关注底层的基础设施。阿里云于2017年首次提出“数据库主动驾驶”理念,数据库自身就具备异样自感知、自诊断、自决策、自修复、自弹性及自平安的能力,齐全自闭环解决企业数据库遇到的性能、可用性以及数据可靠性等问题。以阿里巴巴团体为例,已为所有数据库开启主动驾驶能力,同时,6000家企业客户也已通过RDS实现数据库的主动驾驶。 在企业级数据库主动驾驶能力方面,阿里云在数据库智能调参ResTune零碎论文被SIGMOD2021录用,这是阿里云自治数据库和智能化运维获得的里程碑式的一步。所谓的智能调参,是指联合了机器学习以及大量专家教训和逻辑,去做对数据库影响比拟大的参数优化,从根本上帮忙企业升高参数调优门槛,满足千行百业的工作负载需要。 阿里云除了领有弱小的数据库自治能力,还有另外一款明星产品,即一站式数据管理平台DMS。DMS并不是一个从无到有、从0开始构建的产品,它最早在阿里巴巴团体外部孵化,次要解决数据库开发效率问题。之后,随着企业业务的倒退,用户也越来越关注海量数据的采集、集成及价值开掘,此时,用户开始涌现出对数据处理、加工、剖析以及利用集成等一系列需要,这须要企业要领有更弱小的平台治理能力。于是,阿里云在2021年对DMS进行了一站式降级。 阿里云DMS包含几个重要模块,包含:数据库的开发设计模块(最早开发的模块);数据集成模块(次要解决跨数据源之间的数据流动问题);数据开发加工模块;数据库的利用模块,以及横跨这些模块的数据安全及DevOps等,基本上所有的数据生产和治理能力都能够在这个平台上解决。 基于DMS,企业能够真正实现库仓一体,能够让数据流动变得简略,而且能做到实时的数据流动和集成。另外,DMS内置了弱小的数据安全能力,能够让用户从生产到利用层面领有一站式的平安能力,包含能够自定义合乎规定的平安引擎,对敏感数据进行脱敏,设置平安拜访拦挡性能等。同时,平台自身能够提供端到端的自助诊断能力,能帮忙用户疾速发现、诊断数据在流动、集成以及流转过程当中遇到的所有问题。DMS的一站式体验,还体现在笼罩的数据源比拟多,有27种常见数据源,所有数据都能实现对立治理。 所以,整体来看,阿里云云原生数据库产品家族,不仅强调全场景、全链路撑持能力,单品云原生能力也在继续演进,尤其从RDS以及DMS体现来看,正在向智能化以及平安可靠性方面降级。 交融趋势的基本是解决业务多样化需要 除了更强调智能化和安全性,其实交融型趋势也是云原生2.0时代的一种新变动。 蔡冬者认为,不论是湖仓一体化、大数据一体化,还是多模,实质上是企业数据的多样性导致计算的多样性需要起来了。这时,数据库的倒退会体现出几种演进思路。一个是专项专用,即每个引擎只解决我独特的场景问题,通过简单的技术状态组合来解决企业的多样化需要,这是一种解决思路。第二种思路,是通过一体化交融的趋势,升高企业解决问题的老本。比方:通过多样化的计算存储需要,升高数据计算存储的老本及门槛。 而云原生+分布式的联合,次要是解决指标客户群体的高并发、继续经营、动静负载及海量数据等问题。当传统的单机数据库遇到容量瓶颈,云原生+分布式演进方向显然是最佳抉择,能够帮忙用户满足互联网业务状态下的挑战。同样,软、硬件一体化,也是IT技术倒退的必经阶段,通过更深层次的软硬件联合,能够从设计之初晋升利用自身的性能、稳定性和安全性等问题。 不论是哪种交融模式,阿里云数据库会始终秉承云原生2.0指标,在底层的引擎布局上,布局全链路能力。其中,智能化、平安可控、在线一体化、多模以及与分布式联合的方向,都是单品能力持续精进的主攻方向。包含在国产化代替大背景下,会对数据库的平安要求越来越高,阿里云推出全加密数据库产品,确保政府、金融以及运营商行业用户,领有更强的数据加密能力。针对去O趋势,阿里云数据库也在做相干筹备,推出了一整套数据库降级迭代解决方案,蕴含PolarDB -O,能够实现金融级的数据库迁徙。 阿里云数据库领有丰盛的业务场景,不仅繁多数据库产品能力强,更领有全场景化的服务能力。通过多年的技术打磨和云原生化的疾速迭代,阿里云数据库产品在易用性、性价比以及稳定性方面,都领有更卓越体现,这可能是用户抉择阿里云数据库的最根本原因。换言之,产品自身的内核以及弱小的技术研发能力,是阿里云数据库获得用户信赖、建设宏大用户生态的基石。 点击查看一站式在线数据管理平台DMS更多信息 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 3, 2021 · 1 min · jiezi

关于阿里云开发者:2021云栖大会开源引力峰会重磅发布的战略合作Grafana服务到底是什么

简介:这几天关注云栖大会的小伙伴肯定会发现阿里巴巴合伙人、阿里云高级研究员蒋江伟(小邪)在云栖大会开源引力峰会的演讲中,特地提到了一个叫 Grafana 服务的产品,并特意破费一页 PPT 介绍了这一次单干。到底是一个什么样的产品值得隆重介绍?作者 | 幼麒 这几天关注云栖大会的小伙伴肯定会发现阿里巴巴合伙人、阿里云高级研究员蒋江伟(小邪)在云栖大会开源引力峰会的演讲中,特地提到了一个叫 Grafana 服务的产品,并特意破费一页 PPT 介绍了这一次单干。到底是一个什么样的产品值得隆重介绍? 那么,接下来咱们一起聊聊 Grafana 服务吧~在正式开始前,大家能够先答复一下以下问题: 你有没有沉迷在购买机器、配置网络、构建环境、装置部署、筹备域名和 IP 地址的技术陆地无法自拔?你有没有遇到过服务起不来无法访问? SLA 无奈保障? 或者过一段时间后遗记服务 IP 地址及明码找都找不回来?你有没有心愿集成 ARMS、SLS、云监控、RDS、Trace 等各云产品的数据到对立的大盘而苦于不知从何下手?你有没有心愿 Grafana 连贯专有网络 VPC 内各自建数据源业务数据,并提供邮件、短信告警以及定期报告?你有没有在命令行黑屏装置各种插件和调整配置参数? 一顿操作猛于虎,一看零碎心里堵?什么是 Grafana ?为了解决上述问题,Grafana 应运而生。Grafana 的官网是这样介绍本人的:Grafana 是开源可视化和剖析软件。它容许查问、可视化、揭示和摸索指标,无论它们存储在何处。简略地说,提供了将工夫序列数据库(TSDB)数据转换为丑陋的图形和可视化的工具。你还不晓得什么是 Grafana? 那么你肯定看到过上面相似可视化看板,它们就是配置在 Grafana 中。 为什么要做 Grafana 托管服务?Grafana 作为云原生可观测性的对立展现解决方案,可向下笼罩各类数据源和监控零碎。在阿里云上有着成千上万的用户通过本人搭建 Grafana 来实现数据的可视化展现,他们在应用 Grafana 时也要忍耐运维部署、共性设置、账号治理、阿里云数据源对接、告警等各方面不便。 正是为了解决用户在应用 Grafana 的各种痛点,咱们云原生团队与 Grafana 官网(Grafana Labs)进行了长达一年的沟通洽谈并达成单干,目前 Grafana 托管服务正在公测(申请地址详见文末)。此次单干,也是 Grafana 与亚太地区云厂商的首次深度单干,单方将在中国区提供首款 Grafana 托管服务。 详见:Grafana Labs 携手阿里云,将提供国内首款 Grafana 托管服务 在这一过程中,咱们在做了些什么?在确定零碎架构前,咱们明确作为 Grafana 托管服务产品,用户存在的泛滥诉求,这其中包含: ...

November 3, 2021 · 2 min · jiezi

关于阿里云开发者:业内首款云原生技术中台产品云原生-Stack-来了

简介:云原生 Stack 满足了各种典型场景下客户对于线下高集成平台的诉求,让企业数字话转型不受技术束缚,专一业务自身,减速企业数字化迭代。明天,企业数字化转型仍然面临很大的挑战,尽管有很多新技术不断涌现,云厂商、ISV 在帮忙企业做转型,然而在理论落地过程中,企业依然须要解决一些痛点,比方:以后,业界技术产品和理念十分繁多,怎么用新技术实现业务疾速翻新?目前的门路还不是很清晰。  其次,分布式技术复杂度高,运维老本高,业务稳定性挑战大,零碎搭建进去之后,存在稳定性不好的问题,在后续运行中也可能呈现多种问题。还有就是技术组合集成度有余,不足对立的布局和端到端统一的解决方案。  正是因为看到企业在数字化转型中面临的技术难点,阿里云公布业界首款云原生技术中台产品——云原生 Stack(简称 CNStack)。 云原生 Stack,是云原生时代的技术中台,能够线下轻量、麻利的输入。技术中台基于 ACK 麻利版,在用户的基础设施环境,轻量敏捷地享受到与 ACK一样平安、稳固的容器服务,天生具备多集群治理能力。 同时,云原生 Stack 也是业务利用平台,能够满足线下各行各业客户在数字化转型中遇到的所有技术挑战。云原生 Stack 岂但能够麻利输入,也能够规模化输入,更能够在异构 IaaS 上输入。 云原生 Stack 补齐了云原生线下能力,提供了四大外围产品状态: 第一个是云原生 Stack for Application:它是企业数字化的一站式技术底座,把 ACK 麻利版、EDAS 利用平台、利用高可用服务 AHAS、可观测 ARMS 集成在一个平台上,具备较高的集成度和统一的体验。云原生 Stack for Application 解决了开发运维一体化,减速业务迭代,内置分布式中间件,一站式满足行业利用云原生的所有诉求,并且提供了大量的解决方案,包含异地多活计划、企业互联网架构计划、业务中台计划、平安生产计划、资源混部计划等。 以阿里云资源混部解决方案为例,它能够将 IT 基础设施资源的日均匀利用率从 10% 的业界平均水平晋升到 45%,帮忙企业升高 50% 的 IT 老本。让企业数字化不受技术束缚,更轻量、更简略。 第二个状态是云原生 Stack for SaaS:以容器为代表的云原生技术带来的外围价值是:向下治理资源,向上撑持利用,程度管理软件生命周期。过来在单机时代,软件的装置治理比拟容易。然而到了云计算时代,在分布式软件、分布式环境、分布式算力的背景下,软件想要部署公布,降级保护就会变得很简单,以前行业中齐全没有这个问题的解法。 明天,阿里云开创性地提出云原生 Stack for SaaS。让 SaaS 软件的交付更简略,它屏蔽了 IaaS 的差异性,什么环境都能够部署,什么环境都能够适配,每一种硬件、芯片都能够适配。云原生 Stack for SaaS能够让部署提效 5 倍,集群测试提效 5 倍,并且升高依赖组件 90% 运维工作量。当初曾经有超过 50 家企业软件在对接、应用、落地这个产品。 ...

November 3, 2021 · 1 min · jiezi

关于阿里云开发者:阿里云IoT何云飞智物Cloud-AIoT-Native-为何能让设备智能更快一步

简介:在10月21日举办的2021云栖大会-IoT云端一体硬件与利用翻新峰会上,阿里云智能IoT产品总经理何云飞在会上做了主题为“阿里云 Cloud AIoT Native 年度降级”的演讲,旨在助力企业设施智能化减速,推动产业智联。在2021云栖大会上,阿里云智能IoT发表了“智物智造”策略,打算在三年内赋能10亿智能设施,阿里云智能IoT产品总经理何云飞全面公布了“智物 Cloud AIoT Native ”能力体系的降级。 据理解,Cloud AIoT Native智物是阿里云IoT面向“智能化环节多,技术复杂度高,生态协同难”三大需要推出的云端一体基础设施平台,包含物联网连贯、运维、智能、平安、开发5大产品能力,软件、硬件2大生态能力,全面涵盖了设施开发的整个链条,减速设施智能化上下游生态协同,让智能化翻新更简略,智万物快一步。  何云飞此次全面诠释了智物Cloud AIoT Native的全面降级,在边缘计算、物联网云平台、利用开发、平安防护等方面公布了一系列新的能力和服务,赋予智能设施更弱小的智能与平安能力。 在开发方面提供IoT平台的公共云,业余云,一体机三种状态,并面向工业、农业、政府、能源、交通、医疗、银行、家居等各行业,提供稳固、牢靠的IoT平台服务。在运维方面,C.A.N平台做了一体化集成,当初OTA近程运维能力不仅反对全量OTA,也反对差分OTA,并且把OTA的成功率提到98%以上。在连贯方面,依附阿里云云原生技术,可能让所有的数据到云上当前能够做到顺利解决,一旦发现一些单节点的站点故障时能够疾速切换,保障链接牢靠。在智能方面,AliOS Things for IPC能更快响应、更低能耗的智能视觉。HaaS UI一套利用在HaaS硬件上的轻量级触控UI解决方案,具备更低资源占用的智能触控能力。  在云栖大会上,公布了一系列的基于C.A.N平台的智能新品,包含菜鸟物流机器人AGV、智能声码服务千里传音 2.0、以及LV芯云一体解决方案。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 3, 2021 · 1 min · jiezi

关于阿里云开发者:最佳实践丨企业上云后资源容量如何规划和实施

简介:企业上云后,云上的估算间接影响上云的优先级、进度、深度。估算投入的多少,与业务倒退和资源需要的容量评估严密相干。精准的容量评估,能够使企业上云的估算布局更迷信,同时也更贴合业务倒退阶段的须要。本文分享业务上云后企业该如何进行容量的布局和施行 本文作者:阿里云技术专家李雨前 摘要 随着企业数字化转型、企业IT服务云原生化疾速倒退,客户上云的步调更加紧凑,随之而来云上的估算间接影响上云的优先级、上云的进度、上云的深度。估算投入的多少,与业务倒退无关,另外一个关键因素就是资源需要的容量评估。 精准的容量评估,能够使企业上云的估算布局更迷信,同时也更贴合业务倒退阶段的须要。本文将分享企业业务上云后,如何进行容量的布局和施行。 一、为什么要进行容量布局企业数字化转型,企业IT服务云原生化正大踏步的倒退,上云的或正在上云企业,惯例的估算收入中就蕴含数字信息化或者IT软件服务收入。这部分的估算收入,其中就蕴含云上资源的估算投入,其核算根据之一:云上容量布局和施行。 日常生活中,须要“容量”布局的场景是很广泛的。例如:水库储水就是一个典型的动静“容量”布局过程,须要依据上下游水环境状况做库容的调控。例如:疫情期间,景区履行游客提前预约胜利后购票入园的动作,须要依据防控要求做每日游客的总人数的调控。 同理,云上的业务也会动静倒退变动,云产品服务依赖的算力资源也须要相应调整。咱们把算力资源的用量布局形象为容量布局。 企业上云后进行容量布局的必要性在于,企业的业务是动静倒退的,业务依赖的云上算力资源也须要相应地动静调整。过多算力资源导致资源闲置、老本节约,过少的算力资源影响业服务响应性能、妨碍业务疾速倒退。那么,企业上云后,如果不进行容量布局会产生什么问题呢? 首先,可能呈现老本投入和业务倒退不匹配。例如,当业务出现疾速倒退的态势,业务依赖的算力资源需要也出现回升趋势,此时,如果没有容量布局,很可能业务暴发期来的时候,后端服务能力不能及时跟上,进而影响业务继续、稳固倒退,甚至错失业务的黄金倒退机会。 另外,互联网技术的利用极大地拉近了服务消费者和服务提供者的间隔,服务提供者的服务体现跨地区的高可用、稳定性已是常态化指标。针对这个指标,一种最间接的实现计划:进行地区间的容量冗余,从而在软硬件故障或者其余应急场景下,进行流量切换实现灾备。 总结起来就是:企业上云后,业务的容量布局是刚需,并且须要继续地布局。精准的容量布局,能够帮忙业务的疾速倒退,防止算力反对成为业务倒退的瓶颈、妨碍项,同时,企业业务跨地区服务的高可用、稳定性也能失去保障。 二、业务需要转化为容量布局容量布局是为业务服务的,脱离业务理论情况的容量布局毫无意义。依据业务特色、业务倒退阶段指标,制订和业务倒退相匹配的容量布局,才是正当的布局。 例如某A企业,B部门的业务须要人均一台办公电脑。目前洽购的是阿里云的云桌面产品。往年预计B部门员工数量扩充10%,那么往年云桌面台数的容量布局也须要扩充10%。这个例子比拟直观的好了解,实际上不同行业、不同业务特色的云上容量布局须要思考的因素十分多。上面按通用的了解,进行拆解剖析,如图1所示,自底向上逐渐细分。 图1-业务驱动的容量布局 因素1:业务需要的整体倒退评估     企业业务整体倒退态势和评估是所有需要起源的根基,没有业务整体倒退的充沛评估,不可能输入正当、无效的容量布局评估。对企业来说,不会为了容量布局而布局,容量布局都是为业务倒退服务的。业务整体倒退评估天然就在“金字塔”的最底部。 因素2:业务需要云原生局部的倒退评估“金字塔”底部再上一层对应云原生局部的倒退评估,云原生服务倒退的比例间接关系到云上容量布局估算的比重。对于互联网行业,可能业务的主体都是云原生的;对于传统行业,如果只有企业治理信息化局部上云,那么云原生局部的倒退评估就是很小的比重。 因素3:无限估算下,云上优先保障的需要评估对企业来说,每一项的估算总是无限的,无限的资源服务该当优先服务要害业务的倒退,从而实现投入产出比最大化的。对所有云上服务来说,存储、数据库、计算服务是根底的依赖项,个别这三块的布局和投入都是高优先级保障的。 因素4:业务云原生局部的连续性需要评估对企业来说,在业务所有的倒退阶段,业务的连续性至关重要,尤其是要害业务服务的连续性。所以,容量布局过程,须要关注、评估业务连续性在估算中的体现。例如外围业务依赖的计算资源,能够通过布局:包年包月的实例、弹性资源保障服务、资源预留服务等实现资源的确定性交付,从而保障服务的连续性。 参考资料:资源保障服务  https://help.aliyun.com/document\_detail/193626.html 因素5:业务云原生局部的地区容灾需要评估对企业来说,不同的倒退阶段,业务在地区服务的优先级可能有所偏重,那么容量布局须要感知地区。同时,服务的高可用,往往依赖地区之间服务容灾能力的建设。所以,估算须要均衡地区倒退的须要。 因素6:业务云原生局部需要独立布局VS综合布局在后面5个因素根底上,容量评估越来越具体化。接下来从因素6开始,布局须要思考具体操作的计划影响。独立布局和综合布局依赖的输出不同,输入的计划也不同。例如后面提到的面向员工办公的场景,对云桌面的需要,因为云桌面的彼此绝对独立,能够独立布局,独立交付。 例如对于大型Web服务的场景,因为依赖云数据库、云存储、流量带宽等多方面服务,所以容量评估须要整体打包评估、整体交付,防止短板效应。并且在评估具体容量多少的时候,依赖的评估工具和计划也不同。对于独立的布局,个别评估绝对容易给出;对于综合的布局,阿里云的容量布局服务提供了全套的解决方案。 参考资料:容量布局服务 https://www.aliyun.com/service/capacity\_planning 因素7:不同云服务供应商以后折扣优惠信息评估当业务容量布局细分到位后,明确了容量布局落地依赖的产品、工具,那么接下来须要感知折扣优惠信息。 不同的云服务供应商,在不同的地区、算力产品上的有相干的流动、折扣。评估这部分内容,能够使得花雷同的估算,购买到更多更实惠的算力资源。例如阿里云推出的SavingPlan + CapacityReservation 服务,实现了老本的节约和资源的确定性交付。 因素8:布局的容量交付时间表评估容量交付时间表评估这一步就是输入在什么工夫、什么地区、交付哪些算力资源、对应的估算是多少等具体的布局计划信息。过早或者过迟的交付,都可能与业务倒退不匹配,甚至容量布局最终无奈落地实施。 三、容量布局映射为资源购买量上一节咱们按分层的形式对容量布局须要思考的因素做了自底向上的形容。布局评估的实质是:满足业务在适合的工夫、地点的倒退须要,布局出对应工夫、地点的算力需要。 如图2所示,具体的需要到算力的映射办法有很多。上面假如:企业业务将来倒退所需云上服务能力是可预测的,基于可预测的值,转化为具体的资源实例购买量需要,进而造成具体的购买计划。上面介绍罕用的布局容量映射为资源购买量的技术计划。 图2- 业务需要映射算力需要 _办法一:_线性映射--程度扩缩容从资源视角来看,经典的评估办法是:资源实例总量 = 业务总的申请量QPS/ 单个资源实例反对的QPS。当业务倒退须要更多的算力时,总的QPS会发生变化,此时须要新增扩容的的资源实例数量 = 新增的QPS/单机QPS。这种形式对应资源调度畛域所说的“程度扩容”。阿里云提供的服务例如Auto Scaling 就反对主动程度扩缩容。 参考资料:弹性伸缩 https://help.aliyun.com/document\_detail/25857.html 对于程度扩容更多内容能够参考K8s的HPA(Horizontal Pod Autoscaling): https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/ _办法二:_线性映射--垂直扩缩容从资源视角来看,垂直扩容是绝对程度扩容来说的。通过调整单机资源算力大小也就是调整单机反对QPS的大小(间接通过资源实例的降配来升高单资源实例反对的QPS),来调整总的资源实例数量,从而调整总的服务申请QPS。个别在精细化资源调度、业务负载混合部署场景下,会进行资源单实例的垂直扩缩容。 这种垂直扩缩有两种状态:一种是固定式的(规格调整后就不扭转),例如从原来4VCPU,垂直缩容为2VCPU。而后实例按2VCPU 进行程度扩缩容;另外一种是非固定式的(短时间内繁多算力资源的弹性伸缩),例如资源实例在运行过程中,进行某个维度资源的“限度”,从而实现单实例资源在特定场景下算力的调整。 对于业务方来说,看到的实例规格没有扭转。典型的例如K8s的资源模型外面,如CPU资源申请,有request、limit两个参数,能够实现CPU资源的弹性burst。又例如阿里云突发性能实例,通过CPU积分来保障计算性能的实例规格,实用于平时CPU使用率低,但偶然有突发高CPU使用率的场景。 参考资料:突发性能实例 https://help.aliyun.com/document\_detail/59977.html 对于垂直扩缩容更多内容能够参考GKE的 VPA (vertical-pod-autoscaler):https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler _办法三:_非线性映射--全链路评估大型互联网服务,典型如电商交易系统,业务场景多、业务之间存在依赖性、业务服务规模大。曾经很难按利用独自评估零碎容量,须要在全链路场景压力下,进行整体的容量评估。 阿里云的容量布局服务,提供了全套服务,具体包含: 服务布局,提供业务流量剖析、数据容量剖析、音讯容量剖析、数据库容量剖析、集群容量剖析;服务布局后执行,提供全链路压测计划、场景流量配比以及调度计划、限流降级计划、演练计划。全链路评估的外围价值:帮忙客户探测云上零碎最佳压力、极限压力、毁坏压力点,并进行降级、限流爱护。采纳全链路评估尤其适宜大规模、简单的场景利用。 参考资料:容量布局服务 ...

November 3, 2021 · 1 min · jiezi

关于阿里云开发者:ESSD技术解读ESSD-Auto-PL规格引领IO性能弹性新方向

简介:阿里云 ESSD 为云服务器 ECS 提供低时延、持久性和高牢靠的块存储服务,成为云厂商全闪块存储的业界标杆。存储团队推出了 ESSD Auto PL 新的云盘规格,把性能与容量解耦,提供 IO 性能按需供应两大要害个性。AutoPL 具备的灵活性和弹性能力升高了 IT 规模布局难度和因布局不当带来的危险,本文具体介绍了Auto PL 新产品个性、揭秘背地的技术原理。前言作为 IaaS 最重要的外围组件之一,阿里云 ESSD 为云服务器 ECS 提供低时延、持久性和高牢靠的块存储服务,成为云厂商全闪块存储的业界标杆。随着越来越多的企业上云和外围利用上云,以及容器和 Serverless 架构的蓬勃发展,对块存储 IO 性能的弹性能力提出了新的挑战和需要。阿里云存储团队在这种背景下推出了 ESSD Auto PL 新的云盘规格,把性能与容量解耦,提供 IO 性能按需供应两大要害个性。本文联合块存储典型业务场景,介绍 Auto PL 新产品个性、揭秘背地的技术原理。 云存储的IO弹性需要和业务痛点随着云原生技术的倒退,越来越多的企业基于云计算的虚拟化、弹性扩大及蓬勃发展的云原生技术的分布式框架,容器技术、编排零碎、继续交付及疾速迭代,构建起大规模、弹性扩大强、丰盛的云上分布式业务场景;新的计算状态逐渐往短周期、轻量化等方向倒退,对块存储 IO 性能弹性提出了更多需要(性能通常用 IOPS :Input/Output Operations per Second 和吞吐 BPS :Bytes per Second 来形容),以下是比拟常见的业务痛点: VM/容器批量启动:计算实例启动时,系统盘短时间内耗费大量 IOPS 和吞吐 BPS业务顶峰:客户业务面临不可预期的突发场景,须要云盘以及 VM 具备短时的突发性能需求的弹性扩大能力周期性工作解决:OLAP/批处理在可预感的工夫内周期性的提交海量工作,须要云盘具备突发的弹性扩大能力传统的块存储产品采纳性能/容量耦合的产品设计,用户通过购买云盘容量获取相应的 IOPS/BPS 性能下限,通过云盘扩容同时取得磁盘容量和 IO 性能。ESSD 反对 PL0/1/2/3 多种性能的档位(PL:performance level),不同 PL 等级有不同 IO 性能下限,客户可通过云盘变配性能晋升 PL 等级,从而失去更高的 IOPS/BPS 性能下限。云原生业务充分利用云的弹性能力,业务需要上量有个较长的工夫周期,通常会预留局部存储性能余量。此外,相当局部云上业务流量存在显著的波峰波谷行为,大部分工夫处于业务低负载期,且业务高峰期和峰值难以精确预估。典型的 IO 流量突发型业务可能在肯定工夫内呈现一个或多个突发 IO 流量,突发工夫短、突发性能峰值高,常见于互联网秒杀等突发业务场景,对性能布局提出了新的挑战:如果性能配置预留过高,会造成日常资源的大量闲置节约;而如果性能预留有余,业务突发洪峰会造成业务受损。总而言之,通过云盘扩容/变配进行较为精准的性能布局变得十分艰难。 ...

November 3, 2021 · 2 min · jiezi

关于阿里云开发者:网易云音乐音视频算法的-Serverless-探索之路

简介:基于音视频算法服务化的教训,网易云音乐曲库团队与音视频算法团队一起合作,一起共建了网易云音乐音视频算法解决平台,为整个云音乐提供对立的音视频算法解决平台。本文将分享咱们如何通过 Serverless 技术去优化咱们整个音视频解决平台。作者 | 廖祥俐 网易云音乐最后的音视频技术大多都利用在曲库的数据处理上,基于音视频算法服务化的教训,云音乐曲库团队与音视频算法团队一起合作,一起共建了网易云音乐音视频算法解决平台,为整个云音乐提供对立的音视频算法解决平台。本文将分享咱们如何通过 Serverless 技术去优化咱们整个音视频解决平台。 本文将从三个局部向大家介绍: 现状:音视频技术在网易云音乐的利用状况,引入 Serverless 技术之前遇到的问题;选型:调研 Serverless 计划时的思考点;落地和瞻望:咱们进行了哪些革新,最终的落地成果和将来布局。现状作为一家以音乐为主体的公司,音视频技术被广泛应用于网易云音乐的泛滥业务场景里,为了更形象的让大家感触到,这里列举了 5 个常见的场景: 1)默认状况下,用户听到的是咱们采纳音频转码算法事后转好的标准化码率的音质,但因为流量无限或本身对于音质更高的要求,想要切换到差一些或更好的音质。 2)用户能够应用云音乐 APP 外面的听歌识曲性能去辨认环境中的音乐,这背地应用到了音频指纹提取及辨认技术。 3)在平台上的一些 VIP 歌曲,为了能给用户更好的试听体验,咱们会做副歌检测,让试听间接定位到低潮片段,这里用到了副歌检测算法。 4)在云音乐的 K 歌场景里,咱们须要对音频的音高进行展现并辅助打分,这里咱们用到了音高生成算法去欠缺K歌的根底数据。 5)为了更好的满足云音乐平台上,小语种用户的听歌体验,咱们为日语、粤语等提供了音译歌词,这里用到了主动罗马音的算法。 从下面的场景能够看到,音视频技术被广泛应用于云音乐的不同场景外面,施展了重要的作用。 从咱们的音视频技术做一个简略划分,能够分为三大类:剖析了解、加工解决、创作生产,这些一部分是以端上 SDK 的形式,在端上进行解决;而更多的局部,是通过算法工程化的形式,采纳后端集群部署治理,以服务的模式提供通用的音视频能力,而这部分是咱们明天分享的重点。 音视频算法的服务化部署工作中,须要理解很多相干音视频算法的特点,如部署环境、执行工夫、是否反对并发解决等,随着咱们落地算法的减少,咱们总结了以下法则: 1) 算法的执行工夫长:执行工夫往往与原始音频的时长成正比,云音乐很多场景下音频、视频的时长 Range 范畴是很大的,基于这个特点,咱们在执行单元的设计上,往往都采纳异步化的模式。 2)音视频算法具备多语言个性:云音乐的算法包含了 C++、Python 等语言,对接环境上下文会带来极大的困扰,为了解决这个问题,咱们采纳标准化约定及镜像交付的形式,解耦各类环境筹备的工作,所以后续对于是否反对镜像部署,会成为咱们技术选型的一个重点考查。 3)弹性的诉求正在变大:云音乐平台的歌曲,从我入职时候的 500w,到当初在线超过 6000w,增量 vs 存量的 gap 越来越大,当咱们疾速施行一个算法时,不仅要思考增量的接入,更要思考存量的疾速解决,所以在零碎设计中,会独自把执行单元的最小粒度剥离进去,便于疾速的扩容。 基于咱们对工程化的了解,及音视频算法解决的特点,云音乐的音视频解决平台的整体架构如下: 对于不同音视频算法解决的独特局部,咱们做了对立的设计,包含算法解决的可视化、监控、疾速试用和解决数据统计等,对于资源的调配也设计了对立可配置的管理模式,让整个零碎的公共局部能够尽可能形象并复用。 整个音视频算法解决平台最要害的,也是明天的分享重点,是执行单元的交互与设计。云音乐通过对立的对接规范、采纳镜像交付的形式,解决了很多对接和部署上的效率问题。针对资源的应用,因为咱们一直有新算法、存量/增量服务的存在,在上云之前,用的是外部公有云云主机申请/回收、内容容器化的形式。 为了更好的形容云音乐执行单元的运行流程,咱们将它更细化下,如下图所示: 通过音讯队列去解耦了执行单元与其余零碎的交互,在执行单元外部,咱们通过管制音讯队列的并发度去适配不同并发性能的算法,尽量管制执行单元的次要工作仅用于算法的计算,这样最终在零碎扩容的时候,咱们可能做到最小粒度的扩容。 在这个模式下,咱们落地了 60 多种音视频算法,尤其是在近一年来,服务化的算法占到了一半,这些算法向云音乐 100+的业务场景提供了服务能力。但更简单的算法、更多的业务场景,对咱们的服务化效率、运维部署和弹性能力都提出了更高的要求,在咱们上云之前,在外部曾经用到了 1000 台以上不同规格的云主机及物理机。 选型随着业务场景和算法复杂度的减少,尽管通过了很多形式去简化了外部业务场景、算法等的对接,但越来越多夹杂存量、增量解决的算法,不同流量的业务场景规模,以及不同业务场景可能会复用同一类算法的,让咱们在解决机器资源的工夫,远比咱们在开发的工夫更多。 这个也促使咱们开始去思考更多的形式办法,去解决咱们遇到的问题,最间接的有三个痛点。 第一个是存量和增量的差别变大,和新算法落地的增多,咱们花在解决存量和增量的资源协调工夫越来越多;其次是随着算法复杂度的增高,咱们在申请/洽购机器的时候,须要关注机器的整体规格、利用率等;最初是,咱们心愿存量的解决可能放慢,在解决存量的时候有足够大的资源,在海量音视频数据处理时候,可能压缩存量与增量不统一的工夫。总的来讲,咱们心愿可能有足够大规模的弹性资源,让音视频算法服务不必再多去关注机器治理。 然而,理论革新不仅仅是关注最终服务能力,还须要综合思考投入的 ROI。具体来看: 老本:蕴含两方面,革新的施行老本和计算资源的老本。前者能够联合具体计划进行评估,失去所需投入的人日,此外,革新后在将来的灵便拓展性,也是咱们须要思考的点。后者能够通过云厂商官网给出的费用计算模型,联合咱们的执行数据,估算进去。咱们在老本方面的选型要害是,在革新老本可能承受的状况下,将来的IT老本不会大额的减少。运行环境的反对:后面提到过,云音乐的运行环境比拟多样化,是以镜像交付的形式进行部署的;团队外部都有绝对欠缺的 CICD 反对,这个要求将来的降级、部署事务,例如规格配置上,是否可能简化开发人员对于机器等的关注。咱们心愿在革新后,不须要在此类事项上破费过多的工夫和精力,更多的关注算法执行自身。弹性能力:除了云厂商提供的计算资源池的规模,咱们还会关注弹性算力的启动速度,是否可能对固定场景进行实例预留,以及是否提供更合乎业务诉求的灵便弹性能力,以更好的反对业务的倒退。这些其实都合乎 Serverless 的定义,构建和运行应用程序都不须要对服务器进行治理、弹性能力出众等。综合以上的考量,咱们抉择了私有云函数计算的形式,它能直观的映射咱们目前的计算执行过程,同时也能满足后续想尝试通过 Schema 进行算法的编排。上面我会重点分享下引入函数计算 FC 的过程。 ...

November 2, 2021 · 1 min · jiezi

关于阿里云开发者:打破-Serverless-落地边界阿里云-SAE-发布-5-大新特性

简介:SAE 的5大新个性、4大最佳实际,突破了 Serverless 落地的边界,让利用容器化更快捷,让 K8s 落地更简略,让容器 + Serverless + PaaS 得以合三为一,使得技术先进性、资源利用率优化、不变的开发运维体验能够交融在一起。作者|黛忻&望宸 微服务场景,开源自建真的最快最省最稳的?复杂性真的会成为 Kubernetes 的“致命伤”吗?企业应用容器化,肯定得过 Kubernetes 这座“独木桥”吗?Serverless 利用场景繁多,多用在逻辑简略的非核心场景:小程序、ETL、定时备份等。Java 微服务真的遥遥无期了? 2021云栖大会现场,阿里巴巴研究员、阿里云智能云原生利用平台总经理丁宇(叔同)重磅公布了 Serverless 利用引擎 SAE 的产品全新定位和 5大产品新个性,给出了以上问题的答案。 从专用到通用,SAE 人造适宜企业外围业务的大规模落地区别于 FaaS 状态的 Serverless,SAE 以“利用为核心”,提供了面向利用的 UI 和 API,不扭转利用编程模型和部署形式,放弃了客户在传统服务器上统一的开发部署体验,还能不便的进行本地开发调试/监控,极大地升高了客户应用 Serverless 的门槛,能做到零革新平滑迁徙企业在线利用。 也正因为此,SAE 帮忙 Serverless 从专用到通用, 突破了 Serverless 的落地施行边界,使得 Serverless 不再是前端全栈、小程序的专宠,后盾微服务、SaaS服务、物联网利用等一样也能够构建在 Serverless 之上,人造适宜企业外围业务的大规模落地。 从简单到简略,SAE 人造适宜企业零门槛容器化区别开源自建微服务,SAE 提供了开箱即用的历经双11考验的全套微服务治理能力,客户无需思考框架选型、更无需思考数据隔离、分布式事务、熔断设计、限流降级等,也无需放心社区保护力度无限二次定制开发的问题。能做到 Spring Cloud/Dubbo 零革新无缝迁徙。开源之上,咱们还加强了无损高低线、服务鉴权、全链路灰度等高级个性。 SAE 还帮用户屏蔽了K8s 技术细节,实现企业应用零门槛容器化,无感拥抱 K8s。提供主动构建镜像的能力,除镜像外,提供 WAR/JAR/PHP zip包等多种形式,升高客户制作 Docker 镜像门槛。屏蔽 K8s 简单的网络和存储插件适配,帮每个利用的实例调配一个在VPC内互联互通的 IP,长久化数据到存储系统。屏蔽 K8s 的运维降级,再也不必放心 K8s 版本升级带来的稳定性危险。屏蔽 K8s 对接监控组件和弹性 controller,提供白屏化的端到端可观测能力和灵活多样的弹性策略配置。用户持续沿用原有打包部署形式,间接 享受 K8s 的技术红利。 ...

November 2, 2021 · 1 min · jiezi

关于阿里云开发者:Linux系统TCP内核参数优化总结

简介:Linux零碎TCP内核参数优化总结 日常运维工作中,会遇到很多TCP相干的问题,网上有很多文章介绍须要优化哪些TCP内核参数,然而并没有很具体阐明优化的根据、实用的场景是什么,如果咱们不理解各个参数理论的作用,照搬网上的配置到生产环境,很有可能会事与愿违,本文从建设连贯、数据传输、断开连接三个阶段对波及到的相干TCP内核参数做出阐明并给出优化倡议。 图1:TCP连贯状态变迁图 1. 建设连贯阶段net.ipv4.tcp\_syn\_retries 管制三次握手第一步客户端发送syn得不到服务端响应时重传syn的次数,如果是内网环境,两头链路少,网络稳固,服务端无响应很可能是服务端利用出了问题,重传屡次的意义不大,还会加大服务端压力,能够调低重传次数,让客户端尽快去尝试连贯其余服务端。net.ipv4.tcp\_syncookies 开启SYN Cookies,默认开启,倡议放弃默认值,能够晋升SYN Flood攻打的防护能力。net.ipv4.tcp\_synack\_retries 管制三次握手第二步服务端发送syn+ack得不到客户端响应时重传syn+ack的次数,如果是内网环境,两头链路少,网络稳固,客户端无响应很可能是客户端出了问题,重传屡次的意义不大,能够调低重传次数。net.ipv4.tcp\_max\_syn\_backlog 管制半连贯队列大小,所谓半连贯是指还没有实现TCP三次握手的连贯。服务端收到了客户端的SYN包后,就会把这个连贯放到半连贯队列中,而后再向客户端发送SYN+ACK,为了应答新建连接数暴增的场景,倡议调大,半连贯队列溢出察看办法:netstat -s | grep "SYNs to LISTEN"net.core.somaxconn 全连贯队列=min(somaxconn,backlog),所谓全连贯,是指服务端曾经收到客户端三次握手第三步的ACK,而后就会把这个连贯放到全连贯队列中,全连贯队列中的连贯还须要被 accept()零碎调用取走,服务端利用才能够开始解决客户端的申请,倡议适当调大,全连贯队列溢出察看办法:netstat -s | grep "listen queue"net.ipv4.tcp\_abort\_on\_overflow 当全连贯队列满了之后,新的连贯就会被抛弃掉。服务端在抛弃新连贯时,默认行为是间接抛弃不去告诉客户端,有的时候须要发送reset来告诉客户端,这样客户端就不会再次重试,至于是否须要给客户端发送reset,是由tcp\_abort\_on\_overflow参数管制,默认为0,即不发送reset给客户端,如非非凡需要,倡议放弃默认值。2. 数据传输阶段net.ipv4.tcp\_wmem tcp发送缓冲区大小,蕴含min、default、max三个值,内核会管制发送缓冲区在min-max之间动静调整,可依据理论业务场景和服务器配置适当调大,如果设置了socket的SO\_SNDBUF,动静调整性能生效,个别不倡议设置。net.core.wmem\_max socket发送缓冲区的最大值,须要设置net.core.wmem\_max的值大于等于 net.ipv4.tcp\_wmem的max值。net.ipv4.tcp\_mem 零碎中所有tcp连贯最多可耗费的内存,有三个值,当TCP总内存小于第1个值时,不须要内核进行主动调节,在第1和第2个值之间时,内核开始调节缓冲区的大小,大于第3个值时,内核不再为TCP调配新内存,此时无奈新建连贯,须要留神的是,三个值的单位都是内存页,也就是4KB。net.ipv4.tcp\_rmem tcp接收缓冲区大小,蕴含min、default、max三个值,内核会管制接收缓冲区在min-max之间动静调整,可依据理论业务场景和服务器配置适当调大,如果设置了socket的 SO\_RECVBUF或者敞开了net.ipv4.tcp\_moderate\_rcvbuf,动静调整性能生效。net.core.rmem\_max socket接收缓冲区的最大值,须要设置net.core.rmem\_max的值大于等于net.ipv4.tcp\_rmem 的max值。net.ipv4.tcp\_moderate\_rcvbuf 接收缓冲区动静调整性能,默认关上,倡议放弃默认配置。net.ipv4.tcp\_window\_scaling 裁减滑动窗口,tcp头部中,窗口字段只有2个字节,最多只能达到2的16次方,即65535字节大小的窗口,关上此开关能够裁减窗口大小,默认关上,倡议放弃默认配置。net.ipv4.tcp\_keepalive\_probes keepalive探测失败后告诉利用前的重试次数,倡议适当调低。net.ipv4.tcp\_keepalive\_intvl keepalive探测包的发送间隔时间,倡议适当调低。net.ipv4.tcp\_keepalive\_time 最初一次数据包到keepalive探测包的间隔时间,倡议适当调低。net.ipv4.tcp\_available\_congestion\_control 查看内核反对的拥塞控制算法。net.ipv4.tcp\_congestion\_control 配置拥塞控制算法,默认cubic,内核4.9版本后反对BBR,弱网络条件下倡议配置成BBR。3. 断开连接阶段net.ipv4.tcp\_fin\_timeout 是从Fin\_WAIT\_2到TIME\_WAIT的超时工夫,长时间收不到对端FIN包,大概率是对端机器有问题,不能及时调用close()敞开连贯,倡议调低,防止等待时间太长,资源开销过大。net.ipv4.tcp\_max\_tw\_buckets 零碎TIME\_WAIT连贯的最大数量,依据理论业务须要调整,超过最大值后dmesg会有报错TCP: time wait bucket table overflow。net.ipv4.tcp\_tw\_reuse 容许TIME\_WAIT状态的连贯占用的端口用到新建连贯中,客户端可开启。net.ipv4.tcp\_tw\_recycle 开启后,TIME\_WAIT状态的连贯无需期待2MSL工夫就可用于新建连贯,在NAT环境下,开启tcp\_tw\_recycle参数会触发PAWS机制导致丢包,倡议不开启,事实上,内核在4.1版本后就把这个参数删除了。咱们是阿里云智能寰球技术服务-SRE团队,咱们致力成为一个以技术为根底、面向服务、保障业务零碎高可用的工程师团队;提供业余、体系化的SRE服务,帮忙广大客户更好地应用云、基于云构建更加稳固牢靠的业务零碎,晋升业务稳定性。咱们冀望可能分享更多帮忙企业客户上云、用好云,让客户云上业务运行更加稳固牢靠的技术,您可用钉钉扫描下方二维码,退出阿里云SRE技术学院钉钉圈子,和更多云上人交换对于云平台的那些事。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 2, 2021 · 1 min · jiezi

关于阿里云开发者:最佳实践丨三种典型场景下的云上虚拟IDC私有池选购指南

简介:业务上云常态化,业务在云上资源的选购、弹性交付、自助化成为大趋势。不同行业的不同客户,业务倒退阶段不一样,云上资源的老本投入在业务整体老本占比也不一样,最小化老本投入、最大化业务收益始终是不同客户间的独特指标。阿里云面向全行业的用户提供了丰盛的云上算力产品服务和灵活多样的售卖模式,帮忙用户云上准确的资源容量预估和精密的资源交付治理,十分有利于客户节约云上购买资源的老本。本文是云上公有池系列的第二篇,将集中介绍不同场景下公有池的选购指南。 本文作者:阿里云技术专家李雨前 引言: 业务上云常态化,业务在云上资源的选购、弹性交付、自助化成为大趋势。不同行业的不同客户,业务倒退阶段不一样,云上资源的老本投入在业务整体老本占比也不一样,最小化老本投入、最大化业务收益始终是不同客户间的独特指标。 阿里云面向全行业的用户提供了丰盛的云上算力产品服务和灵活多样的售卖模式,帮忙用户云上准确的资源容量预估和精密的资源交付治理,十分有利于客户节约云上购买资源的老本。 本文是最佳实际--云上公有池系列的第二篇,在第一篇中,笔者重点介绍了公有池的价值和如何获取;本文集中介绍不同场景下公有池的选购指南。 先回顾下公有池是什么:当用户在ECS 控制台,“资源保障”服务标签页下,购买“弹性保障”或者“容量预约”等产品后,就取得了云上一个确定性计算资源(CPU和Memory)预留,并且是专属调配应用的资源池。一个公有池的服务有两个阶段:公有池预留和公有池资源交付。 公有池具备资源库存确定性、资源调度交付灵活性的价值,可能为客户业务确定性、连续性倒退保驾护航。那么,对不同的客户来说,选购最合适的公有池,能够实现资源老本和业务倒退的相匹配。 咱们晓得,云上客户来自各行各业,通过行业数字化解决方案、数字化产品服务实现产业的本身价值,背地依靠云平台提供各种算力服务。算力服务最终会反映在资源需求量的变动上。咱们将资源需求量变动特色形象为图1所示,分为日常稳定性需要、日常弹性需要、突发需要三种类型。 图1-资源需要量特色 如图1所示,资源确定性的需要集中反映在“日常弹性需要”和“突发需要”。其中,“日常弹性”需要又能够细分为“周期性的”短期资源需要和“非周期性的”短期资源需要(偶发的和非凡期间的)。总结起来,须要确定性交付的场景集中在: “周期性”的短期资源需要“偶发的”大量资源需要“非凡期间的”资源需要上面就三种场景的确定性资源选购别离做介绍。 周期性的短期资源需要如图2所示,资源需要体现出显著的周期性和规律性。这种实例数量随工夫的变动特色,比拟合乎游戏、在线教育场景资源需要。例如上班后、周末时段,实例数量上涨,平时实例数量较小。 游戏场景:XX游戏每周六固定工夫开新服,大量用户涌入并注册,资源需要激增;在线教育场景:XX在线教育公司,在线教学的课表暑期集中在固定的工夫,开课时候,产生大量的资源诉求,课程完结后资源就能够开释。 图2-周期性短期资源需要 确定性交付计划 针对周期性的短期资源需要,上面从资源实例持有工夫长短和多云平台进行分类介绍。每一种分类上面细分多种购买计划,并展现相干劣势和劣势。 计划1 长期持有 这个计划的外围是一次性、提前把周期性须要的资源购买下来。如表1所示: 表1-长期持有 计划2 短期持有 这个计划的外围是只在周期时间段内,须要资源的时候确保资源确定性交付。如表2所示: 表2-短期持有 针对周期性短期资源需要,购买“弹性保障”是须要预收取肯定费用的,相比其余的购买形式老本投入是怎么样的呢?上面做进一步剖析。 举例:假如用户有一个确定的资源需要:北京地区,实例规格ecs.g6.xlarge,1台,一个月内预计累计应用时长为12天,一个月内其余的时段资源能够开释。业务上要求:随时须要资源的时候,资源肯定是100%胜利交付进去。此时,确保资源确定性交付,用户有4种选购和对应的计费形式,如下表3所示: 表3-4种形式费用比照 形式1:“包月”的一个月,总费用1 = 该实例包月价格 * 1 形式2:”包年“的一个月, 总费用2 = 该实例包年的月均价格 * 时长(本案例月数1) 形式3:0预付RI 预留一个月, 总费用3 = 该实例一个月的RI费用 形式4:弹性保障预留一个月,总费用4 = 保障包预约费用+实例开启理论时长产生的费用(40% * 30 = 12 天,本案例1个月只有40%的工夫会应用);如果间接包月购买,那么须要领取一个月的价格。 阐明:确定规格的某个实例费用比照如下: 包年的月均价 < 包月的月价 < 按量的累计的月价 因而,在雷同配置条件下,以上四种不同的选购形式费用关系是:总费用1 > 总费用2 > 总费用3> 总费用4 这个时候,在雷同的配置下,“弹性保障+12天”开启的按量小时总成本最优。 四种形式持有工夫和老本的关系形象为图3所示: 图3-各种形式老本和时长的比拟 ...

November 2, 2021 · 1 min · jiezi

关于阿里云开发者:ESSD技术解读阿里云块存储企业级特性之异步复制

简介:在大数据时代,数据就是企业的外围资产,是企业的生命线。在事实世界中,劫难时有发生,当产生劫难时,容灾能力成为企业是否生存的要害。云上容灾服务,通常称为 DRaaS(劫难复原即服务)岂但可能省去自建容灾核心的开销,还能节俭后续运维老本,帮忙客户疾速建设起跨地区的容灾计划,即买即用,随时开释的个性也为用户提供了极大的弹性。本文介绍了云上容灾产品状态,企业可联合本身特点抉择适合的容灾计划,针对异步复制产品解析了传统容灾与云上容灾的技术架构。阿里云块存储也联合本身架构特点实现了块存储的异步复制产品。前言 数据是企业的生命线数据异地容灾是企业级客户的一个普适需要,尤其是对于政府,金融等大客户,更是外围需要。在大数据时代,数据就是企业的外围资产,是企业的生命线。在事实世界中,劫难时有发生,当产生劫难时,容灾能力成为企业是否生存的要害。 在美国“911”事件中,美国的双子大楼倒塌,数家银行的数据中心因而毁于一旦。德意志银行,因为在几十公里外做了数据备份,很快复原了业务,失去用户的好评,而纽约银行因为没有灾备计划,在数月后开张。 21 年 3 月份,法国最大数据中心运营商 OVHcloud 机房着火,超 350 万网站受到影响。 在刚刚过来的郑州 720 旱灾中,郑州大学第一从属医院河医院区受到间断暴雨影响,整个院区淹水导致停电,医院启动了异地容灾机制,仅用 15 分钟就将外围业务紧急切换至东区外围机房,保障了其余两个院区的失常运行。 云上容灾成为趋势一个个实在案例警钟长鸣,这也使得企业对数据保护,容灾的投入不断扩大。传统的容灾计划,往往须要企业自建容灾核心,购买专线,以及投入人力进行运维等,投入老本较大。在云计算疾速倒退的时代,越来越多的企业客户思考云上容灾。云上容灾服务,通常称为 DRaaS(劫难复原即服务)岂但可能省去自建容灾核心的开销,还能节俭后续运维老本,帮忙客户疾速建设起跨地区的容灾计划,即买即用,随时开释的个性也为用户提供了极大的弹性。 下表中总结了 DRaaS 与传统容灾计划的比照,能够看出 DRaaS 与传统容灾相比具备零基建、少运维、高弹性的特点,因而,在云计算疾速倒退的时代,DRaaS 也成为容灾的趋势所在。 DR as a Service传统线下DR弹性按需建设,按需开释提前布局建设费用按量计费,仅需云盘和所需带宽费用, 0 基建一次性买断阵列和网络,初期投资高容灾数据链路专用网络自行铺设专线,租用带宽最佳实际Cloud on Cloud 与云上多种组件配合,达到最优模式自行摸索 + 供应商举荐模式性能演进随私有云降级与演进购买新设施、软件、降级#### ESSD 云盘异步复制阿里云块存储 ESSD 产品是寰球当先的旗舰级产品,曾经逐步走向成熟。为了更好的服务企业客户,满足企业客户云上容灾需要,阿里云块存储也推出本人的 DRaaS 产品,云盘异步复制,实现云盘的跨地区异步复制。本文介绍了用户如何抉择适合的云上容灾产品,从技术角度解析了不同容灾架构的异同点,而后介绍针对 ESSD 架构咱们如何抉择容灾架构以及云盘异步复制背地的技术原理。## 企业如何抉择云上容灾计划#### 依据 RPO,RTO 抉择适合的容灾类型企业在抉择容灾计划时,首先应该依据本人的业务特点确定本人的容灾等级。在容灾畛域通常应用 RPO(Recovery Point Objective)来掂量一个容灾零碎最多可能失落的数据的时长,RTO(Recovery Time Objective),来掂量从劫难产生到整个零碎恢复正常所须要的最大时长。国家出台了相干规范,把容灾能力分为六个等级,如下图所示对于企业来说从一级到六级,级别越高,数据失落的危险越低,然而容灾建设的老本越高。在传统存储行业中,通常数据备份归档类产品能够满足一到二级容灾需要,一般存储阵列的备份性能能够满足三到五级需要,高端存储阵列的异步复制性能能够满足四到五级需要,而高端存储同步复制,双活性能,以及基于利用的复制能够满足五到六级需要。那么对于云上,各大云厂商也提供了丰盛的云产品来满足不同的容灾级别需要,云上灾备核心通常提供跨地区或者跨可用区的云上灾备服务,能够满足一到四级的需要,而异步复制、同步复制产品能够满足五到六级容灾需要。支流的利用,例如数据库业务通常也有本人的容灾产品,最高能够做到 IO 级别的容灾粒度。从下面的级别能够看出异步复制能够满足四到五级容灾需要,也是银行等金融客户以及政府单位等宽泛须要的。#### 依据零碎特点抉择适合的容灾服务从实现形式的角度来分类,现有云厂商的容灾计划大抵调配三类:基于利用、基于实例和基于块存储:基于利用这类通常是针对某种特定的应用服务进行的容灾计划,例如云数据库,音讯队列,对象存储等,应用相干云服务的用户能够依据本人的须要抉择对应产品的容灾服务,这种容灾服务的劣势是联合业务往往可能做到利用级别的一致性,毛病是普适性不强,只有基于特定的利用的业务才能够应用。基于云主机对于只购买了 IaaS 服务,或者有本人的定制化业务,又或者是利用级容灾服务不能满足需要的,能够抉择基于云主机的容灾计划,这种计划会做整机的数据一致性爱护,或者跨实例的数据一致性爱护,容灾端通常除了存储数据的复原,也进行主机网络的复原,应用起来比拟便捷,这种容灾服务长处是操作简略,普适性强,毛病是在容灾端也须要买好主机资源,老本绝对较高。基于块存储(云盘)容灾的外围是数据容灾,因而也有局部厂商针对云盘自身推出跨地区复制产品,这种产品模式比拟灵便,对利用个别没有限度,复制期间不须要容灾端购买主机,能够升高用户老本,也能够无缝与其余云服务搭配应用,造成利用级容灾相似的成果。同样基于云盘能够做一致性组,对一组云盘的复制数据满足解体一致性语义。## ESSD云盘异步复制,简略几步帮你搞定业务复原云盘异步复制性能反对 ESSD 产品跨 Region(地区)进行云盘数据的异步复制,RPO 为 15 分钟。用户仅须要简略 3 步就能够实现一个容灾对的创立:首选抉择须要复制的云盘,第二抉择容灾站点并创立从盘,第三创立容灾对并激活容灾对。容灾对激活后云盘数据就会周期性复制到容灾站点对应的从盘上了,当用户想临时进行复制时,能够应用容灾对的进行性能来临时终止复制。当故障产生时,用户能够应用故障切换性能,实现主备站点的切换,故障切换会断开复制链路,并使得从端设施复原到上一个复制的一致性点,提供给用户可读可写权限。当劫难复原后,用户想将业务复原到原有生产站点,能够应用反向的复原性能,将从站点产生的增量数据恢复回主站点。 ## 云上异步复制背地的技术本章就容灾产品中宽泛应用的异步复制技术探讨一下其实现原理以及与传统存储的架构异同。容灾的外围是数据的容灾,块存储容灾是最通用的容灾计划,因而后文的探讨次要针对云盘的异步复制技术。#### 传统存储的复制架构传统存储异步复制实现形式大抵有三种:基于存储网关:存储网关位于服务器与存储设备之间,是构架在 SAN 网络上的存储服务技术。存储网关能够对进入的 IO 流提供灵活多样的存储服务,存储网关与主机服务器和阵列是拆散的,不占用主机和存储端的资源,能够不便的反对异构零碎之间的复制,但因为 IO 多了网关链路,所以性能会有肯定的损失,不太适宜对性能要求高的业务。基于主机:在 SAN 存储中通常实现在 Initiator 端,在主机端依据 IO 复制要求进行数据分流,典型实现如 DRBD,这种架构对后端的存储阵列没有要求,主机端须要装置相应的软件。做灾备服务的第三方厂商多采纳这种架构。基于存储阵列:少数存储阵列厂商会联合本人的阵列特点实现基于存储阵列的复制架构,这种架构下厂商会依据本人阵列 IO 架构实现在 Target 端,对数据进行追踪和双写。#### 云上异步复制的两种技术架构云厂商通常联合本人的产品特点,通常有两种技术架构:有代理的实现架构:这种形式通常须要在用户虚拟主机中装置插件作为 IO 代理,插件通过截获用户 IO 申请并转发进行复制,这种计划劣势在于能够提供利用级别的一致性语义。这种架构对云盘厂商没有特殊要求,容易做到异构零碎的容灾,劣势是用户应用时须要部署插件能力应用,对用户操作系统的版本可能有限度。云产品第三方服务商通常采纳这种架构。无代理的实现架构:这种实现形式往往基于底层的存储系统,依靠存储系统提供的一致性点以及获取数据差别位图等技术进行全量或者增量数据复制,能为用户提供数据解体一致性语义。这种形式的劣势是能够联合存储系统进行高效的差别数据复制,并且对用户主机零碎无入侵,业务应用形式更简略,劣势是无奈做到利用级数据一致性。支流云厂商通常具备自主研发的块存储服务,通常会联合块存储的本身架构特点实现无代理形式的复制架构。## 阿里云 ESSD 云盘异步复制架构阿里云块存储也推出了本人异步复制产品,本章介绍一下阿里云如何联合本身架构实现异步复制产品。阿里云块存储异步复制性能采纳的是无代理的实现形式。零碎架构如图所示,容灾管理软件别离在生产站点和容灾站点部署,容灾管控零碎周期性的发动复制工作给异步复制 IO 组件,复制组件从云盘存储系统后端获取数据差别并将差别数据复制到指标区域,目前跨区域复制的 RPO 设计指标为 15 分钟。#### 高可用架构异步复制技术实现上采纳高可用架构。思考到故障场景下零碎仍然能做到可用,容灾治理组件会在生产站点和容灾站点同时部署,而不是采纳容灾组件部署在单边或者在第三放区域部署的形式。容灾治理的元数据信息会在容灾对的主从都同步一份。这就保障了主站点劫难时,从站点的容灾治理性能依然可用。此外,容灾管理软件以及复制链路上都别离采纳了高可用架构,所有管控节点均采纳一主两备形式部署,保障了容灾服务本身的服务连续性。#### 高效复制异步复制的复制流程采纳增量形式进行复制,可能最大水平的升高复制和传输的数据量,这也进步了复制效率。依靠底层存储系统高效的外部获取一致性点技术,可能高效的获取云盘的数据解体一致性数据视图,通过存储系统外部索引技术可能高效的获取数据的增量差别。下图给出一个存储系统如何获取一致性点的差别位图。获取到的差别位图会被序列化为数据差别日志,即 DCL(Data Change Log)发送给复制组件,依据差别位图读取相应区域的一致性点数据并写入到从盘。复制链路也会依据云盘的大小带宽等个性将复制流程进行主动分片,并发复制,从而晋升复制的效率,最大水平满足 RPO。下图展现了复制组件获取差别位图和复制工作的过程,云盘会依据大小切分成多个数据分片存储到不同的数据服务器上,复制组件会从存储服务器获取一致性视图的 DCL,依据云盘大小和带宽状况,决定将一个云盘切分为多少个子工作进行复制,以更好的适配复制带宽。下图是复制 IO 组件的工作原理。#### 主盘性能无损依靠存储系统自身的高效索引零碎和高性能一致性点生成技术,异步复制对主站点云盘自身的性能影响很小,能够忽略不计,主盘性能齐全满足官网售卖规范。#### 秒级 RTO传统的备份业务通常会把数据存储在 OSS 等内部零碎上,须要应用时再利用 OSS 快照创立出盘,创盘和加载数据,会使得 RTO 工夫较长,通常达到分钟级或者更长。云盘异步复制对从端云盘进行周期性的写入,云盘在复制阶段不可读写,在故障切换后能够霎时可用,RTO 可达秒级,这得益于从盘数据始终在线的设计和存储系统可疾速复原到一致性点的架构劣势。## 总结与瞻望本文介绍了云上容灾产品状态,企业可联合本身特点抉择适合的容灾计划,针对异步复制产品解析了传统容灾与云上容灾的技术架构。阿里云块存储也联合本身架构特点实现了块存储的异步复制产品,相较于传统的异地容灾计划,块存储的容灾计划有如下劣势:低成本:无需绑定虚拟机应用,用户在容灾站点只须要购买云盘,而无需购买备用虚拟机,在容灾复原时可依据须要购买虚拟机,从而大大降低经营老本。易用性:无需用户虚拟机装置代理插件,做到利用无感知,对用户主机操作系统无版本要求。按需购买,操作简略,即买即用,反对一键切换和一键生成容灾演练盘。高可用:容灾组件均采纳高可用区设计,保障在劫难场景下容灾零碎可能进行容灾切换操作。业务疾速复原:提供较低的业务复原工夫,RTO 可达秒级。极低的性能开销:复制期间主盘性能简直不受影响。块存储异步复制产品致力于为用户提供简略高效易用低成本的异地容灾解决方案,后续将继续丰盛产品个性,陆续推出一致性复制组,共享盘反对,数据链路压缩与去重等个性,丰盛产品的应用场景和升高用户的应用老本,打造牢靠易用低成本的 DRaaS 服务,敬请期待。 原创作品:阿里云存储 李玮玮> 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 2, 2021 · 1 min · jiezi

关于阿里云开发者:一图速览-DTCC-2021大会阿里云数据库技术大咖都聊了些什么

简介:3天9场干货分享,快来珍藏吧!10月18日~10月20日, 由国内出名IT技术社区主办的数据库技术交换盛会——DTCC 2021 (第十一届中国数据库技术大会)在京圆满闭幕。大会以“数造将来”为主题,重点围绕数据架构、人工智能与大数据利用、传统企业数据库实际和国产开源数据库等内容开展分享和探讨。 作为DTCC的老朋友和寰球当先的云计算厂商,阿里云数据库团队集结多位顶级技术大咖亮相本次大会,带来极具价值的数据库饕餮盛宴,探讨最前沿的技术趋势与实际。 如果你错过了现场分享? **没关系 ** **同小编一起回顾 ** 阿里云数据库9场干货分享的大咖金句吧 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 1, 2021 · 1 min · jiezi

关于阿里云开发者:2021云栖大会|东方通正式加入阿里云云原生合作伙伴计划强强联手共创国产数字化转型新风向

简介:近日,互联网 IT 峰会中当属每年一度的“云栖大会”热度高,西方通作为外围搭档受邀加入 2021 云栖大会,并与阿里云一起探讨中间件撑持云原生技术推动政企行业数字化转型的新方向。近日,互联网 IT 峰会中当属每年一度的“云栖大会”热度高,西方通作为外围搭档受邀加入 2021 云栖大会,并与阿里云一起探讨中间件撑持云原生技术推动政企行业数字化转型的新方向。单方均高度重视本次单干,西方通团体执行副总裁 蔺思涛 学生、副总裁 李利军 学生、首席科学家 谢耘 学生等一行与阿里云就云原生单干发展深度沟通。 数字化转型已成为企业乃至寰球经济倒退的必然趋势。往年是十四五的开局之年,为放慢数字经济、数字社会、数字政府建设,各行业都在减速进行数字化转型。数字化转型的根本任务是价值体系优化、翻新和重构,在业务层面的体现是麻利、翻新、高效,恰好云原生技术架构的特色可能很好地撑持这些业务需要,越来越多的政企行业用户开始采纳云原生的思维和技术主导数字化转型架构。 西方通作为中间件的领军企业,已成为阿里云云原生合作伙伴打算的重要一员,单方已建设深度合作伙伴关系;在云原生技术架构中,中间件作为其外围产品家族之一,能更好地助力企业稳固、麻利、智能且平安可信的一站式数字翻新服务。 图1 西方通团体副总裁 李利军 学生代表授牌 正如阿里云智能云原生利用平台总经理丁宇学生在云原生峰会公布中提到,阿里云推出的云原生技术栈曾经笼罩了容器、中间件、Serverless等技术,并联合本身在电商业务的生产实践进行了大规模落地。借助阿里云云原生产品,包含企业级分布式应用服务 EDAS、音讯队列 RocketMQ、性能测试 PTS、容器服务 ACK/ASK、Serverless 工作流、Serverless 利用引擎 SAE 等云原生产品,能够减速企业数字化转型降级,享受云原生时代的技术红利。  会上,西方通团体副总裁 李利军 学生也示意,目前超六成的云原生企业为互联网企业,局部政企客户抉择了云原生技术架构,但构建的生产集群仍以中小规模为主,银行、保险、通信、电力、物流以及高性能计算等行业和畛域产生了一些云原生利用案例,实践证明,云原生解决方案能给用户带来业务智能、利用麻利、平安可信、资源高效等翻新价值。 图2 西方通团体副总裁 李利军 学生代表发言 西方通作为一个二十多年来专一于中间件畛域的根底软件厂商,TONG 系列中间件产品在政府、交通、金融、电信、军工等行业建立了泛滥典型利用案例,在全国有 33 家分支机构,营销体系和技术服务体系覆盖全国所有省市。尤其在信息技术利用翻新产业跨越式倒退的背景下,累计实现产业链上下游 1200 多个产品兼容适配认证,在利用上云和利用迁徙方面积攒了丰盛的实战经验,西方通领有丰盛的企业级根底软件研发、施行等教训,与阿里云的深度产品单干,可助力解决云技术落地时的诸多挑战,减速阿里云原生技术的落地。 截至目前,西方通中间件产品 TongWeb 与阿里云产品 EDAS 已实现产品深度交融和技术单干。将来,西方通与阿里云将一直深入单干,针对行业细分场景提供联结解决方案,阿里云提供底层技术平台并整合西方通的产品利用、解决方案、经营服务等能力,继续发展技术、产品、解决方案及市场深度交融共享,独特推动云原生技术在政企等要害行业重点畛域的落地,为减速客户的数字化转型奉献西方通的一份力量。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 1, 2021 · 1 min · jiezi

关于阿里云开发者:云栖新品阿里云IoT发布云芯一体智能视觉解决方案

简介:在2021云栖大会IoT云端一体硬件与利用翻新峰会上,阿里云IoT公布了Link Visual 云芯一体化智能视觉解决方案,发表Link Visual从繁多视频云服务平台向芯云一体化智能视觉解决方案降级。在2021云栖大会IoT云端一体硬件与利用翻新峰会上,阿里云IoT公布了Link Visual 云芯一体化智能视觉解决方案,发表Link Visual从繁多视频云服务平台向芯云一体化智能视觉解决方案降级。 阿里云高级产品解决方案架构师侯芳玉示意,降级后的Link Visual,将提供交融、凋谢、智能的Link Visual视频云平台整体解决方案,减速智能视觉设施的智能化;面向2B2C的视频设施智能化提供端云一体化的整体解决方案,反对合作伙伴自主开发翻新、自主增值服务经营;面向2B场景化提供凋谢的视频云底座(视频型企业实例)产品,赋能集成商场景化利用。 据理解, Link Visual 视频云平台是一个端到端一体化的视频服务整体解决方案,设施端采纳原子化技术架构,反对开发者自由选择开发计划;服务端提供多协定接入、视频流媒体服务、AI服务以及全球化服务,同时提供自主、可控的云存储经营服务,反对合作伙伴自主开发翻新、自主增值服务经营,助力合作伙伴从视频设施的经销商向云存储服务运营商转型降级。 同时为了减速视频设施的智能化,阿里云IoT与芯片合作伙伴晶视科技联结公布了Link Visual 系列视觉芯片CV1821,该芯片具备0.5T OPs算力,反对 2路视频输出,最大分辨率2880*1620@30fps ,广泛应用于智能摄像机、人脸识别面板机;上云即上电:芯片预集成阿里云IoT Link Visual 设施端 SDK ,具备上电即上云的能力,大大晋升开发者开发效率、升高对接老本;云端定义摄像机CDC(Cloud Define Camera):在芯片预集成阿里云IoT 端边共享的视频利用框架AI Accelerator,采纳AI算法与硬件基座解藕的设计理念,通过云端算法迭代、模型降级,实现一机多用。 随着智能门锁、户外摄像机市场的一直增长,阿里云IoT Link Visual还公布了低功耗保活解决方案和智能视频门锁解决方案;低功耗保活计划,很好的解决了电池类视频设施的功耗、疾速启动问题,大大晋升了用户体验,助力合作伙伴晋升产品竞争力;智能视觉门锁解决方案,基于Link Visual平台视频服务能力,整合天猫精灵生态和阿里云IoT的ID²平安能力,面向智能门锁计划商、品牌商提供交融、平安的整体解决方案。天猫精灵生态,当用户门口勾留或按门铃的时候,能够充分利用曾经进入千家万户的天猫精灵设施语音播报,也可通过天猫精灵APP近程查看门口视频。阿里云IoT的ID²平安能够为联网门锁设施提供可信设施身份认证,同时也为人脸识别门锁提供算法模型爱护和人脸特征值爱护等平安服务,全链路保障设施平安。 除了面向2B2C畛域的设施智能化计划外,阿里云IoT还公布了Link Visual视频云底座(视频型企业实例)产品,面向视频计划集成商提供底层视频平台,反对合作伙伴自主翻新场景化利用,据悉该产品也利用在了本次云栖大会的地方调度核心,为大会提供了各种视频服务和智能剖析服务。 从根底视频平台服务到芯云一体化智能视觉解决方案,阿里云IoT Link Visual视频云平台依靠阿里云IoT积攒的物联网技术、视频技术、边缘计算、AI算法等外围能力,正成为视频设施接入的行业首选平台。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 1, 2021 · 1 min · jiezi

关于阿里云开发者:ODPS主备集群双向数据复制导致主备中心网络打爆问题

简介:ODPS主备集群双向数据复制导致主备核心网络打爆问题 1. 故障问题形容客户现场产生了ODPS主备机房互相数据全量复制导致的主备核心网络被打爆的问题,重大影响了日常运行的ODPS工作。在ODPS主备机房的环境中,用户的工作均在主机房中运行,产生的数据默认会落在主机房,通过ODPS replicationService将主机房的数据异步复制到备用机房。那么为什么会有反向同步到主机房数据的状况,须要对该问题发展排查进行根因剖析。 2. 故障景象在排查过程中察看敞开数据前后的机器网络负载状态,当关上数据主备复制的时候,机器的网卡的进出流量很大。 图1 持续排查发现主机房复制作业和备机房复制作业都在运行,而且很多都是没有更新的数据表,这种没有必要的全量数据同步造成大量的网络开销。 图2 图3 图4 3. 故障起因剖析在解决问题之前,咱们须要先搞清楚ODPS同城双机房容灾整体技术计划和其中的跨机房数据异步复制工作原理。 3.1 ODPS同城双机房容灾整体技术计划ODPS产品利用中针对每一种场景的故障或者集群劫难,其故障复原或者服务切换计划都是不同的。该客户属于ODPS同城双机房容灾计划,咱们先看下ODPS同城双机房容灾整体技术计划。 特点:主备机房均部署残缺的MaxCompute服务(管制集群、计算集群、tunnel、前端)。主备机房均能够失常应用,但失常状态下,备机房处于静默状态,不解决具体业务申请。主备机房之间开启数据传输,设置既定的策略定时或按需将数据同步到备机房。外围逻辑:元数据放弃同步复制;业务数据放弃异步复制;RTO:能够实现分钟级;RPO:视数据量及同步频率来定,个别为小时级。网络要求:元数据的同步提早要管制在5ms以内;业务数据的同步提早要管制在20ms以内。 图5 模块具体阐明如下:VIP1:指向一组Tunnel数据服务节点的虚构IP,绑定ODPS tunnel的域名,所有的ODPS数据上传和下载都通过VIP1。VIP2:指向一组ODPS DDL/DML命令服务节点的虚构IP,绑定ODPS服务的域名,所有的DDL/DML命令都通过VIP2提交给ODPS进行解决。Tunnel前端集群:部署ODPS Tunnel服务过程的一组节点,用于数据上传和下载,会调用用户核心和Meta服务进行用户申请的鉴权,读写计算存储集群的数据。命令前端集群:部署ODPS DDL/DML命令解决服务的一组前端节点,将DDL/DML操作命令转发给ODPS管制服务进行解决。管制服务:解决前端发来的DDL/DML命令,对于DML,会进行SQL语法分析、查问优化和查问打算生成,通过提交给计算集群的分布式作业来实现物理执行打算。用户核心:即UMM服务,负责管理整个阿里云和大数据平台的用户。Meta服务:ODPS采纳OTS作为本人的Meta存储服务,负责管理ODPS对象的元数据,包含Project信息,表数据(Table)的schema及其数据存储在飞天集群上的门路,数据在不同飞天集群上的版本信息,用户UDF的元数据信息等等。计算集群:用于存储和计算的飞天集群,存储所有的数据和UDF程序,所有的DML命令会解析为一个飞天的分布式DAG(有向无环图)作业提交给计算集群来执行。飞天集群最外围的模块包含盘古(Pangu)和伏羲(Fuxi),盘古是一个分布式文件系统,Fuxi负责资源和作业调度治理。 在这个计划中,主备机房各有一套ODPS服务,它们共享同一个用户核心(UMM)和Meta服务,UMM和OTS都具备各自双机房容灾能力,具体详见它们的容灾计划。3.2 跨机房数据异步复制工作原理咱们再来看下跨机房数据异步复制工作原理: 在失常工作状态下,主机房的ODPS提供服务,备机房的ODPS没有服务申请,下层数据业务都只通过两个服务域名应用ODPS:ODPS服务域名:指向命令前端集群的虚构IP,即零碎架构图中的VIP2。Tunnel服务域名:指向Tunnel前端集群的虚构IP,即零碎架构图中的VIP1。ODPS通过数据异步复制机制,由主机房的Replication Service一直将主机房的ODPS数据同步到备机房的计算集群,ODPS引入数据版本的机制:同一份数据(表或分区)在多个计算集群上可能具备不同的版本,ODPS Meta服务会保护每份数据的版本信息,示意如下:        <span class="lake-fontsize-12">{"LatestVersion":V1,"Status":{"ClusterA":"V1","ClusterB":"V0"}}</span> 当一份数据版本更新后,触发一个分布式的跨集群数据复制工作,将数据复制到其余计算集群,通过对复制工作的限度能够进行机房间数据复制流量管控。1. 对于ODPS这种大规模离线数据处理系统来说,数据加工往往有突发的状况,在某个时间段产出的数据量可能十分大,受限于机房间的带宽,新上传的和新计算的数据复制到备机房须要肯定的工夫,ODPS提供实时查看以后未同步的数据表/分区,实时的容灾数据同步率等信息,实时数据同步率次要取决于两个因素的影响: 机房间带宽大小; * 主机房ODPS计算集群忙碌水平。因为数据复制也是以飞天分布式工作来进行的,须要用到主机房的ODPS计算集群的计算资源(次要是CPU和内存),ODPS能够依据这两个因素给出数据同步实现的工夫预估。思考到集群间带宽,存储等资源的竞争, 须要用户自行抉择是否创立容灾project。通过ascm/dtcenter创立project时,能够抉择创立单集群project,也能够抉择创立多集群project。其中单集群project不反对容灾性能。容灾project配置:1. 通过ascm/dtcenter创立多集群project之后,默认主备集群不会进行数据同步,须要通过bcc页面配置开启数据同步(maxcompute模块下 -> 运维菜单 -> 业务运维 -> 项目管理 -> 我的项目列表)。图61. 客户某个project的资源复制配置:图7配置项阐明,开启资源复制后,以下配置能力失效。 SyncObject:配置同步的集群,以及同步数据类型,参照上图将ODPS集群名批改为现场主备集群名称即可开启ODPS数据齐全复制。 * ScanMetaInterval:数据同步距离,单位为秒。 * EnableEvent:数据是否实时同步,配置为true时,当主集群数据产生变动,会立即同步到备集群,同时ScanMetaInterval配置将生效。  注:配置数据同步为实时同步或数据同步距离配置工夫较短会较大水平占用网络带宽,倡议当须要同步的数据量较大时,敞开实时同步并调大同步距离。  1. 容灾复制危险和实际阐明:     如上一节提到的 EnableEvent 如果设置为true,那么project中的数据会在被更改后立即触发同步,并且每次同步的数据量为该表或该分区的全副数据量。例如:某非分区表中有1T的数据,如果对该表插入1条数据,就须要将这1T的数据都复制到备机房。 如果1分钟内写了10次数据,那一分钟就会复制10次1T的数据到备机房,从而产生9T的待回收数据。混合云上强烈建议敞开实时复制,以缩小机房间的带宽和存储压力。改为定时复制的策略,比方设置ScanMetaInterval,6小时一次扫描复制一次。     EnableEvent = false     ScanMetaInterval=21600   #6小时=21600秒     * 为避免顶峰时段ODPS占满集群带宽,能够在adminconsle->跨集群复制全局配置,这里限度ODPS集群间复制的流量带宽,单位是Gb,下图示例:图8从具体的备机房往主核心复制作业日志截图中能够看到,集群的名字是大写,而客户在资源复制同步中设置的sourceLocation中是小写,客户侧存在谬误配置的问题。图9和ODPS的研发同学沟通确认了这个问题的root cause是ODPS的replicationService在发动我的项目数据异步复制时会拿SyncObject的集群通过ots来校验备用集群对应的project的版本号。这里将大小写不同认为是备机房该我的项目不存在,于是发动了同步,然而在数据落地存储的时候有数据校验并不会把这些真正存储起来。于是带来了不必要的网络开销,但并不会影响数据品质。 通过bcc批改资源配置,将SyncObject中集群改为大写,并重启ODPS的replicationService后问题失去彻底解决。图10# 4. 问题论断ODPS主备集群做数据复制同步带宽被打满,root cause是ODPS project资源复制中的集群名是小写,而ODPS project集群的名称是大写,数据同步的时候会认为该project不存在,导致了双向同步,通过测试也验证了这一点。该问题曾经通过bcc批量更正我的项目名中集群信息为大写,同时重启replicationService解决。须要特地留神:客户在bcc中我的项目资源复制配置中须要留神放弃同步数据集群名字大小写和集群名字匹配。通过这次问题排查能够很好地理解到以后的ODPS多机房的数据同步计划和多机房的技术容灾架构。 咱们是阿里云智能寰球技术服务-SRE团队,咱们致力成为一个以技术为根底、面向服务、保障业务零碎高可用的工程师团队;提供业余、体系化的SRE服务,帮忙广大客户更好地应用云、基于云构建更加稳固牢靠的业务零碎,晋升业务稳定性。咱们冀望可能分享更多帮忙企业客户上云、用好云,让客户云上业务运行更加稳固牢靠的技术,您可用钉钉扫描下方二维码,退出阿里云SRE技术学院钉钉圈子,和更多云上人交换对于云平台的那些事。> 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

November 1, 2021 · 1 min · jiezi

关于阿里云开发者:最佳实践丨云上虚拟IDC私有池如何为客户业务的确定性连续性保驾护航

简介:企业业务上云后,还面临特定可用区购买云上特定计算产品实例失败的窘境?云上公有池pick一下Why 云上业务为什么须要资源确定性、服务连续性 云计算正朝着像水电煤一样的基础设施演进,反对用户按需应用、按量付费。目前,国内外各云服务商联结生态搭档,致力晋升云产品服务的疾速迭代、推广应用,然而事实很骨感:用户仍然面临偶发的在特定可用区购买云上特定计算产品实例失败的窘境。云服务的计算理念--随时随地弹性,怎么这个场景下就不Work了?咱们来剖析剖析。 目前,客户云上业务整个生命周期过程,须要感知算力的“商品化”载体:例如某客户A,将集体博客的Web服务迁徙到阿里云上时,须要购买阿里云弹性计算云服务器,客户须要感知云服务器规格信息,如最新的ecs.g7.xlarge。例如某客户B,将在线制作3D创意成果的业务部署在阿里云上,依靠阿里云弱小GPU等算力资源,此时,须要购买阿里云弹性计算的GPU云服务器,如ecs.gn7i-c8g1.2xlarge。 艰深了解:相似用户向“酒店”租住一个“房间”。云上环境,用户购买云上的一个具体的计算实例规格。 这与水电煤“即插即用”存在区别:云上的算力须要感知商品实例信息。水电煤是对立的‘用量’,屏蔽了后端的供货商(哪个电网供电、哪条线路输送)、供货的生产设施(水力发电、火力发电、风能发电、太阳能发电等)。目前国内外头部云服务供应商的算力服务售卖实体,支流仍然是算力对应具体商品。因为面向具体商品,那么就存在商品之间服务个性、适宜的业务场景、业务所需数量等差别。云服务供应商也就须要在不同地区提前准备好不同的商品,以及供给数量。 因为很难精准地预测各种具体算力商品的用户量级、购买工夫、购买数量,一旦呈现行业热点,同一行业的大多数客户短时间大量购买某一个个性的商品,较容易呈现针对特定商品的抢购而导致局部用户购买失败。典型如疫情背景下,挖矿、在线教育的衰亡,对本地盘、视频编解码算力需要旺盛,导致相干商品抢购景象突出。 艰深了解:相似“酒店”的残余房间曾经用完了,新客户入住失败。对应云环境,用户在云上购买计算实例,短时库存售磬,可能购买失败。 另外,电商每年在不同时间段会有各种“节日”促销流动,典型如618、双11。在促销期间和促销完结的一段时间内,须要大量的算力资源反对在线流动和流动完结后的海量数据分析。客户服务经验“失常态”、“大促态”、“大促收尾态”、“失常态”这样的典型服务间断过程。客户为了确保全年服务的连续性,特地是资源需要按预期布局确定进行,那么,云上资源确定性交付就是重要撑持。 艰深了解:例如奥运这样的预期流动,用户入住酒店,保险的措施就是提前预订好房间。对于云环境,就是在云上预订一个虚构的IDC(公有池),这样就能够在公有池上确定性地交付资源。 图1-水电煤基础设施与云计算基础设施“服务状态”现阶段的比照 综上剖析,现阶段,在云服务的支流服务售卖模式仍然是“算力商品化”的大背景下,用户须要感知业务在云上生命周期过程所需商品个性,云平台须要面向商品进行供给生产。因为需要的变动和市场环境的不确定性,供给和需要短时间的不匹配比拟容易产生。所以,服务特定行业的特定客户、针对特定算力商品的确定性购买,即云上资源确定性交付就成为解决这种窘境的重要能力。 How 如何保障云上业务资源确定性、服务连续性 后面剖析了主观现状,存在特定地区、特定时间段、特定算力商品的短时购买失败景象。对客户来说,须要联合本身场景,市场上云商品供给状况,适合的老本投入来实现资源交付的确定性,从而确保业务连续性。 下文的剖析以整体性概念为主,具体到客户的业务场景,还须要具体案例具体分析。例如预约地区的抉择、实例规格的抉择、预约时长的抉择、预约数量的抉择、总的老本最优等。资源交付的一种划分如图2所示,其中公有池是确定性交付的重要实现形式。联合业务场景,举荐最佳的公有池选购计划本文暂不介绍,后续专门出文档形容,帮忙用户更好地依靠云的产品服务,实现资源的确定性交付,保障业务服务的连续性。 图2-资源交付的一种划分 图3-确定性交付的可选策略 图4-灵便弹性交付的可选策略 Aliyun 公有池选购和价值 1- 相干概念 私有池: 当用户在ECS 控制台,“资源保障”服务标签页下,购买“弹性保障”或者“容量预约”等产品后,就取得了云上的一个具备确定性库存资源预留,并且是专属调配应用的资源池。如图5-公有池模式形象和多种产品实现。图5左侧,一个公有池的服务有两个阶段:公有池预留和公有池资源交付。针对公有池预留,产品指标是履约:确保公有池真正被应用。例如弹性保障EA elastic assurance,一次性预收取这个公有池费用。 图5-公有池模式和多种产品实现 iCR:immediately Capacity Reservesion 立刻失效按量预留CR,公有池全副用完,无额定的老本开销,只在公有池有残余容量的时候,收取残余容量局部费用。 aCR:advance Capacity Reservation 指定工夫、提早失效的容量预约,基于信用分等级收取一些预订金,信用等级越高,预定金越低。 针对公有池资源交付,产品指标是:确定性交付、零门槛应用。当实例开进去后,会按实例进行失常的免费。 资源保障:资源保障是包含资源供应量化感知、资源的确定性预约、公有池布局应用的全链路资源确定性服务,它可能全面晋升您在查问、预约、购买、应用资源过程中的体验,使您在复杂多变的市场环境下仍然可能享受到专有保障资源。 弹性保障:通过弹性保障,您只须要领取一笔较低的保障费用,即可换取固定周期(反对1个月~5年)的资源确定性保障。购买弹性保障时设置可用区、实例规格、保障数量等属性,零碎会以公有池的形式预留指定数量属性相匹配的资源,例如在华东1(杭州)可用区I预留10台ecs.c6.large规格的实例。在弹性保障有效期内,您创立按量付费实例时抉择应用公有池的容量,即可享受到资源确定性保障。在弹性保障有效期内,您能够反复创立/开释指定数量的实例而无需放心资源供给的问题。超出弹性保障有效期或者弹性保障曾经没有闲暇的容量时,资源确定性保障将不再提供。 立刻失效容量预约:您能够随时购买立刻失效容量预约,预约胜利后立刻失效,即可享受资源确定性服务。容量预约失效后即开始依照按量实例费率免费,直至立刻失效容量预约到期主动开释或者您提前手动开释。购买立刻失效容量预约时设置可用区、实例规格、操作系统类型、容量大小等属性,零碎会以公有池的形式预留指定数量属性相匹配的资源。在容量预订有效期内,您创立按量付费实例时抉择应用公有池的容量,即可享受到资源确定性保障。通过一般场景购买的ECS,因为资源的供给变幻无穷,线上的资源可能无奈每时每刻满足您的定制化需要;而在容量预订有效期内,您能够反复创立/开释指定数量的实例而无需放心资源供给的问题。容量预约未处于失效状态或者容量预约曾经没有闲暇的容量时,资源确定性保障将不再提供。在容量预约计费周期内,如果您购买了按量实例,并且应用了资源确定性,这部分按量实例的计算资源费用将会抵扣与按量实例匹配的容量预约的局部或者全副费用。 当一个按量实例与弹性保障和容量预订均匹配时,零碎会优先选取容量预约产品对应的公有池进行匹配。 2- 公有池价值 价值1: 确定性资源交付 随着云原生概念和实际的宽泛遍及,基于云的算力研发已成为新常态。客户业务云原生后,业务的疾速倒退过程中,往往针对特定场景,有着资源确定性交付的诉求,冀望100%地保障业务按既定布局上线、经营、推广等。 资源保障相干产品提供了全链路确定性交付能力。 具备确定性交付的能力,从业务角度就防止了云上某个可用区下、某种稀缺资源的抢购带来的购买成功率低的不确定性危险,例如GPU大规格实例。在原有共有资源池弹性交付根底上,配合确定性交付,能够进一步保障高优先级业务的资源100%保障。例如之前按量购买了20台A规格实例,这些实例会有业务的一些运维、变更等操作,购买20个A规格形成的公有池,这样就确保这些实例操作运维过程中资源具备100%确定性,不会被其余客户抢占。失常状况下20个A规格公有池容量被20个A规格实例全副应用,无任何闲暇容量,从而无任何额定老本投入。当理论应用资源确定性的A实例数量有余20个的时候,例如仅应用18个实例,产生2个闲暇容量,此时闲暇容量会按秒级计费,按小时出账单。 价值2: 资源专属调度调配应用 在客户业务架构、业务演进深度交融云产品服务的迭代降级过程中,除了资源确定性交付之外,资源灵活性交付也随之成为重要的诉求。阿里云资源保障服务目前曾经反对基于云上公有池的专属调度调配,用户专属调度目前有两种实际形式。 形式一:用户基于Open、Target、None的匹配规定,进行实例的调度调配 用户在创立公有池的时候,指定公有池的匹配属性:Open(凋谢)、Target(指定)。在创立实例的时候指定实例匹配属性Open 或者Target(应用Target模式须要显示指定公有池ID),后端进行属性匹配调度。 当实例匹配属性值为Open的时候,零碎会优先从用户公有池创立实例;如果无匹配的公有池,则依照共有池流程创立实例,同时保留资源确定性特色,一旦发现有闲暇的容量,零碎会准时的主动将这些实例从新与闲暇公有池进行匹配和关联;当实例匹配属性值为Target的时候,明确指定某个公有池,此时零碎在指定的公有池进行容量和公有池资源规定的匹配校验。例如公有池region、zone、instanceType、platform、payType等校验。 运行过程中,当实例的匹配属性产生批改,零碎会准时进行实例和公有池的从新匹配,确保实例尽可能地关联到公有池,从而缩小用户的费用老本(公有池的闲暇容量及时应用掉);当匹配模式为Open的公有池被开释的时候,零碎会准时的对与该公有池关联的并且应用Open匹配模式的实例从新匹配,确保实例尽可能地关联到公有池,从而缩小用户的老本(公有池的闲暇容量及时应用掉)。 形式二:用户基于Tags匹配规定,进行实例的调度调配 用户在创立公有池的时候,指定公有池的tag信息,而后创立实例的时候指定tag信息,后端就能够依照客户指定的tag匹配规定,从公有池或者共有池进行精细化资源调度调配。 为了升高用户应用门槛,或者零门槛,不管形式一还是形式二,阿里云资源保障服务都反对用户在现有CreateInstance、RunInstnaces接口根底上,间接应用形式一或者形式二进行资源专属调度。例如用户申请白名单后,后端按用户需要,将用户创立实例时候的匹配属性指定为默认值,这样用户既有的集成接口参数毋庸改变。 3- 公有池的获取 控制台购买获取 https://help.aliyun.com/document\_detail/193634.html OpenAPI集成式获取 ...

November 1, 2021 · 2 min · jiezi

关于阿里云开发者:ESSD技术解读企业级利器阿里云-NVMe-盘和共享存储

简介:以后 NVMe 云盘联合了业界最先进的软硬件技术,在云存储市场,独创性同时实现了 NVMe 协定 + 共享拜访 + IO Fencing 技术。它在 ESSD 之上取得了高牢靠、高可用、高性能,同时基于 NVMe 协定实现了丰盛的企业个性,如多重挂载、IO Fencing、加密、离线扩容、原生快照、异步复制等性能。本文具体介绍了云上SAN和NVMe的倒退历程,并做出了对将来的构想7x24 高可用是怎么炼成的?事实世界中单点故障是常态,确保故障下业务连续性是高可用零碎的外围能力,那么在金融、保险、政务等要害利用中,如何保障业务 7*24 高可用?通常来讲,业务零碎由计算、网络、存储组成,在云上,网络多路径和存储分布式确保了稳固高可用,但要实现业务全链路高可用,还要解决计算和业务侧单点故障。以常见的数据库为例,单点故障导致业务进行对于用户难以承受,那么,当断电、宕机、硬件故障等导致实例不可服务时,如何疾速复原业务? 不同场景的解决方案有所不同,MySQL 通常搭建主从/主备架构实现业务高可用,主库故障时切换到备库继续对外提供服务。但实例切换后,如何保障主从库数据的一致性?依据业务对数据失落的容忍度,MySQL 通常采纳同步或异步形式进行数据复制,由此引入额定的问题:局部场景下导致数据缺失、同步数据影响零碎性能、业务扩容要新增整套设施并进行全量数据复制、主备切换工夫较长影响业务连续性等。能够看到,为了搭建高可用零碎,架构将变得复杂,且很难兼顾可用性、可靠性、扩展性、老本、性能等,那么是否有更加先进的计划,兼得鱼和熊掌?答案必须是:Yes! 图1:数据库的高可用架构 通过共享存储,不同数据库实例间可共享同一份数据,从而通过计算实例的疾速切换取得高可用(图1),Oracle RAC、AWS Aurora、阿里云 PolarDB 数据库就是其中的代表。这里的关键在于共享存储,传统 SAN 价格昂扬,扩缩容麻烦,机头也容易成为瓶颈,其应用门槛较高对用户并不敌对,有没有更好、更快、更省的共享存储,来解决用户的痛点呢?阿里云最近推出的 NVMe 云盘和共享个性,将充沛满足用户的诉求,接下来咱们将重点介绍。这里给大家抛出一个问题,在实例切换过后,如果原库仍在写入数据,如何保证数据正确性?卖个关子,读者能够先思考下。 图2:主从切换场景的数据正确性问题 历史后退的车轮:云上 SAN 和NVMe咱们已步入“数据石油”的数字经济时代,云计算、人工智能、物联网、5G 等技术的疾速倒退,促使数据的爆炸式增长。从 IDC 2020 年报告能够看出,寰球数据规模逐年增长,2025 年将达到 175 ZB,数据将次要集中在公共云和企业数据中心。数据的快速增长,为存储的倒退提供了新的能源和要求,让咱们回顾下块存储状态是如何一步步演进的。 图3:块存储状态演进 DAS:存储设备采纳直连形式(SCSI、SAS、FC 等协定)与主机连贯,零碎简略、易于配置管理、费用较低,因为存储资源无奈被充分利用和共享,难以做到集中统⼀的治理和保护。 SAN:通过专用网路连贯存储阵列和业务主机,解决了对立治理和数据共享等问题,并实现高性能低提早的数据拜访,不过 SAN 存储价格昂贵、运维简单、可扩展性差,进步了用户的应用门槛。 全闪:底层存储介质的反动和老本的降落,标记着全闪存时代的到来,从此存储性能转移到软件栈,迫使软件进行大规模的改革,促成了用户态协定、软硬一体化、RDMA 等技术的高速倒退,带来了存储性能的飞越。 云盘:云计算的高速倒退历程中,存储转移到云上,云盘具备天生的长处:灵便、弹性、易用、易扩大、高牢靠、大容量、低成本、免运维等,在数字化转型历程中成为存储松软的底座。 云上 SAN:为全方面反对存储业务,取代传统的 SAN 存储,云上 SAN 应时代而生,它继承了云盘的诸多劣势,也具备了传统 SAN 存储能力,包含共享存储、数据保护、同步/异步复制、极速快照等个性,必将在企业存储市场继续发光发热。 另一端,在存储协定的演进上,NVMe 正在成为新时代的宠儿。 图4:存储协定的演进 SCSI/SATA:存储远古时代,硬盘多为低速设施,数据通过 SCSI 层和 SATA 总线传输数据,性能受限于存储慢速介质,如机械硬盘,覆盖了 SATA 单通道和 SCSI 软件层的性能劣势。 ...

November 1, 2021 · 2 min · jiezi

关于阿里云开发者:ESSD技术解读-云原生时代阿里云块存储-ESSD-快照服务如何被企业级数据保护所集成

简介:本文形容了阿里云块存储快照服务基于高性能 ESSD 云盘晋升快照服务性能,提供轻量、实时的用户体验及揭秘背地的技术原理。根据行业倒退及云上数据保护场景,为企业用户及备份厂商提供基于快照高级个性的数据保护的技术计划,满足云上用户数据保护的迫切需要,保障云上企业业务连续性。简介:本文以云原生为时代背景,介绍了阿里云块存储快照服务如何基于高性能 ESSD 云盘晋升快照服务性能,提供轻量、实时的用户体验及揭秘背地的技术原理。根据行业倒退及云上数据保护场景,为企业用户及备份厂商提供基于快照高级个性的数据保护的技术计划,满足云上用户数据保护的迫切需要,保障云上企业业务连续性。 2021年7月份,国内出名征询公司 Gartner 公布了私有云的 IaaS(基础设施即服务)和 PaaS(平台即服务)平台的“魔力象限(Magic Quadrant)”,阿里云凭借其当先的技术能力首次成为“近景者”象限的私有云服务提供商,其中阿里云块存储取得单项得分第一的问题,阿里云计算、存储,网络及平安得分取得寰球第一。存储当先业界的背地离不开高性能的 ESSD 云盘产品为用户提供高可用、高牢靠、高性能的块级随机拜访服务及原生的快照数据保护能力。 原生业务新需要随着云原生技术的倒退,越来越多的企业基于云计算的虚拟化、弹性扩大及蓬勃发展的云原生技术的分布式框架,容器技术、编排零碎、继续交付及疾速迭代,构建起大规模、弹性扩大强、丰盛的云上分布式业务场景。企业应用的部署规模,存储,计算等资源需要随之成指数增长,导致传统的数据保护计划无奈满足云端新的技术变动。用户面临的市场竞争环境更加强烈,迫切需要适应业务规模及倒退的云端数据保护计划来满足本身竞争力及业务的倒退须要。尽管数据保护的业务背景及场景因云计算及云原生而发生变化,但用户对数据保护的诉求没有发生变化,掂量的规范仍然是复原工夫点指标 RTO 及复原点指标 RPO。 用户谋求的首要指标仍然是业务连续性,即在业务面临中断威逼,迅速实现业务复原;业务面临增长压力,迅速实现业务扩大。用户依据业务场景对云上的数据保护及快照服务提出了如下的迫切需要: 创立工夫短:快照极速实现,要害业务即刻进行数据备份。极速可用:快照极速可用,应答突发事件,实现云盘回滚复原。业务扩大:业务量突增须要业务扩容。整机爱护:单 ECS 实例及多 ECS 实例的关联多盘的一致性数据保护。测试验证:生产环境以外即可进行数据测试验证及复原。复原速度快:文件系统及利用数据处于利用一致性的备份状态,防止利用宕机复原过程。容器备份:容器业务环境的疾速迭代及公布,迫切需要爱护元数据及利用业务数据。依据存储网络工业协会 SNIA 对快照的定义:快照是指定数据汇合的一个齐全可用拷贝,该拷贝包含相应数据在某个工夫点(拷贝开始的工夫点)的映像。阿里云块存储快照就是提供 ESSD 云盘某一时刻的一致性数据镜像。适应行业的发展趋势,快照服务一直发现用户的新需要及新场景,不懈地进行了新性能开发及迭代演进,极致降级优化 ESSD 云盘快照的高级企业新个性:快照极速可用个性、利用一致性快照及适应分布式应用架构的一致性组快照及快照跨地区复制的异地灾备性能。在一直独立输入及被集成的倒退过程中,满足了云上企业用户的需要,服务大数据、游戏,人工智能、金融行业等畛域,也失去了阿里云其余团队如:云数据库团队 RDS、混合云备份团队、弹性容器实例 ECI、容器服务 ACK 等业务团队及用户的反馈: 云数据库团队 RDS 行业用户的评估是:RDS 的秒级备份产品对齐业界的数据库备份产品,升高原有物理文件备份对实例资源占用,无效升高了数据保护危险。弹性容器实例 ECI 容器减速收益客户图森的评估是:极速型缓存减速性能减速了容器利用公布,升高了仿真平台的计算工夫,将计算工作升高到均匀 5 分钟以内,产品公布周期极大缩短。依照混合云备份客户的说法,利用一致性整机备份能力齐全对标 VMware 虚拟化平台的快照性能。快照服务提供的一致性组快照及利用一致性能力,齐全满足 2021 年 Gartner 对阿里云块存储服务评测能力。容器业务 ACK 团队通过 2021 年 Forrestor 容器备份评测能力。典型场景轻量、实时的快照极速可用个性,一致性组快照及利用一致性快照的高级个性,为企业用户及第三方备份厂商疾速构建起:极速备份复原、容灾测试、正本利用及容灾切换的正本数据管理(Copy Data Management)利用场景。Gartner 于 2021 年 7 月份公布的对于存储及数据保护的技术趋势(Hype Cycle)剖析中,将容器备份、云数据备份及正本数据管理(CDM)列为将来几年的数据保护的行业发展趋势。Gartner 对正本数据的治理的根本定义为:基于利用一致性的主存储快照在辅助存储上生成“Golden Image”,并利用其进行备份,容灾及测试,而且异构存储作为能力的根本条件。阿里云的 ESSD 的高级快照服务个性齐全满足构建 CDM 的条件,帮忙用户实现云上正本数据管理的原生数据保护典型场景: ...

October 29, 2021 · 2 min · jiezi

关于阿里云开发者:小米行李箱厚款卫衣定制徽章大礼包免费领-没错问答官第三期性能调优专场来啦

简介:用更少的资源提供更好的服务,让老本利益最大化,这是咱们在工作中不变的谋求。性能调优的伎俩有空间换工夫、工夫换空间、并行,你还有哪些更好的解决办法?用更少的资源提供更好的服务,让老本利益最大化,这是咱们在工作中不变的谋求。性能调优的伎俩有空间换工夫、工夫换空间、并行,你还有哪些更好的解决办法? 当初只有提出对于性能调优在Java、linux中的问题或解答相干问题,就有机会赢取开发者社区专享大礼包! 发问或答复请尊重知识版权,一旦发现剽窃等违规行为,删除并勾销流动资格 咱们先看奖品大礼包! 注:答复仅限答复10月28日当前且合乎主题的问题 奖品很心动,却不晓得从哪里动手,先看以下问题有没有带给你灵感。 Java性能调优 为简化java程序加载的累赘,缩短加载工夫,单例个别用在哪些方面呢?Java调优中为什么要防止随便应用动态变量呢无关java的性能调优,有哪些罕用的办法?Java性能调优,为什么要尽量避免过多地创立Java对象应用final修饰符对于Java外围API有什么益处呢?多线程在未产生线程平安前提下应用HashMap、ArrayList有什么益处呢Java堆该怎么调配能力做到最好的优化呢Java都有哪些函数来晋升算法效率呢?Java调优中,过早的优化会占用大量工夫,并使代码难以浏览和保护,那么如何证实须要优化某些货色?如何制订Java性能调优规范?linux性能调优 Linux零碎中有哪些性能调优命令呢?Linux零碎中该怎么查看hdparm硬度读取速度?进步Linux服务器性能有哪些技巧呢?linux性能调优,为磁盘I/O调整Linux内核电梯算法有什么益处?Linux磁盘子系统的调优有哪些好的办法?如何进步Linux Makefile 的编译速度呢?Linux CPU的性能应该如何优化?linux性能指标都蕴含哪些方面?Linux文件子系统的调优应该怎么做?Linux中监控内存的常用工具都有什么呢流动工夫10月29日-11月7日 奖品邮寄工夫流动完结后7个工作日内进行邮寄,节假日顺延。 参加步骤第一步:1、点击:https://developer.aliyun.com/ask 进入问答板块,登录胜利后,点击“我要发问”进行发问; 如答复问题,可搜寻关键词查找问题进行答复; 第二步:提交您的相干信息,便于数据统计和礼品寄送。(提交地址:https://yida.alibaba-inc.com/o/wdg) 流动答疑钉钉扫描下方二维码,退出问答官流动群,取得流动停顿一手信息。 流动规定1.每个参加用户,奖品不可反复取得,如果同时满足两个以上的得奖条件,获奖人能够抉择奖品; 2.无关问答须围绕主题进行,发问和答复总数依照流动期间所提交的进行计算; 3.问题及答复需为中文,英文不记录数据; 4.问题或答案公布后将进入审核状态,审核实现即可查看; 5.用户在流动期间内按规定提交集体链接和收奖地址,即视为参加流动,如超过提交工夫,则视为放弃; 6.题目党、黑稿、通稿、蕴含守法违规、未被许可的商业推广、外站链接、非原创内容、营销软文、剽窃嫌疑的文章审核将不予通过,同时勾销参赛资格。 阿里云开发者社区问答频道关心处分每一个酷爱技术并寻找真谛的你。 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

October 29, 2021 · 1 min · jiezi

关于阿里云开发者:技术解读|云上企业级存储打开存储新维度促进用户核心业务创新

简介:将企业级存储和云的特点进行完满的交融是云上企业级存储的指标,它关上存储更多新的维度,在保障用户业务永续的同时,帮忙用户更好的进行业务翻新。本文属ESSD技术解读的总篇,总体介绍ESSD 云盘翻新交融了云和企业级存储的个性,以服务为核心,为用户提供了更便捷、更智能的存储服务体验。前言提到企业级存储,大家印象最深的是“高稳固”、“高性能”、“丰盛的企业级个性”等关键词;而说到云计算,大家会想到“大规模”、“寰球部署”、“弹性”、“服务化”、“智能化”、“即时开明"、“按量付费”这些鲜明特征。如果把两者联合,会产生什么样的新存储状态呢?云上企业级存储的指标就是将企业级存储和云的特点进行完满的交融,关上存储更多新的维度,在保障用户业务永续的同时,帮忙用户更好的进行业务翻新。 以块存储为例,常见的企业级解决方案是存储区域网络(Storage Area Network,简称 SAN),通过专用网路连贯存储阵列和业务主机,提供存储对立治理和共享,并实现高性能低提早的数据拜访。但 SAN 存在老本高、运维简单、可扩展性差等有余,而这些问题恰好是云技术最善于的方面。为此,阿里云推出了基于 ESSD 云盘的云上企业级存储,帮忙用户更好的满足以后数字化转型和翻新的须要。 ESSD 企业级云盘ESSD 云盘为用户提供高可用、高牢靠、高性能的块级随机拜访服务,并提供原生快照数据保护和跨域容灾等丰盛的企业个性。它于 2016 年启动我的项目, 基于盘古 2.0 分布式存储底座,采纳 RDMA 和 NVMe SSD 全用户态 IO 技术,并联合阿里 10 多年分布式存储自研技术积攒, 在 2017 年首次亮相阿里“双11”购物节,承载数据库和中间件等外围业务局部峰值流量,获得了惊艳的体现;于是在 2018 年开始在阿里外部大规模推广应用,并开始凋谢给局部内部客户应用,都获得了十分踊跃的反馈;在 2019 年 ESSD 云盘大规模商业化,率先率领云盘进入了微秒时代; 2020 年推出普惠型规格 ESSD PL0,让中小客户也能获取 ESSD 全闪技术的红利;到 2021 年 9 月,ESSD 云盘曾经在 59 个可用区规模售卖, 95% 的阿里云头部客户抉择应用 ESSD, 成为最受欢迎的云盘产品。 作为云产品服务,ESSD 云盘提供服务化、平安、智能的运维管控服务,帮忙用户屏蔽了底层简单的硬件和零碎运维,以申明式凋谢 API 不便用户构建下层的业务零碎。同时,ESSD 云盘服务随着云的基础设施在寰球部署输入,无论是核心区域、还是本地云、边缘云,更好的满足用户多样化的部署需要。 ESSD 云盘为用户提供了三大方面的数据服务: 高稳固、高性能、高弹性的数据拜访服务, 轻量、实时、弹性的原生快照数据保护服务,随时随地、容灾多活服务。 在最根底的数据拜访方面,ESSD 云盘提供了 9 个 9 的高牢靠和 5 个 9 的高可用,并提供端到端的数据保护,百微秒低提早和百万 IOPS,反对自定义密钥加密、在线扩容和秒级性能变配。并且在近期公布按业务负载性能主动弹性伸缩的 ESSD Auto PL 云盘,反对 NVMe 标准协议和共享拜访, 以及满足平安合规物理隔离的专属集群。 ...

October 29, 2021 · 2 min · jiezi

关于阿里云开发者:跨越行业绊脚石阿里云函数计算发布-7-大技术突破

简介:2021 云栖大会现场,阿里巴巴研究员、阿里云智能云原生利用平台总经理 丁宇(叔同)重磅公布了函数计算的 7 大技术创新和冲破,减速古代利用架构的变革。Serverless 的实质是通过屏蔽底层的计算资源,来实现业务层开发的专一度和自由度。但越是往上形象,云厂商在底层的实现就越是简单。函数计算将服务进一步拆分到函数的颗粒度,这势必会给开发、运维、交付等带来新的挑战,例如如何对函数进行端云联调、如何对函数进行可观测和调试、如何优化 GB 级别的镜像冷启动?这些以往在服务的颗粒度时,都不是问题的事件,成了 Serverless 大规模落地企业外围生产业务的绊脚石。 2021 云栖大会现场,阿里巴巴研究员、阿里云智能云原生利用平台总经理 丁宇(叔同)重磅公布了函数计算的 7 大技术创新和冲破,减速古代利用架构的变革。 Serverless Devs 2.0:业内首发 Desktop,反对端云联调、多环境部署开源近一年, Serverless 开发者平台 Serverless Devs 2.0 版本正式公布。相比 1.0 ,2.0 在性能、应用体验实现全方位晋升,业内首发桌面客户端 Serverless Desktop,对桌面客户端进行了精密设计兼具美感和实用主义,具备更强的企业级服务能力。 作为业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理的平台,Serverless Devs 致力于为开发者打造 Serverless 利用开发一站式服务,Serverless Devs 2.0 提出多模式调试计划,包含买通线上线下环境;本地对接线上环境并进行调试的端云联调计划、本地间接进行开发态调试的本地调试计划、以及云端运维态调试的在线调试/近程调试计划等。新版本减少多环境部署部署能力,Serverless Devs 2.0 已反对一键部署框架 30 余种,包含 Django,Express,Koa,Egg,Flask,Zblog,Wordpress 等。 业内首发实例级别可观测和调试实例是函数资源最小的可被调度的原子单位,类比容器的 Pod。Serverless 将异构根底资源高度形象,因而“黑盒问题”是 Serverless 大规模遍及的外围落地之痛。业内同类产品均没有透出“实例”概念,也从未在可观测性能中将 CPU、内存等指标透出,但可观测就是开发者的眼睛,没有可观测,何谈高可用呢? 函数计算重磅公布实例级别可观测能力,对函数实例进行实时监控和性能数据采集,并进行可视化展现,为开发者提供函数实例端到端的监控排查门路。通过实例级别指标,您能够查看 CPU 和内存应用状况、实例网络状况和实例内申请数等外围指标信息,让“黑盒”不黑。同时,函数计算将通过凋谢局部实例登录权限,做到既能观测,还能调试。 业内首发固定数量、定时、水位主动伸缩的实例预留策略函数计算冷启动受到多个因素影响:代码和镜像大小、启动容器、语言运行时初始化、过程初始化、执行逻辑等,这依赖用户和云厂商的双向优化。云厂商会主动为每个函数调配最合适的实例数量,并进行平台侧的冷启动优化。但对于某些在线业务时延十分敏感,云厂商无奈代替用户进行更深层的业务优化,如对代码或依赖进行精简、编程语言的抉择、过程的初始化、算法优化等。 业内同类产品广泛是采纳预留固定实例数量的策略,即让用户配置 N 个并发值,除非手动调整,否则在调配了 N 个实例后不会再伸或者缩。这种计划只解决了局部业务高峰期的冷启动延时,但大大增加了运维老本和资源老本,对红包大促等带有不定期峰谷的业务,其实并不敌对。 因而,函数计算率先将局部实例资源的调度权限授予用户,容许用户通过固定数量、定时伸缩、按水位伸缩、混合伸缩等多维度的实例预留策略,来预留适量函数实例,别离满足业务曲线绝对安稳(如 AI/ML 场景)、峰谷时间段明确(如游戏互娱、在线教育、新批发等场景)、突发流量无奈预估(如电商大促、广告等场景)、业务混淆(如 Web 后盾、数据处理等场景)等不同场景的诉求,从而升高冷启动对时延敏感型业务的影响,真正实现弹性和性能兼顾的终极目标。 业内率先推出 GPU 实例函数计算提供弹性实例和性能实例两种实例类型,弹性实例规格从 128 MB 到 3 GB,隔离粒度做到了整个云生态最细,能真正实现普适场景下资源利用率 100%;性能实例规格区间范畴蕴含 4 GB、8 GB、16 GB 和 32 GB。资源下限更高,次要实用于计算密集型场景,如音视频解决、AI 建模和企业级 Java 利用等场景。 ...

October 29, 2021 · 2 min · jiezi