阿里云

年度开发者调查报告，能够帮忙咱们加深了解行业的发展趋势，对集体职业倒退方向、企业技术选型都具备肯定的参考作用。 近日，CSDN  公布《2021-2022 中国开发者调查报告》，咱们对其中微服务畛域的调研内容做一些摘录和剖析。 云原生成为驱动业务增长的重要引擎，微服务架构最受欢迎考察显示，云原生逐步在人工智能、大数据、边缘计算、5G 等新兴畛域锋芒毕露。在对云原生感兴趣的群体中，仅有 7% 的开发者能深度了解且深刻利用云原生的技术，70% 的开发者示意齐全不懂或 仅理解一些概念。  图 1：开发者对云原生的理解水平 40% 的开发者关注微服务架构，而后顺次是 API 治理、分布式数据库、DevOps、容器调度平台、服务可观测性、服务编排和服务治理、混沌工程和流式计算。 图 2：开发者涉足云原生畛域排行 微服务化是云原生革新的首个阶段，高频公布成支流有 38% 的公司曾经实现了微服务化/容器化革新，10% 的公司实现了容器化，10% 的公司实现了服务化，可见微服务是云原生革新的首先要落地的事件。 图 3：云原生革新过程散布 应用云原生的部署形式，可能很不便地进行服务公布，44% 的公司曾经可能实现不定时公布，8% 的公司每天会公布很屡次，这意味着一半以上的企业都在通过高频公布来减速企业竞争力，其落地的难题逐渐从如何建好微服务延长到如何用好微服务，例如无损高低线、全链路灰度这些微服务治理能力将能够大幅缩小版本公布过程的危险、进步公布效率。 图 4：利用公布频率散布 企业云原生投入加大，价值与挑战共显云原生已倒退为驱动业务增长的重要引擎，其对于企业的重要性越来越高，各公司也在云原生的建设上加大投入，18% 的公司在云原生上的费用占整个公司 IT 投入比例的  30% 以上。 图 5：企业 IT 投入中用于云原生的费用占比 随着云原生技术的演进和市场的疾速倒退，云原生的价值逐步浮现，成为开发者们偏好应用云原生的起因。43% 的开发者示意，云原生可能进步开发效率。除此之外，晋升业务的麻利度也是吸引开发者的重要起因。 图 6：应用云原生的次要目标 与 2020-2021 年度相比，企业对云原生利用的规模也显著晋升。通过数据比照显示，集群部署节点规模在 50 个以下的占比从 59% 升高至 33%，节点规模在 51-500 个的占比从 29% 攀升至 47%，节点规模在 1000 个以上的占比从 12% 晋升至 20%。 ...

Dubbo 3 是 Dubbo 新的里程碑，Dubbo 的生态组件（包含 Dubbo Java SDK，Dubbo Golang SDK 等）都在向 Dubbo 3 的指标聚拢，在用户实际方面，包含阿里巴巴、淘宝、天猫、饿了么、工商银行、安全衰弱等企业都已胜利降级 Dubbo 3 版本，随着更多的企业和用户关注或降级 Dubbo 3，整个社区对 Dubbo 3 的文档的需要开始变得更加迫切，以帮忙用户正确应用 Dubbo 3 性能或晓得如何排查遇到的问题。 为了晋升 Dubbo 3 文档的品质，Dubbo 社区在 6 月份中旬的时候收回了《Dubbo 3 官网文档贡献者召集令》。这两个月以来，Dubbo 官网收到了近 250 个 Commit，正是因为有了社区各位搭档的踊跃奉献，Dubbo 官网文档的构造和内容有了许许多多的扭转。 apache/dubbo-website 提交活跃度 本次体验优化聚焦的关注点1. 文档全面对齐最新 Dubbo 3 版本Dubbo 3 作为 Dubbo 的一个里程碑版本，做了泛滥的优化和架构调整。在本次文档优化中，咱们重点关注了这部分的文档问题，补充欠缺了 Dubbo 架构调整的内容、全新的利用级服务发现模型和 Triple 协定等的阐明应用文档。另外咱们也对一些疾速开始用例和已有性能的文档做了肯定的优化调整，来对齐 Dubbo 3 版本。 2. 文档架构优化，抽离出面向老手的入门文档本次体验优化的过程中，咱们把原有的文档拆分为入门文档和 SDK 文档两个局部。面向 Dubbo 的入门用户，在入门文档模块能够疾速理解什么是 Dubbo、Dubbo 3 的新个性、疾速开始应用 Dubbo、基于场景示例的实际等。和入门文档模块与之对应的是 SDK 手册，SDK 手册中寄存了各个 SDK、工具的文档，包含了 Java SDK、Golang SDK、Dubbo Go Pixiu 等，面向想要深刻理解各个 SDK 的用户。 ...

作者： 谱一段风华笔墨 什么是函数计算阿里云函数计算 FC 是事件驱动的全托管计算服务。应用函数计算，您无需洽购与治理服务器等基础设施，只需编写并上传代码。函数计算为您筹备好计算资源，弹性地牢靠地运行工作，并提供日志查问、性能监控和报警等性能，借助函数计算，您能够疾速构建任何类型的利用和服务，并且只需为工作理论耗费的资源付费。 开发步骤开明函数计算开明前须要您已注册阿里云账号并实现实名认证，进入函数计算官网函数计算： https://fcnext.console.aliyun... 如果您还未开明函数计算，需在函数计算开明页面勾选函数计算服务协定之后点击 “立刻开明”，开明实现后会主动跳转至函数计算控制台。 新建服务在函数计算控制台点击 “服务及函数” 进入服务列表，在服务列表点击创立服务，填写服务的配置，点击 “确认” 即可创立服务。 （注：开启日志和链路追踪性能能够更不便的进行代码调试、故障剖析、数据分析和查看函数外部工夫的耗费等；举荐开启，但可能会收取局部费用)。 新建函数在服务列表下点击创立的服务名称进入函数治理页面，点击 “创立函数”，在创立函数页面抉择 “应用自定义运行时创立” 填写函数的相干配置，在运行环境中抉择 Java 17 的示例模版函数。 配置实现后页面下拉至底部点击 “创立” 即可部署一个 springboot 我的项目。 \ 自定义域名配置函数创立实现后间接在浏览器中间接关上申请地址，将会以附件的形式下载响应。 这是因为 Http 触发器会主动在响应头中增加 Content-Disposition: attachment 字段，咱们能够应用自定义域名防止该问题。 进入域名治理页面点击增加自定义域名，在路由配置中抉择本人创立的服务和函数，配置实现后，就能够在浏览器中输出配置的域名，能够看到页面显示的 Hello World! 内容。 到此一个简略的 springboot 我的项目就部署配置实现了。 开发导出代码持续进行我的项目开发，咱们能够在函数计算控制台，进入到该函数的详情页面，在函数代码页应用在线 IDE 进行开发和调试，也能够在 “导出函数” 这里导出函数的代码，应用本人的代码编辑器进行开发。 代码构造 pom.xml： <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.6.6</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.example</groupId> <artifactId>demo</artifactId> <version>0.0.1-SNAPSHOT</version> <name>demo</name> <description>Demo project for Spring Boot</description> <properties> <java.version>17</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build></project>DemoApplication： ...

阿里云飞天技术峰会于 8 月 11 日在深圳举办，峰会以“聚焦核心技术，激活企业内生能源”为主题，邀请泛滥高新技术领军企业，围绕“企业如何在新一代云计算体系架构之上激活业务、技术、产品的内生能源”这一外围话题开展探讨，共商后疫情时代企业增长的破局之道。 主论坛上，阿里云提出云原生激活利用构建三大范式：全面容器化、核心技术互联网化、利用 Serverless 化， 并公布最新的产品与解决方案。基于分布式云容器平台 ACK One，实现多地区分布式系统统一治理；公布 ACK FinOps 解决方案，让企业实现数字化老本治理，云原生老本优化。同时在峰会现场发表，音讯队列 RocketMQ5.0 全面商业化，以更优的老本、超大规模弹性、轻量易集成、全链路可观测的劣势，助力企业构建稳固的音讯零碎。 阿里云智能云原生利用平台总经理丁宇主论坛演讲 下午【云原生减速利用构建】分论坛，聚焦：FinOps、可观测与SRE、云原生 AI、Serverless、云原生技术中台等热点话题展开讨论。目前峰会分论坛材料已凋谢下载，关注阿里云云原生公众号，后盾回复关键词“飞天云原生”获取下载链接。 点击此处，下载峰会 PPT 材料。

作者：牛通(奇卫) 日志，对于一个程序的重要水平显而易见。无论是作为排查问题的伎俩，记录要害节点信息，或者是预警，配置监控大盘等等，都扮演着至关重要的角色。是每一类，甚至每一个应用程序都须要记录和查看的重要内容。而在云原生时代，日志采集无论是在采集计划，还是在采集架构上，都会和传统的日志采集有一些差别。咱们汇总了一下在日志的采集过程中，常常会遇到一些理论的通用问题，例如： 部署在 K8s 的利用，磁盘大小会远远低于物理机，无奈把所有日志长期存储，又有查问历史数据的诉求日志数据十分要害，不容许失落，即便是在利用重启实例重建后心愿对日志做一些关键字等信息的报警，以及监控大盘权限管控十分严格，不能应用或者查问例如 SLS 等日志零碎，须要导入到本人的日志采集零碎JAVA，PHP 等利用的异样堆栈会产生换行，把堆栈异样打印成多行，如何汇总查看呢？ 那么在理论生产环境中，用户是如何应用日志性能采集的呢？而面对不同的业务场景，不同的业务诉求时，采纳哪种采集计划更佳呢？Serverless 利用引擎 SAE（Serverless App Engine）作为一个全托管、免运维、高弹性的通用 PaaS 平台，提供了 SLS 采集、挂载 NAS 采集、Kafka 采集等多种采集形式，供用户在不同的场景下应用。本文将着重介绍各种日志采集形式的特点，最佳应用场景，帮忙大家来设计适合的采集架构，并躲避一些常见的问题。 SAE 的日志采集形式SLS 采集架构SLS 采集日志是 SAE 举荐的日志采集计划。一站式提供数据采集、加工、查问与剖析、可视化、告警、生产与投递等能力。 SAE 内置集成了 SLS 的采集，能够很不便的将业务日志，容器规范输入采集到 SLS 。SAE 集成 SLS 的架构图如下图所示： SAE 会在 pod 中，挂载一个 logtail （SLS 的采集器）的 Sidecar。而后将客户配置的，须要采集的文件或者门路，用 volume 的模式，给业务 Container 和 logtail Sidecar 共享。这也是 SAE 日志采集不能配置/home/admin 的起因。因为服务的启动容器是放在/home/admin 中，挂载 volume 会笼罩掉启动容器。同时 logtail 的数据上报，是通过 SLS 内网地址去上报，因而无需开明外网。SLS 的 Sidecar 采集，为了不影响业务 Container 的运行，会设置资源的限度，例如 CPU 限度在 0.25C ，内存限度在 100M。 SLS 适宜大部分的业务场景，并且反对配置告警和监控图。绝大多数适宜间接抉择 SLS 就能够了。 ...

作者：溪洋、徐佳航 云原生的技术价值喻示着它就是将来，退出到一个具备可延续性生命力的开源社区，能够帮忙咱们更快地达到那里。 *——徐佳航，KubeVela Maintainer，来自招商银行基础设施研发核心云平台及运维平台开发团队。 来自招商银行基础设施研发核心的徐佳航是 KubeVela 开源社区的一位新晋 Maintainer，目前在云平台及运维平台开发团队，从事企业级云原生利用管理体系的建设。 据徐佳航同学介绍，当初他所在的团队中有 15 位成员都在参加 KubeVela 社区的奉献。在他成为 Maintainer 前，曾经有另外三位同学升级为 Reviewer。 对 KubeVela 有些理解的敌人都晓得，KubeVela 的实质是一个现代化的软件交付平台，由阿里云云原生团队发动开源，目前是 CNCF Sandbox 我的项目。它能够让你的利用交付在当今风行的混合、多云环境中变得更加简略、高效、牢靠。KubeVela 部署工作流的背地就是凋谢利用模型 OAM ，帮忙开发者一次编排、随处运行。在云原生畛域，KubeVela 是最近两年体现最抢眼的开源我的项目之一。 然而，仅有 2 年多倒退工夫的 KubeVela，不得不说还很年老。像招商银行这样处于金融行业的企业，对于业务架构的稳定性、可靠性要求非常严苛，对技术的选型和落地也很审慎。投入这么多力量在 KubeVela 上，他们的需要和考量是什么？对于开源技术的态度是怎么的？KubeVela 在招商银行的云原生化过程中又施展了怎么样的作用呢？ 在最近和徐佳航同学的一次对话中，他答复了咱们这些“好奇”。 “我眼中利用治理正在经验的变动”往年是徐佳航从事 IT 研发工作的第 13 个年头，退出招行前次要在数据通信畛域负责产品研发，其间做过无线通信协定，也做过做嵌入式汽车无线互联，还有过一段 3 年多的云存储畛域守业教训。 技术深度和教训的积攒，使他对将来 技术倒退的走向建设了本人的“预测模型”。最近几年，他开始对云原生技术放弃着亲密的关注，比方云原生利用 DevOps、可观测性、分布式文件系统、API 网关等，特地是对根底软件层的开源技术很感兴趣。因为他察看到在基础设施云化后，利用研发和运维的工作须要解决一些新的挑战，比方： 基础设施云化后，利用研发、运维接触到的运行时越来越多样。如果不进行关注点的拆散， 新的环境下带给利用开发和运维角色的认知和把握老本都较高；利用微服务化水平加深，架构高度分布式，使部署和运维工作更为简单； 在 IT 零碎日益简单的背景下，为了保障利用和业务继续稳固，基于日志、链路、指标的利用可观测性渐成刚需。 如果去看 CNCF 全景图、 社区 Group 以及 Github 中疾速倒退的我的项目，也可能发现以上三点也是社区和业界在重点发力和沉闷实际的方向。 （图片来自 CNCF Landscape:https://landscape.cncf.io/）\ 除此之外，身处金融行业，也让他对利用研发和运维的变动有着更强的体感 ：“在金融行业, 做好利用治理挑战不小。比方，基础设施和利用运行时的简单多样性更加突出，像 mainframe, bare mental, hypervisor, container, faas 都可能同时存在；同时，对于业务的连续性、 可用性、 安全性要求更高，因而对利用的可观测性(SLO)诉求强烈。” ...

作者：宇汇 ACK One 概述ACK One 是阿里云面向混合云、多集群、分布式计算等场景推出的分布式云容器平台，可能对立治理阿里云上、边缘、部署在客户数据中心以及其余云上的 Kubernetes 集群，并简化集群治理界面，让企业轻松应答多集群状态，从而灵便地依据本身业务和数据管控等需要，同时使部署在客户数据中心的集群也能获取云上弹性算力，实现“计算无界”。 三大重磅个性，笼罩三大场景，引领多集群治理新高度多集群服务 -- 跨集群服务发现与拜访概述应用 Kubernetes 原生的 Service，能够不便地在集群内发现和拜访 Service，但无奈实现跨集群的 Service 发现与拜访。随着业务的倒退，利用往往须要多集群部署，实现隔离性，高可用性，例如：多个开发生产集群，不同业务不同集群，不同组织保护的集群，以解决可用性和数据所有权要求，灵便分账等需要。同时，不同业务利用间须要互相拜访，因而须要一个跨集群 Service 计划，应答多集群带来的挑战。 ACK One 多集群治理公布新个性多集群服务，通过多集群服务实现 Kubernetes 原生 Service 的跨集群拜访，突破了多集群服务拜访的边界。 场景一：跨集群服务发现与拜访 ACK One 多集群服务反对 Kubernetes 社区多集群服务 API 规范，通过 ServiceExport、ServiceImport 对象实现跨集群的服务发现与拜访。 如图中链路 0 所示：管理员通过主控实例下发利用、多集群服务 ServiceExport、ServiceImport、散发规定等资源。如图中链路 1 所示：主控实例将利用和多集群服务资源，依据散发规定下发到关联集群中。a.通过向 ACK Cluster 1 下发 ServiceExport 资源，定义 ACK Cluster 1 为服务提供者。 b.通过向 ACK Cluster 2 下发 ServiceImport 资源，定义 ACK Cluster 2 为服务消费者。  如图中链路 2 所示：ACK Cluster 2 上的 Client Pod 能够拜访 ACK Cluster 1 上的 Service 1。场景二：多集群服务高可用 ...

点击此处即可查看容器服务 ACK 产品详情！

最近，阿里云容器镜像服务 ACR 开发者评测流动正在炽热发展中。阿里云容器镜像服务 ACR（Alibaba Cloud Container Registry）是面向容器镜像、Helm Chart 等合乎 OCI 规范的云原生制品平安托管及高效散发平台。产品分为个人版和企业版，个人版面向容器开发者限额收费应用。 为了帮忙更多开发者理解容器镜像服务 ACR 的性能、应用形式和产品体验，阿里云容器镜像 ACR 面向宽广开发者招募产品测评团，公布对于 ACR 的原创测评内容。流动正式开展仅一周的工夫，已有数十位开发者公布他们对于 ACR 的应用体验。 在各位开发者看来，阿里云 ACR 与其余的镜像仓库有哪些不同之处呢？咱们截取了几位开发者分享的观点，不晓得和你的感触一样吗？ “与其余镜像仓库比照，ACR 提供弱小的 Devops 构建能力”测评员 ID：理想国余烬容器的应用离不开镜像。以 Docker 为代表的容器技术，能够将利用打包成规范格局的镜像，并且利用会以容器的形式再度启用运行。 在真正的生产环境中，你会须要大量的镜像，第三方或者是自建的；大量镜像随同而来的是须要保留、散发应用等管控工作。 阿里云容器镜像服务提供了平安的镜像托管能力，无需你本人搭建运维的工夫人力老本，不便进行镜像的全生命周期治理，为容器改革的浪潮提供稳固的技术根底。 ACR 镜像仓库的特色次要包含： 寰球部署：超过 20 个地区，地区内下载限额收费高效镜像构建：主动代码构建、反对多阶段构建DevOps 反对：丰盛触发器规定，无缝部署利用平安合规：反对平安扫描，阿里云认证和云市场售卖 我应用过很多镜像仓库，从多方面的具体比照来看，支流的 Harbor 和 Quay 的绝大部分性能都是重叠的。Harbor 的多仓库治理以及镜像同步性能，始终作为 Harbor 十分大的亮点，并且有很大的实用价值。至于 Quay 有而 Harbor 没有的 SCM 集成的能力，并不能为 Quay 造成多大劣势。因为绝大部分企业曾经有根本的 CI，而 Quay 提供的构建能力太简略，不足以替换现有的 CI。 Quay 绝对于 Harbor 并没有显著劣势，然而存在作为新开源我的项目两个不可避免的劣势：用户积攒，开源社区。Harbor 曾经积攒了宽泛的用户，各方面都失去充沛地测验，加上 CNCF 的背书，会使其用户群体进一步疾速扩充。在这种状况下，Quay 是很难跟 Harbor 抢用户的。Harbor 的外围贡献者尽管仍是 VMWare，然而通过这么多年的积攒，曾经造成了绝对欠缺的社区，这对一个开源我的项目的疾速倒退也是至关重要的。因而，Quay 的开源并不能撼动 Harbor 的位置。 ...

作者： EdgeX Foundry 2022 EdgeX 中国挑战赛暨中关村国内前沿科技翻新大赛 EdgeX 专题赛正式拉开帷幕。本次大赛分设两大赛道：医疗、教育、生产行业赛道和能源、工业、供应链赛道。大赛致力于构建一个物联网及边缘计算的学习和分享平台，基于 EdgeX Foundry、OpenYurt 等开源技术，针对不同赛道的多个利用场景，以共享技术投资解决行业技术问题。 为帮忙参赛选手更好地理解并使用相干技术，本次大赛将在 7 月至 9 月继续发展 3 轮技术培训，涵盖初、中、高不同层级，帮忙开发者零碎学习智能边缘系统常识。咱们邀请到来自英特尔、VMware、阿里云等多家机构的技术专家进行分享。 边缘计算与边缘云原生首先，熊峰专家为咱们解说了边缘计算与边缘云原生的具体定义。 边缘计算（Edge Computing）： 是一种将工作负载部署在边缘的计算形式；是一种分散式运算架构，在凑近物、数据源或用户的中央进行利用计算与数据存储；外围指标：疾速决策；四大驱动力：提早/确定性，数据/带宽，无限的自治权，隐衷/安全性；目前次要使用于汽车、农业、交通、医疗保健等行业。 图注：物联网与边缘计算 边缘计算依据对提早的敏感度有两种定义的分层架构：Gartner 定义和 IDC 定义。 图注：Gartner 定义下的边缘计算分层架构 在 Gartner 定义中，边缘计算按提早敏感度分层为： Near Edge：非标准服务器或设施，在间隔端侧最近的中央；Far Edge：规范的 IDC，能够分三种类型：IDC、MEC、CDN 等；Cloud：公共云或专有云服务，特色为资源集中、中心化治理。 图注：IDC 定义下的边缘计算分层架构 在 IDC 定义中，边缘计算按提早敏感度分层为： Heavy Edge：数据中心维度；集中式计算平台（CDN，自建 IDC）；Light Edge：低功耗计算平台，实用于工业管制，数据处理、传输等物联网场景。 图注：2015 年至 2024 年（预测）私有与非公有云服务市场规模 目前，云原生用凋谢、规范 的技术体系，麻利的构建和运行高弹性、容错性好、易于治理的零碎，帮忙企业最大化利用云的能力，最大化施展云的价值。云原生重构企业上云形式，企业上云成为常态。 图注：云、边、端一体的边缘云原生架构 云原生减速了多云、云边交融，构建出云、边、端一体的边缘云原生架构。其中，边缘计算云边一体化基础设施因为具备以下特点被宽泛使用： 在边缘基础设施上提供和云上统一的性能和体验；云边运维协同、算力混编、网络协同等；云边的 DevOps 协同，业务疾速边缘拓展；设施孪生，实现云边端的业务交融。OpenYurt 云原生边缘计算平台架构熊峰专家还为咱们介绍了 OpenYurt 云原生边缘计算平台架构。 OpenYurt 是 CNCF 沙箱我的项目，提供云端管控、边缘自治的云边协同计算能力。通过与社区摸索云原生物模型标准化，可扩大反对 EdgeX，LinkEdge 等物联网框架，反对多种物联网协定，实现设施孪生能力。 ...

作者： 十眠、洵沐 背景微服务体系架构中，服务之间的依赖关系盘根错节，有时某个性能发版依赖多个服务同时降级上线。咱们心愿能够对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。在公布过程中，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图： 上图能够很好展现这种计划的成果，咱们用不同的色彩来示意不同版本的灰度流量，能够看出无论是微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境，这种计划不仅能够节俭大量的机器老本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。 全链路灰度能力晋升了微服务架构带来的疾速迭代、稳定性验证的劣势，给企业生产环境的零碎带来了真真切切的益处。本文将着重介绍 MSE 服务治理基于全链路灰度能力的利用场景与痛点延长进去了新的能力。 全链路之运行时白屏化能力在咱们生产环境应用全链路灰度的过程中，咱们经常会遇到一些问题。 咱们配置全链路灰度的流量流向是否合乎预期，咱们的流量是否依照咱们配置的灰度规定进行匹配。咱们灰度的流量呈现了大量的慢调用、异样，我该如何确定是咱们新版本代码的业务问题还是因为咱们在流量灰度过程中思考不全导致的零碎问题，如何疾速定位问题，从而实现高效的迭代。在咱们设计灰度零碎的过程中，咱们须要思考如何对咱们的灰度流量进行打标，有些时候在入口利用、微服务接口出可能难以找到适合的流量特色（参数、headers 等携带的具备业务语义的标识），在这样的场景下咱们如何快捷地对咱们的流量进行打标。 基于以上一些列的问题，也是咱们在反对云上客户落地全链路灰度的过程中一直碰到的问题。运行时白屏化能力也就是咱们在这个过程中形象设计进去的一个能力。 运行时白屏化的目标是为了帮忙咱们洞察全链路灰度的流量匹配以及运行的行为。 咱们基于流量路由的规定将运行时白屏化规定形象为如下： WhiteScreenRule = Taget + Action** Target： ResourceTarget: 指标接口，反对Web、Rpc 以及自定义办法 WorkloadTarget: 指标实例，能够抉择所有机器或指定机器 IP TrafficCondition: 是否仅针对异样、慢调用、全链路灰度标签 Action： 相干上下文诊断信息的收集后续链路进行流量染色后续链路是否日志打印  上面咱们来具体看一下如何使用运行时白屏化能力解决咱们在全链路灰度过程中遇到的问题。 灰度流量的匹配以及流向是否合乎预期 针对如上场景咱们只需配置 Zuul 利用入口的白屏化匹配规定即可： 咱们能够疾速察看到全链路中灰度流量的参数、返回值、headers 等特色属性。咱们也能够疾速发现全链路是否合乎预期以及定位不合乎预期的起因。 全链路之配置灰度除了微服务实例和流量的灰度，微服务利用中的配置项也应该具备相应的灰度能力，以应答灰度利用对非凡配置值的诉求。 微服务利用通常会引入配置核心做配置管理，其提供动静的配置推送能力使得利用无需重启就能够动静地扭转运行逻辑。但配置核心的治理维度仅仅是配置项自身，并不能感知到前来获取配置的服务实例的环境信息，即无奈辨别申请配置的是正式环境的实例还是灰度环境的实例。在这种背景下，如果某项配置在正式环境和灰度环境中须要应用不同值，它们在配置核心中必须作为不同的配置项，咱们可能须要写出这样的代码： ...if (env == "gray") { cfg = getConfig("cfg-1");} else if (env == "gray2") { cfg = getConfig("cfg-2");} else { cfg = getConfig("cfg-base");}...这一场景在 A/B 测试中十分常见。随着配置项和灰度环境的减少，这类代码还会反复许多次。此外，一套灰度环境中往往存在多个服务，每个服务都须要独立保护一套相似的代码。最终的解决方案如图所示，同一配置项在不同环境中应用的配置值须要在用户利用中被动进行辨别。 究其原因，还是来自于配置核心无奈感知服务实例的环境信息，使得咱们必须在代码中代替配置核心行使这一工作，从而导致了环境信息对业务代码产生了侵入。 针对这一问题，MSE 的配置标签推送性能将配置管理场景下的环境信息的感知下沉到平台侧，由 Agent 负责。用户只需接入 MSE，就可轻松在全链路灰度场景中应用配置推送能力，免去业务代码中繁琐的环境信息检测逻辑。如图所示： ...

作者：陈陈 日志在可观测场景下的利用随着 IT 架构扭转与云原生技术实际，融入开发与业务部门视角，运维团队具备比原有监控更宽泛、更被动的可观测能力。日志作为可观测三支柱（Tracing、Metrics、Logs）之一，帮忙运维团队追踪程序运行状态、定位故障根因、还原故障现场。以故障发现和故障定位为目标应用日志场景可大抵分为日志搜寻和日志剖析两类： 日志搜寻：通过日志关键字搜寻日志；通过线程名、类名搜寻日志；联合 Trace 上下文信息，衍生出依据 TraceID、依据 spanName、parentSpanName、serviceName、parentServiceName 搜寻日志。 日志剖析：查看、剖析指定日志数量的趋势；依据日志内容生成指标（比方每次交易胜利打印一条日志，能够生成对于交易额的一个指标）；自动识别日志模式（比方查看不同模式的日志数量的变动，占比）。在理论生产中，通过灵便组合以上几种应用形式，运维团队能够很好地排除日常观测、故障定位过程中的烦扰因素，更快的定界甚至定位问题根因。 常见开源日志解决方案的有余常见的日志解决方案多是利用主机上安装日志采集 Agent，通过配置日志采集门路的形式将日志采集到第三方零碎存储、查问、展现、剖析。较为成熟的有 ELK(Elasticsearch、Logstash、Kibana)开源计划，其沉闷的社区、简略的装置流程、便捷应用形式等劣势吸引了不少用户。 但 ELK 计划也存在着些许有余： 运维老本高：搭建一套残缺的 ELK 零碎须要部署 ES 集群，kafka 集群以及 logstash 组件等等，以及随着日志规模的增长带来多集群拆分、多集群降级、稳定性等问题，往往须要投入更多人力。资源开销大：ELK 架构中简直所有组件的资源开销都会随着日志规模的增长线性增长，占用极大老本。企业级能力不足：日志中往往蕴含业务要害信息，须要一套齐备的多租户隔离以及细粒度的权限管制计划，这在开源收费 ELK 架构中是不足的。基于 ARMS 的日志解决方案相较于 ELK 开源自建计划，是否能够有更轻量、更容易运维的日志解决方案呢？ 目前，利用实时监控服务 ARMS 提供一套简略易用的日志解决方案，让运维团队能够一键集成利用日志。相较于开源计划，丰盛功能性、压降老本的同时，进一步晋升易用性。 功能性1. 主动富化日志关联调用链上下文包含 TraceID、ServerIP、spanName，parentSpanName，serviceName，parentServiceName。全面满足依据 TraceID 搜寻日志、查找触发异样日志打印的上游利用、上游接口等须要将 Tracing 和 Logs 进行关联剖析的可观测场景。 2. 提供智能日志聚类能力针对规模大、内容杂、且格局也难以做到对立标准的日志进行汇总、形象聚类，使运维人员迅速发现异常日志与失常日志“类别”上的不同，从而疾速定位异样日志、发现问题。 3. 提供 LiveTail 能力针对线上日志进行实时监控剖析，毫秒级别提早上报日志，最贴近tail -f的日志查看体验，无效加重运维压力。 4. 基于 ARMS 的 Arthas 能力，运行时调整 logger 输入级别5. 一键生成基于日志的报警、日志转指标的能力（内测中 行将上线）。易用性ARMS 控制台一键开明，即可应用日志相干全套性能；无需装置额定日志采集组件，防止利用革新；无需治理运维日志服务端以及日志，升高日常运维工作量；反对日志服务 SLS、及 ARMS 间接采集的日志。运维老本日志性能处于公测阶段，完全免费；提供灵便可配置的日志抛弃策略，从源头上缩小大量有效日志；提供灵便可配置的日志存储策略，可依据利用重要水平配置日志存储时长。ARMS 日志性能展现 & 场景最佳实际前置要求降级到 2.7.1.4 以及更高版本的 Agent（K8s 利用重启后会降级到 2.7.1.4 版本 agent，非 K8s 利用须要用户手动下载最新版本 Agent 并挂载）。 ...

最近，国内出名 IT 技术社区 CSDN  重磅公布《2021-2022 中国开发者调查报告》，旨在全面和深刻地理解中国开发者群体整体现状、利用开发技术以及开发工具、平台的情况和发展趋势。该报告对近万名开发者进行调研，“云原生”首次作为独立章节呈现在年度报告中，已倒退为反映中国开发技术倒退变化趋势的要害畛域。 企业云原生投入加大，阿里云容器服务成为开发者首选考察显示，云原生已倒退为驱动业务增长的重要引擎，其对于企业的重要性越来越高，各公司也在云原生的建设上加大投入，18% 的公司在云原生上的费用占整个公司 IT 投入比例的 30% 以上。 图 1：企业 IT 投入中用于云原生的费用占比 作为云原生生态的基石，Kubernetes 不出意外地成为最热门的容器集群管理工具，有 48% 的开发者示意，他们在应用 Kubernetes 进行容器治理。 图 2：容器集群管理工具排行版 在容器云平台的应用形式上，大部分受访者抉择应用云厂商提供的容器服务，仅有 12% 的开发者示意采纳自建容器云平台的形式。在国内支流容器云平台中，阿里云容器服务成为开发者首选，结果显示有 52% 的开发者在应用阿里云。 图 3：容器云平台应用状况 云原生大规模利用落地过程减速，价值与挑战共显随着云原生技术的演进和市场的疾速倒退，云原生的价值逐步浮现，成为开发者们偏好应用云原生的起因。43% 的开发者示意，云原生可能进步开发效率。除此之外，晋升业务的麻利度也是吸引开发者的重要起因。 图 4：应用云原生的次要目标 与 2020-2021 年度相比，企业对云原生利用的规模也显著晋升。通过数据比照显示，集群部署节点规模在 50 个以下的占比从 59% 升高至 33%，节点规模在 51-500 个的占比从  29% 攀升至 47%，节点规模在 1000 个以上的占比从 12% 晋升至 20% 图 5：节点数量 在规模化利用倒退的同时，云原生利用落地给开发者带来的挑战依然较大，特地是“非功能性”的挑战占据了支流，如性能问题、故障问题、并发和吞吐量问题等；另外，如本地存储扩容和 GPU 监控等的一些功能性有余也继续存在。与此同时，国内的云原生技术遍及工作仍任重道远，相干专业人才依然短缺。报告显示，目前仅有 7% 的开发者可能纯熟利用云原生，不过约六成的开发者在被动自学云原生相干技术。 阿里云容器服务：高效智能、平安无界的云原生基础设施通过 10 多年的技术实际，阿里云已领有国内规模最大的云原生产品家族和开源生态，提供云原生裸金属服务器、云原生数据库、容器服务、微服务等超过 100 款翻新产品，帮忙阿里云是中国惟一进入 Forrester 公共云容器平台领导者象限、间断三年入选 Gartner 容器私有云竞争格局的云服务商。 ...

作者：绍舒 引言Apache RocketMQ 诞生至今，历经十余年大规模业务稳定性打磨，服务了阿里团体外部业务以及阿里云数以万计的企业客户。作为金融级牢靠的业务音讯计划，RocketMQ 从创立之初就始终专一于业务集成畛域的异步通信能力构建。本篇将持续业务音讯集成的场景，从性能原理、利用案例、最佳实际以及实战等角度介绍 RocketMQ 的程序音讯性能。 简介程序音讯是音讯队列 RocketMQ 版提供的一种对音讯发送和生产程序有严格要求的音讯。对于一个指定的 Topic，同一 MessageGroup 的音讯依照严格的先进先出（FIFO）准则进行公布和生产，即先公布的音讯先生产，后公布的音讯后生产，服务端严格依照发送程序进行存储、生产。同一 MessageGroup 的音讯保障程序，不同 MessageGroup 之间的音讯程序不做要求，因而需做到两点，发送的程序性和生产的程序性。 性能原理在这里首先抛出一个问题，在日常的接触中，许多 RocketMQ 使用者会认为，既然程序音讯能在一般音讯的根底上实现程序，看起来就是一般音讯的加强版，那么为什么不全副都应用程序音讯呢？接下来就会围绕这个问题，比照一般音讯和程序音讯进行论述。 程序发送在分布式环境下，保障音讯的全局程序性是十分困难的，例如两个 RocketMQ Producer A 与 Producer B，它们在没有沟通的状况下各自向 RocketMQ 服务端发送音讯 a 和音讯 b，因为分布式系统的限度，咱们无奈保障 a 和 b 的程序。因而业界音讯零碎通常保障的是分区的程序性，即保障带有同一属性的音讯的程序，咱们将该属性称之为 MessageGroup。如图所示，ProducerA 发送了 MessageGroup 属性为 A 的两条音讯 A1，A2 和 MessageGroup 属性为 B 的 B1，B2，而 ProducerB 发送了 MessageGroup 属性为 C 的两条属性 C1，C2。 同时，对于同一 MessageGroup，为了保障其发送程序的先后性，比较简单的做法是结构一个单线程的场景，即不同的 MessageGroup 由不同的 Producer 负责，并且对于每一个 Producer 而言，程序音讯是同步发送的。同步发送的益处是不言而喻的，在客户端失去上一条音讯的发送后果后再发送下一条，即能精确保障发送程序，若应用异步发送或多线程则很难保障这一点。  因而能够看到，尽管在底层原理上，程序音讯发送和一般音讯发送并无二异，然而为了保障程序音讯的发送程序性，同步发送的形式相比拟一般音讯，实际上升高了音讯的最大吞吐。 程序生产与程序音讯不同的是，一般音讯的生产实际上没有任何限度，消费者拉取的音讯是被异步、并发生产的，而程序音讯，须要保障对于同一个 MessageGroup，同一时刻只有一个客户端在生产音讯，并且在该条音讯被确认生产实现之前（或者进入死信队列），消费者无奈生产同一 MessageGroup 的下一条音讯，否则生产的程序性将得不到保障。因而这里存在着一个生产瓶颈，该瓶颈取决于用户本身的业务解决逻辑。极其状况下当某一 MessageGroup 的音讯过多时，就可能导致生产沉积。当然也须要明确的是，这里的语境都指的是同一 MessageGroup，不同 MessageGroup 的音讯之间并不存在程序性的关联，是能够进行并发生产的。因而全文中提到的程序实际上是一种偏序。 ...

作者：连喆人 本文选自 “Serverless 函数计算征集令" 征文利用 Serverless 的程度扩大与按量付费劣势, 联合自定义运行时, 实现 Web 利用的疾速迁徙。而 Deno 运行时是新一代的 JS 运行时, 应用阿里云 Serverless + Deno 的组合, 咱们能够疾速开发现代化 Web 利用。 Deno 配合 Serverless Devs 工具, 能够疾速实现代码部署工作。至此, 阿里云函数计算 + Serverless Devs + Deno + TypeScript 的组合实现了软件的疾速开发, 疾速迭代, 疾速部署, 疾速伸缩，利用云端劣势, 疾速解决业务问题。 为什么是 Serverless在 Web 开发畛域, Serverless 相比传统形式, 最大的劣势在于：能够在低运维前提下实现程度扩大。这样开发者可能将次要精力放在业务上, 而不是为了反对可能的高并发而过多关注繁冗的技术细节, 因为专一于业务,大大晋升了开发效率, 升高了开发成本。 同时弹性的程度扩大能够反对任何拜访频次的业务需要, 无需放心老本收益不符问题。从日 1 PV 到日 1,000,000 PV 的利用都能够反对, 无需进行额定配置, 不须要本人做集群治理, 也无需承当固定的费用, 按使用量付费即可。 咱们能够把 Serverless 了解为无需本人治理的按需扩缩的容器集群，在 Web 利用的开发上, 无论从技术角度, 还是老本角度, Serverless 都更有劣势。 ...

