阿里云开发者

简介：2021年，云栖大会曾经步入第13年，从最后站长大会，到寰球顶级的科技盛会，云栖大会先后带来了达摩院、平头哥、含光芯片、城市大脑、小蛮驴、无影云电脑等诸多重磅公布。而往年的云栖大会，又会带来什么新惊喜呢？2021杭州·云栖大会，定了！ 10月19日-22日，就在杭州云栖小镇 2场重磅主论坛上百场分论坛 超4万平米科技展 首次收费凋谢！ 2021年，云栖大会曾经步入第13年，从最后站长大会，到寰球顶级的科技盛会，云栖大会先后带来了达摩院、平头哥、含光芯片、城市大脑、小蛮驴、无影云电脑等诸多重磅公布。 ↓往届云栖大会精彩回顾↓ 往年，云栖大会将回归线下会场，全面降级！ 大会设置两场主论坛和超过100场分论坛，将与数百位行业和技术领军人独特探讨前沿科技议题和产业数字化。同时超4万平米科技展将展出上千款科技新品。 看云原生最新进展，来云原生峰会2020年咱们认为是云原生实战的元年，越来越多的企业开始关注云原生在企业的落地。这个词在云计算畛域逐渐走到聚光灯下，成为以后的热词之一。各行各业正在切实通过云原生将企业的数字化转型带入“快车道”。  2020年，阿里云提出“云原生是企业数字翻新的最短门路”，自从该理念被提出当前，深受产业界关注和探讨。往年5月，阿里云提出云原生推动全云开发与实际，开启了全云开发的时代。 阿里云在云原生畛域有哪些重要的技术、产品、计划的最新公布？10月21日，云栖大会-云原生峰会将全面介绍云原生产业动静、云原生产品停顿、云原生行业实际等，为大家带来一场年度最全面的云原生盛宴。 看点一：阿里巴巴研究员、阿里云云原生利用平台负责人丁宇将从云原生产品技术升级角度，全面介绍容器、Serverless、技术中台等产品新个性。 看点二：多位企业CEO、技术负责人将带来云原生产业最新实际。企业的业务场景简单，随着业务需要的降级，对云原生技术和产品的需要必将更深更广，多位技术负责人将基于本身实战经验，从企业理论的需要登程，全面解读云原生转型降级历程。 看点三：阿里云云原生的生态搭档也将齐聚峰会，公布云原生生态产品集成和最佳实际，共建云原生产业生态，让云原生走进更多企业，发明更大的价值。 扫码报名参会 报名云栖大会，参加抽奖流动 为回馈所有阿里巴巴云原生公众号的粉丝，为行将到来的云栖大会预热，咱们设置了报名参会就有机会参加抽奖的流动。 抽奖流程小tip： Step1：通过长按辨认上文【邀请函】中二维码信息或下方【门票申领二维码】，返回【2021云栖大会-企业互联网架构分论坛领票页面】进行门票申领报名，实现报名后肯定要截图哦！！两个分论坛都能够报名。 Step2：增加小助手微信号并发送门票申领胜利的截图。 Step3：通过小助手发给你的抽奖链接实现以下操作取得抽奖资格哦。 10月，咱们杭州云栖大会见！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：本文次要论述 CDS 产品中 OSS 服务在容灾方面的部署状态以及实现的其本原理。 容灾性能能够保障用户一份数据在多个中央存在冗余备份，当某个机房呈现极其异样（比方物理损毁）状况下，数据也不会呈现失落；也能够保障当某个机房呈现不可用（比方断电）时，用户向外提供的性能也根本不受影响。前言对象存储服务（Object Storage Service，OSS）是阿里云推出的一种海量、平安、低成本、高牢靠的云存储服务，适宜寄存任意类型的文件；容量和解决能力反对任意弹性扩大，并提供多种存储类型以供选用户依据本人的业务个性去抉择，能够帮忙客户全面优化存储老本；提供数据持久性可达到 99.9999999999%(12个9)，可用性可达 99.995%。 为了更好的将私有云的这种线上能力输入到线下，让线下客户也能享受到上述微小的技术红利；同时，也为了帮忙线下客户无效的升高硬件部署老本，阿里云推出了 Cloud Define Storage(CDS)。本文次要论述 CDS 产品中 OSS 服务在容灾方面的部署状态以及实现的其本原理。容灾性能能够保障用户一份数据在多个中央存在冗余备份，当某个机房呈现极其异样（比方物理损毁）状况下，数据也不会呈现失落；也能够保障当某个机房呈现不可用（比方断电）时，用户向外提供的性能也根本不受影响。 容灾原理OSS 蕴含一个十分重要的后盾服务即数据复制服务 DRS（Data Replication Service）。当用户为 Bucket 开明了数据复制服务时（每一个数据复制服务的规定咱们称之为复制边）,每当用户上传一个文件， DRS 服务都会收到告诉，而后 DRS 服务会主动异步的将该文件“搬运”到数据复制规定中的目标端，整个过程对用户齐全通明，用户无需干预。 上图是一个跨区域复制的例子，用户为源 Bucket 开明了数据复制服务并配置好了目标端 Bucket 后，DRS 会主动将数据从源 Bucket 复制到指标端 Bucket。 部署架构简略介绍一下 CDS 线下部署的物理概念。从大到小逐层顺次为Cloud(云)、Region(地区)、AZ(可用区)、Cluster(集群)，Bucket(桶)。能够用图阐明如下。里面一层能够包含一个或者多个外面一层。 上面以一朵云上面的多 Region 部署架构更为具体阐明，同一个 Region 外部的两个集群 Bucket 之间能够做同城容灾，两个不同 Rregion 外部的两个集群 Bucket 之间能够做异地容灾。 容灾状态依据用户不同的容灾场景需要，OSS 提供了不同的容灾状态，次要分为同城容灾，异地容灾(跨区域复制)，跨云复制和两地三核心 四种场景。当初别离一一介绍他们的特点。 1、同城容灾同城容灾的零碎架构如下所示： 集群 A 和集群 A' 别离部署在同一个 Region 的两个 AZ，集群布局时候这两个集群就被布局成互为容灾集群。当在任何一个集群创立 Bucket 时候，后盾都会为这个 Bucket 在两个集群之间开明好双向的数据复制边（也就是两条复制边），数据通过 Bucket 写入到任意一个集群，都能被 DRS 主动异步的复制到另外一个集群。当 Bucket所在的以后集群产生故障时候，能够通过运维平台一键切换将 Bucket 以后所在的集群切换到另外一个集群。因为 Bucket 的名字雷同，用户拜访 OSS 服务的 Endpoint 也雷同，因而用户不须要批改拜访 OSS 的域名；整个切换过程对用户通明，基本上不会影响到用户的业务。 ...

简介：全新公布的云定义存储 CDS 和传统的存储阵列、分布式存储、软件定义存储的区别在哪里？阿里云存储团队如何对待未来存储的发展趋势？本文邀请了 CDS 研发团队的核心技术负责人为大家揭开围绕着阿里云 CDS 的种种谜团。云定义存储（CDS: Cloud Defined Storage）正式公布在 2021 年中秋与国庆之际，阿里云存储团队公布了全新的云定义存储 CDS。 这次公布的 CDS 1.0 版本，基于阿里云飞天操作系统和分布式存储底座盘古，是业界首次同时反对对象存储服务 OSS、块存储服务 EBS、日志服务 SLS和灾备服务 HBR，特地是通过盘古全新的QoS框架反对对象存储服务 OSS 和块存储服务 EBS 服务交融部署在同一套物理服务器下面。这次公布的存储服务与公共云上规模化的存储服务做到了代码版本基本一致，弥合了以往混合云版本和公共云版本差距比拟大的问题，让客户可能享受到和公共云基本一致的性能。 阿里云存储团队为什么要公布 CDS? CDS 和当初传统的存储阵列、分布式存储、软件定义存储的区别在哪里？阿里云存储团队如何看未来存储的发展趋势？在这里，咱们 CDS 研发团队的核心技术负责人们会通过一系列的技术文章为大家揭开围绕着阿里云 CDS 的种种谜团。 为什么要开发云定义存储？业务的需要从阿里云存储在 2016 年底成立混合云存储 HCS（Hybrid Cloud Storage）部门以来，内外部业务对规模配置灵便和性能有竞争力的分布式存储产品的需要始终都不少。过后综合思考产品研发的投入，阿里云在混合云市场尚且缺乏经验，以及国内市场参加厂商比拟多和竞争强烈等多方面因素，咱们制订的策略是以专有星散成的分布式存储、阵列、灾备一体机等联合起步，先进入传统存储市场的不同细分畛域试水，为阿里云理解和摸索这个市场，储备教训和弹药。 自 2018 年开始，随着 IT 基础设施云化的节奏放慢，基于云的基础架构或者数据中心曾经成为政企客户的首选计划，给新的存储厂商特地是软件定义存储厂商带来了微小的市场机会，同时随着阿里云在混合云市场的倒退，对阿里云存储在混合云场景输入的要求越来越低落，于是存储团队在 2019 年开始正式启动相干产品的布局、设计和开发。 艰巨的决策在把指标聚焦在分布式存储和 SDS 的方向当前，通过剖析和钻研，咱们发现国内 SDS 产品的的同质化很重大，咱们如果脱离公共云技术栈重整旗鼓搞一个相似的产品难以构建长久的外围竞争力，同时从技术和工程角度讲，公共云和专有云两套产品架构并行开发，会造成微小资源节约，很多类似个性都须要在不同产品上从新做一遍，而且因为架构束缚还不能保障都能反对。最初咱们决策启动混合云分布式存储 SDS 的自研，技术上保持公共云和混合云 CDS 共享同一套技术和代码，放弃公共云存储服务的弹性、扩大能力和服务托管的差异化竞争力，同时踊跃补齐企业存储的高级个性。因而混合云 CDS 的架构、性能和用户体验都是和公共云保持一致的， 这也是咱们这里所说的云定义存储的“云定义”的由来。 接下来，咱们顺次介绍一下软件定义存储的特点、云定义存储和软件定义存储的区别。 软件定义存储软件定义存储的起源软件定义存储（SDS：Software Defined Storage）的说法最早见于 2012 年 VMware 和 EMC 推动软件定义数据核心（SDDC：Software Defined Data Center）的一系列市场战斗，后续一众数据中心/服务器/存储厂商也跟进了这个定义，大家的策略是为了应答越来越显著的企业上云的诉求，以及 AWS/Azure 云计算厂商带来的压力和竞争，于是面向云计算从新定义了企业数据中心和存储的门路和方向。当年 SDS 最热的一段历史过程如下图所示： ...

简介：服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。Dubbo3.0 是 Dubbo2.0 与 HSF 交融而来，是阿里经济体面向外部业务、商业化、开源的唯一标准服务框架。服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。 Dubbo3.0 是 Dubbo2.0 与 HSF 交融而来，是阿里经济体面向外部业务、商业化、开源的唯一标准服务框架。 阿里巴巴服务框架的抉择与实际Dubbo 和 HSF 在阿里巴巴的实际Dubbo 和 HSF 都是阿里巴巴目前在应用的微服务 RPC 框架。 Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。Dubbo 我的项目诞生于 2008 年，起初只在一个阿里外部的零碎应用；2011 年，阿里 B2B 决定将整个我的项目开源，仅用了一年工夫就播种了来自不同行业的少量用户；2014 年，因为外部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3.0 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴募捐至 Apache 毕业的我的项目。 HSF 在阿里巴巴应用更多，承接了外部从单体利用到微服务的架构演进，撑持了阿里历年双十一的安稳运行；自 2008 年 5 月公布第一个版本 1.1 后，经验数年迭代，HSF 从一个根底的 RPC 框架逐步演变成为日撑持十万亿级别调用的易于扩大的微服务框架。外部场景中，用户既能够抉择大量配置轻松接入微服务体系，获取高性能的稳固服务调用。也能够依照本身业务需要，对 HSF 进行扩大，获取整条链路的能力加强。 对于团体内的需要而言，稳固和性能是外围，因而，过后选型了在电商这种高并发场景久经考验的 HSF 做为新一代服务框架外围。随后，HSF 推出了 2.0 的版本，并针对 HSF 之前版本的次要问题进行重构革新，升高了保护老本，进一步提高了稳定性和性能。HSF2.0 解决了通信协定反对不通明，序列化协定反对不通明等框架扩展性问题。基于 HSF2.0 的 Java 版本，团体内也演进出了 CPP/NodeJs/PHP 等多语言的客户端。因为 HSF 还兼容了 Dubbo 的协定，原有的 Dubbo 用户能够平滑地迁徙到新版本上，所以 HSF 推出后很快就在团体全面铺开，部署的 server 数量达到数十万，根本实现了阿里巴巴外部微服务框架的对立，并经验了多年双十一零点流量洪峰的验证。 ...

简介：当下，Serverless 概念很火，很多同学被 Serverless 的劣势吸引过去，比方它的弹性伸缩，免运维，高可用，资费少。但真正应用起来去落地的时候发现问题很多，大型项目如何组织函数，性能优化怎么做，怎么做Serverless调试，数据库，共享会话怎么加等等。上周，Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升。本文以 Serverless Devs 的利用核心（web 版)为案例，来看开箱实际计划。当下，Serverless 概念很火，很多同学被 Serverless 的劣势吸引过去，比方它的弹性伸缩，免运维，高可用，资费少。但真正应用起来去落地的时候发现问题很多，大型项目如何组织函数，性能优化怎么做，怎么做Serverless调试，数据库，共享会话怎么加等等。上周，Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升。接下来，以 Serverless Devs 的利用核心（web 版)为案例，来看开箱实际计划。 Serverless 函数代码组织如果想充分利用 Serverless 的能力函数是最佳计划，能够最大水平缩小冷启动工夫，践行用完即走的理念，保障用户体验的同时，最大水平缩小老本，不过对于中大型项目而言，以单函数的形式组织代码，在保护上无疑是一个微小挑战，可能一个利用会有数百个函数，保护老本极高也极易出错。 最好的形式是用框架的形式组织代码，以函数的形式部署执行。框架组织代码须要做业务的划分，比方电商蕴含商品，订单，用户等服务，都放到一个框架外面并通过函数去部署执行的话显著太大了。最好就是像微服务一样，独立业务的接口能够在同一个函数中，每一个业务有本人的独立域名，再通过外部路由拜访具体的业务服务。 这样做能够最大限度的利用函数能力，并且保护得来绝对容易一些。 咱们把 Serverless Hub 的利用市场作为一类场景，进行了对立划分，具体的函数调用如下实现(残缺的代码目录 git) const { http } = require('@serverless-devs/dk');const { searchApp, getAppDetail, getSpecialDetail, getSpecialApp, getCategorys, getTags } = require('./services');http .get("/appCenter/getSpecial", async (ctx) => { const data = await getSpecialApp(ctx); ctx.body = data; }) .post("/appCenter/getSpecialDetail", async (ctx, next) => { const data = await getSpecialDetail(ctx); ctx.body = data; }) .post("/appCenter/getAppDetail", async (ctx) => { const data = await getAppDetail(ctx); ctx.body = data; }) .get("/appCenter/getCategory", async (ctx) => { const data = await getCategorys(); ctx.body = data; }) .get("/appCenter/getTags", async (ctx) => { const data = await getTags(); ctx.body = data; }) .post("/appCenter/getApps", async (ctx) => { const data = await searchApp(ctx); ctx.body = data; }) .get("/", async (ctx, next) => { let result = "Hello ServerlessDevs"; ctx.body = result; })http.app.use(http.routes());exports.handler = http();代码应用了 Serverless Devs 提供的 @serverless-devs/dk ，咱们对规范的前端框架进行了外围封装，比方 express,koa 等，你能够持续应用习惯的 web 框架进行开发工作，最初通过 s 工具进行函数部署。s.yaml 的配置如下： ...

简介：本文以大量实践阐述解析业务，并提供多种基于不同场景的实操办法，帮忙技术同学以迷信、正当的形式发展日常工作、领导团队开展业务建设，保障顶层设计的落地执行。一. 背景目前曾经公布《技术一号位的方法论》系列文章其实能够分为两大类，第一类是围绕技术一号位这一角色自身开展探讨，剖析了其工作职责和工作内容涵盖的范畴，同时也剖析了一般技术人员如何扭转认知，尝试以该角色的心态发展工作。第二类文章偏实践阐述，集体认为这部分文章其实是整个系列最重要的局部，咱们能够把它视为“实践篇”。实践篇相干的文章是基于马克思主义哲学原理，给出了技术一号位在解决日常工作中必须把握的最重要的基础理论，例如如何剖析事务的实质，解决问题的法则，业务、组织、技术的常见法则有哪些等等，这些实践是后续所有的实践和实际发展的终点。 接下来咱们要开始探讨业务相干的内容，咱们把所有探讨业务相干的文章，对立称之为“业务篇”。 本篇文章作为“业务篇”的开篇文章，次要有以下三个目标： 第一个目标，是浅谈什么是业务，心愿能让读者理解业务的实质是什么，从各种维度和视角全面认知业务。 第二个目标，是心愿可能通过本文，理清信息化技术和业务的关系，从而看到信息化技术在业务发展过程中施展的次要作用是什么，将来的发展趋势是什么。 最初一个目标，就是心愿可能通过相干内容的思考和探讨，最终造成一些根本的认知，而后基于这些根本的认知来构建出技术一号位在宏观的场景和方向上的行为准则，从而从宏观层面领导具体的实际行为。 因为笔者打算尽量把一些实践的、宏观的货色在“业务篇”的开篇文章讲清讲透，实现相干的铺垫，因而本文会波及大量实践阐述，略显干燥。当然，在后续的文章中，笔者会提供一些能够实操的办法，例如如何定制业务指标、如何画业务大图、如何基于业务大图构建技术大图，如何基于业务技术大图开展业务或技术战斗等等，心愿通过提供这些办法，帮忙技术同学以迷信、正当的形式发展日常工作、领导团队开展业务建设，保障顶层设计的落地执行。 二. 所有要从人的实质说起1、看清实质在探讨业务之前，咱们须要先思考几个问题：业务为什么会存在？它是怎么产生的？它会隐没吗？ 想要搞清楚这些问题，咱们不能只把眼光集中在业务上，而是要把眼光转移，从新聚焦在“人”上。当咱们搞清楚了人的实质是什么，咱们天然能看到业务是怎么产生的，它存在的意义是什么，它会不会隐没。 咱们依然是以马克思主义哲学为探讨根底，一起看下在哲学上，人的实质是什么： 以下援用原始起源：《甘肃社会科学》2015年第6期——《马克思对于人的实质的四重含意及其现实意义》，作者：张国安__残缺文字版本：马克思主义钻研网—— 张国安：马克思对于人的实质的四重含意 第一，人的实质是人本身。马克思在《〈黑格尔法哲学批评〉导言》（下称《导言》）中批评了宗教对于人的空幻实质，马克思认为：人不是脱离尘世的存在物，人就生存在人的世界，人生存在国家、社会中。 马克思在《导言》中揭示了人是人的实质这一重要概念的真正外延，即“人的根本就是人自身……对宗教的批评最初归结为人是人的最高实质这样一个学说，从而也归结为这样的相对命令：必须颠覆使人成为被羞辱、被奴役、被遗弃和被藐视的货色的所有关系”。 上述马克思对于人的实质的阐述阐明人的实质不是宗教，而是事实的人，他超过了德国哲学形象的人以及费尔巴哈丢掉人的社会实质而仅仅强调人的天然实质的观点，而以人的“国家特质”“社会实质”来阐明人，把人从神的统治和奴役下解放出来，把人的实质还原给人。 第二，人的实质是人的须要。马克思在《詹姆斯·穆勒〈政治经济学原理〉一书摘要》中屡次提到人的实质就是人的须要。在原始社会，没有私人财产，人也没有同化，这时人的“须要”天然体现为真正的人的实质，生产者生产的物品刚好满足他的须要，就是说需要和供应刚好相等，不存在盘剥和奴役，这种须要尽管简略，却反映了原始状态下人与人、人与自然的平等关系，人的实质没有被物所奴役、管制。 私有制的到来，人的须要产生同化，也就是人的实质产生了同化，原始社会状态下须要和生产是间接对立的，而私有制条件下生产与须要产生了裂变，每个人都须要别人的产品，依赖别人的产品，每个人都要思考他人的须要，用本人的剩余产品替换他人的生产品。 只有到了共产主义社会，人的须要才体现为人的真正实质，到那时，本人的产品不仅体现了本人的共性和特点，而且劳动者在劳动过程中是被动的、踊跃的、自在的，而不是被动的、消极的、被强制的，劳动成果既满足劳动者的须要，也满足其他人的须要，劳动过程自身能使劳动者感到高兴。他人享受本人的产品，咱们不仅不感觉被占有、盘剥，而且是一种高兴的享受。同样，咱们也享有他人的产品，而不是占有他人的产品，共产主义衰弱、健全的须要才体现为人的真正的社会实质。总之，马克思在多部著述中论述：人的须要的产生既受现实状况制约又有主观能动性；人的须要的满足过程是人意识、确证和实现本人的社会实质的过程；人的须要的对象，是体现、确证他的实质的重要对象，人的须要充沛地体现了人的社会性、历史性和过程性，也就充沛地体现了人的实质。 第三，人的实质是自在的无意识的劳动。人的最有代表性的流动，最能体现人与动物区别的流动就是劳动，特地是生产性的实际流动。 第四，马克思认为，“人的实质不是单个人所固有的形象物，在其现实性上，它是所有社会关系的总和。” 有的读者可能会对下面的“人的实质”的论断有一些质疑，没关系，实践就是这样，随着实际的深刻、随着工夫的变动都能够被改良。因而，受限于文章主题和笔者能力，本文笔者不会针对对于“人的实质”的质疑与读者进行进一步探讨，有疑难的读者能够寻找更业余的哲学钻研人士来发展相干的探讨。 从下面的对于“人的实质”阐述的文字，咱们能够总结为如下图内容： 图1 人的实质 从下面的总结能够看进去，从人的物质性角度来看，所有人类所有的事件都能够形象为两件事：“需要”和“满足需要”，也就是说，咱们每个人，不是在满足本人的需要的路上，就是在满足他人的需要的路上，咱们每个人做的每一件小事小事，不是在满足本人的需要，就是在满足他人的需要，如下图所示： 图2 人与需要 2、业务与人的实质的关系——业务的产生、存在和沦亡取决于人的实质理解了人的实质当前，咱们能够从宏观的视角探讨业务和人的实质的关系。 首先，业务是服务提供方满足需求方诉求的次要模式。从人的物质方面的实质登程来看，咱们很容易看到这样的演变过程：在一方面，人的某一类需要，在共性足够大的状况下，会造成市场，诞生了需求方；同时在另外一方面，人通过发明价值（劳动）满足他人的需要，诞生了服务提供方。如果以服务提供方作为叙事主体，从其视角来看，“服务提供方满足需求方”的整个过程就能够抽象地总结为“服务提供方在做某个业务”。当然，这里咱们没有开展详细描述服务提供者满足需求方的过程是如何由最开始的简略的物-物替换的模式，逐渐演变到当初“通过有组织地生产价值，有组织地保障价值交付过程、大量地应用更先进的技术晋升生成经营效率”等等这样简单的模式。简而言之，咱们没有开展谈业务的倒退过程，但这不影响咱们的论断——服务提供方是以“业务”的模式满足需求方的需要的，或者说，企业是以业务的模式服务于市场的。 其次，业务是服务提供方和需求方独特形成的对立统一体。尽管“做业务”的叙事主体是服务提供方，然而事实上，业务是二者的对立统一体，或者说，是业务实现了二者之间的连贯。业务“不是服务提供方一个人的事”，而是单方相互影响互相适应互相博弈的矛盾体，这是很多业务负责人非常容易漠视的一个最根底的事实。 当咱们从足够长的工夫维度来看业务，需求方与服务提供方通过动静的博弈过程逐渐促使单方都不断进步。这个过程用哲学术语来形容，就是单方在对立统一造成均衡的过程中，尽管可能某一方的外围利益诉求会被侵害，然而随着侵害水平的一直重大而逐渐激化彼此间的矛盾，然而对立的共同利益又会制约对抗的抵触的激化，对抗的激化水平在某一方扭转的前提下会趋于弛缓，如此周而复始。 所以说，如果对抗不是激化到了无奈维持对立的状况，那么业务最终会演变造成高层次的对立统一的场面，即：对立大于对抗，对抗尽管存在然而未被激化。在这个对立统一的动静过程中，当然会有需求方比服务提供方在单方博弈的过程中更占优势的状况，代表性的景象之一就是“买方市场”；也会有服务提供方比需求方在单方博弈过程中更有劣势的状况，代表性的景象之一就是“卖方市场”，然而最终的趋势肯定是单方的利益诉求都能被均衡、满足，造成共赢的场面。 最初，人的实质决定了业务的存在与否。需要呈现了，市场规模扩充，业务就随之呈现并扩充；如果需要隐没了，市场规模缩减了，也会导致业务的沦亡。所以咱们晓得，狭义的、形象的、共性的“业务”，产生于人的“需要和满足需要”这一关系的产生；存在于人的需要的存在；沦亡于人的需要的沦亡。当然更底层、更哲学的形容是：“业务”只是人的劳动的某种模式，人的“劳动”是业务的外在实质，也是人的物质方面的实质，这就是为什么说业务的生命周期取决于人的实质的，这里就不再持续展开讨论了。 从宏观的视角来看，一个具体的业务的生命周期，则取决于这个业务是否可能通过发明价值来满足客户的需要，并且整个过程必须造成可继续的闭环，在本大节咱们就不再展开讨论了。 这个问题也当做留给读者思考的题目，在看完整篇文章后，大家能够联合实践剖析和理论接触过的业务，剖析它的生命周期经验了哪些阶段，又在哪个环节出了问题，最终在什么环节走向沦亡。（就互联网行业而言，从业者应该见过太多做到一半被叫停的业务了，如果当初你不明确本人做的业务哪里有问题而被叫停了，那么心愿明天这篇文章能帮你找出其中的局部起因） 三. 业务的实质是什么上个章节咱们探讨了业务的由来，这个章节，咱们尝试着给业务进行一个全面的剖析，以探索业务的实质。同时依然和之前的“实践篇”一样，本文作为“业务篇”的开篇文章，会将“宏观的、狭义的、形象的业务”作为探讨的对象——钻研、阐述业务普遍存在的法则，即业务的共性，不谈业务的非凡状况，即业务的共性。 这样做的起因是取决于哲学上的“共性和共性的辩证关系”的。认知事物既要看到其共性，也须要看到其共性。从实际登程认知一个事物，通过接触、参加、感知失去的信息，都是具体的事物的共性的方面，然而这样的认知过程效率比拟低；而从实践登程认知一个事物，通过思考演绎、演绎、主观实践的剖析失去的信息，都是形象的事物的共性的方面，这样的认知过程效率比拟高，然而容易和理论有偏差，须要通过实际进行验证、修改。 基于下面的情理，本文之所以次要探讨业务的共性，一方面是因为业务的共性在数量上无穷无尽，在探讨的根底前提方面千差万别，如果想做捕风捉影的具体问题具体分析，那就须要大量的篇幅，本文的宗旨就会被冲散，无奈达到文章的次要目标；另外一方面是为了晋升读者掌握业务实质的效率，先将实践讲清楚，不便大家带着实践认知，联合本人的业务做实际测验，从而加深对业务共性的了解、对业务共性的深入研究。 那么接下来，咱们就依照之前的文章中提到的剖析事物本质的办法，对业务进行剖析。 1、定义一些人通过有组织的劳动，满足另外一些人的需要，从而获取回报，并可能继续运行上来的整个过程，能够统称为业务。 2、业务外部的主次矛盾剖析2.1 探讨的事物范畴划定咱们接下来探讨的“业务”，都是宏观的、狭义的业务，而不是某个具体的、特定的业务，期间可能会以某个具体的业务为例，然而探讨的也都是不同业务间的共性局部。 2.2 业务的参与方及其角色和外围利益诉求2.2.1 狭义的业务的参与方及其角色和外围利益诉求探讨狭义的业务的参与方，因为形象水平过高，所以可探讨的内容不多。不过这恰好可能让咱们看到业务的最底层的逻辑和外围准则是什么，并且这个准则是所有在其之上演化出的业务的根底准则，尽管日常工作中可能感知不到它的存在，但它最终在长期的事物演进过程中冥冥之中施展着最根本性的作用。所以这部分看似简略，却是最容易被疏忽的，也是最不应该被疏忽的。 客户：集体或一类人，以市场的状态呈现角色：需求方，消费者外围利益诉求：以尽可能低的价值付出，失去需要的满足；或者以适合的价值付出，失去高水平的需要满足。企业：集体或一群人，常以组织的状态呈现角色：服务提供方，生产者外围利益诉求：将本人的劳动后果尽可能多的换取想要的价值，这一过程尽可能短暂价值载体：满足需求方需要的事物，常以狭义的商品的状态呈现角色：狭义的商品（蕴含物质的商品，也蕴含虚构的服务等）外围利益诉求：价格体现价值2.2.2 特定的业务参与方及其角色和外围利益诉求不同的具体的业务大类，具备明确的、显明的业务模式，在需求方或服务提供方或价值载体上，有其独特性，并且这种独特性，形成了此业务与彼业务的实质差别。咱们以几个例子来看，例如最宏观的，农业、工业、建筑业、服务业、信息化产业等，咱们做软件研发的技术同学，接触最多的其实是服务业中的信息化产业，外面持续细分有面向C的社交、电商、广告、视频、游戏等等，面向B的软件服务业务。以大多数技术人员都相熟的电商业务为例，咱们简略剖析一下业务的参加各方： 电商业务参与方： 买家：个别是C端用户角色：消费者，买商品的人或企业外围利益诉求：买的称心（可能是享受到足够的优惠才会称心，也可能是买到高品质的商品才会称心，也可能是购物过程享受到贴心的服务才会称心，也可能是购物过程平安、隐衷失去爱护而称心）买家：个别是有货的商户或公司角色：商家，能够是商品生产者，也能够是商品分销者外围利益诉求：卖出更多的商品，并且晋升利润率，放弃继续盈利买家：个别是电商平台角色：交易场合外围利益诉求：实现更多成交量，升高业务发展过程中的老本、进步业务效率，俗称降本提效，放弃业务继续盈利金融领取机构：个别是电商平台自带的领取服务角色：领取服务提供方外围利益诉求：降本提效，继续盈利物流服务：个别是物流公司或物流服务平台商品履约（交付）服务外围利益诉求：降本提效，继续盈利2.2.3 业务参与方的辩证了解——从简略的二元对抗到业务生态的多元博弈和共赢从上两节的内容咱们能够看到，从“狭义的业务”到“某一个具体的业务”（本文中是电商业务），业务的参与方从高度形象的、简略的 “需求方”、“服务提供方”两个，丰盛、收缩为“买家、卖家、平台、物流公司、领取机构”等等参与者，这些参与者贯通业务发展的各个环节，别离代表了业务发展过程中必不可少的简单的子业务。这个参与方由形象的“少”，变为具体的“多”的过程，实际上体现了一个业务从简略到简单的倒退过程，同时也是一个业务逐渐演变为不同的其余的业务的过程。 比方在电商呈现之前，人货场都是在固定的、具体的物理场合内产生互动关系。咱们以30年前的村里的小卖店为例，大家买货色都是一手交钱一手交货，所以“物流”、“领取机构”并不是传统售卖行业中的重要参与者。然而到了电商业务状态中，领取机构的服务作为用户为商品付费的根底、物流作为商家向消费者交付商品的根底，重要性产生了天翻地覆的变动。同时咱们再察看电商业务本人的倒退过程，最开始的领取、物流都是被电商平台“包圆”的，而随着业务规模和业务复杂度的倒退，过来涵盖在电商平台内的领取服务演变成了对外开放的、服务多方的独立业务；物流服务也走了同样的门路。 咱们能够看到这样的法则：过来做业务，从简略的供需双方的利益诉求的对立统一，变成了多方的利益诉求的对立统一过程，越简单的业务模式，要均衡的参与方就越多，遇到的阻力和艰难就越大，也越难以造成高层次的对立场面。以咱们明天接触到的大多数业务，其实都是大的业务中蕴含着若干个重要的子业务，波及到了多种业务参与方的外围利益诉求，所以业务不再是简略的二元对抗，而是业务生态内各参与方的多元博弈和共赢。 晓得这个信息有什么用呢？一方面是让当初所有的业务决策者要造成清晰地认知：以目前的社会化大生产的大背景，做业务最终是在做业务生态，即解决了业务自身的生存问题之后，业务上下游的其余业务、其余生产者和消费者曾经造成了一个“生态环境”，这个环境须要被治理、须要通过正当的准入和清退汰换保障机制造成良性的运行机制。另外一方面，从哲学的角度答复了为什么有些简单的业务“不好做”，从而让咱们认清简单业务不好做的基本面的状况下，来思考均衡各方利益诉求的时候，最根本的准则是什么，这是最重要的。 咱们仍旧是以电商业务为例，作为电商平台，以保障商家的利益为主，还是以保障消费者的利益为主？二者的利益呈现抵触的时候，如何做好均衡？理论生存中，当这种状况实在呈现的时候，电商平台真的是依照现实的形式去均衡二者的利益吗，还是就义了某一方的利益？其余业务也存在同样的问题，咱们看到日常工作中很多业务的决策呈现了偏差，带来了负面的影响，究其根本原因，就是在做决策时没有答复好这个问题的缘故，或者说可能都没有思考过这个问题就做出了想当然的决策。对于这个问题，咱们会在下一个大节会给出答案。 2.3 业务各参与方的对立统一剖析基础理论：在探讨业务参加各方的对立统一剖析之前，咱们先明确一个根底法则，即解决以后事物的主要矛盾次要矛盾的办法，要合乎该事物所隶属的父事物的主要矛盾次要矛盾的束缚，否则就会在该事物所隶属的父事物的主要矛盾次要矛盾发生变化当前，反过来对该事物产生负面的影响。 例如中国近代社会的主要矛盾次要矛盾是和世界的主要矛盾次要矛盾非亲非故的，国内的主次矛盾随着国内环境的主次矛盾的变动而变动，从而形成了两次国共合作的前提。那些违反了大环境的主次矛盾演变法则的行为，最终都是失败的。以第二次国共合作为例，过后的国内大环境的主要矛盾是反法西斯奋斗，而国内国民党的一些反共行为是出于其阶层角色的利益消极抗日踊跃反共，疏忽国内大环境主要矛盾、对国内主要矛盾没有正确的认知导致的，所以最终是失败的（当然，失败的起因不止这一个，不展开讨论了）；反观过后我党的认知和行为，将过来的反帝反封建的主要矛盾，调整为反法西斯帝国主义入侵的主要矛盾，踊跃推动国共合作，团结所有能够团结的力量，构建抗日民族统一战线，踊跃抗日，所以最终获得了反侵略和平的胜利（当然胜利的起因不止这一个，不展开讨论了）。 在剖析业务各参与方的对立统一时，咱们依然别离探讨狭义的、共性的业务参与方和广义的、个性的业务业务参与方，如下所示： 共性局部的对立统一剖析 狭义的业务的组成，能够形象为下图： 图3 狭义业务的状态 这个对立统一关系中的主要矛盾是需求方的需要是否可能被满足，次要矛盾是业务是否能长久运行上来。也就是说，最重要的是客户的外围利益诉求，其次重要的是业务的组织的外围利益诉求。这是所有业务，不论是什么行业、什么状态的业务的共性，和最根底的准则。这也是阿里秉承的一句话“客户第一、员工第二”在哲学上理论依据。 留神，这里并不是因为有这句话，所以有这个实践剖析，而是这个实践剖析的后果，恰好和之前的人提出的口号是雷同的。同时咱们也能看到，在狭义的、广泛的、共性的业务中，最重要的两个关系，一个是客户关系、另外一个就是组织关系，即组织是业务的发展的主体，这部分关系咱们会在后续的“组织篇”外面详细分析阐明，这里不再开展，感兴趣的读者能够联合“实践篇”中提到的组织、业务、技术的法则自行思考。 共性局部的对立统一剖析 某一个特定的业务的组成，能够形象为下图： ...

简介：Getty 保护团队不谋求无意义的 benchmark 数据，不做无意义的炫技式优化，只依据生产环境需要来进行本身改良。只有保护团队在，Getty 稳定性和性能定会越来越优良。集体从事互联网基础架构零碎研发十年余，包含我本人在内的很多敌人都是轮子党。 2011 年我在某大厂干活时，很多应用 C 语言进行开发的共事都有一个本人的私人 SDK 库，尤其是网络通信库。集体刚融入这个环境时，感觉不能写一个基于 epoll/iocp/kqueue 接口封装一个异步网络通信库，会在共事背后矮人三分。当初想起来过后很多共事很大胆，把本人封装的通信库间接在测试生产环境上线应用，据说那时候整个公司投入生产环境运行的 RPC 通信库就有 197 个之多。 集体过后消耗两年周末休息时间造了这么一个私人 C 语言 SDK 库：大部分 C++ STL 容器的 C 语言实现、定时器、TCP/UDP 通信库、输入速度可达 150MiB/s 的日志输入库、基于 CAS 实现的各种锁、躲避了 ABA 问题的多生产者多消费者无锁队列 等等。本人过后不懂 PHP，其实略微封装下就能够做出一个相似于 Swoole 的框架。如果始终保持写下来，可能它也堪媲美老朋友郑树新老师的 ACL 库了。 本人 2014 年开始接触 Go 语言，通过一段时间学习之后，发现了它有 C 语言一样的特点：根底库太少 -- 又能够造轮子了。我清晰地记得本人造出来的第一个轮子每个 element 只应用一个指针的双向链表 xorlist【见参考 1】。 2016 年 6 月我在做一个即时通讯我的项目时，原始网关是一个基于 netty 实现的 Java 我的项目，起初应用 Go 语言重构时其 TCP 网路库各个接口实现就间接借鉴了 netty。同年 8 月份在其上增加了 websocket 反对时，感觉 websocket提供的 onopen/onclose/onmessage 网络接口极其不便，就把它的网络接口改为 OnOpen/OnClose/OnMessage/OnClose ，把全副代码放到了 github 上，并在小范畴内进行了宣传【见参考 2】。 ...

简介：还在花精力去选型Kafka组件去做荡涤转化？来试试Kafka ETL工作性能！一说到数据孤岛，所有技术人都不生疏。在 IT 倒退过程中，企业不可避免地搭建了各种业务零碎，这些零碎独立运行且所产生的数据彼此独立关闭，使得企业难以实现数据共享和交融，并造成了"数据孤岛"。 因为数据散落在不同数据库、音讯队列中，计算平台间接拜访这些数据时可能遇到可用性、传输提早，甚至零碎吞吐问题。如果回升到业务层面，咱们会发现这些场景随时都会遇到：汇总业务交易数据、旧零碎数据迁徙到新零碎中、不同零碎数据整合。因而，为了能让数据更加实时、高效的交融并反对各业务场景，企业通常抉择应用各种 ETL 工具以达到上述目标。 因而，咱们能够看到企业自行摸索的各种解决方案，比方应用自定义脚本，或应用服务总线（Enterprise Service Bus，ESB）和音讯队列（Message Queue，MQ），比方应用企业应用集成（Enterprise application integration，EAI）通过底层构造的设计来横贯企业异构零碎、利用、数据源等，实现数据的无缝共享与替换。 只管以上伎俩都算实现了无效实时处理，但也给企业带来更难决断的选择题：实时，但不可扩大，或可扩大。但批处理。与此同时，随着数据技术、业务需要的一直倒退，企业对 ETL 的要求也一直晋升： 除了反对事务性数据，也须要可能解决诸如 Log、Metric 等类型越来越丰盛的数据源；批处理速度须要进一步晋升；底层技术架构须要反对实时处理，并向以事件为核心演进。能够看到，流解决/实时处理平台作为事件驱动交互的基石。它向企业提供了全局化的数据/事件链接、即时数据拜访、繁多零碎统管全域数据以及继续索引/查问能力。也正是面对以上技术与业务需要，Kafka 提供了一个全新思路： 作为实时、可扩大音讯总线，不再须要企业应用集成；为所有音讯解决目的地提供流数据管道；作为有状态流解决微服务的根底构建块。咱们以购物网站数据分析场景为例，为了实现精细化经营，经营团队以及产品经理须要将泛滥用户行为、业务数据以及其余数据数据进行汇总，这其中包含但不限于： 1. 用户各类点击、浏览、加购、登陆等行为数据； 2. 根底日志数据； 3. APP 被动上传数据； 4. 来自 db 中的数据； 5. 其余。 这些数据会集到 Kafka，而后数据分析工具对立从 Kafka 中获取所需的数据进行剖析计算。因为 Kafka 采集的数据源十分多且格局也各种各样。在数据进入上游数据分析工具之前，须要进行数据荡涤，例如过滤、格式化。在这里研发团队有两个抉择：（1）写代码去生产 Kafka 中的音讯，荡涤实现后发送到指标 Kafka Topic。（2）应用组件进行数据荡涤转换，例如：Logstash、Kafka Stream、Kafka Connector、Flink等。 看在这里，大家必定会有疑难：Kafka Stream 作为流式解决类库，间接提供具体的类给开发者调用，整个利用的运行形式次要由开发者管制，方便使用和调试。这有什么问题吗？尽管以上办法的确可能很快解决问题，但其问题也不言而喻。 研发团队须要自行编写代码，且须要前期继续保护，运维老本较大；对于很多轻量或简略计算需要，引入一个全新组件的技术老本过高，须要进行技术选型；在某组件选定后，须要研发团队进行学习并继续保护，这就带来了不可预期的学习老本、保护老本。 为了解决问题，咱们提供了一个更加轻量的解决方案：Kafka ETL 性能。 应用 Kafka ETL 性能后，只需通过 Kafka 控制台进行简略配置，在线写一段荡涤代码，即可实现 ETL 的目标。可能存在的高可用、保护等问题，齐全交由 Kafka。 那么接下来，咱们为大家展现如何疾速的创立数据 ETL 工作，仅需 3 步即可。 Step 1 : 创立工作抉择 Kafka 起源实例、起源 Topic，以及对应的抉择 Kafka 指标实例、指标 Topic。并配置音讯初始地位、失败解决以及创立资源形式。 ...

简介：针对需要，OpenKruise 在 v0.10.0 版本中新增了 WorkloadSpread 个性。目前它反对配合 Deployment、ReplicaSet、CloneSet 这些 workload，来治理它们上司 Pod 的分区部署与弹性伸缩。下文会深刻介绍 WorkloadSpread 的利用场景和实现原理，帮忙用户更好的理解该个性。背景Workload 散布在不同 zone，不同的硬件类型，甚至是不同的集群和云厂商曾经是一个十分广泛的需要。过来个别只能将一个利用拆分为多个 workload（比方 Deployment）来部署，由 SRE 团队手工治理或者对 PaaS 层深度定制，来反对对一个利用多个 workload 的精细化治理。 进一步来说，在利用部署的场景下有着多种多样的拓扑打散以及弹性的诉求。其中最常见就是按某种或多种拓扑维度打散，比方： 利用部署须要按 node 维度打散，防止重叠（进步容灾能力）。利用部署须要按 AZ（available zone）维度打散（进步容灾能力）。按 zone 打散时，须要指定在不同 zone 中部署的比例数。随着云原生在国内外的迅速遍及落地，利用对于弹性的需要也越来越多。各私有云厂商陆续推出了 Serverless 容器服务来撑持弹性部署场景，如阿里云的弹性容器服务 ECI，AWS 的 Fragate 容器服务等。以 ECI 为例，ECI 能够通过Virtual Kubelet对接 Kubernetes 零碎，给予 Pod 肯定的配置就能够调度到 virtual-node 背地的 ECI 集群。总结一些常见的弹性诉求，比方： 利用优先部署到自有集群，资源有余时再部署到弹性集群。缩容时，优先从弹性节点缩容以节省成本。用户本人布局根底节点池和弹性节点池。利用部署时须要固定数量或比例的 Pod 部署在根底节点池，其余的都扩到弹性节点池。针对这些需要，OpenKruise 在 v0.10.0 版本中新增了 WorkloadSpread 个性。目前它反对配合 Deployment、ReplicaSet、CloneSet 这些 workload，来治理它们上司 Pod 的分区部署与弹性伸缩。下文会深刻介绍 WorkloadSpread 的利用场景和实现原理，帮忙用户更好的理解该个性。 WorkloadSpread介绍官网文档（见文末相干链接一） 简而言之，WorkloadSpread 可能将 workload 所属的 Pod 按肯定规定散布到不同类型的 Node 节点上，可能同时满足上述的打散与弹性场景。 ...

简介：作为对原生 Kubernetes 生态齐全兼容的数据密集型利用运行撑持平台，Fluid 将向更灵便、智能、可扩大的架构方向倒退，一直晋升开发者和用户应用体验。将来，Fluid 将持续与社区并肩、与生态同行，致力于推动云原生技术在 AI 等畛域的生态建设与遍及，与寰球开发者一起拓展云原生的边界。作者 | Fluid开源社区 2021 年 9 月 17 日，在由中国信息通信研究院、中国通信标准化协会联结主办的“2021 OSCAR 开源产业大会”上，由阿里云云原生团队联结发动（其余联结单位包含：南京大学、Alluxio 社区）的开源我的项目 Fluid 荣获“ OSCAR 尖峰开源我的项目和开源社区”奖项；同时，作为 Fluid 我的项目的联结发起人和社区经营主席，来自南京大学 PASALab 的顾荣副研究员被评比为“开源人物”。 Fluid 于 2020 年 9 月正式对外开源。很多相熟 Fluid 的敌人都晓得，该项目标实质是一个云原生数据编排和减速零碎，于 2021 年 5 月正式成为 CNCF Sandbox 我的项目，帮忙业界欠缺在云原生 AI 畛域的一块重要幅员。 倒退不过短短一年工夫， Fluid  便一次取得两项开源界的重要认可，证实着其所专一的云原生、AI 畛域也正在迎来宽泛关注。这其中的意义和价值如何？咱们尝试管中察豹，从 Fluid 的倒退背景和实区实际聊表观点。 云原生 + AI，企业数字化翻新的循环引擎往年是十四五的开局之年。2021 年 3 月，新华社全文颁布了《中华人民共和国国民经济和社会倒退第十四个五年布局和2035年近景指标大纲》（以下简称“大纲”）。作为将来五年产业倒退、科技翻新等的重要口头纲领，大纲中有三个关键词分外引人关注：“人工智能”、“云计算”，和首次被列进布局的“开源”。 作为构筑数字经济的基础设施，云计算正像水电煤气一样，浸透至各行各业，用润物细无声来形容也毫不为过。近年来，以容器、微服务、DevOps 为代表的云原生技术，使云端弱小的服务能力失去充沛开释，减速了基础设施的麻利化，进一步实现企业生产效力的晋升，因为被喻为“企业数字化转型的最短门路”。 作为在信息基础设施上承载的次要资源，“数据”则能够看成是新型基础设施的“血液”。AI 技术与云计算的深度交融趋势, 也进一步对算力和利用架构提出了新要求。 回溯 AI 畛域次要技术框架的倒退，如 Spark，Hive，MapReduce ，为了缩小数据传输，其设计更多地思考数据本地化架构。但随着技术环境和利用需要的一直更迭，为兼顾资源扩大的灵活性与应用老本，计算和存储拆散的架构在云原生环境中逐步成为支流。这种计算存储拆散架构在晋升零碎弹性和灵活性的同时，也给 AI 等数据密集型利用带来了计算性能和管理效率方面的挑战。 为了解决现有云原生编排框架运行此类利用面临数据拜访延时高、多数据源联结剖析难、利用应用数据过程简单等痛点，阿里云云原生团队、南京大学、Alluxio 社区联结发动并开源的云原生数据编排和减速零碎 Fluid ，该我的项目于 2021 年 5 月正式被 CNCF 接收为 Sandbox 我的项目，减速数据密集型利用全面拥抱云原生。 ...

简介：第二届云原生编程挑战赛为酷爱技术的年轻人提供一个挑战世界级技术问题的舞台，心愿用技术为全社会发明更大价值。作者 | 刘欣 呃，我可能是他人眼中所说的不必奋斗的一代。 大家喜爱听的什么多姿多彩的生存，我都经验过一些些。 我家里开的是连锁超市，次要集中在几个二线城市。 在我上小学的时候，各连锁店里开始装电脑，购买并装置了残缺的收银设施。 我爸说要向那些大的连锁超市学习，进步生产效率。 那个时候我对那些灰色界面的收银软件很感兴趣，惋惜爸妈不让我碰。 起初他们给我买了电脑，过后小镇上有电脑的人家不多，亲戚的小孩也经常跑到我这儿来玩电脑。 也正因为和电脑接触得早，上大学时就选了计算机专业。 我才刚上大学没几个星期，我爸就问我： 那个时候我连数据库什么的都还没有个概念，还在学反码补码，我通知他：能，但当初不行，等我一两年。 我爸说不要紧。依照他的思维，咱们不须要齐全会写，只有明确怎么写进去就行，具体的实现咱们能够交给软件公司做。 但搞明确软件是怎么造出来的很重要，因为这可能帮忙咱们在购买软件时站在供应商的角度思考，知己知彼，放大我方信息差。 做买卖实质上玩的就是这一套。 2005年，我大三，学校要搞一次软件开发大赛，一共有三个命题，其实根本涵盖了所有场景，学生能够自由发挥。于是我就想到了超市的收银软件。 过后淘宝刚火起来，我想为啥不学习一下呢， 彻底变革我爸的商业模式，从线下转到线上！ 整个网上商城， 浏览商品，购物车，下单，配送，但咱们次要卖的是本人的货源。 过后用到的技术是 MySQL+ Java + JSP，而后本人买了服务器让服务跑起来。 在学校演示这套零碎时，我拿了最高的问题。 满心欢喜之余，我尝试把这套零碎用到理论业务中，先从自家的总店开始试点。 没想到我爸给我泼了一盆冷水，他说咱们这里的用户没有上网购物的习惯，送货问题没法解决。 我不服，非要尝试，果然现实与事实间存在着微小的差别，我跌了一个大跟头。 尽管我搞了很多流动，发传单宣传商城，但真正上网购物的寥寥无几。 有些违心尝鲜的，在网上买了货色，都是我亲自开车送货的。 毕业回家，我本想出国留学，但被我爸拽了回来， 我先跟着信息部的负责人老张学习，而后缓缓接班。 过后家里的每个超市都很大，都有一二十台 POS 机， 每个超市有一台服务器，一个数据库。 POS 机间接连到本超市的服务器上， 典型的客户端/服务器构造。 在那个时代，我预计大家都是这样的吧！ 说实话，这样的软件架构外表看似挺稳的，只有机器不出问题，稳固供电，整套收银零碎就没有问题。但实际上面临着许多缺点： 1. 机器是真的会坏的，而且真的有坏过的案例 2. 每次有商品数据要更新都要告诉每一家店的管理人员进行更新，呈现纰漏是很失常的 3. 更新软件的时候，工程师须要到各个现场配置，更新4. 各个店面对立数据艰难，每个月统计数据的时候须要对立汇总，不能随时随地得悉以后各分店的数据5. 等等...... 每一家店独自运作一套零碎，这毛病要是列上来就没完没了了 我倡议老张搞个地方机房，把软件集中化，每个门店都连贯到对立的机房服务器，这样就把下面的问题给解决了： 起初的零碎革新，通过招标、投标，咱们选了本地一家颇有实力的公司来做。 我施展了计算机专业的劣势，帮忙老张发现了不少问题。 看来我爸说的是对的，放大信息差很重要。 地方机房运作了几年，成果不错， 不过自家的机房治理起来十分麻烦。 ...

简介：云网管是基于阿里云网络多年技术和教训积淀打造的云上智能网络管理运维平台，提供企业网络全生命周期治理运维的能力，让部署更快捷、运维更高效、网络更通明。云网管更多内容：https://yqh.aliyun.com/live/cmn\_release 1.背景云网管是基于阿里云网络多年技术和教训积淀打造的云上智能网络管理运维平台，提供企业网络全生命周期治理运维的能力，让部署更快捷、运维更高效、网络更通明。 1.1用户痛点1.装置部署难 传统网管大多都是本地部署，用户须要负责物理资源布局、中间件装置、安装包部署等等工作，通常须要业余的网络和IT保护人员数天甚至数周能力部署上线。 2.集中管理难 网络设备自有的厂商网管，个别只能提供本地web拜访形式，不能集中管理，更做不到跨厂商治理，无奈给用户提供对立的治理视角，须要多套网管零碎之间切换应用。 3.网络扩大难 办公、批发场合随着业务的扩大，常常须要全国各地疾速开店，目前网络的交付都是网络工程师通过console口登录一台台配置下发，效率低下且容易出错。 2.产品介绍2.1网络管理范畴如下图定义网络管理的全生命周期，传统的网管零碎，对网络的治理次要针对网络退役阶段，面向的是已上线网元的资源管理和运维监控等，无奈做到网络设备的全生命周期治理。 图1 网络管理全生命周期 云网管对网络的治理是贯通整个生命周期的，在网络未上线的时候，能够离线规划设计，定义网络架构；在建设交付的时候，将定义好的网络架构以我的项目的形式进行施行，整个交付过程流程可控，品质可管；验收通过后，网络正式进入退役阶段，在该阶段网络的外围诉求是稳固运行、少出故障以及故障产生后的疾速定位和故障复原，云网管的监控、变更、巡检等模块确保网络退役阶段的稳固运行直到网络下线。在整个网络生命周期中，资源管理确保网络资源与实在网络的一致性。 2.2 产品性能介绍2.2.1 建设交付架构设计在网络尚未上线时能够事后进行网络布局，网络架构用于定义网络组网的互联标准和技术规格，提供图形化的架构设计和治理性能，通过图形化的形式进行组网拓扑的灵便编排，并对各个网络组件的具体规格进行配置。 如图通过可视化的形式进行网络架构设计，定义网络模块的数量和连贯关系。 图2 网络架构设计 联合设计好的网络布局和配置标准，主动生成可一键导入的规范配置文件。 图3 配置文件生成 建设交付建设交付是将网络计划以我的项目的模式进行设施下发，在每个我的项目中以工单的模式管制交付过程和保障品质。 图3 建设交付我的项目施行 2.2.2 智能运维态势感知通过全局视角和分支视角对网络整体状态进行实时感知。 衰弱度: 联合设施告警状况、网络巡检情况、监控笼罩水平等多维度对网络情况进行评分。 动静拓扑: 通过LLDP和MAC扫描技术准实时拓扑更新，设施连贯关系、端口信息等实时出现。 一体化监控一个办公分支或者门店的网络，个别是涵盖了多个档次的网络，蕴含多种网络状态的设施。通常包含接入运营商的网关设施，进行数据转发的网络设备（路由器或交换机），提供WLAN的无线设施以及形形色色的终端利用。一套从网到端全链路笼罩的监控计划是必要的，因为往往端侧的异样，可能是有线网络的问题，有线侧的故障，会影响上游端侧多个终端或利用的应用。 云网管针对有线网络、无线网络、终端利用等不同网络档次的设施，通过被动采集、事件接管、插件部署、被动拨测等多种监控技术，从网关到终端全链路监控网络运行状况。在如下的监控视图里将交换机上联口流量、到运营商的进口流量、AP的终端连接数以及终端的监控信息等有线和无线的指标在一个视图里实现监控。 网络编排云网管提供可视化的流程编排引擎，用户通过拖拽的形式将网络操作的原子能力串联起来，保障业务下发时的事务残缺和平安。 1.残缺业务流程编排定义 2．单步配置流程可视化下发 故障自愈日常高频的故障场景，基于云网管的网络编排能力，能够将告警联动解决计划，疾速实现故障止血和业务复原。 3.架构介绍3.1技术架构 协定插件云网管的协定插件集成了管理网络所须要的ssh、telnet、netconf、snmp、grpc等协定，反对治理市面常见的商用网络设备。 协定插件通过加密的平安通道与云端的采集管制实例进行通信，高效执行云端下发的设施操作指令和采集工作，并将数据压缩后实时反馈给云端进行剖析和展现。 协定插件的Agent反对以云网管自有硬件、软件安装包、集成SDWAN网关等多种形式输入。 采集管制采集管制实例在云端部署，在云网管的整体架构中起承前启后的作用。 调度引擎的工作流程: 1. 接管网络编排下发的工作，按工作优先级、调度打算等策略，将工作进行正当拆解和调度。2. 依据设施厂家型号等维度将指令通过模板翻译映射为操作设施的具体指令。3. 将指令下发到Agent执行，期待接管执行后果 4. 工作执行后果剖析和拼装 模板治理: 模板分为“用户模板”和“设施模板”两类，“用户模板”只具备业务含意，屏蔽了厂家差别，在网络编排中间接援用，“设施模板”是细化到厂商、型号粒度，不同的厂商之间都有显著差别。例如：“ACL策略”的设施模板，思科和华为是不同的指令。 网络编排网络编排负责业务模型的对立形象和定义，网络编排将原子能力按业务流程进行串连，造成具体的网络计划。网络计划通过流程引擎驱动采集管制实例执行每一步的原子操作，以工单的形式管制事务残缺和链路追踪。 利用网络编排以API的模式对利用提供能力和数据接口，应用层实现具体的“资源管理”、“网络巡检”、“网络变更”、“故障复原”等能力，反对运维人员进行日常的网络运维、业务配置等工作。 3.2部署架构云网管SaaS化部署，分钟级开明云上网管实例，用户侧只用部署探针（硬件版只须要上电和网络可达）即可。 云网管的计算和存储资源都是应用的阿里云资源，能够依据规格随时扩容，基于阿里云ASK集群实现的CI/CD性能，能够随时迭代上线新性能。 4.总结云网管致力于为简单、异构、分支泛滥的线下网络打造一款免部署、易上手、集中管理的SaaS化网络运维治理平台。欢送申请试用和加群交换。 https://common-buy.aliyun.com/?spm=5176.21109098.J\_3759233040.1.1c5dc777vP6U7p&commodityCode=cmn\_aliyun\_public\_cn&regionId=cn-hangzhou 云网管服务交换钉钉群: 35556346 ...

简介：2020年初新冠肺炎疫情在寰球迅速蔓延，从天而降的疫情让大多数企业不得不复工停产，企业在摸索和实际各种新的办公形式，近程办公、居家办公的需要和市场规模呈现出爆发式增长，已成为企业的共识和寰球趋势。 中转最佳实际：【无影云电脑居家办公最佳实际（便捷账号）】 最佳实际频道：【最佳实际频道】 这里有丰盛的企业上云最佳实际，从典型场景入门，提供一系列我的项目实际计划，升高企业上云门槛的同时满足您的需要！ 场景形容近程办公虽不受限于办公室场合和网络，以保障员工能够随时随地工作的便当，但企业的传统IT架构，还不能满足大规模近程挪动办公的需要，企业信息化零碎网络接入形式繁多，并不具备反对很多人近程办公的条件；近程办公的平安治理挑战一直减少，因而对近程办公的设施治理、近程拜访和安全策略就成为企业管理者和IT部门亟待解决的问题。 计划劣势弹性伸缩，依据业务规模变动，按需购买服务。简化运维，服务状态交付，运维简略，进步服务效率。便捷接入，随时随地接入，轻松应答疫情、自然灾害等各种状况，保障业务连续性。利用生态，利用市场为企业提供各类应用服务，也可纳管企业自有license，按需分配。进步资产效率，无需一次性购买大量服务器、数据中心建设及保护老本，将贵重的资源投入到外围能力畛域。产品架构 中转最佳实际 》》 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：一年一度的科技盛会“云栖大会”行将启幕！足足四天，两场主论坛，上百场分论坛，四大场馆会展一体，打造“云栖数字谷”，再加码互动探展沉迷体验，诚意满满，惊喜有限。 一年一度的科技盛会“云栖大会”行将启幕！ 诞生于2009年的云栖大会，历经十三载倒退，逐步成为科技翻新的风向标，见证了中国云计算崛起，科技翻新，和数字经济的蓬勃发展。 去年，疫情让咱们只得相约线上。往年，咱们将带着全面降级的云栖大会与您重逢！足足四天，两场主论坛，上百场分论坛，四大场馆会展一体，打造“云栖数字谷”，再加码互动探展沉迷体验，诚意满满，惊喜有限。 论坛：大咖星散 2021云栖大会将是“群星闪耀”的一届。 咱们邀请了上千名重磅演讲嘉宾，涵盖院士、IEEE Fellow、政企智客及首领、500强企业CXO、上市公司创始人，顶级科学家和行业领军人共襄盛举。 两场主论坛，百余场分论坛及专场，将从前沿畛域讲到科技翻新——5G、人工智能、量子信息、空天科技——咱们将和光临嘉宾一起，独特引领技术、产业新风向。 此外，阿里巴巴将在云栖大会公布包含AI、芯片、量子计算、根底云、云原生、AIoT等等在内的百余项最新技术、产业成绩。 逛展：尖端科技 每年四天，杭州云栖小镇将降级成为“云栖数字谷”。 它将不仅是科技大会，还是集智能产品与产业all in one的超级“数字谷”。它不仅星散技术、产业、学术大咖，还是面向整体科技爱好者的“智能科技狂欢节”。数智中国馆、数智源力馆、数智风暴馆，三“馆”齐下，讲述数字技术倒退。人人都能在这里找到属于本人的科技共鸣。 在这些根底之上，咱们还引入了新潮逛展体验，力求打造人人举世无双的云栖“冒险”之旅。更有云栖电视台重磅出炉，直播对话、专题栏目，人人参加共创内容。还有迷人的“数字谷之夜”，丰盛“云栖生存”。 精彩看点 报名云栖大会，参加抽奖流动 为回馈所有阿里巴巴云原生公众号的粉丝，为行将到来的云栖大会预热，咱们设置了报名参会就有机会参加抽奖的流动。 抽奖流程小tip： Step1：通过长按辨认上文【邀请函】中二维码信息或下方【门票申领二维码】，返回【2021云栖大会-企业互联网架构分论坛领票页面】进行门票申领报名，实现报名后肯定要截图哦！！两个分论坛都能够报名。 Step2：增加小助手微信号并发送门票申领胜利的截图。 Step3：通过小助手发给你的抽奖链接实现以下操作取得抽奖资格哦。 10月，咱们杭州云栖大会见！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：足足四天，两场主论坛，上百场分论坛，四大场馆会展一体，打造“云栖数字谷”，再加码互动探展沉迷体验，诚意满满，惊喜有限。 4天96小时 数智沉迷极致体验 10大技术板块、21大行业 100+场 数字新思维论坛 450+ 最热科技新品 1000+ 数字生存新物种 40000平米云栖数字谷…… 前沿·摸索·想象力一年一度，云栖大会如期而至。  10月19日-10月22日，2021云栖大会以“前沿·摸索·想象力”为主题，与大家独特见证下一代前沿硬核技术的诞生，摸索数字化科技的新趋势，激发创新者对数智产业将来的全新想象力。（文末报名提前锁定） 前沿：硬核技术联动热门议题 科技产品、数字技术、资讯密集度进一步降级！满载干货的四天大会，云栖小镇将从技术和产业人士汇聚的产业翻新胜地，降级为智能产品与产业all in one的“云栖数字谷”。 大会将专项展出国内外顶尖科研机构与达摩院的最新研究成果和黑科技，在千行百业的数字翻新样本间中，参会者可能畅游数字时代的“新京杭大运河”，体验上千种数字生存新物种和科技新品，放大科技与生存间的 “化学反应”。 报名云栖大会，参加抽奖流动 为回馈所有阿里巴巴云原生公众号的粉丝，为行将到来的云栖大会预热，咱们设置了报名参会就有机会参加抽奖的流动。 抽奖流程小tip： Step1：通过长按辨认上文【邀请函】中二维码信息，返回【2021云栖大会-云原生峰会领票页面】进行门票申领报名，实现报名后肯定要截图哦！！两个分论坛都能够报名。 Step2：增加小助手微信号并发送门票申领胜利的截图。 Step3：通过小助手发给你的抽奖链接实现以下操作取得抽奖资格哦。 10月，咱们杭州云栖大会见！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：随着音讯基础架构的云原生化演进，RocketMQ 也开始摸索音讯畛域的后处理场景，以及音讯的流式解决和轻计算，帮忙用户实现音讯的就近计算和剖析，并将全面拥抱 Serverless 和 EDA。那么，当初一线大厂在哪些新场景在应用RocketMQ，社区最近又有新的性能演进？那些想要理解这些，那就快来加入 Apache RocketMQ MeetUp - 北京站 线下流动吧！作为由阿里巴巴捐献的Apache顶级云原生消息中间件，RocketMQ 立足于在线交易链路，帮忙企业实现异步解耦和削峰填谷以及 IoT 边缘数据以及 C 端用户行为数据采集传输和集成等泛滥性能。咱们能够在十分多的大规模落地场景看到它的身影：电商物流的交易系统、在线教育课程零碎、大型游戏信令零碎以及银行交易系统；非在线业务的场景里，大量车联网、电商网站。 随着音讯基础架构的云原生化演进，RocketMQ 也开始摸索音讯畛域的后处理场景，以及音讯的流式解决和轻计算，帮忙用户实现音讯的就近计算和剖析，并将全面拥抱 Serverless 和 EDA。那么，当初一线大厂在哪些新场景在应用RocketMQ，社区最近又有新的性能演进？那些想要理解这些，那就快来加入 Apache RocketMQ MeetUp - 北京站 线下流动吧！ 流动现场你不仅可能失去多个干货案例剖析，更能取得多种神秘小礼物。更重要的是，你能结交100余位与你气味相投的开发者小伙伴！别再犹豫！立刻海报扫码报名吧！ 流动名称：Apache RocketMQ Meetup - 北京站 流动工夫：2021年10月16日 14:00 - 17:00 流动地址：北京市朝阳区霄云路35号-氪空间（霄云路社区） 流动亮点： （1）深刻针对多云异构存储，如何打造云原生消息中间件 （2）全面解说RocketMQ Go语言重构设计思路和实现细节 （3）深底解析RocketMQ Streams，让实时计算更加简略 （4）理解架构新趋势，解读Event-Driven架构摸索与实际 （5）理解rocketmq 5.0 音讯、事件、流交融解决平台的演进方向 点击链接（https://www.huodongxing.com/event/7616142309600），即可报名取票！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：足足四天，两场主论坛，上百场分论坛，四大场馆会展一体，打造“云栖数字谷”，再加码互动探展沉迷体验，诚意满满，惊喜有限。 一年一度的科技盛会“云栖大会”行将启幕！ 诞生于2009年的云栖大会，历经十三载倒退，逐步成为科技翻新的风向标，见证了中国云计算崛起，科技翻新，和数字经济的蓬勃发展。 去年，疫情让咱们只得相约线上。往年，咱们将带着全面降级的云栖大会与您重逢！足足四天，两场主论坛，上百场分论坛，四大场馆会展一体，打造“云栖数字谷”，再加码互动探展沉迷体验，诚意满满，惊喜有限。【文末有抽奖】 群星闪耀2021云栖大会将是“群星闪耀”的一届。科技产品、数字技术、资讯密集度进一步降级！满载干货的四天大会，云栖小镇将从技术和产业人士汇聚的产业翻新胜地，降级为智能产品与产业all in one的“云栖数字谷”。 咱们邀请了上千名重磅演讲嘉宾，涵盖院士、IEEE Fellow、政企智客及首领、500强企业CXO、上市公司创始人，顶级科学家和行业领军人共襄盛举。 此外，阿里巴巴将在云栖大会公布包含AI、芯片、量子计算、根底云、云原生、AIoT、企业互联网架构等在内的百余项最新技术、产业成绩。笼罩10大技术板块、21大行业，从前沿技术冲破、根底产品翻新，以及数字产业交融，与参会者一起见证数字翻新的最佳实际。 逛的尽兴19-22号四天，杭州云栖小镇将降级成为“云栖数字谷”。 本届云栖大会集齐技术、产业、学术大咖，面向整体科技爱好者打造了一场“智能科技狂欢节”。数智中国馆、数智源力馆、数智风暴馆，三“馆”齐下，讲述数字技术倒退。人人都能在这里找到属于本人的科技共鸣。 在这些根底之上，咱们还引入了新潮逛展体验，力求打造人人举世无双的云栖“冒险”之旅。更有云栖电视台重磅出炉，直播对话、专题栏目，人人参加共创内容。还有迷人的“数字谷之夜”，丰盛“云栖生存”。 大会将专项展出国内外顶尖科研机构与达摩院的最新研究成果和黑科技，在千行百业的数字翻新样本间中，参会者可能畅游数字时代的“新京杭大运河”，体验上千种数字生存新物种和科技新品，放大科技与生存间的 “化学反应”。 云栖热门看点看云原生最新进展，来云原生峰会2020年咱们认为是云原生实战的元年，越来越多的企业开始关注云原生在企业的落地。这个词在云计算畛域逐渐走到聚光灯下，成为以后的热词之一。各行各业正在切实通过云原生将企业的数字化转型带入“快车道”。  2020年，阿里云提出“云原生是企业数字翻新的最短门路”，自从该理念被提出当前，深受产业界关注和探讨。往年5月，阿里云提出云原生推动全云开发与实际，开启了全云开发的时代。 阿里云在云原生畛域有哪些重要的技术、产品、计划的最新公布？10月21日，云栖大会-云原生峰会将全面介绍云原生产业动静、云原生产品停顿、云原生行业实际等，为大家带来一场年度最全面的云原生盛宴。 看点一：阿里巴巴研究员、阿里云云原生利用平台负责人丁宇将从云原生产品技术升级角度，全面介绍容器、Serverless、技术中台等产品新个性。 看点二：多位企业CEO、技术负责人将带来云原生产业最新实际。企业的业务场景简单，随着业务需要的降级，对云原生技术和产品的需要必将更深更广，多位技术负责人将基于本身实战经验，从企业理论的需要登程，全面解读云原生转型降级历程。 看点三：阿里云云原生的生态搭档也将齐聚峰会，公布云原生生态产品集成和最佳实际，共建云原生产业生态，让云原生走进更多企业，发明更大的价值。 扫码报名参会 企业互联网架构如何演进？看这个分论坛！历经10余年双11大规模流量场景，阿里云中间件不仅撑持了阿里巴巴团体99%的大规模利用，更撑持了互联网、金融、制作等各个行业的数字化转型。10月22日，企业互联网架构论坛将解读微服务、音讯队列、高可用、可观测等如何助力企业疾速实现互联网架构降级，拥抱智能新时代。 看点一：RocketMQ 重磅降级 RocketMQ 诞生于阿里云，是Apache社区十分沉闷的消息中间件我的项目。本次社区和云产品独特公布新一代 RocketMQ5.0 版本。RocketMQ 5.0凋谢了全新的存储计算拆散架构，提供海量队列、更高性能、极致弹性的根底能力，并向上承载了轻量级流式计算框架和事件驱动架构。企业客户能够基于RocketMQ 5.0进一步开掘数据价值，打造“音讯、事件、流”一体化解决的业务模式。 看点二：首发 CNStack 技术中台，企业数字化转型的利器 CNStack是一款高效能企业级云原生PaaS平台，在异构的混合云基础设施上构建跨平台适配和资源优化调度能力，以云原生的形式提供利用全生命周期托管所依赖的技术组件，帮忙用户打造满足大规模、高性能、可靠性和业务连续性等要求的分布式应用零碎。 看点三：安利、南航、溪鸟物流等企业实战经验分享 安利基于阿里中间件ARMS能力，构建端到端全链路监控链路，疾速进行故障报警和追溯；南航通过阿里云业务中台，将技术和业务能力积淀为一套共享能力平台，满足业务倒退需要及对于新业务的疾速响应；溪鸟物流在业务单量十几倍增长状况下，通过云原生中间件和高可用组件进行架构降级，同时落地云平安生产体系，全方位保障系统99.99%高可用性。 扫码报名参会 云栖大会史上最大数字智能博览展会，行将退场！ 云栖小镇变身“云栖数字谷”，4大数智主题馆，长达96小时的沉迷式智能展，独特畅想数字翻新将来，塑造产业智能将来。同时，在玩法上，寰球独创的智能Pin旅行形式，参会者通过角色扮演、互动打卡，可沉迷式体验展馆。 报名云栖大会，参加抽奖流动 为回馈所有阿里巴巴云原生公众号的粉丝，为行将到来的云栖大会预热，咱们设置了报名参会就有机会参加抽奖的流动。 抽奖流程小tip： Step1：通过长按辨认上文【邀请函】中二维码信息，返回【2021云栖大会领票页面】进行门票申领报名，实现报名后肯定要截图哦！！两个分论坛都能够报名。 Step2：增加小助手微信号并发送门票申领胜利的截图。 Step3：通过小助手发给你的抽奖链接实现以下操作取得抽奖资格哦：点击抽奖链接—点击“参加抽奖”—点击“去辨认二维码并回复”—长按辨认【阿里巴巴云原生】公众号二维码并关注—在【阿里巴巴云原生】公众号后盾回复 “2021云栖大会”，即可参加抽奖。  10月，咱们杭州云栖大会见！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：俗话说“人生如戏，秋如四季”，在这个气温多变的节令里，咱们云开发平台要你始终和煦相伴！云开发平台跟天猫精灵利用平台一起联结宠粉，5分钟跟着文档打造你的私人小管家，1200件阿里云定制卫衣等你来领。宠你就要给你每个节令的和煦。宠你就要给你每个节令的和煦。俗话说“人生如戏，秋如四季”，在这个气温多变的节令里，咱们云开发平台要你始终和煦相伴！ 5分钟零根底打造你的私人暖心小管家语音技能置信大家都不生疏，谁还没有一个AI音箱呢。不过少数时候大家都是拿AI音箱当音乐播放器使了，还没有把这个金矿给利用进去。其实市面上的AI音箱都可能定制开发语言技能，让AI听你的话，比如说当初有听故事的、放音乐的。然而因为之前技能的开发比拟麻烦，你须要提前花上近千元买好服务器筹备好，想0根底0门槛上线一个技能几乎是太难了。 云开发平台跟天猫精灵利用平台单干推出天猫精灵语音技能云开发新性能。帮忙大家无需购买服务器0门槛创立和上线个性化AI语音技能，动动手指就可能打造你的私人暖心小管家。它能够在秋季揭示你天气的变动，及时加减衣物，在你疲乏的时候能够举荐一部和煦治愈的电影让你放松放松。不会写代码？都有现成的保姆式文档，跟着文档5分钟微微松实现。 秋天的第一件卫衣领了吗？这还没完哦，天气转凉，秋天的第一杯奶茶喝过了, 秋天的第一件卫衣你们买了吗？打造完的小管家还要送你秋天的第一件卫衣，陪你度过一个微暖的秋季。阿里云云开发平台这里为各位粉丝们筹备了1000件宠粉礼，粉丝们仅需5分钟实现2个工作中的任意一个就可能拿到咱们为粉丝们筹备的宠粉礼，让这份宠粉礼和煦粉丝们的整个秋天！ 最初有一句话想对你们说：天气多变，宠“AI”你们的心不变！ 获奖形式与流动工夫流动页面：https://workbench.aliyun.com/activities/aligenie 9月22日到9月30日，仅需实现页面上的2个工作中的任意一个即可支付呦！定制卫衣会在每个工作日的10点补充到150件，这周日也是工作日，那就也会照常补货哦。当天没有领到的同学也不要焦急，第二天10点从新补货后能够间接支付的！ 体验还不过瘾，实战营等你来踢馆！10月18号开始咱们邀请天猫精灵智能利用平台的大神们手把手教大家开发技能，从欢送语的实现到、单轮对话、多轮对话、有屏音箱技能理解技能开发的方方面面吗，同时还有一个小百科的全实战演练，你能够改成你的画画小百科、厨艺小百科、数学小百科等等，是不是很期待啊？！间接在流动页面报名即可。 第一次应用云开发，请收下见面礼！第一次应用云开发平台的用户点击页面下方的支付加油包按钮，实现相应的工作就能够支付10元阿里云无门槛代金券，抵扣你在阿里云上的云资源耗费哦，一个技能一年的钱就有了，个别人我不通知他。 也能够间接点击加油包的链接间接支付。https://workbench.aliyun.com/activities/coupon 具体流动规定 流动对象：阿里云官网注册的已实名认证用户 流动工夫：2021.09.22-2021.09.30 流动网址：https://workbench.aliyun.com/activities/aligenie 1. 用户须要实现页面所有的工作才能够支付奖品，同一用户限领一次。流动期间奖品每天发放150件，周六除外，每天上午10都会新补仓奖品，当日奖品领完当前能够次日再来支付，先到先得，发完即止。 2. 奖品以实物为准，色彩随机，图片仅供参考，流动完结后15个工作日内发货。如果因为疫情影响，导致实物奖品发货工夫不确定，请注意流动群的布告信息。 3. 阿里云能够依据流动的理论状况对流动规定进行变动或调整，相干变动或调整将颁布在流动页面上，并于颁布时即时失效；但不影响用户在流动规定调整前曾经取得的权利。 4. 流动相干问题能够钉钉扫码退出云开发的流动群或者搜寻钉钉群号: 34096194退出。 5. “同一用户”，是指依据不同阿里云账号在注册、登录、应用中的关联信息，阿里云判断其理论为同一用户。关联信息举例：同一证件、同一手机号、同一领取账号、同一设施、同一地址等。 6. “同人账号”，是指同一用户领有多个阿里云账号的，各个账号之间互为同人账号。 7. 为保障流动的偏心公正，如用户在流动中存在瞒哄、虚构、舞弊、欺诈或通过其余非正常伎俩躲避流动规定、获取不当利益的行为，例如：舞弊支付、歹意套现、网络攻击、虚伪交易等，阿里云有权发出相干权利、勾销用户的流动参加资格，撤销违规交易，必要时查究违规用户的法律责任。 8. 本流动最终的解释权归阿里巴巴团体所有。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：余票不多，收费抢票！9月26日，“数聚云端·智驭将来”——阿里云数据库翻新上云峰会暨第3届数据库性能挑战赛决赛颁奖典礼，将在北京隆重召开。收费报名入口数，究万物之基本； 智，指将来之所在。 新一轮科技反动令这个时代迎来空前巨变，企业对数据存储、价值开掘、赋能业务决策等需要愈发强烈和清晰。能够说，将来市场的竞争其实就是数据的竞争。 9月26日，“数聚云端·智驭将来”——阿里云数据库翻新上云峰会暨第3届数据库性能挑战赛决赛颁奖典礼，将在北京隆重召开。 会上，阿里巴巴团体副总裁、阿里云数据库产品事业部负责人李飞飞将为您解读新技术变革时代下数据库产业的现状和将来；华东师范大学副校长周傲英坦言云数据库是数智新时代下，数据赋能的先锋和楷模；上海新能源汽车、用友和绿洲游戏等作为一站式数据管理的最佳实际，将别离展示云数据库在汽车行业、软件行业和游戏行业的翻新明码。 本届峰会，更多精彩看点：深刻洞察新技术改革驱动下的云原生数据库；20+产学研各界技术大咖、知名企业技术首领齐聚；精选并深刻分析多行业一站式数据管理的最佳实际；首次重磅公布“企业级实时数据仓库”场景化解决方案。嘉宾阵容+峰会议程详见下图： 余票不多，欢送扫描图片上图二维码或点击链接，收费抢票，泛滥技术大咖在现场等你，更有惊喜礼品相送哦！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：为了最终共建寰球事实标准，阿里云服务网格 ASM 产品抉择了以开源的 Istio 为根底进行能力加强和产品化。Istio 面向微服务治理的将来做了很好的概念形象而功能强大，也因为功能强大带来了易用性问题。用户通过 YAML 文件运维服务网格不仅技术门槛高，而且很容易出错。为此开设本次直播，将分享过来几个月 ASM 在产品易用性上的工作进展和背地的思考。一、直播主题《服务网格 ASM 产品易用性改善实际与思考》 二、直播工夫9月26日 16:00-17:00 三、直播嘉宾阿里云高级技术专家，李云（至简） 四、直播简介为了最终共建寰球事实标准，阿里云服务网格 ASM 产品抉择了以开源的 Istio 为根底进行能力加强和产品化。Istio 面向微服务治理的将来做了很好的概念形象而功能强大，也因为功能强大带来了易用性问题。 用户通过 YAML 文件运维服务网格不仅技术门槛高，而且很容易出错。本次直播将分享过来几个月 ASM 在产品易用性上的工作进展和背地的思考。 五、立刻预约点击链接（https://live.bilibili.com/23021247），或扫描海报二维码关注阿里云云原生B站直播间（本课程将在阿里云云原生视频号同步直播，敬请关注~） 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：收费报名入口！9月26日，“数聚云端·智驭将来”——阿里云数据库翻新上云峰会暨第3届数据库性能挑战赛决赛颁奖典礼将在北京隆重召开。收费报名入口9月26日，“数聚云端·智驭将来”——阿里云数据库翻新上云峰会暨第3届数据库性能挑战赛决赛颁奖典礼将在北京隆重召开。 阿里巴巴团体副总裁、阿里云数据库产品事业部负责人李飞飞、华东师范大学副校长周傲英等产学研大咖齐聚，数智将来号角未然吹起。 本次峰会以“数聚云端，智驭将来”为主题，深刻数据库上云垂直畛域，“翻新上云”带来七大精彩议题，探寻这个时代里数据赋能、数据库上云的翻新之道。 倒计时3天，阿里云数据库翻新上云峰会蓄势待发！ 余票无限，各位数据库DBer放松机会，扫码收费抢票啦！ 会议当天，更会有3大平台实时直播， 小伙伴们，快珍藏下方链接，免得错过直播哦～ 业余开发者社区CSDN直播间链接 阿里云开发者社区链接 阿里云云栖号链接 本届峰会，更多精彩看点：深刻洞察新技术改革驱动下的云原生数据库；20+产学研各界技术大咖、知名企业技术首领齐聚；精选并深刻分析多行业一站式数据管理的最佳实际；首次重磅公布“企业级实时数据仓库”场景化解决方案。嘉宾阵容+峰会议程详见下图： 余票不多，欢送扫描图片上图二维码或点击链接，收费抢票，泛滥技术大咖在现场等你，更有惊喜礼品相送哦！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：为了升高 OpenYurt 的应用门槛，帮忙更多地开发者疾速上手 OpenYurt，社区提供了 OpenYurt 易用性工具 yurtctl。该工具致力于屏蔽 OpenYurt 集群创立的复杂性，帮忙开发者在本地疾速地搭建 OpenYurt 开发测试集群。OpenYurt 作为阿里巴巴首个开源的边缘云原生我的项目，波及到边缘计算和云原生两个畛域。然而，许多边缘计算的开发者并不相熟云原生相干的常识。为了升高 OpenYurt 的应用门槛，帮忙更多地开发者疾速上手 OpenYurt，社区提供了 OpenYurt 易用性工具 yurtctl。该工具致力于屏蔽 OpenYurt  集群创立的复杂性，帮忙开发者在本地疾速地搭建 OpenYurt 开发测试集群。 OpenYurt 采纳云管边的架构，在原生 Kubernetes 集群之上，以 Addon 的模式进行性能加强，解决了云管边场景中，云边网络不稳固、云边运维难等关键问题，并实现了工作负载/流量的单元化治理、边缘本地存储、物联网设施治理等外围性能。本文试验的拓扑如图所示： 其中，蓝色局部是原生的 k8s 组件，橙色局部是 OpenYurt 提供的组件。 Master 节点位于云端，作为 OpenYurt 集群的管控节点，同时也作为集群的 Cloud Node，下面部署了原生 k8s 的管制面组件 controlplane，以及 OpenYurt 的管控组件 yurt-controller-manager、yurt-app-manager、yurt-tunnel-serverCloud-Node 节点位于云端，作为 OpenYurt 集群的 Cloud Node，能够用于部署 OpenYurt 的管控组件，本文试验中只用于演示了云端节点接入操作，没有理论部署OpenYurt的管控组件。Edge-Node 位于边缘，作为集群的边缘节点，部署了节点自治组件 YurtHub，以及云端通道组件 tunnel-agent。环境筹备（1）三台 Linux 操作系统的计算机。一个作为管制立体节点（同时也是云端节点）、一个作为云端节点和一个作为边缘节点，零碎均为 Ubuntu18.04）。 （2）零碎预装置 Docker，装置形式参考。 （3）关闭系统替换分区，不同版本零碎的敞开形式存在差别，本文环境执行 swapoff -a 敞开。 （4）下载 OpenYurt 社区代码，构建 yurtctl 工具，并将 yurtctl 拷贝到三台主机上。 ...

简介：支付宝客户端的动态化技术经验三个阶段：现阶段也就是第三阶段是实体组件+局部光栅化的hybrid模式，Cube 就是该模式下的产物。 如题目所述，笔者将继续更新《Cube 技术解读》系列文章。本文为Cube系列首篇文章，后续文章笔者会更侧重于技术详解，包含不限于：Cube卡片技术栈一篇，Cube小程序技术栈一篇，品质KITE&工具ACT一篇，性能优化一篇等。背景支付宝客户端的动态化技术经验三个阶段。第一个阶段是native+web的hybrid模式，以webview为基石。第二阶段是实体组件模式，把html形容的组件和css款式信息映射到实体组件，并且把实体组件的事件传递到js层进行解决。第三阶段是实体组件+局部光栅化的hybrid模式，Cube是第三阶段的产物。 Cube起源于native页面的动态化诉求，产品状态体现于Cube卡片。随着小程序概念的呈现，Cube融入了支付宝小程序技术栈，产品状态为轻量级的支付宝小程序解决方案（绝对于应用浏览作为外围的web小程序）。这篇文章是一个综述，也是Cube系列的首篇文章。 技术选型Cube的精确诞生工夫很难确定，大抵在16和17年之间，比RN（ReactNative）早晨一年。Cube诞生的次要起因是native页面的动态化诉求。钱包改版的频率高，给研发的压力很大，于是想到把高频改版的页面动态化。RN和Flutter的呈现，给了咱们一个很好的察看视角，即业界优良的科技公司是如何对待动态化这个话题以及它们的答案。起步阶段，咱们达成以下共识： 独立研发，自主可控。咱们没有抉择基于RN的开源代码来实现咱们的动态化解决方案，也没有Flutter颁布源码后，切换到Flutter。这么做是思考到两点，第一点，技术栈的演进要把握在本人手里，不心愿被牵着鼻子走；第二点，开源我的项目的产品化老本并不低，前期的保护老本也不低；服务业务，技术克服。首先，咱们没有足够能力和资源来撑持一个通用技术产品，服务于钱包业务是第一位的，简略说就是贴着业务走。其次，咱们回绝只求花里胡哨的技术demo，把外围能力做好，把产品成熟度做好，思考拿到业务价值是第一位的。基于下面两个共识，咱们的技术选型如下： 抉择Javascript作为逻辑语言；抉择CSS的某个子集作为界面描述语言；自绘制（text/img/div/scroller）+ 原生组件 （input, animation，map, audio, video …）的混合渲染模式。阿里在前端的积攒比拟多，Cube抉择拥抱前端，采纳javascript和css是天然的事件。默认js引擎是quickjs。没有抉择v8，有两个判断：v8太重，内存开销和库加载速度都不现实；Cube的利用场景大概率不须要v8提供的jit能力。咱们额定引入了第三方的 wamr 作为webassemby引擎，且在编译构建工具上反对javacript和assemblyscript混合开发。Flutter开源后受到很多人的追捧，在很多文章和ppt上都看到了“Flutter齐全独立于平台层的渲染管线的劣势”表述，认为比RN映射实体组件的形式要高级很多。咱们不认为Flutter的渲染管线的性能优于操作系统的渲染管线，毕竟设施和操作系统能够垂直整合，利用一些设施个性。此外，是否自建渲染管线应该取决于业务诉求，而不应该自觉的谋求技术。 Cube的自建渲染管线仅限于自绘制标签，如前所述包含text/img/div/scroller，应用平台层的canvas api间接绘制在零碎的view上；如果某颗子树的标签都是自绘制标签，这颗子树会被“拍平”绘制在一个view上。自绘制标签以外的标签都是用映射原生组件的形式，并且封装了对立的实体组件映射这些协定，提供给开发人员。目前Cube的业务场景次要集中在挪动端，也简略尝试过往linux/rtos平台移植。如果后续业务逐步扩大到linux/rtos，咱们会思考进一步欠缺自绘制，一个是把平台层的canvas api收敛到skia，另一个是内置layer compositor。 以后状态在承接业务的过程中，Cube大抵积淀了2种业务状态，别离是Cube卡片和Cube小程序。 Cube卡片的作用是给native页面赋予区域化的动静能力，进步业务迭代和经营效率。钱包接入的卡片也分为两类，一类是没有js能力的简略卡片，反对表达式和vif&vshow这类构建时管制DOM树的操作，谋求近似native的速度；另一类是具备js能力的简单卡片，用来反对一些简单的业务。Cube卡片在钱包曾经大规模利用，pv超过100亿，接入的场景参考截图，包含不限于首页、理财、我的等tab页，以及卡包、出行、领取后果页等二级页面。 Cube卡片的定位也是优先服务于钱包内的一二方业务，如果要想提供给三方开发者区域动态化的能力，咱们举荐小程序widget。此外，咱们正在着手把Cube卡片能力输入给中小型金融机构以及互联网公司。 Cube 是作为渲染引擎来引入小程序技术栈。小程序基础设施包含：容器，前端框架，渲染引擎，脚本引擎。容器能够了解成Appx/渲染引擎/脚本引擎之间的聚合层代码，提供包治理/JSAPI/平安管控/钱包外围服务等性能。挪动端上小程序默认的渲染引擎是UC，Cube小程序利用很无限。绝对于UC来说，Cube在包大小/启动速度/列表滑动流畅性/内存耗费上有一些劣势，然而劣势也非常明显——Cube反对的css能力有余，且Cube的开发工具不欠缺。基于此，从19年开始Cube投入了微小的人力来裁减css能力。Cube 是除浏览器内核外反对 CSS 较欠缺的渲染引擎，反对flex/inline/block等布局形式，伪类和伪元素，z-index以及绝对和相对定位层级治理。咱们也投入大量的精力试图建设相似devtools性能的工具。 这些致力肯定水平上改良了开发效力，但依然无奈满足前端同学的诉求。咱们逐步意识到，在浏览器性能不是次要瓶颈的场景下，前端开发者不大会承受浏览器的一个子集。于是，Cube小程序开始转向IoT场景，面向浏览器跑不起来，或者，体验极差的场景。Cube小程序作为某种利用开发栈，对试图建设三方开发者生态的客户是有肯定的吸引力。目前咱们次要的精力在电视大屏端，感兴趣的同学能够在天猫魔盒上体验Cube小程序，也能够在别的盒子以及智能电视上下载[酷喵影视](https://acz.youku.com/wow/tvact/act/cibn）。 在卡片和小程序之间，实际上还有一个两头地带，即单页。这个页面能够是全屏，也能够是沉没在地面的半屏。Cube晚期尝试过h5单页，面向高频率营销场景。它的技术栈和小程序简直齐全一样，不同的是，h5单页没有容器的概念，从服务端下载到端上的不是小程序包而是嵌入了Cube构建产物的h5页面。h5单页接入过红包码业务和蚂蚁森林的二级页面，因为保护老本陆续下线。h5单页不胜利，并不意味着单页的需要不存在。近期摸索的小程序widget其实就属于单页的领域——咱们心愿widget可能让服务前置，承载肯定的交互逻辑，同时也限度它的能力，便于管控，适宜三方开发者。 技术架构Cube的外部有两个大的模块，一个是CubeKit，负责对接js引擎且封装平台差别，也包含了开发调试工具。另一个是CubeCore，是用c++代码实现的渲染外围逻辑。 对于Cube小程序，反对tinyApp-dsl子集，挪动端上应用jscore/v8作为js代码的执行引擎，IoT设施上应用quickjs；对于Cube卡片，反对基于精简vue的card-dsl。简略的卡片间接解析AST来渲染页面，简单卡片反对用户用js写一些简略逻辑，并且通过quckjs来驱动dom树的更新。 挪动端上，Cube和Web小程序共用一个容器代码。在IoT设施上，咱们继续投入人力到Appx和容器的垂直整合中。从目前的数据来看，IoT上的Cube小程序绝对挪动端的Cube小程序有不小的根底性能劣势。在电视端上Cube小程序的根底性能数据是：包体积5.5mb，内存耗费32mb（淘宝特价板小程序为例），冷启动耗时3～4s。随着垂直整合的深刻，将来Cube小程序的根底性能会进一步的改善。 质量体系这个话题，我放在技术架构里讲，起因是它自身是技术架构的一部分。做业务开发，测试人员能够遍历用户场景，有bug修bug。根底软件所承载的业务场景只是有限样本中很小的一部分，业务场景的回归没有问题，不可能保障引擎没有问题——最坏的状况是问题继续累积，直到某一天忽然暴发进去。这个时候再想解决问题，曾经积重难返。所以，根底软件的研发迫切需要某种提前裸露潜在问题的伎俩，这个伎俩不可能借助某个测试资源而是研发团队本人建设。 浏览器的WPT测试用例汇合给了一个很好的参考，Cube也建设了这样一套根底能力样本汇合以及配套的样本自动化执行框架KITE，投入到版本迭代&代码提交中。截止目前，咱们根本能做到单日粒度的主动巡检，撑持咱们在已有大量的业务场景的状况下对引擎做降级和重构，下图是引擎根底能力巡检工具的截图。 开发工具链这个话题，我也放在这里讲。Cube的间接客户不是用户，而是业务方的开发同学。在我的项目初期就要思考到工具这块，比方调试器的设计、预览容器、日志设计、低代码搭建平台等等。在扩大业务过程中，工具链某种程度上比Cube自身还要重要，毕竟它是客户的第一印象。咱们遇到过后期技术调研时，客户因为工具的不欠缺而回绝应用。业务接入后，除了能力上，业务方也会对工具提供各种要求（在帮助排查问题时也会发现新的工具需要），贯通产品的整个生命周期，也是维系客户粘性的重要工作。随着Cube大规模利用于业务后，咱们在工具上投入的精力逐步超过了性能&技术迭代自身。 回顾&将来布局回顾过去5年，Cube一路趔趔趄趄，中途差点夭折，能走到明天实属不易。从集体视角，Cube能活下来依赖“高低保持”。一方面，下面的决策者保持投入（19年及以前简直没有像样的业务价值）；另一方面，一线的同学保持做一件事，没有技术谋求是不可能挺过途中的各种崎岖。咱们期待能Cube将来利用到物联网操作系统，毕竟利用开发技术栈是操作系统的核心技术之一。 Cube将来的布局持续保持“紧贴业务”和“技术克服”，把产品做好，把开发者服务好，把技术打磨好。重点的倒退方向如下： 鉴于Cube卡片能够运行在32MB内存/400Mhz的RTOS设施上，进一步摸索在物联网设施上的落地；推广Cube小程序在电视大屏端的利用和落地，摸索商业模式。如前所述，后续更新文章我会更偏重技术详解，针对卡片技术栈、小程序技术栈、品质KITE&工具ACT、性能优化等进行深刻解读与畅聊。 Cube 技术栈将于近期上线 mPaaS，作为一项全新能力对外输入，如你对该系列文章感兴趣，亦或是对Cube 技术感兴趣，欢送点击文末浏览原文理解 mPaaS 更多相干资讯。 咱们下篇文章再见。 本文转载于公众号「阿里巴巴挪动技术」，点击这里，理解 mPaaS 更多相干资讯。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：提前报名锁定云栖大会门票 4 天 96 小时 数智沉迷极致体验 10 大技术板块、21 大行业 100+ 场 数字新思维论坛 450+ 最热科技新品 1000+ 数字生存新物种 40000 平米云栖数字谷…… 前沿・摸索・想象力 一年一度，云栖大会如期而至。 10 月 19 日 - 10 月 22 日，2021 云栖大会以 “前沿・摸索・想象力” 为主题，与大家独特见证下一代前沿硬核技术的诞生，摸索数字化科技的新趋势，激发创新者对数智产业将来的全新想象力。（文末报名提前锁定） 前沿：硬核技术联动热门议题  科技产品、数字技术、资讯密集度进一步降级！满载干货的四天大会，云栖小镇将从技术和产业人士汇聚的产业翻新胜地，降级为智能产品与产业 all in one 的 “云栖数字谷”。  上千名重磅演讲嘉宾倾情分享，话题涵盖云计算、大数据、人工智能、智能硬件、数据库、IoT、操作系统、金融科技、量子计算等笼罩 10 大技术板块、21 大行业，从前沿技术冲破、根底产品翻新，以及数字产业交融，与参会者一起见证数字翻新的最佳实际。 此外，阿里云还将首次公开技术策略，公布百余项最新技术和产业成绩。 大会将专项展出国内外顶尖科研机构与达摩院的最新研究成果和黑科技，在千行百业的数字翻新样本间中，参会者可能畅游数字时代的 “新京杭大运河”，体验上千种数字生存新物种和科技新品，放大科技与生存间的 “化学反应”。 摸索：产业视频化翻新与最佳实际在全新的大视频时代，社会全畛域都在趋于线上化、视频化演变，而 “视频云” 作为大视频产业的要害底座，交融了 “云 + 音视频 + AI” 的能力，正在扭转泛滥行业的倒退格局并发明第二增长曲线，新的商业逻辑、新的机会空间由此不断涌现。显性可见，智慧教育、数智传媒、互联网娱乐、“直播 +” 生态、协同办公等畛域在视频化浪潮下后行降级，而更多产业正在视频化翻新的摸索之中。 阿里云视频云将于 10 月 21 日下午，开展云栖大会 “产业视频化翻新与最佳实际” 专题论坛。届时，泛滥分享者将围绕阿里云视频云自研的超低延时、实时音视频、4K+HDR 超高清、视频 AI、低代码开发等技术在产业中的摸索与实际，面向全产业提供一场触手可及的全新技术体验。 视频云专题论坛还将重磅公布一系列场景化、行业化利用新产品，凸显视频云技术的前瞻性成绩和新技术将带来的新商业价值。同时，在云栖大会技术展区还可摸索 “云端一体” 的多场景体验，由内容到交互共振新的可能。  想象力：96 小时 “云栖数字谷” 的时空沉迷云栖大会史上最大数字智能博览展会，行将退场！  云栖小镇变身 “云栖数字谷”，4 大数智主题馆，长达 96 小时的沉迷式智能展，独特畅想数字翻新将来，塑造产业智能将来。  ...

简介：2021云栖大会，技术精彩值得打call！万物智联的时代曾经到来。 随着云+5G+AI+IoT新一代信息技术的倒退，人工智能、新批发、无人驾驶、智能家居正在越来越多的扭转着人们的生存。 10月，2021云栖大会拉开序幕，IoT以“论坛+创客较量+两场峰会”的模式，邀请泛滥行业首领、技术专家，掀起一场以“智物-智造”为主题的头脑风暴。 两场峰会现场，紧扣物联网的外围、热点、难点问题，深度分析行业发展趋势，重磅公布多项最新产品与解决方案，并有优良实际分享。 【IoT云端一体硬件与利用翻新峰会】 智能硬件翻新与利用峰会，让万物智联 .png") 【AIoT原生技术与实际峰会】 云原生技术与实战解读大会，高效实现数字原生产品 .png") 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：人人都在探讨的 Serverless 到底怎么用？Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。为了帮忙开发者高效解决解决实在场景下的 Serverless 难题，疾速体验 Serverless 开释红利，阿里云开发者学堂发展0根底升级Serverless高手课，快来开启Serverless技术超神之旅吧~人人都在探讨的 Serverless 到底怎么用？Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。 为了帮忙开发者高效解决解决实在场景下的 Serverless 难题，疾速体验 Serverless 开释红利。9月22日起，每个工作日 19:00-20:00，间断 12 堂干货直播课，8 位 Serverless 技术专家手把手带你零根底升级 Serverless 高手，拿下高手证书。实现所有打卡，即可拿到由阿里云开发者学堂颁发的“Serverless 高手证书”！（纸质+电子） 直播工夫：9月22日-10月12日 工作日 19:00 - 20:00（可有限回放） 打卡工夫：9月22日—10月31日 直播预约：辨认下方二维码 直播亮点从 Serverless 概念开始零碎解说 Serverless以架构师视角选型 Serverless应用微服务的企业如何转型 Serverless？Serverless 在阿里团体的大规模落地案例Serverless 在企业落地难点及解析 点击链接（https://developer.aliyun.com/learning/topic/serverless），即可预约直播哦！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：为解决容器数据长久化存储问题，疾速帮忙开发者攻克 Kubernetes 技术难题，咱们和 ACK CNFS 及 NAS 的开发团队一起筹备了一场“硬核”训练营，为大家带来干货满满的直播课程，不仅提供技术难点的深度解读、最佳实践经验和胜利案例分享，同时实战环节将带你“沉迷式”上手体验，更有多重惊喜好礼等你来拿！依据 CNCF 最新调查结果，企业在生产环境中应用 Kubernetes 的比例从 78% 进步到了 83%，Kubernetes 作为云原生的外围平台，吸引了越来越多的开发者去理解、学习和把握。 在此基础之上，随同着云原生对业务翻新的影响力继续浮现，企业将容器利用于生产环境成为大势所趋，数据长久化存储问题始终以来都是容器技术的一大挑战。 为了解决上述问题，疾速帮忙开发者攻克 Kubernetes 技术难题，咱们和 ACK CNFS 及 NAS 的开发团队一起筹备了一场“硬核”训练营，为大家带来干货满满的直播课程，不仅提供技术难点的深度解读、最佳实践经验和胜利案例分享，同时实战环节将带你“沉迷式”上手体验，更有多重惊喜好礼等你来拿！ 9月22日「Kubernetes 难点攻破系列：容器长久化存储训练营」行将正式开营！ 01 训练营简介Kubernetes 难点攻破系列——容器长久化存储训练营，由阿里云容器服务团队与开发者社区独特打造，旨在帮忙更多开发者应答学习和应用 Kubernetes 的挑战。 9 月 22 日-9 月 24 日，3 天工夫，集中冲破。本次训练营你将理解为什么容器须要长久化存储、Kubernetes 容器服务编排的基本概念、长久化存储的架构和实现形式，并通过实战让你把握容器长久化存储的最佳实际。 02 流动福利实现容器长久化存储训练营的全副工作，即可依照以下规定支付流动奖品： 理解训练营玩法 + 课程打卡 + 实现通用型 NAS 文件系统创立（9 月 24 日 10：00 开启，次日 15:00 后查看打卡后果）+ 实现样板间试验+ 实现线上考试认证依照打卡工作实现程序支付奖品，1-10 名将获取奖品小米耳机，同时支付容器产品优惠券 （ACK Pro、ACREE），11-20 名将获取奖品阿里云定制T恤，21-60 名将获取奖品 ACK 定制小风扇03 实战课程（9 月 22-24 日，每天 17:00—18:00 开课） DAY1：何种数据存储能力助力容器计算主讲嘉宾：阿里云容器产品专家，张楠（朝昔）内容简介：本节课程将介绍容器计算中数据存储面临的挑战，分析以后存储状态在容器计算环境中应用的异同，以及阿里云在容器计算畛域对数据存储的洞察与翻新。 DAY2：容器网络文件系统 CNFS 在容器计算畛域的最佳实际主讲嘉宾：阿里云存储高级技术专家徐泰明、阿里云存储技术专家，孟威内容简介：介绍阿里云创新性的 CNFS 文件存储系统在各个场景的最佳实际和胜利案例。 DAY3：【实战体验】一步一步搭建容器弹性 Web 与内容管理系统主讲嘉宾：阿里云容器产品专家，阚俊宝内容简介：演示利用 ACK 和 CNFS 如何一步一步的疾速构建弹性 Web 与内容管理系统。同时，利用收费试验环境，您能够亲自体验平安易用、简略高效的阿里云 ACK 和 CNFS 文件系统 ...

简介：Kubernetes 监控立足于利用监控之下的 Kubernetes 容器界面和底层操作系统，是 Kubernetes 集群软件栈端到端可观测性的一体化解决方案，在 Kubernetes 监控中能够同时看到关联的所有层的观测数据。咱们心愿通过 Kubernetes 监控的一系列最佳实际，让大家可能应用 Kubernetes 监控解决 Kubernetes 环境下辣手的可观测问题。大家好，我是阿里云云原生利用平台的炎寻，很快乐能和大家一起在 Kubernetes 监控系列公开课上进行交换。本次公开课冀望可能给大家在 Kubernetes 容器化环境中疾速发现和定位问题带来新的解决思路。 为什么须要 Kubernetes 监控？很多同学对利用性能监控应该并不生疏，这类监控次要关注业务应用逻辑、利用框架和语言运行时，监控对象有线程池满，数据库连贯无奈获取，MySQL， 内存溢出，还有各种调用链异样栈等。随着 Kubernetes 容器化技术带来的云原生技术演进，下层利用的开发和运维变得更加简略，但复杂度是恒定的，下层的复杂度升高必然随同着底层的复杂度晋升。如下图所示，复杂度逐步转移到容器虚拟化层以及零碎调用内核层对各种虚拟化技术的反对。每一层都可能呈现问题，且这些问题会影响下层利用。比方容器虚拟化层的 Kubernetes 组件异样，如果调度器异样，Pod 将无奈调度影响利用；比方文件系统相干的零碎调用异样，下层利用无奈读取文件，造成利用问题；比方内核异样，利用过程无奈调度实现工作。 利用想要衰弱稳固的运行，须要的是软件栈端到端的衰弱稳固，尽管当初很多运维团队都搭建了利用监控和系统监控体系，但没有一个监控可能自顶向下、端到端的串联起来各层软件的行为，导致辣手的问题产生时，无从下手解决。在应用层，一个网络申请超时，在客户端和服务端看起来仿佛都没有问题，但实际上是网络层包发送 RTT 过高，重传率过高，亦或是 DNS 解析慢，或者是 CNI 插件慢。如何在 Kubernetes 容器化环境下做到端到端的可观测性是Kubernetes 监控呈现的意义。 Kubernetes 监控立足于利用监控之下的 Kubernetes 容器界面和底层操作系统。在容器虚拟化层，咱们通过以下五个数据源获取观测数据，通过 Kubernetes 管控组件 exporter 来获取 Kubernetes 管控组件的观测数据；通过 cAdvisor 获取容器的资源观测数据；通过 kube-state-metrics 获取 Kubernetes 资源的状态数据，还有事件和 Kubernetes 资源的状态以及条件数据。在零碎调用层，咱们通过 Kprobe/tracepoints  等 Linux tracing 技术获取观测数据；在内核层，咱们通过内核可观测模块获取观测数据，而后 Kubernetes 监控通过过程、容器、Kubernetes 资源和业务利用的关联关系向上关联买通利用性能监控，打造端到端的可观测性。所以 Kubernetes 监控是 Kubernetes 集群软件栈端到端可观测性的一体化解决方案，在 Kubernetes 监控中能够同时看到关联的所有层的观测数据。咱们心愿通过 Kubernetes 监控的一系列最佳实际，让大家可能应用 Kubernetes 监控解决 Kubernetes 环境下辣手的可观测问题。 ...

简介：智慧渔业，来了！有一位阿里云工程师，每天工作就是”摸鱼“。 在舟山国内水产城，阿里云IoT工程师鴻毅每天就与捕鱼的、养鱼的、卖鱼的、管渔的一起”摸鱼“。鴻毅理解到，舟山本地有许多渔业从业者，然而每个环节都很扩散，渔业捕捞、运输、营销各自为政，很难产生集群化效应。 基于这些“摸鱼”得来的信息，鸿毅联动阿里云IoT的技术产品团队，为舟山国内水产城搭建了渔农产业服务平台，链接了渔农产业链上的所有资源、征询和优质资本，为渔民和养殖户提供一站式信息服务，使全产业链数字化。小到信息资讯、专家征询，大到品牌溯源、渔船交易、线上销售海鲜等便当服务都能够让渔民及其他渔业从业者在平台上享受到。渔民在码头卸货，都能通过IoT设施与AI智能算法实现自动化卸货量统计，不需人力老本。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：阿里云凋谢搜寻对立召回引擎，搜寻召回环节同时反对阿里云自研Ha3引擎与阿里云Elasticsearch引擎，并提供多行业的搜索算法能力，助力企业高效实现搜寻成果深度优化特邀嘉宾： 邢少敏（多愚）-阿里巴巴高级技术专家 视频地址：https://yqh.aliyun.com/live/opensearch 搜寻面临的挑战工程挑战百万QPS618、双11等大促流动的高并发拜访千亿级数据SKU、订单、物流等大数据检索高时效订单、物流类数据时效性要求极高高可用分钟级不可用会导致巨额业务损失低提早搜寻作为流量入口，提早高会导致交易量降落算法挑战信息标准水平低比如说拿电商行业来讲，电商行业的商品名称，个别状况下为了进步商品排序，为了让商品排的比拟靠前，商品名称会加很多关键字，这样就会导致商品名称不标准，很多可能连语法都不太通，这个时候去剖析这些关键词是十分艰难的。 例如： 宝宝棉服套装婴幼儿冬装0-1岁3男婴儿棉衣秋冬女保暖棉袄加厚外套；毛豆陈腐5斤青豆毛豆角甜豆生鲜蔬菜豌豆带壳农家现摘嫩豆荚包邮；用意丰盛搜寻的时候查问词的用意十分的丰盛，而后会有很多不同的这种用意。 例如： 水 --（矿泉水？花露水？洗发水？）苹果 --（吃的苹果？苹果手机?）马可菠萝 --（菠萝？马可菠萝火腿肠？）丝袜奶茶 --（丝袜？奶茶？）召回量大，排序难单次召回千万，无限资源下进行精确排序难如果说咱们解决不好这些问题会产生什么状况呢？ 那么如果工程挑战和算法挑战，解决的不好，就会有用户散失的问题。 用户散失察看： 用户搜寻某个关键词两次以上仍然没有后果将认为平台无此类商品；用户浏览搜寻后果超过半分钟仍未找到指标商品将间接跳出；用户浏览搜寻后果超过4页仍未找到指标商品将间接跳出；搜寻产品和解决方案对于Elasticsearch业内最支流的信息检索、剖析引擎，DB-Engine指数排行“寰球热度No.7数据库，寰球热度No.1检索引擎”。宽泛的利用在各种业务场景。 阿里云Elasticsearch产品介绍提供全托管Elastic Stack服务，100%兼容开源，收费提供X-Pack商业插件，即开即用，按需付费。同时深刻性能与内核性能优化，提供更丰盛的剖析检索能力，更平安、高可用服务。 个性及劣势低成本收费提供每个节点价值6000美元的X-Pack商业插件智能运维、高级监控告警、容灾部署等，超低运维老本针对性场景调优，进步资源利用效率，多种产品价格策略性能与性能强劲日志增强版内核，100%老本升高，100%性能晋升文本、视频、音频、图像，提供最全面的信息检索能力全面对齐等保2.0要求，企业级数据安全能力凋谢的二次开发能力，反对各种业务场景的封装品牌背书阿里云与Elastic策略单干;丰盛行业教训为电商,批发,教育,金融,媒体,物流等30个行业提供服务;寰球服务服务笼罩全副阿里云数据中心,并且反对本地化专有云交付，和混合云计划 阿里云凋谢搜寻产品介绍凋谢搜寻（OpenSearch）是基于阿里巴巴自主研发的大规模分布式搜索引擎搭建的一站式智能搜寻业务开发平台，目前为包含淘宝、天猫在内的阿里团体外围业务提供搜寻服务反对。通过内置各行业的查问语义了解、机器学习排序算法等能力，提供充沛凋谢的引擎能力，助力开发者疾速搭建智能搜寻服务。 利用场景电商行业: 商品搜寻、订单搜寻、门店搜寻、数据库减速和剖析场景内容行业：新闻搜寻、社区搜寻、视频搜寻、图库搜寻多媒体行业、游戏行业、企业大数据….外围劣势工程劣势：高性能（毫秒级端到端提早）、高稳定性（99.99%稳定性）、高时效（毫秒级失效）；算法劣势：达摩院多年积淀的NLP技术，多行业打磨积淀的查问剖析、搜寻排序能力；产品劣势：低门槛，免运维，开放平台； 团体内搜寻中台外围搜索引擎HA3从淘宝天猫搜寻孵化而来团体内1000+业务接入，7000亿+商品/文档被索引，日搜寻PV达百亿。2020年双十一QPS峰值110万+，实时数据更新TPS峰值55万+凋谢搜索算法产品化凋谢搜寻是一个智能搜寻产品，在最近几年做了大量的算法产品化的工作，这外面就包含了查问剖析，多路召回、智能排序、用户行为、业务开发、成果评测等。 阿里云搜寻服务选型-产品生态产品选型开源产品--阿里云Elasticsearch业界知名度高，搜寻首选平台；开源生态学习门槛低，易于把握；插件机制容许自在定制，满足不同业务需要；阿里自研产品--凋谢搜寻（OpenSearch）一站式搜索引擎平台服务；外围引擎HA3为阿里团体外围搜寻技术，提供百万QPS查问能力，和千亿级别文档索引能力；内置QP和排序算法能力以及行业模板，实现垂直行业高质量搜寻成果；利用生态 性能差别 对立召回引擎满足不同用户的应用习惯，如果客户从Elasticsearch 进行查问，能够去调用凋谢搜寻外面QP的性能，而后提供查问剖析的能力给客户。如果是从凋谢搜寻这块进行查问，能够原生的应用凋谢搜寻查问剖析能力。 \>>如果有搜寻成果深度优化需要，能够填写专家征询问卷，参加试用即可收费取得凋谢搜寻通用分词能力。问卷地址：https://c.tb.cn/F3.05Srxl 如果你想与更多开发者们进行交换、理解最前沿的搜寻与举荐技术，能够钉钉扫码退出社群 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。有人说要把 Serverless 架构看成一种人造的分布式架构，须要用分布式架构的思路去开发 Serverless 利用。诚然，这种说法是正确的。然而在一些状况下，Serverless 还有一些个性，所以要转变开发观点。前言：__在 Serverless 架构下，尽管更多精力是关注业务代码，然而实际上对一些配置和老本也是须要关注的，并且必要的时候还须要依据配置与老本对 Serverless 利用进行配置和代码优化。 Serverless 利用开发观点的转变 Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。有人说要把 Serverless 架构看成一种人造的分布式架构，须要用分布式架构的思路去开发 Serverless 利用。诚然，这种说法是正确的。然而在一些状况下，Serverless 还有一些个性，所以要转变开发观点。 1、文件上传办法在传统 Web 框架中，上传文件是非常简单和便捷的，例如 Python 的 Flask 框架： f = request.files['file']f.save('my_file_path')然而在 Serverless 架构下，文件却不能间接上传，起因如下： 个别状况下，一些云平台的API网关触发器会将二进制文件转换成字符串，不便间接获取和存储；个别状况下，API 网关与 FaaS 平台之间传递的数据包有大小限度，很多平台限度数据包大小为 6MB 以内；FaaS 平台大多是无状态的，即便存储到以后实例中，也会随着实例开释而使文件失落。所以，传统 Web 框架中罕用的上传文件计划不太适宜在 Serverless 架构中间接应用。在 Serverless 架构中，上传文件的办法通常有两种：一种是转换为 Base64 格局后上传，将文件长久化到对象存储或者 NAS 中，但 API 网关与 FaaS 平台之间传递的数据包有大小限度，所以此办法通常实用于上传头像等小文件的业务场景。 另一种上传办法是通过对象存储等平台来上传，因为客户端间接通过密钥等来将文件直传到对象存储是有肯定危险的，所以通常是客户端发动上传申请，函数计算依据申请内容进行预签名操作，并将预签名地址返给客户端，客户端再应用指定的办法上传，上传实现之后，通过对象存储触发器等来对上传后果进行更新等，如下图所示。 在 Serverless 架构下文件上传文件示例 以阿里云函数计算为例，针对上述两种常见的上传办法通过 Bottle 来实现。在函数计算中，先初始化对象存储相干的对象等： 初始化对象存储相干的对象等： AccessKey = { "id": '', "secret": ''}OSSConf = { 'endPoint': 'oss-cn-hangzhou.aliyuncs.com', 'bucketName': 'bucketName', 'objectSignUrlTimeOut': 60}#获取/上传文件到OSS的长期地址auth = oss2.Auth(AccessKey['id'], AccessKey['secret'])bucket = oss2.Bucket(auth, OSSConf['endPoint'], OSSConf['bucketName'])#对象存储操作getUrl = lambda object, method: bucket.sign_url(method, object, OSSConf['object SignUrlTimeOut'])getSignUrl = lambda object: getUrl(object, "GET")putSignUrl = lambda object: getUrl(object, "PUT")#获取随机字符串randomStr = lambda len: "".join(random.sample('abcdefghijklqrstuvwxyz123456789 ABCDEFGZSA' * 100, len))第一种上传办法，通过 Base64 上传之后，将文件长久化到对象存储： ...

简介：目前云效全家桶的性能相对来说比拟适宜集体开发或者中小团队的群体，如果你此时正在为搭建这类治理平台做选型，同时估算和人力都顾此失彼，那么无妨试试云效这个产品！一起白嫖一起爽！尤其服务器资源在阿里云的小伙伴们，真得不能错过！作者|翟永超 周末的时候，收到好几个云服务器邻近过期的告诉短信，筹备续个费，竟然都要大几千！因为这几个都是以前高价抢购的，掐指一算，如果都续费的话，要鲸吞好多利润！ 作为一名本人养活本人的独立开发者，节省成本是必备技能，不然哪来可观的利润？于是，就开始推敲着做一些架构上的调整，看看是否在这次服务器资源缩小的状况下，持续低成本的运行目前还在跑的业务。 因为业务产品是最重要的，所以这块根本不能动。那么能动的就是一些周边设施了，比方：做工作治理、文档治理或继续交付的工具。在调研了诸多 SaaS 产品和云服务之后，最初抉择了阿里云的云效全家桶。为什么最终抉择了云效全家桶呢？外围起因还是“全家桶”三个字，基本上我想要的研发治理性能都是否笼罩了。那么这个全家桶具体能做什么呢？上面给大家分享下我革新前和革新后的平台构造，给大家一个直观的意识。 老架构：散装集成老架构的建设基本上借鉴了以前在公司里搭建根底平台时候所用的罕用开源产品和商业产品，按性能来分，次要有以下这几个： 代码仓库：GitLab继续集成：Jenkins工作治理：JIRA文档治理：ConfluenceGitlab 和 Jenkins 都是开源产品，收费且利用宽泛，是大部分公司的散装计划中会囊括的。JIRA 和 Confluence 尽管是商业产品，但高级版本的认证只须要 9.9 美元，对集体和 10 人以下小团队还是十分敌对的，因为 JIRA 弱小的流程配置性能，能够将其作为整个研发治理平台的门户。 补充：有很多开发者对于 JIRA 只认为是一个工作治理的工具，不太理解 JIRA 的工作流性能，这里简略阐明一下。JIRA 之所以弱小，有很大一点就是得益于其弱小的工作流配置性能。因为 GitLab、Jenkins 等这些工具都有 WebHook 或 JIRA 市场下的插件反对，咱们就能够很不便的把这些工具的应用步骤串联起来。这样咱们在软件研发过程中的业务需要、工作拆解、代码版本、构建部署等一体化过程都能够 JIRA 这样一个繁多入口中来实现。 所用资源：因为之前抢购的各个服务器配置都不高，大多是 1C2G、2C4G 的。为了稳固运行就都做了离开部署，一共耗费了 4 台 ECS。 计划长处： 学习成本低：这些产品都是互联网公司中十分常见的，大部分开发都不会太生疏。同时这些软件的生态都十分健全，都有很丰盛的插件市场来适应用户的各种需要。产品成本低：这里用到的产品不是收费就是很便宜，所以老本的根底老本不高计划毛病： 部署老本高：因为须要装置的软件产品多，部署老本较高新架构：云效全家桶在决定应用云效全家桶之后，接下来要做的就是对老架构中用到的各个产品找到代替的解决方案。上面跟着我的调研应用步骤，来看看这一个个产品的对应关系吧！ 代码仓库代码仓库在云效的解决方案中是一个名为云效Codeup 的产品，产品地址：https://codeup.aliyun.com/ 。如果你跟我一样，是要做仓库迁徙的话，非常简单。如下图所示，Codeup 为各种罕用平台都提供了专用的导入形式，对 Git 治理不是特地相熟的小伙伴也能够依据提醒轻松的实现代码仓库的迁徙。 在点击“导入代码库”之后，咱们能够看到下图界面，基本上罕用的一些 Git 治理平台都曾经反对，抉择你要迁徙的源平台，而后依据官网文档，找到对应平台须要获取的认证形式做好配置即可。 在实现认证信息配置好之后，Codeup 就会从对应的平台获取所有我的项目仓库，接下来只须要一一抉择你要导入的仓库点击“导入”按钮，就能轻松实现代码的迁徙。 这块比较简单，根本所有的 Git 治理平台都能够反对相似的迁徙操作。也不算特地的亮点吧，光从代码治理上来说，次要奉献就是为这次的革新打算节俭了一台 ECS。 继续集成实现了代码迁徙之后，接下来开整继续集成局部，对应的产品是云效 Flow，产品地址是：https://flow.aliyun.com/。 在云效 Flow中创立 CI/CD 的流水线非常简单，因为它提供了各个支流开发语言的多种继续集成案例的配置模版。 ...

简介：9月15日阿里云凋谢搜寻重磅公布【开源兼容版】，搜寻召回环节同时反对阿里云自研Ha3引擎与阿里云Elasticsearch引擎，并提供多行业的搜索算法能力，助力企业高效实现搜寻成果深度优化。9月15日，阿里云凋谢搜寻正式上线开源兼容版，搜寻召回环节同时反对阿里云自研Ha3引擎与阿里云Elasticsearch引擎，并提供多行业的搜索算法能力，助力企业高效实现搜寻成果深度优化。 搜寻是在线批发以及各类在线服务重要的流量入口，作为泛滥行业、企业的刚需性能，与行业特点、业务状态有着深度的关联。但对于很多抉择开源技术栈的企业而言，如果想要做到高质量的智能搜寻成果、更加优质的用户体验，必须在分词、用户用意辨认等NLP算法上投入大量的精力，而这正是目前基于Elasticsearch开源引擎无奈开箱获取的能力。 凋谢搜寻此次推出的开源兼容版正是为了解决上述问题，提供阿里自研的多行业搜索算法能力，赋予Elasticsearch引擎达摩院NLP先进技术和智能查问剖析能力。丰盛Elasticsearch分词库，提供了电商、教育、内容、游戏等行业分词器，分词成果与开源相比显著更优，可疾速晋升阿里云Elasticsearch等开源引擎的搜寻成果。 阿里云凋谢搜寻高级技术专家邢少敏示意，“凋谢搜寻开源兼容版目标是为更多企业提供低门槛甚至零门槛的高质量智能搜寻服务，从技术源头解决业务增长和转化的难题。” 据悉，凋谢搜寻服务平台利用在阿里外部和内部数千家企业，其独有的行业搜寻能力通过行业模板模式产品化落地，客户无需各方向技术摸索，一键接入即可领有高质量搜寻成果。将来也会继续深耕搜寻畛域技术，为开发者们提供更智能更便当的服务体验。 \>>阿里云凋谢搜寻开源兼容版发布会传送门：https://yqh.aliyun.com/live/opensearch 如果有搜寻成果深度优化需要，能够填写专家征询问卷，参加试用即可收费取得凋谢搜寻通用分词能力~ 问卷地址：https://c.tb.cn/F3.05Srxl 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Kubernetes 常识图谱遵循云原生人才学习门路搭建课程体系框架，及人才倒退路线设置不同阶段，由浅入深，帮忙云原生人才学习容器根底、Kuternetes 网络、存储、资源对象、服务发现、利用编排与治理等 Kubernetes 残缺技术栈内容，贯通实践、实际、体验，为宽广云原生畛域人才实现相干认证资格提供积攒专业技能的根底环境。什么是 Kubernetes 常识图谱？Kubernetes 常识图谱为云原生人才培养打算 2.0 推出的第一个系列内容。本课程由 Linux Foundation 开源软件大学、出名 IT 教育平台马哥教育、阿里云云原生团队专家联结出品，阿里云大学、阿里云开发者社区联合开发，遵循云原生人才学习门路搭建课程体系框架，及人才倒退路线设置不同阶段，由浅入深，帮忙云原生人才学习容器根底、Kuternetes 网络、存储、资源对象、服务发现、利用编排与治理等 Kubernetes 残缺技术栈内容，贯通实践、实际、体验，为宽广云原生畛域人才实现相干认证资格提供积攒专业技能的根底环境。 Kubernetes 常识图谱能力模块 Kubernetes 常识图谱六大劣势 五大高效学习工具 “Kubernetes 技能难点攻破系列训练营”**第一期重磅开营Kubernetes 难点攻破系列：容器长久化存储训练营作为生产环境中最突出的问题之一，有相当多的开源我的项目致力于解决云原生架构上的存储问题。不久前，阿里云容器服务 ACK 也推出了“容器网络文件系统 CNFS”，通过将阿里云的文件存储形象为一个 K8s 对象（CRD）的形式来进行独立治理，包含创立、删除、形容、挂载，监控及扩容等运维操作，破解企业提供容器环境中利用长久化存储的窘境。 9 月 22-24 日，咱们将和 ACK CNFS 及 NAS 的开发团队一起，利用 3 天工夫集中冲破，从容器长久化存储开始，关上 Kubernetes 难点攻破之旅。实现全副打卡工作，还有小米耳机、阿里云定制帽衫、精美周边等丰盛的训练营奖品等你来拿！ 钉钉扫描二维码，中转“容器长久化存储训练营”钉群，容器存储专家在线带你挑战 Kubernetes 难点！ 点击下方链接，退出 Kubernetes 残缺常识图谱学习：https://developer.aliyun.com/graph/Kubernetes 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：多年来，随着云计算技术的蓬勃发展和落地，越来越多的企业抉择采纳云计算技术来帮忙本人疾速实现业务数字化转型，以便能更好地适应市场变动，进而博得更大的市场空间。作者|郝树伟 Flexera 的《RightScale2021 云状态报告》中指出 92% 的大型企业采纳混合云策略。Gartner 也在一份报告中称将来 90% 中大型企业将利用混合云架构治理基础设施。 多年来，随着云计算技术的蓬勃发展和落地，越来越多的企业抉择采纳云计算技术来帮忙本人疾速实现业务数字化转型，以便能更好地适应市场变动，进而博得更大的市场空间。其中有很大一部分企业基于升高技术开发和运维老本、享受随时随地的即时服务等起因，抉择将本人的业务部署在云端；还有一部分企业因为数据主权和平安隐衷方面的思考，会抉择在本人外部数据中心环境中搭建本人的专有云平台；对于公共云和专有云都有需要的企业用户会抉择搭建混合云架构。 为什么须要混合云架构企业本身业务安全性思考 对于企业用户，特地是大型企业用户来说，把公司的要害“生命线”业务齐全托付给一个内部云厂商来保障，是有肯定的危险的。尽管公共云厂商通常都提供了安全可靠的冗余计划来保障企业用户服务的不间断性，但也并不是没有意外产生。应用混合云计划能够保障企业用户同时具备 A B 两套计划抉择和切换，最大限度保障业务稳定性。 数据主权和平安隐衷方面的监管要求一些法律法规或者公司本身的安全策略对其企业数据所存储或驻留的地点有硬性要求，比方欧盟的“通用数据保护条例”（GDRP）等对数据控制者和数据处理者的数字监管措施，比方企业政策要求数据只能驻留在指定地点，目标是为了爱护数据隐衷和安全性等等。混合云云架构能够帮忙企业用户满足这一类的需要。 享受云厂商的服务个性本地云与公共云厂商提供的服务质量是有肯定的差异性的，这种差异性体现在方方面面，取决于用户的理论需要和考量。比方地区覆盖面的差异性，企业用户通常在本地云中自提供的服务，在某个特定的区域内云厂商提供的服务在拜访提早上更优，企业用户在此区域有重要客户且对云服务的拜访提早有较高要求，则企业用户会抉择将此区域的业务部署在公共云上，其余业务持续部署在本地云上。 老本优化本地云在基础设施上不足灵便的扩缩容能力，无奈在业务顶峰和低谷期依据理论需要合理安排根底计算资源，造成很大水平上的资源节约和成本增加，而云上弹性麻利、按需扩缩容的个性，能够补救本地云的这一缺点。 追寻技术革新对与一些相似人工智能、机器学习、物联网等高精尖技术的技术革新和演进上，通常云厂商可能第一工夫提供与之绝对应的云服务，企业用户能够以更小的老本应用这些云服务，并推动企业本身的技术革新和倒退，混合云架构能够让企业随时随地采纳最好的云服务。 云原生如何助力混合云架构演进公共云和本地云自身就是两朵不同的云，它们有不同的基础设施、不同的能力个性以及不同的 API 接口，构建混合云架构，一方面须要云提供商消耗大量精力在适配和整合云平台的能力上，另一方面，用户在这种架构下也无奈真正按需切换云服务提供商，反而是另一种模式的绑定。传统混合云的种种缺点，导致这种云架构无奈造成标准化的生态体系，也是始终以来咱们无奈针对这种云架构构建对立治理、对立交付的起因。 Kubernetes 的呈现让混合云云架构进入 2.0 时代，Kubernetes 的多项个性及其相干生态体系为混合云的标准化提供了可能性： 以 Kubernetes 为代表的云原生技术屏蔽了基础设施的差异性，目前各个云厂商以及大量的数据中心都曾经落地这些技术，使得利用“一次定义，到处部署”成为可能。Kubernetes 标准化、申明式的 API，简化了利用的部署，让利用交付变得越来越标准化和统一化，反对在不同的云上应用雷同的形式形容和编排利用网格服务技术能够逾越多个 Kubernetes 集群，实现对立的流量治理和服务治理，使得混合云云架构下的应用服务对立到一个管制立体进行治理。在云原生时代，以 Kubernetes 为代表的云原生技术推动了以利用为核心的混合云架构的到来，Kubernetes 曾经成为企业多集群治理的事实根底。 云原生混合云多集群的典型应用场景异地多活——跨地区容灾尽管从基础设施服务和 Kubernetes 容器平台两个维度来看，用户能够低成本搭建一个高可用利用业务架构，但对于容灾能力要求更高的一些业务，还须要通过异地多活这样的地区级容灾能力来实现。 用户能够在繁多云厂商的不同区域搭建多个集群，也能够别离在线下 IDC 和线上云厂商的不同区域搭建多个集群来实现业务利用的异地多活部署。下图展现了混合云场景下 IDC 内的容器集群和公共云上的容器集群 Active-Active 部署，在异地多活架构下，利用的业务负载同时部署在多个集群上，而后应用一个全局的 DNS 服务将申请转发到对应的后端集群，当其中一个集群产生故障无奈解决申请时，DNS 服务会主动解决并只转发申请到衰弱的集群。 低延时——就近拜访对于发展全球化国内业务的用户来说，服务的访问者散布宽泛，如果服务器部署在某个特定的区域，势必会造成其余局部地区网络体验差的问题。 在这种场景下，咱们就能够抉择在多个地区别离部署集群，通过智能 DNS 解析将用户申请转发至间隔最近的集群解决，最大限度缩小网络带来的提早。例如下图中，某应用服务别离部署于北京，成都，香港三个地区的 Kubernetes 集群，来自华北区域的用户申请会被智能解析到北京的 Kubernetes 集群，来自东北区域的用户申请会被智能解析到成都的 Kubernetes 集群，来自海内的用户申请则会被智能解析到香港的 Kubernetes 集群，这样能够最大限度地缩小天文间隔带来的网络提早，为各地用户带来统一的服务体验。 升高爆炸半径通常状况下，多个小规模的集群要比一个大规模的集群更容易进行故障隔离。集群有可能因为磁盘、网络等故障导致无奈解决申请，应用多个集群能够将故障限度和隔离在某个集群，防止引起更大的连锁反应。 业务隔离不同的业务通常须要做好业务隔离，尽管 Kubernetes 自身也有命名空间的机制来帮忙用户做平安隔离，但这只是逻辑上的软隔离，不同 namespace 之间仍然能够网络互通，而且也还存在资源抢占的问题，须要进一步配置网络隔离策略和资源限额等。 ...

简介：在所有皆可视频化的明天，短视频内容作为挪动端产品新的促活点，受到了越来越多的器重与投入。盒马在秒播、卡顿率、播放成功率等根底优化之外，在用户应用体验上引入了无痕续播能力，晋升用户观看视频内容的延续性。本篇将分享盒马在 iOS 短视频方面的实际干货。作者｜神捕 审校｜泰一 跨页面续播是除秒播外另一个能够从体感上减少用户体验的能力。因为一些业务场景须要在不同页面上播放同一个视频内容的场景，而这些场景页面切换往往是间断的，这就要求短视频的播放也是间断。这样能力使得体验上会有连贯性，让用户在进入沉迷式页面时，能流畅的适度，且无感知的持续播放，从而产生间断不间断的感触。上面咱们开始介绍盒马短视频的跨页面续播能力和晦涩的动画切换成果的流畅性。 如上视频所示，视频在列表页预览观看后，用户很可能持续点击跳到下一个全屏页面，进入沉迷式体验。在这过程中，视频窗口平滑变大至全屏，视频进度是连续的，两头没有感觉到视频或音频的进展感。在页面返回后，视频窗口也有相应的还原成果。 指标接入简略，只须要关怀并加一个参数，其它逻辑内聚。适配性好，反对裁剪模式的切换。视频、音频无缝连接，不能有任何进展感。页面间播放状态隔离，互不烦扰。实现计划在计划抉择上，次要思考了以下三种： 目前盒马采纳的是第 3 种 ——playerView 的复用形式，具体来说，无痕续播的实现，至多须要以下几个步骤： 1. 用户点击，从 A 页面跳转到 B 页面，如：domain/path?reusedPlayerView=0xyyyyyy, 在原有业务参数的根底上，增加一个 reusedPlayerView 参数，把 playerView 传给下个页面 。 2. B 页面 HMTBPlayerView 的实例化：外部实例化一个或复用 A 页面的 reusedPlayerView。 3. playerView 的大小地位换算，实现切换动画。 4. 从 B 页面返回 A 时，实现退出动画并返还 playerView。 以上步骤不多，但具体实现起来是比较复杂的，上面咱们将围绕 4 个次要问题的解决过程，来阐明具体实现形式。 尺寸变动的动画失常来说，只有计算好 playerView 的原始 Rect，以及最终 Rect，基于 UIView 做 frame 动画就能够简略实现窗口变大成果。但实现时发现，手淘播放器外部重写了 setFrame 办法，只有批改了 frame，playerView 将间接显示为终态，动画没有成果。 于是，这里采纳了 CGAffineTransform 的 scale 实现：先把 playerView 的 frame 设置为终态，计算好变动前后的尺寸比例 ratio，设置 playerView.transform = CGAffineTransformMakeScale (ratio, ratio)，将其尺寸等比放大为初始地位大小，而后就能够执行 transform 的动画实现从终点到起点的变换。 ...

简介： “宜搭客户说”，聆听用户的声音，感触来自百行千业的用户应用宜搭的心得。 第二期“宜搭客户说”带你理解宜搭在跨境金融行业的利用，听听互联网公司用户是如何应用和评估宜搭的。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：毫末机器学习训练场景对于数据读取有较高的性能要求，且对于元数据和数据缓存的精细化管制要求较高， 通过 Fluid + JindoRuntime 的缓存能力能够灵便地缓存 OSS 训练文件进行元数据和数据，提供高效的元数据和数据拜访性能。基于这种计划，咱们能够实现精细化管制缓存的内容，进步生产资源利用率，不仅无效缓解了 OSS 带宽的压力，也大大提高了训练效率。作者介绍： 李范：毫末智行 服务端开发工程师，负责 AI 主动训练平台的研发与算法优化 陈铁文：毫末智行 服务端开发工程师，负责 AI 主动训练平台的下层研发 引言：Fluid 是云原生基金会 CNCF 下的云原生数据编排和减速我的项目，由南京大学、阿里云及 Alluxio 社区联结发动并开源。本文次要介绍毫末智行机器学习平台在主动驾驶场景的应用，以及如何基于 Fluid +JindoFS 冲破原有存储与计算拆散架构带来的性能瓶颈，从而进步生产资源利用率，无效缓解 OSS 带宽压力，并且大大提高训练效率的生产实践。 主动驾驶商业利用正驶入快车道毫末智行是一家致力于主动驾驶，提供智能物流解决方案的人工智能技术公司。企业使命为以零事变、零拥挤、自在出行和高效物流为指标， 帮助客户重塑和全面降级整个社会的出行及物流形式。 数据智能是毫末智行的外围能力，乘用车主动驾驶零碎及解决方案、低速无人车生态系统及解决方案、主动驾驶相干产品研发与定制服务三大垂类产品为数据智能服务， 数据智能反哺三大垂类产品，坚固其在各自市场内的相对领先地位。经近10年的积攒与全栈自研，以及90%以上的研发投入，在乘用车、低速无人车、智能硬件三个方 面一直积攒相干数据，目前已孵化出小魔盒、小魔驼、小魔盘等10余款成熟产品。 毫末智行的疾速倒退也体现着更高级别的智能驾驶将在更宽泛的场景中发挥作用，主动驾驶的商业利用正在驶入快车道。 传统机器学习训练效力遭逢瓶颈随着机器学习在主动驾驶业务场景中的宽泛应用，机器学习平台表演了十分外围的角色。该平台采纳了存储与计算拆散的架构，使得计算资源得以与存储资源解耦， 从而实现了灵便的资源配比以及便捷的存储扩大，并且升高了存储资金和运维老本。 然而，这种架构也带来了一些挑战，其中比拟要害的问题体现在数据拜访性能和稳定性方面： 1、计算存储拆散架构导致数据拜访高延时，导致训练慢： 业务团队应用的机器学习工作在训练过程中要实时频繁拜访 OSS 上的数据，在 OSS 带宽受限或者压力较大时， 拜访 OSS 上数据速度比拜访本地文件速度要慢很多； 2、Kubernetes 调度器数据缓存无感知，同一数据源屡次运行拜访仍旧慢： 在事实利用中深度学习工作运行会一直 反复拜访同一数据，包含雷同模型不同超参的工作、微调模型雷同输出的工作、以及 AutoML 工作等。这种深度学习工作的反复数据拜访就产生了能够复用的数据缓存。然而，因为原生 Kubernetes 调度器无奈感知缓存，导致利用调度的后果不佳，缓存无奈重用，性能难以晋升； 3、OSS 成为数据并发拜访的瓶颈点，稳定性挑战大： 毫末机器学习平台上的大量机器学习工作在同时训练时都会并发拜访后端 OSS 存储。这种并发机器学习训练造成的 IO 压力比拟大， OSS 服务成为了性能单点，一旦 OSS 带宽呈现瓶颈则会影响所有机器学习工作； 4、训练文件扩散，元数据压力大:  ...

简介：Apache Flink 社区携手一线企业重磅推出8大行业实际案例，本书整顿了 Flink 社区近一年的行业案例，供大家参考！Apache Flink 是一个开源的分布式大数据处理引擎,可对无限数据流和有限数据流进行有状态计算。它具备强一致性的计算能力、大规模的扩展性，整体性能十分卓越，同时反对SQL、Java、Python等多语言，领有丰盛的API接口不便各种场景业务应用。目前在国内外互联网企业中Flink曾经成为支流的实时大数据计算技术，是实时计算畛域的事实技术标准。 随着实时化需要的场景日益增多，企业更须要技术+场景的技术计划，来实现数据的价值最大化。Apache Flink 在行业利用中体现如何？新鲜出炉的《Apache Flink 行业案例集》带来了答案。整顿了 Flink 社区近一年热度最高的业务实际场景，并依照挪动媒体、生存服务、游戏、金融、在线教育、物流、在线交易、IT企业等八大行业进行分类。 点击收费下载《Apache Flink 行业案例集》 本书亮点8大行业20+厂商实在案例，场景丰盛；深刻理解阿里、字节、美团、腾讯、京东站等出名厂商实战经验，干货满满；精彩内容领先看 更有 Apache Flink 社区手册同步收费下载，Apache Flink 社区动静触手可及。 流动举荐 阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启流动： 99元试用实时计算Flink版(包年包月、10CU）即有机会取得 Flink 独家定制T恤；另包3个月及以上还有85折优惠！ 理解流动详情：https://www.aliyun.com/product/bigdata/sc 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：在企业的倒退过程中，如果不器重敏感数据的爱护，和数据安全体系的建设，那么一旦产生了敏感数据透露事件，轻则企业口碑受损，业务受影响；重则会直接触法律，受到主管部门的处罚和制裁。本文将以一个最常见的场景：消费者隐衷数据保护，展现如何利用Dataphin的平安能力，保障企业的数据安全。作者：龙裔 在《基于数据分类分级和敏感数据爱护，保障企业数据安全》一文中，咱们解说了Dataphin中资产平安的次要利用场景和基本概念，那么如何利用Dataphin的平安能力，来保障企业的数据安全呢？ 咱们来看一个最常见的案例：消费者隐衷数据保护。 场景介绍近几年，随着消费者集体意识的崛起和对隐衷的器重，数据安全成为了一个越来越热门的话题，国家也陆续公布了一些相干规定，来标准数据的采集和应用。在企业的倒退过程中，如果不器重敏感数据的爱护，不器重数据安全体系的建设，那么一旦产生了敏感数据透露事件，轻则企业口碑受损，业务受影响；重则会直接触法律，受到主管部门的处罚和制裁。 而在企业畛域的敏感信息中，集体敏感信息是相对的大头，包含集体的身份信息（姓名、身份证号码）、联系方式（手机、邮箱、地址）、个人财产信息、生物辨认信息等等，都属于集体敏感数据。这些数据一旦透露，对用户的集体生存以及对企业的业务运行，都会产生十分大的侵害，所以在企业的业务运行中，要对消费者的个人隐私数据进行脱敏爱护。 图片：支付宝中，对用户姓名与用户账号的脱敏爱护 次要流程首先，咱们回顾一下在Dataphin上，实现敏感数据爱护的次要流程： 在Dataphin中，实现敏感数据爱护，次要能够分为以下三个步骤： 1、辨认敏感数据：即设定数据分类、数据分级、辨认规定等内容 2、设置敏感数据保护方式：为辨认的敏感数据抉择适合的脱敏算法、设定脱敏规定 3、数据生产：在即席查问、开发数据写生产等场景进行数据生产时脱敏 具体步骤接下来，咱们以用户敏感信息中，最常见的用户姓名为例，展现如何一步步的首先用户姓名的辨认和脱敏爱护。 1、辨认敏感数据假如咱们曾经建设好了数据分类和数据分级（Dataphin会内置通用的分类和分级规范，反对开箱即用），咱们间接进入新建辨认规定的模仿步骤： 新建一个【用户姓名】的辨认规定； 扫描范畴抉择【全副】； 扫描形式抉择【内置辨认】-【名字】（如果用户姓名的字段都叫【name】，也能够配置正则规定【^name$】）； 数据分类抉择【集体数据（C）】； 数据分级抉择【秘密数据（L3）】（依据本人企业的状况灵便调衡）； 优先级抉择【3】（两头优先级，依据本人企业的状况灵便调整）； 配置实现辨认规定后，咱们能够触发一次【手动规定扫描】，或者等到第二天，零碎会主动执行一次全局扫描。最终敏感数据辨认的后果，都能够在【辨认记录】页面看到： 2、设置敏感数据保护方式辨认到敏感数据之后，下一步就是给敏感数据设置适合的保护方式，从而保证数据不透露。 Dataphin以后内置了多种遮蔽脱敏规定（如【张三】，显示成【*三】）、哈希脱敏规定（如【张三】，显示为【615DB57AA314529AAA0FBE95B3E95BD3】），能够满足大部分业务场景下的数据保护需要，并在将来反对加解密算法和用户自定义脱敏算法。 这里倡议大家依据业务需要，抉择适合的算法。比方对于用户姓名，在大部分的业务场景中（如支付宝转账），都是不能显示残缺的名称，然而能够显示一部分，用于身份确认，这样就能够抉择内置的【中文姓名】的脱敏算法 抉择好适合的脱敏算法之后，咱们就能够配置动静脱敏规定了，还是以用户姓名为例： 新建一个【用户姓名脱敏】的脱敏规定； 绑定曾经建好的敏感数据辨认规定【用户姓名】； 利用场景抉择【写开发表】、【即席查问】； 脱敏形式抉择【遮蔽掩码-中文姓名】； 失效范畴抉择【全副】 至此，咱们的敏感数据辨认和爱护就曾经齐全配置实现了，接下来在数据生产的过程中，就能够对数据进行爱护了。 3、数据生产上面已即席查问为例，展现敏感数据辨认和脱敏的成果： 能够看到，咱们开始往表格里写入的数据是【张三】，因为写入了敏感数据【name】字段，也就是【用户姓名】，所以在数据读取的时候，零碎主动的进行了脱敏，操作的同学只可能看到【*三】，从而避免敏感数据透露，爱护了数据安全。 结语下面通过用户姓名这样一个十分很简略的案例，串讲了整个敏感数据辨认和脱敏的主流程，置信能帮忙您了解整个数据安全爱护的机制；而在主流程之外，还有数据分类分级的制订、审核辨认记录并手动批改、脱敏白名单等流程。同时，在企业理论的数据安全爱护中，还有更多的零碎工作要做，比方制订合乎企业的数据分类分级体系、建设残缺的数据辨认体系等等。 理解产品更多内容能够戳入：https://dp.alibaba.com/product/dataphin 数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。 目前正通过阿里云对外输入系列解决方案，包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。 其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包含： - Dataphin，一站式、智能化的数据构建及治理平台；- Quick BI，随时随地 智能决策；- Quick Audience，全方位洞察、全域营销、智能增长；- Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；- Quick Stock， 智能货品经营平台；- Quick Decision，智能决策平台；官方站点： 数据中台官网 https://dp.alibaba.com 钉钉沟通群和微信公众号 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：很多时候人们是被本人心田的偏见所战胜的。作为一名程序媛，放弃一种对世界、对人生的不同认识，能够帮忙咱们建立本人的参照系，不被内部轻易左右。或者咱们无奈像一些凡人那样突破、推动如此重大的社会认知，然而咱们保持去做，就能实现更高的人生价值。作者 | 芸峥 前言我叫芸峥，来自阿里云云原生团队。喜爱写作，在博客上发表过几篇热门文章。作为一个从业多年，就任过三家企业的程序媛，明天给大家分享下：程序媛在心态方面要如何自我冲破。 每个行业都有本人的祖师爷，编程也不例外。值得程序员们骄傲的是，他们的这位祖师爷其实是位不折不扣的“白富美”——阿达•奥古斯塔（1815-1852）。她是英国著名诗人拜伦的女儿，19 岁时嫁给洛甫雷斯伯爵，成为洛甫雷斯伯爵夫人（Countess of Lovelace）。她死后一百多年，阿达之前对查尔斯·巴贝奇的《剖析概论》所留下的笔记被从新颁布，并被公认为对古代计算机与软件工程造成了微小的影响。当然咱们作为后继者，除了企慕和学习之外，可能也有很多焦虑。 时至今日，程序媛的三大焦虑时至 2021年，女程序员的待业占比将达到 20%，咱们作为这 20%的群体，我演绎了一下咱们大略有哪些焦虑：精力不够、技能不够、心态不够这三方面。 首先精力不够的话，咱们就没有足够的工夫去磨难技能，从而导致技能不够。技能不够又会让咱们在面对微小的工作压力时，无奈产生幸福感。为什么幸福不够呢？我想源头是在认知上。为了解决这个问题，我提出了一些办法供大家参考。 1、精力不够怎么办——沉迷式融入沉迷式融入是指当你做一件事件的时候全身心的投入，不要想的太多。 沉迷式融入家庭对于家庭来说的话，最次要要做到一点就是互相担待，相互磨合。就是说咱们的家庭是互相要去补位的。在生活中谁投入多，谁投入少这些并不是最重要的，最重要的是互相要了解，治家和治业其实是一个情理。 沉迷式融入工作第一步要融入周边的共事。 大家除了一起工作、一起打仗，也要一起玩。能够说自从进入工作工作岗位当前，咱们的大部分工夫都奉献给了工作，只有少部分工夫属于家庭和自我。所以白天在工作中开开心心的，早晨能力在家放释怀心的劳动。作为共事，咱们单方奔赴，互相去融入，一起神往远方，一起呐喊自在，最终的能力求同存异，找到共同点，同时也保留本人最特色的一部分。 第二步是要解决好你的汇报关系。 汇报关系次要有两种：一种是常见的垂直性能组织，一种是横向的我的项目组织。垂直性能组织中，常见的比如说技术团队里次要向技术 leader 汇报。而在横向的我的项目组织里，咱们通常是拉通多个 BU，由一个 PM 作为总指挥。 在垂直性能组织里，咱们向上对主管进行汇报，向下对上司下发指令，聆听他的诉求，满足他的要求。在垂直性能组织里，很多人会觉得很有压力。其实只有咱们将主管、上司这样的角色身份当做本人工作中的一个资源。让领导更好的帮忙咱们工作，咱们也帮忙他收集更多的信息，辅助他的工作。另外，当初很多公司越来越偏向于扁平化组织，垂直性能组织的职责逐步被淡化，员工之间的分工协作逐步会向项目管理模式歪斜。 在横向的我的项目组织里，要均衡两个关系：上游和上游。在我的项目单干中，咱们通常将上游当做乙方去看待：约定好你对它的诉求，对其须要的接口。用比拟程序化的语言来说就是要对齐输入输出参数。要将本人的诉求以一种更加具体的数据等模式体现进去。当然咱们只须要关怀本人的上游，而不须要关怀上游的上游。在我的项目单干中，还要一个十分重要的关系：上游。咱们通常将上游当做甲方去看待。咱们给上游提供本身的产品或零碎能力等，当上游在应用这些产品或零碎能力时，咱们要去依赖、跟踪。这样看起来是有一些像微服务的。梳理好各自的依赖、梳理好各自的输入输出参数，用微服务的理念来管理工作。 当然咱们光用技术语言和我的项目语言也是无奈齐全解决好汇报关系的。因为不论甲方也好、乙方也罢，都是一个活生生的人。咱们要在跨团队单干中，要找到单方独特的利益点。如果一件事件只对本身无利，而对他人无利，这样的单干关系是不短暂的。当然咱们也能够去发明无利的条件，将对他人不利的中央转变成无利。 无论是垂直的性能组织还是横向的我的项目组织，我感觉重点肯定是要做好信息的替换。咱们工作中80%的工夫都在解决信息的对齐问题。只有咱们清晰的表白，能力更好的解决信息替换。（留神，这里指的思路清晰是指别人认为你的思路清晰，而不是本人认为。）做好信息替换就是指：向上要做好信息的聚合，向下要做好信息的分类。对于向上来说，信息聚合可能会有小局部失真，但这并不是最重要的，咱们肯定要拉长工夫线看效力，就是说最终的后果是否是最优的。 第三步就是扩大社会关系。 其实作为一个程序媛，咱们不只有工作，还会有兴趣爱好的个人等，社会关系越宽泛，咱们对生存的认知也更加趋向于多层次，咱们的心理状态能够寄情于多方面，心田也就更加文件自信，更不容易被战胜。 最初是集体脸谱，或者说是集体画像。 职场中我认为是没有相对的对事不对人。人因事结缘，事靠人落地。咱们在与其他人接触沟通的过程中，他人通常会给咱们画一个脸谱，这个脸谱可能就决定了下次跟你单干的态度。比方当咱们遇到某些不喜爱的工作时，是十分抗拒的去实现，还是用更致力态度去实现，他人是能够感知到的。咱们尽量抉择本人感兴趣的工作，用更多的微笑、更加轻松的心态去面对单干的每一个人，能力“路遥知马力，日久见人心”。这其实也是咱们每个人大脑中脸谱库是在一直的修改和更新信息中。 2、技能不够怎么办——自我管理、继续积攒、挑战自我。技能不够的话，我感觉第一步就是要做好自我布局与治理。而后第二步就是你要继续的积攒。第三步就是挑战自我。 自我管理——金字塔原理 当今互联网时代，信息大爆炸，也能够说是数据大爆炸。将数据-信息-常识-智慧这个转化逻辑做好，长于解决接管到的信息，才算做好了自我管理的第一步。咱们肯定要长于从信息中去开掘问题，发现矛盾。进而更好的定义它的优先级和重要性，继而更好的去总结演绎。总结演绎反过来又会帮忙咱们更好的从信息中是开掘问题根源。这时候就须要善用金字塔原理。我感觉金字塔原理相对来说属于说易行难。只有将它化为本人血液中的一部分，变成潜意识中就是必须去重视的一个点，能力算是较好的把握了它。反复屡次的能够训练才是职场中胜人一筹的真正秘笈。 咱们将信息演绎解决完后，曾经辨别出哪些是紧急的，哪些是重要的。这时候就要做一个取舍。其实工作的实质就是衡量和取舍。从下班开始的第一分钟到上班前的最初一分钟，咱们每一步都是在衡量和取舍。有时候咱们会感觉一个事件很纠结，其实并不是做事的过程让咱们纠结，而是在做事的过程中产生的取舍让咱们纠结。网上有句“名言”：小孩子才做抉择，成年人两个都要。我私心里认为这可能是个悖论，个别状况下人的欲望总是超过事实，总比咱们能够达到的水平要高一些。在一个时间段内，咱们优先做什么、延后做什么这就是在做取舍。 取舍不是说是永恒的取舍，而是要在一个工夫范畴去看。比方咱们在做职业规划时，前三年做什么，后三年做什么，各个时间段内要有一个重点。不可能说前三年的职业规划里，我既要实现财产自在，又要实现仗剑走咫尺的自在现实。有时候取舍并不难，难的是取舍后，第二天的悔恨。这些情绪会极大的影响咱们。一旦做了决定，就要义无反顾不要悔恨，也不要思虑过多而解体。如果咱们决定前五年在工作上达到一个成就，后五年全面投入家庭，就要给本人有一个打算，判若两人的坚持下去。 自我管理——迁延和优先级做完取舍、抉择之后就是执行了。执行时最次要的是克服迁延症。即使咱们将重要紧急等事务辨别的再好，一旦产生了迁延，那么重要紧急也要毫无意义。这里给大家介绍一个迁延症克星——2 分钟准则：如果某项工作不到 2 分钟即可实现，那么就立刻去执行。 咱们在执行中还须要留神另一个问题：谨防优先级成为迁延的接口。当咱们曾经定义好事件的优先级时，执行的过程中产生了更加重要紧急的工作，然而当下执行中的事务还没有达到预期的成果，就可能被烦扰。所以咱们应该拉长工夫去看效率自身，谨防优先级成为迁延借口。另外一个可能导致迁延症的“病因”就是“完满偏向”。其实过程中的不完满相对而言真的没有那么重要。即便最初真的迁延了，也不会太过挂怀。拿我来说，我的工作的有时候工作特地重，就想着我周末要不要加个班？等到周一了，才发现周末其实没加班，而是去看了本人很喜爱的小说。放在以前我可能会十分后悔，然而当初我会感觉我本人开心了，也算是另一种失去和满足，就是常说的收之东隅失之桑榆。 继续积攒——多学做完了取舍，确定了优先级就要开始执行了。那咱们如何执行呢？多学多做。初入职场，不要像太多，多看多学多做，只有积攒到了肯定水平，能力“悟”，一开始就像“悟”只能让本人陷入纠结。给大家提一个我本人学习的小 TIPS：我每年都会给本人列一个书单，云原生、人工智能、量子计算、区块链、处世哲学等，感兴趣的内容都列出来，有工夫就看一会，没工夫也不要有压力，缓缓看，保持学，总会有所播种。 继续积攒——多做大家都听过“一万小时定律”。翻译过去就是：平凡人做不凡事。咱们在本人身上的投资是会经验一个从质变到量变的。一直积攒，缓缓就会超过很多人。说不准当前就能成就什么奇观呢？ 挑战自我——人与环境我置信很多人都会有同样的懊恼：环境不好导致无心工作。我本人是待过阿里妈妈、用友、云原生等不同职场环境的，最终我发现，其实工作环境大同小异，更多的晋升本人才是终极解决办法。 咱们想要换个环境工作的理由，不外乎以下几条： 1、换个环境才踊跃。老板给予的压力太大、公司平台不适宜本身倒退、业务太忙或者太闲等都很容易让咱们想要换环境。然而换环境要有度，不能一直的调换，否则本人就很容易进入一个困乏状态，以前的积攒也会逐渐清零。 2、换不了环境才踊跃。网络上甚嚣尘上的 35 岁焦虑论，让很多人不敢辞职，不敢换环境，所以只能“踊跃工作”。这种状况下可能更须要一个类型冲破，即便咱们来到了阿里，也不能说本人就没有第二段幸福的工作旅程。防患未然，提前准备，不论是财务筹备也好、技术储备也罢，提前给本人加一层担保，就能更好的去适应环境。 3、换不换环境都踊跃。有些人并不在乎身边的环境，不论什么环境，他都能发光发热，都能把事件做好。即便当下公司某些制度我并不称心，那我是否致力走到高层，扭转一些规定呢？尽管这些人是多数，然而对于公司来说的确十分重要的。 人们常说林子大了什么鸟都有，那到底是林子的问题还是鸟的问题呢？其实林子说白了它背地代表是一群人，不同的鸟就是不同的集体。所以人与环境的问题，归根结底还是人与人的问题。公司要汰换活水，补充新鲜血液，就意味着老人肯定会被嫌弃吗？前些日子看到一篇帖子年轻人在阿里没有机会了，中年人在阿里也没有机会了。过后我感觉特地决裂，到底是年轻人没有机会了呢，还是中年人没有机会了呢？不同的 BU 中，不同的业务中又是如何定义年轻人和老人的呢？仅仅是简略的通过年龄去判断吗？还是通过他在该畛域的教训与常识呢？在阿里外部，你能够理解更多不同 BU、不同业务的新常识、新技术，其实也是另一种意义上的“永远年老”。 挑战自我——造轮子与翻新就我集体而言是十分喜爱翻新，我很少去做那种没有技术含量的工作，但这不是说我拿到的工作都是有技术含量的，而是遇到没有技术含量的，就翻新一下，让他变得有技术含量。比方阿里晚期运维工程师是特地多的，然而随着云原生、容器、虚拟机等技术反动，带给这个职位更多的变动，提出了 DevOps、SRE、AIOps 等，运维畛域在一直的被自动化掉，所以说翻新是无处不在的。翻新也不是自古华山一条路这样的简略，翻新能够是开辟式翻新、降级式翻新、也能够是组合式翻新、差异化翻新等。有一双长于发现翻新的眼镜，无时无刻不想着去“偷懒”、去扭转，而不是安于现状，那么就会发现许多须要改善的点。可能改善的这个笑点还不足以被称为翻新，然而咱们一直积攒，不断改进、一直思考，思想境界就会失去一个极大的晋升，可能 5 年后，就会对当初的本人造成降维打击。另外一种则是跨维打击：以己之长，攻彼之短。尤其是作为一名女程序员，我在团队中不能算技术上最牛X，在业务上也没有那么牛X。然而我真的闪光点在于能够将业务和技术更好的去联合。在团队和业务中找准本人的定位，找到本人最适宜倒退的方向，才算有了本人的生存之道。 讲到翻新就不得不提到一个词“造轮子”。高水平的造轮子是翻新之母。我集体是不拥护高水平造轮子的，毕竟很多人很多事都是先从模拟开始的，如果一个业务正处于发展期，其零碎三个月小重构，三年大重构，都是正当的。然而须要咱们留神的是：谨防低水平造轮子和内卷式造轮子。 ...

简介：联邦家私通过钉钉宜搭低代码，走出了一条适宜家具行业理论业务场景的数字化解决方案。 “你好！我新买的沙发呈现了一点问题，是否解决下？”这是联邦家私售后组张小姐接到的一通400电话。联邦家私是一家深耕行业37年的家具品牌，产品远销国内外，有1000多家线下门店。 “消费者在购买家具前次要思考品牌可不牢靠，购买后更关怀产品是否按时交付，遇到问题是否及时处理。”联邦家私利用开发经理石春晓示意，“联邦家私很早就开始思考如何通过构建线上线下、渠道终端一体化的全渠道管理体系，实现一客到底、一单到底的高效经营。” 2008年起，联邦家私就先后引进ERP、物流、MES等数字零碎，开始摸索数字化、智能化降级之路。然而，外采零碎只能解决局部问题，大量个性化场景和需要无奈失去满足。 公司短少一套数字化售后管理系统。顾客购买商品后呈现问题，个别会通过拨打400电话或者间接去当地门店解决。如果遇到当下无奈疾速解决的状况，就会波及到返厂培修、运输等繁琐的环节，工夫破费半个月到20天不等，周期长，跟踪也较为艰难。 传统的Excel治理，无奈实现售后问题的自主提报，售后进度的实时跟踪和客户评估的及时反馈。售后处理过程中波及的门店、厂家、消费者三方相干的图片、视频、文字等数据，服务指令的下达，服务后果的反馈，消费者满意度等等，都没有标准化的零碎去标准和积淀，导致服务质量不容易把控。 走外购零碎，少则投入十几万多则上百万，老本投入是一方面，买来当前零碎的各种水土不服是另一方面。如果下决心自建一套零碎，IT部门在评估了所投入的人力资源和工夫老本后，也只得放弃。 在比照了外购零碎宏大的开销和自建零碎昂扬的人力投入当前，石春晓发现：“以钉钉宜搭为代表的低代码平台，可能疾速地响应咱们多样化的需要。通过可视化拖拽的形式，平时2周能力开发实现的利用，我用宜搭1天就能实现，大大缩短了开发周期，企业也把握了核心技术。” 联邦家私IT部门借助宜搭弱小的集成和连贯能力，买通了不同零碎之间的信息孤岛，一人仅花一周工夫为企业量身定制了专属的售后业务零碎，显著进步了上下游的协同效率。 （图注：基于钉钉宜搭打造的家具行业售后解决方案） （图注：基于钉钉宜搭打造的售后平台） 零碎实现了售后服务流程的提报、跟踪和评估的全链路清爽追踪。依据不同类型客诉，走不同的流程。 1、返厂培修：总部断定本次售后是否免费，如果免费则预估费用，门店承担费用比例，预计解决工夫。 2、当地培修：上传报销凭证及品质问题图片，总部根据费用金额进行分级审批。此外，还有上门培修、整机补发、借货、退货等类型的售后流程。 （图注：基于宜搭审批流实现的售后服务全流程） （图注：售后服务录入零碎） 门店一旦有售后需要先按惟一条码录入零碎，零碎反对详情形容、售后图片、售后视频的提报。总部客服收到需要后及时沟通解决计划，断定品质责任，相干业务人员会立刻收到音讯揭示，24小时未解决则预警揭示。所有数据都能及时、精确、全面地记录在零碎中，不便公司对售后问题进行溯源剖析，防止同类问题再度产生。 同时，借助宜搭弱小的集成能力，售后管理系统跟生产ERP零碎、财务零碎、物流零碎都做了买通，物流出了货当前，能够在售后零碎实时看到货物的物流状态。 （图注：基于钉钉宜搭搭建的品质问题注销零碎） （图注：基于钉钉宜搭搭建的服务满意度零碎） 如何通过业务在线，发展一体化的售后服务治理，一直晋升用户的满意度，是摆在联邦家私IT部门背后的难题。现在，他们通过钉钉宜搭低代码的尝试，走出了一条适宜家具行业理论业务场景的数字化解决方案。 “联邦家私领有上千家门店，从软件老本上思考，节俭几十万的费用是有的。一个人一个星期打造实现，宜搭十分简便，非常灵活。”在谈到对宜搭的认识时石春晓这样示意，“一个人能够走的很快，一群人能够走的更远，心愿更多的同路人一起钻研低代码，助力传统企业更快地走上数字化转型的路线。” 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： DataWorks性能实际系列，帮忙您解析业务实现过程中的痛点，进步业务性能应用效率！ 往期回顾： DataWorks 性能实际速览01期——数据同步解决方案：为您介绍不同场景下可选的数据同步计划。DataWorks 性能实际速览02期——独享数据集成资源组：为您介绍进行数据同步时，可应用的资源组与网络连通计划、注意事项。DataWorks 性能实际速览03期——生产开发环境隔离：为您介绍DataWorks通过规范模式提供开发环境与生产环境隔离及不同环境的权限要求。通过往期的介绍，您曾经理解到在DataWorks上进行工作运行的最要害的几个知识点，接下来为您逐渐介绍如何通过DataWorks的工作节点实现最常见的数据开发场景。本期为您介绍如何在DataWorks上实现参数透传，即把上游工作的参数透传到上游工作。 性能举荐：赋值节点与参数节点在阿里云DataWorks中，一个数据开发工作最终是拆解为多个节点工作，并通过设置节点间上下游关系最终造成一个残缺的数据开发业务流程，如下图所示。 以上为一个简略的示例，在理论利用时，咱们通常会碰到这样的状况，拆解进去的上游节点工作会生成一些参数，或上游节点的运行后果，须要在上游节点工作中利用到，这就须要数据开发工作可能实现参数/节点运行后果在各个节点间的透传，依据不同的透传需要，DataWorks提供了两种非凡节点能够实现：赋值节点与参数节点。 Part1：赋值节点 - 实现工作后果透传当您须要将上游节点工作的后果提供给上游节点应用时，您可应用赋值节点，实现工作后果在节点间传递。赋值节点反对ODPS SQL、SHELL和Python三种赋值语言，且依据赋值规定，主动为您增加赋值参数（outputs参数），便于其余节点援用。 应用赋值节点进行透传参数时，需关注以下三个要点。 1.1赋值节点与上下游节点间的依赖关系 如上图所示，应用赋值节点透传参数时： 赋值节点（fuzhi\_python、fuzhi\_sql、fuzhi\_shell）需作为援用赋值节点参数节点（down\_compare）的上游节点，上游节点须要与赋值节点设置间接依赖关系(赋值节点为上游节点的一层父节点)。赋值节点作为上游与其它节点配合应用时，请务必先提交赋值节点，以便上游节点在配置时能够解析出参数。1.2赋值节点与上游节点的上下文参数透传关系如下图所示，通过赋值节点与援用节点的调度配置中的上下文参数配置，造成参数透传援用关系： 赋值节点（fuzhi\_python、fuzhi\_sql、fuzhi\_shell）需将待赋值给上游的参数增加为节点上下文中的本节点输入参数。上游援用赋值参数的节点需将待援用的赋值参数增加为节点上下文中的本节点输出参数。阐明： 赋值节点参数传递只反对传递给一层子节点，不反对跨节点传递。1.3赋值语言与赋值后果援用赋值节点后果时，赋值节点的参数输入格局与上游节点援用参数形式有关系，不同语言的赋值参数（outputs参数）赋值阐明如下。 赋值语言outputs参数取值outputs参数格局outputs参数大小限度ODPS SQL最初一行SELECT语句的输入作为赋值参数，增加为赋值节点的本节点输入参数，供其余节点援用。将输入后果作为一个二维数组传递至上游。传递值最大为2 MB。如果赋值语句的输入后果超过该限度，赋值节点会运行失败。SHELL最初一行ECHO语句的数据，增加为赋值节点的本节点输入参数，供其余节点援用。将输入后果基于逗号（,）宰割为一维数组。Python最初一行PRINT语句的输入，增加为赋值节点的本节点输入参数，供其余节点援用。将输入后果基于逗号（,）宰割为一维数组。 更多赋值节点的介绍可进入帮忙核心查看文档配置赋值节点。 ## Part2：参数节点 - 实现参数透传参数节点是一种非凡的虚构节点，用于治理业务流程中的参数和实现参数在工作节点中传递，反对常量参数、变量参数和透传上游节点的参数，须要援用参数的节点间接依赖参数节点即可。参数节点实质上是一种虚构节点，不会运行数据计算工作产生数据，次要用于跨节点传参、参数治理的场景。 ### 2.1跨节点传参当数据开发的业务流程中，某个上游节点的工作须要获取多个、多级上游节点的输入参数时，您能够应用参数节点，将上游节点须要获取的所有参数对立增加至参数节点中，后续上游节点可间接挂在参数节点之下，即可获取到所有所需参数。以上图为例，sql\_7节点须要获取sql\_1、sql\_3、sql\_4节点的输入参数，此时您能够新增一个参数节点，作为sql\_1、sql\_3、sql\_4的上游节点，并将所有sql\_7所需参数增加至参数节点中，将sql\_7的挂在此参数节点上游，则sql\_7可间接通过参数节点获取到所有所需参数。 ### 2.2参数治理当数据开发的业务流程中，上游节点的工作须要应用某些常量参数、变量参数时，您能够应用参数节点，将上游节点须要应用的参数均增加至参数节点中，需应用参数的上游节点间接挂在参数节点之下，即可获取应用所需参数，便于整个业务流程中对所有应用的参数进行对立治理。以上图为例，sql\_3、sql\_4、sql\_5、sql\_7节点均需应用参数，此时您能够新增一个参数节点，将各个上游节点应用的参数都增加至参数节点中，将须要应用参数的节点挂在此参数节点上游。更多参数节点的介绍可进入帮忙核心查看文档创立参数节点。 ## Part3：赋值节点与参数节点的比照 比照项赋值节点参数节点透传场景节点运行后果透传节点参数透传透传限度仅能透传至一层子节点，不反对跨节点透传可跨节点透传节点属性一种工作节点，节点中运行赋值工作，反对<span>ODPS SQL、SHELL和Python三种赋值语言</span>实质上是一种虚构节点，不会运行工作产生数据 > 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： HSF 和 Dubbo 的交融是大势所趋。为了能更好的服务内外用户，也为了两个框架更好倒退，Dubbo 3.0 和以 Dubbo 3.0 为内核适配团体内基础架构生态的 HSF 3 应运而生。作者 | 郭浩 Dubbo 和 HSF 都是阿里巴巴目前在应用的微服务 RPC 框架。HSF 在阿里巴巴应用更多，承接了外部从单体利用到微服务的架构演进，撑持了阿里历年双十一的安稳运行；Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。 自 2008 年 5 月公布第一个版本 1.1 后，经验数年迭代，HSF 从一个根底的 RPC 框架逐步演变成为日撑持十万亿级别调用的易于扩大的微服务框架。外部场景中，用户既能够抉择大量配置轻松接入微服务体系，获取高性能的稳固服务调用。也能够依照本身业务需要，对 HSF 进行扩大，获取整条链路的能力加强。 Dubbo 我的项目诞生于 2008 年，起初只在一个阿里外部的零碎应用；2011 年，阿里 B2B 决定将整个我的项目开源，仅用了一年工夫就播种了来自不同行业的少量用户；2014 年，因为外部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴募捐至 Apache 毕业的我的项目。 Dubbo 和 HSF 在阿里巴巴的实际2008 年的时候，团体外部淘系次要应用的服务框架是 HSF， 而 B2B 应用的则是 Dubbo。二者独立，各行其道，彼此不通。随着业务飞速发展，跨语言、跨平台、跨框架的需要日益显著，不同业务间彼此互联互通的呼声越来越高，而且很快演变成为简直整个团体的需要。即淘系能够调用 B2B 的服务，反之亦然。 ...

简介：本文基于MySQL 8.0.25源码进行剖析和总结。这里MySQL Server层指的是MySQL的优化器、执行器局部。咱们对MySQL的了解还建设在5.6和5.7版本的了解之上，更多的是比照PostgreSQL或者传统数据库。然而从MySQL 8.0开始，继续每三个月的迭代和重构工作，使得MySQL Server层的整体架构有了质的飞越。上面来看下MySQL最新的架构。背景和架构本文基于MySQL 8.0.25源码进行剖析和总结。这里MySQL Server层指的是MySQL的优化器、执行器局部。咱们对MySQL的了解还建设在5.6和5.7版本的了解之上，更多的是比照PostgreSQL或者传统数据库。然而从MySQL 8.0开始，继续每三个月的迭代和重构工作，使得MySQL Server层的整体架构有了质的飞越。上面来看下MySQL最新的架构。 咱们能够看到最新的MySQL的分层架构和其余数据库并没有太大的区别，另外值得一提的是从图中能够看出MySQL当初更多的增强InnoDB、NDB集群和RAPID(HeatWave clusters)内存集群架构的演进。上面咱们就看下具体细节，咱们这次不随着官网的Feature实现和重构程序进行了解，本文更偏差于从优化器、执行器的流程角度来演进。 MySQL 解析器Parser 首先从Parser开始，官网MySQL 8.0应用Bison进行了重写，生成Parser Tree，同时Parser Tree会contextualize生成MySQL形象语法树（Abstract Syntax Tree）。 MySQL形象语法树和其余数据库有些不同，参考《MySQL 8.0 新的火山模型执行器》文章，是由让比拟让人拗口SELECT\_LEX\_UNIT/SELECT\_LEX类交替形成的，然而这两个构造在最新的版本中曾经重命名成规范的SELECT\_LEX -> Query\_block和ELECT\_LEX\_UNIT -> Query\_expression。Query\_block是代表查问块，而Query\_expression是蕴含多个查问块的查问表达式，包含UNION AND/OR的查问块（如SELECT * FROM t1 union SELECT * FROM t2）或者有多Level的ORDER BY/LIMIT (如SELECT * FROM t1 ORDER BY a LIMIT 10) ORDER BY b LIMIT 5 例如，来看一个简单的嵌套查问： (SELECT * FROM ttt1)UNION ALL (SELECT * FROM (SELECT * FROM ttt2) AS a, (SELECT * FROM ttt3 UNION ALL SELECT * FROM ttt4) AS b)在MySQL中就能够用上面形式表白： 通过解析和转换后的语法树依然建设在Query\_block和Query\_expression的框架下，只不过有些LEVEL的query block被打消或者合并了，这里不在具体开展。 MySQL prepare/rewrite阶段接下来咱们要通过resolve和transformation过程Query\_expression::prepare->Query\_block::prepare，这个过程包含（按性能分而非齐全依照执行程序）： Setup and Fixsetup\_tables : Set up table leaves in the query block based on list of tables.resolve\_placeholder\_tables/merge\_derived/setup\_table\_function/setup\_materialized\_derived : Resolve derived table, view or table function references in query block.setup\_natural\_join\_row\_types : Compute and store the row types of the top-most NATURAL/USING joins.setup\_wild : Expand all '*' in list of expressions with the matching column references.setup\_base\_ref\_items : Set query\_block's base\_ref\_items.setup\_fields : Check that all given fields exists and fill struct with current data.setup\_conds : Resolve WHERE condition and join conditionssetup\_group : Resolve and set up the GROUP BY list.m\_having\_cond->fix\_fields : Setup the HAVING clause.resolve\_rollup : Resolve items in SELECT list and ORDER BY list for rollup processingresolve\_rollup\_item : Resolve an item (and its tree) for rollup processing by replacing items matching grouped expressions with Item\_rollup\_group\_items and updating properties (m\_nullable, PROP\_ROLLUP\_FIELD). Also check any GROUPING function for incorrect column.setup\_order : Set up the ORDER BY clause.resolve\_limits : Resolve OFFSET and LIMIT clauses.Window::setup\_windows1: Set up windows after setup\_order() and before setup\_order\_final()setup\_order\_final: Do final setup of ORDER BY clause, after the query block is fully resolved.setup\_ftfuncs : Setup full-text functions after resolving HAVINGresolve\_rollup\_wfs : Replace group by field references inside window functions with references in the presence of ROLLUP.Transformationremove\_redundant\_subquery\_clause : Permanently remove redundant parts from the query if 1) This is a subquery 2) Not normalizing a view. Removal should take place when a query involving a view is optimized, not when the view is created. remove\_base\_options: Remove SELECT\_DISTINCT options from a query block if can skip distinctresolve\_subquery : Resolve predicate involving subquery, perform early unconditional subquery transformationsConvert subquery predicate into semi-join, orMark the subquery for execution using materialization, orPerform IN->EXISTS transformation, orPerform more/less ALL/ANY -> MIN/MAX rewriteSubstitute trivial scalar-context subquery with its valuetransform\_scalar\_subqueries\_to\_join\_with\_derived: Transform eligible scalar subqueries to derived tables.flatten\_subqueries : Convert semi-join subquery predicates into semi-join join nests. Convert candidate subquery predicates into semi-join join nests. This transformation is performed once in query lifetime and is irreversible.apply\_local\_transforms : delete\_unused\_merged\_columns : If query block contains one or more merged derived tables/views, walk through lists of columns in select lists and remove unused columns.simplify\_joins : Convert all outer joins to inner joins if possibleprune\_partitions ：Perform partition pruning for a given table and condition.push\_conditions\_to\_derived\_tables : Pushing conditions down to derived tables must be done after validity checks of grouped queries done by apply\_local\_transforms();Window::eliminate\_unused\_objects: Eliminate unused window definitions, redundant sorts etc.这里，节俭篇幅，咱们只举例关注下和top\_join\_list相干的simple\_joins这个函数的作用，对于Query\_block中嵌套join的简化过程。 比照PostgreSQL为了更清晰的了解规范数据库的做法，咱们这里援用了PostgreSQL的这三个过程： Parser 下图首先Parser把SQL语句生成parse tree。 testdb=# SELECT id, data FROM tbl_a WHERE id < 300 ORDER BY data; Analyzer/Analyser 下图展现了PostgreSQL的analyzer/analyser如何将parse tree通过语义剖析后生成query tree。 Rewriter Rewriter会依据规定零碎中的规定把query tree进行转换改写。 sampledb=# CREATE VIEW employees_list sampledb-# AS SELECT e.id, e.name, d.name AS department sampledb-# FROM employees AS e, departments AS d WHERE e.department_id = d.id;下图的例子就是一个蕴含view的query tree如何开展成新的query tree。 ...

简介：2021年9月3日，北京弹力科技有限公司发表成为阿里云IoT智慧消防畛域的行业合伙人，一起打造城市消防畛域的数字化解决方案。9月3日，以“凋谢生态·单干共赢”为主题的阿里云&弹力科技主题论坛在杭州召开。现场汇聚了权威部门领导、业界知名企业代表等1000+行业人士就消防物联网产业衰弱倒退等话题进行深度探讨、交流学习。 在十四五布局中，“新基建”“智慧城市”成为时代热词，城市建设一直被提及，智慧消防更是智慧城市公共安全的重要组成部分。 阿里云IoT消控宝产品基于阿里自研AI算法，实现对消防通道占用、消控室人员离岗等多种消防隐患场景的智能辨认与监测，预警信息及时通过钉钉、电话、等伎俩告诉到责任人。为消防监管部门、各类消防监管单位提供由“人为监控”向“智能监控”转变的技术手段。 会上，北京弹力科技有限公司发表成为阿里云IoT智慧消防畛域的行业合伙人。阿里云IoT智能城市业务总经理吴金海示意，阿里云和金舟消防（弹力科技为金舟消防全资子公司）将在智慧消防我的项目中进行全方位单干，实现优势互补，独特倒退。联结为客户提供智慧消防服务，打造城市消防畛域的数字化解决方案。 将来，阿里云IoT消控宝将继续进行技术革新，助力消防安全建设。智慧消防城市合伙人继续招募中，欢送入群交换！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：“宜搭客户说”是宜搭新推出的栏目，聆听用户的声音，感触来自百行千业的用户应用宜搭的心得是咱们的初衷。第一期“宜搭客户说”带你理解宜搭在教育行业的利用，听听来自教育局的用户是如何应用和评估宜搭的。 “宜搭客户说”是宜搭新推出的栏目，聆听用户的声音，感触来自百行千业的用户应用宜搭的心得是咱们的初衷。第一期“宜搭客户说”带你理解宜搭在教育行业的利用，听听来自教育局的用户是如何应用和评估宜搭的。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：云原生的Serverless数据库，正在成为下一个五年的云数据库发展趋势。 近日，在国内数据库顶级会议2021 ACM SIGMOD上，一篇以PolarDB Serverless为主题的论文，被评委会认为指引了下一代数据库服务的倒退方向。 这篇题为《PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers》的论文，介绍了阿里云自研数据库PolarDB基于计算存储拆散，实现的最新Serverless技术架构研究进展。 PolarDB Serverless论文的录用，标记着阿里云PolarDB数据库在最新一云原生的Serverless数据库，正在成为下一个五年的云数据库发展趋势。 近日，在国内数据库顶级会议2021 ACM SIGMOD上，一篇以PolarDB Serverless为主题的论文，被评委会认为指引了下一代数据库服务的倒退方向。 这篇题为_《PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers》_的论文，介绍了阿里云自研数据库PolarDB基于计算存储拆散，实现的最新Serverless技术架构研究进展。 PolarDB Serverless论文的录用，标记着阿里云PolarDB数据库在最新一代架构的摸索上迈出当先一步。 以下是这项冲破的核心内容介绍：  _01_第一代云原生数据库的窘境 晚期的云上数据库，大部分是以ECS中的自建数据库和云厂商托管的数据库RDS的状态存在的，到目前为止还是有十分大的用户量。 这些云上数据库架构还是传统数据库的架构，只是运行在云的基础设施上，数据库自身并没有为云做太多的革新和适配。局限于其架构，各项资源等比率的限度在一个范畴内，其弹性范畴、资源利用率都受到较大的限度，无奈充分利用云的红利。 以亚马逊Aurora和阿里云PolarDB为代表的第一代云原生数据库，第一次对数据库架构进行了革新，实现了存储和计算拆散，并基于此实现了一写多读，肯定水平上适配云架构，存储实现了池化和按量付费，这是对云数据库十分大的提高。 但此架构下，CPU和内存仍然是强绑定的，导致计算要实现真正按需供给也十分艰难。也就是说，CPU资源和内存资源是一个整体，只能作为一个最小的单位升降级。例如，在亚马逊Aurora中，计算资源和缓存资源的比例是1core CPU：2GB内存。 然而，CPU和内存资源比例的绑定对一些场景下对用户是不合理的： 例如，剖析型内存数据库用户，用户应用多数CPU来定期同步和更新数据，但须要大内存，因为维表数据、或者两头后果须要缓存在内存里防止从磁盘来读的提早。 事务型数据库，例如电商等互联网利用场景里，客户的利用往往存在热点，因而大量的内存就足够保障缓存命中率超过99%，但顶峰时CPU须要弹到64c甚至更多核，CPU的需要会高于内存的需要。 简而言之，因为第一代云原生数据库无奈实现计算和内存资源的解耦，这也是导致目前云原生数据库价格仍然高于RDS和自建数据库，无奈占据大部分市场的外围起因。  _02_ 实现新架构的冲破 不过，随着PolarDB Serverless新架构的率先提出，这种状况可能要呈现极大扭转。 PolarDB Serverless的最大翻新之处在于：在业内首次实现了内存与计算/存储的解耦，内存进一步池化，造成三层池化，使得弹性能力有数量级的晋升，同时内存池化大幅度降低了老本，实现了齐全地按量应用和按需弹性，贴合各种场景。 PolarDB Serverless构建了一个全新的数据库状态，即DCaaDB_（Datacenter as a Database）_： 整个IDC造成一个多租户的大数据库，其全副的CPU，内存，存储形成三个独立的资源池。在资源池未耗尽的状况下，任何一个用户（租户）都可能任意的弹性扩大任何一种资源到任何一个规格，用户为其SQL动静耗费的CPU、内存和存储买单，不须要预置任何的规格。 这种状况下，CPU和内存资源因其池化其使用率将会大幅度晋升，云原生数据的老本将会远低于自建和RDS等一体化数据库，云原生技术的价值将会失去充沛的体现，数据库市场将会从新洗牌。  _03_ 背地的技术难点 在PolarDB Serverless之前，学术界曾经对拆散架构有肯定的钻研，并且也进行了一些技术上的试验，然而都没有解决拆散架构下的数据库的性能和弹性问题。 PolarDB Serverless通过进行技术创新解决了困扰业界的难题： 1） PolarDB Serverless中引入了多租户、分布式的内存池的设计，包含页面调配和生命周期治理。 第一个挑战是减少内存池设计后，确保零碎能正确的执行事务。 例如，一个被批改过的数据页不应该读到老的数据，即便跨节点也是如此，咱们应用全局的缓存统一的机制（相似于多核cpu之间缓存一致性机制）来实现。 还有，当主节点正在决裂或合并一个 B+Tree 索引，其余节点不应看到两头不统一的 B-tree 构造，咱们须要应用全局页锁来爱护它。 当节点执行只读事务时，它必须防止读取未提交事务写入的任何内容，咱们通过在数据库节点之间同步全局视图来实现它。 ...

简介：2020 年 10 月 23日，阿里巴巴正式发表开源其首个 Serverless 开发者平台 Serverless Devs。历经近一年精心打磨，明天 Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升，更加贴近开发者的理论生产诉求，应用体验再晋升，让开发者像应用手机一样玩转 Serverless，疾速享受 Serverless 技术红利。 作者 | 寒斜、江昱 2020 年 10 月 23日，阿里巴巴正式发表开源其首个 Serverless 开发者平台 Serverless Devs。历经近一年精心打磨，明天 Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升，更加贴近开发者的理论生产诉求，应用体验再晋升，让开发者像应用手机一样玩转 Serverless，疾速享受 Serverless 技术红利。 这就是 Serverless DevsServerless Devs 是一个开源凋谢的 Serverless 开发者平台，Serverless Devs 也是业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理的平台，致力于为开发者打造 Serverless 利用开发一站式服务, 帮忙解决目前的工具链之困，让开发者一键体验多云产品，极速部署 Serverless 我的项目。 Serverless Devs 由"两端一核心体系"组成： Serverless Devs CLI (命令行客户端)，适宜极客开发人员应用，玲珑轻便，易于集成Serverless Desktop (桌面客户端) ，具备更宽泛的适用性，领有开发，构建，部署，调试，可观测等全方位利用治理能力Serverless Hub 利用核心，提供利用的集散和散发，作为公共服务提供给 开发者或贡献者实用。 ...

简介：疫情来临，疫情态势剖析和防控工作火烧眉毛，如果疾速搭建高效的疫情态势剖析零碎是泛滥部门和单位的难题，阿里云RDS PG+Ganos解决方案可在极短时间内实现剖析零碎搭建，无效助力疫情防控。 中转最佳实际：【阿里云数据库疾速搭建疫情剖析零碎最佳实际】 最佳实际频道：【最佳实际频道】 这里有丰盛的企业上云最佳实际，从典型场景入门，提供一系列我的项目实际计划，升高企业上云门槛的同时满足您的需要！ 场景形容疫情来临，疫情态势剖析和防控工作火烧眉毛，如果疾速搭建高效的疫情态势剖析零碎是泛滥部门和单位的难题，阿里云RDS PG+Ganos解决方案可在极短时间内实现剖析零碎搭建，无效助力疫情防控。 计划劣势性能优越：Ganos作为自研的时空数据库引擎，相比postgis性能更优良。平安稳固：故障主动切换自愈，资源隔离，多正本存储。简略易用：开箱即用，兼容postgresql，买通quickbi疾速搭建数据分析展现。功能强大：相比postgis在时空模型上做了较多裁减，反对几何模型，栅格模型，网络模型，时空轨迹模型，点云模型，拓扑网络模型。业务架构 中转最佳实际 》》 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：PolarDB由阿里巴巴自主研发的下一代关系型分布式云原生数据库。在兼容传统数据库生态的同时，冲破了传统单机硬件的限度，为用户提供大容量，高性能，极致弹性的数据库服务。一、背景 传统的关系型数据库有着悠久的历史，从上世纪60年代开始就曾经在航空畛域发挥作用。因为其谨严的强统一保障以及通用的关系型数据模型接口，取得了越来越多的利用，大有一统天下的声势。 2000年当前，随着互联网利用的呈现，很多场景下，并不需要传统关系型数据库提供的强一致性以及关系型数据模型。相同，因为疾速收缩和变动的业务场景，对可扩展性(Scalability)以及可靠性(Reliable)更加须要，而这个又正是传统关系型数据库的弱点。 天然地，新的适宜这种业务特点的数据库呈现，就是咱们常说的NoSQL。然而因为不足强一致性及事务反对，很多业务场景被NoSQL拒之门外。同时，不足对立的高级的数据模型，拜访接口，又让业务代码承当了更多的累赘。数据库的历史就这样经验了否定之否定，又螺旋回升的过程。而这一次，鱼和熊掌咱们都要。 PolarDB就是在这种背景下呈现的，由阿里巴巴自主研发的下一代关系型分布式云原生数据库。在兼容传统数据库生态的同时，冲破了传统单机硬件的限度，为用户提供大容量，高性能，极致弹性的数据库服务。 二、核心技术之共享存储 PolarDB采纳了Share Storage的整体架构。采纳RDMA高速网络互连的泛滥Chunk Server一起向下层计算节点提供块设施服务。一个集群能够反对一个Primary和多个Secondary节点，别离以读写和只读的挂载模式通过RDMA挂载在Chunk Server上。PolarDB的计算节点通过libpfs挂载在PolarStores上，数据依照Chunk为单位拆分，再通过本机的PolarSwritch散发到对应的ChunkServer。每个ChunkServer保护一组Chunk正本，并通过ParallelRaft保障正本间的一致性。PolarCtl则负责保护和更新整个集群的元信息。 Bypass KernelPolarDB诞生于2015年，因为RDMA高速网络的呈现，使得网络带宽靠近于总线带宽。PoalrDB作出大胆的假如，那就是将来数据库的瓶颈将由网络转向软件栈本人。因而PolarStore中采纳了大量的Bypass Kernel的设计。首先是新硬件的应用，NVME和RDMA的应用，解脱了IO拜访过程中的用户态内核态交互。 软件设计中，在绑定CPU，非阻塞IO的模式下， 通过状态机代替操作系统的线程调度，达到Bypass Kernel的目标。 ParallelRaftPolarStore中采纳三正本的形式来保证数据的高可用，须要保障正本间的一致性。工业界有成熟的Raft协定及实现，但Raft因为对可了解的谋求，要求程序确认以及程序提交。而正本的确认提交速度会间接影响整个PolarStore的性能。为了取得更好的访问速度，PolarStore提出了ParallelRaft协定，在Raft协定的框架下，利用块设施拜访模式中不便断定拜访抵触的特点，容许肯定水平的乱序确认和乱序提交，如下图所示：在所有曾经确认提案中，那些对前序拜访有拜访Range抵触的提案会被临时Block，而没有抵触的提案会进入Ready状态并commit，commit当前的提案会持续反馈给以后的Scheduler，之前被Block的提案有可能会进入Ready状态，进而持续被提交。 三、核心技术之物理复制采纳了共享存储的模式之后，Secondary上仍然须要从Primary来的复制逻辑来刷新内存构造，如果Buffer Pool以及各种Cache。然而，因为读写节点和只读节点拜访的是同一份数据，传统的基于binlog的逻辑复制形式不再可用，这时因为逻辑复制因为最终执行程序的变动，导致主从之间不同的物理数据结构。因而DB层基于Redo Log的物理复制的反对是必不可少的： 不同于逻辑复制自上而下的复制形式，物理复制的复制形式是自下而上的，从共享存储中读取并重放REDO，重放过程会间接批改Buffer Pool中的Page，同步B+Tree及事务信息，更新Secondary上的各种内存Cache。除了反对共享存储外，物理复制还能够缩小一份日志写。同时，因为整个复制过程不须要等到事务提交能力开始，显著地缩小了复制提早： 四、交易场景优化针对双十一峰值交易场景，PolarDB也做了大量优化。 Blink Tree在峰值交易场景中，会有大量波及热点page的更新及拜访，会导致大量对于这些热点Page的SMO操作， 之前PolarDB在SMO场景下因为B+Tree实现有如下的加锁限度： 同一时刻整个B+Tree 有且只能有一个SMO在进行；正在做SMO的B+Tree分支上的读取操作会被阻塞直到整个smo实现。针对这个问题PolarDB做了如下优化： 通过优化加锁，反对同一时刻有多个SMO同时进行，这样本来期待在其余分支做SMO的插入操作就无需期待，从而进步写入性能；引入Blink Tree来替换B+Tree并通过缩小SMO的加锁粒度，将本来须要将所有波及SMO的各层Page加锁直到整个SMO实现后才开释的逻辑，优化成Ladder Latch，即逐层加锁，批改完一层即可放锁而后去加上一层Page锁持续批改。这样本来被SMO阻塞的读操作会有机会在SMO两头进来：通过对每个节点减少一个后继链接的形式，使得在Page Split的中间状态也能够实现对Page平安的拜访，如下图所示，传统的B+ Tree必须通过一把锁来Block整个Page Split过程中对所影响的Page的拜访。而Blink Tree则不须要，即便Split还在进行中，父节点到子节点的链接还没有实现建设，仍然能够通过前一个节点的后继链接找到正确的子节点。并且通过非凡解决确保拜访到正确的Page，从而进步读取性能。 通过这些对B+ Tree的优化，能够实现交易场景PolarDB读写性能晋升20%。 Simulated AIOInnoDB中有simulated AIO的逻辑，用于反对运行在不蕴含AIO的零碎下，PolarDB下的共享存储文件系统就是没有AIO的，所以采纳的是simulated AIO的逻辑。 然而原版中的simulated AIO是基于本地存储设计的，与分布式存储的个性并不适配。为了进行IO合并，原版的simulated IO设计，将所有异步IO申请依照指标地址进行组织，寄存在同一个IO数组中，不便将指标地址间断的小IO合并成大IO来操作，以晋升IO的吞吐。 然而这个设计与分布式存储是不相适配的，间断的大IO操作，会使得同一时刻，只有一个或大量存储节点处在服务状态，节约了其余存储节点的作用；另外，分布式存储的网络提早较大，高负载下，网络中的Inflight IO会较多，IO组中的IO申请数量也会很多，而这种组织形式下，IO数组中的槽位状态都无序的，往数组中增加IO申请和移除IO申请的开销都很大。 所以，PolarDB在高负载下的性能比拟差且不稳固，为此PolarDB专门对simulated AIO进行了从新的设计，次要包含： a.正当地抉择IO合并和拆解，充沛利分布式存储的多节点劣势； b.建设状态有序的IO服务队列，缩小高负载下的IO服务开销。 从新设计下，性能晋升了很多 稳定性也有了很大的晋升 Partitioned Lock SystemPolarDB采纳的是2PL + MVCC的并发管制形式。也就是用多版本数据构建Snapshot来服务读申请，从而防止读写之间的拜访抵触。而读写之间的抵触须要通过两阶段锁来保障，包含表锁，记录锁，谓词锁等。每当须要加锁的时候，之前的做法都须要去log\_sys中先取得一把全局的mutex爱护。在峰值的交易场景中，大量的写入会导致这个中央的mutex成为瓶颈。因而PolarDB采取了Partition Lock System的形式，将log\_sys革新成由多个LockSysShard组成，每个Shard中都有本人部分的mutex，从而将这个瓶颈打散。尤其是在这种大压力的写入场景下显著的晋升写入性能。 ...

简介：云原生趋势下，利用容器化比例正在快速增长，Kubernetes 也已成为云原生时代新的基础设施。背景云原生趋势下，利用容器化比例正在快速增长，Kubernetes 也已成为云原生时代新的基础设施。 察看明天的容器和 Kubernetes 的利用现状，能够看到两个广泛的景象： 首先，在云上托管 Kubernetes 曾经成为企业上云及运行容器的优先选择；另外，用户应用容器的形式也在产生扭转，从“无状态利用”到“外围企业应用到数据智能利用”，越来越多的企业应用容器来部署生产级别、复杂度高和高性能计算的有状态利用。比方 Web 服务、内容资料库、数据库，甚至 DevOps、AI/大数据利用等。 利用迭代快、服务更新频繁是云原生利用的重要特色，也是云原生利用场景中绕不开的强需要。对容器和 Kubernetes 技术有所理解的同学都晓得，尽管 Kubernetes 在许多方面十分有用，例如可伸缩性、可移植性和治理能力，但受限于其架构设计思维，原生 Kubernetes 对存储状态的反对不足，因而长久化存储始终以来都是容器技术的一大挑战。 当然，原生 Kubernetes 本身也提供了一些治理存储的解决方案，比方长期选项、长久化存储卷、长久化存储卷申明、存储类和有状态正本集等，但这可能非常容易带来凌乱。如果你想理解 Kubernetes 存储的相干常识，能够通过阿里云开发者社区公布的“云原生人才培养打算之 Kubernetes 常识图谱”的相干章节学习。 K8s 常识图谱地址：https://developer.aliyun.com/graph/Kubernetes 围绕云原生技术的工具和我的项目大幅减少。作为生产环境中最突出的问题之一，有相当多的开源我的项目致力于解决云原生架构上的存储问题。不久前，阿里云容器服务 ACK 也推出了“容器网络文件系统 CNFS”，通过将阿里云的文件存储形象为一个 K8s 对象（CRD）的形式来进行独立治理，包含创立、删除、形容、挂载，监控及扩容等运维操作，破解企业提供容器环境中利用长久化存储的窘境。感兴趣的同学欢送通过《剑指企业级云原生，阿里云 CNFS 如何破局容器长久化存储窘境》这篇文章理解。 为了帮忙更多开发者理解为什么容器须要长久化存储、Kubernetes 容器服务编排的基本概念、长久化存储的架构和实现形式，并通过实战把握容器长久化存储的最佳实际，阿里云容器服务团队与开发者社区独特打造了“Kubernetes 难点攻破训练营系列”，和开发者们一起应答学习和应用 Kubernetes 的挑战。 「Kubernetes 难点攻破系列：容器长久化存储训练营」启动倒计时!9 月 22-24 日，咱们将和 ACK CNFS 及 NAS 的开发团队一起，利用 3 天工夫集中冲破，从容器长久化存储开始，关上 Kubernetes 难点攻破之旅。实现全副打卡工作，还有小米耳机、阿里云定制帽衫、精美周边等丰盛的训练营奖品等你来拿！ 还等什么？我在“容器长久化存储训练营”等你！钉钉扫描下方二维码或点击下方链接，即可理解训练营报名加入形式： https://developer.aliyun.com/learning/trainingcamp/kubernetes 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：PolarDB与开源MySQL及其它类MySQL的产品相比，除了计算与存储拆散的先进架构之外，另外一个最外围的技术冲破就是开发了其它类MySQL产品没有的并行查问引擎，通过并行查问引擎，PolarDB除了放弃本身对OLTP利用的劣势之外，还对OLAP的反对能力有了一个质的飞越，遥遥领先于其它类MySQL产品。PolarDB与开源MySQL及其它类MySQL的产品相比，除了计算与存储拆散的先进架构之外，另外一个最外围的技术冲破就是开发了其它类MySQL产品没有的并行查问引擎，通过并行查问引擎，PolarDB除了放弃本身对OLTP利用的劣势之外，还对OLAP的反对能力有了一个质的飞越，遥遥领先于其它类MySQL产品。 用户越来越多的剖析统计需要        家喻户晓，MySQL的优化器目前还不反对并行优化，也不反对并行执行。当然，MySQL本人也在逐步摸索并行执行的可能，比方对count(*)的并行执行，但整体上，还没有造成一套成熟的并行优化、并行执行的机制，只是针对一些非凡的场景进行局部优化。随着类MySQL产品在云上的蓬勃发展，越来越多的传统用户迁徙到类MySQL产品上，对MySQL提出了一些新的挑战。很多传统用户在对OLTP要求的同时，还要求数据库有一些剖析、统计、报表的能力，绝对传统商业数据库来说，MySQL在这方面有显著的劣势。为了满足用户一直晋升的OLTP能力，同时又能进行OLAP剖析的需要，PolarDB的并行查问引擎应运而生。自诞生以来，通过弱小的并行执行能力，原来须要几百秒的查问，当初只须要几秒，为用户节俭了大量的工夫和金钱，失去大量用户的极大好评。 PolarDB并行查问引擎应运而生        优化器是数据库的外围，优化器的好坏简直能够决定一个数据库产品的成败。开发一个全新的优化器，对任何团队都是一个微小的挑战，技术的复杂度暂且不提，就是想做到产品的足够稳固就是一个十分难以克服的艰难。因而即便传统商业数据库，也是在现有优化器的根底上不断改进，逐步减少对并行的反对，最终成为一个成熟的并行优化器。对PolarDB也是如此，在设计和开发并行查问引擎时，咱们充分利用现有优化器的技术积攒和实现根底，不断改进，一直打磨，最终造成了一个继续迭代的技术计划，以保障新的优化器的稳固运行和技术革新。         对于一个类OLAP的查问，不言而喻的是它通常是对大批量数据的查问，数据量大意味着数据远大于数据库的内存容量，大部分数据可能无奈缓存到数据库的buffer中，而必须在查问执行时才动静加载到buffer中，这样就会造成大量IO操作，而IO操作又是最耗时的，因而首先要思考的就是如何能减速IO操作。因为硬件的限度，每次IO的耗时根本是固定的，尽管还有程序IO和随机IO的区别，但在SSD曾经流行的明天，两者的差别也在逐步靠近。那么还有没有其它形式能够减速IO呢? 显然并行IO是一个简单易行的办法，如果多个线程能够同时发动IO，每个线程只读取局部数据，这样就能够疾速的将数据读到数据库的buffer中。然而如果只是将数据读取到buffer中，而不是立刻进行后续解决，那么这些数据就会因buffer爆满导致数据被换出，从而失去减速IO的意义。       图1-并行IO示意图         因而，在并行读取数据的同时，必须同时并行的解决这些数据，这是并行查问减速的根底。因为原有的优化器只能生成串行的执行打算，为了实现并行读取数据，同时并行处理数据，首先必须对现有的优化器进行革新，让优化器能够生成咱们须要的并行打算。比方哪些表能够并行读取，并且通过并行读取会带来足够的收益；或者哪些操作能够并行执行，并且能够带来足够的收益。并不是说并行化革新肯定会有收益，比方对一个数据量很小的表，可能只是几行，如果也对它进行并行读取的话，并行执行所须要的多线程构建所须要的代价可能远大于所失去的收益，总体来说，并行读取会须要更多的资源和工夫，这就得失相当了，因而并行化的革新必须是基于代价的，否则可能会导致更重大的性能褪化问题。 Fact表的并行扫描        通过基于并行cost的计算和比拟，抉择能够并行读取的表作为候选，是并行执行打算的第一步。基于新的并行cost，兴许会有更优的JOIN的程序抉择，但这须要更多的迭代空间，为避免优化过程耗费太多的工夫，放弃原有打算的JOIN程序是一个不错的抉择。另外，对于参加JOIN的每张表，因为表的拜访办法不同，比方全表扫描、ref索引扫描，range索引扫描等，这些都会影响到最终并行扫描的cost。         通常咱们抉择最大的那张表作为并行表，这样并行扫描的收益最大，当然也能够抉择多个表同时做并行扫描，前面会持续探讨更简单的状况。 上面以查问年度生产TOP 10的用户为例: SELECT c.c_name, sum(o.o_totalprice) as s FROM customer c, orders o WHERE c.c_custkey = o.o_custkey AND o_orderdate >= '1996-01-01' AND o_orderdate <= '1996-12-31' GROUP BY c.c_name ORDER BY s DESC LIMIT 10; ...

简介：HSF 和 Dubbo 的交融是大势所趋。为了能更好的服务内外用户，也为了两个框架更好倒退，Dubbo 3.0 和以 Dubbo 3.0 为内核适配团体内基础架构生态的 HSF 3 应运而生。作者 | 郭浩 Dubbo 和 HSF 都是阿里巴巴目前在应用的微服务 RPC 框架。HSF 在阿里巴巴应用更多，承接了外部从单体利用到微服务的架构演进，撑持了阿里历年双十一的安稳运行；Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。 自 2008 年 5 月公布第一个版本 1.1 后，经验数年迭代，HSF 从一个根底的 RPC 框架逐步演变成为日撑持十万亿级别调用的易于扩大的微服务框架。外部场景中，用户既能够抉择大量配置轻松接入微服务体系，获取高性能的稳固服务调用。也能够依照本身业务需要，对 HSF 进行扩大，获取整条链路的能力加强。 Dubbo 我的项目诞生于 2008 年，起初只在一个阿里外部的零碎应用；2011 年，阿里 B2B 决定将整个我的项目开源，仅用了一年工夫就播种了来自不同行业的少量用户；2014 年，因为外部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴募捐至 Apache 毕业的我的项目。 Dubbo 和 HSF 在阿里巴巴的实际2008 年的时候，团体外部淘系次要应用的服务框架是 HSF， 而 B2B 应用的则是 Dubbo。二者独立，各行其道，彼此不通。随着业务飞速发展，跨语言、跨平台、跨框架的需要日益显著，不同业务间彼此互联互通的呼声越来越高，而且很快演变成为简直整个团体的需要。即淘系能够调用 B2B 的服务，反之亦然。 ...

简介：本文重点介绍了优化器的基于规定的其中一部分优化，更多的偏重于SQL中的根本操作符一  背景和架构咱们都晓得，利用编写程序来动静实现咱们利用所须要的逻辑，从而程序执行时失去咱们须要的后果。那么数据库就是一种通过输出SQL字符串来疾速获取数据的利用。当然，假如没有数据库这种零碎利用，用程序如何实现呢？咱们可能会发现，即便不论数据如何存储、数据是否并发拜访，依然须要一直通过批改程序处理不同利用对数据的不同申请。比方大数据畛域，咱们通常通过非关系型数据库的API，实现对数据的获取。然而这种形式尽管入门简略，然而保护极难，而且通用性不强，即便一直进行软件架构设计或者形象重构，依然须要一直地变换利用，这也是为何非关系型数据库回头拥抱数据库SQL优化器的起因。 SQL优化器实质上是一种高度抽象化的数据接口的实现，通过该设计，客户能够应用更通用且易于了解的SQL语言，对数据进行操作和解决，而不须要关注和形象本人的数据接口，极大地解放了客户的应用程序。 本文就来通过图形讲解的形式介绍下MySQL 8.0 SQL优化器如何把一个简略的字符串（SQL），变成数据库执行器能够了解的执行序列，最终将数据返还给客户。弱小的优化器是不须要客户关注SQL如何写的更好来更快取得须要的数据，因而优化器对原始SQL肯定会做一些等价的变动。在《MySQL 8.0 Server层最新架构详解》一文中咱们重点介绍了MySQL最新版本对于Server层解析器、优化器和执行器的总体介绍，包含一些代码构造和变动的具体展现，并且通过simple\_joins函数抛砖引玉展现了MySQL优化器在逻辑变换中如何简化嵌套Join的优化。本文咱们会一步一步带你进入神奇的优化器细节，具体理解优化器优化局部的每个步骤如何扭转着一个SQL最终的执行。 本文基于最新MySQL8.0.25版本，因为优化器转换局部篇幅比拟长，咱们分成两篇文章来介绍，第一局部介绍基于根本构造的Setup和Resolve的解析转换过程，第二局部介绍更为简单的子查问、分区表和连贯的简单转换过程，纲要如下： Setup and Resolvesetup\_tables : Set up table leaves in the query block based on list of tables.resolve\_placeholder\_tables/merge\_derived/setup\_table\_function/setup\_materialized\_derived : Resolve derived table, view or table function references in query block.setup\_natural\_join\_row\_types : Compute and store the row types of the top-most NATURAL/USING joins.setup\_wild : Expand all '*' in list of expressions with the matching column references.setup\_base\_ref\_items : Set query\_block's base\_ref\_items.setup\_fields : Check that all given fields exists and fill struct with current data.setup\_conds : Resolve WHERE condition and join conditions.setup\_group : Resolve and set up the GROUP BY list.m\_having\_cond->fix\_fields : Setup the HAVING clause.resolve\_rollup : Resolve items in SELECT list and ORDER BY list for rollup processing.resolve\_rollup\_item : Resolve an item (and its tree) for rollup processing by replacing items matching grouped expressions with Item\_rollup\_group\_items and updating properties (m\_nullable, PROP\_ROLLUP\_FIELD). Also check any GROUPING function for incorrect column.setup\_order : Set up the ORDER BY clause.resolve\_limits : Resolve OFFSET and LIMIT clauses.Window::setup\_windows1: Set up windows after setup\_order() and before setup\_order\_final().setup\_order\_final: Do final setup of ORDER BY clause, after the query block is fully resolved.setup\_ftfuncs : Setup full-text functions after resolving HAVING.resolve\_rollup\_wfs : Replace group by field references inside window functions with references in the presence of ROLLUP.二  具体转换过程转换的整个框架是由Query\_expression到Query\_block调用prepare函数(sql/sql\_resolver.cc)并且依据不同转换规则的要求自顶向下或者自底向上的过程。 ...

简介： Nacos作为整个阿里云原生三位策略中的外围组成部分，咱们在2018年以Configserver/VIPServer/Diamond为根底通过Nacos开源输入阿里十年积淀的注册核心和配置核心能力，并且疾速成为国内首选。并且通过云产品MSE以BaaS模式输入解决方案能力。作者：彦林（李艳林），彦林（李艳林），Nacos PMC，阿里云 MSE 产品创始人，阿里云软负载团队负责人。阿里云原生三位一体策略解读阿里巴巴开源、自研、商业化技术三位一体，用私有云反对阿里团体上云，以开源为内核做外部扩大，以商业化为根底做外部定制；后端BaaS化，客户端轻量化，业务侧Serverless化。 Nacos作为整个阿里云原生三位策略中的外围组成部分，咱们在2018年以Configserver/VIPServer/Diamond为根底通过Nacos开源输入阿里十年积淀的注册核心和配置核心能力，并且疾速成为国内首选。并且通过云产品MSE以BaaS模式输入解决方案能力。 Nacos开源三年以来，打造了残缺的云原生技术生态，成为国内的事实标准，并且通过社区推动凋谢共建，通过阿里丰盛产品打磨产品性能和可用性，通过商业化打造产品极致体验，更平安的产品能力，满足企业用户的生产要求。从而全方位锻炼Nacos各个维度的能力，正循环继续加强产品竞争力！上面我从开源、自研、商业化三个维度进行更深刻的分享。 Nacos 生态&布局Nacos 生态Nacos简直反对所有支流语言，其中Java/Golang/Python曾经反对Nacos2.0长链接协定，能最大限度施展Nacos性能。阿里微服务 DNS（Dubbo+Nacos+Spring-cloud-alibaba/Seata/Sentinel）最佳实际，是Java微服务生态最佳解决方案；除此之外，Nacos也对微服务生态沉闷的技术做了无缝的反对，如目前比拟风行的Envoy、Dapr等，能让用户更加规范获取微服务能力。 Nacos 布局自从Nacos 2.0公布以来，凭借10倍性能晋升激发社区生机，进入国内开源我的项目活跃度Top10，并且成为行业首选。随着Nacos2.0的成熟，后续Nacos1.X将进入保护状态，Nacos 2.0.X将做1.X到2.X的适度，从2.1.0版本咱们将去掉适度降级逻辑，让Nacos2.0代码更加清新，性能更加卓越，并且减速插件化和服务网格生态的进化速度，冀望对此感兴趣小伙伴一起共建！！！ Nacos 阿里落地实际Nacos 阿里百万实例微服务架构因为阿里巴巴曾经倒退到百万实例级的超大集群，为了更高的性能和扩展性，咱们依照职能将Nacos切分成注册核心和配置核心两个集群；倡议超过10w实例规模公司从晚期做好拆分。小的时候部署到一起运维和部署代价是最小的。对立接入依照流量网关和微服务网关做了两层拆分，Tengine负责流量网关，次要抗连贯，证书卸载和弱七层流量管制；Envoy负责微服务网关局部，负责服务治理，协定转化，跨域互通等场景；倡议超过100w/s倡议做两层，不超过一层具备最佳性价比。阿里在国际化业务中将服务路由和异地多活切流能力下沉到Sidecar，并且大规模落地中，以便通过异地多活体系依照Region级别扩大集群。 目前为止，阿里云原生网关，注册核心和配置核心所有单元环境全副切到私有云产品MSE中，并且通过了99大促的验证，并且以此反对往年双十一。 Nacos 服务发现实际随着业务规模和业务域扩充，大公司根本都会遇到跨域互通的问题，阿里巴巴通过云原生网关买通多个业务域，如钉钉和其余团体业务域互通，通过MSE的云原生网关互通，通过Dubbo3.0的Triple协定互调，没有任何协定转化的耗费，效率高，rt低，还能够通过网关配置简略的路由切分逻辑晋升整体高可用。在阿里巴巴落地服务网格过程中Istio不能满足阿里规模要求，因而服务链路间接跟Nacos注册核心买通，路由规定通过Istio对接Nacos配置核心买通，以便可能大规模生产落地。 Nacos配置管理实际阿里可能喝着咖啡搞大促的一个底层技术就是动静配置管理+预案零碎（定时批改规定配置）。Nacos作为动静配置管理的根底撑持着整个双十一的外围业务。 如阿里巴巴混部疾速交付一个单元环境后，会动静推送单元化规定引流到新的混部环境，大促开始前会对日志采样率规定进行调整，避免过多日志对系统性能造成影响。 Nacos 解决方案微服务解决方案微服务引擎（Micro Service Engine，简称 MSE）是一个面向业界支流开源微服务生态的一站式微服务平台。 用户能够在注册&配置核心、服务框架、云原生网关、服务治理四个模块随便组合，能够抉择商业化产品，也能够抉择自建产品，如果全副抉择咱们解决方案，能够间接取得阿里十年积淀的外围竞争力。 服务网格解决方案阿里服务网格（简称 ASM）是一个对立治理微服务利用流量、兼容Istio的托管式平台。 Nacos用户可用通过 MSE + ASM 两个产品疾速组合间接进入服务网格时代。ASM 中Istio通过规范 MCP协定跟MSE 中 Nacos买通服务，MSE服务治理基于ASM流量治理原子API 做服务治理，咱们的云原生网关也是基于Envoy构建，这样就能够通过Istio规范的管制东西南北流量，进而晋升整个微服务高可用能力。 跨域互通解决方案个别大公司都会有跨业务域、网络域、平安域、跨云等场景服务互通的需要，MSE云原生网关买通多个业务域，简直所有用户都能用此形式解决，该模式通用，可管控，平安； 如果是一个网络域内，并且业务交加多，流量大，能够用Nacos-Sync组件做跨注册核心服务互通，跨域流量超过100w/s倡议再思考此种模式，该模式管控代价比拟大，只能在网络互通、协定统一场景应用。 当然还有很多用户采纳多注册和多订阅实现跨域互通，这样更无奈管控跨域互通，危险无奈辨认，并且对研发有代价。 微服务高可用解决方案随着数字化过程的演进，很多公司跟阿里巴巴一样会搞大促流动，这样峰值流量可能压垮整个零碎，导致微小经济损失，如果筹备过多资源会导致资源节约。这种场景下能够采纳阿里巴巴的PTS+MSE+AHAS+ARMS+ACK产品组合，边压、边限流、边看，边弹。通过PTS模仿用户流量做全链路压测，通过MSE中云原生网关做入口限流，并且通过Nacos发现后端服务转发，通过ARMS做服务可用性和服务治理观测，通过链路追踪剖析超时、异样等问题，容量不够通过ACK弹性，从而在性能、高可用、和资源利用率之间做最大均衡。 异地多活解决方案对于快递、政府、医疗、金融等国内民生的畛域，对业务可用性要求极高，须要具备异地多活的能力。阿里云MSHA提供同城多活和异地多活两种多活模式，底层采纳MSE为微服务根底。MSE在一个Region内提供同AZ拜访能力，具备同城容灾能力，单AZ故障，MSHA从入口将流量切到可用AZ疾速复原。 Region之间通过MSE云原生网关互通，解决服务部署不对等的跨域拜访问题，MSHA通过全局管制流量入口，一个区域不可用从入口开始切流复原业务。 本次直播回放地址：https://yqh.aliyun.com/live/detail/26356 ，也可扫描看钉钉群直播回放。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：5 款阿里罕用代码检测工具收费体验，仅需 2 步，Cherry键盘、公仔抱回家，100%拿奖！作者 | 喻阳 面临问题在日常研发过程中，咱们通常面临的代码资产问题次要分为两大类：代码品质问题和代码安全漏洞。 1、代码品质问题代码品质其实是一个陈词滥调的话题，但问题是大家都晓得它很重要，却又不晓得如何去晋升和保护这一团队的共同财产。一方面开发人员可能为了性能及时上线，忽略了对品质的把控，另一方面开发人员编码习惯和程序了解风格各异。 长期下来代码品质降落通常会自成因果，因为业务压力大而趋于降落，又因而开发效率降落，进一步加大业务压力，导致恶性循环。 2、代码平安问题安全类问题往往暗藏在不足安全意识的编码逻辑和未经检测或保护的开源依赖组件中，难以在日常开发和代码评审中被及时觉察。 代码平安问题也能够分两个方面进行剖析： 编码平安问题，即：平安标准类问题，通过防止不符合规范的代码进入企业代码库，缩小隐衷数据泄露、注入类危险、安全策略破绽的呈现。依赖平安问题，即：开源依赖三方组件引入的安全漏洞。依据 Synopsys 2020 开源平安报告显示，99%以上的组织应用了开源技术。应用开源组件自身带来的技术交换和站在伟人肩膀上合作、升高开发成本、放慢迭代周期、进步软件品质等劣势曾经不用赘述，然而，开源软件带来一系列便当的同时，也暗藏大量平安危险，据审计，75%的代码库存在安全漏洞，其中 49%蕴含高危问题，另外 82%的代码库仍在应用超过 4 年的 outdated 组件。代码安全类问题，一方面也须要进行准入性查看，依据业务场景和标准配置平安编码标准检测和卡点。另一方面须要定期维护，对于新暴发出的安全漏洞进行及时觉察并修复。 5 款阿里罕用代码监测工具举荐1、代码品质检测Java 代码规约检测阿里巴巴在实际过程中，各个组织因为历史隔膜和业务格调差别，工程构造差异很大，代码格调迥异，标准不一，沟通老本大，单干效率低，保护老本高。团体倒退到当初的规模，须要专业化的技术集团军迭代式、集约式倒退，而不是动辄反复造轮，而真正专业化的团队肯定会有对立的开发规约，这代表效率、共鸣、情怀、可继续。 基于上述背景，阿里制订了《阿里巴巴 Java 开发手册》，作为阿里外部 Java 工程师所遵循的开发标准，涵盖编程规约、单元测试规约、异样日志规约、MySQL 规约、工程规约、平安规约等。这是近万名阿里 Java 技术精英的经验总结，并经验了屡次大规模一线实战测验及欠缺。 制订交通法规外表上是要限度行车权，实际上是保障公众的人身安全。试想如果没有限速，没有红绿灯，没有靠右行驶条款，谁还敢上路。同理，对软件来说，开发规约绝不是毁灭代码内容的创造性、优雅性，而是限度适度个性化，推广绝对标准化，以一种广泛认可的形式一起做事。 因而，代码规约的指标是：1、码出高效：规范对立，晋升沟通效率和研发效力。2、码出品质：防患未然，晋升品质意识和零碎可维护性，升高故障率。3、码出情怀：工匠精力，谋求极致的卓越精力，打磨精品代码。 代码规约通过 IDE 检测插件、流水线集成测试、代码评审集成等工具伎俩，深度融入了阿里巴巴的各种开发流动中。与此同时，在云效代码托管平台 Codeup 中，也内置集成了 Java 代码规约检测能力，为开发人员在代码提交和代码评审阶段提供更为不便的疾速查看。 代码智能补丁举荐缺点检测和补丁举荐几十年来始终是软件工程畛域的难题，又是研究者和一线开发者最为关怀的问题之一，这里讲的缺点不是网络破绽、零碎缺点，而是暗藏在代码中的缺点。帮忙开发者辨认这些缺点，并进行修复，可能大幅晋升软件品质。 基于业界和学术界较为风行的缺点检测伎俩，并剖析和躲避其局限性，阿里巴巴 Codeup 的算法工程师们提出了一种新的算法，实现更加精准和高效的剖析代码缺点并举荐优化计划，该算法已被国内软件工程大会（ICSE）收录。 1、依据 commit message 中的关键词找出修复型的 commit，只取波及文件小于 5 个的 commit（波及文件过多的 commit 可能会浓缩修复行为）。这个步骤非常依赖开发者良好的 commit习惯，心愿开发者能用好 commit，写好 message。 2、从这些修复型 commit 中以文件级别提取删除内容和新增内容，即 Defect and Patch pairs(DP Pair)，这一步难免会有很大的噪声。 3、利用改良的 DBSCAN 办法对 buggy 和 patch 对同时聚类，将类似的缺点和补丁代码聚在一起。（也能够做片段级的聚类）通过将类似的缺点和修复做聚类，缩小了上一步留下的大量噪声，同时历史代码提交中大家独特犯过的错具备很强的借鉴意义。 ...

简介：阿里云自研的 Serverless 产品函数计算 FC 是事件驱动的全托管计算服务，完满符合了伊对 App 的需要和痛点。北京米连科技有限公司成立于 2015 年，是国家高新技术企业，旗下品牌伊对 App 上线于 2018 年，专一于挪动端交友和相亲，将视频、直播和线上红娘创造性地交融在一起，开拓了视频恋爱社区的独立赛道，为独身人群提供了全新的社交体验。截至 2020 年，伊对 App 注册用户已达 1 亿，每月撮合线上相亲流动约 1000 万场，成为视频恋爱社交垂直畛域最具影响力的品牌之一。 业务需要 随着伊对 App 业务的快速增长，外围利用的零碎规模和零碎复杂度也在经验着天翻地覆的变动。伊对 App 技术团队通过引进新的技术手段，保护整套零碎架构的技术先进性，以更好地反对业务需要，升高 IT 老本。从成立以来，伊对 App 的外围零碎架构实现了屡次重大的降级，波及微服务化、容器化、分布式数据库、大数据和人工智能等重要的技术，特地在 Serverless 技术的摸索方面，伊对 App 投入了很大精力，以充沛享受到云计算时代资源疾速弹性伸缩的价值。 在伊对 App 的业务场景外面，视频直播是最为重要的环节，基于视频直播这个骨架，能够融入线上红娘等多类翻新业务模式，这也对视频直播的内容平安提出了极高的要求。不论是本身通过 AI 技术对视频直播内容进行智能剖析，还是应答监管的要求，都须要在每一路视频直播流开始后，依据固定频率对视频进行截帧，并通过对立的审核服务对截帧生成的图片进行解决。 在这个需要外面，截帧服务承当着要害职责，这个服务不仅须要通过 FFmpeg 命令对每一路直播视频流进行截帧操作，还须要将生成的图片保留到对象存储 OSS，并将截帧信息写入到 Kafka。这样上游的截帧服务就能从 Kafka 上拉取截帧信息，并从截帧信息中失去图片在 OSS 中的地址，从而实现对于图片的审核。在这个架构中，引入 Kafka 是为了通过异步解决机制缓解审核服务在业务高峰期的负载。 业务痛点 FFmpeg 截帧命令应用非常简单，但这是一个对于 CPU 算力要求十分高的操作。依据伊对 App 技术团队的屡次试验，采纳 ECS 部署截帧服务，是一个绝对老本最优的抉择。如果依照每秒钟1次截帧的固定频繁，1 台 ECS 可能同时撑持大概数百路直播视频流的截帧工作。为了保障业务高峰期的资源储备，伊对 App 筹备了大量 ECS 来部署截帧服务。跟绝大多数互联网利用一样，伊对 App 的负载也存在着波峰波谷，这样的稳定对伊对 App 整体的资源布局带来了极高的挑战，如果依照固定的 ECS 集群规模来部署截帧服务，会存在两个非常明显的弊病： ...

简介：2021年9月26日，“数聚云端·智驭将来”——阿里云数据库翻新上云峰会暨第3届数据库性能挑战赛决赛颁奖典礼行将在京隆重召开。收费报名入口新一轮科技反动正在重塑寰球倒退格局，以云计算为代表的信息技术成为数字经济智能和翻新倒退新引擎。 云原生浪潮滚滚而来，数据库云化大势所趋。随同企业数字化转型减速，数据存储和价值开掘需要愈发强烈。新一代云原生数据库，正在继续赋能业务在线化，让无限数据开释有限价值，引领企业数智蝶变。 2021年9月26日，“数聚云端·智驭将来”——阿里云数据库翻新上云峰会暨第3届数据库性能挑战赛决赛颁奖典礼行将在京隆重召开。 本届峰会，咱们将与您一起深刻洞察新技术改革驱动下，云原生数据库的现状和将来发展趋势。现场凝聚产学研各界首领大咖、知名企业技术首领和开发者、资深行业媒体同仁等，共议云原生数据库2.0的倒退、时机与挑战和一站式数据管理的最佳实际，并首次重磅公布“企业级实时数据仓库”场景化解决方案。 云·驱动，数·跃迁 阿里云数据库翻新上云峰会 期待与您相约云端，与业界大咖共赴技术盛宴！ 报名形式点击下方链接，或扫描二维码，均可收费领票： https://www.huodongxing.com/event/7614700069900 更多峰会信息，详见下图 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：近日，数据可视化公司 Grafana Labs 与阿里云建设外围合作伙伴关系。单方将施展各自劣势，在可观测性产品、服务反对等方面开展全方位单干，独特打造 Grafana 托管服务，帮忙宽广企业疾速具备各类数据源即时查问与数据可视化的可观测性能力。此次单干，也是 Grafana 与亚太地区云厂商的首次深度单干，单方将在中国区提供首款 Grafana 托管服务。作者 | 白玙 近日，数据可视化公司 Grafana Labs 与阿里云建设外围合作伙伴关系。单方将施展各自劣势，在可观测性产品、服务反对等方面开展全方位单干，独特打造 Grafana 托管服务，帮忙宽广企业疾速具备各类数据源即时查问与数据可视化的可观测性能力。此次单干，也是 Grafana 与亚太地区云厂商的首次深度单干，单方将在中国区提供首款 Grafana 托管服务。 背景随着云原生技术一直落地，面向分布式应用和容器的数据可观测技术，笼罩从前端到后端、从基础设施层到应用层，成为企业必备运维能力。凭借其丰盛的可视化看板、多数据源接入等个性，Grafana 曾经成为云原生时代的可观测可视化事实标准。CNCF 公布的《 End User Technology Radar》报告显示，三分之二的受访者将 Grafana 与  Prometheus 作为首选可观测工具。 为了帮忙寰球云计算用户构建基于本身业务特色的可观测性体系，阿里云与 Grafana 携手打造 Grafana 托管服务，使用户高效剖析与查看指标、日志和跟踪的同时，无需关注服务器配置、软件更新等繁冗工作，无效升高运维复杂性与工作量，并借助阿里云弱小的云原生能力，全面晋升 Grafana 安全性与可用性。 Grafana 实验室联结创始人兼首席执行官 Raj Dutt 示意，“咱们在 Grafana Labs 的指标是确保 Grafana 可用，但这对咱们的用户来说是最有意义的——无论是自建设施，还是在阿里云这样的私有云平台。借助全托管服务形式与一直开展的深度单干，阿里云的海量寰球用户将取得远超自托管的便捷性与可用性，更高效、更低门槛地应用 Grafana 当先的开源看板和可观测性功能。更为单方关上一扇全新市场的大门。” 阿里云智能根底产品事业部总经理蒋江伟示意，“阿里云可观测产品始终致力于为企业数字翻新保驾护航，单方此次单干将为寰球用户带来更加优质、贴合业务场景的产品体验，为客户提供残缺的可观测性计划，赋能企业数字化转型。与 Grafana 此次的单干，不仅仅是为了给客户发明更多价值，更是与开源厂商的强强联合，推动开源生态进一步茁壮成长。” 阿里云云原生利用平台负责人丁宇示意，“Grafana 作为目前开源看板与可视化的事实标准，被咱们泛滥用户所认可与应用。始终以客户为核心的阿里云，心愿借助此次与 Grafana Labs 团队的深度单干，寰球用户可能更便捷、更高效应用他们所认可的技术，并将更多精力聚焦在业务倒退中，无需再关注根底运维工作。阿里云在开源畛域进行踊跃奉献的同时，也将继续与更多开源厂商开展单干，继续推动云原生与开源在中 国的实际落地。” 据悉，将来单方将一直扩大单干范畴和深度，为企业提供更加丰盛的基于阿里云的优良可观测性解决方案，解决企业在数字经济时代的运维难题。 对于 Grafana LabsGrafana Labs 围绕 Grafana提供了一个凋谢的、可组合的监控和可观测性堆栈，Grafana 是用于仪表板和可视化的当先开源技术。Grafana Labs 的客户超过 1500 家，包含彭博社、摩根大通、易趣、贝宝和索尼，寰球有超过 750000 台 Grafana 的流动装置。Grafana Labs 通过全栈产品帮忙公司治理其可观测性策略，这些产品能够通过 Grafana Cloud 齐全治理，也能够通过 Grafana Enterprise stack 自我管理，两者都具备宽泛的企业数据源插件、仪表板治理、警报、报告和安全性、可扩大指标（Prometheus&Graphite），日志（Grafana Loki）和跟踪（Grafana Tempo）。Grafana 实验室失去当先投资者 Lightspeed Venture Partners、Lead Edge Capital、GIC、红杉资本和 Coatue 的反对。 ...

简介：以你之意，冠它之名~大家常常埋怨阿里云 Cloud AIoT Native名字太难记了，当初请你给它起个名字！以你之意 冠它之名 事件是这样的 往年3月阿里云 Cloud AIoT Native推出以来，迅速火遍IoT圈，这是一个云端一体的能力体系，集成云平台、AI、操作系统等能力，帮忙开发者高效便捷进行智能硬件开发，其中Haas 600、IoT studio3.0等都是网红产品了。 然而大家常常埋怨阿里云 Cloud AIoT Native名字太难记了 当初咱们就请有创意的你，给它起个名字有奖！ 要求 1、中文名称，5个汉字以内，简洁、易记，防止应用生僻、歧义字。 2、提交的命名应有外延和内涵诠释，外延要体现命名的深义，内涵要具备流传个性。 3、提交的命名不得含有不衰弱信息，不得剽窃别人品牌，不得进犯别人非法的知识产权，具唯一性，为确保唯一性，您批准对命名严格窃密。4、每人投稿命名仅限1个，须要拟定命名含意。如提交的命名呈现反复，履行“先提先得”准则。 5、您通晓并批准，您提交的命名如果获奖（无论何种奖项），该“名称”相干的全副知识产权将归阿里云所有，您承诺不会应用提交的命名进行知识产权相干申请。阿里云有权对获奖的命名进行批改，且不承诺获奖提名肯定会成为最终产品名称。 日程安排 2021年9月8日-2021年9月20日：扫二维码进行名称提交 2021年9月27日：通过阿里云AIoT官网微信公众号、微博最终后果颁布 奖项设置 冠名奖：1名 奖品：苹果无线耳机（AirPodsPro）1个 倾情参加奖：5名  奖品：天猫精灵方糖R 只有你有创意，  就能以你之意，冠它之名 长按辨认下图二维码，即可参加征名流动 相干材料 更多阿里云 Cloud AIoT Native信息，请点击下方链接理解↓ ↓ ↓ https://developer.aliyun.com/topic/ydyt 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：作者于雨负责了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中作者同时作为听众从这些同行的演讲中学到了很多十分有用的常识。本文算是对 2021 GIAC 云原生专场的侧记，管中窥豹，以观 2021 年云原生技术倒退现状及将来一段时间内的趋势。作者 | 于雨 自己有幸负责了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中集体同时作为听众从这些同行的演讲中学到了很多十分有用的常识。本文算是对 2021 GIAC 云原生专场的侧记，管中窥豹，以观 2021 年云原生技术倒退现状及将来一段时间内的趋势。 云原生这个词含意宽泛，波及到资源的高效利用、交付、部署及运维等方方面面。 从零碎层次分能够辨别出云原生根底设置【如存储、网络、治理平台 K8s】、云原生中间件、云原生利用架构以及云原生交付运维体系，本次专场的四个议题也根本涵盖了这四大方向： 亚马逊的资深技术专家黄帅的《一个云原生服务的爆炸半径治理》快手基础架构核心服务网格负责人姜涛的《快手中间件 Mesh 化实际》Tetrate 可观测性工程师柯振旭的《应用 SkyWalking 监控 Kubernetes 事件》自己以 Dubbogo 社区负责人出品的《Dubbogo 3.0：Dubbo 在云原生时代的基石》上面依据集体现场笔记以及集体回顾别离记述各个议题的要点。因工夫以及自己能力无限，一些谬误不免，还请里手多多斧正。 云原生服务的爆炸半径集体了解，黄的这个议题属于云原生利用架构领域。 其演讲内容首先从亚马逊 AWS 十年前的一个故障说开：AWS 某服务的配置核心是一个 CP 零碎，一次人为的网络变更导致配置核心的冗余备份节点被打垮，当运维人员紧急复原变更后，因为配置核心不可用【无效正本数少于一半】导致了整个存储系统其余数据节点认为配置数据一致性不正确拒绝服务，最终导致整个零碎服务解体。 复盘整个事变的间接起因是：CAP 定理对可用性和一致性的定义限定十分严格，并不适宜利用于理论的生产零碎。因而作为线上管制面的配置核心的数据应该在保障最终一致性的前提下，首先保障可用性。 更进一步，古代分布式系统的人为操作谬误、网络异样、软件 Bug、网络/存储/计算资源耗尽等都是不可避免的，分布式时代的设计人员个别都是通过各种冗余【如多存储分区、多服务正本】伎俩保证系统的可靠性，在不牢靠的软硬件体系之上构建牢靠的服务。 然而这两头有一个误区：有时候一些冗余伎俩可能因为雪崩效应反而会导致系统的可靠性升高。 如下面的事变，人为的配置谬误导致了一连串的软件体系故障，且这些故障之间是高度强相干的，最终导致了雪崩效应，能够称之为“程度扩大的毒药效应”。此时思考的维度就从“在不牢靠软硬件体系上提供牢靠服务”进一步拓展为“通过各种隔离伎俩减小事变的爆炸半径”：当不可避免的故障产生时，尽量把故障损失管制到最小，保障在可承受范畴内，保障服务可用。 针对这个思路，黄给出了如下故障隔离伎俩： 服务粒度适中微服务的服务粒度并不是拆分的越细越好。如果服务粒度过细，会导致服务数量过多，其第一个结果就是导致一个组织内简直无人能搞清楚服务整体逻辑的前因后果，减少保护人员的累赘：大家只敢小修小补无人敢做出大幅度的优化改良。服务粒度过细的第二个结果是造成整体微服务单元体指数级减少，造成容器编排部署成本上升。适中的服务粒度要兼顾架构体系的进化与部署老本的升高。充沛隔离进行服务编排时，获取数据核心的电源和网络拓扑信息，保障强相干零碎之间部署做到“不远”且“不近”。“不近”是指同一个服务的正本不在应用同一个电源的同一个机柜部署，也不在应用了同一个网络立体的 Azone 内部署。“不远”是指部署间隔不能太远，例如多正本能够同城多 IDC 部署。应用这两个准则兼顾性能与系统可靠性。随机分区所谓的随机分区这块，其实质就是在混合服务申请，保障某个服务的申请能够走多通道【队列】，保障在某些通道挂掉的状况下不影响某个服务的申请解决，利用随机分区技术，将用户打散在多个 Cell 中，大幅度降低爆炸半径。与 K8s APF 偏心限流算法中的洗牌分片（Shuffle Sharding）颇为类似。混沌工程通过继续内化的混沌工程实际，提前踩雷，尽量减少“故障点”，晋升系统可靠性。应用 SkyWalking 监控 Kubernetes 事件这个议题尽管被安顿在第三场演讲，属于云原生交付运维体系，然而与上个议题关联性比拟强，所以先在此记述。 如何晋升 K8s 零碎的可观测性，始终是各大云平台的核心技术难题。K8s 零碎可观测性的根底数据是 K8s event，这些事件蕴含了 Pod 等资源从申请到调度以及资源分配的全链路信息。 ...

简介：“秒懂边缘云”第二期来了，9月15日下午4点不见不散！9月8号，阿里云边缘云高级产品专家鸠舍老师率领大家揭开边缘云的神秘面纱，通过简略易懂的形式理解边缘云的发展趋势，相熟边缘云的状态和个性，把握边缘云的产品及技术架构，并通过场景化带入形式领会边缘云的生态价值。 很多小伙伴留言看完有点意犹未尽，于是，“秒懂边缘云”第二期来了，周三下午4点不见不散！ 再谈边缘云！ 以阿里云边缘云产品为例子，揭秘边缘云产品的构建能力。 这次分享嘉宾是阿里云边缘云团队高级技术专家治先， 治先是OpenResty 社区委员会成员，高性能 OpenResty 开发框架 Vanilla 作者，WeiboMesh 初创核心成员，推动实现微博外围服务 Mesh 化革新，开源爱好者，目前次要负责阿里云边缘交融计算平台的设计研发，致力于 5G 边缘计算基础设施的设计建设与行业落地。 分享背景： 通过 CDN十年磨一剑的积淀和边缘计算在 IaaS 虚拟化方向的深刻摸索，阿里云积攒了包含全域智能调度、拓扑感知、异样感知、秒级逃逸、交融计算、多点协同、分布式管控、自动化拆卸维稳等核心技术；内容与算力散发、边缘计算两大产品体系；寰球超大规模的边缘云节点资源以及撑持百万节点千万机器的全面云化的弱小技术基座。在技术、产品、资源层的深厚积攒和积淀将阿里云边缘云推向了由 CDN 和 ENS 双轮驱动，边缘设施全面云化的高速倒退阶段。这个过程中产品技术架构是如何演进的呢？本期分享将为您具体解读。 扫描下方二维码或者点击浏览原文即可预约报名！还可观看上一期回放！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： 在放弃对业界趋势调度关注的同时，始终选用最适宜本身的技术，这可能是中瑞能在车联网畛域引领行业的重要起因之一，正如中瑞CTO所说“阿里云云原生产品体系带给咱们的，不是单纯的IT工具，而是整个团队战斗力的晋升”。作者 | 山猎 中瑞团体成立于2011年，是一家青岛外乡的物联网独角兽企业。中瑞团体致力于利用物联网和人工智能技术，交融智慧交通、智慧城管、智慧出行、智慧物流、智慧风控、智慧审计、智慧车险、智慧校园、智慧批发等业务场景，为数万家政府和企业客户提供资产数字化治理解决方案。自2015年以来，团体业务营收年均复合增长率超过100%，2019年营收超过20亿人民币。中瑞团体累计服务7000余家汽车经销商、200余家金融机构、20多家出名出行机构。2020年10月平台累计在线车联网终端设备超过678万台，是全国车联网在线终端规模No.1的利用平台。 商用车辆数字化治理是中瑞团体的外围业务之一，在这个畛域，中瑞团体已联动包含整车厂、银行、汽车金融机构、保险公司、根底技术提供方等十数家机构，造成以传感器、人工智能算法、数据管理平台为外围的整体解决方案，为客户提供高度定制个性化服务，同时辅以汽车金融、保险、规范制订、平台经营等衍生性能板块，业务能力涵盖数字化治理我的项目设计、建设和经营的各个阶段。 商用车辆数字化治理，通过车联网技术连贯大量终端配备，实时收集并解决海量数据。智能车载传感设施会依据不同行业属性，如物流、出行、工程作业、农业作业等，产生人、车、货、设施等数据。中瑞团体基于对车联网行业实际的深度积攒，将物联网与挪动互联网技术相结合，依附云计算、大数据等技术的反对，自主研发中瑞车联云平台。通过对在线经营车辆数据的收集、解决和剖析，反馈到整车厂研发、设计、洽购、生产、销售及售后各个环节，无效改善了整车设计程度，晋升了零部件品质，优化了销售策略，进步了售后实时性及准确度。 车联网智能设施实时上报的数据，会同步流转到多个业务零碎进行解决，其中包含中瑞自建的在线业务平台、离线剖析平台和实时计算平台，还有一部分数据会通过API的形式进行透出，提供给配备所属机构和政府监管部门应用。中瑞团体依据政府监管政策要求，承建智慧城市出行平台，通过部署车载联网终端设备，会集合乎当地监管要求和技术标准的车辆作业数据，上传归集至当地政府数据中心，同时建设遵循国家标准的凋谢数据接口，提供给各部委调用。 对于中瑞的技术团队而言，每一条通过车联网上报的数据都是十分宝贵的，其背地蕴藏着微小的业务价值。因而，在进行零碎架构设计的时候，须要思考到如下几个重要的业务诉求： 1、 对于上报的数据，通过一个两头模块进行音讯散发，交给不同的零碎进行解决，缩小音讯复制的老本。 2、 当上游业务模块的音讯处理速度比拟快的时候，要确保音讯流转的低时延。这个需要对于大多数在线业务场景都是十分重要的，比方当车联网用户发动一个新的指令的时候，云端须要尽可能快的对指令进行解决，并及时给予回复。 3、 当上游业务模块的音讯处理速度跟不上数据上报速度的时候，须要音讯能尽可能多的在两头模块进行暂存，并在单方速度拉平的时候，让之前暂存的音讯可能失去正确的解决。这是一种典型的异步化通信思路，在绝大多数的离线剖析场景，以及局部在线业务场景中被宽泛的应用，可能显著晋升零碎整体的稳定性和吞吐量。 通过引入音讯队列，可能比较顺利的实现这几大业务诉求，音讯散发、暂存的工作都能够交给音讯队列来实现，不须要在具体的业务模块中自行实现。 在整个零碎架构中，所有音讯的流转都须要通过音讯队列来实现。在业务高峰期，会有超过100万台车联网设施同时在线，每秒的产生的音讯数量，也会达到百万级别，因而音讯队列的稳定性以及吞吐能力至关重要。在音讯队列的选型上，中瑞的技术团队针对业界支流的产品进行了深刻摸索。 在音讯队列产品选型过程中，咱们排除了是无奈通过程度扩大的形式线性晋升整体性能的音讯队列产品。这类产品以ActiveMQ和RabbitMQ为代表，尽管在业界失去了宽泛应用，但无奈撑持来自于海量设施的大吞吐量需要。最实质的起因是这类产品并不是依照原生的分布式理念进行设计，当性能无奈满足业务需要的时候，只有通过垂直晋升硬件性能的形式实现，降级过程中对业务有感知，而且性能晋升的水平无限，不具备可操作性。 Kafka是一个比拟好的抉择，其原生的分布式设计理念能确保性能能够通过程度扩容而实现线性的晋升。中瑞的技术团队对Kafka进行了大量技术预研，心愿可能通过Kafka的程度扩大能力撑持起中瑞的高并发业务场景。但随着钻研的深刻，中瑞的技术团队发现Kafka也存在肯定的局限性。对于流转到在线业务模块以及第三方合作伙伴的音讯，须要确保音讯的可达性，也就是说不论零碎的哪个环节呈现了异常情况，都应该确保重要的音讯不失落。这一点Kafka没有方法在协定层提供保障，并在测试过程中也失去了验证：过后Kafka与在线业务模块之间的网络呈现了短暂抖动，这原本应该是一个很常见的异常情况，零碎能够比拟快的工夫内复原运行。但理论应用过程中，这次网络抖动造成了一批音讯的永久性失落，这在一些金融风险管制相干的要害业务场景中是不能被承受的。 在测试的过程中，中瑞还发现往Kafka集群退出新的节点的时候，会造成集群的性能呈现抖动状况，通常会继续1小时以上。这个过程中尽管集群层面能确保高可用，但对于业务仍然会造成肯定的影响，这是由Kafka底层的ISR机制的实现原理导致的，整个技术界都没有太好的优化方向。 通过深刻的评估，中瑞最终决定采纳RocketMQ来建设音讯队列集群。RocketMQ是阿里巴巴在历年双11业务的积淀下，构建的低提早、高并发、高可用、高牢靠的分布式消息中间件。最后RocketMQ的诞生，也参考了Kafka的分布式模型，但在Kafka的根底上围绕在线交易类业务场景进行了多项优化。对于中瑞来说，RocketMQ建设在协定层的音讯必达性保障能够避免重要的数据在流转的过程中失落，这种必达性保障通过了各种刻薄场景的验证，齐全能够应用在金融相干业务中。对于每一个发往RocketMQ的音讯，只有发送方收到了来自于RocketMQ的回执，就能确保这条音讯肯定会被对应的生产方接管并正确的解决。 早在2012年，RocketMQ就被募捐给了开源组织，并在随后成为Apache的顶级我的项目，因而RocketMQ在整个业界具备十分高的影响力，对于RocketMQ的实现原理、优化计划，都能在技术论坛找到大量的材料。但在到底应用开源RocketMQ进行自建，还是应用云上商业版RocketMQ的问题上，中瑞的技术团队倒是很快达成了统一：对于一只以业务倒退为第一导向的技术团队而言，云上商业版在老本和效率上体现进去的劣势是不言而喻的。 RocketMQ人造具备高可用性，不论是Name Server集群还是Broker集群，当有节点宕机的时候，整个集群仍然能够对外提供服务，不会对业务造成影响。但在这种状况下，RocketMQ集群处于一种比拟软弱的状态，须要使用者想方法进行系统性的补救，以确保在下一次呈现节点宕机的时候，RocketMQ集群仍然可能稳固得运行。比方当一个Master Broker节点呈现故障后，尽管Slave Broker节点仍然能够承当音讯收发的工作，而且RocketMQ的音讯同步机制确保了这个过程中的音讯不失落，但使用者须要尽快将Slave节点降级为Master节点，并引入新的Slave节点。否则当原有的Slave节点再次遇到故障的时候，整个集群将进行工作，这会对业务造成十分重大的影响。在开源RocketMQ的实现中，并没有提供欠缺的机制来实现主从Broker的互相切换，须要使用者自行实现计划，危险十分大。在前期的版本中，尽管提供了Dledger多正本机制实现主从切换，但操作难度很大，切换的过程中也并不能保障平滑过渡，会使业务造成肯定的抖动。 RocketMQ集群的扩容也是一项十分有挑战性的工作，在引入新节点的过程中，须要投入大量运维工作量，扩容所须要的工夫也比拟长。每一步的操作都必须小心谨慎，一旦呈现操作失误，就会导致整个集群不可用。在中瑞的业务场景中，因用户流量的突增而引发零碎紧急扩容的需要比拟频繁。音讯队列是整个零碎的外围，必须保障每一次扩容都能够在保障业务不中断的前提下疾速实现。 阿里云版本的RocketMQ完满的解决了高可用和弹性伸缩这两个方面的挑战。这样的能力来自于阿里巴巴本身业务场景的积淀和历练，也就是每年双11流动的极其考验。随着阿里云的飞速发展，RocketMQ成为了阿里云音讯队列产品家族的最重要组成部分。云上的商业版RocketMQ残缺保留了在阿里团体本身业务场景中积淀的高吞吐量、沉积能力、高可用性、高安全性、低提早性，并针对云上的使用者在易用性方面进行了大量加强。中瑞的技术团队在零碎架构中全面应用阿里云版RocketMQ作为音讯队列后，对集群进行了屡次程度扩容，以满足更大用户量更高并发的需要。在业务值峰期间，数百万台车联网设施同时在线，给零碎带来了微小的压力，但阿里云版RocketMQ作为音讯流转的外围组件，始终保持稳定进行，至今为止0故障。 当一支技术团队的工作内容从简单的底层技术细节中解放出来后，他们就有了更多的精力来实现业务畛域的翻新。这也是云计算以及云原生理念为宽广企业带来的微小价值，随着业务的飞速发展，中瑞的技术团队还会持续围绕云原生技术，摸索更多节俭IT老本、晋升业务效率的新方向。以后，中瑞正在将现有的微服务利用进行容器化革新，并全面接入阿里云实时利用监控ARMS，以实现全栈式的性能监控和端到端的全链路追踪诊断。此外，他们还踊跃尝试通过函数计算FC的形式对局部业务零碎进行Serverless化革新，从而全面的升高计算资源老本，更充沛的利用云计算的弹性能力。 在放弃对业界趋势调度关注的同时，始终选用最适宜本身的技术，这可能是中瑞能在车联网畛域引领行业的重要起因之一，正如中瑞CTO杨少杰所说：“阿里云云原生产品体系带给咱们的，不是单纯的IT工具，而是整个团队战斗力的晋升”。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：在所有皆可视频化的明天，短视频内容作为挪动端产品新的促活点，受到了越来越多的器重与投入，同时短视频也是减少用户粘性、减少用户停留时长的一把利器。那么如何疾速实现挪动端短视频性能呢？前两篇咱们介绍了盒马短视频秒播优化（iOS 篇 / Android 篇），本篇咱们聊聊秒播之外，另一个从体感上减少短视频用户体验的能力 - 续播。作者｜少阳 审校｜泰一 短视频作为内容重要的承载形式，是吸引用户的重点，短视频的内容与体验间接关系到用户是否违心长时停留。因而，体验的优化就显得尤为重要。 跨页面续播跨页面续播是除秒播外另一个能够从体感上减少用户体验的能力。因为一些业务场景须要在不同页面上播放同一个视频内容的场景，而这些场景页面切换往往是间断的，这就要求短视频的播放也是间断。这样能力使得体验上会有连贯性，让用户在进入沉迷式页面时，能流畅的适度，并无感知的持续播放，从而产生间断不间断的感触。 在优化前，盒马沉迷式短视频播放页面的体验与支流短视频 App 有显著差距。从卡片列表页面跳转视频沉迷式页面时，雷同视频无奈续播，影响用户参观和体验。上面次要介绍盒马短视频从一般展现页进入沉迷式页面时跨页面续播能力和晦涩的动画切换成果的实现过程。 环境 手机：Pixel 4os：Android 10播放器：淘宝播放器成果比照 首先咱们来看一下盒马优化前后与支流短视频 App 的成果比照 **问题剖析 ** 从比照能够看出，续播的关键在于视频流的复用以及页面转场动画。 ◆ 视频流的复用 要解决流的复用，同时又要保障进入新的页面时能够立刻播放，不产生声音和画面的顿挫，这里依据上一篇《揭秘盒马鲜生 APP Android 短视频秒播优化计划》的剖析，必须要解决视频下载，加载解码的耗时。 依据《揭秘盒马鲜生 APP Android 短视频秒播优化计划》里讲到缓存原理，这里能够利用播放器播放同一个视频（留神对立 URL，盒马全副转为 H.265）来防止屡次下载。加载解码的耗时则须要播放器复用来解决。这里波及到实现计划，可参照下一章的续播计划选型。◆ 转场动画 转场动画能显著进步体感晦涩度，但实现过程中须要思考各种兼容问题。 续播计划选型在优化后期，咱们思考了三种续播计划。 1. 播放器 View 跨页面传递长处：思路简略，体验成果好。毛病：业务侵入重大，不具通用性，播放器业务回调无奈隔离，不利于续播放器管控。 2. 基于 Surface (View) 级别的全局播放器治理长处：体验成果好，能扩大内存管控，侵入性低。毛病：实现简单，须要改写底层 HMVideoView 的封装逻辑；革新中易呈现内存透露，较难排查。 3. 基于 MediaPlayer 级别的全局播放器治理长处：无侵入，能扩大内存管控，实现快（可复用和扩大淘宝播放器底层 token 机制）毛病：须要肯定的革新，体验比计划 1、2 略差（声音有一瞬间的顿挫，不显著） 盒马最终抉择计划 3，这里计划 2 和 3 原理是雷同的，没有显著的优劣之分，最终抉择计划 3 是因为这是目前稳定性最高，老本最低的办法。后续的播放器续播、复用、治理的剖析同样实用于计划 2。 播放器续播、复用和治理 业务上，咱们须要实现续播，通过问题剖析，咱们曾经晓得，通过视频流的复用即可实现，而视频流的复用这里抉择通过复用 MediaPlayer 实现（也能够复用 Surface+MediaPlayer）。 ...

简介：阿里云开源的云原生利用自动化治理套件、CNCF Sandbox 我的项目 -- OpenKruise，明天公布 v0.10.0 新版本，这也会是 OpenKruise v1.0 之前的最初一个 minor 版本。 本文将带你一览 v0.10.0 的新变动，其中新增的 WorkloadSpread、PodUnavailableBudget 等大颗粒个性后续还将有转文具体介绍其设计实现原理。作者 | 酒祝 **背景** 阿里云开源的云原生利用自动化治理套件、CNCF Sandbox 我的项目 -- OpenKruise，明天公布 v0.10.0 新版本，这也会是 OpenKruise v1.0 之前的最初一个 minor 版本。 本文将带你一览 v0.10.0 的新变动，其中新增的 WorkloadSpread、PodUnavailableBudget 等大颗粒个性后续还将有转文具体介绍其设计实现原理。 新性能概览1.  WorkloadSpread：旁路的利用弹性拓扑治理能力在利用部署运维的场景下，有着多种多样的拓扑打散以及弹性的诉求。其中最常见、最根本的，就是按某种或几种拓扑程度打散，比方： 利用部署须要按 node 维度打散，防止重叠（进步容灾能力）利用部署须要按 AZ（available zone）维度打散（进步容灾能力）这些根本的诉求，通过 Kubernetes 原生提供的 pod affinity、topology spread constraints 等能力目前都可能满足了。但在理论的生产场景下，还有着太多更加简单的分区与弹性需要，以下举一些理论的例子： 按 zone 打散时，须要指定在不同 zone 中部署的比例数，比方某个利用在 zone a、b、c 中部署的 Pod 数量比例为 1 : 1 : 2 等（因为一些事实的起因比方该利用在多个 zone 中的流量不平衡等）存在多个 zone 或不同机型的拓扑，利用扩容时，优先部署到某个 zone 或机型上，当资源有余时再部署到另一个 zone 或机型上（往后以此类推）；利用缩容时，要按反向程序，优先缩容前面 zone 或机型上的 Pod（往前以此类推）存在多个根底的节点池和弹性的节点池，利用部署时须要固定数量或比例的 Pod 部署在根底节点池，其余的都扩到弹性节点池对于这些例子，过来个别只能将一个利用拆分为多个 Workload（比方 Deployment）来部署，能力解决利用在不同拓扑下采纳不同比例数量、扩缩容优先级、资源感知、弹性抉择等场景的根本问题，但还是须要 PaaS 层深度定制化，来反对对一个利用多个 Workload 的精细化治理。 ...

简介：人不知;鬼不觉中，2021 年最初一个季度悄悄邻近。对各大热门畛域技术一年的总结、将来的判断及工具的盘点类内容也将不出意外再次成为业界关注的焦点。而近期，海内出名技术媒体 ITNEXT 公布了一年一度的云原生技术排行榜《Kubernetes Essential Tools: 2021》的内容。其中，来自阿里云的 KubeVela 我的项目榜上有名，成为这份“2021 Kubernetes 必备工具”清单中，惟一一个由中国开发者主导的开源我的项目。作者 | KubeVela社区 背景人不知;鬼不觉中，2021 年最初一个季度悄悄邻近。对各大热门畛域技术一年的总结、将来的判断及工具的盘点类内容也将不出意外再次成为业界关注的焦点。而近期，海内出名技术媒体 ITNEXT 公布了一年一度的云原生技术排行榜《Kubernetes Essential Tools: 2021》的内容。其中，来自阿里云的 KubeVela 我的项目榜上有名，成为这份“2021 Kubernetes 必备工具”清单中，惟一一个由中国开发者主导的开源我的项目。 这个我的项目将扭转咱们应用 Kubernetes 的形式 在本次榜单中，作者用相当一部分篇幅对 KubeVela 进行了介绍，他提到： “以后 Kubernetes 的一个问题是开发人员须要十分理解基础设施和集群的细节。许多人都在探讨 K8s 的形象级别太低的问题，这会给只想专一于编写和交付应用程序的开发人员带来很多困扰。而开放式利用模型（OAM）就是为解决这个问题而创立的。它的核心思想是以一种独立于底层基础设施的形式，围绕应用程序来创立更高级别的形象。浏览标准：https://github.com/oam-dev/spec 正是因为专一于应用程序而不是容器或编排，凋谢利用模型 （OAM）为利用开发人员带来了模块化、可扩大和可移植的设计，使他们可能用更高级别但统一的 API 对利用交付与治理进行建模。” KubeVela 作为 OAM 模型的规范实现，不仅与底层基础设施和无关、原生可扩大，而最重要的是它是齐全以利用为核心的。在 KubeVela 中，“利用”被设计为整个平台的「一等公民」。利用团队只须要围绕组件、运维特色、工作流等几个跨平台、跨环境的下层形象来进行利用的交付与治理，而无需关注任何基础设施细节和差异性；平台管理员则能够随时以 IaC 的形式配置平台反对的组件类型和运维能力集等个性，以便适配任何利用托管场景。 利用团队：抉择一个指标环境，依据须要应用组件和特色来形容应用程序，而后将其交付到指标环境平台团队：对平台反对的性能作为进行模块化、模板化的治理和建模最初，ITNEXT 总结道：“KubeVela 这个我的项目，将在不久的未来扭转咱们应用 Kubernetes 的形式，最终使得开发人员无需成为 Kubernetes 专家即可享受到云原生带来的高效与便捷。当然，OAM 模型在事实世界中的可能会遇到新的挑战，比方某些零碎级的程序就可能跟底层基础设施细节耦合的很紧，诸如此类的问题有待进一步在 KubeVela 中解决。” 定义下一代云原生利用治理平台KubeVela 我的项目自公布后始终受到社区的宽泛关注，开源当天就登上了 GitHub 趋势榜 Go 语言区榜首的地位；2020 年年底被出名科技媒体 TheNewStack 评比为“Top Cloud Native Technology Trends from 2020”；也是 InfoQ 国内站《软件架构与设计趋势报告》中惟一一个来自中国的开源我的项目；2021 年 5 月，中国信息通信研究院联结 10 余家机构独特公布了以 OAM 为实现根底“云计算凋谢利用架构规范”。现在，在 KubeVela 社区中曾经沉闷着超过 100 名贡献者，被超过 20 家国内外当先企业在生产环境中应用，Oracle Cloud 还正式公布了基于 OAM 的企业级混合云利用平台产品。 ...

简介：编者按：近几年国产数据库市场风生水起，涌现了多款优良的国产数据库产品，本文选取了三款典型的国产分布式数据库进行全方位比照压测，出现了国产分布式数据库的倒退现状。对于所有的利用零碎，数据都是承载业务逻辑的外围资产，而存储数据的数据库系统则是最外围的零碎之一。随着国产化过程的一直推动，利用零碎基于国产化数据库进行构建越来越重要，也越来越成为数据库选型中的支流。 近几年国产数据库市场风生水起，涌现了多款优良的国产数据库产品，各大厂商也在重金投入数据库研发中。本文选取了三款典型的国产分布式数据库进行全方位比照压测，剖析国产分布式数据库的倒退现状，供各位读者参考。 测试环境及数据库架构PolarDB-X环境参数PolarDB-X版本polarx-kernel_5.4.11-16270254_xcluster-20210719节点规格16核64GB节点个数5个 (CN 16核64GB + DN 16核64G)数据库架构：### Oceanbase数据库架构：### TiDB数据库架构：## 压测指标剖析### Sysbench压测状况：#### 1. 压测参数配置参数值--rand-typeuniform--table-size1000,0000--table-num16--db-ps-modedisable--auto-incfalse--range-size5--skip-trxoff`测试表构造：CREATE TABLE sbtest1 ( id int(11) NOT NULL, k int(11) NOT NULL DEFAULT '0', c char(120) NOT NULL DEFAULT '', pad char(60) NOT NULL DEFAULT'', PRIMARY KEY (id), KEY k_1 (k)) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4`#### 2. 场景阐明 * 总计16 张表，每张表 1000 万行数据，数据分布uniform。* tidb场景：基于range程度拆分模式的分布式(tidb默认会把所有表的数据依照range做主动平衡，某一张测试表的数据会均匀分布到多个机器上)。 * OB模式：单表即官网默认举荐模式，sysbench脚本不作批改时主动建设的表，这里简称非分区表；基于hash程度拆分模式的分布式，简称分区表。 * PolarDB-X场景：单表，sysbench脚本不作批改时主动建设的表，这里简称非分区表；基于hash程度拆分模式的分布式，简称分区表，索引采纳本地索引；基于hash程度拆分模式的分布式，简称分区表，索引采纳GSI全局索引。 #### 3. 测试后果数据### TPCC (5000仓) TPCC是专门针对联机交易解决零碎（OLTP零碎）的测试标准，个别状况下咱们也把这类零碎称为在线业务解决零碎。1992年7月公布，简直所有在OLTP市场提供软硬平台的国外支流厂商都公布了相应的TPC-C测试后果，随着计算机技术的一直倒退，这些测试后果也在一直刷新。 TPCC通常用于模仿测试简单的在线事务处理零碎，在大压力状况测试数据库的事务处理能力，以下压测汇总了三种分布式数据库的最大tpmC指标： `// 数据导入 5000仓tiup bench tpcc --warehouses 5000 -D tpcc -H xxx -P xxx -T threads_num prepare// 运行tiup bench tpcc run -U root --db tpcc2 --host xxx --port xxx --time xxx --warehouses 5000 --threads` ###  TPCH (100G)TPCH（商业智能计算测试）是美国交易解决效力委员会(TPC,TransactionProcessing Performance Council) 组织制订的用来模仿决策反对类利用的一个测试集。目前，在学术界和工业界广泛采纳它来评估决策反对技术方面利用的性能。 这种商业测试能够全方位评测零碎的整体商业计算综合能力，对厂商的要求更高，同时也具备广泛的商业实用意义，目前在银行信贷剖析和信用卡剖析、电信经营剖析、税收剖析、烟草行业决策分析中都有宽泛的利用,以下以TPCH-100G来比照剖析三种分布式数据库的剖析能力： `// 导入数据 100Gtiup bench tpch prepare --host xxx --port xxx --db tpch_100 --sf 100 --analyze --threads xxx// runtiup bench tpch run --host xxx --port xxx --db tpch_100 --sf 100 --check=true` ### DDL 能力 #### 1. 场景阐明测试数据为tpch100g 生成的lineitem表，单表6亿行数据#### 2. 并行DDL测试并行DDL用于测试在达标的DDL过冲中，在前一个DDL未实现时，在同一张lineitem表上面加列、雷同库下创立一张表、给小表（如nation表）建设索引，察看第二步是否可能立刻返回，若能立刻返回，则表明反对并行DDL。### 热点行更新 对于无限的数据库资源，如果有大量申请去生产的话，必定会产生大量的锁竞争（数据库对一条数据的更新会导致在索引上给这条记录加锁），耗费服务器资源，而且申请的成功率也不高（换句话说就是你在节约服务器资源，性价比不高）；热点行更新用来测试数据库锁控制能力和高并发大压力下事务状况。### 读写拆散场景介绍：一致性读用于在只读节点读取数据的时候，是否可用管制读的数据统一，包含强统一读和弱统一读；并且只读节点提早管制用于管制业务在读取过程中，备库最大反对多长时间的提早。### 分区变更个性场景介绍：分区规定变更用于验证数据库的分布式调整能力，分区策略调整能够灵便适配线上表的业务场景，尤其从单表到分区表（分布式表），或者从单表到播送表的场景。### 非凡场景#### 1. 大事务`测试数据为tpch100g 生成的lineitem表，单表6亿行数据select * from lineitem; update lineitem set L_PARTKEY=L_PARTKEY+1; `测试后果： #### 2. Json类型#### 3. 单机表数量单机表数量用于测试在简单业务场景下，单机上能够存储的最大表（分区）的数量状况，验证数据库的元数据管理能力，并且考查在单机反对更多表的状况下能够升高分布式的存储老本。#### 4. drop大表影响TiDB、OceanBase、PolarDB-X均能够平滑删除，对在线业务无影响。 #### 5. 应急限流场景介绍：应急限流用于在线上紧急情况下，对局部烂SQL或者问题SQL进行紧急限流，保障大多数业务失常的状况下，限度局部烂SQL的运行，可用于紧急线上复原。#### 6. 资源隔离场景介绍：用户验证是否反对oltp和olap场景主动资源隔离，olap通常须要大量的数据查问剖析资源，如果无奈资源隔离有可能影响在线业务的应用和稳定性。#### 7. 动静索引绑定场景介绍：用于测试执行打算绑定能力## 测试后果剖析### TiDB：1. 开启了实验室个性(plan cache)，不倡议生产间接应用。生产环境默认不开启的话，point\_select性能会有60%左右的性能降落，100核左右的资源点查场景只有36万QPS2. sysbench测试场景中，会有比拟大量的where id between xx and xx，但在理论业务中单纯基于用户id或者交易id的范畴查问意义并不大，更多是在工夫范畴的查问。TiDB基于Range的分区策略，在between的分区裁剪能够做到只拜访1个数据分片，而PolarDB-X和OceanBase基于Hash的策略会拜访5个数据分片，因而TiDB的数据结构会在sysbench单纯指标能力上占肯定的劣势。ps. 针对Range 和 Hash分区的性能差别，在PolarDB-X上基于read only场景下跑了下Range分区的比照测试，Range相比于Hash分区差不多有45%左右的性能晋升(28万 vs 19万)3. TPC-C场景下，整体劣势比拟显著4. TPC-H场景下，在tilfash模式下性能体现不错，但在一般的tikv模式下，局部SQL跑不出后果5. 非凡场景下，加索引的DDL性能有待晋升，反对json但不倡议生产应用，以及在热点行更新下有显著瓶颈###  OceanBase：1. 非分区表(通常了解的单表)，在OceanBase外部会在分布式多个节点上做表级别的平衡，一张表的数据只在一个节点，不同表能够在不同的节点，在非分区表下比拟考验纯单机的能力。针对sysbench场景下的多张表在测试过程中是齐全独立的，这样能够充分利用"多个单机"跑出一个更好的总吞吐值。这样的模式下，相比于TiDB会有30%~70%的劣势，多个独立的单表模式在实在业务场景中个别须要配合业务端的分库分表。2. 分区表，在OceanBase外部反对将一张表的数据分布到多台机器上，实现行级别的程度扩大能力，在分区表下会存在分布式事务、分片聚合查问等额定代价，是最考验分布式能力的中央。分区表和 非分区表在sysbench的性能测试后果上，两者的性能差别微小。尤其在写入和混合读写场景，分区表只有单表测试的1/5左右，分布式事务的性能还须要有进一步的晋升空间。3. TPC-C场景下体现优良。在TPC-H场景下，通过并行计算+行存整体体现不错。4. 非凡场景下，不反对json，以及在热点行更新下有显著瓶颈。###  PolarDB-X：1. 非分区表(通常了解的单表)，PolarDB-X上反对通过locality模式将表调配到不同的节点，一张表的数据只在一个节点上，比拟考验纯单机的能力。针对纯读和混合读写场景，相比于TiDB会有2~2.5倍的性能劣势。2. 分区表，在PolarDB-X外部反对将一张表的数据分布到多台机器上，实现形式和TiDB、OceanBase分布式表基本一致，在write only上整体性能会比TiDB好一些；在最常见的业务场景read write下，分区表和单机表性能都比OB要好很多，非分区表比TIDB有显著的性能劣势，分区表跟tidb根本保持一致3. TPC-C场景下体现优良。在TPC-H场景下，通过并行计算+行存整体体现不错4. 非凡场景下，疾速加列DDL须要优化，反对json，以及针对热点更新的优化显著。polardb-x对分区规定变更反对最好，根本反对所有常见的分区变更策略## 总结1. PolarDB-X/OceanBase/TiDB在分布式程度扩大的性能上大同小异，区分度并不大。2. TiDB有一些不错的试验性质的性能(比方plan cache、json)，对性能和性能易用性帮忙比拟大，但眼下生产不举荐应用。3. OceanBase的模型比较复杂，测试场景须要充沛了解分区表和 非分区表(单表)。在非分区表(单表)模式下，性能体现不错，重点考查的是纯单机能力，性能尚可，略低于MySQL。但分区表模式下，性能降落比拟多，须要业务辨别来看。4. PolarDB-X功能性和易用性比拟不错，json、大事务、热点更新反对比拟残缺。在非分区表(单表)模式下，纯MySQL单机的能力体现突出，在分区表模式下，能够通过分布式能力进一步扩大性能，对分区表的变更策略反对最欠缺。（完）> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：云计算将扭转数据库格局近日，阿里云智能数据库事业部负责人李飞飞在媒体沟通会上发表了“新技术变革时代的数据库产业”主题演讲。 李飞飞说，云数据库曾经成为数据库最重要的倒退方向，从国内国内数据库产业的倒退来看，这个趋势曾经非常明显。在他看来，在新技术大改革期间，中国数据库市场也肯定会产生一系列显著的变动。 具体到阿里云的倒退策略，他示意，作为中国排名第一的数据库厂商，阿里云曾经做好了全面服务政企市场的筹备，并会在这个市场上继续发力。 以下为演讲的核心内容： 数据库的将来：云原生+分布式首先回顾整个数据库的倒退历程。 过来几十年，IT基础设施的规模正在发生巨变，从晚期的大型机、小型机，再到X86服务器，到互联网，再到云+端的演进，底层的设施数量呈现了从几十台到几百万台指数级的增长。 这种基础设施的变动，为下层数据库的演进提供了松软的根底。就像物种会随着环境的变动而演进一样，当基础设施——计算、存储、网络这些根底的计算资源一直演进的时候，这些基础设施之上的数据库系统，也需相应地继续演进。 不同的基础设施对应了不同的利用场景，以及数据库倒退的不同历史阶段。 过来几十年，数据库经验了从晚期的关系型数据库，到起初的数据仓库和关系型数据库配合，OLTP和OLAP两个畛域的细分，到前面开源数据库，再到明天云数据库的一个倒退历程。 DB-Engines对数据库畛域有深刻的跟踪剖析。目前，这个网站上有近400款不同的数据库的产品，这个数字直白地阐明数据库市场竞争十分强烈。 DB-Engines网站上的数据库分为不同类型，有关系型数据库、图、文档、剖析型数据库等，别离对应不同行业特点和客户需要的细分市场。除了传统商业化数据库，开源社区的数据库倒退也十分迅猛。 DB-Engines有一个指数——Popularity Trend，这是通过各种指标计算出的。该指数显示开源数据库和商业数据库之间的风行差距曾经疾速放大。 这所有都表明了数据库行业正在产生新的变动。权威市场钻研机构Gartner在相干报告中论述了几个十分重要的趋势： 第一，数据规模爆炸性增长。咱们处在一个大数据时代，毋庸置疑。 第二，数据的生产和解决的实时化需要越来越强。这也是为什么阿里云明天提出云原生数据库2.0，提供一站式数据管理与服务。 第三，生产和数据处理的智能化。当初用户对数据的解决不再停留在传统的事务处理、交易以及简略或聚合类的剖析查问，而是心愿能从数据中失去更多洞察，利用数据驱动智能的业务决策。这对咱们数据库后续的倒退也提出了新的挑战。 最初，数据在减速上云。这是非常明显的行业趋势，尽管有公共云、混合云、公有云等各种状态，然而各行业对云化的部署形式已是深信不疑。依据Gartner预测，到2023年，全世界75%的数据库都会以云的形式在运行。 数据库系统架构也在疾速演进。最早数据库是单节点架构，传统的商业数据库和开源数据库都是这个架构。 在理论的利用部署中，这种数据库的长处是部署简略，开发简略。然而也有毛病，首先无奈提供高可用能力、主备的运维、高可用切换、非常复杂且面对十分大的技术挑战；其次，无奈疾速扩容。就比方本人家后院的小仓库，当数据量或者并发解决的要求超过容量的时候，没有方法疾速扩容。 为了解决弹性扩大、高可用等问题，业界衍生出两个核心技术路线，一个是云原生的技术路线，一个是分布式数据库的技术路线。 云原生到底是什么？ 云原生的实质就是将资源池化，就像以前家家户户在后院挖个水井，明天不会再在后院挖个水井，而是会关上水龙头，按需按量应用，弹性计费应用水的资源，有一个大的池子，这就叫资源池化，其实和云计算应用计算存储网络资源是一样的情理。 云原生数据库外围的理念就是利用云计算的实质，使用虚拟化的技术，将数据库外面的外围资源进行池化解决，以此解决资源弹性、高可用的挑战。这外面还有一个外围的理念——存储计算拆散，通过将存储和计算解耦，别离灵便弹性地满足客户业务需要。 除了云原生，另一个技术方向是分布式。 通过分布式的形式，能够将计算和存储进行程度拓展，满足业务的大数据量以及高并发的需要。当然这也有挑战，分布式的事务处理，数据库仍须要满足ACID原子性、一致性、隔离性、持久性等个性。在分布式架构下，保障读写的高效解决十分有挑战。 数据库将来的发展趋势肯定是将云原生能力和分布式能力合二为一，既提供分布式的程度拓展能力，也提供云原生的弹性高可用能力。将两者联合起来，也是阿里云以PolarDB为代表的云原生数据库，进一步去摸索和倒退的方向。 云计算扭转数据库市场格局阿里云数据库在云原生畛域继续进行了多年的耕耘和积攒，咱们获得了一些停顿。Gartner预测在2023年75%的数据库都会以云的形式来运行。 Gartner每年都会做魔力象限，对云计算IT畛域重要赛道进行评估。2013年之前，数据库领导者象限根本是被传统的几个巨头占据，Oracle、微软、IBM的DB2，还有SAP。 到2020年，市场产生了天翻地覆的变动，在海内市场有一个显著的特点是，除了传统数据库巨头，AWS、谷歌、微软等云厂商也进入领导者象限。 值得一提的是当初的微软和当年的微软齐全不同，微软此次进入领导者象限是因为其云数据库的服务能力疾速晋升，极具竞争力。联合其线下数据库和云数据库两个赛道的劣势，微软曾经实现了在整体市场份额上对Oracle的反超。 阿里云数据库在2020年首次进入了寰球数据库领导者象限，这也是Gartner在产品成熟度、技术先进性、客户满意度，以及市场占有率等多个维度深度评估后给出的高度认可。 图片起源：特大号   上图是十年前和2020年最新的寰球数据库市场份额排名比照。寰球数据库市场份额列表蕴含了云数据库的市场份额以及传统线下数据库的市场份额，两者联合剖析，过来Oracle始终占据第一，2020年微软第一次反超Oracle。 这其实是微软利用SQL Server以及Azure云数据库的疾速成长，两个赛道联合实现了对Oracle的反超，这是十分具备历史意义的里程碑事件，再次凸显了云数据库在新的环境下，对各个厂商及数据库市场的重要性。 另外，在过来几年，阿里云的市场份额继续晋升，曾经到了寰球第七位。如果只看云数据库赛道，阿里云排名寰球第四，位列AWS、微软、谷歌之后。 数据库产业的历史新机遇尽管数据库是一个倒退了四十年的赛道，但它并不是一个按部就班的赛道。我认为在明天这个工夫节点，数据库还是一个十分有生机的赛道，孕育着大量新的市场时机和新的暴发点。 第一，数据库是根底软件类目标第一大赛道，根底软件有很多，但数据库是根底软件里最为外围的类目，也是市场体量最大的一个类目。 第二，从开发者的角度看，超过一半的开发者都须要应用数据库，其重要性毋庸置疑。 中国数据库的产业倒退有几个新的时机，能够称之为四新——新政策、新面孔、新技术、新机遇。 第一，新政策。这次要是国家出台了系列政策，将对根底软件的器重水平晋升到了前所未有的高度。国家十分激励咱们中国的企业，通过凋谢、偏心的市场竞争形式，晋升国产数据库的竞争力，从技术水位、市场份额来看，国家也提供了十分好的环境。 第二，新面孔。传统的上一代国产数据库厂商叫四小龙，衍生到明天国产数据库的赛道百花齐放，呈现了更多的新面孔，包含以阿里云为代表的云服务厂商，还有专门做企业级数据库软件的厂商等。 第三，新技术。明天之所以咱们有这个时机去挑战传统数据库厂商市场第一的位置，并且实现了超过，实质上是咱们所处的环境产生了巨大变化。 如同达尔文的《进化论》，物种要疾速进化的前提是四周的环境发生变化，新物种适应环境的能力比具备统治位置的老物种更快，它的进化速度就会更快。 新技术的产生，像云原生、分布式、智能化，面向物联网的多模数据的解决、平安可信、新硬件、以及开源，这些维度是明天以及将来很长一段时间，各个数据库厂商会开展强烈竞争的赛道。 最初，新机遇。越来越多的企业级用户会抉择云的部署形式，这个为咱们进入传统政企市场提供了十分好的时机。 阿里云数据库不仅在公共云市场处于领导者位置，也做好了全面为线下传统政企市场服务的筹备，事实上咱们曾经服务了大量传统政企客户，并且用云原生、云计算的形式，为他们带来了以前传统部署形式享受不到的技术红利，不仅仅是从IT降老本，保障稳固运行，更是带来了新的业务价值，新的业务时机。 云原生数据库2.0：一站式数据管理回顾阿里巴巴数据库的倒退历程： 2005年-2009年，电商高速倒退期间，阿里巴巴团体领有亚洲最大的Oracle集群； 2010年-2013年，阿里巴巴胜利用自主开源的AliSQL替换了传统商业数据库； 2014年，阿里巴巴开始布局自研数据库，因为业务推着咱们往前走，比方双十一电商场景，有异地多活、热点打卡、秒杀的需要，让咱们看到了自研数据库的价值，于是咱们动摇投入到数据库这个根底软件的自主研发中去； 2017年到明天，通过多年积攒的数据库技术，咱们提供了丰盛的数据库的服务，比方云数据库的托管服务RDS、云原生数据库PolarDB和分布式版本PolarDB-X、以及云原生数据仓库AnalyticDB，这些外围产品造成了咱们数据库产品和服务的矩阵。 通过技术迭代，云原生数据库2.0时代，咱们心愿提供一站式的数据管理与服务。 阿里云数据库曾经毫无争议的来到了中国数据库市场第一的地位，在寰球舞台上，具备了向更高台阶、更高市场份额竞争和挑战的能力，进入了Gartner寰球数据库领导者象限。 另外，依据IDC最新的中国关系型数据库市场份额的钻研报告，公共云加线下合起来统计，阿里云数据库的市场份额占比28%，超过了第二名十个百分点。 在Forrester最新数仓报告中，云原生数仓AnalyticDB也进入了寰球的强劲领导者象限，在业界的规范基准测试外面，获得多项性能及性价比第一的后果。 咱们不仅在商业市场上获得微小的冲破和成就，还失去了国家的高度认可。云原生最外围的产品，云原生数据库PolarDB去年取得中国电子学会的科技进步一等奖，这是中国电子学会最高的奖项。咱们的数据库也是惟一入选的数据库的产品，体现了从国家层面，从科研的角度，对咱们的新技术、新科研实力的认可。 云原生数仓AnalyticDB也取得了浙江省科技进步一等奖，咱们进行了对x86、ARM等多种硬件以及操作系统的适配，这样能够更好的服务中国的企业级市场和客户。 展望未来，我认为云原生数据库曾经倒退到了Gartner提到的市场倒退阶段，开始直面数据的实时性、在线交易剖析一体化、数据智能化解决等新需要。 因而，咱们提出云原生数据库2.0，提供一站式数据管理与服务的能力，通过数据生产和集成，到数据实时处理、存储，再到数据分析和发现，最初到数据开发和治理，提供全链路数据生命周期的治理。 在这个根底上，咱们为客户提供面向行业的解决方案，也就是面向不同客户且能产生行业价值的解决方案，最初联结咱们的生态合作伙伴一起服务客户，从分销生态到ISV被集成，再到服务生态，再到开发者，造成一整套的数据全链路的治理和服务的能力。 最初感激咱们的客户，咱们的客户散布在各行各业，从泛互联网行业，到传统的政企，包含交通、能源、电力、银行、保险、证券等行业。 咱们十分骄傲能够通过阿里云数据库产品和服务，以及一直的迭代翻新，发明客户价值。通过为客户提供优质的数据库服务，帮忙客户获得业务上的停顿和胜利，咱们的客户再去服务千家万户，最终为整个社会的倒退做出奉献。 ...

简介：2020 年 10 月 23日，阿里巴巴正式发表开源其首个 Serverless 开发者平台 Serverless Devs。历经近一年精心打磨，明天 Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升，更加贴近开发者的理论生产诉求，应用体验再晋升，让开发者像应用手机一样玩转 Serverless，疾速享受 Serverless 技术红利。 作者 | 寒斜、江昱 2020 年 10 月 23日，阿里巴巴正式发表开源其首个 Serverless 开发者平台 Serverless Devs。历经近一年精心打磨，明天 Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升，更加贴近开发者的理论生产诉求，应用体验再晋升，让开发者像应用手机一样玩转 Serverless，疾速享受 Serverless 技术红利。 这就是 Serverless DevsServerless Devs 是一个开源凋谢的 Serverless 开发者平台，Serverless Devs 也是业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理的平台，致力于为开发者打造 Serverless 利用开发一站式服务, 帮忙解决目前的工具链之困，让开发者一键体验多云产品，极速部署 Serverless 我的项目。 Serverless Devs 由"两端一核心体系"组成： Serverless Devs CLI (命令行客户端)，适宜极客开发人员应用，玲珑轻便，易于集成Serverless Desktop (桌面客户端) ，具备更宽泛的适用性，领有开发，构建，部署，调试，可观测等全方位利用治理能力Serverless Hub 利用核心，提供利用的集散和散发，作为公共服务提供给 开发者或贡献者实用。 ...

简介：云开发平台将“人生重开模拟器”fork到了云开发的仓库了，用户只须要间接fork到本人的仓库当前就能够在云开发平台上进行疾速魔改和一键部署，绑定本人的域名就可能让小伙伴们一起来感触你的魔改创意哦。人生无奈重来，游戏能够重开！人生重开模拟器莫名其妙就火了，这是款纯文字MUD游戏。玩家开局能够从10个各具特色的天才里选中3个，并为本人的4项属性（颜值、智力、体质、家境）调配点值就可能重开你的人生。你齐全无奈意料本人会有怎么样的经验，比方2岁吃不饱饭死了、政府要求5点放学、家庭艰难、吃不饱饭、进入监狱、一会有女朋友、一会交一个男朋友等等，这款游戏还有很多十分厉害的暗藏终局！ 这个游戏的全貌就是全程点点点，如播放 PPT 个别从诞生到死亡，没有美术、没有音效、甚至没有广告。但它魔性的随机文本词条混搭着平平淡淡的日常，偶然还会存在奇奇怪怪的开展，让我一心想摸索一下人生的边界，重复重开，重复筛选天才、配置属性，总想体验不一样的人生，一不小心就轮回了几百次。一玩就上瘾，重开了快 300 次人生，也逃不过究竟平庸的命运，还是没有体验到开挂的人生。那来啊，来魔改啊，长生不老版、升仙版、音效版，你都能够领有。 云开发平台将原我的项目fork到了云开发的仓库了，用户只须要间接fork到本人的仓库当前就能够在云开发平台上进行疾速魔改和一键部署，绑定本人的域名就可能让小伙伴们一起来感触你的魔改创意哦。 人生重开模拟器的实现逻辑剖析这个游戏的repo里一共就不超过10个js文件，没有应用任何简单的库，只是用jQuery和css简略的拼了一个前端而已，惟一简单一点的中央是游戏逻辑解决。 首先，游戏数据，如天才和事件等，是寄存在data目录下：外面有游戏数据相干的xlsx与json文件，如每个年龄可能产生的事件、各个事件产生的条件、天才等等。作者还写了一个脚本文件utils/xlsxTransform.js用于将xlsx文件转化为json，不便读取。 钻研一下这个表格，咱们能够发现，人物的根底属性有这么几种： CHR(Charm): 颜值INT(Intelligence): 智力STR(Strong): 体质MNY(Money): 家境SPR(Spirit): 高兴LIF(Life): 生命事件的产生可能会带来颜值、智力、体质、家境的变动。 生命的变动只有“-1”。包含“你死了”和“飞升天界”两种状况。所以修仙胜利的敌人们不要太得意。你认为的位列仙班，没准就是被天道采摘成熟果实呢？“有某事件时能力被随机到”和“有某事件时肯定随机不到”造就了命运迥异的农村线、城市线、美籍华人线。天才（TLT, talent）对于事件的产生也有影响，如城间高楼必然出世在城市。产生事件后，可能会依据前置事件和人物属性走向不同的分支。例如“你受到了一位老师的猥亵”事件在人物 INT>7 时会走向“你报了警，老师被刑拘”反之则是“你逐步低沉，但不敢和其他人说。”其次游戏的次要代码都是在src目录下： 你能够先从 src/index.js 开始了解，这个文件就干了两件事： 读取方才提到的 data 下的 json 游戏数据，绑定为全局变量；绑定一个全局的 banner handler。初始化 app。import App from '../src/app.js';window.json = async fileName => await (await fetch(`../data/${fileName}.json`)).json();// Pssst, I've created a github package - https://github.com/brookesb91/dismissiblewindow.hideBanners = (e) => { document .querySelectorAll(".banner.visible") .forEach((b) => b.classList.remove("visible"));};const app = new App();app.initial();而后你能够顺着去读 src/app.js 的代码，外面就是次要的前端 jQuery 局部，负责生成视图并绑定函数，基本上大部分前端的逻辑都在这里。举个例子，上面这段代码： ...

简介：想让你的利用成为几万个开发者的开发模版吗？云开发平台向腾云驾雾的程序员征集Serverless云开发的最佳实际，优良的利用案例将成为云开发平台实验室的模版供大家体验，一键部署成为TA的利用。同时云开发平台还筹备了开发者社区有史以来最大的礼包等你来PICK，阿里云定制T、公仔徽章、背包、Cherry联名BugFree机械键盘！云开发平台曾经上线一年多工夫，在升高开发者的老本的同时也给开发带来了极大的便当。本次征文活动向开发者征集云开发的最佳实际，开发者show出本人的用法和理论的案例，通过这些教程让更多的开发者能够感触到云原生时代新开发范式带来的畅快感！ 第一次应用云开发平台？收费体验最当先的Serverless云开发模式，支付10元阿里云无门槛代金券加油包。网址：https://workbench.aliyun.com/activities/coupon须要包含什么内容？整体文章内容1000字以上，图文联合且必须为原创。题目包含：「72变的云开发」+内容题目征文内容围绕开发者基于云开发平台开发的利用案例开展，须要包含利用开发的背景，利用开发的流程和通过。能够是云开发部署利用的具体步骤，也能够是胜利开发和迁徙利用所想所感悟到的教训和技巧。云开发平台将筛选文章总结成最佳实际案例，征文内容包含但不限于以下的三类案例。迁徙的利用：基于云开发平台的迁徙模版，将开源或者本地已有我的项目迁徙到云开发平台上。开发的利用：基于云开发平台的案例模版进行定制化的开发，造成本人的集体利用和或者企业级别的利用。新的性能实现：基于云开发平台的性能，如何实现大数据分析、多媒体文件托管等新的性能。文章样例「Serverless云开发72变」来右边跟我一起画个龙，左边跟我用AntV画个图「Serverless云开发72变」随时随地短链「Serverless云开发72变」实现一个简略的博客如何参加投稿？本次征文活动面向所有阿里云官网注册用户，参加形式如下： 注册成为阿里云用户，并实现实名认证。点击进行注册登录之后进入云开发平台技术圈：https://developer.aliyun.com/group/devcloud，点击页面右上方“发文章”按钮即可进行创作，内容将公布至您的个人主页内，并同步云开发技术圈板块。所有参赛作品需在2021年10月31日24:00前提交。文章积分统计工夫截止11月2日10:00。获奖名单将于11月5日上午12:00颁布，奖品将于11月11日前寄出。留神：发文前需进行实名认证。曾经注册过的用户及实名用户无需再次注册实名。 三重礼都有什么奖品？一重礼所有合乎根本条件的投稿作者，均将会取得阿里云公仔徽章留念礼品一份。 二重礼利用创意新鲜，云开发平台选为利用模版让宽广开发者进行试用的文章，处分天猫精灵方糖音响一个。 三重礼同时咱们还会依据文章的品质进行奖项评比，处分三重奖品，有BugFree的机械键盘哦。 奖项奖品获奖条件“最强王者”奖积分9分以上的参赛者“进阶大神”奖阿里云背包积分8分以上的参赛者“技术牛人”奖阿里云设计师款T恤积分6分以上的参赛者社区将根据文章浏览评论等综合剖析对文章进行排名，并根据排名发放奖品。 积分采纳2（评论）:3（浏览量）:5（专家评审），10分制满分。 能够分享文章，吸引气味相投的盆友评论（同一uid反复评论不计数）。 评论量评分：1～5条积0.5分； 5～30条积1分； 30～50条积1.5分； 50+积2分。 浏览量评分：注：浏览量2000以下不计分 浏览量1分：浏览量在2000~5000积1分； 浏览量2分：浏览量在5000~10000积2分； 浏览量3分：浏览量在10000+积3分； 专家评审：5分为高质文章：文章内容残缺，条理清晰，逻辑性强，有成熟的技术思考和翻新。 4分优质文章：文章内容残缺，逻辑性强，代码与文字占比正当，有肯定技术思考。 3分个别：文章内容残缺且有肯定逻辑性。 2分合格：文章内容残缺。 1分不合格：文字拼贴，排版潦草，有笔误等。 （具体评审根据专家评判） 为偏心起见，每位用户可参加一次发文，屡次发文者依照积分最高的一篇计算获奖状况。 有问题？投稿过程有任何问题，可钉钉扫码进群进行沟通，理解流动实时停顿！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：应用Severless架构搭建挪动App、小程序和Web利用后端服务，弹性伸缩应用云资源。 中转最佳实际：【函数计算搭建小程序Web利用后端服务】 最佳实际频道：【点击查看更多上云最佳实际】 这里有丰盛的企业上云最佳实际，从典型场景入门，提供一系列我的项目实际计划，升高企业上云门槛的同时满足您的需要！ 场景形容应用Severless无服务器架构搭建挪动App、小程序和Web利用的后端服务，动态资源（如图片）存在OSS上通过CDN减速拜访，动态数据通过API网关+函数计算拜访RDS数据库，无需治理服务器和运行环境，弹性伸缩应用云资源。 解决问题1、业务摸索阶段疾速上线服务 2、服务端开发资源有余，业务紧急 3、利用阿里云API网关能力做流控和平安 产品列表函数计算云数据库RDS MySQL版CDN对象存储OSSAPI网关专有网络VPC 中转最佳实际 》》 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：短视频作为内容重要的承载形式，是吸引用户的重点，短视频的内容与体验间接关系到用户是否违心长时停留。因而，体验的优化就显得尤为重要。上一篇咱们分享了 iOS 短视频秒播优化，这篇咱们来聊聊 Android 端的优化。作者｜少阳 审校｜泰一 优化前的盒马沉迷式短视频播放页面，体感和晦涩度上与支流短视频 App 有显著差距。次要问题有播放封面闪屏、出流速度慢两个问题。所以优化的指标是解决盒马沉迷式短视频现有短板，与支流 App 的沉迷式短视频体验对齐，如抖音、手淘等。具体指标有： 满足硬性指标：播放成功率、首帧时长、秒开率。满足用户体感晦涩度。（为反馈用户观看短视频过程中的实在体验，盒马新增秒播体感指标：从用户划到视频，到视频首帧播放的工夫。） 优化成果比照首先咱们来看一下优化前后与其余 App 的成果比照： 环境 手机：Pixel 4OS：Android 10播放器：淘宝播放器问题剖析◆ 首页闪屏盒马最后为了保障进入画面时不是空白页面而减少了封面图显示，在播放时暗藏。从体感指标能够看出，即使是优化前，体感播放工夫很短，只有 200ms 左右（不蕴含滑动过程）。因为滑动过程中，到视频正式播放有约 600ms 左右工夫显示封面，随后又迅速显示播放画面，此时用户仍有强烈的屏幕闪动和顿挫感，体验极差。 解决思路：在滑动过程中就显示视频首帧画面，不再显示封面，则播放时不再产生顿挫感。这里的优化须要联合出流慢问题一起优化。 ◆ 出流速度慢（播放体感慢）服务端：服务端造成的出流速度慢，个别是文件大，网络链路差造成。可用 H.265 和 CDN 减速优化 客户端：客户端播放须要经验下载 -> 加载 + 解码 -> 渲染三个步骤，并且三个步骤为线性执行。所以在窗口播放画面前必然须要通过 1s 左右的筹备工作。这里能够思考提前执行下载 -> 加载 + 解码。 优化计划选型在优化后期，咱们思考了三种优化计划。 计划一：双播放器 + 预下载长处：占内存小，思路简略。毛病：优化力度无限，无奈同时兼顾上滑和下滑。 计划二：自定义三播放器治理 + 预下载长处：同时兼顾高低翻页，体验靠近抖音。毛病：播放器治理与回收实现简单，容易错乱；占用内存高。 计划三：三播放器（基于 RecyclerView 的缓存机制实现）+ 预下载长处：同时兼顾高低翻页，体验靠近抖音，缓存机制由 RecyclerView 托管。毛病：占用内存高，频繁创立和销毁播放器。 最终因为性价比因素，抉择了第三个计划。 计划三原理：翻页前current 播放器开始播放视频 1。pre,next 播放器别离加载视频数据 0 和 2。同时视频数据 3-7 退出预下载队列。 计划三原理：翻页后被 RecyclerView 回收的 holder 销毁播放器。RecyclerView onBind 中的 holder 创立新的 next 播放器。current 播放器开始播放视频 2。pre 播放器 seek 0 并暂停， next 播放器创立并加载视频 3 文件。同时预下载革除未生产的队列，视频数据 4-8 退出预下载队列开始下载（此处已有缓存的视频不会被反复下载）。 ...

简介：2021.9.1，阿里云微服务引擎（MSE）反对Dubbo3.0+Nacos2.0，扩展性晋升10倍，反对服务网格生态，规范、灵便、精准的管制流量，晋升零碎整体可用性。阿里云微服务引擎（MSE）反对Dubbo3.0+Nacos2.0，扩展性晋升10倍，反对服务网格生态  2021.9.1，阿里云微服务引擎（MSE）反对Dubbo3.0+Nacos2.0，扩展性晋升10倍，反对服务网格生态，规范、灵便、精准的管制流量，晋升零碎整体可用性。   据介绍 Dubbo 3.0做了大的架构降级，反对利用级服务发现，升高注册核心和服务订阅者压力，反对百万集群横向扩大；新增Triple协定（基于 HTTP/2），大幅晋升服务网格治理能力；反对云原生治理规定，打造基于标和模板的规范、灵便、精准流量管制体系。并且MSE基于云原生治理规定做了全面的服务治理能力加强，晋升零碎可用性，晋升研发运维效率。 据介绍 Nacos 2.0做了大的架构降级，采纳gRPC协定 和 基于连贯的服务一致性模型晋升10倍扩展性和推送效率；反对MCP协定反对服务网格生态；并且MSE 在高可用、性能、平安大量加强，让用户取得企业级保障。 阿里云 MSE 负责人示意，采纳MSE能够间接享受阿里10年双十一打磨的微服务体系的红利，从此不必思考性能、扩展性、稳定性、平安等问题，让业务更专一于业务开发，疾速迭代倒退。 阿里云微服务引擎（MSE）云原生网关公测，引领下一代网关技术2021.9.1 随着云原生技术倒退，微服务体系标准化根本成型，目前K8s通过Ingress将网关技术标准化，通过服务网格技术将流量管制标准化。MSE也推出借势推出 云原生网关产品（合乎K8s Ingress规范的微服务 API GateWay），将阿里外部一年多积淀的云原生和服务网格技术输入，让用户尽快享受云原生红利。 据介绍云原生网关采纳Envoy内核，将K8s Ingress 和 微服务网关 合二为一，升高50%资源老本；集成限流和熔断能力，帮忙业务从入口构建高可用体系，避免大促洪峰冲垮零碎；集成认证登录体系，让业务疾速构建平安屏障。 阿里云 MSE 负责人示意，采纳MSE 云原生网关，就默认具备了卓越的性能，企业级可用性，金融级平安能力；抉择了面对将来的网关技术潮流，无缝融入K8s和服务网格生态。  版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：上文说到云计算的十余年倒退让整个互联网行业产生了天翻地覆的变动，Serverless 作为云计算的产物，或者说是云计算在某个时代的体现，被很多人认为是真正意义上的云计算，对于“Serverless 是什么”这个问题，其实是能够通过不同角度来剖析的。作者 | 刘宇 前言上文说到云计算的十余年倒退让整个互联网行业产生了天翻地覆的变动，Serverless 作为云计算的产物，或者说是云计算在某个时代的体现，被很多人认为是真正意义上的云计算，对于“Serverless 是什么”这个问题，其实是能够通过不同角度来剖析的。 Martin Fowler 在 “Serverless Architectures” 一文中从 Serverless 组成角度给出了 Serverless 的定义，他认为 Serverless 实际上是 BaaS 与 FaaS 的组合，并针对 BaaS 和 FaaS 进行了具体的形容。 Serverless 最早用于形容那些大部分或者齐全依赖于第三方（云端）利用或服务来治理服务器端逻辑和状态的利用，这些利用通常是富客户端利用（单页利用或者挪动端App），建设在云服务生态之上，包含数据库（Parse、Firebase）、账号零碎（Auth0、AWS Cognito）等。这些服务最早被称为 Baas（Backend as a Service，后端即服务）。 Serverless 还能够指这种状况：利用的一部分服务端逻辑仍然由开发者实现，然而和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动，生命周期很短（甚至只有一次调用），齐全由第三方治理。这种状况被称为 FaaS（Functions as a service，函数即服务）。AWS Lambda 是目前的热门 FaaS 实现之一。 通过 Martin Fowler 的形容能够总结出 FaaS、BaaS 以及 Serverless 之间的关系为下图所示。 Serverless 架构的组成 从 Serverless 的构造上来看，Serverless = FaaS + BaaS 是一个被广泛认可的概念；从 Serverless 的个性上来看，Serverless 运行在无状态的计算容器中，由事件触发，并且领有弹性伸缩以及按量付费等能力，让使用者不必破费更多的精力在服务器上，而是更加关注业务自身。 不同角度上的 Serverless 的定义 ...

简介：云原生编程挑战赛，是由阿里云、Intel 主办，阿里云云原生、阿里云天池承办的云原生顶级品牌赛事。自 2015 年开始，大赛曾经胜利举办了六届，并从 2020 年开始降级为首届云原生编程挑战赛，共吸引超过 23000 支队伍，笼罩 10 余个国家和地区。 往年的云原生编程挑战赛将持续深度摸索 RocketMQ、Dubbo 3、Serverless 三大热门技术畛域，为酷爱技术的年轻人提供一个挑战世界级技术问题的舞台，心愿选手们能用手中的技术为全社会发明更大价值。 本文次要解密【赛道3】Less is more - Serverless 翻新利用赛，心愿为各位选手们提供一些思路。即日起—9月22日，但凡报名后提交参赛计划的选手，计划合乎预选赛规范，都将获赠大赛限量版留念T恤一件！ 还没报名的小伙伴放松上车了：https://tianchi.aliyun.com/competition/entrance/531924/introduction?spm=5176.12281925.0.0.58987137KRXtxf 云原生编程挑战赛，是由阿里云、Intel 主办，阿里云云原生、阿里云天池承办的云原生顶级品牌赛事。自 2015 年开始，大赛曾经胜利举办了六届，并从 2020 年开始降级为首届云原生编程挑战赛，共吸引超过 23000 支队伍，笼罩 10 余个国家和地区。 往年的云原生编程挑战赛将持续深度摸索 RocketMQ、Dubbo 3、Serverless 三大热门技术畛域，为酷爱技术的年轻人提供一个挑战世界级技术问题的舞台，心愿选手们能用手中的技术为全社会发明更大价值。 本文次要解密【赛道3】Less is more - Serverless 翻新利用赛，心愿为各位选手们提供一些思路。 赛程工夫预选赛（ 8月4日 - 9月6日）预选赛入围颁布（ 9月9日）半决赛（ 9月10日 - 10月18日）半决赛后果颁布（ 10月21日）。 点击下方链接可立刻理解详情、参赛报名 https://tianchi.aliyun.com/competition/entrance/531924/introduction 赛题背景2019 年 Berkeley 预测 Serverless 将取代 Serverful 计算，成为云计算的计算新范式。Serverless 为利用程序开发提供了一种全新的零碎架构，其凭借着弹性伸缩省事省心，按需付费更低成本、聚焦业务升高 OPS 这三大外围价值，成为云计算中一股新生力量取得有数开发者的青眼。Serverless 将开发人员从沉重的手动资源管理和性能老本优化中解放出来，就像数十年前汇编语言演变到高级语言的过程一样，让工程师的生产力再次发生改革。 明天，Serverless 已不再局限利用于耦合性低、边缘利用或离线工作上，越来越多的企业将 Serverless 利用于人工智能、音视频解决、网站利用、电商零碎等生产外围链路。新浪微博每日数十亿次个性化图片解决大幅度降低综合老本，石墨文档基于 Serverless 架构无效解决了性能瓶颈，闲鱼通过 Serverless 实现云端一体化编程模式晋升研发效率，口袋奇兵基于 Serverless 架构大幅晋升资源利用率，世纪联华更是全面降级到 Serverless 架构，享受 Serverless 带来的技术红利。 ...

简介：Nacos 在阿里巴巴起源于 2008 年五彩石我的项目（该我的项目实现微服务拆分和业务中台建设），成长于十年的阿里双十一峰值考验，这一阶段次要帮忙业务解决微服务的扩展性和高可用问题，解决了百万实例扩展性问题（10w->100w实例）。2018 年咱们粗浅感触到开源软件行业的影响，因而决定将 Nacos 开源，输入阿里十年对于服务发现和配管治理的积淀，推动微服务行业倒退，减速企业数字化转型。 随着近几年云原生技术的倒退，服务网格技术的提出，越来越多的公司尝试将微服务架构迁徙到服务网格架构，这对 Nacos 提出了一个新的诉求，那就是如何更好的反对服务网格生态。作者 | 怀成 Nacos 简介Nacos /n:ks/ 是 Dynamic Naming and Configuration Service 的首字母简称。指标是构建一个更易于构建云原生利用的动静服务发现、配置管理和服务治理平台。 Nacos 在阿里巴巴起源于 2008 年五彩石我的项目（该我的项目实现微服务拆分和业务中台建设），成长于十年的阿里双十一峰值考验，这一阶段次要帮忙业务解决微服务的扩展性和高可用问题，解决了百万实例扩展性问题（10w->100w实例）。2018 年咱们粗浅感触到开源软件行业的影响，因而决定将 Nacos 开源，输入阿里十年对于服务发现和配管治理的积淀，推动微服务行业倒退，减速企业数字化转型。 随着近几年云原生技术的倒退，服务网格技术的提出，越来越多的公司尝试将微服务架构迁徙到服务网格架构，这对 Nacos 提出了一个新的诉求，那就是如何更好的反对服务网格生态。 Nacos 无缝反对服务网格咱们先看下微服务 1.0 下的架构，流量从 Tengine 进来，通过微服务网关，而后再进入微服务体系。 这里解释下为什么分了两层网关，第一层 Tegine 是负责流量的接入，外围具备的能力是抗大流量、平安防护和反对 https 证书，谋求的是通用性、稳定性和高性能。第二层是微服务网关，这层网关偏重的是认证鉴权、服务治理、协定转换、动静路由等微服务相干的能力，比方开源的 spring cloud gateway，zuul 等都属于微服务网关。 流量进入微服务体系后，会通过微服务框架实现服务间的调用，比方 hsf/dubbo、spring cloud 等等，那么 Nacos 在这里起到的核心作用是服务发现能力，比方 cousumer 会先从 Nacos 获取 provider 的服务列表地址，而后再发动调用，还有微服务网关也会通过 Nacos 获取上游的服务列表。这些能力次要通过 SDK 的形式提供，同时也会在 SDK 上减少一些负载平衡、容载爱护的策略。 微服务 1.0 架构次要存在以下几个问题： ...

简介：随着微服务架构的衰亡，服务端的调用依赖更加简单，为了疾速定位异样组件与性能瓶颈，接入分布式链路追踪 Trace 曾经成为 IT 运维畛域的共识。然而，开源自建、开源托管或商业化自研 Trace 产品之间到底有哪些差别，我该如何抉择？这是许多用户在调研 Trace 计划时都会遇到的疑难，也是最容易混同的误区。作者 | 涯海 随着微服务架构的衰亡，服务端的调用依赖更加简单，为了疾速定位异样组件与性能瓶颈，接入分布式链路追踪 Trace 曾经成为 IT 运维畛域的共识。然而，开源自建、开源托管或商业化自研 Trace 产品之间到底有哪些差别，我该如何抉择？这是许多用户在调研 Trace 计划时都会遇到的疑难，也是最容易混同的误区。 为了搞清楚这个问题，咱们须要从两方面动手，一是梳理线上利用的外围危险与典型场景。二是比照开源自建、托管与商业化自研三种 Trace 计划的能力差异。所谓“知己知彼，百战不殆”，只有联合本身理论状况，能力抉择出最适宜的计划。 “两类危险”与“十大典型问题”线上利用危险次要分为“错”、“慢”两大类。其中“错”的起因通常是程序运行不合乎预期，比方 JVM 加载了谬误版本的类实例，代码进入异样分支，环境配置谬误等。而“慢”的起因通常是资源有余，比方突发流量导致 CPU 打满，微服务或数据库线程池被耗尽，内存透露导致继续 FGC 等等。 无论是“错”问题，还是“慢”问题。从用户的角度，都是心愿可能疾速定位根因，及时止损，并消除隐患。然而，依据作者五年多的 Trace 开发、运维与双十一大促备战教训来看，绝大部分线上问题是无奈仅通过链路追踪的根底能力就可能无效定位并解决的。线上零碎的复杂性决定了一款优良的 Trace 产品必须提供更加全面、无效的数据诊断能力，比方代码级诊断、内存剖析、线程池剖析等；同时，为了进步 Trace 组件的易用性和稳定性，还须要提供动静采样、无损统计、接口名称主动收敛等能力。这也是为什么业界支流 Trace 产品都在逐渐向 APM、利用可观测畛域降级。为了不便了解，本文依然以 Trace 来对立表述应用层的可观测能力。 综上所述，线上利用为了保障最终的业务稳定性，在做链路追踪计划选型时，除了 Trace 通用根底能力外（如调用链、服务监控、链路拓扑），还能够参考上面列举的“十大典型问题”（以 Java 利用为例），综合比照开源自建、开源托管与商业化自研 Trace 产品的差异化体现。 1、【代码级主动诊断】接口偶发性超时，调用链只能看到超时接口名称，看不到外部办法，无奈定位根因，也难以复现，怎么办？ 负责稳定性的同学应该对这种场景不生疏：零碎在夜间或整点大促时会呈现偶发性的接口超时，等到发现问题再去排查时，曾经失落了异样现场，并且难以复现，无奈通过手动 jstack 来诊断。而目前开源的链路追踪实现个别只能通过调用链看到超时的接口，具体是什么起因，哪段代码导致的异样始终无奈定位，最初只能不了了之。上述场景反复演出直至酿成故障，最终遭受微小的业务损失。 为了解决上述问题，须要一种精准、轻量级的慢调用主动监听性能，无需当时埋点，就可能实在还原代码执行的第一现场，自动记录慢调用的残缺办法栈。如下图所示，当接口调用超过肯定阈值（比方2秒），会启动对该次慢申请所在线程的监听，直至该次申请在第 15 秒完结后立刻进行监听，精准保留该次申请生命周期内所在线程的快照集，并还原残缺的办法栈及耗时。 2、【池化监控】微服务/数据库线程池常常被打满，导致服务超时，排查起来十分艰难，如何解决？ 微服务/数据库线程池满导致业务申请超时，这类问题每天都在频繁产生。具备丰盛诊断教训的同学，会无意识的查看对应的组件日志，比方 Dubbo 在线程池满的状况下会输入相干的异样记录。然而，如果组件没有输入线程池信息，或者运维同学排查教训不够丰盛，这类问题就会变得十分辣手。目前，开源版本 Trace 个别只提供 JVM 概览监控，无奈具体查看每个线程池的状态，更无奈判断线程池是否耗尽。 而商业化自研 Trace 提供的池化监控能够间接看到指定线程池的最大线程数、以后线程数、沉闷线程数等，线程池耗尽或高水位危险和盘托出。此外，还能够设置线程池应用百分比告警，比方设置 Tomcat 线程池以后线程数超过最大线程数 80% 就提前短信告诉，达到 100% 时电话告警。  ...

简介：在高性能的背地，Java 的启动性能差也令人印象粗浅，大家印象中的 Java 轻便迟缓的印象也大多来源于此。高性能和快启动速度仿佛有一些相悖，本文将和大家一起探索两者是否能够兼得。作者 | 梁希 高性能和快启动速度，是否鱼和熊掌兼得？Java 作为一门面向对象编程语言，在性能方面的卓越体现自成一家。 《Energy Efficiency across Programming Languages，How Does Energy, Time, and Memory Relate?》这份报告调研了各大编程语言的执行效率，尽管场景的丰盛水平无限，然而也可能让咱们见微知著。 从表中，咱们能够看到，Java 的执行效率十分高，约为最快的 C 语言的一半。这在支流的编程语言中，仅次于 C、Rust 和 C++。 Java 的优异性能得益于 Hotspot 中十分优良的 JIT 编译器。Java 的 Server Compiler(C2) 编译器是 Cliff Click 博士的作品，应用了 Sea-of-Nodes 模型。而这项技术，也通过工夫证实了它代表了业界的最先进程度： 驰名的 V8（JavaScript 引擎）的 TurboFan 编译器应用了雷同的设计，只是用更加古代的形式去实现；Hotspot 应用 Graal JVMCI 做 JIT 时，性能根本与 C2 持平；Azul 的商业化产品将 Hotspot 中的 C2 compiler 替换成 LLVM，峰值性能和 C2 也是持平。在高性能的背地，Java 的启动性能差也令人印象粗浅，大家印象中的 Java 轻便迟缓的印象也大多来源于此。高性能和快启动速度仿佛有一些相悖，本文将和大家一起探索两者是否能够兼得。 JAVA 启动慢的根因1、框架简单 ...

简介：服务网格作为服务间通信的基础设施层，吸引了越来越多的用户应用。阿里云服务网格 ASM 将持续为开发者带来便当。9月1日，阿里云服务网格（ ASM ）产品经理问思为大家解读近期 ASM 公布的一些新性能。9月1日，阿里云服务网格（ ASM ）产品经理问思为大家解读近期 ASM 公布的一些新性能。 ASM 5月推出的 Pro版，对Istio底层能力进行了扩大加强。全面反对Dubbo微服务框架，提供了精细化服务治理能力，比方全链路标签路由和服务无损下线。新增的规定控制器可实现路由配置只在指定标签范畴的Envoy节点上灰度失效，无效升高路由规定配置变更的危险。全面交融多种服务注册核心，包含Nacos和Consul，以便对应用这两种注册核心的微服务进行治理，并实现跨注册核心的多语言服务互通。其中Nacos 2.0性能晋升了10倍，可反对高性能、大规模场景。ASM更好地反对跨地区多集群、多云混合云上的服务的对立治理，通过边缘集群的反对，用户可摸索5G网络下边缘计算中服务网格的场景。用户无需代码革新就能实现零信赖平安, 并可利用OPA策略的动静执行能力，简化治理多种安全策略。优化现有利用进行现代化革新。阿里云服务网格ASM作为对立治理微服务利用流量、兼容Istio的托管式服务网格平台。它通过流量管制、网格观测以及服务间通信安全等性能，能够全方位地简化服务治理。从向下与基础设施交融的角度来看，它为运行在异构计算基础设施上的服务提供对立的能力。实用于Kubernetes集群、Serverless Kubernetes集群、ECS虚拟机以及自建集群。包含最近反对的ACK Edge边缘集群。 从网格本身能力建设来看，作为一个托管的服务网格产品, ASM将管制面外围组件进行革新托管, 并负责整个管制面和数据面组件的生命周期治理。在产品能力方面, ASM在Mesh CA、平安审计方面加强晋升了网格实例的平安度，它还在不断丰富网格诊断剖析规定，用户能够自助地对版本、服务端口、服务关联、标签、规定抵触等等可能呈现问题的点进行排查，提前裸露危险。 此外, ASM也集成扩大了社区开源的组件能力, 包含在平安方面的OPA平安引擎反对、SPIFFE/SPIRE 的反对、EnvoyFilter及WASM的扩大反对等，同时它优化整合了阿里云的多个产品服务, 包含链路追踪、利用实时监控、日志服务等可观测性产品，利用高可用服务的限流性能，并可通过MSE微服务治理提供多语言的场景化性能。 据统计，阿里云服务网格 ASM 很大水平上帮忙了企业管制服务器资源老本，将服务网络技术落地由月缩短为周，晋升了70%的更新迭代效率，缩短了80%的异样排错老本。 服务网格作为服务间通信的基础设施层，吸引了越来越多的用户应用。阿里云服务网格 ASM 将持续为开发者带来便当。如果您对于ASM有任何疑难或者想理解更多产品信息，欢送应用钉钉扫描二维码或者搜寻群号30421250退出钉钉交换群。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：间隔上一篇宣告 OCM 开源并提交 CNCF TOC 我的项目孵化申请的文章曾经有一个多月了。这一个多月来 OCM 社区吸引了越来越多的关注和搭档们的退出，OCM 本身的研发，相干畛域产品和解决方案的利用也获得了疾速的倒退。如果你还在对云原生环境下多集群治理的技术选型当机立断，心愿这篇文章可能答疑解惑。当初参加 OCM 社区正是时候。作者 | 邱见 冯泳 前言间隔上一篇宣告 OCM 开源并提交 CNCF TOC 我的项目孵化申请的文章曾经有一个多月了。这一个多月来 OCM 社区吸引了越来越多的关注和搭档们的退出，OCM 本身的研发，相干畛域产品和解决方案的利用也获得了疾速的倒退。如果你还在对云原生环境下多集群治理的技术选型当机立断，心愿这篇文章可能答疑解惑。当初参加 OCM 社区正是时候。 OCM 社区研发停顿Open Cluster Management 在七月份公布了 0.4.0 版本，新退出的次要性能包含： 1、插件注册和生命周期的治理  通过 ManagedClusterAddon API，用户能够定义治理插件阐明在被治理集群上装置治理插件，而后通过治理插件实现可扩大的治理能力。例如，用户能够在核心集群上的 ManagedCluster 资源对应的命名空间中创立名为 submariner 的 ManagedClusterAddon 资源来激活被治理集群中 submariner 的装置和配置，应用 submariner 作为多集群网络连通的解决方案。 集群治理插件的注册和治理如下图所示： 每个插件须要一个在核心集群上运行的控制器。这个控制器由插件的开发者开发，次要目标是通知 OCM 这个插件在被治理集群中须要如何被装置，如何和核心集群通信以及对应的通信权限。OCM 通过这些信息负责插件在被治理集群的部署和与核心集群的通信。为了不便开发者不便的开发基于 OCM 的治理组件，OCM 0.4.0 退出了 addon-framework 的 golang 框架帮忙开发者。开发者只须要实现框架透出的接口提供插件的部署和配置信息，同时框架还提供了若干帮忙函数，不便开发者在 Kubernetes 平台增加资源解决逻辑。开发人员能够将 Kuberentes 自定义资源的 Operator 也实现在插件内。 2、集群负载和任意资源调度的新 Placement API  ...

简介：突破”治理难“魔咒，知位停车来狙击！车场无人值守 所有停车出入记录集中管理 还有各类停车相干场景创新能力 …… 一大波停车场黑科技来袭 手握泛滥停车场的你，筹备好了吗？ 一套阿里云知位停车零碎就能帮你轻松治理 知位停车——打造“无人值守”场库解决方案，以轻设施、重云端的模式，为停车企业场库经营解决“经营难”、“治理难”、“免费难”等外围问题，提供降本增效的解决方案，同时，为车主提供自主进离场、便捷领取服务，提供良好的停车体验。 该智能停车零碎是阿里云联结智芯原动打造，利用阿里云AIoT技术和智芯原动当先行业的技术完满联合，通过阿里云AIoT停车服务引擎，应用了算法剖析能力、地图能力、领取能力等停车相干场景的创新能力。这不仅是停车形式的变更，更是停车场互联网的开始，帮忙停车经营企业从数字化向数智化转型。 咱们正在全国招募知位停车城市合伙人，欢送入群交换。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：在当下，由阿里云智能云原生利用平台团队发动， 政采云、谐云科技单干共建的 sealer 开源我的项目补充了 Kubernetes 在一体化交付畛域的短板，sealer 以十分优雅的设计方案思考了集群 + 分布式应用的整体交付。而政采云作为政府洽购行业的代表，已胜利的利用 sealer 实现了大型分布式应用的整体私有化交付，交付的实际充分证明了：sealer 具备灵便，弱小的一体化交付能力。作者 | 政采云 | 汪勋 近年来， 互联网极速倒退，为了跟进业务快速增长的倒退步调，新的技术如雨后春笋般一直的涌现，一眼望去，漫天星光，群星争艳。以容器为外围的云原生技术成长迅速，其中 Kubernetes 作为新的基础设施，容器编排事实上的规范， 无疑是最夺目的那颗星。 然而，Kubernetes 尽管很好的解决了大规模利用部署，资源管理及调度的问题，然而其对业务交付并不敌对，Kubernetes 本身的部署也比较复杂，在不断涌现的围绕 Kubernetes 生态的利用中， 始终短少了能够将业务、中间件、集群整合起来一体化交付的利用。 在当下，由阿里云智能云原生利用平台团队发动， 政采云、谐云科技单干共建的 sealer 开源我的项目补充了 Kubernetes 在一体化交付畛域的短板，sealer 以十分优雅的设计方案思考了集群 + 分布式应用的整体交付。而政采云作为政府洽购行业的代表，已胜利的利用 sealer 实现了大型分布式应用的整体私有化交付，交付的实际充分证明了：sealer 具备灵便，弱小的一体化交付能力。 背景政采云的私有化交付客户为政企场景，需交付业务规模较大：300+ 业务组件， 20+ 中间件，交付指标的基础设施不同构且不可控，网络限度严格，一些敏感的场景甚至是齐全隔离的网络，在这种背景下，业务交付的最大痛点就是部署依赖的解决以及交付一致性的问题。尽管业务对立基于 Kubernetes 进行交付实现了运行环境的统一，然而如何解决部署过程中所依赖的所有镜像、 各种包的对立解决以及交付零碎本身的一致性等一系列问题，亟需解决。 如上图所示政采云本地化交付的流程中， 次要分为：用户需要确认-> 提出资源需要给用户 -> 取得用户所提供的资源清单 -> 依据资源清单生成筹备配置 ->  筹备部署脚本及依赖 -> 理论交付六个步骤。前置筹备和理论交付时， 须要耗费大量的人力和工夫来筹备和进行部署。 私有化交付的痛云原生时代，docker 的呈现解决了单个利用的环境一致性和打包问题，业务的交付不再像传统的交付那样破费大量的工夫在部署环境依赖上。而后 Kubernetes 等容器编排零碎的呈现解决了对底层资源进行对立的调度，对利用运行时进行对立的编排的问题，然而一个简单的业务， 其交付的自身就是一个工程浩大的问题，以政采云的场景为例：各种 helm chart、RBAC， istio gateway，cni，中间件等各种资源对象的部署和配置，再加上 300 余业务组件的交付，每一次私有化交付带来的都是大量人力和工夫老本的耗费。 ...

简介：利用网关作为利用的对立接入层，它的倒退和演进也是随同着利用架构的变动，大家都晓得企业应用从最晚期 SOA 时代倒退到微服务的时代。在 SOA 时代，传统的企业服务总线承当了企业应用的对立接入层；然而倒退到微服务时代当前，微服务考究的就是单元化，业务的疾速迭代，服务的松耦合。传统的服务总线曾经不再适宜微服务的需要，因而微服务 APIGateway 慢慢倒退起来，例如大家相熟的 Zuul、Spring Cloud Gateway 等微服务网关。作者 | 子墚 百丈 背景介绍1. 利用网关的倒退历程利用网关作为利用的对立接入层，它的倒退和演进也是随同着利用架构的变动，大家都晓得企业应用从最晚期 SOA 时代倒退到微服务的时代。在 SOA 时代，传统的企业服务总线承当了企业应用的对立接入层；然而倒退到微服务时代当前，微服务考究的就是单元化，业务的疾速迭代，服务的松耦合。传统的服务总线曾经不再适宜微服务的需要，因而微服务 APIGateway 慢慢倒退起来，例如大家相熟的 Zuul、Spring Cloud Gateway 等微服务网关。 微服务进入容器化时代当前，K8s Ingress 成为了容器的接入层规范，代表产品为 Nginx；然而 Nginx 自身只是一个7层负载，无奈真正代替微服务网关的场景，例如 RPC 协定转换和注册核心的服务发现等微服务场景；往往咱们在 Ingress 上面还须要再部署一层微服务网关；然而减少了一层当前，咱们的资源老本、运维老本以及链路的耗时都减少了，因而进入云原生时代当前，咱们推出了 Ingress 和微服务网关二合一的云原生网关，既能满足利用场景，也能升高企业的老本和复杂度。 2. 云原生网关是什么云原生网关用一句话来概括就是：提供稳定性更高、老本更优、效率更高的合乎 K8s Ingress 以及微服务利用场景对立接入层。 3. 云原生网关的劣势老本：现有容器化时代下，微服务接入层从二层升高为一层，资源老本和运维老本升高50%。 集成：深度集成阿里云多款产品，例如日志、服务治理、链路追踪、压测、容器服务、EDAS、SAE 等，为客户提供一站式对立接入层解决方案。 性能：丰盛的服务治理能力（限流降级、金丝雀/标签路由、动静服务发现等）；多种平安防护能力（WAF/DDos、黑白名单、JWT/OAuth/第三方认证）；欠缺的可观测性指标（调用链、日志、监控大盘）。 牢靠：通过阿里外部零碎在双11大促的考验，堪称是百炼成钢，并且向咱们的客户承诺  99.95% 的 SLA。 产品具体介绍1. 性能架构云原生网关主打服务治理、接入平安、高可用、可观测性以及可扩展性的能力。 2. 技术架构 3. 利用场景网关作为利用的“大门”，既要保障南北向流量的对立接入，也要承当东西向流量的互通互联。 南北向：全渠道接入对接多种利用架构 东西向：混合云、多数据中心、多业务域互通 公测进行中目前云原生网关正在阿里云微服务引擎MSE中进行公测，欢送大家收费体验和试用！ 欢送退出产品钉钉交换群：34754806 理解更多产品详情：https://www.aliyun.com/product/aliware/mse ...

简介：“秒懂边缘云”是阿里云开发者社区 X 阿里云边缘云团队面向企业及集体开发者联结打造系列直播，围绕边缘云的行业发展趋势、产品定义、利用场景，并联合阿里云边缘云深入浅出解说，让宽广技术人员从入门到进阶理解边缘云。“秒懂边缘云”是阿里云开发者社区 X 阿里云边缘云团队面向企业及集体开发者联结打造系列直播，围绕边缘云的行业发展趋势、产品定义、利用场景，并联合阿里云边缘云深入浅出解说，让宽广技术人员从入门到进阶理解边缘云。 从9月8号到9月22日，每周三下午16:00-17:00线上直播分享。第一期讲师是鸠舍，他将率领大家疾速理解边缘云趋势、产品、劣势和利用。 嘉宾介绍： 鸠舍是阿里云智能边缘云高级产品专家，6年通信零碎研发及零碎计划教训，近10年云计算产品布局和架构教训。作为核心成员曾深度参加并主导过三个以上私有云平台的落地和研发工作。曾负责SODA社区中国区外联负责人，开源我的项目YIG初创核心成员。目前次要负责阿里云边缘节点的产品布局和设计工作。 演讲介绍：分布式云是2021年寰球十大重要策略科技趋势，边缘云做为分布式云的重要状态具备很强的分布式属性和边缘部署属性，本次解说将率领大家揭开边缘云的神秘面纱，通过简略易懂的形式理解边缘云的发展趋势，相熟边缘云的状态和个性，把握边缘云的产品及技术架构，并通过场景化带入形式领会边缘云的生态价值。 如果您也想理解一下边缘云，连忙点击链接，一起理解一下边缘云吧！ https://developer.aliyun.com/topic/edge/lives?utm\_content=g\_1000291841 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Fluid 是 CNCF 基金会旗下云原生环境中数据密集型利用的高效撑持平台，由南京大学、阿里云云原生团队以及 Alluxio 开源社区联结发动。我的项目自开源公布以来吸引了泛滥相干方向领域专家和工程师的关注，在大家的踊跃反馈下社区一直演进。近期 Fluid 0.6 版本正式公布，在该版本中，Fluid 次要新增改善三个方面的内容。作者 | 顾荣  Fluid开源社区主席  南京大学PASALab Fluid 是 CNCF 基金会旗下云原生环境中数据密集型利用的高效撑持平台，由南京大学、阿里云云原生团队以及 Alluxio 开源社区联结发动。我的项目自开源公布以来吸引了泛滥相干方向领域专家和工程师的关注，在大家的踊跃反馈下社区一直演进。近期 Fluid 0.6 版本正式公布，在该版本中，Fluid 次要新增改善以下三个方面内容： 数据感知的Pod调度，反对数据与利用协同调度，增强生态交融, 适配更多开源调度器。丰盛数据集操作性能，反对数据集主动弹性扩缩容、挂载点动静更新。缓存引擎新增与加强，反对缓存引擎高可用并新增私有云缓存引擎。Fluid 开源我的项目地址：https://github.com/fluid-cloudnative/fluid Fluid 我的项目全新官网：https://fluid-cloudnative.github.io/ 这三大次要性能的开发需要来自泛滥社区用户的理论生产反馈，此外 Fluid v0.6 还进行了一些 bug 修复和文档更新，欢送应用体验 Fluid v0.6！ Fluid v0.6 下载链接：https://github.com/fluid-cloudnative/fluid/releases 下文是本次新版本公布性能的进一步介绍。 数据感知到 Pod 调度优化Fluid 始终致力于利用云原生资源调度能力满足云上数据密集利用高效运行的需要。在上个版本 Fluid v0.5 中，咱们曾经针对数据集编排不足架构感知的问题，在数据集编排调度方面进行了一系列优化。在 Fluid v0.6 中，咱们进一步针对容器编排不足数据感知的问题，设计实现了对 Pod 调度的优化。 咱们目前思考到的优化场景问题包含： 应用非 K8s 原生调度器时，不能与 Fluid 很好的兼容应用数据集的 Pod 调度时，短少思考缓存散布思考不应用数据集的 Pod，可能调度到有缓存的节点，影响其它 Pod 应用缓存咱们依据数据集缓存地位信息制订 Pod 调度策略，通过 webhook 机制将生成的调度信息注入到 Pod，最终实现了以下性能： ...

简介：2021 阿里云开发者大会，阿里云基于阿里云云原生产品技术架构倒退布局，全新公布阿里云云原生助理工程师认证。新认证明确、残缺定义了云原生人才所需技能及专业知识，定义了行业云原生人才的考量规范，也是阿里巴巴云原生产品（容器、微服务等）相干体系认证打算的统领框架。2021 阿里云开发者大会，阿里云基于阿里云云原生产品技术架构倒退布局，全新公布阿里云云原生助理工程师认证。新认证明确、残缺定义了云原生人才所需技能及专业知识，定义了行业云原生人才的考量规范，也是阿里巴巴云原生产品（容器、微服务等）相干体系认证打算的统领框架。 阿里云认证100 万人参加认证学习，20 万人取得认证证书5 年的精心打磨，140 门认证课程为泛云从业者开拓了一条热门的进阶之路 阿里云认证四大方向。阿里云最新公布的技术产品认证次要输入阿里云产品关键技术，助力理解技术利用场景，并且可能在业务零碎中灵活运用，解决理论问题。阿里云技术产品认证，次要分为计算、数据智能、产业智能和挪动协同四大方向。 计算：帮忙晋升用户对于云的理解，同时把握搬站上云，解决云上平安问题以及利用云原生架构更便捷的应用云资源。数据智能：在数据全链路场景提供认证，让用户更好的理解和把握阿里云数据相干的产品技术，升高企业开发和利用老本，用低代码的形式解决业务问题。产业智能：产业生态日益丰盛，须要泛云生态人才既懂技术，又懂行业。因而，阿里云提供基于理论行业场景的培训认证，帮忙学员晋升对于行业，对于业务的了解。挪动协同：应用数字化驱动企业外部的办公，晋升用户低代码开发和翻新的能力，实现在线化、数字化、智能化，随时随地协同，让组织更加麻利。阿里云认证三大进阶。针对不同产品类别、用户成长阶段、生态岗位，阿里云精心打造不同的认证考试，依照进阶路线分为 ACA、ACP 和 ACE 三个层级，别离代表具备高级、高级以及专家级别的云产品业余技术水平。 助理工程师 ACA：证实您理解阿里云产品和技术的利用场景，能够基于阿里云产品在对应的技术方向上解决企业的根本业务问题。高级工程师ACP：证实您把握阿里云产品关键技术（架构/个性/性能/运维）并纯熟应用，能够作为合作伙伴或专业人才进行阿里云相干我的项目的开发交付。高级专家 ACE：证实您具备在零碎架构中灵活运用阿里云产品，解决业务问题的能力，实用于技术实际及工作经验丰富的业余畛域人才。阿里云云原生助理工程师认证阿里云云原生助理工程师认证为全新设计开发的面向云原生相干通用技术及阿里云云原生体系产品的根底认证，为整个云原生认证的通用底座，能够作为 ACP/ACE 认证的根底认证，次要蕴含：云原生技术&架构根底、容器、微服务、 DevOps 等考核要点。 该认证面向学生群体、销售等非技术类人群以及开发者&运维人员等对云原生有学习认证需要的人员，取得此认证可证实您把握了云原生的根底理念、阿里云云原生外围产品根底的性能和利用的能力，能够在阿里云生态取得更好的就业机会。  通过该技术认证能够无效证实该认证人员具备以下能力： 具备云原生畛域相干的从业基础知识，理解云原生的核心理念；了解云原生的概念，相熟云原生的倒退、特点，理解云原生技术和架构的呈现和利用所产生的影响； 相熟常见的云原生技术，对容器、微服务、DevOps 等重要云原生技术有比拟深刻的了解； 相熟阿里云云原生产品大图，初步具备通过阿里云云原生外围产品帮忙企业设计云原生根底框架的能力；阿里云全新认证重磅上线 3折钜惠首发全新认证上线之际，限时推出 3 折购买认证权利！ 【流动工夫】 2021.8.10-2021.9.10 【流动内容】限时享3折购买阿里云云原生 ACA 认证、数据库 ACA 认证权利。 【优惠路径】应用PC端登录本次流动页面，同时钉钉扫描下方二维码进入官网福利群 https://edu.aliyun.com/promotion/436 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：2021 EdgeX中国挑战赛自7月12日揭幕以来，失去各方积极响应，初赛作品提交通道已于8月10日顺利敞开。作者 | EF中国项目组 2021 EdgeX中国挑战赛自7月12日揭幕以来，失去各方积极响应，初赛作品提交通道已于8月10日顺利敞开。 本次大赛共收到 80 支队伍报名，55 份提交作品，相比 2020 年有近 50% 的晋升。本次大赛的参赛队背景多样性很强，既包含像研华、新华三、网易、中兴通讯、京东、中科创达、正泰电器等物联网头部企业，也包含江行智能、南京将来物联 等初创公司，以及来自南洋理工大学、中国科技大学、北方科技大学、常州工学院 等高校的老师和学生。随着 EdgeX Foundry 影响力的扩充，往年 EdgeX  挑战赛的覆盖范围也大为拓宽，已由中国大陆延长到了中国台湾、新加坡。EdgeX 中国挑战赛已成为辐射华语区的寰球 EdgeX 黑客松赛事。 与去年相比，往年参赛作品涵盖更为宽泛的行业，包含批发、工业、物流、商业和医疗，为 EdgeX 的利用部署拓广了新的空间。在已提交的参赛作品中，有 27 份作品应用了人工智能工具套件 OpenVINO，8 份作品应用了百度云边协同计划 Baetyl，12 份应用了 工业互联网开源软件组件-边缘洞见平台，9 份作品波及 5G & Robotics。这些组件与 EdgeX 联合起来，可实现端到端的解决方案，极大晋升了计划的完整性。 通过赛事组委会初步筛选，有 35 支参赛队伍进入下一轮。 他们别离是： 2021 EdgeX 中国挑战赛分为初赛、决赛两个轮次。初赛阶段，所有参赛队需提交一份创意构想文件，形容 EdgeX 的技术框架如何与业务需要相结合、构建行业计划。组委初选出 35 个作品，入围决赛。决赛阶段，每个参赛队须现场编制代码、展现 demo、路演问难。参赛队伍最终评分，将由评委打分、社交媒体投票得分两局部组成，依分数高下排定名次，确定奖项。 值得一提的是，咱们非常荣幸阿里云能成为往年 EdgeX 中国挑战赛新的赞助商，独特助力本赛事顺利举办。  .png") 对于 2021 EdgeX 中国挑战赛2021 EdgeX 中国挑战赛由 Linux 基金会、上海市科委、北京市科委、中关村管委会等单位联结主办，阿里云、百度云、紫竹 ET、EMQ 映云科技、英特尔、 InnoSpace、IOTech、中科创达、Ubuntu、VMware 威睿等单位联结承办的利用 EdgeX 解决行业问题的编程大赛。本大赛将在上海、北京、深圳三地同步开展。 赛事官网网址：https://edgexchallenge.shanghaimakers.com/   工夫线 如何退出 EdgeX 中文社区EdgeX Foundry中文网站:  https://cn.edgexfoundry.org/ OSChina: https://www.oschina.net/group/edgex-foundry ...

简介：阿里云高级技术专家王烨(萌豆)在Apache Hudi 与 Apache Pulsar 联结 Meetup 杭州站上的演讲整顿稿件，本议题介绍了阿里云如何应用 Hudi 和 OSS 对象存储构建 Lakehouse，为大家分享了什么是 Lakehouse，阿里云数据库 OLAP 团队如何构建 Lakehouse，也介绍了在构建 Lakehouse 时遇到的问题和挑战，以及如何解决这些问题和挑战。本文PPT下载链接： 王烨(萌豆)-阿里云高级技术专家 -《阿里云基于Hudi构建Lakehouse实际》.pdf 其余干货： 李少锋(风泽) - 阿里云技术专家-《基于Apache Hudi的CDC数据入湖》.pdf 翟佳-StreamNative 联结创始人、Apache Pulsar PMC 成员-《Pulsar 2.8.0 性能个性概述及布局》.pdf 盛宇帆-StreamNative 软件工程师-《基于 Flink 的全新 Pulsar Connector 的设计、开发和应用》.pdf 一、数据湖与Lakehouse2021年开发者大会上，咱们的一位研究员分享的一个议题，提到了很多数据，次要想论述的是行业倒退到当初这个阶段，数据的收缩十分厉害，数据增速十分可怕。无论是数据规模还是生产解决的实时化，到生产解决的智能化，以及数据减速上云的云化过程。 这些数据来自Gartner、IDC的剖析，都是行业最权威的剖析报告里积淀总结进去的。这就意味着咱们在数据畛域尤其是剖析畛域的时机和挑战都很大。 在海量的数据上，咱们要真正做好数据价值的开掘和应用会面临很多挑战，第一是现有的架构缓缓都要往云上架构迁徙；第二个是数据量；第三个是Serverless按量付费，缓缓从尝试性的抉择成为默认抉择；第四是还有多样化的利用、异构数据源。置信大家接触过云都晓得，无论是哪个云厂商都有很多种云服务可供，尤其是数据类服务数量繁多。这时候，大量数据源肯定会带来一个问题：剖析难度大，尤其是想做关联剖析的时候，异构数据源怎么连接起来是很大的问题。其次是差异化的数据格式，通常咱们做数据写入会时抉择不便、简略的格局，比方CSV、Json格局，但对剖析来讲，这些格局往往是十分低效的，尤其是数据到了TB、PB级的时候，基本没法剖析。这时候Parquet、ORC等面向剖析的列存格局就衍生进去了。当然还包含链路平安以及差异化群体等等，数据量收缩的过程中又减少了很多的剖析难度。 在实在的客户场景里，很多数据曾经上云了和“入湖”了。湖是什么？咱们对湖的定义和了解更像AWS的S3或者阿里云OSS这种对象存储，是简略易用的API模式，能够存各种各样差异化的数据格式，有有限的容量、按量付费等十分多的益处。之前想基于湖做剖析十分麻烦，很多时候要做T+1的建仓和各种云服务投递。有时候数据格式不对就要人肉做ETL，如果数据曾经在湖里要做元信息发现剖析等等，整个运维链路很简单，问题也很多。这里都是线上客户理论面临的离线数据湖问题，有些优先级偏高，有些低些，总而言之问题十分多。 其实Databricks大略19年就开始将钻研重点从Spark方向，缓缓往Lakehouse方向调整了。他们发表了两篇论文，这两篇论文为数据湖怎么被对立拜访、怎么被更好地拜访提供了实践层面的定义。 基于Lakehouse的新概念，想做到的是屏蔽格局上的各种差别，为不同的利用提供对立的接口以及更加简化的数据拜访、数据分析能力。架构说实现数据仓、数据湖、Lakehouse一步步演进。 他的两篇论文论述了很多新概念：第一，怎么设计和实现MVCC，能让离线数仓也有像数据库一样的MVCC能力，从而满足大部分对批事务的需要；第二，提供不同的存储模式，可能适应不同的读和写Workload；第三，提供一些近实时的写入和合并能力，为数据量提供链路能力。总之，他的思路可能较好解决离线数据分析的难题。 目前业界有三款产品绝对比拟风行，第一个是Delta Lake，它是Databricks本人公布的数据湖治理协定；第二个是Iceberg，Iceberg也是Apache的一个开源我的项目；第三个是Hudi，Hudi最早由Uber外部研发，起初开源的我的项目（晚期用得比拟多的是Hive的ACID）。目前这三个产品因为能够对接HDFS的API，能够适配底层的湖存储，而OSS又能够适配到HDFS存储接口。因为外围原理类似，三个产品各方面的能力都在逐步凑近，同时有了论文做实践撑持，咱们才会有方向去实际。 对咱们来说，过后抉择Hudi也是因为其产品成熟度方面的起因，还有它面向数据库方面的数据入湖能力，状态上比拟满足咱们在数据库团队做CDC方面的业务需要。 Hudi晚期的定义是Hadoop Updates anD Incrementals的缩写，前面是面向Hadoop的Update、Delete、Insert的概念，外围逻辑是事务版本化、状态机管制和异步化执行，模仿整个MVCC的逻辑，提供对于外部列存文件比方Parquet、ORC等对象列表的增量式治理，实现高效的存储读写。它和Databricks定义的Lakehouse概念很类似，不约而同，Iceberg也是一样，它的能力也在逐渐往这个方向晋升。 Hudi官方网站对外提供的架构是这样的状态。之前咱们做技术选型、调研的时候发现很多同行也曾经充沛应用Hudi做数据入湖和离线数据管理的计划选型。第一，因为产品比拟成熟；第二，它合乎咱们CDC的需要；第三，Delta Lake有一套开源版本，一套外部优化版本，对外只提供开源版本，咱们认为它不肯定把最好的货色出现。Iceberg起步比拟晚，晚期相比其余两个产品能力不太齐全，所以没有思考它。因为咱们都是Java团队，也有本人的Spark产品，Hudi正好比拟符合咱们用本人的runtime反对数据入湖的能力，因而也就抉择了Hudi。 当然咱们也始终在关注这三个产品的倒退，起初国内的一个开源我的项目StarLake，也是做相似的事件。每种产品都在提高，长期来看能力根本对齐，我感觉会和论文里定义的能力缓缓吻合。 “以开源Hudi为列式、多版本格局为根底，将异构数据源增量、低提早入湖，存储在凋谢、低成本的对象存储上，并且在这个过程中要实现数据布局优化、元信息进化的能力，最终实现离线数据对立治理，无差别反对下面的计算和剖析能力，这是整体的计划。”这是咱们对Lakehouse的了解，以及咱们的技术摸索方向。 二、阿里云Lakehouse实际上面介绍一下阿里云Lakehouse的技术摸索和具体的实际。首先，大略介绍一下阿里云数据库团队近年来始终提的概念“数据库、仓、湖一体化”策略。 大家都晓得数据库产品分为四个档次：一是DB；二是NewSQL/NoSQL产品；三是数仓产品；四是湖数据产品。越往上数据的价值密度越大，会以元表元仓模式的数据关联到剖析中去，比方DB数据格式非常简单、清晰； 越往下数据量越来越宏大，数据模式越来越简单，有各种各样的存储格局，数据湖模式有结构化、半结构化、非结构化，要剖析就必须要做肯定的提炼、开掘，能力真正把数据价值用起来。 四个存储方向有各自的畛域，同时又有关联剖析诉求，次要就是要突破数据孤岛，让数据一体化，能力让价值更立体化。如果只是做一些日志剖析，例如关联的地区、客户起源的话，也只是应用了GroupBy或者是Count等绝对简略的剖析能力。对于底层数据，可能要做屡次荡涤、回流，能力往向在线化、高并发的场景一层层剖析。这里不仅仅间接将数据从湖到库写入，也能够到仓，到NoSQL/NewSQL的产品里，到KV零碎里去，利用好在线化的查问能力，等等。 反过来也是一样，这些数据库/NewSQL产品甚至数仓中的数据也会向下流动，构建低成本、大容量的存储备份、归档，升高下面的存储压力、剖析吞吐压力，且能够造成弱小的联结剖析能力。这也是我本人对数据库、仓、湖一体化的了解。 ...

简介：阿里云技术专家李少锋(风泽)在Apache Hudi 与 Apache Pulsar 联结 Meetup 杭州站上的演讲整顿稿件，本议题将介绍典型 CDC 入湖场景，以及如何应用 Pulsar/Hudi 来构建数据湖，同时将会分享 Hudi 内核设计、新愿景以及社区最新动静。本文PPT下载链接： 李少锋(风泽) - 阿里云技术专家-《基于Apache Hudi的CDC数据入湖》.pdf  其余干货： 王烨(萌豆)-阿里云高级技术专家 -《阿里云基于Hudi构建Lakehouse实际》.pdf  翟佳-StreamNative 联结创始人、Apache Pulsar PMC 成员-《Pulsar 2.8.0 性能个性概述及布局》.pdf 盛宇帆-StreamNative 软件工程师-《基于 Flink 的全新 Pulsar Connector 的设计、开发和应用》.pdf  一、CDC背景介绍首先咱们介绍什么是CDC？CDC的全称是Change data Capture，即变更数据捕捉，它是数据库畛域十分常见的技术，次要用于捕捉数据库的一些变更，而后能够把变更数据发送到上游。它的利用比拟广，能够做一些数据同步、数据散发和数据采集，还能够做ETL，明天次要分享的也是把DB数据通过CDC的形式ETL到数据湖。 对于CDC，业界次要有两种类型：一是基于查问的，客户端会通过SQL形式查问源库表变更数据，而后对外发送。二是基于日志，这也是业界宽泛应用的一种形式，个别是通过binlog形式，变更的记录会写入binlog，解析binlog后会写入音讯零碎，或间接基于Flink CDC进行解决。 它们两者是有区别的，基于查问比较简单，是入侵性的，而基于日志是非侵入性，对数据源没有影响，但binlog的解析比较复杂一些。 基于查问和基于日志，别离有四种实现技术，有基于工夫戳、基于触发器和快照，还有基于日志的，这是实现CDC的技术，上面是几种形式的比照。 通过这个表格比照能够发现基于日志的综合最优，但解析比较复杂，但业界有很多开源的binlog的解析器，比拟通用和风行的有Debezium、Canal，以及Maxwell。基于这些binlog解析器就能够构建ETL管道。 上面来看下业界比拟风行的一种CDC入仓架构。 整个数据入仓是分实时流是离线流，实时流解析binlog，通过Canal解析binlog，而后写入Kafka，而后每个小时会把Kafka数据同步到Hive中；另外就是离线流，离线流须要对同步到Hive的贴源层的表进行拉取一次全量，如果只有后面的实时流是数据是不全的，必须通过离线流的SQL Select把全量导入一次数据，对每张ODS表会把存量数据和增量数据做一个Merge。这里能够看到对于ODS层的实时性不够，存在小时、天级别的提早。而对ODS层这个延时能够通过引入Apache Hudi做到分钟级。 二、CDC数据入湖办法基于CDC数据的入湖，这个架构非常简单。上游各种各样的数据源，比方DB的变更数据、事件流，以及各种内部数据源，都能够通过变更流的形式写入表中，再进行内部的查问剖析，整个架构非常简单。 架构尽管简略，但还是面临很多挑战。以Apache Hudi数据湖为例，数据湖是通过文件存储各种各样的数据， 对于CDC的数据处理须要对湖里某局部文件进行牢靠地、事务性变更，这样能够保障上游查问不会看到局部后果，另外对CDC数据须要高效的做更新、删除操作，这就须要疾速定位到更改的文件，另外是对于每小批量的数据写入，心愿可能主动解决小文件，防止繁冗的小文件解决，还有面向查问的布局优化，能够通过一些技术手段如Clustering革新文件布局，对外提供更好的查问性能。 而Apache Hudi是怎么应答这些挑战的呢？首先反对事务性写入，包含读写之间的MVCC机制保障写不影响读，也能够管制事务及并发保障，对于并发写采纳OCC乐观锁机制，对更新删除，内置一些索引及自定义保障更新、删除比拟高效。另外是面向查问优化，Hudi外部会主动做小文件的治理，文件会主动长到用户指定的文件大小，如128M，这对Hudi来说也是比拟外围的个性。另外Hudi提供了Clustering来优化文件布局的性能。 下图是典型CDC入湖的链路。下面的链路是大部分公司采取的链路，后面CDC的数据先通过CDC工具导入Kafka或者Pulsar，再通过Flink或者是Spark流式生产写到Hudi里。第二个架构是通过Flink CDC直联到MySQL上游数据源，间接写到上游Hudi表。 其实，这两条链路各有优缺点。第一个链路对立数据总线，扩展性和容错性都很好。对于第二条链路，扩展性和容错性会略微差点，但因为组件较少，保护老本相应较低。 这是阿里云数据库OLAP团队的CDC入湖链路，因为咱们咱们做Spark的团队，所以咱们采纳的Spark Streaming链路入湖。整个入湖链路也分为两个局部：首先有一个全量同步作业，会通过Spark做一次全量数据拉取，这里如果有从库能够直连从库做一次全量同步，防止对主库的影响，而后写到Hudi。而后会启动一个增量作业，增量作业通过Spark生产阿里云DTS里的binlog数据来将binlog准实时同步至Hudi表。全量和增量作业的编排借助了Lakehouse的作业主动编排能力，协调全量和增量作业，而对于全量和增量连接时利用Hudi的Upsert语义保障全增量数据的最终的一致性，不会呈现数据偏多和偏少的问题。 在Lakehouse的CDC入湖链路中，咱们团队也做了一些优化。 ...

简介：AnalyticDB For MySQL为用户提供了高效、实时、功能丰富并且智能化的「SQL智能诊断」和「SQL智能调优」性能，提供用户SQL性能调优的思路、方向和具体的办法，升高用户应用老本，进步用户应用ADB的效率SQL是一种简略易用的业务逻辑表白语言，但随着扫描数据量和查问复杂度的减少，查问性能会变得越来越慢。想要对SQL进行调优，往往须要关注以下几个局部： 须要理解引擎架构：用户往往须要对SQL引擎的架构特点有肯定的理解，能力和业务的数据分布特色以及业务场景特色完满联合，来进行数据建模，从而设计出合乎SQL引擎架构特点的表构造。SQL特色差别较大：即席查问的SQL往往变动较大，包含参加Join的表个数、Join条件、分组聚合的字段个数以及过滤条件等。数据特色差别较大：用户的数据分布特色是会随着业务特色的变动而变动的，如果始终依照最后的建模形式和SQL语句，也是无奈保障能施展出SQL引擎的最大劣势，数据特色或者业务模型的变动，都会导致SQL性能回退。基于此，AnalyticDB For MySQL（新一代云原生实时数据仓库，语法兼容MySQL，以下简称ADB）为用户提供了高效、实时、功能丰富并且智能化的「SQL智能诊断」和「SQL智能调优」性能，提供用户SQL性能调优的思路、方向和具体的办法，升高用户应用老本，进步用户应用ADB的效率。 上面咱们通过「发现慢查问」+「诊断慢查问」两个步骤，并联合一个场景Case，来介绍ADB新公布的「SQL智能诊断」性能。（PS：「SQL智能调优」会在后续版本中公布） 一、发现慢查问用户要定位慢查问，首先须要找到慢查问。ADB的用户控制台提供了多样的形式来帮忙用户，例如「甘特图」和「查问列表」等，都能够在多个维度进行检索，帮忙用户疾速定位慢查问，而且诊断工具确保用户能够进行最近两周的全量查问检索和剖析。 （一）甘特图用户能够通过「集群控制台」-「诊断与优化」 - 「SQL诊断」进入SQL智能诊断性能。 首先会看到一个甘特图（也称泳道图，查问从不同的泳道流过，这里的泳道并不是ADB的查问队列，只是为了辨别开不同工夫执行的查问），甘特图以图形化的形式形象的展现了查问在ADB实例上的执行程序，每个色块示意了一条查问，色块左侧为查问的提交工夫，色块右侧为查问的完结工夫，色块的绝对长度示意了某条查问的执行工夫，色块的色彩没有非凡含意，只是为了辨别不同的泳道。 通过甘特图，用户能够十分直观的看到以后工夫范畴内执行耗时较长的查问，并且能够直观的看到哪些查问是在并行的执行以及并行执行的时间段，这能够帮忙用户判断出哪些查问是受到了某条Bad SQL的影响。色块的密集度则能够用来直观的判断ADB实例压力较大的时段是否和某些查问的并发度较高相干。 （二）查问列表甘特图可能以直观的形式体现出查问之间的工夫相关性，然而当用户抉择的工夫范畴较大，甘特图中的色块会密集散布不容易分辨，而且甘特图上的指标较为无限，此时用户能够应用诊断工具中的查问列表性能。查问列表提供了多大10余项查问级别的重要指标，例如数据库名、用户名、客户端段IP、耗时、耗费内存以及扫描量等，这些信息和指标能够帮忙用户进一步判断慢查问的起源和资源耗费等。 高级检索能力方面，诊断工具提供了三种类型的检索办法： 1.含糊检索和准确检索：用户能够依据SQL中的关键字进行含糊匹配，准确检索性能则帮忙用户在确定查问ID的状况下，准确的检索到这条查问； 2.字符串类型的检索条件：检索工具会自动识别出用户所选工夫范畴内应用的数据名、用户名、客户端IP以及资源组等，提供下拉框的模式供用户抉择，进步用户检索效率； 3.数值类型的检索条件：用户能够自由选择检索的指标单位，例如KB、MB、GB等，不须要进行手动的换算。 同时，用户在应用诊断工具时，往往有对慢查问的下载需要，下载后的慢查问能够在例如Excel等工具中进行更多自定义的慢查问治理和剖析，所以咱们也提供了查问列表的下载性能。 二、诊断慢查问（一）查问在ADB中的执行流程在介绍ADB执行流程前须要简略介绍一下三个相干的基本概念： Stage在执行阶段，ADB中的查问会首先依据是否产生Shuffle被切分为多个Stage来执行，一个Stage就是执行打算中某一部分的物理实体。Stage的数据起源能够是底层存储系统中的数据或者网络中传输的数据，一个Stage由散布在不同计算节点上雷同类型的Task组成，多个Task会并行处理数据。 TaskTask是一个Stage在某个Executor节点上的执行实体，多个同类型的Task组成一个Stage，在集群外部并行处理数据。 OperatorOperator（算子）是ADB的最小数据处理单元。ADB会依据算子所表白的语义或算子间的依赖关系，决定应用并行还是串行执行来解决数据。 上面以一个典型的分局聚合查问为例来理解ADB中查问的执行流程，SQL语句如下： SELECT COUNT(*), SUM(salary) FROM emplayee WHERE age>30 ADN age<32 GROUP BY sex 在ADB外部，首先由前端的Controller节点接管SQL语句申请，并对SQL语句进行语句解析和语法分析（Parser），最初应用优化器（Optimizer）生成最终的执行打算，整体执行打算会依据Stage的划分准则被切分为子打算，如图中的Plan0、Plan1和Plan2，别离被下发到对应的节点上。 其中子打算Plan2会并行的在4个计算节点上以Task实例的模式解决数据，首先执行数据的扫描和过滤，而后执行数据的部分聚合，解决完之后的数据会依据sex字段Repartition到上游的计算节点，即Stage1的节点，依照子打算Plan1的要求执行数据的最终聚合。最初，数据由Stage0的节点汇总并返回到客户端。 和典型的数据仓库一样，ADB的执行打算个别分为「逻辑执行打算」和「物理执行打算」： 逻辑执行打算：宏观层面理解查问的解决流程逻辑执行打算在较高的层面展现查问的解决逻辑，基于规定的执行打算（RBO）会判断过滤条件是否能够下推，而基于代价的执行打算（CBO）会判断出多表关联时的程序等。所以逻辑执行打算并不关注在物理执行时的具体解决形式，例如是否在执行时须要对多个算子进行交融以缩小函数调用，或者主动生成代码的粒度，这些逻辑执行打算并不关注，这也就导致了逻辑执行打算往往只蕴含了Stage级别的执行统计信息。然而用户调优时往往是须要准确到算子级别的统计信息。 物理执行打算：宏观层面理解每个算子的解决性能绝对于逻辑执行打算，物理执行打算蕴含了算子间的数据处理流图，也蕴含了算子的执行统计信息，能够准确的看到某个Join算子或者聚合算子占用的内存，也能够看到过滤算子过滤前后的数据量。然而并不是所有的算子用户都须要能正确理解其含意，特地是有些物理算子和用户的SQL语句找不到关联之处，这也会给用户独自应用物理执行打算定位问题带来较大的纳闷。 ADB的「SQL智能诊断」性能，提供给了用户一个逻辑执行打算和物理执行打算的交融视图，用户应用交融的执行打算即能够从宏观层面理解查问的解决流程，也能够从宏观层面理解每个算子的解决性能，从而能够更加精确疾速的帮忙用户定位查问的性能瓶颈点。 （二）SQL自诊断性能尽管咱们提供了交融的和分层的执行打算来帮忙用户剖析查问的性能问题，然而咱们发现在两类场景中用户应用交融执行打算会遇到困难： ADB的高级使用者ADB为了缩小MySQL用户的学习和迁徙老本，做到了绝大多数语法和MySQL兼容，然而ADB的后盾并非MySQL内核，而是独立自研的一套分布式数据存储和分布式计算零碎，面对ADB的执行打算，ADB的高级使用者往往不晓得优化的重点在哪里，无从下手。 ADB中的简单SQL对于简单的SQL，往往波及几百张表的连贯操作，Stage个数会达到几百个以上，算子个数更是会达到上千，执行打算图十分大，即便是ADB的高级使用者，面对这样简单的执行打算，往往也无从下手，如下图是个196个Stage的执行打算图： 针对以上问题，咱们在执行打算图中退出了SQL自诊断能力，SQL自诊断能力会将专家教训以规定的模式体现在执行打算中，对于ADB的首次接触者，即能够依据诊断后果确定查问执行过程中的性能瓶颈点，也能够依据诊断后果学习到ADB执行打算中须要关注的重点算子。针对简单执行打算，SQL自诊断能够帮忙用户疾速定位到执行打算中须要调优的地位，并提供了调优的相干办法和文档，让用户在调优过程中更有针对性。 SQL自诊断能力通过「Query级别诊断后果」、「Stage级别诊断后果」、「算子级别诊断后果」这三层来展现诊断后果和优化倡议。 咱们以一个线上的简单SQL为例来介绍应用执行打算和SQL自诊断工具来进行性能问题定位的例子。首先咱们通过慢查问检索工具搜寻到一个内存耗费较大的查问，点击「诊断」关上该查问的诊断页面，切换到「执行打算」页签，咱们会看到查问级别诊断后果曾经判断出以后查问数据一个内存耗费较大的查问，如下图中的1所示：         这时，咱们须要定位内存成果较大的起因，咱们点击按内存排序，能够看到在右侧，会依据Stage耗费的内存百分比进行了顺叙排序，能够非常明显的看出，Stage[1]占用的以后查问87%以上的内存比例，咱们点击Stage[1]，诊断工具会主动聚焦到执行打算树的Stage[1]的地位，点击Stage[1]，咱们能够看到Stage[1]的执行统计信息，同时，咱们能够看到在5的地位，提醒咱们以后Stage1外部有个算子占用内存较大，然而并没有详细信息，所以接下来，咱们须要进入到Stage[1]的外部，看看Stage[1]具体是哪个算子占用了较多内存。 点击「查看Stage执行打算」，进入到Stage[1]外部，首先，咱们仍然依据内存排序，能够看到，其中的Join[317]这个算子占用了整个Stage 99%以上的内存，点击该算子，算子执行打算树主动定位到以后算子，这时咱们就能够看到算子诊断后果的详细信息了，信息提醒咱们，在构建Hash表用户Left Join时，占用了较大的内存，诊断后果还提供了官网的调优文档链接，依据文档中给出的调优办法，咱们就能够缩小该算子的内存占用。  以上的例子通过「查问级别诊断后果」和「算子级别诊断后果」进行SQL性能问题定位的办法，咱们再来看一个「Stage级别诊断后果」的例子。 如下图所示，咱们能够看到依据耗时排序后，Stage[10]的耗时比例最大，点击执行打算图中的Stage[10]，能够在诊断后果栏看到两类诊断后果，一类是“Stage诊断”，一类是“算子诊断”，其中的Stage诊断通知咱们以后Stage的输入数据有歪斜，并且通知咱们歪斜的字段是哪些（数据歪斜是分布式系统中重大影响性能的问题，Stage输入数据歪斜岂但会过后以后Stage解决数据在工夫上存在长尾，而且会导致上游的数据处理存在长尾），同时能够看到有一个算子诊断后果，提醒咱们表扫描存在歪斜，那么咱们能够初步判断以后Stage输入数据歪斜是因为扫描了一个数据歪斜的表导致的。接下来咱们进入到Stage[0]外部进行定位和剖析。  进入到Stage内存，咱们依据耗时排序，能够看到TableScan算子耗时最大，这时咱们点击TableScan算子，能够看到在诊断后果里，有对于该表数据歪斜的具体诊断后果信息，这张表因为数据分布字段抉择的不适合，存在重大的数据歪斜问题，同时能够看到有相干的官网调优文档，咱们依据调优文档，就能够调整为适合的散布字段，缩小表数据歪斜对查问性能的影响。  通过以上的两个例子，咱们能够看到，交融执行打算和SQL自诊断性能，能够疾速的帮咱们定位到查问的性能问题，并给出肯定的调优倡议，缩小大量不必要的工夫和精力的节约，升高了高级使用者应用ADB的门槛。对于SQL自诊断更多的诊断后果能够参考官网文档：SQL自诊断，目前曾经有20+诊断规定上线，波及查问相干的内存耗费、耗时、数据歪斜、磁盘IO以及执行打算等多个方面，后续还有更多诊断规定陆续上线。 三、 后续布局通过以上的论述和例子剖析，能够看到以后的诊断调优工具曾经能够帮忙用户进行多方面的SQL性能问题排查，然而咱们在理论的线上问题解决和值班时依然发现总结了多个用户在剖析实例性能问题时的需要： 我应该调优哪些SQL？用户在关上诊断调优页面时，面对实例上运行的上万甚至上千万条SQL，尽管能够通过耗时、内存耗费或者扫描量等进行排序来初步筛选出须要调优的SQL，然而其实其实用户欠缺了一个特定诊断后果的视角，例如： ...

简介：图数据库GDB提供智能搜寻举荐一站式服务，基于达摩院的智能搜寻举荐算法和常识图谱技术，助力企业疾速过渡冷启动过程，面向业务场景定制化计划，以晋升外围业务指标，实现业务营收增长。计划架构 计划特点智能算法解决数据偏差和趣味迁徙挑战通过智能算法解决因为商品曝光、用户的抉择偏差和从众心理等因素造成的数据缺失、数据偏差问题，同时解决因时序变动而使用户趣味发生变化等问题，向用户举荐用户想要的商品。多种策略召回深度开掘用户偏好基于多种算法策略捕获用户、商品和行为特色，联合元门路和图神经网络算法实现千人千面的个性化举荐，并具备可解释性。常识图谱助力营销支出增长借助常识图谱技术，精准了解用户和商品之间的交互行为，通过交互行为产生的信息，找到可经营因素，帮忙业务营销支出增长。凋谢接口反对定制化业务场景需要提供凋谢接口反对企业依据业务场景定制个性化计划，例如设置白名单或黑名单，可用于大型促销等场景。计划劣势提供搜寻举荐一站式服务将搜寻和举荐交融提供一站式服务，精准了解用户用意并提供个性化智能举荐，推用户之所想。交融常识图谱技术和数据积淀使用常识图谱技术，交融阿里电商丰盛策略和数据积淀，提供行业常识驱动、多元场景笼罩的智能服务。切实晋升外围业务营收指标面向用户业务场景，通过智能算法和策略的赋能，同时反对用户面向一些业务场景的定制化需要，切实晋升营收指标。可解决问题优化搜寻匹配成果。千人千面精准散发和举荐。新商品和用户疾速冷启动。反对计划场景化定制。利用场景电商、新批发或泛举荐：精准了解用户搜寻用意，个性化千人千面举荐散发，切实晋升GMV营收指标。 计划实例某奢侈品电商将智能搜寻举荐服务接入本人的外围搜寻业务，智能搜寻举荐服务帮忙客户优化搜寻举荐后果，打造出“猜您喜爱”的个性化举荐计划，使该电商的新用户均匀GMV（Gross Merchandise Volume）晋升61.88%，均匀点击率晋升18.44%。 申请办法智能搜寻举荐一体化营收增长计划的试用流动已上线，您能够登录（试用申请）智能搜寻举荐一体化营收增长计划申请试用（不反对RAM账号试用），具体请参见申请智能搜寻举荐解决方案服务。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：挪威博士倾心传授对于软件架构师角色至关重要的教训，心愿能领导和帮忙各位技术同学实现成为资深技术架构师。我叫Øystein Grøvlen，在过来的三年中，我始终在阿里巴巴PolarDB团队的优化器和执行器团队负责资深技术专家。我来自挪威，但在2018年来到中国杭州阿里巴巴公司, 一年后，我搬到了加利福尼亚州桑尼维尔的阿里巴巴公司办公室。 My name is Øystein Grøvlen, and for the last 3 years I have been working as a Senior Staff Engineer in the MySQL Optimizer & SQL group of the POLARDB team at Alibaba. I am originally from Norway, but moved to China to work for Alibaba in 2018. After living one year in Hangzhou, I relocated to Alibaba's office in Sunnyvale, California.  我的软件开发之旅始于作为美国的一名替换生，在那里我在APPLE II电脑上接触到了BASIC语言。我发现我对可能创立本人的程序来解决不同的问题感到十分满足，这激发了我在Norwegian Institute of Technology的学习期间去学习计算机科学，我发现数据库和信息检索特地乏味，因而我决定在该畛域攻读博士学位。我与挪威电信的钻研部门获得了分割，最终在他们的钻研我的项目ClustRa上工作了一段时间，同时攻读了基于Compensation-Based Query Processing课题的博士学位。 ...

简介：为帮忙宽广开发者更疾速、更便捷、更容易理解边缘云，阿里云推出“秒懂边缘云”主题技术直播流动，从产品、技术、架构、利用、翻新等维度，打造了一系列视频课程，让企业开发者疾速学习阿里云边缘云产品技术能力，从而轻松开发边缘利用。依据Gartner预测，到2025年，超过50%的组织将在其抉择的地点应用分布式云，从而实现转型业务模式。分布式云服务正在国内掀起一股热潮，国内行业巨头布局分布式云。2021年5月28日云峰会上，阿里云对外发表飞天云计算操作系统反对多种状态，即核心Region、本地Region、边缘云节点和现场计算节点，让客户在多种状态的云上共享所有产品。 边缘云是由大量扩散在各个地区部署的边缘云节点互相协同组成，人造具备分布式属性。与大规模集中式部署的云相比，边缘云最大特色是节点数量泛滥，但单节点资源规模较小，能够部署到5G基站左近的居民社区或工业园区，在地理位置上离终端很近。边缘云解决利用时延过长、汇聚流量过大等问题，满足音视频、游戏、物联网、工业互联网、终端虚拟化、主动驾驶场景对算力、网络、部署和低延时的场景需要。 随着越来越多企业抉择将利用部署在边缘，边缘云作为连贯数字世界和物理世界的重要载体，已成为成为企业应用开发不可或缺的一部分。相比IT环境下成熟的云利用开发，边缘云作为IT和CT相交融的产品，其利用开发可能会给企业及集体开发者带来肯定挑战。为帮忙宽广开发者更疾速、更便捷、更容易理解边缘云，阿里云推出“秒懂边缘云”主题技术直播流动，从产品、技术、架构、利用、翻新等维度，打造了一系列视频课程，让企业开发者疾速学习阿里云边缘云产品技术能力，从而轻松开发边缘利用。 阿里云在寰球领有2800多个边缘云节点，企业及集体开发者无需关怀利用部署的机器硬件配置、部署区域、调度和弹性扩容等，利用一经上传，即可实现寰球边缘云节点的部署，在寰球边缘执行，依据用户散布就近解决数据申请。 阿里云也是国内边缘云的定义者和领导者。2018年12月，阿里云联结中国电子技术标准化研究院公布《边缘云计算技术及标准化白皮书》，在业界首次定义了“边缘云计算”的概念、技术特点、利用场景及标准化需要。阿里云成为通过边缘云规范合乎性测试（2019年）和边缘云服务信赖能力测试（2020年）的首批厂商。2021年，阿里云边缘云节点服务取得“2021 云边协同能力”规范认证。阿里云牵头制订的边缘云国家标准《信息技术 云计算 边缘云通用技术要求》已正式取得国标我的项目号20213299-T-469。 目前，阿里云已联结行业搭档独特打造的10多个边缘云计划，胜利利用在城市、娱乐、电商、游戏、体育、金融、政企、广电、电力等行业。 点击进入秒懂边缘云：https://developer.aliyun.com/topic/edge/lives?utm\_content=g\_1000291841 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：8月行将完结，一起回顾下钉钉宜搭本月的产品停顿和阶段性成绩吧！蕴含：热点大事件、产品新性能、服务新策略、开发者新动静等。 8月行将完结，一起回顾下钉钉宜搭本月的产品停顿和阶段性成绩吧！蕴含：热点大事件、产品新性能、服务新策略、开发者新动静等。  在寰球权威咨询机构Gartner公布的《2021年中国信息与通信技术（ICT）成熟度曲线报告》中，阿里云凭借旗下低代码产品-钉钉宜搭多年来在低代码畛域积攒的技术能力与实践经验，胜利入选低代码利用开发平台（LCAP）代表厂商。  8月11日，钉钉宜搭举办2021线上发布会，3000人在线观看。本次发布会以“更高的性价比”、“更低的门槛”和“更好的服务”为关键词，全新公布10多款重要性能。同时，面向客户和合作伙伴别离推出了客户服务反对和搭档激励打算，钉钉宜搭将和企业及搭档一起共创，一起成长，一起赢！  宜搭业务流程能力全面降级，当初能够在易用根底上实现更加简单的业务流程配置，帮忙企业晋升审批效率。新版设计器流程绘制更简略、分支条件更弱小，审批人规定反对更多场景，同时减少流程模仿测试性能。 全新报表降级带来好搭易读的报表配置，解决搭报表时排版布局艰难，配报表时的各种配置名称、属性了解老本高，以及报表配置好后页面加载速度慢的问题。 宜搭集成&自动化已买通钉钉开放平台并接入大量钉钉一方连接器，包含通讯录、日程、考勤、工作告诉、日清月结（制造业）等，让业务与钉钉连贯更严密。此外，宜搭反对企业开发自定义连接器，连贯业务上下游，升高利用集成的门槛。 将来的数字化人才在高校，2021教育部—阿里云产学单干协同育人我的项目，钉钉低代码开发线上师资培训班于8月19日召开，来自全国70多所高校的256位老师参加线上培训。大多数老师都是第一次接触低代码，感叹钉钉低代码的弱小能力，40%的老师打算把低代码纳入课程教学中，认为对学生毕业当前进入社会工作会很有帮忙。 钉钉宜搭携手阿里巴巴技术公益委员会、阿里云“码上公益”平台，发动“码上公益营·低代码挑战”流动，用低代码技术升高技术公益的门槛，帮忙公益组织更低成本、更高效率地实现“技术公益”。流动发动至今，已有200+志愿者报名，120+志愿者正式参加我的项目开发，场景涵盖求助申请及治理、信息档案管理、志愿者治理等。 8月，宜搭服务商中级认证线上培训班炽热开启，疫情也阻止不了学员们学习宜搭的激情，本次培训共计200+小二报名参加，认证后果将于近期颁布。 8月23日，宜搭需要平台正式灰度公布，让每个需要都落地有声。需要平台是连贯宜搭与用户的桥梁，用户可在平台上提交对产品的诉求和倡议，并能实时查看所提需要的解决进度。客户的用心反馈是宜搭一直成长的能源！ 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：8月27日，《数据安全法》解读与阿里云三大合规计划线上直播流动完满收官。阿里云高级平安征询专家李娜对数据安全相干法律法规做了综合解读，她指出，数据安全合规不能仅看全面，须要有整体的数据安全观，知其然也要知其所以然，真正做到从被动合规到被动策略风控。 1.《网络安全法》作为基础性法律，有哪些比拟重要的数据安全要求？1)第二十一条： 国家履行网络安全等级爱护制度。防止网络数据泄露或者被窃取、篡改。 划重点：这一条阐明，等保2.0测评也蕴含数据安全相干内容。 2)第三十一条：国家对重要行业和畛域，以及其余一旦受到毁坏、丢失性能或者数据泄露，可能严重危害国家平安、国计民生、公共利益的要害信息基础设施，在网络安全等级爱护制度的根底上，履行重点保护。 划重点：这一条阐明，波及要害信息基础设施的数据泄露问题，在等保根底上，须要重点保护，包含但不限于商用明码利用安全性评估，数据安全审查、云计算评估等。 3)第三十七条：要害信息基础设施的运营者在境内经营中收集和产生的个人信息和重要数据该当在境内存储。确需向境外提供的，该当依照国家网信部门会同国务院无关部门制订的方法进行平安评估。 划重点：这一条阐明，向境外提供数据，须要通过网信部门评估前方可入境。 4)第七十六条：术语中网络安全，包含保障网络数据的完整性、保密性、可用性的能力。 划重点：这一条阐明，网络数据的完整性、保密性、可用性是网络安全的根底能力，需纳入根底平安防护能力的领域。 2.《数据安全法》的立法过程十分迅速，这是为什么？这要从《数据安全法》的立法背景来看： 1)社会经济倒退层面，数字经济疾速倒退，数据成为“国家基础性策略资源”，爱护这些数据保护须要法律依据； 2)数据开发利用层面，数据曾经从生产因素转变为生产力，促成数据正当开发利用须要法律依据。 鉴于上述两个需要的迫切性，数据安全法从立法布局到正式颁布十分迅速，而且在其余行政法规中及时失去具体利用。 3.《数据安全法》的适用范围是什么？1)境内发展数据处理流动及其安全监管； 2)境外发展数据处理流动，侵害国家平安、公共利益或者公民、组织合法权益的，依法追究法律责任； 划重点：这里明确了数据安全属地管辖为主，保护性管辖为辅。 4.《数据安全法》每章重点讲了什么？1)第一章总则，次要技术要求包含建设数据安全治理体系以及次要监管为国家网信和行业主管等。其中数据安全治理比拟重要，包含数据梳理、数据安全危险剖析、分类分级、监控预警、数据安全布局等较多内容，这些内容都涵盖在数据安全征询的服务范畴。 2)第二章数据安全与倒退，次要包含反对数据安全评估与认证、建设数据交易管理制度等。 划重点：第一，数据安全评估与认证有可能像等保和密评一样成为数安法落地的查看伎俩；第二，建设数据交易管理制度而不是数据交易制度，重点在数据交易的治理。 3)第三章数据安全制度，包含最受关注的数据分类分级、数据安全审查和数据进口管制， 4)第四章数据安全爱护任务，次要包含数据安全治理、危险监控与处理和数据处理及服务三局部。 划重点：数据处理中的数据起源核实及记录，次要针对的是数据交易场景中数据源的权属，不是传统数据安全的拜访溯源取证场景。本章最重要的是，数据入境，未经批准，不得对外提供。 5)第五章政务数据安全与凋谢，重点是国家制订政务数据凋谢目录，构建对立标准、互联互通、平安可控的政务数据开放平台。 划重点：倡议各单位遵循相干规范与规定，不要自行制订数据目录，可能导致互联互通艰难。 6)第六章法律责任，简略地说，多条处罚，包含除了罚款，还能够责令停业整顿、撤消相干业务许可证或营业执照。 划重点：可依法追究间接责任人的刑事责任。 7)第七章附则，数据安全法往年9月1号施行。 5.《数据安全法》有哪些条文须要重点关注？1)《数据安全法》第二十一条的数据分类分级。首先国家建设数据分类分级爱护制度，对数据履行分类分级爱护。国家数据安全工作协调机制兼顾协调无关部门制订重要数据目录，各地区、各部门该当依照数据分类分级爱护制度，确定本地区、本部门以及相干行业、畛域的重要数据具体目录， **a)划重点：国家部委或行业的分类分级，尽量采纳已有的数据分类规范或目录，不倡议独自制订专门的分类分级制度，防止因数据目录不同而影响数据集替换与共享。 b)数据分类是为了更好地区分治理对象，分级是为了施行不同水平的爱护，数据分类肯定是面向某种治理指标、监管伎俩的，不能一言以蔽之。** 2)《数据安全法》十八条对于国家反对数据安全检测评估与认证服务的倒退。 **a)划重点：规范37988数据安全能力成熟度模型，能够作为数据安全法检测落地的抓手。该规范已在ISO立项，有可能成为国内数据安全规范； b)规范37988数据安全能力成熟度模型的1-5级不能和等保作简略的对应关系，企业确定本人的数据安全能力等级须要依照预评估的理论状况而定，能力不具备时自觉谋求高等级可能整改艰难。** 3)《数据安全法》第二十七条强调的也是全流程数据安全治理，涵盖数据安全的外围八大能力，包含数据安全生命周期的分类分级、传输加密、存储平安、数据脱敏、数据资产治理、终端数据安全、监控与审计、数据甄别与访问控制。这些外围的技术能力加上数据管理能力和运维能力，是DSMM评估与认证查看的核心技术能力，如果满足DSMM评估与认证查看，数据安全法提出的技术要求根本满足。 6.《数据安全法》和《网络安全审查方法》之间是什么关系？新订正的《网络安全审查方法》将数据安全纳入网络安全审查范畴。 《网络安全审查方法》订正前后比对状况： 1)第二条：要害信息基础设施的运营者，数据处理者，发展数据处理流动，可能影响国家平安的，将进行网络安全审查， 划重点：数据处理流动是重点标准对象 2)第六条：减少了把握超过100万用户个人信息的运营者赴国外上市，必须向网信办申报安审。 划重点：对数据运营者作出了100万的定量形容。 3)第四条：审查单位减少了中国证监会； 4)第十条：网络安全审查评估内容减少了数据处理流动和海内上市场景，其中重点减少的国家平安危险有外围数据、重要数据或大量个人信息被窃取、泄露毁损以及非法利用或入境危险，国外上市后要害信息基础设施、外围数据、重要数据或大量个人信息被国外政府影响、管制、歹意利用的危险。 划重点：网络安全审查将数据处理流动及海内上市减少为评估内容，重点评估的是数据安全。 5)第十三条：将网络安全审查的工夫从45个工作日，缩短到3个月。 6)最要害的第一条，为了确保要害信息基础设施的平安，执法根据除了《国家安全法》、《网络安全法》，减少了《数据安全法》；第十六条，违反本方法规定的，处罚根据减少《数据安全法》。 划重点：这二条阐明《数据安全法》被列为审查和处罚的根据。 因而整体来看，数据安全不仅有相干的数据安全能力评估认证作为抓手，还有网络安全审查作为检查和处罚伎俩。 7.数据安全法正式施行在即，咱们应该如何对待数据合规？划重点：数据安全要从被动合规转化为被动策略风控 首先，总体国家安全观中，网络安全是16个之一。从国家安全法的安全观到《网络安全法》的网络空间主权到《数据安全法》的具体条文，其内容一脉相承。目前波及数据安全的还有《个人信息保护法》、民典法、刑法修正案（十一）等法律，都涵盖相干内容。 其次数据安全相干法律法规和政策的落地，正在经验一个逐步欠缺监管伎俩、晋升监管能力的过程，“让法律长出牙齿”，目前国家不仅在解决“有法可依”的问题，也在解决“违法必究”的问题。 在此状况下，企业对数据安全合规的了解不能全面，甚至怀有不查看不处罚的侥幸心理，须要将数据安全合规危险回升到业务危险，甚至企业危险，踊跃驳回企业法务与平安合规团队意见，或者延聘业余的平安征询团队解决问题，确保对政策趋势有足够的敏感性和前瞻性，从被动数据安全合规到被动策略风控。 两 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：云开发系列课程次要介绍了从入门到精通疾速上手Serverless和云开发技术。学习内容涵盖云开发协同、云函数、云数据库、多媒体托管、前后端一体化框架等Serverless Web开发必备常识。心愿通过云开发系列课程的学习与实际操作，让大家深刻理解Serverless和云开发技术，并加深对阿里云云开发平台和阿里云Serverless产品的了解与意识。 本篇内容按阿里云云开发平台的构造，别离拆分解说如何意识和应用Severless云开发平台。阿里云的云开发平台 一站式的研发平台在阿里云的云开发平台，能够一站式反对整个研发团队进行线上利用研发工作。应用阿里云账号登录平台当前，进入到平台之后咱们能够抉择不同的我的项目团队，就能看到云开发平台的利用列表操作界面，在这个界面大家能够看到一些简略的入口，那么下文将按程序别离介绍一下。 在利用列表操作界面的顶部，有个十分重要的帮忙文档入口。进入这个入口能够找到平台提供的重要文档，例如《残缺的疾速入门》，文档将指引首次登录的开发者如何创立团队和治理团队，如何利用产品或开发部署等，基本上涵盖了一个残缺研发生命周期的全部内容领导。 模版化的场景解决方案轻松上手 团队协同里重点介绍了说在整个研发平台，团队怎么创立，团队的成员角色是怎么子的，以及怎么将一个开发任务分配给一个具体的开发成员。 场景与解决方案里蕴含根底Helloworld等云原生的Serverless的利用模版，解说如何在云开发平台创立和部署。2020年9月云栖大会期间咱们组织了Hello World上手会懂，旨在帮忙大家通过简略的Hello World，一个规范的程序员或者开发者的通用语言，来疾速感知云原生Serverless利用如何开发。 在这个入口里有很多场景和解决方案。比方天猫精灵的计划怎么开发，比方基于前端的NodeJS的一系列的利用框架怎么疾速迁徙上来？比如说EggJS、Express、KOA、NextJS、Nuxt以及更多的利用，都能够通过这些形式疾速迁徙上来。还有阿里巴巴的Serverless框架，Midway Serverless，以及基于Midway Serverless系列怎么操作数据库的RDS、OTS等等。除此之外， Python语言的开发迁徙、PHP的开发迁徙，以及Java的SpringCloud，SpringBoot，SpringMVC等等的迁徙。 基于阿里云的智能视觉平台提供的凋谢能力，咱们能够做很多乏味的利用。比方，阿里巴巴自研的从图像智能生成代码的ImgCook的利用，通过ImgCook生成一个H5，这个H5的背地是一个上传图片和辨认图片的性能，所以通过阿里云智能服务能够实现很多乏味的创意。 OSS文件浏览器直传计划，它能够实现与平常不一样的文件上传。它向开发者展现了如何在利用、存储、拆散的状况下实现文件上传。高阶的开发辅助里有Codeup代码托管的具体应用办法介绍，以及Java的在线流水线Flow的应用办法介绍。如果你有深度学习的需要，或想更多地开掘阿里云云开发平台的服务能力，能够多点开看看这个入口。服务条款里介绍了阿里云云开发平台是通过什么形式为大家提供服务的。其中费用与账单中，开发者能够查看在这个平台上曾经利用开发部署了哪些资源和应用了哪些服务，费用一栏是与之对应的。如何计费、怎么领取，这里都有具体的介绍。 作为一名合格的开发者，浏览文档是一件很重要的事件。云开发平台的帮忙文档里，能够为大家解答了很多重要的问题。 如何实现团队协同和利用治理？ 在阿里云标记的左侧有9个点的入口，点开是一个能够开展的团队协同的界面。界面里有制品仓库、流水线、代码治理一系列团队协同的工具，点开任何一个工具都能够利用到团队中。 作为开发者能够基于工作台创立一些工作，并对一些工作和我的项目进行治理。比方代码治理，每一个利用都会给使用者调配一个代码仓库，通过代码治理能够具体地理解利用的代码仓库是什么样子，以及针对它的所有更细节的操作你都能够实现。如果想做更多的团队协同，能够通过云开发平台左上角9个点的入口开展菜单，去做更多的事件。 创立团队阿里云平台登录后，能够通过左侧的以后团队查看本人所在的团队及团队所给予的权限。这就保障了大家在做工作或想创立利用的时候，及时理解本人的权限，防止不必要的工夫节约。 团队和利用治理产品线治理、利用治理、利用模板以及成员治理，是当你有肯定的权限后能力看到残缺的入口。举个例子，如果在以后团队只是开发者，这里的视图就会发生变化，因为开发者没有权限治理和创立利用。 以上所介绍的就是团队协同的概念及利用。当大家把团队整个搬上来时，能够给每一位团队成员调配权限。那么如何把团队搬上平台，怎么给团队成员调配权限？ 邀请团队成员 在当下团队下关上成员列表，能够看一张视图，主体是以后团队所有成员，右上角有两个入口，一个是增加阿里云子账号成员，一个是点击复制邀请链接，邀请其余阿里云主账号，这两个有什么区别呢？ 点击复制邀请链接，是指邀请其余阿里云主账号。意味着你邀请的人首先领有阿里云的账号，他承受邀请退出你的团队之后，也是用他的阿里云账号登录。因为他是独立的阿里云账号，作为团队管理者你可能对他没法做管控，这种状况实用像开源的共建我的项目的互相协同。这种形式就会比拟灵便，每个人都用本人的账号登录。 当受邀人关上链接后，会看到显示邀请人姓名的提醒界面，点击批准退出团队后，期待审批。邀请人这边界面会提醒有新用户申请加入，审批同意后受邀人即可通过阿里账户登录团队。 邀请阿里云子账号成员，是指邀请你主账号之下创立的子账号。首先咱们能够通过返回创立ram子账号入口，抉择主账号人并给他创立子账户，并在创立过程中勾选管制选项，并设定登陆密码。子账号创立失效后，只需勾选此子账号，就实现了子账号邀请工作。 大家在退出团队后能够按调配的工作进行执行，实现协同开发。所有团队成员角色和他们对应的权限，能够是利用开发者、利用管理者以及团队治理园等权限，通过第一点所提到的帮忙文档里团队协同中查看。 在线调试和一件部署管理员进入利用列表，点击创立利用并抉择开发语言实现创立利用。创立利用后进入代码仓库，将咱们抉择的初始化脚手架文件内置到代码仓库中，期待调配。 当利用创立结束后，点击利用后三个点，抉择开发者治理，抉择并勾选指标开发员，任务分配胜利。新退出的成员零碎会默认为利用开发者，作为团队拥有者能够因需调整成员的权限。 当成员在进行开发工作的时候，团队拥有者能够关上界面与之同步进行开发，这就是乏味的结对编程。实现代码开发后，可间接点击日常部署。 如果部署胜利，状态地位就会显示已部署。 部署的利用如果想下线并进行服务也很简略，只需点击当下利用，并确认下线进行服务即可。如果是实在的线上服务利用，这个操作要十分审慎。 当部署的利用出错了，咱们能够通过运维监控入口进入，查看运维监控的面板。可抉择须要查看的运维日志及监控环境。同样在上文提及的第一点，通过帮忙文档的疾速入门中学习怎么查看日志和测试。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：通过两个demo分享技术实时计算flink版的解决方案本文整顿自阿里云智能行业解决方案专家GIN的直播分享 直播链接：https://developer.aliyun.com/learning/course/839 本文次要分享两个基于 Flink 制作的实时大数据的利用。为了更好的体现利用的价值以及它所代表的典型的场景，这次的分享定制了两个靠近现实生活中的利用案例。 第一个是如何去做实时的 API 应用服务日志的剖析，第二个是采纳模仿的 IoT 遥测数据去剖析车辆的引擎，并且做实时的异样侦测，以达到做预测保护的一个目标。 实时利用日志剖析场景形容第一个场景的需要是比拟广泛的，这个场景搭建了车辆隐衷爱护的API。这个API自身是能够对用户上传的车辆的照片进行一个隐衷爱护的解决，是一个深度学习的模型。 这个模型被封装成一个API，放在阿里云的公共云ECS上，供全世界各地的用户去拜访。针对这个API首先须要做的就是去剖析到底有多少人在拜访他的反馈的频度，来自哪个国家或地区，以及他的拜访的一些特色，是否为攻打或者失常的利用？ 为了做这个实时的剖析，首先须要有能力对各个API扩散在各个服务器当中的自身的利用日志去进行海量且实时的一个收集的行为。不仅能收集咱们，咱们还要可能对它进行一个比拟及时的实时的一个解决。解决包含可能有维度表的查问，有些窗口的聚合等等，这对流式计算来说比拟常见的操作，最初把这些操作解决完的后果放在高吞吐低提早的一个环境里边，使得上游的剖析零碎可能对数据进行一个实时的拜访。 整个这个链路并不简单，然而它代表了一个十分重要的能力，也就是通过应用 Flink 为代表的实时计算和解决，可能在秒级的单位内给业务决策人员提供一个数据驱动决策的性能。 Demo计划架构具体来看一下这个demo是如何实现的，这里边的这个架构里边有几个重要的要害。 首先右上方是搭建好的API的环境，用的是Flask、 Pytho联合比拟支流的Nginx、Gunicorn把它制成了一个API 。须要把API变成一个容器镜像，并且通过镜像将它部署到阿里云的ECS下面，为了高并发低提早，还装了第七层的负载平衡，以及后面套了一个API Gateway网关去帮忙用户去调用API的能力。 同时作为这个demo，咱们也提供了一个 WEB APP ，使得用户不仅能通过代码去调用 API ，也能够应用图形化的界面去拜访API 。以后端的用户去调用API 的时候，会应用SLS 简略日志服务去从API 自身的服务器当中收集实时的收集API 的利用日志，并且将它做简略的解决之后，投递到实时计算Flink中。 Flink 有个很好的一个特色，就是它能够去订阅来自简略日志服务的日志的投递，并且以流式计算的形式对这个日志进行窗口聚合维度表的查问联合等等这些操作，还有一个益处是它能够用习惯的SQL去做比较复杂的业务逻辑的定制。 当这些数据都解决完了之后Flink 就会把流数据以结构化表的形式写到Hologres，Hologres不仅作为数据的一个存储，也同时作为一个给上游 BI 数据展示提供能源的相似OLAP的引擎的性质。这些货色串起来，造成了本次的大数据实时日志采集剖析的一个架构。 计划解析具体来看一下，每个部件是如何应用的。 应用车辆隐衷 API 作为实时剖析的数据源 通过WEB APP能够容许用户非常简单的去上传本人的车辆的照片，API 会对他进行一个模糊化的解决。录屏中能够看到这张照片交由API 解决之后背景被虚化了，并且车牌的局部还有隐衷信息的局部也被遮挡了。 SLS 日志核心 当有用户去拜访这个API 的时候后盾简略日志服务就会对他进行一个实时的采集。 日志采集之后会应用Log tail 的转换数据加工的能力，对原始的日志去进行肯定水平的解析和转换，其中就包含将IP地址解析为例如国家城市纬度精度等这样的地理信息，不便后续做上游的剖析的时候能够调度这些信息，除了简略的一些服务还提供一个十分弱小的图形化的数据分析的能力。 实时计算Flink版 在这里能够做一个高级的数据分析的，或者是数据勘察的性能，能够看到原始日志的转换是否满足上游业务撑持的一个需要，当日志被采集转换解决完之后，会通过Log Hub将这个日志投递给流解决核心，也就是实时计算Flink 。 其实用投递这个词并不是特地的准确，实际上是Flink 被动去订阅，在Log Hub 里边存储的Log Store 的这些解决过的日志的信息。Flink 有个十分好的中央，能够用常见的SQL去写编业务逻辑，包含转换解决一些逻辑条件。当SQL写完后只有点击上线，就能够包装成一个Flink的job ，并托管在Flink 的cluste里边，集群里边，通过这个控制台能够十分不便的拜访。 ...

简介：阿里云实时计算 Flink 版解决方案白皮书-2021版正式公布～Apache Flink：寰球当先的开源大数据计算引擎Apache Flink 是一个开源的分布式大数据处理引擎,可对无限数据流和有限数据流进行有状态计算。作为 Apache 软件基金会(ASF)顶级我的项目之一， Flink 在流解决方面具备相对的劣势，提供高吞吐、低延时的计算能力，Exactly-once 语义保证数据的准确性，亚秒级别的解决提早确保业务的疾速响应。 作为疾速倒退的新一代大数据引擎， Flink 自身的架构劣势也吸引着越来越多的开源爱好者投入到社区的建设来。截止到2021年8月，社区的star数达到16900，contributor数达到905，有27806次commits，同时至2021年1月 Flink 已蝉联三年 Apache 最沉闷开源我的项目。随同着社区的疾速倒退， Flink 也成为相似阿里巴巴等出名公司建设流解决平台的首选。 Apache Flink 的零碎架构残缺白皮书下载>>>https://developer.aliyun.com/topic/download?id=7968 阿里云实时计算Flink版实时计算Flink版（Alibaba Cloud Realtime Compute for Apache Flink，Powered by Ververica）是阿里云基于 Apache Flink 构建的企业级、高性能实时大数据处理平台，由 Apache Flink 开创团队官网出品，领有寰球对立商业化品牌，齐全兼容开源 Flink API，提供丰盛的企业级增值性能。 在PB级别的数据集上能够反对亚秒级别的解决延时，赋能用户规范实时数据处理流程和行业解决方案;在反对 Datastream API 作业开发的同时，提供了残缺的SQL语义，使得BI场景下的开发变得更加简略;丰盛的上下游 connector 保障了与用户已应用的大数据组件无缝对接;智能作业调优和诊断性能进一步简化了用户的开发和应用。 实时计算Flink版在 Apache Flink 外围性能的根底上还加强了企业用户所关注的集群稳固、性能优化、安全控制、系统监控和作业管理等性能。同时积淀了互联网娱乐，在线交易，金融，在线教育等近百个行业案例场景，多行业全方位实际场景，为业务稳固倒退保驾护航。阿里云实时计算团队目前是寰球最大、领有 Committer 数量最多、专业性最强的 Flink 团队，为实时计算用户提供企业级的治理和咨询服务。2019年6月，由数据中心联盟发动的大数据产品能力评测后果权威公布，阿里云实时计算Flink版通过最新制订的分布式流解决平台根底能力评测，成为国内首批通过流计算产品能力评测的产品，并被数据中心联盟圈定为国内大数据流计算根底平台第一梯队。2020年在国内出名征询调研公司 Forrester 的测评中，实时计算Flink版成为中国惟一进入 Forrester 象限的实时流计算产品。 阿里云实时计算 Flink 版与 Apache Flink 的比照 实时计算Flink版产品架构 阿里云实时计算 Flink 版的产品性能及劣势产品性能 产品劣势：性能优越：单核CPU每秒数十万条记录解决能力，端口间达亚秒级数据处理提早，反对数万并发超大规模实时工作计算。功能强大：一站式SQL开发运维平台，智能化诊断与主动配置调优，无缝对接阿里云支流数据产品。物美价廉：单核CPU计算每小时低至0.25元，可基于负载弹性伸缩及按量付费，TCO大幅低于IDC自建。稳固牢靠：99.9%SLA稳定性保障，全链路指标监控报警，历经阿里巴巴多年双十一测验。兼容开源：100%兼容ApacheFlink，反对开源Flink平滑迁徙上云，无缝对接支流开源大数据生态。品牌认证：Flink开创团队官网出品，中国信通院权威认证，中国惟一进入Forrester象限的实时流计算产品。实时计算 Flink 版在各行业的利用金融行业解决方案 ...