互联网

云栖号资讯：【点击查看更多行业资讯】 在这里您能够找到不同行业的第一手的上云资讯，还在等什么，快来！纵观中国开源历史，你真的没法找到第二个像 Dubbo 一样自带争议和探讨热度的开源我的项目。 一方面，2011 年，它的开源填补了过后生产环境应用的 RPC 框架的空白，一公布就被宽泛采纳；另一方面，它经验了进行保护、重启保护后募捐给 Apache 基金会、接着又以顶级我的项目的身份毕业。 面对多疑的开发者，在云原生时代，Apache Dubbo 将如何连续以后光辉？ 往年是 Dubbo 从 Apache 基金会毕业的一周年，同时也是推动 Dubbo 3.0，即全面拥抱云原生的重要一年。 作者简介 刘军，花名陆龟，GitHub 账号 Chickenlj，Apache Dubbo PMC，我的项目外围开发，见证了 Dubbo 重启开源，到从 Apache 基金会毕业的整个过程。现任职阿里云云原生利用平台团队，参加服务框架、微服务相干工作，目前次要在推动 Dubbo 3.0 - Dubbo 云原生。 系列开篇：3.0 全面铺开、ASF 毕业一周年 从 2019 年到当初，在 Dubbo 毕业的这一年工夫里，Dubbo 社区和产品都获得长足进步，同时 Dubbo 云原生版本 - Dubbo 3.0 的开发工作也曾经全面铺开。 社区方面。须要重点提及的有两点：一个是落地与奉献的企业用户进一步减少，被动与社区取得联系的中、大规模公司达 200 多家，如携程、工商银行、瓜子二手车、网联清理、中通等；另一个是以 Dubbo-go 为代表的子社区蓬勃发展。 产品技术演进方面。Dubbo Java 版公布 10 个版本，在多语言、协定、性能、服务治理模型等方面都有深度摸索。Dubbo go 公布超过 8 个版本，在性能根本对齐 Java 版本的根底上，一些方向上也曾经走在了 Java 版本后面。 ...

前言： -更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 （文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index 随着2018年银保监发文《银行业金融机构数据治理指引》，各银监局，机关各部门，各政策性银行、大型银行、股份制银行，邮储银行，外资银行，金融资产治理公司，以及其余会管金融机构纷纷开始了新一轮的数据治理的相干工作。然而在金融机构进行数据治理的过程中，波及的畛域和相干的工作十分多。 本文是作者联合本人十几年在机构做数据相干的工作教训，从数据资产治理的角度做了一些总结和思考。 银行业为什么要进行数据资产治理近年来，银行业金融机构在业务疾速倒退过程中，积攒了客户数据、交易数据、内部数据等海量数据。数据曾经成为银行的重要资产和外围竞争力，充分发挥数据价值，用数据驱动银行倒退，进步银行经营质效，具备重要意义。 以后，银行业金融机构数据品质存在较多问题，次要体现为数据准确性和完整性欠缺，时效性和适应性有余。数据品质问题曾经妨碍了银行业金融机构向高质量方向倒退，对数据资产的治理、治理亟待增强。 银行业数据资产治理三个方面当咱们提到数据资产治理，要从三个方面来看。即数据资产的盘点与剖析、对数据资产的治理、以及资产的利用。接下来咱们就一个个开展。 首先银行要用好数据，把数据变成资产发明价值，就要搞清楚手里到底有哪些数据资产。 而银行有太多的数据，因而数据资产盘点要落地也并不简略。数据资产的盘点和评估要思考融通性，保证数据盘点的精准。 在数据内容的了解方面，要建设全行的数据资产目录，并且对数据进行画像，对数据的起源、业务含意等进行形容。同时要有确信机制和工具来撑持，通过各部门的协同实现数据资产探查。这里不只是数据团队，包含科技和业务部门都要参加进来，有明确的接口人来配合数据资产的盘点工作。 这里值得一提的是数据中台的理念其实和数据资产治理不约而同，在数据中台的建设中，十分重要的工作就是数据公共层的建设，通过数据公共层建设能够清晰的梳理出咱们的数据资产散布及应用状况，联合资产的拜访路径分析，最终造成全行的数据资产全景剖析。资产盘点与剖析这里的细节工作本文不再一一开展。 在银行对本人的数据资产有了比拟清晰理解的根底上，便能够开展数据资产的治理工作了。 银行机构该当把数据品质危险和平安合规危险都纳入数据资产治理的领域，并且造成一个资产治理的闭环。 依据数据资产应用的现状登程，发现以后的问题并提出治理优化的策略，而后通过对治理成果的反馈来迭代现状剖析，造成一个治理能力的闭环。 在数据品质的保障方面，该当围绕数据的完整性、准确性、一致性以及及时性，对数据处理链条上的流程标准，在事先事中预先的关键环节进行卡点校验。 同时对数据工作、数据监控划分不同级别不同保障力度，实现精准保障。在业务高峰期，很多银行机构都会呈现数据报表加工延时的状况，针对这种十分影响业务体验的状况，银行能够依据业务或数据产品产出的上下游所有节点组合成工作组，对工作组进行分级，保障产出的优先级、监控产出的及时性。 在平安合规的分享治理方面，银行要造成一套以数据为核心，以数据的流转为主线，贯通数据全生命周期的平安管理机制。次要波及的工作有: 防窃取(透露)、防误用、防滥用 。 数据的全生命周期包含生产、存储、应用、传输、流传到销货。对客户数据、业务数据、公司财务经营治理进行分级。 个别咱们会分成公开数据、外部数据、保障数据和秘密数据四个等级。 银行的数据资产治理对银行的业务数据化经营和数据业务化转型都十分重要，这其中包含大量的治理标准制订和组织间协同工作，当然还要有相干的工具平台来帮忙数据资产治理的落地，为用户提供多维度数据资产剖析，智能化数据资产治理，全链路数据资产监管与价值追踪，全方位数据资产经营的数据资产治理一站式服务平台 。 数据中台是企业数智化的新基建，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云数据中台解决方案对外输入，包含批发、金融、互联网、政务等畛域，其中外围产品有： Dataphin，一站式、智能化的数据构建及治理平台；Quick BI，随时随地 智能决策；Quick Audience，全方位洞察、全域营销、智能增长；Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；官方站点： 数据中台官网 https://dp.alibaba.com

现阶段，高速公路监控设施笼罩曾经有普遍提高，但监控设施的笼罩仅实现了视频的监控性能，没有实现剖析揭示性能。传统人工巡检形式工作量大且容易产生事件脱漏、事变发现不及时导致二次事变、人工视频巡检工作量大无奈做到实时检测、监控核心绝大部分工作量被巡检占用以及交通状况不能及时检测和解决等痛点问题。 杭州湾跨海大桥“新基建”智慧高速我的项目通过全量视频上云、视频监测全联网、全笼罩与智能化，实现高速公路异样事件自动检测、路况自动识别、智能监控的目标，满足大桥路网高效运行、及时处理突发事件和为广大群众提供优质出行服务等需要，同时强化大桥的平安经营治理，夯实智慧高速“云基建”。 我的项目背景：全国高速公路视频联网监测 杭州湾跨海大桥全长36千米，是连贯上海和宁波两大城市的惟一路上通道，日交通量超过4.8万辆，对通行平安、通行效率有较高要求，心愿通过桥面监控视频的智能剖析，检出路面常见交通事件并及时处理。 《交通强国建设大纲》中明确要求“强化交通基础设施养护，增强基础设施运行监测检测”。在推广全国高速公路视频联网监测工作的背景下，阿里云施展云计算能力、大数据架构、达摩院视觉剖析算法的劣势，全面晋升杭州湾跨海大桥公路信息化、智能化程度以及出行服务保障能力，实现了“平安畅通 谐和高效”的经营指标。 我的项目挑战：技术、业务、信息、管控等全方位降级 1.传统巡检形式，人工工作量大，产生的视觉疲劳，容易产生事件脱漏。 2.标准外场监测设施布设，实现全路段笼罩、全息感知、全天候通行。 3.通过视频智能剖析无效辨认简单环境下的交通事故，以及事变或交通拥堵及时检测和解决，让路线管理人员及时发现并处理异样事件，防止车辆绕行或引发二次事变，升高事变产生几率，晋升高速公路的经营效率。 4.利用多源数据交融技术实时监测路网交通运行状况，辨认产生拥挤路段的拥挤范畴、持续时间等，买通不同交通检测设施之间的数据孤岛并通过视觉AI被动发现事件和报警，晋升事件出检率，进步路况监测准确度。 5.智能公布路况信息，及时揭示出行者被动避让，升高高速公路经营压力。 6.主动剖析并智能举荐路线封道分流等，辅助治理部门决策分析，从而建设科学合理的管控工作机制和工作流程。 解决方案：通过全量视频上云，实现事件自动检测 为了改善杭州湾跨海大桥路面经营管理效率，进步交通事件检出以及处理能力，晋升公路信息服务能力，阿里云依靠当先的CDN网络减速能力、达摩院视觉剖析算法、高德地图出行数据等，构建视频剖析零碎、智慧高速云控数据底盘以及利用平台，实现全量视频上云，从而构建杭州湾跨海大桥路面异样事件自动检测零碎。通过阿里云交通事件AI视觉引擎，辨认交通事故、抛洒物等常见交通事件。将事件数据经由阿里云智能高速数据交融引擎，交融高德全网模型，打造交通态势、事件发现与处理闭环，大幅度提高了路况智能、被动辨认的效率以及全面感知与运行指挥调度能力，升高了路网监管经营的老本。 整体架构：全面感知，自动检测 利用云上服务器、存储及网络设施，造成可伸缩、高安全性、低保护量的存储资源池和计算资源池；应用开源数据库、负载均衡器、消息中间件等平台利用构建信息系统。 利用视觉AI事件检测算法、全网模型、云控平台等构建数据交融底盘与智能剖析引擎，提供实时、高清、便捷的视频调看服务，同时向出行公众提供低码流、大并发、可管控的平安视频服务。视觉AI事件检测算法实现视频接入、计算与调度，RTMP直播等；全网模型实现事件交融、路况交融、数据服务等；云控平台实现事件预警、视频回放、路况检测等。 建设成绩：外围能力，翻新功效 1.全量视频上云：将本地机房与公共云通过专线连贯实现混合云架构，全量视频流通过推流上公共云，在公共云实现视频的剖析与云控平台的部署。 2.事件精准感知：针对路面上的各场景能够实现违停、逆行、拥挤、抛洒物、烟雾等事件检测；同时能够实现车牌辨认、车型辨认统计等性能，加强事件追溯成功率。 3.智能巡检：实时辨认高速公路路况、异样事件，及时向可变情报板、高德等推送交通状态和异样事件信息，确保高速公路治理部门和高速公路出行者及时全面把握路线信息。 4.大屏展现：辨认后果在监控室大屏上实时展现，展现内容包含路面基础设施车流与预警、路网异样事件声光色告警、路网拥挤事件声光色告警、特定断面管控预警倡议等。 5.事件应急解决：值班监控员通过现场视频确认路网异样事件，零碎主动交融监控指挥管理系统进行现场事件、治理联动单位、管制诱导、管控措施、信息公布等一系列应急解决工作。 6.标准外场设施布设，实现全息感知、全天候通行：单向250米一个摄像头立杆，双向125米一个摄像头立杆，保障感知能力达到100%全笼罩，同时保障夜间监控100%全笼罩，单摄像头感知范畴笼罩双向车道。 7.专人案例剖析：大桥管理人员和阿里云成立专门算法剖析小组，利用落地零碎定期对施行的算法模型精度、功效进行剖析、跟踪、复盘，及时调整交通阈值、优化算法模型，并一直标准外场监测设施布设规范。 8.我的项目闭环：我的项目经营准则本着展现辨认后果、事件治理、智能公布路况信息、专人案例剖析、优化路况模型闭环治理准则，联合路网监控工作理论场景进行优化降级，进步路况智能、被动辨认的效率，升高路网监管经营的老本。 结尾：良好的社会效益和经济效益 杭州湾跨海大桥视频事件监测设施设置344处视频事件监测设施全量上云，全桥36千米每125米一路的事件检测密度实现全路段笼罩。通过阿里云高速公路数据交融引擎以及深度学习算法的AI视觉引擎，交融高德全网交通数据模型，打造大桥路面交通态势感知、事件发现与轻处理闭环。 在试运行过程中，白天规范环境下检测准确率达到99%以上，并达到“零漏报”；夜间规范环境准确度达到98%以上，并达到“零漏报”。个别条件下，已根本具备零碎代替人工巡检的条件（注：除去台风、能见度200米以内的雾霾、小时降雨达到16-32毫米以上的大雨等极其状况外）。 社会效益方面，全面实时掌控路线通行情况，进步综合交通管理程度，晋升服务质量。经济效益方面，缩小拥挤工夫、进步通行保障能力，进步高速公路运行效率，缩小燃油耗费与碳排放。 智慧交通相干举荐 阿里云智慧交通门户正式上线啦！计划全景、体验核心、客户案例、上云模式、架构师征询……智慧交通，一网全览！

互联网行业就喜爱搞一些单词的缩写，在云计算行业，前者有SaaS、PaaS、IaaS，最近两三年aPaaS的概念又开始被关注。aPaaS到底是什么意思，有什么用，与前三者的区别是什么？本文将对这些问题进行彻底探讨。 什么是云计算在探讨什么是aPaaS之前，咱们有必要解说一下云计算的概念。设想一下，假如你要开发一款软件程序，会须要用到哪些技术或设施呢？不懂技术没关系，您只有记得，一套软件通常蕴含以下九个档次： 利用（application）数据（data）运行库（runtime）中间件（middleware）操作系统（OS）虚拟化技术（virtualization）服务器（servers）存储（storage）网络（networking）在过来，您须要购买和保护这九种设施/技术，而当初，有一些公司把其中某些档次整合起来（比方存储、服务器、操作系统）打包成一种服务对外发售，这些公司被称为云计算公司，他们的这种打包办法被称为云技术，这种服务模式也就是云服务。 你能够间接租用这些服务，只须要像水电费一样每个月缴钱就行了，比起之前要保护九层设施/技术，是不是轻松多了？ 也不是所有公司都把这九个档次全都做了，目前市面上次要有三种服务模式，他们别离是：基础架构即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS），区别在于哪些服务是云计算公司提供、哪些是本人提供。 什么是aPaaS？你能够把aPaaS了解为PaaS的一种子模式。aPaaS的全称是application Platform as a Service，即应用程序平台即服务。Gartner对其所下的定义是：“这是基于PaaS（平台即服务）的一种解决方案，反对应用程序在云端的开发、部署和运行，提供软件开发中的根底工具给用户，包含数据对象、权限治理、用户界面等。” aPaaS（应用程序平台即服务）有以下2个特色： 提供疾速开发的环境，用户在几个小时内就能实现利用的开发、测试、部署，并可能随时调整或更新。低代码或零代码，非技术人员就能实现利用开发aPaaS和PaaS的区别是什么？aPaaS和PaaS都能够实现软件的开发和部署，都反对云端拜访。而两者的差别次要体现在用户人群和应用环境不一样： PaaS蕴含所有平台级别的服务，须要技术人员在本地实现应用程序的开发和数据提供，而后部署到PaaS平台上，再分发给用户应用。aPaaS是PaaS的一种子模式，在aPaaS模式下，非技术人员能够间接在云端实现应用程序的搭建、部署、应用、更新和治理。能够看进去，PaaS是比拟灵便的，因为能够齐全按需开发，然而毛病是人力老本较高，因为你要招募程序员去实现这个开发过程，另外，如果波及到需要的调整，还会波及到二次开发。不论是人力老本和工夫都不是个别企业可能接受的。 aPaaS的长处是快、成本低，非技术人员就能够开发一套商业软件，在开发过程中可见即可得，方面随时调整。例如，国内的aPaaS平台明道云，一个销售总监可能在2个小时内搭建一套残缺的销售CRM管理系统，查看介绍视频。 成熟的aPaaS产品aPaaS的疾速发展期是在2016年左右，至今已有近百家厂商进入这个畛域。而在中小企业市场，国外倒退比拟快的厂商有：Redmine，Jira，Odoo，Smartsheet, Airtable和Zoho Creator，中国市场有简道云、明道云、氚云和搭档云等厂商。 图为用明道云搭建的销售CRM管理系统 aPaaS三个特色和对中小企业的益处尽管市面上曾经有不少SaaS通用解决方案，但中小企业目前依然面临以下挑战： 这些通用软件不是特地合乎本人企业的需要个性化需要反馈给厂商后，他们很难专为独自一个企业调整产品业务场景在变动，须要一直洽购新的软件产品，减少了估算这些软件之间的数据无奈买通，进步了IT运维老本对于中小企业而言，aPaaS的益处是不言而喻的，咱们来自认真看下aPaaS的三大次要特色： 零代码/低代码应用aPaaS的解决方案，非技术人员就能构建业务应用程序。 这些aPaaS厂商把开发软件所须要的权限、界面、数据、交互、流程形象进去，组成一套简略好用配置页面。即便没有丰盛的计算机专业常识和代码能力，在这些aPaaS平台中，任何人都能够创立一个有用的应用程序。 图为应用明道云的权限设置页面 零代码的益处是不言而喻的，以往须要数月或数年能力实现的软件开发我的项目，个别能够在几周甚至几天内实现。而依据Garter的调研，应用aPaaS工具节俭的人力费用可高达350％ 可扩展性aPaaS工具另一个特点是具备很高的拓展性。假如你利用某个平台开发了一套订单管理系统，前期发现须要减少新的工具。依照以往的做法，必定是找到技术人员，或者厂商帮你定制某个性能，然而在aPaaS平台中，你只须要找到一个纯熟业务的人员，即可在短时间内疾速让该性能上线。 另外，aPaaS工具都会提供API接口，可让技术人员进行更高级的开发，比方跟其余零碎进行对接。 云服务跟本地化软件相比，aPaaS天生就有云技术的劣势。这象征，你能够在多个设施、任何工夫拜访数据。同时，aPaaS厂商的IT运维能力也远远高于个别中小企业，保证数据的安全可靠。另外，在应用老本上，云服务的费用也远远低于本地开发。 aPaaS不适宜什么样的企业？aPaaS尽管领有微小的劣势，简直能满足所有行业和企业的所有IT需要。明道云创始人任向晖在他的文章《什么是零代码开发平台，为什么企业IT应该器重？》指出，aPaaS不适宜解决上面这些性质的需要。 1）行业有显著的专有特色 有些行业自身的专有化水平很高，而且企业之间的差异性不大，这时候垂直的行业利用可能更加正当。 围绕这个特色最典型的例子就是餐饮业和酒店业。所有餐饮业的经营逻辑都是相似的，除了单店和连锁可能应用不同复杂度的计划以外，利用模块都大同小异。而且，这个行业解决问题的办法和范式是有显著的行业特色的，比方餐厅的排队等座零碎，点单结账零碎等。aPaaS工具来构建如此专有的场景反而更加麻烦，而且无奈无效提供有行业特色的视图。 2）行业有独立的代码审计要求 金融等行业的外围业务零碎因为法规等要求不能应用零代码平台，因为它无奈满足代码审计的要求。aPaaS平台不肯定可能提供源代码给用户企业，而且即便提供，也无奈佐证利用零碎解决数据的准确性。这些行业因为监管要求高，自身资金也拮据，所以不会利用aPaaS计划在外围业务环节。 3）面向顾客的前台零碎 这个当然就是指的电商网店平台了。尽管电商批发的根本数据管理和aPaaS的能力并无太大的间隔，然而面向消费者的前台零碎个别要求更高的灵活性和营销设施的配套，用零代码平台创立不如间接应用专门的电商零碎，比方有赞、微盟等开店计划。它们提供的不仅仅是店面性能，还包含围绕顾客的营销服务和领取平台，这些是aPaaS所不善于的畛域。 aPaaS的将来第一个aPaaS平台于2005年推出，尔后产生了很大变动。新的技术改革和企业治理需要的变动赋予了aPaaS更大的设想空间。对于aPaaS，一个十分乏味的评估是：“你会发现aPaaS可能解决的问题，不止是你最后要解决的那一个问题” 看完本文，如果你想进一步理解aPaaS平台，欢送拜访明道云平台注册试用。

文/明道云创始人任向晖 咱们的业务过程中，不可避免地开始和开发者群体产生了一些抵触，更精确地说，是一些误会。对此，咱们也有思维筹备。 当然，可恶的程序员们往往都很宛转，他们不会说——“零代码平台有什么鸟用？如果不写代码就可能开发软件，还要咱们干吗？”。 他们不会说，但咱们心里晓得。当咱们向一位潜在顾客演示明道云后，我简直都能听到有几位程序员心里的想法。有时候，客户不同职能的人围绕是否要驳回零代码零碎当面争执起来，我也有点难堪。 有内部人士善意给咱们倡议将产品定位名称批改为“低代码”，而不要那么决绝地叫“零代码”。因为叫低代码，好歹不会让程序员群体过于恶感，感觉本人至多还有用武之地。 事实上，明道云也蕴含若干低代码模块，容许局部高级用户应用脚本语言来简化配置步骤，应用API来进行对接开发，这些都离不开训练有素的程序员。 但这不是重点，咱们想要达成的指标，是让现役程序员做点真正有价值的活，而把那些重复性的开发工作齐全削减。称为“零代码”，确实蕴含一些市场宣言的用意成分。 零代码平台代替哪些软件开发工作？概括来说，以明道云为代表的零代码平台次要用于企业中后盾应用领域，尤其是围绕数据管理和工作流相干的利用类别，他们个别都用于企业外部，有时候也会延长到内部客户和合作伙伴。这些利用都围绕数据的增删查改和灵便的工作流程治理而建设，用户通过浏览器和挪动设施进行应用。 这段概括确实曾经将企业软件行业中的很多场景都包含在内了。为了让读者更好了解，我再例举一些更为具体的场景： 1）基于关系数据库的业务管理利用 是指不同行业围绕着外围业务构筑的业务管理系统，例如： 流通业的进销存制造业的生产执行、物料治理、设施治理古代服务业的项目管理教育行业的师资、学员、课程管理设施工程业的洽购、装置和服务治理个别B2B行业的销售治理等等这个大类别中大多数软件都长得简直截然不同。在Web版本上，往往通过顶部和左侧菜单进行性能导航，主界面用表格列出数据条目，关上记录详情能够进行各种数据操作，查看关联数据。 正是因为这样的雷同度，所以零代码平台能够大显神通，将所有这些利用的实现用一个对立的组装形式来实现，从而防止从头至尾的原生软件开发过程。 2）利用挪动利用采集数据的利用 制作、工程、批发等行业须要特定职能人员从一线采集数据的利用场景。 3）利用API接口写入数据并构筑治理看板的利用 从多个异构零碎抽取数据，积淀到对立的数据中台，并联合本产品的自定义仪表盘性能构筑治理驾驶舱的利用需要。这个利用场景用另外一种形式代替了BI+ETL的计划。 4）部门级解决特定业务环节需要的小利用 因为零代码零碎带来的易用性和罢黜代码开发的特点，用户企业能够由业务部门的非开发人员间接搭建或者主导一些简略的小利用。在对立的利用治理能力下，同时也能防备影子IT问题。 5）为实现流程自动化而构建的利用 基于本产品的自动化工作流，能够买通过来须要人工协调的断续工作流程，例如： 订单、交付和发票的主动连接基于工夫触发的检查单生成、设施维保揭示、合同到期揭示等基于销售流程和营销流程之间的线索主动标签和线索培养等6）为实现数据流转、填报和审核过程而构筑的流程利用 在简单的数据协同中，构筑基于表单数据，审批和填写节点的人工控制工作流利用。 零代码不善于的场景除了这些侧面领域，也有一些负面清单。意思是零代码平台并不长于解决的场景也有很多，比方： 1）市场规模微小，场景统一，通用水平很高的品类 比方合作利用，通信利用。当然，因为这些市场容量微小，也曾经有大量的成熟厂商在提供产品。你齐全没有必要去用零代码去搭建。如果你要参加这些市场的竞争，理当领有一支技能欠缺的软件产品研发团队，能力对市场竞争做出及时的响应。 2）在特定行业中依赖十分专有化的计算或专有化的视图来提供服务的门类 例如酒店行业的动静房价治理，餐饮业的收银排桌，围绕生产制作的工业管制和非凡逻辑排程，围绕市场营销指标的广告数据管理等等。这就像要拧无数颗直径固定为3毫米的螺母，就没有必要用万能扳手。 3）面向消费者的利用 这个很好了解，2C利用是非常多元的，很难通过零代码的形式来实现。当然，那些简略的信息展现类或者购物车类的小程序利用另当别论。很多小程序生成平台，实质上也是一种零代码平台。 我置信这个清单并没有完，这个市场总是存在各种各样非凡状况的长尾，以至于每一个零星需要都不得不专门来进行架构，设计和开发。 零代码为什么比写代码还要好？一旦你要实现的场景和咱们的劣势方向吻合，那么我敢说，用零代码平台搭建的利用，要比绝大多数一般软件开发团队开发进去的利用要好得多。 我这么说，可能有点不礼貌了，但咱们都得主观一些，优良和卓越的软件开发团队总是无限的，他们不会天天在开发增删查改数据的企业应用。这些活交给咱们比拟适合。 1）罢黜交互体验设计流程 零代码平台承当了根本交互设计的全副工作，围绕数据输出，查问，展现等一系列动作。利用零代码平台后，不须要再进行这些细枝末节的交互体验设计和加强。 比方：一个简单表单的每个控件，应该用什么款式，放弃什么间距，支不反对键盘切换焦点等等，这些细节问题往往消耗前端程序员大量的重复劳动。 当初，都不必了。咱们的一次性范式设计通通思考在内了。 有人说，如果不能个性化设计前端页面，那做进去的利用岂不是很雷同。确实是这样，但这种雷同是好的反复，而不是粗俗的复制。 咱们能够为一个日期输出控件消耗几天的工夫来优化，这并不是所有的利用前端开发所可能承当的老本。 而且，即使你不必零代码平台，在利用前端框架时，也相对不可能本人从头开始设计，总是会利用一些现成的成熟框架。君不见各种后盾零碎应用的简直都是阿里Ant的那一套？ 在企业中后盾利用中，界面难看，性能好用是最重要的指标。所以，高质量的雷同正是解决这个问题的伎俩。 2）罢黜后端架构流程 前端开发容易产生反复工作，后端数据架构也是一样。为了让一个企业应用可能满足业务数据管理和工作流程的须要，开发者须要设计正确正当的数据结构。这个工作，无论是零代码，还是传统的原生开发都是须要的。 然而，除了数据模型外，原生开发我的项目还须要架构师设计正当的数据存储过程和函数（可反复利用的程序结构），这些工作都是依赖经验丰富的架构师的。 有了零代码平台，所有的后端架构工作被转化成可视化的配置过程，数据结构依附表单来建设，工作流依附触发器和节点来配置，权限零碎依附角色和颗粒度很高的权限细节来组合。 这些工作尽管不会主动实现，但它们曾经不再依赖广义的软件架构师，实现这些工作的工夫老本也大大降低。 这里还要提到一个重要因素，那就是业务变更所带来的后端架构调整噩梦。 一旦业务流程产生新的需要，绝大多数状况下都不是简略地批改几行前端代码可能搞定的，后端架构都须要配合进行调整。 在过来，这是很多定制开发软件我的项目的危机所在，因为往往须要的时候找不到人，或者找不到健全的文档，导致后续跟进的批改中重叠出越来越多的低质量代码。 有零代码零碎，无非就是调整一下配置就可能实现。这是原生开发永远难以企及的成果。 3）简化测试流程 零代码搭建的利用也要测试，但用户只须要聚焦在数据处理的正确性上，一次对，次次对。 传统软件的测试要简单得多，首先要有开发人员本人实现的白盒测试，还须要有需求方和测试人员独特编写黑盒测试用例清单。 光这一件事件就依赖业余人员，老本很高，而且有很麻烦的跨专业沟通。残缺的测试还须要涵盖性能，兼容性等方面，相当地耗时耗力。 所以大部分定制软件开发是没有强壮的测试流程的。作为只有一个用户的定制软件，软件缺陷的打消过程十分漫长。 4）罢黜利用散发 开发曾经掉了一层皮，但一个最终可用的企业应用，为了可能地让员工开始失常应用，还有一个“在组织内散发”的过程。 这个过程通常都比设想的简单，尤其是那些须要依据不同角色调配不同权限的简单零碎。在软件开发结束后，还须要疏导用户注册账户，调配角色后，用户才真正可能登录零碎应用。 目前，越来越多的企业曾经开始应用钉钉和企业微信等平台，这意味着，开发进去的企业应用最好还可能适配这些平台，至多实现用户账户和音讯告诉的买通。 零代码零碎个别都带有欠缺的企业治理后盾，提供用户，部门，职能角色，汇报关系配置，还事后和钉钉和企业微信等平台接通。 这样，用零代码形式搭建的利用不仅交付迅捷，部署到用户那里也很不便。如果某个利用的角色须要对应企业的财务出纳，配置好当前，只有有人入职了财务出纳岗位，就可能主动失去这个利用的拜访权和失当的权限。 5）让需要沟通更轻松 ...

前言： -更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 （文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index 前言 在市场营销中，数据迷信的次要指标是将数据转化为可行的口头。大数据为销售提供了更好地理解指标受众提供的能力。 数据迷信次要利用于概要剖析，搜索引擎优化，客户参加，响应能力，实时营销流动等营销畛域。而且，每天都会呈现将数据迷信和剖析利用于营销的新办法。 六大数据迷信用例用户分群所有客户都是独立的个体。因而，「一刀切」的办法基本有效。 在这种状况下，用户分群能够帮忙营销人员依据特定的特色将客户进行正当的划分。 有两种最罕用的细分类型： 普通用户分群——通过剖析用户属性与行为特色预测用户分群——通过机器学习算法预测事件概率用户分群的细分仿佛在市场营销中出现一种回升趋势。用户的细分有助于将人们划分为更准确的类别，尤其是与行为用意无关的类别。因而，即便是很少数量的客户群，也能够针对他们的爱好定制营销流动。 实时剖析实践证明，实时剖析可立刻反馈营销流动的成绩。因为社交媒体和通信技术的遍及，实时营销将被利用得越来越宽泛。 高效的实时数据能够为公司带来可观的增长。 实时算法次要解决两组数据：客户数据和经营数据。客户数据可洞悉客户的需要，偏好和需要。经营数据反映了客户做出的各种交易，动作和决策。实时数据分析的利用为营销流动带来了效率，速度和高性能。 预测剖析目前，即便对于中型公司，数据也很容易获取和应用。预测剖析是统计和机器学习算法的利用，以概率预测将来。在市场营销中预测剖析的机会很多。 可能能够作用于以下几个方向： 客户行为的预测剖析客户的购买力预测热销产品预测智能举荐智能举荐是功能强大的工具，旨在为客户提供个性化的体验和较高的满意度。 智能举荐是将产品与客户的偏好与他或她喜爱的性能等相匹配。为此，智能举荐通常应用以下模型和算法：回归，决策树，K近邻，神经网络等。 在电商中智能举荐将作为做次要的营销伎俩。 购物篮剖析购物篮剖析就是通过购物篮子所显示的信息来钻研顾客的购买行为。 次要的目标在于找出什么样的货色应该放在一起。 藉由顾客的购买行为来理解是什么样的顾客以及这些顾客为什么买这些产品，找出相干的联想规定，企业藉由这些规定的开掘取得利益与建设竞争劣势。 举例来说，_零售店可藉由此剖析扭转置物架上的商品排列或是设计吸引客户的商业套餐_等等。 而且，购物篮剖析能够显着进步营销信息的效率。除了营销信息的类型之外，无论是间接报价，电子邮件，社交媒体，电话还是新闻通讯，您都能够提供适宜特定客户的产品。 用户价值RFM是互联网行业最常见的客户价值指标分级，依据最近的购买工夫，购买的频率和购买金额这三个维度将客户分为8类，对于重要价值客户是要做好重点保护的，对于一些后劲客户要做好激活，对于快要散失客户要做好挽留，最重要的是须要依据客户的价值分类对各类客户做好不同的动作，实现客户价值实现的最大利益化。 当然，也能够退出，响应能力、购买历史、偏好、拜访、喜爱、分享甚至他们常常浏览的内容等作为掂量维度。 数据中台是企业数智化的新基建，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云数据中台解决方案对外输入，包含批发、金融、互联网、政务等畛域，其中外围产品有： Dataphin，一站式、智能化的数据构建及治理平台；Quick BI，随时随地 智能决策；Quick Audience，全方位洞察、全域营销、智能增长；Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；官方站点： 数据中台官网 https://dp.alibaba.com

数字经济时代，计算、剖析、解决等作为“要害生产因素”已成为行业和社会的共识。然而对于交通畛域而言，以往端到端的形式进行平台搭建和利用开发已不能适应数字爆炸和产品疾速迭代的要求。交通行业在计算剖析方面面临着信息采集难、款式杂、变动快、价值低、利用难度低等诸多痛点。总结而言，次要体现在4个方面： （1）交通业务零碎互相独立，数据孤岛景象重大，业务解决容量大然而无统一标准，采集的字段凌乱，难以了解和利用？ （2）先前曾经搭建了交通大数据平台，然而不足行业知识库，计算剖析能力弱，数据只是简略地BI展示，不能赋能业务翻新？ （3）业务部门多，资源接口凌乱，复用性差，每次调用计算都须要开发新的接口，费时费力？ （4）数字零散，全域交融难，不足计算价值开掘，并且未和公众服务平台买通，交通相干APP用户量太少，不能从根本上解决“市民出行难”的问题？ 那么，如何用新一代信息技术伎俩买通交通业务之间的内在联系，晋升交通部门的协同效率？如何建成一个交通智能剖析的全流程平台，实现交通系统上云、治理、剖析、决策、后果展示等性能？这是咱们探讨和解决的内容，以更好地撑持交通管理部门晋升效力。 数据中台是交通行业数字化转型的最佳门路 交通体系是一个简单的零碎，笼罩的场景丰盛，关涉的业务宽泛，行政治理关系归口多，不仅有公路、铁路、水运、航空等行业线，执法、车管等职能线，还有区县、市级、省级等区域线。从组织架构上来看，管辖范畴和侧重点不同，计算协同与利用自身就是一个微小的挑战。 如何让纷繁复杂的计算为业务场景服务，为交通治理提效？从以后的技术、业务和实际来看，“数据中台”是应答挑战的最佳门路，它以信息充沛共享、资源高度交融、信息深度开掘、部门协调联动为外围，通过构建一套大数据技术体系和对立的计算资源池，帮忙交通企业疾速推动施行数字化转型策略。 数据中台概念首次被阿里提出时是在2015年, 其定位就是紧贴业务，集方法论、工具、组织于一体的“快、准、全、统、通”的智能体系。历经外部简单场景的实际后,在2018年正式通过阿里云全面对外输入数据中台能力,帮忙企业实现数智化转型。在2020阿里云线上峰会上, 阿里云智能总裁张建锋示意，阿里云将会做深根底，做厚中台，做强生态，有信念真正做好数字经济时代的基础设施。这标记着阿里云进一步把数据中台引入全速重构业务数智化的深地。 从“首次提出”到“全速重构”，阿里云数据中台累积了丰盛的教训。而在交通畛域，数据中台越来越受到重视，交通企业通过构建交通数据中台，能够造成数字资产，对业务方提供高价值、高可靠性、高效率、低成本、少节约的的共享多样计算服务，疾速撑持百花齐放的利用。 阿里云交通数据中台解决方案提供从交通信息接入到计算利用的全链路智能资源构建与治理能力，帮忙交通客户突破信息孤岛、交融全域信息，在把资源对立之后，会疾速造成数据资产、开掘计算价值，进而赋能交通业务，为客户提供高效服务。这些服务跟交通客户的业务有较强的关联性，是交通企业业务和资源的积淀，其不仅能升高反复建设、缩小烟囱式合作的老本，也是差异化竞争劣势所在，助力交通行业数字化转型及智能利用的翻新和推广。 3大次要利用场景：自在流免费稽核、交通态势感知、ETC用户经营 （1）合纠偏，对立路网表白，全量轨迹实时还原，实现最精准、全面、实时的免费稽核后果。 （2）交通态势感知：基于视频、地图和人工录入事变等数据，对路线状况进行实时感知，并对事变进行智能剖析解决。 （3）ETC客户经营：ETC客户数字化经营，与异业协同共赢，共建会员生态，实现体验晋升、穿插销售、协同获客、会员互认、权利互通等服务。 5大外围劣势：数据中台建设+施行的方法论和解决方案 基于长期的最佳实际，阿里云积淀了一整套数据中台建设+施行的方法论和解决方案，该解决方案具备5大外围劣势： （1）对立的数据集成治理：对立集成治理不同起源、格局、特点性质的资源，从而为企业提供全面的资源共享。 （2）高效的内容加工、服务能力：全域计算剖析主题和场景设计，依据应用领域和类别，联合业务流程中的理论痛点和问题，确定剖析洞察主题、相应的剖析场景及外围的剖析维度和指标。 （3）端到端的行业数据安全策略：提供计算辨认、敏感信息发现、信息分类分级、脱敏、拜访监控、危险发现预警与审计能力，进步信息安全等级，便于进行信息权限管控。 （4）提供丰盛的交通行业知识库/模型：通过多年在城市大脑、智慧高速等我的项目上的积攒，再加上对交通信息建模畛域的深入研究，积淀了丰盛的交通算法模型，涵盖交通态势感知、调度优化、仿真预测、免费稽核等多个畛域。 （5）高效的全域信息共享替换：通过全域信息共享替换平台升高交通业务对技术的依赖，晋升交通信息生产体验和效率，充分发挥交通业务翻新潜能，提供交通数据资产变现能力。 5大外围价值：让大数据真正驱动客户业务 （1）开发更简略：中台提供的各种工具产品可能极大的简化开发过程，缩短治理周期，升高治理老本。 （2）服务更便捷：可能赋予数据以业务价值，让各级用户可能直观的了解，并以此为根底向利用输入计算服务。 （3）利用更智能：通过一直晋升数字面向业务的价值，积攒积淀业务模型，可能向下层利用提供更加智能的信息计算。 （4）资产更清晰：从宏观到宏观助力资源管理方全面盘点数据资产，理清策略资源，做到让管理者成竹在胸。 （5）经营更高效：遵循利用后行、以用带存、由存而通、因通促用的理念，实现城市智能化经营，驱动客户业务翻新。 在交通行业中，阿里云不仅具备成熟的方法论和工具，还联结高德、支付宝、阿里达摩院等，形成了一个外部协同生态，内部也踊跃与生态搭档开展单干，全方位浸透交通各个领域和场景，是建设智能计算和催生智能剖析的引擎。 将来，阿里云交通数据中台解决方案将发力高速公路、大中型机场、汽车制造商、大型港口以及城市的市内交通等各个领域，以数据产品+数据技术+方法论+场景实现的综合性输入，构建新一代交通数字化基础设施，推动交通智能化计算、技术极致晋升和智能化业务的翻新摸索，为交通建设及城市倒退注入智能化的新动力。 阿里云智慧交通对立门户正式上线

作者：王庆璨 张凯 进击的Kubernetes调度零碎（一）：Scheduling Framework 进击的Kubernetes调度零碎（二）：反对批工作的Coscheduling/Gang scheduling 前言首先咱们来理解一下什么是Coscheduling和Gang scheduling。Wikipedia对 Coscheduling的定义是“在并发零碎中将多个相关联的过程调度到不同处理器上同时运行的策略”。在Coscheduling的场景中，最次要的准则是保障所有相关联的过程可能同时启动。避免局部过程的异样，导致整个关联过程组的阻塞。这种导致阻塞的局部异样过程，称之为“碎片（fragement）”。 在Coscheduling的具体实现过程中，依据是否容许“碎片”存在，能够细分为Explicit Coscheduling，Local Coscheduling和Implicit Coscheduling。 其中Explicit Coscheduling就是大家常听到的Gang Scheduling。Gang Scheduling要求齐全不容许有“碎片”存在， 也就是“All or Nothing”。 咱们将上述定义的概念对应到Kubernetes中，就能够了解Kubernetes调度零碎反对批工作Coscheduling的含意了。 一个批工作（关联过程组）包含了N个Pod（过程），Kubernetes调度器负责将这N个Pod调度到M个节点（处理器）上同时运行。如果这个批工作须要局部Pod同时启动即可运行，咱们称需启动Pod的最小数量为min-available。特地地，当min-available=N时，批工作要求满足Gang Scheduling。 为什么Kubernetes调度零碎须要Coscheduling？Kubernetes目前曾经宽泛的利用于在线服务编排，为了晋升集群的的利用率和运行效率，咱们心愿将Kubernetes作为一个对立的治理平台来治理在线服务和离线作业。默认的调度器是以Pod为调度单元进行顺次调度，不会思考Pod之间的互相关系。然而很多数据计算类的离线作业具备组合调度的特点，即要求所有的子工作都可能胜利创立后，整个作业能力失常运行。如果只有局部子工作启动的话，启动的子工作将继续期待残余的子工作被调度。这正是Gang Scheduling的场景。 如下图所示，JobA须要4个Pod同时启动，能力失常运行。Kube-scheduler顺次调度3个Pod并创立胜利。到第4个Pod时，集群资源有余，则JobA的3个Pod处于空等的状态。然而它们曾经占用了局部资源，如果第4个Pod不能及时启动的话，整个JobA无奈胜利运行，更蹩脚的是导致集群资源节约。 如果呈现更坏的状况的话，如下图所示，集群其余的资源刚好被JobB的3个Pod所占用，同时在期待JobB的第4个Pod创立，此时整个集群就呈现了死锁。 社区相干的计划社区目前有Kube-batch以及基于Kube-batch衍生的Volcano 2个我的项目来解决上文中提到的痛点。实现的形式是通过开发新的调度器将Scheduler中的调度单元从Pod批改为PodGroup，以组的模式进行调度。应用形式是如果须要Coscheduling性能的Pod走新的调度器，其余的例如在线服务的Pod走Kube-scheduler进行调度。 这些计划尽管可能解决Coscheduling的问题，然而同样引入了新的问题。如大家所知，对于同一集群资源，调度器须要中心化。但如果同时存在两个调度器的话，有可能会呈现决策抵触，例如别离将同一块资源分配给两个不同的Pod，导致某个Pod调度到节点后因为资源有余，导致无奈创立的问题。解决的形式只能是通过标签的模式将节点强行的划分开来，或者部署多个集群。这种形式通过同一个Kubernetes集群来同时运行在线服务和离线作业，势必会导致整体集群资源的节约以及运维老本的减少。再者，Volcano运行须要启动定制的MutatingAdmissionWebhook和ValidatingAdmissionWebhook。这些Webhooks自身存在单点危险，一旦呈现故障，将影响集群内所有pod的创立。另外，多运行一套调度器，自身也会带来保护上的复杂性，以及与上游Kube-scheduler接口兼容上的不确定性。 基于Scheduling Framework的计划本系列第一篇《进击的Kubernetes调度零碎 （一）：Scheduling Framework》介绍了Kubernetes Scheduling Framework的架构原理和开发方法。在此基础上，咱们扩大实现了Coscheduling调度插件，帮忙Kubernetes原生调度器反对批作业调度，同时防止上述计划存在的问题。Scheduling framework的内容在前一篇文章具体介绍，欢送大家翻阅。 Kubernetes负责Kube-scheduler的小组sig-scheduler为了更好的治理调度相干的Plugin，新建了我的项目scheduler-plugins治理不同场景的Plugin。咱们基于scheduling framework实现的Coscheduling Plugin成为该项目标第一个官网插件，上面我将具体的介绍Coscheduling Plugin的实现和应用形式。 技术计划总体架构 PodGroup咱们通过label的模式来定义PodGroup的概念，领有同样label的Pod同属于一个PodGroup。min-available是用来标识该PodGroup的作业可能正式运行时所须要的最小正本数。 labels: pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu pod-group.scheduling.sigs.k8s.io/min-available: "2"备注: 要求属于同一个PodGroup的Pod必须放弃雷同的优先级 PermitFramework的Permit插件提供了提早绑定的性能，即Pod进入到Permit阶段时，用户能够自定义条件来容许Pod通过、回绝Pod通过以及让Pod期待状态(可设置超时工夫)。Permit的提早绑定的性能，刚好能够让属于同一个PodGruop的Pod调度到这个节点时，进行期待，期待积攒的Pod数目满足足够的数目时，再对立运行同一个PodGruop的所有Pod进行绑定并创立。 举个理论的例子，当JobA调度时，须要4个Pod同时启动，能力失常运行。但此时集群仅能满足3个Pod创立，此时与Default Scheduler不同的是，并不是间接将3个Pod调度并创立。而是通过Framework的Permit机制进行期待。 此时当集群中有闲暇资源被开释后，JobA的中Pod所须要的资源均能够满足。 则JobA的4个Pod被一起调度创立进去，失常运行工作。 QueueSort因为Default Scheduler的队列并不能感知PodGroup的信息，所以Pod在出队时处于无序性(针对PodGroup而言)。如下图所示，a和b示意两个不同的PodGroup，两个PodGroup的Pod在进入队列时，因为创立的工夫交织导致在队列中以交织的顺序排列。 当一个新的Pod创立后，入队后，无奈跟与其雷同的PodGroup的Pod排列在一起，只能持续以凌乱的模式交织排列。 这种无序性就会导致如果PodGroupA在Permit阶段处于期待状态，此时PodGroupB的Pod调度实现后也处于期待状态，互相占有资源使得PodGroupA和PodGroupB均无奈失常调度。这种状况即是把死锁景象呈现的地位从Node节点挪动到Permit阶段，无奈解决前文提到的问题。 针对如上所示的问题，咱们通过实现QueueSort插件， 保障在队列中属于同一个PodGroup的Pod可能排列在一起。咱们通过定义QueueSort所用的Less办法，作用于Pod在入队后排队的程序： ...

6月16日，2020阿里云合作伙伴峰会上，阿里云发表深耕“被集成”策略，做强生态，将来一年投入20亿专项资金，助力50家搭档云上营收过亿。据悉，到目前为止，阿里云与合作伙伴已公布500多款联结解决方案，笼罩30多个重点细分行业，一批搭档在阿里云上已营收过亿。 近日，作为国内当先的企业级视频直播营销云微吼发表：正式入驻阿里云云市场，进一步加深与阿里云SaaS生态单干。 微吼会成为阿里云的单干对象绝非偶尔。作为国内企业级视频直播营销云的引领者，微吼成立于2010年，在2013年开发了专门针对中小企业的SaaS平台，为企业量身订做专属直播间，让企业能够间接在微吼网站做流动预报、邀请，发动流动直播以及进行全维度的数据统计和剖析，致力于解决中小企业的营销痛点。 基于对行业的十年深耕，微吼通过视频互动技术，以数据技术+AI为依靠，目前已造成平台化PaaS服务(微吼云)、场景化SaaS 服务(微吼直播+微吼课堂+微吼现场+微吼知客)和整体化解决方案(行业解决方案+场景解决方案)三大产品矩阵，构建了全场景多层次的业务体系，能够为不同类型的企业提供定制化视频直播服务，实现对内降本增效，对外发明营收，全方位赋能企业数字化转型。5月26日，36氪研究院公布《2020年中国企业直播钻研报告》（以下简称报告），微吼以当先技术和优质服务博得行业及企业客户认可，成为独占第一梯队的企业直播服务商。 对于企业客户而言，微吼的劣势不仅在当先的直播技术，更重要的是涵盖直播前中后的残缺营销业务链，以及多年来积淀的对不同类型行业、不同规模企业的直播营销需要的深度了解。 在退出阿里云SaaS生态营垒后，微吼将继续为企业客户提供优质的SaaS直播产品及服务，赋能企业数字化营销。接下来微吼将全面凋谢旗下直播产品，依靠阿里云的技术和平台反对，为企业的直播营销提供一站式解决方案。阿里云+微吼的劣势叠加，一方面为企业提供了高质稳固、安全可靠的直播技术，一方面升高了企业直播的老本，拓宽了营销的渠道，助力企业降本增效，减速转型数字化。将来，单方将就直播技术、云计算、企业服务等方面开展深度单干，为更多企业用户提供产品与服务，协力推动企业直播营销云生态的共建和倒退。 微吼负责人示意，通过退出阿里云SaaS加速器，与阿里云当先的技术绝对接、交融，独特摸索SaaS开放平台和生态能力，微吼将以更快的速度降级技术与服务。借助阿里云平台的力量，微吼也将在客户规模、市场拓展、技术打磨、产品服务能力等畛域实现新冲破，在产业互联网时代，深度赋能企业用户，减速数字化、智能化过程。

作者 | 孤弋  阿里云高级技术专家，负责 EDAS 的开发和用户体验优化工作。 前言近年来，云原生、Kubernetes、微服务、SpringCloud 这些名词在技术圈内不绝于耳，数据显示，应用 SpringCloud 作为微服务的框架，同时抉择 Kubernetes 作为利用与基础设施运维底座的团队越来越多，这二者的搭档基本上成为了业界的支流配搭。 为了适应这一趋势，EDAS 也紧紧围绕这一典型场景，对它的开发、测试、部署、联调、线上运维等诸多环节中的开发者体验进行深度打磨，公布了全新的 3.0 版本。同时，针对如何在采纳了 SpringCloud + Kubernetes 架构的利用上应用 EDAS，咱们团队提供各个环节的最佳实际，供开发者参考。 本篇进入咱们的第一章节：开发。 初始化我的项目阿里巴巴从 2018 年开始开源了以原阿里团体中间件为次要能力、全方位对标 SpringCloud Netflix 的全家桶服务，也就是目前的 Spring Cloud Alibaba 我的项目(https://github.com/alibaba/spring-cloud-alibaba)，通过两年多的倒退，这个我的项目受到了越来越多开发者的青睐，目前的 star 数也达到了 14K。 不过对于开发者而言，抉择变多的同时，往往也会随同一些懊恼，比方：咱们到底须要应用什么版本？如何抉择依赖的服务？如何解决公共组件的抵触问题？为了解决这些问题，阿里云去年上线了一款我的项目初始化工具(http://start.aliyun.com) ，如下图： 咱们通过这个页面提供了一个生成 Java 利用（不只是 SpringCloud 利用）的白屏化工具，对于一个最简略的 Spring Cloud 利用，只有一项是您必须要抉择的依赖，就是 Spring Cloud Alibaba 选项卡下的 Nacos Service Discovery 组件。选中之后，点击按钮组中橙色的 “生成” ，工具会依据所需的依赖主动生成一份可间接打包运行的 pom.xml 文件，同时将所有内容打成一个规范的 Java 我的项目工程包供您下载。 在本地跑起来下载完生成的我的项目工程之后，对于惯例 Spring Cloud 利用开发开发流程，下一步是须要去找一个（或本地搭建一个）注册核心（如：Nacos），这个过程往往是须要破费肯定工夫的。去年年底咱们在阿里云的 IDE 插件 Cloud Toolkit 中开发了一个主动拉起/抉择注册核心， 并将利用主动适配到所抉择的注册核心的性能。界面如下图： ...

2020年5月28日，驻云发表与阿里云智能深入策略单干，单方将携手推动更多企业采纳云计算和智能技术进行数字化转型。在产品技术层面，驻云将以DataFlux为根底，为更宽泛的行业和企业提供残缺的数字化转型解决方案和服务。 自2013年来，驻云与阿里云智能严密单干，为阿里云智能用户提供欠缺的云计算服务。2019年，驻云基于阿里云智能开发的新一代实时监控数据分析平台DataFlux，成为阿里云智能心选产品。DataFlux通过对任何起源、类型、规模的实时数据进行监控、剖析和解决，开释数据价值，帮忙企业从数据中洞察业务并无效预测，进而做出决策并采取行动，利用实时数据驱动商业将来。 DataFlux是集成阿里云智能公共云，边缘云，专有云，容器服务，时序数据库，剖析型数据库，以及DataV等技术的新一代面向数据的实时剖析平台，能够广泛应用于各行各业的监控及实时数据分析场景的高可定制化的PaaS/SaaS产品，提供十分弱小的计算能力和产品能力，并且可能无效的和阿里云智能其余产品疾速组合造成一体化的解决方案。 驻云CEO蒋烁淼认为：“咱们的使命始终是为中国的企业用户提供基于云计算大数据的产品与服务，而此刻与阿里云智能深入策略单干，符合中国逐渐成熟的云计算用户的诉求，让更多用户享受到阿里云智能根底能力组合后的想象力。除了DataFlux，驻云还将致力基于集成阿里云智能的技术提供更加优良的产品与服务。” 阿里云智能副总裁李津强调：“驻云是阿里云智能的重要生态合作伙伴，咱们将会持续反对驻云倒退，与驻云新的产品单干将给阿里云智能的客户带来更多价值。咱们心愿更多的合作伙伴能在阿里云智能的技术根底上构建更丰盛的产品与解决方案，帮忙客户解决业务上的问题。” 阿里云网站负责人毕玄示意：“很快乐驻云的DataFlux成为阿里云心选产品，阿里云心选是阿里云智能联结合作伙伴施展各自劣势为中国宽广企业客户提供优良产品的平台。驻云的DataFlux作为心选重点引入的产品，这次的策略协定的签订，标记着阿里云智能更凋谢的生态策略和致力于为客户提供优质的产品和解决方案。” 将来，驻云将施展本身积攒的丰盛云服务教训劣势，与阿里云智能持续深入策略单干，造成更多、更贴近客户需要的解决方案及服务，进一步助力中国各行各业实现数字化与智能化倒退。

前言： -更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 （文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index（作者：qingliang_hu） 定义APP埋点主动采集是指用户在APP内的操作行为主动采集并上报日志，其体现在APP上的元素（按钮、图片等）的行为次要分为点击和曝光行为。 其中曝光意为该元素在可视区域停留时长达到肯定阈值，即标记为一次曝光行为。 本文次要定位为对Andorid端外部主动采集技术的原理分析。 外围原理支流的Android端的事件监听机制次要有Listener代理，Hook，AccessibilityDelegate，dispatchTouchEvent四种监听形式，上面将简要总结四种形式的具体实现。 （此处不介绍采纳AspectJ框架编译期注入代码形式实现监听，次要起因在于此形式相对而言太暴力，业务侵入性太强，很难在业务方APP上进行推广和实现，感兴趣的可自行Google/Baidu。） Listener代理 在Android中，对于事件的监听及逻辑解决次要通过对View.onClickListener中的onClick办法进行覆写，如 View saveView = findViewById(R.id.btnSave); saveView.setOnClickListener(new OnClickListener() {@Override public void onClick(View v) { //TO DO } }); 因而，能够通过自定义监听代理类ProxyListener，实现View.OnClickListener中的onClick办法，将控件的onClickListener对立替换成ProxyListener，从而实现点击监听和日志上报。代码如下： ProxyListener监听代理类： public abstract class ProxyListener implements View.OnClickListener{ @Overridepublic void onClick(View view) { // doOnClick为业务方控件点击事件的逻辑实现 doOnClick(view); sendLog(view)； }protected void sendLog(View view) { //TODO:detail of sendLog(), based on Thread Runnable runnable = new Runnable() { @Overrid public void run() { //TODO:do send log } }; Thread thread = new Thread(runnable); thread.start();}protected abstract void doOnClick(View view);} ...

作者：王庆璨 张凯 前言Kubernetes曾经成为目前事实标准上的容器集群治理平台。它为容器化利用提供了自动化部署、运维、资源调度等全生命周期治理性能。通过3年多的疾速倒退，Kubernetes在稳定性、扩展性和规模化方面都有了长足进步。 尤其是Kubernetes管制立体的外围组件日臻成熟。而作为决定容器是否在集群中运行的调度器Kube-scheduler，更是因为长久以来体现稳固，且已能满足大部分Pod调度场景，逐步不被开发人员特地关注。 随同着Kubernetes在私有云以及企业外部IT零碎中广泛应用，越来越多的开发人员尝试应用Kubernetes运行和治理Web利用和微服务以外的工作负载。典型场景包含机器学习和深度学习训练任务，高性能计算作业，基因计算工作流，甚至是传统的大数据处理工作。此外，Kubernetes集群所治理的资源类型也更加丰盛，不仅有GPU，TPU和FPGA，RDMA高性能网络，还有针对畛域工作的各种定制加速器，比方各种AI芯片，NPU，视频编解码器等。开发人员心愿在Kubernetes集群中能像应用CPU和内存那样简略地申明式应用各种异构设施。 总的来说，围绕Kubernetes构建一个容器服务平台，对立治理各种新算力资源，弹性运行多种类型利用，最终把服务按需交付到各种运行环境（包含公共云、数据中心、边缘节点，甚至是终端设备），未然成为云原生技术的发展趋势。 阿里云容器服务团队联合多年Kubernetes产品化与客户反对教训，对Kube-scheduler进行了大量扩大和改良，逐渐使其在多种场景下仍然能稳固、高效地调度简单工作负载类型。 《进击的Kubernetes调度零碎》系列文章将把咱们的教训、技术思考和实现细节全面地展示给Kubernetes用户和开发者，冀望帮忙大家更好地理解Kubernetes调度零碎的弱小能力和将来倒退方向。 晚期计划首先，让咱们来理解一下Kubernetes社区都有过哪些晋升调度器扩大能力的计划。 要对立治理和调度异构资源与更多简单工作负载类型，首先面对挑战的就是Kube-scheduler。在Kubernetes社区里对于晋升调度器扩大能力的探讨始终一直。sig-scheduling给出的判断是，越多功能退出，使得调度器代码量宏大，逻辑简单，导致保护的难度越来越大，很多bug难以发现、解决。而对于应用了自定义调度的用户来说，跟上每一次调度器性能更新，都充斥挑战。 在阿里云，咱们的用户遇到了同样的挑战。Kubernetes原生调度器循环解决单个Pod容器的固定逻辑，无奈及时、简略地反对用户在不同场景的需要。所以针对特定的场景，咱们会基于原生Kube-scheduler扩大本人的调度策略。 最后对于Kube-scheduler进行扩大的形式次要有两种，一种是调度器扩大（Scheduler Extender）， 另外一种是多调度器（Multiple schedulers）。接下来咱们对这两种形式别离进行介绍和比照。 Scheduler Extender社区最后提供的计划是通过Extender的模式来扩大scheduler。Extender是内部服务，反对Filter、Preempt、Prioritize和Bind的扩大，scheduler运行到相应阶段时，通过调用Extender注册的webhook来运行扩大的逻辑，影响调度流程中各阶段的决策后果。 以Filter阶段举例，执行过程会通过2个阶段: scheduler会先执行内置的Filter策略，如果执行失败的话，会间接标识Pod调度失败。如何内置的Filter策略执行胜利的话，scheduler通过Http调用Extender注册的webhook, 将调度所须要的Pod和Node的信息发送到到Extender，依据返回filter后果，作为最终后果。 咱们能够发现Extender存在以下问题: 调用Extender的接口是HTTP申请，受到网络环境的影响，性能远低于本地的函数调用。同时每次调用都须要将Pod和Node的信息进行marshaling和unmarshalling的操作，会进一步升高性能。用户能够扩大的点比拟无限，地位比拟固定，无奈反对灵便的扩大，例如只能在执行完默认的Filter策略后能力调用。基于以上介绍，Extender的形式在集群规模较小，调度效率要求不高的状况下，是一个灵便可用的扩大计划，然而在失常生产环境的大型集群中，Extender无奈反对高吞吐量，性能较差。 Multiple schedulersScheduler在Kubernetes集群中其实相似于一个非凡的Controller，通过监听Pod和Node的信息，给Pod筛选最佳的节点，更新Pod的spec.NodeName的信息来将调度后果同步到节点。所以对于局部有非凡的调度需要的用户，有些开发者通过自研Custom Scheduler来实现以上的流程，而后通过和default scheduler同时部署的形式，来反对本人非凡的调度需要。 Custom Scheduler会存在一下问题： 如果与default scheduler同时部署，因为每个调度器所看到的资源视图都是全局的，所以在调度决策中可能会在同一时刻在同一个节点资源上调度不同的Pod，导致节点资源抵触的问题。有些用户将调度器所能调度的资源通过Label划分不同的池子，能够防止资源抵触的景象呈现。然而这样又会导致整体集群资源利用率的降落。有些用户抉择通过齐全自研的形式来替换default scheduler，这种会带来比拟高的研发老本，以及Kubernetes版本升级后可能存在的兼容性问题。Scheduler Extender的性能较差可是保护老本较小，Custom Scheduler的研发和保护的老本特地高然而性能较好，这种状况是开发者面临这种两难处境。这时候Kubernetes Scheduling Framework V2横空出世，给咱们带来鱼和熊掌能够兼得的计划。 新一代调度框架 Scheduling Framework之解析社区也逐步的发现开发者所面临的窘境，为了解决如上问题，使Kube-scheduler扩展性更好、代码更简洁，社区从Kubernetes 1.16版本开始, 构建了一种新的调度框架Kubernetes Scheduling Framework的机制。 Scheduling Framework在原有的调度流程中, 定义了丰盛扩大点接口，开发者能够通过实现扩大点所定义的接口来实现插件，将插件注册到扩大点。Scheduling Framework在执行调度流程时，运行到相应的扩大点时，会调用用户注册的插件，影响调度决策的后果。通过这种形式来将用户的调度逻辑集成到Scheduling Framework中。 Framework的调度流程是分为两个阶段scheduling cycle和binding cycle. scheduling cycle是同步执行的，同一个工夫只有一个scheduling cycle，是线程平安的。binding cycle是异步执行的，同一个工夫中可能会有多个binding cycle在运行，是线程不平安的。 scheduling cyclescheduling cycle是调度的外围流程，次要的工作是进行调度决策，挑选出惟一的节点。 Queue sort// QueueSortPlugin is an interface that must be implemented by "QueueSort" plugins.// These plugins are used to sort pods in the scheduling queue. Only one queue sort// plugin may be enabled at a time.type QueueSortPlugin interface { Plugin // Less are used to sort pods in the scheduling queue. Less(*PodInfo, *PodInfo) bool}Scheduler中的优先级队列是通过heap实现的，咱们能够在QueueSortPlugin中定义heap的比拟函数来决定的排序构造。然而须要留神的是heap的比拟函数在同一时刻只有一个，所以QueueSort插件只能Enable一个，如果用户Enable了2个则调度器启动时会报错退出。上面是默认的比拟函数，可供参考。 ...

作者 | 不瞋  阿里云高级技术专家 每隔几年，IT 界就会呈现新突破性的停顿。回望整个计算机技术发展史，咱们会发现“形象、解耦、集成”的主题贯通其中。产业每一次的形象、解耦、集成，都将翻新推向新的高度，也催生出宏大的市场和新的商业模式。 对于大多数利用而言，借助 Serverless 服务，开发者能够将绝大多数精力投入在业务逻辑的开发整合上，大大缩短开发周期，升高运维老本。有人说：Serverless 正在扭转将来软件开发的模式和流程，它就是云计算的将来。技术畛域真正的改革看似是新技术的高歌猛进，为客户发明价值才是任何技术改革的原点。本文将从客户价值的角度，再一次探讨为什么说 Serverless 是云的将来。 Serverless 对客户的价值为客户发明价值是任何技术改革的原点，从客户价值倒推，真正须要答复的是：客户的痛点是什么？Serverless 在解决客户痛点上是否有显著劣势？甚至为客户发明新的机会？以企业的平台化策略为例，为什么泛滥 SaaS 企业不能像 Salesforce 一样施行平台策略，打造 PaaS 或者 Serverless 计算平台？甚至做 PaaS，做中台变成了企业生死劫？这其中诚然有业务、组织的顶层设计起因，但不可否认，打造平台的难度和老本太高也是其中很重要的起因。一方面要撑持前台业务的高速倒退，另一方面又要形象、重组，对系统进行重构。因而须要有新的方法论和工具来升高平台构建的老本，实现疾速迭代演进。 从更宏观的视角来看，企业交付价值的形式，正在被数字技术重塑。依据阿里研究院的报告，在批发、金融等行业，数字化的商业状态正在代替传统商业状态，成为支流和必然。即便在工业制作等畛域，企业的商业状态并非通过数字化的模式体现，但充分利用数据科技进行生产经营优化，也正在成为行业共识。在数字化转型的时代 ，企业面临微小的竞争压力和不确定性，产品 time-to-market 的能力比任何时候都重要。依据微软的预计，将来 5 年会产生 5 亿个利用，比过来 40 年的总和都多，现有的研发模式已无奈撑持这样规模的利用开发需要。 Serverless 计算的思维是将同质化的、累赘沉重的基于服务器等基础设施的开发和运维等工作从将来云上利用开发中移除，借助云上丰盛的托管服务能力，以搭积木的形式构建弹性、牢靠、低成本的零碎或利用。除此之外，云服务商也通过事件驱动的形式增强产品集成和被集成的能力。 以 Serverless 的外围计算产品函数计算为例，在函数计算呈现之前，客户要通过很多胶水代码实现多个云产品间的集成，还要认真的解决各种谬误状况。当函数计算和阿里云对象存储集成后，对象存储中产生的上传 / 删除对象等事件可能主动、牢靠地触发函数解决，而且每个环节都是弹性高可用的，客户可能疾速实现大规模数据的实时并行处理。同样的，通过消息中间件和函数计算的集成，客户能够疾速实现大规模音讯的实时处理。在将来，无论是一方云服务，还是三方利用，所有的事件都将被捕捉，被函数计算等服务牢靠地解决。 比照传统开发模式，Serverless 模式基于大量成熟的云服务能力构建利用，客户的技术决策点更少，施行复杂度更低。随着云产品的欠缺，产品的集成和被集成能力的增强，软件交付流程自动化能力的进步，咱们置信在 Serverless 架构下，企业的敏捷性有 10 倍晋升的后劲。 Serverless 对云服务商的价值Serverless 有助于云服务商建设更广阔的差异化竞争劣势。基础设施即服务（IaaS ）层的竞争实质是规模。云服务商通过晋升供应链的议价能力、资源并池、采纳异构硬件、软硬协同优化等伎俩来最大化性能功耗比（performance per watt）和性能价格比（performance per dollar）。基础设施层竞争的次要模式是价格战。 但云的竞争肯定不是繁多维度的，正如苹果提供了挪动利用编程模型最好的实现，这是硬件、软件、服务三位一体的协同整合能力，以此为根底造成的杰出用户体验和粘性让其在挪动互联网产业中自成一家。云服务商也须要思考如何在基础设施、产品体系、生态等方面多维度，立体化地打造竞争力。倒退 Serverless 关乎于产品体系差异化竞争力的建设，对云服务商至关重要。 在函数计算呈现之前，各个云产品难于反对定制化需要，产品间的交加很少。在函数计算呈现后，每个云服务具备了“可编程“的能力。“可编程“让云服务将本人的外围能力延长进来，让开发者基于此编写相干利用，岂但解决了定制化需要撑持的问题，云服务还降级为利用平台，建设开发者生态。因而当先的云服务商的产品体系都在迅速 Serverless 化，不断加强产品间的集成和被集成的能力。 Serverless 有助于云服务商进步资源利用率，减速硬件翻新。为了实现精准、实时的实例伸缩和搁置，Serverless 计算平台必须把利用负载特色作为资源调度的根据，零碎通常要实时追踪申请执行时长，排队期待时长，单位工夫申请数，利用初始化时长等指标。以感知利用负载为根底的“白盒“调度，可能实现更杰出的伸缩实时性和全局资源利用率。轻量平安容器等新的虚拟化技术实现了更小的资源隔离粒度（典型的 Serverless 计算服务通常反对 0.1 vcpu，128 MB 的实例规格），更快的启动速度，更小的零碎开销，数据中心的资源应用变得更加细粒度和动静，可能更充沛的利用碎片化资源。在减速硬件翻新方面，Serverless 计算屏蔽了底层硬件规格，可能复用多种机型，减速新硬件的大规模利用。 ...

7月9日 19:00-21:30 阿里云开发者社区首场“Offer 5000”直播开启！15位团队技术大牛在线招人，更有《阿里云技术面试红宝书》助你拿下Offer！ 点击图片或戳我查看详情和投简历 作者 | 箫逸  阿里娱乐高级技术专家 导读：转瞬 2020 曾经过来了一半，是时候来做一次年中总结了。本文中，阿里娱乐高级技术专家箫逸总结了本人在阿里 6 年来的成长和播种，分享他在工作中的一些思维办法，以及对生存的一些感悟，心愿对同学们有所启发。 察看本人的成长，能力播种更大的成长很长时间以来我根本都是基于本能或本能在做事件，不是说没有思考，是素来没有思考过本人为什么那么思考。过来一年最大的觉醒是逐步向内看，本人怎么做的，怎么思考的，怎么成长的，本人为什么是那么想的，为什么是那样做的，抓住思维过程，让更多的本能或本能裸露，向内扫视本人做事件的逻辑，从而建设起本人的体系去思考，去想问题。在这个过程中逐步地造成了本人在成长过程中所遵循的一系列“章法”，我想这是我这一年来最大的成长。 1. 从孩子身上重新学习闺女 1 岁半，逐步能够意识挂在墙上的各种水果卡片，尽管她不会说，然而当我问起诸如苹果在哪儿，豌豆射手在哪儿之类的问题时，她总能疾速指到正确的地位。我欣慰于这种疾速的成长，不禁想她到底是怎么学会的？无意识的察看后果发现，她始终保持了一个最简略的法令：模拟 -> 反复 -> 学会 -> 学会下一个，她的成长过程始终保持着这样一个小循环，这种循环在一直地扩充她的认知圈。 上边这几张图按程序能够代表我察看孩子成长过程取得的粗浅启发。最右边是一个渺小的循环，其中的关键在于“晓得如何学会”，这个过程与刻意练习的过程近乎相似，然而更加聚焦于渺小且具体的事或者哪怕一丁点儿的提高，这个小循环的价值在于扫视、发觉、反思和坚固，能够极大的带来学习的能源。我把这个循环实际到率领儿子的各科学习过程中，通过重复的确认“如何做到的”实现对他成长的激励，小家伙面对艰难的信念也是越来越足。右侧的三幅图是档次逐渐回升的表述，从刻意练习到认知的边界，再到更长时间维度上的螺旋式成长，根本组成了成长中必然经验的过程。 这其中最难的是什么？我认为是对循环过程的保持和及时止损。 咱们都晓得复利的指数分布图，在最开始的很长一段时间内趋势趋于平滑，须要很长的工夫能力迎来拐点，这其中须要保持，因为只有保持能力借助工夫的催化作用产生复利。我认为保持训练“晓得如何学会”这个思维卡点，保持通过刻意练习强化某一件事件、某一类技能或某个概念的心理表征，这是让拐点疾速到来惟一的路径。除此之外，要克服心田的焦虑感，让本人慢下来（请留神，慢不是速度问题，而是规范问题）。 但不是始终保持就能够迎来拐点，这里还有另外一层，就是要“及时止损”，巴菲特说他的投资准则：Rule No 1，Never lose money；Rule No 2，Never forget rule No.1。乍听起来第二条像是废话，但认真了解背地其实是“及时止损”这层深意：必须保障一寸一寸的后退，必须在乎一寸一寸的得失。只有这样舒服区能力一直的扩充。咱们能够在很短时间内把握一个技能或一门常识，然而如果没有输入，没有实际，就会很快失去这个播种，因为忘记是本能。而及时止损的实质是反抗忘记，反抗忘记的最好方法是一直的反复，一直的应用，一直的实际。《认知本能》这本书里提到对于记忆神经，通过检索造成突触，为记忆打一个结。这个结就如同咱们在健身房一直的训练，刺激，一直的撕裂肌肉神经让他从新再成长一样，也是一个长肌肉的过程，所以要想成长必须学会“及时止损”。 这是我去年从孩子身上取得的学习播种，我始终在一直的催促本人实现单个小闭环，一直的反复，一直的进化，冀望可能疾速迎接到拐点，从而走出残缺的复利曲线。 2. 所有兼有章法万维钢在《万万没想到》一书中说到：人所把握的常识和技能绝非是零散的信息和随便的动作，他们大多具备某种 “构造”，这些构造就是模型。而厉害的人，或者精英就是长于把握和利用这些模型解决问题的人。我了解这里的模型就是“章法”，也能够了解为咱们常说的套路。 延展到过来一年在团队和治理上的成长，我从很多的高年级同学的分享中吸取到了章法的力量。所有的模型皆为形象，这个点和技术畛域里的形象是相通的，比方去年在团队中曾分享过《如何画好一张架构图》就是一种章法的总结；再比方绩效治理这个周期性的治理动作，被形象为定指标-追过程-拿后果这样的模型。一旦造成章法，并且基于章法再去开展思考，会让整个过程达到事倍功半的成果。 那么如何找到“章法”呢？我的教训是时刻询问本人：我是如何学会的？发觉过程，基于后果扫视，复盘思考积淀，认知实际，重复确认再认知，我感觉这就是造成章法的关键所在。这个章法当然能够参考他人的，然而我感觉本人的思考才是最最有用的。所有兼有章法，只有肯用心、肯下苦功夫，敢于在思想上艰苦奋斗，我置信就肯定会有大的播种。 过来的一年，团队在治理实际上扎扎实实的思考、落地，通过外围团队的一次又一次复盘，思考，探讨，强化了执行次数，造成了合乎复利的驱动模型。把做一件事件的“章法”重复作用于学习-保持-实际的回升螺旋，那么在这件事件上，就能够播种比他人或比本人过来快的多的成长，这是过来一年我在治理成长上的最大播种。 3. 认真生存，高兴工作去年 9 月份团队有一次普吉岛 Outing，Outing 的时候我发现很多平时工作中体现很低调的同学，在 Outing 中充斥了闪光点。我忽然发现，咱们每一个同学都是一座冰山，在工作中体现进去的只是冰山可见的那局部，而冰山之下的日常生活才更能实在全面的反馈一个人，这给了我十分大的启发，让我更加深刻的思考“认真生存，高兴工作”背地的智慧。 我感觉认真生存必须要学会观赏，要谦卑的去观赏接触到的每一个人，发现他人身上的闪光点，这是我 Outing 中最大的播种。这种观赏让我越来越容纳，可能容纳和承受本人从前无奈承受的人或事，也更加向内看本人。这种容纳，也让本人的心田就越来越凋谢，也越能接管不一样的观点，能取得很多从前属于“盲区”的成长体验。这个过程须要修炼，须要放弃心田的谦卑，一个人在工作上的魅力可能全无，但在生活中他是一个十分闪光的人，放弃谦卑能够让本人看到一个残缺的人。 认真生存也是一种态度，更是对人生的一种了解。在过来，我始终感觉本人处在一个奋斗的年纪，素来没有过多的关注生存，我也素来没有置信什么生存和工作的均衡，我看待工作的激情和投入的精力要远大过于我的生存。我感觉人的精力是无限的，必须要把最旺盛的阶段投入到事业和集体能力的晋升上来。所以看待“认真生存”素来没有认真去想过，更多停留在喊喊说说而已，我狭窄的对待了生存与工作之间的关系，Outing 之后我有不一样的思考。 咱们经常会提到一个问题：如何均衡生存和工作自身？这里边有一个词叫“均衡”，我不晓得这个词在大家脑海里的画像是什么？在我脑子里第一呈现的是“天平”，要么投入生存，工作上不做过多谋求；要么更多思考工作，生存更多服务于工作。这种工作和生存非此即彼的广义了解其实粗浅妨碍了本人进一步的思考。我很长时间都是这么割裂开来看的。事实是工作是生存的一部分，是蕴含关系，生存是什么？生存是人生，生存蕴含了事业（工作）、家庭（咱们经常了解的生存）、孩子、教育、兴趣爱好等等。《高效能人士的七个习惯》这本书在讲“要事第一”时提到“木桶人生”，这个木桶里能够装大石头、小石子、沙子等等，工作对于我可能是一个大石头，它承载了我很多人生的价值、经济基础等底座，这本书让我感觉生存是能够全面推动的，外围是咱们须要辨认本人在生活中每一个角色里承当的“重要不紧急”事项，而后做好它，做好这要害的 20%，一直的吸取，以“全面推动”为准则，而不是以某一个全面的侧重点为方向。而且日常生活中的思考和启发其实是能够很好的作用于工作。发现美妙，发现痛的中央，发现兽性中趋利避害，这是一种智慧，这也是过来一年在认真生存里播种的成长，我还在一直的强化这种了解，一直的在践行这条价值观。 撑持我不断前进的底层逻辑下面的文字更多是过来一年吸取的成长，上面这些内容是我回顾六年走来的感悟，也算作这六年的一个总结。 1. 此时此刻，非我莫属这是我最喜爱的一句阿里土话，在它成为价值观之前，有太多太多的故事通过这八个字滋润了我。这八个字蕴含了使命感、责任感、担当、激情、更蕴含了一种“舍我其谁”的豪气。我很好奇，新六脉三角形中“此时此刻 非我莫属”放在最底层，最两头的局部，是偶合还是无意为之。在我看来这一条是所有其余价值观的内生能源源泉，无论是在个人成长还是在客户价值的保卫中，都是十分十分要害的。如何放弃内生的激情，从我的历史教训看至多有三点。 ...

你明天点外卖了吗？你明天剁手了吗？ 你每次在饿了么和淘宝上的刷刷刷、点点点 都有阿里云服务器ECS在云端疯狂计算 ——阿里云ECS，撑持了阿里经济体全面上云—— ---- 天猫双11外围零碎100%上云 阿里云驯服史上最大流量洪峰 饿了么100%迁至阿里云 可反对1亿人同时点单 考拉全面上云，阿里云助其老本升高2000万、性能晋升20% …… 你的每次业务背地，ECS都是你最松软的“底座” ——阿里云ECS，发明一次次“不可能——” ---- 钉钉百倍流量暴涨背地的扩容 寰球抗疫，撑持新冠药物研发 复课不停学，撑持数亿学生在线上课 …… 你的每次业务挑战，背地有ECS为你“扛着”。 ——ECS，是企业上云的第一步—— ---- 保障着客户业务每一天的安稳运行 充当着客户业务洪峰“扩容”靠谱队友 ECS曾经跟客户并肩而行十年 十年以来，阿里云服务器ECS **一代比一代快 一代比一代稳 一代比一代实惠** 让客户的业务越来越稳，性能越来越高 到底是什么样的产品，什么样的技术 让阿里云ECS扛住了天量流量？ 7月15日，阿里云ECS新品发布会为你揭秘 优异的性能背地 是阿里云ECS十年的自研技术积淀 当先的神龙架构，重构了云端服务器的性能 将来十年，阿里云ECS的技术又会往哪儿走？ ——阿里云ECS产品家族全面降级—— ---- 首款全闪存云服务器ECS 让redis等数据库运行性能晋升20% 让金融级业务更顺滑，进一步优化高性能计算场景 寰球首发AEP实例 与内存增强型服务器联合，笼罩Sap Hana全场景 新批发、制造业上云更轻松、更省心 寰球首发下一代GPU服务器 联合含光800云服务，让AI训练享受最新最强算力 推理性价比更高 …… 更多新品，欢送报名观看2020阿里云ECS新品发布会 直播地址：https://yqh.aliyun.com/live/2020ecsevent

X-Engine是阿里巴巴自研的存储引擎，作为阿里云 RDS MySQL 的一个可选引擎，除了主打高性能和低成本，还减少了不少惠及用户的新性能。本文将具体介绍 MySQL(X-Engine) 如何近乎刹时实现传统数据库须要数小时实现的DDL操作。 1.数据库DDL操作面临的问题互联网业务倒退迅速，利用模式频繁更改是常态。相应地，数据库拜访模式和schema也随之变动。DDL（Data Definition Language）是SQL的一类，次要作用是创立和更改数据的schema信息，最常见的操作包含：加减列、更改列类型、加减索引等。相熟MySQL的同学都晓得，在8.0以前，尽管Online DDL不阻塞其它DML（Insert/Update/Delete）操作，但许多重要的DDL操作，如加列、减列等，仍旧须要期待数小时、甚至好几天工夫（根据数据量的大小）才会失效。更改列类型等操作甚至仍须要锁表执行，阻塞DML操作。 DDL操作运行工夫长，占用系统资源，须要额定的磁盘空间（建设长期表），影响零碎吞吐，并且一旦DDL过程中实例crash，复原工夫也会很久。以加列DDL为例，MySQL经验如下过程： 1.以新schema建设空表。2.拷贝数据到新表，并且将新加列的值赋为默认值，同时更新索引表。数据库承受到的DML操作被记录在临时文件。3.加exclusive lock，阻塞写操作，将临时文件记录的DML操作apply到新表。如果DML很多，这一阶段将破费较多工夫。4.删除旧表，将新表命名为旧表的名字。显然，这个过程加锁工夫长，拷贝数据操作会占用系统资源和长期空间，并须要大量I/O。为了适应变动频繁的业务，不立刻更改存储层数据、能够疾速实现的DDL（咱们称之为Fast DDL）成为了一个必要feature。MySQL 8.0 减少了instant add column性能，能够在短时间内只批改table元信息，实现加列操作。遗憾的是，它还不反对其它类型的DDL。得益于阿里自研的存储引擎X-Engine存储了多版本Table Schema，每一行记录在引擎层就实现了解析，并且能够根据更新版本的schema实现格局转换，X-Engine因而可反对多种类型的Fast DDL。 2.业界Fast ddl实现计划MySQL 8.0 record记录了列个数, instant add column操作只批改零碎表。 写操作：新格局的记录。 读操作：依据存储在零碎表中default value补齐新加列。 反对类型： • Change index optionRename table • Set/drop default • Modify column when the table is empty • Add/drop virtual columnsAdd columns MariaDB10.3 整体实现计划与MySQL8.0相似，record记录了列个数，在leftmost leaf page中记录所有列的default值. 反对类型： • Add column • Drop column • Extend VARCHAR maximum （Only if the physical format allows; not VARCHAR(255) to VARCHAR(256)） ...

背景阿里团体针对故障解决提出了“1/5/10”的指标-- 1 分钟发现、5 分钟定位、10 分钟复原，这对咱们的定位能力提出了更高的要求。 EMonitor 是一款集成 Tracing 和 Metrics、服务于饿了么所有技术部门的一站式监控零碎，其笼罩了 前端监控、接入层监控；业务 Trace 和 Metric 监控；所有的中间件监控；容器监控、物理机监控、机房网络监控。每日解决总数据量近 PB，每日写入指标数据量几百 T，日均几千万的指标查问量，内含上万个图表、数千个指标看板，并且曾经将所有层的监控数据买通并串联了起来。然而在故障来长期，用户依然须要破费大量工夫来查看和剖析 EMonitor 上的数据。 比方阿里本地生存的下单业务，波及到诸多利用，每个利用诸多 SOA 服务之间盘根错节的调用关系，每个利用还依赖 DB、Redis、MQ 等等资源，在下单成功率上涨时，这些利用的负责人都要在 EMonitor 上查看指标曲线以及链路信息来进行人肉排障以自证清白，耗时耗力，所以自动化的根因剖析必不可少。 根因剖析建模业界曾经有好多在做根因剖析的了，然而大都准确率不高，大部分还在 40% 到 70% 之间，从侧面阐明根因剖析的确是一个难啃的骨头。 根因剖析看起来很宏大，很形象，无从下手，从不同的角度（可能是表象）去看它，就可能走向不同的路。那如何能力透过表象来看到实质呢？ 我这里并不会一开始就给你列出高大上的算法解决方案，而是要带你从新认知根因剖析要解决的问题到底是什么。其实好多人对要解决的问题都模糊不清，你只有对问题了解分明了，能力有更好的计划来解决它。 要解决什么样的问题举个例子：现有一个利用，领有一堆容器资源，对外提供了诸多 SOA 服务或者 Http 服务，同时它也依赖了其余利用提供的服务，以及 DB 资源、Redis 资源、MQ 资源等等，具体见下图；那咱们如何才可能全面的掌控这个利用的健康状况呢？ 咱们须要掌控： 掌控这个利用的所有入口服务的「耗时」和「状态」掌控每个入口服务之后每种操作的「耗时」和「状态」一个利用都有哪些入口？ SOA 服务入口；Http 服务入口；MQ 生产音讯入口；定时 job 入口；其余的一些入口。进入每个入口之后，都可能会有一系列的如下 5 种操作和 1 种行为（上面的操作属性都是以阿里本地生存的理论状况为例，并且都蕴含所在机房的属性）： DB 近程操作：有 dal group、table、operation（比方select、update、insert等）、sql 的操作属性；Redis 近程操作：有 command 的操作属性；MQ 近程操作（向MQ中写音讯）：有 exchange、routingKey、vhost 的操作属性；RPC 近程操作：有 近程依赖的 appId、近程 method 的操作属性；Local 操作（即除了上述4种近程操作之外的本地操作）: 暂无属性；抛出异样的行为：有异样 name 的属性。那咱们其实就是要去统计每个入口之后的 5 种操作的耗时状况以及状态状况，以及抛出异样的统计状况。 ...

作者 | 新胜  阿里云技术专家 导读：OpenYurt 开源两周以来，以非侵入式的架构设计交融云原生和边缘计算两大畛域，引起了不少行业内同学的关注。阿里云推出开源我的项目 OpenYurt，一方面是把阿里云在云原生边缘计算畛域的教训回馈给开源社区，另一方面也心愿减速云计算向边缘延长的过程，并和社区独特探讨将来云原生边缘计算架构的统一标准。为了更好地向社区和用户介绍 OpenYurt，咱们顺便推出【深度解读OpenYurt】系列文章，本文为系列文章的第三篇，一一介绍了 OpenYurt 中组件 YurtHub 的扩大能力。 系列文章举荐： OpenYurt 开箱测评 | 一键让原生 K8s 集群具备边缘计算能力深度解读 OpenYurt ：边缘自治能力设计解析OpenYurt 介绍阿里云边缘容器服务上线 1 年后，正式开源了云原生边缘计算解决方案 OpenYurt，跟其余开源的容器化边缘计算计划的区别在于：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，对 Kubernetes 零碎零批改，并提供一键式转换原生 Kubernetes 为 openyurt，让原生 K8s 集群具备边缘集群能力。 同时随着 OpenYurt 的继续演进，也肯定会持续放弃如下倒退理念： 非侵入式加强 K8s放弃和云原生社区支流技术同步演进YurtHub 架构阐明在上篇文章中，咱们介绍了 OpenYurt 的边缘自治能力，重点解读了其中的组件 YurtHub。其架构图如下： 同时在介绍 YurtHub 的劣势中咱们提到 与 Kubernetes 设计理念符合，YurtHub 非常容易扩大出更多的能力。具体在 YurtHub 扩大出了什么能力呢？接下来咱们将一一开展介绍。 YurtHub 的扩大能力1. 边缘网络自治首先介绍一下何谓边缘网络自治：即在边缘和云端网络断连时，不论时业务容器重启，或是边缘节点重启等，边缘业务的跨节点通信能够继续工作或是主动复原。 在 OpenYurt 中，实现边缘网络自治须要解决如下的问题（以 flannel vxlan overlay 网络为例）： ...

汽车产业互联网平台大搜车由姚军红创建于2012年12月，先后取得阿里巴巴团体、蚂蚁金服、晨兴资本、华平投资、春华资本等机构超过12亿美元融资。2017年12月，大搜车列入由硅谷寰球数据钻研机构PitchBook评比的“2017年寰球新晋独角兽”名单。 目前，大搜车曾经搭建起比拟残缺的汽车产业互联网协同生态。随着业务业务的疾速倒退，大搜车遇到了一系列的问题： 大量微服务零碎，总数在2000以上，这些零碎之间的异步通信全副都须要通过音讯队列MQ，导致音讯量大幅减少，日均音讯TPS在6000以上，音讯零碎的稳定性成为云上业务稳固保障的重中之重。因为有杭州和北京两大研发核心，客户在杭州和北京都部署了大量业务零碎，多地区利用的音讯同步须要有稳固牢靠的机制。物联网设施的治理和接入对音讯零碎提出了更高的要求。大数据畛域大量利用Kafka，须要更稳固牢靠的商业版Kafka产品，缩小运维工作量。为了更好地撑持业务，大搜车利用云上MQTT+音讯队列RocketMQ+寰球音讯路由+音讯队列Kafka构建了残缺的云上音讯零碎。 通过寰球音讯路由性能将杭州地区的音讯同步到北京地区，做到业务分地区就近部署。独立音讯队列实例治理不同业务，可用性更高。利用音讯队列Kafka对接大数据生态，即开即用，疾速扩容，可靠性更高。物联网设施通过MQTT进行接入，后盾开发物联网设施治理平台，通过MQTT连贯设施端，并对设施的能力进行治理，可通过平台调用设施端能力（比方发动会议、下发开机图片、获取设施信息等）。MQTT与RocketMQ后盾音讯买通，后端应用服务器无需放弃设施端连贯，以通用的RocketMQ音讯进行对接，服务器端更稳固，连贯治理更牢靠。 业务稳定性：阿里云RocketMQ提供99.99999999%的数据可靠性和99.95%的服务可用性SLA，确保服务高可用以及数据不失落。高性能：RocketMQ反对千万级TPS以及亿级音讯沉积，在业务高峰期仍然能够放弃高性能。寰球音讯路由：利用稳固牢靠的路由性能，将客户多个地区的音讯零碎买通，实现业务就近拜访，满足跨地区、远距离、毫秒级音讯流转的需要。海量物联网设施治理：利用阿里云音讯队列MQTT，实现物联网设施与云上业务利用牢靠连贯，轻松治理海量物联网设施。云上托管版Kafka：兼容开源Kafka协定，全托管，高可用，高平安。无缝对接开源及云上大数据生态。

Redis 6.0更多精彩详情Redis 6.0是Redis发展史上极为重要的版本，蕴含多项重大性能更新和大幅度的性能晋升。为了让用户能够第一工夫体验到最新版Redis的各项性能，阿里云紧随其后公布了最新版 Redis 6.0云数据库。在昨天的发布会中，云数据库Redis 6.0版本正式与大家见面。 明天小编就为大家揭秘一下云数据库Redis极速上云背地的故事。 2020年5月2日，Redis 6.0 GA版正式公布，这个版本被作者誉为社区版史上最大的一次公布，蕴含诸如 RESP3新协定反对、ACL 治理、多 IO 线程、SSL 加密、客户端缓存与集群代理等多项重大要害性能更新和内核架构晋升。 2020年5月7日，阿里云寰球首发（除原厂）最新版 Redis 6.0云数据库，全面涵盖开源Redis 6.0各项性能。 短短不到一周的工夫，阿里云Redis是如何做到极速上云的呢？总结起来，阿里云Redis团队对内核深度的掌控能力和云原生管控弱小的助力是两大主因。 内核的掌控能力 这次社区版6.0中阿里云Redis团队的奉献排在第二位，仅次于作者和其所在的商业公司，高居原厂外代码奉献第一名，充分说明了阿里云Redis对内核的掌控能力，在6.0正式GA之前阿里云团队便开始一直对这些新feature进行测试和优化，将云上积攒的货色反馈给社区，疏导社区的倒退。 另一方面，阿里云Redis企业版（Tair）此前就已具备了Redis 6.0版本中的很多新性能，例如：多IO线程、权限治理、SSL加密以及集群proxy。在线下，阿里云Redis团队成员也和作者进行了屡次沟通，就Tair上的实现计划与他进行深入探讨。 比方多IO线程，从RC1到GA，阿里云Redis团队帮社区在多线程的根底上又晋升了30%的性能。而在权限治理上，阿里云Redis云服务有很多运维的教训把它联合到ACL中，让ACL更加不便的应用和治理。 除此以外，咱们在主备数据一致性和对于过期工夫的判断又做了进一步增强，这亦是阿里云Redis和许多客户独特成长的成绩。另外针对云上用户实现的一些通用需要也合并到了6.0骨干，比方新增加了bitfiled_ro、set keepttl等等命令，让更多用户享受到阿里的技术红利。 云原生管控Redis 6.0大版本疾速输入得益于管控基于云原生的新架构，新管控平台屏蔽了管控上简单的机器操作和实例交互，通过应用十分驻长期pod的形式来实现所有的管控动作，同时新增通用模块，提供了数据库畛域级别的模型形象，业务只须要依据相应的业务模型去形容service_spec.yaml文件即可。 通过通用和高度可定制化的云原生管控平台，新增业务性能无需过多关怀平台接口，更多聚焦于业务自身，大大晋升了新业务接入开发效率，Redis 6.0在极短的工夫内实现管控适配并上线，助力寰球首发。 随着阿里云Redis团队对内核的掌控能力进一步晋升以及云原生管控的助力，包含内核优化、性能加强与弹性伸缩能力等多方面均失去大幅度晋升， Redis 6.0之后的阿里云Redis服务后续会有更为丰盛的性能和更佳的用户体验。 而由同一团队所出品的兼容Redis的高性能KV存储Tair本年度也将推出数据闪回（按工夫点复原数据）、寰球分布式缓存、存储级内存KV等多项重磅性能和新产品，为更多行业客户与场景赋能。 另外，咱们还为用户提供了Redis云数据库专属集群（https://www.aliyun.com/product/apsaradb/cddc）这是阿里云专为大中型企业用户定制优化的解决方案，填补了市场空白，具备资源独享、自主可运维、多数据库混合部署等特点，让用户既享受到云数据库的灵活性，又满足了企业对数据库合规性、高性能和安全性要求。 相干浏览： 寰球首发 | 阿里云正式推出云数据库Redis 6.0版本 倒计时7天 | 寰球第一的KV内存数据库行将再度降级！ 错过直播的同学可扫描下方二维码观看回放哦 公众号菜单栏回复“redis 6.0”即可获取讲师直播PPT材料啦！ 点击文字 立刻解锁Redis 6.0更多精彩详情 新用户还可享5折优惠哦！

云栖号资讯：【点击查看更多行业资讯】 在这里您能够找到不同行业的第一手的上云资讯，还在等什么，快来！什么是 Serverless 架构？依照 CNCF 对 Serverless 计算的定义，Serverless 架构应该是采纳 FaaS（函数即服务）和 BaaS（后端服务）服务来解决问题的一种设计。这个定义让咱们对 Serverless 的了解稍显清晰，同时可能也造成了一些困扰和争执。 随着需要和技术的倒退，业界呈现了一些 FaaS 以外的其它状态的 Serverless 计算服务，比方 Google Cloud Run，阿里云推出的面向利用的 Serverless 利用引擎服务以及 Serverless K8s，这些服务也提供了弹性伸缩能力和按应用计费的免费模式，具备 Serverless 服务的状态，能够说进一步扩充了 Serverless 计算的营垒； 为了打消冷启动影响，FaaS 类服务如阿里云的函数计算和 AWS 的 Lambda 相继推出了预留性能，变得不那么“按应用付费”了； 一些基于服务器（Serverful）的后端服务也推出了 Serverless 状态产品，比方 AWS Serverless Aurora，阿里云 Serverless HBase 服务。 这样看来，Serverless 的界限是有些含糊的，诸多云服务都向着 Serverless 方向演进。一个含糊的货色如何领导咱们解决业务问题呢？Serverless 有一个基本的理念是始终没有扭转的，即让用户最大化地专一业务逻辑，其它的特色如不关怀服务器、主动弹性、按应用计费等，都是为了实现这个理念而服务。 驰名的 Serverless 实践者 Ben Kehoe 这样形容 Serverless 原生心智，当咱们在业务中思考做什么时能够领会一下这种心智： 我的业务是什么？ 做这件事件能不能让我的业务超群绝伦？ 如果不能，我为什么要做这件事件而不是让他人来解决这个问题？ 在解决业务问题之前没有必要解决技术问题。 在实际 Serverless 架构时，最重要的心智不是抉择哪些风行服务和技术，攻克哪些技术难题，而是时刻将专一业务逻辑铭记在心，这样更容易让咱们抉择适合的技术和服务，明确如何设计利用架构。人的精力是无限的，组织的资源是无限的，Serverless 的理念能够让咱们更好地用无限的资源解决真正须要解决的问题，正是因为咱们少做了一些事件，转而让他人做这些事件，咱们才能够在业务上做的更多。 接下来咱们介绍一些常见的场景，并探讨如何应用 Serverless 架构反对这些场景。咱们次要会采纳计算、存储和音讯通信等技术来设计架构，从可运维性、安全性、可靠性、可扩展性、老本几个角度来掂量架构的优劣。为了让这种探讨不过于形象，咱们会用一些具体的服务作为参考，然而这些架构的思维是通用的，能够用其它相似产品实现。 ...

摘要：本文次要分享 Flink 的 CheckPoint 机制、反压机制及 Flink 的内存模型。对这3局部内容的相熟是调优的前提，文章次要从以下几个局部分享： 原理分析性能定位经典场景调优内存调优Checkpoint 机制1.什么是 checkpoint简略地说就是 Flink 为了达到容错和 exactly-once 语义的性能，定期把 state 长久化下来，而这一长久化的过程就叫做 checkpoint ，它是 Flink Job 在某一时刻全局状态的快照。 当咱们要对分布式系统实现一个全局状态保留的性能时，传统计划会引入一个对立时钟，通过分布式系统中的 master 节点播送进来给每一个 slaves 节点，当节点接管到这个对立时钟时，它们就记录下本人以后的状态即可。 然而对立时钟的形式也存在肯定的问题，某一个 node 进行的 GC 工夫比拟长，或者 master 与 slaves 的网络在过后存在稳定而造成时钟的发送提早或者发送失败，都会造成此 slave 和其它的机器呈现数据不统一而最终导致脑裂的状况。如果咱们想要解决这个问题，就须要对 master 和 slaves 做一个 HA（High Availability）。然而，一个零碎越是简单，就越不稳固且保护老本越高。 Flink 是将 checkpoint 都放进了一个名为 Barrier 的流。 上图中就是一个 Barrier 的例子，从上游的第一个 Task 到上游的最初一个 Task，每次当 Task 通过图中蓝色的栅栏时，就会触发 save snapshot（快照）的性能。咱们用一个例子来简略阐明。 2.实例剖析 这是一个简略的 ETL 过程，首先咱们把数据从 Kafka 中拿过去进行一个 trans 的转换操作，而后再发送到一个上游的 Kafka ...

1. 背景以图搜图在生活中有着广泛的应用, 当我们在电视上看到有人穿着一件美丽的裙子或者帅气的球鞋也想拥有时, 我们可以拍张照片然后打开淘宝然后上传照片就可以快速的找到这个商品. 我们看到一张电影截图想知道出处的时候只要将图片粘贴到百度或者谷歌的图搜框中就可以找到相关电影的信息. 以图搜图还可以通过照片在海量的人物相册中快速的找到想要找的目标. 当您在使用百度谷歌等搜索引擎的以图搜图功能的时候的时候是否觉得这种"黑科技"遥不可及呢? 其实通过AnalyticDB提供的深度学习算法和高效向量检索, 我们只需要使用SQL就可以轻松的搭建一套以图搜图系统, 不需要掌握tensorflow, pytorch等深度学习框架, 也不需要学习OpenCV之类的视觉算法库. 本文将介绍如何通过AnalyticDB来快速搭建一套以图搜图系统. 内容包括: 以图搜图原理介绍, AnalyticDB以图搜图演示, 以图搜图代码实现, AnalyticDB的产品介绍, 总结和演示系统的源码分享. 2.以图搜图原理介绍以图搜图又被称为反向图搜(Reverse image search)是一种基于内容的图像检索(Content-based Image Retrieval) 技术. 以图片作为查询的对象, 以图搜图系统会在大量的图像记录中返回与查询图像内容最相关的记录. 例如, 商品图搜会返回与查询图片中主体物品相同或相似的图片信息. 人脸的图搜会根据图片中人脸特征返回目标人物的记录. 如下图所示是一个以图搜图的流程图. 以图搜图应用的核心模块有两个, 其中特征提取模块主要负责从图像中提取视觉特征, 从而获得一个高维的特征向量, 在这个高维特征空间中越相似的图像距离越近. 向量检索模块负责在海量的图像特征向量集中查找与查询图片特征最接近的前k个记录, 并返回. 2.1 图像特征提取当前主流的特征提取算法主要使用深度学习模型里如VGG[1], ResNet[2] , MobileNet[3], SqueezeNet[4]等模型作为主干网络, 然后使用不同的方法生成特征. 最简单的方法是直接将分类模型例如VGG模型的分类层前一层输出作为图像的特征. 这种算法在以图搜图场景中往往召回率不是很高. 第二种方法是将模型的中间层的特征经过特殊的的方法池化如RMAC[5], GeM[6] 和降维从而得到. 第三种方法是将模型在目标数据集上使用专门设计的损失函数进行前一训练. 例如商品以图搜图特征提取模型通常需要在商品数据集上进行迁移学习, 才能更加准确的提取不同商品的视觉特征。 AnalyticDB提供的通用以图搜图模型采用了阿里云自研的特征提取模型.AnalyticDB模型使用海量图片训练并且使用了先进的特征后处理方法. 与常用的VGG分类模型特征提取模型相比, AnalyticDB利用了多个尺度的特征,更好的平衡图像的局部特征和高层次特征, 在多样的图像场景中有更好的泛化能力。 AnalyticDB还提供了阿里云自研的人脸特识别模型, 基于大量数据训练, 模型已经在多个城市的安防和新零售场景大规模使用. 在百万人脸ID的相册中千分之一误识率下召回率可以达到99%. 2.2 向量检索向量检索又称为最近邻( Nearest Neighbor Search, NN)检索, 主要负责在海量特征向量中快速的查找与查询向量距离最近的k个记录, 虽然暴力的计算查询向量与数据库中所有向量的距离然后再进行排序可以找到最相近的记录, 但是这种方法的时间复杂度在大规模数据场景下无法满足需求的. 在实际应用场景中, 通常使用近似最近邻检索(Approximate Nearest Neighbor, ANN)的方法, ANN主要是利用向量数据分布的特性以牺牲一定检索精度为代价,快速的返回可能是查询目标最近邻的记录. 常见的ANN的方法有基于局部敏感哈希(LSH)的方法[7], 基于乘积量化的方法[8]和基于图的方法[9]. ...

作者 | Andy Shi（阿里云高级技术专家）、天元（阿里云技术专家） 今年 5 月，阿里云和微软云共同宣布，Open Application Model （OAM） 社区携手知名混合云管理项目 Crossplane 社区，联合发布了 OAM 在 Kubernetes 平台上的标准实现与核心依赖库。本次合作达成后，OAM 社区成功的将标准应用定义和标准化的云服务管理能力统一起来，迈出了实现真正意义上的无差别云端应用交付的关键一步 。 去年 10 月 ，阿里云和微软共同推出了 OAM 项目，旨在构建围绕 Kubernetes 的云原生应用规范。OAM 描述了一个模型 —— 开发人员可以在其中定义应用程序组件；应用程序操作员负责创建这些组件的实例并为它们分配应用程序配置；基础架构运营商负责定义、安装和维护平台上可用的基础服务。  本次合作是阿里云、微软与 Crossplane 社区的三方技术合作，主要围绕 OAM 在 Kubernetes 上的标准实现以及 Crossplane 项目的 OAM 化展开。因为 Kubernetes 社区在落地 OAM 模型的过程中，提出了关于 OAM 标准实现的诉求。所以这次合作的一个重点，就是三方工程师使用 Go 语言开发了一个 OAM Kubernetes 核心依赖库。这个项目的名字叫做 oam-kubernetes-runtime。OAM Kubernetes Runtime 将会成为 OAM 社区官方维护的基础组件，目标是在 Kubernetes 上提供稳定且统一的 OAM 核心插件。  为进一步了解本次合作的细节以及 OAM 项目的现状，阿里云高级技术专家 Andy Shi 以及阿里云技术专家孙健波（花名：天元）接受开源中国的专访，共同探讨了 OAM 项目存在的意义。 ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 他是公认的“湖畔第一大脑”，被王坚院士称为“云计算的试飞员”。跟他聊下来，仿佛上了一套【管理+创业+哲学】MBA课程，时刻烧脑，而回味无穷。以下为蒋烁淼的个人专访，推荐阅读（约3分钟）。因为看见，所以相信我的创业经历有两段，最初在上海建立“够快科技”的过程还算简单，正好是云计算从无到有的时间节点，个人云存储变成了红海，和一帮同学拉了投资做企业云存储，公司就起来了。面临架构升级的时候，直接选择了阿里云。因为马云做的产品生命周期都很长，当年说会连续投资云计算十年，我们选择阿里云的出发点就是天真朴素地相信马云，事实证明这个直觉对了。 2013年，阿里云的业务量大幅提升，阿里的同学问我有没有兴趣做阿里云的相关服务。一开始我没有什么明确的想法，当时的“初心”并不清晰，但我认为云计算天地大有可为之处，有很多需要云支持服务的内容，所以就毅然决然地跳进来了开始了新的一段创业历程。没什么复杂的原因，只是单纯的赌一个未来，懵懂地押宝。 有人会评价驻云科技为一个勇敢的尝试，与其说是勇敢，不如说是“看见”。比如马云创办阿里巴巴，王坚创办阿里云，在大多数人眼里是不靠谱的，最终都获得了成功。其实是因为他们有能力看见未来，在看见了之后，决策就没那么困难了。给湖畔大学面试新学员的时候我也会强调，多聊未来，不要停留在过去。固步自封只会画地为牢，人要努力看见明天。 破山中贼易，破心中贼难在云计算逐步被俯视化、通用化的今天，驻云科技的定位必须改变，公司需要做更多的事情，回归到业务和产品本身。因为云计算目前还存在软件公司的形态，更多像是传统形态地补充，在国内的发展速度和创新应用都十分有限，我对云计算到底带动了多少核心生产力存疑。打个比方说，以前我们用直流电点亮灯泡，后来技术发达，改用交流电。交流电的负荷更大、成本更低，可以支撑空调、电视的运转，但目前看来，国内的云计算还是用它来亮灯泡。大家更注重商业模式，重交付效果，重PPT呈现，而非创新的价值。 驻云未来的发展在我眼里前途堪忧。为了更有效地利用好核心资源，我几乎看遍全世界所有SaaS、PaaS、IaaS公司的信息，妄图从中获得灵感，但收效甚微。所以2018下半年到2019年初这段时间我一直处于完全灰暗的状态，整日浑浑噩噩，丧失一切兴趣，仿佛行尸走肉。当时整个人都极度惶恐，意识到人生命有限，所成就有限，想要增加自己生命的厚度。而这种恐慌不可与人言，别人理解不了。也尝试过打游戏、刷剧，尝试转移注意力。放弃对于创业公司的创始人毫无用处，我只能不停寻找答案。 之前公司很多时候都是站在云的立场上看问题，经历了灰暗的恐慌期，我将驻云看问题的角度转变为客户视角。我们想真正做出一些有创新、有灵魂的产品，高可用、广普惠，要做更多的有价值的“电器”跑在云计算上。关注是不是客户的真实需求，而非把所有组件拼装起来的解决方案。我希望驻云未来做出有创新的产品，催生出一个新的物种。它是基于云计算的未来技术而诞生的新软件、新服务，其核心方法论是用未来的方法论、技术、手段来看现在，而不是依赖过去的经验。 驻云的2020年新产品 以前我的心态是，什么产品有前景就做什么。如今我的想法是，要把产品做好，对社会有所交代。现在我的使命感比任何时候都强，可能是经历了一场思想认知的洗涤，置之死地而后生的通透和坚定吧。 知行合一是一场修行我选择创业本身是为了一种不一样的体验，站在人生不同的角度领略更壮阔的风景。创业跟金钱和股份无关，而是选择了一种决策的方式，以及自己认知世界的一种好方法。用人也是其中有趣的体验之一，驻云的核心员工加入公司都属于因缘际会，带领天南海北诸军奋战，最难处在于统一认知。需要不断提高对方的认知，统一大家的目标，可能还需要借力于外部。创业就像开疆扩土，建立帝国，会涉及到心理、哲学甚至兵法，它整件事都非常有趣。 另一方面，人一定要想清楚自己所做事情的最终追求，创业者首当其冲。它是使命、愿景、价值观，但绝不是定义好一句话给别人看。即使没有这句话，人也应该知道自己正在做什么，以后要怎么做。 在这里也有一句话送给创业的同行者：“真正想明白”使命、愿景和价值观，贯穿创业始终！愿与诸君共勉。 蒋烁淼善于用浅显的例子解释自己的真知灼见，以直白而深刻的“创始人心智”，鞭辟入里，充满玩味。他是老蒋，阿里云 MVP有趣的灵魂之一。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

前言：更多关于数智化转型、数据中台内容可扫码加群一起探讨 阿里云数据中台官网 https://dp.alibaba.com/index （作者：qingliang_hu） 关联阅读：大厂经验（二）：多端可视化埋点解决方案 前言首先在介绍这套方案前，咱们还是简单地普及一下“埋点”这个名词。 埋点是指在各个终端（如网页、小程序）中收集一些关键访问数据并将数据发送到日志服务器，以供后续的数据分析。 如下笔者在写这篇文章之前对公司内的一些业务做的访谈调研记录，可以发现埋点在实际业务中大概会有这些作用： “采集并针对性做些投放调整，比如会员权益的展现、影院场次的优先露出、用户想看和看过的互动等”“做新春大盘活动的时候，某些模块曝光次数不够高，运营会调整相应策略”“个性化推荐，根据曝光和点击情况推荐用户数据”“我们这边埋点数据对算法开发、模型训练、效果评估起决定性作用”“观察用户逛会场深度的分布，做相应决策”在简单介绍今天的主角——埋点的定义后，接下来，我们一起来研究一下自动曝光这件事情。 什么是自动曝光？自动曝光是指按照埋点规范在页面上进行一个简单的声明式埋点，第三方采集SDK会根据埋点信息自动的采集元素曝光信息的一种方式。 如下图，页面滑动过程中A、B、C、D模块出现在视口内采集SDK会自动上报埋点日志： 典型轮播图场景，图片滚动出现后需要打曝光日志： 自动曝光的实现难点？1、一般而言产品上会要求页面上某个模块一定面积连续一段时间出现在视口才是有效曝光（如30%、300ms） 2、性能，几乎所有的第三方采集平台都会在曝光埋点的说明文档里注明：“请不要配置过多的曝光埋点，这会严重影响你的页面性能” 两个埋点方式 HTML如下： <title>轮播图自动曝光埋点demo</title><style type="text/css">ul { padding: 0;}.clear{ clear:both; zoom: 1;}*, :after, :before { -webkit-box-sizing: border-box; box-sizing: border-box;}.clearfix:after { clear: both;}.clearfix:after,.clearfix:before { display: table; content: "";}.promo-bd { margin: 0 auto; overflow: hidden; width: 520px;}.promo-bd .items-container { list-style: none; overflow: hidden; width: 2280px; left: 0px; opacity: 1; height: 280px;}.promo-bd .items-container .item { display: list-item; float: left; overflow: hidden; display: block; visibility: visible; height: 100%;}.promo-bd .items-container .item a { display: inline-block; height: 100%;}.sld-ft-nav { text-align: center;}.sld-ft-nav li { display: inline-block; margin-left: 8px; border-radius: 10px; width: 20px; height: 20px; line-height: 20px; background-color: #ccc; color: #fff; font-size: 12px; cursor: pointer;}.sld-ft-nav li:first-child { margin-left: 0px;}.sld-ft-nav li.selector { background-color: #ff7300;}<div class="container"> <div class="promo-bd"> <div class="items-container clear"> <div class="item" data-id="111"> <a href="#"> <img src="https://img.alicdn.com/tfs/TB1fEOLCrr1gK0jSZFDXXb9yVXa-520-280.jpg"> </a> </div> <div class="item" data-id="112"> <a href="#"> <img src="//img.alicdn.com/tfs/TB1BrwUFuL2gK0jSZPhXXahvXXa-520-280.jpg_q90_.webp"> </a> </div> <div class="item" data-id="113"> <a href="#"> <img border="0" src="//aecpm.alicdn.com/simba/img/TB183NQapLM8KJjSZFBSutJHVXa.jpg"> </a> </div> <div class="item" data-id="114"> <a href="#"> <img border="0" src="//aecpm.alicdn.com/simba/img/TB1JNHwKFXXXXafXVXXSutbFXXX.jpg"> </a> </div> </div> <ul class="promo-nav sld-ft-nav"> <li class="dot selector" onclick="handlerClick(0)">1</li> <li class="dot" onclick="handlerClick(1)">2</li> <li class="dot" onclick="handlerClick(2)">3</li> <li class="dot" onclick="handlerClick(3)">4</li> </ul> </div></div><script type="text/javascript"> let handlerLoop; let width = 520; function transform (num) { document.querySelector('.items-container').setAttribute('style', ` transition-duration: 0.3s; transform: translate3d(-${width * num}px, 0px, 0px); backface-visibility: hidden; left: 0px; opacity: 1; `); document.querySelectorAll('li.dot').forEach(function(ele, i){ ele.setAttribute('class', 'dot'); if (i === num) { ele.setAttribute('class', 'dot selector'); } }); } function loop (n) { let num = n; handlerLoop = setInterval(function(){ if (num === 3) { num = 0; } else { num++; } transform(num); }, 1500); } loop(0); function handlerClick (index) { clearInterval(handlerLoop); transform(index); loop(index); }</script>方式1：在head头部声明式埋点 ...

背景信息互联网时代个性化推荐已经渗透到人们生活的方方面面，例如常见的“猜你喜欢”、“相关商品”等。互联网能够对用户投其所好，向用户推荐他们最感兴趣的内容，实时精准地把握用户兴趣。目前很多成功的手机APP都引入了个性化推荐算法，例如，新闻类的有今日头条新闻客户端、网易新闻客户端、阿里UC新闻客户端等；电商类的有拼多多、淘宝、天猫等。分析型数据库PostgreSQL版推出的向量分析可以帮助您实现上述个性化推荐系统。 个性化推荐系统概述以个性化新闻推荐系统为例，一篇新闻包含新闻标题、正文等内容，可以先通过NLP（Neuro-Linguistic Programming，自然语言处理）算法，从新闻标题和新闻正文中提取关键词。然后，利用分析型数据库PostgreSQL版向量内置的文本转换为向量函数，将从新闻标题和新闻正文中提取出的关键词转换为新闻向量导入分析型数据库PostgreSQL版向量数据库中，用于用户新闻推荐，具体实现流程如图1所示。 图1.推荐算法整体框架 1.构建分析型数据库PostgreSQL版向量库，得到用户特征向量。通过分析用户历史浏览数据，构建相应的用户画像，建立用户偏好模型，得到用户特征向量。新闻推荐系统可以从用户的浏览日志中得到用户历史浏览新闻详情，再从每条历史浏览新闻中提取关键词，建立用户画像。例如，某用户浏览了多条NBA（National Basketball Association，美国职业篮球联赛）季后赛新闻，这些新闻中包含了NBA、篮球、球星、体育等关键词，通过这些关键词可以得出该用户是一个NBA球迷。通过分析型数据库PostgreSQL版向量将这些文本关键词转换为向量并导入到分析型数据库PostgreSQL版向量库中，得到用户特征向量。2.根据分析型数据库PostgreSQL版向量数据库和逻辑回归预测模型，将用户感兴趣的新闻推荐给用户。通过分析型数据库PostgreSQL版向量数据库，可以从互联网检索出前500条用户没有浏览过的新闻，但是这500条新闻却是该用户最感兴趣的新闻。然后，从这500条新闻中提取每条新闻的创建时间和点击率，根据逻辑回归预测模型（该模型来自于用户以往的浏览的历史记录中），将用户感兴趣的新闻推荐给用户。分析型数据库PostgreSQL版内置的文本转换为向量函数采用BERT（Bidirectional Encoder Representations from Transformers）模型，同时支持中文和英文两种语言。该模型基于大量的语料进行训练，其中包含了语义信息，而且其查询精度比简单的TF-IDF（term frequency–inverse document frequency）算法高。 个性化推荐系统中数据库表结构设计图2是个性化新闻推荐系统中分析型数据库PostgreSQL版数据库表结构设计，系统包含了三张表（News, Person，Browses_History）,分别存储新闻信息、用户基本信息、用户浏览记录。 图2. 个性化推荐系统分析型数据库PostgreSQL版表结构 我们对着三张表进行分别介绍： • News表存储新闻信息，包含新闻id（news_id）、新闻创建时间（create_time）、新闻名字（title）、新闻内容（content）、总的用户点击数（click_times）、两个小时内的用户点击次数（two_hour_click_times）。根据新闻的名称和内容得到新闻的关键词keywords，然后将新闻的关键词转化成向量（news_vector）。向news表中插入数据时，系统自动根据关键词转换为向量，将向量和其他新闻信息一起插入news表。 CREATE TABLE news ( news_id bigint, create_time timestamp, title varchar(100), content varchar(200), keywords varchar(50), click_times bigint, two_hour_click_times bigint, news_vector real[], primary key (news_id)) distributed by (news_id);• Browses_History表记录用户浏览的新闻的情况，包括新闻id（news_id）、用户id（person_id）、用户浏览新闻的时间（browse_time）。 CREATE TABLE browses_history ( browse_id bigint, news_id bigint, person_id bigint, browse_time timestamp, primary key (browse_id)) distributed by (browse_id);• Person表记录用户信息，包括用户的id（person_id）、用户的年龄（age）、用户的星级（star）。 ...

作者 | 承风 阿里巴巴高级前端技术专家 导读：建立结构化的思维，以结构化的模式驱动工作，以结构化的体系构建自身的能力，小到写 PPT、大到为业务提供更大价值，都是非常值得我们使用的模式。阿里巴巴数字供应链事业部高级前端技术专家 - 承风，将会在本文中和大家分享他在建立和践行结构化思维过程中的方法论。 引言在每年自评、汇报、工作中总会感受到一些结构化带来的问题： 老板问我当前做的事情怎么样了，我讲了合作中的难点、视觉风格问题、业务情况、代码质量······工作的进展，说了半小时，老板还是 get 不到我做的事情的情况和价值，是老板不在意这件事、还是我语言表达能力不行？我这一年做了很多事情，都有一定产出，但是跳出细节来看，发现对业务、对团队价值都不大，是我做得不好、还是运气不好做的事情不好？最近流行 codeless，我打算研究下可视化搭建；团队业务涉及到流程编排，我打算研究下 TMF······一年下来折腾了不少成果出来，似乎老板也没有很认可，是我不讨老板喜欢还是做的事情没价值？这些问题，根据我自己工作经验的总结，认为大都是对结构化认知不足和践行不佳导致的。 第一个问题：对事情的认知和表述结构化方面存在问题 - 结构化的思维相关问题；第二个问题：做事儿多而杂不成体系 - 结构化的工作模式问题；第三个问题：学习和成长缺乏重点 - 结构化的能力建设的问题。关于结构化Structured：建立中心（问题、目标）。以中心的核心要素对中心进行分解，形成分类子结构。以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；对关键分类子结构进行分析，寻找对策，制订行动计划。 同理，逆向的顺序，对多种杂乱的内容，进行分类、剪枝、归纳汇总成一个中心。我认为也是结构化。 有很多相关的书籍： 领导者之剑：成功人士的 5 大突破思维技巧、金字塔原理、极简思考：来自世界顶尖咨询公司的高效工作法······ 也可以参看很多结构化的应用方式：结构化面试、结构化金融产品设计、结构化系统开发方法······从多行业多领域的使用可以反思和加深自己的认知。 在工作中认知和践行结构化结构化的理论是简单清晰的（道的层面总是比较简洁），但实际应用中如何进行结构化、最有效的使用结构化却有很多经验（术的层面总是多变的）。在此结合我个人的经验给出一些建议： 1. 建立中心当我们接手一个业务需求、面对一项挑战的时候，应当先思考这个需求的核心目标是干嘛的。 1）结构化的建立中心思考的过程也是结构化的，我通常会分解为两个子结构进行： 这个业务需求当前的目标是什么（事的维度）：1. 目标是快速完成上线试一试业务效果：目标事的维度为高效稳定上线；2. 目标是建立后续业务铺开的基础方案：目标事的维度是强架构设计下的核心与功能拆分方案；为什么需要我来做（人的维度）：1. 是因为我工作量还有 buffer 所有承担这部分：目标人的维度是完成职能范畴内的工作；2. 是因为我在这方面技术比较擅长：目标人的维度是利用事情强化自身能力和使用能力把事儿做好。2）沿中心上行对单个业务需求而言，从事、人两个维度建立起的中心即其核心，是最主要部分，建立一颗结构树的基础。但我们不应当停止于此，还应当向上推导：这个需求在整个业务的范畴内，是在哪一层次，哪一分类的。即应当更高层面、或整体业务和行业发展，对这方面业务是怎样的期许。（价值的维度） 一个团队接手某项业务或需求，其背后都会有思考：我们是期望借着这个业务打造一个平台，提升整体行业的表现；还是突击这个业务方向，占领局部的商业蓝海······接到一个需求时一定要思考更大层面这事的价值，才能更好的判断优先级、做事模式。例如：我们做采购系统，当前需求是，提供采购单列表，按总价范畴搜索单据的能力。按结构化的中心建立，它是：高效稳定上线（事）、我职能范围内的工作（人）。 如果止步于单个需求建立的中心，我们后续的分解应当是如何快速搞定、如何更稳定······如果我们继续向上构建树，我们可以和产品、使用者深度沟通下为什么要做价格搜索：1. 管理员期望能看到高价订单的情况。那么这个需求的上一个中心节点应当是：管理提效；2. 继续向上，是基于什么原因需要做管理提效？因为防止贪腐、提高工作效率。那么上一个中心节点应当是：降低成本；3. 依次向上，直到抵达整个业务的目标。比如总结觉得，我们的业务是构建一个集成高效的集团采购系统；再以此反思：1. 降低成本是不是当前工作的重点？团队是否有足够的架构设计和人员组织来支撑？2. 下一步到到管理提效层面，订单的搜索是否真的是当前最佳的提效工具，因为用户如何定义高价格？他执行这种搜索式查阅工作是否真的是有效不遗漏的？查阅到了订单有问题他能做什么？······我们会发现这个需求背后更多的问题。我们也可以沿着更大的中心树，去思考是否构建更好的方案可以更根本的解决这个问题；  再回过头来看当前的任务，是否真的是高效稳定上线（事）、我职能范围内的工作（人）。或者当前最紧急的部分（用户直接需求嘛）是高效稳定上线（事）、我职能范围内的工作（人），但后续更要做更多的其他的根本性解决方案。 沿当前的中心向上建立更大的结构化的认知体系： 会让我们对当前事情的判断（中心）更加清晰，也有更好的认知基础，极有利于与合作方的沟通碰撞和内容创新；建立更大结构化认知体系的过程，也是深入业务、扩展认知力的过程。一定要多和老板、业务方交流，从各自认知的差异性上提升自身的认知能力。此外，构建更大认知体系，对个人和团队发展也是有价值的。 很多时候我们忙于业务实现，都没有花时间去思考业务的价值。一部分是因为忙，一部分是因为懒，一部分是因为不懂，一部分是因为我们是来做事拿工资的，而不是带着愿景想把事做好的。这都不是真正能把事情做好的方式；作为团队的一员，我们不应当只做“花时间、生鸡蛋”的极低人效、技术外包的母鸡模式，而应当积极的尝试做“建机器、铺厂房、出产品”的工厂模式。这对业务和个人的发展才是积极的作用。2. 中心的分解建立完成中心后，有多种对中心进行分解的方式。其目标在于将中心拆解为多个内聚的子部分。整体思想是 MECE（Mutually Exclusive Collectively Exhaustive）原则，即相互独立，完全穷尽不重叠、不遗漏的分类。够借此有效把握问题的核心，并成为有效解决问题的方法。 下文是一些分解方案的简介。1）SWOTSWOT 分析方法又称态势分析法：即 Strengths（优势）、Weaknesses（劣势）、Opportunities（机会）、Threats（威胁）四类。最早用于进行企业竞争态势分析，对个人而言用于分析自身的竞争态势也是极佳的。 （对团队数据可视化能力建设的 SWOT 分析示例） SWOT 分析法四个象限可以分别分类四大独立的方面，而其中 SW 部分 - 优势劣势一般用于分析内部条件；OT 部分 - 机会威胁一般用于分析外部情况。又形成了两个独立而全覆盖的大类分隔。非常有助于看清楚当前的情况。 此外，SWOT 形成的象限又可以结合跨大类进行组合分析： ...

这些年当程序员当得糊涂了，脑子里都是怎么更快更好得编码，却忽略了生活中经常能看到的概念，比如：传统企业、商业模式、数字化、平台化、互联网+等，虽然都听说过，也大概了解是个什么东西，但是当要自己说一遍的时候却是说不上来了。感觉自己像个文盲。 下面是一些关于“平台化”的文章：为什么越来越多的互联网产品在往平台化、社区化发展？ 想要将“平台化”这个概念变成自己的知识，我想应该要弄清楚下面这几个问题： 平台是什么意思平台化的好处平台化的局限性1. 平台是什么意思“平台”这个词有很多含义，这里特指的是互联网产品的一种存在形式。 网上没有发现权威的定义，我认为： “平台”是相对“工具”而言的，两者没有明确的界限，工具帮助人们完成某件具体的事情，平台包含了工具，并且还对工具进行了扩展。 工具：一个音乐播放器，它只能用来听歌，那么它是一个听歌工具。平台：一个音乐播放器，它不仅能听歌，还能K歌、看MV、直播、交友、创作、购物……这时传统的词汇就比较难以定义它到底是个什么东西了，这时可以称它为音乐平台。工具：一个购物网站，它只能用来买东西，那它就是一个购物网站而已。平台：一个购物网站，它不仅可以买东西，它还可以卖东西、分享购物心得、推广宣传、直播、贷款……它可以称为电商平台。 2. 平台化的好处增加流量、用户粘性平台化之后，功能更丰富了，满足了更多用户群体的需求，为产品带来了更多的流量，用户的停留时间也边长了。 流量变现途径更丰富音乐平台里不仅歌曲版权可以收费，还可以在：音效、音质、广告、听书、商城等功能上进行变现。 方便企业扩展业务扩展出来的功能，万一哪个火了，就可以独立成一个产品了。或者为新的产品进行引流。 其他看待问题可以从很多纬度、角度，好处肯定不止上面这些。 3. 平台化的局限性不适用于使用目的性很强的产品比如手机手电筒，就是用来照明的，要是加上一些附近也在照明的人、照明历史、照明直播的功能，emmm... 感觉是没什么用的。 得有一定的流量基础这个是我个人的感觉，没有数据支撑。一个产品首先得在其核心功能上有所建树，并积累了一定的用户群体之后，再进行平台化才能达到增加流量、增加用户粘性的目的。 其他是的，一定还存在其他局限性。

导读：在 2020 阿里云合作伙伴峰会上，阿里巴巴合伙人、阿里云智能基础产品事业部高级研究员蒋江伟发表了《深耕“被集成”，共建新生态》主题演讲，他在演讲中提到，阿里云将继续深耕“被集成”战略，做强生态，未来一年投入 20 亿专项资金，启动“云原生合作伙伴计划”，优选扶持 100 家头部合作伙伴，赋能 10000 家合作伙伴和 50 万开发者，共同服务百万云上客户，帮助合作伙伴实现云原生技术升级，合力加速百行千业实现数字化转型。 企业上云已经成为一种必然趋势。疫情之下，虽然各行各业都受到了不同程度的影响，但那些数字化能力健全的企业抵御风险的能力更强。经过此次疫情，越来越多的企业坚定了上云和实现数字化转型的信念和步伐，而云原生技术则是实现数字化转型的最短路径。 阿里云在全球领域内是云原生技术的定义者和领导者。目前，阿里云原生推出的技术栈已经覆盖了容器服务、Serverless 应用引擎、函数计算等技术，并结合自身在电商业务的生产实践进行了落地。借助阿里云原生产品，包括企业级分布式应用服务 EDAS、消息队列 MQ、性能测试 PTS、容器服务 ACK/ASK、Serverless 工作流、无服务器应用引擎 SAE 等云原生产品，可以加速企业数字化转型，享受云原生时代的技术红利。 “云原生合作伙伴计划”可以为企业带来哪些价值？「伯俊」成立于 1999 年，从成立之初就一直致力于零售相关的 IT 服务，并在零售行业有很深的积累，是规模最大、客户最多、口碑最好、技术最强的信息化建设服务商之一。伯俊软件 CEO 孙一晖曾表示，过去 20 年，伯俊积累了 3000 多个品牌客户，几乎所有的客户都在天猫上面做零售，所以伯俊和阿里巴巴的合作时间很长，但是和阿里云的合作，是始于 2017 年。在那一年，伯俊软件与阿里云全线展开深度合作，并提出了“All in 阿里云”的发展战略，与阿里云合作研发了 8 款联合解决方案，助力数千家零售企业以更低成本向数字化方向推进。其中，伯俊软件已成功交付的 20 多家企业级互联网中台客户，100% 基于阿里云。 伯俊软件为百丽国际打造的数字化营销解决方案，正是基于与阿里云合作开发的 CDP 数字化营销解决方案，可满足零售企业在顾客运营全链路覆盖、多渠道消费者数字信息的高效的 OneID 解决方案、自动化的精准营销活动等方面的需求，以支持企业在不断变化的市场需求中，进行数字化、精准化的营销。目前，该项目一期已经上线，百丽国际旗下滔搏运动已开始运作 CDP 并获得了显著成效。 日前，伯俊软件获得了阿里云原生合作伙伴认证授牌，双方将开展云原生技术的深度合作。成为阿里云云原生合作伙伴后，伯俊软件将基于阿里云丰富的云原生产品、高可用的基础架构支撑能力以及强大的安全服务，助力更多企业运用云原生技术加速数字化转型，快速落地“新基建”，实现业绩增长。 孙一晖表示，在这些项目中，不是阿里云签了合同然后再分给合作伙伴，而是阿里云找到合作伙伴联合研发产品，并一起向市场推出产品，这种合作思路给予了他们更大的空间。 「企加云」是另一家获得阿里云原生合作伙伴认证的公司。企加云消费者运营中台创立于 2017 年，专注在“消费者运营中台”领域，为企业提供“轻咨询+技术+运营”端到端方案。疫情以来，线上企业迎来业务快速增长，企业需要对市场做出快速响应，占领制高点，企加云基于云原生架构打造的消费者运营中台技术，帮助全时云会议、烨辉医药等企业实现按周迭代，系统快速支持亿级客户行为数据，在这一波市场红利中占得先机。 企加云一直是云原生架构的倡导者。通过加入阿里云原生合作计划，企加云将和阿里云深度携手，围绕阿里云原生技术栈的系列产品（EDAS、SAE、MQ、Kafka、MQTT、AMQP、ARMS、AHAS、PTS、函数计算、容器服务、Serverless 工作流等），展开销售、架构、开发、交付，运营等全方位合作。 正如企加云合伙人兼 CTO 罗义所言：“企加云将更加紧密的拥抱阿里云原生技术栈，在阿里云强大和深厚的技术加持下，不断深化云原生最佳实践，与阿里云一起，帮助更多的企业在数字化时代构建更加弹性、敏捷、稳定的系统。” 原“中间件合作伙伴计划”升级为“阿里云原生合作伙伴计划”，助力企业落地新基建据阿里云原生生态负责人宁晓民介绍，这次“阿里云原生合作伙伴计划”是原来“中间件合作伙伴计划”的一次重大升级，主要是包括三方面内容： 产品范围升级：在云原生技术浪潮之下，阿里云原生合作伙伴计划在技术先进性和产品定位上做了重大升级，从中间件技术向云原生技术的转变，从中间件驱动的阿里多年 双11 技术实践到云原生技术驱动 2019 年阿里集团核心系统 100% 上云，这充分证明了阿里云原生技术、产品体系的成熟。阿里云也希望通过云原生普惠的技术和产品帮助合作伙伴释放技术生产力。除了阿里中间件产品外，本次“阿里云原生合作伙伴计划”也覆盖了容器、微服务、Serverless、函数计算等众多产品；合作方式升级：在阿里云“做强生态”的战略指引下，以产品和解决方案“被集成”为核心，以帮助合作伙伴自身核心竞争力的成长为目标，阿里云原生合作伙伴计划从原来分销伙伴转变为解决方案伙伴，通过云原生技术和产品帮助伙伴的产品和解决方案技术换代，架构升级，让伙伴更加聚焦于自身业务优势，更好的发挥“长板效应”；合作权益升级：今年阿里云生态隆重推出“云聚计划”，投入 20 亿人民币，打造产品、技术、商务、交付的生态体系，阿里云原生合作伙伴计划对合作权益做了重点升级，计划重点扶持 100 家头部伙伴，赋能 10000 家伙伴，50 万开发者，在产品、技术、商务、交付等方面全方位地帮助伙伴能力成长。在这次峰会上，阿里云除了发布“云原生合作伙伴计划”之外，还发布了基础产品“企业工作台”合作计划。“企业工作台”以阿里云控制台为统一底座，提供丰富的阿里云 OpenAPI 能力，同时对外开放 CMDB、资源管理、身份管理、权限管理、审计合规的能力，生态伙伴可以在之上集成丰富多样的企业开发、运维、管控类工具软件。在传统模式下，一个 30 人的软件研发团队，基于企业工作台只需要 5 个人就足够了。同时企业工作台还把工具软件的权限管控统一收敛，用户不再需要把账号密码给到伙伴就能完成授权，最大程度地解决客户账号安全的问题。 ...

Redis 6.0更多精彩详情2020年6月23日，阿里云正式推出云数据库Redis 6.0版本。Redis 6.0版本为Redis开源社区于5月2日发布的全新版本，包含多项重大功能更新和大幅度的性能提升。 依托于阿里云强大的云服务与管控能力，以及团队的快速跟进，5月7日，阿里云仅用不到一周时间就完成了最新版Redis 6.0云数据库的全球首发（除原厂外），全面涵盖开源Redis 6.0的多项重大更新。 开源Redis 6.0版本在一系列关键领域进行了重大改进，而这些的背后都有阿里云数据库Redis团队的贡献。据统计，在Redis 6.0开源版本中，阿里云Commit贡献仅次于作者和 Redis Labs（Redis作者所在的商业公司），高居原厂外代码贡献第一名。 Redis社区版（6.0RC）Commit排行榜 阿里云Redis团队对社区版的贡献commit位居全球第二 在6.0版本中，最激动人心的是千呼万唤的Redis多线程终于发布，Redis性能和CPU并行利用率上均得到大幅度提升。用户可以通过可以设置 IO 线程数（注：该参数不包含 worker 线程），提升网络吞吐能力，进而提升整体处理性能。而命令的具体执行仍然是保留单线程，延续着Redis无锁的简单之美，在用户享受更大读写吞吐能力的同时，避免了上下文切换和锁操作带来的开销。 阿里云Redis团队在Redis 6.x 核心基础上对Redis多线程进行了深入优化，将我们企业版Tair的性能增强版中有关多线程的设计贡献给了社区，相比于社区最初多线程版本的设计，我们对Redis 6.0最终多线程版本的性能进一步提升了30%。 在开源Redis过去的版本中，安全时常被人所诟病。而Redis 6.0在数据传输和权限管理上都有了完整的解决方案。本次发布引入了TLS数据链路加密，提升了 Redis 数据传输安全性。对于数据链路的加密，阿里云 Redis 已经在之前就已经完整支持，并且对Redis 6.0的这部分，这项能力在几年前就是我们的标配了。 而在权限管理部分，Redis终于从过去单密码设置的极简配置演进到了比较完善的 ACL 管理能力，方便客户分账号、命令进行更细粒度的权限管理，安全性及易用性均得到了极大的提升。阿里云Redis也将过去权限管理的一些能力，输出给社区，对社区的ACL进行了bug修复和功能的扩展。 另外，阿里云还在复制机制的增强、稳定性增强以及新增多个实用命令和配置等方面为社区版做出了重要的贡献。 阿里云Redis团队在四大方面为社区版做出贡献 阿里云数据库高级产品专家，Redis产品负责人黄鹏程（花名：马格）表示， Redis 6.0是Redis发展史上极为重要的版本，多线程的设计为Redis带来了更大的性能提升空间。 阿里云Redis 6.0云产品的快速发布，展现了阿里云数据库Redis团队在Redis内核、架构以及功能改进与修复等多个方面的强大技术实力。阿里云数据库Redis 6.0的推出，将赋能广大用户，让Redis开发者们可以第一时间在云上体验Redis最新版本，使用最新特性。 阿里云 Redis 从 2015 年商用以来，一直是全球领先的云KV内存数据库产品。其背后的研发团队拥有众多顶级Redis社区Committer和中文社区组织者，为社区做出了卓越贡献，是国内最强大的Redis团队。 过去一年，我们更是将原服务于阿里集团内部、有着上万台规模、访问峰值高达10亿量级的Tair（兼容Redis协议的KV存储）作为Redis增强版输出上云，让广大深度使用Redis的客户共享阿里多年技术沉淀的成果。 除此之外，我们还为用户提供了Redis云数据库专属集群： （https://www.aliyun.com/product/apsaradb/cddc） 这是阿里云专为大中型企业用户定制优化的解决方案，填补了市场空白，具有资源独享、自主可运维、多数据库混合部署等特点，让用户既享受到云数据库的灵活性，又满足了企业对数据库合规性、高性能和安全性要求。 相关阅读：倒计时7天 | 全球第一的KV内存数据库即将再度升级！ 错过直播的同学可扫描下方二维码观看回放哦 公众号菜单栏回复“redis 6.0”即可获取讲师直播PPT资料啦！ 点击文字 立即解锁Redis 6.0更多精彩详情 新用户还可享5折优惠哦！

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 作为豆瓣9.0评分的作者，周志明算得上是一位Java大神，而他却对此不以为意，坦白Java只是一个工具。他的技术生涯似乎从未有过瓶颈，又或许，是他足够清晰和明确，一切都可以为自己所用，顺理成章地成长。以下为周志明的个人专访，推荐阅读（约3分钟）。热爱决定必然可能大家认识我都是从《深入理解Java虚拟机》这本书开始的。在十一二岁的时候，我就开始接触计算机了，大学也是计算机专业，很早的时候，我就隐隐知道，自己一定会从事IT行业。 作为一个80后开发者，虽然现在的岗位是上市公司高层管理人员，但我并不愿意脱离一线程序员的行列。平时的工作中，我主要从事宏观方向上的大型企业级软件的架构研发，却对高级语言虚拟机、程序语言设计、编译原理等偏底层、微观的方向更感兴趣。 另外，我对计算机科学相关的多个领域也都有持续跟进，比如软件架构、高级语言虚拟机、编译器、人工智能等等。我个人是开源精神拥护者，最近刚刚开始一个名为《软件架构探索：The Fenix Project》的开源文档项目。这些项目无关乎利益，只是个人兴趣。 目前我正式出版过七部计算机技术书籍，撰写过两部开源文档，口碑和销量均有幸得到读者的认可。其中四本书在豆瓣上获得了9.0分或以上的评价，《深入理解Java虚拟机》系列总销量逾30万册，在技术领域里算是个中翘楚了。有人曾问我为什么选择Java这门语言，与其说是我选择了Java，不如说是Java选择了我。我是个没什么技术忠诚度的人，不会因为熟悉和个人喜好就偏爱哪种语言，而是会根据具体情境来决断，在我眼里，技术本身就只是个工具而已。 成长如修炼，功到自然成宏观与微观之间融会贯通。人需要经常思考，“做什么”更重要，还是“为什么更重要”，即执行与知行。我个人更偏向于多问为什么，这也是我不愿意离开一线编程工作的原因，希望了解底层基础，效果是如何实现，为什么要这样实现。在对微观具象有了清晰的理解之后，才具备真正完成宏观掌控和抽象的可能。跟学功夫是一样的道理，头三年师傅不教把式，先扫地担水扎马步。练好内功再学招式，才能行云流水，步步生风。 开放的心态引领未来。一直以来，我都认为自己的技术生涯中不存在什么算得上是瓶颈的困难。比如最初我并不使用Java语言，但入职场后的第一个公司是走Java技术路线的，可能在别人看来就是障碍，但我认为这是一次值得庆幸的机会，所以并不排斥转变，很乐于接纳新事物和另一种思维。现在我同时在攻读博士学位，选择了人工智能领域，对我来说是完全陌生的，相当于从0开始，我也会非常珍视这样的契机。可以深入了解一个全新的技术、事物、领域，这种好事，怎能浪费？ 学会分享，加速成长。当我想以最快的速度掌握新知识的时候，我会通过学习和记忆，形成自己的一套方法论。然后再试着以老师的身份将知识教给别人，在这个过程中会发现自己有所欠缺的地方，查漏补缺后，再次简化和凝练，传递为更高效有价值的内容。这一套流程下来，会发现自己对知识的掌握炉火纯青，通过输入+输出的分享和沉淀小闭环，达成个人的螺旋上升。这也是国际顶尖学府都在推崇的费曼学习法。有些时候，选择比努力重要，选对方式，成功会简单一半。 提升社交圈，看见新世界。物以类聚，人以群分，当感知到周围的环境已经很难给自己带来提升和启发时，就是该做出改变的时刻。想办法进入到更高阶层的圈子，了解到更深层次的事物和运转模式，打开视野，能力的提升会有质的飞跃。 专注技术，也热衷生活在技术上，我格外较真，专注于细节，也会关注很多别人注意不到的价值，所以无论是团队、公司、合作伙伴，都一致评价我为靠谱的人。另一个评价就是“好欺负”，可以很融洽地跟下属们相处。大家跟我聊天都很放松，有的同事可能会忌惮我的下属，但都完全不会怕我。我还蛮享受这样的过程，可以获得很多其他人难以触及的东西。 在生活中，游戏占了我娱乐的很大比重。我是RTS竞技爱好者，Warcraft 3、Starcraft 12曾经有准职业的水准，从开始到AFK，一直都是星际2宗师组的玩家。大学时还拥有自己的游戏战队，现在也还在打游戏，除了放松以外，游戏可以很大程度上提高我的专注力。同时也是模型爱好者，每年都会自己打磨、喷漆2~3个GK模型，不过我并不是宅男哦。 在与周志明的沟通中，他似乎一直都保持轻松的状态侃侃而谈，好像并没有什么困难值得一提。但我发现，他只是更善于走捷径解决问题，成熟的方法论加多年如一日的专注，才收获了他水到渠成的成功。这位刚加入阿里云 MVP大家庭的新星，也将为技术普惠贡献出自己的力量。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 作为豆瓣9.0评分的作者，周志明算得上是一位Java大神，而他却对此不以为意，坦白Java只是一个工具。他的技术生涯似乎从未有过瓶颈，又或许，是他足够清晰和明确，一切都可以为自己所用，顺理成章地成长。以下为周志明的个人专访，推荐阅读（约3分钟）。热爱决定必然可能大家认识我都是从《深入理解Java虚拟机》这本书开始的。在十一二岁的时候，我就开始接触计算机了，大学也是计算机专业，很早的时候，我就隐隐知道，自己一定会从事IT行业。 作为一个80后开发者，虽然现在的岗位是上市公司高层管理人员，但我并不愿意脱离一线程序员的行列。平时的工作中，我主要从事宏观方向上的大型企业级软件的架构研发，却对高级语言虚拟机、程序语言设计、编译原理等偏底层、微观的方向更感兴趣。 另外，我对计算机科学相关的多个领域也都有持续跟进，比如软件架构、高级语言虚拟机、编译器、人工智能等等。我个人是开源精神拥护者，最近刚刚开始一个名为《软件架构探索：The Fenix Project》的开源文档项目。这些项目无关乎利益，只是个人兴趣。 目前我正式出版过七部计算机技术书籍，撰写过两部开源文档，口碑和销量均有幸得到读者的认可。其中四本书在豆瓣上获得了9.0分或以上的评价，《深入理解Java虚拟机》系列总销量逾30万册，在技术领域里算是个中翘楚了。有人曾问我为什么选择Java这门语言，与其说是我选择了Java，不如说是Java选择了我。我是个没什么技术忠诚度的人，不会因为熟悉和个人喜好就偏爱哪种语言，而是会根据具体情境来决断，在我眼里，技术本身就只是个工具而已。 成长如修炼，功到自然成宏观与微观之间融会贯通。人需要经常思考，“做什么”更重要，还是“为什么更重要”，即执行与知行。我个人更偏向于多问为什么，这也是我不愿意离开一线编程工作的原因，希望了解底层基础，效果是如何实现，为什么要这样实现。在对微观具象有了清晰的理解之后，才具备真正完成宏观掌控和抽象的可能。跟学功夫是一样的道理，头三年师傅不教把式，先扫地担水扎马步。练好内功再学招式，才能行云流水，步步生风。 开放的心态引领未来。一直以来，我都认为自己的技术生涯中不存在什么算得上是瓶颈的困难。比如最初我并不使用Java语言，但入职场后的第一个公司是走Java技术路线的，可能在别人看来就是障碍，但我认为这是一次值得庆幸的机会，所以并不排斥转变，很乐于接纳新事物和另一种思维。现在我同时在攻读博士学位，选择了人工智能领域，对我来说是完全陌生的，相当于从0开始，我也会非常珍视这样的契机。可以深入了解一个全新的技术、事物、领域，这种好事，怎能浪费？ 学会分享，加速成长。当我想以最快的速度掌握新知识的时候，我会通过学习和记忆，形成自己的一套方法论。然后再试着以老师的身份将知识教给别人，在这个过程中会发现自己有所欠缺的地方，查漏补缺后，再次简化和凝练，传递为更高效有价值的内容。这一套流程下来，会发现自己对知识的掌握炉火纯青，通过输入+输出的分享和沉淀小闭环，达成个人的螺旋上升。这也是国际顶尖学府都在推崇的费曼学习法。有些时候，选择比努力重要，选对方式，成功会简单一半。 提升社交圈，看见新世界。物以类聚，人以群分，当感知到周围的环境已经很难给自己带来提升和启发时，就是该做出改变的时刻。想办法进入到更高阶层的圈子，了解到更深层次的事物和运转模式，打开视野，能力的提升会有质的飞跃。 专注技术，也热衷生活在技术上，我格外较真，专注于细节，也会关注很多别人注意不到的价值，所以无论是团队、公司、合作伙伴，都一致评价我为靠谱的人。另一个评价就是“好欺负”，可以很融洽地跟下属们相处。大家跟我聊天都很放松，有的同事可能会忌惮我的下属，但都完全不会怕我。我还蛮享受这样的过程，可以获得很多其他人难以触及的东西。 在生活中，游戏占了我娱乐的很大比重。我是RTS竞技爱好者，Warcraft 3、Starcraft 12曾经有准职业的水准，从开始到AFK，一直都是星际2宗师组的玩家。大学时还拥有自己的游戏战队，现在也还在打游戏，除了放松以外，游戏可以很大程度上提高我的专注力。同时也是模型爱好者，每年都会自己打磨、喷漆2~3个GK模型，不过我并不是宅男哦。 在与周志明的沟通中，他似乎一直都保持轻松的状态侃侃而谈，好像并没有什么困难值得一提。但我发现，他只是更善于走捷径解决问题，成熟的方法论加多年如一日的专注，才收获了他水到渠成的成功。这位刚加入阿里云 MVP大家庭的新星，也将为技术普惠贡献出自己的力量。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

摘要：本文根据 Flink Forward 全球在线会议 · 中文精华版整理而成，围绕着项目的开始、需求分析、开发，以及测试、上线、运维整个生命周期展开，介绍了 Apache Flink 实践中的一些典型误用情况，并给出了相应的更优实践方案。 Flink 实践中最首当其冲的误用就是不按迭代开发的过程操作。最佳实践应该遵循迭代开发的步骤进行，包含以下几个阶段： 项目开始涉及分析开发测试上线维护1. 项目开始在开始开发前，我们需要选择正确的切入方式，以下几种往往是最糟糕的开始： a) 从一个具有挑战性的用例开始（端对端的 Exactly-once、大状态、复杂的业务逻辑、强实时SLA的组合） b) 之前没有流处理经验 c) 不对团队做相关的培训 d) 不利用社区在开发的过程中，其实要认认真真的来规划我们的切入点，首先，要从简单的任务开始循序渐进。要有一定的大数据和流处理的知识积累，尽量参加一些培训，也要利用好社区资源。基于这样的想法，我们就能很快找到切入点。 怎么样去做？社区提供了很多的培训，包括 Flink Forward 和 Vererica 网站上有各种培训课程，大家可以去看。同时，可以充分利用社区。社区还建立了中文的邮件列表，大家可以充分利用中文邮件列表来解决手头的疑难杂症。另外，Stack Overflow 也是个提问的好地方，但在提问前尽量去看一看已有的提问，做到心中有数。 邮件列表： user@flink.apache.com/user-zh@flink.apache.orgStack Overflow： www.stackoverflow.com2. 设计分析方案设计中的一些常见错误思维，往往是由于没有充分思考需求导致的，比如： a) 不考虑数据一致性和交付保证 b) 不考虑业务升级和应用改进 c) 不考虑业务规模问题 d) 不深入思考实际业务需求我们要认真分析需求，同时认真考虑实际交付情况。提到一致性和交付保障，其实可以通过几个问题来引导大家完成这件事，如下图所示： 第1个问题，是否在乎数据的丢失？ 如果不在乎，你可以没有 Checkpoint。 第2个问题，是否在乎结果的正确性？ 在很多的场景里面，我们非常关注结果的正确性，比如金融领域，但是另外一些场景比如监控或其他简单的使用场景仅需要一个概要的数据统计。如果不在乎结果的正确性，可以考虑用 at-least-once 的模式配置并使用可回放的数据源。相反，如果结果的准确性十分重要，且下游不关心重复记录，那么仅需设置 exactly-once 模式并使用可回放的数据源。如果下游要求数据不能重复，哪怕数据正确也只能发送一次，这种时候就对 sink 有更进一步的限制，在 exactly-once 的模式下，使用可回放的数据源，并且 sink 需要支持事务。 带着这样的思维方式分析业务，才能非常清晰地知道，怎么去使用 Flink，进而避免一些糟糕的事情发生。 完成分析之后，最终目的是什么？我们为什么要有这种选择，而不是一上来就选一个最好的方案？ 因为世界上永远没有“最好”，这里的核心因素就是延迟，要根据业务的延迟和准确性需求来均衡去做选择。 当需求都分析好之后，还需要去思考应用是否需要升级。从一个正常的 Flink 作业来讲，我们有几个问题要考虑。第一个，Flink 作业一般都有状态读取，做升级时需要有 savepoint 机制来保障，将状态存储保留在远端，再恢复到新的作业上去。很多场景下都会有升级的需求，这简单列了几点： ...

作者 | 不瞋  阿里云高级技术专家 导读：Serverless 是如何产生的？当前有哪些落地场景？Serverless 的未来又将如何？本文分享了阿里云高级技术专家不瞋对于 Serverless 的看法，回顾其发展历程，并对 Serverless 的发展趋势做出预测。 源起回望整个计算机技术发展史，我们会发现 “抽象、解耦、集成” 的主题贯穿其中。产业每一次的抽象、解耦、集成，都将创新推向新的高度，也催生出庞大的市场和新的商业模式。 大型机时代，硬件和软件都是定制化的，使用专有的硬件、操作系统和应用软件。 PC 时代，硬件被抽象解耦成 CPU、内存、硬盘、主板、USB 设备等标准化的部件，不同厂商生产的部件可以自由组合，组装成整机。软件被抽象解耦为操作系统、库等可复用组件。硬件和软件的抽象解耦，创造了新的商业模式，释放了生产力，造就了 PC 时代的繁荣。 云的时代，硬件软件化和软件服务化成为最显著的两个趋势。 硬件软件化的核心在于硬件功能中越来越多的部分由软件来呈现，从而在迭代效率、成本等方面获得显著优势。以软件定义存储（Software Defined Storage，SDS）为例，SDS 是位于物理存储和数据请求之间的一个软件层，允许用户操控数据的存储方式和存储位置。通过硬件与软件解耦，SDS 可运行于行业标准系统或者 X86 系统上，意味着用户可以无差别的使用任何标准的商用服务器来满足不断增长的存储需求。硬件与软件解耦也让 SDS 能够横向扩展，消除容量规划，成本管理等方面的复杂性。 云时代的另一趋势是软件服务化。应用软件的功能通过网络以远程调用的模式被海量用户使用。服务成为应用构建的基础，API 被实现为服务提供给开发者，微服务架构获得广泛的成功。服务也成为云产品的基本形态。过去 10 年，云已经证明了它的成功。用户只需要通过调用 API 就能获取服务器，而无需自己建设数据中心。算力以前所未有简洁的方式提供给用户。 还记得 Google 那篇著名的 “Datacenter as a computer “ 论文吗？如果我们把云看作是 DT 时代的计算机，那么一个很自然的问题是：随着云的 API（全托管服务）越来越丰富，什么才是适合于云的编程模型？我们应当以何种 “抽象、解耦、集成” 的方式构建基于云的应用？ 在回答上述问题之前，让我们首先将目光转向 SaaS 领域。Salesforce 是 SaaS 领域的明星企业，在平台化能力建设方面的布局为我们提供了一个绝佳的案例。早期的 SaaS 产品采用标准化的交付模式，通过开放 API 接口实现被集成的能力。随着 Salesforce 产品越来越丰富，客户规模日益增长，企业开始面临新的挑战： 如何更快地推出新产品，加强产品间的整合和协同？客户迅速增长，需求多样。如何高效地满足客户的定制化需求，增加客户粘性？如何提高产品被集成的能力，更好的衔接上下游资源？当产品能力和 API 完整度到达一定水准后，如何让开发者快速整合 API，围绕 Salesforce 能力便捷地开发应用？如何设计好的商业模式，让客户、企业和开发者共赢？Salesforce 的策略是让整个业务、技术和组织平台化。平台放大了企业的价值，让企业、客户、开发者三方受益。通过不断提升平台的应用交付能力，对内大幅提高产品的研发效率，加强产品的集成和整合；对外则大幅提高了产品的被集成能力，建立开发者生态。 ...

事务的概念在这篇文章中描述过，在分布式系统中，读写位于多个节点的数据，如果依旧想保证ACID特性，就必须实现分布式事务。而其实现关键则是适当的提交协议，目前最简洁，且使用最广泛的无疑是两阶段提交协议（2PC）。 1.实现分布式事务关键组件单机系统通过事务管理器（transaction manager，TM）实现本地事务。分布式系统中，需要协调多个节点的事务管理器，共同提交成功或失败，因此需要事务协调者（transaction coordinator，TC）。一个分布式事务管理器，可以粗略地划分为这两个子系统。这两个子系统根据自己在事务执行中扮演的角色，也可称之为参与者与协调者。 本地事务管理器负责本机事务并发控制和异常恢复等功能，事务协调者负责开启事务，将事务划分为多个子事务分发到相应的节点执行，并协调事务完成（一起提交成功或失败）。在实现中，TM和TC可以实现在同一个进程中，也可以部署在不同的节点。 2.经典两阶段提交协议两阶段提交的流程比较简单。当分布式事务T执行完成，即事务执行的各节点都告知协调者TC，事务已经执行完成，TC便开启两阶段提交流程。 Phase 1 Prepare： 1.TC写本地日志，并持久化。TC向所有参与者发送Prepare T消息。 2.各参与者TM收到Prepare T消息，根据自身情况，决定是否提交事务。 如果决定提交，TM写日志并持久化，向TC发送Ready T消息。如果决定不提交，TM写日志并持久化，向TC发送Abort T消息，本地也进入事务abort流程。Phase 2 Commit : 1.当TC收到所有节点的回应，或者等待超时，决定事务commit或abort。 如果所有参与者回应Ready T，则TC先写日志并持久化，再向所有参与者发送Commit T消息。如果收到至少一个参与者Abort T回应，或者在超时时间内有参与者未回应，则TC先写日志，再向所有参与者发送Abort T消息。2.参与者收到TC的消息后，写或日志并持久化。 两阶段提交协议可以保证分布式事务执行的一个关键点：参与者在向协调者发生Ready T消息前，随时都可以自己决定是否abort，一旦这个消息发送，那么这个事务就进入ready状态，commit和abort完全由协调者控制。Ready T消息本质上是参与者向协调者发送的一个郑重的、不可逆的承诺。为了保证这一个承诺，参与者需要在发送Ready T消息前将所有必要的信息持久化，否则如果参与者在发送Ready T后异常宕机，重启后可能无法遵守以上承诺。在第二阶段，当协调者写了或日志，整个事务的命运就被决定了，不会再发生变化了。 为了优化2PC性能，减少关键路径的持久化和RPC次数是关键，一种对经典2PC的优化思路如下： 协调者无状态，不再持久化日志，但是为了方便宕机重启后恢复事务状态，需要向每个参与者发送事务的参与者名单并持久化。这样即使协调者宕机，参与者也可以方便地询问其他参与者事务状态了。该思路相当于参与者在协调者宕机时，自己担当起协调者询问事务状态的任务。 只要所有参与者prepare成功，事务一定会成功提交。因此为了减少提交延时，协调者可以在收到所有参与者prepare成功后就返回客户端成功，但如此，读请求可能会因为提交未完成而等待，从而增大读请求的延时。反过来，如果协调者确认所有参与者都提交成功才返回客户端成功，提交延时比较长，但会减少读请求延时。 3.两阶段提交协议异常处理两阶段提交协议的正常流程较为简单，但它还需要考虑分布式系统中各种异常问题（节点失败，网络分区等）。 1.如果协调者检测到参与者失败： 如果参与者在发送Ready T前失败，则协调者认为该节点事务Abort，并开始abort流程。如果参与者在发送Ready T后失败，证明参与者本地事务已经持久化，协调者忽视参与者失败，继续事务流程。2.如果参与者在事务提交过程中失败，其恢复过程，需要根据参与者日志内容，决定本地事务状态。 如果日志中包含日志，证明事务已经成功提交，REDO(T)。如果日志中包含日志，证明事务已经失败，UNDO(T)。如果日志中包含日志，参与者P需向其它节点咨询当前事务状态。如果协调者正常，则向告知参与者P，事务已经commit或是abort，参与者依此REDO(T)或UNDO(T)。如果协调者异常，则向其它参与者询问事务状态。如果其他参与者收到信息，并已知事务是commit还是abort状态，需回复参与者P事务状态。如果所有的参与者现在都不知道该事务的状态（事务上下文销毁了，或者自己也处于未决状态），那么该事务处于暂时既不能commit也不能abort。需要定期向其它节点问询事务状态，直到得到答案。（这是2PC最不想遇到的一个场景）如果日志中不包含上述几种日志，说明该参与者在向协调者发送Ready T消息前就失败了。由于协调者没有收到参与者的回应，会超时Abort，因此该参与者在恢复过程中，遇到这种情况也需要abort。3.如果协调者在事务提交过程中失败。参与者需要根据全局事务状态（通过与其它参与者通信）决定本地行为。 （事务状态已经形成决议：） 如果至少有一个参与者中事务T已经提交（参与者包含日志），说明T必须要提交。如果至少有一个参与者中事务T已经Abort（参与者包含日志），说明T必须要Abort。（事务状态未形成决议：） 如果至少有一个参与者没有进入Ready状态（参与者不包含日志）。说明全局还未就提交与否达成协议。有两种选择：（1）等待协调者恢复。（2）参与者自行abort。为了减少资源占用时间，选择后者居多。如果所有参与者都进入了Ready状态，且都没有或日志（事实上，即使有这些日志，查日志也是一种比较费的操作，还需要考虑日志回收的问题），这种情况下，参与者谁都不知道现在事务的状态，只能死等协调者恢复。（又到了这个最不想遇到的场景）当参与者均进入ready状态，等待协调者的下一步指令，协调者在这个时候出现异常，那么参与者将一直持有系统资源，如果基于锁实现的并发控制，还会一直持有锁，导致其他事务等待。这种情况如果持续较旧，会对系统产生巨大的影响。因此2PC最大的问题就是协调者失败，可能会导致事务阻塞，未决事务的最终状态，只能等待协调者恢复后才确定。同时在这种情况下，参与者宕机重启，回放到这类未决事务，也会因为死等而block recovery流程。 4.缓解2PC blocking思路三阶段提交是两阶段提交的延伸，目的是解决2PC block的问题，但是也引入了其它问题。它的解决方式是为参与者引入timeout机制，如果参与者成功PreCommit后，一直收不到协调者最后的DoCommit请求，等待超时自动提交，显然这样会引入一致性问题，例如，协调者收到一个参与者PreCommit失败，打算发abort请求给其它参与者时宕机，显然此时该分布式事务应该失败，但一些参与者可能因为超时而提交。 为了解决这个问题，3PC多引进了一个阶段，就是第一个阶段CanCommit阶段，协调者询问所有参与者是否可以提交，参与者如果状态正常，就会回应可以提交，但此时并不会占用任何系统资源。如果协调者及时收到了所有参与者ok的回应，便会认为各个参与者正常，之后的提交应该不会失败。但是实质上，仍有小概率失败的可能：某参与者PreCommit失败后，协调者和参与者都宕机，其它参与者超时自动提交，产生不一致。 因此3PC还有一个关键优化是协调者宕机后，迅速找到一个继任者，继续未完的流程，尽量保证不会出现参与者超时提交的现象。但是如果出现诸如网络分区等异常，新的协调者联系不上参与者，还是会产生一致性问题。 3PC通过牺牲一定的C(onsistency)来提高A(vailability)，并且增加了网络开销，这些都是OLTP系统很难接受的，所以基本没有系统会采用。 但是协调者高可用，确实可以使block的时间大幅减少，基于诸如Paxos/Raft的一致性协议的高可用方案，可以让多个节点就commit/abort达成一致后，再去通知参与者，当协调者出现异常，可以迅速选出新的协调者，推进事务至完成。

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 跟唐云峰对话的时间比我们预想的都要长很久，却丝毫不觉得疲倦。聊到被奉为电脑神童的经历、中学就赚到几十万的奇遇，明明是现在听来都不可思议的桥段，却被唐云峰轻松地一带而过，颇有些“古今多少事，都付笑谈中”的淡定从容。以下为唐云峰的个人专访，推荐阅读（约4分钟）。电脑神童的第一桶金我算是国内第一批站长，1986年出生，10岁开始研究计算机，最初尝试用HTML写网站，后来出于兴趣对网络服务做了很多研究，并从1999年起以此牟利。当时很多公司都找不到能帮助他们实现技术需求的人，而一个小孩子解决了问题，就很容易被传得神乎其神。一来二去，电脑神童的称号就被冠名了，其实现在看来并不困难。那时做网站非常昂贵，一单能赚几十万，高中和大学期间也一直在接商业项目，从来都不缺钱花。后来需求越来越多，成立了工作室，教授一些同学朋友和成年人，帮我分担部分工作，也开始培训各种网站站长。 2001年我开始做《人物春秋》Renwu.net网站，随着网站资料的增多和全文检索的要求出现，开始研究搜索相关的技术；2003年为了加强网站内文章内容和人物的关联性，开始研究关键词提取和文本聚类相关的技术。同时开始用Flash做起了电子杂志，讲一些过去的历史故事。做电子杂志的过程中开始思考，能否将大量的制作工作使用读取配置的方式自动生成，于是做了很多代自动生成Flash电子杂志的框架。 在我们那个时代，获取信息和知识大多是通过书报，当我第一次看到互联网传媒的窗口时，就被深深地震撼了，从事传媒的梦想也像种子一样在少年的心里发了芽。对《人物春秋》的投入也是出于少年时期不切实际的想法，比如探究人性和本心，挖掘不同视角的价值。少年的执念不可小觑，到现在我也没有放弃对传媒梦想的追求。 不务正业是属于极客的倔强一直以来，我都有点不务正业。2008年开始研究如何用手机短信进行百度搜索，开发了具有简单语义识别能力的短信引擎，甚至用短信的方式做了短信农场。然而这绝对是最失败的案例，因为智能手机开始流行了。但也帮我打开了新天地，就是开始关注硬件的变化对技术和应用带来的影响。 接下来的一两年，固态硬盘出现了实用化趋势，内存大规模的降低了单位成本，CPU也开始出现了性能过剩。我把90年代末的拖机卡挖掘出来加上了虚拟机，搞起了桌面虚拟化的一些技术实践。紧接着我发现一个好玩的传感器，可以对脑电波进行采集和处理，为了读取数据，又研究起了Arduino。自此对于开源硬件的喜爱一发而不可收。2013年，我沿着文本处理的方向继续走向了NLP的斜路，做了大量的文本情感训练，最终用于舆情监测。当AI逐渐火热，我意识到是时候让“人工智障”耳聪目明起来了，于是2016年开始正式给自己打了一个标签——物联网。 虽然看起来是零基础步入物联网领域，但事实上我所做的事情与物联网的关联源远流长。开公司第一年正赶上偷菜游戏流行，在转租来的30亩土地，想实现线上线下的联动，但由于市场问题没有商业产品成型，不过现在转租来的600亩土地上设计着各种尝试。有一次在新闻上看到长途司机由于疲劳驾驶导致事故的新闻，就开发了一套检测客货车司机疲劳状态的系统，通过脑机接口实时同步到公司和部门等。 诸如此类的例子还很多，发现有需求，就会着手去执行，并不会考虑太多商业价值。虽然很多事情自己无法左右大局，但力所能及的贡献我从不吝啬。有点任性，但遵从自己的本心，永远好奇，立刻行动，姑且算是极客最后的倔强吧。 关注人的价值，视野与格局同样重要我始终认为技术的意义最终在于解放人力，让人有空闲时间去做自己喜欢的事情。比方说，我们公司保洁阿姨的工作就非常轻松，因为区域内已经实现物联网最大化，几乎所有设备都可以通过手机一键管理。每个传感器监控着周围多少平米的卫生和空气质量，一目了然；甚至可以在APP上查看到卫生纸使用情况，哪一间的卫生纸用完了，系统会自动提示，不需要保洁阿姨每天逐个查看。能真正实现切实可感的便利，我觉得对我们技术人来说有很大意义。 如此一来，才能更好地发挥人独有的价值，比如创造力和想象力，又或者彼此之间宝贵的情感交流。现在我跟西南财经大学合作的人工智能项目就致力于机器的感知能力，面对真实的世界，而非冰冷的数据。甚至可以通过未来的边缘计算和区块链保护信息资料和个人隐私不泄露，让数据更有价值也是我从事物联网行业的目的。 以我个人多年来的身体力行，分享一些少走弯路的经验。最根本的一点是要有良知和底线，做阳光下的业务，用技术来提供正向能量。现在我公司最重要的项目之一是环保方面的创新，即使长远的目标现在看来是幻想，也不会对我的步伐形成阻挡。可能这是中国人骨子里流淌的一点信念吧，愚公移山和精卫填海看起来“蠢不可及”，但只要我看到了、看不顺眼了，就不会置之不理。 从视野来说，技术人在做好本职工作的前提下，可以考虑用历史的眼光去看待正在使用的技术。虽然没有几个人的代码能够永垂不朽，但我也希望真正热爱技术的人能有时忘却营营，尝试给自己定一个简单的开发任务，尝试用各种的开发工具、技术栈去实现。 从观念来讲，要尊重传统行业，物联网就是在为传统行业更新升级。年轻人要努力看到更核心的东西，搞不定大场景没关系，从小场景入手，基于模块化搭建。要基于对场景的理解去做应用，始终明确我们不是为了做传感器，不是为了兜售技术，不是为了上云，而是为了最终解决问题。 最后从执行来说，要深入行业一线，身体力行才能成为专家。物联网的实地环境脏乱差，无可逃避。在做过火锅店底油溯源和化粪池项目以后，我总是对别人自称“潲水佬”和“挑粪工”。这些从前极少有人愿意做的脏活累活，如今可以通过技术来监测和完成，“技术让生活更美好”终于不是一句空话了。创业者或开发者要学会站到业务立场上，而不仅仅局限于技术立场，这样才能成为领域专家而非物联网专家。 对其他知识的输入也不失为一种提升自己思考和认知能力的捷径。闲下来我会刷刷剧，通过对《庆余年》这类现象级作品保持对传媒的输入，《甄嬛传》甚至看了几十遍。也会用大量的整段时间学习金石、篆刻、堪舆、中医等过时技术。现在也会时常学习一些理论物理学的知识，也许五六十岁的时候可以成为一名物理学家呢。 在听到唐云峰丰富的技术创造经历时，我总觉得颇有些生不逢时的英雄主义悲壮色彩，而他似乎毫不在意。他戏称自己是个怪物，那些尝试作为商业人算是失败，作为科学家绝对是成功。或许结果对他来说并不重要，是因为这些体验已经造就了这位阿里云 MVP足够有趣的灵魂吧。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

作者| 郡宝 阿里云技术专家 参与文末留言互动，即有机会获得赠书福利！ 导读：存储服务支撑了应用的状态、数据的持久化，是计算机系统中的重要组成部分，也是所有应用得以运行的基础，其重要性不言而喻。在存储服务演进过程中，每一种业务类型、新技术方向都会对存储的架构、性能、可用性、稳定性等提出新的要求，而在当今技术浪潮走到云原生技术普及的时代，存储服务需要哪些特性来支持应用呢？ 从本文开始，我们将用一个系列文章对云原生存储进行方方面面的探析，该系列文章将从云原生存储服务的概念、特点、需求、原理、使用、案例等方面，和大家一起探讨云原生存储技术新的机遇与挑战，欢迎大家讨论： "There is no such thing as a 'stateless' architecture" - Jonas Boner云原生存储系列文章(一)：云原生应用的基石 云原生存储系列文章(二)：容器存储与K8S存储卷 云原生存储系列文章(三)：Kubernetes存储架构 云原生存储系列文章(四)：K8S存储实践-Flexvolume 云原生存储系列文章(五)：K8S存储实践-CSI 云原生存储系列文章(六)：存储卷高可用方案 云原生存储系列文章(七)：存储调度与容量感知 云原生存储系列文章(八)：数据卷扩缩容能力 云原生存储系列文章(九)：云原生存储安全 云原生存储系列文章(十)：高性能计算场景的存储优化本节会介绍云原生存储的基本概念和常用的存储方案。 云原生存储1.概念要理解云原生存储，我们首先要了解云原生技术的概念，CNCF 对云原生定义如下： 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。简言之：云原生应用和传统应用并没有一个标准的划分界限，其描述的是一种技术倾向，即越符合以下特征的应用越云原生： 应用容器化服务网格化声明式 API运行可弹性扩展自动化的 DevOps故障容忍和自愈平台无关，可移植的云原生应用是一簇应用特征能力的集合，而实现了这些能力的应用在可用性、稳定性、扩展性、性能等核心能力都会有大幅的优化。优异的能力代表了技术的方向，云原生应用正在引领各个应用领域实现云原生化，同时也在深刻改变着应用服务的方方面面。存储作为应用运行的基石，也在服务云原生化过程中提出了更多的需求。 云原生存储的概念来源于云原生应用，顾名思义：一个应用为了满足云原生特性的要求，其对存储所要求的特性是云原生存储的特性，而满足这些特性的存储方案，可以称其为倾向云原生的存储。 2.云原生存储特征1）可用性存储系统的可用性定义了在系统故障情况下访问数据的能力，故障可以是由存储介质、传输、控制器或系统中的其他组件造成的。可用性定义系统故障时如何继续访问数据，以及在部分节点不可用时如何将对数据的访问重新路由到其他的可访问节点。 可用性定义了故障的恢复时间目标（RTO），即故障发生与服务恢复之间的时长。可用性通常计算为应用运行时间中的可用时间的百分比（例如 99.9%），以及以时间单位度量的 MTTF（平均故障时间）或 MTTR（平均修复时间）来度量。 2）可扩展性存储的可扩展性主要衡量以下参数指标： 扩展可以访问存储系统的客户端数量的能力，例如：一个 NAS 存储卷同时支持多少客户端挂载使用；扩展单个接口的吞吐量和 IO 性能；扩展存储服务单实例的容量能力，例如：云盘的扩容能力。3）性能衡量存储的性能通常有两个标准： 每秒支持的最大存储操作数 - IOPS；每秒支持的最大存储读写量 - 吞吐量；云原生应用在大数据分析、AI 等场景得到广泛应用，在这些重吞吐 / IO 场景中对存储的需求也非常高，同时云原生应用的快速扩容、极致伸缩等特性也会考验存储服务在短时间内迎接峰值流量的能力。 4）一致性存储服务的一致性是指在提交新数据或更新数据后，访问这些新数据的能力；根据数据一致性的延迟效果，可以将存储分为：“最终一致”和“强一致”存储。 不同的服务对存储一致性的敏感度是不一样的，像数据库这类对底层数据准确性和时效性要求非常高的应用，对存储的要求是具有强一致性的能力。 5）持久性多个因素应用数据的持久性： 系统冗余等级；存储介质的耐久性（如：SSD 或 HDD）；检测数据损坏的能力，以及使用数据保护功能重建或恢复损坏数据的能力。3.数据访问接口在云原生应用系统中，应用访问存储服务有多种方式。从访问接口类型上可以分为：数据卷方式、API 方式。 数据卷：将存储服务映射为块或文件系统方式共应用直接访问，使用方式类似于应用在操作系统中直接读写本地目录文件。例如：可以将块存储、文件存储挂载到本地，应用可以像访问本地文件一样对数据卷进行访问； API：有些存储类型并不能使用挂载数据卷的方式进行访问，而需要通过调用 API 的方式进行。例如：数据库存储、KV 存储、对象存储，都是通过 API 的方式进行数据的读写。需要说明的是对象存储类型，其标准使用方式是通过 Restful API 对外提供了文件的读写能力，但也可以使用用户态文件系统的方式进行存储挂载，使用方式模拟了块、文件存储数据卷挂载的方式。 ...

CDN是内容分发网络，它可以将本来位于源站的内容分发到全国各地的节点，方便用户去就近访问所需的内容，以此达到缓解互联网网络拥塞、提升应用响应速率、改善用户体验的作用。随着互联网行业的变迁，CDN经历了几个关键的技术发展阶段。 紧随互联网浪潮，CDN走上历史舞台谈到CDN诞生，不得不得到万维网之父Tim Berners-Lee。麻省理工学院教授Tim Berners-Lee作为互联网发明者之一，在制订了3w标准后，敏感地预见到在不久的将来网络拥塞将成为互联网发展的障碍，于是他提出一个技术挑战，要发明一种全新的、从根本上实现互联网内容的无拥塞分发的方法。当时在隔壁的Tom Leighton意识到通过数学算法可以解决内容传输的问题，并且开始实施自己的商业计划，在1998年成立了第一家CDN商业公司。 此后的1999年至2001年，全球互联网迎来发展浪潮，网站和互联网服务如同雨后春笋般蓬勃生长，网页内容加速需求爆发，CDN也因此走上历史舞台。最早CDN都是以将静态内容缓存到终端用户附近的形式来存在的，比如将文本、HTML、JSS、图片、文件等缓存到网络边缘，如果源站有新的静态资源产生，CDN也会及时去缓存这些资源，这可以避免集中访问带来的拥塞，并优化跨地域、跨运营商访问性能问题，让用户更快地浏览到想要的内容，也能为源站服务器的减负。 行业变迁，从内容缓存到动态加速随着互联网的兴起，一方面，传统HTTP和下载网络流量飙升，视频等大流量内容的出现，对服务器和带宽带来巨大的挑战，另一方面，网民的行为也逐渐丰富，网站内容类型也不断增加，流媒体、Flash、交易、支付、O2O等各种业务出现在互联网上。大部分网站从原本的静态，过度到动静结合的形式，比如电子商务、游戏和企业应用类网站，会存在很多如.aspx、.asp、.jsp、.php等为后缀的动态请求加速。通常缓存对静态内容支持得较好，而当面临动态内容请求的时候，一般会回源，源站再将内容传节点，进而传给用户，传输链路步骤增多，这势必会影响传输质量与效率。 所以针对动态内容，CDN也提出了新的加速方法，就是利用智能选路、传输协议优化等算法寻找最快的传输路径，自动躲避拥堵和不稳定线路，以此来提升回源效率，实现动、静混合网站的加速效果保障。 移动视频时代，CDN迎接高速发展此后的移动时代到来，短视频、直播等应用得到普及，CDN也迎来了一段难得的高速发展阶段。这个阶段锤炼CDN在流媒体服务的数据监测和服务能力，比如高吞吐、超低延时、低成本、高流畅、高可靠等，关注的技术指标也从基础的缓存命中率、延时、源站带宽降低，扩展到首播时间、推流稳定性、卡顿率等。 CDN利用智能调度系统来实现节点之间水位的均衡，结合一些节点内部的稳定性优化策略，以此来缓解流媒体对CDN节点的流量冲击。 着眼当下，CDN已成为政企数字化转型的基础设施时光更迭，在2020年初，受到疫情影响，大部分的购物、培训、会议、课堂都转战线上，网络流量暴增，一方面，这无疑是对CDN行业的一次全盘大考，也推动CDN技术向着更健康、更稳定的方向去发展； 另一方面，在更多政府和传统企业加速数字化转型的大环境下，CDN作为互联网基础设施的重要性也进一步凸显出来。传统企业如何利用CDN建设运营好线上业务运营能力，提升客户沟通或者组织协同效率，增强自身容灾能力，成为能否顺利实现数字化转型中的关键一步。而CDN也将迎来场景的进一步开拓。 对于政府和传统企业来说，由于其业务复杂度和差异度，对内容分发提出了全新的要求，比如数据资产的安全传输、源站的高可用性、合规认证、技术服务支撑等等，分发与边缘安全同样重要。 阿里云CDN产品专家彭飞认为：“举个例子，通常我们都会在源站部署相应的DDoS和WAF防护，一旦业务越出源站通过CDN这张网络进行全球分发，企业会自然而然希望能够继续抵御恶意请求，来保证分发链路上的安全，这是当下企业对CDN的合理诉求。CDN不应该只是用于加速，它必须被赋予更多的使命，来帮助企业屏蔽互联网上的各色挑战。” 因为互联网技术的成熟与进化、场景逐渐丰富，用户内容消费方式的巨大变革，这也驱动着CDN不断向更垂直细分、更多元化的技术方向演进。这就需要CDN服务提供商的精耕细作，不断发挥自身优势，构建深入细分领域和场景的企业级综合技术解决方案。 阿里云推出政企安全加速解决方案 赋予未来更多可能为了帮助政企更好迎接国内数字化发展机遇，阿里云也推出政企安全加速解决方案。 解决方案是在CDN全站加速产品（动静混合加速）基座之上，通过在边缘注入国际领先的云安全能力，构建成为链路层安全、网络层安全、应用层安全、内容安全、高可用安全、安全合规六大安全体系，并且打通自动化运维、应急响应、事件护航等三种服务支撑保障，一站式兼顾分发加速与业务安全，帮助金融、传媒等传统企业以及数字政府极速、可靠、安全、合规的使用互联网与用户交互，提升用户访问效率的同时抵御潜在风险。 总结CDN早已不仅仅是当初的缓存的概念，它甚至已经从内容分发演变成为价值传递。在整个互联网发展进程中，CDN的渗透率不断升高，但是不可否认的是，在我国CDN市场仍然存在很大的发展空间。 当5G与物联网时代来临，边缘计算逐渐成为行业焦点。CDN天然分布式部署则可以与边缘计算实现有效结合：通过底层基础设施资源的广泛覆盖，叠加上层安全、存储、计算能力，实现面向垂直领域的场景化解决方案，帮助企业缓解运维难度和负担，提升行业信息化效率。

一、背景阿里云对象存储 OSS 是保存海量数据的平台，支持丰富的应用。在使用过程中难免会遇到误操作、程序 Bug、覆盖写等导致数据被删除的场景，对于数据的丢失会非常着急，后果也非常严重，甚至某些情况下还会影响你的职业生涯。OSS 每年都会遇到多起客户误删除数据的事件，为此 OSS 开发了 版本控制 功能，开启该特性后，可以在误删除数据时通过历史版本找回数据。 二、版本控制技术介绍存储空间（Bucket）开启版本控制后，OSS 会为 Bucket 中所有文件（Object）的每个版本指定唯一的 ID 值，且 Bucket 中现有 Object 的内容、权限保持不变。开启版本控制后，还能够防止意外覆盖或者删除 Object ，并允许查询、恢复 Object 的历史版本。详细信息，请参考 官网 介绍。 如上图所示，通过 PUT 操作第一次上传同名 Object （key=example.jpg）时，原始 Object 版本（ID=111111）作为历史版本，生成的新版本（ID=222222）将作为当前版本保存在存储空间中。当再次上传同名 Object 时，原始 Object 版本（包括 ID=111111 以及 ID=222222）将作为历史版本，而生成的新版本（ID=333333）则作为当前版本保存在 Bucket 中。 三、数据防误删实际操作3.1 开启版本控制开启版本控制有两种方式： 创建时，选择开通 版本控制。创建后，设置 版本控制。 因此，通过创建后设置版本控制，可以对存量的OSS数据设置版本控制，有效的保障历史数据。 3.2 上传对象开启版本控制后，在控制台有 显示对象的历史版本 框，选择该框则可以显示对象的历史版本，如下图所示。 通过在控制台上传同名对象，则会生成多个版本，其中显示 (最新版本) 的那个对象是最新对象，更新时间 也是最近的时间。 3.3 删除对象开启版本控制后，删除对象并不会真正删除，而是插入 删除标记，如下图所示。 删除对象后，如果没有选择 显示对象的历史版本，则在控制台显示该文件不存在，但实际上对象并未删除，因此可以支持后面的恢复操作。 3.4 快捷的恢复数据由于开通了版本保护，数据历史版本并未删除，可以采用下图所示的顺序，DIY 恢复数据。第一步，选中 显示对象的历史版本，此时可以看到历史版本，其中显示 (删除标记) 表示该对象被删除。第二步，删除该 (删除标记) 就可以让数据在控制台重新可见。第三步，删除标记成功后，最近的版本被恢复为 (最新版本)，此时不管是否选中 显示对象的历史版本，都可以在控制台看到该对象。 因此，开通了版本控制后，可以非常便捷的 DIY 恢复数据，不用再担心“误操作、程序 Bug、覆盖写”等带来的严重影响。 ...

1.任务编排介绍数据库是企业IT系统里的重要基础设施，里面存储了大量有价值的数据资产，如：交易数据、客户数据、订单数据，等等。其实，数据库在企业里一直扮演着一个数据生产者（Producer）的角色，日积月累这些数据会形成一个巨大的宝藏。但是，随着数据库中数据量的增长和数据形态的多样化，如何对数据进行存储、迁移和加工，并挖掘出其中的价值，是许多企业面临的难题。 为解决上述问题，阿里云DMS（Data Management Service）产品近期推出了一个新功能——任务编排。无论您的数据库部署在何处（阿里云/本地IDC/其他云厂商等），是何种类型（OLTP交易型数据库/OLAP分析型数据库），DMS任务编排都能够触达您的数据库，让您轻松地对数据库中的数据进行流转、加工和变换。DMS任务编排提供的主要功能和特性包括： 丰富的数据迁移能力：可实现数据库与数据库之间（如：OLTP在线库与OLAP离线库）、数据库与弹性存储之间（如：MySQL与OSS）的数据自由流动；丰富的数据加工手段：单库SQL任务、跨库SQL任务、数据迁移任务、Spark任务、数据备份与恢复服务（建设中）；不仅可以通过SQL语句对单个数据库或多个数据库里的数据进行加工，还可编写Spark任务进行复杂的数据处理和AI分析；任务流和定时调度：通过可视化的方式将多个任务节点进行编排形成任务流，灵活按需设置多种不同粒度间隔的定时调度；按模板一键创建任务流：为不同的场景（如：历史数据归档到OSS）内置了任务流模板，用户可一键生成模板任务流，通过简单的配置即可应用于生产；牢靠的数据安全保障：依托DMS强大的数据安全能力，任务编排会对用户权限进行严格检查，仅限有权限的用户才能执行相应的任务。了解了DMS任务编排的功能，你一定开始好奇用DMS任务编排能做什么？下图展示了DMS任务编排支持的四类主要场景： 场景1：数据归档目前比较流行的有两类数据库：传统单机版数据库（如：MySQL）和云原生数据库（如：阿里云PolarDB和AnalyticDB for MySQL）。前者的存储空间是有限的，后者虽然可以对存储扩容，但也要收取较高的费用。那么，当数据库中的数据量持续增长时，该如何降低存储成本呢？许多用户希望能将数据库中的冷数据/历史数据转储到可靠又低价的存储上，如：阿里云对象存储（OSS）。现在通过DMS任务编排，可轻松实现数据库数据周期归档（如：每日/每周）到OSS的需求。同时，DMS还有好地对接了阿里云数据湖分析产品（DLA），用户可在DMS里方便地访问DLA，对归档到OSS上的数据进行即席查询和分析。 场景2：数据集成企业的数据可能分散在不同的数据源中（如：MySQL、SQL Server），也可能分散在不同的地域（例如：北京、杭州、深圳）。导致数据分散的原因有很多，比如：业务的垂直划分、微服务、应用的本地部署等等。数据的分散不可避免，但同时许多企业又有数据集成的需求，需要将各地的数据汇聚到一起进行全局分析（如：汇总和AI分析），典型的场景就是OLTP交易库的数据同步至OLAP分析库做离线分析。通过DMS任务编排，可以轻松实现这一需求。首先，DMS打通了各种网络环境（如：阿里云VPC/经典网络，本地IDC网络），可连接至各个地域的数据源。其次，DMS支持异构数据源间的数据集成，如：RDS MySQL到AnalyticDB。此外，通过DMS任务编排，还能满足各种集成方式的需求，如：单次全量集成、周期性增量集成。 场景3：数据加工做完数据集成之后，用户通常还要对汇聚的原始数据进行加工、清洗和分析，才能挖掘出其中的价值，例如：每日统计产品的用户数（UV），按周产生报表数据。DMS任务编排提供了任务流和定时调度能力，通过任务流可以将复杂加工任务进行拆解和编排，然后配置调度信息。DMS支持单次调度和周期调度（如：按日、周、月），此外还支持多类型的加工任务，用户可使用SQL进行数据加工，也可编写Spark程序进行复杂的数据处理和AI分析。通过丰富的调度配置和任务类型，DMS任务编排能满足各种简单/复杂场景的数据加工需求。 场景4：定时操作在日常数据库的使用中，有许多DML/DDL/DCL操作需要定期执行，如：每周清理历史数据（DELETE）防止表过大、每日更新统计信息（ANALYZE TABLE）以获得更好的查询优化结果。有些数据库在内核层面已经提供了事件调度功能，如：MySQL Event，但是使用特殊的语法创建Event和维护Event都有一定的成本。DMS任务编排的调度功能提供了可视化的方式轻松创建定时任务，并且不依赖数据库引擎上的能力，因此更加简易灵活，适用范围更广。 2.任务编排实操 — DB数据周期归档介绍完DMS任务编排的功能和使用场景，下面将以数据归档场景为例，介绍如何通过DMS任务编排和阿里云DLA服务将RDS MySQL数据周期地归档至OSS上。具体的实操步骤还可查阅DMS的使用文档。 2.1 背景和需求用户的RDS MySQL业务库中某张表（如：交易记录、登录/操作日志）的数据持续增长，占用了大量的存储空间，甚至影响到了数据库性能。同时，这部分数据又是有价值的，比如：用于审计、报表和统计分析，不能随意删除。为解决这个问题，用户有三个核心的需求： • 降低MySQL业务库的存储压力; • 对历史业务数据做增量归档； • 对归档数据做分区，可按分区过滤进行高效查询。 为满足这三个需求，我们选择了阿里云DLA服务，因为其同时打通了OSS和RDS MySQL，能够对上面的数据进行迁移和即席分析。但是，DLA并不具备周期调度和增量数据迁移的能力，DMS任务编排正好可以与DLA互补，形成完整的解决方案满足用户需求。 在下面的实操中，我们假设用户RDS MySQL中待归档的表为订单表orders，其表结构如下（created_date字段为订单创建日期）： create table orders( order_id bigint, product_name varchar(32), price double, total_amount double, created_date date);2.2前置条件1、已购买阿里云DLA服务，且DLA服务的区域（Region）和待归档的RDS MySQL区域一致，如：都是华东1（杭州） 2、已开通阿里云OSS服务，且服务的区域与DLA、RDS MySQL一致 3、已购买阿里云DMS服务 4、DLA实例已录入DMS中（请参考DMS实例录入） 各产品的购买要求和用途： 产品 购买产品的区域 用途 DMS 无限制 周期调度 DLA 与RDS MySQL同区域 RDS MySQL数据迁移至OSS；查询OSS上的归档数据 OSS 与RDS MySQL同区域 ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 胡逢法作为阿里云 MVP，是一名经验丰富的人工智能领域研究专家，谦虚诚恳、精力充沛。在智能图像视频分析、智能交通等诸多领域研发深有建树，拥有发明专利十余项，希望他的看法能给大家带来启发。以下是胡逢法的专访，推荐阅读（约5分钟）。思考点燃理想，尝试成就结果初中时，学校附近有个工厂，课余时间经常跑到那里去看工人干活，看到很多场景觉得比较好玩，比如工人在做产品质量检查，当时都是用肉眼去看的，我当时想，这类工作得一个个用人去看去记录，要是用机器自动去完成该多好，那时我对自动化及视觉设备这一块应该已经萌生了兴趣。读研的时候，我发现图像处理这些研究很有实际应用价值，例如机器替代人工去做很多繁琐且辛苦的事情可以缓解很多工人的压力等。所以我的学习和工作也一直在做这些方面研究，我逐渐地把自己的想法，通过结合各个模块的知识添加到系统里的方式来实现很多功能。 以前我是做算法类的，只要把某个功能点写好即可。智慧园区的一个项目需要我从技术和业务两个角度考虑问题，不同的视角不断碰撞，于是产生新的点子。在这个过程中有很多知识和技术可以更好地结合利用起来，做出的效果令人很有成就感，对个人的经验和能力来说都有很大提升。 负重前行，每一次转折都弥足珍贵我的职业生涯有几次较大转折，从规模庞大的上市公司，到初创的技术团队，再到杭州际视科技有限公司的合伙人。尤其家人会不理解，觉得大公司很好，瞎折腾什么？ 个人认为大公司拥有完善的机制、企业文化等，这些对于培养职业素养方面有很多好处，我现在仍然保持当时养成的一些好习惯并在工作中颇有收益。同时，在大公司也会存在一些限制，后来我有自己的想法想去实现，所以去了互联网创业公司体验。其实每次转变过程也是对自己内心的一种拷问，我不是想简单的跳槽，而是在朝我想要的方向去发展。这个过程也包括对自己优势劣势的考量、生活工作的复盘，以及对未来的重新规划。 挑战肯定是有的，比如在大公司工作时，更倾向于专注，大多数时候只需要负责好个人的小模块并不断专精就可以高枕无忧了。而到一个初创团队里，需要考虑的问题接踵而来，做事方式、沟通方式需要转变，思维都需要转变等，刚开始时会有些不适应，对个人来说也是一种挑战。由大多数时候只需做好某个领域的技术活，其他事情基本上不用管，转为不光专精某一方向，还需要不断扩充周边知识，不同方向的内容产生交集。从原有的点向面的碰撞，到需要掌握更多的系统性的工作，对个人来说这也是一笔宝贵的经历。 与时俱进，融会贯通随着近几年深度学习的兴起，视频图像智能的准确率在很多应用领域已经超过了我们人眼的识别，如人脸识别、目标识别。但是从更高的维度去考虑，如视频的分析、视频的理解，个人认为目前图像以及相应的算法还处于人类的婴儿期，比如说：它可以区分出这是什么那是什么；但是当这些变成一个视频序列的时候，比如在一个固定的场景中，要让它判断这个人在干什么，理解发生了什么事情，还需要探索一段时间。未来会朝着场景理解这方面推出新的应用和创新，比如在智慧园区智慧工地里面，发现工人工作时的危险行为，能进行甄别和及时危险预警；在心理学上，结合图像或者脑电波以及心理学等方面的知识，对人的心理活动进行探索。也就是从目前图像检测、分类跨到对图像和视频系列的理解，进阶到更高的维度。 目前看来，图像视频这一块发展是挺迅速的。近年来，随着硬件的性能拓展和提升、深度学习的发展，不论性能还是准确率都提升非常快。早些年的时候，做一些最简单的物体分类，可能得花上几个月才能做成一个比较好的分类器（比如人脸识别），目前有一些现有的模型可以在几周甚至几小时就可以得出效果更好的分类器。所以知识在不断的更新时，我们也要不断地学习，更新技术和知识体系。可以参考最新的一些会议，国内外高效的论坛等。另外一个重要的点是，个人要善于横向发展，融会贯通，很多东西都是源于生活又高于生活，实际上很多问题结合生活中很浅显的例子就可以引用过来更便于理解，特别是我们视觉上的方式比较直观，可以用简单的模型引用到复杂的逻辑上，这样会理解得更快。 勤于思考，勇于创新，胡逢法也在努力践行阿里云 MVP的使命，用其思考和技术为人类探索更美好的生活。 胡逢法近期技术分享：智慧厂区视觉防控探索实践 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

阿里云 Redis 直播地址 近年来，完美日记的“小黑钻口红”“动物眼影盘”等爆款彩妆出现在了越来越多女孩子的化妆台上，完美日记（Perfect Diary）是由逸仙电商在2017年推出的彩妆品牌，凭借着高颜值和性价比，完美日记彩妆销量增长迅猛，被众多网友誉为国货之光。 2019年8月完美日记业务爆发后，开始与阿里云进行深度合作，基于阿里云成熟的数据库产品，完美日记快速复制电商数据库最佳实践，通过PolarDB + DTS +AnalyticDB 组成HTAP解决方案，2020年4月，完美日记3周年大促，系统吞吐量相比半年前提升50倍。 上云，打通线上线下数据2019年，逸仙电商开始全面推进新零售业务，依托线上销售经验及数据支撑，联动线上线下打造自由无拘束的美妆体验店。起步于电商的完美日记如何才能在竞争激烈的线下市场开辟一片属于自己的天地，上云，正是助力完美日记推进新零售业务的重要一步。 区别于传统线下店铺，完美日记线下体验店的所有购买流程，比如试妆、下单、取货等都可以在手机上完成，将线下数据数字化便于分析决策的同时，也将线下体验店的消费者引导到线上，便于完美日记进行后续更擅长的线上运营。 阿里云成熟的数据库PaaS产品简单高效地满足了完美日记运营人员对数据在线化的需求，使得完美日记的技术团队可以聚焦在业务上，更好地支持了完美日记业务的快速发展。 上云，给消费者更顺滑的购物体验现在电商大促节、淘宝直播带货促销层出不穷，伴随着“3,2,1”的倒数，紧接而来的往往是秒空。这短短的几秒钟看起来像是一场狂欢，对于数据库而言则是一场对于高并发处理能力的大考，既需要满足快速响应极速下单也要防止超卖，如果因为超卖而导致延迟发货，在等待发货的日子里，消费者极有可能会不耐烦取消订单，也会在消费者心里留下一个发货慢的印象，从而影响后续是否回购的动作，这对于粉丝留存来说非常地不利。 伴随着线下门店迅速扩张，直播带来的巨大流量，面对业务量爆发，完美日记的业务系统在数据库方面也遇到了库存不统一超卖、数据库吞吐难以提升、升降配周期长、统计分析的SQL性能差等电商业界的常见问题，基于以上问题完美日记与阿里云开始深入合作，希望能够基于阿里云成熟的数据库产品，快速复制这些电商数据库最佳实践。 经过细致的探讨，阿里云针对完美日记架构规划和技术演进分两个阶段来进行。通过仅1个月时间的第一个阶段优化，利用阿里云PTS压测工具快速搭建对全链路进行压测，确认系统水位线和瓶颈，对每一个实例进行调优，全面梳理每一个数据库的系统资源使用率和系统瓶颈。 完美日记在2019年天猫双11刷新销售纪录，仅用28分钟就超过了2018年双11全天销售额，成为第一个登上天猫双11彩妆榜首的国货品牌。 而在第二阶段，2020年4月，完美日记3周年大促最后一天压测，订单系统下单速度摸高到1万笔/每秒，对应PolarDB数据库的写入速度10万TPS，比半年前的系统吞吐提升了50倍！ 4月14日活动当天，抢购开始瞬间系统涌进了几百万用户，在几十秒内抢空了几十万件小狗盘眼影。每秒成交的订单数再创历史新高，订单峰值比历史最高峰值再次提高了几倍，高峰业务流量比半年前提高了50倍，系统丝般顺滑！ 上云，数据更加安全稳定随着完美日记的用户和GMV继续快速增长，对系统可靠性的要求也会越来越高，而阿里异地多活的数据库解决方案将是最好的可参照样板。完美日记在2020年Q1借助阿里云DBS服务快速实现了异地备份，以满足安全等保三级的要求。并且完美日记也成为数据库自治服务DAS商用后的第一批用户，体验到了数据库自感知、自修复、自优化、自运维及自安全等强大和便捷的功能。完美日记目前正在实施分布式数据库改造，改造完成后，电商系统将可以实现线性的性能扩展。 完美日记的数据库架构 从2018年8月份完美日记开始使用阿里云Redis集群，2019年8月份业务爆发之后开始深度使用PolarDB for MySQL。 截止目前，完美日记在数据库方面基本 All in 阿里云产品，在美妆产品上，完美日记跨界联名玩得风生水起，这次数据库方面完美日记全面上云，利用阿里云数据库PaaS服务迅速解决了很多业界常见的痛点，给所有的独角兽企业树立了一个利用数字基础设施助力业务快速增长的标杆。 作为全球云数据库市场份额前三及中国市场第一的厂商，阿里云在产品技术领域发展迅猛，获得市场广泛认可，连续2年作为唯一的中国企业入选Gartner数据库魔力象限。目前，已有超过40万个数据库实例迁移到阿里云上，包含政务、零售、金融、电信、制造、物流等多个领域的龙头企业。 直播预告 6月23日15：00-16：00 我们一起见证 Redis 史上最大更新 点击文字 预约观看直播Redis 6.0版发布会

作者 | 阚俊宝 阿里云技术专家 导读：云原生存储详解系列文章将从云原生存储服务的概念、特点、需求、原理、使用及案例等方面，和大家一起探讨云原生存储技术新的机遇与挑战。本文为该系列文章的第二篇，会对容器存储的相关概念进行讲述，欢迎大家在留言区参与讨论。相关文章推荐： 云原生存储详解：云原生应用的基石 云原生存储详解：容器存储与 K8s 存储卷云原生存储的两个关键领域：Docker 存储卷、K8s 存储卷； Docker 存储卷：容器服务在单节点的存储组织形式，关注数据存储、容器运行时的相关技术；K8s 存储卷：关注容器集群的存储编排，从应用使用存储的角度关注存储服务。Docker 存储容器服务之所以如此流行，一大优势即来自于运行容器时容器镜像的组织形式。容器通过复用容器镜像的技术，实现在相同节点上多个容器共享一个镜像资源（更细一点说是共享某一个镜像层），避免了每次启动容器时都拷贝、加载镜像文件，这种方式既节省了主机的存储空间，又提高了容器启动效率。 1. 容器读写层为了提高节点存储的使用效率，容器不光在不同运行的容器之间共享镜像资源，而且还实现了在不同镜像之间共享数据。共享镜像数据的实现原理：镜像是分层组合而成的，即一个完整的镜像会包含多个数据层，每层数据相互叠加、覆盖组成了最终的完整镜像。 为了实现多个容器间共享镜像数据，容器镜像每一层都是只读的。而通过实践我们得知，使用镜像启动一个容器的时候，其实是可以在容器里随意读写的，这是如何实现的呢？ 容器使用镜像时，在多个镜像分层的最上面还添加了一个读写层。每一个容器在运行时，都会基于当前镜像在其最上层挂载一个读写层，用户针对容器的所有操作都在读写层中完成。一旦容器销毁，这个读写层也随之销毁。 如上图所示例子，一个节点上共有 3 个容器，分别基于 2 个镜像运行。 镜像存储层说明如下： 该节点上共包含 6 个镜像层：Layer 1~6。 镜像 1 由：Layer 1、3、4、5 组成；镜像 2 由：Layer 2、3、5、6 组成。所以两个镜像共享了 Layer 3、5 两个镜像层； 容器存储说明： 容器 1：使用镜像 1 启动容器 2：使用镜像 1 启动容器 3：使用镜像 2 启动容器 1 和容器 2 共享镜像 1，且每个容器有自己的可写层； 容器 1（2）和容器 3 共享镜像 2 个层（Layer3、5）； 通过上述例子可以看到，通过容器镜像分层实现数据共享可以大幅减少容器服务对主机存储的资源需求。 ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 我和田亮的交流耗时较久，甚至用上了他出差的所有碎片时间，而他的回答始终谨慎、认真、高效。历任搜狐、阿里巴巴、新浪微博，10年如一日始终深耕大数据领域，阿里云 MVP田亮能在百舸争流中成为大数据和人工智能领域的佼佼者，似乎也就不奇怪了。以下为田亮的专访内容，推荐阅读（约5分钟）。兴趣导向职业，信心坚定抉择在读研期间我就深深痴迷于大数据这个领域，与几个同学一起做了很多这方面的应用实践，大数据是一个机遇与挑战共存的方向，毕业时我就坚定了这个择业目标，整个职业履历也聚焦在分布式计算系统、大数据云计算平台以及机器学习算法与AI。 以我个人对大数据10年的研究来说，大数据变革可以分上下两半场，前5年聚焦在云计算基础设施方面，企业级应用从自建到逐步迁云，技术选型上摆脱IOE的垄断，有了新的技术思路与选择。后5年聚焦在大数据的应用场景上，企业级数据应用不再是大数据变革的目标，而是更多地渗透到人们日常生活中，改变大家的生活方式，甚至未来社会经济发展的模式。 大家都知道大数据与云计算是密不可分的共同体，大数据促使云计算迭代，云计算支撑着大数据业务的落地与发展。随着移动互联网的高速发展，每日数据增长达到几何级别，这对大数据计算提出了前所未有的挑战，包括研发效率，运维成本，数据安全，容灾等环节。于是我们尝试寻找更具性价比的优化方案，同时积极调研下一代大数据计算解决方案，也就是基于开源技术的Hadoop云计算生态链。困难重重，但是解决问题的信心始终很坚决。 转到有信后，从0到1组织大数据团队，从0到1构建大数据平台基础设施，是最大的困难了。在诸多数据业务已排期的背景下，需要在较短时间内快速组建一只具备核心战斗力的大数据团队，那段时间里我们白天进行项目开发，晚上面试招人，工作节奏超负荷。多线程任务的情况下，完成数据仓库、批处理（离线计算）、流式处理（实时计算）、推荐系统、BI、中间件等平台服务的搭建，从而才能有效保证数据业务的迭代，也是极大的挑战，但也会带来更大的成长。 细化受众，专注价值选择克拉克拉（KilaKila）做声音社交是因为几个明显优势：故事性更强、互动性更高、场景覆盖更广、内容具备沉淀价值，所以有更持久的生命力。社交网络的核心在于平台让人与人之间形成关系并随时随地无边界的对话沟通。我认为未来的社交方向则朝个性化、细分领域的目标发展，“兴趣社交”就符合这个定义。通过情感连线精细垂直的主题圈子，可以避免无聊又混乱的信息噪音，从而得到沉浸式的体验。 我负责有信和克拉克拉两个产品时，为解决信息过载，用户难以从中自主挑选感兴趣内容的问题，我们首先构建个性化推荐系统，除采用传统的机器学习算法外，还引入在线学习、强化学习、迁移学习等技术，值得高兴的是每一次技术架构的迭代都对业务发展带来了直观提升。 定位清晰，持续学习我个人认为大数据开发者从方向与职业规划上大致分成 2*2=4种人才定位。从方向上讲，大数据领域有平台开发与应用开发两个方向，前者聚焦在基础平台研发环节（平台工程师），后者聚焦在数据业务环节（策略&算法工程师）。从职业规划来讲，一种是技术专家线，这类开发者需要对所在领域有着深入的技术储备，了解相关技术原理，追踪前沿技术发展；另一种是技术管理线，该人才定位除了有技术深度还要有广度，包括团队管理能力、敏锐的业务意识以及前瞻性，负责把控项目进度与风险预判、公司技术规划与规范等，属于综合型人才。 无论将自己定位于何种类型，唯一的建议是持续性学习。这样的学习不局限于前沿技术跟踪，还要提升产品意识、思维方式、沟通技巧等多个方面。 笃定前行，不忘初心，田亮一直在发挥更大的价值。阿里云也始终在陪伴MVP成长，并一路见证他们的努力。 田亮近期技术分享：基于深度学习技术的视频内容检测 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

随着网络技术的发展，越来越多的应用基于互联网发布，再好的应用，如果打开速度慢，10个用户会有9个用户选择离开，相关统计数据显示，每增加0.1秒的加载延迟，将会导致客户活跃度下降1%。在目前获客成本较高，用户面临众多可选项的情况下，如何提高用户访问的体验，给用户留下良好的第一印象，提高ROI，是所有开发互联网应用的企业都关注的核心问题。 影响应用资源加载的因素很多，服务器性能、网络传输质量、网站出口带宽状况、DNS解析时间、网页内容大小、终端用户网络质量等，在云计算技术高度发达的今天，并非每一个环节的优化都需要企业自己造轮子，更为便捷可行的选择是：借助云服务商提供的相应加速服务来优化企业的应用，可以实现更低的成本、更敏捷快速的建设、更强壮和高性能的服务，用来取代传统的用昂贵的成本购买大量服务器、带宽做自建的模式。 标准CDN服务所擅长加速的内容是静态内容，如文件、图片、视频等，通过CDN的缓存策略来缓存并实现加速。但互联网上的应用复杂，源站往往也会有很多经常变化的内容---动态内容，如用户登录、内容搜索、视频弹幕、直播评论、购物交易、股票行情、体育实况等，很多时候这些应用没有做动静分离设计和动静内容分别处理，这也造成很多应用即使采用了标准CDN服务，却没有达到很好的加速效果，因为动态部分内容的加速性能并没有得到很好的优化。 对应上叙的情况，我们推荐使用阿里云全站加速产品，阿里云全站加速产品是阿里云自主研发的融合了动态加速技术和静态加速技术的CDN产品，可以很好的解决页面动静态资源混合、跨运营商、网络不稳定、单线源站、突发流量、网络拥塞等诸多因素导致的响应慢、丢包、服务不稳定的问题，全面提升全站性能和用户体验。 阿里云全站加速产品可以有效提升静态、动态内容的加速效果。下面的图我们可以具体看下，使用全站加速产品前后的效果对比。从实际的测试结果图中可以看到使用全站加速前，无论访问效率，还是节点加速效果，都较未使用前有了明显的提升。 那阿里云全站加速怎么样才能够实现以上的效果呢？主要通过以下四个方面完成： 第一、全球覆盖的加速节点 阿里云在全球有2800+节点，这些节点涵盖了中国国内、欧洲、美洲、亚洲、非洲等全世界的大部分区域，同时这些节点都是互联了当地最核心的运营商网络，阿里云全站加速可以保证全球用户都能够找到离他最近的、访问质量最好的和用户接入网络运营商相对应的加速节点。 第二、全球智能调度系统 在上面我们讲到了覆盖，只有覆盖还是不够的，还需要把用户调度到对应的最合理的节点，这个环节就非常取决于调度的IP库的完善性和准确性。阿里云全球智能调度系统结合阿里整体庞大的用户基础（淘宝、天猫、优酷等），基于这些用户基础可以打造非常详尽、精准的用户IP库，可以有效保证用户接入匹配的高准确度。 第三、智能自适应缓存 业界一般对于全站加速的场景，需要客户手动配置动静态内容，来让CDN平台执行动态和静态两种加速模式。但是很多网站特别是中小客户，动静态内容区分不是很清晰，不便于做动静态的区分。全站加速推出的动静态智能自适应功能，可以让客户不再需要繁琐配置动静态内容区分，全站加速会自动的分析和识别请求和响应特征，智能的对访问的内容进行动静态分类，让可以缓存的静态内容避免了动态化访问源站，从而降低了回源带宽、回源时间而提升了性能。当然，阿里云全站加速平台也支持客户通过自定义的方案，很方便的自行定义实动静态内容加速规则。 此外，针对静态内容，阿里云全站加速还可以通过智能压缩功，自动对静态文件进行Gzip压缩，以及通过页面优化，对当前域名下所有HTML页面中冗余的注释和重复的空白符进行优化，以减小传输文件大小，减少流量支出和提升加速分发效率。 第四、智能路由 对于无法缓存或者不允许缓存的内容，最核心的处理逻辑是实现路径加速，阿里云的路径加速是通过智能路由来实现的，在广泛覆盖的节点之间，通过实时探测通信网络质量，并根据探测的质量，进行路径的有效分析，同时结合阿里达摩院的最佳数据计算模型，提供一条从用户的接入点到源站之间一个最优的路径，实现最好的加速效果。 阿里云全站加速产品除了通过以上的策略提供了优秀的加速效果之外，还提供了下面的相关的功能模块让客户的服务可以变得更灵活和更健壮，以及还提供了更广泛和新颖的加速模式： 第一、源站策略 1、智能回源策略 全站加速除了提供最优链路回源来保证最好的服务质量的同时，还提供了丰富的回源策略管理。很多客户的场景处于安全和自身业务的需求，往往会有一些复杂的策略需要CDN来适配。目前全站加速在回源策略方面具有丰富的功能。 可以根据特定的URL回不同的源站；可以根据区分国内和海外客户，进行分国内和海外回源；可以根据网民的DNS情况，回对应区域的源站；2、灵活回源配置和重试容灾策略 阿里云全站加速提供了灵活的回源配置策略，可以根据需求配置多主源（可设置不同的回源权重）、主备源，源站可以使用IP和域名。 网络情况瞬息万变，连接抖动和拥堵时常发生，在长链路传输时，情况会更加严峻。通常情况下在回源阶段，因为链路的加长，整体的网络可控性降低。经常会遇到回源节点的机房网络有问题，回源的某条运营商链路断了等等相关的问题。 结合阿里云全站加速的提供了多种回源配置以及回源重试容灾策略，可以避免单源站问题、源站单IP问题、源站偶发不通等问题，给业务提供更健壮的一个支撑。 3、 WaitingRoom回源方案 在回源的时候，有的时候会面临一种场景，就是某次突发活动请求的压力非常大，举个例子，比如在春运火车票购票的时候，请求的压力可能是平时压力的上百倍，短时间之内没有办法扩容这么大倍数能力的源站来解决请求问题的（短时间内扩容源站上百倍的能力，会面临到很大的成本压力以及很长的时间周期问题）。针对上面这种场景，全站加速提供了WaitingRoom解决方案，可以灵活根据请求的URL、配置的回源比例、排队时长，实现突发情况下有序的回源，保证源站服务稳定性。 第二、全链路https加速 我们知道HTTP协议以明文方式发送内容，不提供任何方式的数据加密。HTTPS协议是以安全为目标的HTTP通道， HTTPS提供了身份验证与加密通讯方法，被广泛用于网上安全敏感的通讯，例如交易支付、金融应用、API接口、政务信息等。 通过阿里云全站加速的控制台，可快速开启HTTPS协议，实现客户端和全站加速之间请求的HTTPS加密，保障数据传输的安全性，防止HTTP明文传输中的被窃听、篡改、冒充和劫持风险。 目前主流浏览器已将HTTP协议标识为不安全，若坚持使用HTTP协议，除了安全会埋下隐患外，终端客户在访问网站时出现的不安全标识，也将影响访问。 第三、WebSocket加速 WebSocket协议是基于TCP的一种新的网络协议。实现了浏览器与服务器全双工（full-duplex）通信，允许服务器主动发送信息给客户端。在WebSocket中，浏览器和服务器只需要完成一次握手，两者之间创建持久性的连接，进行双向数据传输，客户端和服务器之间的数据交换变得更加简单高效。 阿里云的全站加速产品也提供了对应的Websocket加速模式，通过阿里云全站加速的Websocket, 可在视频弹幕、在线教育笔记大纲等信息推送、股票、金融产品实时报价、体育实况更新、视频会议和聊天、基于位置的应用等场景中使用，能偶更好的节省服务器资源和带宽，并且能够更实时高效地进行通讯。 第四、IP应用加速 IP应用加速旨在提供非标准HTTP协议用户，特别是四层私有协议服务场景下，如金融类、游戏类、语音交互类等客户提供网络传输加速，降低服务的延迟和提升访问的可用性。 阿里云IP应用加速可以提供：私有协议做传输控制、智能选路优化网络层、源站透传、业务透明转发无任何侵入，可以通过IP应用加速灵活的使用TCP、UDP等相关协议做业务的传输。 通过以上的了解，我们可以看到通过阿里云全站加速产品，可以有效的提升网站（APP）加速性能和用户体验。在更多的业务搬到线上的时代，全站加速为游戏、在线教育、互联网媒体、金融、商等行业中的数字化应用提供了更优的加速方案。如果您的业务中有全站加速的需求，可以通过阿里云官网、工单、服务群等方式进行了解和反馈。

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 孙琦喜欢调侃自己为“一个失败的创业者”。跟他聊过之后，我却发现他跟以往的创业者不同，并非出于追逐创业风潮，也不将重心放在迎来送往的商业公关，而是踏实地迭代技术，一步一个脚印向前走。以下为孙琦的个人专访，推荐阅读（约3分钟）。一个纯粹的技术人我有很多标签，万博智云CTO，Ceph中国社区联合创始人，基金会亚太大使等等，但我最喜欢做的角色还是布道师。身为创业者，我不得不成为多元化角色，需要考虑营销、市场、社交等各种复杂事务。而在做技术布道的时候，我只需要关注技术本身，轻松、简单、纯粹。 这也是我最早辞职创业的初心。2011年，公司分配给我一个小团队研究云计算的方向，当时选型OpenStack，从此彻底走进了IaaS的世界。转眼到了2013年，那一年几乎是所有创业者的春天，我看好自己所做技术的前景，于是毅然决然的辞职去创业，研发基于OpenStack私有云的产品。 事实证明，技术创业者最大的问题，是过于技术理想化，容易自嗨，而忽略用户真正的需求，再好的技术没有落地场景也是纸上谈兵。现在，OpenStack已经成为了私有云的规范之一，但在2013年-2016年，多少用户会真正认可这一点呢？那时与用户的交流几乎都是技术普及过程。To B行业不同于To C行业，To B在价格之外，更看重案例和背景。当IT巨头们决定要进入这个领域后，创业公司所谓的积累瞬间荡然无存，能生存下来的只有凤毛菱角。 一次跨越舒适圈的转变于是在2016年，最初的创业合伙人和我对产品方向出现了分歧，公司面临危机。最终团队被一拆为二，我经历了一段挣扎的时光。那时候对自己的初心开始产生怀疑，也曾几度想过放弃，但实在心有不甘。同时给了我很大信心和勇气的还有我的团队，他们在最艰难的时期默默支撑着我，成为我的盔甲。这帮兄弟们陪我风雨同舟一路走来，我自己轻言放弃又怎么对得起他们的信任。人心一散，再想聚就难了。 于是我们决心转型，转型的契机是当年一个金融行业私有云项目。我们搭建云平台只花了两周时间，但是仅仅迁移十几套业务系统，我们前前后后花了半年的时间才完成。这个项目是在一个不通高铁的县城实施的，从北京3小时高铁到徐州，再乘4小时大巴到县城。总共有6名同事去了40多次才把项目完成。这给了我很大的触动，为什么看似简单的迁移，却让我们付出了如此高昂的成本，同时也坚定了团队转型做云迁移这个细分领域的决心。 一些技术创业者需要具备的特质洞察——深入理解用户需求。做技术的人在听用户讲需求的时候，会不自觉地去想技术实现细节，而缺乏对用户需求源的理解，这就容易造成你满意的产品，对用户毫无用处的情况。所以在和用户交流的时候，一定要了解用户为什么会提出这个需求，只有理解了这一点才能把产品做好。 长远——关注历史。罗马不是一天建成的，一个新的技术产生必然有其历史发展过程，机械式的学习往往让人觉得更加困惑。关注历史的发展过程，更容易让人懂得最早的设计者的想法，加深对现状的理解。目前很多新的技术，并不是绝对意义的创新，更多偏向模式创新，就像容器一样。所以关注历史，能够更快领悟新技术。 广阔——深挖洞、广积粮。IT行业在近10年发展迅猛，变的是层出不穷的新技术，不变的是学习新技术的方法论。云计算从业者需要掌握的内容则更多，前几年还是OpenStack，现在已经全面进入无服务化了。所以从业者应该时刻保持危机意识，对目前工作的内容深入理解，对自己不熟悉的领域也要关注。 洒脱——学会断舍离。到达一定阶段以后，就要有勇气放弃自己所坚持的一些事物，比如市场不需要的东西。面临这种情况，能否在坚持大方向的前提下，于细微处断舍离，对人是很大的考验。很多时候，学会放弃最难。 创业过程让孙琦完成了自我突破，他似乎变了很多，又好像从未改变。他像每一位阿里云 MVP一样，坚守自己相信的，坚持自己热爱的。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

作者：宋辛童（五藏） 整理：王文杰（Flink 社区志愿者） 摘要：本文根据 Apache Flink 系列直播整理而成，由阿里巴巴高级开发工程师宋辛童分享。文章主要从基本概念、当前机制与策略、未来发展方向等三个方面帮助开发者深入理解 Flink 的资源管理机制。 基本概念当前机制与策略未来发展方向Tips：点击「下方链接」可查看更多数仓系列视频～ https://ververica.cn/developers/flink-training-course-data-warehouse/ 1. 基本概念1.1 相关组件我们今天介绍的主要是与 Flink 资源管理相关的组件，我们知道一个 Flink Cluster 是由一个 Flink Master 和多个 Task Manager 组成的，Flink Master 和 Task Manager 是进程级组件，其他的组件都是进程内的组件。 图1. Flink 资源管理相关组件 如图1所示，一个 Flink Master 中有一个 Resource Manager 和多个 Job Manager ，Flink Master 中每一个 Job Manager 单独管理一个具体的 Job ，Job Manager 中的 Scheduler 组件负责调度执行该 Job 的 DAG 中所有 Task ，发出资源请求，即整个资源调度的起点；JobManager 中的 Slot Pool 组件持有分配到该 Job 的所有资源。另外，Flink Master 中唯一的 Resource Manager 负责整个 Flink Cluster 的资源调度以及与外部调度系统对接，这里的外部调度系统指的是 Kubernetes、Mesos、Yarn 等资源管理系统。 ...

作者 | 周正喜  阿里云技术专家  爱好云原生，深度参与 OAM 社区 大家都知道，应用开放模型 Open Application Model（OAM） 将应用的工作负载（Workload）分为三种 —— 核心型、标准型和扩展型，这三者的主要区别在于一个 OAM 平台对于具体某一类工作负载进行实现的自由度不同。其中，OAM 社区中目前唯一一个核心工作负载是 Containerized Workload，它用来描述一个基于容器的工作负载，可以理解为是 Kubernetes Deployment 的简化版（去掉了 PodSecurityPolicy 等大量与业务研发无关的字段）。 不过，很多读者可能会有疑问：对于 Kubernetes 内置的工作负载 OAM 是否还能直接支持呢？ 答案当然是肯定的，而且这是 OAM 作为 Kubernetes 原生的应用定义模型的默认能力。 下面，本文就以 Deployment 为例，介绍如何使用 OAM 基于 Kubernetes 的内置工作负载来定义和管理云原生应用。 示例准备基于 GitHub FoodTrucks （旧金山美味街边小吃地图应用）项目，构建镜像  zzxwill/foodtrucks-web:0.1.1，加上依赖的 Elasticsearch 镜像，在默认情况下，它的 Deployment 描述文件  food-truck-deployment.yaml 如下所示： apiVersion: apps/v1kind: Deploymentmetadata: name: food-trucks-deployment labels: app: food-trucksspec: selector: matchLabels: app: food-trucks template: metadata: labels: app: food-trucks spec: containers: - name: food-trucks-web image: zzxwill/foodtrucks-web:0.1.1 env: - name: discovery.type value: single-node ports: - containerPort: 5000 - name: es image: docker.elastic.co/elasticsearch/elasticsearch:6.3.2 ports: - containerPort: 9200 - containerPort: 9300如果将上述 yaml 文件提交到 Kubernetes 集群，通过 port-forward 可以通过浏览器查看效果： ...

前言：更多关于数智化转型、数据中台内容可扫码加群一起探讨 阿里云数据中台官网 https://dp.alibaba.com/index （作者：qingliang_hu） 团队经过一年探索，已经实现了多终端可视化埋点方案，包含 Web / App / 小程序等终端，基本操作流程就是将原运行在终端的应用，映射到PC浏览器上，通过浏览器做配置埋点，相较于H5，App终端因技术栈及访问环境等条件不同，在界面投屏及元素识别上有一定的难度，下面分享我们实现的像素识别方案。 埋点，简单说就是对指定位置埋上指定的值，以便监控到该位置是否做了点击、曝光、跳转等操作，从而得到数据以做分析使用。 该数据通常被PD、运营等同学使用，但埋点却由编码的开发同学完成，且埋点的值还会不定时的更新，增加开发人员工作。 以此为诉求，团队着手实现可视化埋点方案，可视化埋点核心在于 如何以平台的形式不经开发人员来对页面埋点，比如由制定埋点规划、使用埋点数据的PD人员来操作。 可视化埋点 从使用终端及技术栈上可划分为两类，native和web，而weex、小程序则两端都覆盖 开发完全不参与，当然是非常理想，实际上难以操作。简单来说做埋点管理的平台通常是在web端，而PD很难通过web平台来操作native app的页面元素。相比之下web端的埋点可视化因终端及技术的一致性，我们已经实现。 退而求其次，由开发人员在代码中标明需要埋点的位置，由PD来配置、更新需埋点的值，也可以很大程度上减少开发人员工作，提升工作效率，我们就以这种思路来实际App可视化埋点。 下面主要分享下，如何在PC平台对App实现可视化埋点解析，实际的实现行为更复杂，这里精要讲下思路、流程。 方案web端的可视化埋点，用户可以通过js实现对html操作，从而直接在PC上对web页面做元素的圈选、分析。 而web不具备操作native的能力，通过埋点规范、Native截屏、解析约定等，共同实现了一套完整的方案。 首先Native开发人员做硬编码向需要埋点的元素定义id，native接入sdk，以识别此类元素，截应用图，并将图元素绘制在对应位置，保存为RGB色值的png图像，如下图。 上图中带黑色边框的蓝色正方形的区块，标明了需要埋点的元素及ID都隐藏这个区块里。 我们放大该区块 可以看到黑框内的左上角，有一些彩色像素，这些像素就是用来标识埋点元素的位置及id。 web端的工作重点就是解析这张图片的Data。 web端下载该图并得到其像素数据 const canvas = document.canvas; const ctx = canvas.getContext('2d');const img = new Image(); img.setAttribute("crossOrigin", "anonymous"); img.crossOrigin = "Anonymous" img.src = src; img.onload = function() { ctx.drawImage(img, 0, 0); let imageData = ctx.getImageData(0, 0, this.width, this.height); // imageData即 该图片的所有像素点 } ...

作者 | 王思宇（酒祝）  阿里云技术专家 参与阿里巴巴云原生文末留言互动，即有机会获得赠书福利及作者答疑！ 概念介绍原地升级一词中，“升级”不难理解，是将应用实例的版本由旧版替换为新版。那么如何结合 Kubernetes 环境来理解“原地”呢？ 我们先来看看 K8s 原生 workload 的发布方式。这里假设我们需要部署一个应用，包括 foo、bar 两个容器在 Pod 中。其中，foo 容器第一次部署时用的镜像版本是 v1，我们需要将其升级为 v2 版本镜像，该怎么做呢？ 如果这个应用使用 Deployment 部署，那么升级过程中 Deployment 会触发新版本 ReplicaSet 创建 Pod，并删除旧版本 Pod。如下图所示： 在本次升级过程中，原 Pod 对象被删除，一个新 Pod 对象被创建。新 Pod 被调度到另一个 Node 上，分配到一个新的 IP，并把 foo、bar 两个容器在这个 Node 上重新拉取镜像、启动容器。 如果这个应该使用 StatefulSet 部署，那么升级过程中 StatefulSet 会先删除旧 Pod 对象，等删除完成后用同样的名字在创建一个新的 Pod 对象。如下图所示： 值得注意的是，尽管新旧两个 Pod 名字都叫 pod-0，但其实是两个完全不同的 Pod 对象（uid也变了）。StatefulSet 等到原先的 pod-0 对象完全从 Kubernetes 集群中被删除后，才会提交创建一个新的 pod-0 对象。而这个新的 Pod 也会被重新调度、分配IP、拉镜像、启动容器。 ...

背景介绍声纹检索，顾名思义就是说话人识别，通过声音来验证或者识别说话人的声音。声纹识别的关键步骤就是声音向量化，将说话人的声音将其转化成结构化的向量。阿里云AnalyticDB向量版，提供了一套声纹验证检索的解决方案。用户只需要使用简单的几条SQL命令，三步之内就可以搭建一套高精度的声纹检索验证服务。 声纹识别技术1）声纹检索演示图1展示了AnalyticDB向量数据库的声纹检索系统的演示界面。为了方便用户体验，我们将380个人的声音信息，转化成向量存储在系统中。当前演示系统分成两部分，第一部分是检索部分，用户输入录制好的声音文件或者用户现场进行录音上传声音文件，提交到声纹库进行声音的匹配检索。第二部分是注册部分，用户可以注册上传自己的声音到当前的声纹库里面，方便后期的查询验证。在接下来的章节中，我们分别介绍各个功能。 图1. 声纹演示系统 图2上传一段S0004的测试音频“BAC009S0004W0486.wav”到声纹库里面进行检索，可以看到top1的结果S0004就会在最上面进行展示。 图2. 查询声音 图3展示了声纹注册系统，用户可以注册自己的声音到后台声纹库里面，方便检索。比方说，用户Hanchao注册自己的声音（只有7s长度），到当前的系统里面来。当前系统支持无文本注册，用户可以说任何话来进行注册。 图3. 注册声音 图4演示用户现场录制声音，上传到系统中，进行检索。比方说，“Hanchao”录制了一段5秒的语音到声纹系统中进行检索。之前注册过“Hanchao”的声音，当前系统可以看到排名第一的声音就是“Hanchao”的声音。 图4. 录制并检索声音 当前对于声纹演示，我们采用的是1:N的演示结果，可以用在会议室中的识别，通过声音可以找到相关的会议说话人。当前，对于身份验证，这种1:1的演示，我们只用限制距离小于550，就可以方便的进行身份验证。 2）应用结构总体设计阿里云声纹库检索的系统框架的总体架构如图5所示，AnalyticDB（声纹库）负责整个声纹检索应用的全部结构化信息（用户注册标识，用户姓名，以及其他的用户信息）和非结构化信息（声音产生的向量）的存储和查询。在查询的过程中，用户通过声纹抽取模型，将声音转成向量，在AnalyticDB中进行查询。系统返还回来相关的用户信息，以及l2向量距离[5]。其中声音抽取模型的训练和测试，我们在下一章进行讲解。 图5. 声纹检索库 3）系统精度当前演示声纹系统，采用的是GMM-UMB模型抽取的i-vector作为检索向量[3]。另外，我们还训练了精度更高的深度学习声纹识别模型（x-vector[4]）。并且，可以针对特定的场景，比方说电话通话场景，手机APP场景，嘈杂噪声场景等相关的场景进行声纹模型训练，详细信息可以加我们的群进行了解。 声纹识别在学术界常用的数据集（Aishall.v1 [1]数据集和TIMIT [2]数据集）上面的（1:N）的准确率（>99.5%，见表1）。 表1. Top 1 精度测试结果 三步搭建一个声纹系统第一步，初始化。 当前系统实现了声音转向量的函数，用户将前端得到的声音通过POST请求，发给阿里云服务系统，选择对应的声纹模型，就可以将声音转成对应的向量。 import requestsimport jsonimport numpy as np# sound： 声音二进制文件。# model_id：模型id。def get_vector(sound, model_id='i-vector'): url = 'http://47.111.21.183:18089/demo/vdb/v1/retrieve' d = {'resource': sound, 'model_id': model_id} r = requests.post(url, data=d) js = json.loads(r.text) return np.array(js['emb'])# 读取用户文件。file = 'xxx.wav'data = f.read()print(get_vector(data))f.close()在初始化的过程中，用户创建相关的用户声纹表。同时，给表的向量列加入向量索引，来加速查询过程。当前声纹模型输出的都是400维的向量，所以索引参数dim设置为400。 ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 今天的深度访谈来自我们的老朋友， 001号阿里云 MVP傅奎。在信息安全领域摸爬滚打十余年，驱动他创业并坚持至今的原动力，竟然来自一个温暖的愿望。以下为傅奎的个人专访，推荐阅读（约3分钟）。误打误撞入行，爱不释手学生时期，我偶然接触到了一本杂志《黑客防线》，受其影响，从此踏上安全之路。十几年来，我练过渗透，干过产品，做过集成，卖过服务，吹过咨询，也曾在互联网电商企业一线与职业黑客、羊毛党直接对抗，“扫黄（牛）打黑（产）”。对信息安全领域的兴趣，让我从未感到疲倦，也从来不曾想过放弃。 从最初的产品厂商到服务商，再到CTO，这一路的进阶其实是源自职业危机感。我会经常思考自己三五年后的发展，是否还在从事现在的工作，是否愿意做些新尝试，于是在坚持大方向的前提下不断迭代，也去接纳改变，突破自我。 创业做雾帜智能也是谨慎思考后的抉择。我从工程师到主管，到业务负责人这一路积累的大量的从业经历，也看到了很多行业内的痛点，我萌生了自己的一些想法，希望有一片天地能放开来施展拳脚。很多人认为创业的原始驱动力就是经济诉求，其实不尽然。有时候需要有人去主动肩负起行业内的责任和使命。以我个人来说，既然发现了安全行业里边很多可以改进的环节，那么如果能够通过改善现有的工作方式来提高安全从业人员的生活幸福指数，何乐而不为呢？ 以提升安全人员的幸福感为创业使命众所周知，安全人员在IT行业的位置颇为特殊，需要时刻保持警惕，不断抢占技术高地。半夜受到攻击、系统报警都是家常便饭，我们必须第一时间爬起来处理……在亲历过无数次这类场景之后，我萌生了一个改变行业现状的“小目标”。 我希望通过促进人机协同，改变从业人员的工作生活方式，在与攻击者的对抗中，让我们快人一步，最终提升大家的幸福指数。通过提高人机协同度和使用自动化编排的方式，让系统更加智能，以精准快速的反馈来取代内部低效率沟通，甚至不再需要等待，毕竟系统对安全从业人员的依赖与幸福感息息相关。 目前的阶段来说，我的精力主要聚焦在团队上，希望能打造出革命化的安全产品，让自己的理念和想法映射在被市场认可的方案上。倘若能在国内乃至世界发出一些声音，也算是有所贡献。 尝试跨界协作，成就更好的自己本着身体力行的观念和对新事物的好奇，我在业余时间也会参加一些技术公益来沉淀经验，比如曾经和几位阿里云MVP成员一起合作参与了中国可持续水产数据库项目的技术支持工作。起初大家互相不了解，在几次钉钉会议后我们的合作就默契多了。触及新项目和领域的过程也在不断提升自己的认知，你会发现互相借鉴工具、交换知识、沟通协作之后，人们学习成长的速度会变得飞快。 也是在亲历以后才发现，原来在我个人工作范围外还有如此多的领域，原来很多项目对安全都有需求，而圈外的人往往不知道该怎么做。在公益合作项目里，我们每个人都有自己的专长，可以互相分享指正，有人引导方向，有人提供知识，有人修复漏洞。彼此使用不同的工具和语言，为同一件事添砖加瓦。这种环境和场景下搭建出来的产品，所带给我们技术人自身的影响是别具温暖和力量的。 与“黑灰产”斗智斗勇，妙趣横生安全行业由于自身高危敏感的特性，一直都颇受关注。跟“黑灰产”的对抗，有段时间曾占据我工作内容的很大比重。大家在科幻片里经常看到阻击黑客的酷炫画面，就是我的日常。羊毛党们千方百计薅羊毛，我们就百转千回维护商业用户利益。不同于普通程序员的工作，每天在你来我往与攻守进退中斗智斗勇，其实也是蛮让人乐在其中的事情。 虽然说起来轻松好玩，但落在技术层面，我们从来都不敢轻敌。在电商兴起的早期，我们每天都直面攻击，面临很大的风控压力。很多用户会担心自己的账号被盗用，引发信息泄露或遭遇诈骗等问题；商家担心由于系统bug或羊毛党攻击而造成损失，无法确定新团队是否值得信任等等。 俗话说，道高一尺，魔高一丈，最初我们每天都在想方设法和团队成员出策略维护用户利益。但很多时候，也会出现安全风控策略与其他团队的运营动作产生冲突的时候。内部质疑与外部攻击的压力并存，持续受挫，曾经一度到了不得不怀疑自己甚至放弃的地步。 最终我们还是扛住压力，艰难地坚持了下来，通过各种方式组织大家共同讨论，甚至拉上了业务团队，群策群力。安全事业本身就充满对人性的挑战，偶尔有面临两难选择的时刻，在短暂挣扎后我还是会坚持自己的选择，即使在短期内不被理解甚至受到非议，但我的原则不可触及。关键时刻的抉择才能看到你对价值观的坚持。秉承着这样的信念，经过半年时间风控团队成长了起来，我们的成果也被众人见证，最终获得了认可。 工作过程总在紧张刺激和斗智斗勇中开展，通常我也会通过冥想和听戏的方式来放松自己。当然，如果能有个空档闲下来，我希望有更多的时间来陪伴家人。希望未来我的“小目标”实现之后，大家都有机会体验人工智能解放生产力的快乐吧。 在与傅奎的对话中，他时不时就会提到提升安全业者幸福指数的初心。我见过许多以技术革新为目标的开发者，却极少遇到以提升幸福感为理想的理工男。他称自己为信息安全的狂热爱好者，恰如其分。用技术改变世界，诚然筚路蓝缕。而每一位阿里云 MVP都是饮冰十年，难凉热血啊。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

6月17日，在阿里云新品发布会上，阿里云宣布专属钉钉解决方案正式上线。专属钉钉解决方案是阿里云同钉钉联手打造的新一代企业数字化办公操作系统。 通过同上千家企业在企业数字化办公上的探讨，专属钉钉解决方案为企业用户特别设计开发了专属设计、专属安全、专属开放能力。同时，专属钉钉解决方案通过阿里云产品，进一步深化钉钉在组织在线、沟通在线、协同在线、业务在线、生态在线上的能力，成为企业全新一代的安全、高效的企业数字化操作系统。 目前，专属钉钉解决方案已在金融、零售、地产、制造、教育等行业打造诸多标杆。钉钉解决方案中心总监司酒在发布会中介绍了专属钉钉在各个行业的成功案例。司酒表示，“专属钉钉同时拥有钉钉本身高效的IM、协同能力，和大企业需要的高安全性，同时还提供高度开放的自定义业务空间。将专属钉钉作为企业数字化操作系统，将大大提升企业沟通、协同和业务构建的能力。” “专属钉钉即是企业用户沟通协同的能力中心，也是企业业务的插排。专属钉钉能够帮助企业打造低成本与高效率相结合的数字化工作学习平台”，阿里云高级解决方案工程师叶珩表示，“我们将专属钉钉本身强大的IM能力和阿里云的企业产品能力深度集成，形成专属钉钉解决方案，为企业提供新一代的数字化办公操作系统；通过与IDaaS的集成，为企业解决组织在线的问题；通过与混合云存储阵列、SAG的集成，将企业数据落到本地，以提供高级别的数据安全保护；通过同Teambition的集成，解决项目和任务管理问题；通过DingPaaS以及同云枢集成，实现快速定制复杂业务的能力。” 钉钉作为新一代的企业数字化办公操作系统，身份安全服务（IDaaS）作为整个操作系统的组织中台帮助企业实现基于钉钉组织架构的统一账号、统一认证、统一授权、统一审计。阿里云IDaaS产品线总经理尚红林在《云钉一体，安全护航》的议题中，深入介绍了云钉一体下的核心产品、使用场景和客户案例等。 一切工作都可以从 Teambition 开始。无论是策划活动、研发软件、制造机器人、建设发电站或者发射卫星，团队成员以更高效的协作方式，为目标不断创造成果。本场发布会最后，Teambition团队业务运营专家文苑全方位介绍了Teambiton帮助企业完成一站式任务及项目管理，实现跨部门、跨地域的无缝协作，并沉淀管理流程和知识，积累宝贵的实践经验。 数字经济时代，专属钉钉全面赋能企业办公数字化，打造“简单、高效、协同、安全”的新一代企业办公数字化办公操作系统。 最后，专属钉钉解决方案公测期间，官网下单可享受7.5折专属优惠。了解更多详情，请进入官网购买直通车：专属钉钉解决方案全新上线

作者 | 伍翀（云邪），阿里巴巴技术专家 整理 | 陈婧敏（清樾），阿里巴巴技术专家 摘要：本文整理自 Flink Forward 2020 全球在线会议中文精华版，由 Apache Flink PMC 伍翀（云邪）分享，社区志愿者陈婧敏（清樾）整理。旨在帮助大家更好地理解 Flink SQL 引擎的工作原理。文章主要分为以下四部分： Flink SQL ArchitectureHow Flink SQL Works?Flink SQL OptimizationsSummary and FuturesTips：点击下方链接可查看作者分享的原版视频～ https://ververica.cn/developers/flink-forward-virtual-conference/ Apache Flink 社区在最近的两个版本（1.9 & 1.10 ）中为面向未来的统一流批处理在架构层面做了很多优化，其中一个重大改造是引入了 Blink Planner，开始支持 SQL & Table API 使用不同的 SQL Planner 进行编译（Planner 的插件化）。 本文首先会介绍推动这些优化背后的思考，展示统一的架构如何更好地处理流式和批式查询，其次将深入剖析 Flink SQL 的编译及优化过程，包括： Flink SQL 利用 Apache Calcite 将 SQL 翻译为关系代数表达式，使用表达式折叠（Expression Reduce），下推优化（Predicate / Projection Pushdown ）等优化技术生成物理执行计划（Physical Plan），利用 Codegen 技术生成高效执行代码。Flink SQL 使用高效的二进制数据存储结构 BinaryRow 加速计算性能；使用 Mini-batch 攒批提高吞吐，降低两层聚合时由 Retraction 引起的数据抖动；聚合场景下数据倾斜处理和 Top-N 排序的优化原理。## Flink SQL 架构 & Blink Planner（1.9+ ） ...

最近，国家政策开始鼓励“地摊经济”，一时间各家企业平台纷纷推出地摊扶持政策，地摊概念股顺势大涨，地摊生态及配套商品也开始走俏，甚至在网络上也涌现出各种“新摊主速成攻略”，万亿的烟火经济俨然已经走上风口。 实际上，早就有人已经在网上“摆地摊”了，那就是直播带货！受到疫情的影响，线下实体纷纷停摆，直播带货受到了前所未有的追捧，企业们纷纷选择通过直播的形式，来提升品牌形象、保持与用户的互动并完成商品的销售。 那么问题就来了，在搭建直播平台或者应用的过程中，都需要关注哪些技术呢？CDN又对直播起到什么作用呢？ 一个直播系统都包括什么？通常整个直播的系统可能包括：推流端经过一次边缘节点的加速，将视频直播流推到直播中心，在直播中心完成一系列转码、截图、录制、水印等处理，然后视频流再经过CDN分发，分发到不同的播放端，播放端有不同的SDK进行秒开、弱网等优化动作。 直播系统中的推流与播放对于视频直播来讲，最重要的两个环节，一个是推流，一个是播放。推流一般采用RTMP协议，常用的推流端包括OBS、手机APP、FFmpeg等。播放除了采用RTMP协议，还可以采用HTTP FLV和HLS协议，RTMP和HTTP FLV是流式传输，HLS是文件加速传输，常见的播放端包括：Flash / VLC / HTML5 / 手机App等等。对于阿里云直播系统来讲，大部分直播分发都是通过流式传输完成的，只有一少部分量是使用文件加速分发完成的。 流式分发与CDN直播系统其实在直播场景中，不管是推流还是播放，流式分发都是长连接的，一场直播可能5个小时，推流在这5小时内不会中断。对于播放器来讲，服务器端获取到的是一帧一帧的音视频数据，不管是什么传输协议，都是采用FLV tag来封装。每一帧音频或者视频，都会有一个时间戳的属性。 视频直播流会传输音频帧和视频帧，对于音频帧来讲，它每一帧都可以独立解码，播放器从服务器获取到任何一帧音频帧之后，都可以独立渲染，听到声音。而视频分为视频关键帧和非关键帧，关键帧可以独立解码渲染，播放器拿到后可以直接看到画面，一般10K以上甚至几十K；其他非关键帧解码依赖于前面的一些视频帧，播放器会根据前面的帧和这一帧来解码产生画面，非关键帧一般大小是几K甚至不到1K。对于播放器来说，服务器一般会从视频关键帧开始发送，这样才不会产生花屏。 对于节点上直播服务器存储的内容，如果是文件加速，节点上存储的内容很明确，就是文件数据, URL不变的话文件数据内容也不变。但是对于直播来讲，传输的就是帧数据，缓存的也是不断变化的帧序列数据。 下面的图里可以看到，当前的服务器缓存了V1-V3五帧数据，当V4这个关键帧出现了，服务器把之前的丢掉，开始缓存V4开始的音视频数据，以这个策略保证过来的播放端都是当前最新的数据。一般直播服务器都是用这个策略来进行服务器缓存的。 直播平台面临的挑战？1、 前面也说了，直播系统包含推流、转码、分发、播放等各个环境，经历了冗长复杂的网络环境，尤其是当业务场景逐渐丰富起来之后，功能需求也越来越多 2、 一些关键指标的提升，比如：卡顿率、打开速度、流畅度、回源率等，任何指标的下降都可能会导致整个应用的用户体验下降，影响直播效果 3、 直播平台经常会面临业务突发，数十万甚至数百万用户的同时在线，对服务器和带宽考验十分巨大 直播平台为什么要使用CDN？1、减少卡顿率，提升用户体验直播，尤其是电商直播，对网络抖动十分敏感，稍有问题就会出现卡顿、花屏等问题，严重影响用户体验，甚至直接掉线影响销售。CDN借助负载均衡系统能够将内容推送到接近用户的边缘节点，使得用户就近取得资源，可以大大提升访问效率。 2、业务峰值来临的时候，为流量高峰护航在确保直播流畅度上，全球覆盖的CDN节点和精准调度系统缺一不可。CDN节点是采用分布式架构，节点资源与带宽储备就代表了能够覆盖的用户的量级和广度。当突发峰值特别高的时候，CDN系统会确保用更精准的调度策略，比如DNS、IP调度，来降低对直播的影响。打比方有一个装了很多冰块和水的杯子，如果我们要把杯子里面的狭小空间全部用上，我们先要把冰块放进去，再倒液态水。在智能调度的场景里，把“固体”和“液体”结合起来考虑，才能做到所有的节点、水位的精准控制，实现更精准的调度。 所以，选择节点和带宽资源覆盖广泛，综合实力强，质量有保证，具备大型项目最佳实践的CDN服务提供商对直播带货平台来说至关重要。想要在云上开启“地摊经济”，阿里云CDN，了解一下~ 阿里云全速重构年中大促中，CDN/全站加速、视频直播、视频点播等多款产品都推出限时折扣，点击登陆活动页面了解优惠详情 点击回顾CDN百科第一讲，最近你的APP崩了吗？ https://developer.aliyun.com/article/757268 点击回顾CDN百科第二讲，假如没用CDN，网络世界会变成什么样？ https://developer.aliyun.com/article/759623 CDN百科第三讲，如果用了云服务器，还需要做CDN加速吗？ https://developer.aliyun.com/article/763524 【CDN百科】专栏中，我们会不断科普CDN知识，解读CDN实践，分享CDN案例，如果你也关注CDN、使用CDN，请留言回复你关心的话题，如果被选中就有机会获得阿里云ET公仔一个，包邮哦！

图数据库GDB精彩详情在6月9日的“全速重构”2020阿里云·线上峰会中，阿里云智能数据库事业部的资深产品专家斗佛开启了全球首发4款云数据库新产品——云数据库专属集群、图数据库GDB、云数据库Cassandra版、云数据库ClickHouse。今天小编为大家深度揭秘图数据库GDB助力盒马构建商品图谱知识引擎的案例。 盒马鲜生是阿里巴巴对线下超市完全重构的新零售业态。盒马既是超市，也是餐饮店，还是菜市场。消费者可到店购买，也可以在盒马App下单。而盒马最大的特点之一就是快速配送：门店附近3公里范围内，30分钟送货上门。 盒马鲜生基于门店、人群、商品、食材、菜谱等数据，以及相互间的关联关系数据，借助阿里云图数据库GDB，构建了商品图谱知识引擎。用于优化菜谱搭配、生鲜搭配、以及标品搭配等，沉淀盒马图谱数据，完善盒马推荐和导购能力，提升转化率。 经过近几年高速增长，目前规模已经成型。摆在当下更重要的事情是，需加强商品数字化建设，完善商品管理体系，使各个链路向垂直化、精细化运营，进而升级为数据和技术驱动的新零售平台。而如何借助门店、消费人群、商品、食材、菜谱间，数以亿计的海量关联关系数据，构建商品图谱，并进一步为终端客户提供智能推荐服务，使客户获得方便快捷的购物体验是摆在面前的一大挑战。 图数据库在处理海量关联关系数据方面具有查询效率高，模型直观，编程简便的独有优势，在知识图谱、推荐等领域有广泛应用，非常契合盒马鲜生的商品图谱应用场景。 阿里云图数据库GDB是一款支持ACID事务，兼容Gremlin和Cyper两大主流查询语言，提供99.95%企业级高可用保障的全托管在线图数据库。并支持自动索引、Schema-Free、内置常用图算法，完全满足盒马鲜生的需求。 图数据库GDB为盒马商品图谱知识引擎在数以亿计的海量数据中，提供了毫秒级高效图查询和存储能力，ACID事务使实时更新和查询数据更为便捷。在编程模型上，图模型的支持比起传统数据库更加直观，自动索引和Schema-Free的特性使得知识引擎在日常设计和运维方面更加轻松。 最终，图数据库GDB助力盒马知识引擎实现了构建盒马知识图谱，提供菜谱推荐、人群推荐、门店推荐功能。提升生鲜SKU覆盖率和准确度，并提高了客单价。沉淀了盒马生鲜领域的商品标准数据，为探索新的业务场景和数据服务打下基础。 历经数年，盒马鲜生已逐步成长为中国领先的社区化一站式新零售体验中心，而基于商品图谱知识引擎所构建的智能菜谱推荐、门店推荐等功能使用户在购物时，变得更为简单快捷，同时也提升了商品的下单量。面向未来，盒马鲜生期望与阿里云图数据库GDB，共同构建深度关联关系的分析处理能力，从而为客户提供更为智能、精准的推荐和导购服务。 点击文字 解锁图数据库GDB的更多精彩详情 还有新用户首购9.9元包3月的限时优惠哦！

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 跟黄军雷聊的时间格外长，我总是忍不住一再追问故事的细节。他的逻辑永远像有个在线思维脑图一样清晰，简明扼要、深入浅出。职业生涯的进阶听起来格外顺遂，但我们都知道，机会从不眷顾毫无准备的人。以下为黄军雷的个人专访，推荐阅读（约4分钟）。求知若愚，热爱成就非凡在毕业十几年后我也从未停止学习，包括后来读MBA，考各种认证证书。内驱力其实很简单，爽。对我来说，学习是很开心的事情。上学的时候，每搞懂一个知识点的通透感都会让我很愉悦，工作后解决问题时也是如此。当你能力越强大，解决的问题越复杂，所获得的成就感也非比寻常。即使当时痛苦，回想起来留下的都是美好的记忆。经历过几次成功的循环后，就知道眼前的难题又是一次成长历练的机会，就不会只将它视作困难了。因为你知道，翻过这座山，会有更好的风景。 在这方面，我很大程度上受到乔布斯的指引，他是一个颇具专业精神的人，我每年都会重温一两遍他的演讲视频。我很认同他“Stay hungry，Stay foolish”的观念，人在有一定知识和能力之后会发现，一直保持空杯状态很难。我记得当年MacBook Air出来的时候非常震撼，一个笔记本可以做到艺术品的程度。后来对产品的投入越来越多，我才发现乔布斯对细节的执着让人敬仰，世界就怕“认真”二字，人生也是如此。仅限于指派任务或者完成任务很容易走样，理解后再思考，更容易认同它的意义。 之前公司的CEO有一句话对我影响也很大：热爱成就非凡。热爱你的事业，投入最大的激情和努力，跟完成任务的心态相比显然天差地别。当时我们要做一个类似Oracle的国产数据库。因为Oracle占据中国市场太久，对国家信息安全等存在各种挑战，并且CEO提出了更高的要求，要求不改系统的前提下研发出新产品，要解决工程环境等很多问题。做一个国产数据库，这是对国家社会有价值的东西，我们愿意为此而努力。那段时间每一次进步，团队都由衷骄傲，会兴奋地告诉身边的朋友，我们又有什么进展，因为是很有意义的事情。在我离开团队的时候，它已经是亿级销售额的产品了。 厉兵秣马，前置的人生就像开了挂人需要一本手艺安身立命，技术和管理是我的两个轮子。我一直定位自己为技术人，高中时候接触编程，大学一直泡在机房，到现在也在持续研究技术。对管理的探索是从大学开始的，也是那时候少数对管理课的价值真正认可的人之一。当时我经常和管理学院的同学混在一起，也看了很多经济学、会计学甚至心理学的书，跟着他们参加了原本没我份儿的模拟经营比赛。 所以我对管理的兴趣和能力其实很早就暴露出来了，后来做项目管理、带产品团队也算是一路在演进。现在积累了一定能力和行业感知，于是去年以合伙人的身份加入云顶云，真正做一些事情了。现在看起来，这些都是大学奠定的基础，那时候就经常跟同学聊创业，就想着将来一定要有一份自己独立的事业。“Keep looking，don’t settle.”其实也是我人生价值理念的体现，持续探索，不要给自己设限。 2011年公司转型做云计算的时候，我负责从0开始组建IT团队。当时面临很多挑战：快速组建一个稳定的团队，缓解他们从传统模式转换的观念冲突；满足客户有更高的交付需求；降本增效，尝试混合部署等；暴露在公网后的安全问题，黑客频繁攻击……当时有一次团建，我让大家放轻松随便玩，所有出现的业务问题我来处理，于是就有了我连着3G网捧着笔记本行走在鲁山山巅的一幕，团队也印象深刻。 有一件事情很让我感动，有一回系统半夜发来报警信息，5分钟左右还在响，我就跟值班同学一起处理。后来不断有团队里的其他同学上线，大家都自觉来帮忙处理问题，每个人排查自己负责的部分，问题很快就解决了，即使这并不是他们的义务。当时非常欣慰，也很有成就感。 一个领导如果没体会过这种“若有战、召必回”的带兵打仗的感觉，很难理解团队和部门的概念差异。那时候距离团队组建也就1年左右。我自己本身是开发，转过来后其实很多技术都是短板。但我来扛压力救火，让大家不再焦虑，专注于自己的技术；同时我也快速学习他们的东西，包括技术知识、业务知识，甚至充当心灵导师指导职业方向。毕竟担当不足，何来信服。 领略更广阔的天地首先，无论什么行业，都要有自己擅长的领域，我推荐年轻人走T字型能力路线。当你的能力到达足够深度，才能做到触类旁通。很多人在深度不够的时候想通过“面”的方式来解决，其实是没有竞争力的，必须成为至少一个领域的专家。 其次要有宽阔的视野，站在外部角度才能真正看懂自己所面临的问题，自己工作的价值，对这个社会的意义。我能跟团队内的每个人沟通，是因为自己本身经历过很多部门的轮岗，包括算法研究、产品研发、工程化开发、运维，甚至人力资源。以外部视角、内部视角、客户视角看待各个团队，才发现差异如此巨大。 另外有机会也要多出去走走，人生需要一些视野的宽度。比如在国外泡一段时间来理解当地文化；安排一些时间给自己工作毫不相干的事情，比如我还会参加营销团体的线下活动，接触微商，了解社会其他群体以什么样的模式去工作。不局限于自己的想法，去看看真实的世界。 小时候为了不让家长操心，于是自觉学习，摸索怎样与人相处。到了大学，推开每个自习室基本都会找到能跟他聊两句的人。求知的主动和过人的情商似乎早早就为他的成功做好了准备。他是阿里云 MVP黄军雷，对于事业，对于人生，一往无前，永不疲倦。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！dubbo 是一个基于 Java 开发的高性能的轻量级 RPC 框架，dubbo 提供了丰富的服务治理功能和优秀的扩展能力。而 dubbo-go 在 java 与 golang 之间提供统一的服务化能力与标准，是涂鸦智能目前最需要解决的主要问题。本文分为实践和快速接入两部分，分享在涂鸦智能的 dubbo-go 实战经验，意在帮助用户快速接入 dubbo-go RPC 框架，希望能让大家少走些弯路。另外，文中的测试代码基于 dubbo-go版本 v1.4.0。 dubbo-go 网关实践 dubbo-go 在涂鸦智能的使用情况如上图，接下来会为大家详细介绍落地细节，希望这些在生产环境中总结的经验能够帮助到大家。 1. 背景 在涂鸦智能，dubbo-go 已经作为了 golang 服务与原有 dubbo 集群打通的首选 RPC 框架。其中比较有代表性的 open-gateway 网关系统（下文统一称 gateway，开源版本见 https://github.com/dubbogo/dubbo-go-proxy）。该 gateway 动态加载内部 dubbo 接口信息，以HTTP API 的形式对外暴露。该网关意在解决上一代网关的以下痛点。 通过页面配置 dubbo 接口开放规则，步骤繁琐，权限难以把控；接口非 RESTful 风格，对外部开发者不友好；依赖繁重，升级风险大；并发性能问题。2. 架构设计 针对如上痛点，随即着手准备设计新的 gateway 架构。首先就是语言选型，golang 的协程调用模型使得 golang 非常适合构建 IO 密集型的应用，且应用部署上也较 java 简单。 经过调研后我们敲定使用 golang 作为 proxy 的编码语言，并使用 dubbo-go 用于连接 dubbo provider 集群。provider 端的业务应用通过使用 java 的插件，以注解形式配置 API 配置信息，该插件会将配置信息和 dubbo 接口元数据更新到元数据注册中心（下图中的 redis ）。这样一来，配置从管理后台页面转移到了程序代码中。开发人员在编码时，非常方便地看到 dubbo 接口对外的 API 描述，无需从另外一个管理后台配置 API 的使用方式。 ...

程序员小王正坐在电脑前写代码，屏幕跳出一条提醒：“亲，你于2019年6月5日提交的创新提案，已经通过专利审批。”这是来自阿里巴巴知识产权管理系统的通知，当公司权利库内的某项权利（比如专利）的状态发生变化时，就会自动触发系统提醒。基于“宜搭”低代码平台快速搭建应用的优势，该系统仅花1周时间就顺利上线，相比传统的开发模式，效率提升100%。 在这套系统上线前，公司对知识产权的管理很大程度上需要借助人工完成。尤其是随着阿里经济体的快速壮大，lazada，银泰商业、饿了么、考拉海购等纷纷加入，带来了大量的知识产权管理诉求，传统的人工处理方式已经无法满足业务发展的需要。 场景痛点知识产权管理涉及多个部门（比如集团/部门法务、业务、市场、设计、研发、财务等），彼此之间的业务息息相关。可是，数据分散在各个部门，无法彼此连接和共享，这就增加了部门之间的协作难度。一旦公司的权利被侵犯，集团法务需要凭经验找对应的部门核对信息，而被问询的部门也要进行内部核对。这样一来，整个处理过程占用了大量的人力和时间，很容易错过舆情处理的最佳时间。 为了解决以上问题，阿里巴巴企业智能事业部的法务研发团队决定打造一套全新的知识产权管理系统，通过在线化、智能化的方式，实现对集团知识产权的全生命周期管理。 首先，法务研发团队评估了外购和内部开发两种方案：如果选择外购，成本高而且市面上并没有贴合实际业务的专项管理系统；如果走内部开发，由于公司研发和测试资源紧张，短时间内申请不到相应资源。 这时，法务开发团队想到了“宜搭”，一款由阿里巴巴企业智能事业部自研的低代码应用开发平台，借助宜搭平台强大的配置能力，可以自动生成数据模型和关系图，辅以少量的代码开发工作就可以快速搭建功能完善、带有流程体系的线上系统，并且对未来系统数据的变化（数据模型的扩展）也有很好的支持。 短短1周时间，基于宜搭开发的全新知识产权管理系统上线了。它快速、低成本地实现了企业对商标权、版权、著作权、专利权等知识产权的全流程管理，有效支撑了业务的数字化升级。 业务在线新系统借助“宜搭”高度配置化的表单能力，彻底告别了以往用EXCEL登记表格的“土”办法，实现了知识产权数据线上化、标准化管理。系统不仅详细记录了知识产权的产生、申请、核准、使用、变更、转让、纠纷、消亡、维护等方面，并且还能实时查看每项权利在生命周期中的变化，法律文书对该项权利的规范要求，以及后续对侵权和维权操作的处理等。 数据连接新系统建立了个人之间、系统之间、数据之间的连接。同时，它打通了集团在法务层面的权利系统大盘，把从原来的单点法务工作、分散的管理模式、个人的智慧与知识变成整个团队的能力。当公司权利被侵犯时，集团法务无需逐一问询相关部门，通过系统就能快速响应并定位问题，不给侵权者有可乘之机。 智能管理宜搭强大的接口能力为系统预留了接入数据化分析、AI算法、神经网络等智能化提效工具的入口。例如，系统通过相似度分析算法对阿里巴巴内部提交的创新提案和现有文章、专利做分析，帮助法务专利审核人员快速理解提案所描述的领域以及筛选相似的参考资料，极大地降低了沟通成本。另外，在审批环节，系统对所需要审批的事项划分为高、中、低三类，实现高风险案件优先处理，低风险案件智能辅助审批，大大提升了审批效率。 新系统借助“宜搭”平台，打破了原先的数据孤岛，把业务人员从大量简单、繁琐的法务工作中释放了出来，实现了集团知识产权的全生命周期管理。据统计，系统上线7天即实现上万数据入库，累计承载数十万权利数据的管理和运营。 目前在阿里内部，宜搭平台上运行着3000多个月活应用。为了让更多的企业像阿里巴巴一样，利用低代码平台在企业内部快速搭建出符合实际业务需求的个性化应用，宜搭上线了精品应用市场，涵盖了包括法务在内的企业运营管理5大领域（行政、HR、费控、法务、IT）。同时，宜搭还为那些对数据安全要求高、希望数据存储在自己专有云内的用户提供了专有云版本，现在登陆宜搭官网（aliwork.com）即可体验。

作者：董亭亭、徐明 摘要：作为短视频分享跟直播的平台，快手有诸多业务场景应用了 Flink，包括短视频、直播的质量监控、用户增长分析、实时数据处理、直播 CDN 调度等。此次主要介绍在快手使用 Flink 在实时多维分析场景的应用与优化。主要内容包括： Flink 在快手应用场景及规模快手实时多维分析平台SlimBase-更省 IO、嵌入式共享 state 存储Tips：点击下方链接可查看作者原版PPT及分享视频～ https://ververica.cn/developers/flink-forward-asia-2019/ Flink 在快手应用场景及规模首先看 Flink 在快手的应用场景和规模。 1. 快手应用场景 快手计算链路是从 DB/Binlog 以及 WebService Log 实时入到 Kafka 中，然后接入 Flink 做实时计算，其中包括实时数仓、实时分析以及实时训练，最后的结果存到 Druid、Kudu、HBase 或者 ClickHouse 里面；同时 Kafka 数据实时 Dump 一份到 Hadoop 集群，然后通过 Hive、MapReduce 或者 Spark 来做离线计算；最终实时计算和离线计算的结果数据会用内部自研 BI 工具 KwaiBI 来展现出来。 Flink 在快手典型的应用场景主要分为三大类： 80% 统计监控：实时统计，包括各项数据的指标，监控项报警，用于辅助业务进行实时分析和监控；15% 数据处理：对数据的清洗、拆分、Join 等逻辑处理，例如大 Topic 的数据拆分、清洗；5% 数据处理：实时业务处理，针对特定业务逻辑的实时处理，例如实时调度。 Flink 在快手应用的典型场景案例包括： 快手是分享短视频跟直播的平台，快手短视频、直播的质量监控是通过 Flink 进行实时统计，比如直播观众端、主播端的播放量、卡顿率、开播失败率等跟直播质量相关的多种监控指标；用户增长分析，实时统计各投放渠道拉新情况，根据效果实时调整各渠道的投放量；实时数据处理，广告展现流、点击流实时 Join，客户端日志的拆分等；直播 CDN 调度，实时监控各 CDN 厂商质量，通过 Flink 实时训练调整各个 CDN 厂商流量配比。2. Flink 集群规模 ...

QuestMobile《2020中国移动直播行业“战疫”专题报告》数据显示， 疫情期间，看直播成为休闲娱乐、获取资讯、上课学习的主要方式，一些高度依赖线下场景的行业也纷纷通过直播进行自救，线上转型直播卖货，政府部门也通过直播形式进行招商、推广农产品等。电商平台在疫情期间加大对直播的支持力度，为滞销农产品直播、云卖车、云卖房、实体店直播卖货提供平台和支持。 直播破圈加速进行，除了各类网络红人外，国家博物馆、知名酒吧、景点等线下主体为网民提供线上逛博物馆、云蹦迪、云旅游服务，吸引了大批年轻用户参与。直播不再是线上娱乐内容的生产工具，而是与商业业务场景结合越来越紧密，逐渐演变为基础的业务工具。 直播的及时性和互动性让他成为信息触达、互动沟通的新媒介，但直播的实时互动效果够好了吗？传统的直播技术延迟非常大，从观众评论到看到主播给出反馈一般要在5-10秒以上。 我们来看下几个典型的尴尬场景： 在线教育，学生提问，老师都讲到下一个知识点了，再返回来回答。电商直播，询问宝贝信息，主播“视而不理”。打赏后迟迟听不到主播的口播感谢。在别人的呐喊声知道球进了，你看的还是直播吗？高延时影响了直播互动体验，阻碍了直播在一些场景的落地，特别在电商直播，直播间的评论提问是观众和主播互动的一个重要手段，主播的实时互动反馈对直播间的活跃度和交易达成至关重要。 使用常规的直播方案（rtmp 推流，FLV/RTMP/HLS 播放），延迟大概在5-10秒左右，这些延迟主要来自以下几个方面： 推流侧buffer， 这部分来自于画面从传感器模数转换到音视频编码以及输出画面到网络的buffer。最主要的还是来自于编码的延迟，这与推流软件的编码参数设置有关，如是否有B帧，帧参考关系设置，压缩性能等。以OBS为例，当输出设置如下图时，延迟达到最低（1s以内）： 不过，上图的配置，在MAC和windows 平台上的效果也不一样，mac 平台的延迟在几百ms，而windows 可以做到50ms （实际案例数据)。推流网络方面，主播的推流网络一般都比较稳定，有的会拉专线，质量比较可靠。 CDN链路延迟， 这分为两部分，一部分是网络传输延迟。CDN内部有四段网络传输，假设每段网络传输带来的延迟是20ms，那这四段延迟便是100ms；此外，使用RTMP帧为传输单位，意味着每个节点都要收满一帧之后才能启动向下游转发的流程；CDN为了提升并发性能，会有一定的优化发包策略，会增加部分延迟。在网络抖动的场景下，延迟就更加无法控制了，可靠传输协议下，一旦有网络抖动，后续的发送流程都将阻塞，需要等待前序包的重传。播放端buffer，这个是延迟的主要来源。公网环境千差万别，推流、CDN传输、播放接收这几个环节任何一个环节发生网络抖动，都会影响到播放端。为了对抗前边链路的抖动，播放器的常规策略是保留6s 左右的媒体buffer。阿里云低延时直播（Real-time Streaming） 传统的直播技术，已经不能满足对互动要求更高的直播要求，为此，2019年阿里云与淘宝直播共同推出超低延时直播服务RTS（Real-time Streaming），该方案基于WebRTC实现，采用UDP传输协议打造，实现可以承载大规模并发，端到端延时1秒内的低延时直播体验。由于RTS服务部署于阿里云CDN节点，复用CDN的节点和网络资源，在接入成本、节点覆盖、承载能力上实现了平衡。经过一年多的不断磨炼，整体体验和服务也更为完善和成熟。 阿里云低延时直播的技术架构： 从传输的细节来看，如下图所示： 上图与现在直播系统的架构图并无大的区别，改变的地方在于客户端到CDN节点进行播放的链路，由RTMP协议切换为RTP协议，TCP协议换成UDP协议。RTS服务进行了服务与节点双重升级，同时针对全链路直播指标进行监控和针对性优化，以及通过智能调度系统以及网络拥塞、抗弱网优化、缓冲策略等进行一系列底层核心技术优化，实现RTP over UDP更好地对抗公网的丢包，使得播放器上收到的流质量相对RTMP over TCP更加稳定，这样一来，播放器就可以降低buffer，不用像以前那样设置6s 的buffer来对抗抖动，现在只需要设置1秒左右就OK了，整体延时可以控制在1-1.5S左右。 如何接入RTS服务： RTS目前提供两种接入服务： 1、基于WebRTC开放协议升级网络模块 对于自研播放器或者使用开源播放器的用户，阿里云提供与标准WebRTC协议对接方案，在现有的直播业务新增一个RTS播流域名，一个推流两种方式拉流。推流侧不用改造，仅升级播放器网络模块，拉取超低延时流播放，这样让底层网络对接更透明开放，客户端自主可控。 上图是普通播放器的架构。播放器使用 FFmpeg 打开网络连接，读取音视频帧后会放入播放器缓冲，之后会依次对它进行解码、音视频同步及渲染。 接入低延迟直播系统后，整体架构如图下面部分：FFmpeg 增加低延迟直播插件支持私有协议；将播放器的缓冲设置为1秒，FFmpeg 输出的音视频帧直接送入解码器进行解码，然后同步，渲染。 另外，RTS网络SDK为播放器接入阿里云低成本多协议低延时网络传输基础设施提接口。该SDK具有非常友好的API，非常稳定的设计，在音视频同步，秒开，流畅度等指标也做了很多优化。API设计上提供了ffmpeg demux插件，可以像调用其他ffmpeg demux插件一样被集成进应用程序，另外也提供非ffmpeg接口。 2. 集成阿里云RTS播放器 使用第二种方法，可以更加快速的实现RTS服务，即在现有的直播业务新增一个RTS播流域名，然后集成阿里云播放SDK，用户端通过不同URL参数播放器自动识别，即可实现低延时直播服务。阿里云播放器是一个通用的播放器sdk，除了支持点播和直播的播放功能外，深度融合视频云业务，如支持视频的加密播放、安全下载、清晰度切换、短视频等业务场景，为用户提供简单、快速、安全、稳定的视频播放服务。 结束语 经验证，阿里云RTS直播核心指标表现优异：相同卡顿率下，RTS直播延时降低75%，并且在相同网络延时和丢包率指标下，RTS直播播放成功率、卡顿率、秒开率等指标表现均有所提升，大幅优化直播体验。RTS已经在淘宝直播中大规模应用，降低了淘宝直播的延迟，提升了用户的互动体验，经过线上验证发现，低延迟直播对电商直播的成交有明显的促进作用，其中 UV 转化率提升4%，GMV 提升5%。目前在一些教育行业、电商、游戏直播等领域，已经有众多知名客户接入RTS服务并上线。

在6月9日的“全速重构”2020阿里云·线上峰会（点击可查看数据库专场亮点）中，阿里云智能数据库事业部的资深产品专家斗佛开启了全球首发4款云数据库新产品——云数据库专属集群、图数据库GDB、云数据库Cassandra版、云数据库ClickHouse。今天小编就为大家深度揭秘云数据库专属集群是如何帮助客户上云的。 客户小盒科技是中国知名的AI教育公司，致力于用AI技术构建基于校内教学和家庭辅导的智能教育服务生态。截止目前，小盒科技的产品已经走进了全国 31个省市自治区近 400座城市的 100000所学校，有超过 5000万小学师生家长在使用小盒科技提供的工具产品、课程和教学辅导服务。 随着在线教育的发展壮大，核心业务数据库压力越来越大，需要性能优化和支撑。在线教育业务高低峰明显且频繁，线下数据库无法快速动态扩缩容，对业务有侵入性。同时，维护工作量大，人力成本高。自建数据库硬件规模大，资源利用率低，成本越来越高。 基于以上痛点，小盒科技最终采用云数据库专属集群的方案承载核心业务，一个半月就快速的实现了数据库搬迁上云。 在专属集群主机之上能按需创建出不同RDS数据库实例规格，通过专属集群的超配能力合理配置资源，降低成本。按业务场景需求快速构建出读写分离、代理短连接优化等不同数据库架构，满足业务复杂场景的需求；同时开放数据库和OS权限，客户可自主运维数据库。客户表示上云前需要维护DNS Server来实现扩容不修改配置，上云后RDS一键读写分离让使用更简单高效。 另一方面，专属集群成本上比较有优势，一是提供的机器是整机虚拟化，物理上与其他租户隔离，CPU是物理核上虚拟出来的，因此能自己做资源超分配，对CPU要求不高的业务可以少分配一些算力，对CPU要求高的业务可以多分配一些算力，整体来说在数据库上CPU不是瓶颈。磁盘上是本地NVMeSSD，可以保障大并发下数据稳定落盘。 此外，平时通过DAS基础版提供的免费MySQL监控大盘配合具体实例的CloudDBA性能洞察功能快速的定位线上故障，通过对数据库实例的巡检评分排名针对性的查看实例隐患及时处理慢SQL等问题，减少了故障定位时间，而且常规问题DBA也不需要手动捕获异常SQL给研发了，直接发链接，让研发上阿里云控制台查看实例的监控更快捷。 通过阿里云服务承载核心业务，满足爆炸式增长的线上教育需求，树立了快捷高效、极致体验的新标杆。国际权威市场研究机构Gartner指出，云数据库将是未来。到2021年，云数据库在整个数据库市场中的占比将首次达到50%；而到2023年，75%的数据库要跑在云平台之上。 遗憾错过峰会直播？ 扫一扫看精彩回放吧 点这里直达数据库各专场地址 ???? 定制太阳伞免费赠送活动倒计时1天！ 公众号后台回复“峰会” 即可免费领取 （颜色有细微差别 请以实物为准） 奖品领取数量已过半 还没行动的同学抓紧啦！ 点击文字 查看详细活动规则

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 不同于其他技术人的进阶经历，熊昌伟毕业后从未跳槽，在用友网络潜心修炼14年至今。从测试、开发管理到运维，再到技术运营总监，他的转型与成就来自无数次刻意练习和困境中的逆行身影。每一段打怪升级的鲜明烙印，皆因他事事有回应，件件有着落。以下为熊昌伟的个人专访，推荐阅读（约4分钟）。乐于挑战，与良师益友同行毕业后只身来到北京，扎根在上地，有机会经历了中国互联网高速发展的十几年，在用友从测试工程师开始，贡献了自己的青春，有过兴奋、有过委屈，曾经水深火热的“苦难”，如今再回首，都是知遇之恩的感怀。 2006年我通过校招加入用友网络，第一份工作，第一位主管，对我影响深远。他为人温和包容，不苛求初出茅庐的职场人立刻为公司创造价值，而是关注怎样可以让新人迅速成长、稳扎基础。这让我建立了自己的领导风格，利他视角、多赢思考，给团队成员相应的空间和机会，加速新人的成长，强化团队的凝聚力。 两年后我被推荐到公司创新业务里，起初我想要待在舒适圈里，不愿意更换新赛道。然而新主管初步与我接触后，并不认可我！一下子激起了我的好胜心。接到的第一个任务就给我当头一棒，领两台服务器安装运行Linux系统。而我之前对Linux毫不了解，两眼一黑不知道从哪里开始？我告诉自己：必须完成！厚着脸皮四处请教、搜索信息。一周后完成汇报时，超出了新主管的预期，得到了他的信任。我也意识到，他原本可能只是想打击我，让我知难而退。 之后我通过每一次超预期完成任务来证明自己的价值，并建立起领导和公司的信任。在“鞭笞”高压下，培养出自己的强执行力。有了清晰的目标，带领团队全力以赴以达到110%甚至120%的效果。 2010年随着国内云计算的起步，我接受了更感兴趣的运维管理工作，与用友的前沿团队一起实现IaaS、PaaS平台的投产运行。我遇到了另一位良师益友，他让我感受强执行力已经不能带动团队快速前进，更需要的是广阔的专业知识、自驱力的强大、充分的信任、业务的体系与格局。我要从基层程序员的纯编程角度上升到更高维度，从写好代码到思考客户真正的需求，甚至从公司成本等多角度的开始思考业务背后的意义。 怀揣感恩与学习的心态珍惜每次遇见与告别，开放的心态，全力以赴使众人行，见证良师益友们不同的视野、格局和领导力，成就了如今的我。 从业务出发的技术创新，找到下一个赛道2008年随着SaaS在国际市场的快速发展，用友网络作为国内TOP的软件公司，很早就拥抱了前沿理念。我连续半年吃住在公司，打破原有软件部署方式将SaaS产品上线。然而那时国内还是拨号上网的时代，企业办公的网络环境无法支持SaaS的超时代模式，最终公司缩减了相关业务，让我备受打击。期间收到了阿里云的测试岗位的Offer。换个地方做擅长的事？还是留下挑战其他可能性？我选择了后者。 近几年世界经济格局变化快，业务发展迅猛，每一次技术变革都会释放大量劳动力。云计算争议到上云、AI、云原生，岗位随着新技术出现有了新的定义和能力要求，有人甚至提出运维将会消失的说法。 业务与技术克服与斗争的艰苦历程很难与外人言说，就像阿里云的飞天一样，相信相信的力量。我负责畅捷通小微企业的运维管理，为了实现租户的隔离，我们将Cloud Foundry集群规模扩展到连开源它的Pivotal公司都没想到的地步，单物理机支持1000个容器（900个挂起100个运行），高峰时并发运行达到30万，当时应该是在全球范围内最大的集群规模。虽然技术上取得了不错的成绩，在核算成本时却发现面向小微企业的机器成本还是过高。 随着我们全面转向了云时代，我把自己从管理员定位为云架构师，实时更新知识结构，在看到云未来的风向后，带领团队成功转型，也在与阿里云的磨合中相互成就。我认为云乐高式的低代码、强配置玩法，可以实现产品经理即可用的新运维管理模式。 从运维转型技术运营，以上云来替代传统的IDC模式，不能只是将物理服务器换成云主机，而是整个工作模式、意识形态的变革。需要我们主动了解并理解云产品和其运行模式，比如网络的延时、多可用区的模式、负载、消息等。此外，提升产品的高可用性，通过极简操作实现引爆市场的可能。不光需要保证产品的稳定，更关注用户的产品体验，看见更多未来。 运维已去，技术运营已来 很多人好奇技术运营有什么不同?其实技术运营是从运维保障，转变为技术服务。我认为作为技术运营思考的是如何促进产品的成熟？如何发挥技术的价值？如何为用户带来感动？让新运维成为企业的另一个核心竞争力！我更多时刻会从财务视角判断并决策，作为成本中心从商业角度控制成本投入和分配，以获取资源利用率和营收最大化。从客户真正的痛点出发，平衡稳定、安全、容量与成本，用创业心态做产品，用花自己工资的心态去运营。 与近年来互联网公司融资烧钱的方式不同，用友网络企业的价值观是绝不做亏本的生意。作为技术运营，我们不再是传统运维分配资源的方式管理。从业务出发评估投入产出比，资源利用率、甚至是每个客户的资源成本等，将成本的意识完全植入到研发的体系中，让公司每一位开发人员明确业务资源的成本，合理申请公司IT资源，提升了整体研发能效。 本质上我们从维护升级为经营，兼任技术、运营、产品与财务的角色。通过技术运营理念，对研发进行赋能，为全国几百万小微企业提供稳定、高效的SaaS服务。 谈及在公司的坚守，熊昌伟认为比起跳槽，在同一战场的扎根更能体现自己的能力。每个阶段都超出预期的拿到结果，个人成长也就在一个个项目中磨练的更强，也与良师益友们一起成为行业技术变革的引领者。虽然他没有成为阿里人，但是作为阿里云 MVP，他同样在他的技术人生路上奋斗不止、奔腾不息。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

6月9日， 在2020阿里云线上峰会上阿里云混合云战略正式发布：全栈建云、智能管云、极致用云。同步发布专有云敏捷版（Apsara Stack Agility）、 混合云管理平台（Apsara Uni-manager）以及下一代企业级一站式DevOps平台“云效”三大新品。阿里云智能资深技术专家王小瑞对混合云管理平台（Apsara Uni-manager）进行了详细解读。 新时代下企业客户数字化转型面临的挑战 早期企业在做数字化转型时开发的应用程序面向的用户规模非常小，例如银行、电信行业开发的应用程序主要面向柜台操作人员，而柜台的数量是有限的，所以他们面向的用户规模也有限。最近十年移动浪潮的来临，让每个人的手机都成为一个柜台，此时企业开发的应用面向的用户规模就发生翻天覆地的变化，呈现几个数量级的增长。而随着虚拟化、容器等新技术的发展，企业的IT基础设施也发生了翻天覆地的变化，开始从传统架构全面转向云架构，多云架构被越来越多的企业所认可并采用。 Gartner的报告显示：2020年，90%的中大型企业将利用混合云管理基础设施；IDC认为：未来混合云将占据整个云市场份额的67%。 为什么众多企业会选择“混合云”呢？我们认为主要原因有三点：第一中大型企业都有自己的数据中心，混合云可以帮助企业“利旧”，进行成本分摊。第二企业会有一些敏感数据需要在私有数据中心处理，特别是金融行业的企业还存在“合规”的需求，它一定需要在自己私有的数据中心部署自己的应用程序。第三随着IoT、5G、大数据、AI等新技术产生的新场景，会对算力提出更高的要求，而公共云在这方面具备天然的技术优势和成本优势。 虽然“混合云”可以解决以上困难，但是混合云也给企业带来了新的问题。IT基础设施架构的复杂度，相对于单云、传统IT大幅度增加，企业对IT基础设施的运维管理将面临新的挑战。在传统IT时代，企业仅需要维护好几十台机器就基本可以满足业务需求，而在云时代企业要管理的机器（或容器）可能多达几百台、上千台，甚至上台的规模，会遇到稳定性、成本、安全、效率等方面的挑战。不同部门之间，还可能需要进行成本分摊、权限控制等，这都给云平台的管理带来困难。而在混合云场景下，情况更加复杂。比如不同云厂商对于云的概念和API可能完全不一样，而云服务和资源又分布在不同的云平台之上，如何实现一致性体验，如何让开发人员、运维人员能像“一朵云”一样使用“多云”，这些挑战非常巨大。 在混合云场景下企业客户需要解决的问题 我们把企业中使用云的用户分为四类：决策者、运营管理人员、云用户、运维人员。决策者最希望在同一个地方看到云的所有资源，甚至资源的使用率。运营管理人员要为企业中每个部门的权限控制、成本分摊负责，这就需要构架一个一整套的分权、分账的企业IT治理体系。“云用户”主要是指我们的开发者，他最关心的是如何能高效地使用云资源，比如可以很快速地创建一个虚拟机。而运维人员更关心的是如何高效地在线上做变更，并且能保证稳定性。 客户场景：多级云一体化管理 “多级云”面向超大型集团用户，一般为总部云和区域云两级，这两级云会分期建设，甚至使用不同的云厂商。区域云有完全的自治管理能力，总部需要有对区域独立专有云的集中管控能力。这里会出现混合多云和混合单云的场景，我们希望给客户呈现的结果是使用“多级云”像使用“一朵云”一样简单。 客户场景—混合云管理 当客户已使用阿里云专有云，但是部分应用希望跑在公共云之上，这时客户就会选择混合云的部署方式。如何解决公共云和专有云统一管理的问题，比如说账号权限的统一、资源的统一，这就是一个巨大的挑战。 客户场景—异构云纳管 当客户已经使用基于Vmware、OpenStack的私有云，同时也使用了阿里云专有云，这时就需要将多个异构云进行统一管控，从多云共存到多云融合。只有资源统一，才有机会统一向开发者提供运营能力，比如开发者在申请资源时就不用关心底层使用的是VMware还是阿里云专有云。 混合云管理—细分场景 除以上几个场景外，在混合云管理中还存在一些细分场景：应用跨云部署、数据备份、应用弹性伸缩、系统容灾、混合云DevOps等，这里详细介绍一下“应用弹性伸缩”。互联网应用常会用到“应用弹性伸缩”，比如有一个应用的流量存在高峰和低谷，客户只需要为它的平均流量分配机器来布置专有云，如果遇到高峰流量就可以瞬时“弹”到公共云上面去。在业内通常被称为“异地多活”，遇到的挑战是如何能把流量快速分配到公共云上，如何能在公共云上自动分配出这些资源，这就需要混合云的管理系统来做这些事情。 阿里云混合云管理平台重磅发布 为解决以上客户痛点，我们正式推出阿里云混合云管理平台（Apsara Uni-manager），面向混合云和多级云场景的企业级云管理平台，提供全方位资源供给、运维和运营管理能力，具备一体化管控、自动化运维，智能化分析及个性化扩展等核心竞争力，通过极致的用户体验，简化混合云管理，加速企业业务数字化转型。面向开发者重新定义了云和应用的界面，在混合云、多级云、异构云场景下，开发者看到的是完全统一、一致的界面。 接下来介绍阿里云混合云管理平台（简称云管平台）主要功能特性。 资源供给 阿里云混合云管理平台提供面向云租户的资源自助供给门户，包括资源实例的申请开通、资源实例的操作和监控，账单查看以及租户的数据统计分析等能力。比如客户同时购买了阿里云公共云和专有云服务，“云管平台”可帮助客户通过一个管控台就能够完成多个云资源的申请开通、账单查看、资源统计分析等任务。 资源运营 阿里云混合云管理平台提供完整的混合云运营能力，包括组织权限、服务目录，流程审批，计量计费等能力。在混合云场景下，可以让不同的云实例拥有一致的组织账号和权限模型，并且基于这些统一的账号做到统一的流程审批、统一的计量计费。 资源运维 阿里云混合云管理平台提供集中化的混合云运维能力，通过自动化和智能化的技术，降低运维成本，提高运维效率。“运维”一直是企业IT的重点，“云管平台”提供了统一的管理入口，预置大量自动化任务，可以大幅度减少因为人工操作的产生的运维事故；为防止“删库”这类高危操作，云管平台汲取阿里巴巴多年线上运维实践经验，提供事前可以审核、事后可以审计的能力；对于线上机器的数据目录提供特殊保护，运维人员即使拥有运维权限也无法进行删除；同时集成阿里巴巴数据中心多年沉淀的智能化算法，比如可根据磁盘的运行指标提前预测出哪些机器可能出现“坏盘”的情况，并自动完成故障机器的下线，从而自动化地提升云平台的可用性。 资源展现 阿里云混合云管理平台为企业IT决策者提供了全景数据大屏，可以看到整个资源的全景，混合云资源统一展现，支持千人千面及自定义展现。 开放集成 阿里云混合云管理平台提供的所有管理功能全部可以通过开放API被二次集成，并且这些API与公共云API接口保持标准一致，完全兼容。对于大型企业，各种第三方系统都很容易和阿里云混合云打通。 【总结】 阿里云混合云管理平台（Apsara Uni-manager）是混合云的智能指挥官，致力于打造一个企业级的云管理入口，来实现精准、高效、智能的混合云和多云的统一管理。为决策者提供全景数据大屏，全方位可视化展现数据，支持大屏和移动端等多终端展现，具备千人千面和自定义分析展现的能力。为运营管理员提供完整的混合云&多级云运营能力，包括服务目录，流程审批，计量计费等能力。为云用户（开发者）提供资源自助门户，包括资源实例的申请开通、资源实例的操作和监控，账单查看等能力。为运维人员提供集中化的高效运维能力，通过自动化和智能化的技术，降低运维成本，提高运维效率。 了解阿里云混合云

近日，在2020阿里云“全速重构”峰会上，阿里巴巴副总裁许诗军提到一个数字“11182”，在海口抗疫期间，利用AI技术在2小时内完成11182次外呼，极大提升防疫人员工作效率，而这背后正是智能外呼机器人技术的应用。 阿里云通信智能外呼机器人是通过呼叫控制，结合阿里达摩院语音转文本（ASR）、语音合成（TTS）、自然语言处理（NLP/NLU）等技术手段以及阿里云大数据能力，针对传统客户服务领域外呼难题，推出的智能呼叫产品。 企业通过阿里云智能外呼机器人可以实现企业服务流程打通，通过简单界面配置操作即可完成复杂的外呼场景。企业可根据实际业务场景编排外呼使用的文字内容，机器人通过外呼任务和预置的文字内容自动触达用户，通过外呼机器人来完成技术水平低、重复度高的工作，不仅节省成本，也提升了工作效率与收入。 用户在接通电话后，AI外呼语音会根据预设的对话策略选择相应文字内容，通过语音合成技术TTS转换为语音播放给用户，当用户回应后，通过智能语音识别技术ASR翻译成文字，机器人对文字进行语义分析理解后，根据知识图谱和对话策略再选择对应文字内容，再通过自然语言生成技术生成文本，最后通过语音合成生成语音响应客户，完成一轮通话交互。 智能外呼机器人可广泛应用于电商、汽车、教育、IT、餐饮、政务、旅游等各个行业领域，实现客户意向的确认、客户信息确认、活动通知、产品销售、满意度调查等业务，帮助企业全面升级数字服务模式，降本增效。 在这个大数据时代，企业数字化转型速度加快，技术将越来越深入人们的日常生活，改变生产方式。智能外呼机器人在本次抗疫期间优异和全面的表现得到社会各方的高度认可和赞誉，赢得消费者群体的信任。企业智能化升级为智能外呼机器人发展提供良好的契机，未来市场值得期待。

快速上线全球100支工单流程，为员工提供千人千面的HR自助服务……借助阿里巴巴旗下低代码应用搭建平台“宜搭”，仅仅历时3个月，阿里巴巴HR共享服务中心全新上线，标志着全面服务阿里巴巴生态化、全球化的HR共享服务平台诞生了。 作为一个拥有超10万员工的全球化公司，阿里巴巴HR共享服务中心不仅要全面支持阿里巴巴在全球各地的HR工作，更要思考如何通过信息化、数字化能力，让HR从日常的事务性工作中解放出来，集中精力关注公司业务和战略，提升HR的整体服务效率，降低运营成本。 场景痛点阿里巴巴HR共享服务的主要业务涵盖：入职、离职、合同、内档等，比如证明打印（如婚育证明、在职证明、收入证明等）；社保办理（如福利地变更/保留申请、社保缴纳证明、异地养老/医疗转入、生育报销及津贴申请等）；公积金办理（如公积金支取、异地公积金转入等）；以及各类居住证、户口、档案、签证等业务的办理。在一开始，因为缺乏统一的系统平台支撑，HR共享服务中心的业务发展遇到了不小的阻碍。 （一名员工正在线下服务台办理HR相关业务） 举个例子，当一名员工需要打印个人收入证明时，他可以向多个反馈渠道求助：拨打热线电话，前往线下服务台或者线上发起咨询，这就导致了同一个需求可能会在不同渠道重复反馈。而距离总部比较远的员工，受服务时间和地点的限制比较严重，员工数比较少的地方可能都没有单独设服务台。 从HRSSC业务侧来看，一方面由于业务办理没有全部线上化，业务处理的进度也没有可视化，造成了服务效率和质量不可控。另外，由于线、网、台渠道链路没有打通，同一个需求有多人在同时跟进，导致人力资源浪费严重。 是否可以通过外购或者自研解决上述问题？如果选择外购，市面上没有贴合业务的产品，如果选择自研，成本将非常高。在偶然的一次内部宣讲上，HRSSC团队知道了“宜搭”，它可以通过低代码的方式快速搭建更贴合业务的应用，即便不会写代码的业务人员也能轻松开发应用，这正是团队所需要的。于是，HRSSC团队立即决定通过“自研+宜搭”混合的方式开发“阿里HR共享服务工单系统（HRSSC）”。 快速上线工单流程，业务实现自主交付经过3个月的努力，阿里巴巴HR共享服务中心全新上线。借助宜搭低代码可视化搭建应用的能力，平台快速上线了全球100支工单流程，一次搭建双端适配，即使没有代码基础的业务人员也可以灵活配置页面组件和数据服务，上下线管理一键完成，业务方完全自主交付和管理。 千人千面自助服务，进度追踪一站式搞定新上线的阿里HR共享服务中心支持了国内和亚太9大类38个子类的业务，并且可以根据每个员工所在的国家、福利地、层级等因素进行自动判断，自动生成千人千面的个性化页面，让员工可以聚焦跟自身密切相关的问题。员工的业务办理进度在后台实时可视，可以看到当前流程结点的办理人是谁？并可及时与之互动。即使离总部较远的员工也能享受到标准化的HR服务，员工体验更好。 一体化线上协作，表单流程上线效率提升100倍新系统将热线电话、线上咨询、线下服务台三大渠道进行了整合，将所有工单集中在工单中心进行统一处理。员工只需要在HR共享服务中心提交需求，后台工作流系统就会分配给专人跟进，避免了多渠道多责任人带来的人力成本浪费。宜搭提供的标准化线上服务能力大大提升了业务运营的效率，原本需要一个月才能上线的表单流程，用宜搭1.5小时就能配置完成，流程效率提升了100倍。 业务自主交付，工单业务全面线上化工单的内容、流程，不再依赖开发人员，HRSSC业务人员通过宜搭即可实现自主配置、自主上线，大大提高了HRSSC业务职能的效率，用很短的时间实现了工单的全面线上化管理。 推动业务模式创新，高效支撑生态化、全球化业务随着公司业务的不断扩大，海外员工的比重也越来越高。考虑到生态和海外多样化的业务需求，HRSSC业务团队通过宜搭来快速支持生态公司和海外业务的落地。全面支持了全球10+个国家，具备海外在线机器人问答、热线电话、员工自助Portal、业务自配置办理单等能力，在3个月内达到了国内HRSSC员工服务4年的系统建设水平。 “宜搭”低代码应用搭建平台，用技术创新提升了业务效率，降低了运营风险，改善了服务体验，奠定了扎实的阿里HR共享服务生态化和全球化的支撑基础。未来，阿里HR共享服务工单系统（HRSSC），不仅要实现更广泛的业务线上化，还要实现服务线上化，将核心服务场景显性化建立服务SLA，为员工和管理者提供更高效和优质的服务。 为了让更多的企业像阿里巴巴一样，利用低代码平台赋予的技术能力，在企业内部快速搭建出符合实际业务需求的个性化应用，宜搭于近期上线了精品应用市场，涵盖企业运营管理5大领域（行政、HR、费控、法务、IT）。同时，宜搭还为那些对数据安全要求高、希望数据存储在自己专有云内的用户提供了专有云版本，现在登陆宜搭官网（aliwork.com）即可体验。

作者 | 李国强  阿里云资深产品专家 本文整理自《Serverless 技术公开课》。关注“Serverless”公众号，回复“入门”，即可获取 Serverless 系列文章 PPT。 今天来讲，在 Serverless 这个大领域中，不只有函数计算这一种产品形态和应用类型，而是面向不同的用户群体和使用习惯，都有其各自适用的 Serverless 产品。例如面向函数的函数计算、面向应用的 Serverless 应用引擎、面向容器的 Serverless Kubernetes，用户可以根据自己的使用习惯、使用场景或者应用类型，去选择使用什么样的 Serverless 产品。下面通过本文给大家介绍一下，阿里云都有哪些可供大家选择的 Serverless 产品。 Serverless 产品及分层众所周知，最早提出 Serverless 的是 AWS，其在 Serverless 领域的旗舰产品是 function compute。同样阿里云也有函数计算的产品，帮助用户构建 Serverless 函数。但 Serverless 不仅仅是函数，如下图所示，其实用户会期望在应用、容器等层面也能够享受到 Serverless 的好处，包括按量付费、极致弹性等，这样也更符合用户原有的使用习惯。 在上图中，大家能够看到，阿里云针对函数、应用和容器都推出了对应的 Serverless 产品，用户可以针对自己的使用场景选择不同的产品。 函数计算 1. 函数计算介绍 上图展示了函数计算的使用方式。从用户角度，他需要做的只是编码，然后把代码上传到函数计算中。这个时候还不会产生费用，只有到被调用的时候才有费用。调用的方式可以是产品提供的 API/SDK，也可以通过一些事件源，比如阿里云的 OSS 的事件。比如用户往 OSS 里的某一个 bucket 上传了一个文件，希望这个文件被自动处理；比如上传一个 zip 包，希望能够自动解压到另外一个 bucket，这都是很典型的函数场景。 另外，函数计算能够提供非常好的弹性能力，最终的费用是根据时长和内存数进行计费的，如果调用量小的话，只会有很少的费用。并且它在语言方面也非常丰富，常用的 nodejs、php、python、java 都直接支持。同时提供自定义的运行环境，可以支持任意的可执行的语言。 2. 函数计算典型场景 从使用场景来说，主要有三类： Web 应用：可以是各种语言写的，这种可以使用 Serverless 框架新编写的程序，也可以是已有的应用。比如小程序后端、或者发布到 API 市场的 API 后端应用等；对计算能力有很强的弹性诉求的应用：比如 AI 推理、音视频处理、文档转换等；事件驱动型的应用：比如通过其他阿里云产品驱动的场景、Web Hook、定时任务等，函数计算已经与很多产品进行了打通，比如对象存储、表格存储、定时器、CDN、日志服务、云监控等，可以非常快速地组装出一些业务逻辑。3. 函数计算核心竞争力 ...

作者：蒋晓伟（量仔） 阿里巴巴研究员 因为侧重点的不同，传统的数据库可以分为交易型的 OLTP 系统和分析型的 OLAP 系统。随着互联网的发展，数据量出现了指数型的增长，单机的数据库已经不能满足业务的需求。特别是在分析领域，一个查询就可能需要处理很大一部分甚至全量数据，海量数据带来的压力变得尤为迫切。这促成了过去十多年来以 Hadoop 技术开始的大数据革命，解决了海量数据分析的需求。与此同时，数据库领域也出现了一批分布式数据库产品来应对 OLTP 场景数据量的增长。 为了对 OLTP 系统里的数据进行分析，标准的做法是把里面的数据定期（比如说每天）同步到一个 OLAP 系统中。这种架构通过两套系统保证了分析型查询不会影响线上的交易。但是定期同步导致了分析的结果并不是基于最新数据，这种延迟让我们失去了做出更及时的商业决策的机会。为了解决这个问题，近几年出现了 HTAP 的架构，这种架构允许我们对 OLTP 数据库里的数据直接进行分析，从而保证了分析的时效性。分析不再是传统的 OLAP 系统或者大数据系统特有的能力，一个很自然的问题是：既然 HTAP 有了分析的能力，它是不是将取代大数据系统呢？大数据的下一站是什么？ 背景为了回答这个问题，我们以推荐系统为例分析一下大数据系统的典型场景。 当你看到购物应用给你展示正好想要买的商品，短视频应用播放你喜欢的音乐时，推荐系统正在发挥它神奇的作用。一个先进的推荐系统，核心目标是根据用户的实时行为做出个性化的推荐，用户和系统的每一次交互都将即时优化下一步的体验。为了支持这样一个系统，后端的大数据技术栈已经演变为一个非常复杂和多元化的系统。 下图展示了一个支持实时推荐系统的大数据技术栈。 为了提供优质的实时个性化推荐，推荐系统重度依赖实时特征和模型的连续更新。 实时特征可以分为两类： 系统会收集大量的用户行为事件（比如说浏览、点击等），以及交易记录（比如说从 OLTP 数据库同步过来的付款记录等）。这些数据量非常巨大（可能高达每秒种数千万甚至上亿条），并且其中的绝大部分不是来自交易系统。为了方便以后使用，这些数据会导入到系统里（图中的 a），同时它们会和各种维表数据做关联推导出一系列重要的特征（图中的 1），这些特征会实时更新到推荐系统以优化用户体验。这里的实时维表关联需要低延迟高吞吐的点查支持才能跟得上新产生的数据。系统也会使用滑动窗口等方式去计算出各种不同维度和时间粒度的特征（比如说一个商品过去 5 分钟的点击数、过去 7 天的浏览量和过去 30 天的销售等）。根据滑动窗口的粒度，这些聚合可能通过流计算或者批处理的方式完成。这些数据也被用来产生实时和离线机器学习的样本，训练出来的模型经过验证后会持续地更新到推荐系统中。 上述所解释的是一个先进的推荐系统的核心部分，但这只是整个系统的冰山一角。除此之外还需要实时模型监控、验证、分析和调优等一整套体系，这包含：使用实时大屏去查看 A/B 测试的结果（3），使用交互式分析（4）去做 BI 分析，对模型进行细化和调优。除此之外，运营还会使用各种复杂的查询去洞察业务的进展，并且通过圈人圈品等方式进行针对性的营销。 这个例子展示了一个非常复杂但典型的大数据场景，从数据的实时导入（a），到预聚合（b），从数据服务（1），持续聚合（3），到交互式查询（4），一直到批处理（2）。这类复杂场景对大数据系统有着非常多样化的需求，在构建这些系统的实践中我们看到了两个新的趋势。 实时化：业务需要快速地从刚刚收集到的数据中获得商业洞察。写入的数据需要在秒级甚至亚秒级就可见。冗长的离线 ETL 过程正在变得不可容忍。同时，收集到的数据比从 OLTP 系统同步过来的数据要大得多，用户浏览点击等日志类数据甚至要比它大几个数量级。我们的系统需要有能力在大量实时数据写入的同时提供低延迟的查询能力。服务 / 分析的融合：传统的 OLAP 系统在业务中往往扮演着比较静态的角色。我们通过分析海量的数据得到业务的洞察（比如说预计算好的视图、模型等），这些获得的知识通过另外一个系统提供在线数据服务。这里的服务和分析是个割裂的过程。与此不同的是，理想的业务决策过程往往是一个持续优化的在线过程。服务的过程会产生大量的新数据，我们需要对这些新数据进行复杂的分析。分析产生的洞察实时反馈到服务创造更大的商业价值。服务和分析正在形成一个闭环。现有的解决方案通过一系列产品的组合来解决实时的服务 / 分析融合的需求。比如说，通过 Apache Flink 做数据的实时预聚合，聚合后的数据会存储在类似 Apache Druid 这种提供多维分析的产品中，并且通过 Apache HBase 这类产品来提供数据服务。这种烟囱式开发的模式会不可避免地产生数据孤岛，从而引起不必要的数据重复，各个产品间复杂的数据同步也使数据的一致性和安全性成为挑战。这种复杂度使得应用开发很难快速响应新需求，影响了业务的迭代速度，也给开发和运维都带来了较大的额外开销。 ...

QuestMobile2020数据显示，疫情发生以来，每个网民每天花在移动互联网的时长比年初增加了21.5%，对于视频类应用增长尤为突出。而短视频用户规模已超8.5亿，用户使用时长在移动互联网用户使用总时长占比已达10.5%，仅次于社交与长视频。 我们已经到了视频+时代，视频正在成为一个基础的能力:第一：视频已成为信息传输、交互的主流方式，从最早的文字到图片，再到现在的视频，视频和我们学习、生活、工作、娱乐越来越息息相关。 第二：直播带货、短视频、VLog等形式的不断涌现，视频已经从原来在泛娱乐领域里专有的一个特性，向教育，金融，电商、资讯、健康等垂直行业快速全面渗透，视频与业务紧密结合，催生了更好的业务价值传达形式。 第三： 4K、8K、 VR、AR、MR这些交互的不断发展，AI和5G新技术的助推，视频与云计算深度融合，为用户提供了更流畅、更高清、更实时、更真实的体验，用户对于视频的依赖程度不断在加深。 但视频是一个比较特殊的领域，企业想要从零到一搭建视频应用，会面临着一系列挑战：第一前期资源投入大，视频在带宽、流量、存储等计算资源的消耗上，远高于其他的互联网来务，需要投入大量的资金来建设基础设施。 第二技术门槛比较高，分布式的存储、计算，视频编解码、视频加密以及高并发流畅播放，整个流程涉及到多个技术栈，对于团队技术能力要求非常高。 第三个是运营成本比较高，视频是非结构化的数据，面对海量的视频特别是短视频业务，涉及媒资管理、审核、剪辑等多个流程，这些工作都是会比较耗费大量的人力。 那如何解决这些问题？阿里云就推出了视频点播一站式解决解决方案，它集音视频采集辑、上传、自动化转码处理、媒体资源管理、高效云剪辑处理、分发加速、视频播放于一体，综合了对象存储OSS可靠性、视频的规模化处理能力、阿里云AI技术以及强大的CDN分发能力，提供端到端的视频全链路服务。客户在使用时，无需考虑存储以及带宽瓶颈，按需使用，按量付费，是一种非常好的控制成本、快速为应用构建视频点播能力的方式。 阿里云视频点播整体架构 PGC视频、UGC短视频（如抖音、快手的短视频）以及直播录制的文件，这些视频资源上传到云端，在云端完成对视频的处理，包括媒资服务、媒资管理服务、视频内容安全审核、视频转码等环节，然后通过阿里云的CDN进行内容分发，最终在用户终端进行播放，整个服务覆盖了视频从生产到消费的整个生命周期。 视频生产针对需要在应用中添加一个能让用户拍摄、编辑并发布的短视频功能的客户，阿里云 提供产品级的短视频的SDK，通过SDK能够快速实现主流短视频的功能，如录制、导入裁剪、变速处理、美颜，滤镜、转场、拼接等，以及一些高级的功能，如瘦脸大眼、动态贴纸、mv的效果等。由于SDK UI是高度仿真并开源的，客户可根据自己的业务场景非常方便进行定制，快速上线APP。 媒资管理 媒资服务，即为视频内容提供相应的管理和应用，包括媒体文件管理、meta信息管理、数据服务。由于UGC场景产生的内容良莠不齐、需要对UGC的内容进行AI审核，以此来保障内容的合规。点播服务可以提供对黄、反、暴恐、广告内容的快速识别和反馈，降低人工审核的成本和提高审核效率。 视频的DNA也就是视频指纹，即用 DNA的技术来唯一标记一个视频，它不会随视频文件的格式转换、剪辑拼接压缩而发生变化。在短视频场景里，可以利用视频DNA来做原创识别、内容查重、版权保护。比如新上传的内容如果和内容库里版权内容的DNA是匹配的，那么可以标记这个新上传内容，并由客户来决策如何处理这样的内容。 针对应用中内容list封面图片，传统的做法是运营通过人工截图或单独制作，针对海量的短视频内容，这个成本是非常大的，如果没有人工参与，通过系统截图的方式，展现效果是有可能是非常差的（如模糊、非关键内容），在这个看标题看封面的用户惯性下，会降低视频的点击率。视频点播的智能首图技术可通过美学AI模型，选取最具用户吸引力那一帧自动生成封面图片。通过各业务方人工评测劣品率低至0.71%，处理耗时提升6倍。 媒体转码对视频来说在云端最重要的一个环节就是媒体处理，通俗来讲就是视频转码，即将多媒体的数据转换成适合在全平台、各终端播放的媒体格式和适应不同网络条件播放（如蓝光、高清、标清）的规格在转码过程中，以及增加业务所需的水印或视频加密。 在转码服务中，阿里云提供独有的转码技术-窄带高清，窄带高清就是对视频中每个场景、动作、内容、纹理等进行智能分析，保证相同视频画质下，码率更低，以带来存储成本和播放成本的降低，在大规模应用视频场景下，对成本的节约是非常明显的。 消息通知在上传、转码、候视频AI处理、截图等相应服务完成时，视频点播平台都有相应的消息通知，方便业务层即时响应和处理相应的业务流程。 视频分发播放云端处理完成之后，最后的环节是播放。这里的播放包括两层，第一就是视频内容的边缘分发，基于阿里云遍布全球的2800+节点，可以实现视频内容的流畅播放。第二视频点播服务还提供多终端的播放的SDK，除了支持基础的播放能力外，更是深度融合了阿里云视频云的业务，比如支持视频的加密播放，安全（加密）下载、清晰度切换等能力。 以上就是视频点播从生产到消费的全链路服务。在这里面还有一个非常重要的点，就是内容安全。视频点播针对内容安全提供了从访问限制、到播放中心鉴权力、视频加密，安全下载，多维度保障视频访问安全和不被盗播。 整体来看视频点播包括短视频的解决方案，覆盖了端、云、端一体化解决方案，利用这套体系，企业可以简单、低成本、快速搭建视频点播的业务，为业务开拓新的赛道。 以上内容截选自6月10日阿里云视频点播高级产品专家的直播分享，可前往以下链接《视频豪横时代，如何快速构建视频点播能力？》查看完整内容： 关于视频点播如何使用，请点击查看视频详情

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 阿里云 MVP黄坤是个言简意赅的实干家，言谈中显示出的知识广度和技术深度令我钦佩折服，这一位曾在自己熟悉的信息领域驰骋，如何在转入保险行业后依然游刃有余？怎样成功地将丰富的信息化行业经验引入到保险行业中？本次专访，或许能提供一些答案。以下是黄坤的专访，推荐阅读（约5分钟）革旧维新，引领先锋我对新生事物总是比较感兴趣，愿意投入时间和精力去钻研，希望能够把新东西研究透彻。坚持一定的知识广度和某个领域的深度相结合，既有一定的广泛知识基础，又在研究某个具体技术点的时候，愿意深入了解，在这个投入的过程中，经常能够从其他领域获得灵感，触类旁通。关于激励方面，主要还是解决了复杂事情，比较有成就感，也能够自我驱动，自我激励，不断挑战新的目标。 选择从互联网行业转去保险行业主要原因是我觉得中国人整体上保险保障力度很弱，很多人需要合适的保险，但是市场上能够买到的价格实惠、保障力度足够的保险产品实在是非常有限。保险行业发展空间巨大，但是整个行业无论是人才素质、管理能力，研发能力、承保和理赔能力参差不齐，是一个有巨大改进改善和提升空间的行业。所以我愿意选择这样的行业，从零开始学习保险行业知识，融入这个行业，不断学习不断为行业做出自己的贡献，推动行业进步。 我所在的企业安心保险传统核心系统向互联网化改造能够成功，主要得益于“三个面向、三流分离”原则的落地和实施。我提出这个原则，是考虑到金融科技首先要解决战略目标的问题，它是不同于互联网企业的IT的，金融企业信息化首先要面向客户、面向业务和面向网络。在具体系统建设过程中，传统公司核心系统大而全，不利于面向互联网业务的发展。要做互联网化改造，必须要对业务流、控制流和数据流来进行分离操作，让核心系统尽可能小，只有这样才能够提高并发处理能力，快速完成产品上线，响应业务发展。 未雨绸缪，静待时机大数据和人工智能未来在保险行业将有巨大的发展空间，无论是客户获取、核保、理赔、反欺诈还是客户服务方面，都会有广泛的应用空间。保险行业在数字化转型中将广泛应用前沿科技，人工智能、大数据、云计算、移动互联、5G等前沿科技都将在保险行业获得巨大的发展空间。 对传统保险从业人员将带来多方面的挑战：第一是将改变传统的客户获取和触达方式；第二是风险控制和风险识别在核保领域也存在很大差别，未来新技术会在核保环节广泛应用；最后是产品设计和理赔环节也会面临巨大的改变。 在业务上将会带来很多广泛和深远的影响，比如从销售层面，未来会更多使用互联网触达客户的方式获取客户；在产品设计上将会更多依赖大数据分析来进行产品设计；在承保侧将运用新技术来进行风险识别；在理赔环节也广泛采用人工智能和大数据技术来防止欺诈风险。 在繁忙的工作之余，黄坤还坚持健身、乒乓球、羽毛球、游泳等运动，也会经常写作。阿里云 MVP正是这样一群人，懂技术，也懂生活。 黄坤近期技术分享：保险行业传统核心向互联网化演进 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

作者 | 张磊  阿里云高级技术专家、CNCF 官方大使，CNCF 应用交付领域 co-chair，Kubernetes 项目资深维护者 美国西部时间 2020 年 5 月 27 日，阿里云和微软云共同宣布，Open Application Model （OAM） 社区携手知名混合云管理项目 Crossplane，联合发布了 OAM  在 Kubernetes 平台上的标准实现与核心依赖库项目。新版的 OAM 核心依赖库以 Go 语言编写，由来自阿里、微软和 Crossplane 三方的工程师共同维护，能够以 Kubernetes 插件或者 Go 语言依赖库的方式被社区所使用。在内置了 OAM 核心依赖库之后，Crossplane 项目也实现了“华丽升级”，从原先的混合云管理项目一跃成为了一个能够面向所有云环境、提供“应用 + 云服务”一站式管理与交付体验的 OAM 标准实现平台。 OAM 核心依赖库项目：https://github.com/crossplane/oam-kubernetes-runtimeCrossplane 项目：https://github.com/crossplane/crossplaneOAM 是阿里云与微软云在 2019 年末联合推出的标准化云原生应用管理模型。相比于传统 PaaS 封闭、不能同“以 Operator 为基础的云原生生态”衔接的现状，基于 OAM 和 Kubernetes 构建的现代云原生应用管理平台，本质上是一个“以应用为中心”的  Kubernetes ，保证了这个应用平台在能够无缝接入整个云原生生态。同时，OAM 可以进一步屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。 OAM 项目：https://github.com/oam-dev/spec “Cloud 2.0”时代的应用定义模型应用容器技术自诞生开始，就以“彻底改变了软件打包与分发方式”的魅力迅速征服了几乎所有的云厂商与数据中心。 不过，软件打包与分发方式的革新，并没有能够让软件本身的定义与描述发生本质的变化，基于 K8s 的应用管理体验，也没有让业务研发与运维的工作变得更简单。 实际上，Kubernetes 带来的云原生技术革命，在于实现了基础设施层的标准化和抽象，但这一层抽象距离业务研发与运维还是太过遥远了。一个最典型的例子，直到今天，Kubernetes 里面始终都没有“应用”这个概念，它提供的是更细粒度的“工作负载”原语，比如 Deployment 或者 DaemonSet。而在实际环境中，一个应用往往是由一系列独立组件的组合，比如一个“PHP 应用容器”和一个“数据库实例”组成的电商网站；一个“参数服务节点”和一个“工作节点”组成的机器学习训练任务；一个由“Deployment + StatefulSet + HPA + Service + Ingress”组成的 Kubernetes 应用。 ...

6月9日，在2020阿里云线上峰会上，“宜搭”重磅发布专有云版本和精品应用市场，为政企数字化转型提供高效、安全、可靠的服务。宜搭是阿里巴巴集团企业智能事业部自研的低代码应用开发PaaS平台，通过可视化拖拽的方式，传统模式下需要2周才能开发完成的表单流程类应用，用宜搭2小时就能完成。 宜搭负责人范之岳在峰会上介绍，宜搭平台是阿里巴巴内部孵化的一款明星产品。目前，在阿里内部已经搭建了3000多个月度活跃应用，其中99%的应用都是由没有开发经验的阿里员工搭建的。从统计数据来看，这些用宜搭搭建的应用累计为阿里巴巴节约近10万人/日的资源投入。在疫情期间，宜搭以0代码、快速搭建应用的优势，第一时间助力各级政府及企业快速实现疫情防控和管理，累计支持了19个省、28个地市、2000多个组织机构的防疫项目，并免费开放各类疫情相关的应用供政府和企业使用。 （宜搭负责人范之岳在云峰会上介绍宜搭） 上线专有云版本在本次峰会上，宜搭重磅发布了专有云版本，它基于阿里云专有云的云原生技术部署，这意味着用宜搭平台搭建的应用也支持云原生的基础能力。专有云版本的宜搭，可以满足那些对数据安全要求高、希望数据存储在自己专有云内客户的定制化需求，这也是宜搭的政务客户、大型企业客户翘首以盼的能力。 宜搭专有云版可以独立部署在客户自己的阿里专有云中，客户可以用自己专属的宜搭平台，实现快速的数字化自交付、自运营，就像阿里巴巴一样，在组织内诞生出成百上千个能够极大提升工作效率的应用。 基于阿里云专有云，宜搭已经与政务钉钉完成了深度集成，为政府及大型企业打造数字化的协同平台，提供安全可靠的政企数字化转型方案。 （宜搭全新发布专有云版本） 发布精品应用市场为了进一步降低企业的应用开发成本，让没有开发能力的业务同学通过拖拽的方式就能自主完成应用搭建，宜搭推出了精品应用市场。它涵盖了企业运营管理5大领域（行政、HR、费控、法务、IT），共计30多款精品应用模板，让宜搭平台的客户可以快速定制和扩展应用，满足自身业务的个性化诉求。 有了宜搭，业务人员只需要关注业务需求本身，数据存储、运行环境、服务器、网络安全等都由宜搭帮你搞定。这样一来大大降低了企业搭建应用的门槛，提升了应用交付质量，能打造出更符合实际业务需求的企业应用，帮助企业解决数字化转型难题。 （宜搭全新发布精品应用市场） 提升应用构建能力宜搭还进行了平台能力的升级，面向专业开发者提供了强大的逻辑编排扩展能力。开发者可以通过拖拉拽的方式进行逻辑层开发， 对单据和流程生命周期的事件进行处理，也可以定义计划任务、消息通知、数据操作、服务、脚本等。灵活的逻辑扩展能力可以帮助企业和组织实现更复杂的业务场景。 （宜搭面向专业开发者提供了强大的逻辑编排能力） 同时，宜搭与阿里巴巴旗下的数据大屏产品DataV进行了集成。 宜搭平台的应用采集和处理的数据，可以直接与DataV的大屏进行打通。 两款产品的集成，给客户带来更完美的数据场景解决方案。 （宜搭宣布与DataV进行集成） 现在，用户可登陆宜搭官网（aliwork.com）体验以上内容。宜搭作为一款泛业务场景的低代码应用开发平台，始终致力于通过好用、便捷的功能，以更低的成本实现组织运营管理的信息化、数据化和智能化，让小而美的应用在每个组织内部遍地开花，助力政府和企业快速实现数字化转型。

前言：更多关于数智化转型、数据中台内容可扫码加群一起探讨 阿里云数据中台官网 https://dp.alibaba.com/index 作者：数据小海豚 随着大数据趋势的迅速增长，数据的重要性与日俱增，企业内看数据、用数据的诉求越来越强烈，其中最常见的就是各种经营报表数据： 老板早晨9点准时需要看到企业核心的经营数据，以便进行企业战略及方向决策 业务负责人不定期进行个性化的项目筹划，需要多维、及时效果数据以优化项目安排 运营需要和高层一致但粒度不同的经营分析数据，并进行活动策略调整 …… 举个经营报表的例子： 这个例子并不复杂，但是对于分析师或者业务开发者，实际执行的复杂度和工作量并不小，而且类似的工作每日都在重复……业务发展越快，带来的问题就越来越多： 加工时间长、人工成本高，招再多的分析师也难以满足需求 代码可读性差，数据可维护性差，类似需求需要反复、重复开发 代码开发不规范，加工过程中难以避免的计算存储浪费 得到的数据指标，复用性差导致重复建设，数据越来越不标准规范 这种情况下，对业务的直接影响就是：决策周期长（数据需求满足慢），决策易出错（数据指标口径不一致）。 既要保证数据生产时效性——及时产出数据并满足需求，又要支持数据多样性——企业自下而上不同业务分析场景，最后还要保证数据准确性——任何时间、不同岗位的人都能用同样的数据解读经营情况，怎么才能做到呢？ 企业的发展加速，离不开20世纪的文档管理转到21世纪的信息管理。同样的，如果繁复的指标代码编写工作，也可以如计算器一般，界面可视化点选，复杂的代码研发过程由计算器自行处理完成就好了。 而Dataphin的自动化建模功能，就可以很好实现这个能力。 1、选择组合条件如下图，确定需要统计计算的值，Dataphin里称为“原子指标”——最小的数据值统计单元，比如用户数这样的统计值等，然后组合如下内容： A. 统计计算值需要应用的分析对象，Dataphin里称为“统计粒度”——维度或维度的组合，比如用户星级、用户状态等B. 数据统计计算的时间周期，Dataphin里称为“统计周期”——统计数据需要跨越的时间长度，比如最近1天、最近30天、自然周、自然月的等C. 数据统计的其他个性化限定条件，Dataphin里称为“业务限定”——数据记录的筛选过滤条件，比如生鲜业务类型、PC端、女性等 2 预览指标选择完毕组合条件后，可以预览组合出来的派生指标： 1）组合的指标，默认名取“原子指标+时间周期+业务限定”组合名，保证命名标准规范。 2）历史已生成的组合，不再生成，保证指标建设统一，无重复 3 一键自动化生成确认需要提交的指标后，一键【提交】，分钟级指标生成： 1）自动汇聚至以“统计粒度为主题”的汇总逻辑表表下，保证管理标准规范； 2）代码和调度依赖关系，系统自动生成； 3）派生指标基于汇总逻辑表，可快速雪花模型查询使用指标、分析对象的属性信息。 ①派生指标自动汇聚至汇总逻辑表 ②派生指标所在汇总表节点，代码及调度关系自动生成 ③汇总表及派生指标可查询消费 4 复杂需求实现上面主要是基于简单统计指标实现，实际上，报表需求还有类似 比率型、乘积型等复合统计方式，比如“客单价=销售额/客户数”，这类也可以通过Dataphin的衍生原子指标实现： 1）衍生原子指标是基于原子指标的再组合； 2）基于衍生原子指标新建派生指标时，需要保证拆解到最细粒度的原子指标，有相同的分析维度、时间周期，允许维度的计算路径不同、设置的业务限定不同。 ①新建衍生原子指标 ②基于衍生原子指标新建派生指标 总结上面步骤可以看到，派生指标的计算生成，离不开原子指标、业务限定、统计粒度的协助，这其中有什么奥秘呢？ 其实很简单，用Dataphin高效创建派生指标，掌握这1张图就够了： 1）原子指标为核心，原子指标的来源表为中心 2）统计粒度取自来源表的关联维度，以及关联维度上的关联维度 3）业务限定基于来源表为中心的雪花模型做定义 4）统计周期可任意搭配使用 数据中台是企业数智化的新基建，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云数据中台解决方案对外输出，包括零售、金融、互联网、政务等领域，其中核心产品有： Dataphin，一站式、智能化的数据构建及管理平台；Quick BI，随时随地 智能决策；Quick Audience，全方位洞察、全域营销、智能增长；Quick A+， 跨多端全域应用体验分析及洞察的一站式数据化运营平台；官方站点： 数据中台官网 https://dp.alibaba.com ...

2020年6月9日，阿里云 MaxCompute 全新发布企业级新能力，在成本、性能、安全方面，持续定义企业级SaaS模式云数据仓库，通过 “云数据仓库+” 的新模式，帮助企业实现数字经济新优势。 据介绍，最新发布的算力资源解决方案中，多计算资源打通方案融合了包年包月与按需使用两种资源调配方式，针对日常业务稳定并伴随突发计算需求的实际业务场景，可实现更优的成本与性能平衡；抢占算力资源方案，则针对测试、非紧急作业等业务场景，可实现计算资源价格较包年包月标准计算资源下降74%。此次安全能力方面的发布包含数据安全加密、持续备份恢复、实时审计日志和跨地域容灾备份。安全能力的全面升级将MaxCompute平台系统安全能力提升到了更高的水平。 MaxCompute原名ODPS，是阿里云飞天系统三大件中大数据计算的部分。 历经十年发展，MaxCompute支撑着阿里巴巴经济体内部所有的业务，存储着阿里巴巴经济体超过99%的数据，提供了95%以上的计算力，同时服务着阿里云上各行业的数千家企业。 阿里云智能研究员，MaxCompute计算平台负责人关涛表示，大数据领域，经过10年的发展，已实现普惠化，并且进入到企业和政府的关键环节，正在被大规模的应用。所以，大数据平台当前的痛点，已经不再是如何使用的问题，而是，如何在大规模的情况下，平衡价值与成本；如何让企业用起来更安全，更可靠，更经济，更便捷。所以MaxCompute率先提出了SaaS模式云数据仓库的概念，力求将复杂留给系统，为企业提供开箱即用，更经济，更安全的大数据计算服务。 深刻理解企业的算力资源需求，提供兼顾成本与性能的算力方案 谈到降低成本，提升效率，首先是平台引擎侧的性能提升，其次是数据治理相关的效率提升， 然后就是本次发布的关于优化资源使用方面的提升。从企业使用情况分析来看，大约存在着 四种较为典型的企业级计算力的需求模式。 第一种是平台成熟，资源使用稳定，每天的大数据计算波动不大。典型的例子就是阿里巴巴经济体。这种用户，适合选用包年包月的预付费资源模式。 第二种是面向初创型企业，企业业务存在着较大的变化性和高速迭代性。这种情况下，适合选用按量付费模式，后付费，不使用不收费，更无需关心资源配置。 第三种是本次全新发布的，面向日常业务平稳并伴有突发计算力需求的企业，MaxCompute可提供预付费与按量付费混合的算力解决方案，平衡日常的资源使用成本，同时又能满足大促等突发业务对资源弹性的需求。 第四种是本次全新发布的面向部分客户需要的测试作业，以及不保证SLA作业的超低成本的算力方案。通过将系统闲置资源打包，形成非预留型资源包，从而为客户提供较包年包月标准计算资源下降74%的算力价格。 安全能力重大升级，持续保护企业云上安全 数据作为一种资产，面临诸多风险。MaxCompute作为企业级云数据仓库，提供了三级安全能力超过20项的安全功能。不仅包含最底层的基础设施，数据中心，网络、供电的安全，也包含中间层的平台能力安全，以及向上的用户权限管理，隐私保护层面的安全。 数据安全加密。根据数据资产的要求，发布BYOK功能。用户可以自带密钥，对数据进行全链路加密。 持续备份恢复。自动化的容灾管理能力，用户可通过配置的方式将数据做自动容灾，并做自动的容灾恢复。 跨地域的容灾备份。在容灾恢复的基础上，MaxCompute提供跨集群的容灾能力,极限情况下，当某一个数据中心不可用时，用户的数据和计算仍然可以不受影响。 实时审计日志。MaxCompute提供实时审计的能力，使得用户的管理员可以实时追踪所有数据的变化。 本次全新发布的四项安全功能，使得MaxCompute安全体系进一步提升，安全能力已经达到业内的较高水平。 了解更多SaaS模式云数仓MaxCompute，欢迎访问官网 https://www.aliyun.com/product/odps

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 对朱祺我是好奇的。初次交流时，仅限于一个积极活跃、涉猎广泛的印象，拥抱新技术的传统业者。后来读过他许多文章，发现在很多领域，几乎是“凡我所及，必有朱祺”。我非常惊讶，一个人是怎样用有限精力投入到无限研究中的，顿觉此人Young & Powerful，迫不及待想要了解更多。以下为朱祺的专访内容，欢迎收看（约3分钟）。当爱好成为职业大数据本身也是我的业余爱好之一，所以并不会枯燥，也不会计较精力投入问题，我差不多除了睡觉都在研究这些。进行各个行业领域研究的时候，首先想一下自己需要得出的结论目标方向，然后去分析下结论会是什么，没有方向确立的话经常想着想着会偏题，所以目标先明确再去思考其中的过程，最终得出结论。迅速了解跨界行业的最好办法是和不同行业的朋友聊天，因为书本上的知识有时会和实际情况有差异，因此和朋友讨论是最好的办法。另外我想说的就是阿里云 MVP是我最为珍视的头衔，当然也有责任去推动数据变革。 有一个项目比较有意思。之前网上有观点说特征分析如果做得好，不用了解生产过程也能设计出很好的算法。于是我把自己实验数据集的标签全部删掉，用PCA（主成分分析算法）又试了一下，准确度其实还真差不多。但是经过仔细思考，其实了解生产过程必要性在于算法的选择精准，而不是在于特征值怎么去处理，在了解生产过程或者业务流程的基础上设计出的算法是有灵魂的。 云计算赋能行业互通各种技术的选择和叠加代表着需要增加投资，能源行业的数字化转型会遇到一些普遍问题。比如云计算的应用，投资会产生多少回报，这个回报未必是金钱，也可以是工作效率。数字化转型是长远趋势，是必然，但是目前需不需要，需要到什么程度，新技术的采用能够产生什么价值，各方面始终有不同意见。最简单的争议比如在计算量能够被满足的时候，本地IDC机房虽然之前服务器买多了，但是现在要做私有云，又要增加投入，更有可能服务器不满足要求需要更新，那这个投入是不是值得。如果本地IDC的服务器能够部署，那么云计算就能够提高效率避免新购服务器。 很多行业是相通的，比如能源行业，特别是电力行业，和智慧城市、智慧建筑和智慧园区等都是密不可分的。最典型的阿里云的千岛湖数据中心和张北数据中心，网上宣传视频都提到一个很重要的点就是节能，各种节能方式包括对于服务器的改进和可再生能源的利用等，就联系到了电力行业。所以个人还是很喜欢跨界研究，利于开阔眼界和深度思考。不止是反哺自己所在的电力行业，更是融合，包括大数据、云计算、物联网、移动互联网、人工智能和区块链技术对于电力行业的赋能，也包括了本行业同其他行业的融合。王坚博士说云计算就像电力资源一样，是基础设施，阿里的五新中，新能源的能源指的是数据，那作为被参照比较的无处不在的电力，本身就有能结合信息技术加深同其他行业进一步融合的提升空间。 数据驱动时代，关注人类需求我对电商行业也做了不少研究。第三次信息时代开始的时候虽然中国还是落后欧美一些，但目前这个差距至少在大数据方面已经没有了，并且部分领域还是领先的。数据驱动时代到来，中国幅员辽阔形成的天然优势就是数据量大。在领先的领域中，电商和社交非常明显的领先于国外，很多先进算法在这两个领域中已经实践过并且取得了成功，这个代表虽然其他行业还没有使用但可能会成为未来发展的方向。 最近对大健康很感兴趣，业余会看看大健康产业的布局、数据的类型和常用的算法等，没有特别的目的，就是感觉这个产业如果数据驱动能够做好，对人类社会的发展是有价值的，毕竟生存是人第一需求。 阿里云 MVP朱祺还是PADI潜水教练，这项运动帮助放松，也培养克服恐惧、勇往直前的精神。拥抱变化，勇于探索，因为相信，所以看见。这是朱祺的最好写照，阿里巴巴的好朋友。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

2020年6月9日，阿里云重磅发布第七代ECS企业级高主频实例以及新一代弹性裸金属云服务器，目前已启动邀测。 新一代的高主频实例搭载最新一代英特尔®至强®可扩展处理器（代号Cedar Island）以及阿里云自研的第三代神龙云服务器架构， 标配ESSD云盘，整机算力是上一代的2.6倍。 第三代神龙架构让第七代实例性能和稳定性大幅提升，在网络存储转发能力、延时、性能的稳定性等方面均做到了业界领先。尤其适用半导体仿真设计、工业仿真、 游戏、高性能数据库和渲染等场景。 在计算方面， 实例最大支持192个vCPU，计算、存储、网络性能继续领跑全球。 为了提升安全性和稳定性,阿里云进一步完善no QEMU极致优化,，降低ECS计算抖动。配合Aliyun Linux 2 LTS，第七代实例启动速度最多提升60%、运行时性能最多提升30%。 网络方面，第七代ECS实例有了重大突破，首次支持50Gx2的网络架构， 配合阿里云物理网络架构全面升级，最多可以使用100G带宽，同时将传输带宽提升近5倍，空载网络延时有最多下降30%。 为了配合网络转发能力和带宽的提升， 第七代高主频实例支持大帧传输，， 真正能够把带宽物尽其用。依托神龙计算平台的转发效率，，世界领先。 存储方面， 整机存储吞吐从2GB上升到4GB，吞吐能力提升一倍；存储转发能力从20万 IOPS提升到60万IOPS；写延时最多下降20%以上，接近裸盘性能。 性能稳定性方面，阿里云采用软硬一体的计算架构，将物理机上的转发任务卸载到神龙芯片上，避免了底层资源争抢而导致的虚拟机性能波动。 第七代ECS实例不仅进一步降低性能抖动，同时引入硬件级别QOS能力，为客户关键业务带来更强的保障。 一键直达： 了解产品详情：https://www.aliyun.com/daily-act/ecs/hf7_sales 领取新用户优惠：https://www.aliyun.com/daily-act/ecs/activity_selection_618 发布会回顾：https://summit.aliyun.com/events? 限量邀测报名：https://page.aliyun.com/form/act1413187633/index.htm

6月9日，2020年阿里云线上峰会召开。阿里云智能总裁张建锋认为，数字化已经成为中国经济的主要驱动力，疫情让政府、企业都认识到数字化的迫切性。在峰会上，阿里云CDN正式对外发布基于CDN构建的六大边缘安全能力，全力助推政企数字化发展。 阿里云CDN产品专家彭飞在演讲中表示：作为关键互联网基础设施之一，CDN帮助互联网应用实现用户访问体验的提升之外，也逐渐渗透到传统领域，比如政府、金融、传媒等等，帮助他们来应对数字化转型中业务互联网化的技术挑战，在追求更快速、更稳定的内容分发加速体验的同时，网络攻击的防护也是他们十分关注的命题。 例如，对高可性和安全性非常敏感的金融行业，如何防御逐年上升的DDoS与CC攻击，如何满足行业安全合规要求？对于企业官网来说，如何应对WAF攻击，避免来自恶意刷量、爬虫的的骚扰？在线政务平台如何实现全链路传输内容加密和防篡改？传媒企业如何确保业务高可用与内容一致性？ 为了应对以上挑战，CDN也需要进行持续的创新和升级。 在全站加速产品基座之上，通过云安全能力在边缘的注入，阿里云CDN打造了WAF应用层安全、DDoS网络层安全、内容防篡改、全链路HTTPS传输、高可用安全、安全合规六大安全体系，形成了边缘安全的立体防护能力，一站式保障分发加速与业务安全。 加速效率仍需提升，全站加速提升30%动静混合站点分发效率CDN本质上是提供内容分发加速服务的，而大部分企业的官网中都既有图片、文件类的静态资源，也存在一些如账号登录、数据查询等动态的交互，针对动静内容要做智能分离，采用不同的策略，才能呈现更好的加速效果。 阿里云全站加速可实现动、静态内容智能识别，针对静态内容，通过CDN边缘节点多级缓存实现高命中率的静态内容分发加速，针对动态内容，基于实时网络探测、智能路由选路、传输协议的优化、内容压缩传输等一系列的技术手段，来提升回源效率，降低访问时延，整体上可以帮助动静态混合页面提升30%的分发效率。 对抗Web应用攻击，CDN边缘节点注入WAF安全能力在应用层，最常见的攻击形式是Web应用攻击，如SQL注入、XSS跨站脚本等攻击手段，会对网站的数据内容、品牌形象造成极大的风险。 CDN边缘安全体系架构分为边缘节点和回源节点，采用多级、双层的防御体系，为用户构筑一道完整的边缘应用层的防护体系。在回源节点侧，通过WAF能力注入，帮助回源动态请求实现Web攻击的防护。同时，云安全0 day漏洞实时更新支持24小时内为高危风险漏洞提供虚拟安全补丁。在边缘节点侧，也提供频次控制与机器流量管理能力，识别恶意爬虫、刷量软件等机器流量，降低用户下行带宽，避免成本浪费。在实际应用场景上，方案可以帮助零售企业的电商销售平台避免WAF攻击、CC攻击和刷量等恶意行为。 边缘平滑联动DDoS高防，确保业务平稳银行、保险、券商等金融企业由于本身业务的敏感性，经常会遭受到外部攻击，其中DDoS攻击防护十分关键。阿里云政企安全加速解决方案通过CDN边缘节点与DDoS高防平滑联动方案，自动化实现DDoS攻击识别、调度至高防节点进行流量清洗与平稳后的流量回调，让用户可以享受到高防节点的上T级别的DDoS防攻击能力以及上百万级别的QPS防御能力，同时在没有攻击时用边缘节点来保障加速效果。 独享+国密+防篡改方案，全方位保障链路与内容安全对于政务网站、党建学习平台等场景来说，信息的准确性至关重要。除了采用https来进行源站到CDN、CDN到客户端的全链路传输加密，也需要规避源站和CDN节点上的内容安全风险。 针对高安全等级的业务场景，阿里云基于前期在股份制银行、央媒等大型项目中的最佳实践经验，沉淀了一套基于独享物理资源、国密算法与节点一致性校验等手段的防篡改方案，可以最大程度规避内容安全风险。同时，为了让更多用户将防篡改能力应用到其业务场景中去，阿里云也提供独享IP、双证书keyless等更通用、简化的技术方案。 边缘高可用与合规认证，层层保障让业务更安心通过主备源切换、源站告警、离线模式、灾备站等多种模式，来保障当源站出现风险时CDN仍然能够为用户响应内容，为源站恢复争取时间。同时，在合规认证方面，阿里云具备国内外97项合规认证，其中与CDN相关47项，包括等保2.0三级、金融云等保四级、可信云、ISO27001系列、PCI DSS安全认证等一些列认证，作为国内领先的合规服务商，阿里云可以完全满足客户对合规性的要求。 基于CDN构建的边缘安全体系，阿里云发布了政企安全加速解决方案，这是阿里云CDN加速落地政企行业的一大步。阿里云CDN产品专家彭飞表示：解决方案已经在金融、传媒、政府、航空、车企等众多领域上得到客户的认可，阿里云CDN希望与客户一起构建极速、安全的互联网体验。对此，阿里云还开展了CDN加速以及DDoS防护、高级版WAF免费试用活动，帮助更多企业降低解决方案的使用门槛。详细情况，可以登录阿里云官网搜索「政企安全加速」进一步了解。 搜索加入钉钉群：34249460，进行解决方案咨询。

企业高速发展，对各类管理软件的需求日益增长，随之而来的是系统孤立、数据不通、应用操作繁琐以及部署运维成本高、投入大、成效慢等问题。现在，通达与阿里云通力合作，通过面向不同规模的企业提供以知识管理和协同办公为核心的云上一站式工作平台，实现简单、极速、高效的应用体验，从而解决以上难题。相比于传统方式，企业硬件部署成本平均节省60%，时间上也缩短了近一半。 OA 是Office Automation的简写，即办公自动化。顾名思义，它是现代利用电脑进行全自动的办公，目的是提高办公效率，这是广义的OA概念。现代意义的OA系统，是指通过先进的计算机技术、有线和无线等网络通信技术，处理单位内部的工作，实现协同审批，辅助办公管理，实现提高办公效率和规范管理的软件系统。 通达OA协同办公标准解决方案是针对企事业单位、政府部门等日常办公信息化而设计的标准解决方案，基于协同办公理念，将日常办公电子化、网络化、规范化、统一化。 实时跨部门、跨地域协作办公，达到节省办公时间、节省办公成本、提高工作效率的目的。随着通达OA的日常使用，逐渐建立了单位内部的完整知识库，利于单位内部知识的传播与分享。通达OA协同办公标准平台，能充分体现单位的管理思想、企业文化、单位成果等。最终目的是提高单位的管理水平和运营效率。 Office Anywhere网络智能办公系统是中国企业办公自动化软件(OA软件)普及型的旗舰产品，是中国用户群最广的OA产品，是与中国企业最佳管理实践相结合，形成的中国企业最佳综合管理办公平台。它充分适应了中国企业高速发展和逐步规范的现状，是通达信科在二十余年从事管理软件研发过程中集技术创新、项目实践、先进的管理思想和中肯的客户建议为一体的完美结晶。 衡量一款办公软件好不好用，建议买家首先要着眼于其的易用、安全、稳定、灵活、开放等这些核心的特性方面，其次，还要看其是否符合办公习惯、是否满足办公需求、是否方便维护、是否具有先进的开发技术等等。一直以来，秉持从技术到产品的专一、精纯，让通达产品更加专业与成熟，也因此能更好地对应和服务起客户的高适配性与深度的需求。 企业上云一站式服务：https://www.aliyun.com/activity/daily/enterprise-solution?spm=a1z2e.8028000.0.0.6f2f6a6ckI7W6y 作为阿里云的重要合作伙伴，此次通达基于云OA应用入口与云网组合的形式，阿里云拥有云服务器、云负载均衡、云数据库、云存储、云加速等云计算资源集群，以独立部署的方式提供给企业客户，能够保证智能办公信息系统秒速打开，系统稳定运行，数据安全私密，可以为不同类型的企业，打造最贴合企业性质的协同办公解决方案。

作者 | 子白（阿里云开发工程师）、溪恒（阿里云技术专家） <关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Kubernetes 集群中，业务通常采用 Deployment + LoadBalancer 类型 Service 的方式对外提供服务，其典型部署架构如图 1 所示。这种架构部署和运维都十分简单方便，但是在应用更新或者升级时可能会存在服务中断，引发线上问题。今天我们来详细分析下这种架构为何在更新应用时会发生服务中断以及如何避免服务中断。 图1 业务部署图 为何会发生服务中断Deployment 滚动更新时会先创建新 pod，等待新 pod running 后再删除旧 pod。 新建 Pod图 2 服务中断示意图 中断原因：Pod running 后被加入到 Endpoint 后端，容器服务监控到 Endpoint 变更后将 Node 加入到 SLB 后端。此时请求从 SLB 转发到 Pod 中，但是 Pod 业务代码还未初始化完毕，无法处理请求，导致服务中断，如图 2 所示。 解决方法：为 pod 配置就绪检测，等待业务代码初始化完毕后后再将 node 加入到 SLB 后端。 删除 Pod在删除旧 pod 过程中需要对多个对象（如 Endpoint、ipvs/iptables、SLB）进行状态同步，并且这些同步操作是异步执行的，整体同步流程如图 3 所示。 图 3 Deployment 更新时序图 Podpod 状态变更：将 Pod 设置为 Terminating 状态，并从所有 Service 的 Endpoints 列表中删除。此时，Pod 停止获得新的流量，但在 Pod 中运行的容器不会受到影响；执行 preStop Hook：Pod 删除时会触发 preStop Hook，preStop Hook 支持 bash 脚本、TCP 或 HTTP 请求；发送 SIGTERM 信号：向 Pod 中的容器发送 SIGTERM 信号；等待指定的时间：terminationGracePeriodSeconds 字段用于控制等待时间，默认值为 30 秒。该步骤与 preStop Hook 同时执行，因此 terminationGracePeriodSeconds 需要大于 preStop 的时间，否则会出现 preStop 未执行完毕，pod 就被 kill 的情况；发送 SIGKILL 信号：等待指定时间后，向 pod 中的容器发送 SIGKILL 信号，删除 pod。中断原因：上述 1、2、3、4步骤同时进行，因此有可能存在 Pod 收到 SIGTERM 信号并且停止工作后，还未从 Endpoints 中移除的情况。此时，请求从 slb 转发到 pod 中，而 Pod 已经停止工作，因此会出现服务中断，如图 4 所示。 图 4 服务中断示意图 解决方法：为 pod 配置 preStop Hook，使 Pod 收到 SIGTERM 时 sleep 一段时间而不是立刻停止工作，从而确保从 SLB 转发的流量还可以继续被 Pod 处理。 iptables/ipvs中断原因：当 pod 变为 termintaing 状态时，会从所有 service 的 endpoint 中移除该 pod。kube-proxy 会清理对应的 iptables/ipvs 条目。而容器服务 watch 到 endpoint 变化后，会调用 slb openapi 移除后端，此操作会耗费几秒。由于这两个操作是同时进行，因此有可能存在节点上的 iptables/ipvs 条目已经被清理，但是节点还未从 slb 移除的情况。此时，流量从 slb 流入，而节点上已经没有对应的 iptables/ipvs 规则导致服务中断，如图 5 所示。 图 5 服务中断示意图 解决方法： Cluster 模式：Cluster 模式下 kube-proxy 会把所有业务 Pod 写入 Node 的 iptables/ipvs 中，如果当前 Node 没有业务 pod，则该请求会被转发给其他 Node，因此不会存在服务中断，如 6 所示；图 6 Cluster 模式请求转发示意图 Local 模式：Local 模式下，kube-proxy 仅会把 Node 上的 pod 写入 iptables/ipvs。当 Node 上只有一个 pod 且状态变为 terminating 时，iptables/ipvs 会将该 pod 记录移除。此时请求转发到这个 node 时，无对应的 iptables/ipvs 记录，导致请求失败。这个问题可以通过原地升级来避免，即保证更新过程中 Node 上至少有一个 Running Pod。原地升级可以保障 Node 的 iptables/ipvs 中总会有一条业务 pod 记录，因此不会产生服务中断，如图 7 所示；图 7 Local 模式原地升级时请求转发示意图 ENI 模式 Service：ENI 模式绕过 kube-proxy，将 Pod 直接挂载到 SLB 后端，因此不存在因为 iptables/ipvs 导致的服务中断。图 8  ENI 模式请求转发示意图 SLB图 9  服务中断示意图 中断原因：容器服务监控到 Endpoints 变化后，会将 Node 从 slb 后端移除。当节点从 slb 后端移除后，SLB 对于继续发往该节点的长连接会直接断开，导致服务中断。 解决方法：为 SLB 设置长链接优雅中断（依赖具体云厂商）。 如何避免服务中断避免服务中断可以从 Pod 和 Service 两类资源入手，接下来将针对上述中断原因介绍相应的配置方法。 Pod 配置apiVersion: v1kind: Podmetadata: name: nginx namespace: defaultspec: containers: - name: nginx image: nginx # 存活检测 livenessProbe: failureThreshold: 3 initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 tcpSocket: port: 5084 timeoutSeconds: 1 # 就绪检测 readinessProbe: failureThreshold: 3 initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 tcpSocket: port: 5084 timeoutSeconds: 1 # 优雅退出 lifecycle: preStop: exec: command: - sleep - 30 terminationGracePeriodSeconds: 60注意：需要合理设置就绪检测（readinessProbe）的探测频率、延时时间、不健康阈值等数据，部分应用启动时间本身较长，如果设置的时间过短，会导致 POD 反复重启。 ...

阿里云直播回放 头号云话题直播回放“今年将帮1000家企业'去O'，完成10000套传统数据仓库上云。”6月9日，阿里云数据库负责人李飞飞在阿里云峰会上表示，经过多年技术演进，传统数据库上云已进入大规模攻坚阶段。 达摩院数据库首席科学家、阿里云智能数据库事业部总负责人李飞飞 因传统数据库架构无法满足企业面临的业务挑战，电信、金融和政务等客户正在核心系统领域加速上云。 据悉，中国联通就通过云原生分布式数据库PolarDB-X等技术，重构了中国联通的核心IT架构，实现了对中国联通3.6亿用户的无缝“广覆盖”，成为全球最大的云上BSS系统；某全国性股份制商业银行则通过PolarDB-X支撑信用卡、借记卡等关键业务。 国家税务总局采用阿里云云原生数据仓库AnalyticDB实现了全国税务数据大集中，实现20PB+海量数据的实时计算分析，覆盖全国纳税人，推动个税系统改革。 这些通过阿里云数据库上云的案例还包括：PrestoMall、上海伯俊、百华悦邦、银泰百货、朗致集团、谊品生鲜、石基零售等诸多新零售、新金融、税务、交通、气象等核心行业的头部企业。 当天，阿里云重点介绍了云原生分布式数据库PolarDB-X和云原生数据仓库AnalyticDB在大型客户中的最新实践。前者融合了分布式SQL引擎DRDS与分布式自研存储X-DB，可实现资源池化高效管理，专注解决海量数据存储、超高并发吞吐及复杂计算效率等数据库瓶颈问题；后者基于数据库大数据一体化的理念，结合数据库、大数据、AI算法技术，实现智能数据库的重磅创新。 李飞飞透露，PolarDB系列已成为阿里云增速最快的产品之一，PolarDB-X也在阿里巴巴线上核心系统广泛使用，连续多年稳定支撑天猫双11，在1秒钟内系统负载增加了135倍情况下依然保持稳定，峰值TPS达8700万次，但成本仅为传统数据库的1/6。 AnalyticDB是阿里巴巴自研的云原生数据仓库，可支持GB到PB级任意数据规模的数据计算分析，对复杂SQL查询速度比传统的关系型数据库快10倍以上。不同于复杂、高门槛的大数据体系，AnalyticDB完全兼容MySQL、PostgreSQL，高度兼容Oracle，可对万亿级别的数据进行实时的多维度分析透视，极大地提升了企业挖掘数据价值效率。 全球云计算巨头中，亚马逊AWS和微软Azure也积极推广传统数据库上云，亚马逊CEO贝索斯甚至在股东信中，直接批评传统数据库价格昂贵、体验糟糕。 权威机构Gartner预测，2023年全球75%的数据库会跑在云上。目前，阿里云已经稳居亚太云数据库市场份额第一，客户包含政务、零售、金融、电信、制造、物流等多个领域的龙头企业。 阿里云峰会此次共发布6大新产品戳下图一探究竟 深度科技脱口秀——头号云话题新技术上场，我们去哪儿？ 被脱口秀耽误的程序员呼兰对话 达摩院数据库首席科学家飞刀 还没看过的朋友可扫描图中二维码查看回放 遗憾错过峰会直播？ 扫一扫看精彩回放吧 点这里直达数据库各专场地址 公众号后台回复“峰会” 还可免费领取阿里云数据库定制版太阳伞 （颜色有细微差别 请以实物为准） 奖品领取数量已过半 还没行动的同学抓紧啦！

2018 年夏天 国内微服务开源 领域，迎来了一位新成员。此后，在构建微服务注册中心和配置中心的过程中，国内开发者多了一个可信赖的选项。 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台(官方网站)，它凝聚了阿里巴巴十多年来在超大规模注册和配置上的最佳实践，可以用在微服务场景作为服务注册中心、配置中心等核心场景中，和阿里的其他微服务开源项目一样，Nacos 也是始于阿里，成长于社区的典型。 为什么要开源 Nacos ？ 在大规模服务发现和服务治理领域，现有的开源解决方案并非已经非常完美，阿里巴巴从 IOE 集中式应用架构升级为互联网分布式服务化架构的演进过程中，积累了大量有关服务注册和服务配置的实践经验，而这些经验是可以在各个行业大规模复用。除此之外，更重要的是，希望和社区开发者共同发展，让 Nacos 可以帮助国内企业更自由的构建基于云原生应用的动态服务发现、配置和服务管理。 相比其他服务注册和配置中心开源方案，Nacos 的起步虽然晚了点，但除了注册和配置中心的功能外，他还提供了动态服务发现、服务共享与管理的功能，在大规模场景下具备更优秀的性能，在易用性上更便捷，分布式部署上更灵活。例如和 Consul / Eureka / Zookeeper 相比：（内容摘自《主流微服务注册中心浅析和对比》） NacosConsulEurekaZookeeper一致性协议CP+APCPAPCP健康检查TCP/HTTP/MYSQL/Client BeatTCP/HTTP/gRPC/CmdClient BeatKeep Alive负载均衡策略权重/ metadata/SelectorFabioRibbon—雪崩保护有无有无自动注销实例支持不支持支持支持访问协议HTTP/DNSHTTP/DNSHTTPTCP监听支持支持支持支持支持多数据中心支持支持支持不支持跨注册中心同步支持支持不支持不支持SpringCloud集成支持支持支持支持Dubbo集成支持支持不支持支持K8S集成支持支持不支持不支持 不想自己运维Nacos? 阿里云微服务引擎MSE提供Nacos托管服务 阿里云微服务引擎 ( MSE ) 是开源注册、配置中心的全托管平台，提供高可用、免运维的 ZooKeeper、Nacos 注册中心 和 Eureka 等集群，完全兼容开源产品标准接口，无需修改代码、开箱即用，并为客户提供相应的监控和运维工具。产品官网：https://www.aliyun.com/product/mse 那么，MSE托管的注册中心，和开源自建注册中心究竟有什么区别？可以通过下面这张表来进行对比。 对比项自建注册中心MSE注册中心成本资源成本ECS费用支持按时/包年包月，约等于同等配置ECS费用人力成本需要专人维护运维MSE提供易用自动化能力运维，门槛低高可用容灾能力无支持多机房，多区域容灾宕机处理手动处理自动探测，自动恢复活性探测不支持支持进程活性探测，失败自动恢复功能数据管理命令行页面可视化，支持增删查改访问方式机器IP直连，代码要变域名，换机器，不需要变动业务报警无支持核心业务指标如链接数多维度报警配置网络方式本地网络VPC网络，公网服务管理不支持服务提供者，订阅者页面管理集群权限管理不支持支持子账号管理，可自定义子账号访问权限TPS/QPS统计不支持提供TPS，QPS监控视图运维集群观测无页面可视化，查看节点健康状态，角色监控图表无提供多种指标如Znode，链接数图形化视图配置运维手动修改，手动重启页面修改，一键重启生效节点伸缩手动扩缩容，手动重启页面选择，一键扩缩容性能伸缩不支持页面选择，一键伸缩从了解到实践 Dubbo 应用如何保证业务不停机的情况下无缝迁移到MSE？ 下面以基于 SpringBoot 构建的 Dubbo 应用为例介绍如何进行迁移 第一步：引入用于迁移的定制化注册中心依赖 虽然 Dubbo 本身提供了配置多注册中心的能力，但其存在比较大的局限性，当消费者配置多注册中心时，Dubbo 原有的策略为优先选取第一个注册中心的地址，若其地址为空，再读取第二个，依次类推选取地址。理想的模型应当是多个注册中心的地址合并后随机选取，为此，MSE 提供了专门的注册中心扩展，解决该问题： <dependency> <groupId>com.alibaba.edas</groupId> <artifactId>edas-dubbo-migration-bom</artifactId> <version>2.6.5.1</version> <type>pom</type> </dependency> 其中 edas-dubbo-migration-bom 有 2.6.5.1 和 2.7.5 两个版本，分别对应 Dubbo 2.6.x 和 Dubbo 2.7.x 两个大版本。 第二步：购买 MSE Nacos 实例，并配置对应 nacos server address 在 MSE 控制台购买相同 VPC 内的 Nacos 实例，并在应用的 application.properties 配置文件增加： dubbo.registry.address = edas-migration://30.5.124.15:9999?service-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848&reference-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848 说明： edas-migration://30.5.124.15:9999 多注册中心的头部信息。可以不做更改，ip 和 port 可以任意填写，主要是为了兼容 Dubbo 对 ip 和 port 的校验。启动时，如果日志级别是 WARN 及以下，可能会抛一个 WARN 的日志，可以忽略。 service-registry 服务注册的注册中心地址。写入多个注册中心地址。每个注册中心都是标准的 Dubbo 注册中心格式；多个用 , 分隔。 reference-registry 服务订阅的注册中心地址。每个注册中心都是标准的 Dubbo 注册中心格式；多个用,分隔。 第三步：确认双注册方案成功 启动应用，并观察到 MSE 实例的服务管理页面中注册上了提供者和消费者的信息。 ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 戚俊的快速成长离不开恰逢其时的机遇和委以重任的伯乐，毕业一两年受邀创业。当腻了CTO，于是转行VC，作为大老板的副手再次起飞。这位90后技术人的故事，或许能给你新的启迪。以下为戚俊的个人专访，推荐阅读（约3分钟）。前夜难耐，曙光难得我是一个很主动拥抱新事物的人，热衷于学习、实践新技术，从Docker到TensorFlow，只要确定技术对产品有促进作用并且可能成为趋势，我就敢把这些技术应用于产品中，属于架构师里胆子比较肥的人。 在2016年容器技术刚推出的时候，恰逢公司业务需求攀升，我们需要在扩招人员与技术升级中二选一。考虑到扩增团队的成本和风险都较大，我就做了拥抱Docker的决策。不可避免地，最初出现了很多大大小小的问题，不过最后是成功的。纵然有些风险不可控，我的决定也时常仓促大胆，好在结果总是能论证直觉的准确性。 拥抱Docker是创业以来最痛苦的一年，容器经常出问题，造成过不少事故，也直接导致公司的销售承受来自客户的许多压力。有一次容器在晚上9点多崩溃，完全无法使用，这会造成第二天100多家媒体客户无法发稿，后果相当严重，这一个行业丑闻足以颠覆公司。当时我正在高速公路上开车，立马停到服务区，钉钉联系阿里云工程师团队来解决。从晚上9点到凌晨，一直有人陆续进群处理，最终没有产生恶劣影响。也正是这次事故让我对阿里云技术团队有了更强的信心，也有了坚持下去的决心。我意识到虽然产品还有瑕疵，但我们的方向没选错，只不过还不够成熟而已，黎明的曙光不会更远了。 后来我们花了大量时间来学习、优化、迭代，也算是迈过了这道坎，现在已经实现全部容器化，包括业务、服务、网站、系统等等。很庆幸我们最终坚持了下来，2020年我们服务的客户数量是2016年的7倍，但人员只增加了不到10位，如果不拥抱新技术我们至少需要扩招70-80人。而且开发速度也得到明显提高，可以说是教科书式的降本增效范例。 事业与人生的最优解作为一个使用过40+种产品的资深用户，我和阿里云的情缘算得上是风雨同舟了。在高速公路解决容器危机时，来不及提交工单，只能直接找到产品的工程师帮忙，阿里云的工程师团队也尽职尽责地冲在问题最前面。我认为作为阿里云 MVP，有时候需要比阿里云更懂阿里云，所以平时我也会参与产品反馈等活动，注重跟产品负责人的深入交流，将心比心。 曾经发现过一个管理配置的小工具，认真仔细地使用3天后，给产品提出了很多建议。那个团队只有3个人，通过钉钉找到我沟通，我还画了原型图给他们。大概一周的时间内，他们迭代完成所有我发现的问题，也采纳了我提出的建议，其实这是很出乎我意料的。原本只是想着能做些力所能及的贡献，没想到以外部人的身份完成了和阿里云团队的产品共创与共建，于我而言是很有意义的事情。 2018年，我和另外几个MVP一起参加了阿里小伙伴组织的“玄奘之旅”，那是一次灵魂与肉体双重历练的旅途，每个人都难以忘却。在浩瀚的戈壁中徒步100公里，发生了太多足够铭记的小插曲。有一天早上5点摸黑出门，我忘记带全天的干粮，小伙伴们分给我一个牛肉干、一个苹果、一个烧饼，我靠着大家的救济一路走到了营地，哭笑不得。 还有一件事深深震撼了我，当徒步一天后回到营地，大家累到只想北京瘫。这时候有个阿里的小伙伴又跑出去找了一个山坡，爬到山顶只为了有信号参加一场钉钉会议，回到营地后兴奋地说问题解决了。这可能是思维模式的差异，有些人会觉得没信号多好，大家都找不到我，也就不用考虑工作。而他们会觉得幸好有信号，我可以完成这件工作，又给客户创造了些价值。那一刻我仿佛看到阿里人身上的光芒，带来了蛮大的冲击，之后在团队管理上，我也常讲这个故事。 从零开始，创业者都有连续创业心当初作为创业伙伴加入路特软件，在公司经营得有声有色之后，我开始思考更多可能。传统行业的天花板较低，我认为自己未来3年内在这里不会有什么质的飞跃，不满足于现状，于是想转型做一份新的事业。刚好银杏谷投资公司需要一位懂技术的人做大数据方面的判断，于是一拍即合。路特软件也希望我留下来，最终决定股份保留，薪资照发，重要会议出席即可，相当于我到新公司吸收更多的养分。 这个转变其实也是有迹可循的。作为CTO，不仅要专精技术选型，还需要关注企业全局，思考如何能快速实现更高的商业价值，如何利用技术前景与商业模式巧妙地互惠。更需要摸索平衡之道，平衡技术投入产出比，平衡技术价值与研发难度，平衡效率与稳定等。合伙人的每一个决策都会对公司产生影响，也就必须对公司负责，在所有选择里寻求最优解。 进入投行后，由于我在金融财经方面毫无经验，几乎完全是从零开始的成长，这一次转型也遇到了极大困难。首先，技术人员的思维模式是从起点到终点的清晰思路，而投资人则是确定结果后再梳理路径，从终点到起点的选择和判断，起初我很难适应。其次，没有财务背景而开展工作尤为吃力，学习财经新闻、研究企业年报的难度不亚于修一门课。第三，作为CTO时的决策，总是技术为主，商业为辅，而投资人则恰恰相反。种种思想和认知的颠覆性，是我当初难以想象，始料未及的。 在经过持续的学习和请教后，我的投资人生涯终于步入正轨，整个人也有了由内而外的巨大转变。在熟悉了资本运作的流程后，我对于产业的关注和商业模式有了更加清晰的认知，了解如何有针对性地找到最适合公司的投资。被动学习的知识量和信息呈指数增长，自我价值也完成了新的跃升。对于如何更好地去创业，我也有了愈发深刻的理解，给朋友提的建议有理有据，对于创业者来说是非常宝贵的财富。或许之后还会再次创业，毕竟每一位创业者都有一颗连续创业心。 谈及被信任的原因，戚俊调侃道，“因为体重，所以憨厚。”但我们都知道，这位阿里云 MVP敢为天下先的非凡勇气，和与人交往的真诚共情力，才是助他成功的双翼。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

大家好，我是小编云BliBli， 这些天 领导问了我一个暴击我灵魂的问题： 什么是SLA？那么多9到底是什么意思？ （瓦特？？我怎么知道？？？？？？？） 但是领导都“屈尊”问我了 我怎么敢“不知道” 经过我几天几夜的 查阅文献、翻阅“古籍”、寻师问道 终于让我明白了 SLA协议里 各种不同词汇的含义 1、何为SLA（Service Level Agreement）服务等级协议 简单来说，SLA是一种双方的约定，是一种服务可用性的指标。 说人话！！！ 就像是一对情侣 男友会向女友做出一些承诺，比如 （SLA中的对服务类型、质量时间条款的条文规定） 可男生却老是迟到 每周迟到的次数 超过了之前做的承诺的次数 （可用性低于条文中所规定的值） 为了哄女友开心 男孩只能在到达约会地点后 只能给她道歉、逛街、买礼物 表达自己的歉意 （可用性低于条文规定值，服务商所需提供的赔偿） 2、SLA和SLO 的区别 SLA（service level agreement）服务等级协议，指的是整个协议，其定义了服务类型、质量以及赔付标准等。 SLO（service level objective）服务等级目标，指的是设计可用性，其意思即为设计该产品时期望达到的可用性目标。 SLA与SLO的区别 主要是体现在“协议”与“目标”上 SLO只是产品的“设计可用性” 比如恋爱过程中 “大猪蹄子们”时常会和女友进行承诺 以后包揽一切家务 但是 “太美的承诺，因为太年轻” 承诺就仅仅是承诺 并未规定 具体该实施、实施的方法以及未达目标所受的惩罚等 （也就是“说说就是说说而已”） 3、SLA中那么多9究竟代表什么意思？ 首先，我们来明确一个概念。 即为9越多 代表全年服务可用时间越长，服务更可靠 如果我们将一个月按照30天计算 ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 跟郭旭东聊过之后，我对程序员的敬佩又多一分。这个92年的开发者，难能可贵地兼备朝气蓬勃的技术能量与长远深刻的行业洞见。独自承担DevOps平台从0到1的所有工作，我打趣说超级开发者不过如此，他却谦虚地表示差得还远，始终在学习。业余生活几乎都在撸猫遛狗的铲屎官，在云原生也有自己的一片天地。以下为郭旭东的专访内容，欢迎收看（约4分钟）。自我驱动，成就非凡我负责开发自研的DevOps平台Varian，可以说是工作中遇到过的最大难题了。整个平台由我一手搭建，从技术选型、产品设计，到代码编写、开发测试，甚至营销宣传的工作也要自己来做。对于一个习惯根据需求文档来写代码的程序员来说，是很恐怖的一件事，甚至接到任务的第一天就怕到想跑路了。但是领导的一句话：“怕什么，放手去干，做砸了也不会怪你”，给了我很大的信心，于是就放开手脚，大胆去干，反而后来越做越好了。 当时整个项目只有我一个人做，准确点说，整个部门只有我一个运维开发，其他都是从事业务开发的Java程序员，我兼任了产品、开发、测试、运维等所有角色。本身我只是一名后端开发，前端的内容也要捡起来现学，从页面的设计到实现的功能，都要一个人解决。这些技术的问题还好解决，最难的角色转换其实是产品，每天都要想方设法地给自己提需求，甚至睡觉做梦的时候都在画页面原型，同时疯狂地参加各种技术交流会，企图从别人的实践那里获得灵感。而我们的系统又是内部系统，是提供给开发和运维同学来使用的，大家都有自己的使用习惯，所以也要经常向内部团队收集需求等等。 一开始就是普通程序员，只会业务代码，没什么深入研究。负责整个平台后，要考虑整个项目流程管理，成长速度是非常快的。在不断的分享交流中，视野慢慢打开了，想做的也就越来越多了。 现在项目越做越大，团队人也很多，但运维人数只有5个，通过DevOps平台负责公司所有云资源的管理和维护，基础设施组件（代码管理平台、CI/CD 系统、资源监控系统、Kubernetes 容器管理平台、办公OA系统、项目跟踪&文档管理系统等）的开发和维护，同时也负责公司所有的IT设备的维护。DevOps平台也是随着团队的壮大不断迭代，由最初的一个由Django开发的单体应用，发展成由核心服务、CMDB服务、监控服务、消息通知服务和 CI/CD 服务组成的云原生应用。 DevOps平台现在着力于提升开发效率，降低开发与运维之间的沟通成本，由机器处理大量繁琐的运维任务，节约人力成本，使开发和运维能更专注于业务开发与维护，同时借助 Kubernetes 的容器编排和弹性能力更是释放出了大量的运维时间。2019年在业务不断增加、服务数量直线上升的情况下，ECS服务器数却在负增长，真正达到了降本增效的目的。 云原生是未来趋势我觉得云原生是开源精神最完美的体现，把各个大厂、曾经的竞争对手拉到一起共同解决问题，对推动软件发展是非常有利的。我们自己也在坚持云原生项目的输出，实践并反馈问题解决方案给上游，大家一起讨论、协调、修复。最近一年在开源方面，我为sig-cli 的子项目 Kustomize提供了完整的中文文档，让更多的中文开发者可以更接近云原生生态。同时 Istio 和 Kubernetes 也有中文文档的贡献。以前大家只关注自己的代码和项目，现在提交后共同建立项目，减少竞争和许多不必要的麻烦，社区的声音被重视，反而人越来越多，生态越来越好，算是真正发挥了开源精神。 阿里云和微软合作的OAM项目和阿里开源的混沌实验实施工具 chaosblade 是我最近比较关注的。全球首个云原生应用标准定义与架构模型，应用点分离，让管理更轻松，交付更可控；应用定义与平台层实现解耦，应用描述支持任意扩展和跨环境实现；可以自由组合和支持模块化实现的运维特征描述。可以大大降低 k8s 的入门成本。混沌工程属于一门新兴的技术学科，行业认知和实践积累比较少，大多数IT团队对它的理解还没有上升到一个领域概念。阿里开源的 chaosblade 则很好的提供了一款简单易用、功能强大的混沌实践注入工具。 进一步海阔天空当初因为独立负责项目，心里发虚，就经常去参加各种技术分享，包括网络交流，在学习的同时增长见识，渐渐就能参与其中。在学习技术方面，我推荐走出去和别人讨论、分享，当给别人讲明白，讲透彻了，自己也就精通了，这样学习的知识就很不容易忘记。而学习的过程中难免要跟外籍小伙伴交流，比如Github讨论，不要因为英语不好而退缩，英文本非我们的母语，只要表达意思明确，问题描述详细，即使是使用 Google 翻译也不是什么丢人的事情。 现在国内有很多人在把优秀开源项目的文档翻译成中文文档，同时越来越多的中国人在著名项目中起着重要作用，我们比自己想象得更优秀。克服了接触新事物的本能恐惧之后，就是另一片天地了。 代码成就人生，程序员改变世界。阿里云 MVP郭旭东也在用他的努力，让我们的生活更加便利。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

阿里云峰会直播地址 2020年6月9日，“全速重构”2020阿里云·线上峰会即将隆重召开。 在此次峰会上，阿里云数据库重磅发布云原生分布式数据库 PolarDB-X 、云原生数据仓库AnalyticDB、数据库自治服务DAS、云数据库专属集群、图数据库GDB、云数据库Cassandra版、云数据库ClickHouse 7款跨时代产品，用技术倾情打造新数字时代的基石！ 今天小编为大家倾情呈现全球首个数据库自动驾驶云平台DAS产品亮点！ 过去10年，数据库上云俨然已成共识，云数据库相较于传统线下数据库，解决了资源、弹性、高可用、备份、监控等基本DB运维负担。但如何用好数据库，如何对数据库进行快速诊断和持续优化，对一般应用开发者而言，依然充满挑战。 阿里云基于阿里巴巴自身数据库规模化运维的专家经验，结合人工智能和机器学习技术，实现自感知、自诊断、自修复和自安全的数据库自动驾驶能力，今天依托于阿里云平台，推出数据库自治服务，正式向云上客户开放。 DAS是业界首次以独立云服务的方式实现数据库自治能力，推出六大核心自治特性，覆盖支持包括OLTP(RDS/PolarDB)、NoSQL(Redis/MongoDB)、OLTP(ADB)等各类数据库引擎，并支持混合云、SQL审计和风险识别等企业级数据库运维特性，为客户数据库的稳定安全提供全方位保驾护航。 基于数据驱动、专家经验和机器学习，从异常发现、根因分析、执行修复／优化操作、跟踪评估、反馈实现全流程闭环，无需人工干预，实现数据库的自治，保障数据库持续稳定、高效运行。 DAS 具备 6大核心自治特性 7 x 24实时异常检测：通过机器学习算法，实时对数据库的Workload进行异常检测，相比基于阈值的告警方式，能够更及时的发现数据库的异常，而不是靠故障驱动； 异常自愈：DAS发现异常后，自动进行根因分析，定位到问题后，自动执行相关止损／修复／优化操作，帮助数据库自动恢复，减少对企业业务的影响； 自动优化：基于全局workload和真实的业务场景，而不是基于单条SQL，持续的对数据库进行SQL Review和优化，就像有一个不知疲倦的专业DBA一直在守护着您的数据库； 智能调参：数据库的参数成百上千，用户的业务场景多种多样，靠人肉的方式无法将参数调整为最优的配置，DAS和达摩院合作，通过基于机器学习技术，和智能压测相结合，可以为每个数据库实例的自动推荐最优的参数模版； AutoScale：基于机器学习，自动对数据库的业务模型、容量水位进行计算和预测，实现先知先觉式的自动扩缩容。 智能压测：为用户提供个性化的压测服务，DAS可以自动学习业务模型，自动生成无限多的接近真实业务的workload，同时提供给用户更丰富的压测场景，帮助用户解决大促、数据库选型等等问题。 和自动驾驶一样，数据库自治服务，也不是一蹴而就的，我们将数据库的自治能力划分为5层： Level-0:全部靠人肉，没有任何工具／产品辅助Level-1:提供基础监控、告警等信息，不输出任何建议；Level-2:在某些场景下，能够输出诊断或者优化建议，但是建议是否采纳和应用，还是由人来决策，例如SQL诊断引擎Level-3:在某些场景下，实现完全的自治，无需人参与，例如自动SQL限流、自动弹性伸缩Level-4:实现数据库的完全自动驾驶，目前DAS正在努力做到Level-4的过程中。为了实现数据库自治服务，我们已经实践了6年。 从2014年开始，我们开始尝试如何将DBA的经验转换成产品，为业务开发提供更高效，更智能的数据库服务。我们就构建了基于规则的SQL诊断引擎，即输入一条或者多条SQL后，SQL诊断引擎会直接输出优化建议； 2016年，CloudDBA的web版发布，同时也升级了SQL诊断引擎，在这个阶段用户可以直接在阿里云上通过C loudDBA直观的查看数据库的负载，同时进行SQL诊断和优化。 2018年我们通过在阿里巴巴的业务和场景，开始孵化和锤炼数据库自治能力， 通过Self-driving Database Platform，截止到2020年4月已经自动优化了4200万+的SQL、自动回收了超过4 PB的空间、自动优化了 27 TB的内存。 2019年11月，为了更好的服务客户，我们将混合云数据库管理HDM+ CloudDBA+自治的能力，升级为数据库自治服务DAS。 DAS 在4个方面取得了核心创新和突破： 首个全局综合自治引擎：基于根因分析以及实例全维度聚合信息，进行集中决策，冲突解决，专项自治场景决策分发，在多自治场景下实现综合自治。 首个外置式Cost-based SQL诊断：基于代价的诊断引擎，一套独立于数据库之外的优化器，并以自适应的统计信息收集机制，基于执行计划的代价评估，实现SQL精确诊断与优化建议输出。 基于Workload全局SQL优化技术：以Workload负载为优化单位，综合考虑Workload中影响整体性能的特征，如SQL执行消耗资源占比、读写比等，进行整体优化，实现负载整体性能最大化提升同时，最大化降低空间消耗。 基于机器学习的Workload异常发现与预测：基于机器的Workload异常发现，自动感知引发Workload变化的异常SQL，自动触发全局优化，变被动式优化为即时主动式全局优化。 和达摩院的相关的研究成果，也取得了国际学术界的认可： 2018年,WWW《Unsupervised Anomaly Detection via Variational Auto-Encoder forSeasonal KPIs in Web Applications》 2019年,VLDB《iBTune: Individualized Buffer Tuning for Large-scale Cloud Databases》 2020年，VLDB《Diagnosing Root Causes of Intermittent Slow Queries in Large-ScaleCloud Databases》 通过DAS，可以帮助企业节省90%的数据库管理成本，降低80%的运维风险，让用户可以更集中在业务创新，让业务持续行驶在快车道上。 更多DAS产品性能尽在2020年6月9日阿里云峰会数据库新品发布现场，我们不见不散！ 预约观看： ...

6月9日，在2020阿里云线上峰会上，阿里巴巴集团副总裁、数据技术及产品部负责人朋新宇推出Quick Audience、Quick A+两款全新产品，并升级Dataphin和Quick BI两款现有产品。同时，阿里云零售、金融、政务及互联网企业等四大行业数据中台解决方案也首度亮相，未来将要扶持100万家企业。 1. 数据中台扎实有效 2015年，阿里巴巴在国内首次提出数据中台概念，它是集方法论、工具、组织于一体的“快”、“准”、“全”、“统”、“通”的智能大数据体系。 历经内部复杂场景的实践后，阿里巴巴在2018年正式通过阿里云全面对外输出数据中台能力，帮助企业实现数智化转型。 朋新宇在现场分享了来自餐饮、快消、服饰、商业地产、旅游业等行业的头部企业案例。 蓝光地产利用数据中台服务孵化出了更多销售创新场景，仅“老带新”的一个单一场景就为该企业实现了单日36亿元成交额。 雅士利则通过阿里云数据中台挖掘了5个业务场景，短期快速提效，去年双11期间实现了同期增长92%。 而今年“新冠”疫情的特殊考验，更是让越来越多企业感受到数字经济趋势下数智化的重要性。 疫情期间，红蜻蜓4000多家门店无法营业，但通过全员线上服务营销，7天内新设立了500多个粉丝群，日均销售额突破百万。 无独有偶，雅戈尔3000余家线下门店在疫情期间悉数歇业。但随着全员all in线上营销，一季度整体业绩已经恢复到同期的80% 。 根据亿欧智库针对过去一年内沪深两地上市公司公告的集中研究，已有超过500家企业将数据中台的实施进展纳入了上市公告中。 2. 产品矩阵从“2”变“4” 据朋新宇介绍，阿里云数据中台核心产品矩阵从之前的两大核心产品——Dataphin、Quick BI，拓展到了Dataphin、Quick BI、Quick Audience和Quick A+四大核心产品。 聚焦智能数据构建及管理领域的Dataphin，完成了数据服务开放和自助式开发升级，并针对中小企业，提供了轻量化版本。 作为国内唯一成功进入国际知名机构Gartner魔力象限的BI产品而受到广泛关注的Quick BI，本次升级重点聚焦在与钉钉的协同合作上。升级后，用户可以实现“随时随地，智能决策”。 新亮相的Quick Audience定位于智能用户增长，帮助实现“全方位洞察、多渠道触达”的增长闭环。 Quick A+则是跨多端的全域应用洞察平台，能够帮助企业对用户进行综合分析，了解用户的使用习惯并进行相应的预测和决策。 3. 四大行业解决方案齐飞 除了丰富产品能力之外，阿里云数据中台本次峰会上，朋新宇还重磅发布四大行业数据中台解决方案：零售数据中台、金融数据中台、政务数据中台以及互联网企业数据中台，将进一步把数据中台引入全速重构业务数智化的深地。 据介绍，针对零售行业，阿里云数据中台可以提供多维的全方位洞察、全域自动化营销等服务，并通过与阿里巴巴生态联动，帮助更多零售企业实现数智化增长； 针对金融行业，提供理财业务线上用户增长、整体的数字化运营解决方案，通过联动蚂蚁生态，融合投资者教育的实践方法论，并集成支付宝小程序中，帮助金融机构实现业务增长； 针对政务行业，提供全套政务数字参谋解决方案，实现跨端、跨层级、跨系统等政务数据融通，支持政府决策科学化、社会治理精准化、公共服务高效化； 针对互联网企业，阿里云数据中台将与友盟+进行深度联动，让互联网企业能拥有阿里云数据中台的能力，在营销增长、风控、智能运营等场景中实现业务增长。 这四大数据中台行业解决方案是阿里云数据中台行业边界的一次重要拓展，标志着阿里云数据中台已经实现了从通用领域走向精细化垂直领域。 朋新宇表示，全新升级后的阿里云数据中台将成为企业数智化的新基建，未来将帮助超过100万企业，实现数智化加速升级。 数据中台是企业数智化的新基建，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云数据中台解决方案对外输出，包括零售、金融、互联网、政务等领域，其中核心产品有： Dataphin，一站式、智能化的数据构建及管理平台；Quick BI，随时随地 智能决策；Quick Audience，全方位洞察、全域营销、智能增长；Quick A+， 跨多端全域应用体验分析及洞察的一站式数据化运营平台；

Dubbo-go k8s注册中心设计方案与实现 随着云原生的推广，越来越多的公司或组织将服务容器化，并将容器化后的服务部署在k8s集群中。 今天这篇文章将会介绍dubbo-go将k8s作为服务注册中心的方案设计，以及具体实现。到目前为止该方案的实现已经被合并到dubbo-go的master分支。具体实现为关于Kubernetes的PullRequest。 k8s管理资源的哲学 k8s作为容器集群化管理方案可以将管理资源的维度可主观的分为服务实例管理和服务接入管理。 服务实例管理，主要体现方式为Pod设计模式加控制器模式。控制器保证具有特定标签（Label）的Pod保持在恒定的数量（多删，少补）。服务接入管理，主要为Service，该Service默认为具有特定标签（Label）的一批Pod提供一个VIP（ClusterIP）作为服务的接入点，默认会按照round-robin的负载均衡策略将请求转发到真正提供服务的Pod。并且CoreDNS为该Service提供集群内唯一的域名。k8s服务发现模型 为了明确k8s在服务接入管理提供的解决方案，我们以kube-apiserver 提供的API(HTTPS)服务为例。k8s集群为该服务分配了一个集群内有效的ClusterIP，并通过CoreDNS为其分配了唯一的域名 kubernetes 。如果集群内的Pod需要访问该服务时直接通过https://kubernetes:443即可完成。 具体流程如上图所示(红色为客户端，绿色为kube-apiserver)： 首先客户端通过CoreDNS解析域名为kubernetes的服务获得对应的ClusterIP为10.96.0.1。客户端向10.96.0.1发起HTTPS请求。HTTPS之下的TCP连接被kube-proxy创建的iptables的PREROUTING链拦截并DNAT 为 10.0.2.16或10.0.2.15。Client与最终提供服务的Pod建立连接并交互。由此可见，k8s提供的服务发现为域名解析级别。 Dubbo服务发现模型 同样为了明确Dubbo服务发现的模型，以一个简单的Dubbo-Consumer发现并访问Provider的具体流程为例。 具体流程如上图所示： Provider将本进程的元数据注册到Registry中，包括IP，Port，以及服务名称等。Consumer通过Registry获取Provider的接入信息，直接发起请求由此可见，Dubbo当前的服务发现模型是针对Endpoint级别的，并且注册的信息不只IP和端口还包括其他的一些元数据。 K8s service vs dubbo-go 服务 通过上述两个小节，答案基本已经比较清晰了。总结一下，无法直接使用k8s的服务发现模型的原因主要为以下几点: k8s的Service标准的资源对象具有的服务描述字段 中并未提供完整的Dubbo进程元数据字段因此，无法直接使用该标准对象进行服务注册与发现。dubbo-do的服务注册是基于每个进程的，每个Dubbo进程均需进行独立的注册。k8s的Service默认为服务创建VIP，提供round-robin的负载策略也与Dubbo-go自有的Cluster模块的负载策略形成了冲突。Dubbo-go 当前的方案 服务注册 K8s基于Service对象实现服务注册/发现。可是dubbo现有方案为每个dubbo-go进程独立注册，因此dubbo-go选择将该进程具有的独有的元数据写入运行该dubbo-go进程的Pod在k8s中的Pod资源对象的描述信息中。每个运行dubbo进程的Pod将本进程的元数据写入Pod的Annotations字段。为了避免与其他使用Annotations字段的Operator或者其他类型的控制器（istio）的字段冲突。dubbo-go使用Key为 dubbo.io/annotation value为具体存储的K/V对的数组的json编码后的base64编码。 样例为： apiVersion: v1kind: Podmetadata: annotations: dubbo.io/annotation: W3siayI6Ii9kdWJibyIsInYiOiIifSx7ImsiOiIvZHViYm8vY29tLmlrdXJlbnRvLnVzZXIuVXNlclByb3ZpZGVyIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvY29uc3VtZXJzIiwidiI6IiJ9LHsiayI6Ii9kdWJibyIsInYiOiIifSx7ImsiOiIvZHViYm8vY29tLmlrdXJlbnRvLnVzZXIuVXNlclByb3ZpZGVyIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvcHJvdmlkZXJzIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvY29uc3VtZXJzL2NvbnN1bWVyJTNBJTJGJTJGMTcyLjE3LjAuOCUyRlVzZXJQcm92aWRlciUzRmNhdGVnb3J5JTNEY29uc3VtZXJzJTI2ZHViYm8lM0RkdWJib2dvLWNvbnN1bWVyLTIuNi4wJTI2cHJvdG9jb2wlM0RkdWJibyIsInYiOiIifV0=由于每个dubbo-go的Pod均只负责注册本进程的元数据，因此Annotations字段长度也不会因为运行dubbo-go进程的Pod数量增加而增加。 服务发现 依赖kube-apiserver 提供了WATCH的功能。可以观察特定namespace内各Pod对象的变化。dubbo-go为了避免dubbo-go进程WATCH到与dubbo-go进程无关的Pod的变化，dubbo-go将WATCH的条件限制在当前Pod所在的namespace，以及仅WATCH具有Key为 dubbo.io/label Value为 dubbo.io-value 的Pod。在WATCH到对应Pod的变化后实时更新本地Cache，并通过Registry提供的Subscribe接口通知建立在注册中心之上的服务集群管理其他模块。 总体设计图 具体流程如上图所示： 启动dubbo-go的Deployment或其他类型控制器使用k8s Downward-Api将本Pod所在namespace通过环境变量的形式注入dubbo-go进程。Consumer/Provider进程所在的Pod启动后通过环境变量获得当前的namespace以及该Pod名称， 调用kube-apiserver PATCH 功能为本Pod添加Key为dubbo.io/label Value为 dubbo.io-value 的label。Consumer/Provider进程所在的Pod启动后调用kube-apiserver将本进程的元数据通过PATCH接口写入当前Pod的Annotations字段。Consumer进程通过kube-apiserver LIST 当前namespace下其他具有同样标签的Pod，并解码对应的Annotations字段获取Provider的信息。Consumer进程通过kube-apiserver WATCH 当前namespace下其他具有同样label的Pod的Annotations的字段变化，动态更新本地Cache。总结 k8s已经为其承载的服务提供了一套服务发现，服务注册，以及服务集群管理机制。而dubbo-go的同时也拥有自成体系的服务集群管理。这两个功能点形成了冲突，在无法调谐两者的情况，dubbo-go团队决定保持dubbo自有的服务集群管理系，而选择性的放弃了Service功能，将元数据直接写入到Pod对象的Annotations中。 当然这只是dubbo-go在将k8s作为服务注册中心的方案之一，后续社区会以更加“云原生”的形式对接k8s，让我们拭目以待吧。 dubbo-go 社区钉钉群 :23331795 ,欢迎你的加入。 ...

在《我心中的云时代原生开发环境》这篇文章中，我们探讨过云厂商的愿景，云计算的趋势与现状以及研发团队的架构服务诉求等背景。今天，我想结合我们打造的云开发平台（Cloud Workbench）跟大家进一步聊聊，如何打造全云端研发的新基建，去服务好研发团队和用户。 云时代创新核心要素 首先，让我们快速将视野放大到社会商业爆炸式增长的云时代，无论是创业公司还是发展中的公司，都希望能有一个低成本、可持续支撑的架构服务，帮助自己的业务持续发展，用户流量从小到大，无需变更架构，更不用中断业务。 这种架构服务诉求背后的核心痛点体现在业务快速试错与流量快速增长之间的矛盾。如果从传统的架构方式去思考，这个问题很难调和：如果要快速奔跑，就没有时间好好思考设计架构；如果架构设计不好，就无法支撑未来巨大的流量；而如果花时间把架构设计好再动手，就没办法快速奔跑，很可能错过一个商业创新的时间窗口。另外，还有一个未知的疑问，这个设计好的架构真的够好么？ 结合我们之前的探索实践，我们知道，借助云原生 Serverless 的能力：实时弹性、按量付费，正好可以帮助我们把上述问题提升到一个新的维度去解决：业务完全可以放飞自我快速奔跑，架构服务由云原生Serverless矩阵来提供，保证流量再大也不怕。 中小研发生态现状 基于上述的一个判断，我们认为，现代商业社会的启动过程：从一个 idea 的诞生，到快速试错，再到上线服务用户的过程，有了一个很好的方案去支撑。但是，就像布道师们经常讲的一句话，人人都在谈云原生 Serverless，实际上并不是人人都知道怎么落地 Serverless。我们不妨来看几个真实的创业公司案例。 案例一，天猫精灵技能业务 天猫精灵的技能应用开发本身与天猫精灵开发者平台之前的连接较为松散，技能应用的开发对于一个中小开发者而言，启动成本较高。开发技能应用过程中的技术栈和方案也因人而异，因团队而异，也由于广大的开发者对技能应用背后的大流量没有一个一致的高水位保障，使得天猫精灵平台在做推广的时候也经常遇到阻力，担心在推广之后，很多技能无法承载大量涌入的活动流量，反而影响活动效果； 案例二，某直播互动健身创业公司 Y 公司是一家面对面直播互动健身的创业公司，研发团队的构成有 2 个前端、2 个后端、1 个架构师、1 个 iOS、1 个产品经理、1 个设计师，产品的构成有微信小程序、iOS APP、Android APP、PC 端 WEB 应用； 当前的核心痛点及诉求： 研发成本、架构人员的浪费；（这已经算是幸福的烦恼了，很多公司是找不到合格的架构师的）新人落地的成本（每个新人都有 3 个月的熟悉环境、流程、业务的成本）；自研自建业务架构的成本，要等业务架构确定后才能动手；业务线切换的沉默成本比较高，如新业务启动到上线：技术架构的选型、服务的复用等等都是损耗；运维成本，如：承接推活动来的高峰流量以及平时流量的平均成本；案例三，某软件外包服务商 O 公司是一家 base 杭州的软件外包服务商，他们的研发团队构成为：5 个 Java、4 个前端、1 个iOS、1 个Android、1 个产品经理、2 个测试、5 个商务、6 个品牌、2 个 UI 设计； 当前的核心痛点及诉求： 10人以下规模来什么做什么，没有沉淀，没有办法复用，没有高的盈利回报，人都铺在业务上，没时间学习架构，进入了一个恶性循环，需要一个很低的成本去采用一个先进的技术架构方案，确保不落伍，同时可以继续聚焦业务开发；有了可复用的空间（如架构、组件、服务）才有盈利的空间。10人以下的外包公司，CTO是不太可能去招的，40万一年的话，公司一半的利润就没了；想依托于云，不过每家云厂商都产品众多，围绕自己的业务怎么知道有哪些产品适合，要一个个去挑选、学习，整体成本太高；核心要解决的问题以及产品化思考 我们将上述调研的客户反馈诉求进行梳理，可以归纳出以下几点诉求： 人员、业务尽可能做到快速启动，低成本启动。开发人员能够快速进入业务开发，架构师能省就省，业务能够基于行业现有解决方案、基本业务架构、业务模块尽快启动； 开发人员的时间尽可能投入到业务开发中，但同时要保证业务所用技术架构的先进性：一个人的时间是恒定的，如何帮助中小企业把人员投入业务的时间从60%提高到99%，同时还能确保业务背后所用的技术栈及技术架构是行业内广受认可的； 线上业务能够做到按量付费：1、业务的流量高峰不会成为业务增长的瓶颈；2、类似于外包服务商/ISV，可以为他们的客户灵活制定弹性的服务体系； 基于以上三点，我们进一步抽象用户群体以及场景和服务策略： 主要用户群体 中小体量研发团队及创业公司研发团队； 要做开发生态的业务或平台； 行业软件/解决方案ISV/服务商； 场景和服务策略 1、在快速商业化试错的创新创业场景下，通过集成设计以阿里云 Serverless 产品线为矩阵的业务架构，帮助用户快速迭代业务，同时保证业务上线后无需变更架构就可以持续支撑不断增长的流量，确保业务不中断，提高试错效率，降低试错成本； 2、在研发人员需要支持多业务线切换调度的场景下，通过集成云效研发协同底座的能力构建在线研发团队，通过设计解决方案实例化的能力构建统一应用开发环境，降低开发者在业务切换中的沉默成本，让开发者可以快速且专注地进入业务逻辑的开发，提高研发效率； 3、在需要快速启动业务的场景下，通过构建三套业务环境，帮助用户实现环境在线，降低环境准备的时间成本与投入成本； 4、为研发团队提供一种将应用开发方法和结果抽象成标准的格式化的解决方案的能力，用该解决方案统一快速地教育开发者； ...

在全站上云的背景下，云计算已经不仅仅是大型互联网公司的独享概念，正在被更多的传统企业、中小企业甚至个人站长所采用。在众多云计算服务中，最常见两个产品就是云服务器和CDN，今天的CDN百科第三讲，就给大家介绍下你关心的问题：如果用了云服务器，还需不需要做CDN加速？ 先上结论：云服务器和CDN的业务场景不同，并不能彼此替代，同时，它们可以互相补充已达到提升效率的目的。 相对于传统服务器，云服务器以简单高效、安全可靠、处理能力可弹性伸缩的计算形态为用户提供服务，有助于降低用户的企业IT成本，提升运维效率。云计算发展至今，云服务器作为基础服务受到了众多企业和站长的欢迎，用于部署企业官网网站、资讯门户、电商应用、办公系统等等，承载数据。通常针对不同的业务场景，会有不同规格、价位、性能的云服务器可供选择。 CDN全称Content Delivery Network，即内容分发网络，它是指将源站内容分发至最接近用户的节点服务器，使用户可就近取得所需内容，提高用户访问的响应速度和成功率。解决因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、音乐、图片、文件、点播、直播、应用程序等内容的加速分发。 我们就拿618促销背后的物流体系来举例，服务器源站就相当于某品牌自己的货仓，而CDN就像分布于各地的仓储物流点。 现在很多品牌都会预先在各地仓储物流点，提前储备一些常用的商品（静态文件使用CDN进行缓存），当用户从电商平台下单购买货物的时候（用户发起请求），平台根据用户的收获地址就近匹配到最近的仓储物流点并直接进行派货（就近分发），让用户以最快的速度拿到快递包裹（分发的内容）。我们可以用实际的生活经验来做个对比，如果从江浙沪包邮区寄给杭州的用户，一般第二天就能到，如果是从北京、深圳发货，一般需要2-3天！ 这种方案还能避免所有订单都从单一货仓发货爆仓的风验，当就近的货仓物流比较繁忙时，则智能匹配其它就近的货仓进行分流，可以减少包裹全部由总仓（源站服务器）发货到各地的运输（带宽）成本。另外，采用共享的仓储物流点（CDN）模式也可以完美地根据销售需求来调整仓储规模和方案，避免自建货仓（多地云服务器）后在业务高峰后的资源闲置浪费。 所以，降低延时，提高稳定性，降低带宽成本，弹性灵活，都是使用CDN的好处。除此之外，CDN还可以： 第一，降低服务器带宽压力假如你的服务器同时支持1000人在线，那么当超过1000人访问的时候，你的网站就会出现访问瓶颈，延时、卡顿甚至宕机问题接踵而至。在使用CDN后，CDN可以将网站的静态内容缓存在边缘节点上，这样当用户访问静态资源时候就不用再请求回源服务器了，以此减少服务器的带宽峰值。 第二，保护源站服务器由于CDN的分布式架构，用户通过访问就近边缘节点获取内容，通过这样的跳板，有效地隐藏源站IP，从而分解源站的访问压力。当大规模恶意攻击来袭时，CDN也可以做为第一道防线进行防护，大大分散攻击强度，即使是针对动态内容的的恶意请求，CDN的智能调度系统还可以卸载源站服务器的压力，维护系统平稳。 相信看过这篇文章后，再有人问你：使用云服务器之后到底要不要再用CDN，你应该会有答案了吧。 往期回顾CDN百科第一讲，最近你的APP崩了吗？ CDN百科第二讲，假如没用CDN，网络世界会变成什么样？ 【CDN百科】专栏中，我们会不断科普CDN知识，解读CDN实践，分享CDN案例，如果你也关注CDN、使用CDN，请留言回复你关心的话题，如果被选中就有机会获得阿里云ET公仔一个，包邮哦！

在全站上云的背景下，云计算已经不仅仅是大型互联网公司的独享概念，正在被更多的传统企业、中小企业甚至个人站长所采用。在众多云计算服务中，最常见两个产品就是云服务器和CDN，今天的CDN百科第三讲，就给大家介绍下你关心的问题：如果用了云服务器，还需不需要做CDN加速？ 先上结论：云服务器和CDN的业务场景不同，并不能彼此替代，同时，它们可以互相补充已达到提升效率的目的。 相对于传统服务器，云服务器以简单高效、安全可靠、处理能力可弹性伸缩的计算形态为用户提供服务，有助于降低用户的企业IT成本，提升运维效率。云计算发展至今，云服务器作为基础服务受到了众多企业和站长的欢迎，用于部署企业官网网站、资讯门户、电商应用、办公系统等等，承载数据。通常针对不同的业务场景，会有不同规格、价位、性能的云服务器可供选择。 CDN全称Content Delivery Network，即内容分发网络，它是指将源站内容分发至最接近用户的节点服务器，使用户可就近取得所需内容，提高用户访问的响应速度和成功率。解决因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、音乐、图片、文件、点播、直播、应用程序等内容的加速分发。 我们就拿618促销背后的物流体系来举例，服务器源站就相当于某品牌自己的货仓，而CDN就像分布于各地的仓储物流点。 现在很多品牌都会预先在各地仓储物流点，提前储备一些常用的商品（静态文件使用CDN进行缓存），当用户从电商平台下单购买货物的时候（用户发起请求），平台根据用户的收获地址就近匹配到最近的仓储物流点并直接进行派货（就近分发），让用户以最快的速度拿到快递包裹（分发的内容）。我们可以用实际的生活经验来做个对比，如果从江浙沪包邮区寄给杭州的用户，一般第二天就能到，如果是从北京、深圳发货，一般需要2-3天！ 这种方案还能避免所有订单都从单一货仓发货爆仓的风验，当就近的货仓物流比较繁忙时，则智能匹配其它就近的货仓进行分流，可以减少包裹全部由总仓（源站服务器）发货到各地的运输（带宽）成本。另外，采用共享的仓储物流点（CDN）模式也可以完美地根据销售需求来调整仓储规模和方案，避免自建货仓（多地云服务器）后在业务高峰后的资源闲置浪费。 所以，降低延时，提高稳定性，降低带宽成本，弹性灵活，都是使用CDN的好处。除此之外，CDN还可以： 第一，降低服务器带宽压力假如你的服务器同时支持1000人在线，那么当超过1000人访问的时候，你的网站就会出现访问瓶颈，延时、卡顿甚至宕机问题接踵而至。在使用CDN后，CDN可以将网站的静态内容缓存在边缘节点上，这样当用户访问静态资源时候就不用再请求回源服务器了，以此减少服务器的带宽峰值。 第二，保护源站服务器由于CDN的分布式架构，用户通过访问就近边缘节点获取内容，通过这样的跳板，有效地隐藏源站IP，从而分解源站的访问压力。当大规模恶意攻击来袭时，CDN也可以做为第一道防线进行防护，大大分散攻击强度，即使是针对动态内容的的恶意请求，CDN的智能调度系统还可以卸载源站服务器的压力，维护系统平稳。 相信看过这篇文章后，再有人问你：使用云服务器之后到底要不要再用CDN，你应该会有答案了吧。 往期回顾CDN百科第一讲，最近你的APP崩了吗？ CDN百科第二讲，假如没用CDN，网络世界会变成什么样？ 【CDN百科】专栏中，我们会不断科普CDN知识，解读CDN实践，分享CDN案例，如果你也关注CDN、使用CDN，请留言回复你关心的话题，如果被选中就有机会获得阿里云ET公仔一个，包邮哦！

文 |《财经》记者 谢丽容 秋冬交替往往在一夜之间。这一年，受疫情的客观影响，数字化新旧时代的交替，从稳步推进，转变为一夜之间——数字化成为中国经济的主要驱动力，变革因为疫情而更加强烈，政府、企业都认识到数字化的迫切性。 6月9日，在2020阿里云峰会上，《财经》主编何刚对话阿里云智能总裁张建锋，张建锋认为，经此一“疫”，原本需要3到5年的数字化进程，将在未来1年之内加速完成。 在这次对话中，张建锋表达了两个核心观点。 其一，阿里云历经11年的坚定投入和发展，早已演进成一朵不一样的云，不仅提供了云代表的新型计算架构，更是诞生了钉钉这样的新型操作系统，两者深度绑定，形成一个整体，为政企提供面向数字经济时代的新型基础设施。 就像传统信息时代PC和Windows的组合一样，企业既需要云这样的新型计算结构，也需要钉钉这样的新型操作系统，这是一个整体，前者提供水电煤一样的算力基础设施，后者如同新时代的Windows，让企业可以面向大数据、面向智能、面向IoT、面向移动化，快速开发管理组织和业务的所有应用。 其二，做好这个基础设施需要强大的技术能力。他认为，阿里云在软件层面已经达到世界顶尖水平，飞天是中国唯一自研云操作系统，今年将持续加大在芯片、服务器、交换机、网络等领域的自研力度。 而“做深基础”背后逻辑并不是简单替换，是基于云的特点来构建整套基础体系，就像当年阿里巴巴“去IOE”并不是做一个新的小型机替代了旧的小型机，而是用阿里云这辆汽车超过了旧时代的马车。“做深基础”要将飞天云操作系统向下延伸定义硬件，构建数字经济时代的新型基础设施。 以下为对话全文： 经此一疫，数字化加速 何刚：这次新冠疫情的蔓延，对经济和社会带来了特别重大的影响，这些影响体现在哪些方面？ 张建锋：本来我们这次活动应该是在线下举办的，但今天我们用了相对特别的方法，也是因为疫情的影响。大家都是亲历者，但之前可能不会想到疫情会对我们造成这么大的冲击。从2月开始，中国的经济重心基本转移到抗疫上面。很多人在努力，医务工作者在前线抗疫，科技工作者在后台数字化抗疫。3、4月之后，数字化抗疫的重心从前期的“抗疫”转移到“重启”经济。到今天为止，我觉得数字化已经变成中国经济重要驱动力，包括政府、企业、学校，甚至广大的老百姓，真真切切地感受到了数字化带来的改变，线上的工作、生活，包括电子商务等，无接触经济蓬勃发展，这是疫情期间带来的巨大变化。 何刚：对于企业、社会、经济发展来讲，是否意味着一个全新重构的开始？ 张建锋：疫情并不是这个时代孤立的一件事，我们今天本来就处于数字化转型的阶段，疫情对数字化是起到了非常强的推动作用，数字化变革可能会因为疫情变得更强烈。 我之前经常琢磨，秋天是怎么变化到冬天的？是一天天的温度降下来的，还是一个突然的变化过程？后来我发现，绝大部分时候是一夜之间冷空气袭来，一场狂风冷雨，瞬间就会从秋天变成冬天，季节转换完成。 这次疫情对于数字化转型进程的影响，有这个味道。由于疫情，政府企业都认识到了数字化的迫切性和重要性，普通人也享受到了数字化转型带来的很多好处，包括居家办公，电子商务等，这些需求因疫情而加速。因为疫情，很多事情本来是需要三五年的发展过程，可能会在一年之内就完成转换。 何刚：阿里云是中国数字化进程的重要推动者和参与者，也是底层技术的构建者，全球范围内，中国的数字经济大概发展处于一个什么样的阶段？有什么跟别的国家相比不太一样的重要特征？ 张建锋：阿里巴巴本身是个数字经济的亲历者，也是一个推动者。阿里巴巴过去二十年的发展基本上伴随数字经济的发展到今天。从中国来讲，我认为是中国的数字化在全球是走在最前头。我们不管在消费领域、产业领域、政府治理、甚至农业都走在前面，我认为比大多数国家都走得要更完整。 从1999年开始，美国第一次提出政府要电子化，到现在都没有我们过去三年的数字化更深入。政府也好，治理也好，产业也好，大部分人都从数字化中得到了很好的收获，所以我觉得全社会今天对数字化要不要做、或者数字经济是不是未来，这已经达到了高度共识。 今天我们关注的重点是快速实现数字化的方式，这个行业能够根据数字化来重构自己的技术体系也好，业务体系也好，这是目前最关键的。 何刚：你提到两个词，一是全面无死角，从农业、工业、服务业包括政府、个人、社会组织；二是全速，谁能够更快速地实现数字化，谁有可能在未来获得更大的一种可能性。具体说说，从全面上云到全速重构区别是什么？ 张建锋：全面上云是一个技术性阶段，原来的基础设施从非云到云；全面重构是一个更强的深化，要重构，需要关注的面会更广，包括理念要升级，组织要升级，经营模式、运营模式要升级，而上云更多着眼于技术升级。 都要升级的话，要把原来传统的信息化手段变成数字化手段，它对管理者的思路、对于经营者的思路都是一个重塑的过程。我和我们的客户交流也是这样，我们做很多数字化的项目，我们是通过交付一个项目来帮助客户打造一支团队。因为它不是在信息化时代时简单地采购产品，帮你交付就完了；因为要用好这个产品要有一个新的理念，你要重建这个产品，要重构这个组织、重构这个业务，这个是当下未来可能是最最重要的，所以我们叫做全速重构。 何刚：由于疫情，有人提到了几个行业，发现它很繁荣，我不知道这些行业会不会率先如何来实现全面重构，比如公共卫生领域、教育领域、交通，也包括大家谈得很多的工业互联网领域。 张建锋：公共卫生领域，疫情影响因素特别明显，因为计算机系统处理问题都是类似的，第一，把数据收集上来；第二，做一些分析；第三，根据分析结果做一些结论。防疫抗疫的所有环节，我认为数字化都可以发生巨大价值。比如，政府针对密切接触人员人群做外呼提醒和通知。原来是传统的人工打电话，每个外呼员，一天的极限是200通电话；现在我们采用AI的办法，一分钟打3500个电话。对方有问题，用AI来给你回答问题，这是这样一个新型的数字化体系，这个体系以前从来没有出现过。 教育方面，因为之前大家不能返校，我们知道大学推了很多年的多媒体教育，渗透率和接受度没有那么高，疫情期间，我们跟浙江大学合作，只花了7天时间就改造了200多个教室，几万师生就通过远程教育一夜之间就实现了，当天有一百多万人次的访问量，最热门的课我听说有十万人次来观看。真的是一夜之间，以前几年做的事情现在一周就做完了，还有非常多的例子。疫情催化了需求，不过这个事情，我觉得没有疫情也必然会发生。 何刚：是不是可以理解为，疫情的发生确实是一件坏事，但也为重构提供了一些新的机会，当年非典催生电子商务业态，这次新冠是不是也会催生数字经济业态？ 张建锋：非典时我们做B2B贸易，所有的企业都不能出门推销自己的产品或者谈业务了，所以就转移到网上来了，一直发展到今天，其实也证明了零售业的这种形态比原来更高效，也是串联了大量的此前感觉和零售业没有太大关系的产业，诞生了新的行业，发挥了很大作用。我觉得像新冠之后，在线教育、在家办工、远程视频会议，它的一系列影响都是深远的。这一次刚好又在数字化转型的当下，我觉得要比那一次的SARS影响更深刻。 云钉一体：数字经济时代的PC+Windows 何刚：全速重构指的是什么，中间这一部分类似于当年操作系统？ 张建锋：很多人问云到底是什么？云的理解有很多种，它有宽泛的理解和狭义的理解，狭义的理解就是原来的服务器这些东西，用新的模式来替代了。我们今天在中国讲的云，意义要宽泛多得多，今天的云，既有云基座，也有中台，也有上面的服务。 至少从我们的角度来看，云是一个新型计算体系结构，它从原来的PC时代，包括原来大机、小机的时代，全面升级成云的形式。当然，云的特点是分布式，分布式还是互联网时代的技术。云在互联网分布式基础上更强调弹性，更强调大范围调度，复用，更强调安全性，这是云本身很重要的特点。你要怎么做好云，就要一整套的云系统，我们叫做飞天云的操作系统来管理这个东西。这也是国内唯一自研的产品。 前两年阿里在说要做中台，外面也有很多人在聊类中台概念。他们虽然不理解，总觉得这是一个好东西，所以现在但凡是一个企业都在讲中台，都在建自己的中台。 我的理解，中台是一个新型操作系统，因为我们原来做信息化系统相对来说比较简单，把业务流程理解清楚了，程序员把业务流程变成一个信息系统就可以了。今天面临一个非常大的变化，因为今天的信息系统不是一个简单的业务流问题，还有数据流，还要移动化，还要用人工智能的办法通过大数据来挖掘等，这些都是以前的信息系统没有遇到过的。 这需要新型的操作系统，我们原来叫中台，其实它是超越于原来的以windows为代表的处理系统，上面做简单的信息化的开发。从信息化到数字时代它需要一个新型的操作系统，大家面向大数据、面向智能、面向IoT、面向移动化，开发自己的应用变得更方便。 不同的行业有不同的特点，有人是零售的，有人是做工业的，它们可以在中台之上继续构建自己的系统。所以中台其实是一个云时代的、大数据时代的、智能化时代的、移动化时代的一个新型的操作系统。 何刚：我理解，一个是数据中台，基于数据的；第二是基于不同行业的，叫做业务中台。可能就是数据中台对于阿里来讲是更容易让大家来通过你们的这种计算能力和云处理的能力，来实现，而业务中台可能跟行业要有一定的结合。 张建锋：阿里巴巴也好，政府也好，很多单位也好，因为现在全社会的数据非常丰富，数据的汇聚也变得更容易。因为有新型的技术手段，分析数据有类似人工智能等更好的工具，所以现在的宏观预测可以基于微观分析来直接通过算法推导出来。 不像以前，政府也好，企业也好，要一层层汇总。今天的大数据趋势，都是大量的、微观的数据融合的做分析，所以迫切的需要一套新型的工具，是基于数据的、基于人工智能的、基于移动的，我们就认为这是一个新型的中台，新型的操作系统。 何刚：有点像你们在把PC时代英特尔和微软的事做了，是吗？ 张建锋：对，我觉得计算机的体系结构变了，上面的操作系统也变了，所以像阿里云+钉钉，就相当于以前的信息时代的PC+windows，类似于这样的一个概念。 我们相当于做了社会化的公共资源，我们一直认为，云是类似水电煤一样的公共服务，我觉得这个愿景越来越变成现实了，计算资源都公共服务化了，然后再提供一个新型的操作系统，让创新变得更容易发生了。 有很多行业今年发生了很大的变化。比如金融业。从今年开始，金融行业在积极拥抱新型的计算机体系结构，因为这是一整套从原来的PC时代、小型机时代到云时代一整套新的体系结构，这个体系结构不仅仅是技术变革，它还是一整套生态环境的重构，因为它的开发方式、理念都是一个新变化。 变化首先会发生在原来信息化做的比较好的那些行业，比如金融业、政府，他们的转型速度非常快。因为很多中小企业通用化的需求更高，不用搞广泛的定制，所以社会的公共服务也能基本满足他们的需求了。 阿里云现在有300万的客户，里面绝大部分是中小企业。对于那些中小企业来讲，这个相当于一个新型的淘宝，你原来要去做零售，要在线下开一个店，你要进货要去卖，要去做所有你不擅长的事情，例如开店租房本质上跟零售没有关系。现在中小企业在云的时代，它相当于在公共服务平台，像淘宝一样。 何刚：淘宝开店，很多事情淘宝来做。他只需要自己卖东西，发货收款。 张建锋：我觉得以后所有的行业都会齐头并进，因为它这里有现实的收益，也是一个新型创新平台。 何刚：提到疫情期间的应用，您提到远程期间的应用和教育，必须提一下钉钉，之前我用钉钉用得不是那么多，但是疫情期间审批、报销、开会各种东西，好像离了钉钉那天就没法干活了，能不能跟我分享一下，在疫情期间钉钉引发的现象级的应用，它究竟对钉钉意味着什么？ 张建锋：我觉得很多人把钉钉理解为一个沟通工具，钉钉是远远超越沟通本身的，我理解成为我刚才讲的操作系统的重要组成部分，它主要解决几个问题，它非常好地解决了移动化的问题。今天包括政府也好、企业也好，它所有的服务对象、参与对象已经发生了变化，基本上人人都有智能手机，你说政府要服务一个老百姓也好，老百姓是移动化的，可以7×24小时的通过手机接触政府的服务，那就看政府有没有提供这样的服务，通过什么样的方式来提供这样的服务。 何刚：比如说到政府部门办事情，原来要搞申请公证，原来在上班时间人得去，现在如果有手机，你们有一个政务钉钉。 张建锋：在几年前办事要找到哪个部门办事，需要找到特定的办公室去办；后来，像杭州等一些地方做办事大厅，只要到办事大厅去办就可以了；再后来，推一窗通办，把原来办事大厅中每个窗口办特定的事情，改成每个窗口可以办任何事情，这里就需要后台系统进行改造，因为要有这个能力去处理所有的事情。 再之后是移动化，手机上就可以办。手机上办带来一个新的问题，你要7×24小时可办，因为手机不用下班。 整个过程一步步发展到今天，离不开后面整个系统的改造，也离不开整个政务流程的再造，这里面数字化发挥了很大作用。钉钉在这里面扮演很重要的角色，它就是移动化，又是一个新型的，里面有通讯录，有各种各样的电子流审批，它给他们要做移动化开发提供了非常好的应用。浙江省上面有一千多个应用基于钉钉这个平台开发的，这就是操作系统的典型特征，操作系统就是我自己做掉一部分事情，大家都可以在上面做更多的事情。钉钉就是一个新型的操作系统，也是我们操作系统的重要组成部分，这就是我们这边的定位。 何刚：现在在有些地方政府信息化做得比较好的，开始大量运用政务钉钉做行政管理。我们按照这样的思路，是不是未来还有各种钉钉，金融钉钉、零售钉钉、教育钉钉、医疗钉钉，会是这样的吗？有这样的规划吗？ 张建锋：我觉得钉钉本身是一个平台，大企业可能对于自己的定制化要求非常高，所以推出了企业版。我们跟税务做了一个学习新税平台，原来有几十万的税务干部是垂管干部，税务干部要去学习、考核，要进行政策的传递，以前是一层层的，今天有这样的平台之后整个系统就管理起来了。 这样的话，对组织原来的运作模式就产生了非常深远的影响。比如说，教育系统也在用钉钉，原来教育局和学校、学校和老师、老师和家长、家长和学生，它是多方的主体，有个消息要从教育局通知到学生，之前的做法是一层一层通知下来。今天用钉钉这个平台，因为所有人在这个上面，可以非常容易地形成一个环路。我作为学生家长，在疫情期间，我也收到教育局在家学习的调查问卷，你小孩子学得怎么样？学科重不重？ 原来教育局要了解学生的情况是非常难的，现在电子化，第一可以触达我，第二可以实时地知道，因为这个问卷上去的话我们很快就分析出来了。对各行各业都有很大的影响。今天我们数字化过程中就看你的业务跟数字化怎么结合，你怎么用好这样新型的一些工具跟手段，这个我觉得是最最重要的。 钉钉我觉得它本身是个操作系统，本身是个新的平台，就看大家怎么样来用好这个平台。 何刚：其实按你刚才这样一解释，我听了钉钉能做的事太多了，大家原来做一个联络工具，做一个简单的办公流程的东西，是大大低估了它潜在的对于人、信息和业务的这种连接能力。 张建锋：这就是我们刚才那个话题，就像windows和英特尔一样，他们是深度绑定成一个整体，对于消费者和用户来说它是个整体。云就是我们刚才讲的，替代了前一代的信息时代的基础架构，今天的云是未来面向数字经济时代的新型的体系结构，这个结构中，云是承担了这样一个职能。但对于很多行业来讲，他希望上面还有一个更容易去开发自己应用的平台，因为他要解决移动化的问题，要解决很多政府要审批流程、安全等等问题，所以它需要一个新的平台，钉钉是这个平台非常非常重要的组成部分。我们讲很多企业“云钉一体”，因为它基于这个体系可以开发出它面向未来的数字化的新的系统。 何刚：阿里云+ 钉钉就是云钉一体，数字经济时代新的windows+英特尔。 张建锋：数字经济时代我觉得最大的特点就是云+新型的操作系统。 何刚：就是你们的云钉一体。现在能给我们一个数字吗，钉钉可以公开的用户有多少，企业组织有多少？ 张建锋：钉钉现在上面有1500万的组织，用户超过3亿，3亿用户用钉钉在工作、在学习，我觉得跟其他的工具非常不一样的。 何刚：所以我想它可能对于我们的大型企业显然很有用，它的连接能力，对于中小型企业，钉钉价值又在什么地方？ 张建锋：大企业因为连接比较复杂，需要一个新型手段，中小企业是整体式的管理，我看到很多餐饮企业只有几十个人，所有工作，所有事情都通过钉钉在连接。因为原来可能要买很多的垂直化的应用，比如说他要做考勤，比如说他要做财务，比如说他要做人事，今天他都不需要这些东西了，钉钉就可以搞定，钉钉本身又是一个新型平台，很多人基于钉钉开发了通用的应用，甚至不用自己开发，把那些应用组合起来就可以了，这就大大降低了信息化、数字化的门槛。 做深基础，做厚中台，做强生态 何刚：阿里云在整个数字时代一个新的使命，就是构建数字经济的基础设施，如果具体来看的话，怎么理解数字经济的基础设施，包括哪些关键的支撑？钉钉在这次的现象级的应用增长当中，一开始曾经出现了拥塞，但是阿里云很快用强大的能力把它解决了，跑得很顺畅，3亿人能也能顺畅地跑，数字经济的基础设施是不是也可以支撑我们所说全速重构的这样快速的需求？需要做哪些关键支撑？ 张建锋：我们去年提出做数字经济时代的基础设施，我们是一个公共的服务资源，这是我们做云计算一个非常强的两个特点。 刚才我们讲了，我们把云定义成一个新型计算体系，这是我们云来实现的；第二个我们要构建一个中台，做一个新型的操作系统，上面呈现各种各样行业的应用，这个前提下我们提出来自己是要做深基础，我们要把云的底座给做深，怎么做深呢？我们除了要做云的操作系统之外，我们有个飞天操作系统，要做调度等。我们还要做芯片、数据库，做路由器、交换机等，基于云的特点来构建整套的基础体系。 何刚：芯片就是去年一直在发布的AI智能芯片？ 张建锋：AI，我们可能有更多的芯片，像我们做虚拟化等有很多芯片，而且现在安全很重要，我们也有自己的一些安全的芯片等。 何刚：所以第一个叫做深基础，第二是？ 张建锋：第二是要“做厚中台”，中台作为一个新型的操作系统，要提供更多的功能，我们上面的应用才能更容易来开发，这些功能，包括AI的功能，大数据的处理，IOT的能力，移动的能力。这里面我们想把中台做得越厚，这个操作系统的功能就越强大。 还有第三，我们要做大做强生态。 最终不是阿里云来做所有事情的，我们是一个开放的体系，我们是希望软件开发上，基于云的结构、基于一个新型的操作系统，来帮助各行各业做一些应用的开发，所以我们提出“做深基础”、“做厚中台”、“做强生态”。这是我们作为数字经济时代基础的一个主要的出发点，也是一个落脚点。 何刚：今年4月20号的时候，你提出来阿里云未来要花一笔大钱，3年要花2000亿，当时把这个行业都震撼了，说有时候没钱是个事，钱多了怎么花也是一个问题。当时提到3年2000亿，要做新技术、新基建，帮助全社会做这种数字化的升级转型，为什么提出这么一个宏大的投资计划？具体会花在哪些方向？ 张建锋：这个投资看上去很大，但是对于全社会的数字经济的新基建来讲，其实并不大。我们现在整个阿里云管理有超过100多万台服务器，我们预计在3年之后就会超过300万台服务器，300万台服务器本身的投资就是个非常巨大的投资。 还要去建新型的网络、大规模IDC等等的建设，我们还要投入一些新产品的研发，像芯片之类的研发投入都是非常大的。所以看起来2000亿好像很多，3年之内可能还不够，除了这些投资之外，我们还会更多的投资在人才上。我们今年人才还继续招聘，会招聘超过5000个工程师加入阿里云。 何刚：如果我们再仔细地想一下阿里一家投了2000亿，整个社会关于数字经济的基础设施投资在你看来，比如未来3—5年，大概会是一个什么量级的规模，企业和政府分别在里面大概能够扮演什么角色？ 张建锋：这个投入可能会非常大。阿里巴巴比较集中在云计算的基础设施，还有5G也是非常大的投资，工业互联网可能是大头，我认为比消费互联网规模更大，而且对企业的影响应该也会更深远，工业互联网里有非常多行业，跟其他行业可能都不一样，这一块可能也是一个非常大的投入。 可能几万亿的投入是必须要做到的，因为没有这个投入就没有新型的基础设施，也谈不上数字经济。我们也看了2019年发的报告，2018年中国跟数字经济相关的GDP已经占到了34万亿，占中国整个GDP的三分之一，我觉得这个可能会进一步提高比例。所以说是非常大的量。 何刚：所以从整个未来趋势展望来看的话，我们看到无论是数字经济的基础设施，还是数字经济的这种应用，应该是一个非常令人激动美好的前景。 张建锋：我觉得数字化云化这是一个确定性会发生的事情，中国在这方面是走在世界的前头的。我们也有信心真正做好数字经济时代的基础设施。 推荐阅读 ...