作者：赵明山（立衡） 前言Kruise Rollout [ 1] 是 OpenKruise 社区开源的渐进式交付框架。Kruise Rollout 反对配合流量和实例灰度的金丝雀公布、蓝绿公布、A/B Testing 公布，以及公布过程可能基于 Prometheus Metrics 指标自动化分批与暂停，并提供旁路的无感对接、兼容已有的多种工作负载（Deployment、CloneSet）。 Gateway APIIngress API 是 K8s 中针对服务网关的形象，也是目前 K8s 社区中应用最为宽泛的网关资源，其中最具代表性的有 Nginx Ingress Controller。然而 Ingress 资源也存在一些问题，次要是 Ingress 定义比拟繁多，不能很好的满足一些简单的网络需要。很多场景下 Ingress 控制器都须要通过定义 Annotations 或者 CRD 的形式来进行扩大，比方，Istio 就扩大了 Virtual Service、DestinationRule 资源。 为了解决上述问题，推动社区应用对立的规范，SIG-NETWORK 社区提出了 Gateway API 资源，它是 Kubernetes 中的一个 API 资源汇合，包含 GatewayClass、Gateway、HTTPRoute、TCPRoute、Service 等，这些资源独特为各种网络用例构建模型。目前 Istio、Nginx、Kong 等诸多社区开源我的项目都曾经实现了该接口。而 Kruise Rollout 作为渐进式交付框架，天经地义的须要反对，如下是应用 Gateway API 进行金丝雀公布的例子： apiVersion: gateway.networking.k8s.io/v1alpha2kind: HTTPRoutemetadata: name: echoserverspec: hostnames: - test.app.domain rules: - backendRefs: - group: "" name: echoserver port: 80---apiVersion: rollouts.kruise.io/v1alpha1kind: Rolloutspec: objectRef: ... strategy: canary: steps: - weight: 20 pause: {} trafficRoutings: - service: echoserver gateway: httpRouteName: echoserverStatefulSet & Advanced StatefulSet 分批公布Kruise Rollout 在 v0.1.0 版本曾经反对了无状态利用（Deployment 和 CloneSet）的分批公布能力，而有状态的利用同样有相似的诉求。社区 StatefulSet 自身反对公布过程中保留旧版本 Pod 数量的能力（Order 小于 Partition 的 Pod 保留旧版本），所以 Kruise Rollout 通过该个性也能够十分不便的集成有状态工作负载（包含：Kruise 扩大 的 Advanced StatefulSet）。如下是一个分三批公布的例子：  ...

作者：冯诗淳（行疾） ACK 可观测体系介绍全景概要介绍 上图为 ACK 可观测体系全景图金字塔，从上至下可分为四层： 最上层是最靠近用户业务的 Business Monitoring，包含用户业务的前端的流量、PV、前端性能、JS 响应速度等监控。通过容器服务的 IngressDashboard 来监测 Ingress 的申请量以及申请的状态，用户能够定制业务日志，通过容器服务的日志监控来实现业务的自定义监控。 第二层是 Application Performance Monitoring，包含用户的利用监控，由 ARMS APM 产品提供用户Java Profiling 和 Tracing等能力，也反对 OpenTracing和 OpenTelemetric 协定的多语言监控计划。 第三层是 Container Monitoring，包含容器的集群资源、容器 runtime 层、容器引擎以及容器集群的稳定性。应用阿里云 Prometheus 在一张 Global view 的大盘中展现不同集群层面的资源利用，包含性能、水位、云资源，也包含事件体系和日志体系，由事件核心和日志核心笼罩。 最上层是 Infrastructure Monitoring，包含不同的云资源、虚拟化层、操作系统内核层等。容器层和基础架构层都能够应用基于 eBPF 的无侵入式架构和 K8s 监控能力做网络和调用的 tracing。 可观测体系的每一层都和可观测的三大支柱 Logging、Tracing、Metrics 有不同水平的映射。 场景一：异样诊断场景的可观测能力实际 用户的异样诊断案例 早上 9 点多业务流量激增时呈现了异样诊断，收到容器报警提醒某 Pod Down 影响业务流量。用户收到报警后快速反应，对外围业务的 Pod 进行重启或扩容，查找问题根因。首先通过 IngressDashboard 从入口流量自上而下剖析，发现对外业务的拜访成功率降落以及呈现 4XX 返回码的申请，阐明这次异样影响了用户业务。再从资源以及负载层面剖析，能够发现是因为朝九晚五的流量导致水位负载，在当天早上 9 点时存在与故障对齐的显著水位飙升，这也是故障所在。 零碎第一工夫报警外围业务的 Pod 定位，联合业务日志进行剖析，加上 ARMS Java 的 APM 利用监控，定位到产生缓存 bug 是因为早上 9 点钟业务流量飙升引发了 bug 最初造成频繁的数据库读写，调用链也反映可能呈现了数据库的慢查问,最初通过修复 bug 彻底闭环整个异样。 ...

近日，成都元来云志科技有限公司（以下简称“秒云”）的云原生智能运维中台产品与阿里云计算有限公司（以下简称“阿里云”）的阿里云容器服务 ACK 通过严格测试程序，实现了首批的产品生态集成认证测试。 此前，秒云凭借云原生智能运维中台产品以及一体化的云原生治理运维解决方案，入选了阿里云首期云原生加速器，本次通过产品生态集成认证，是入选加速器之后，秒云与阿里云的首次产品级单干。将来，单方将加大力度构建更加丰盛的云原生产业生态圈，携手共建云原生智能运维生态服务。 阿里云产品生态集成认证是面向阿里云合作伙伴自有产品、解决方案与阿里云相干产品的兼容性、可用性的技术能力认证。此次实现阿里云产品生态集成认证，这不仅证实秒云的技术能力、产品利用程度曾经满足阿里云相干产品的适配性要求，也为秒云与阿里云生态的严密单干提供了更强力的技术保障。 近年来，以大数据、云计算、AI 为代表的数字技术疾速倒退，越来越多的业务经营向数字化进阶，企业数字零碎越来越庞杂，传统运维形式曾经无奈满足企业运维治理需要，运维正从手工化、工具化向智能化转变。随着运维体系的日益完善，真正从业务登程、从外围数据登程，能疾速地发现问题并定位故障起因，实现提前预测问题，对潜在的故障进行预防，成为企业运维的诉求点。 秒云智能运维剖析平台整合运维工具栈数据，构建对立的运维大数据平台，解决数据孤岛问题。基于数据平台，采纳 AI 算法，围绕业务拓扑图做剖析。在全景的业务拓扑图上查问、展现日志、指标、告警、事件等运维数据。帮忙运维人员实时掌控 IT 环境衰弱状态，及时发现问题，智能的定位问题，缩小业务故障中断工夫，晋升运维效率，升高运维老本。 同时，秒云反对在阿里云、腾讯云、AWS 等私有云上部署，可别离采集云外部日志/指标/事件等运维数据，独立剖析、展现、告警，原始数据不出云，不产生流量费用，同时反对多云环境的运维。从而用秒云一个工具代替多云的多个运维工具，对立应用习惯，升高运维人员技术门槛。 阿里云容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器利用治理能力，整合了阿里云虚拟化、存储、网络和平安能力，助力企业高效运行云端 Kubernetes 容器化利用，反对企业级容器化利用的全生命周期治理。阿里云容器产品公布 7 年以来，已倒退为企业客户与阿里云自研“飞天”零碎交互的新界面。相比开源计划，阿里云容器服务在计算密集型利用可实现 20% 的性能晋升，容器网络延时升高 50%，异构资源利用率晋升 100%，并实现全链路可观测。阿里云容器产品撑持了阿里团体 100%利用云原生化，帮忙同年双 11 的大促资源老本升高 50%。目前容器服务 ACK 已全面降级为 ACK Anywhere，在企业任何须要云的中央，提供对立的容器基础设施能力。 本次集成测试旨在通过验证秒云对阿里云容器服务 ACK 平台的数据接入、数据解析、数据分析、数据展现及告警等次要性能点，并达成智能运维场景。测试结果表明，秒云智能运维剖析平台在阿里云容器服务 ACK 上运行稳固，所有用例、场景均合乎测试通过规范，各项性能运行失常，性能卓越，单方齐全满足产品兼容认证要求。 将来世界上的每家企业，都将成为数字化的软件企业。数字化转型或者没有对立门路，但经实际验证，云原生是企业实现数字翻新的最短门路。阿里云云原生致力于为企业提供五大外围价值：资源弹性、零碎稳固、利用麻利、业务智能、可信平安，让企业释怀用云，用好云。秒云始终以生态搭档的身份与阿里云放弃着深度单干。将来，借助阿里云的“被集成”生态策略与生态集成技术的全面凋谢，单方的严密单干将进入新的阶段，携手共建云原生智能运维生态服务。

作者：子葵 背景注册核心迁徙在行业中次要有两个计划，一个是双注册双订阅模式（相似数据库双写），一个是 Sync 模式（相似于数据库 DTS）；MSE 同时反对了两种模式，对于开明 MSE 服务治理客户，MSE 服务治理 Agent 帮用户做双注册和双订阅平滑迁徙；对于没有开明 MSE 服务治理可用，能够通过咱们明天推出的 MSE Sync 工具一键迁徙。 什么是 MSE SyncMSE Sync 是基于开源 NacosSync 深度优化的一款数据同步工具，MSE Sync 提供双向同、主动服务获取、一键同步全副服务等能力，帮忙用户更好的实现 Nacos、Zookeeper 注册配置核心的迁徙。MSE Sync 可能在用户迁徙过程中将用户源集群中的服务信息 和 MSE 的云上产品中的服务信息放弃同步，从而实现用户在自建配置注册核心和 MSE 产品之间的平滑迁徙。 为了防止单实例宕机导致两端服务信息不统一，MSE Sync 可采纳多实例部署的形式实现容灾。 MseSync适配了 Zookeeper ，Nacos 的服务注册逻辑，可能实现 Zookeeper 到 Zookeeper， Zookeeper 到 Nacos， Nacos 到 Nacos 的服务信息同步(更多同步能力改善中)，并且反对从 Zookeeper，Nacos 中主动获取服务信息，一键全选防止繁琐操作。 如何通过 MSE Sync 进行上云迁徙首先依据业务规模在 MSE 购买对应规格的实例以及对应规格的 MSE Sync 宿主机，实例规格可参考文末相干文档，Zookeeper，Nacos 都有开发版和专业版利用于开发测试和生产环境，专业版反对多 AZ 部署，稳定性更强，倡议生产环境应用专业版。之后部署 MSE Sync，倡议生产环境迁徙至多部署两个 MSE Sync 实例保障容灾能力，MSE Sync 须要数据库资源，请提前准备好 Mysql 数据库。 ...

阿里云飞天技术峰会于 8 月 11 日在深圳举办，峰会以“聚焦核心技术，激活企业内生能源”为主题，邀请泛滥高新技术领军企业，围绕“企业如何在新一代云计算体系架构之上激活业务、技术、产品的内生能源”这一外围话题开展探讨，共商后疫情时代企业增长的破局之道。 主论坛上，阿里云提出云原生激活利用构建三大范式：全面容器化、核心技术互联网化、利用 Serverless 化， 并公布最新的产品与解决方案。基于分布式云容器平台 ACK One，实现多地区分布式系统统一治理；公布 ACK FinOps 解决方案，让企业实现数字化老本治理，云原生老本优化。同时在峰会现场发表，音讯队列 RocketMQ5.0 全面商业化，以更优的老本、超大规模弹性、轻量易集成、全链路可观测的劣势，助力企业构建稳固的音讯零碎。 阿里云智能云原生利用平台总经理丁宇主论坛演讲 下午【云原生减速利用构建】分论坛，聚焦：FinOps、可观测与SRE、云原生 AI、Serverless、云原生技术中台等热点话题展开讨论。目前峰会分论坛材料已凋谢下载，关注阿里云云原生公众号，后盾回复关键词“飞天云原生”获取下载链接。 点击此处，下载峰会 PPT 材料。

寰球数字化时代曾经到来，数字经济正推动生产方式、生存形式和治理形式的粗浅变动，成为重组寰球因素资源，重塑经济构造，扭转寰球竞争格局的要害力量。 云是连贯事实与虚构孪生世界的技术平台，具备广大的设想空间，作为数字经济的技术方向，云原生技术正在以前所未有的速度成为企业疾速倒退的关节一环。8月11日，2022 飞天技术峰会在深圳胜利举办。硬之城作为阿里云云原生加速器成员企业受邀参会，并由 CEO 李六七发表主题演讲：硬之城云原生转型之路。 本文依据硬之城 CEO 李六七学生在峰会上的分享整顿而成。  背景硬之城是一家电子产业工业互联网的平台，为包含新能源汽车，工控、医疗、IoT 等十万家企业提供从硬件设计选型到芯片供给，到制作、营销和服务的基于 BOM 的一站式交付。这些硬件设施设计结束当前，硬之城可能提供 PCBA 我的项目全生命周期交付。这个过程中，硬之城要把产品设计到输入之间的 2 至 3 个月工夫缩短到 2 周。为了实现效率的晋升，须要做很多对应数据和技术下面的事件。比如说： 1、硬之城做了行业外面对应芯片当先的产品数据库、商品数据库，以及知识库，这是帮忙硬之城在解决方案设计的时候，可能把以前须要人工解决的一个月的工夫缩短 90%，也就是是几秒钟的工夫再加上人工复核的十分钟。 2、在生产过程中，须要对工厂的整个生产工艺、品质、售后服务进行数字化，所以硬之城能力做到为十万家的硬件公司提供最根底的产品、生产和服务的基础设施。 传统架构面临的问题 在这个过程当中，咱们会遇到很多数据和技术的一些问题。比如说传统技术架构遇到三个外围的问题： 第一个是服务器资源占用不均匀。当处于资源波峰和波谷的时候，因为负载不均会呈现个别服务器压力较大，响应变慢，资源利用效率是较低的。 第二个是运维老本高。以前基于 ECS 的架构，每次做发版降级的时候须要写 Shell 脚本，只有在客户量处于绝对低峰的时候会作发版。发版效率低，回滚也很麻烦；出问题的时候排查效率低下，短少利用级别的监控。 三是操作权限调配繁琐。开发人员和运维人员须要不定期地去登录零碎做保护，权限难以收敛，危险较大。 为什么抉择 SAE 基于下面提及的这些问题，咱们就有了以下几个计划： 1、优化咱们的脚本。就是用传统的形式去晋升效率，但这个只能缓解问题，不能解决基本的问题，且保护老本高。 2、通过 K8s 容器化来化解问题。但这个对技术的要求更高，有肯定的技术平缓性。尽管硬之城具备较强的技术能力，但咱们认为这不是最好的形式。 3、抉择 SAE。当接触了阿里云的云原生技术之后，最终抉择将咱们的 K8s 嫁接到 SAE 根底之上。把新的场景和利用部署在 SAE 上当前，咱们发现 SAE 在很多方面给咱们带来了很大的晋升。比如说在原有架构不变的状况下，咱们能够用 0 代码革新的形式，不须要做任何动作，一键能够迁徙。第二个是基于云效构建流水线，能够非常简单地实现自动化公布。第三个是不必做机器的登录，而是能够基于权限助手给开发和运维调配权限，将安全性做进一步的晋升。当然后面也讲到过 SAE 极具弹性的能力，能够让咱们的资源效率变得更高。 SAE 应用实际能够通过下图来看一下理论状况。 最左图咱们能够基于弹性规定给每一个利用配置弹性策略，并且可能察看到每个利用的资源弹性伸缩状况。两头这幅图能够看见的是每个利用的利用监控状况，比方 API 接口调用提早、慢 SQL 查问等。最左边是关注 TOP 利用状况，比方哪个利用的资源耗费最大，异样申请最多等。作为运维，可能实时可视化地看见每个利用的衰弱状况，这些能力很好的加重了运维的累赘，尤其是 SAE 还反对一键回滚、高效调配权限等性能。 硬之城所有的目标是为了更专一于业务，给业务带来显著的变动。比如说在应用 SAE 后，在开发效率方面，咱们晋升了 50%。在运维的效率下面，晋升了 70%。在整个技术新利用老本下面，升高了 40%，在整个问题排查方面，效率进步了 100%。 ...

作者：宋阳（流鑫） 企业上云是近些年的倒退热潮，越来越多的企业把本人的利用部署在各个云厂商中，利用云计算带来的弹性、灵便、平安、低成本等个性，轻松帮忙企业搭建本人的利用。 随着企业规模和业务状态的倒退，一个利用须要组合多种云资源能力对外提供服务，为了便于研发人员开发调试，每种利用都须要部署到多套环境，单纯通过人工手动治理云资源的形式会使得基础设施管理人员的累赘一直减轻。 因而越来越多的企业抉择应用代码（而非手动流程）来定义基础设施，即 IaC（Infrastructure as Code），像看待应用软件一样看待基础设施，这样不仅可能免去繁冗的人工操作还能够利用代码配置原生带来的版本化和抽象化等能力。 在云计算的时代下，利用的部署往往会依赖多个基础设施（计算、存储、网络）。企业外部往往须要一个 PaaS 平台来交付本人的利用，然而 PaaS 平台的开发和保护须要企业有较大的技术和人力投入。对于疾速倒退的企业更心愿可能把精力专一于企业的外围业务。 阿里云 Serverless 利用引擎 SAE（Serverless App Engine）是一个面向利用的 Serverless PaaS 平台，人造反对通过 IaC 的形式来创立和治理，而 Terraform 作为 IaC 畛域的事实标准，已成为了企业 IaC 治理的首选工具，将 Terraform 和 SAE 组合会产生一些微妙的化学反应，企业能够以一种 ADaC（Application Deploy as Code）的形式，通过简略的代码配置文件治理企业的利用。 上面，咱们简略的介绍 IaC 和 SAE 给企业带来的微小便当，并通过一个应用 Terraform 创立 SAE 利用的例子感触 SAE & Terraform 给传统企业 IT 设施治理带来的降维打击。 基础设施即代码企业基础设施治理倒退历程利用可能失常对外服务须要依赖计算、存储、网络等根底资源。他们是利用失常运行的根底上下文。这些资源也称为环境基础设施。在传统的管理模式下，大多数公司都会有专门的运维团队来治理本人的正式生产和测试环境。随着业务的降级和公司规模的增长，运维团队在根底资源管理上会经验大略 3 个阶段： 手工运维：在企业倒退初期，企业的业务品种和规模都处于起步阶段，而且根底环境属于变更频率绝对很低的资源，运维团队往往通过人工治理就能够搭建起服务所需的根底资源，应用云服务的企业在云厂商的控制台通过鼠标操作就能够实现云资源的创立。这一阶段研发人员基础设施需要很低，运维人员通过手工运维就能满足。 运维操作脚本化：随同企业规模和业务的倒退，运维团队会接管到越来越多的环境创立申请，大部分运维团队的成员为了晋升环境创立效率会自发的编写规范化的文档和脚本，或者通过 CLI 来辅助资源的创立，然而因为一个服务往往须要多种基础设施资源配合能力失常对外提供服务，脚本还无奈简略的解决不同基础设施之间的依赖关系，这一段运维人员创立环境会逐渐变成一个繁琐且低效的工作。 基础设施即代码：手工运维和文档脚本化曾经极大的影响开发效率。企业会逐渐把基础设施形象成代码，用治理代码的形式配置基础设施，对环境基础设施能够像看待代码一样进行版本控制和回滚，而且多个环境之间能够复用雷同的代码模块，实现环境基础设施的疾速交付。Terraform 应运而生2014 年，HashiCorp 公司推出了产品 Terraform，它是一个能够平安、高效地建设，变更以及版本化治理基础设施的工具，时至今日 Terraform 相对是 IaC 畛域的王者。应用 Terraform 治理企业基础设施能够给企业带来多种益处： 应用申明式的 IaC 治理基础设施：申明式的形容可能保障即便代码执行屡次也能达到统一的状态，应用代码来形容根底资源，可能更加形象间接的展现出不同环境之间的差别。不论什么环境呈现问题，都能疾速的复刻出一个新的环境。丰盛的 modules 生态：简直蕴含所有云厂商的云资源，使用者能够在官网保护的模块仓库 Terraform Registry 中应用各种官网和社区提供的高质量模块。让使用者不必再反复编写其余云厂商的模块，利用开源社区的能力，不断完善和壮大 Terraform 生态。 资源依赖治理：Terraform 会依据模板中的定义，构建所有资源的 DAG 拓扑关系图。对于有依赖资源的资源，会依据依赖关系有序执行，对于没有任何依赖关系的资源会以并行的形式创立以保障执行的高效性。云计算时代下的企业应用部署利用的部署往往会波及到 VPC 网络管理和划分，虚拟机的创立，通过负载平衡裸露利用的服务地址。在微服务架构流行的明天，企业还须要部署和运维一些微服务组件，以提供服务发现、配置管理、无损高低线等性能保障利用可能提供稳固一直流的服务。为了可能监控利用的运行状态，通过 Trace、Metrics、Logs 等信息来理解利用衰弱状态是必不可少的局部。 ...

作者：刘军 中仑网络在 2022 年实现了服务框架从 Dubbo 2 到 Dubbo 3 的全站降级，深度应用了利用级服务发现、Kubernetes 原生服务部署、服务治理等外围能力。来自中仑网络的技术负责人来彬彬对整个 Dubbo 3 的选型、降级过程及收益等做了深刻总结。 来彬彬，2020 年退出苏州中仑网络科技有限公司，负责架构部负责人/高级架构师，十四年架构开发教训。曾任职于苏宁易购七年参加商户平台、物流四方服务平台等架构设计，为用户提供亿级 SaaS 服务。现重点保障中台化施行、性能优化、业务架构、稳定性等，专一批发行业、互联网、云计算、架构设计。值得一提的是近期 Dubbo 3 官网文档 整体有了实质的晋升，并且社区承诺短期内文档还会投入大量精力欠缺文档，这点对于 Dubbo 3 的应用和用户信念晋升十分重要。 公司业务与技术架构简介苏州中仑网络科技有限公司是一家“专一批发门店增收服务”的公司，始终以“解决中小批发门店经营难的问题”为初心，致力于为零售商户提供门店经营一体化解决方案，帮忙批发门店实现增收。中仑网络以批发技术为外围，为零售商户打造出集收银零碎、中仑掌柜、微商城、汇邻生存平台、大数据平台、挪动领取、智慧农贸、汇邻门店经营服务等为一体的新批发生态体系，实现线上线下全方位交融，为零售商家赋能增收。技术团队在构建之初选取 Dubbo 2.5.3+Zookeeper 版本构建公司微服务基座撑持公司业务倒退，前期同阿里云深度单干整体迁徙应用阿里云，应用云原生基础设施 ACK（Kubernetes）+MSE（Zookeeper）+Dubbo+PolarDB 等构建，实现可动静缩扩容的服务能力。 随同单干商扩大 3000+，市场遍布 300+城市，零售商户 30 万+，服务笼罩餐饮、茶饮、服装、母婴、烘焙、生鲜、商超、美业、美妆、宠物等多个行业。随同着畛域拓宽、商户量快速增长回升，零碎数量和部署节点也迎来了暴增，随之在零碎可用性上受到较大挑战：微服务治理能力、微服务地址注册发现，Kubernetes 平台服务的无损高低线顺滑度上问题与挑战越来越多。架构图见图一。 图一 Dubbo 3 降级总结在降级微服务组件技术选型上次要思考解决以前的痛点：服务治理能力、云原生敌对性、服务注册发现，这几个制约业务倒退的紧要问题。比拟下来 Dubbo 3 架构设计理念与咱们较为符合，能较好的满足咱们业务倒退要求。 1、服务治理能力Dubbo 3 提供丰盛的服务治理能力，可实现诸如服务发现、负载平衡、流量调度等服务治理诉求。在应用上咱们有两种抉择： 应用 Dubbo 治理控制台治理配置集成相干 API 能力到零碎同时 Dubbo 扩展性较好，能够在很多性能点（见图二）去定制本人的实现，以扭转框架的默认行为来满足本人的业务需要。 Dubbo  SPI ( Service Provider Interface)将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样能够在运行时，动静为接口替换实现类。基于此个性，咱们能够很容易的通过 SPI 机制为咱们的程序提供拓展性能，如咱们在此基础上实现了基于生产和消费者过滤器 Filter 实现全链路自定义的链路监控;基于路由扩大标签路由形式进行测试环境的隔离不便疾速多版本服务测试验证。实操上咱们基于生产者注册服务时打标，如原零碎 A  V1 版本部署在 fat 环境上，当初为了测试 V2 版本，咱们将 V2 版本打标 tag=fat-v2；应用端在生产时指定 Invocation Attachment  参数，inv.setAttachment(TAG_KEY, routeTag)；基于此咱们能够不便自测试，同时生产上咱们也能够做简略的生产灰度使用。 ...

8 月 11 日，2022 阿里云飞天技术峰会在深圳举办，会上阿里云提出云原生激活利用构建三大范式，并公布最新的产品与解决方案。基于分布式云容器平台 ACK One，实现多地区分布式系统统一治理；公布 ACK FinOps 解决方案，让企业实现数字化老本治理，云原生老本优化。同时在峰会现场发表，音讯队列 RocketMQ5.0 全面商业化，以更优的老本、超大规模弹性、轻量易集成、全链路可观测的劣势，助力企业构建稳固的音讯零碎。 阿里巴巴研究员、阿里云智能云原生利用平台总经理丁宇在主论坛发表演讲，以下依据演讲内容整顿而成。 丁宇在峰会现场 明天，企业应用构建仍然面临很大挑战，资源如何按需应用，实现降本增效？如何在简单零碎架构下充沛保障业务稳固和连续性，如何做到利用的麻利和业务的智能化？以及十分重要的一点，如何保障系统的可信和平安？ 企业亟需充沛开掘云计算的技术红利，助力业务倒退，发明更多的商业价值。而云原生能够激活利用构建范式，以解决企业在新期间遇到的挑战。 全面容器化。容器带来运维的标准化，明天容器曾经成为云计算和企业交互的新界面，并带来弹性和可伸缩能力的晋升，助力企业应答降本增效的刚需。同时咱们也看到一个趋势就是全负载的容器化。明天讲的容器化，不仅仅是微服务，包含 AI、大数据等新型利用也在全面容器化，这就让容器部署变得无处不在。 核心技术互联网化。互联网化能够撑持业务的麻利迭代，同时构建弹性架构，让利用能够从容应对流量的顶峰，并实现高可用、高牢靠，保障业务的连续性。 利用 Serverless 化。 Serverless 大幅度晋升企业开发运维效率。并且因为全托管，带来了更加极致的弹性，针对所有场景进行笼罩，让利用上云更简略。 IDC 预测：到 2024 年，因为采纳了微服务、容器、动静编排和 DevOps 等技术，新增的生产级云原生利用在新利用的占比将从 2020 年的 10% 减少到 60% 。针对三大利用构建新范式，阿里云提供了哪些云原生产品与计划呢？ 首先咱们来看容器服务。阿里云容器产品公布 7 年以来，已倒退成为企业客户与阿里云自研飞天云操作系统交互的新界面。相比开源计划，阿里云容器服务实现了计算密集型利用性能晋升 20%，容器网络延时升高 50%，异构资源利用率晋升 100%，并实现全链路可观测。目前容器服务 ACK 已全面降级为 ACK Anywhere，在企业任何须要云的中央，提供对立的容器基础设施能力。 分布式云容器平台 ACK One：多地区分布式系统统一治理据预测，到 2025 年，50% 大型企业将通过分布式云推动业务翻新，为此阿里云推出了企业级多地区/多集群容器治理平台 ACK One，大幅简化了集群治理界面，提供统一的治理、交付、运维体验。无论是基于公共云、专有云、自有 IDC 还是边缘节点，用户都能够通过 ACK One 进行对立的容器集群治理、资源调度、数据容灾和利用交付。 泛生子是我国当先的癌症精准医疗公司，基于ACK容器技术支持对癌症基因检测数据处理，充分利用了云的弹性能力，日解决能力在过来三年晋升了10倍， 单样本解决老本相比于云下节省成本 60%。 vivo 是国内出名的智能手机厂商，其 AI 计算平台通过 ACK One ，及时满足算力需要，大大缩短资源交付周期，从数月缩短到天级别。 对于长期的短期应用的算力需要，通过混合云应用私有云资源，可升高 90% 以上老本。 ...

作者：洵沐、流士 背景微服务场景下，全链路灰度作为一种低成本的新性能验证形式，失去了越来越宽泛的利用。除了微服务实例和流量的灰度，微服务利用中的配置项也应该具备相应的灰度能力，以应答灰度利用对非凡配置的诉求。 为什么须要配置标签推送从全链路灰度谈起在微服务场景中，利用的灰度公布迎来了新的挑战。不同于单体架构中将利用整体打包即可公布测试版本，微服务利用往往由多个服务组合而成。这些服务通常由不同的团队负责，独立进行开发。一个新性能通常只波及到局部服务，在测试新个性时，咱们只须要对这部分服务进行公布即可。为了让微服务利用失常运行，还须要设计一种计划，让灰度流量也能失常通过其余不须要公布的服务。 这一性能通常有物理环境隔离和逻辑环境隔离两种解决方案。前者须要为每套灰度环境都搭建一套网络隔离、资源独立的环境，为了利用能失常运行，还须要在环境中为未被灰度到的服务、各种中间件等做冗余公布，如图所示： 物理环境隔离这一计划存在着大量的机器资源节约。因而业界广泛采纳后者，即逻辑环境隔离的形式做为全链路灰度的解决方案。只需部署灰度服务，通过调用链路上的流量管制使得灰度流量能在灰度环境和正式环境间流转，实现灰度微服务利用的失常运行，帮忙业务方进行新性能验证。如图所示： 配置灰度的利用场景在许多业务场景中都可能波及到配置灰度能力的利用，上面是几个典型场景。 金丝雀公布金丝雀公布曾经在业界宽泛落地，是新版本公布的罕用伎俩。金丝雀发布会对流量进行比例分隔，一开始为新版本的实例调配较小比例的流量，通过一段时间的运行，确认新版本运行失常后再逐步提高所调配流量的比例，直到最终全量切流。通过这种形式做公布能够在新版本呈现问题时管制影响面，进步零碎的稳定性。 金丝雀公布通常通过流量染色和机器打标来实现。新版本的机器被打上金丝雀版本标记，同时让局部流量携带上金丝雀版本标记，最终还是演变成全链路灰度的解决方案。金丝雀版本的利用中的配置项可能须要应用和旧版本中不同的配置值，这就须要配置灰度的能力。 新性能上线在改变波及较大的性能上线时，往往会通过逐渐放量的形式来验证性能的稳定性。一种典型的放量形式就是白名单，即配置在白名单中的用户/设施能够应用新性能，未在白名单中的用户依然应用旧版本。在线上运行一段时间后收集白名单用户的反馈，对性能做优化的同时逐渐减少白名单中的用户/设施数，等性能达到最终的稳固状态后再全量公布。 来自于白名单中的用户/设施会被打上非凡的标记，被路由到灰度环境中。如果新性能中的配置须要应用不同于旧版本中的配置值，就须要同步用到配置灰度。 数据库迁徙数据库迁徙也是业务倒退中的常见问题。随着业务的快速增长，原有的数据库可能在容量/性能上都不再能满足将来的业务须要，这时就须要做数据库迁徙。为了保障迁徙过程的稳定性，迁徙通常是渐进式的，这个过程中会存在局部流量写新库，局部流量写老库，待迁徙齐全实现后再将所有流量切到新库上。迁徙过程中咱们能够通过流量染色配合配置灰度来实现对不同数据库的操作。 问题及解决方案微服务利用通常会引入配置核心做配置管理，其提供动静的配置推送能力使得利用无需重启就能够动静地扭转运行逻辑。然而配置核心的治理维度仅仅是配置项自身，并不能感知到前来获取配置的服务实例的环境信息，即无奈辨别申请配置的是正式环境的实例还是灰度环境的实例。在这种背景下，如果某项配置在正式环境和灰度环境中须要应用不同值，它们在配置核心中必须作为不同的配置项，咱们可能须要写出这样的代码： ...if (env == "gray") { cfg = getConfig('cfg1');} else { cfg = getConfig('cfg2');}...如果有多个配置项在灰度环境中存在不同的配置值，这样的代码还须要反复屡次。更极其的场景下，如果在测试的灰度环境还有多套，每套环境中的配置值都不同，负责获取配置项的代码还会更简单。此外，一套灰度环境中往往存在多个服务，每个服务都须要独立保护一套相似的代码。最终的解决方案如图所示，同一配置项在不同环境中应用的配置值须要在用户利用中被动进行辨别。 究其原因，还是来自于配置核心无奈感知服务实例的环境信息，使得咱们必须在代码中代替配置核心行使这一工作，从而导致了环境信息对业务代码产生了侵入。只管咱们能够通过对获取配置的代码做一些封装来升高业务代码的应用复杂度，但只有配置核心无奈感知服务实例的环境信息这一事实存在，这种环境信息对业务代码的侵入性就无奈防止。 性能介绍MSE 新上线的配置标签推送性能将配置管理场景下的环境信息的感知下沉到平台侧，由 Agent 负责。用户只需接入 MSE，就可轻松在全链路灰度场景中应用配置推送能力，免去业务代码中繁琐的环境信息检测逻辑。如图所示： 配置标签推送提供的性能包含： 标签维度的配置管理在配置列表页中能够查看利用中的各种配置项。目前 MSE 反对对三类配置进行采集： 应用 SDK 提供的注解@Switch 标记的配置类应用 Spring 的注解 @Value 标记的配置项应用 SpringBoot 的注解 @ConfigurationProperties 标记的配置类每个配置项下会展现所有服务实例的配置值，用户能够通过标签名直观地看到不同实例所处的灰度环境，还能够查看不同灰度环境下的配置值散布 标签维度的利用配置推送能力通过“按标签推送”，用户能够便捷地为指定灰度环境中的所有服务实例推送长久化的新配置值。长久化意味着即便利用重启，针对该环境的配置项也不会失落。 配置场景下的实例动静打标除了在利用启动时通过 MSE 的打标形式为服务实例设置标签，用户能够在 MSE 控制台动静地为服务实例新增/删除标签，以适配不同灰度环境下的配置项治理。 围绕整个配置标签推送流程的溯源能力MSE 为标签推送提供了全流程的溯源能力，包含实例标签变动记录，标签推送记录，帮忙用户便捷地排查标签推送流程中的问题。 配置标签推送实际接下来，咱们通过实际来演示配置标签推送的应用流程，只需简略的三步即可实现。 筹备工作将利用接入 MSE 微服务治理进入 MSE 控制台，抉择地区进入 治理核心 > 利用治理，进入刚刚接入的利用Step 1：新增标签配置标签推送的第一步是为服务实例设置标签。服务实例的标签能够在启动时通过 -Dalicloud.service.tag 设置，同时也能够在 MSE 控制台动静设置。 ...

以后，Serverless 在挪动利用、游戏等场景曾经实现规模化利用，Serverless 技术能够更好的帮忙开发者只关注利用翻新，缩小对开发与运维的适度关注。 为了让更多开发者在实在场景中体验 Serverless 的劣势，这一次咱们基于阿里云函数计算 FC + Serverless 利用核心推出 1 分钟 Serverless 极速抽盲盒，开发者能够疾速体验一键部署并迅速集成到利用，感触 Serverless 技术带来的开发门槛升高和交付效率晋升。 流动期间，只需实现 1 个场景体验，即可抽取“程序员专属惊喜盲盒” ，每日补货，抽完为止！（轻轻说...中奖率超高） 流动工夫8月1日 — 8月12日（工作日期间） 参加形式点击“ 此处 ”浏览器拜访：https://developer.aliyun.com/...扫描海报二维码， 举荐 PC 端进行体验 盲盒福利本次流动的盲盒中奖概率为 55.533%，共计 1700 件奖品福利放送，程序员的“抽盲盒”形式就是这么朴实无华且极客！ ✅奖品包含价值 1300 元暗藏盲盒✅BiliBili 联名机械键盘✅天猫精灵✅优酷会员卡✅云小宝公仔✅天猫超市卡✅清凉小风扇✅阿里云产品代金券 5元/10元（仅限购买函数计算 FC）本场景提供的云产品和服务函数计算 FC: 函数计算是事件驱动的全托管计算服务。应用函数计算，您无需洽购与治理服务器等基础设施，只需编写并上传代码。函数计算为您筹备好计算资源，弹性地、牢靠地运行工作，并提供日志查问、性能监控和报警等性能。 立刻返回：https://www.aliyun.com/produc... 若有盲盒部署相干问题 可钉钉搜寻群号：35154841 征询！ 【答疑群】Serverless 抽盲盒体验流动立刻部署你的专属盲盒机！

面对疾速变动的世界 开源畛域涌现了哪些新技术和倒退模式？ 开源社区建设又有哪些新进展和翻新实际？ 下周 8月22日-24日 间断三天，精彩不止 锁定"阿里技术"视频号直播 和开发者和开源爱好者 一起摸索开源畛域最佳实际和新机遇 欢送预约直播 精彩分享和海量周边抽奖福利 2022阿里巴巴开源凋谢周  敬请期待 主论坛：开源生态与将来阿里巴巴开源委员会分管委员蒋江伟（小邪）、Matt Asay（ VP of MongoDB）、bilibili技术委员会主席毛剑，邀你一起聚焦开源生态倒退，前瞻开源趋势和将来。并邀请中国信息通信研究院云计算与大数据研究所副所长栗蔚，上海交通大学长聘传授、人工智能研究院总工程师、上海白玉兰开源凋谢研究院执行院长金耀辉，Apache软件基金会首位华人董事、Tetrate 开创工程师吴晟，与阿里巴巴开源委员会秘书长、开源办公室负责人王晶昱（沈询）共话云与开源的更多可能。 云原生专场等五大畛域论坛分论坛聚焦操作系统、数据库、云原生、大数据智能和终端畛域，邀请 Intel 、字节跳动、网易、快手、韵达、统信、莲子数据等 30+ 技术专家分享开源畛域最佳实际和新机遇，帮忙开发者、工程师、开源爱好者摸索技术凋谢生态的更多可能。 残缺议程 点击此处，进入阿里巴巴开源官网，可获取 PPT 下载地址和直播回看地址。

作者：周欣元 个人简介大家好，我是周欣元，本科就读于杭州师范大学，往年 9 月将去往云南大学进行研究生学习。本科钻研方向为 docker 容器在网络攻防中的利用，目前作为 sealer member 退出了外围模块 sealer runtime 的研发工作。 个人主页：https://github.com/starComingup 引言sealer 是一款由阿里巴巴开源的集群镜像软件，是疾速装置 Kubernetes 的交付工具，可能短时间“一键”实现新集群的装置。sealer 主打的“集群镜像”概念可能帮忙应用 docker 的用户平滑的过渡到 Kubernetes。 作为准研一“00 后”，在 2022 年 6 月初，我怀着对开源的神往退出了 sealer 的 Developers 的队列，此时间隔 sealer 启动曾经有一年了，在 2022 年 4 月左右进入了 CNCF sandbox 阶段。 我置信很多人都一样，接触到 Github 大多是从下面克隆一个下来而后轻易改改交个作业，至多本科如此。而真正的作为一个 Github 良好社区我的项目，须要有沉闷的生态，沉闷的提交（Pull Request），沉闷的倡议（Issues）。而我，凭借实习用起来的 git commit/pull/clone/push 对于退出社区来说无从下手。 上面就以我集体与 sealer 的一段成长故事来率领大家体验从小白到外围性能开发者的开源之旅，同时本文也作为一篇引领开源小白入门的文章供大家参考。 参加 sealer 开源的偶尔与必然大四上学期考完研后，我依附本科我的项目教训所积攒的 Java、SpringBoot、docker 等技术进去寻找工作。此时恰逢杭州的容器云岗位大量招募，我有幸进到了杭州谐云科技有限公司，并在一个机缘巧合下进入了和阿里云单干的云原生我的项目中，并在岗位上意识了团队的 Leader--孙宏亮。前面恰逢技术调研须要，天天在 Github 上逛，发现团队正在经营开源的交付工具 sealer，只不过仅仅据说了 sealer 小名--号称“三分钟通过集群镜像交付一套集群”。因而 sealer 在我脑海中蒙上了神秘的面纱，恰逢 4 月底录取告诉收回，我想我今后是否能为开源贡献力量。 大略 5 月中旬，我确定了我去读研的打算，这个时候我比拟迷茫，因为无奈留在杭州，但又不舍保持三年的云原生畛域。偶尔一次周会上据说 sealer 正在吸引开源志愿者加入开源之夏-2022（下称 OSPP），我一听：这不是明摆的机会吗？于是我在 5 月底来到了团队，开始着手 OSPP 上 sealer 对于反对装置 K0s 的我的项目计划书。6 月份的入选如期而至--当然，背地少不了宏亮的鼎力支持。 ...

随着云原生技术的遍及，业务负载上容器越来越广泛。特地是在企业级环境下，越来越多的开发者在进行容器镜像仓库的选型时，都会面临官网镜像版本无奈满足性能需要、传统构建形式镜像体积越来越大、镜像下载时受到网络环境的影响、镜像内存在的破绽无奈躲避等诸多须要解决的问题。 阿里云容器镜像服务 ACR（Alibaba Cloud Container Registry）是面向容器镜像、Helm Chart 等合乎 OCI 规范的云原生制品平安托管及高效散发平台，产品分为个人版和企业版，个人版面向开发者收费应用，可提供根底的容器镜像服务，包含利用镜像托管能力、镜像平安扫描性能、稳固的镜像构建服务以及便捷的镜像受权性能，可能帮忙开发者不便地进行镜像全生命周期治理。 为了帮忙更多开发者理解容器镜像服务 ACR 的性能、应用形式和产品体验，阿里云容器镜像 ACR 产品测评团正在炽热招募中，当初起退出流动，公布对于 ACR 的原创测评内容，即有机会取得多重定制好礼哦 ！ 流动规定收费开明并体验阿里云容器镜像服务 ACR公布原创测评内容流动工夫：即日起至2022年9月30日测评方向1. ACR 产品性能或体验评估，包含但不限于以下内容：ACR 访问速度、镜像平安、部署和保护老本等方面的体现如何，是否满足你的预期？是否接触或应用过其余容器镜像仓库？不局限于性能、效率、性能、应用体验等方面，与同类型工具相比，有哪些劣势或期待改良的中央？ACR 中有什么性能或设计会让您感觉印象粗浅？为什么？2. ACR 利用实际反馈，包含但不限于：您目前从事什么方向的工作？在什么场景下会应用到 ACR？ACR 是否免足了您对于容器镜像仓库的需要？给您或公司带来的价值和收益如何？您是否应用过 ACR 企业版服务？次要须要哪些差异化能力？您认为 ACR 企业版有待改良的方面是什么？流动处分（1）内容原创，无效字数在 100 字以上且通过审核的用户可取得 50 积分处分，每人最多可取得 150 积分处分 （2）内容原创，前 100 位公布无效字数 300 字以上测评的用户可取得 30 元挪动充值卡一张 （3）流动期间，每月主办方将依据测评内容品质挑选出至少 5 篇最佳测评，发布者可取得 ACR 定制雨伞一把 （4）流动完结时，主办方将选出流动期间品质最佳的 1 篇测评（评比要求：字数 500 字以上，图文联合，内容空虚、有新意），发布者取得机械键盘一个！ 限量好礼限时派送中，赶快点击此处或扫描下方图片二维码，退出 ACR 产品测评团吧！

作者：弈川 结尾咱们先讲一个小故事，这也是很多守业团队常常碰到的状况： 小王是一家互联网守业公司的研发领导，最后守业的时候研发团队只有 10 人左右。过后他最大的痛点是，如何率领技术团队尽快把 Idea 落地，业务上线。因而过后最大的诉求是业务可能疾速开发迭代，同时过后业务量并不会太大，云资源老本也不是太高，天然也不会太 care 云资源的老本调配。然而随着业务的高速倒退，业务架构也从原来的单体利用变成了微服务利用，同时，小王的公司也随之疾速扩张，研发人员也从 10 人扩张到一百多人。 此时，作为公司 CTO 的小王，也不得不将更多的重心从技术架构治理放到研发团队的治理上来。此时摆在他背后的研发团队分成了 7、8 个小组，别离负责不同微服务模块，包含了用户核心，交易中心，日志核心等等......云资源的老本呈指数增长，老本优化、估算调配也成为了小王的事不宜迟。 那么有没有一款好的工具能够帮忙小王解决这些问题呢？这时候就要借助一项企业高级个性—企业分账了。 SAE 企业分账能力介绍Serverless 利用引擎（SAE）作为一个通过多年倒退积淀，成熟优良的 PaaS 平台，天然也是具备了企业分账的能力，其外围就是通过阿里云的 Tag 标签零碎，实现利用的账单的分类，而后再通过阿里云的费用核心进行一些配置，最终实现分账。 标签布局当云资源（在 SAE 中即是利用）逐步增多时，利用标签将资源进行分组治理和归类，能够便于搜寻、聚合资源。最常见的就是为不同环境或我的项目等设置不同的标签，示例如下： 环境隔离：为不同的环境（如生产环境和测试环境）、操作系统（如 Windows Server 和 Linux）或者客户端平台（如 iOS 和 Android）绑定不同的标签。项目管理：在团队或者项目管理中，您能够增加以群组、我的项目或部门为维度的标签（如 CostCenter:aliyun），实现分组、分账治理。  实现办法SAE 实现企业分账的操作方法如下： 基于组织或业务维度，为资源（利用）布局标签。（图示中①）通过 SAE 控制台或 API 为利用绑定标签，建设利用和标签的关系。（图示中②）通过阿里云用户核心查看费用账单。（图示中③） 步骤一首先依据本身的业务，进行标签布局，而后能够到 SAE 控制台的利用治理页面内，进行标签的编辑。标签都是一对键值对（Key-Value）组成，每一个利用最多能够打 20 个标签。 步骤二须要在费用核心启用费用标签，启用过后，相干标签所蕴含的云资源的账单才会真正带上标签信息。只有账单带上了标签，咱们能力在账单明细中通过标签进行过滤筛选。 另外，咱们还能够新增财务单元，将相干标签的资源分配进该财务单元。此处的财务单元能够了解是一个费用统计汇合，将资源实例调配到创立的“财务单元”中，并依照“财务单元”维度灵便汇总、查看相应资源实例的账单费用。例如能够将雷同标签（相当于同一个部门）的不同云资源对立集中到一个财务单元，进行对立的账单统计与治理。 步骤三最初，能够在分账账单中查看对应的财务单元的相干具体账单，同时还能够导出不便进一步数据处理。“分账账单”蕴含了 SAE 利用 CPU 与内存的费用明细，用户能够用于查看每个“分拆项”的具体用量，同时每个免费项也蕴含了标签信息，因而作为企业外部分账的参考根据。 在分账账单中定制列勾选，用量与资源包抵扣，即可在控制台中显示计量明细。 此时，咱们能够看到相干账单明细，对于按量付费的客户，能够看到相干实例的用量状况。对于购买了资源包的用户，还能看到资源包抵扣状况。 并且，能够依据标签过滤显示账单详情，同时也能够将整个账单导出成 CSV 格局的文件，便于统计分析。 总结咱们能够发现企业分账这个性能，是面向企业客户生产费用分账的场景，解决的是企业费用外部 chargeback 的问题。企业费用分账无论是对于大企业，还是文中小王所在的日益发展壮大的中小企业都是一个必不可少的需要。它不只是作为一个企业迈向标准与成熟的重要标识，它也成为了企业上云做云产品选型的重要考量，因而标签分账性能也是 SAE 企业级能力的重要体现。 ...

作者：十眠 为什么有了无损下线，还须要无损上线？无损上线能够解决哪些问题？ 本篇文章将一一答复这些问题。 无损上线性能不得不说是一个客户打磨进去的性能咱们将从一次公布问题的排查与解决的过程说起。 背景阿里云外部某利用核心服务在公布过程中呈现了大量的 5xx 超时异样。初步狐疑是无损下线问题，于是很快便接入了 MSE 提供的无损下线性能。然而接入无损下线性能后持续公布，利用的公布过程仍然存在大量的超时报错。依据业务方同学的反馈，大略利用在启动后 5 秒左右，会有大量超时申请。 无损下线性能未失效？于是拉了相干的同学开始排查。利用的调用状况如下：gateway - > A -> C 。 公布的利用为 C 利用，公布过程中呈现大量超时报错。咱们通过相干日志与利用的启动状况，整顿如下线索： 【服务端视角】：找了一台 C 利用的机器 xxx.xxx.xxx.60 察看第一阶段：xxx.xxx.xxx.60 (C 利用)下线阶段 20:27:51 开始重启，执行重启脚本<!----> 同时察看到执行了 sendReadOnlyEvent 动作，表明服务端发送只读事件，客户端不会再申请该服务端在 sendReadOnlyEvent 后，开始陆续执行登记服务动作<!----> 20:27:54 登记所有 provider seivce 实现20:28:15  利用收到 kill -15 信号第二阶段：xxx.xxx.xxx.60 (C 利用)上线阶段 20:28:34 服务端重新启动20:29:19 在 Dubbo 注册核心控制台察看到 xxx.xxx.xxx.60 注册结束20:29:19,257 日志中看到 start NettyServer【客户端视角】：找了一台 A 利用的机器 XXX.XXX.XXX.142 察看20:27:51 received readOnly event，收到服务端发送的只读事件，此时该客户端不会申请至 XXX.XXX.XXX.60 机器20:27:56 close [xxx.xxx.xxx.142:0 -> /XXX.XXX.XXX.60:20880] ，敞开channel连贯业务日志报错信息同时搜 C 利用的机器 XXX.XXX.XXX.60 的报错相干的日志，共 237 条日志 ...

背景：算是一个腾讯云深度用户，用了78年左右，因为业务需要，往年五月份开始逐渐在阿里云跑了一些服务。不吹不黑。发自内心的吐槽一下阿里云的ack服务。其余服务没有多大发言权。都差不多。然而作为一个算是比拟晚期的kubernetes用户有必要吐槽一下阿里云的ack服务，没有方法。圈子外面没有阿里云容器组的人，像是腾讯云的tke的服务有问题能够间接找到相干人员反映，提交一下集体意见了。 深度吐槽阿里云ack服务1.从创立集群开始吧1. 对于虚构交换机对于这个抉择虚构交换机我就很不能了解，比方我当初有四个交换机，ok，我抉择了三个，是不是我另外一个交换机的服务器就不能退出集群？前提是我抉择了专用网络了，实践上我的专用网络内任何一台服务器是不是都能够退出集群？为什么要给我加一个这个的限度呢？不晓得我的了解有没有问题，也欢送各位阿里云的大佬斧正！ 2.对于容器的网络这个中央更是恶心....默认的pod 的cidr 172网段的，service cidr192.168.0.0/16段的？这只是我的截图阿，反正就是 两个网络的段不会是一个大的网段默认的......pod 网络 service网络默认会是两个不一样的私网....可是我有点强迫症....我想pod service cidr在一个网络内可不可以？请看一下腾讯的我只设置了容器网络172.1716.0/20,而后我的容器pod网络主动设置为了172.17.16.0/20,service cidr设置为了172.17.28.0/22：这样他不香吗？要害是这样，我前面如果多vpc，多地区集群作互联是不是会不便一些？可能手动的能够设置。然而用户疏导这方面设置为两个不同的私网是很恶心的，请考虑一下多集群互联，和网络资源的布局！这只是集群创立过程中体验的不爽的... 2.当集群创立实现之后：1.资源的扩容增加服务器到集群这个问题我提交过工单，工单可见服务编号000D0585GS。过程是这样的。我要增加一台已有的服务器退出集群，而后居然加不进去，查了一圈问题，客服通知我，要先把这台服务器退出到ack节点的平安祖我能力操作....what这是什么鬼操作？我增加机器进入集群，平安祖不应该默认增加吗？还须要我手动先将机器退出平安祖我能力增加机器进入集群？这是什么神仙操作？很让我费解。工单中提交了集体意见心愿能更改这个流程，不晓得后续是否有什么批改 2.诡异的alb事件是这样的：我应该三四月份创立的ack集群，而后过后看网络路由有ALB ingress，咱没有用过阿...体验一下吧！后果就是我没有创立胜利......有点难过，作为一个用了kubernetes5-6年的用户我居然没有搞胜利，好吧一气之下删除了，换成了traefik作代理。诡异的期间 14天后的一个夜晚产生了.....主动创立了ALB服务。齐全懵了......我不是删除了吗？为什么是14天的周期主动创立了？我关怀的是删除了服务 ，为什么没有删除洁净？为什么14天后服务主动创立了？这都是什么神仙操作？ 3.日志服务对于Job日志的采集谁家还没有几个job服务呢对吧？而后接入了阿里云的日志采集服务。恩要害是日志齐全没有采集到阿....怎么会事件？问 了一下我的job退出太快了....要害是job就算退出了也是complete状态吧？默认的能够看到最新的三个工作的日志吧？起码kubectl logs -f？采集不到....好吧，批改代码打完了日志期待30秒再推出...这也太恶心了......我起码filebeat啥的采集也能采集到吧？怎么就不能呢？能不能别让我批改阿...... 4.可恶的报警.......先吐槽一下这个报警模板，大家的审美观看一下可还悦目？第一眼ack 好的我默认关上ACKTMD报警模板外面的实例名称能不能给ack集群中节点名称统一我那里下手阿？哦对有公网IP我凑 ，这ack控制台显示公网Ip吗？点开详情ip这里能力发现是这一台这里我心愿报警模板实例能与ACK节点名称规范化一下。ack控制台节点相干信息显示也可能更欠缺一下。而后接着吐槽，报警这里fs.inode.utilization_device设置的阈值是85%没有问题，看一下kubelet的垃圾回收：--eviction-hard=imagefs.available<15%,memory.available<300Mi,nodefs.available<10%,nodefs.inodesFree<5%。这是默认的吧压根就没有批改吧？那这个报警与垃圾回收有什么用呢？我就想晓得？ 好吧我本人去批改kubelet配置文件行不行？eviction-hard=imagefs.available<15%,memory.available<300Mi,nodefs.available<20%,nodefs.inodesFree<15%找了一圈我居然无奈确定改批改哪个文件我这里批改能够吗？重启服务后 ps -ef|grep kubelet还是这样 我怂了 ，惹不起！ 我改一下报警行了不？，惹不起我躲了！看一下失常kubeadm集群的配置：我批改了一下kubeadm-flags.env好歹是失效的阿？对不惹不起我躲了....先批改监控报警策略了！而且从根本上来说，托管的服务。这些货色应该是优化好的尽量去缩小用户的操作不是吗?你的 报警跟垃圾回收策略都不统一，搞毛线呢？问题是我集体批改参数他也不失效阿.....这让我怎么玩？毫无舒适感，不想动了！心愿阿里云ack的小伙伴能看到我的吐槽，没有方法阿吐槽无门阿....太居高临下了.....心愿能听一下用户的心声！

阿里云音讯队列 MNS 定位是 RocketMQ 轻量版，提供轻量模型、轻量 HTTP RESTful 协定，运维轻量、计费轻量，具备易集成等特点。 为了帮忙大家由浅入深的对阿里云音讯队列 MNS 有更加全面的理解，同时冀望音讯队列 MNS 可能帮忙大家解决日常工作和生产的问题，特推出音讯队列 MNS 产品训练营课程，课程中不仅有对产品简略形象的介绍，还有“首秀”的入手实际学习课程。 参加本次音讯队列 MNS 训练营，您能够学习并播种到： 音讯队列 MNS 的根底概念及个性音讯队列 MNS 的最佳实际及案例基于 MNS，0 根底轻松构建 Web Client除了学习层面的播种，流动期间，实现所有参营工作且考试通过的前 20 名同学可取得（若问题雷同按考试工夫程序排名），即可收费取得小米充电宝。 流动工夫：8月10日-8月31日（工作日期间） 参加形式：（举荐 PC 端登陆体验） 点击文末“浏览原文”；扫描海报二维码。  点击此处，立刻报名加入吧～

作者：秋雨陈 前言随着 Serverless 架构一直倒退，各云厂商和开源社区都曾经布局 Serverless 畛域，一方面体现在云厂商推出传统服务/业务的 Serverless 化版本，或者 Serverless 计算平台；另一方面体现在开源社区中 Serverless 我的项目逐步丰盛起来，无论是平台类还是工具类的开源我的项目、或者是框架类的开源我的项目，都如雨后春笋般疾速成长。 任何技术，在这样凋敝倒退背地，都会疾速降级和迭代，Serverless 架构也不例外，从阿里云的 FaaS 产品倒退过程中，不难看出 Serverless 架构在提效和降本的路线上一直的场景化，特色化；在产品状态上也一直的趋于残缺化，统一化，尽管间隔 “大道至简” 还有肯定的间隔，然而也只是工夫的问题了。 从思维到产品升级Serverless 架构在一直倒退，无论是产品状态还是技术架构都能够用突飞猛进来形容。 Serverless 精力的更迭最后，Serverless 架构指的是 FaaS 与 BaaS 的联合，认为开发者能够不必破费更多的精力在服务器等底层资源上，而是能够将精力放在更具价值的业务逻辑之上。这也是文章《Serverless Architectures》中所强调的观点。 但随着工夫倒退，大家发现，对于 Serverless 架构这样的形容过于薄弱，没有凸显出 Serverless 架构为业务带来的技术红利，也没能体现出 Serverless 所交付的心智。 所以 UC 伯克利在《Cloud Programming Simplified: A Berkeley View on Serverless Computing》中对 Serverless 架构进一步的定义：对于被认为是 Serverless 架构的服务/产品还须要具备按量付费和弹性伸缩的特点，并认为， long-run 的运行模式并不合乎 Serverless 精力。 云计算相干技术的倒退，往往有一个特点：云厂商的驱动性十分强，因为云厂商往往会最先感知到普遍性的用户需要，并且有足够的数据撑持其做出正当的判断与翻新。所以 Serverless 架构的翻新很多时候也都是由厂商驱动的；在事件驱动与函数计算的倒退下，厂商逐步发现函数计算的模式 “短时运行” 没有方法满足更多用户的诉求，此时一种 long-run 模式的 Serverless 计算服务就逐步的被孵化进去了。至此，Serverless 架构也从最后的薄弱，逐步欠缺，通过 “自我变革”，实现了新一轮业务能力的自我丰盛与产品性能的自我完善。 随着 long-run 模式逐步被开发者们认可，传统 Serverless 架构的定义有点 “心心相印”：既不能在模式上笼罩最新的 Serverless 产品纬度，也不能在状态上形容清 Serverless 的个性。 ...

近日，杭州云霁科技有限公司 CloudIaC（v1.0.0） 通过阿里云产品集成认证测试，与阿里云旗下的阿里云容器服务 ACK、云数据库 RDS MySQL 版深度集成。这意味着在云原生畛域云霁科技与阿里云正式携手单干。此前，云霁科技入选了阿里云首期云原生加速器，本次实现阿里云产品生态集成认证，是继加速器单干之后，云霁科技与阿里云单干的又一次冲破。将来，单方将加大力度构建更加丰盛的云原生产业生态圈，减速云原生在全行业的落地。 阿里云产品生态集成认证是面向阿里云合作伙伴自有产品、解决方案与阿里云相干产品的兼容性、可用性的技术能力认证。取得此认证，证实了云霁科技的技术能力、产品利用程度已满足阿里云相干产品的适配性要求。云霁科技以阿里云技术底座，为用户提供牢靠、无效的产品与解决方案技术服务，这为云霁科技与阿里云生态的严密单干提供了强力的技术保障。 杭州云霁科技成立于 2015 年，在杭州、北京、上海、广州、深圳、佛山、武汉、成都、美国洛杉矶等城市设有团队。公司开创团队来自于阿里巴巴、蚂蚁金服、惠普、建设银行等企业，客户涵盖国有银行、股份制银行、大型城商行、一线保险和证券公司等。 云霁科技的 CloudIaC 是国内首个开源的 IaC （基础设施即代码，Infrastructure as Code）全家桶，旨在从新定义云和基础设施治理。CloudIaC 专门为 IaC 工作流而构建，它是 Terraform 工作流自动化和加强合作的绝佳解决方案，它将易于应用的界面与弱小的治理工具相结合，让用户能够疾速轻松地在云中部署和治理环境。CloudIaC 领有“环境即服务”和“合规即服务”两大模块，“环境即服务”让简单应用环境能够一键部署，一键销毁，弹性伸缩，“合规即服务”让风险管理前置，标准基础设施部署。CloudIaC 同时提供了 SaaS 平台，用户能够通过该平台的自助式服务和 IaC Store 的海量资源疾速体验和搭建所需环境。 阿里云容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器利用治理能力，整合了阿里云虚拟化、存储、网络和平安能力，助力企业高效运行云端 Kubernetes 容器化利用，反对企业级容器化利用的全生命周期治理。阿里云容器产品公布 7 年以来，已倒退为企业客户与阿里云自研“飞天”零碎交互的新界面。相比开源计划，阿里云容器服务在计算密集型利用可实现20%的性能晋升，容器网络延时升高 30%，异构资源利用率晋升 100%，并实现全链路可观测。阿里云容器产品撑持了阿里团体100%利用云原生化，帮忙同年双11的大促资源老本升高50%。目前容器服务 ACK 已全面降级为 ACK Anywhere，在企业任何须要云的中央，提供对立的容器基础设施能力。此前，阿里云入选 Forrester 寰球公共云容器平台领导者象限，这是中国云计算厂商首次进入该象限。 阿里云关系型数据库RDS（Relational Database Service）是一种稳固牢靠、可弹性伸缩的在线数据库服务，基于阿里云分布式文件系统和 SSD 盘高性能存储。云数据库 RDS MySQL 版是寰球最受欢迎的开源数据库之一，作为开源软件组合 LAMP（Linux + Apache + MySQL + Perl/PHP/Python） 中的重要一环，广泛应用于各类利用场景。 将来世界上的每家企业，都将成为数字化的软件企业。数字化转型或者没有对立门路，但经实际验证，云原生是企业实现数字翻新的最短门路。阿里云云原生致力于为企业提供五大外围价值：资源弹性、零碎稳固、利用麻利、业务智能、可信平安，让企业释怀用云，用好云。云霁科技始终以生态搭档的身份与阿里云放弃着深度单干。将来，借助阿里云的“被集成”生态策略与生态集成技术的全面凋谢，单方的严密单干将进入新的阶段，独特为中国数千万家企业提供数字化转型服务。

对于从事IT行业的人来说，想在这行做到久远的倒退，就肯定须要能体现本人价值的货色，能而最直观体现本人价值的货色，除了本人做过的我的项目，其余的就是本人持有的技能证书了。阿里云人才认证恰恰好就是这样一个证书，能帮忙宽广从事IT行业的人晋升本人的职业价值。 随着咱们人类科技的提高，咱们的社会也产生了微小的扭转，信息通信技术的呈现扭转了原有的生产方式，将人力从劳动中解放了进去，也带来了生存的巨大变化。与此同时，很多中小型企业在营业形式上也转变了思路，纷纷将阵地转移到了线上，这样一来就须要大量的技术型人才来保护企业的运行。 于是为了满足市场需求，各大互联网云厂商纷纷推出了本人的人才认证零碎，旨在给市场造就、输送高质量、高技术的人才。阿里云的证书是阿里云依据本身的产品搭建起来的一套体系残缺、层次分明的认证，在业界内有很高的知名度和高认可度。 在阿里云的证书中，ACP这个等级是十分值得考的，尽管这是阿里中等级的考试，然而最高等级的只有一个云计算方向，其余大多数的都在ACP上，能够说对于大多数方向，ACP就是最高等级的了。 对于当初大多数的从业者来说，考的最多的认证就是云计算了，这是很多我的项目的根底，也是很多从业者的根底能力要求。上面小编就简略介绍一下。 阿里云ACP云计算考试内容 1、云服务器 ECS 2、弹性伸缩（Auto Scaling） 3、负载平衡 SLB 4、专有网络 VPC 5、对象存储 OSS 6、内容散发网络 CDN 7、平安（云盾、云平安） 8、云计算通用常识 考试模式：口试 考试分数：一百分，80分通过 考试题型：单选70道，多选30道 考试费用：1200 ACP的考试只能在线下进行，然而有的机构能够约到线上的考试，而且ACP考试只有一次机会，失败了就要再次花钱购买报名券，很多人为了能一次通过，会寻找对应的题库，有须要的人能够到认证大使网站上找找。

2022 年 8 月 3 日，由 LF Edge 主办的第三届 EdgeX 中国挑战赛正式揭幕，阿里云作为本届大赛策略合作伙伴重磅亮相，心愿通过其主导开源的云原生边缘计算智能平台 OpenYurt 与 EdgeX Foundry 的继续深刻单干，独特为宽广开发者构建一个物联网及边缘计算的学习和分享平台，以开源、共享的技术环境解决行业技术问题，促成云原生边缘计算、AIoT 等的利用落地及部署。 随同着物联网利用进一步演进，越来越多理论场景要求数据本地存储、隐衷爱护、低传输时延、低成本，边缘计算技术因而迅猛发展。计算规模和业务复杂度的日益晋升，也对边缘计算的效率、可靠性、资源利用率等一系列能力提出了新的诉求。而云原生技术的特有劣势让解决上述挑战成为可能。 OpenYurt 基于原生 Kubernetes 构建，由阿里云于 2020 年 5 月开源，同年 9 月份入选 CNCF SandBox 我的项目，是业界首个对 Kubernetes 无侵入的边缘计算云原生开源平台。OpenYurt 善于以非侵入的形式，实现云边资源的对立治理和运维，使得边缘节点领有云端雷同的能力。 2021 年以来，OpenYurt 社区与 EdgeX Foundry 已在独特打造 IoT 设施孪生及物模型云原生规范、提供边缘云资源接口对立能准力、欠缺软硬一体化交付模型等方面获得要害停顿。 胡伟琪，阿里云资深技术专家&中间件研发负责人 在本次 2022 EdgeX 中国挑战赛开幕式上，阿里云资深技术专家、中间件研发负责人胡伟琪示意：“云边协同正在成为交通、制作、农业、能源等行业数字化转型的重要驱动力。明天，边缘计算正面临着对性能、效率更为严苛的要求，云原生边缘计算的呈现能够很好地补救边缘侧对数据疾速解决 、疾速迭代更新的麻利要求。 “长期以来，阿里云及 Intel 的工程师始终在相干畛域进行摸索、翻新和实际，并且通过 OpenYurt 和 EdgeX Foundry 开源社区开展积极合作，独特推动云边协同规范的建设，为企业边缘设施的云原生治理能力的大规模落地提供最优门路。心愿通过本次大赛，让更多的企业和开发者理解到两个我的项目，帮忙企业在边缘计算场景下更疾速、更敏捷地进行业务翻新。” 据悉，本次大赛分设两大赛道，别离为医疗/教育/生产行业赛道和能源/工业/供应链行业赛道。大赛评委将围绕创造力、可行性和实用性、落地能力三大维度为稳参赛作品进行打分。除了根底评分外，选手计划中如有额定应用开源组件，如 OpenYurt 等可获附加评分，该附加分计入评审总分。同时，每个开源组件独立设奖，由对应开源组件的反对方提供评审、确定获奖名单，获奖选手最高可取得 5 万元处分。 为帮忙参赛选手更好地理解并使用相干技术，本次大赛还将在 7 月至 9 月继续发展多轮技术培训涵盖初、中、高不同层级，邀请来自 Intel、VMware、阿里云等多家机构的技术专家进行分享，帮忙开发者零碎学习智能边缘计算、云原生零碎常识，理解如何基于 OpenYurt+EdgeX 等开源我的项目，更好地实现云边协同。 ...

阿里云重磅公布全链路数据湖解决方案，次要蕴含开源大数据平台 E-MapReduce(EMR) + 一站式大数据数据开发治理平台DataWorks + 数据湖构建DLF + 对象存储OSS 等外围产品。 近日，阿里云EMR重磅推出新版数据湖Datalake，100%兼容社区大数据开源组件，具备极强的弹性能力，反对数据湖构建DLF，数据湖存储OSS和OSS-HDFS，反对 Delta Lake、Hudi、Iceberg 三种湖格局。同时新版本 Datalake 对接阿里云一站式大数据开发治理平台DataWorks，积淀阿里巴巴十多年大数据建设方法论，为客户实现从入湖、建模、开发、调度、治理、平安等全链路数据湖开发治理能力，帮忙客户晋升数据的利用效率。 另外，解决方案提供了“对立元数据管理、数据入湖、数据存储、缓存减速、弹性计算、容器、数据分析、工作编排、运维治理，以及平安”等全面数据湖能力。通过了工业和信息化部中国信息通信研究院大数据能力专项评测，荣获“云原生数据湖根底能力专项评测证书”。 阿里云全链路数据湖开发治理解决方案架构阿里云全链路数据湖开发治理解决方案应用 OSS/OSS–HDFS 作为数据湖存储，DLF 作为数据湖构建和管理工具，JindoFS 进行湖缓存减速，EMR 作为弹性计算引擎进行湖计算，DataWorks 进行数据开发和治理。DataWorks 各模块与 DataLake 深度集成，从而实现一站式数据湖开发治理。 EMR新版数据湖集群外围运维管控能力介绍弹性能力 弹性伸缩反对按集群负载和按工夫2种模式弹性伸缩组反对多种实例规格反对抢占式实例（相较按量付费老本升高80%以上）反对老本优化模式（弹性比例的按量付费+包年包月）集群管控能力 分钟级别创立和扩容集群，无需手动部署和启动服务欠缺的集群监控和告警体系，笼罩硬件和引擎服务，反对配置告警模板新版数据湖比照Hadoop集群劣势性能更优 速度放慢新版数据湖集群节点组扩容速度失去显著晋升，单批次大规模节点扩容速度晋升80% HadoopDataLake弹性扩容 10 节点4分钟1分10秒弹性扩容 50 节点8分钟1分30秒弹性扩容 100节点10分钟1分50秒反对并发反对工作节点（task节点类型）多节点组并行扩缩容，可能笼罩多种应用场景，业务效率成倍晋升。性能更全 弹性伸缩能力更强能够同时配置按工夫伸缩和按负载伸缩；反对优先下线负载低的节点；配置规定不依赖于是否运行弹性伸缩流动，可灵便批改配置（仅影响下一次触发）。 执行逻辑更贴近应用场景多方位调研用户实在应用场景，性能执行逻辑设计更贴近业务理论。如：1）弹性伸缩扩容策略反对多实例抉择并按程序弹出（兜底库存有余场景），弹性伸缩缩容反对配置优雅下线并默认按负载抉择指标节点下线（缩小缩容时对集群工作影响）2）同一节点组多个弹性规定同时触发时，默认依照用户规定排序顺次失效（灵便应答多种应用场景） 操作体验优化更丰盛的配置提醒和操作疏导，并新增配置项预校验逻辑，升高用户学习老本和操作失败概率。老本更省 弹性伸缩性能更优，性能笼罩更宽泛的场景弹性伸缩失效更快，反对性能更全。能够帮忙用户更快更好地对硬件资源进行麻利治理，依据业务须要设置相干策略，主动变更集群规模，缩小硬件资源节约。 通过灵便配置抢占式实例进一步压缩老本在新增节点组时，提供欠缺的抢占式实例配置策略和兜底策略供用户配置，用户能够依据其业务诉求灵便配置，通过配置抢占式实例可能进一步压缩老本。 与Hadoop集群全面比照 模块性能项新版数据湖集群Hadoop集群集群集群创立工夫均匀工夫小于5分钟。均匀工夫小于10分钟。 集群节点组新增节点均匀工夫小于3.5分钟。均匀工夫小于10分钟。 凋谢API反对。反对。 域名反对Private Zone。hosts地址映射。 磁盘扩容反对热扩容，无需重启集群服务。不反对热扩容，需重启集群服务失效。节点组交换机能够在新建节点组时抉择交换机。仅反对在集群创立时抉择，集群创立后不可更改。 挂载公网能够在创立集群的硬件配置页面的实例区域，抉择是否为节点组开启公网。* 没有节点组类型的限度。 仅反对在集群创立时抉择是否开启公网，创立后如果您须要应用公网IP地址拜访，请在ECS上申请开明公网IP地址，详情请参见弹性公网IP中的申请EIP的内容。 仅反对Master节点组挂载公网。 附加平安组反对。不反对。 部署集 能够在创立集群硬件配置页面的实例区域，抉择是否开启部署集开关。 能够在新增Core节点组时，抉择是否开启部署集开关。性能受限。 节点组状态反对。不反对。 混合节点反对同规格的不同机型混合。 仅反对同规格机型。 弹性伸缩节点反对混合节点。弹性伸缩弹性伸缩弹性伸缩与节点组解耦，从独立的功能模块转为节点组操作，应用更加便捷。须要专用的弹性伸缩组，该节点组不可进行手动扩缩容。 伸缩规定 配置规定不依赖于是否运行弹性伸缩流动，可灵便批改配置（仅影响下一次触发）。 同一节点组多个规定同时触发时，会依照用户规定排序顺次失效。 配置规定受到弹性伸缩状态限度，批改后无奈立刻失效。 同一节点组多个规定同时触发时，随机失效。 伸缩记录丰盛了弹性伸缩记录信息。在查看详情页面新增了触发规定快照和执行后果参数，可能疾速查看触发起因和变更节点信息。提供根底的伸缩记录列表。 指标采集频繁每30秒采集一次。每30秒采集一次。 伸缩流动失效工夫规定利用后1~30秒。规定利用后1~2分钟。扩缩容扩缩容流动 弹性伸缩流动与手动扩缩容流动运行机制雷同。区别仅在于触发条件不同： 弹性伸缩须要弹性伸缩规定触发。 手动扩缩容须要人为触发。 反对暂停弹性伸缩流动。 多个Task节点组的扩缩容流动彼此独立，互不影响。 弹性缩容依据节点负载和创立工夫，智能选中指标节点，缩小业务影响。 弹性伸缩流动和手动扩缩容流动是两套机制，互不兼容。 弹性伸缩流动不反对暂停状态。 同时仅反对一个节点组进行（弹性）扩缩容。 弹性缩容节点抉择具备随机性。高可用与软件应用高可用不再反对本地MySQL作为Hive Metastore数据库。反对本地MySQL作为Hive Metastore数据库。 反对部署集，3台Master散布在不同底层硬件以升高硬件危险。默认不反对部署集。 NameNode与Resource Manager部署于3节点，并不再反对2 Master模式。Namenode与Resource Manager仅部署于2节点，反对2 Master模式。 集群利用组件反对可选必选 + 可选。 Spark2与Hadoop3组合反对。不反对。 Spark3与Hadoop2组合反对。EMR-3.38.0之后版本反对同时部署。DataWorks全链路开发治理能力介绍DataWorks基于EMR-Datalake、EMR-Clickhouse、CDP等大数据引擎，为数据湖/数据仓库/湖仓一体等解决方案提供对立的全链路大数据开发治理平台。作为阿里巴巴数据中台的建设者，DataWorks从2009年起一直积淀阿里巴巴大数据建设方法论，通过智能数据建模、全域数据集成、高效数据开发、被动数据治理（数据品质、数据地图等）、全面数据安全、疾速剖析服务六大全链路数据治理的能力，与数万名政务/金融/批发/互联网/能源/制作等客户携手，助力产业数字化降级。 ...

点击此处，返回 ARMS 产品官网页理解更多详情～

作者：车漾、刘奖、景奇 随着 IT 基础设施从物理机到虚拟机，再到以 Kubernetes 为代表的容器环境，甚至到 Serverless 的逐步演进，明天的计算和利用的状态以日新月异的速度倒退。尤其是 AI 和数据分析等数据智能利用的 Serverless 化曾经成为了一种趋势。 Gartner 曾预测，到 2023 年 70% 的 AI 利用将基于容器和 Serverless 技术开发。这是大家置信的将来，但利用 Serverless 化之路充斥艰苦，比方现有利用迁徙门槛高，供应商锁定，基础设施响应能力有余，可观测性欠缺，存储接入繁琐等。 这些都是用户对于 Serverless 根底平台提供商的刚性需要，谁能更加凋谢，谁能更好提供 Serverless 利用所运行的基础设施和生态系统，谁能力成为客户的最终抉择，而不仅仅是谁提供的计算资源弹性能力更强或者老本更低，这理论是云计算巨头的内功较量。 （图片来源于网络） 本文首先聚焦到 AI 和大数据等利用 Serverless 化的最大挑战：计算和存储拆散架构带来的数据拜访提早和近程拉取数据带 宽 微小的挑战。尤其在 GPU 深度学习训练场景中，迭代式的近程读取大量训练数据办法会重大拖慢 GPU 计算效率。 Serverless 的数据拜访挑战Serverless 云平台对用户提供的外围能力就是极致弹性，然而这里探讨的弹性并不只是资源弹性，而是站在用户视角的利用弹性或者说业务弹性，即从用户决定扩容开始到利用真正就绪提供服务的端到端工夫。资源弹性工夫是其中很重要的局部，计算资源可能实现秒级，甚至毫秒级扩容，相干基础设施就很快会面临微小的压力，其中最常见的基础设施就是存储。如果存储系统的 IO 吞吐能力跟不上实例变动的速度，例如对于业务来说，容器实例 2 秒就实现了扩容，但还须要花几十秒钟甚至几分钟期待从存储下载数据，那么极致弹性也就无从谈起。 应该说 Serverless 容器化的技术体系对于传统的存储系统提出了新的挑战： 1. 高密拜访：计算资源无存储能力，数据齐全下沉到存储系统，导致并发数据拜访压力陡增。这一方面影响存储系统的稳定性，另一方面也会打满存储系统服务带宽。 2. 网络延时:计算存储拆散架构拉长了存储拜访链路，跨网络通信数据和元数据拜访的额定提早。 3. IO 吞吐能力的扩容老本高：传统分布式存储带宽与吞吐仅和数据应用容量成正比，而 Serverless 平台会创立大量的容器并发的拜访存储系统的数据，会触发存储系统拜访限流。这就造成计算资源极致弹性与存储系统无限带宽之间的矛盾。 换而言之，Serverless 的大数据和 AI 场景须要数据分流（Data Offloading），缩短数据读取链路和提供弹性的 IO 吞吐能力。然而思考到现有云存储系统的稳定性，老本和通用性，这个架构演进会是一个任重道远的工作。 Fluid：利用应用数据过程的形象Fluid 是云原生计算基金会（CNCF）旗下的官网沙箱开源我的项目。该开源我的项目定位于面向云原生场景下的数据密集型利用减速和编排，社区次要开发者和维护者来自阿里巴巴、南京大学等多家知名企业和高校。Fluid 的思路是将存储系统的能力进行分层，合成为数据存储和数据拜访能力，并且将一部分的数据拜访能力向上平移到计算集群中；并且在大数据（AI）场景下，对“计算工作应用数据的过程”进行形象，提出了弹性数据集 Dataset 的概念，并将数据分布式缓存技术与云原生 主动弹性（Autoscaling），可迁徙（Portablity），可调度（Scheduling） 能力相结合。 ...

中秋将至，EMAS Serverless帮你4步轻松搭建专属相册小程序，用不一样的形式记录家庭离散时刻。参加流动并实现试验即可进行抽奖，罗技G512游戏机械键盘、机械鼠标等3000份好礼，100%中奖！赶快口头吧～ >> 点击立刻参加流动 << 产品介绍：EMAS Serverless 是阿里云一站式利用研发平台 EMAS 旗下的一款子产品，是面向小程序场景提供的 Serverless 开发、经营套件，开发者无需关怀服务器和底层设施运维，专一于代码逻辑和业务自身，具备极简运维、多端适配、按需应用、弹性扩容等劣势，帮忙开发者疾速部署小程序。 云函数：提供NodeJS运行环境，开发者能够将代码打包提交到云端，无需搭建运维服务器。云函数主动实现机器调度与函数部署，弹性扩容，按量免费，轻松应答突发流量。云数据库：基于MongoDB文档型数据库，数据以JSON格局存储。数据库中的每条记录都是一个JSON格局的文档对象。一个数据库能够有多个汇合（相当于关系型数据中的表）。云存储：反对将文本、图片、视频等文件存储到云端。开发者能够在小程序端和控制台应用云存储性能。图片上传胜利后，零碎会主动生成一个资源链接。开发者能够在小程序中应用该图片地址。参加EMAS Serverless试验，赢罗技游戏机械键盘！1、流动介绍本试验基于 EMAS Serverless 的云函数、云数据库、云存储等云服务能力一站式疾速开发小程序《私人云相册》。Demo 次要包含如下性能： 相册治理上传相片每日壁纸（该性能利用云函数定时工作，每天从必应复制一张壁纸）珍藏壁纸通过本试验教程，您将疾速上手基于云函数、云数据库、云存储等云服务能力一站式疾速开发多端小程序。 2、流动工夫：8月15日 10:00 - 8月31日 23:59参加形式：举荐PC端进行体验 3、流动步骤：Step1 ：实现试验场景，疾速开发小程序利用EMAS Serverless 的云函数、云数据库、云存储，部署《私人云相册》小程序Step2 ：参加抽奖，赢丰富好礼实现场景体验取得一次抽奖机会，每人只限一次，100%中奖！总计3000件精美礼品！抽完为止！Step3：填写收货地址请依照规定格局填写xx省xx市xx区地址4、3000份流动奖品 罗技G512游戏机械键盘 罗技G512机械鼠标 随机T恤 USB小风扇 4.99元EMAS Serverless根底版套餐代金券 3元猫超卡 8.15-8.31流动期间实现一个场景体验，即可参加抽奖！抽完即止！罗技机械键盘、机械鼠标等3000份好礼，100%中奖 >> 点击立刻参加流动 << 欢送退出EMAS开发者技术交换群：35248489

对于明天的分享主题——“平安生产”，内容次要分为三大部分： 第一局部是平安生产的背景，以及咱们对于平安生产这个畛域的了解；第二局部次要介绍阿里巴巴团体的平安生产工作到底是怎么发展的，借此给各位有作为参考和借鉴；第三局部是咱们提炼的平安生产整体计划，帮忙在座的各位去到咱们本身的企业或者环境下，去落地平安生产。数字化平安生产背景谈到平安生产，首先咱们要看一个行业大背景，其实刚刚我的共事曾经讲到了，就是当初各行各业都在做本身业务的数字化转型降级。咱们的业务开始做上云、线上化，利用架构开始做云原生革新。当咱们每一个业务都跑到线下来之后，咱们就会发现，原来传统的平安生产理念及管理模式，也须要转变成线上化、数字化。 随着线上化的零碎越来越简单，业务故障无奈防止。故障的产生，对咱们企业的影响是微小的，怎么样晋升故障的定位、解决能力及恢复能力，是现阶段平安生产工作中最重要的指标。 在业务数字化转型降级的过程中，咱们每个企业都应该同时去思考，怎么同步实现数字化平安生产体系的建设。 从业务视角的平安生产挑战说起 对于平安生产，从以上几个近期产生的故障能够看到，不仅仅是咱们一般的企业，就算是在平安生产畛域重度投入的国内外大型互联网公司，也会呈现业务故障。故障产生之后不仅仅是业务中断、经济损失，舆情影响也会带来十分大的挑战。咱们怎么样来帮忙大家把平安生产工作体系建设好？就是明天咱们探讨的外围主题。 在阿里巴巴团体外部，通过十多年的摸索，咱们积淀了一系列的产品和服务体系，以及平安生产建设的方法论。咱们总结出了“高可用、稳固压倒一切”，作为咱们面对业务侧平安生产挑战的指导思想。 什么是数字化平安生产 明天咱们讲数字化平安生产，大家可能第一印象想到的平安生产还是比拟传统的。比方一些工厂、车间、煤矿或者建筑工地上，咱们常常会看到一些标语、海报和一些相干的理念。传统的平安生产，是指在生产经营流动中，为了防止造成人员挫伤和财产损失的事变而采取相应的事变预防和控制措施。 咱们明天探讨的这个数字化平安生产，其实是跟咱们的业务数字化转型降级是相结合的，次要解决企业业务连续性治理问题。 如产生预期或无预期的事变或灾祸时，企业以正当的老本和资源爱护重要的业务流动，确保在规定的工夫内复原继续运行，最大水平地缩小灾祸带来的冲击并将中断影响降至最低。 数字化平安生产，有以下几方面的特殊要求： 数字化赋能的平安生产。 业务从线下转移到线上之后，实现业务全生命周期触点的数字化革新。这时，平安生产的重心也会从线下转移到线上，同时平安生产工作自身也须要数字化赋能。云原生加持的平安生产。 数字化转型带来了架构的降级，所有的零碎都在云上，都是利用先进的云原生、微服务架构设计的。咱们的平安生产平台也须要同步降级，去无缝连接适配云原生的产品能力，以及面向未来架构的扩大能力。最佳实际的平安生产。 平安生产体系建设须要通过实际的测验。在阿里巴巴团体外部，咱们有个一百多人的团队，在平安生产建设方面继续摸索，积淀了一套非常适合各行各业的最佳实际，并且还在继续演进。数字化平安生产建设内容 基于以上探讨，为了做好平安生产工作，核心内容咱们拆解成三个局部，就是事先、事中、预先建设。 事先： 咱们要有相干的组织架构保障，要有事先的制度流程体系、零碎架构的建设，须要具备相干零碎的水位监测、故障监测能力，以及与 SLA 匹配的防护、切流、变更管控治理能力。事中： 咱们要做到麻利疾速协同，让故障疾速发现、疾速定位、疾速复原。比方在阿里外部，双十一或者说大的故障场景，咱们通常须要协同上百人、甚至是上千人的团队。在这样的一个背景下，首先咱们须要对立的机制保障各自为政，以及上一位共事提到的全链路监测（可观测）的能力，保障疾速发现。另外还须要系统化的能力做事件处理过程的自动化协同，依赖零碎的 trace 及拓扑能力实现疾速定位，以及须要依赖零碎的防护能力及单元化容灾多活，真正实现故障的疾速复原。预先： 咱们须要去反思，总结根因，定义 action。每一个故障应急实现后，咱们都须要做复盘，定级定责，产出零碎改良项，保障咱们的整个架构继续迭代晋升。对于管理者，咱们须要去剖析故障的起因是什么，处理过程的团队配合效率怎么样，分团队分产品的稳定性数据统计，而后保障咱们整个平安生产治理的体系是可度量、可考核、可治理的。最初通过可视化的能力，指标化、全局化把控业务平安生产。阿里巴巴团体最佳实际阿里巴巴团体寰球运行指挥核心 首先在组织保障层，咱们有一个组织叫寰球运行指挥核心，也就是 GOC。在团体外部，有六十多个业务 BU 把所有平安生产相干的业务，接入 GOC 对立协同解决。 而后是咱们刚刚说到的监测（可观测），这是十分重要的一个环节。咱们会把所有的可观测，以及人工反馈（比方淘宝客服、阿里云客服收集的反馈），汇聚到对立的事件核心，利用系统化平台做治理。 最初所有的故障应急都汇聚到两岸三地的指挥核心，相应的应急值班同学，利用应急协同、故障定位、快恢工具进行故障应急与快恢处理，并且进行预先复盘与改良，通过机制经营等多种策略管控整个团体的平安生产危险事件。 平安生产体系大图 平安生产是一个残缺的体系，借助这个架构图给大家做一个大抵的介绍，团体的平安生产体系比拟大，咱们把整体工作拆分成一个个小的模块。 首先有平台的技术能力撑持。 通过后面的介绍，咱们理解了平安生产工作波及很多不同角色的人，来自不同业务零碎的可观测数据，平安生产治理须要压测、故障应急协同、演练、定位、切流、复盘等能力，咱们团体外部有相应的一个平台做无效的撑持。 在这个平台上，建设各个领域的零碎，包含故障治理、多活、全链路压测、变更管控等这些能力都是在这个大的平台下面做对立的撑持，平安生产平台的建设， 自身也是平安生产工作的数字化转型。 在平台的下层，是相干的管理体系、数据经营、技术文化建设。 晚期咱们在做平安生产工作的时候，最大的体感就是无奈度量，出了故障之后无奈定位是哪里出了问题、谁的问题，通过故障等级定义、故障分、稳定性分等机制体系及经营流动的建设，能够实现平安生产工作的可度量可考核。 而后平台和体系建设须要配合相干的演练来做标准化的验收， 保障这些体系和产品能力可能无效的落地并发挥作用。 平安生产外围因素 人员&组织平安生产的外围次要有三局部，第一局部就是人员组织的架构建设，咱们认为平安生产是企业的一把手工程，须要建设一个自上而下的对立组织，可能把所有平安生产能力协同起来。 在团体外部，咱们是有这样一个垂直的组织架构，指挥核心是和每个业务 BU 平级的一个部门，而后上面有相应的反对各个业务 BU 的业余角色，横向的话有平安生产的值班长、仲裁委员会等这样的一些组织角色，保障咱们的体系可能无效落地。 制度&流程第二局部次要是机制流程，团体通过十多年的建设，积攒了十分多的制度流程。 全团体的对立的故障等级定义： 为应急过程的资源调度、决策提供了量化的规范；标准化的应急流程： 让事件处理快捷、有序；故障分、稳定性分的考核规范，对立掂量平安生产的成绩；故障定级、定责、争议协商机制： 保障了平安生产工作的长效机制。工具平台最初一部分就是工具。团体的制度和流程不是仅仅停留在纸面，或者挂在墙上的。咱们所有的机制流程都是有相应的零碎平台做运行撑持，而后基于咱们的零碎能力、机器人、NLP 技术等，做到无效的落地，把所有的这些机制落到理论的每一天的工作，每一个执行环节当中。 故障等级定义 故障等级定义是平安生产体系的运行根底。咱们把生产环境中，无论什么起因造成的服务中断或者服务品质降落及体验降落对立定义为故障。大家留神这是基于业务视角去定义的故障，它的益处就是可能先于用户发现，相比传统的监测准确度更高。 而后再往上层的话，咱们会有很多撑持平台，如中间件、数据库、云平台、网络、服务器等等，上层的指标及故障定义，咱们会依据各个业务的特点来针对性的做定义。然而总体准则还是以业务影响为主，从上往下，只是上层零碎的业务，通常就变成了下层零碎的业务依赖。 基于故障等级定义的根底，理论落地的时候，在团体外部有十分多细分品种。这里简略列举几个罕用类别：P 序列示意通用等级定义、D 序列代表数据品质等级、S 序列代表影响重要客户水平、E 序列代表舆情等级、 I 序列基础设施相干等级。 每一个序列咱们通常有 4 个级别，4 代表一般故障，1 代表重大故障，数字越小紧急水平越高、重要性越高。 ...

作者：赵明山（立衡） 前言Kruise Rollout 是 OpenKruise 社区开源的渐进式交付框架。Kruise Rollout 反对配合流量和实例灰度的金丝雀公布、蓝绿公布、A/B Testing 公布，以及公布过程可能基于 Prometheus Metrics 指标自动化分批与暂停，并提供旁路的无感对接、兼容已有的多种工作负载（Deployment、CloneSet、DaemonSet）。 近期也在《2022 凋谢原子寰球开源峰会》下面做了主题分享，以下是次要内容。 什么是渐进式交付？ 渐进式公布次要区别于全量、一次性公布。它次要蕴含以下特点： 增量的公布过程：艰深讲就是咱们能够将一次公布分成多个批次，并且能够管制每个批次的开始与进行。 实例与流量双重维度的灰度：比方社区常见的金丝雀公布、A/B Testing 公布、蓝绿公布。阶段可验证性：就是公布的每个批次，能够验证公布的正确性、是否合乎预期。 上面咱们来看一个理论的例子。 如果线上是 X 版本，当初须要公布到 Y 版本。首先，会将公布分为多个批次（比方，第一批只公布十个实例）；而后，灰度肯定规定的流量到 Y 版本，比方：像淘宝每次重大公布，会应用 A/B Testing 的形式，只将公司员工灰度到新版本；最初，验证新版本的衰弱状况，验证 OK 后，能够反复上述的过程，实现残余的批次。如果在这个过程中发现了任何异样，能够疾速回滚到 X 版本。通过下面这个例子，渐进式公布与全量公布相比，减少了很多两头的验证过程，渐进式公布能够说是极大的进步了交付的稳定性，尤其是针对一些大规模的场景而言，渐进式公布是十分有必要的。 渐进式公布与 K8s 工作负载之间的关系 K8s 当中所有的 Pod 都是由工作负载来治理的，其中最常见的两个工作负载就是 Deployment 和 statefulset。Deployment 对于降级而言提供了 maxUnavailable 和 maxSurge 两个参数，然而实质上来讲 Deployment 它只反对流式的一次性公布，用户并不能管制分批。StatefulSet 尽管反对分批，然而跟咱们想要的渐进式公布的能力还有比拟大的间隔。 所以渐进式公布与工作负载从能力上讲是一种蕴含关系，它除了根底的 Pod 公布之外，还应该蕴含流量公布和进度管制。既然能力上曾经梳理分明了，上面咱们就要看看实现，如何去设计和实现 Rollout 能力也是十分重要的。在这咱们能够思考一个问题，从设计的角度看他们也是蕴含关系吗？ Rollout 计划的设计理念筹备开始做这件事件前，必定要先调研一下社区的优良计划，看看其他人是如何解决的。 Argo Rollout 是 Argo 公司推出的 Workload，它的实现思路是：从新定义一个相似于 Deployment 的工作负载，在实现 Deployment 原有能力的根底上，又扩大了 Rollout 的相干能力。它的长处是工作负载内置了 Rollout 能力，配置简略、实现也会比较简单，并且目前反对的性能也十分的丰盛，反对各种公布策略、流量灰度和 metrics 剖析，是一个比拟成熟的我的项目。 ...

不必掏手机，不必登微博，借助 SAE 定时工作就能够实现每小时获取实时新闻热搜！SAE 场景体验炽热开启中，参加还可领好礼！ Job 作为一种运完即停的负载类型，在企业级开发中承载着丰盛的应用场景。Serverless Job 将 Serverless 技术所带来的普惠红利从应用领域向外延展至工作畛域，通过联合 longrun+shortrun 的应用场景和最佳实际打造成为 Serverless 一体化企业级开发运维平台，以满足不同行业的差异化诉求，为用户提供更加欠缺多元的能力反对和稳固牢靠的技术保障。 Serverless Job 反对将传统的 XXL-JOB 零革新迁徙至SAE中，本场景将采纳 XXL-JOB 作为示例。创立并执行 demoJobHandler 和 shardingJobHandler 两个工作，让用户体验整个应用流程。 流动地址https://developer.aliyun.com/... 流动工夫2022.7.25-2022.8.2 流动步骤Step 1：实现《3 分钟创立 Serverless Job 定时获取新闻热搜》及《XXL-JOB 零革新迁徙》场景搭建。 Step 2：实现《3 分钟创立 Serverless Job 定时获取新闻热搜》场景搭建，即可点击流动页面中的【支付奖品】链接，填写地址提交支付小风扇；同时可点击上面的【支付权利券】支付阿里云 5 元代金券。（流动期间每个工作日 10 点刷新 70 个小风扇和 500 张代金券） Step 3：支付的小风扇会在流动完结后 15 个工作日内邮寄给您！ 试验过程中有任何疑难，欢送搜寻退出钉钉群（44810049）探讨！ 点击下方“此处”中转场景体验！

作者：学仁 简介K8s Job 是 Kubernetes 中的一种资源，用来解决短周期的 Pod，相当于一次性工作，跑完就会把 Pod 销毁，不会始终占用资源，能够节省成本，进步资源利用率 阿里任务调度 SchedulerX 和云原生联合，重磅推出可视化 K8s 工作，针对脚本使用者，屏蔽了容器服务的细节，不必构建镜像就能够让不相熟容器的同学（比方运维和经营同学）玩转K8s Job，受害容器服务带来的降本增效福利。针对容器使用者，SchedulerX 岂但齐全兼容原生的 K8s Job，还能反对历史执行记录、日志服务、重跑工作、报警监控、可视化工作编排等能力，为企业级利用保驾护航。架构图如下： 个性一：疾速开发 K8s 可视化脚本工作Kubernetes 的 Job，常见用来做离线数据处理和运维工作（比方每天凌晨 2 点把 mysql 数据同步到大数据平台，每隔 1 小时更新一次 redis 缓存等），个别以脚本实现居多。这里以一个简略的场景举例子，来比照两种计划的差别。 Kubernetes 原生解决方案K8s 调度的最小单位是 Pod，想跑脚本工作，须要提前把脚本打包到镜像里，而后在 YAML 文件中配置脚本命令，上面以通过 python 脚本查询数据库为例子： 编写 python 脚本 demo.py#!/usr/bin/python# -*- coding: UTF-8 -*-import MySQLdb# 关上数据库连贯db = MySQLdb.connect("localhost", "testuser", "test123", "TESTDB", charset='utf8' )# 应用cursor()办法获取操作游标 cursor = db.cursor()# SQL 查问语句sql = "SELECT * FROM EMPLOYEE \WHERE INCOME > %s" % (1000)try: # 执行SQL语句 cursor.execute(sql) # 获取所有记录列表 results = cursor.fetchall() for row in results: fname = row[0] lname = row[1] age = row[2] sex = row[3] income = row[4] # 打印后果 print "fname=%s,lname=%s,age=%s,sex=%s,income=%s" % \ (fname, lname, age, sex, income ) except: print "Error: unable to fetch data" # 敞开数据库连贯db.close()编写 DockerfileFROM python:3WORKDIR /usr/src/appCOPY requirements.txt ./RUN pip install --no-cache-dir -r requirements.txtCOPY demo.py /root/demo.pyCMD [ "python", "/root/demo.py" ]制作 docker 镜像，推到镜像仓库中docker build -t registry.cn-beijing.aliyuncs.com/demo/python:1.0.0 .docker push registry.cn-beijing.aliyuncs.com/demo/python:1.0.0编写 K8s Job 的 YAML 文件，image 抉择第 3 步制作的镜像，command 的命令为执行脚本apiVersion: batch/v1kind: Jobmetadata: name: demo-pythonspec: template: spec: containers: - name: demo-python image: registry.cn-beijing.aliyuncs.com/demo/python:1.0.0 command: ["python", "/root/demo.py"] restartPolicy: Never backoffLimit: 4咱们看到要在容器服务中跑脚本，须要这么多步骤，如果要批改脚本，还须要从新构建镜像和从新公布 K8s Job，十分麻烦。 ...

作者：古琦 介绍微服务开发的问题微服务架构下咱们在开发中遇到的常见的问题有以下 4 个： 多语言问题：有多种编程语言，node.js, JAVA, GoLang…微服务须要为每种语言都保护一种中间件 SDK 降级推动难：SDK 降级须要推动业务利用进行代码批改和公布，对业务有打搅，业务压力下推动老本高迭代速度慢：因为多语言多版本的存在，须要破费大量精力去保护历史版本，升高了迭代速度，降级速度慢 （在数据面选型上也思考研发效力的问题多版本问题：每种语言的 SDK 都面临版本升级，同时存在大量不同的版本相互拜访，兼容性和测试保护老本微小 为了解决这些问题，服务网格的 Sidecar + APP 模式是一个很好的计划 服务网格Service Mesh 是一个专门解决服务通信的基础设施层。它的职责是在由云原生利用组成服务的简单拓扑构造下进行牢靠的申请传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务通明。服务网格的概念被提出也有很多年了，服务网格的也呈现了很多不同类型的实现，比方 Istio、Linkerd，Open Service Mesh 等等，还有呈现相似 ebpf + envoy，proxylessMesh 等等其余形式的服务网格实现，其实都是在想如何解决当下生产、开发中的问题，咱们熟知的关注度最多还是 Istio，架构如下： 通过 Sidecar 和业务利用拆散，管制面 Istiod 实现对整个流量的管控，基于 Istio + Envoy 的能力实现了微服务的连贯、平安、管制和可观测，服务网格在微服务架构下体现了与利用解耦的平台级服务治理能力，推出来对立的多协定多语言的微服务治理，同时放弃了基础架构与利用解耦，升高降级和运维的老本，而且实现了微服务间的安全可靠通信，让不同类型的微服务的通信具备可观测。 阿里云专有云服务网格能力服务网格的劣势被大家宽泛认可，直到明天曾经有很多的用户将服务网格应用在本人的生产业务零碎中，然而对于很多的常见的用户而言应用和运维这样的一套零碎还是过于简单，在通常的应用中，可能咱们只须要做一次灰度公布，这时候就波及不同规定的配置，非常容易出错，如何定义好利用的 VirtualService、DestinationRule 等规定对于大部分使用者而言都须要很高的学习老本，为了缩小应用的老本和运维难度，阿里云专有云服务网格通过高度的产品化能力将服务网格的能力推出，只须要依照常见的思路去操作控制台，即可轻松的实现比方灰度公布、标签路由、鉴权、全链路等能力。 上面是一张阿里云专有云服务网格的能力大图，笼罩了协定、环境、服务治理、可观测、平安生产几个方面： 接下来来介绍下咱们的产品能力： 服务治理流量治理流量治理的能力很多，蕴含了负载平衡、熔断、限流、超时、重试、流量镜像、连接池治理、故障注入、同 AZ 路由、服务 Mock。 限流的能力提供了单机的限流、基于 header 的限流、Path 的限流。 故障注入中除了开源社区的服务级别的故障外，还提供了针对服务单个 Pod 的故障注入，这样能够进行单个 Pod 的测试。 服务 Mock 的能力能够为开发人员 Mock 指定接口的返回，在接口还没有开发实现的时候，进步开发测试的效率，服务 Mock 的配置中能够抉择申请的门路、端口号、办法、状态码、Header、返回 Json 数据。 ...

作者：排列昂、昕辰、龙琛、黛忻 我的项目背景SKG 公司是一家专一于高端衰弱产品的研发、设计与制作的企业。专一为消费者提供粗劣、时尚的高端产品，以及极致的按摩仪产品体验。 随着市场需求的迅速变动，SKG 的 IT 零碎也逐步面临着库存不精确、线上线下渠道无奈协同、部署架构不灵便、IT 响应速度过慢等问题，为了能适配销售拓展、提高效率、增强规模化经营，SKG 同阿里云达成策略单干，打造基于线上线下买通，并笼罩全渠道利用场景的渠道中台我的项目。本次渠道中台建设面向 SKG 线上、线下、礼品等渠道的营销治理，买通经销商、导购、后端 SAP 多端业务数据，同时整合面向 C 端会员数据和渠道批发终端销售数据，以全新的互联网架构云化零碎能力撑持业务疾速倒退。 基于底层渠道中台构建的营销经营治理平台、经销商门户、导购终端小程序，须要有多端触达能力，同时满足不同端的个性化业务诉求和拜访特点，要求中台有灵便的扩大定制能力、以及适配不同渠道流量需要的弹性能力。 现状问题&剖析在渠道中台建设之前、SKG 次要是租用 IDC 机房部署利用，也有业务跑在云上，整体是 IDC 机房+ECS 自建利用配套 RDS 等云产品的混合云架构。整套零碎架构须要手工保护的中央比拟多，比方：利用公布、开源产品搭建接入、云服务集成、集群保护等根本都是单点治理、手工操作。老零碎交付过程中和转维后痛点有： 麻利协同、DevOps 等的成熟度低：过来我的项目迭代短少全生命周期管控，对问题和工作进度的跟进次要靠线下沟通、短少在线化追踪工具；DevOps 流程短少自动化的工具撑持，如业务利用的公布上线，根本都是人肉公布，公布耗时长、流程低效、且容易产生线上平安故障。 利用上线部署繁琐：上线需进行资源评估、应用服务器购买、装置配套软件初始化等操作流程较长；此外还须要搭配集群监控、公布&调度脚本服务治理、配置管理、日志备份等能力，都须要独自部署配套组件或零碎。 自行施行容器化存在上手老本：开发对 K8s 等容器治理平台底层细节不相熟、绝对比拟黑盒，呈现问题排查进度较慢。 弹性伸缩不不便：业务侧有肯定的峰谷，而在低谷期资源利用率很低；扩容须要从新走一套上线流程、且扩容后不容易下机器; 后续中台上线之后、预计会拆出更多的微服务利用、但这些利用因承接的业务场景不同流量不平均，须要有更灵便的弹性策略。 前期运维老本高：不单须要保护利用自身、还须要保护整套基础设施及对应的配套零碎；须要投入较多的额定人力技术选型&比照基于以上痛点以及其余中台我的项目的施行教训，项目组在渠道中台项目前期做技术选型、架构设计时，一开始就否决了在 ECS 或 K8s 上间接部署利用的计划，心愿有一个省事的“容器托管平台”。尽量减少运维老本、屏蔽底层细节，对开发上手敌对、且能较大化进步部署公布效率，具体来说，次要心愿达到以下几个指标： 心愿有对立的治理平台进行在线化交付，全生命周期管控，以此来进步我的项目施行效率，该平台需具备麻利协同、DevOps、品质保障等能力，尤其是具备 CI/CD 流水线自动化部署至选型的容器托管平台的能力，用于保障我的项目交付品质、晋升我的项目交付效率、同时升高交付老本。我的项目采纳基于 Spring Cloud 的微服务架构、须要容器平台能无缝兼容。心愿平台能屏蔽底层 ECS 和 K8s 的运维工作，开发大部分工作能够在控制台实现，不须要投太多精力在运维下面，能够专一在业务性能开发上。有肯定的弹性伸缩能力、扩缩容比拟不便、可能定制性的做一些资源优化。微服务利用的配套设施要齐备：如灰度公布、流量管制、近程调式、监控等等，可能不便的集成。基于以上的一些诉求，咱们举荐了基于 SAE（Serverless 利用引擎）的无服务器化容器平台计划、并做了一个两者的比照（如下表格）： 我的项目交付停顿我的项目在施行过程中深度应用了阿里云飞天技术服务平台——大禹进行在线化交付，通过平台进行对立的管控和赋能。 目前 SKG 渠道中台已上线包含微服务网关、微服务中心、前台 Portal、终端小程序、前端 Node 利用等前中台所属 20 多个利用全副部署在 SAE 上；上线过程不须要花太多额定的工夫做零碎革新或适配，只须要在控制台做一些必要的配置即可，且上线后平台运行安稳。 渠道中台业务零碎的研发态和运行态大图如下所示： SKG 渠道中台研发态&运行态大图 我的项目交付过程中的直观感触CI/CD 自动化部署至 SAE：通过大禹提供的 CI/CD 流水线能力将业务利用自动化部署至 SAE，彻底替换原来的人工部署、人肉运维的低效形式，在晋升利用部署效率的同时，也无效升高了利用公布变更的危险，实现了可控部署、平安生产的成果。 免运维&聚焦业务：以往相似规模的集群和利用数、至多须要配置 2 个专门的运维；应用 SAE 后根本免运维、省去专门运维投入；一些 SAE 控制台配置操作根本由开发兼职即可；以往保护利用集群、常常须要排查 K8s 集群和 ECS 底层的一些问题；应用 SAE 这块根本不必关注。 良好兼容各类微服务框架：对基于 Springboot、Spring Cloud、Dubbo 等微服务框架开发的利用兼容较好、同时很不便的集成了 ACM、ARMS 等云产品；屏蔽了局部底层细节，能够做到一键低配置部署。 弹性伸缩、疾速扩缩容：弹性策略灵便、在做资源优化的时候较为不便调整。我的项目交付成果SAE 指标全副 20+利用初始化配置-创立-部署到 SAE 上只须要 2-3 个小时，人效晋升 4 倍；资源老本比独自购买机器节俭 30% 以上；因为 SAE 反对 0.5core 的规格，开发测试环境资源开销得以升高 50% 以上；扩容效率则从按天计进步到分钟级。 ...

开源是根底软件的基本。云+开源，将独特成为数字世界的根。将来数字世界的根底软件应该建设在开源之上，须要全行业共建、共享。因而，阿里云不仅踊跃拥抱开源，也被动回馈开源，引领开源，开源曾经成为了阿里技术策略之一。 7 月 28 日，阿里巴巴团体 CTO 程立受邀加入 2022 凋谢原子寰球开源峰会，并在主论坛演讲中提到，容器技术是从阿里外部实际倒退到云上商业化，并逐渐成为寰球容器技术引领者。 他提到，“阿里云是寰球 Kubernetes 社区重要企业贡献者，为寰球云原生开源社区做出了重大贡献。2017 年，阿里云容器服务 ACK 正式公布，成为寰球首批通过 Kubernetes 一致性认证的产品。往年，阿里云成为国内惟一进入 Forrester 公共云容器平台领导者象限的企业。” 阿里云构建了残缺的云原生开源生态，通过 KubeVela、OpenYurt、OpenKruise、Fluid 等多个开源我的项目，帮忙 Kubernetes 向边缘、AI、混合云等更多场景延长。KubeVela 打造了面向云计算时代的现代化利用交付治理事实标准，以利用为核心，定义研发、运维与基础设施之间的边界与协同形式，曾经成为 CNCF 沙箱我的项目。2021 年信通院将 KubeVela 的利用模型（OAM）作为行业架构规范公布。 OpenYurt 是阿里开源的首款云原生边缘计算我的项目，助力打造智能化、云边端一体化的边缘计算云原生基础设施，目前曾经成为 CNCF 沙箱我的项目。OpenYurt 开源以来，在上下游单干，技术、社区、行业影响力均有了显著的晋升，并在 2020 年 12 月取得亚太 CDN 产业联盟边缘计算影响力我的项目 TOP 3；在生态单干方面，和 VMware、intel、深服气、联通、IBM 等上下游生态搭档在 IoT、云边协同、硬件、边缘 AI、边缘平安等方面开展了多层次单干，其中和 LFEdge EdgeX 我的项目的深度单干，共推云原生物模型规范成为业界独创。 2021 年双 11，阿里团体实现 100% 利用云原生化，实现寰球最大规模云原生实际，电商、搜寻、大数据、AI 业务全副运行在对立的容器平台之上。容器服务 ACK 已为互联网、金融、批发、制作、交通等云上万余家企业提供容器利用治理服务。 阿里云在云原生畛域领有泛滥出名开源我的项目，包含两大 Apache 顶级我的项目和十大 CNCF 托管我的项目，笼罩容器、利用交付、音讯、微服务、Serverless 等技术方向，开源活跃度和影响力全面当先。其中，一些开源我的项目也成为了畛域事实标准，如 Apache RocketMQ 作为国内首个互联网中间件 Apache 顶级我的项目，在业务音讯畛域中国市场占有率第一；Apache Dubbo 是开源服务框架中影响力最大、采用率最高的国产微服务框架。和 RocketMQ 一样，Dubbo 在全球化和影响力两大维度进入了 Apache 中国开源我的项目象限第一方阵。 ...

作者：MSE 背景注册核心是日常应用频率很高的微服务组件，通过较低的资源溢价帮忙客户缩短微服务的构建周期、晋升可用性； 微服务治理实现了 0 门槛就能接入全链路灰度、无损高低线、限流降级、环境隔离、数据库治理等能力，轻松实现开源到稳固生产的逾越； 云原生网关则将网络入口的流量调度能力和后端的服务发现、服务治理能力相结合，从架构层面来晋升全链路的性能和安全性。这是 MSE 提供的三大外围产品能力之间的底层关联，产品研发团队放弃每月至多迭代一次的投入，来继续晋升产品竞争力。基于此，咱们将 MSE 近期公布的重要能力做了一次汇总。  注册配置核心更新版本体系、降级产品能力新增开发版，开发测试环境也能应用 Nacos2.0、ZooKeeper3.8 的引擎版本MSE 最早提供的是根底版和专业版，然而哪个版本实用于生产、哪个版本实用于测试，并不不言而喻，减少了客户选型的工夫老本；根底版不反对 Nacos2.0、ZooKeeper3.8，使得应用开源 Nacos2.0、ZooKeeper3.8 的客户，在测试环境也必须购买价格更高的专业版。 在最新公布的版本中，MSE 勾销根底版、上线开发版，并且开发版也反对 Nacos2.0、ZooKeeper3.8 ，这样一来，就升高了客户测试环境的应用老本，也屏蔽了测试、生产不同环境版本选型的烦扰。 MSE Nacos 专业版新增推送轨迹性能，读写性能晋升 40%+是否能平滑迁徙是客户选型商业化产品优先会思考的条件之一。新版本中，MSE Nacos 提供了低版本到高版本、自建 Nacos 到 MSE Nacos 的平滑迁徙计划，并且反对 Eureka 协定、ACM 协定。 注册核心的调用和配置变更都是高频应用性能，一旦出现异常，问题排查就成了用户最大的困惑，是注册和配置核心导致的，还是上下游业务本身的问题呢？新版本中，MSE Nacos 专业版提供可视化的数据观测界面和推送轨迹能力，从而十分清晰地观测到 Nacos 推送性能的履约状况，极大的进步问题的排查效率。 开源性能优化是开源自建的必修课，往往也是商业化服务会去精耕细作的能力。MSE Nacos 专业版基于阿里高性能 JDK Dragonwell 构建并且深度调优，并且 Nacos 自身基于企业级场景进行性能调优，使得 MSE Nacos2.0.4.0 版本性能比历史版本晋升 40%+。 此外，与阿里云产品体系无缝对接，例如日志服务、服务治理、SSL 证书、观测、压测工具等，缩小了云上的接入老本，反对注册核心 RAM 鉴权，整体反对管控策略配置，安全性也取得了全面晋升。 MSE ZooKeeper 丰盛可观测能力、多可用区部署，进步集群稳定性，读写性能大幅晋升开源 ZooKeeper 在可观测姓比拟欠缺，这也导致较高的故障排查老本。MSE ZooKeeper 专业版和普罗米修斯进行了深度集成，并且能够收费应用，提供了 20 多个 Zookeeper 罕用的观测指标，4 个外围资源观测指标，凋谢 70 多个 Metrics 指标，极大地晋升了可观测性。 ...

作者：王易可（楚岳） 背景Helm  是云原生畛域被宽泛采纳的客户端利用打包和部署工具，其简洁的设计和易用的体验失去了用户的认可并造成了本人的生态，到现在已有近万个利用应用 Helm Chart 的形式打包。Helm 的设计理念足够简洁，甚至能够演绎为以下两条： 1. 对简单的 Kubernetes API 做打包和模板化，形象并简化为大量参数。 2. 给出利用生命周期解决方案：制作、上传（托管）、版本化、散发（发现）、部署。 这两条设计准则保障了 Helm 足够灵便，同时也足够简略，可能涵盖全副的 Kubernetes API，很好的解决了云原生利用一次性交付的场景。然而对于具备肯定规模的企业而言，应用 Helm 做软件的继续交付就呈现了不小的挑战。 Helm 继续交付的挑战Helm 设计之初就为了保障其简略易用，放弃了简单的组件编排。所以在利用部署时，Helm 是一股脑将所有的资源交付到 Kubernetes 集群中，冀望通过 Kubernetes 面向终态的自愈能力，自动化的解决利用的依赖和编排问题。 这样的设计在首次部署时可能没有问题，然而对于具备肯定规模的企业生产环境而言，就显得过于理想化了。 一方面，在利用降级时一股脑将资源全副更新很容易因为局部服务短暂的不可用造成整体的服务中断；另一方面，如果软件存在 BUG，也无奈及时回滚，很容易将影响范畴扩充，难以管制。在某些更重大的场景下，如存在生产环境局部配置被运维人工批改过，因为 Helm 一次性部署会将原有的批改全副笼罩，而 Helm 之前的版本与生产环境可能并不统一，导致回滚也无奈复原，造成更大面积的故障。 由此可见，当具备肯定规模当前，软件在生产环境的灰度和回滚的能力极其重要，而 Helm 本身并不能保障足够的稳定性。 如何针对 Helm 做金丝雀公布？通常状况下，一个谨严的软件降级过程会听从相似如下流程：大抵分成三个阶段，第一阶段降级大量（如 20% ）的实例，并切换大量流量到新版本，实现这个阶段后先暂停降级。通过人工确认之后持续第二个阶段，降级更大比例（如 90% ）的实例和流量，再次暂停期待人工确认。最初阶段将全量降级到新版本并验证结束，从而实现整个公布过程。如果降级期间发现包含业务指标在内的任何异样，例如 CPU 或 memory 异样使用率升高或申请 500 日志过多等状况，能够疾速回滚。 下面就是一个典型的金丝雀公布的场景，那么针对 Helm Chart 利用，咱们该如何实现下面这个流程呢？业界的典型做法通常有如下两种： 批改 Helm Chart，将工作负载变成两份，并别离暴露出不同的 Helm 参数，在公布时一直批改两份工作负载的镜像、实例数和流量比例，从而实现灰度公布。 批改 Helm Chart，将原先的根底工作负载批改为具备同样性能然而具备灰度公布能力的自定义工作负载，并暴露出 Helm 参数，在公布是操纵这些灰度公布的 CRD。 这两个计划都很简单，有不小的革新老本，尤其是当你的 Helm Chart 是第三方组件无奈批改或本身不具备保护 Helm Chart 能力时，这些办法都是不可行的。 即便真的去革新了，相比于原先简略的工作负载模式，也存在不小的稳定性危险。究其原因，还是在于 Helm 自身的定位只是一个包管理工具，设计时并不思考灰度公布、也不针对工作负载做治理。 ...

作者：罗静 在刚刚过来的 RocketMQ Summit 2022 寰球开发者峰会上，咱们对外正式开源了咱们的新产品 RocketMQ-Eventbridge 事件驱动引擎。 RocketMQ 给人最大的印象始终是一个音讯引擎。那什么是事件驱动引擎？为什么咱们这次要推出事件驱动引擎这个产品？他有哪些利用场景，以及对应的技术计划是什么？ 明天咱们就一起来看下，整篇文章蕴含三局部： 第一局部，咱们一起看下什么是事件。 第二局部，和大家一起看看，事件有哪些不一样的“超能力”，应用这些“超能力”呢，咱们又无能些什么？ 第三局部，咱们讲一下 RocketMQ 给出的对于事件的解决方案，也是咱们这次开源的我的项目：RocketMQ-EventBridge。 什么是事件大家本人能够先在脑袋里想一下，什么是事件？咱们给事件下的一个定义是： 过来曾经产生的事，尤其是比拟重要的事。 A thing that happens, especially one of importance.这个很好了解。比如说，昨天下午我做了一次核酸检测；今天上午又吃了一个冰激淋。这些都是过来曾经产生的事件。然而，如果我再问：事件跟音讯有什么区别？这个时候，大家是不是感觉事件这个定义，如同又不那么清晰？ 方才说的那些事件，是不是也能够了解为音讯啊？如果，老张给我发送了一条短信，这个算是事件，还是音讯啊？平时开发过程中，“什么时候应用音讯，什么时候应用事件？” 不过，在答复这个问题之前，咱们一起来看一个典型的微服务。 一个微服务零碎和内部零碎的交互，能够简略分为两局部：一是接管内部申请（就是图中下面黄色的局部）；二是是调用内部服务（就是图中上面绿色的局部）。 接管内部申请，咱们有两种形式：一种是提供 API，接管内部发过来的 Query 申请和 Commond 申请；另外一种是被动订阅内部 Command 音讯。这两类操作，进入零碎外部之后呢，咱们经常还会，调用其余为微服务零碎，一起协同解决，来实现一个具体的操作。当这些操作，使得零碎状态产生扭转时，就会产生事件。 这里呢，咱们把从内部接管到的 Command 音讯，和零碎外部产生的事件，都称之为音讯。 咱们总结一下，音讯和事件的关系是这样的：音讯蕴含两局部，Command 音讯和 Event 音讯 1、看图中左半局部，Command 是内部零碎发送给本零碎的一条操作命令； 2、再看图中右半局部，Event 则是本零碎收到 Command 操作申请，零碎外部产生扭转之后，随之而产生了事件； 所以，事件和音讯是不同的，事件能够了解为是一种非凡的音讯。其非凡的点，次要在 4 个中央： 已产生、且不可变事件，肯定是“已发的”。“已产生”的代表什么呢？不可变的。咱们不可能扭转过来。这个个性十分重要，在咱们处理事件、剖析事件的时候，这就意味着，咱们相对能够置信这些事件，只有是收到的事件，肯定是零碎实在产生过的行为。而且是不可批改。 比照 Command 和 Query。Command 的中文是什么？命令。很显然，它是还没有产生的，只是表白了一种冀望。咱们晓得“冀望的”，不肯定会胜利产生。 比方：把厨房的灯关上、去按下门铃、转给 A 账户 10w…… 这些都是 Commond，都是冀望产生的行为。然而，最终有没有产生？并不知道。 Event 则是明确曾经产生的事件。比方：厨房灯被关上了、有人按了门铃、A 账户收到了 10w…… ...

作者：合伯 引言：在分布式系统调用场景中存在这样一个通用问题，即在执行一个外围业务逻辑的同时，还须要调用多个上游做业务解决，而且要求多个上游业务和以后外围业务必须同时胜利或者同时失败，进而防止局部胜利和失败的不统一状况呈现。简略来说，音讯队列中的“事务”，次要解决的是音讯生产者和消费者的数据一致性问题。本篇文章通过拆解 RocketMQ 事务音讯的应用场景、基本原理、实现细节和实战应用，帮忙大家更好的了解和应用 RocketMQ 的事务音讯。点击下方链接，查看视频解说： https://yqh.aliyun.com/live/d... 场景：为什么须要事务音讯以电商交易场景为例，用户领取订单这一外围操作的同时会波及到上游物流发货、积分变更、购物车状态清空等多个子系统的变更。以后业务的解决分支包含： 主分支订单零碎状态更新：由未领取变更为领取胜利；物流零碎状态新增：新增待发货物流记录，创立订单物流记录；积分零碎状态变更：变更用户积分，更新用户积分表；购物车零碎状态变更：清空购物车，更新用户购物车记录。  分布式系统调用的特点是：一个外围业务逻辑的执行，同时须要调用多个上游业务进行解决。因而，如何保障外围业务和多个上游业务的执行后果完全一致，是分布式事务须要解决的次要问题。 传统 XA 事务计划：性能有余为了保障上述四个分支的执行后果一致性，典型计划是基于XA协定的分布式事务零碎来实现。将四个调用分支封装成蕴含四个独立事务分支的大事务，基于XA分布式事务的计划能够满足业务处理结果的正确性，但最大的毛病是多分支环境下资源锁定范畴大，并发度低，随着上游分支的减少，零碎性能会越来越差。 基于一般音讯计划：一致性保障艰难将上述基于 XA 事务的计划进行简化，将订单零碎变更作为本地事务，剩下的零碎变更作为一般音讯的上游来执行，事务分支简化成一般音讯+订单表事务，充分利用音讯异步化的能力缩短链路，进步并发度。 该计划中音讯上游分支和订单零碎变更的主分支很容易呈现不统一的景象，例如： 音讯发送胜利，订单没有执行胜利，须要回滚整个事务；订单执行胜利，音讯没有发送胜利，须要额定弥补能力发现不统一；音讯发送超时未知，此时无奈判断须要回滚订单还是提交订单变更。基于RocketMQ分布式事务音讯：反对最终一致性上述一般音讯计划中，一般音讯和订单事务无奈保障统一的实质起因是一般音讯无奈像单机数据库事务一样，具备提交、回滚和对立协调的能力。 而基于音讯队列 RocketMQ 版实现的分布式事务音讯性能，在一般音讯根底上，反对二阶段的提交能力。将二阶段提交和本地事务绑定，实现全局提交后果的一致性。 音讯队列 RocketMQ 版事务音讯的计划，具备高性能、可扩大、业务开发简略的劣势。 基本原理概念介绍事务音讯：RocketMQ 提供相似 XA 或 Open XA 的分布式事务性能，通过 RocketMQ 事务音讯能达到分布式事务的最终统一； 半事务音讯：暂不能投递的音讯，生产者曾经胜利地将音讯发送到了 RocketMQ 服务端，然而 RocketMQ 服务端未收到生产者对该音讯的二次确认，此时该音讯被标记成“暂不能投递”状态，处于该种状态下的音讯即半事务音讯； 音讯回查：因为网络闪断、生产者利用重启等起因，导致某条事务音讯的二次确认失落，RocketMQ 服务端通过扫描发现某条音讯长期处于“半事务音讯”时，须要被动向音讯生产者询问该音讯的最终状态（Commit 或是 Rollback），该询问过程即音讯回查。事务音讯生命周期 初始化：半事务音讯被生产者构建并实现初始化，待发送到服务端的状态； 事务待提交：半事务音讯被发送到服务端，和一般音讯不同，并不会间接被服务端长久化，而是会被独自存储到事务存储系统中，期待第二阶段本地事务返回执行后果后再提交。此时音讯对上游消费者不可见； 音讯回滚：第二阶段如果事务执行后果明确为回滚，服务端会将半事务音讯回滚，该事务音讯流程终止； 提交待生产：第二阶段如果事务执行后果明确为提交，服务端会将半事务音讯从新存储到一般存储系统中，此时音讯对上游消费者可见，期待被消费者获取并生产； 生产中：音讯被消费者获取，并依照消费者本地的业务逻辑进行解决的过程。此时服务端会期待消费者实现生产并提交生产后果，如果肯定工夫后没有收到消费者的响应，RocketMQ 会对音讯进行重试解决。具体信息，请参见音讯重试； 生产提交：消费者实现生产解决，并向服务端提交生产后果，服务端标记以后音讯曾经被解决（包含生产胜利和失败）；RocketMQ 默认反对保留所有音讯，此时音讯数据并不会立刻被删除，只是逻辑标记已生产。音讯在保留工夫到期或存储空间有余被删除前，消费者依然能够回溯音讯从新生产。 音讯删除：当音讯存储时长到期或存储空间有余时，RocketMQ 会依照滚动机制清理最早保留的音讯数据，将音讯从物理文件中删除。事务音讯根本流程事务音讯交互流程如下图所示： 生产者将音讯发送至 RocketMQ 服务端； RocketMQ 服务端将音讯长久化胜利之后，向生产者返回 Ack 确认音讯曾经发送胜利，此时音讯被标记为“暂不能投递”，这种状态下的音讯即为半事务音讯； 生产者开始执行本地事务逻辑； 生产者依据本地事务执行后果向服务端提交二次确认后果（Commit 或是 Rollback），服务端收到确认后果后处理逻辑如下：二次确认后果为 Commit：服务端将半事务音讯标记为可投递，并投递给消费者；二次确认后果为 Rollback：服务端将回滚事务，不会将半事务音讯投递给消费者。 在断网或者是生产者利用重启的非凡状况下，若服务端未收到发送者提交的二次确认后果，或服务端收到的二次确认后果为Unknown未知状态，通过固定工夫后，服务端将对音讯生产者即生产者集群中任一生产者实例发动音讯回查；生产者收到音讯回查后，须要查看对应音讯的本地事务执行的最终后果； 生产者依据查看到的本地事务的最终状态再次提交二次确认，服务端仍依照步骤 4 对半事务音讯进行解决。实现细节：RocketMQ 事务音讯如何实现 依据发送事务音讯的根本流程的须要，实现分为三个次要流程：接管解决 Half 音讯、Commit 或 Rollback 命令解决、事务音讯 check。 解决 Half 音讯发送方第一阶段发送 Half 音讯到 Broker 后，Broker 解决 Half 音讯。Broker 流程参考下图： ...

作者：于怀 Nacos 是什么？Nacos /n:ks/ 是 Dynamic Naming and Configuration Service 的首字母简称，定位于一个更易于构建云原生利用的动静服务发现、配置管理和服务治理平台。从 2018 年 7 月开始发表开源以来，曾经走过了第四个年头，在这四年里，备受宽广开源用户欢送，共播种 23.3K 的 star 数，10.3K 的 Fork 数，在开源中国公布的 2021 年度 OSC 中国开源我的项目评比中，Nacos 被评为云原生畛域人气指数 Top5 的我的项目，公布电子书《Nacos 架构与原理》6w+浏览量，2w 下载量，公布半年的工夫里在阿里云藏经阁历史下载榜前十。Nacos 在社区独特的建设下一直成长，逐渐的开始帮忙用户解决理论问题，助力企业数字化转型，目前曾经宽泛的应用在国内的公司中，依据微服务畛域考察问卷，Nacos 在注册配置核心畛域曾经成为国内首选，占有 50%+国内市场份额，被头部企业宽泛应用！ 《2022 中国开源倒退蓝皮书》由中国开源软件推动联盟（COPU）牵头，联结中国开发者网络（CSDN）、北京开源翻新委员会、凋谢原子开源基金会、中国电子信息产业倒退研究院、中科院软件研究所等 85 家企业及行业机构、120 多位开源专家和志愿者独特合作编撰实现，旨在全面展示以后中国开源倒退的全景图，为国家政府相干治理部门、科研院所、科技企业以及开源从业者提供更多的实践参考和数据撑持，进一步助力我国开源生态的蓬勃发展。 依据最近刚公布的《2022 中国开源倒退蓝皮书》报告中显示，Github 中国我的项目活跃度 TOP 20，Nacos 排名全国第六，作为根底类型云原生中间件，能有如此活跃度是十分不容易的，在上一年度《2021 中国开源倒退蓝皮书》中，Nacos 排名全国第十，也体现 Nacos 不仅仅维持高的我的项目活跃度，而且我的项目关注度和活跃度还在逐步提高。 同时阿里巴巴在国内企业中开源影响力排行第一，在《2022 中国开源倒退蓝皮书》中介绍：“阿里巴巴是国内参加开源技术生态建设的企业榜样。自 2011 年至今，阿里累计开源我的项目超过 3000 个，代表性的我的项目包含龙蜥操作系统、Apache RocketMQ、Apache Dubbo、Spring Cloud Alibaba、 Nacos、Seata、PolarDB-X、PolarDB for PostgreSQL 等”。 Nacos 是阿里巴巴微服务畛域开源我的项目的活跃度排行第一，也得益于开源合作模式，并且在 Nacos 中有大量国内外出名公司的外围贡献者，其中也蕴含就任在腾讯、华为、小米等等知名企业的同学，也正是社区整体的贡献者和用户在帮忙 Nacos 成长，让 Nacos 逐步完善生态，反对简直所有支流语言，整合更多开源生态，也正是用户和社区贡献者让 Nacos 为企业数字化转型首选产品。 ...

>>收费下载《云原生架构白皮书 2022 版》<< 云原生时代下的企业 IT 实战云原生自 2013 年由 Pivotal 首次提出至今已历 7 年，这 7 年间对于云原生的定义曾经产生了屡次变动，云原生概念自身也始终在一直地成长、扩张。企业、开发者各自有不同的解读，行业各方也有各异的了解。 制约云原生技术更进一步落地的起因有很多，除了概念、规范的模糊不清，也包含企业数字化转型的浪潮中，传统行业对云原生价值认知的含糊、企业云原生技术能力参差不齐、云原生落地浮于外表、云原生化 IT 架构革新面临惨重历史包袱等事实问题。 企业短少的并不是云原生概念的解释，也不是云原生架构的设计图，而是真正从场景登程，通过实际考验的云原生落地方法论。阿里在云原生畛域领有 16 年积攒的实战经验，这既是阿里技术在摸索、积攒、翻新的宝贵财富，也是行业云原生落地过程中可供参考的来自实在场景、简单业务、海量并发下的最佳实际。 阿里云云原生利用平台负责人丁宇在此前承受媒体采访时提到： “近两年企业受到线上流量冲击，放大了生于云长于云的 IT 架构的优越性，减速了行业对云原生的接受度。云原生从最开始的互联网行业起步，曾经逐步扩散到金融、政务、物流等各行各业，造成了一种千行百业拥抱云原生的景象。 但在云原生的落地过程中，因为各行业的个性不同，各企业成长起来的期间不同，导致 IT 架构上仍旧存在比拟大的历史包袱，如何更好地拥抱云原生要解决的不仅是迁徙老本，还有工夫周期、开发人员观点转变等多个难题。阿里云心愿在行业数字化转型、拥抱云原生的过程中，将这 16 年云原生实战的教训带给行业，帮忙大家真正落地云原生。” 向技术要红利云原生行业在千行百业落地的过程中遇到了千人千面的问题。概念的模糊不清，技术实力的参差不齐，反映出了企业在云原生落地时的困境：晓得云原生很重要，但不晓得如何利用云原生的价值，实现业务的变革。 云原生落地的过程并不简单，实质上就是要吃到技术倒退的红利。对于开发者而言，益处同样显著。从业务角度看，利用开发者对基础设施的关注会越来越少，更多只须要专一在业务逻辑自身。而随着云原生概念下各技术的逐步标准化，将来利用开发者面对的开发和生产环境也会越来越标准化，省去简单的环境搭建和治理等环节。 2019 年，阿里实现了外围零碎全面上云。2020 年，阿里实现了外围零碎全面云原生化。从外围零碎全面上云，再到外围零碎全面云原生化，两大技术策略的交替背地，有着怎么的逻辑关系？这其实是一个自然而然的过程。 从外围零碎全面上云，带来了一个维度的降级。云原生上云背地，变成了如何在云上翻新，如何更好地全面应用云原生产品开释技术的价值，背地代表的是一个良好的生态、标准化的服务、残缺的技术体系。 将来的企业在上云当前，下一步肯定是全面地应用好云。现阶段很多企业对云的应用还停留在 IaaS 阶段，从阿里云的角度，咱们须要去帮忙他们实现一个规范的云原生化上云。 怎么样在“没有规范、全是规范”的云原生行业落地实战办法呢？一方面是阿里本身业务规模化带来的云原生能力的继续晋升，另一方面则是阿里云服务数百万客户积攒下的落地教训，二者的印证、交融，牵强附会地引出了云原生行业方法论的诞生。 2020 年，由阿里云 20+ 位云原生技术专家独特编撰的《云原生架构白皮书》正式对外公布。这是业界第一本全方位构建云原生架构布局与实际全景图的白皮书，在具体论述云原生架构定义的同时，残缺展现了云原生架构利用所需的演进门路与设计规定，也是阿里云多年云原生实战经验的智慧结晶。往年，《云原生架构白皮书2022版》正式上线，相较于2020年版本，本次内容新增数十家企业实战经验合集，同时在云原生产品矩阵中，新增多个外围产品家族，如容器产品家族、微服务产品家族、云原生技术中台 CNStack 产品家族等，更加一站式助力企业数字化转型。 云原生架构成熟度模型提出的最大意义，在于对企业云原生化现状、能力和倒退门路不清晰等问题，给出了评估与优化方向，帮忙企业走上数字化转型“最短门路”。以后，云原生技术在业务翻新的过程中也开始与其余先进技术产生了耦合，共性举荐、主动驾驶等都与云原生技术一起缩短了业务翻新的耗时。另一方面，以秘密计算、DevSecOps 为代表的平安前置的技术与理念又增强了云原生落地过程中对外围业务平安可信的保障。这是云原生实战方法论对实在的、场景化的业务带来的可落地、可借鉴的设想空间。 往年，在信通院公布的云原生技术架构成熟度模型测评中，阿里云取得国内惟一全域最高等级认证，这也进一步证实了阿里云在云原生技术架构规范的引领和弱小实力。 将来十年，云计算将无处不在，像水电煤一样成为数字经济时代的基础设施，云原生让云计算变得规范、凋谢、简略高效、触手可及。如何更好地拥抱云计算、拥抱云原生架构、用技术减速翻新，将成为企业数字化转型降级胜利的要害。 点击收费下载《云原生架构白皮书 2022 版》

作者：流士 本次 MSE 治理核心在限流降级、数据库治理及同 AZ 优先方面进行了重磅降级，对微服务治理的弹性、依赖中间件的稳定性及流量调度的性能进行全面加强，致力于打造云原生时代的微服务治理平台。 前情回顾在介绍降级能力之前，先简要回顾 MSE 产品的外围能力，分为开发态、测试态及运行态，其中在服务治理中较为罕用的性能包含无损高低线、全链路灰度以及日常环境隔离三大性能。 无损高低线方面反对小流量服务预热，防止新启动利用被流量击垮；而预热模型反对动静调节，可满足简单场景需要；并且，预热过程反对关联 Kubernetes 查看。 全链路灰度方面可进行泳道设置，反对网关、RPC、RocketMQ 等；具备流量一键动静切流能力，可通过监控查看切流成果；此外，提供了端到端的稳固基线环境，不便用户疾速、平安地验证新版本。 日常环境隔离性能流量在 feature 环境内流转，实现高效的麻利开发；各环境逻辑隔离，只须要保护一套基线环境，大幅降低成本；在 IDEA 中应用 Cloud Toolkit 的端云互联，可将本机启动的利用接入到开发环境，升高开发调测老本。 上面介绍流量治理、数据库治理及同 AZ 优先解决的问题和具体计划。 限流降级全面降级为流量治理对应流量治理模型在流量防护方面造成可拓展闭环，围绕零碎线上环境可能呈现的各种问题，进行无效治理。模型始于‘故障辨认’，发现不同档次的问题，如接口层的状态码与异样类型、操作系统层的指标异样；在辨认出问题后，收回异样告警，不便用户进行针对性的流量治理，如进行自适应限流防护或场景化限流防护；防护规定设置后，零碎便依照预设的阈值与防护伎俩爱护零碎，而零碎防护的成果可通过监控查看，另一方面，也可通过监控反向扫视流量防护规定设置的合理性，及时调整。 对于首次接入无历史数据参考的状况，可通过零碎压测的形式，联合业务场景设置压测参数，为线上可能呈现的问题配置流量治理规定，做好防护策略。 单机流量防护 首先看流量管制，其原理是监控利用或服务流量的 QPS 指标，当指标达到设定的阈值时立刻拦挡流量，防止利用被刹时的流量顶峰冲垮，从而保障利用高可用性。本产品提供了提供单机限流、集群流控、分钟小时限流、关联限流等多种限流形式，反对滑动窗口、令牌桶、漏斗桶多种限流算法。 对于并发管制，当强依赖的办法或接口呈现不稳固的时候，能够通过配置并发线程数来限度不稳固的强依赖并发数，起到隔离异样的成果。若运行该申请的响应工夫变长，会导致线程的并发数变大。当并发数超过阈值当前，AHAS 将回绝多余的申请，直到沉积的工作实现，并发线程数变少。达到将异样隔离，减小不稳定性的成果。 在零碎爱护方面，反对自适应流控或手动设置零碎规定，自适应流控是依据零碎的 CPU 使用率主动动静地调整应用程序的入口流量；零碎规定是从整体维度手动设置规定，对利用入口流量进行管制。目标都是为了让零碎的入口流量和零碎的负载达到一个均衡，保证系统在最大吞吐量状态下稳固运行。 熔断防护能够监控利用外部或者上游依赖的响应工夫或异样比例，当达到指定的阈值时立刻升高上游依赖的优先级。在指定的工夫内，零碎不会调用该不稳固的资源，防止利用受到影响，从而保障利用高可用性。当指定工夫过后，再从新复原对该资源的调用。 被动降级防护能够指定对某些接口进行降级，被降级的接口会触发自定义的降级行为（如返回指定内容）而不会执行原有的逻辑。 热点防护通过剖析资源调用过程中的调用次数较高的参数，并依据配置的热点规定对蕴含热点参数的资源调用进行限流，爱护零碎稳定性。 最初，当零碎遇到一些非致命性的谬误（如偶现的超时等）时，能够通过主动重试的形式来防止零碎最终失败。 集群流量防护其中集群流量防护用于解决单机流控存在流量不平均、机器数频繁变动以及均摊阈值太小的状况导致限流成果不佳的问题，集群流控能够准确地管制某个服务接口在整个集群的实时调用总量。较实用于以下场景： 1. 服务调用流量不均，须要缓解的状况 流量到每台服务实例不平衡导致单机限流不够准确（总量上“提前限流”），从而无奈准确管制总量 2. 集群小流量准确场景 对集群总流量限度比拟小的状况，单机限流将生效（比方某个接口每秒总量不超过 10QPS，但机器数为 50 台，即使单机阈值设为 1，仍会超出阈值） 3. 业务集群流控 对于有业务含意的分钟小时级流量管制，可爱护上游零碎不被（如网关层限度每个用户每分钟调用某个 API 不能超过多少次）压垮。 集群流控具备场景丰盛、应用成本低以及全自动管控等劣势： 场景丰盛：全面笼罩从网关入口流量准确防护、Web/RPC 服务调用准确流控到分钟小时级业务维度流量管制的场景 低应用老本：无需非凡接入形式，开箱即用 全自动管控：自动化管控与调配 server 资源，自动化运维能力保障可用性，无需用户关注资源筹备与调配细节，只需关注业务 网关流量防护网关流量防护则用于准确管制某个或某组 API 的流量，起到提前爱护的作用，使多余流量不会打到后端系统。如果依照单机维度配置，一方面网关机器数变动难以感知，另一方面网关流量不均可能导致限流成果不佳。 ...

作者： 陶宇航 本文选自“Serverless 函数计算征集令”征文，后盾回复“函数”理解详情 背景什么是函数？刚刚考完数学没多久的我，脑里立马想到的是自变量、因变量、函数值，也就是 y=f(x)。当然，在计算机里，函数 function 往往指的是一段被定义好的代码程序，咱们能够通过传参调用这个定义好的函数，实现咱们所须要的性能。那么，明天的函数计算 FC 又是什么？ 云计算时代的当下，容器化技术与各种工具倒退的 DevOps，曾经把开发与运维的工作进行了新的兼顾，开发人员在实现代码的编写后，无需思考环境，间接提交到各种流水线就能够实现测试、开发、部署，我的项目构建微服务，由容器实现环境的封装。然而往往咱们最终还是须要投入精力到业务上线的集群，是公有云环境还是私有云？是裸金属服务器还是云实例 ECS？是自购还是租用？ 当然，DevOps 的落地、服务器\集群的运维，这些都是须要投入大量的资源与精力，DevOps 是一条捷径，但不是惟一的前途。而函数计算 FC 的呈现，带来了无服务 Serverless 的架构，让开发者在开发和部署的时候，不再有部署服务简单的感觉。 对服务器的无感召，能够使开发者真正的关注在本人的代码上。阿里云 Serverless 函数式极简编程可专一于业务翻新，无洽购和部署老本、提供监控报警等齐备的可观测能力。阿里云函数计算 FC 是事件驱动的全托管计算服务，真正的无需去思考服务器的运维治理，只须要实现开发的代码进行上传，函数计算会通过角色策略去布局计算资源，弹性的形式执行函数，最初高效的执行部署。优雅！ Serverless 将会有那些实用场景？是集体？还是生产？那么这次我将部署两种不同方向的利用对 Serverless 进行测评！ 一、告诉零碎与 Webhook，Trigger 触发与 Chat 机器人。许多零碎中波及到的 push 类性能，例如邮件、短信、Webhook。当然 Webhook 的能力不只是信息告诉，不过这里所指的告诉性能必然是须要基础设施也就是服务器来撑持运行，如果将这些性能间接由 Serverless 来操作，咱们便无需领取运维一台服务器，节俭了大量的工作与费用。同样，咱们能够利用 Serverless 事件驱动模型实现定时主动触发工作，主动签到主动发送。 二、其次当然是 Web 类的利用。基于各类 Web 框架的利用部署，构建基于 Java、Python、PHP 等语言的站点，Serverless很容易实现如 wordpress 这样的博客利用的上线。配合其余云产品，Codeup、OSS、RDS 等，更能实现高可用高性能的 Web 利用，如官网提供的 Kod 云盘零碎。 Serverless 农产品电商网站上云革新这里我拿隔壁软件业余（俺是网络技术的）的一个大作业我的项目作为部署的案例。我的项目是非常简单并且性能繁多的，然而也是十分经典的前后端拆散我的项目，因为我开发不太会，我的项目具体技术就不献丑了。之前据说是有什么版权的，我就不放源代码了hhhh。 在革新之前，我置信是很多中小型公司业务的经典 AllinOne 构造，把业务波及到的所有服务中间件运行在一台服务器/虚拟机上，尽管当初看可能完完全全是实验室环境，然而理论看到的仍然有很多我的项目是这么做的。害处也不必多提，部署运维难、难以进行资源的扩容、后续革新简单、性能差没有利用高可用技术等等。。。 Serverless 的农产品电商平台上云，我的项目比较简单，布局就在同一地区了。次要是将前端 HTML 页面与后端 Jar 包运行别离由两个独自的 Serverless 函数实现运行计算。其余撑持服务上云，别离用对应的云产品实现，这里 Redis 服务因为我本人 ECS 上有运行 Redis 服务，就不再独自购买云数据库 Redis 版了，当然举荐应用阿里云的 Redis 云数据库产品。 ...

作者：沈斌、右京 业务场景与挑战友邦保险是香港联结交易所上市的人寿保险团体，笼罩 18 个市场。截至 2021 年 12 月 31 号，总资产 3400 亿美元。 友邦保险于 1992 年在上海设立分公司，是改革开放后最早一批获发集体人身保险业务营业执照的非外乡保险机构之一，也是第一家将保险营销员制度引进国内的保险公司。2020 年 6 月，友邦获批将友邦保险有限公司上海分公司改建为友邦人寿保险有限公司。2020 年 7 月，友邦人寿正式成为中国边疆首家外资独资人寿保险公司。友邦友享 App 在 2021 年荣获最佳保险科技平台。 业务特点和架构 为了践行友邦衰弱短暂好生存的 slogan ，上云过程中咱们对利用做了大量微服务化革新，以适应疾速变动的业务要求和性能要求，并将此前在 AS400 里的 core 包程序做了微服务化革新，进步了可用工夫。此外，咱们采纳了容器化计划，使利用运行在 K8s 上以取得弹性扩容能力和自愈能力。 上述革新导致了利用零碎复杂度的晋升，因而，观测微服务和 K8s 的运行成为了一大挑战。 与此同时，局部外采利用没有源码，不适宜做微服务化革新，但咱们依然对这部分利用进行了容器化革新，将它们部署进 K8s；还有一部分利用因为各种起因，不适宜上云革新，最终留在了 IDC 机房。因而，服务之间的调用会波及云上到云下、云下到云上等简单状况。 迁云之后实实在在为咱们带来了 SLA 的晋升，但也导致了拜访链路和部署复杂度的晋升，如何更好地观测利用成为了无奈回避的挑战。 可观测性建设痛点和挑战 建设一个优良的观测零碎，会面临以下痛点： 观测复杂度晋升：云原生微服务化尽管带来了很高的 HA，但也晋升了零碎的复杂度，加大了可观测的难度。核保通过率、交单成功率、用户的日活/月活散落在各个业务模块里，业务须要提供全局视角，以察看整个保单生命周期里重要业务节点的运行状况，并获取研发态的具体情况。 技术选型艰难：因为历史起因，友邦外部利用技术选型不一，版本各异，导致可观测技术和调用链追踪面临很大的艰难。 对立观测艰难：友邦是一家金融公司，开发零碎和利用运维齐全离开，日志也齐全离开存储和保护，因而无奈将以上数据在同一个大盘里出现。 指标治理：IaaS层、PaaS 层和应用层有很多指标，单数据库方面就可能有超过 200 多个指标。如果心愿指标达到比拟容易了解与追踪的数量，则须要一直地进行回顾、删减。 疾速故障定位：在 IDC 机房时代，没有直观的形式让利用查看本人的资源是否足够。尽管曾经有商业 APM 工具，但其价格昂扬，不属于经济无效的形式。问题产生时，因为只有大量利用装置了 APM ，所以调用链不残缺，无奈实现疾速故障定位。可观测性建设流程和布局 可观测零碎的建设次要分为调研剖析、方案设计、革新施行和上线验证四个阶段。 一个优良的可观测零碎至多须要满足五个要求： 服务资源追踪：能够将服务运行节点上的 CPU 内存、网络磁盘、 IO 利用指标进行聚合。问题产生时，可能轻松察看到异样指标。 提供服务 Top 视图：依照服务的调用量、申请耗时、热点排名，利用能够很不便获知哪些是热点 API、哪些 API 申请量较低等，能够更好地布局本身的服务资源。 调用链追踪：关联服务上下游，并且最好是无侵入式，能够很方面地从 Trace关联到日志，获取到链路问题所在。 调用时长散布：察看服务的上游与上游，察看异步耗时，申请慢时能够很不便地判断是服务资源耗时还是依赖服务资源耗时。 数据库关联操作：帮忙利用察看到 API 的关联 SQL、慢 SQL、 Redis 的查问存在慢 key 查问 、Mongo 存在慢查问等操作。实际与落地可观测性整体设计思路 ...

作者：十眠 背景在分布式系统架构中，业务的流量都是端到端的。每个申请都会通过很多层解决，比方从入口网关再到 Web Server 再到服务之间的调用，再到服务拜访缓存或 DB 等存储。 对于咱们的零碎来说，数据库是十分重要的一块。因而无论是在稳定性的治理上，还是在开发提效等场景下，数据库相干的治理能力都是咱们零碎所需具备的能力。上面总结了微服务拜访数据库层时，在数据库治理中的常见的一些场景与能力。 OpenSergo 畛域中对于数据库治理的概览 本文将介绍 MSE 服务治理最近推出数据库治理利器：无侵入实现数据库拜访的读写拆散能力。 什么是读写拆散？读写拆散也就是将数据库拆分为主库和从库，即主库负责解决事务性的增删改操作，从库负责解决查问操作的数据库架构。 为什么要读写拆散？稳定性一个大客户的申请过去，查询数据库返回上万条几百 M 的数据，数据库的 CPU 间接打满。不晓得大家是否遇到过相似的问题。 性能在业务处理过程中，如果对数据库的读操作远多于写操作，同时业务上对于数据查问后果的实时性要求不高（例如能够容忍秒级的提早），那么在做零碎性能优化时就能够思考引入读写拆散的计划，只读库能够承当主库的压力，无效晋升微服务利用的性能。 规模增长随着业务增长，到了肯定规模之后再扩容，但很多都卡在扩容这一步，极大的限度了应答市场变动的速度，其中数据库的扩容是最难的，目前常见的数据库扩容形式有以下几种形式： 垂直降级分库分表读写拆散 垂直降级须要中断服务且高可用方面不迭其它几种形式，分库分表在分区键的抉择上会是个难点，SQL 应用上会有诸多限度，同时对业务的革新也是十分大的工作量。相对来说读写拆散是对业务的侵入最低也最容易实现扩容计划。依据教训大多数利用的读写比都在 5:1 以上，有些场景甚至大量的高于 10:1，在对数据库有大量写申请，但有大量读申请的利用场景下，单个实例可能无奈接受读取压力，甚至对业务产生影响。 综上所述数据库读写拆散计划能够满足阿里云上大多数公司的稳定性治理、性能晋升以及数据库扩容的需要。 读写拆散常见计划目前业界风行的读写拆散计划，通常都是基于上述主从模式的数据库架构。读写拆散的实现计划少数是通过引入 odp、mycat 等数据拜访代理产品，通过其读写拆散性能来帮忙实现读写拆散。引入数据拜访代理的益处是源程序不须要做任何改变就能够实现读写拆散，害处是因为多了一层中间件做直达代理，性能上会有所降落，数据拜访代理也容易成为性能瓶颈。 ShardingSphere 读写拆散计划 [ 1] （摘自 shardingsphere 官网） ShardingSphere [ 2] 的读写拆散次要依赖内核的相干性能。包含解析引擎和路由引擎。解析引擎将用户的 SQL 转化为 ShardingSphere 能够辨认的 Statement 信息，路由引擎依据 SQL 的读写类型以及事务的状态来做 SQL 的路由。如下图所示，ShardingSphere 辨认到读操作和写操作，别离会路由至不同的数据库实例。 MSE 数据库读写拆散能力MSE 提供了一种动态数据流量治理的计划，您能够在不须要批改任何业务代码的状况下，实现数据库的读写拆散能力。上面介绍 MSE 基于 Mysql 数据存储通过的读写拆散能力。 前提条件利用接入 MSE部署 Demo 利用 在阿里云容器服务中部署 A、B、C 三个利用，并且将利用均接入 MSE 服务治理 [ 3] ，用于减少具备数据库治理能力的 Agent。 ...

2021 年，阿里云发表“数据库开源打算”，PolarDB 正式开源，先后开源云原生 PG 版（PolarDB for PostgreSQL）和云原生分布式版(PolarDB-X)，聚合社区力量，与宽广开发者共建云原生分布式数据库生态。为了帮忙宽广开发者能更疾速的学习 PolarDB 开源数据库，阿里云数据库团队联结开发者社区独特推出“阿里云 PolarDB 开源人才培养打算”，从实践到实际，提供一站式学习考试体验，继续凋敝 PolarDB 开源生态。 造就劣势：1.零碎的课程：从实践到实战，一站式入门阿里云 PolarDB 开源数据库2.业余的讲师：由阿里云数据库技术专家与业内资深讲师独特打造的专业课程。3.前沿的技术：云原生+分布式是数据库将来的发展趋势。4.广大的前景：依靠 PolarDB 开源生态广大的利用场景。 考试流程：培训报名 - 加入培训 - 参加考试 - 获取证书 - 证书查问 如何参加： 1.PolarDB-X 开源人才高级考试PolarDB-X 开源人才高级考试是阿里云对于应用 PolarDB-X 云原生分布式数据库能力的考试，要求学员理解 PolarDB-X 开源版架构原理，具备装置部署、日常运维、分布式事务、高可用等常识及能力。考试辅导课程：https://developer.aliyun.com/...考试入口：https://developer.aliyun.com/... 2.PolarDB for PostgreSQL 开源人才高级考试PolarDB for PostgreSQL 开源人才高级考试是阿里云对于应用 PolarDB for PostgreSQ 云原生关系型数据库能力的考试，要求学员理解 PolarDB for PostgreSQL 开源版架构原理，具备装置部署、日常运维、高可用、共享存储、云原生 HATP 等常识及能力。考试辅导课程：https://developer.aliyun.com/...考试入口：https://developer.aliyun.com/... 21 天组队学习打算，参加造就打算赢万元好礼：>>点击此处立刻参加<<流动 1.实现学习工作集齐碎片，得开发者学堂定制无线充电器 工作 1、报名 PolarDB-X 开源人才高级考试培训营，点击报名按钮，学习课程即可实现工作工作 2、参加 PolarDB-X 开源人才高级考试工作 3、报名 PolarDB for PostgreSQL 开源人才高级考试培训营，点击报名按钮，学习课程即可实现工作工作 4、参加 PolarDB for PostgreSQL 开源人才高级考试留神：实现工作 2、4，需实现考试才可实现打卡工作（如果您通过测试也能够失常打卡哦~）每实现一个工作即可点亮一个碎片，集齐 4 个碎片即可兑换定制无线充哦~所有奖品数量无限先到先得，快去加入吧~ ...

作者：榴莲 为什么要迁徙？咱们的业务有很多对外提供服务的 RESTful API，并且要执行很多不同的工作，例如同步连锁 ERP 中的商品信息到美团/饿了么等平台，在线开发票等。因为各种 API 和工作执行的不确定性，常常会因为资源有余导致服务不可用，然而自觉的扩容又很烧钱。整个团队每天都陷在不停的扩容，缩容之中。要害是有时候稍稍慢了一些，就会对业务照成影响，导致被投诉。每天还要被其余业务部门催着做新性能。更难的是，因为咱们没有运维教训，屡次被黑客把咱们原本就不多的机器用来挖矿。作为一个初创公司的研发团队，咱们的资源少，人手少，教训少，面对稳定性，安全性和业务的压力真的是十分苦楚。 在被前共事安利了函数计算当前，我发现这太有用了！迁徙的过程十分顺滑，迁徙的成果也大大超出了我的预期。上面是我感觉函数计算非常适合咱们的理由： 默认弹性，能够轻松应答大量 API 申请和工作，不会再因为扩容不及时导致资源耗尽引起的业务不可用了！无流量时反对缩容到 0，省钱神器，再也不必买虚拟机和负载平衡了，对咱们来说降本成果杠杠滴！免运维，免去了虚拟机的运维老本！更平安，它不能被 SSH 登陆，而且也不会像虚拟机一样始终开着，等着被人扫描和攻破！零革新，无需批改代码，之前虚拟机上的 JAR 包间接就能够跑在函数计算上！迁徙步骤有三种应用形式，这里我具体讲一下怎么在管制台上操作。 应用函数计算控制台进行迁徙。应用函数计算提供的 S 工具，通过命令行 + YAML 的形式进行部署，查看详情 1 [ 1] 。应用函数计算管制台上的利用核心，从 GitHub 等源代码库中主动构建并部署。CICD/GitOps 间接就有了，太香了！查看文末详情 2 [ 2]1. 开明函数计算拜访控制台 [ 3] ，点击“收费开明”将跳转到开明页面。 2. 创立服务点击“服务及函数”，“创立服务”，输出“名称”后点击“确定”。 3. 对 JAR 包进行压缩，失去 ZIP 文件留神！！！这里要对打包好的 JAR 包进行压缩，而后上传 ZIP 包！！！ 备注：其实也能够间接上传 JAR 包，然而启动命令要写为 java org.springframework.boot.loader.JarLauncher 我集体不是很喜爱这种写法。我还是喜爱 java -jar gs-rest-service-0.1.0.jar 的写法。 如果你还没有可用的 JAR 包，请参考 SpringBoot 官网疾速开始文档 [ 4] 进行构建。 ...

作者 | 陈泽涛（硬之城产品总监）& 洛浩（阿里云云原生高级架构师） 硬之城成立于 2015 年，是一家以电子元器件 BOM 整体供给为外围，为中小科技型硬件企业提供 BOM 标准化、BOM 报价、BOM 洽购、BOM 交付和 SMT 一站式 PCBA 服务的电子产业数字供应链与智能制作平台。作为入选阿里云首期云原生加速器的企业，硬之城此前也取得了阿里云首批产品生态集成认证，通 过云原生加 速器我的项目携手阿里云共建更加丰盛的云原生产业生态圈，减速云原生落地。 背景电子产业互联网的需要是离散和复杂多变的，相比传统的代码开发，每一个市场需求的研发都须要消耗不少的研发资源投入到对应的需要开发中。这其中不仅有代码开发的工作，而且后期与工程师间的沟通工作也占用了不少资源。这不仅让每个需要都会耗费不少的研发老本，而且市场的需要也须要期待研发实现能力响应。这也是为什么硬之城抉择做低代码平台的起因。 咱们在理论的业务中，会频繁的收到来自市场的需要，这些需要还存在一部分不确定性和尝试性的需要。为此始终让咱们的研发资源相当缓和。低代码平台的打造，不仅让没有编程根底的业务能够疾速上手，让各业务部门都能够搭建本人的治理利用，大大缓解了研发资源缓和的问题。 在咱们理论的应用过程中，发现低代码平台不仅能够笼罩许多简略的需要研发，而且许多惯例的、简单的需要也能够通过低代码平台实现。特地在不确定性和尝试性的需要，因为此类需要自身存在不稳定性，需要变更的状况十分广泛。这时因为低代码的迭代老本和门槛低，业务能够间接在后盾批改利用，以达到疾速的响应市场指标。 目前咱们低代码平台应用 Java 和 Nodejs 开发，后端采纳 SpringBoot，前端采纳 Vue，基于 ECS 进行部署时，采纳 Shell 脚本公布，并基于 Nginx 负载到多台主机。然而咱们常常会碰到服务器资源占用不均衡，运维老本高，操作权限调配繁琐等问题，这给咱们整个团队的合作造成了困扰，为此咱们始终在寻找对应的解决方案。 始终到咱们发现能够实现全托管、免运维、高弹性的 SAE 平台。SAE 反对开源微服务、开源定时工作框架、Web 利用的全托管。为此咱们进行了架构搭建，发现 SAE 能够正当调配利用和服务器之间的资源，以及利用动静伸缩灵活性。这无效的升高了服务器运维门槛，防止危险操作，简化了咱们团队成员对利用蓝绿公布的操作流程，晋升了公布安全性和可靠性。 通过一段时间的应用，咱们目前能够通过云效流水线公布 SAE 利用，镜像构建存储都缓存到阿里云镜像库，每位该项目标开发人员都能通过流水线公布利用，并且基于阿里云 RAM 零碎能够很好的管制权限，公布效率大大晋升，每一个 SAE 应都对应有独立的节点，不须要思考利用是要选取公布到哪一台主机，只须要做好 SLB 负载平衡，理论资源用多少付费多少，也不须要操心服务器的各种机器保护问题，显著晋升了运维工作的效率。对利用自身来说，就是人效的晋升，更加不便简洁的步骤就能实现一个利用的部署周期。 对于运维治理上来说，就是更加轻便，少了很多诡异的操心事。对于整个微服务架构来说就是脉络更加清晰，可扩展性更强，只须要点一下即可扩大更多更强的负载能力。公司做老本估算的时候也能更加可控，不须要一堆服务器和 IP。 硬之城低码平台将来布局及愿景将来咱们冀望业务与技术能并行。适宜业务自行治理的需要，业务本身能够通过低代码就能够疾速的实现他本人的需要上线，并自行保护。对于非常复杂及存在技术门槛的需要，此时技术人员才染指，让技术人员更专一的解决高价值、高技术的问题。 这不仅让业务能够疾速响应市场需求，也让技术人员有更多的精力去解决企业的技术问题。最终让企业的业务人员和技术人员都流动起来，专一起来，以此来让企业更加有生机。 SAE 针对 SaaS 场景的计划及劣势通过硬之城的实际，咱们也能感触到 SAE 对开发和运维效率的极大晋升，如下图所示，这其实是因为 SAE 联合了容器、Serverless、微服务的长处，打造一站式利用开发部署平台。 对下屏蔽了 K8s 等资源保护的复杂性，对上提供全利用生命周期治理、微服务治理、APM、弹性治理等能力，能够让用户更简略的实现容器化、利用迁徙、业务上云。 同时对于曾经实现了微服务化、或者依然处于单体架构的存量利用，SAE 也能够反对 “0” 代码革新迁徙。如下图，假设业务是基于 ECS 部署的，如果想晋升业务的弹性能力以更好的应答流量稳定，或者就是单纯的想简化资源的治理和运维等繁琐的事件，那么 SAE 就能够间接把 ECS 替换掉，也就是把部署在 ECS 上的业务代码在 SAE 平台上重新部署即可，前端平安、后端数据库等资源的部署和应用依然放弃不变。 ...

7 月 21 日-7 月 22 日，由 Apache RocketMQ 社区主办，阿里云天池平台、云原生利用平台承办的首届 RocketMQ Summit 寰球开发者峰会拉开帷幕。Apache RocketMQ 联结创始人林清山公布 RocketMQ 能力全景图，为泛滥开发者论述 RocketMQ 5.0 的技术定位与倒退方向，来自快手、小米、字节跳动等互联网头部企业的 40 位演讲嘉宾与泛滥开发者分享各自行业的最佳实际与技术摸索教训。 阿里云云原生利用平台负责人丁宇示意，开源让云计算更加的标准化、云计算让开源产品化和规模化，将来的数字世界，将构建在云计算和开源之上。阿里巴巴将以开源的形式，践行凋谢共享好科技理念，把开源作为技术策略的重要组成部分。 明天，阿里巴巴的开源我的项目总数超过 3000 个，涵盖云计算、大数据、AI、中间件、数据库、容器、Serverless、高可用等畛域，领有超过 30000 名 Contributor，超过百万 Star，位列中国企业社区奉献榜首，间断十年蝉联中国厂商开源活跃度第一、影响力第一。将来，阿里云也将会继续投入 RocketMQ 的开源建设，构建更加凋敝的社区生态。心愿与更多的开发者、贡献者一起，谋求极致、凋谢共享，实现开源技术的普惠。 基于本身实际，RocketMQ 社区对于音讯队列演进趋势的洞察音讯队列作为最经典的中间件之一，曾经有三十多年历史。随同着技术倒退，音讯队列畛域一直扩大，爆发新生命力，作为国内大规模实际先行者，RocketMQ 社区认为音讯畛域将迎来以下趋势变动： 1. 全面拥抱云原生音讯队列将向上演进音讯型的产品状态，更好去撑持微服务、事件驱动、Serverless 化等云原生利用架构；向下演进音讯零碎本身云原生架构，通过零碎重构充沛开释基础设施的弹性计算、存储、网络等能力，全方位晋升音讯技术指标，升高音讯老本，进步音讯队列弹性能力。 2. 全面拥抱物联网物联网技术将更宽泛的落地到各行各业，万物互联、边缘计算进一步拓展音讯的边界。面向物联网的音讯队列要海量异构设施接入，海量音讯队列存储，可能随处运行，具备云边端一体的无边界部署能力。 3. 全面拥抱实时数据企业的数字化转型的步调一直减速，从业务数字化迈向数字业务化。数字化企业继续产生业务数据，对业务数据实时洞察与决策，能力帮忙企业疾速响应商机、把握商机，使得业务取得更大胜利。同时，音讯队列也将从在线业务架构的基础设施延长到实时数据架构的基础设施，达到事务剖析一体化。 四大方向，全面解读 RocketMQ 5.0 架构演进 1. 面向微服务引入微服务架构，数字化企业以“高内聚、低耦合”的形式高效合作。微服务架构也带来新问题，比方大量同步微服务会面临提早增大、可用性升高等危险。为了解决这个问题，越来越多的企业引入音讯队列建设异步微服务体系，进一步提高微服务的韧性，升高响应提早。 业界的微服务技术趋势，一方面是曾经造成了事实标准，比如说像 Spring Cloud 体系，Dubbo 体系，通信协议有 HTTP、AMQP 等，另一方面下一代的微服务体系也在疾速倒退中，次要体现在基础设施下沉，比方 Servicemesh，Serverless 等技术。 在这个趋势下，RocketMQ 5.0, 在 SDK 层面将原来的重型客户端往轻量客户端演进，基于规范 gRPC 作为 remoting 层实现 SDK，同时也将更多客户端逻辑下沉到服务端，比方音讯重试、负载平衡等，大幅度降低多语言 SDK 的实现老本。轻量客户端更好的匹配了 ServiceMesh 的需要，RocketMQ 的 Mesh 能力已正式合入 CNCF Envoy 官网社区。 ...

作者：掘金开发者社区 微服务和 Serverless 正在成为一对最佳拍档。 云计算时代，容器和 K8s 的呈现让微服务架构开始施展更大的效力，现在云利用正朝着无服务器（Serverless）的方向倒退，Serverless 简化了开发模式，开发者不必再关怀 Server ，只需专一业务逻辑。 Serverless 曾经扛起了改革传统 IT 架构的大旗，成为企业数字化转型变革架构的利器。Forrester 认为：Serverless 架构的衰亡，让 FaaS （Function As A Service） 成为继 IaaS、PaaS、SaaS 之后一种新的云计算能力提供形式。 预计将来几年，将会有大量支流企业的外围利用，从原来的主机架构迁徙到 Serverless 架构。然而软件开发没有银弹，一些问题失去解决的同时，新的挑战也随之产生。 将一个巨型单体利用以微服务的形式拆合成耦，继而革新为 Serverless 利用，是采纳渐进的形式逐渐替换还是齐全重写？什么样的业务场景适宜微服务，什么样的业务场景适宜 Serverless？理论开发中呈现的厂商锁定、老本问题、业务简单等痛点应如何解决？ 介于此，7 月 22、23 日为期两天的 2022 稀土开发者大会召开在即，此次阿里云 Serverless 研发负责人杨皓然（不瞋）作为大会出品人，带来《微服务与 Serverless》专场演讲，邀请到字节、阿里等各大厂的外围业务负责人，为各位开发者分享微服务与 Serverless 方向的摸索实际和教训心得，带你探索 Serverless 前沿动静。 杨皓然（不瞋）阿里巴巴资深技术专家 阿里云 Serverless 研发负责人。2010 年退出阿里云，参加了阿里云飞天分布式系统的研发，历任表格存储（NoSQL），对象存储（OSS）研发经理，深度参加了阿里云零碎研发和产品迭代的全过程。对大规模分布式计算，大规模数据存储和解决有十分深刻的了解。现负责阿里云 Serverless 产品线研发工作，致力于构建下一代弹性、高可用的无服务器计算平台。本届开发者大会收费报名 ing 点击文末浏览原文或辨认海报二维码 即可与各位牛人分享交换 议题介绍演讲主题：Serverless 时代下大规模微服务利用实际微服务架构相比单体架构有更好的组织，更高的敏捷性，但也不可避免的带来了新的复杂性。然而这些复杂性正好在 Serverless 的时代失去了很好的解决，本次演讲，将会联合以后最新的 Serverless 发展趋势，让架构师/开发者疾速理解微服务架构目前的最新状态，以及如何联合 Serverless 升高复杂度。 即使还处于张望的各位也能够从本次分享中切实感触到 Serverless 带来的益处，以及落地微服务复杂度的升高。 演讲纲要： 微服务架构的长处和痛点Serverless 时代下的解决方案阿里云 Serverless 微服务性能原理和最佳实际总结以及将来瞻望演讲嘉宾： ...

作者： 澄潭 往年 K8s Ingress Nginx 我的项目接连披露了三个高危安全漏洞（CVE-2021-25745 [ 1] , CVE-2021-25746 [ 2] , CVE-2021-25748 [ 3] ），该我的项目也在近期发表将进行接管新性能 PR，专一修复并晋升稳定性。Ingress Nginx 作为 K8s 我的项目自带的网关组件，被大量用户的 K8s 集群默认装置。作为处于 Internet 网络边界的根底软件，又被大规模应用，势必会成为一些攻击者的现实指标。一旦防线攻破，其代价是惨痛的，能够参考同样是网络边界的根底组件，OpenSSL 的 Heartbleed 心血破绽殷鉴不远。 2014 年 Heartbleed 破绽释出不久，OpenBSD 开始自行保护 LibreSSL，Google 也推出了 BoringSSL，基于和 OpenSSL 遵循同一套 SSL/TLS 协定规范，提供更平安的替代品。相似的，基于同一套 K8s Ingress API 规范，是否有更平安的 K8s 网关能够代替 Ingress Nginx？ apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: ingress-examplespec: rules: - host: foo.bar.com http: paths: - pathType: Prefix path: "/" backend: service: name: service1 port: number: 80 - host: bar.foo.com http: paths: - pathType: Prefix path: "/" backend: service: name: service2 port: number: 80Ingress API 规范示例 ...

阿里云飞天技术峰会正式揭幕面向大规模数据的解决需要，往年 6 月咱们正式公布了以飞天和 CIPU 为外围的新一代云计算体系架构。咱们也看到在以后市场大环境下，千行百业试图寻找本身在业务、技术、产品等畛域的破局之道。 由此，咱们将于 2022 年 8 月 11 日，正式举办阿里云飞天技术峰会 ！ 此次峰会，咱们将与行业内泛滥高新技术畛域的领军企业，独特探讨企业如何在新一代的云计算体系架构之上，激活在业务、技术、产品三个层面的内生能源，找到新的增长点和竞争力。 立刻参会扫描下图二维码，即刻报名参会～ 13:30-16:00「云原生利用实际」分论坛不见不散！

作者：张伟（谢石） 因为这篇文章真的很长，大量的篇幅在讲述内核的实现，如果你对这部分不感兴趣，那么在倡议你在看完第一局部的三个问题后，思考一下，而后间接跳转到咱们对问题的答复。提出问题注：本文所有的代码均为 Linux 内核源代码，版本为 5.16.2 你据说过 VLAN 么？它的全称是 Virtual Local Area Network，用于在以太网中隔离不同的播送域。它诞生的工夫很早，1995 年，IEEE 就发表了 802.1Q 规范 [ 1] 定义了在以太网数据帧中 VLAN 的格局，并且沿用至今。如果你晓得 VLAN，那么你据说过 MACVlan 和 IPVlan 么？随着容器技术的一直衰亡，IPVlan 和 MACVlan 作为 Linux 虚构网络设备，缓缓走上前台，在 2017 年 Docker Engine 的 1.13.1 的版本 [2 ] 中，就开始引入了 IPVlan 和 MACVlan 作为容器的网络解决方案。 那么你是否也有过以下的疑难呢？ 1. VLAN 和 IPVlan，MACVlan 有什么关系呢？为什么名字里都有 VLAN？ 2. IPVlan 和 MACVlan 为什么会有各种模式和 flag，比方 VEPA，Private，Passthrough 等等？它们的区别在哪里？ 3. IPVlan 和 MACVlan 的劣势在哪里？你应该在什么状况下接触到，应用到它们呢？ 我也曾有过一样的问题，明天这篇文章，咱们就针对下面三个问题一探到底。 背景常识以下为一些背景常识，如果你对 Linux 自身很理解，能够跳过。 内核对网络设备的形象在 Linux 中，咱们操作一个网络设备，不外乎应用 ip 命令或者 ifconfig 命令。对于 ip 命令的实现 iproute2 来说，它真正依赖的就是 Linux 提供的 netlink 音讯机制，内核会对每一类网络设备（无论是实在的还是虚构的）形象出一个专门响应 netlink 音讯的构造体，它们都依照 rtnl_link_ops 构造来实现，用于响应对网络设备的创立，销毁和批改。例如比拟直观的 Veth 设施： ...

作者：夏明 利用架构与可观测技术演进历程 在软件开发晚期，单体利用架构因其构造简略，便于测试和部署，失去了宽泛的利用，对应的监控诊断技术次要是基于日志和日志关键词的指标监控。随着软件复杂度的一直晋升，单体利用架构逐渐向分布式和微服务的架构演进，整体的调用环境也越来越简单，仅靠日志和指标慢慢难以疾速定位简单环境下的问题。 因而，链路追踪技术应运而生。但晚期的链路追踪技术和日志指标的联合比较简单，更多的是在应用层以 APM 软件的模式存在。 随着云计算和云原生理念的遍及，从业务层到应用层，容器和基础设施之间的边界一直地被突破，研发、运维、平安等工种的职责也一直含糊，因而对于全栈可观测的诉求也变得更加强烈，Traces、Metrics 和 Logs 的连贯也愈发严密。 一个典型的云原生架构及可观测诉求 典型的云原生架构往往是混合云的状态，出于平安或容灾等方面的思考，可能会将一部分利用部署在私有云，另一部分部署在自建机房。而出于软件研发效率和性能的思考，不同的利用又可能采纳多种开发语言，因而可观测诉求能够被演绎为以下四点： 1、全栈立体化对立监控与告警：比方能够将业务层的交易量、领取量的业务指标和利用黄金 3 指标、基础设施的 CPU 利用率以及网络状况，放在一张大盘上做总体监控，这也是大促期间较为罕用的形式。 2、前后端/多语言全链路追踪：用户申请从端上发动，始终到网关，再到后端的利用和云组件之间调用轨迹的追踪，能够疾速定位用户申请在哪里有异样。 3、跨云数据对立可视化：将不同类型的数据、不同环境的数据进行对立可视化，须要有较强的可视化组件。 4、开源格局数据二次加工：出于业务自定义的需要，须要有二次加工与剖析。如果可能基于开源的数据格式规范，很多工作施行起将会比拟轻松，也能够复用很多现有的货色。 为什么要基于 OPLG 构建对立可观测平台 而传统的监控诊断平台往往存在以下几个痛点： 1、很多埋点插桩由用户本人实现，这种闭源实现会导致数据格式不对立，而且埋点在各个系统之间很难复用，接入老本十分高。 2、Metrics 指标孤立地扩散在各个监控的子系统，比方有的在网络，有的在利用，有的在容器。排查全链路问题时，对开发应用人员的教训要求十分高，且效率非常低。 3、Traces 会因为埋点覆盖度不够或协定不对立而无奈串联，导致经常出现断连。 4、日志或链路数据的明细数据全量上报到服务端，也会带十分高的老本，而且查问率较低，还会引发热点的性能瓶颈。 5、自建控制台的前端开发老本高，开发周期长，灵活性较差，很难跟上业务迭代的效率。 6、各个系统的可观测数据之间不足对立的标签治理，关联性较差，很难做综合性的剖析。 为了解决上述问题，咱们在生产环境中逐步积淀下较为可行的计划，即基于 OPLG 建设对立可观测平台。此计划次要有以下几点劣势： 1、开源凋谢：全开源技术栈，借助社区共建合力，比方能够借助 OpenTelemetry 的 Traces 埋点，Prometheus指标的 Metrics Exporters ，无需过多开发，即可保障大部分通用组件数据的采集生成上报，升高了接入老本。 2、对立指标：开源且基于对立的一套标准，能够很轻松地实现外部各个子系统甚至是和内部三方零碎之间的买通和关联剖析。 3、自在灵便：基于 OPLG 特地是 Grafana 一些比拟好的设计，能够非常灵活地组织可观测数据，可能灵便地定制每一个场景下须要的大盘图表，满足自定义的需要。 4、边缘计算：基于 OpeTelemetry Collector技术，能够将数据处理“左移”到用户集群内。通过边缘计算的技术，可能提前提炼数据价值，并将提炼好的数据再发送到服务端，升高公网传输的老本以及服务端的存储老本。 基于 OPLG 构建云原生可观测平台计划 OPLG 次要由以下四个模块形成： 1、端侧数据生成与上报：通过 OpenTelemetry 实现 Traces 数据的生成，通过 Prometheus 实现指标类的数据，通过 Loki 的形式实现日志采纳。 2、边缘侧数据对立解决与路由：所有数据采集实现之后，能够通过 OpenTelemetry Collector 实现数据对立的边缘解决和路由转发。 ...

作者：十眠 背景在分布式系统架构中，业务的流量都是端到端的。每个申请都会通过很多层解决，比方从入口网关再到 Web Server 再到服务之间的调用，再到服务拜访缓存或 DB 等存储。 对于咱们的零碎来说，数据库是十分重要的一块。因而无论是在稳定性的治理上，还是在开发提效等场景下，数据库相干的治理能力都是咱们零碎所需具备的能力。 以下列举一些典型的数据库相干的治理场景： 某零碎对外提供某查问接口，SQL 语句波及多表 join，某些状况下会触发慢查问，耗时长达 30s，最终导致 DB 连接池/Tomcat 线程池满，利用整体不可用。利用刚启动，因为数据库 Druid 连接池还在初始化中，然而此时曾经大量申请进入，迅速导致 Dubbo 的线程池满，许多现场卡在初始化数据库连贯的过程中，导致业务申请大量报错。全链路灰度场景中，因为新的利用版本改了数据库表的内容，灰度流量导致线上数据库的数据错乱，业务同学连夜手动勘误线上数据。 在我的项目初期没有对 SQL 的性能做好考量，随着业务的倒退，用户量级的减少，线上遗留老接口的 SQL 逐步成为性能瓶颈，因而须要有无效的 SQL 洞察能力帮忙咱们发现遗留的 SQL，并及时进行性能优化。 SQL 语句解决工夫比拟长导致线上业务接口呈现大量的慢调用，须要疾速定位有问题的慢 SQL，并且通过肯定的治理伎俩进行隔离，将业务疾速复原。因而在微服务拜访数据层时，实时的 SQL 洞察能力能够帮忙咱们疾速定位慢的 SQL 调用。其实针对大多数的后端利用来讲，零碎的瓶颈次要受限于数据库，当然复杂度的业务必定也离不开数据库的操作。因而数据库问题，也是优先级最高的工作，数据库的治理也是微服务治理中必不可少的一环。 数据库治理相干常见场景上面总结了微服务拜访数据库层时，在数据库治理中的常见的一些场景与能力。 OpenSergo 畛域中对于数据库治理的概览 慢 SQL 治理慢 SQL 是比拟致命的影响零碎稳定性的因素之一，零碎中呈现慢 SQL 可能会导致 CPU、负载异样和系统资源耗尽等状况。重大的慢 SQL 产生后可能会拖垮整个数据库，对线上业务产生阻断性的危险。线上生产环境呈现慢 SQL 可能起因如下： 网络速度慢、内存不足、I/O 吞吐量小、磁盘空间被占满等硬件起因。没有索引或者索引生效。零碎数据过多。在我的项目初期没有对 SQL 的性能做好考量。 对于线上常见的慢 SQL 问题，MSE 服务治理提供了场景化的解决形式。 SQL 洞察MSE 提供了秒级的 SQL 调用监控： 咱们能够察看利用和资源 API 维度的实时数据（细化至秒级），同时 MSE 还提供了 SQL 的 TopN 列表，咱们能够一眼看出 RT 高的 SQL 语句，疾速定位利用变慢的根因。 ...

回看音讯队列发展史，RocketMQ 很荣幸的见证了音讯队列对于计算机及互联网世界的微小影响。参加了技术倒退对于产业及社会的价值重塑，减速了寰球企业数字化转型的过程。 Apache RocketMQ 作为配角之一，也在这一直进击的故事中，施展着重要作用与价值。截至目前，Apache RocketMQ 为寰球超过数万家企业提供服务，这其中不仅包含字节跳动、快手、小米、滴滴、同城艺龙等互联网头部企业，还有泛滥银行、券商、保险，基金公司等金融公司。作为解决海量音讯沉积以及电商场景下精准程序音讯散发的音讯队列我的项目，Apache RocketMQ 随同多年倒退，据不残缺统计，国内金融 Top100、保险 Top100、券商 Top50 中，超过 70% 机构或企业在外围利用链路上规模化部署了 RocketMQ。 作为国内重要的开源我的项目，为了帮忙更多企业、开发者、开源贡献者理解 Apache RocketMQ ，并退出其中，促成 Apache RocketMQ 及其开源生态的凋敝倒退，RocketMQ Summit 2022 将于 7 月 21 日-7 月 22 日正式拉开帷幕！ RocketMQ Summit 2022 邀请了多位来自不同行业、不同公司的顶级技术专家负责出品委员会，并由阿里云智能云原生利用平台负责人丁宇、阿里云智能音讯平台负责人林清山、开源社副理事长刘天栋(Ted)、微众银行技术专家陈广胜、快手技术专家黄理、字节跳动音讯产品负责人高昌利、中国移动技术专家胡宗棠、小米技术专家勇幸独特组成出品委员会，独特进行大会议题的内容评比，确保为各位参与者出现最空虚、最具价值的议题分享。 大会亮点领先看汇聚十余家出名开源我的项目与社区开源贡献者与技术实践者，共话 RocketMQ 生态最新公布与利用实际来自顶级我的项目的沉闷贡献者现场分享，议题笼罩金融、互联网、物流等数字化转型不同畛域，分享 RocketMQ 硬核实战经验。 能力矩阵重磅降级、社区版凋谢下载针对企业数字翻新过程中遇到的难题，RocketMQ 中文社区将凋谢下载最新社区版，助力企业疾速获取最新能力。 十大经典 RocketMQ 实战案例，企业技术负责人解析实际历程本次峰会邀请快手、小米、字节跳动等企业技术负责人，基于各自在数字翻新中遇到的挑战，解说如何应用 RocketMQ 实现跨越式倒退。 首发 RocketMQ 能力全景图，全面定义下一代音讯队列将来倒退方向全面降级 RocketMQ 开源生态，首发 RocketMQ 能力全景，打造对开发者更加敌对的实际门路，通过丰盛的开源我的项目，助力企业数字化转型。 RocketMQ 入手实战营正式上线，手把手帮忙开发者疾速上手 RocketMQRocketMQ 北京社区联结发起人 李伟、联结社区相干贡献者，独特打造系列实际课，从我的项目入门、业务利用演示、自测，分阶段进行学习，帮忙开发者提供收费试验资源以及详尽手册领导。 大会议程残缺出现

作者：刘洋（炎寻） 可观测是为了解决问题，所以在聊可观测之前，应先对问题排查的普适准则进行理解。 背景介绍问题排查的准则 以排查零碎问题为例，要了解零碎，要先关注基础知识，了解编程语言根本的计算机科学常识，关注零碎大图比方架构部署和重大流程，要关注运行细节，要对外围性能的算法和数据结构了然于心，还要关注零碎的运维工具，可能理解公布、回滚和监控。 在了解的根底上，还要可能复现问题，次要关注问题产生的触发条件以及问题产生时数据现场的保留，蕴含指标、链路、日志、事件等。 有了现场再加之对于零碎的，才能够定位问题。通过现场保留的数据，进行关联剖析；基于了解，能够疾速用二分定位到根因。在定位的过程中，尤其要关注变更，因为有大量的零碎问题是由变更导致的。 确定根因后再进行修复，既要治本也要治标，并且要充沛验证，确保不引入新的问题。 以上为问题排查的普适准则，它不仅实用于零碎问题的排查，也能够利用到生存的方方面面。 而可观测使得问题排查的过程更加高效、稳固、低成本。它可能帮忙咱们了解零碎，呈现问题的时候可能留下足够多的现场，可能使数据之间很不便地进行关联，帮忙咱们做二分的关联剖析，最终还能够验证修复是否正确。 Kubernetes 可观测挑战 复杂度是恒定的，它不会隐没，只会转移。咱们构建的编程语言、编程框架、容器操作系统都只是将复杂度关在适合的中央。如果所有运行失常，大快人心；而一旦呈现问题，就是劫难。复杂度一直下沉的趋势使得可观测面临了很大的压力。Kubernetes 的风行使得微服务架构非常遍及，多语言、多通信协议成为常态，这也在另一方面带来了挑战。 挑战 1：端到端观测复杂度回升，埋点老本居高不下。然而这只是冰山一角，有大量能力下沉到 Kubernetes 管控层、容器运行层、网络和操作系统层面，这些基础设施能力的下沉带来了很大挑战。 挑战 2：因为关注点的拆散，使得利用问题与底层问题无奈自顶向下造成关联。 挑战 3：尽管有很多工具，然而上下文缺失、数据散落，导致无奈通过这些数据很好地了解利用，因为现场的缺失无奈关联，而使问题排查效率低下。 可观测须要有对立的技术来解决本身的复杂度。 基于 eBPF 的可观测实际分享eBPF 介绍 从一开始，内核就是可观测的绝佳地位，然而因为效率和平安问题始终无奈实现。通过多年倒退，eBPF 技术为可观测关上了新的大门。 eBPF 是一项能够平安地在内核中运行沙盒程序的技术，无需批改代码即可在内核用户态程序事件产生时运行。它具备以下个性： 无侵入个性：观测老本极低，利用无需批改任何代码，也无需重启过程。 动静可编程性：无需重启探针，动静下发 eBPF 脚本即可批改探针侧的逻辑。 高性能：自带 JIT 编译，使探针可能取得内核本地运行的效率。 平安：verifier 机制限度了 eBPF 脚本可能拜访的内核函数，保障内核运行的稳固。 除了这些令人振奋的个性外，eBPF 的应用流程也十分不便。以监控、利用、性能为例，只须要加载编译 eBPF 程序监听网络的内核事件，解析网络协议，而后聚合成指标，输入 Trace 即可。 eBPF 失去了很多大公司的反对，倒退非常迅猛。过来一年，阿里云可观测团队基于 eBPF 技术构建了对立可观测平台。其架构如下图： 基于 eBPF 的对立可观测平台架构 最底层是数据采集层，次要采纳 Tracepoints、Kprobre、eBPF 函数抓取相干零碎调用，关联过程容器信息，造成原始事件，并通过 eBPF 和 sysdig 的联合反对多内核版本。同时为了解决事件爆炸的问题，引入了事件过滤和高性能事件传输机制。 往上是数据处理层。用户态获取到原始事件后，首先进行协定的解析，生成指标、链路、日志等数据，过程中也会对信息做收敛。而后填充元信息，比方 K8s 信息填充或自定义利用信息填充，最初监控数据会通过 OpenTelemetry Collector 输入。引入 OpenTelemetry Collector 次要为了反对多种数据类型以及多数据传输通道，反对将监控数据写入用户指定的存储。 ...

作者：Ethin 点击上方图片理解流动详情！ 哈喽各位开发者，为了帮忙大家主观理解并应用阿里云函数计算（FC），阿里云开发者社区携手云原生利用平台 Serverless 团队公布 “Serverless 函数计算征集令”，提供免费资源额度邀请你发文评测，7月31日前参加流动，即有机会取得千元好礼 + 千元函数计算资源包！ 立刻加入： https://developer.aliyun.com/... 轻轻说...当初投稿还可支付优酷视频季卡一张；上面让咱们追随笔友 “Ethin” 的步调，看看他眼中的 Serverless 世界吧！ 函数计算，你的名字云计算，是一种基于互联网的计算形式，通过这种形式，共享的软硬件资源和信息能够按需要提供给计算机各种终端和其余设施，应用服务商提供的电脑基建作计算资源，因而用 “云” 来指代 “网络计算资源” 这是一种十分失当的比喻。 美国国家标准和技术研究院的云计算定义中明确了三种服务模式，别离是软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）。 阿里云的产品能全副笼罩这三种服务模式，如果别离举个例子那么应该是：宜搭（SaaS 加速器）、函数计算 FC 和云服务器 ECS。 Serverless 计算服务，其基于 PaaS 又不同于 PaaS，因此更多时候被称作性能即服务（Function-as-a-Service，缩写为 FaaS）。函数计算 FC 是阿里云的事件驱动的全托管 Serverless 计算服务产品，我想函数计算 Function Compute 的名字就是这样诞生的。 函数计算，中转利用的外围咱们晓得利用的外围是逻辑和存储，而代码次要实现业务逻辑和长久化。 函数计算 FC 总体上是：FaaS+BaaS 函数指计算函数，蕴含了业务逻辑局部，这一部分由 FaaS 来实现；而数据长久化、音讯推送和账户零碎等，由 BaaS 来实现。 ECS ？FC ？ Serverless 服务并不是没有服务器了，而是作为一种新的架构让咱们在以往传统利用保护上的工作失去进一步升高。 以常见的次要基于云服务器的 Web 服务为例，大抵有这样的流程： 在服务过程中，服务器可能波及路由规定、鉴权逻辑以及其余各类简单的业务代码。同时，开发团队不仅要将精力用于开发，还要付出很大的精力在服务器的运维下面。例如要时刻关注以下问题： 服务器性能是否应答可能忽然暴发的用户申请，何时扩容？服务器上的脚本和业务代码等多少还在衰弱运行？内部网络安全威逼到来时如何保障数据安全？ 面对诸多问题的确会让人头大，但如果咱们摒弃基于服务器的架构而转用 Serverless 架构之后；服务的过程就变成了这样： 当客户端和数据库未发生变化的前提下，服务器变成了 Serverless 的架构。工作的分工产生了巨变。 例如，之前须要开发团队保护的路由模块以及鉴权模块都将接入服务商提供的 API 网关零碎以及鉴权零碎，开发团队无须再保护这两局部的业务代码，只须要继续保护相干规定即可，再也不必放心利用的构建；业务代码被拆分成了函数粒度，不同函数示意不同的性能，依据申请量还能够实现毫秒级扩容；业务逻辑之外的一部分平安问题、资源调度问题全都交由云厂商负责。 ...

EMAS Serverless 是阿里云提供的基于Serverless技术的一站式后端开发平台，为开发者提供高可用、弹性伸缩的云开发服务，蕴含云函数、云数据库、云存储、动态网站托管等性能，可用帮忙开发者及企业客户疾速实现一云多端利用的搭建，治理运维后端服务更简略，无缝对接丰盛的云资源。 这次的EMAS产品升级整合了原阿里云小程序云Severless产品的次要性能，产品做了底层架构优化，为利用开发者特地是多端开发者实现一站式利用开发提供了全新的开发体验。 EMAS Serverless的产品性能架构图： EMAS Serverless提供如下次要性能： 为了更好的布道推广 Serverless 开发生态，EMAS Serverless 面向开发者/学生提供收费套餐（不是只1个月哦，你懂的），针对业务倒退的不同阶段，提供多种套餐和按量付费模式。 请来阿里云官网一探到底！ 点击进入【EMAS Severless详情页】 点击进入【产品文档】 也欢送退出EMAS Serverless技术支持群，分割咱们的在线技术支持（ 44827893 ）

我国“十四五”布局中明确提出要“协同倒退云服务与边缘计算服务”，国务院《“十四五”数字经济倒退布局》同时指出要“增强面向特定场景的边缘计算能力”。5G、物联网等技术的规模化部署推动边缘计算需要激增，减速与行业交融倒退。 在此背景下，中国信息通信研究院、可信边缘计算推动打算、阿里云、CNCF OpenYurt 开源社区拟定于 2022 年 8 月 6 日联结举办“边缘原生”专题沙龙，邀请来自中国信通院云大说、CNCF 开源社区、WasmEdge 开源社区以及深服气、边无际、新华智云、Intel 等企业技术业余围绕边缘计算和云原生畛域倒退态势、开源社区现状、关键技术、典型利用实际等方面研究，减速边缘原生技术落地倒退。 流动报名信息流动日期 2022 年 8 月 6 日（周六） 13:30—18:00 观看地址 本场大会将在阿里云云原生微信视频号、云大说视频号以及映目直播同步进行 分享嘉宾及议题介绍13:30-13:40 | 致辞 栗蔚｜中国信通院 云计算与大数据研究所 副所长 13:40-14:10 | 边缘计算与云边端一体化倒退态势 李昂｜信通院云大所政企数字化转型部业务主管 14:10-14:40 | OpenYurt：助力云边端一体化协同 何淋波｜CNCF OpenYurt 社区负责人，阿里云技术专家 议题简介：云计算的呈现促使物联网实现爆炸式增长。在设施规模和业务复杂度一直攀升的趋势之下，边缘计算因其可能将计算能力更凑近网络边缘和设施，从而带来云性能老本的升高，也在这波浪潮之下失去疾速倒退。本次分享，将与各位独特探讨什么是边缘计算、云原生时代的边缘计算等问题，同时向大家具体介绍 CNCF 我的项目 OpenYurt 以及基于 OpenYurt 的云边端一体化实际。 14:40-15:10 | 基于 OpenYurt 的端到端视频剖析 陈绍强｜英特尔（中国）有限公司 资深架构师 议题简介：视频剖析是边缘计算的典型利用。边缘计算的规模化利用的一个必须条件是须要解决云边协同的基础设施。OpenYurt 是对 K8s 的无侵入式扩大，并且联合 edgex 提供了端设施的管控。咱们以 OpenYurt 为底座，实现了一个端到端的视频剖析解决方案，为用户提供各种所需能力，诸如摄像头治理，ingress，业务负载平衡，视频 AI 剖析等，满足实在场景下规模化的视频剖析部署。 15:10-15:40 | 深服气边缘计算关键技术及落地实际 赵振阳｜深服气研发架构师 议题简介：本次分享将介绍边缘计算下面临的次要挑战，深服气在云边协同、边缘计算上做的摸索和计划，深服气基于开源社区对于边缘计算、云边协同一些能力建设和思考，以及在如何应用边缘计算帮客户解决理论问题。 15:40-16:10 | 面向产业物联网的开源开发平台——Shifu Framework 秦小禹｜边无际（北京）科技有限公司联结创始人兼首席工程师 议题简介：传统物联网开发的过程中，开发者常常会与不同的物联网零碎，驱动，协定打交道。Shifu 致力于将这些简单的底层形象，真正给开发者提效。所以 Shifu 南向对接各式各样的物联网设施以及零碎，北向用 HTTP 或者 gRPC 的模式来对接下层利用。 计划：如何在 OpenYurt 上部署 Shifu 拓展物联网开发能力，OpenYurt 负责北向，云边协同，Shifu 负责南向，边端协同 成果：让开发一个工业场景都像开发一个 APP 一样简略；基于 K8s CRD，无需再部署一套新的基础设施；让传统的物联网利用开发（如 MES, SCADA 等）转为简略的 web 开发；将软硬件彻底解耦，每一个场景都有属于本人的一个 Shifu。 ...

开源是根底软件的基本。云+开源，将独特成为数字世界的根。将来数字世界的根底软件应该建设在开源之上，须要全行业共建、共享。因而，阿里云不仅踊跃拥抱开源，也被动回馈开源，引领开源，开源曾经成为了阿里技术策略之一。 7月28日，阿里巴巴团体 CTO 程立受邀加入2022凋谢原子寰球开源峰会，并在主论坛演讲中提到，容器技术是从阿里外部实际倒退到云上商业化，并逐渐成为寰球容器技术引领者。 他提到，“阿里云是寰球 Kubernetes 社区重要企业贡献者，为寰球云原生开源社区做出了重大贡献。 2017年，阿里云容器服务 ACK 正式公布，成为寰球首批通过 Kubernete 一致性认证的产品。往年，阿里云成为国内惟一进入 Forrester 公共云容器平台领导者象限的企业。” 阿里云构建了残缺的云原生开源生态，通过 KubeVela、OpenYurt、OpenKruise、Fluid等多个开源我的项目，帮忙 Kubernetes 向边缘、AI、混合云等更多场景延长。KubeVela打造了面向云计算时代的现代化利用交付治理事实标准，以利用为核心，定义研发、运维与基础设施之间的边界与协同形式，曾经成为CNCF沙箱我的项目。2021年信通院将 KubeVela 的利用模型（OAM）作为行业架构规范公布。 OpenYurt是阿里开源的首款云原生边缘计算我的项目，助力打造智能化、云边端一体化的边缘计算云原生基础设施，目前曾经成为CNCF沙箱我的项目。OpenYurt开源以来，在上下游单干，技术、社区、行业影响力均有了显著的晋升，并在2020年12月取得亚太CDN产业联盟边缘计算影响力我的项目TOP3；在生态单干方面，和VMware、intel、深服气、联通、IBM 等上下游生态搭档在IoT、云边协同、硬件、边缘AI、边缘平安等方面开展了多层次单干，其中和LFEdge EdgeX我的项目的深度单干，共推云原生物模型规范成为业界独创。 2021年双11，阿里团体实现 100%利用云原生化，实现寰球最大规模云原生实际，电商、搜寻、大数据、AI 业务全副运行在对立的容器平台之上。容器服务 ACK 已为互联网、金融、批发、制作、交通等云上万余家企业提供容器利用治理服务。 阿里云在云原生畛域领有泛滥出名开源我的项目，包含两大 Apache 顶级我的项目和十大 CNCF 托管我的项目，笼罩容器、利用交付、音讯、微服务、Serverless 等技术方向，开源活跃度和影响力全面当先。其中，一些开源我的项目也成为了畛域事实标准，如 Apache RocketMQ 作为国内首个互联网中间件 Apache 顶级我的项目，在业务音讯畛域中国市场占有率第一；Apache Dubbo是开源服务框架中影响力最大、采用率最高的国产微服务框架。和 RocketMQ 一样，Dubbo 在全球化和影响力两大维度进入了 Apache 中国开源我的项目象限第一方阵。 Apache RocketMQ由阿里巴巴开源的Apache顶级我的项目，作为国内首个开源分布式消息中间件，在业务音讯畛域中国市场占用率第一，重磅降级RocketMQ 5.0在业界率先推出云原生“音讯(Messaging)、事件(Eventing)、流(Streaming)”一体的交融音讯解决平台，RocketMQ 在全球化和影响力两大维度进入了 Apache 中国开源我的项目象限第一方阵，并成为北京大学软件与微电子学院开源实际选修课程；在商业化方面，基于RocketMQ打造的阿里云MQ音讯产品超过IBM成为中国市场占有率第一。 Apache Dubbo由阿里巴巴开源的Apache顶级我的项目，是开源服务框架中影响力最大、采用率最高的国产微服务框架。和 RocketMQ 一样，Dubbo 在全球化和影响力两大维度进入了 Apache 中国开源我的项目象限第一方阵。依据 X-lab 凋谢实验室最新公布的《微服务畛域开源数字化报告》，Dubbo 的开源活跃度在微服务框架中全球排名第五。2021年推出的Dubbo 3，基于在阿里的大规模应用场景孵化，倒退成为用户敌对的新一代云原生服务框架，持续引领国内下一代服务框架选型浪潮。 往年，阿里云在云原生畛域继续冲破，公布两大开源我的项目：一个是云原生混部零碎 Koordinator，它是基于阿里巴巴外部超大规模混部实际，为用户打造云原生场景下接入老本最低、混部效率最佳的解决方案。另一个是与企业和社区独特发动的OpenSergo 我的项目，解决不同框架之间互通带来的各类损耗和高复杂度等问题。 目前，阿里云开源次要涵盖云原生、操作系统、大数据&AI、数据库四大畛域，在GitHub上播种Star总数超百万，阿里曾经间断十年蝉联中国厂商开源活跃度、影响力第一。

第三届云原生编程挑战赛是由阿里云、Intel 主办，云原生利用平台、天池联结承办的云原生顶级赛事。自 2015 年开始，大赛曾经胜利举办了七届，共吸引了超过 36000 支队伍，笼罩 10 余个国家和地区，为寰球酷爱技术的年轻人提供了一个摸索云原生技术、挑战难题的舞台。 在云原生实际一直深入的过程中咱们发现，随着边缘设施和边缘业务的规模增长，以及业务翻新带来的频繁变更，在云边协同的边缘场景架构体系下，“云边协同”正在面临微小的管理效率和老本挑战。 作为本次大赛三大热门技术畛域之一，“边缘容器”赛道的发动就心愿在这样的背景下，通过集结关注、酷爱云原生的开发者的智慧、技术和能量，摸索钻研如何在云边协同的边缘场景架构体系下，升高边缘侧组件的资源占用率，实现一个高效的边缘自治计划。 当初，云原生编程挑战赛“边缘容器赛题”曾经吹响集结号，全面凋谢报名，期待有能力、有气魄、有生机的开发者们前来挑战！ 参加边缘容器赛道挑战，瓜分 170,000 元现金处分本次大赛面向寰球凋谢，大赛分为初赛和决赛，各赛道初赛 TOP6 战队入围决赛问难。最终排行将依据初赛及决赛问难问题综合得出。 专属赛道处分，周周送不停除了云原生编程大赛官网处分，为了激励更多开发者参加边缘容器赛道挑战，即日起，胜利提交赛题工作并在每周排行榜中位列 Top 1 的用户，均将取得云原生边缘容器开源平台 OpenYurt 定制随行杯一个！（每人限一次） 明星导师 张杰，阿里云云原生技术专家，CNCF OpenYurt 开源社区核心成员 赛题解析赛题背景ACK@Edge 是阿里云容器服务针对边缘计算场景推出的云边一体化云原生解决方案，主打“云端托管、边缘自治”的产品理念，为用户提供云边多维度协同，海量异构算力治理，边缘 AI 套件，可观测，轻量化，弹性等能力。现已广泛应用于边缘云、物联网等典型边缘计算场景，笼罩交通、能源、新批发、智慧驾驶、CDN 等多个行业。同时，ACK@Edge 依靠 CNCF OpenYurt 弱小的社区生态，积极参与并协同社区继续打磨和欠缺设施孪生、云边协同网络、高可用等当先技术能力。 为了解决在边缘计算场景下云边网络通信断连时，保障边缘侧节点上业务能够自愈，OpenYurt 在边缘侧组件和 APIServer 之间新增 YurtHub 组件。边缘侧的组件（kubelet,kube-proxy..）对 api server 的申请，会首先通过 YurtHub 组件的而后再转发给 api server，YurtHub 会将 api server 返回的数据缓存到本地。当云边网络断开时，Yurthub 还能将本地缓存的数据返回给边缘侧组件。 然而在实际过程中咱们发现，在云边协同的边缘场景架构体系下，有着大量的轻量级的设施，这些设施的配置绝对比拟低，升高边缘侧组件的资源占用率，为设施上的业务腾出更多的资源，曾经成为了必须要解决的问题。 本赛题心愿实现一个边缘侧的 edge-proxy 组件，负责转发边缘侧组件例如 kubelet,kube-proxy 的申请，同时可能将云上 api server 返回的数据进行过滤，同时在返回给申请端时能够缓存到本地，并尽可能的升高 cpu，内存等资源占用率。 赛题解析在 Kubernetes 零碎中，list/watch 机制次要解决组件间实时数据的异步同步。其中 List 申请是一般的 HTTP GET 申请，一次 List 申请将返回申请类型资源的全量数据。而 watch 申请是基于 HTTP 协定的 chunked 机制实现的长连贯，用于实时告诉申请资源的数据变动。相干的介绍能够参考： ...

作者：昶风 引言CDC（Change Data Capture）指的是监听上游数据变更，并将变更信息同步到上游业务以供进一步解决的一种利用场景。近年来事件驱动架构（EDA）热度逐渐回升，日渐成为我的项目架构设计者的第一抉择。EDA 人造符合 CDC 的底层基础架构，其将数据变更作为事件，各个服务通过监听本人感兴趣的事件来实现一些列业务驱动。阿里云 EventBridge 是阿里云推出的一款无服务器事件总线服务，可能帮忙用户轻松快捷地搭建基于 EDA 架构的利用。近期，EventBridge 事件流曾经反对了基于阿里云 DTS [ 1] 服务的 CDC 能力。本文将从 CDC、CDC 在 EventBridge 上的利用以及若干最佳实际场景等方面，为大家介绍如何利用 EventBridge 轻松构建 CDC 利用。 CDC 概述基本原理与利用场景CDC 从源数据库捕捉增量的数据以及数据模式变更，以高牢靠、低延时的数据传输将这些变更有序地同步到指标数据库、数据湖或者其余数据分析服务。目前业界支流的开源 CDC 工具包含 Debezium [2 ] 、Canal [3 ] 以及 Maxwell [4 ] 。 图片起源：https://dbconvert.com 目前业界次要有以下几类 CDC 的实现： 1. 基于工夫戳或版本号 基于工夫戳的形式要求数据库表有一个字段代表更新工夫戳，当存在数据插入或更新时，对应工夫戳字段就会随之更新。CDC 组件周期性检索更新工夫大于上次同步工夫的数据记录，即可捕捉本周期内数据的变更。基于版本号跟踪和基于工夫戳跟踪原理基本一致，要求开发者变更数据时必须更新数据的版本号。 2. 基于快照 基于快照的 CDC 实现在存储层面应用到了数据源 3 份正本，别离是原始数据、先前快照和以后快照。通过比照 2 次快照之间的差别来获取这之间的数据变更内容。 3. 基于触发器 基于触发器的 CDC 实现形式事实上是在源表上建设触发器将对数据的变更操作（INSERT、UPDATE、DELETE）记录存储下来。例如专门建设一张表记录用户的变更操作，随后创立 INSERT、UPDATE、DELETE 三种类型的触发器将用户变更同步到此表。 4. 基于日志 以上三种形式都对源数据库存在肯定侵入性，而基于日志的形式则是一种非侵入性的 CDC 形式。数据库利用事务日志实现灾备，例如 MySQL 的 binlog 就记录了用户对数据库的所有变更操作。基于日志的 CDC 通过继续监听事务日志来实时获取数据库的变动状况。 ...

第三届云原生编程挑战赛，是由阿里云、Intel 主办，云原生利用平台、天池联结承办的云原生顶级品牌赛事。自 2015 年开始，大赛曾经胜利举办了七届，并从 2020 年开始降级为首届云原生编程挑战赛，共吸引了超过 36000 支队伍，笼罩 10 余个国家和地区。 日前，第三届云原生编程挑战赛曾经正式启动！本届大赛将深度摸索服务网格、边缘容器、Serverless 三大热门技术畛域，针对行业热门技术方向，把握外围解决问题、思考问题的形式，使用最前沿的产品技术工具，全面晋升集体能力。 据统计，2022 年有超过 75% 的企业在生产环境中应用容器。企业在建设 IT 架构时，云不再是第三方孤立的平台，而是成为企业 IT 架构的一部分，云原生正变革开发模式。企业需思考云上运维、云上开发、云上迭代、云上容灾等问题，因而全云开发时代未然降临，开发者和企业将迎来技术红利暴发的黄金时代。那么开发者该如何适应这些变动？其中一种形式是降级集体技能和认知，从新适应一些工作模式，比方如何在云上做权限治理、资产治理、云上运维等。而云原生编程挑战赛正是基于此面向宽广开发者发动的赛事，期待云原生开发者们的退出和踊跃报名！ 赛道一：针对 Sidecar 模式下的服务网格数据面应用服务拜访 QPS 和延时的优化在服务网格技术呈现之前，能够应用 SpringCloud、Netflix OSS 等，通过在应用程序中集成 SDK，编程的形式来管理应用程序中的流量。然而这通常会有编程语言限度，而且在 SDK 降级的时候，须要批改代码并从新上线利用，会增大人力累赘。服务网格技术使得流量治理变得对应用程序通明，使这部分性能从应用程序中转移到了平台层，成为了云原生基础设施。以 Istio 为首的服务网格技术，正在被越来越多的企业所注目。 本赛题心愿从Sidecar代理资源分配、Sidecar配置调优、硬件优化几个角度登程，通过构建一种服务网格性能与资源占用动静优化零碎，实现在尽量减少Sidecar代理资源耗费的状况下，尽可能升高集群中服务的申请时延。 立刻扫码报名 赛道二：针对云原生边缘计算场景的 ACK@Edge 高效的边缘自治计划在云边协同的边缘场景架构体系下，随着边缘设施和边缘业务的规模增长，以及业务翻新带来的频繁变更，给云边协同带来了微小的管理效率和老本挑战。在实际过程中咱们发现，在云边协同的边缘场景架构体系下，有着大量的轻量级的设施，这些设施的配置绝对比拟低，升高边缘侧组件的资源占用率，为设施上的业务腾出更多的资源，曾经成为了必须要解决的问题。 本赛题心愿实现一个边缘侧的 edge-proxy 组件，负责转发边缘侧组件例如 kubelet/kube-proxy 的申请，同时可能将云上 apiserver 返回的数据缓存到本地，实现节点自治，并尽可能的升高 cpu，内存的资源占用率，实现一个高效的边缘自治计划。 立刻扫码报名 赛道三：实现一个 Serverless 架构的 Web IDE 服务在云的时代，IDE 越来越向着轻量化、分布式的方向演进。在小程序、Low code/No code、在线编程教育、前端一体化开发、大数据处理等畛域，Web IDE 都体现了越来越重要的价值。Web IDE 的应用通常是多租户、碎片化的。基于传统架构，要实现一个多租平安、可扩大、高性能、低成本的 IDE 服务很简单。而借助 Serverless 架构，将大幅升高难度。本赛题将提供一个 Web IDE 服务的参考实现，您在此基础上进行扩大，施展您的创意，发明一个独特的 Web IDE 服务！ ...

近日，远光软件股份有限公司新一代企业数字外围零碎远光达普（YG-DAP）V7.1 通过阿里云产品集成认证测试，与阿里云旗下的阿里云应用服务器（V1.0）、阿里云 PolarDB 数据库管理软件、音讯队列 RocketMQ 版（V3.16）以及企业级分布式应用服务 EDAS（V4.0）深度集成。这意味着在云原生畛域远光软件与阿里云正式携手单干。 此前，阿里云首次提出了“被集成”策略：将行业解决方案的搭建、施行、复制交由合作伙伴，阿里云只承当基础设施（IaaS）、技术中间件（PaaS）、数据平台（DaaS）层面的产品技术。“被集成”是阿里云对业务边界进行认真思考后作出的一个重要转变，标记着阿里云生态对合作伙伴的全面凋谢。 阿里云产品生态集成认证是面向阿里云合作伙伴自有产品、解决方案与阿里云相干产品的兼容性、可用性的技术能力认证。取得此认证，证实了远光软件的技术能力、产品利用程度已满足阿里云相干产品的适配性要求，远光软件以阿里云技术底座，为用户提供牢靠、无效的产品与解决方案技术服务，这为远光软件与阿里云生态的严密单干提供了强力的技术保障。 远光软件是国内支流的企业治理、能源互联和社会服务信息技术、产品和服务提供商，专一大型团体企业治理信息化逾30年，主营产品与服务包含数字企业、智能物联、数字社会等。公司扎根能源行业，在能源行业企业管理软件畛域长期处于领先地位。远光 DAP 是采纳新理念、新技术、新模式构建的超过传统ERP的企业级外围利用。基于微服务、中台化的云原生架构，建设“战略规划、资源管理、生产经营、共享服务、数据经营”五大外围畛域利用，以数据驱动业务管理，以智能撑持战略决策，促成产业互联、社会互联生态。目前，远光 DAP 已通过了第三方的业余测评和认证，在平安、性能、性能方面达到业内当先，服务了能源电力、航天航空、高端配备等多个行业的大型团体客户，为企业数字化、智能化转型降级注智赋能。 阿里云关系型数据库RDS（Relational Database Service）是一种稳固牢靠、可弹性伸缩的在线数据库服务，基于阿里云分布式文件系统和SSD盘高性能存储。经严格测试，远光DAP与阿里云RDS数据库单方在兼容性、适配性方面体现优异。 企业级分布式应用服务 EDAS 积淀了阿里巴巴十多年在 PaaS 层的技术实际和积淀，全面拥抱开源，反对 Spring Cloud/Dubbo 等微服务技术体系，同时也反对 K8s 容器技术体系，集利用公布治理、微服务治理、容器治理、可观测能力以及命名空间、子账户等企业级个性于一身，打造一站式 PaaS 治理平台。 RocketMQ 5.0 专一于音讯基础架构的云原生化演进，聚焦在音讯畛域的后处理场景，反对音讯的流式解决和轻计算，帮忙用户实现音讯的就近计算和剖析，并全面拥抱 Serverless 和 EDA。 阿里云领有丰盛的云原生产品家族，有超过 300 款的产品，近千个技术解决方案。随同着云原生时代的到来以及实时计算的衰亡， 生于云、长于云的 RocketMQ 5.0 应运而生，全新降级为云原生音讯、事件、流交融解决平台，帮忙用户更容易地构建下一代事件驱动和流解决利用。本次远光软件取得阿里云产品集成认证，代表了远光软件在生态单干建设上迈过了一个新里程碑。远光软件始终以生态搭档的身份与阿里云放弃着深度单干。将来，借助阿里云的“被集成”生态策略与生态集成技术的全面凋谢，单方的严密单干将进入新的阶段，独特为中国数千万家企业提供数字化转型服务。

异步工作解决零碎中的数据分析数据处理、机器学习训练、数据统计分析是最为常见的一类离线工作。这类工作往往都是通过了一系列的预处理后，由上游对立发送到工作平台进行批量训练及剖析。在解决语言方面，Python 因为其所提供的丰盛的数据处理库，成为了数据畛域最为罕用的语言之一。函数计算原生反对 Python runtime，并反对快捷的引入第三方库，使得应用函数计算异步工作进行解决变得极为不便。 数据分析场景常见诉求数据分析场景往往具备执行工夫长、并发量大的特点。在离线场景中，往往会定时触发一批大量的数据进行集中处理。因为这种触发个性，业务方往往会对资源利用率（老本）具备较高的要求，冀望可能满足效率的同时，尽量降低成本。具体归纳如下： 程序开发便捷，对于第三方包及自定义依赖敌对；反对长时运行。可能查看执行过程中的工作状态，或登录机器进行操作。如果呈现数据谬误反对手动进行工作；资源利用率高，老本最优。以上诉求非常适合应用函数计算异步工作。 典型案例 - 数据库自治服务业务根本状况阿里云团体外部的数据库巡检平台次要用于对 sql 语句的慢查问、日志等进行优化剖析。整个平台工作分为离线训练及在线剖析两类次要工作，其中在线剖析业务的的计算规模达到了上万核，离线业务的每日执行时长也在数万核小时。因为在线剖析、离线训练工夫上的不确定性，很难进步集群整体资源利用率，并且在业务顶峰来时须要极大的弹性算力反对。应用函数计算后，整个业务的架构图如下： 业务痛点及架构演进数据库巡检平台负责阿里巴巴全网各 Region 的数据库 SQL 优化及剖析工作。Mysql 数据来源于各 Region 的各个集群，并对立在 Region 维度进行一次预聚合及存储。在进行剖析时，因为须要跨 region 的聚合及统计，巡检平台首先尝试在内网搭建大型 Flink 集群进行统计分析工作。然而在理论应用中，遇到了如下问题： 数据处理算法迭代繁琐。次要体现在算法的部署、测试及公布上。Flink 的 Runtime 能力极大限度了公布周期；对于常见的及一些自定义的第三方库，Flink 反对不是很好。算法所依赖的一些机器学习、统计的库在 Flink 官网 Python runtime 中要么没有，要么版本老旧，应用不便，无奈满足要求；走 Flink 转发链路较长，Flink 排查问题艰难；峰值时弹性速度及资源均较难满足要求。并且整体老本十分高。 在理解了函数计算后，针对 Flink 计算局部进行了算法工作的迁徙工作，将外围训练及统计算法迁徙至函数计算。通过应用函数计算异步工作所提供的相干能力，整个开发、运维及老本失去了极大的晋升。 迁徙函数计算架构后的成果迁徙函数计算后，零碎可能残缺承接峰值流量，疾速实现每日剖析及训练任务；函数计算丰盛的 Runtime 能力反对了业务的疾速迭代；计算上雷同的核数老本变为了原来 Flink 的 1/3。 函数计算异步工作十分实用于这类数据处理工作。函数计算在升高运算资源的老本同时，可能将您从繁冗的平台运维工作中解放出来，专一于算法开发及优化。 函数计算异步工作最佳实际-Kafka ETLETL 是数据处理中较为常见的工作。原始数据或存在于 Kafka 中，或存在于 DB 中，因为业务须要对数据进行解决后转储到其余存储介质（或存回原来的工作队列）。这类业务也属于显著的工作场景。如果您采纳了云上的中间件服务（如云上的 Kafka），您就能够利用函数计算弱小的触发器集成生态便捷的集成 Kafka，而无需关注诸如 Kafka Connector 的部署、错误处理等与业务无关的操作。 ETL 工作场景的需要一个 ETL 工作往往蕴含 Source、Sink 及处理单元三个局部，因而 ETL 工作除了对算力的要求外，还须要工作零碎具备极强的上下游连贯生态。除此之外，因为数据处理的准确性要求，须要工作解决零碎可能提供工作去重、Exactly Once 的操作语义。并且，对于解决失败的音讯，须要可能进行弥补（如重试、死信队列）的能力。总结如下： ...

大赛介绍第三届云原生编程挑战赛，是由阿里云、Intel 主办，云原生利用平台、天池联结承办的云原生顶级品牌赛事。自 2015 年开始，大赛曾经胜利举办了七届，并从 2020 年开始降级为首届云原生编程挑战赛，共吸引了超过 36000 支队伍，笼罩 10 余个国家和地区。本届大赛将持续深度摸索服务网格、边缘容器、Serverless 三大热门技术畛域，为酷爱技术的年轻人提供一个挑战世界级技术问题的舞台，心愿用技术为全社会发明更大价值。 参加话题投稿选手分享参赛心得、参赛技术攻略、大赛相干产品的应用体验（服务网格、边缘容器、Serverless 产品）、集体参赛成长经验和感想等帖子至开发者下来，将有机会取得大奖礼品！ 注：奖品不能累计取得，取最高奖发放 点击此处，返回理解。

作者：十眠 什么是全链路灰度？微服务体系架构中，服务之间的依赖关系盘根错节，有时某个性能发版依赖多个服务同时降级上线。咱们心愿能够对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。 点击下方链接，查看直播教程： https://yqh.aliyun.com/live/d... 在公布过程中，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图： 上图能够很好展现这种计划的成果，咱们用不同的色彩来示意不同版本的灰度流量，能够看出无论是微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境，这种计划不仅能够节俭大量的机器老本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。 OpenSergo[1] 流量路由规范Q：OpenSergo是什么？ A：OpenSergo 是一套凋谢、通用的、面向分布式服务架构、笼罩全链路异构化生态的服务治理规范，基于业界服务治理场景与实际造成服务治理通用规范。OpenSergo 的最大特点是以对立的一套配置/DSL/协定定义服务治理规定，面向多语言异构化架构，做到全链路生态笼罩。无论微服务的语言是Java, Go, Node.js还是其它语言，无论是规范微服务还是 Mesh 接入，从网关到微服务，从数据库到缓存，从服务注册发现到配置，开发者都能够通过同一套OpenSergo CRD标准配置针对每一层进行对立的治理管控，而无需关注各框架、语言的差别点，升高异构化、全链路服务治理管控的复杂度 Q：为什么理解全链路灰度之前先给我介绍 OpenSergo？A：OpenSergo 定义了一套对立的 YAML 配置形式来针对分布式架构进行全链路的服务治理的标准，介绍标准与规范的同时，咱们能够理解其中的技术细节的实现，同时咱们还能够将新的组件与 OpenSergo 的规范进行实现。 流量路由，顾名思义就是将具备某些属性特色的流量，路由到指定的指标。流量路由是流量治理中重要的一环，开发者能够基于流量路由规范来实现各种场景，如灰度公布、金丝雀公布、容灾路由、标签路由等。 全链路灰度示例： 流量路由规定(v1alpha1) 次要分为三局部： Workload 标签规定 (WorkloadLabelRule)：将某一组 workload 打上对应的标签，这一块能够了解为是为利用或者对应存储层的话就是数据库负载（数据库、表）打上对应的标签流量标签规定 (TrafficLabelRule)：将具备某些属性特色的流量，打上对应的标签依照 Workload 标签和流量标签来做匹配路由，将带有指定标签的流量路由到匹配的 workload 中 给流量打标：须要将具备某些属性特色的流量，打上对应的标签。 假如当初须要将深圳地区的用户灰度到新版主页，测试用户 location=cn-shenzhen，cn-shenzhen 位于 location header 中： apiVersion: traffic.opensergo.io/v1alpha1kind: TrafficLabelRulemetadata: name: my-traffic-label-rule labels: app: spring-cloud-zuulspec: selector: app: spring-cloud-zuul trafficLabel: gray match: - condition: "==" # 匹配表达式 type: header # 匹配属性类型 key: 'location' # 参数名 value: cn-shenzhen # 参数值通过上述配置，location header 为 cn-shenzhen 的 HTTP 流量，打上 gray 标，代表这个流量为灰度流量。 ...

作者：卜比 概述随着 Go 语言、云原生的宽泛采纳，Go 语言在微服务场景中应用的越来越宽泛，对 Go 语言微服务的治理、限流降级需要也越来越强。 在 Go 语言中，尽管社区提供了 go.uber.org/ratelimit 等限流库，但其一，对多语言反对有余，只反对 Go，其二，性能上，限流降级会细分为流控、隔离、熔断、热点等性能，也不反对动静配置，在性能反对度上不够欠缺。 阿里云微服务引擎（MSE）联合 Sentinel，给 Go 语言、Java 语言利用带来微服务治理能力。本文将给大家介绍如何在 Go 语言微服务利用中应用限流降级能力。 什么是限流降级 在微服务利用中，限流降级次要分为三步： Target: 针对什么样的流量Strategy: 限流降级的策略FallbackAction: 触发后的行为 比方，针对订单创立接口（Target），咱们限度申请为 1000QPS（Strategy），触发限流后，申请返回异样（FallbackAction）。 在阿里云 MSE 反对通过开源 Sentinel 的形式来定义资源，并从 MSE 获取、利用限流降级规定，整体接入如下： 如何应用 MSE 限流降级利用接入下载 MSE Go SDK [ 1] ，解压到我的项目的./pkg-custom/github.com/aliyun/aliyun-mse-go-sdk-v1.0.7 目录。<!----> 能够参考 SDK 的 example 目录下的例子，来进行接入。在 go.mod 文件中，增加如下依赖申明：require ( github.com/aliyun/aliyun-mse-go-sdk v1.0.7)replace github.com/aliyun/aliyun-mse-go-sdk => ./pkg-custom/github.com/aliyun/aliyun-mse-go-sdk在利用的启动过程中，增加 MSE SDK 初始化命令：import ( mse_sdk "github.com/aliyun/aliyun-mse-go-sdk")// 在利用的初始化逻辑中退出以下代码。// Sentinel core的初始化蕴含在了这外面。如果之前有调用过Sentinel的初始化函数，须要去掉。err := mse_sdk.InitMseDefaultif err != nil { log.Fatalf("Failed to init MSE: %+v", err)}利用部署在云原生部署形式中，通常的部署标准是 12 因子 [ 2] ，其中对于配置，举荐将利用的配置存储于环境变量中。这样利用在部署时，只须要切换不同的环境变量，就能够接入不同的环境。 ...

作为一款消息中间件，RocketMQ 的第一行代码诞生于 2012 年。从撑持淘宝天猫业务，到对立阿里巴巴消息中间件，再到开源普惠各行各业，人不知;鬼不觉间 RocketMQ 走过了十年。 借助开源，RocketMQ 吸引了泛滥志同道合者，汇聚数百人、数千人、数万人一起开发，排汇各个公司、行业、业务场景的需要，汇聚最大的生产力。整个开发过程中，泛滥开发者、开源爱好者帮忙 Review 代码、测试 Bug，RocketMQ 在泛滥开发者的参加下停顿迅速。 通过十年开源建设，明天的 RocketMQ 曾经领有超过 2 万个 GitHub Star，服务数十万开发者，Contributor 人数超 500，每天通过 RocketMQ 流转的音讯超过十万亿条。 也是在大家致力下，一个由中国开发者发动的我的项目站在了世界的舞台上，受到寰球的企业和开发者的关注。对于开发者而言，咱们认为开源最重要的是在解决世界上最难、最有挑战的问题。并且大家合作的我的项目能被越来越多开发者应用，这也就意味着说我的项目在这个畛域是顶尖的。从某种角度而言，开源是一种最优良的软件开发模式，通过开源模式能把我的项目做到最优良。最终能造成一个规范，让所有人进行技术选型时不必再做抉择，反正抉择规范就对了。 2021 年，RocketMQ 推出了 5.0 版本，实现从业务音讯平台向“音讯、事件、流”一体化交融解决平台的降级，并在数据通道、事件驱动架构、剖析计算等场景一直产生新价值。2022 年，批量音讯索引、逻辑队列公布 RocketMQ-MQTT，RocketMQ-Connect。 作为面向开源及音讯畛域的顶级我的项目，2022 年 7 月 21 日-7 月 22 日，RocketMQ Summit 如约而至，近四十个优质议题与探讨，期待你的参加！ 在常设主论坛之外，本次 RocketMQ Summit 分设「行业摸索实际」、「开源生态倒退」、「核心技术解析」三大分论坛。从行业实际、生态倒退、技术解读三大维度全面展示 Apache RocketMQ 的倒退全貌，小米、快手、同程艺龙、vivo、光大银行、挪动云、中通快递、闪送等不同行业头部企业带来全景分享。深刻解说企业落地 RocketMQ 过程中的技术挑战与难题，分享场景摸索教训。 其中「核心技术解析」专场最为值得期待，不仅有 RocketMQ 在流计算场景的深度解读，还有 RocketMQ-EventBridge 云原生事件驱动引擎的利用与技术解析，更有音讯与流存储高可用架构的再降级。 精彩不容错过，点击此处立刻预约！ 演讲之外，当日更有泛滥精彩开发者流动不容错过！

对 IT 从业者来说，把握容器技术既是市场的须要，也是晋升自我价值的重要途径。7 月 20 日，「玩转容器服务进阶训练营」正式上线，近 500 名“玩家”踊跃报名。具体什么是进阶训练营？进阶训练营有哪些干货？参与者能播种什么？以及如何加入等，对于大家的疑难，本文将一一解答。 对于玩转容器服务进阶训练营「玩转容器服务进阶训练营」是以「5 分钟玩转阿里云容器服务」系列课程为根底，依据不同章节，阶段性发展学习+体验+交换的进阶训练营，由阿里云云原生专家实时在线破解容器规模化落地难点和翻新办法，帮忙更多开发者疾速把握企业级容器利用施行技能。本次训练营的核心内容包含： 不会就学——系列课程精心打磨，疾速把握企业级容器利用施行技能不熟就练——双模式学习+工作打卡，解锁工作关上容器高效学习工具箱不懂就问——大咖直播课1对1答疑，精准破解容器规模化落地难题进阶直播课开播倒计时第一期训练营进阶直播课将于 8 月 2 日-8 月 3 日间断两天开展，围绕“容器网关 Ingress” 和 "容器操作系统" 的进阶操作，帮忙大家攻破难点。 进阶直播 1：8 月 2 日 18:00-19:00 |  如何在 ACK 中应用 MSE Ingress主讲人：李艳林(彦林)，Nacos 创始人，MSE 创始人，阿里中间件上云负责人，阿里云高级技术专家，十年微服务研发教训，参加阿里异地多活架构演进，全链路压测，百万实例架构演进，全面上云，开源和阿里云等要害战斗。课程简介：本次课程次要分享 Ingress 发展趋势，探讨 Ingress/Gateway API 规范趋势，分享 Nginx/Envoy Ingress 技术趋势，论述 阿里云 MSE Ingress 的劣势和实际，帮忙业务从入口规范的建设高可用和平安防线。 进阶直播 2：8 月 3 日 18:00-19:00 | 在 ACK 中如何应用容器优化的操作系统 主讲人：贾正华（晓贾），阿里云操作系统产品专家，长期从事 Linux 操作系统相干的工作，从 Linux 内核研发到操作系统产品开发，从个性功能设计到产品设计，目前次要负责阿里云操作系统团队的产品和布局。 课程简介：专家在线直播&答疑，在 ACK 中如何应用容器优化的操作系统 Alibaba Cloud Linux 进阶训练营增补名额限时凋谢，赶快报名！截至 7 月 27 日，原定 500 人训练营曾经满员，咱们将限时凋谢减少名额，赶快扫描下方二维码或点击浏览原文， 立刻跟上学习队形，成为容器服务进阶玩家！ 【互动有礼】不懂就问，从评论区留言开始底部评论区留言，分享你的训练营学习心得 或提出学习中遇到的问题 截至 8 月 5 日 12:00 ...

随着云计算倒退，云原生热度攀升，Serverless 架构锋芒毕露且发展势头迅猛。不仅被更多开发者所关注，市场占有率也逐年进步。阿里云函数计算（Function Compute）是一个事件驱动的全托管 Serverless 计算服务，应用它您将无需再关怀底层云资源、服务器等基础设施，咱们为您筹备好计算资源，以弹性、牢靠的形式运行代码，助您轻松应答峰谷流量。 为了帮忙更多用户主观理解并应用阿里云函数计算 FC，阿里云开发者社区携手云原生利用平台 Serverless 团队公布 “Serverless 函数计算征集令”，您只需公布函数计算相干评测文章，即有机会取得千元好礼 + 千元函数计算资源包！ 流动工夫：2022年6月28日-7月31日 您将取得：好文奖品 邀请 Serverless 业余导师团队，依据文章品质评出： 参加奖品 撰写函数计算评测文章，依据公布程序评出： （注：奖品将于流动完结后两周内发放，用户可在页面自行支付对应身份的奖品福利。充值卡等虚构奖品会通过短信发放） 参加形式：申领免费资源额度-->场景体验-->发表原创文章-->提交文章-->审核通过-->参加评比/支付福利 流动主页 (注:流动面向所有阿里云注册并实名认证的用户，如不在流动页提交文章,将无奈参加支付奖品) 投稿方向：对函数计算 FC 产品能力的体验和倡议；应用函数计算 FC 创立利用的场景测评，如：基于 Serverless 架构的弹性高可用视频解决零碎、基于函数计算 FC 搭建云上博客等；咱们心愿看到一些最佳实际内容和对函数计算的实在应用感触，尽量图文并茂，文章字数需为 600 字以上。流动领导：为了帮忙各位笔出风范，咱们还提供专家技术领导，扫码退出云原生 Serverless 评测答疑群，第一工夫 Get 产品流动资讯，更有 Serverless 四大导师天团坐镇评测局，群内零距离在线互动答疑，助你下笔如有神，问鼎笔林“一代宗师”！ 点击此处，立即公布你的第一篇测评文章吧！

作者： Kafka&Tablestore 本文章次要介绍音讯队列应用过程中所遇到的音讯失落、反复生产等痛点问题的排查方法，以及音讯队列 Kafka「检索组件」的场景实际，并对其关键技术进行解读。旨在帮忙大家对音讯队列 Kafka「检索组件」的特点和应用形式更加相熟，以更无效地解决音讯排查过程中所遇到的问题。 场景痛点介绍在音讯队列的应用过程中，因为其分布式个性难免会遇到音讯失落、音讯重传等问题。 例如在日志聚合场景中，通常是多个异构数据源生产数据到 Kafka 中以提供给上游的 Spark 等计算引擎生产。而当某些日志缺失时，因为音讯数据的发送形式、数据结构等品种繁冗，导致难以间接从客户端的日志来排查。再例如音讯转发的过程中，生产端可能会反复生产到同样的数据，这就须要依据内容从音讯队列中检索数据以判断音讯是否反复生产，而音讯队列通常只能依照分区和生产位点遍历扫描，并不能灵便的实现音讯检索。 业内现有的音讯队列产品都没有较好的工具和形式来实现对音讯内容的检索，这将使得排查难度和投入老本大大增加。 Kafka 音讯检索组件检索组件介绍音讯队列 Kafka 「检索组件」是一个全托管、高弹性、交互式的检索组件，具备万亿级音讯内容检索的秒级响应能力，旨在解决业内音讯产品不反对检索音讯内容的难题。音讯队列 Kafka 「检索组件」是通过 Kafka Connector 将 Topic 中的音讯数据转存到表格存储（Tablestore）中，基于表格存储的多元索引性能提供音讯检索能力。可能反对通过音讯的分区、位点、发送的工夫范畴等一个或多个条件组合检索，还反对依据音讯 Key、Value 全文检索音讯。 案例实际案例背景假如某运维团队须要监控线上集群的运行状况，采集过程级别的日志导入到 Kafka 中，上游应用 Flink 生产，实时计算各过程资源耗费状况。当在 Flink 中发现某个过程的某个时间段的日志数据失落时，须要应用音讯队列 Kafka 「检索组件」，基于音讯 Value 和工夫范畴检索音讯数据，判断日志是否曾经胜利推送到了音讯队列 Kafka 中。 例如采集的日志数据为 JSON 构造，某一条日志数据格式为： key = 276value = {"PID":"276","COMMAND":"Google Chrom","CPU_USE":"7.2","TIME":"00:01:44","MEM":"8836K","STATE":"sleeping","UID":"0","IP":"164.29.0.1"}开明音讯检索首先须要登录到阿里云音讯队列 Kafka 控制台中，抉择对应的 topic，开明音讯检索服务。 音讯检索服务开明后，将主动创立一个 Tablestore 实例，之后将音讯数据转存到 Tablestore，并创立索引提供音讯检索能力。每一个 topic 对应了 Tablestore 中的一张数据表。能够在音讯队列 Kafka 管制台上查看每个 topic 的音讯检索组件详情。  音讯检索实际音讯检索服务开明后，就能够应用音讯中的多个搜寻项检索音讯，实现上述案例。例如指定一个工夫范畴，并且检索音讯 Value 中蕴含 PID = 276 的音讯。  返回后果示例  ...

作者：竹达 赵宇 背景CPaaS（cainiao platform as a service）是以私有云为基座，联合先进的云原生理建设的企业级 DevOps 的 PaaS 平台，CPaaS 次要目前次要反对的场景：菜鸟生态的云上研发运维、菜鸟私有云 SaaS 化的能力透出、菜鸟商业化输入撑持，部署到客户的私有云、专有云环境。 在服务了菜鸟多家生态公司及局部商业化输入的产品过程中，深刻客户业务场景，解决业务研发及部署痛点的过程中，积攒了一些贵重的教训。这里咱们次要对标准云上研发流程，晋升研发效率为指标建设的环境治理（云上我的项目环境）及缩小线上版本公布风而险建设的灰度平台的实现过程进行开展介绍。 指标1、通过我的项目环境，为多分支并行开发场景提供流量隔离及疾速联调的能力。 2、生产环境实现服务灰度公布（金丝雀公布），升高变更危险。 3、微服务利用具备优雅高低线能力，防止启停过程中带来的服务调用出错问题。 调研阶段微服务流量管控咱们首先调研了开源自建的计划。在调研时咱们发现，开发和保护开源 SDK 计划的老本十分大。须要对 Spring Cloud 和 Dubbo 这些微服务框架以及 RockeMQ 这类消息中间件十分理解，能力精确地找到各个框架的加强点进行定制化开发。 除此之外，业务方应用的微服务框架版本也是跨度很大，保护这些不同版本的微服务框架适配，也须要投入大量的精力。 最重要的一点是，应用开源 SDK 自建的计划，开发业务的共事，须要在利用的开发和部署运维的流程都感知到 SDK 的存在，对开发、构建、运维的侵入性很大，很难进行推广。 起初咱们也找到了阿里团体负责中间件的共事寻求反对，理解到中间件团队曾经推出了一款面向私有云的微服务治理产品 MSE，于是咱们进行了调研。 MSE 作为私有云的微服务治理产品，具备云上的服务管控、微服务测试、标签路由、离群摘除、优雅高低线等能力，与咱们的诉求齐全吻合，并且通过 agent 形式实现，对利用代码无侵入，更适宜 PaaS 平台对业务利用减少扩大。 图 1.1 通过与 MSE 团队同时的几次电话和会议沟通之后，逐步对 MSE 产品有了一些性能上的认知。其中在微服务治理中，咱们结合实际的业务需要，落地实现了上面 MSE 的局部能力。 图 1.2 落地场景我的项目环境在多分支开发的场景下，咱们通常须要同时部署多个分支。然而多个分支同时部署之后，如何将开发自测流量与日常环境的测试流量离开，以及如何让各个分支领有本人独立的流量，都是须要解决的问题。 流量隔离调研和验证 MSE 的标签路由的能力之后，实现思路：通过标签路由能力，将流量进行隔离。 雷同利用的不同分支，应用不同的 deployment 实现对版本和容器标签的治理。图 2.1 中 core 利用我的项目环境 c1 和我的项目环境 c2 均应用独立于日常环境的容器独自部署，各自的路由标签为 joint1 和 joint2。通过对流量携带流量标记的形式，实现我的项目环境流量的管制。 ...

大赛介绍2022 第三届云原生编程挑战赛，是由阿里云、Intel 主办，云原生利用平台、天池联结承办的云原生顶级品牌赛事。 自 2015 年开始，大赛曾经胜利举办了七届，并从 2020 年开始降级为首届云原生编程挑战赛，共吸引了超过 36000 支队伍，笼罩 10 余个国家和地区。 本届大赛将持续深度摸索服务网格、边缘容器、Serverless 三大热门技术畛域，为酷爱技术的年轻人提供一个挑战世界级技术问题的舞台，心愿用技术为全社会发明更大价值。大家赶快报名参赛吧！ 丰富处分等你来报名！瓜分¥510,000 元现金大奖三大热门赛道任意抉择邀请小伙伴报名兑换精美礼品实现 Serverless 场景体验领阿里云背包以下赛道可任选 1 个或全副扫码报名：赛道 1（服务网格） 赛道 2（边缘容器） 赛道 3（Serverless） 更多内容尽在大赛官网，欢送扫码理解~ 赛题背景在云的时代，IDE 越来越向着轻量化，分布式的方向演进， VSCode，IntelliJ Idea 等出名产品都推出了 Web IDE 版本。在小程序，Low code/No code，在线编程教育，前端一体化开发，大数据处理等畛域，Web IDE 都体现了越来越重要的价值。比方: 能不能应用 IDE 的智能代码提醒来剖析 github 上的我的项目代码，而不是 clone 整个我的项目？试试将 Github 上的我的项目 url 中的 github.com 换成 github.dev，就能够在浏览器中应用 vscode web ide 浏览和批改代码，是不是很不便？参加我的项目开发，能不能不用花工夫装置工具和依赖库，间接开始编码？试试在 github 我的项目 url 前加上 https://gitpod.io/# ，就能够为该我的项目创立一个曾经配置好的 Web IDE 环境，立刻开始开发，是不是很酷？在小程序，低代码等场景下，有没有一个高集成，一站式的开发环境，让开发、调试、查看成果的闭环最短？云原生利用，不可避免会依赖各种云服务。在本地开发机调试集成测试太艰难。如果能在配置好的远端环境中应用各种云产品或者调用上下游服务，是不是很不便？在苹果基于 ARM 架构芯片的笔记本电脑下开发 X86 利用，穿插编译配置简单，以模仿的形式运行 X86 利用性能低、耗电快，能不能在一个远端的 X86 IDE 环境中开发和调试程序？……题目解析Web IDE 实质上是一个 SaaS 服务，即便有了 Vscode 这样优良的轻量 IDE 软件，要打造一个牢靠，好用的 Web IDE 服务依然面临诸多技术挑战： ...

从“上云”到“云上”原生，云原生提供了最优用云门路，云原生的技术价值已被宽泛认可。以后行业用户全面转型云原生已是大势所趋，用户侧云原生平台建设和利用云原生化革新过程正在减速。 云原生简单的技术栈和传统IT的历史包袱给用户带来了微小挑战，针对平台建设和利用革新的能力要求短少对立标准成为企业转型的最大阻碍。在用户侧，企业执行层面存在“三难”问题，即诊断难、布局难、选型难，需要和供应不能精准对应，短少权威建设指南；在技术供应侧，技术迭代减速，产品能力构建短少行业“灯塔”，技术押宝的危险掣肘倒退。 正因如此，想要推动云原生技术的规模化利用，云原生产业仍需买通供需最初“一公里”。在此背景下，中国信通院联结业界20余家单位的近40名专家、历时1年，实现了国内首个云原生能力成熟度模型规范体系的编撰，并实现首批评估工作。 在2022 云原生产业大会中，凭借在云原生畛域的技术积攒与充沛的客户服务教训，阿里云拿下多项业余能力最高级认证，包含云原生技术架构成熟度-国内惟一全域最高级，云原生平安成熟度-国内惟一全域最高级 。** 7 月 18 日（周一）14:00 ， 阿里云技术专家将做客直播间，为企业和开发者深度解读云原生技术架构成熟度模型，并介绍云原生架构平安程度，点击下方卡片，立刻预约直播～ 直播主题一：云原生技术架构成熟度模型解读主题介绍： 云原生技术架构成熟度评估模型面向基于云原生技术建设的平台架构，从资源管理域、运维保障域、研发测试域、应用服务域四个维度充沛考查技术架构的云原生程度，帮忙企业精确定位云原生化革新阶段，差异化剖析云原生能力建设短板，明确输入企业将来能力改良方向。阿里云成为国内首个通过信通院云原生技术架构成熟度测评认证的企业，并取得国内惟一全域最高级。本次直播将具体解读云原生技术架构成熟度模型，并拆解各项指标，帮忙企业更好判断云原生实际门路，实现高质量数字化降级。 嘉宾： 胡伟琪，阿里云中间件技术负责人 直播主题二：云原生平安成熟度模型解读主题介绍： 云原生能力成熟度模型以晋升企业研发效力、促成业务翻新倒退为指标，从技术架构（T）、业务利用（A）、架构平安（S）三个方面助推企业云原生能力建设。本次直播将从基础设施平安、云原生基础架构平安、云原生利用平安、云原生研发经营平安和云原生平安运维5个维度，介绍云原生架构平安程度，帮忙企业疾速对照、定位平安能力程度，诊断本身问题，依据业务需要联合模型高阶能力定制平安架构演进方向。 嘉宾： 匡大虎，阿里云高级技术专家 点击此处，立即返回云栖号直播间，锁定直播！

2016 年，阿里巴巴发表将开源分布式消息中间件 RocketMQ 捐献给 Apache，并一举成为 Apache 顶级我的项目(TLP)。这个由中国开发者发动的我的项目站在了世界舞台上，并受到寰球的企业和开发者关注。此前《十万亿条音讯背地的故事》记录片为咱们讲述了从诞生、开源到倒退至今，那些 RocketMQ 背地鲜为人知的开创故事。 作为国内重要的开源我的项目，为了帮忙更多企业、开发者、开源贡献者理解 Apache RocketMQ 并退出其中，促成 Apache RocketMQ 及其开源生态凋敝倒退。由 RocketMQ 中文社区主办，阿里云云原生利用平台、天池社区承办的 RocketMQ Summit 2022 寰球开发者峰会正式拉开帷幕！ 7 月 21 日-22 日，作为面向开源及音讯畛域的盛会，RocketMQ Summit 如约而至，并以线上直播模式让更多开发者参加其中。在主论坛之外，本次 RocketMQ Summit 分设「行业摸索实际」、「开源生态倒退」、「核心技术解析」三大分论坛，从行业实际、生态倒退、技术解读三大维度全面展示 Apache RocketMQ 的倒退全貌。 RocketMQ Summit 2022 邀请了多位来自不同行业、不同公司的顶级技术专家负责出品委员会，并由阿里云智能云原生利用平台负责人丁宇、阿里云智能音讯平台负责人林清山、开源社副理事长刘天栋(Ted)、微众银行技术专家陈广胜、快手技术专家黄理、字节跳动音讯产品负责人高昌利、中国移动技术专家胡宗棠、小米技术专家勇幸独特组成出品委员会，独特进行大会议题的内容评比，确保为各位参与者出现最空虚、最具价值的议题分享。 深度实战解析，分享干货满满一、「核心技术解析」Apache RocketMQ 泛滥 PMC、contributor、Commiter 全景展示 Apache RocketMQ 的我的项目、社区的最新动静及我的项目思考。 二、「行业摸索实际」小米、快手、同程艺龙、vivo、光大银行、挪动云、中通快递、闪送等不同行业头部企业带来全景分享。深刻解说企业落地 RocketMQ 过程中的技术挑战与难题，分享场景摸索教训。 三、「开源生态倒退」Apahce Hudi、Apache Flink、Spring Cloud alibaba、Dapr、Knative、Apache APISIX 等行业出名开源我的项目，多维度解说泛滥我的项目如何与 Apache RocketMQ 开展联动，开释「1+1>2」的场景价值。咱们将联结国内外优良开源我的项目、开发者社区独特推广，让更多开发者与技术爱好者理解、应用 RocketMQ 及上下游我的项目，推动 RocketMQ 及其生态在国内落地倒退。 ...

你是否在苦恼如何踏出本人开源奉献的第一步？ 你是否想要零距离接触技术大神，与之切磋论道？ 无论你对开源社区的诉求是啥？ 来这里，就对了！这里有你有我， All For One，One For All。 参加流动实现工作即可取得定制礼品，还有机会博得实习机会！ 开源是关上将来技术世界的钥匙，为了真正实现「人人都能够参加开源」，龙蜥社区推出开发者激励流动！本次流动无差别面向宽广开发者，不论你是第一次接触开源社区的萌新小白，还是驰骋各大开源社区的高手常客，龙蜥社区提供了数千个入门型、进阶型工作，并筹备了上千份实物激励，邀你一起玩转龙蜥，成为开源贡献者。 龙蜥社区上线开发者激励流动有以下 4 局部： 1.字字珠玑（零代码奉献）：文档捉虫/文档翻译/写文档。2.随机试炼（盲盒专场）：通过 ABS 编译软件包/体验 T-One 品质平台。3.龙蜥一刻（龙蜥实验室专场）：体验龙蜥 OS、应用 KeenTune 调优性能、从 CentOS 迁徙到 Anolis OS、验证第三方利用兼容性。4.一码当先（代码工作）：实现并提交 PR。 以下用“云原生专场”为例介绍下本次流动，其余流动的操作相似： 本次流动设立的难易水平有：根底型、进阶型、挑战型三个阶段。实现相干工作即可取得奉献值，累计奉献值在集体核心查看。 根底型1）【参加基于龙蜥 OS 与 docker 环境联合】 工作形容：在虚拟化环境下，应用装置龙蜥 OS，并装置与运行 docker 技术要求：须要会装置操作系统与理解根本容器环境 验收规范：龙蜥 OS 运行 docker+busybox 的后果 链接地址：https://openanolis.cn/communi... 2）【参加提出以后云原生最佳实际的意见】（SIG 交换群见文末） 工作形容：浏览云原生 SIG 中最佳实际文章，提出改良意见，并被驳回 技术要求：提出改良意见，并被驳回 验收规范：意见被驳回 链接地址：https://openanolis.cn/sig/clo... 进阶型【参加基于龙蜥 OS 与 containerd 环境联合】 工作形容：在虚拟化环境下，应用装置龙蜥 OS，并装置 containerd，并通过 containerd 来启动与运行 runc 容器 技术要求：须要会装置操作系统与理解 containerd 根本用法(nerdctl 用法等) ...

流动报名须知参会收费，点击文末浏览原文，实现问卷，即为报名胜利 咱们将在流动前两天发送阿里巴巴西溪园区 B 区的访客凭证，凭借短信参会签到 收到访客凭证，可在园区内收费停车 现场筹备了程序员礼品三大件，机械键盘、水杯和T恤，还有一些难看的书 流动详情中间件开发者 Meetup 会集了 Appactive、ChaosBlade、Nacos、OpenSergo、Seata、Sentinel、Serverless Devs、Spring Cloud Alibaba 等阿里云利用中间件畛域开源我的项目的最新进展和开源实际。阿里巴巴西溪园区 B 区，访客核心 415A，7 月 30 日（周六）13:30 开始报名地址：点击此处。

在云原生倒退大趋势下，Kubernetes  在将来相当长时间内都会十分风行。对于 IT 从业者来说，把握容器技术既是满足市场和企业对人才的须要，也是晋升自我价值的重要途径。往年 6 月，咱们推出了「5 分钟玩转阿里云容器服务」系列课程，通过简略易懂的短视频授课模式，系统化总结了阿里云容器服务应用办法和技巧，帮助大家晋升应用容器产品的效率，升高应用难度。 思考到大家在应用容器服务产品时，除了常见的问题之外，也会遇到在特定场景下对于组件配置、计划选型、相干产品搭配等诸多困惑，因而咱们在每次 5 分钟短视频课程根底上，推出进阶版线上训练营，通过自学+跟学的形式，帮忙企业开发者疾速把握企业级容器利用施行技能。 「玩转容器服务提高班」第1期正式开营！参营播种《5 分钟玩转容器服务》全套课程随心学专家直播课进阶攻克容器产品应用难点学习+体验+交换，关上容器高效学习工具箱社区定制结业证书，给你致力该有的典礼感开营工夫和学习形式▶开营工夫：2022 年 7 月 25 日（周一）正式开营 ▶上课形式：自学（自学课 8 节）+跟学（直播课2节），疾速把握企业级容器利用施行技能 ▶直播上课工夫：2022 年 8 月 2 日-8 月 3 日，每晚 18：00-19：00 ▶开营名额：仅限 500 人  ▶报名地址：点击此处即可疾速报名！ 自学+跟学，高效把握企业级容器施行技能自学课程： 7 月 20 日起｜5 分钟玩转容器服务 ACK 系列课程 课程链接：https://developer.aliyun.com/... 进阶直播 1：8 月 2 日 18:00-19:00 |  如何在 ACK 中应用 MSE Ingress 李艳林(彦林)，Nacos 创始人，MSE 创始人，阿里中间件上云负责人，阿里云高级技术专家 讲师介绍：十年微服务研发教训，参加阿里异地多活架构演进，全链路压测，百万实例架构演进，全面上云，开源和阿里云等要害战斗。 课程简介：本次课程次要分享 Ingress 发展趋势，探讨 Ingress/Gateway API 规范趋势，分享 Nginx/Envoy Ingress 技术趋势，论述 阿里云 MSE Ingress 的劣势和实际，帮忙业务从入口规范的建设高可用和平安防线。 进阶直播 2：8 月 3 日 18:00-19:00 | 在 ACK 中如何应用容器优化的操作系统  ...

引言Apache RocketMQ 诞生至今，历经十余年大规模业务稳定性打磨，服务了 100% 阿里团体外部业务以及阿里云数以万计的企业客户。作为金融级牢靠的业务音讯计划，RocketMQ 从创立之初就始终专一于业务集成畛域的异步通信能力构建。本篇将从业务集成场景的诉求开始，介绍 RocketMQ 作为业务音讯集成计划的外围能力和劣势，通过性能场景、利用案例以及最佳实际等角度介绍 RocketMQ 一般音讯类型的应用。 关注【阿里云云原生】公众号，回复关键词【一般音讯】获取残缺 PPT 下载地址！ 说起业务集成场景，RocketMQ 最后的应用场景就是典型代表。RocketMQ 诞生于阿里的电商零碎，电商零碎常常须要做各种大促流动，在这类简单需要场景下对音讯零碎的吞吐性能、端到端提早、削峰填谷等能力有着极高的要求。 一句话概括明天的外围问题，跑在外围交易业务链路的音讯有什么特点，有什么要求，和跑在离线剖析等场景的音讯有什么不同。上面和大家一起来探讨～ 业务集成 vs 数据集成 集成指标不同做业务外围架构设计时，很多时候须要面向下层需要去实现业务逻辑的设计。以电商交易场景为例，通过微服务的拆分，可能在整个链路中会拆成很多个环节，不同利用之间通过音讯去集成时，更多的是关注用户订单的流转过程，关注这个业务逻辑是否会失常的解决，这个就是业务集成。 比照一下，数据集成是以数据为核心，更多的是关注业务集成产生的数据，去剖析这些业务数据的价值。数据集成并不关怀这个数据是从哪里来，只关怀数据自身的属性和数据之间的关系。 关注重点不同在业务集成里随着企业业务逻辑的拓宽和复杂度的晋升，调用和被调用方之间的耦合性会逐渐减少，链路的拓扑也会变得越来越简单。常常会呈现一条音讯的上游是另一条音讯的上游，一个服务可能既是发送方也是生产方，等等。 而在数据集成的场景外面，并不关注上述链路，更多是关注数据的多样性。也就是说，在做数据集成剖析时，更多的是从各种异构的数据源里去提取、汇聚这些数据，而后把这些异构零碎的数据聚合在一起做荡涤，最终汇聚成结构化的数据或报表去做剖析。数据集成更多是关注数据的异构性和多样性。 实时性不同业务集成简略了解就是一种在线的逻辑，或者是一种强实时的逻辑。在这个业务集成畛域，无论同步调用还是异步调用，都对调用和被调用之间的响应协同机制有肯定的要求。举个例子，一个订单的解决必须是要在毫秒级实现，否则用户的体验会十分的差。 然而在数据集成畛域，更多的可能是近实时甚至是离线非实时的场景，也就是说通过批、实时流或近实时流的 场景去爬取数据之后做剖析，具体链路对于用户来说并不是可见的，这也是数据集成和业务集成侧重点的差别。 业务集成对音讯零碎的外围诉求音讯队列是企业业务集成的次要模式之一，它是一种异步通信模式。异步模式提供了低耦合、高牢靠、可观测的异步通信能力。那么业务集成链路里应用音讯之后会带来什么成果呢？这里略微列举一下。 上图就是一个比拟典型的下层的利用链路，从利用 A 到上层的利用 B 的一个单链路，通过发送初始化或者结构化一个音讯，作为调用事件发送到事件通道，这个通道就是音讯零碎，比方 RocketMQ、RabbitMQ 等。在工夫通道里存储后通过过滤路由的散发组件匹配到上游，而后推送解决。与此同时，还会有可观测、运维、监控的一些体系去撑持这个链路的牢靠运行。 残缺的性能需要十分多，这里提炼业务集成对音讯零碎的四个外围诉求： 1）多类型音讯传输：反对多样业务场景集成诉求，次要包含一般音讯、定时音讯、事务音讯、程序音讯等； 2）丰盛路由散发能力：反对多种散发路由条件，包含 Tag 过滤、音讯属性过滤，一对多、一对一散发等； 3）多样交互模式：反对收发音讯多样交互方式，反对同步、异步发送，反对被动生产、被动推送生产，反对流式应答、单条应答； 4）可观测体系：反对 Metrics、Trace、Events 剖析，反对单链路、全链路轨迹追踪，反对 Metrics 剖析和监控告警，支持系统运行事件、业务事件透出解决。 RocketMQ 作为十分典型的业务音讯计划，正是对应上述业务集成的诉求，提供了欠缺的音讯性能、丰盛的客户端接口以及欠缺的可观测体系和稳定性保障机制。 接下来就开始逐渐拆解 RocketMQ 的多类型音讯，本篇次要介绍一般音讯。 一般音讯原理介绍性能简介在多种音讯类型中，一般音讯是最简略也最为重要。一般音讯是 RocketMQ 的根本音讯类型，提供高吞吐、扩大、低提早、异步的通信能力。其余高级音讯类型根本都是在这种一般音讯类型的根底上叠加了独有的管制个性，或者是特定的应用的形式。 上面这张图就是一般音讯的一个典型的拓扑，和音讯队列典型场景一样，生产者发送音讯，发送一般音讯到服务端去存储，存储完之后，会把音讯依照订阅关系的匹配，最初推送给上游的生产方去做生产。 一般音讯的特点1）原子性：音讯之间没有关联关系，收发解决逻辑原子； 2）扩展性：一般音讯容量、能力可扩大，反对多队列存储、程度拆分、并发生产； 3）低提早：一般音讯链路短，交互简略，状态简略，链路极简，毫秒级低提早通信。 音讯的生命周期一般音讯从初始化发送开始到最终被解决的过程中会经验多个状态和过程，而理解音讯的生命周期，能够帮忙咱们去判断线上呈现问题后如何疾速定位和解决。 简略来说音讯的生命周期能够形象成五个状态： 初始化：一般音讯被生产者构建初始化实现，待发送到服务端的状态；待生产：音讯被传输到服务端，对上游可见，期待消费者获取解决的状态；生产中：音讯被消费者获取，并依照业务逻辑处理过程，此时服务端会期待生产实现，如果肯定工夫后没有收到生产提交的事件，音讯还会重试解决；生产提交：消费者实现音讯解决，并提交应答事件到服务端，服务端标记以后音讯曾经被解决（包含生产胜利和失败）。RocketMQ默认反对所有音讯保留，此时音讯数据并不会立刻被删除，只是逻辑标记实现，在音讯被物理删除之前，消费者依然能够回溯重新处理音讯；音讯删除：RocketMQ 依照音讯保留工夫机制滚动清理最早的音讯数据，将音讯从物理文件中删除。一般音讯利用场景和案例简略的理解原理和根本介绍之后，那一般音讯次要用在哪里呢？一般音讯是RocketMQ利用最宽泛，应用规模最大的一种音讯类型，它次要集中在服务间的解耦调用，同时还有一些批量数据的采集传输等场景。 应用场景1）微服务调用解耦 异步化解耦：一般音讯实现微服务异步调用，缩短业务流和响应工夫。流量削峰填谷：一般音讯海量沉积能力，解决流量峰值上游解决能力有余的稳定性危险。  2）实时数据传输 ...

作者：朱晋君 大家好，我是君哥。 明天来聊一聊阿里巴巴 Seata 新版本（1.5.1）是怎么解决 TCC 模式下的幂等、悬挂和空回滚问题的。 TCC 回顾TCC 模式是最经典的分布式事务解决方案，它将分布式事务分为两个阶段来执行，try 阶段对每个分支事务进行预留资源，如果所有分支事务都预留资源胜利，则进入 commit 阶段提交全局事务，如果有一个节点预留资源失败则进入 cancel 阶段回滚全局事务。 以传统的订单、库存、账户服务为例，在 try 阶段尝试预留资源，插入订单、扣减库存、扣减金额，这三个服务都是要提交本地事务的，这里能够把资源转入两头表。在 commit 阶段，再把 try 阶段预留的资源转入最终表。而在 cancel 阶段，把 try 阶段预留的资源进行开释，比方把账户金额返回给客户的账户。 留神：try 阶段必须是要提交本地事务的，比方扣减订单金额，必须把钱从客户账户扣掉，如果不扣掉，在 commit 阶段客户账户钱不够了，就会出问题。 try-committry 阶段首先进行预留资源，而后在 commit 阶段扣除资源。如下图： try-canceltry 阶段首先进行预留资源，预留资源时扣减库存失败导致全局事务回滚，在 cancel 阶段开释资源。如下图： TCC 劣势TCC 模式最大的劣势是效率高。TCC 模式在 try 阶段的锁定资源并不是真正意义上的锁定，而是实在提交了本地事务，将资源预留到两头态，并不需要阻塞期待，因而效率比其余模式要高。 同时 TCC 模式还能够进行如下优化： 异步提交try 阶段胜利后，不立刻进入 confirm/cancel 阶段，而是认为全局事务曾经完结了，启动定时工作来异步执行 confirm/cancel，扣减或开释资源，这样会有很大的性能晋升。 同库模式TCC 模式中有三个角色： TM：治理全局事务，包含开启全局事务，提交/回滚全局事务；RM：治理分支事务；TC: 治理全局事务和分支事务的状态。下图来自 Seata 官网： TM 开启全局事务时，RM 须要向 TC 发送注册音讯，TC 保留分支事务的状态。TM 申请提交或回滚时，TC 须要向 RM 发送提交或回滚音讯。这样蕴含两个个分支事务的分布式事务中，TC 和 RM 之间有四次 RPC。 ...

Helm Charts [ 1] 如今已是一种十分风行的软件打包形式，在其利用市场中你能够找到靠近一万款实用于云原生环境的软件。而后在现在的混合云多集群环境中，业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下，单纯依赖 Helm 工具可能无奈做到灵便的部署和交付。 在本文中，咱们将介绍如何通过 KubeVela [ 2] 解决多集群环境下 Helm Chart 的部署问题。如果你手里没有多集群也不要紧，咱们将介绍一种仅依赖于 Docker 或者 Linux 零碎的轻量级部署形式，能够让你轻松的体验多集群性能。当然，KubeVela 也齐全具备单集群的 Helm Chart 交付 [ 3] 能力。 前提条件装置 Docker v20.10.5+ (runc >= v1.0.0-rc93) 或者你的操作系统是 Linux。VelaD [ 4] ，一个轻量级的部署 KubeVela 和 Kubernetes 的工具。 筹备集群本节是做 KubeVela 以及多集群环境的筹备，咱们将基于 Docker 或者 Linux 环境从头开始。如果你曾经具备了 KubeVela 的环境并且实现了集群治理 [ 5] ，则能够跳过本节。 装置 KubeVela 管制立体velad install将新创建的集群导入到环境变量export KUBECONFIG=$(velad kubeconfig --name default --host)到这里，祝贺你！咱们曾经实现了 KubeVela 管制立体的装置。你能够通过上面这个形式退出你的 Kubernetes 集群： vela cluster join <path-to-kubeconfig-of-cluster> --name foo如果你没有现成的 Kubernetes 集群，VelaD 也能够很不便的为你创立一个： ...

作者：十眠 什么是全链路灰度？微服务体系架构中，服务之间的依赖关系盘根错节，有时某个性能发版依赖多个服务同时降级上线。咱们心愿能够对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。 在公布过程中，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图： 上图能够很好展现这种计划的成果，咱们用不同的色彩来示意不同版本的灰度流量，能够看出无论是微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境，这种计划不仅能够节俭大量的机器老本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。 那么全链路灰度具体是如何实现呢？通过下面的探讨，咱们须要解决以下问题： 1.链路上各个组件和服务可能依据申请流量特色进行动静路由 2.须要对服务下的所有节点进行分组，可能辨别版本 3.须要对流量进行灰度标识、版本标识 4.须要辨认出不同版本的灰度流量 上面将借着介绍 OpenSergo 对于流量路由所定义的 v1alpha1 规范，来通知大家实现全链路灰度所需的技术细节。 Q：OpenSergo 是什么？ A：OpenSergo 是一套凋谢、通用的、面向分布式服务架构、笼罩全链路异构化生态的服务治理规范，基于业界服务治理场景与实际造成服务治理通用规范。OpenSergo 的最大特点就是以对立的一套配置/DSL/协定定义服务治理规定，面向多语言异构化架构，做到全链路生态笼罩。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是规范微服务或 Mesh 接入，从网关到微服务，从数据库到缓存，从服务注册发现到配置，开发者都能够通过同一套 OpenSergo CRD 标准配置针对每一层进行对立的治理管控，而无需关注各框架、语言的差别点，升高异构化、全链路服务治理管控的复杂度 Q：为什么理解全链路灰度之前先给我介绍 OpenSergo？ A：OpenSergo 定义了一套对立的 YAML 配置形式来针对分布式架构进行全链路的服务治理的标准，介绍标准与规范的同时，咱们能够理解其中的技术细节的实现，同时咱们还能够将新的组件与 OpenSergo 的规范进行实现。OpenSergo 流量路由 v1alpha1 规范流量路由，顾名思义就是将具备某些属性特色的流量，路由到指定的指标。流量路由是流量治理中重要的一环，开发者能够基于流量路由规范来实现各种场景，如灰度公布、金丝雀公布、容灾路由、标签路由等。 全链路灰度示例： 流量路由规定(v1alpha1) 次要分为三局部： Workload 标签规定 (WorkloadLabelRule)：将某一组 workload 打上对应的标签，这一块能够了解为是为 APISIX 的各个上游打上对应的标签流量标签规定 (TrafficLabelRule)：将具备某些属性特色的流量，打上对应的标签依照 Workload 标签和流量标签来做匹配路由，将带有指定标签的流量路由到匹配的 workload 中咱们能够赋予标签不同的语义，从而实现各个场景下的路由能力。 给流量打标：须要将具备某些属性特色的流量，打上对应的标签。 假如当初须要将内部测试用户灰度到新版主页，测试用户 uid=12345，UID 位于 X-User-Id header 中： apiVersion: traffic.opensergo.io/v1alpha1kind: TrafficLabelRulemetadata: name: my-traffic-label-rule labels: app: my-appspec: selector: app: my-app trafficLabel: gray match: - condition: "==" # 匹配表达式 type: header # 匹配属性类型 key: 'X-User-Id' # 参数名 value: 12345 # 参数值 - condition: "==" value: "/index" type: path通过上述配置，咱们能够将 path 为 /index，且 uid header 为 12345 的 HTTP 流量，打上 gray 标，代表这个流量为灰度流量。 ...