阿里云云原生小助手_社区达人页_阿里云开发者社区
阿里云云原生小助手_社区达人页
阿里云云原生小助手
已加入开发者社区1263天
勋章
更多
技术博主
技术博主
开发者认证勋章
开发者认证勋章
一代宗师
一代宗师
成就
已发布1984篇文章
330条评论
已回答0个问题
0条评论
已发布19个视频
github地址
试试看看
我关注的人
更多
凌云Cloud
凌云Cloud
小周sir
小周sir
lovelydong
lovelydong
阿里云微服务引擎MSE
阿里云微服务引擎MSE
云栖号资讯小哥
云栖号资讯小哥
jessie筱姜
jessie筱姜
技术小能手
技术小能手
amber涂南
amber涂南
开源小秘书
开源小秘书
粉丝
更多
游客wregarpmhb7xy
游客wregarpmhb7xy
aay4c22vhutpu
aay4c22vhutpu
游客di2kk23mndndo
游客di2kk23mndndo
愈合。。
愈合。。
游客wsq76x2ee2blu
游客wsq76x2ee2blu
游客6fqmynq3my264
游客6fqmynq3my264
游客qpn4t7ak22ade
游客qpn4t7ak22ade
避風港
避風港
乱王码
乱王码
娜娜爱
娜娜爱
dxsw
dxsw
希沃
希沃
技术能力
兴趣领域
Java
Python
前端开发
Linux
数据库
擅长领域
技术认证
暂时未有相关云产品技术能力~
搬运工
精选
高分内容
最新动态
文章
问答
视频
暂无精选文章
发表了文章
2022-11-25
又一创新！阿里云 Serverless 调度论文被云计算顶会 ACM SoCC 收录
作者：木吴关注阿里云云原生公众号，后台回复关键词【FC】查看论文原文！近日，阿里云函数计算产品团队撰写的关于 Serverless 调度的创新性论文被 ACM SoCC 国际会议长文录用。去年阿里云函数计算团队首个提出在 FaaS 场景下的去中心化快速镜像分发技术，团队所作论文被计算机系统领域的顶级会议 USENIX ATC’21 录用，入选中国计算机协会（CCF）推荐 A 类国际会议列表（👉详情点击阅读）；今年阿里云函数计算不断突破：发布基于函数画像的调度算法论文并被国际云计算的首要会议 ACM SoCC 录用，真正做到能够保证提升函数资源利用率的同时，达到性能高稳定性。ACM Symposium on Cloud Computing（以下简称 SoCC）是由美国计算机协会主办、聚焦云计算技术的一项学术会议，是云计算的首要会议。它汇集了对云计算感兴趣的研究人员、开发人员、用户和实践者，是唯一由 SIGMOD（数据管理特别兴趣组）和 SIGOPS（操作系统特别兴趣组）联合主办的会议, 这个会议在近些年蓬勃发展，旨在聚集数据库和计算机系统两大领域的学者，共同推进云计算技术在工业界的研究与发展。此次被录用的论文为《Owl: Performance-Aware Scheduling for Resource-Efficient Function-as-a-Service Cloud》。论文灵感诞生于阿里云 Serverless 产品函数计算，函数计算是阿里云的函数即服务(Function-As-A-Service)产品。阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，并提供日志查询、性能监控、报警等功能。现阶段已经覆盖了事件驱动、音视频处理、游戏、物联网、新零售、AI 等实际业务场景，并服务于阿里云、高德、支付宝、淘宝、CBU 等多个业务或项目中。上图是一个经典的 FaaS 调度系统的架构，调度器负载将不同的函数实例调度到集群中的节点上运行。由于 FaaS 产品函数数量多、函数粒度小、执行时间短的特点，节点的资源利用率较低。简单地将更多的实例调度到同一个节点上虽然能够一定程度地提升资源利用率，但是也带来了资源争抢和性能下降。论文针对这个问题创新地提出了基于函数画像的调度算法，在提高资源利用率的同时达到了较好的性能稳定性：1. 对于高频调用的函数，调度器会识别不同函数实例在同一个节点共置时的性能表现，以此指导函数实例的调度；2. 对于低频调用的函数，调度器会统计其执行过程中的实际资源消耗，以此来指导函数实例的调度，同时调度器会监控函数的执行延时，当出现延时上升时通过隔离的手段进行缓解；3. 调度器还针对闲置的实例进行迁移，将它们从利用率低的节点迁移到利用率高的节点以释放闲置节点。为了评估算法的效果，论文根据生产环境典型的函数负载，抽象了 10 个函数，它们覆盖了不同的编程语言、资源消耗、执行时长、外部依赖。列表如下：实验结果表明，在 100 个节点规模下，OWL 调度算法能够节省 43.8% 的资源，同时函数执行延时没有明显的增加：调度延时也没有明显增加：目前 OWL 的函数画像能力也已经应用在函数计算线上环境，并取得了不错的效果。此次论文入选 ACM SoCC，是阿里云在 Serverless 调度领域的又一次创新。附论文信息All On Serverless《Owl: Performance-Aware Scheduling for Resource-Efficient Function-as-a-Service Cloud》作者：田黄石，李苏毅，王骜，王威，吴天龙，杨皓然论文概述：在云计算中，FaaS 是一种非常流行的产品形态，主流的云产商都提供了对应的平台。作为平台构建者我们观察到大部分的函数实例的 CPU 和内存利用率都不高，造成集群节点的利用率也不高。一个简单的做法是在节点上超额放置更多的函数实例，但是这可能会带来资源争抢和性能下降。另外，函数的外部依赖也可能导致函数的性能下降。在本文中，我们设计了 OWL 调度系统来解决这些问题，达到高资源利用率和性能稳定性。对于低频调用的函数，调度器会统计其执行过程中的实际资源消耗，以此来指导函数实例的调度，同时调度器会监控函数的执行延时，当出现延时上升时通过隔离的手段进行缓解；对于高频调用的函数，调度器会识别不同函数实例在同一个节点共置时的性能表现，以此指导函数实例的调度。同时调度器还针对闲置的实例进行迁移，将它们从利用率低的节点迁移到利用率高的节点以释放闲置节点。我们实现了 OWL 原型系统并根据生产环境的负载构造了一组测试集。实验结果表明，OWL 调度系统能够减少 43.8% 的资源消耗并有效缓解性能下降。点击此处，直达阿里云函数计算 FC！
发表了文章
2022-11-22
盘点 | 云原生峰会重磅发布
11 月 5 日，2022 杭州·云栖大会上，阿里巴巴研究员、阿里云智能云原生应用平台总经理丁宇在云原生峰会上发表主题演讲，提出云原生激活应用构建新范式。在分享中发布阿里云在云原生领域多款新产品与全新升级，持续引领行业云原生技术趋势。云原生已经变成非常流行的技术趋势，从上云到用云，云原生能够从PaaS层面帮助企业解决应用构建的一系列问题。具体有三大范式正在成为现实：第一个范式是全面容器化。因为容器形成了运维的标准，成为企业上云用云的新界面，也变成开发者和应用系统交互的新界面，有利于构建高弹性、可伸缩的系统，从而实现降本增效。通过容器，企业可以享受到运维标准化、弹性架构带来的好处，也带来了软件可以无处不在的部署交付，标准化的管理运维。第二个范式是整个行业应用的核心技术互联网化。我们正在用互联网的技术、互联网的架构思想来重构应用系统，从而带来了很多好处：分布式可扩展，支撑业务敏捷迭代，构建弹性架构，从容应对流量高峰。第三个范式是应用的Serverless化。从技术角度来看，能够实现技术组件分层解耦，让应用可以做到全托管免运维，提升系统的可运维性，降低成本。通过极致弹性，能够把所有的组件覆盖，在云上构建应用变得非常简单。容器服务全面进入智能化时代虽然容器服务 ACK 大幅降低了 K8s 的门槛，但管理和运维一个大规模、分布式的集群依然充满挑战，比方说，如何调度应用，在保障稳定的同时，提升资源利用率；如何对应用进行成本规划、分析优化；当集群出现问题后，如何及时的定位和修复。智能化可以解决这些问题，智能化是容器平台发展的必然趋势，阿里云容器服务全面进入智能化时代。其中有三个升级：第一个升级，智能化的混部调度，新一代调度系统Koordinator，帮助用户提升整体资源利用率。第二个升级，智能化的成本治理，容器服务 FinOps套件，帮助用户实现上云成本可见、可控、可优化。第三个升级，智能化的运维体验，容器服务 AIOps套件，帮助用户实现数据驱动诊断决策，助力故障防御定位，自动化诊断可以覆盖 90% 以上的问题。这些能力升级，会进一步降低容器技术的使用门槛，让 ACK 做到普惠化，服务更广泛的客户群体。核心技术互联网化重磅发布一 | 微服务再升级：新增云原生网关开源云原生时代，微服务面临着新的诉求和技术挑战，尤其是在性能、高可用性和安全性方面。今天，阿里云正式开源云原生网关 Higress，它是业内首个标准化、高集成、易扩展、热更新的云原生网关。标准化：随着K8s的普及，K8s Ingress 逐渐成为云原生时代API事实标准，Higress全面支持该标准，并且在服务治理方面（包括灰度、限流、预热、超时、重试）做大幅增强，引领标准演进方向。高集成：Higress首次将流量网关、微服务网关、安全网关三合一，打造高集成网关，在入口建立高性能、安全防线，后端支持 K8s / Nacos / ECS / Serverless 多种运行时路由，打造功能最强大网关实现。易扩展：Higress 提供最丰富插件扩展机制，满足客户灵活路由和安全定制需求，支持最全面语言扩展机制；当然为了降低客户使用门槛，默认集成了数十个插件，并且通过插件市场方便开发者贡献通用能力，产生良性互动。热更新：由于传统Nginx更新规则需要 reload 会导致链接抖动，导致流量损失，对实时通信、视频、IoT无法容忍，因此 Higress 从证书、路由、安全规则、插件全部采用热更新机制，毫秒级生效且业务无感知。除了开源云原生网关之外，阿里云全面升级微服务引擎 MSE3.0，包含三大核心能力：第一大能力是注册配置中心，相比 Nacos 等主流开源方案，性能提升40%，提供70+的监控指标，提供健康检测，帮助客户实现服务异常自治。第二大能力是微服务治理，沉淀了阿里巴巴10+的实践经验，帮助客户缩短30%微服务治理落地周期，提升50%开发测试效率，消除80%线上风险。第三大能力是云原生网关，阿里云将流量网关、微服务网关、安全网关三合一，架构上也做了升级，将实例级防护升级至路由级防护，整体性能相比传统网关提升90%。重磅发布二 | 可观测再升级：让可观测数据价值最大化云原生时代，系统架构日趋复杂，提升可观测能力成为降低复杂度的唯一手段。今天可观测能力成为度量企业IT水平的标准，成本治理、业务连续性、业务增长都需要可观测技术。因此阿里云推出云原生可观测套件ACOS，从应用监控到链路追踪，帮助企业实现成本管理、风险治理、智能运维、保障数字化业务高效稳定的运行。本次云栖大会，阿里云云原生可观测套件 ACOS 三大组件也迎来重要升级。首先， Prometheus已成为不少企业的观测首选。作为容器观测事实标准的Prometheus监控，已成为阿里云50多款云产品的默认观测基础设施，并与应用实时监控服务ARMS的APM指标、eBPF指标、OpenTelemetry指标联通，将观测范围从专精容器延伸到全栈可观测。其次，作为观测界面的阿里云Grafana服务也将迎来9.0焕新升级。全新的Prometheus 和 Loki 查询语句生成器及强化后的搜索 Explore 功能，让用户获得更强的数据查询与分析能力。同时，为了应对越来越丰富的异构可观测数据源，Grafana服务与日志服务SLS、Elasticsearch等20+款可观测存储服务集成，帮助企业更简单地构建统一观测界面。一键导入/导出自建实例、自动数据导出报表，一键数据备份、恢复，用户操作审计等企业特性得到进一步增强。最后，为了帮助企业的云上应用开启多维度观测视角。应用实时监控服务ARMS在数据采集方面，OpenTelemetry 与Prometheus生态全面融合，通过 OpenTelemetry 补充业务、自定义组件埋点，在完善观测维度的同时，实现厂商无锁定。并借助 TraceExplorer 实现多来源 Trace 统一查询。重磅发布三 | RocketMQ5.0全面升级：从消息服务到云原生事件流平台消息队列一直是企业互联网架构的核心组件，阿里巴巴早在2012年就基于电商场景打造了国内流行的消息中间件RocketMQ，并贡献到Apache 社区。历经十余年的打磨，RocketMQ 取得了众多成果。Apache RocketMQ 的社区非常活跃，全球拥有700+的贡献者，超过 75% 头部企业选择使用 RocketMQ，同时超过80%的主流云厂商提供了 RocketMQ 的商业托管服务；阿里云作为 RocketMQ 的发起方和核心贡献者，十多年以来，累计服务了来自互联网、零售、汽车等20多个行业、10万企业客户；承载千万级TPS，万亿级消息洪峰。应用 Serverless 化：引领下一代应用架构随着企业用云的深入，云的能力也在不断升级，过去企业用云就是去买资源、买实例、买规格、搭应用。我们一直在说“云计算是像水电煤一样的基础设施，但是现在这一点还没有完全实现。阿里云一直在推动产品形态、研发方式的升级，希望从提供资源到提供服务，这个服务就是即插即用的能力，企业不需要管理和维护，可以实现自动伸缩免运维，平台全托管，按用量计费，真正实现了服务化、模块化，这也是云产品升级演进的方向。可以说，Serverless 奇点已来，所谓奇点，就是由平稳发展转向高速发展的转折点，预示着行业落地开始爆发。目前，阿里云已经有20多款的Serverless产品，并且会推进核心产品全面 Serverless化，Serverless 是云提供能力的最佳实现方式，也是让云计算基础设施落地到千行百业的最佳范式。除了产品形态的改变之外， Serverless同样带来了软件研发范式的改变。随着阿里云提供越来越全面的Serverless产品以后，很多云产品都变成模块化、API化、服务化，它可以进行组装，通过拖拉拽的方式就能够构建应用。所以说在 Serverless 架构下，研发方式升级到组装式研发，组装式研发可以做到流程编排、事件驱动，甚至可以做成可视化，这就彻底颠覆了原有的软件研发方式，大幅提升研发效率，灵活应对业务挑战。根据权威机构调研统计，组装式研发相比传统模式，可为研发提效50%以上。南瓜电影 7 天内全面 Serverless 化实践云原生 PaaS：CNStack2.0 重磅发布CNStack 是一款以应用为中心的云原生技术中台。它在异构的混合云基础设施上，提供统一的算力管理和优化调度，以开放、云原生的方式为不同场景下的应用提供全技术栈支持，指数级提升用户业务创新能力，加速研发效率，同时降低资源开销和运维成本，保障业务连续性，成为企业数字化转型的最佳路径。自 2021 年 CNStack1.0 发布以来，已经在多个行业的多个客户数字化转型过程中提供了帮助，并在 2022年云原生产业大会获得云原生技术创新案例大奖。今天，云原生Stack 2.0重磅发布，整个平台更加内聚，体验大幅提升，成为企业数字化转型，构建数字化应用的最佳载体。有三大能力升级：第一，统一算力支持。支持不同厂商、不同架构，CPU/GPU算力混合管理，支持管理容器虚拟机多种负载的混合调度。第二，一站式应用管理。应用的开发、测试、运维全生命周期一站式管理，容器服务、分布式应用、云边、DevOps全场景覆盖。第三，丰富易用的能力中心。丰富的云组件，为业务创新提供完整的技术栈支持。能力中心组件经过规模化验证，运维及稳定性有保障。云原生 Stack 让企业的数字化转型 不受技术约束，专注自身业务，加速实现业务目标。未来，阿里云在云原生领域将持续的引领标准，不断突破，推动领域和产业快速发展。
发表了文章
2022-11-18
深度学习 | 如何开发、部署 Serverless 应用？
作者：阿里云云原生本文将详细介绍如何开发和部署 Serverless 应用，并通过阿里云函数计算控制台与开发者工具 Serverless Devs 进行应用的初始化、部署；最后分享应用的调试，通过科学发布、可观测性等介绍应用的部署和运维总结，进而实现从应用初始化到调试、发布、运维基础流程、核心步骤的探索。如何开发、部署 Serverless 应用通过控制台进行函数创建下面我们将基于 Serverless 架构，在 FaaS 平台上实现 Hello world 的输出，基本步骤可分为：1）注册账号，并登录；2）找到对应的 FaaS 产品：阿里云的函数计算；3）单击“创建函数”按钮，进行函数的创建；4）配置函数，包括函数名称、运行时（可以认为是要使用的编程语言，或者要使用的编程环境等）；5）完成创建，并测试。以阿里云函数计算为例，当注册并登录阿里云账号之后，需要找到函数计算产品，并单击进入产品首页，如图所示。阿里云函数计算产品首页选择左侧的“服务及函数”，并进行服务的创建，如图所示。阿里云函数计算创建服务页面然后进行函数的创建，如图所示。阿里云函数计算创建函数页面相对于其他的云平台，在阿里云函数计算平台，我们不仅要为即将创建的函数设置函数名称、选择运行时等，还需要设置该函数所在的服务。在阿里云函数计算的体系中，引入服务的概念会带来一定的好处。相关联的函数可以放在一个服务下进行分类，这种分类实际上比标签分类更直观明了。 相关联的函数在同一个服务下共享一定的配置，例如 VPC 配置、NAS 配置，甚至某些日志仓库的配置等。 通过服务，我们可以很好地做函数环境的划分，例如对于一个相册项目，该项目可能存在线上环境、测试环境、开发环境，那么可以在服务层面做区分，即可以设定 album-release、album-test、album-dev 三个服务，进而做环境的隔离。  通过服务，我们可以很好地收纳函数。如果项目比较大，可能会产生很多函数，统一放在同一层级会显得非常混乱，这时就可以通过服务进行有效的收纳。 完成函数的创建之后，我们可以进行代码的编辑。阿里云函数计算支持从对象存储上传代码，支持直接上传代码包，以及在线编辑。除此之外，阿里云函数计算还支持直接上传文件夹，如图所示。保存代码之后，可以单击“执行”按钮进行函数的触发、测试。可以看到，系统已经输出相关日志：Hello world。至此，一个非常简单的函数就创建成功了。通过工具进行函数创建与部署通过 Serverless 开发者工具入门 Serverless 应用开发、部署、运维是非常方便的，我们以 Serverless Devs 为例介绍阿里云函数计算应用的部署，并对工具侧的函数创建、部署以及其他相关功能进行探索。Serverless Devs 是一个开源的 Serverless 开发者平台，致力于为开发者提供强大的工具链。通过该平台，开发者可以一键体验多云 Serverless 产品，极速部署 Serverless 项目。按照官方目前的描述，Serverless Devs 已经支持包括 AWS Lanbda、阿里云函数计算、百度智能云函数计算、腾讯云云函数、华为云函数工作流等在内的多个云厂商的 Serverless 相关产品。下面通过 Serverless Devs 开发者工具，以阿里云函数计算为例进行实践，探索如何创建、部署 Serverless 应用。1）安装 Serverless Devs 开发者工具（执行npm install -g @Serverless-devs/s命令）。2）设置阿里云凭证信息（执行s config add --AccessKeyID AccessKeyID --AccessKeySecret AccessKeySecret --AccountID AccountID命令）。3）建立模板项目（执行s init node.js12-http -d fc-hello-world-demo命令），初始化过程如图所示。通过 Serverless Devs 创建项目图4）进入项目目录（执行 cd fc-hello-world-demo 命令），并部署（执行 s deploy 命令），部署后的结果如图所示。通过 Serverless Devs 部署项目项目部署成功之后，可以进行更多操作，具体如下。触发函数（执行s invoke命令），结果如图所示。通过 Serverless Devs 触发函数查看线上函数详情（执行s info命令），结果如图所示。通过 Serverless Devs 查看函数详情Serverless Devs 还拥有比较完善的桌面客户端。开发者可以通过桌面客户端进行应用的创建、管理以及相关配套功能的使用，示例如下。查看应用列表，并快速创建应用，如图所示。通过 Serverless Devs 桌面客户端查看应用列表创建应用之后，可以进行应用的管理。下图是 Serverless Devs 桌面客户端管理应用界面。通过 Serverless Devs 桌面客户端管理应用其他配套功能的使用如下。如图所示为一键压测函数性能。通过 Serverless Devs 桌面客户端一键压测函数性能一键对函数资源进行调试，如图所示。通过Serverless Devs桌面客户端一键对函数资源进行调试一键查看函数多维度指标信息，如图所示。通过 Serverless Devs 桌面客户端一键查看函数多维度指标信息除此之外，Serverless Devs 还拥有较为方便的 Yaml 可视化配置功能，如下图所示。通过Serverless Devs桌面客户端进行Yaml可视化配置如何对 Serverless 应用进行调试在应用开发过程中，或者应用开发完成后，当执行结果不符合预期时，通常要进行一定的调试。但是在 Serverless 架构下，调试往往会受到极大的考验，尤其在受环境因素限制时，通常会出现这样的情况：所开发的应用在本地可以健康、符合预期地运行，但是在 FaaS 平台上则有一些不可预测的问题；或者在一些特殊环境下，本地没有办法模拟线上环境，难以进行应用的调试。Serverless 应用的调试一直备受诟病，但是各个云厂商并没有因此放弃在调试方向上的深入探索，下面我们介绍几种方式。在线调试简单调试 所谓的简单调试，就是在控制台进行调试。以阿里云函数计算为例，可以在控制台通过“代码执行”按钮进行基本的调试，如下图所示。函数计算代码编辑页面必要的时候也可以通过设置 Event 来模拟一些事件。阿里云函数计算事件页面在线调试的好处是可以使用一些线上环境进行代码的测试。当线上环境拥有 VPC 等资源时，在本地环境是很难进行调试的。断点调试 除了简单的在线调试之外，部分云厂商还支持断点调试，例如阿里云函数计算的远程调试。我们以阿里云函数计算远程调试为例，可以实现通过控制台进行函数的在线调试。当创建好函数之后，可以选择远程调试，并单击“开启调试”按钮，如图所示。函数计算远程调试页面开启调试之后，稍等片刻，系统将会进入远程调试界面，如图所示。函数计算远程调试开始页面当出现图当出现下图所示界面，我们可以进行断点调试。函数计算远程调试断点调试页面端云联调在本地进行 Serverless 应用开发时，往往会涉及一些线上资源，例如通过对象存储触发器触发函数执行，通过 VPC 访问数据库等，此时线上和线下环境不一致会让线下开发、调试面临极大的挑战。Serverless Devs 开发者工具通过搭建 Proxy 辅助函数的方法将线上和线下资源打通，可以快速帮助开发者在本地进行应用的开发与调试，这种调试方式称为端云联调。如下图所示， Serverless Devs 开发者工具会根据 Yaml 配置文件，创建辅助服务和辅助函数，并通过辅助服务和辅助函数实现线上和线下资源打通，以及完整的端云联调。Serverless Devs 端云联调原理示意图Serverless Devs 开发者工具会根据 Yaml 配置文件的内容，创建辅助服务和辅助函数（辅助服务和 Yaml 中所声明的业务服务配置是一致的）。通过触发器（包括通过 SDK、API、s proxied invoke 命令，或者其他触发器）触发辅助函数（函数计算 C），请求流量回到本地调试实例（本地环境 A），这时本地调试实例（本地函数执行环境容器）收到的 event 和 context 是真实来自线上的。本地调试实例（本地环境 A）可以直接访问以下内容：VPC 内网资源，比如 RDS、Kafka 内网地址等；一些云服务的内网地址；硬盘挂载服务（直接访问 NAS）。 端云联调流程如下：1）执行s proxied setup命令准备端云联调所需的辅助资源以及本地环境；2）对于无触发器的普通事件函数或者 HTTP 触发器，准备工作完成后，启动另一个新的终端，切换到该项目路径下，执行s proxied invoke命令调用本地函数；3）完成调试任务后，执行s proxied cleanup命令清理端云联调所需的辅助资源以及本地环境。除了通过命令使用端云联调功能外，我们也可以在 VSCode 开发者工具中使用端云联调功能，如图所示。在 VSCode 中使用端云联调功能远程调试端云联调在本地除了有一个通道服务容器外，还有一个函数计算容器，用来执行本地函数；远程辅助函数只是单纯将远程流量发送到本地。在实际调试过程中，需要登录到实例进行项目调试，此时可以选择使用远程调试。相比于端云联调，远程调试在本地只有一个通道服务容器，执行过程全部依赖线上；远程函数将执行结果返回。远程调试整体架构简图如图所示。除了通过上面远程调试架构简图所示的通道服务登录线上环境进行代码调试或问题定位之外，部分云厂商还提供了直接登录实例进行代码调试的功能。以 Serverless Devs 为例，当使用阿里云函数计算时，我们就可以直接通过 instance 命令进行线上实例登录。尽管实例登录命令已经提供了便捷的登录体验，能帮助用户解决复杂场景下的应用异常定位等问题，但是登录实例后，用户无法直接通过函数日志、监控指标来具体定位问题，还需要借助例如 coredump、tcpdump、jmap 等工具进行问题的深入排查。例如，某用户发现自己的线上程序最近出现一些函数错误提示，报错内容都是连接远程某服务时超时。该用户怀疑是函数实例与远端服务的网络连接不稳定，因此想进入实例内部，分析实例与远端服务的网络情况。此时，我们可以按照以下步骤进行问题的排查。1）如图所示，登录实例内部后，需要执行 apt-get update 和 apt-get install tcpdump 两条命令，进行 tcpdump 工具的安装。实例登录与安装软件效果图2）安装完毕后，执行 tcpdump 命令，对远端服务 IP 的请求进行抓包，并将抓包结果保存在 tcpdump.cap 文件中。3）抓包完毕后，借助 OSS 命令行工具 ossutil64，将 tcpdump.cap 文件上传到自己的 OSS，然后下载到本地借助分析工具 Wireshark 进行分析。本地调试命令行工具 大部分 FaaS 平台会为用户提供相对完备的命令行工具，如阿里云的 Funcraft，同时也有一些开源项目如 Serverless Framework、Serverless Devs 等支持多云厂商的 FaaS 平台。通过命令行工具进行代码调试的方法很简单。以 Serverless Devs 为例，本地调试阿里云函数计算方法为：首先确保本地拥有一个函数计算的项目，然后在项目下执行调试指令，例如在 Docker 中进行调试，如下面所示。通过命令行进行本地调试编辑器插件 以 VSCode 插件为例，下载好阿里云函数计算的 VSCode 插件，并且配置好账号信息之后，在本地新建函数，并且在打点之后进行断点调试，如图所示。编辑器插件中进行调试其他调试方案Web 框架的本地调试 以 Python 语言 Bottle 框架为例，若在阿里云 FaaS 平台开发传统 Web 框架，可以增加如下代码：app = bottle.default_app()并且对run()方法进行条件限制（if __name__ == '__main__'）：if __name__ == '__main__':
bottle.run(host='localhost', port=8080, debug=True)例如：# index.py
import bottle
@bottle.route('/hello/<name>')
def index(name):
return "Hello world"
app = bottle.default_app()
if __name__ == '__main__':
bottle.run(host='localhost', port=8080, debug=True)和传统开发思路一样，我们可以在本地开发并在本地进行调试。当部署到线上时，只需要在入口方法处设置 index.app，即可实现平滑的部署。本地模拟事件调试 针对非 Web 框架，可以在本地构建一个方法，例如要调试对象存储触发器，代码如下：import jsondef handler(event, context): print(event)def test(): event = { "events": [ { "eventName": "ObjectCreated:PutObject", "eventSource": "acs:oss", "eventTime": "2017-04-21T12:46:37.000Z", "eventVersion": "1.0", "oss": { "bucket": { "arn": "acs:oss:cn-shanghai:123456789:bucketname", "name": "testbucket",
"ownerIdentity": "123456789", "virtualBucket": "" }, "object": { "deltaSize": 122539, "eTag": "688A7BF4F233DC9C88A80BF985AB7329", "key": "image/a.jpg", "size": 122539 }, "ossSchemaVersion": "1.0", "ruleId": "9adac8e253828f4f7c0466d941fa3db81161****" }, "region": "cn-shanghai", "requestParameters": { "sourceIPAddress": "140.205.***.***" }, "responseElements": { "requestId": "58F9FF2D3DF792092E12044C" }, "userIdentity": { "principalId": "123456789" } } ] } handler(json.dumps(event), None)if __name__ == "__main__": print(test())这样通过构造一个 event 对象，即可实现模拟事件触发。通过开发者工具进行依赖安装和项目构建Serverless 架构下的应用开发和传统架构下的应用开发有一个比较大的区别是二者所关注的内容维度是不同的，例如理想状态下的前者并不需要人们关注服务器等底层资源。但是在当今的 Serverless 发展阶段，Serverless 架构下的应用开发真的不需要人们对服务器等额外关注吗？其实不是的，虽然 Serverless 架构强调的是 Noserver 心智，但是在实际生产中，有很多依赖等是无法跨平台使用的，例如 Python 语言中的某些依赖需要进行二进制编译，和操作系统、软件环境等有比较大的关系，所以项目中如果引入这类依赖，需要在和函数计算平台线上环境一致的环境中进行依赖的安装、代码的打包或项目的部署。阿里云函数计算对自身的线上函数环境有比较细致的描述，提供了相应的文档，例如使用 C、C++ 、Go 编译的可执行文件，需要与函数计算的运行环境兼容。函数计算的 Python 运行环境如下。Linux 内核版本：Linux 4.4.24-2.al7.x86_64。Docker 基础镜像：docker pull python:2.7 ; docker pull python:3.6。 但是，在实际应用开发过程中，依赖的打包依旧是让一众开发者头疼的事情。他们在很多 Serverless 应用开发过程中都会面临类似的挑战：项目在本地可以正常运行，一发布到线上就找不到某个依赖，但是实际上依赖是存在的，此时问题定位就成了非常困难的事情。目前来看，为 Serverless 应用安装依赖或者项目构建的方法通常有 3 种：1）在本地创建项目之后，自行根据云厂商提供的环境数据进行线上环境搭建，进而进行依赖的安装。这种方法相对来说自主可控，但是难度非常大，操作较为繁琐。2）用已有的开发者工具进行依赖的安装，如图所示：通过工具安装依赖示意图以 Serverless Devs 开发者工具以及阿里云函数计算产品为例，开发者只需要按照语言习惯准备对应语言的相关依赖安装文件即可，例如 Python 语言的requirements.txt，Node.js语言的package.json等。然后在当前项目下，执行s build --use-docker命令即可完成与阿里云函数计算平台线上环境一致的环境中的依赖的安装。以 Python 项目为例，开发者只需要在项目目录下完成如下操作。开发源代码；执行s build –use-docker命令之后，自动根据requirements.txt文件下载对应的依赖到本地，并且和源码一起组成交付物；执行s deploy命令将整个交付物打包，创建函数，同时设置好依赖包的环境变量，让函数可以直接输入对应的代码依赖包。3）目前，部分云厂商的 FaaS 平台控制台支持 WebIDE，阿里云的 WebIDE 拥有实现命令行程序的能力，所以也可以在控制台的 WebIDE 中直接进行依赖的安装。在线安装依赖示意图如图所示。在线安装依赖示意图新书推荐阿里云、蚂蚁集团的 4 位专家刘宇、田初东、卢萌凯、王仁达（排名不分先后）系统梳理阿里在 Serverless 架构下的 AI 经验，联袂推出新书《Serverless 架构下的 AI 应用开发：入门、实战与性能优化》。本书是关于 Serverless 架构下机器学习实战的技术书，我们希望通过简单明了的语言、真实的案例，以及开放的源代码，为读者介绍 Serverless 架构与机器学习相关的基础知识，帮助读者在 Serverless 架构下开发、上线机器学习项目。作者介绍：刘宇，阿里云 Serverless 产品经理田初东，蚂蚁集团算法工程师卢萌凯，阿里云 Serverless 高级解决方案架构师王仁达，阿里云 Serverless 工具链技术负责人
发表了文章
2022-11-18
让 Serverless 更普惠，阿里云函数计算 FC 宣布全面降价，最大幅度达 37.5%
背景11 月 5 日，2022 杭州 · 云栖大会上，阿里云宣布函数计算 FC 开启全面降价，vCPU 单价降幅 11%，其他的各个独立计费项最高降幅达 37.5%。本次云栖大会上，阿里云智能总裁张建锋表示，以云为核心的新型计算体系正在形成，软件研发范式正在发生新的变革，Serverless 是其中最重要的趋势之一，阿里云将坚定推进核心产品全面 Serverless 化，帮助客户更好地实现敏捷创新。函数计算 FC 全面降价，让 Serverless 更加普惠。用户可随用随取，按量计费，用更低成本采用 Serverless 架构，尽享 Serverless 带来的研发效率提升和技术红利。关注阿里云云原生公众号，后台回复关键词【手册】查看 Serverless 产品手册！阿里云函数计算 FC 全面降价，让 Serverless 更普惠计费粒度更精细，按需付费就是省函数计算 FC 计费粒度精细，按执行环境的内存和执行时间计费，计费规格最低可达到 1 毫秒粒度的计费时长，0.05 核 vCPU、128MB内存、1/16 GPU 卡用户可以只为请求产生的资源消耗买单，极致控制成本。函数计算 FC 上线新版资源包，函数规格 vCPU、内存、磁盘等各个计费项的绑定彻底解绑，让用户可以按需自由选配，贴合自己的应用运行时开销选取规格，进一步降低资源闲置比例。预留模式作为函数计算 FC 消除冷启动的利器，新增了闲置计费仅 1/10 价格更加让业务能免除高成本的后顾之忧。据团队测算，一个集群的资源如果日均利用率在 30% 以下，或者有明显的闲置浪费，就适合使用函数计算 FC。采用函数计算 FC 之后资源利用率能够提高到 60% 甚至 90% 以上，综合成本降低 15% 到 70%。当您的业务 CPU 利用率低于 50%，或 GPU 利用率低于 30%，迁移上函数计算 FC 可以实现降本。以中小企业为例假定（中小型企业某 API 服务 QPS~8个）每月 2000 万次访问，每次访问平均 50 毫秒，每次访问平均占用 vCPU 0.25核/内存 256MB，当你将业务托管到函数计算时，可以将成本精确到每次访问 0.00000175 元，精确地衡量单位成本是函数计算 FC 节省成本利器。接下来对三种方案进行对比：1. 传统虚拟化方案按照传统的虚拟化方案，2C4G 的云主机需要 2828.4 元/年，单机可支持 8 个并发访问，但在业务高峰期（>8 个并发）时需要排队处理访问请求，有可能导致业务性能受损，而在低峰期又闲置造成资源浪费。2. 自建容器化方案自建容器化方案则对技术团队有较高的运维要求，资源成本难以定量优化，且不可避免将引入更高的人力成本。按照业内经验，日均利用率能优化至 30%（8 小时弹性资源）已经是非常不错的结果，但仍需>1416.96 元/年的云主机总成本。3. 函数计算 Serverless 化方案函数计算仅需 420 元/年（2000 万次/月*0.00000175 元/次=35 元/月），在同等情况下简单计算即可量化确认 70%-85% 的降本目标，且无需引入额外的人力成本。以企业使用为例wolai 是一款面向未来的云端信息协同平台。通过使用函数计算，wolai 开发快照保存系统，解决协同编辑算法问题。前端工程师可负责从前到后一整套开发流程，9 人团队即可保证 wolai 研发高度迭代。相比传统架构，使用函数计算可节省 50% 计算费用，人力的投入能够节省一半甚至更多。视频直播是恋爱社交 APP 伊对最为重要的业务，峰谷特征明显。为了保障业务平稳，伊对需要准备大量机器去处理任务，在流量低峰期机器资源会大量空闲浪费，而某些节假日带来的高峰却会超过集群的最大承受能力，任务排队不得不对部分业务做降级处理。在使用函数计算 FC 之后，峰谷期资源问题得到彻底解决，资源成本开支减少了 20%。互联网营销推广服务商鱼传科技，业务主要基于支付宝小程序进行承载，具有访问量波动大、流量突发预测难等特点，尤其是活动期间访问突增对小程序后端服务的稳定和弹性也是一个很大的考验。为了应对无法预测的突发流量，鱼传科技进行全系统 Serverless 化，一天只用 200 元即可支撑日活超过 50 万人的小程序，能承受突发上万 QPS。函数计算 FC 全地域&全计费项价格下调2022 年 11 月 3 日起，函数计算 FC 全地域&全计费项价格下调，最高降价幅度达 37.5%！按量付费和资源包全规格降价，日均资源利用率为 30% 时降本幅度仍可达 12% ～ 47%，实际资源利用率越低可降本空间越大。1. 按量付费全面降价：活跃 vCPU 使用量单价降价 11%，vCPU 闲置时可自动被系统回收，单价仅为活跃时的 1/10，内存使用量单价降价 20%，GPU 使用量单价降价 20%，函数调用次数单价降价 25%，公网出流量单价降价 37.5%。2. 全新的资源包购买方案：新版函数计算资源包支持各计费项自由组合购买，购买相同资源的情况下，新版函数计算资源包价格仅为按量付费价格的 29%~80%。3. 新用户免费试用：首次开通函数计算时可 0 元享免费试用额度，有效期 1 年，总价值 88 元。免费试用额度限购 1 次，内含三个试用包：50 万 vCPU*秒 + 100 万 GB*秒 + 100 万次函数调用。4. 老用户免费试用：函数计算将于 2022年12月31日24时 起取消每月 40万 GB*秒 + 100万次调用免费额度。为答谢老用户(2022年11月2日11:25分 之前开通函数计算的用户）对函数计算产品的关爱，所有老用户仍可在 2022年12月31日24 时前享有免费额度，同时也可 0 元享老用户试用套餐，有效期 1 年，总价值 88 元。免费试用额度限购 1 次，内含三个试用包：50万 vCPU*秒 + 100万 GB*秒 + 100万次函数调用。注意：购买试用套餐以后，会优先抵扣试用包的资源，我们建议您在 2023年1月1日 购买试用套餐。开始使用函数计算 FC阿里云是国内最早提供 Serverless 计算服务的云厂商。2017 年推出的函数计算 FC 是一款 FaaS 产品，这是一种以事件驱动为核心的全托管计算服务，用户只需编写代码并上传，函数计算就会自动准备好计算资源，以弹性、可靠的方式运行代码，并提供完整的可观测能力，大幅简化开发运维过程。函数计算 FC 自发布至今已经帮助上万家国内外企业在 Web、移动后端、音视频、AI 推理、批任务处理等广泛场景落地现代化应用。阿里云函数计算 FC 日调用次数超过 300 亿次，有效支撑历年双 11 百万 QPS 洪峰，业务增速超过 300%，整体规模位居国内首位。在 Forrester 发布的 2021 年第一季度 FaaS 平台评估报告中，阿里云凭借函数计算产品能力全面领先的优势，成为全球前三的 FaaS 领导者，这也是首次有国内科技公司进入 FaaS 领导者象限。今年，函数计算 FC 深入打透音视频处理、实时数据处理、GPU 三大场景，帮助开发者专注业务、降本提效。1. 音视频处理能力再突破，函数计算 FC 新增全景录制模版。通过全景录制这种所见即所得的模式，可轻松还原直播互动效果，让用户开箱即用，既能得到 SaaS 化音视频快速接入体验，又能拥有代码级的定制灵活性，可以瞬间创建多个实例进行视频多路并行转码，极大缩短了出片时间。同时，函数计算 FC 资源利用率高，算力消耗低，相比传统方案成本可降低 70% 以上。2. 让消息流动起来，函数计算 FC 实时数据处理能力再增强。函数计算 FC 与阿里云全系消息产品如 RocketMQ、Kafka、EventBridge 进行官方集成，内置上百个触发源，在消息产品控制台就可以实现“一键”对消息进行数据清洗、富化和转储，让消息发挥更大的价值。函数计算 FC 的自适应弹性可以有效应对海量消息的波峰波谷，达到亿级每分钟的事件吞吐。3. 函数计算 FC 推出 Serverless GPU，支持最小 1/16 卡的多规格 GPU 算力分割，同时提供准实时三秒冷启动，秒级弹性+秒级计费。当前 GPU 成为 AI 推理、多媒体处理的算力提供者。经过团队测算，在以上两种场景下，选择使用 GPU ，将会比选择使用传统 CPU 性能提升达到数十倍甚至百倍以上。然而，GPU 的价格一般比较高，而且使用率普遍低于 30%，这导致很多企业对 GPU 望而却步。Serverless GPU 让 GPU 算力更平价，普惠中小企业。点击此处，查看函数计算 FC 更多详情！
发表了文章
2022-11-17
消息队列 RocketMQ 5.0：从消息服务到云原生事件流平台
前言回顾 RocketMQ 的发展历程，至今已十年有余。2022 年 RocketMQ 5.0 正式发布，全面迈进云原生时代。11 月 5 日，2022 杭州 · 云栖大会上，阿里云智能高级产品专家杨秋弟在云原生峰会上发表主题演讲，发布消息队列 RocketMQ 5.0：从消息服务到云原生事件流处理平台。阿里云智能高级产品专家&Apache RocketMQ 联合创始人   杨秋弟Apache RocketMQ 发展史回顾 Apache RocketMQ 过去十年的发展历程，可分为“诞生于互联网”与“成长于云计算”两大阶段。第一个阶段是 RocketMQ 的从 0 到 1，在阿里内部规模化落地。2012 年，为了支撑超大规模电商互联网架构，阿里中间件研发了 RocketMQ，并在产品诞生初期开源，2017 年 RocketMQ 统一了阿里消息技术体系。第二个阶段是云计算。2015 年 RocketMQ 上云，这也是业界首个提供公共云 SaaS 形态的开源消息队列；2016 年，阿里把 RocketMQ 捐赠给 Apache，2017 年孵化毕业，成为国内首个 TLP 的互联网中间件。十年磨一剑，出鞘必锋芒。在这十年的过程中，通过集团打磨稳定性，依托云计算孵化创新，开源共建加速标准化建立与生态连接，RocketMQ 始终坚持开源、集团、商业三位一体的发展思路，内核演进和产品迭代齐头并进。2022 年 RocketMQ 5.0 正式发布宣告着全面迈进云原生时代。RocketMQ 5.0：从消息服务到云原生事件流平台回顾过去这十年，RocketMQ 服务于集团几乎所有的业务，在阿里云上更是累计服务了 10 万余家企业客户，覆盖互联网、零售、金融、汽车等 20 多个行业，大规模的生产实践持续累积产品的核心优势。多样性，企业级应用复杂的业务诉求，催生 RocketMQ 提供丰富的消息类型，比如定时消息、事务消息、顺序消息等等。此外，也提供了像消息轨迹、消息回溯等一系列的消息治理能力。 一致性，无论是淘宝交易还是蚂蚁支付都天然对数据一致性有着极高的要求，RocketMQ 提供的分布式事务消息是业内第一个提供该特性的消息产品，将异步解耦与数据一致性完美融合，是金融客户中不可或缺的产品能力。 稳定性，稳定性是产品的根基，更是一个系统工程，RocketMQ 长期在电商和金融领域中打磨，不仅提供最高达 99.99% SLA，更是帮助客户提供全方位的健康巡检与故障排查能力，如消息轨迹、消息回溯、死信机制等等，提供多样化的稳定性兜底手段。 高性能，在双十一的极限流量下，RocketMQ 具备无限扩展能力，支持千万级并发与万亿级消息洪峰，P9999 写延迟在 1ms 内，100%在 100ms 内。 可以说，在消息领域，尤其在业务消息领域，RocketMQ 在国内已经做到顶尖，成为企业客户的首选。而随着云原生以及数字化时代的到来，RocketMQ 也在快速的发生着变化，那么变化主要体现在哪些方面呢？首先，全面拥抱云原生。向下，消息系统自身实现云原生架构的演进，充分释放云基础设施的池化能力，全方位提高消息的核心技术指标。向上，消息产品形态持续演进，成为云原生应用架构的核心引擎。比如微服务、事件驱动、Serverless 等现代化应用架构。其次，全面拥抱实时数据。企业的数字化转型从原来的业务数字化迈向了数字业务化。对业务数据的实时洞察、实时决策成为指导业务成功的关键要素。消息队列也将从在线业务架构的基础设施，延伸到实时数据架构的基础设施，从而实现事务分析一体化。随着 5.0 的发布，RocketMQ 也正式从消息服务升级到云原生事件流处理平台。RocketMQ 5.0：云原生架构升级首先来看 RocketMQ 自身的云原生架构演进。从下面的全景图可以看出，RocketMQ 从客户端到服务端都进行了全方位的改造，具体体现在以下几个方面：1. 轻量化。RocketMQ 4.0 诞生于 2012 年的淘宝电商，当时大部分的业务还跑在物理机上，单节点计算能力强，客户端节点数少且较为稳定，因此，富客户端的接入方式不仅更加高效，更可以提供诸如客户端侧负载均衡、消息缓存、故障转移等一系列企业级特性。但这种模式在云原生时代发生了改变，轻量客户端更容易被云原生技术栈所集成。因此，RocketMQ 5.0 客户端采用轻量 SDK 设计理念，将原来富客户端的逻辑下沉到服务端，满足现代化应用轻量化、Serverless 化以及 Mesh 化的趋势，更容易被集成；同时也正是因为轻量化，使得 SDK 多语言开发成本低了很多，快速覆盖当下主流的多语言版本。2. 弹性，存算分离架构让无状态计算节点可以快速伸缩，而分级存储以及冷热分离架构更是让消息存储具备更强的弹性能力。3. 高可用，基于全新的 Leaderless 架构，去 ZK 依赖的同时，可以做到副本数灵活选择，同步异步自动升降级，实现秒级故障转移；面向云的多可用区、多地域组建全局高可用能力。4. 最后，RocketMQ 整体架构走向 Kubernetes 化，拥抱 OpenTelemetry，依托于阿里云提供的 ARMS、Prometheus 以及 Grafana 实现可观测能力的云原生化。而 RocketMQ 5.0 本次的升级，除了在技术架构云原生化之外，在产品能力以及成本优化方面都有着重大的提升，我们来逐一分解。轻量无状态消费模型RocketMQ 4.0 采用按队列消费模型，消费者完全按照队列负载均衡，非常适合批量拉取快速消费，对单一消息状态不敏感的场景，比如流计算。然而在业务消息领域，尤其是金融场景以及事件驱动架构之下，每一条消息状态都是极为重要的。再加上不同业务类型的消息处理耗时也是各不相同，从毫秒级、到秒级甚至到分钟级，队列的负载不均衡或者短暂的 Block 都可能会引发消息的局部堆积，从而影响到最终用户的体验。因此，RocketMQ 5.0 全新推出按消息负载的轻量无状态消费模型，通过 PoP 机制巧妙地在队列模型之上构建了消息模型，业务只需要关心消息而无需关心队列，所有 API 都能够支持单条消息级别控制，如消息的消费、重试、删除等。而基于消息消费模型，客户端、连接和消费都是无状态的，可在任意 Proxy 节点上飘移，真正做到轻量化。RocketMQ 5.0 提供按队列消费模型以及按消息消费模型，更好的满足事件与流的业务场景，正可谓鱼与熊掌兼得。海量消息分级存储RocketMQ 5.0 的另一个重大升级则是海量消息的分级存储。对消息队列了解的同学都知道，消息通常都是流动的短时间的存储，业内大部分消息产品对消息的保留时间都比较优先，3 天，7 天，最长 15 天不等。有限的存储空间使不仅限制了消息的保留时长，更在某些场景下可能会导致业务资损，比如在消息还没有被消费的时候，因为磁盘空间不足或者消息过期而被清除，这在金融等领域都是不可接受的。所以，RocketMQ 一直想要解决这样的问题，让存储变得更有弹性。RocketMQ 5.0 基于 ESSD、对象存储打造冷热分离以及分级存储架构，提供低成本的无限存储能力，确保消息不会因为本地磁盘空间不足而提前被清除，造成业务资损。我们提供消息存储的 Serverless，客户只需按实际存储使用量付费，而无需预购存储空间。此外，流量削峰是消息队列极为常见的场景，而由此带来的海量消息堆积能力以及在堆积情况下的性能稳定性成为衡量产品性能的核心指标。RocketMQ 5.0 基于冷热数据分离架构进一步做到读写隔离，避免在堆积的场景下影响热数据的写入性能。分级存储的冷数据碎片规整能力更是提高了冷数据的读取性能，为用户提供一致的冷读 SLA。售卖系列全线升级，最高降本 50%从前面的介绍我们已经了解到，RocketMQ 5.0 在技术架构以及产品能力上都有着明显提升。而 5.0 推出全新的售卖形态与计费策略相比 4.0 更简单、更灵活也更为普惠。实例的综合成本最高可降低 50%。接入门槛最低可降至 390 元/月，远低于自建成本。消息存储支持 Serverless 弹性能力，按需付费可大幅降低闲置成本。结合冷热分离的多级存储能力，相比开源自建可降低 67%，大幅降低消息队列的使用成本。EventBridge：云上事件枢纽事件驱动是一个起源很早的概念，早在几十年前，无论是操作系统内核的设计、还是客户端编程框架都大量采用了事件驱动技术。RocketMQ PushConsumer 提供的 API 其实就是一种事件驱动的编程范式，但在微服务应用架构当中，集成与通信才是刚需，事件驱动的价值并没有那么明显的体现。而随着云原生时代的到来，计算力的构成越来越多样化。作为云原生的代表技术，Serverless 架构范式也是事件驱动的。无论是阿里云的函数计算、还是 AWS 的 Lambda，它们的主要触发源都是各种形态的事件，云产品事件，如 OSS 文件上传触发用户基于函数进行文件加工处理；用户业务事件，如 RocketMQ 触发函数运行消费逻辑处理等等。以事件驱动为核心理念，阿里云推出了 EventBridge 产品，其使命就是打造云上的事件枢纽。通过 EventBridge 可以兑现四大业务价值：1. 统一事件枢纽。阿里云从 IaaS、PaaS 到第三方的 SaaS，每天都有数以亿计的事件产生，但却没有一种简单和统一的方式来触达这些事件；这些事件散落在各个地方形成『事件孤岛』，很难挖掘出有用的业务价值。只有充分发挥数据的规模效应，建立起数据之间的血缘关系，我们才能更好的发掘出数据的价值；所以 EventBridge 首要任务便是统一阿里云上的事件规范，拥抱 CloudEvents 事件标准，打造阿里云统一的事件枢纽。2. 事件驱动引擎。当 EventBridge 连接了海量的事件源后，基于 RocketMQ 毫秒级的事件触发能力，必将加速企业 EDA/Serverless 的架构升级。3. 开放与集成。EventBridge 提供丰富的跨云、跨平台、跨产品、跨地域以及跨账号的连接能力，能够促进云产品、应用程序、SaaS 服务的相互集成。4. 低代码。EventBridge 借助 Serverless 的应用中心，通过简单的规则匹配以及丰富的模板，即可实现事件的分发、过滤、转换等处理，进一步提升事件驱动的效率。让消息无处不在，让事件无所不及依托于 EventBridge、RocketMQ 以及函数计算 FC 的强强联合，目前 EventBridge 的事件生态已初具规模。在云产品事件集成方面，目前已经集成 200+云产品事件源，3000 多种事件类型。在数据集成与处理方面，EventBridge 与微服务应用、大数据、IoT 等场景深度集成。比如与消息生态的融合，阿里云 6 款消息队列产品通过 EventBridge 实现消息数据的互联互通，并且通过 EventBridge 的全球事件网络赋予消息全球消息路由的能力，同时也可以通过 EventBridge 提供的丰富的模板，实现 ETL 数据处理能力。在 SaaS 应用集成方面，包括钉钉、聚石塔以及云上 50 多个 SaaS 服务都可以通过 EventBridgehook 方式连接到 EventBridge。在事件触发方面，EventBridge 目前已经触达 10 多个事件目标，海量的事件源都可以通过 EventBridge 触发包括 FC/SAE 等在内的 10 多款事件目标云产品。除此之外，目前 EventBridge 已经对接了阿里云全量的云产品 API，任何一个事件都可以通过云产品 API 的方式进行触达。未来还有会更多的事件源以及事件目标接入到 EventBridge 上来。RocketMQ Streams：轻量级计算的新选择正如开篇所提到的，基于云原生架构的全面升级，RocketMQ 5.0 也将从在线业务架构的基础设施，延伸到实时数据架构的基础设施，实现事务分析一体化。将 RocketMQ Streams 打造成为轻量级计算的新选择。业内最常见如 Flink、Spark 等大数据框架大多采用中心化的 Master-Slave 架构，依赖和部署比较重，每个任务的执行都需要很大的开销，有较高的使用成本。而与之不同的是，RocketMQ Streams 着重打造轻资源，高性能的轻量计算引擎，无额外依赖，最低 1core，1g 即可完成部署，适用于大数据量、高过滤、轻窗口计算的场景，在资源敏感型场景，如消息队列流计算、安全风控，边缘计算等，RocketMQ Streams 具有有很大优势。阿里云消息团队与安全团队合作，通过对过滤场景做大量优化，性能提升 3-5 倍，资源节省 50%-80%。目前，RocketMQ Streams 已经在开源社区发布，未来计划在 2023 年 4 月在阿里云完成商业化。RocketMQ 这十年，我们一同向前RocketMQ 历经十余年的打磨，已经取得了众多成果。全球拥有 700+的贡献者，1.8w Star 数，超过 80%的主流云厂商提供了 RocketMQ 的商业托管服务，Apache RocketMQ 社区始终保持着极高的活跃度，因此，也荣获了科创中国“开源创新榜”，中日韩开源软件优秀技术奖等十多个国内外开源奖项。而阿里云作为 RocketMQ 的起源和核心贡献者，不仅 100%覆盖全集团业务，承载千万级并发万亿级消息洪峰。十多年以来更是累计服务 10w+万企业客户，覆盖互联网、零售、汽车等 20 多个行业，超过 75%的头部企业选择使用 RocketMQ。期望阿里云的消息队列 RocketMQ 可以成为广大企业客户的心之所选。也诚邀更广大的开发者来积极参与 RocketMQ 的开源社区建设，一起将 RocketMQ 打造为消息领域的引领者。欢迎扫描下方二维码加入钉钉群与 RocketMQ 爱好者一起沟通交流～点击此处，进入官网了解更多详情～
发表了文章
2022-11-17
RocketMQ 重试机制详解及最佳实践
作者：斜阳引言本文主要介绍在使用 RocketMQ 时为什么需要重试与兜底机制，生产者与消费者触发重试的条件和具体行为，如何在 RocketMQ 中合理使用重试机制，帮助构建弹性，高可用系统的最佳实践。RocketMQ 的重试机制包括三部分，分别是生产者重试，服务端内部数据复制遇到非预期问题时重试，消费者消费重试。本文中仅讨论生产者重试和消费者消费重试两种面向用户侧的实现。生产者发送重试RocketMQ 的生产者在发送消息到服务端时，可能会因为网络问题，服务异常等原因导致调用失败，这时候应该怎么办？如何尽可能的保证消息不丢失呢？1. 生产者重试次数RocketMQ 在客户端中内置了请求重试逻辑，支持在初始化时配置消息发送最大重试次数（默认为 2 次），失败时会按照设置的重试次数重新发送。直到消息发送成功，或者达到最大重试次数时结束，并在最后一次失败后返回调用错误的响应。对于同步发送和异步发送，均支持消息发送重试。同步发送：调用线程会一直阻塞，直到某次重试成功或最终重试失败（返回错误码或抛出异常）。异步发送：调用线程不会阻塞，但调用结果会通过回调的形式，以异常事件或者成功事件返回。 2. 生产者重试间隔在介绍生产者重试前，我们先来了解下流控的概念，流控一般是指服务端压力过大，容量不足时服务端会限制客户端收发消息的行为，是服务端自我保护的一种设计。RocketMQ 会根据当前是否触发了流控而采用不同的重试策略：非流控错误场景：其他触发条件触发重试后，均会立即进行重试，无等待间隔。流控错误场景：系统会按照预设的指数退避策略进行延迟重试。为什么要引入退避和随机抖动？ 如果故障是由过载流控引起的，重试会增加服务端负载，导致情况进一步恶化，因此客户端在遇到流控时会在两次尝试之间等待一段时间。每次尝试后的等待时间都呈指数级延长。指数回退可能导致很长的回退时间，因为指数函数增长很快。指数退避算法通过以下参数控制重试行为，更多信息，请参见 connection-backoff.md。INITIAL_BACKOFF：第一次失败重试前后需等待多久，默认值：1 秒；MULTIPLIER ：指数退避因子，即退避倍率，默认值：1.6；JITTER ：随机抖动因子，默认值：0.2；MAX_BACKOFF ：等待间隔时间上限，默认值：120 秒；MIN_CONNECT_TIMEOUT ：最短重试间隔，默认值：20 秒。ConnectWithBackoff()
current_backoff = INITIAL_BACKOFF
current_deadline = now() + INITIAL_BACKOFF
while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT))!= SUCCESS)
SleepUntil(current_deadline)
current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
current_deadline = now() + current_backoff + UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)特别说明：对于事务消息，只会进行透明重试（transparent retries），网络超时或异常等场景不会进行重试。3. 重试带来的副作用不停的重试看起来很美好，但也是有副作用的，主要包括两方面：消息重复，服务端压力增大远程调用的不确定性，因请求超时触发消息发送重试流程，此时客户端无法感知服务端的处理结果；客户端进行的消息发送重试可能会导致消费方重复消费，应该按照用户ID、业务主键等信息幂等处理消息。 较多的重试次数也会增大服务端的处理压力。 4. 用户的最佳实践是什么1）合理设置发送超时时间，发送的最大次数发送的最大次数在初始化客户端时配置在 ClientConfiguration；对于某些实时调用类场景，可能会导致消息发送请求链路被阻塞导致业务请求整体耗时高或耗时；需要合理评估每次调用请求的超时时间以及最大重试次数，避免影响全链路的耗时。2）如何保证发送消息不丢失由于分布式环境的复杂性，例如网络不可达时 RocketMQ 客户端发送请求重试机制并不能保证消息发送一定成功。业务方需要捕获异常，并做好冗余保护处理，常见的解决方案有两种：向调用方返回业务处理失败；尝试将失败的消息存储到数据库，然后由后台线程定时重试，保证业务逻辑的最终一致性。 3）关注流控异常导致无法重试触发流控的根本原因是系统容量不足，如果因为突发原因触发消息流控，且客户端内置的重试流程执行失败，则建议执行服务端扩容，将请求调用临时替换到其他系统进行应急处理。4）早期版本客户端如何使用故障延迟机制进行发送重试？对于 RocketMQ 4.x 和 3.x 以下客户端开启故障延迟机制可以用：producer.setSendLatencyFaultEnable(true)配置重试次数使用：producer.setRetryTimesWhenSendFailed()producer.setRetryTimesWhenSendAsyncFailed() 消费者消费重试消息中间件做异步解耦时的一个典型问题是如果下游服务处理消息事件失败，那应该怎么做呢？RocketMQ 的消息确认机制以及消费重试策略可以帮助分析如下问题：如何保证业务完整处理消息？消费重试策略可以在设计实现消费者逻辑时保证每条消息处理的完整性，避免部分消息消费异常导致业务状态不一致。业务应用异常时处理中的消息状态如何恢复？当系统出现异常（宕机故障）等场景时，处理中的消息状态如何恢复，消费重试具体行为是什么。1. 什么是消费重试？什么时候认为消费失败？消费者在接收到消息后将调用用户的消费函数执行业务逻辑。如果客户端返回消费失败 ReconsumeLater，抛出非预期异常，或消息处理超时（包括在 PushConsumer 中排队超时），只要服务端服务端一定时间内没收到响应，将认为消费失败。 消费重试是什么？消费者在消费某条消息失败后，服务端会根据重试策略重新向客户端投递该消息。超过一次定数后若还未消费成功，则该消息将不再继续重试，直接被发送到死信队列中； 重试过程状态机：消息在重试流程中的状态和变化逻辑； 重试间隔：上一次消费失败或超时后，下次重新尝试消费的间隔时间； 最大重试次数：消息可被重试消费的最大次数。  2. 消息重试的场景需要注意重试是应对异常情况，给予程序再次消费失败消息的机会，不应该被用作常态化的链路。推荐使用场景：业务处理失败，失败原因跟当前的消息内容相关，预期一段时间后可执行成功；是一个小概率事件，对于大批的消息只有很少量的失败，后面的消息大概率会消费成功，是非常态化的。  正例：消费逻辑是扣减库存，极少量商品因为乐观锁版本冲突导致扣减失败，重试一般立刻成功。错误使用场景：消费处理逻辑中使用消费失败来做条件判断的结果分流，是不合理的。 反例：订单在数据库中状态已经是已取消，此时如果收到发货的消息，处理时不应返回消费失败，而应该返回成功并标记不用发货。消费处理中使用消费失败来做处理速率限流，是不合理的。限流的目的是将超出流量的消息暂时堆积在队列中达到削峰的作用，而不是让消息进入重试链路。这种做法会让消息反复在服务端和客户端之间传递，增大了系统的开销，主要包括以下方面：RocketMQ 内部重试涉及写放大，每一次重试将生成新的重试消息，大量重试将带来严重的 IO 压力；重试有复杂的退避逻辑，内部实现为梯度定时器，该定时器本身不具备高吞吐的特性，大量重试将导致重试消息无法及时出队。重试的间隔将不稳定，将导致大量重试消息延后消费，即削峰的周期被大幅度延长。 3. 不要以重试替代限流上述误用的场景实际上是组合了限流和重试能力来进行削峰，RocketMQ 推荐的削峰最佳手段为组合限流和堆积，业务以保护自身为前提，需要对消费流量进行限流，并利用 RocketMQ 提供的堆积能力将超出业务当前处理的消息滞后消费，以达到削峰的目的。下图中超过处理能力的消息都应该被堆积在服务端，而不是通过消费失败进行重试。如果不想依赖额外的产品/组件来完成该功能，也可以利用一些本地工具类，比如 Guava 的 RateLimiter 来完成单机限流。如下所示，声明一个 50 QPS 的 RateLimiter，在消费前以阻塞的方式 acquire 一个令牌，获取到即处理消息，未获取到阻塞。RateLimiter rateLimiter = RateLimiter.create(50);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
.setClientConfiguration(clientConfiguration)
// 设置订阅组名称
.setConsumerGroup(consumerGroup)
// 设置订阅的过滤器
.setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
.setMessageListener(messageView -> {
// 阻塞直到获得一个令牌，也可以配置一个超时时间
rateLimiter.acquire();
LOGGER.info("Consume message={}", messageView);
return ConsumeResult.SUCCESS;
})
.build();4. PushConsumer 消费重试策略PushConsumer 消费消息时，消息的几个主要状态如下：Ready：已就绪状态。消息在消息队列RocketMQ版服务端已就绪，可以被消费者消费；Inflight：处理中状态。消息被消费者客户端获取，处于消费中还未返回消费结果的状态；Commit：提交状态。消费成功的状态，消费者返回成功响应即可结束消息的状态机；DLQ：死信状态消费逻辑的最终兜底机制，若消息一直处理失败并不断进行重试，直到超过最大重试次数还未成功，此时消息不会再重试。该消息会被投递至死信队列。您可以通过消费死信队列的消息进行业务恢复。最大重试次数 PushConsumer 的最大重试次数由创建时决定。例如，最大重试次数为 3 次，则该消息最多可被投递 4 次，1 次为原始消息，3 次为重试投递次数。重试间隔时间无序消息（非顺序消息）：重试间隔为阶梯时间，具体时间如下：说明：若重试次数超过 16 次，后面每次重试间隔都为 2 小时。顺序消息：重试间隔为固定时间，默认为 3 秒。 5. SimpleConsumer 消费重试策略和 PushConsumer 消费重试策略不同，SimpleConsumer 消费者的重试间隔是预分配的，每次获取消息消费者会在调用 API 时设置一个不可见时间参数 InvisibleDuration，即消息的最大处理时长。若消息消费失败触发重试，不需要设置下一次重试的时间间隔，直接复用不可见时间参数的取值。由于不可见时间为预分配的，可能和实际业务中的消息处理时间差别较大，可以通过 API 接口修改不可见时间。例如，预设消息处理耗时最多 20 ms，但实际业务中 20 ms内消息处理不完，可以修改消息不可见时间，延长消息处理时间，避免消息触发重试机制。修改消息不可见时间需要满足以下条件：消息处理未超时消息处理未提交消费状态 如下图所示，消息不可见时间修改后立即生效，即从调用 API 时刻开始，重新计算消息不可见时间。最大重试次数与 PushConsumer 相同。消息重试间隔 消息重试间隔 = 不可见时间 － 消息实际处理时长例如：消息不可见时间为 30 ms，实际消息处理用了 10 ms 就返回失败响应，则距下次消息重试还需要 20 ms，此时的消息重试间隔即为 20 ms；若直到 30 ms 消息还未处理完成且未返回结果，则消息超时，立即重试，此时重试间隔即为 0 ms。SimpleConsumer 的消费重试间隔通过消息的不可见时间控制。//消费示例：使用SimpleConsumer消费普通消息，主动获取消息处理并提交。
ClientServiceProvider provider1 = ClientServiceProvider.loadService();
String topic1 = "Your Topic";
FilterExpression filterExpression1 = new FilterExpression("Your Filter Tag", FilterExpressionType.TAG);
SimpleConsumer simpleConsumer = provider1.newSimpleConsumerBuilder()
//设置消费者分组。
.setConsumerGroup("Your ConsumerGroup")
//设置接入点。
.setClientConfiguration(ClientConfiguration.newBuilder().setEndpoints("Your Endpoint").build())
//设置预绑定的订阅关系。
.setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
.build();
List<MessageView> messageViewList = null;
try {
//SimpleConsumer需要主动获取消息，并处理。
messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
messageViewList.forEach(messageView -> {
System.out.println(messageView);
//消费处理完成后，需要主动调用ACK提交消费结果。
//没有ack会被认为消费失败
try {
simpleConsumer.ack(messageView);
} catch (ClientException e) {
e.printStackTrace();
});
} catch (ClientException e) {
//如果遇到系统流控等原因造成拉取失败，需要重新发起获取消息请求。
e.printStackTrace();
}修改消息的不可见时间 案例：某产品使用消息队列来发送解耦“视频渲染”的业务逻辑，发送方发送任务编号，消费方收到编号后处理任务。由于消费方的业务逻辑耗时较长，消费者重新消费到同一个任务时，该任务未完成，只能返回消费失败。在这种全新的 API 下，用户可以调用可以通过修改不可见时间给消息续期，实现对单条消息状态的精确控制。simpleConsumer.changeInvisibleDuration();
simpleConsumer.changeInvisibleDurationAsync();6. 功能约束与最佳实践设置消费的最大超时时间和次数 尽快明确的向服务端返回成功或失败，不要以超时（有时是异常抛出）代替消费失败。不要用重试机制来进行业务限流 错误示例：如果当前消费速度过高触发限流，则返回消费失败，等待下次重新消费。正确示例：如果当前消费速度过高触发限流，则延迟获取消息，稍后再消费。发送重试和消费重试会导致相同的消息重复消费，消费方应该有一个良好的幂等设计 正确示例：某系统中消费的逻辑是为某个用户发送短信，该短信已经发送成功了，当消费者应用重复收到该消息，此时应该返回消费成功。总结本文主要介绍重试的基本概念，生产者消费者收发消息时触发重试的条件和具体行为，以及 RocketMQ 收发容错的最佳实践。重试策略帮助我们从随机的、短暂的瞬态故障中恢复，是在容忍错误时，提高可用性的一种强大机制。但请谨记 “重试是对于分布式系统来说自私的”，因为客户端认为其请求很重要，并要求服务端花费更多资源来处理，盲目的重试设计不可取，合理的使用重试可以帮助我们构建更加弹性且可靠的系统。欢迎扫描下方二维码加入钉钉群一起沟通交流～点击此处，进入官网了解更多详情～
发表了文章
2022-11-16
5 步！用阿里云 Serverless 搭建高质量的图片压缩工具
作者：Regan Yue本文选自“Serverless 函数计算征集令”活动什么是 ServerlessServerless 是一种基于云计算的开发方法，它让开发人员可以专注于编写代码来解决业务问题，而不是处理服务器问题。它是独一无二的，因为它支持 Auto Scaling，执行应用程序所需的计算能力是按需分配的。并且使用一种称为事件驱动函数的模型来确定这些需求的范围。这就是 Serverless 架构，也称为功能即服务 (FaaS)。部署、初步体验工作开通阿里云函数计算 FC，点击下方链接跟随提示即可开通。开通地址：https://fcnext.console.aliyun.com/overview通过模版创建应用绑定 Github，然后选择好角色，点击创建这样就部署成功了。访问域名即可：无论是网页调用还是脚本调用，调用速度都比较快！可以看到使用阿里云 Serverless Devs 部署基于 Serverless 图像预测案例是十分流畅的。下面是评分和点评：上手容易度：⭐⭐⭐⭐⭐服务监控功能：⭐⭐⭐⭐⭐部署速度：⭐⭐⭐⭐执行速度：⭐⭐⭐⭐案例资源丰富度：⭐⭐⭐总体评价：⭐⭐⭐⭐体验在线编辑、再次部署通过服务列表-》服务 png-compress 详情-》函数管理-》函数详情-》函数代码可以在线编辑函数，进行开发。我将说明删除后，再次部署：整个流程很流畅，不过不知道为什么应用那里部署历史没有变化，没有看到函数的部署历史。如果是这样的话，那么函数部署如何回滚？体验后我有几方面的建议和心得：在线编辑代码功能建议上线上传文件功能函数部署建议有历史部署功能，以便可以回滚。 通过使用阿里云 Serverless Devs 部署基于 Serverless 图像预测案例，体验了阿里云 Serverless 的部分主要功能，阿里云 Serverless 的功能强大、上手容易、性能也不弱，不过目前应用模板还不够丰富，大部分是环境类模板，这方面有待加强；此外阿里云每月有 100 万次函数调用免费额度、每月前 400,000（GB-秒）函数实例资源的免费使用量，这对开发者来说十分友好。
发表了文章
2022-11-15
OpenSergo 流量路由：从场景到标准化的探索
作者：十眠流量路由，顾名思义就是将具有某些属性特征的流量，路由到指定的目标。流量路由是流量治理中重要的一环，多个路由如同流水线一样，形成一条路由链，从所有的地址表中筛选出最终目的地址集合，再通过负载均衡策略选择访问的地址。开发者可以基于流量路由标准来实现各种场景，如灰度发布、金丝雀发布、容灾路由、标签路由等。直播课程观看：https://yqh.aliyun.com/live/detail/29692微服务治理与 OpenSergo随着微服务(MicroServices) 理念的兴起，让大规模、高并发、低延迟的分布式应用成为可能。但是微服务架构是一把双刃剑，随着微服务架构复杂化，在大规模之下，再小的问题都会牵一发而动全身，因此随着微服务架构增长，如果不对微服务进行恰当的治理，微服务架构带来的效率、稳定性问题很可能会远大于微服务本身带来的架构红利。可以说，现代微服务架构的四大件：服务提供者、服务消费者、注册配置中心，当然还有容易被大家忽视但又十分重要的一点，那就是微服务治理。微服务治理的使命就是对微服务体系中的各个组件与环节进行治理，可以说做好微服务治理那就是把微服务做稳做好的必不可少的一环。在企业内部，往往存在着不同语言、不同通信协议的微服务，这种异构化的架构会导致治理微服务的过程中，业务开发者、架构师无法用统一的方式来对所有服务进行治理管控，并且这类异构会衍生出更多的痛点：业内对服务治理的能力和边界没有明确的认识，每个企业所定义的服务治理概念不一致，造成很高的理解和沟通成本。 开源微服务框架众多，对于服务治理缺乏一些标准化的约定。例如，Spring Cloud 中定义的微服务接口和 Dubbo 中定义的接口就没有办法互通，通过 Dubbo 和 Istio 管理的微服务也没有办法进行统一治理。开发者无法通过统一的配置方式来对不同框架、不同语言的服务进行统一治理管控。 缺少真正面向业务、能够减轻认知负担的抽象和标准。开发者真正想要的可能是简单的、指定服务间的调用关系和配置规则。但现在对于业务开发者来说，不仅需要了解不同微服务框架的部署架构，也要了解不同服务治理方式的概念和能力区别，认知成本很大。 基于上面这些痛点，阿里巴巴在 2022 年 1 月开始和 bilibili、CloudWego 等厂商、社区讨论服务治理如何规范化和更加普及，从而共同发起了 OpenSergo 项目。OpenSergo 是开放通用的，覆盖微服务及上下游关联组件的微服务治理项目，从微服务的角度出发，涵盖流量治理、服务容错、服务元信息治理、安全治理等关键治理领域，提供一系列的治理能力与标准、生态适配与最佳实践，支持 Java, Go, Rust 等多语言生态。OpenSergo 的最大特点就是以统一的一套配置/DSL/协议定义服务治理规则，面向多语言异构化架构，做到全链路生态覆盖。对于开发者来说可以通过同一套 OpenSergo CRD 标准配置针对微服务架构涉及到的每一个组件进行统一的治理管控，而无需关注各框架、语言的差异点，降低异构化、全链路服务治理管控的复杂度。下面我们将从流量路由这个场景入手，从常见的微服务治理场景出发。先是根据流量路由的实践设计流量路由的 Spec，同时在 Spring Cloud Alibaba 中实践遵循 OpenSergo 标准的流量路由能力。流量路由流量路由，顾名思义就是将具有某些属性特征的流量，路由到指定的目标。流量路由是流量治理中重要的一环，我们可以基于流量路由标准来实现各种场景，如全链路灰度、标签路由、金丝雀发布等。标签路由标签路由是按照标签为维度对目标负载进行划分，符合条件的流量匹配至对应的目标，从而实现标签路由的能力。当然基于标签路由的能力，赋予标签各种含义我们就可以实现各种流量路由的场景化能力。金丝雀发布金丝雀发布是一种降低在生产中引入新软件版本的风险的技术，方法是在将更改推广到整个基础架构并使其可供所有人使用之前，缓慢地将更改推广到一小部分用户。金丝雀发布是一种在黑与白之间，能够平滑过渡的一种发布方式。让一部分用户继续用旧版本，一部分用户开始用新版本，如果用户对新版本没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。一直都有听说，安全生产三板斧的概念：可灰度、可观测、可回滚。那么灰度发布能力就是帮助企业软件做到快速迭代验证的必备能力。在 K8s 中金丝雀发布的最佳实践如下：第一步：新建灰度 Deployment，部署新版本的镜像，打上新版本的标签。第二步：配置针对新版本的标签路由规则。第三步：验证成功，扩大灰度比例。第四步：若验证成功，将稳定版本的应用更新成最新镜像；若验证失败，把灰度的 Deployment 副本数调整到 0 或删除该 Deployment。全链路灰度全链路灰度发布就是通过线上多个应用部署灰度版本，灰度流量全部进入灰度版本，正常流量进入生产版本。灰度版本只针对灰度流量验证，有效减少风险。我们可以通过流量路由结合流量染色可以实现全链路的流量灰度能力。流量路由标准化业界微服务治理存在概念不统一、配置形式不统一、能力不统一、多框架统一管控较为复杂等问题。比如我们希望实现流量路由的能力，在 Spring Cloud 中可能需要通过 Spring Cloud 动态规则的方式进行配置，在 istio 中可能又是另一套配置方式，在其它组件上可能又是不同的配置。不同框架治理配置方式的不一致使得微服务统一治理管控的复杂度相当高。为此我们需要通过 OpenSergo 实现一套标准化的流量路由能力与实践，这样在任 OpenSergo 生态中的组件上需通过配置 OpenSergo TrafficRouter 规则，即可实现一致的流量路由能力。我们在实践了许多流量路由的场景后，将流量路由规则进行了如下的设计与抽象。OpenSergo 的流量路由规则 (v1alpha1) 主要分为如下：Workload 集合的抽象 (VirtualWorkloads)：将某一组 VirtualWorkload（如 Kubernetes Deployment, Statefulset 或者一组 pod，或某个 JVM 进程，甚至是一组 DB 实例）按照一定的特征进行分类。 流量标签规则 (RouterRule)：将特定特征的流量映射至特定特征所对应的 VirtualWorkloads 上。 路由链规则(RouterChain)将特定的 RouterRule 跟 VirtualWorkloads按照一定逻辑排列组合成 pipeline。 Workload 集合的抽象 (VirtualWorkloads)VirtualWorkloads 虚拟工作负载集合的抽象即 VirtualWorkload 集合，其中会将 VirtualWorkload 按照一定的特征进行分类。VirtualWorkload虚拟工作负载即 workload 集合的抽象，将一定属性特征的 workload 集合划分成一个 VirtualWorkload，其中 VirtualWorkload 可以是目标 service 集合也可以是 deployment，甚至可以是 database 的实例、库、表集合。对于通用的 workload 场景，我们可以利用 VirtualWorkloads CRD 进行描述。特别地，对于 Kubernetes workload，我们可以通过直接在 workload 上打 label 的方式进行特征标记，如在 Deployment 上打上 traffic.opensergo.io/label: gray 标签代表当前 Deployment 的标签特征为 gray。一个标准的 workloads 描述应该类似于：apiVersion: traffic.opensergo.io/v1alpha1
kind: VirtualWorkloads
metadata:
name: tag-rule
spec:
selector:
app: my-app
virtualWorkload:
- name: my-app-gray
target: my-app-gray-deployment
type: deployment
selector:
tag: gray流量路由规则 (RouterRule)流量路由规则 (RouterRule) 将特定特征的流量映射至特定特征所对应的 VirtualWorkloads 上。假设现在需要将内部测试用户灰度到新版主页，测试用户 uid=12345，UID 位于 X-User-Id header 中，不符合条件的外部用户流量访问原版主页。那么只需要配置如下 CRD 即可：apiVersion: traffic.opensergo.io/v1alpha1
kind: RouterRule
metadata:
name: tag-traffic-router-rule
spec:
selector:
app: my-app
http:
- name: my-traffic-router-http-rule
rule:
match:
header:
X-User-Id: # 参数名
exact: 12345 # 参数值
uri:
exact: "/index"
targets:
- workloads: my-app-worksloads
name: gray
target:
workloads: my-app-worksloads
name: base通过上述配置，我们可以将 path 为 /index，且 uid header 为 12345 的 HTTP 流量为灰度流量，访问灰度版本的新版主页。标签路由场景的流量路由配置 假设我们希望 Header x-user-id 为 123 的流量访问 spring-cloud-a 的具备 gray 标签的实例。其中 spring-cloud-a 的标签情况如下：那么我们需要配置对应的 TrafficRouterRule 配置如下：apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficRouterRule
metadata:
name: tag-traffic-router-rule
spec:
selector:
app: spring-cloud-a
http:
- name: my-traffic-router-http-rule
rule:
match:
headers:
X-User-Id: # 参数名
regex: "^(?!(?:\d{1,2}|100)$)[0-9]\d+$" # 参数值
queryParams:
name:
exact: xiaoming
uri:
prefix: "/"
targets:
- workloads: spring-cloud-a-worksloads
name: gray
target:
- workloads: spring-cloud-a-worksloads
name: base对应的 VirtualWorkloads 配置如下：apiVersion: traffic.opensergo.io/v1alpha1
kind: VirtualWorkloads
metadata:
name: spring-cloud-a-worksloads
spec:
selector:
app: spring-cloud-a
virtualWorkload:
- name: gray
target: spring-cloud-a
type: deployment
selector:
tag: gray
loadbalance: random
- name: base
target: spring-cloud-a
type: deployment
selector:
tag: _base
loadbalance: random金丝雀发布场景的流量路由配置我们配置了如下的金丝雀规则，希望 10% 的流量访问 spring-cloud-a 中具有 gray 标签的实例：对应的 TrafficRouterRule 配置如下：apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficRouterRule
metadata:
name: tag-traffic-router-rule
spec:
selector:
app: spring-cloud-a
http:
- name: my-traffic-router-http-rule
rule:
targets:
- workloads: spring-cloud-a-worksloads
name: gray
weight: 10
- workloads: spring-cloud-a-worksloads
name: base
weight: 90
target:
- workloads: spring-cloud-a-worksloads
name: base流量路由 Demo 演示Spring Cloud Alibaba Consumer 应用中增加 OpenSergo 的依赖，并启动 Spring Cloud Alibaba 流量路由的 Demo<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>opensergo-resource-transform</artifactId>
<version>2.2.9-SNAPSHOT</version>
</dependency>配置 OpenSergo 流量路由启动 OpenSergo 控制面下发 TrafficRouterRule CRD 规则 假设现在需要将灰度流量路由到 v2 版本，灰度请求符合如下条件 header：name=xiaoming，Params：location=shenzhen 的请求流量去往灰度 v2 版本，不符合条件的流量访问 v1 版本。那么只需要配置如下 CRD 即可：apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: TrafficRouterRule
metadata:
name: http-foo-rule
labels:
app: foo-app
spec:
http:
match:
headers:
name: 'xiaoming'
queryParams:
location: 'shenzhen'
targets:
- name: "v2"
selectors:
version: "v2"
target:
name: "v1"
selectors:
version: "v1"结果验证当我们执行 curl http://127.0.0.1:18083/router-testNacosRegistration{nacosDiscoveryProperties=NacosDiscoveryProperties{serverAddr='127.0.0.1:8848', endpoint='', namespace='', watchDelay=30000, logName='', service='service-provider', weight=1.0, clusterName='DEFAULT', group='DEFAULT_GROUP', namingLoadCacheAtStart='false', metadata={preserved.register.source=SPRING_CLOUD, version=v1}, registerEnabled=true, ip='192.168.1.4', networkInterface='', port=18082, secure=false, accessKey='', secretKey='', heartBeatInterval=null, heartBeatTimeout=null, ipDeleteTimeout=null, failFast=true}}其中返回默认 v1 版本的实例当我们执行curl -H 'name:xiaoming' http://127.0.0.1:18083/router-test\?location\=shenzhenNacosRegistration{nacosDiscoveryProperties=NacosDiscoveryProperties{serverAddr='127.0.0.1:8848', endpoint='', namespace='', watchDelay=30000, logName='', service='service-provider', weight=1.0, clusterName='DEFAULT', group='DEFAULT_GROUP', namingLoadCacheAtStart='false', metadata={preserved.register.source=SPRING_CLOUD, version=v2}, registerEnabled=true, ip='192.168.1.4', networkInterface='', port=18081, secure=false, accessKey='', secretKey='', heartBeatInterval=null, heartBeatTimeout=null, ipDeleteTimeout=null, failFast=true}}其中符合流量匹配的条件，返回默认 v2 版本的实例。总结与展望流量路由是微服务流量治理中的重要的一环，当然 MSE 还提供更广范围、更多场景的微服务治理能力，包括全链路灰度、无损上下线、微服务数据库治理、日志治理等一系列的微服务治理能力。服务治理是微服务改造深入到一定阶段之后的必经之路，是将微服务做稳做好的关键。同时我们也在与 CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo、ShardingSphere 等社区共同建设 OpenSergo 微服务治理标准，将企业与社区中微服务治理的场景与最佳实践共同提取成标准规范，也欢迎更多社区与企业一起参与 OpenSergo 微服务治理标准的共建。欢迎大家加入 OpenSergo 社区交流群（钉钉群）进行讨论：34826335MSE 云原生网关、注册配置专业版预付费首购享 8 折，首购 1 年及以上享 7 折。点击此处，即享优惠！
发表了文章
2022-11-15
RocketMQ 5.0 API 与 SDK 的演进
作者：艾阳坤RocketMQ 5.0 SDK 采用了全新的 API，使用 gRPC 作为通信层的实现，并在可观测性上做了很大幅度的提升。全新统一的 API此处的 API 并不单单只是接口上的定义，同时也规定了各个接口不同的方法和行为，明确了整个消息模型。RocketMQ 过去的 API 从第一版开始，至今已经过了很长时间，长期依赖是一个缺乏变革的状态，对于一些中途打算废弃或者变更的 API 也没有进行后续的迭代。此外，接口的定义也不够清晰。因此，RocketMQ 希望在 5.0 中能够建立一个统一的规范，精简整个 API，通过引入 builder 模式来引入更多的不变性，同时做好异常管理，给开发者和用户一个更加清爽的面貌。目前 C++ 和 Java 已经进行了 5.0 API 的定义与实现，更多语言的支持也陆续在路上了。我们也欢迎更多的开发者可以参与到社区的工作中来。这里给出 5.0 客户端的仓库链接：https://github.com/apache/rocketmq-clients除了在上述接口上做的一些修改之外， RocketMQ 5.0 还规定了四种新的不同的客户端类型，即 Producer/Push Consumer/Simple Consumer/Pull Consumer。其中 Pull Consumer 还在开发中；Producer 主要还是做了接口裁剪，规范了异常管理。在功能上其实并没有做一些颠覆性的改变。Push Consumer 也是比较类似的；Simple consumer 将更多的权利将下发给用户，是一种用户可以主动控制消息接收与处理过程的消费者，特别的，5.0 的 SDK 中，Push Consumer 和 Simple Consumer 都采用 RocketMQ 的 pop 机制进行实现，一些社区的同学可能已经熟悉了。如果用户并不一定想控制或者关心整个消息的接收过程，只在乎消息的消费过程的话，这个时候 Push Consumer 可能是一个更好的选择。RocketMQ 5.0 定义了四种不同的消息类型。过去的开源版本中其实我们并没有去突出消息类型这样一个概念，后续出于维护及运维方面的需要以及模型定义的完备，才让今天的 5.0 有了消息类型的这样一个概念。1、NORMAL：普通消息。2、FIFO：满足先入先出的语义。用户可以通过定义 message group 来控制消息间的消费顺序。例如图中的 fruit 这个 topic 下，可以定义不同的 message group，在 apple 这个 message group 下，会按照发送顺序决定消息被消费的顺序，并且不同的 message group 之间不会互相干扰。3、TRANSACTIONAL：可以将一条或多条消息包成一个事务，最终用户可以根据自己的业务结果选择提交或者回滚。4、DELAY：用户可以自主地设置消息的定时时间，相比之前开源版本仅允许用户设置定时/延迟级别，5.0 的实现中还讲允许用户设置更精确的时间戳。以上四种消息是互斥的，我们会在 topic 的元数据去标识它的类型。实际在消息发送的时候如果如果出现了尝试发送的消息类型与 topic 类型不匹配的情况，也会做一些限制。实现RocketMQ 5.0 在客户端的启动过程中提前进行了更多的准备工作。比如用户提前设置要发送消息的 topic 时，Producer 会在启动过程中尝试获取对应 topic 的路由。在过去的客户端实现中，在针对于某个 topic 第一次发送消息时，需要先获取路由，这里就会有一个类似冷启动的过程。提前获取 Topic 的路由信息有两点好处：1. 不阻塞后面的发送，让消息的发送仅仅触发发送这一个动作。2. 错误前置，比如用户要往一个不存在 Topic 发送消息时，因为路由的获取参与到整个客户端的启动过程，获取路由不成功，那整个客户端启动可能就会失败，用户也是拿不到对应的 Producer 对象的。类似的，Consumer 的启动也会有这样的一个过程。除此之外，我们在客户端和服务端之间增加了一个 Telemetry 的部分，它会在客户端和服务端之间建立起了一个进行双向数据通讯的通道，客户端和服务端会在这个过程中沟通配置，比如服务端可以实现对客户端配置的下发，更好地管理客户端。此外，Telemetry 也可以将本地配置主动上报给服务端，让服务端也可以对客户端的设置有更好的了解。Telemetry 通道也会在客户端启动时尝试建立，如果这个通道没有建立成功，也会影响客户端的启动。总的来说，客户端的启动过程会尽可能将所有准备工作做好。同时在客户端和服务端之间建立 Telemetry 这样一个通讯通道。客户端内部存在一些周期性的任务，比如路由的定时更新以及客户端往服务端发送心跳等。对于上文中提到的 Telemetry 过程中，客户端的配置上报也是周期性的。Producer 在 RocketMQ 5.0 中的具体工作流程消息在发送时，会检查是否已经获取对应 topic 的路由信息。如果已经获取，则尝试在路由中选取队列，随即查看要发送的消息的类型是否与 topic 类型匹配，如果匹配，则进行消息发送。如果发送成功，则返回；否则，判断当前重试次数是否超出用户设置的上限，如果超出，则返回失败；否则轮转到下一个队列，然后对新的队列进行重试直到消费次数超出上线。而如果启动过程中没有提前获取路由，那么消息发送时依然会先尝试获取路由，然后再进行下一步操作。另外一点相对于老客户端较大的改变在于，客户端从底层 RPC 交互到上层的业务逻辑全部采用异步实现。Producer 依然会提供一个同步发送接口和异步发送接口，但同步的方法也是使用异步来实现，整个逻辑非常统一和清爽。Push Consumer 分为两部分，消息的接收和消费。消息接收流程为：客户端需要不断地从服务端拉取消息，并将消息缓存。Push Consumer 会将消息先缓存到客户端的本地，再进行消费，因此它会判断客户端本地的 Cache 是否已满，如果已满，则隔一段时间再判断，直到消息被客户端消费，Cache 尚有余量时再进行消息拉取。为了避免出现一些内存问题，Cache 的大小也是被严格限制的。消息消费过程分为两个类型，顺序类型和非顺序类型。其中非顺序类型即并发消费。消费者会先从 Cache 中获取消息，然后尝试消费消息，消费后再将消息从 Cache 中移除。消息消费成功时，会尝试将消息 ACK ，消费流程结束；如果消费失败，则尝试修改消息的可见时间，即决定下一次什么时候可见。顺序消费指对于同一个 Group 的消息，最终消费时一定是前一条消息被消费过并且得到确认后，后面的消息才能够继续消费。而消费过程与非顺序消费类似，首先尝试从 Cache 中拉取消息，如果消费成功，则将消息 ACK。ACK 成功后，将其从 Cache 中移除。特别地，如果消费失败，会 suspend 一段时间，然后继续尝试对消息进行消费。此时会判断消费次数是否超限，如果超限，则会尝试将消息放入死信队列中。相对于非顺序消费，顺序消费更复杂，因为其需要保证前一个消息消费成功后才能对后面的消息进行消费。顺序消费的消费逻辑是基于 message group 隔离的。message group 会在发送时做哈希，从而保证 message group 的消息最终会落在一个队列上，顺序消费模式本质上保证队列内部消费的顺序。此外，因为不同 message group 的顺序消息最终可能会映射到同一个队列上，这可能会导致不同的 message group 之间的消费形成阻塞，因此服务端未来会实现一个虚拟队列，让不同的 message group 映射到客户端的虚拟队列，保证他们之间没有任何阻塞，从而加速数据消息的消费过程。对于 Simple Consumer，用户可以主动控制消息接收和确认的流程。比如用户收到消息后，可以根据业务决定是否过一段时间再消费该消息，或者不需要再收到该消息。消费成功后将消息 ACK 掉，如果失败则主动修改可见时间，选择该消息下一次什么时候可见，即由用户自发地控制整个过程。可观测性Shaded Logback因为历史原因，RocketMQ 的老客户端并不是面向 SLF4J 进行编程的，而是面向 logback 的。这么做的目的其实是为了方便快捷地获取日志，不需要让用户自己去手动配置。RocketMQ 中专门有一个 logging 模块是负责日志部分的，像用户自己使用了 logback ，RocketMQ SDK 如果也直接去使用 logback，两者就会产生各种各样的冲突，这个 logging 模块就是用来保证这一层隔离性的。但是 logging 模块本身的实现并不是很优雅，也带来了一定的维护成本。因此我们采用了 shade logback 的方式来达到上文提到的隔离性。shaded logback 不仅能够避免用户的 logback 与 RocketMQ 自己的 logback 冲突，还能保持较好的可维护性，将来要想在日志上去做一些修改，也来得容易的多。具体来说，用户的 logback 会采用 logback.xml 的配置文件，通过 shade logback， RocketMQ 5.0 的客户端会使用 rocketmq.logback.xml 的配置文件，因此在配置部分就已经完全隔离了，同时在 shade 的过程中，还对原生 logback 中使用到的一些环境变量和系统变量也进行了修改，这样就保证了两者的彻底隔离。另外，使用 shadeed logback 之后，RocketMQ 5.0 客户端中的日志部分就全都是面向 SLF4J 来进行编程的了，这样一来，如果我们未来想让用户自己去完全控制日志的话，提供一个去除 logback 的 SDK 就可以了，非常方便。Trace5.0 的消息轨迹基于 OpenTelemetry 模型进行定义与实现，消息发送或接收消息的流程被定义为一个个独立的 span ，这一套 span 规范参照了 OpenTelemetry 关于 Messaging 的定义。图中这里 Process P 表示 Producer ，Process C 表示 Consumer。消息的全生命周期，从发送到接收到消费，就可以具象化为这样一个个的 span。比如，针对 Push Consumer 而言，先会有一个 receive 的 span 来表示从服务端获取消息的过程，收到消息后到会先等待消息被处理，这个也就是 await span 表示的过程，消息被处理则对应图中的 process span，消息消费结束之后，向服务端反馈消息处理结果也会有专门的 span 进行描述。我们通过 parent 和 link 来讲所有的这些 span 关联起来，这样通过一条消息的任意一个 span，就可以获得这条消息全生命周期的所有 span。不仅如此，用户还将允许可以设置一个 span context 与自己的业务链路进行关联，将 RocketMQ 5.0 的消息轨迹本身嵌入进自己的全链路可观测系统中去。MetricsTracing 相对来说成本是比较高的，因为一条消息从发送到接收，可能会有很多流程，这就伴随着很多的 span，这就导致相对来说，tracing 数据的存储查询成本相对来说比较高。我们希望诊断整个 SDK 的健康状况，同时又不希望收集太多的 tracing 信息提高成本，此时提供一份 metrics 数据就能比较好地满足我们的需求。在 SDK 的 metrics 中我们新增了诸多指标，包括不限于 Producer 中消息发送延时，Push Consumer 中消息的消费耗时和消息缓存量，可以帮助用户和运维者更快更好地发现异常。5.0 中 SDK 的 metrics 也是基于 OpenTelemetry 进行实现的。以 Java程序为例，OpenTelemetry 对于 Java 的实现本身提供了一个 agent，agent 在运行时会打点采集 SDK 的一些 tracing/metrics 信息，并将它上报到对应的 metric collector 中，这种通过 agent 来降低无侵入式数据采集的方式被称之为 automatic instrumentation，而手动在代码中实现打点采集的方式则被称之 manual instrumentation。对于 metrics 我们目前还是采用 manual instrumentation 的方式来进行数据的采集和上报的。服务端会告知客户端对应的 collector 的地址，然后客户端将 Metrics 数据上传到对应的 collector 当中去。作者介绍：艾阳坤，Apache RocketMQ 5.0 Java SDK 作者，CNCF Envoy Contributor，CNCF OpenTelemetry Contributor，阿里云智能高级开发工程师。加入 Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献，相信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅可以结识社区大牛，提升技术水平，也可以提升个人影响力，促进自身成长。社区 5.0 版本正在进行着如火如荼的开发，另外还有接近 30 个 SIG（兴趣小组）等你加入，欢迎立志打造世界级分布式系统的同学加入社区，添加社区开发者微信：rocketmq666 即可进群，参与贡献，打造下一代消息、事件、流融合处理平台。欢迎您扫描下方二维码加入钉钉群一起沟通交流～点击此处，进入官网了解更多详情～
发表了文章
2022-11-15
鼎茂科技获得阿里云首批产品生态集成认证，携手阿里云共建新合作
近日，上海鼎茂信息技术有限公司（以下简称“鼎茂科技”）的鼎茂智能运维 AIOps 平台软件（V3.0）与阿里云计算有限公司（以下简称“阿里云”）的阿里云可观测套件 ACOS 经过严格测试程序，完成了首批的产品生态集成认证测试。作为入选阿里云首期云原生加速器的企业，鼎茂科技通过云原生加速器项目携手阿里云共建更加丰富的云原生产业生态圈，加速云原生落地。此前，阿里云首次提出了“被集成”战略：将行业解决方案的搭建、实施、复制交由合作伙伴，阿里云只承担基础设施（IaaS）、技术中间件（PaaS）、数据平台（DaaS）层面的产品技术。“被集成”是阿里云对业务边界进行认真思考后作出的一个重要转变，标志着阿里云生态对合作伙伴的全面开放。阿里云产品生态集成认证是面向阿里云合作伙伴自有产品、解决方案与阿里云相关产品的兼容性、可用性的技术能力认证。获得此认证，证明了鼎茂科技的技术能力、产品应用水平已满足阿里云相关产品的适配性要求。鼎茂科技是一家企业级数智运营科技公司，总部位于上海，同时拥有杭州算法中心和北京、成都分公司，以及广州、深圳、南京等地的专业技术团队。通过自主研发的 ARCANA 数智平台和场景化智能应用，为企业提供统一的数据运营新方法，实现全域 AIOps 智能运维。鼎茂科技以平台+算法为技术核心，创新突破“AI 能力闭环”和“运维场景闭环”，完成了平台级数智底座+全矩阵智能应用的产品体系建设。与多家人工智能科研院校深度合作，强化自主 AIOps 技术研发与场景泛化应用的能力，帮助企业应对快速变化和不断成长的 IT 环境，实现实时精准的洞察和全局化数智运营。阿里云可观测套件能够实时高效地接入用户环境中的多种数据源，收集用户环境中的 IT 和业务数据，进行统一的管理和存储，通过便捷和强大的建模分析工具，将数据进行关联分析、业务建模，结果实时输出给可视化、告警以及其他应用，具备统一监控、全景监控和关联分析等特点。阿里云拥有丰富的云原生产品家族，有超过 300 款的产品，近千个技术解决方案。本次鼎茂科技获得阿里云产品集成认证，代表了鼎茂科技在生态合作建设上迈过了一个新里程碑。鼎茂科技一直以生态伙伴的身份与阿里云保持着深度合作。未来，借助阿里云的“被集成”生态战略与生态集成技术的全面开放，双方的紧密合作将进入新的阶段，共同为中国数千万家企业提供数字化转型服务。
发表了文章
2022-11-15
2 分钟，教你用 Serverless 每天给女朋友自动发土味情话
作者：安可Serverless 简介Serverless，中文意思是 “无服务器”，所谓的无服务器并非是说不需要依靠服务器等资源，而是说开发者再也不用过多考虑服务器的问题，可以更专注在产品代码上，同时计算资源也开始作为服务出现，而不是作为服务器的概念出现。Serverless 架构主要包含两部分：BaaS 和 FaaS，通常位于云端，使用时不需要关注最底层的服务器。BaaS（后端即服务：Backend as a Service）包括对象存储、云数据库、API 网关、消息推送等。FaaS（函数即服务：Functions as a Service）对计算能力进行了抽象，可以在无需管理服务器的情况下响应事件。Serverless 三大应用场景场景一：事件触发场景，有事件触发时才会执行。场景二：流量突发场景，遇到突发大流量情况时，Serverless 架构下按需加载，弹性伸缩，节省资源，负载均衡。场景三：大数据处理场景，用户只需要上传核心代码到函数计算，就可以快速完成整个工作。Serverless 的优势传统架构下，面对大流量场景，需要增加机器或者对机器升级，运维较为困难。面对高峰和低谷，无法做到按需使用，成本较高。Serverless 架构下，开发者只需专注代码开发，无需在各个云资源控制台手动开通服务和配置管理，并能够根据业务请求自动进行弹性伸缩；支持用户按需付费，成本较低；开发周期快，很大程度上提升了开发、部署的效率。具体可以查看阿里云相关文档：https://developer.aliyun.com/group/serverlessPython 实现发送邮件演示视频：https://developer.aliyun.com/live/249772import requests
import yagmail # 此模块用于发邮件
import schedule # 此模块用于计划任务
from bs4 import BeautifulSoup
import re
ran = 0
url = 'https://tianqi.2345.com/cixian1d/70177.htm' # 定义天气预报的url
loveurl = 'https://www.guaze.com/juzi/23389.html' # 定义情话的url
def email():
global ran # 将ran变量声明为全局变量
web = requests.get(url)
# print(web.text)
page = BeautifulSoup(web.text,"html.parser")
# print(ran)
# print(love[ran])
weather = page.find("div",class_="real-today")
# print(weather.text)
web2 = requests.get(loveurl)
web2.encoding = 'gb2312'
page = BeautifulSoup(web2.text, "html.parser")
div = page.find('div', class_="content")
div = str(div.text)
# print(div)
grep = re.compile(r"\d+、(.*)")
content = grep.findall(div)
# print(content)
# email函数内的内容是爬取天气和情话的，具体的地址天气你可以更换url
yag = yagmail.SMTP(
host='smtp.qq.com', user='xxxxxxx@qq.com', # 如过用的是qq邮箱就写smtp.qq.com，如果是163就写smtp.163.com
password='xhaztrwpjffpbdhh', smtp_ssl=True # 授权码在qq邮箱里开启smtp就会生成一个
weather = [weather.text,"每日情话:",content[ran], # 定义发送内容
yagmail.inline(r"/.love.jpg") # 附件图片，不发图片可以删掉
yag.send(
to=['xxxxxxxxx@qq.com'],
subject='早鸭', # 邮件主题
contents=weather # 发送的内容为上面定义的weather，其中weather.text是天气预报，content[ran]是情话
print("发送完成")
ran += 1
schedule.every().day.at("05:21").do(email) # 每天5点20分执行函数email0
#schedule.every(10).seconds.do(email) #每10秒执行一下函数email的内容，我这里用于测试
while True:
schedule.run_pending(部署到阿里云 Serverless，实现自动发送1. 登录到阿里云首页2. 选择产品->弹性计算->Serverless->函数计算3.进入控制台->服务及函数->创建函数4.上传代码->上传文件夹->选择文件夹->保存并部署5.函数配置->编辑环境信息->修改函数入口6.添加触发器，实现每日定时发送触发器管理->创建触发器->定时触发器->填写名称和指定时间7. 导入依赖并部署先在终端执行以下三条命令，导入项目所需要的依赖：pip3 install yagmail -t .
pip3 install schedule -t .
pip3 install bs4 -t .点击右上角保存并部署：最终效果展示点击左上角测试函数，然后通过实时日志查看运行结果：总结这次实战是对 Serverless 的一次深刻的理解，收获技术的同时也提升了自己的学习能力。由于目前正在准备考研，就好久没有更新关于自学技术的文章，这回借着阿里云官方评测活动也去学一学火热的 Serverless 无服务架构的技术和思想，在这里分享这个当下流行的技术，然后结合着一些个人浅显的探索，希望能和大佬们共同学习成长！戳此处，立即查看原文！
发表了文章
2022-11-15
阿里云微服务引擎 MSE 9 月份产品动态
发表了文章
2022-11-15
传统 Web 框架部署与迁移
与其说 Serverless 架构是一个新的概念，不如说它是一种全新的思路，一种新的编程范式。但是原生的 Serverless 开发框架却非常少。以 Web 框架为例，目前主流的 Web 框架“均不支持 Serverless 模式部署”，因此我们一方面要尝试接触 Serverless，一方面又没办法完全放弃传统框架，所以如何将传统框架更简单、更快速、更科学地部署到 Serverless 架构是一个值得探讨的问题。请求集成方案请求集成方案实际上就是把真实的 API 网关请求直接透传给 FaaS 平台，而不在中途增加任何转换逻辑。以阿里云函数计算的 HTTP 函数为例，当想要把传统框架（例如 Django、Flask、Express、Next.js 等）部署到阿里云函数计算平台，并且体验Serverless架构带来的按量付费、弹性伸缩等红利时，得益于阿里云函数计算的 HTTP 函数和 HTTP 触发器，使用者不仅可以快速、简单地将框架部署到阿里云函数计算平台，还可以获得和传统开发一样的体验。例如以 Python 的 Bottle 框架开发一个 Bottle 项目：# index.py
import bottle
@bottle.route('/hello/<name>')
def index(name):
return "Hello world"
if __name__ == '__main__':
bottle.run(host='localhost', port=8080, debug=True)之后，可以直接在本地进行调试。当想要把该项目部署到阿里云函数计算平台时，只需要增加一个 default_app 的对象即可：app = bottle.default_app()整个项目的代码如下所示：# index.py
import bottle
@bottle.route('/hello/<name>')
def index(name):
return "Hello world"
app = bottle.default_app()
if __name__ == '__main__':
bottle.run(host='localhost', port=8080, debug=True)若在阿里云函数计算平台创建函数，将入口函数设置为 index.app 即可。除了 Bottle 框架之外，其他 Web 框架的操作方法是类似的，再以 Flask 为例：# index.py
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
return 'Hello, World!'
if __name__ == '__main__':
app.run(
host="0.0.0.0",
port=int("8001")
)在创建函数的时候设置入口函数为 index.app，就可以保证该 Flask 项目运行在函数计算平台上。当然，除了使用已有的语言化 Runtime（指具体语言的运行时，例如 Python3 运行时、Node. js12 运行时），我们还可以考虑使用 Custom Runtime 和 Custom Container 来实现，例如，一个 Web 项目完成之后，可以编写一个 Bootstrap 文件（在 Bootstrap 文件中写一些启动命令）。例如要启动一个 Express 项目，把 Express 项目准备完成之后，可以直接创建 Bootstrap 文件，并将启动命令配置到该文件中：#!/usr/bin/env bash
export PORT=9000
npm run star阿里云函数计算还提供了更简单的 Web 框架迁移方案。如图所示是阿里云函数计算页面传统 Web 框架迁移功能示例。阿里云函数计算页面传统 Web 框架迁移功能选择对应的环境之后，只需要上传代码，做好简单的配置，即可让传统的 Web 框架迁移至阿里云函数计算平台。如果通过开发者工具进行部署，以 Serverless Devs 为例，首先创建 index.py：# -*- coding: utf-8 -*-
from bottle import route, run
@route('/')
def hello():
return "Hello World!"
run(host='0.0.0.0', debug=False, port=9000)
然后编写资源和行为描述文件：
edition: 1.0.0
name: framework #项目名称
access: "default" #密钥别名
services:
framework: #业务名称/模块名称
component: fc #组件名称
actions:
pre-deploy: #在部署之前运行
- run: pip3 install -r requirements.txt -t . #要运行的命令行
path: ./code #命令行运行的路径
props: #组件的属性值
region: cn-beijing
service:
name: web-framework
description: 'Serverless Devs Web Framework Service'
function:
name: bottle
description: 'Serverless Devs Web Framework Bottle Function'
codeUri: './code'
runtime: python3
handler: index.app
timeout: 60
triggers:
- name: httpTrigger
type: http
config:
authType: anonymous
methods:
- GET
customDomains:
- domainName: auto
protocol: HTTP
routeConfigs:
- path: '/*'
同时，提供对应的Bootstrap文件，即启动文件：
#!/bin/bash
python3 index.py完成之后，执行 deploy 指令进行部署：s deploy部署结果如图所示。Serverless Devs 部署 Bottle 框架过程根据返回的网址，可以看到部署结果预览，如下图所示。Serverless Devs 部署结果预览通过 Serverless Devs 开发者工具，我们不仅可以简单地进行传统 Web 框架的部署，还可以快速在 Serverless 架构下进行传统 Web 框架的初始化。以 Express 项目为例，只需要通过 Serverless Devs 开发者工具执行如下代码即可进行 Express.js 项目的初始化。s init start-express初始化的过程如图所示。此时，只需要进入该项目执行如下代码即可快速进行项目的部署。s deploy通过 Serverless Devs 初始化 Express 项目部署结果如图所示。打开系统分配的地址，可以看到通过 Serverless Devs 开发者工具初始化的 Express 项目，效果展示如下图所示。Express 项目完成效果展示当然，目前 Serverless Devs 开发者工具不仅支持 Express 项目的快速初始化（见表），还支持包括 Django、Flask、SpringBoot 等数十个传统框架的快速创建与部署。Serverless Devs 支持快速创建和部署的传统框架综上所述，通过阿里云函数计算进行传统 Web 框架的部署和迁移是很方便的，并且得益于 HTTP 函数与 HTTP 触发器，整个过程侵入性非常低。当然，将传统 Web 框架部署到阿里云上的可选方案也比较多。编程语言化的 Runtime：只需要写好函数入口即可。Custom Runtime：只需要写好 Bootstrap 即可。Custom Container：直接按照规范上传镜像文件即可。 部署途径也是多种多样的，具体如下。直接在控制台创建函数。在应用中心处创建 Web 应用。利用开发者工具。其他方案相对于阿里云的 HTTP 函数以及 HTTP 触发器，其他 FaaS 平台则需要借助 API 网关以及一个转换层来实现传统 Web 框架到 FaaS 平台的部署。如图所示，以 Python Web 框架为例，在通常情况下，使用 Flask 等框架时实际上要通过 Web Server 才能进入下一个环节，而云函数是一个函数，本不需要启动 Web Server，所以可以直接调用 wsgi_app 方法。传统 WSGI Web Server 工作原理示例这里的 environ 就是对 event/context 等处理后的对象，也就是所说的转换层要做的工作；start_response 可以认为是一种特殊的数据结构，例如 response 结构形态等。当然，转换工作在某些情况下还是比较麻烦的，所以很多时候我们可以借助常见的开发者工具进行传统 Web 框架的部署，例如借助开源的开发者工具 Serverless Devs、Serverless Framework 等。作者介绍刘宇，阿里云 Serverless 产品经理田初东，蚂蚁集团算法工程师卢萌凯，阿里云 Serverless 高级解决方案架构师王仁达，阿里云 Serverless 工具链技术负责人点击此处，直达阿里云函数计算 FC！
发表了文章
2022-11-14
谈谈我对服务网格的理解
作者：王夕宁服务网格作为一种用来管理应用服务通信的基础核心技术，为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。什么是服务网格技术以 Istio 为代表的 Service Mesh 技术已经存在四五年的时间了，阿里云也是第一批支持 Service Mesh 云服务的厂商。在 Service Mesh 技术中，通过把服务治理的能力进行 Sidecar 化，实现与应用程序本身的解耦。这些若干个 Sidecar 代理就形成了一个网状的数据平面，通过该数据平面可以处理和观察所有应用服务间的流量。负责数据平面如何执行的管理组件称为控制平面，是服务网格的大脑，它为网格使用人员提供公开 API，以便更容易地操纵网络行为。通过 Service Mesh，Dev/Ops/SRE 将以统一的、声明的方式解决应用服务管理问题。服务网格一种应用感知的云原生基础设施我们认为服务网格是一种应用感知的云原生基础设施。它不仅仅是服务治理，而且包括了其他几个维度的云原生应用感知的特征与能力。我们把它分为了 5 个部分，分别是：云原生应用网络云原生应用治理云原生零信任安全云原生可观测及应用弹性云原生应用生态引擎云原生应用网络首先来看云原生应用网络，分为 3 个部分来介绍。Sidecar 模式下的云原生应用网络数据面 L4 与 L7 代理解耦模式下的网络基于地域可用区信息的优先路由网络是 Kubernetes 的核心部分，涉及了 Pod 间通信、Pod 和服务间通信以及服务与外部系统间的通信等。Kubernetes 集群中使用 CNI 插件来管理其容器网络功能，使用 Kube-proxy 维护节点上的网络规则， 譬如使发往 Service 的流量（通过 ClusterIP 和端口）负载均衡到正确的后端 Pod。容器网络成为用户使用 IaaS 网络的新界面，以阿里云 ACK Terway 网络为例，基于阿里云 VPC 网络直通弹性网卡，具备高性能特征，同时无缝地跟阿里云 IAAS 网络对接。然而，kube-proxy 设置是全局的，无法针对每个服务进行细粒度控制，而且 kube-proxy 只是专在网络数据包级别上运行。它无法满足现代应用程序的需求，如应用层流量管理、跟踪、身份验证等。我们来看服务网格 Sidecar 代理模式下的云原生应用网络是如何解决这些问题的。服务网格通过 Sidecar 代理将流量控制从 Kubernetes 的服务层中解耦，将代理注入到每个 Pod，并通过控制平面操纵管理这些分布式代理，从而可以更加精细地控制这些服务之间的流量。那么在 Sidecar 代理下的网络数据包的传输是怎样的过程？当前 Istio 实现中涉及了 TCP/IP 堆栈的开销，它使用了 Linux 内核的 netfilter 通过配置 iptables 来拦截流量，并根据配置的规则对进出 sidecar 代理的流量进行路由。客户端 pod 到服务器端 pod 之间的典型路径（即使在同一主机内）至少要遍历 TCP/IP 堆栈 3 次（出站、客户端 Sidecar Proxy 到服务器端 Sidecar Proxy、入站）。为了解决这个网络数据路径问题，业界通过引入 eBPF 绕过 Linux 内核中的 TCP/IP 网络堆栈来实现网络加速，这不但降低了延迟，同时也提升了吞吐量。当然，eBPF 并不会替换 Envoy 的七层代理能力，在七层流量管理的场景下，仍然是 4 层 eBPF + 7 层 Envoy 代理的融合模式。只有在针对 4 层流量网络的情况下，跳过代理 pod 直接进入网络接口。前面讲述的是传统的 Sidecar 代理模式，除此之外，业界开始探索一种新型的数据平面模式。它的设计理念是：将数据平面分层，4 层用于基础处理，特点是低资源、高效率；7 层用于高级流量处理，特点是功能丰富（当然也需要更多的资源）。这样的话， 用户可以根据所需功能的范围，以渐进增量的方式采用服务网格技术。具体来说，在 4 层处理中，主要包括：流量管理：TCP 路由安全：面向 4 层的简单授权策略、双向 TLS可观测：TCP 监控指标及日志在 7 层处理中，则主要包括：流量管理：HTTP 路由、负载均衡、熔断、限流、故障容错、重试、超时等安全：面向 7 层的精细化授权策略可观测：HTTP 监控指标、访问日志、链路追踪那么数据面 L4 与 L7 代理的解耦模式下，Service Mesh 的网络拓扑将是什么形式？一方面，将 L4 Proxy 能力下移到 CNI 组件中，L4 Proxy 组件以 DaemonSet 的形式运行，分别运行在每个节点上。这意味着它是为一个节点上运行的所有 pod 提供服务的共享基础组件。另一方面，L7 代理不再以 Sidecar 模式存在，而是解耦出来，我们称之为 Waypoint Proxy，它是为每一个 Service Account 创建的 7 层代理 pod。4 层和 7 层代理的配置仍然保持通过 Service Mesh 控制面组件来进行下发管理。总之，通过这种解耦模式，实现了 Service Mesh 数据平面与应用程序之间的进一步解耦分离。那么， 在 Istio 的具体实现中，可以分为 3 个部分：Waypoint代理：L7 组件完全独立于应用程序运行，安全性更高；每个身份（Kubernetes 中的服务账户）都有自己专用的 L7 代理（ Waypoint 代理），避免多租户 L7 代理模式引入的复杂度与不稳定性；同时，通过 K8s Gateway CRD 定义触发启用；ztunnel：将 L4 处理下沉到 CNI 级别，来自工作负载的流量被重定向到 ztunnel， 然后 ztunnel 识别工作负载并选择正确的证书来处理；与 Sidecar 模式兼容：Sidecar 模式仍然是网格的一等公民，Waypoint 代理可以与部署了 Sidecar 的工作负载进行本地通信；Service Mesh 作为云原生应用网络之场景示例：基于地域可用区信息的优先路由在这个示例中，我们部署了两套一样的应用服务到 2 个不同的可用区下，即这个部署架构图中的可用区 A 和 B。正常情况下，这些应用服务本身是遵循了同 AZ 流量路由优先的机制，也就是说可用区 A 中的应用服务 productpage 会指向本可用区中的 reviews 服务。而当本可用区服务不可用时，譬如 reviews 服务出现故障，容灾模式就会自动开启，这个时候可用区 A 中的应用服务 productpage 会指向另一可用区 B 中的 reviews 服务。这个流量拓扑是阿里云 ASM 产品提供的网格拓扑中按可用区信息展示的调用链路。在实现同 AZ 路由的过程中， 是不需要修改应用代码本身就可以完成的。同样地，在不需要修改应用代码本身的情况下，Service Mesh 自动实现故障转移以保证高可用。这个拓扑图中可以看到可用区 A 中的应用服务会自动切换到调用可用区B中的服务了。  云原生应用治理接下来看云原生应用治理，它的内容包含很多维度，这里重点摘取讲述 3 个部分。服务慢启动以支持预热能力全链路流量管理与服务框架的融合先来看下启用预热模式前后的差异。未启用预热模式：不支持新 Pod 的渐进式流量增加。每当新目标 Pod 加入时，请求方都会向该 Pod 发送一定比例的流量。这对于需要一些预热时间来提供全部负载的服务可能是不可取的，并且可能会导致请求超时、数据丢失和用户体验恶化。作为一个实际示例，上述问题体现在基于 JVM 的 Web 应用程序中，这些应用程序使用水平 pod 自动缩放。当服务刚启动时，它会被大量请求淹没，这会导致应用程序预热时持续超时。因此，每次扩展服务时，都会丢失数据。启用预热模式：预热/慢启动模式又称渐进式流量增加，用户可以为他们的服务配置一个时间段。每当一个服务实例启动时， 请求方会向该实例发送一部分请求负载，并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达，它就会退出慢启动模式。在慢启动模式下，在添加新的目标服务 Pod 时，可以使得他们不会被大量请求压倒， 这些新目标服务可以根据指定的加速期在接受其均衡策略的请求之前进行预热。通过这两个图也可以看到， 在启用了预热模式之后， 新创建的 pod 达到均衡的负载请求所需的时间会拉长，这也反映了在一定的预热时间内，进入该 pod 的请求是逐步增加的。一个实际客户案例：扩容和滚动更新场景下支持预热实现服务优雅上线背景：Java 应用冷启动时大流量导致 CPU 打满，调用异常应用滚动更新仅仅通过 readiness 无法实现优雅上线支持预热实现服务优雅上线：ASM 感知实例的上下线，当发现一台机器刚上线时，自动将其权重给调低，过了一定的时间后（预热周期）再将权重调到 100%（权重调整比例）；对应用完全没有侵入性；那这个功能是怎么在服务网格 ASM 中实现的呢，简单说，一行配置就可以实现预热、慢启动能力。这个拓扑图也是这个实际案例的脱敏简化版，可以看到通过预热功能：能够实现业务的平滑启动，完美避免业务抖动问题；启用预热功能之后，流量均衡地分布到 v1 和 v2 版本，相比未启用热功能多花费了 1 分 10 秒左右的时间，以此缓冲。全链路流量管理，两个使用场景全链路灰度发布：在生产环境正常运行的同时，开始针对部分应用服务进行灰度升级，譬如图中的 B 和 D 应用进行灰度，在不需要修改应用逻辑的情况下，利用 Service Mesh 技术就可以实现根据请求来源或者请求的头信息，动态地路由到不同版本的服务上。譬如，当请求头中包含 tag1 时，应用 A 就会调用灰度版本 B，而 C 并没有灰度版本，系统就会自动 fallback 回退到原有的版本。多版本开发环境：类似地，有一个基线环境，其他不同的开发环境可以根据需要，分别部署各自版本的部分应用服务。根据请求来源或者请求的头信息，动态地路由到不同版本的服务上。整个过程中，不需要修改应用代码逻辑，只需要针对应用打标，ASM 产品实现了一个 Traffic Label CRD 抽象定义，简化对流量和应用实例打标。应用治理与服务框架融合在遗留的应用系统中，仍然还是实现了类似 Spring Cloud 或者 Dubbo 的服务框架，服务网格 ASM 支持了多模服务治理，实现了调用互通、监控互通、治理互通。通过 MCP over xDS 协议将原有注册中心的服务信息注册到 Service Mesh 中，通过 Service Mesh 控制面组件统一管理规则配置，并以 xDS 协议统一下发管理。云原生应用的零信任安全接下来看云原生应用的零信任安全，包括：零信任的基础 - 工作负载身份零信任的载体 - 安全证书零信任的引擎 - 策略执行零信任的洞察 - 可视化与分析具体来说，构建基于服务网格的零信任安全能力体系包括了以下几个方面：1、零信任的基础 - 工作负载身份，如何为云原生工作负载提供统一的身份：ASM 产品为服务网格下的每一个工作负载提供了简单易用的身份定义，并根据特定场景提供定制机制用于扩展身份构建体系，同时兼容社区 SPIFFE 标准；2、零信任的载体 - 安全证书，ASM 产品提供了如何签发证书以及管理证书的生命周期、轮转等机制，通过 X509 TLS 证书建立身份，每个代理都使用该证书，并提供证书和私钥轮换；3、零信任的引擎 - 策略执行，基于策略的信任引擎是构建零信任的关键核心，ASM 产品除了支持 Istio RBAC 授权策略之外，还提供了基于 OPA 提供更加细粒度的授权策略；同时，支持 dry-run 模式；4、零信任的洞察 - 可视化与分析，ASM 产品提供了可观测机制用于监视策略执行的日志和指标，来判断每一个策略的执行情况等；使用服务网格实现零信任具备如下优势：Sidecar 代理生命周期独立动态配置、无需重启服务网格集中控制，降低开发心智负担加强身份认证授权系统本身安全保障集中管理并下发 OPA 授权策略简化接入第三方授权服务、OIDC 身份认证这是某平台使用网格零信任安全技术的场景。可以看到，客户使用中遵循了零信任安全架构的基本原则：工作负载身份标识服务认证服务授权TLS 加密OPA 策略最小权限访问策略云原生应用的可观测及应用弹性接下来看云原生应用的可观测及应用弹性，包括：网格可观测中心网格诊断网格拓扑网格可观测中心：统一的可观测性体系和联动分析（3 个维度）一是日志分析。通过对数据平面的 AccessLog 采集分析，特别是对入口网关日志的分析，可以分析出服务请求的流量情况、状态码比例等，从而可以进一步优化这些服务间的调用；第二个可观测性能力是分布式追踪能力。为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率；第三个可观测性能力是监控能力。根据监视的四个维度（延迟，流量，错误和饱和度）生成一组服务指标, 来了解、监视网格中服务的行为。网格诊断：检测网格配置的潜在问题及提供改进措施根据我们对 Service Mesh 技术的客户支持和实战经验，在服务网格 ASM 中：内置 30+ 项诊断规则、最佳实践针对每个 Istio 资源对象提供语法的静态检查支持多个 Istio 资源对象的执行语义的动态验证针对诊断出的问题提供相应的改进措施网格拓扑：提供对服务网格行为的即时洞察除了强大的网格流量拓扑可视化之外， 还提供了回放功能可以选定过去时间段的流量。云原生应用的生态引擎接下来看云原生应用的生态引擎，包括 3 个部分：插件市场能力中心新场景定义开箱即用的 EnvoyFilter 插件市场、WebAssembly 插件全生命周期管理基于内置的模板， 用户只需要根据对应的参数要求， 进行简单配置， 就可以部署出对应的 EnvoyFilter 插件。通过这样的机制， 使得数据平面成为更易可扩展的插件集合能力。能力中心:  服务网格与生态系统的集成整合能力围绕服务网格技术, 业界存在着一系列以应用为中心的生态系统。其中, 阿里云托管服务网格 ASM 支持了以下多种生态系统，列举如下。蓝绿发布、 渐进式交付、GitOps、CI/CD支持了与 Argo Rollout、Flagger 以及云效等系统的集成实现了应用的蓝绿或者金丝雀发布微服务框架兼容支持 Spring Boot/Cloud 应用无缝迁移至服务网格进行统一纳管和治理。Serverless支持 Knative 运行于托管的服务网格 ASM 之上, 用于部署和运行 Serverless 工作负载, 并基于服务网格实现了在各个版本之间的流量路由。AI ServingKubeflow Serving 是谷歌牵头发起的一个基于 Kubernetes 支持机器学习的社区项目，它的下一代名称改为 KServe，该项目的目的是可以通过云原生的方式支持不同的机器学习框架，基于服务网格实现流量控制和模型版本的更新及回滚。Policy As CodeOPA（Open Policy Agent）/声明式策略表达语言 Rego：在使用 Kubernetes Network Policy 实现三层网络安全控制之上，服务网格 ASM 提供了包括工作负载身份、对等身份和请求身份认证能力、Istio 授权策略以及更为精细化管理的基于 OPA(Open Policy Agent) 的策略控制能力。一般来说，构建基于服务网格的零信任安全能力体系包括了以下几个方面：零信任的基础 - 工作负载身份，零信任的载体 - 安全证书，零信任的引擎 - 策略执行，零信任的洞察 - 可视化与分析。此外，我们也在探索拓宽服务网格驱动的新场景，我这里举一个 AI Serving 示例。这个需求来源也是来自我们的实际客户，这些客户使用场景就是希望在服务网格技术之上运行 KServe 来实现 AI 服务。KServe 平滑运行于服务网格之上，实现模型服务的蓝/绿和金丝雀部署、修订版本之间的流量分配等能力。支持自动伸缩的 Serverless 推理工作负载部署、支持高可扩展性、基于并发的智能负载路由等能力。云原生基础设施的关键层，企业数字化转型的重要桥梁作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的Istio定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。托管式服务网格 ASM 在成为多种类型计算服务统一管理的基础设施中，提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及基于 WebAssembly 实现统一的代理可扩展能力，以此构筑企业级能力。可以点击文末“此处”查看具体的内容介绍。总结如下，服务网格作为一种用来管理应用服务通信的基础核心技术，为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。可以看到，服务网格加持下的云原生应用基础设施带来了重要的优势，总结为以下六个方面。优势之一：异构服务统一治理多语言多框架的互通与治理、与传统微服务体系融合的双模架构精细化的多协议流量控制、东西向与南北向流量的统一管理统一的异构计算基础设施的自动服务发现优势之二：端到端的可观测日志、监控与跟踪融合的一体化智能运维直观易用的可视化网格拓扑、基于颜色标识的健康识别体系内置最佳实践、自助式网格诊断优势之三：零信任安全端到端 mTLS 加密、基于属性的访问控制 (ABAC)OPA 声明式策略引擎、全局唯一的工作负载身份（Identity）带有仪表板的完整审计历史记录及洞察分析优势之四：软硬结合性能优化首个基于 Intel Multi-Buffer 技术提升 TLS 加解密的服务网格平台NFD 自动探测硬件特征, 自适应支持诸如 AVX 指令集、QAT 加速等特性首批通过可信云服务网格平台以及性能评测先进级认证优势之五：SLO 驱动的应用弹性服务级别目标 (SLO) 策略基于可观测性数据的应用服务的自动弹性伸缩多集群流量突发下的自动切换与故障容灾优势之六：开箱即用扩展 & 生态兼容开箱即用的 EnvoyFilter 插件市场、WebAssembly 插件全生命周期管理与 Proxyless 模式的统一融合，支持 SDK、内核 eBPF 方式兼容 Istio 生态系统，支持 Serverless/Knative，AI Serving/KServe
发表了文章
2022-11-14
甩掉容量规划炸弹：用 AHPA 实现 Kubernetes 智能弹性伸缩
作者：子白AHPA 介绍背景Kubernetes 中应用实例数设置有固定实例数、HPA 和 CronHPA 三种策略。使用最多的是固定实例数，但是很多业务都存在波峰波谷，如果采用固定实例数的方式会造成较大的资源浪费。Kubernetes 中提供了 HPA 及 CronHPA 两种机制实现按需扩容实例数量，减少资源浪费。CronHPA 是用户设定定时规则，在固定时间进行实例数伸缩。但是设定定时规则较为复杂，如果定时间隔设置较大就会造成资源浪费。HPA 可以根据应用实时负载设置实例数量，当应用负载高时扩容，当应用负载低时则缩容实例。HPA 是基于实时负载进行扩容，只有当负载已经比较高时才会触发扩容，但此时业务已经处在高负载中因此业务部分流量出现响应慢或者超时的问题，即存在“弹性滞后”的问题。为此，我们提出了一种智能化弹性伸缩方案 AHPA，可以根据历史时序数据进行主动预测，提前扩容，避免弹性滞后。同时，会根据实时数据动态调整主动预测结果，兼容周期变动等场景。图 1 各种弹性伸缩策略对比图AHPA 架构图 2 AHPA 框架图AHPA 整体架构如图 2 所示，分为数据采集、预测及弹性伸缩三大部分。Data CollectionData Collection 模块负责从数据源收集数据并将数据转为统一的格式传入给 Prediction 模块。数据源支持如 Prometheus、Metrics Serve、Log Service 以及其他自定义的监控平台。指标包含 CPU、Memory、GPU 等资源指标，也包括 QPS、RT 等业务指标，同时也支持其他用户自定义指标。Adapter 模块负责将从多个数据源收集的各类指标转为统一的格式输入给 Prediction 模块。PredictionPrediction 模块负责根据输入指标预测所需的 Pod 数量。Preprocessing 负责数据预处理，如过滤非 Running 状态的 Pod 利用率、处理缺失数据等。完成预处理后将时序数据传递给 RobustScaler[1]算法模块。该模块将在第二部分详细介绍。Revise 模块负责对 RobustScaler 模块给出的预测 Pod 数量进行修正。RobustScaler 分为 Proactive 和 Reactive 两种模式，用户也会为应用 Pod 数量设置上下限。为保证应用平稳运行，我们采取尽快扩，缓慢缩的策略，因此 Revise 模块会取 Proactive、Reactive 及用户设置的上下限中最大值作为预测的 Pod 数量。ScalingScaling 模块负责执行 Pod 扩缩容。弹性伸缩策略分为两类：auto 及 observer 模式。auto：根据 Prediction 给出的 Pod 数量自动调整observer：dryrun 模式，不调整 Pod 数量。用户可以通过这种方式观察 AHPA 工作是否符合预期。 AHPA 部署方式图 3 AHPA 部署图AHPA 在 Kubernetes 中部署图如上所示，分为 AHPA Algorithm 及 AHPA Controller 两部分。AHPA Algorithm Deployment 是负责 AHPA 中算法相关的部分，对应架构图中的 Prediction 模块。AHPA Controller 负责数据收集及弹性扩缩容的执行，对应架构图中的 Data Collection 及 Scaling 模块。AHPA 引入 CRD（CustomResourceDefinition）资源以配置弹性伸缩策略，每个应用（Deployment）对应一个 CRD 资源。使用 CRD 的优势在于可以透出多种算法配置，具有较强的灵活性。CRD 的配置示例如下：apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: AdvancedHorizontalPodAutoscaler
metadata:
name: ahpa-demo
spec:
scaleStrategy: observer
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 40
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
maxReplicas: 100
minReplicas: 2
prediction:
quantile: 95
scaleUpForward: 180
instanceBounds:
- startTime: "2021-12-16 00:00:00"
endTime: "2022-12-16 24:00:00"
bounds:
- cron: "* 0-8 ? * MON-FRI"
maxReplicas: 15
minReplicas: 4
- cron: "* 9-15 ? * MON-FRI"
maxReplicas: 15
minReplicas: 10
- cron: "* 16-23 ? * MON-FRI"
maxReplicas: 20
minReplicas: 15spec.scaleTargetRef 用于指定这个 CRD 资源关联的应用，spec.metrics 用于指定采集的时序指标，spec.scaleStrategy 用于设置弹性策略，包括 auto、observer 模式。spec.prediction字段用于设置算法相关指标。spec.maxReplicas 及 spec.minReplicas 设定了应用的Pod数量的上下界。有些应用存在明显的波峰浪谷，因此需要针对不同时段设置不同的上下界。因此，我们提供了 spec.instanceBounds 可以设置不同时段边界保护，也可以起到定时弹性的作用。具体参数及说明如表 1 所示。表 1 AHPA CRD 核心参数列表及说明高可用性异常在复杂系统中不可避免，因此我们在部署时采用了高可用性架构。Algorithm 与 Controller 组件都采用 Deployment 方式部署，当 Pod 发生异常时会自动杀死异常 Pod 并创建新的 Pod，保证业务平稳运行。当接入的业务应用较多时，Algorithm 及 Controller 均可水平扩展以满足高并发需求。为了保证 AHPA 组件升级过程中业务无感知，Algorithm 和 Controller 组件基于 Service 进行通信，Algorithm 及 Controller 可以独立升级。升级时采用滚动升级方式，即先创建新的 Pod，等待新的 Pod 可以对外提供服务后再杀死旧 Pod。可观测性我们提供了 Kubernetes Event、Prothemetheus、Dashboard 等多种方式透出 AHPA 组件运行状态，方便客户监控 AHPA 运行状态及定位问题。如设置 observer 模式后，用户可以通过查看 Dashboard 预估 AHPA 生效结果。Predict CPU Oberserver：蓝色表示 HPA 实际的 CPU 使用量，绿色表示 AHPA 预测出来的 CPU 使用量。绿色曲线大于蓝色，表明预测的 CPU 容量充足。Predict POD Oberserver：蓝色表示使用 HPA 实际的扩缩容 Pod 数，绿色表示 AHPA 预测出来的扩缩容 Pod 数，绿色曲线小于蓝色，表明预测的 Pod 数量更少。AHPA Algorithm-RobustScaler 算法时序预测是 AHPA 算法的核心能力。现有的时间序列预测算法大致可以分为两大类：统计学算法如 ARIMA、 ETS、 GARCH 等；机器学习算法和深度学习算法如广义线性模型、XGBoost、LSTM、CNN、RNN 等。Kubernetes 中 metrics 数据一般采用 Prometheus 存储，综合效率成本等因素，一般业务数据存储周期为 7 天。7 天数据量作为训练集过小，训练出的机器/深度学习模型准确性较差。AHPA 用于实时弹性扩容，对于预测时延要求较高，统计学算法配置参数少、计算复杂度低、延时低。综合考虑，我们采用了统计学算法进行时序预测。Framework图 4  RobustScaler FrameworkRobustScaler算法框架如图 4 所示。实时指标数据(Real-time metric data)为过去Tmin分钟内的数据，用于被动预测(Proactive Planning)；历史指标数据(Historical metric data)为过去Tday天数据，用于主动预测(Reactive Planning)。Forecasting首先利用 RobustPeriod[2]算法检测数据是否有周期，有几重周期以及每个周期分量的长度。如果数据存在周期性，则调用 RobustSTL[3]算法分解出数据的趋势、周期及残差项；如果数据没有周期性，则调用 RobustTrend[4]算法分解出趋势和残差项。图 5 Forecasing 模块框架图RobustPeriod 利用特殊的小波变换 MODWT 来隔绝多周期之间的相互干扰，从而检测出时序数据中的多周期。RobustSTL 针对周期性数据，首先从时序数据中分解出趋势项，然后分解出周期项，最后根据残差项修正，以上过程多次迭代直至收敛。RobustTrend 算法针对非周期性数据，从时序数据中分解出趋势及残差。Resource ModelResourceModel 模块用于构建资源模型，该模型的输入为指标时序数据，输出为 Pod 数量。模型选用了统计学中的排队论[5]模型。具体的模型与输入的指标有关，单指标一般采用线性模型，多指标时往往采用非线性模型。Proactive planningForecasting 模块使用 RobustSTL 算法将时序数据分解为趋势项，周期项Si,t及残差项Tt, 下一时刻的指标值计算方式如下。主动预测：将历史周期项直接向右平移作为未来周期项的预测，将趋势项用指数平滑等经典的时序模型预测得到未来趋势分量的预测，残差部分利用分位数回归森林得到未来残差的上界预测。Reactive planningForecasting 模块使用 RobustTrend 算法将无周期数据分解为趋势项Tt，残差项rt。当前时刻的指标可以表示为yt=Tt+rt，下一时刻的指标值由最近h分钟指标计算得出，公式如下。其中wi表示i时刻的指标权重，该值由i时刻的指标值及与时刻与i当前时刻差共同决定。模型训练及预测算法使用过程如下。主动预测1. 获取最近Tday天数据2. 对数据进行分析，基于 Forecasting 模块分解出数据周期、趋势及残差。Proactive Planning 模块根据 Forecasting 模块分解出的信息进行预测。预测结果为接下来Thour小时的指标值。3. 根据最近Tday数据构建 Resource Estimation 模型。该模型的输入为第二步预测出的指标值，输出为预期 Pod 数量。被动预测1. 获取最近Tmin分钟数据2. 对数据进行分析，基于 Forecasting 模块分解出数据趋势及残差。Reactive Planning 模块根据 Forecasting 模块分解出的趋势及残差信息预测下一时刻的指标值。3. 将第二步预测出的指标值输入主动预测构建出的 Resource Estimation 模型中，计算下一时刻 Pod 数量。应用扩缩容最终 pod 数量取主动及被动预测的最大值，计算公式如下。算法效果评估AHPA 算法可以帮助客户识别业务是否存在周期性当数据存在周期性时，AHPA 对数据缺失、毛刺以及业务变更引发的数据周期变化等有很强的鲁棒性当数据不存在周期性时，AHPA 因具备一定的预测能力，可以提前感知数据趋势变化；对数据丢失、噪音等有很强的鲁棒性结论极致弹性是云核心优势之一，在云原生时代用户对弹性的诉求也越发强烈。很多用户配置了 HPA 和 CronHPA 策略。HPA 可以根据应用负载更改实例数量，当应用负载较高时扩容更多的实例。CronHPA 是定时 HPA，在固定时间进行实例数伸缩。CronHPA 配置规则复杂，且存在资源浪费，HPA 存在弹性触发滞后的问题，会导致业务稳定性下降。为此，我们提出了一种智能化弹性伸缩组件 AHPA，核心算法使用达摩院决策智能时序团队提供的 RobustScaler，该算法已被数据库顶会 ICDE 2022 录用。RobustScaler 可以自动识别指标数据是否具有周期性，并且在周期变更、毛刺、数据缺失等场景下都具有很强的鲁棒性。AHPA 组件可以在容器服务 ACK 的组件中心里一键安装，安装成功后即可通过 CRD 资源为应用配置弹性伸缩策略，具体请参考官方帮助文档《AHPA 弹性预测》[6]。Reference[1] Qian, H. ,  Wen, Q. ,  Sun, L. ,  Gu, J. ,  Niu, Q. , &  Tang, Z. . (2022). Robu​stscaler: qos-aware autoscaling for complex workloads.  The 38th IEEE International Conference on Data Engineering (ICDE 2022)​[2] Qingsong Wen, Kai He, Liang Sun, Yingying Zhang, Min Ke, and Huan Xu. 2021. RobustPeriod: Robust Time-Frequency Mining for Multiple Periodicity Detection. In Proceedings of the 2021 International Conference on Management of Data (SIGMOD '21).​[3] Qingsong Wen, Jingkun Gao, Xiaomin Song, Liang Sun, Huan Xu, Shenghuo Zhu. (2019). RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series. Proceedings of the AAAI Conference on Artificial Intelligence, 33(01), 5409-5416.[4] Qingsong Wen, Jingkun Gao, Xiaomin Song, Liang Sun, Jian Tan. RobustTrend: A Huber Loss with a Combined First and Second Order Difference Regularization for Time Series Trend Filtering. IJCAI 2019[5] 《运筹学》教材编写组. 运筹学(第三版)[M]. 清华大学出版社, 2005.[6]《AHPA 弹性预测》https://help.aliyun.com/document_detail/416041.html
发表了文章
2022-11-14
合阔智云核心生产系统切换到服务网格 ASM 的落地实践
作者：刘如鸿背景合阔智云(www.hexcloud.cn) 是专注于为大中型零售连锁行业，提供全渠道业务中/前台产品和解决方案，并建立以消费者为中心的全渠道交易和敏捷供应链的新一代零售运营协同平台。合阔智云提供了从全渠道交易管理到订单履约再到门店供应链完整的餐饮零售连锁解决方案，整个方案采取微服务设计，并深度使用了 Kubernetes 作为生产调度平台。技术现状整个业务系统采用微服务架构，但不同业务场景在不同阶段选择了不同的技术语言来开发，如 Python、Golang 和 Java，甚至有部分应用使用了 Nodejs，因为技术栈的缘故，Spring Cloud 或者 Dubbo 这样的全家桶并不适合我们，为了能够适应业务需要，我们选择了下面的策略：不依赖于单一语言和单一技术框架，允许使用更加合适业务的开发语言，如快速业务迭代使用 Python，基础服务和云原生部分使用 Golang，核心的业务系统使用 Java 服务内部使用 gRPC 通信，服务接口定义依赖于 Protobuf 原则上跨服务通信不依赖于消息队列，消息队列只用于服务自身的调度与补偿，这样子降低了消息系统本身的复杂性 所有系统不直接暴露 HTTP，需要提供 HTTP 服务的，使用团队开发的 grpc-proxy 来实现 HTTP to gRPC 的转码代理工作原则上应用只处理业务本身的问题，所有基础架构部分的能力都转由 K8s 来负责，包括：网关服务发现负载均衡指标与监控健康检查故障恢复当前挑战早期所有技术人员只需要专注业务的编写，其他所有的工作全部交给 K8s，在流量比较小业务相对简单的情况下，这个运行非常流畅。然而，随着应用数量的增加，业务变得越加复杂，外部流量也在不断增长，由此带来了应用链路调用更加复杂等新的运维难题：内部调用用的是 gRPC 协议，应用端没有做特别处理，导致基于 HTTP2 的长连接协议无法实现负载均衡，尤其是单一客户端调用变大的情况下，服务端无法有效负载； 因为应用本身比较薄，应用调用链路无法透明化，每次新的发布部署容易出问题。在 2022 年之前，我们使用 Linkerd，初步解决了服务在负载均衡和调用链路上的治理难题，但我们大部分的基础架构都是依赖于阿里云，比如：日志使用 SLS应用监控使用 ARMS链路追踪使用 XTrace仪表盘使用 Grafana容器监控使用 Prometheus为了简化基础架构的复杂性，我们在基础服务上的基本原则是使用云厂商而非自建，而 Linkerd 在实际的使用过程中遇到了一些问题：需要使用自建的基础设施，无法和阿里云提供的基础设施很好的融合应用可观测性比较简单Sidecar 使用默认配置，控制能力相对较少，在应对一些复杂一点的场景，无法做到灵活配置而可观测性是服务网格的基石，在一套自建的基础架构上，我们会偶发的出现链路被熔断、某个端口无法访问的场景，最终的解决方案就是取消注入或者重新注入来解决。基于服务网格 ASM 的探索集群现状我们目前有两个生产集群，合计 150 台 ECS，2500 个 Pod，不同开发语言应用的特点如下：Golang 用于用户基础架构以及计算密集型性的应用系统，总体内存占用不会超过 500M，部分服务会随着临时性的内存而增长，如文件的导入导出服务； Python 用于早期业务敏捷迭代构建的业务系统，都是单进程多线程工作模式，单一 Pod 内存占用不高，但一个 Deploy 需要更多的 ReplicaSet 数量； Java 用于全渠道在线交易业务构建的系统，单一 Pod 需要耗费的资源比较多，但同等情况下单一 Pod 的处理能力比较强。两个集群包括了不同的应用场景：ACK-PROD：早期针对大型客户专有部署的应用集群，每个客户的规模体量比较大，应用资源的隔离通过namespace和调度绑定来隔离； ACK-SAAS：针对 SME/KA 全新开发的 SaaS 平台，所有客户都使用统一的计算资源。调研阿里云服务网格 ASM我们知道， 服务网格作为一种用来管理应用服务通信的基础核心技术,  为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。我们针对开源社区 Istio 和阿里云服务网格 ASM 产品分别进行了调研， 通过试用了解到作为云厂商的产品， ASM 具备了若干生产使用的功能和实战经验，具体来说， ASM 增强了多协议支持以及动态扩展能力，提供精细化服务治理，完善零信任安全体系，并持续提升性能及大规模集群支持能力，降低在生产环境落地服务网格的门槛。商业版适用于有多语言互通，服务精细治理需求，在生产环境大规模使用服务网格的场景。详细的介绍可以参见：https://help.aliyun.com/document_detail/176082.html通过调研， 我们了解到作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。 托管式服务网格 ASM 在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及实现统一的代理可扩展能力, 以此构筑企业级能力。可以通过点击"阅读原文"查看具体的内容介绍。基于上述的调研， 我们决定开始使用阿里云服务网格 ASM 产品进行迁移。迁移到阿里云 ASM第一轮第一次注入：ACK-PROD我们首先将一个足够规模体量的单一客户生产环境（门店供应链）（每天 50 万笔订单，1500 万库存流水）注入 Istio，因为这个环境的使用场景不是全天候的，出现问题会有半个小时的缓冲时间来解决问题，并且应用系统做了完善的自动补偿，确保在出现问题我们取消 Istio 以后业务也能够正常恢复，第一次注入非常成功。第二次注入：ACK-PROD然后我们将另外一个门店供应链的生产环境也做了 Istio 注入，相对于第一个环境，规模体量小一点，但业务环境更加复杂，有更多的应用服务在运行，第二次注入非常成功。第三次注入：ACK-SAAS随着前面两次的成功实践，我们在一个更加重要的实时生产系统（门店全渠道交易）的基础服务部分引入了 Istio，因为这些服务只使用 Golang 编写，都是一些实时处理要求比较高，但业务相对简单的，第三次注入成功。第四次注入：ACK-SAAS我们在生产环境开始注入部分交易链路，注入以后系统生产可用，在第二天高峰期发现了会有部分服务出现 istio-proxy crash 导致应用不可用，从而影响了部分应用的正常运行。鉴于对生产环境的谨慎，我们重新复盘了出现问题的场景，最终得到的结论是：Java 应用的启动对于资源的要求比较苛刻，我们没有提前配置好更加合理的启动参数，将会导致 Java 应用启动缓慢； 检查机制不完善，将会导致流量打给还没有完全准备就绪的服务，此时 K8s 的健康检查机制会在多次没有响应时会再次重启服务； Istio Sidecar 默认的设置也会推慢整个 Pod 的启动时间，之前应用的假设是 15s 内完成启动，随着 Sidecar 代理的注入，有时候会遇到更长的时间； Java 应用提供 gPRC 服务的时候，istio-proxy 会出现某种特殊情况的 Crash，这也是导致生产服务不可用的直接原因。简单而言，在 istio-proxy 存在部分 bug 的情况下，我们的应用的快速启动策略和健康检查机制的不合理，直接导致了注入 Sidecar 代理的部分服务生产不可用。针对这个问题，我们在阿里云工程师的支持之下，在另外一个环境复现并做了改进，主要的改进如下：针对 istio-proxyCRASH 问题，社区已经有了解决方案，在阿里云工程师的支持下，我们升级了 Sidecar，并做了 A/B 测试，确定复现了这个 Crash 的场景； 针对 Java 应用一开始分配更多的CPU资源来加快 Java 应用启动，在测试过程中，如果默认分配 0.2 调整到 1.5，启动时间最长的会从 6 分钟减少到 40 秒； 调整 Sidecar 配置，根据应用优化 istio-proxy 的启动速度；第二轮在方案得到确认以后，我们开始了第二轮的 Istio 升级。第一次注入：ACK-SAAS我们将 SaaS 的供应链业务注入 Istio，除了升级过程中遇到部分服务资源不足的问题，其他都非常顺利；第二次注入：ACK-SAAS-QA我们在测试环境复现了启动速度慢的问题，并通过更加合理的启动参数配置验证了在 CPU 初始化申请对于 Java 应用的影响；第三次注入：ACK-SAAS-QAA/B 测试 Istio crash 场景，确认新的 Sidecar 已经修复这个问题；第四次注入：ACK-SAAS正式完成全渠道交易的 Istio 生产注入；第五次注入：ACK-SAAS将剩余的应用全部完成注入。 此外，服务网格 ASM 相比社区 Istio 能够实现更加丰富的能力，如流量标签、配置推送优化等能力。在实际的应用场景中，我们充分利用配置推送优化能力。在默认情况下，由于无法确定数据平面内所有工作负载与服务之间的关系，服务网格数据平面内的所有 Sidecar 都必须保存数据平面集群内所有服务信息的全量配置。同时，一次针对控制平面或数据平面的修改（例如在控制平面新建一条虚拟服务规则），都会导致控制平面向数据平面的所有 Sidecar 推送新的配置。而在我们的数据平面 Kubernetes 集群中的工作负载数量比较多， 默认情况下会增加 Sidecar 对数据平面集群的资源消耗，同时控制平面会面临较大的配置推送负担，降低控制平面的效率与可用性。ASM 提供了选择性服务发现和 Sidecar 资源推荐功能，帮助优化配置推送效率。 服务网格 ASM 可以通过分析数据平面 Sidecar 产生的访问日志获取数据平面服务之间的调用依赖关系，为数据平面中的每个工作负载自动推荐 Sidecar 资源。为工作负载推荐 Sidecar 资源后：Sidecar 配置内将仅保留该 Sidecar 对应工作负载所依赖的服务信息。 当该 Sidecar 资源对应的工作负载无依赖关系的服务发生改变，或与该服务相关的资源发生改变（例如虚拟服务等），都不会引起控制平面向该 Sidecar 的配置推送。服务网格ASM  通过访问日志分析自动推荐 Sidecar CR 经过优化后， Sidecar 配置大小从原来的 40 多M减少为 5M, 控制面配置推送时间也随之大大减少。总之， 经过一个多月的反复测试和确认，我们终于完成了基于服务网格 ASM 的核心生产系统切换，相对于之前的服务网格方案，给我们带来了很多益处。方案优势及进展规划完备的可观测性以及应用监控通过服务网格对应的控制面盘，我们发现了很多之前应用本身的问题，比如：不合理的应用补偿策略不合理的应用部署（比如把大数据查询和应用处理放在同一个服务）不合理的应用报错...而这些问题随着服务网格的上线，我们变得一清二楚，进而非常方便的推动应用架构的改造。流量与资源的均衡这是我们上线服务网格的初衷，随着我们将所有应用放到服务网格，我们真正做到了在 CPU、内存、网络利用率的均衡，通过通过应用调用的监控来看，所有请求数量和错误也非常均衡的分配在不同的 Pod 上，不用再去担心随着流量的增长因为负载不均衡而导致横向扩展失效更加强大的流量治理能力在没有 Istio 之前，我们基于自身业务需要做了一些“手工”的流量治理工作，比如：东西流量：基于基于租户与门店的流量隔离，允许我们可以允许需要针对某一个租户某一个门店发布指定服务南北流量：针对业务场景进行灰度测试，比如某一个租户的美团订单处理使用新的接单服务为某个租户提供自定义域名...这些工作都是基于 K8s CRD 构建的，随着服务网格的上线，我们发现 Istio 可以帮助我们实现更多，比如灰度发布、熔断、限流、流量标签等。这些能力将在未来持续不断提升我们线上业务的稳定性。
发表了文章
2022-11-14
让数据流动起来，RocketMQ Connect 技术架构解析
作者：周波Why RocketMQ Connect在业务系统，或者大数据系统中不同数据源之间的数据同步是十分常见的，传统的点对点的数据同步工具，在面临越来越多的数据源点对点的数据同步会产生 N*N 的问题，开发成本，维护成本都是非常高的，因为上下游是耦合的，一个数据源的逻辑调整，也可能会影响多个数据管道之间的数据同步。引入消息中间件将上下游解耦这些问题是不是就迎刃而解了？通过消息中间件上下游的数据源的处理逻辑相对独立，但是如果我们直接用 RocketMQ 的生产者消费者来构建数据管道还需要考虑以下挑战。1. 异构数据源越来越多，如何实现任意数据源的数据同步?2. 高性能，如何高效的在源数据源到目的数据源的数据同步？3. 高可用，故障处理能力，当一个节点挂掉是否这个节点的任务就停止了，任务重新启动是否还可以断点续传。4. 弹性扩缩容，是否可以根据系统数据的变动动态的增加减少节点？5. 集群监控，运维管理，随着数据管道的增多，如何管理，运维监控这些数据管道也变的越来越复杂。我们通过 RocketMQ 的生产者消费者开发一个完整的数据管道是比较简单的，可能几天就可以完成，但是如果想一起解决上述这些问题可能需要几个月才能完成，而且一旦我们完成了这样一个系统，就会发现，它与 RocketMQ Connect 是一个非常类似的系统，而上述这些问题是 RocketMQ Connect 都已经完美解决的问题。下面将系统化的介绍一下 RocketMQ Connect 是如何解决这些问题的。RocketMQ Connect 介绍什么是 RocketMQ ConnectRocketMQ Connect 是 RocketMQ 数据集成重要组件，可将各种系统中的数据通过高效，可靠，流的方式，流入流出到 RocketMQ，它是独立于 RocketMQ 的一个单独的分布式，可扩展，可容错系统，它具备低延时，高靠性，高性能，低代码，扩展性强等特点，可以实现各种异构数据系统的连接，构建数据管道，ETL，CDC，数据湖等能力。RocketMQ Connect 具备以下优势：1. 上下游解耦，因为上下游都是通过 RocketMQ 做数据中转的，所以上下游系统是异步解耦的，上下游系统变化不会互相影响，只需要关注与 RocketMQ 的数据同步。2. 低延迟，流式数据传输，秒级甚至毫秒级延迟。3. 可靠性高，集群部署，支持 failover，数据可回放。4. 扩展性强，通过 Connect API 可以实现与任意系统之间建立连接。5. 实现简单，专注数据拷贝，无需关注分布式，故障转移、弹性伸缩等能力。6. 可伸缩，支持动态扩缩容。7. 配置化，低代码，已经支持的数据源只需简单配置就可完成不同数据源之间的，不支持的数据源，只需要实现 Connect API 专注数据拷贝即可快速完成新的数据源的支持。Connector 工作原理 RocketMQ Connect 是一个独立的的分布式，可伸缩，容错的系统，它主要为 RocketMQ 提供与各种外部系统的数据的流入流出能力。用户不需要编程，只需要简单的配置即可使用 RocketMQ Connect，例如从 MySQL 同步数据到 RocketMQ，只需要配置同步所需的 MySQL 的账号密码，链接地址，和需要同步的数据库，表名就可以了。Connector的使用场景构建流式数据管道在业务系统中，利用 MySQL 完善的事务支持，处理数据的增删改，使用 ElasticSearch，Solr 等实现强大的搜索能力,或者将产生的业务数据同步到数据分析系统，数据湖中（例如 Hudi），对数据进一步处理从而让数据产生更高的价值。使用 RocketMQ Connect 很容易实现这样的数据管道的能力，只需要配置 3 个任务，第一个从 MySQL 获取数据的任务，第二、三个是从 RocketMQ 消费数据到 ElasticSearch、Hudi 的任务，配置这 3 个任务就实现了从 MySQL 到 ElasticSearch，MySQL 到 Hudi 的两条数据管道，既可以满足业务中事务的需求，搜索的需求，又可以构建数据湖。1. 系统迁移随着业务的发展，往往会对旧的系统进行系统优化，甚至重构，在新的系统中可能选用新的组件，新的技术框架，旧的系统又无法直接停机将数据迁移到新系统。如何动态的将数据从旧存储系统迁移到新的存储系统，例如旧的系统使用的是 ActiveMQ，新的系统选用了 RocketMQ，只需要配置一个从 ActiveMQ 到 RocketMQ 的 Connector 任务即可实时的将旧系统的数据迁移到新系统，实现旧系统的 ActiveMQ 上的数据迁移到新系统 RocketMQ 中，同时也不影响业务，用户无感知。2. CDC图片来源：https://luminousmen.com/post/change-data-captureCDC 作为 ETL 模式之一，可以通过近乎实时的增量捕获数据库的 INSERT、UPDATE，DELETE 变化，RocketMQ Connect 流式数据传输，具备高可用，低延时等特性，通过 Connector 很容易实现 CDC。数据的序列化与转换前面对 RoketMQ Connect 已经有了基本的介绍，知道 RocketMQ Connect 可以实现很多数据源之间的数据同步，那么这些数据在 RocketMQ Connect 中是如何流转和处理的呢？Converter 和 Transform在数据的序列化和转换有十分重要的作用，下面介绍下 Converter 和 Transform。Converter 和 Transform 和 Connector 一样都属于 RocketMQ Connect 的插件，可以使用 RocketMQ Connect 内置的实现，也可以自定义实现个性化的处理逻辑，通过 RocketMQ Connect Worker 插件加载能力可以将自定义实现加载到 Worker 运行时中，通过简单的配置既可以使用自定义的插件。Converter：转换器，主要负载数据的序列化和反序列化。Converter 可以将数据和数据的 Schema 进行转换并且完成序列化，还可以与Schema Registry配合，将 Schema 注册到 Schema Register 中。Transform：单消息转换，对 Connect 数据对象进行转换，例如过滤掉不需要的数据, 字段过滤，替换数据 Key，大小写转换等，都可以通过 Transform 进行转换。Connector 的数据处理的基本流程，Source Connect 从源数据系统获取数据封装成 Connect 标准的数据对象，然后经过 Transform 对单条数据进行转换，转换后的数据会经过 Converter，Converter 会将数据和 Schema 处理成支持的格式并进行序列化，如果是支持 Schema Registry，Converter 会将数据的 Schema 注册到 Schema Registry 中，然后序列化数据，最后将序列化后的数据发送到 RocketMQ 中。Sink Connect 处理流程是从 RocketMQ Topic 拉取数据，经过数据的反序列化，然后对每条消息进行转换，如果配置了 Transform，最后 Connector 将数据写入到目标存储。RESTful 接口Connector Worker 节点提供了 RESTful 接口方便 Connector 的创建，停止，配置信息获取接口，使用这些接口可以很方便的管理 Connector，只需要调用对应的接口带上对应的配置即可，下面介绍一些常用的接口。•POST /connectors/{connector name}•GET /connectors/{connector name}/config•GET /connectors/{connector name}/status•POST /connectors/{connector name}/stop通过这些 API 即可向 Connect Worker 创建 Connector，停止 Connector，查询 Connector 的配置和状态。Metrics可观测性在许多系统中都扮演着非常重要的作用，它可以帮助观察系统运行情况，系统是否正常运行，系统的高峰期，空闲期是在什么时候，帮助对系统进行监控问题定位等等。Worker 提供了丰富的 Metrics 信息，可以通过 Metrics 观察到所有 Worker 总的 tps，消息数量，还可以观察到每个 task 的 tps，成功处理的数量和处理失败的数量等等，通过这些 Metrics 信息可以很方便的运维 Connector。将 Metrics 信息展示在 Prometheus 中是很多系统的选择，Prometheus 也提供了接入方式，通过实现一个 Prometheus Exporter 即可，新增或者修改 Metrics 修改这个 Exporter 即可，这是一种将 Metrics 接入 Prometheus 的方式。通过 RocketMQ Connect 可以提供一种新的接入方式，实现一个通用的 Sink Prometheus Connector，Source Connector 是获取 Metrics 所需的 Connector，例如 RocketMQ 和 RocketMQ Connect 的 Metrics 信息都写在了文件里，那么获取 Metrics 的 Connector 就是 SFTP Source Connector，这样就可以将 Metrics 信息通过 Connector 的方式接入 Prometheus。Connector 数据质量RocketMQ Connect 和 RocketMQ 一样，实现了 at least once 的语义，即保障至少一次。Source Connector 发送消息到 RocketMQ 失败，producer 会重试，如果重试失败，可以选择跳过，还是停止任务，可以通过配置进行选择。Sink Connector 拉取消息同样会重试，并且在重试达到一定次数时会将消息发送到死信队列，进而保障消息不丢失。Connector 部署在创建 Connector 时，一般是通过配置完成的，Connector 一般包含逻辑的 Connector 连接器和执行数据复制的 Task 即物理线程，如下图所示，两个 Connector 连接器和它们对应的运行 Task 任务。一个 Connector 也可以同时运行多个任务，提高 Connector 的并行度，例如下图所示的 Hudi Sink Connector 有 2 个任务，每个任务处理不同的分片数据，从而增加 Connector 的并行度，进而提高处理性能。RocketMQ Connect Worker 支持两种运行模式，集群和单机集群模式，顾名思义，有多个 Worker 节点组成，推荐最少有 2 个 Worker 节点，组成高可用集群。集群间的配置信息，offset 信息，status 信息通过指定 RocketMQ Topic 存储，新增 Worker 节点也会获取到集群中的这些配置，offset，status 信息，并且触发负载均衡，重新分配集群中的任务，使集群达到均衡的状态，减少 Woker 节点或者 Worker 宕机也会触发负载均衡，从而保障集群中所有的任务都可以均衡的在集群中存活的节点中正常运行。单机模式，Connector 任务运行在单机上，Worker 本身没有高可用，任务 offset 信息持久化在本地。适合一些对高可没有什么要求或者不需要 Worker 保障高可用的场景，例如部署在 K8s 集群中，由 K8s 集群保障高可用。Connector 原理概念Connector 连接器，定义数据从哪复制到哪，是从源数据系统读取数据写入 RocketMQ，这种是 SourceConnector，或从 RocketMQ 读数据写入到目标系统,这种是 SinkConnector。Connector 决定需要创建任务的数量，从Worker 接收配置传递给任务。Task 是 Connector 任务分片的最小分配单位，是实际将源数据源数据复制数据到RocketMQ（SourceTask），或者将数据从 RocketMQ 读取数据写入到目标系统（SinkTask）真正的执行者，Task 是无状态的可以动态的启停任务，多个 Task 是可以并行执行的，Connector 复制数据的并行度主要体现在 Task 数量上。通过 Connect 的 API 也可以看到 Connector 和 Task 各自的职责，Connector 实现时就已经确定数据复制的流向，Connector 接收数据源相关的配置，taskClass 获取需要创建的任务类型，通过 taskConfigs 指定最大任务数量，并且为 Task 分配好配置。Task 拿到配置以后从数据源取数据写入到目标存储。通过下面的两张图可以清楚的看到，Connector 和 Task 处理基本流程。Worker Worker 进程是 Connector 和 Task 运行环境，它提供 RESTful 能力，接受 HTTP 请求，将获取到的配置传递给 Connector 和 Task。除此之外它还负责启动 Connector 和 Task，保存 Connector 配置信息，保存 Task 同步数据的位点信息，负载均衡能力，Connect 集群高可用，扩缩容，故障处理主要依赖 Worker 的负责均衡能力实现的。从上面这张图，看到 Worker 通过提供的 REST API 接收 http 请求，将接收到的配置信息传递给配置管理服务，配置管理服务将配置保存到本地并同步给其它 Worker 节点，同时触发负载均衡。从下面这张图可以看到 Connect 集群中多个 Worker 节点负载均衡后在各自节点启动 Connector 和 Task 的情况。Worker集群的服务发现学习和使用 RocketMQ 的时候，我们知道 NameSrv 是 RocketMQ 服务注册与发现的重要组件，具备简单轻量易运维等特性。通过前面 Connector 部署方式的介绍，RocketMQ Connect Worker 是可以集群方式部署的，那么 Worker 节点之间的服务发现是如何实现的呢？Worker 的服务发现是否依赖外部组件?在使用一项技术或者中间件的时候，尽量少的依赖额外的组件，这对系统的稳定性，可维护性都非常重要，学习成本也会低一些，这也很容易理解，如果多依赖一个组件，就需要多维护一个，学习成本和后期维护成本就会越高。RocketMQ Connect 也是这个原则，尽量少或者不依赖额外的外部组件。通过前面对 RocketMQ Connect 的介绍我们知道 RocketMQ Connect 是 RocketMQ 数据集成，数据流入流出的重要组件，所以 RocketMQ Connect 的运行是依赖一个 RocketMQ 集群的，能否利用RocketMQ的特性实现 Worker 的服务发现呢？答案是肯定的。通过 RocketMQ 客户端有消费客户端变化通知机制，只需要在每个 Worker 启动一个消费者，设置相同的 ConsumerGroup，注册监听 NOTIFY_CONSUMER_IDS_CHANGED 事件即可，增加或减少 Worker 节点就会触发 NOTIFY_CONSUMER_IDS_CHANGED 事件，监听到这个事件就可以触发 Worker 集群的负责均衡，通过 RocketMQ 客户端接口既可以获取所有 Worker 对应的客户端标识，最后根据在线的客户端和任务进行负载均衡。配置同步Topic 的订阅消费分为两种，集群消费，广播消费，不过不同的客户端使用不同的 ConsumerGroup 也可以达到广播消费的目的，RocketMQ Connect Worker 之间元数据的同步就是根据这种原理实现的。所有的 Worker 节点订阅相同的 Topic（connector-config-topic），每个 Worker 节点使用不同的 consumerGroup，这样就可以实现广播的方式消费同一个 Topic，每个 Worker 节点只需要配置发生变化时向 connector-config-topic 发送配置信息，即可实现各个 Worker 节点间的配置同步。位点同步位点同步与配置同步类似只是使用的是不同的 Topic 和 consumerGroup服务发现与配置/位点管理：Connector 配置管理和 Task 任务的位点管理是类似的，除了需要将配置和位点信息持久化到本地，还会将配置和位点信息同步给集群的其它 Worker 节点，这个同步方式也是通过所有 Worker 节点订阅相同的 Topic，使用不同的 consumerGroup 实现的。负载均衡Connect 的负载均衡和 RocketMQ 消费端负载均衡是类似的。都是在每个节点上运行相同的负载均衡算法，只不过负载均衡的对象不一样，RocketMQ 消费端负载均衡是相同 ConsumerGroup 消费端与 MessageQueue 之间负载均衡，Connect 是 Worker 节点与 Connector，Worker 节点与 Task 之间的负载均衡，不过逻辑是类似的，负载均衡算法获取到所有 Worker 和所有的 Connector，Task，并对这些信息排序，根据当前 Worker 节点在排序中所有 Worker 的位置，排序后的 Connector，Task 位置与当前的 Worker 位置取模，就可以为当前 Worker 节点分配好需要运行那些 Connector 和那些 Task，然后 Worker 在本节点启动这些 Connector 和 Task。Worker 扩缩容，Worker 宕机，新增 Connector 配置都会触发重新分配，因此 Worker 集群是弹性的可以故障处理，动态扩缩容的。Connector插件加载Worker 加载 Connector 插件 jar 包类似于 Tomcat 加载 War 包。Tomcat 加载 War 包并不会像 jvm 加载类一样使用双亲委派模型对类进行加载，而是使用自定义的 ClassLoader 加载类，使用不同的 ClassLoader 加载不同的 War 包的不同的类。这样可以避免不同的 War 包中引用相同的 jar 包因为版本的不同各种包引用问题，Worker 也是一样，在加载不同的类插件时为其创建单独的 ClassLoader，从而避免相同的类，因为不同 War 包引用相同 jar，并且版本不同而导致的各种包引用问题，在类加载方面 Worker 像一个分布式的 Tomcat。动手实现 Connector了解了 RocketMQ Connect 的实现原理，下面看一下如何自己实现一个 Connector。看下面这个场景：业务数据写入到 MySQL，然后同步到 Hudi，通过 Hudi 构建数据湖，这个跟我们开头讲到的场景比较相似。通过 Connector 如何实现这个流程?通过前面的介绍，应该清楚，需要实现两个 Connector，一个是从 MySQL 到 RocketMQ 的 SourceConnector，第二个是从 RocketMQ 读数据写入到 Hudi 的 Sink Connector。以 MySqlSourceConnector 为例介绍如何自己写一个 Connector。首先要实现一个 SourceConnector，实现类 MySqlConnectorImpl 继承 SourceConnector 接口,实现配置初始化，taskClass，taskConfigs 等接口。taskClass 方法指定创建 MySqlTask，taskConfigs 将接收到的 Connector 配置并分好每个 Task 配置，这些配置包含连接 MySql 实例相关的账号，密码，address，port 等。Worker 启动 MySqlTask 并将配置传给 MySqlTask，MySqlTask 创建到 MySql 实例的链接并获取 MySql Binlog，解析 Binlog，并将解析的数据封装成 ConnectRecord 放到 BlockingQueue，poll 接口从 BlockingQueue 中取数据返回。这样就实现了一个 Connector。将写好的 Connector 打包放到 Worker 指定目录加载到 Worker 进程，通过请求 Worker http 接口创建 MySqlSourceConnector。Worker 启动 MysqlConnector，通过 MySqlConnector taskClass 获取 MySqlTask 并启动 Task，WorkerSourceTask 从 poll 接口获取数据，然后把获取到的数据通过 Producer 发送到 RocketMQ，这样就完成了 MySql 到 RocketMQ 的数据同步的 Connector。Connector 现状与未来CDC 方面已与 debezium 完成适配，jdbc 标准协议也已支持并且在此基础上与 openmldb 社区合作开发了与面向机器学习数据库 openmldb 的 Connector，数据湖方面与 Hudi 也建立了链接，不久的将来还会与 Doris，clickhouse，es 等流行的存储建立连接，如果有熟悉的的存储，每个人都可以通过 OpenMessaging Connect API 开发一个 RocketMQ 连接器。提到 OpenMessaging Connect API，简单介绍一下 OpenMessaging，OpenMessaging 是 Linux 基金会下一个开源组织，致力于制定消息领域的标准，除了 OpenMessaging Connect Api 还有存储方面的标准 OMOI，压测方面的标准 OMBI，流计算方面的标准 OMS 等等。Connector TutorialQuickStarthttps://github.com/apache/rocketmq-connectRocketMQ Connect & OpenMLDBOpenMLDB 是一个开源机器学习数据库，提供线上线下一致的生产级特征平台。通过与 OpenMLDB 社区合作，RocketMQ 与机器学习数据库 OpenMLDB 建立连接。RocketMQ Connect & Debeziumhttps://mp.weixin.qq.com/s/YNjylhmo1IlvAEKwpjjMkg总结本文介绍了 RocketMQ Connect 的概念，然后讲解了 RocketMQ Connect 的实现原理，对服务发现，配置同步，位点同步，负载均衡都有了初步的介绍，接着以 MySqlSourceConnector 为例讲解了如何自己实现一个 Connector，最后对 Connect API 和生态做了一些介绍，提供了一些 RocketMQ Connect 相关的上手教程，希望本文对学习 RocketMQ Connect 有帮助，更希望感兴趣的同学能参与进来一起贡献社区，实现一个自己熟悉的存储系统到 RocketMQ 的 Connector。作者介绍：周波，阿里云智能高级开发工程师， Apache RocketMQ Committer 。参考链接：rocketmq-connecthttps://github.com/apache/rocketmq-connectapihttps://github.com/openmessaging/openconnect加入 Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献，相信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅可以结识社区大牛，提升技术水平，也可以提升个人影响力，促进自身成长。社区 5.0 版本正在进行着如火如荼的开发，另外还有接近 30 个 SIG（兴趣小组）等你加入，欢迎立志打造世界级分布式系统的同学加入社区，添加社区开发者微信：rocketmq666 即可进群，参与贡献，打造下一代消息、事件、流融合处理平台。加入钉钉群与 RocketMQ 爱好者一起广泛讨论：
发表了文章
2022-11-11
云原生可观测套件：构建无处不在的可观测基础设施
Gartner：可观测性成为数据驱动型决策最强支撑近日，全球权威 IT 研究与顾问咨询公司 Gartner 发布《2023 年十大战略技术趋势》报告。报告围绕优化、扩展和开拓三大主题展开，「应用可观测性」再次成为其中热门趋势之一。Gartner 杰出研究副总裁 Frances Karamouzis 表示：“为增加盈利，企业 IT 高管在持续加快数字化转型的同时，需将目光从节约成本转向新的卓越运维方式。，可观测性以高度统筹与整合的方式将用户数字化操作所产生的可观测数据进行反馈并创造决策循环，提高组织决策有效性。如能在战略中予以规划并执行，可观测性将成为数据驱动型决策的最强支撑。”但伴随着 IT 技术高速发展，企业在落地可观测过程中必然遭遇三大阻隘。首先，蓬勃发展的开源/商业可观测产品生态与逐渐无法满足云原生 IT 运维需求的传统企业监控体系，造成新老工具、数据与工具的割裂。 如何选择与平衡成为CTO、CIO 必须面对的选择题。其次，当微服务架构以及分布式架构被越来越多应用于企业业务，以日志为例的典型可观测数据，计算成本与存储成本以指数级增长。在行业形势愈发严峻的当下，可观测成本投入高昂且难以预估，应用场景往往停留在单点排查或基础监控告警上，大张旗鼓的落地可观测基础设施，回报价值未知。以上几点，这都难以说服CTO、CIO们投入愈发吃紧的运维预算与人力进行可观测性建设。为解决以上难题，深耕可观测领域的阿里云于今年6月推出阿里云云原生可观测套件ACOS，该产品套件由阿里云 Prometheus 服务、阿里云 Grafana 服务、链路追踪 OpenTelemetry组成，这三款开源流行度最高、生态集成最广的事实标准是云原生可观测套件ACOS的“核心”，旨在通过开放标准打通所有阿里云可观测产品实现全链路数据标准化，并连接企业存量可观测数据资产，与阿里云应用托管平台集成。全面覆盖用户体验（UEM）、应用观测（APM)、云服务观测、成本管理、应急协同效率等场景。帮助企业高效构建开放、高质量、低成本的统一可观测体系。云原生可观测 ACOS 的独特价值相较于其他可观测商业化或开源解决方案，云原生可观测套件在采集、存储、计算、告警、查询、可视化六大环节做到与开源标准的全面兼容与优化提升。同时，将阿里巴巴集团以及阿里云服务海量用户的可观测经验进行产品化输出。这包含超过 50 款阿里云主流云服务的运行指标、大盘和告警规则预置模板。从基础设施到容器，从应用到用户体验，从成本分析到运维效能分析，在接入第一天就做到全链路高质量观测。自发布以来，众多行业客户借助阿里云原生可观测套件 ACOS 快速构建统一可观测体系。以友邦人寿为例，友邦人寿对应用进行容器化、微服务化改造，以适应业务与性能要求。但随着访问链路与部署复杂度提升，观测微服务和 K8s 运行，并构建全栈可观测能力成为巨大挑战。借助 ACOS，友邦人寿将可观测性覆盖研发生产全周期，将研发态与运维态指标关联与展现，从而有效度量研发效率。同时，将多容器集群及应用服务的观测进行统一，将应用性能指标、全局调用链、日志相融进行快速根因定位的同时，形成指挥决策、仪表盘展示、告警推送的多维度观测能力，大幅提升运维服务效率。云原生可观测 ACOS 焕新升级本次云栖大会，阿里云云原生可观测套件 ACOS 三大组件也迎来重要升级。首先，作为容器观测事实标准的阿里云 Prometheus 监控，观测范围从专精容器延伸到全栈可观测。为了帮助更多企业构建统一观测体系，Prometheus 监控已成为阿里云 50+款云产品默认观测基础设施，并与应用实时监控服务 ARMS 的 APM 指标、eBPF 指标、OpenTelemetry 指标联通，以及将企业的 ECS（非 K8s 集群）、K8s 集群、非阿里云集群进行 Prometheus 实例聚合，帮助企业一键开启全球与异构架构下的统一可观测中心。在服务外部客户同时，阿里云 Prometheus 监控不断通过内部场景进行打磨，目前已能够支持千万核的容器观测及数十亿级别时间线的时序存算能力。对于时序监控场景的核心技术难点，如海量动态监控对象采集能力、高基数时间线发散收敛、长周期查询、突发流量下误报漏报等场景进行针对性优化，使得阿里云 Prometheus 监控真正成为无处不在，大规模生产可用的可观测基础设施。在赋予企业强大观测能力的同时，Prometheus 推出全新包年包月计费形式，同等业务规模下，平均相较于自建成本降低 60%。满足不同业务规模用户的观测需求，并尽可能减轻企业的运维成本压力。其次，作为观测界面的阿里云 Grafana 服务也将迎来 9.0 焕新升级。全新的 Prometheus 和 Loki 查询语句生成器及强化后的搜索 Explore 功能，让用户获得更强的数据查询与分析能力，更低门槛的创建可视化大盘与告警。同时，为了应对越来越丰富的异构可观测数据源，Grafana 服务与日志服务 SLS、Elasticsearch 等 20+款可观测存储服务集成，帮助企业更简单的构建统一「运维&业务」观测界面。一键导入/导出自建实例、自动数据导出报表，一键数据备份、恢复，用户操作审计等企业特性进一步增强。最后，为了帮助企业的云上应用开启多维度观测视角，应用实时监控服务 ARMS 也迎来巨大升级。在数据采集方面，在完整支持 Opentelemetry SDK 的同时，指标数据可完全通过与 Prometheus 标准进行存储与计算，补充业务、自定义组件埋点。在完善观测维度的同时，避免厂商锁定。并借助 TraceExplorer 实现多来源 Trace 统一查询。与此同时，eBPF 技术以及 Continuous Profiling 作为目前可观测领域最为热门的细分领域，阿里云可观测团队也进行积极探索。本次大会阿里云可观测团队开放基于 eBPF 技术的“轻量版应用监控”预览，帮助企业快速获得无侵入、全语言的应用监控能力，并及时感知集群全局拓扑结构。同时，与 Alibaba Dragonwell 团队联合推出 Continuous Profiling 功能，能够以极低功耗持续分析代码级别的性能开销，覆盖传统链路、指标和日志覆盖不到的细节，实现代码级生产环境性能问题定位及全天候主动剖析，让应用观测视角更丰富，观测颗粒度更细致。在不断探索更多可观测场景服务阿里巴巴集团以及海量企业用户的同时，阿里云可观测凭借其完备的产品能力与良好的生态集成能力及出色的成本优势，收获了国内外行业机构的高度认可。阿里云应用实时监控服务 ARMS 在今年获得中国信通院首批可观测产品先进级认证。同时，阿里云连续两年进入 Gartner APM 与可观测魔力象限，今年更是成为唯一入选的中国厂商。万物皆云的时代，可观测性让云计算更易用高效，最大程度释放业务稳定性、安全性、经济性价值。“观测力”已成为每个 IT 人的必备核心竞争力。不止于观测，可观测帮助企业分析、洞察并实现高质量的决策与业务创新。而阿里云将不断推动可观测技术演进与落地实践，帮助企业获得最具性价比的可观测性，真正实现高质量数字化转型与创新。
发表了文章
2022-11-11
云原生可观测套件：构建无处不在的可观测基础设施
Gartner：可观测性成为数据驱动型决策最强支撑近日，全球权威 IT 研究与顾问咨询公司 Gartner 发布《2023 年十大战略技术趋势》报告。报告围绕优化、扩展和开拓三大主题展开，「应用可观测性」再次成为其中热门趋势之一。Gartner 杰出研究副总裁 Frances Karamouzis 表示：“为增加盈利，企业 IT 高管在持续加快数字化转型的同时，需将目光从节约成本转向新的卓越运维方式。，可观测性以高度统筹与整合的方式将用户数字化操作所产生的可观测数据进行反馈并创造决策循环，提高组织决策有效性。如能在战略中予以规划并执行，可观测性将成为数据驱动型决策的最强支撑。”但伴随着 IT 技术高速发展，企业在落地可观测过程中必然遭遇三大阻隘。首先，蓬勃发展的开源/商业可观测产品生态与逐渐无法满足云原生 IT 运维需求的传统企业监控体系，造成新老工具、数据与工具的割裂。 如何选择与平衡成为CTO、CIO 必须面对的选择题。其次，当微服务架构以及分布式架构被越来越多应用于企业业务，以日志为例的典型可观测数据，计算成本与存储成本以指数级增长。在行业形势愈发严峻的当下，可观测成本投入高昂且难以预估，应用场景往往停留在单点排查或基础监控告警上，大张旗鼓的落地可观测基础设施，回报价值未知。以上几点，这都难以说服CTO、CIO们投入愈发吃紧的运维预算与人力进行可观测性建设。为解决以上难题，深耕可观测领域的阿里云于今年6月推出阿里云云原生可观测套件ACOS，该产品套件由阿里云 Prometheus 服务、阿里云 Grafana 服务、链路追踪 OpenTelemetry组成，这三款开源流行度最高、生态集成最广的事实标准是云原生可观测套件ACOS的“核心”，旨在通过开放标准打通所有阿里云可观测产品实现全链路数据标准化，并连接企业存量可观测数据资产，与阿里云应用托管平台集成。全面覆盖用户体验（UEM）、应用观测（APM)、云服务观测、成本管理、应急协同效率等场景。帮助企业高效构建开放、高质量、低成本的统一可观测体系。云原生可观测 ACOS 的独特价值相较于其他可观测商业化或开源解决方案，云原生可观测套件在采集、存储、计算、告警、查询、可视化六大环节做到与开源标准的全面兼容与优化提升。同时，将阿里巴巴集团以及阿里云服务海量用户的可观测经验进行产品化输出。这包含超过 50 款阿里云主流云服务的运行指标、大盘和告警规则预置模板。从基础设施到容器，从应用到用户体验，从成本分析到运维效能分析，在接入第一天就做到全链路高质量观测。自发布以来，众多行业客户借助阿里云原生可观测套件 ACOS 快速构建统一可观测体系。以友邦人寿为例，友邦人寿对应用进行容器化、微服务化改造，以适应业务与性能要求。但随着访问链路与部署复杂度提升，观测微服务和 K8s 运行，并构建全栈可观测能力成为巨大挑战。借助 ACOS，友邦人寿将可观测性覆盖研发生产全周期，将研发态与运维态指标关联与展现，从而有效度量研发效率。同时，将多容器集群及应用服务的观测进行统一，将应用性能指标、全局调用链、日志相融进行快速根因定位的同时，形成指挥决策、仪表盘展示、告警推送的多维度观测能力，大幅提升运维服务效率。云原生可观测 ACOS 焕新升级本次云栖大会，阿里云云原生可观测套件 ACOS 三大组件也迎来重要升级。首先，作为容器观测事实标准的阿里云 Prometheus 监控，观测范围从专精容器延伸到全栈可观测。为了帮助更多企业构建统一观测体系，Prometheus 监控已成为阿里云 50+款云产品默认观测基础设施，并与应用实时监控服务 ARMS 的 APM 指标、eBPF 指标、OpenTelemetry 指标联通，以及将企业的 ECS（非 K8s 集群）、K8s 集群、非阿里云集群进行 Prometheus 实例聚合，帮助企业一键开启全球与异构架构下的统一可观测中心。在服务外部客户同时，阿里云 Prometheus 监控不断通过内部场景进行打磨，目前已能够支持千万核的容器观测及数十亿级别时间线的时序存算能力。对于时序监控场景的核心技术难点，如海量动态监控对象采集能力、高基数时间线发散收敛、长周期查询、突发流量下误报漏报等场景进行针对性优化，使得阿里云 Prometheus 监控真正成为无处不在，大规模生产可用的可观测基础设施。在赋予企业强大观测能力的同时，Prometheus 推出全新包年包月计费形式，同等业务规模下，平均相较于自建成本降低 60%。满足不同业务规模用户的观测需求，并尽可能减轻企业的运维成本压力。其次，作为观测界面的阿里云 Grafana 服务也将迎来 9.0 焕新升级。全新的 Prometheus 和 Loki 查询语句生成器及强化后的搜索 Explore 功能，让用户获得更强的数据查询与分析能力，更低门槛的创建可视化大盘与告警。同时，为了应对越来越丰富的异构可观测数据源，Grafana 服务与日志服务 SLS、Elasticsearch 等 20+款可观测存储服务集成，帮助企业更简单的构建统一「运维&业务」观测界面。一键导入/导出自建实例、自动数据导出报表，一键数据备份、恢复，用户操作审计等企业特性进一步增强。最后，为了帮助企业的云上应用开启多维度观测视角，应用实时监控服务 ARMS 也迎来巨大升级。在数据采集方面，在完整支持 Opentelemetry SDK 的同时，指标数据可完全通过与 Prometheus 标准进行存储与计算，补充业务、自定义组件埋点。在完善观测维度的同时，避免厂商锁定。并借助 TraceExplorer 实现多来源 Trace 统一查询。与此同时，eBPF 技术以及 Continuous Profiling 作为目前可观测领域最为热门的细分领域，阿里云可观测团队也进行积极探索。本次大会阿里云可观测团队开放基于 eBPF 技术的“轻量版应用监控”预览，帮助企业快速获得无侵入、全语言的应用监控能力，并及时感知集群全局拓扑结构。同时，与 Alibaba Dragonwell 团队联合推出 Continuous Profiling 功能，能够以极低功耗持续分析代码级别的性能开销，覆盖传统链路、指标和日志覆盖不到的细节，实现代码级生产环境性能问题定位及全天候主动剖析，让应用观测视角更丰富，观测颗粒度更细致。在不断探索更多可观测场景服务阿里巴巴集团以及海量企业用户的同时，阿里云可观测凭借其完备的产品能力与良好的生态集成能力及出色的成本优势，收获了国内外行业机构的高度认可。阿里云应用实时监控服务 ARMS 在今年获得中国信通院首批可观测产品先进级认证。同时，阿里云连续两年进入 Gartner APM 与可观测魔力象限，今年更是成为唯一入选的中国厂商。万物皆云的时代，可观测性让云计算更易用高效，最大程度释放业务稳定性、安全性、经济性价值。“观测力”已成为每个 IT 人的必备核心竞争力。不止于观测，可观测帮助企业分析、洞察并实现高质量的决策与业务创新。而阿里云将不断推动可观测技术演进与落地实践，帮助企业获得最具性价比的可观测性，真正实现高质量数字化转型与创新。
发表了文章
2022-11-07
阿里云丁宇：云原生激活应用构建新范式，Serverless奇点已来
作者：丁宇11月5日，2022杭州·云栖大会上，阿里巴巴研究员、阿里云智能云原生应用平台总经理丁宇在云原生峰会上发表主题演讲，提出云原生激活应用构建新范式，并表示Serverless将引领下一代应用架构。阿里云将坚定推进核心产品全面Serverless 化，帮助客户最大限度的减轻运维工作，更好的实现敏捷创新。云计算时代，企业上云后，应用构建依然面临很多挑战，如何保障系统资源的弹性、降本增效；如何做到应用敏捷开发，实现业务快速迭代；如何保障系统的稳定以及业务的连续性，这些问题没有完全解决。我们看到，云原生已经变成非常流行的技术趋势，从上云到用云，云原生能够从PaaS 层面帮助企业解决应用构建的一系列问题。具体有三大范式正在成为现实：第一个范式是全面容器化。因为容器形成了运维的标准，成为企业上云用云的新界面，也变成开发者和应用系统交互的新界面，有利于构建高弹性、可伸缩的系统，从而实现降本增效。当下所有的负载都在容器化，包括耳熟能详的微服务、在线应用到整个数据库、大数据、AI、中间件等，所有的工作负载都在容器化。通过容器，我们可以享受到运维标准化、弹性架构带来的好处，也带来了软件可以无处不在的部署交付，标准化的管理运维。第二个范式是整个行业应用的核心技术互联网化。我们正在用互联网的技术、互联网的架构思想来重构应用系统，从而带来了很多好处：分布式可扩展，支撑业务敏捷迭代，构建弹性架构，从容应对流量高峰。举例来说，准备一场促销活动、一场跨年晚会，都可能有不可预期的流量高峰，数字化系统需要应对不确定的流量，必须要用互联网架构来实现；此外保障系统高可用、高可靠，保障业务的连续性，也是互联网技术能够带给企业的红利。第三个范式是应用的Serverless化。从技术角度来看，能够实现技术组件分层解耦，让应用可以做到全托管免运维，提升系统的可运维性，降低成本。通过极致弹性，能够把所有的组件覆盖，在云上构建应用变得非常简单。以前构建应用，需要买ECS实例，搭建开源软件体系然后维护它，流量大了扩容，流量小了缩容，整个过程很复杂繁琐。用了Serverless服务以后，这些问题都简化了，从半托管到全托管，所有的服务API化，无限容量充分弹性，可以组装使用，能够感受到生产力大幅度的改变。也会在软件开发的全生命周期进行优化，升级研发模式，让开发者更多的聚焦在业务上，加速迭代。以上这三个范式代表着云原生非常主流的演进方向。全面容器化：容器服务进入智能化时代Gartner预测，到2022年，超过75%的全球组织会在他们的生产环境中运行容器化的应用，而这一数据在2020年才不到30%。 我们看到，容器技术已经跨越鸿沟，从早期的互联网行业到现在的千行百业，都在生产系统中使用。虽然 ACK 大幅降低了K8s的门槛，但管理和运维一个大规模、分布式的集群依然充满挑战，比方说，如何调度应用，在保障稳定的同时，提升资源利用率；如何对应用进行成本规划、分析优化；当集群出现问题后，如何及时的定位和修复。智能化可以解决这些问题，智能化是容器平台发展的必然趋势。阿里云基于过去10年的大规模容器实战经验，通过数据化手段和智能化算法，推动容器服务ACK走向智能化。其中有三个升级：第一个升级，智能化的混部调度，新一代调度系统Koordinator，帮助用户提升整体资源利用率，智能化混部调度助力识货 App节省 20% 资源成本。第二个升级，智能化的成本治理，容器服务 FinOps套件，帮助用户实现上云成本可见、可控、可优化，中华保险基于容器 FinOps 套件实现资源闲置率从30%降低到 10%。第三个升级，智能化的运维体验，容器服务 AIOps套件，帮助用户实现数据驱动诊断决策，助力故障防御定位，自动化诊断可以覆盖 90% 以上的问题，得物 App 基于容器 AIOps 套件定位问题时间从周缩短到小时。这些能力升级，会进一步降低容器技术的使用门槛，让 ACK 做到普惠化，服务更广泛的客户群体。核心技术互联网化互联网中间件产品有三个特点：第一个就是开源全兼容，完全没有厂商锁定，像微服务、消息、服务注册发现、网关等，都是跟开源完全兼容的。第二个特点是大量的企业级特性加持，包括性能、稳定性、扩展性等。互联网分布式技术的先进性需要非常好的场景锤炼，阿里云的优势就在于多年双11复杂场景的打磨，基于双11的加持以及海量客户的应用，使得阿里云互联网技术在企业级特性上有非常强劲的优势。第三个特点有丰富的技术类解决方案，包括异地多活，应用容灾的方案、技术中台、业务中台的方案，以及混部、混沌工程和全链路压测方案等。云原生中间件实现了开源、自研和商业化的三位一体，能够助力更多企业使用标准开放的技术实现数字化转型。重磅发布一 微服务再升级：新增云原生网关开源云原生时代，微服务面临着新的诉求和技术挑战，尤其是在性能、高可用性和安全性方面。今天，阿里云正式开源云原生网关 Higress，它是业内首个标准化、高集成、易扩展、热更新的云原生网关。标准化：随着K8s的普及，K8s Ingress 逐渐成为云原生时代API事实标准， Higress全面支持该标准，并且在服务治理方面（包括灰度、限流、预热、超时、重试）做大幅增强，引领标准演进方向。高集成：Higress首次将流量网关、微服务网关、安全网关三合一，打造高集成网关，在入口建立高性能、安全防线，后端支持K8s/Nacos/ECS/Serverless多种运行时路由，打造功能最强大网关实现。易扩展：Higress提供最丰富插件扩展机制，满足客户灵活路由和安全定制需求，支持最全面语言扩展机制；当然我们为了降低客户使用门槛，默认集成了数十个插件，并且通过插件市场方便开发者贡献通用能力，产生良性互动。热更新：由于传统Nginx更新规则需要reload会导致链接抖动，导致流量损失，对实时通信、视频、IoT无法容忍，因此Higress 从证书、路由、安全规则、插件全部采用热更新机制，毫秒级生效且业务无感知。除了开源云原生网关之外，阿里云全面升级微服务引擎MSE3.0，包含三大核心能力：第一大能力是注册配置中心，相比Nacos等主流开源方案，性能提升40%，提供70+的监控指标，提供健康检测，帮助客户实现服务异常自治，例如禾连健康这家医疗行业的SaaS企业，通过MSE注册配置中心，提升开源注册配置中心性能达50%，解决了业务高速发展中的扩展性问题，保障全国 200 多个城市、2000 多家医院体验业务的稳定性超99.99%。 第二大能力是微服务治理，沉淀了阿里巴巴10+的实践经验，帮助客户缩短30%微服务治理落地周期，提升50%开发测试效率，消除80%线上风险。例如纺织产业互联网企业致景科技，未修改任何代码就接入了MSE微服务治理所有能力。微服务实施周期下降 30%，构建开发测试环境从天降低到分钟。第三大能力是云原生网关，阿里云将流量网关、微服务网关、安全网关三合一，架构上也做了升级，将实例级防护升级至路由级防护，整体性能相比传统网关提升90%。例如移动支付企业费芮互动利用MSE构建了零信任架构，大幅提升业务入口安全性，通过软硬一体完成TLS卸载，性能提90%，并采用软硬件一体化，响应时间下降50%。重磅发布二 可观测再升级：让可观测数据价值最大化云原生时代，系统架构日趋复杂，提升可观测能力成为降低复杂度的唯一手段。今天可观测能力成为度量企业IT水平的标准，成本治理、业务连续性、业务增长都需要可观测技术。因此阿里云推出云原生可观测套件ACOS，从应用监控到链路追踪，帮助企业实现成本管理、风险治理、智能运维、保障数字化业务高效稳定的运行。本次云栖大会，阿里云云原生可观测套件ACOS三大组件也迎来重要升级。首先， Prometheus已成为不少企业的观测首选。作为容器观测事实标准的Prometheus监控，已成为阿里云50多款云产品的默认观测基础设施，并与应用实时监控服务ARMS的APM指标、eBPF指标、OpenTelemetry 指标联通，将观测范围从专精容器延伸到全栈可观测。其次，作为观测界面的阿里云Grafana服务也将迎来9.0焕新升级。全新的Prometheus 和 Loki 查询语句生成器及强化后的搜索 Explore 功能，让用户获得更强的数据查询与分析能力。同时，为了应对越来越丰富的异构可观测数据源，Grafana服务与日志服务SLS、Elasticsearch等20+款可观测存储服务集成，帮助企业更简单的构建统一观测界面。一键导入/导出自建实例、自动数据导出报表，一键数据备份、恢复，用户操作审计等企业特性得到进一步增强。最后，为了帮助企业的云上应用开启多维度观测视角。应用实时监控服务ARMS在数据采集方面，OpenTelemetry 与Prometheus生态全面融合，通过 OpenTelemetry 补充业务、自定义组件埋点，在完善观测维度的同时，实现厂商无锁定。并借助 TraceExplorer 实现多来源 Trace 统一查询。重磅发布三 RocketMQ5.0全面升级：从消息服务到云原生事件流平台消息队列一直是企业互联网架构的核心组件，阿里巴巴早在2012年就基于电商场景打造了国内流行的消息中间件RocketMQ，并贡献到Apache 社区。历经十余年的打磨，RocketMQ 取得了众多成果。Apache RocketMQ 的社区非常活跃，全球拥有700+的贡献者，超过75%的头部企业选择使用RocketMQ，同时超过80%的主流云厂商提供了RocketMQ的商业托管服务；阿里云作为 RocketMQ 的发起方和核心贡献者，十多年以来，累计服务了来自互联网、零售、汽车等20多个行业、10w+万企业客户；承载千万级TPS，万亿级消息洪峰。当下，阿里云 RocketMQ 5.0 正式商业化，从内核到生态全面拓宽，全新升级为云原生事件流平台，深耕事件驱动和事件流处理两大核心场景。在未来，企业开发者基于RocketMQ事件流平台，既可以轻松驱动微服务、Serverless应用；也可以基于RocketMQ重构当下的流处理任务，以更加轻量化、低代码的形态，高效的完成CDC、ETL等流处理需求。Serverless 奇点已来：引领下一代应用架构随着企业用云的深入，云的能力也在不断升级，过去企业用云就是去买资源、买实例、买规格、搭应用。我们一直在说“云计算是像水电煤一样的基础设施，但是现在这一点还没有完全实现。阿里云一直在推动产品形态、研发方式的升级，希望从提供资源到提供服务，这个服务就是即插即用的能力，企业不需要管理和维护，可以实现自动伸缩免运维，平台全托管，按用量计费，真正实现了服务化、模块化，这也是云产品升级演进的方向。可以说，Serverless 奇点己来，所谓奇点，就是由平稳发展转向高速发展的转折点，预示着行业落地开始爆发。目前，阿里云已经有20 多款的 Serverless产品，并且会推进核心产品全面Serverless化，Serverless 是云提供能力的最佳实现方式，也是让云计算基础设施落地到千行百业的最佳范式。回顾阿里云在Serverless 领域的演进历程：2017年推出的函数计算是一款FaaS产品，这是一种以事件驱动的全托管计算服务，用户只需编写代码并上传，函数计算就会自动准备好计算资源，以弹性、可靠的方式运行代码，并提供完整的可观测能力，大幅简化开发运维过程。2018年推出的Serverless 应用引擎SAE是业内首款面向应用的Serverless PaaS平台，屏蔽底层IaaS和Kubernetes的复杂度，提供了零代码改造、成本更优、效率更高的应用托管方案，帮用户实现单体Web应用、微服务应用以及定时任务的Serverless化。同年领先业界推出 Serverless 容器服务ASK，基于弹性容器实例ECI（Elastic Container Instance），可以实现 1min 扩容 2000个 pod，降低了 Kubernetes 使用门槛，让用户更专注于应用程序，而不是管理底层基础设施。2020年阿里云开源 Serverless Devs，成为业内首个支持主流 Serverless服务/框架的云原生全生命周期管理的平台。2022年9月该项目正式进入CNCF Sandbox，也成为业内首个入选的Serverless工具项目。除了产品形态的改变之外， Serverless 同样带来了软件研发范式的改变。随着阿里云提供越来越全面的Serverless产品以后，很多云产品都变成模块化、API化、服务化，它可以进行组装，通过拖拉拽的方式就能够构建应用。所以说在Serverless架构下，研发方式升级到组装式研发，组装式研发可以做到流程编排、事件驱动，甚至可以做成可视化，这就彻底颠覆了原有的软件研发方式，大幅提升研发效率，灵活应对业务挑战。根据权威机构调研统计，组装式研发相比传统模式，可为研发提效 50%以上。 以南瓜电影为例，因为一场热映电影，南瓜电影一小时用户增加了一百万，流量暴涨引发网站服务一度中断，临时云上扩容也无法及时满足巨大的流量。传统架构没有改变云上的效率，南瓜电影开始转向Serverless架构，三天时间完成了核心应用的上线，第五天100%的切换，第六到七天把核心的30多个应用切换到Serverless上，最终带来扩容效率提升10倍，成本下降超过 40%，研发效率提升 70%，这就是 Serverless 带来的价值：真正让开发者回归业务本身，让企业做得更少而收获更多。未来，阿里云在云原生领域将持续的引领标准，不断突破，推动领域和产业快速发展。
发表了文章
2022-11-07
【活动已结束】就在明天！2022 云原生峰会正式拉开帷幕
作者：云原生峰会小组今天，企业应用构建依然面临很大挑战，资源如何按需使用，实现降本增效？如何在复杂系统架构下，充分保障业务稳定和连续性？如何做到应用的敏捷和业务的智能化？如何保障系统的可信和安全？企业亟需充分挖掘云计算的技术红利，助力业务发展，创造更多的商业价值。云原生可以激活应用构建范式，以解决企业在新时期遇到的挑战。15位重磅嘉宾齐聚探讨云原生阿里云智能云原生应用平台总经理丁宇、中国信息通信研究院云大所副所长栗蔚、阿里云智能容器服务负责人易立识货运维总监瞿晟荣、小红书基础架构部负责人贺晋如、阿里云可观测负责人周小帆、阿里云可观测& Serverless 负责人司徒放新东方教育科技集团云教室直播平台技术负责人么敬国、心动网络TapTap/IEM/AI平台负责人陈欣昊阿里云智能高级产品专家董振华、禾连健康CTO邓志豪、阿里云智能高级产品专家杨秋弟、阿里云智能资深技术专家云原生PaaS负责人谢吉宝、阿里云智能资深技术专家高可用架构负责人周洋硬核科技等你来玩！为探寻企业数字化转型的未来方向及技术重点深度解密云原生技术新动向11 月 5 日（本周六）杭州云栖小镇-云原生峰会B 馆 B2-1阿里云将联手识货、传音、禾连健康、新东方、心动网络、小红书等实战企业技术负责人分享云原生最新技术与经验，助力更多企业落地云原生。11 月 5 日，杭州云栖小镇 B 馆，我们不见不散！
发表了文章
2022-11-07
阿里云张建锋：核心云产品全面 Serverless 化
11 月 3 日，2022 杭州·云栖大会上，阿里云智能总裁张建锋表示，以云为核心的新型计算体系正在形成，软件研发范式正在发生新的变革，Serverless 是其中最重要的趋势之一，阿里云将坚定推进核心产品全面Serverless 化，帮助客户更好地实现敏捷创新。“我们希望让用户做得更少而收获更多，通过Serverless化，用云就像用电一样简单。”张建锋表示，Serverless 让云计算从一种资源真正变成一种能力，未来云将全面Serverless化，更加接近“电网”模式，按计算的调用次数付费。Serverless 并不是不用服务器，它是将服务器全权托管给了云厂商，根据业务流量大小自动弹性伸缩，开箱即用免去维护成本，按使用量计费。用户无需关心和管理底层IT资源，只要聚焦业务代码，根据实际请求处理业务。依托于 Serverless 架构，云上研发方式正在发生根本性的改变。从过去的集中式研发、分布式研发，到云上的组装式研发，实现了软件研发的服务化、模块化、可编排、可组装。无论是2万用户还是2000万用户体量，基于 Serverless 构建的IT架构都可以自适应伸缩，峰值秒级自动扩容、峰谷自动缩容。基于 Serverless 产品，云产品都变成模块化、API 化、服务化，它可以进行组装，通过拖拉拽的方式就能够构建应用，并通过流程驱动和事件驱动，让应用构建可视化，从而获得更强大的应用能力。 阿里云是国内最早提供 Serverless 计算服务的云厂商。2017 年推出的函数计算 FC 是一款 FaaS 产品，这是一种以事件驱动的全托管计算服务，用户只需编写代码并上传，函数计算就会自动准备好计算资源，以弹性、可靠的方式运行代码，并提供日志查询、性能监控、报警等功能。2018年领先业界推出 Serverless 容器服务 ASK，基于弹性容器实例 ECI（Elastic Container Instance），可以实现 1min 扩容 2000个 pod，降低了 Kubernetes 使用门槛，让用户更专注于应用程序，而不是管理底层基础设施。2019年推出首款面向应用的 Serverless PaaS（SAE），提供成本更优、效率更高的一站式微服务和 K8s 托管方案，零改造实现 web/微服务/任务的迁移。2020年开源 Serverless 开发者平台 Serverless Devs，这是业内首个支持主流 Serverless 服务/框架的云原生全生命周期管理平台。2022 年 9 月，Serverless Devs 正式成为 CNCF 官方沙箱项目，也成为 CNCF 首个 Serverless Tool 项目。2022年 Serverless 应用中心发布，它是一个 Serverless 应用全生命周期管理平台，用户不需要在部署应用之前进行额外的克隆、构建、打包和发布操作，就可以快速部署和管理应用。权威分析机构 Gartner 预测，2025 年将有 50% 以上的全球企业部署 Serverless 架构。从应用场景上来看，除小程序外，Serverless 还受到电商大促、音视频转码、AI 算法服务、游戏应用包分发、文件实时处理、物联网数据处理、微服务等场景的青睐。世纪联华是最早试水 Serverless 的新零售代表，当发现老架构无法满足大促时流量爆炸问题，于是果断将会员系统、交易系统、支付系统等放在阿里云函数计算上处理，告别了靠扩展机器支撑大体量业务，促销准备时间从周级缩短到小时级，研发运维提效 30%，成本下降 40%，真正的把促销活动变成常态；流媒体平台南瓜电影从创业之初架构就构建在阿里云之上，是一个典型的“生于云，长于云”的企业。但随着业务的不断发展，原有的系统架构逐渐暴露了很多问题。因为一场热映电影，南瓜电影新用户量 1 小时内增加了 100 万，流量暴涨引发网站服务一度中断，临时云上扩容也无法及时满足巨大的流量。痛定思痛，开始走向 Serverless 转型之路，基于阿里云 Serverless 应用引擎 SAE 产品，3 天完成核心应用 API 网关上线，第 5 天验证结束 100% 流量打到 SAE 上，第 6-7 天把其余 30 多个系统快速迁移到 SAE。7天完成 Serverless 架构升级，使用 SAE 后，运维效率提升 70%，成本下降超过 40%，扩容效率提升 10 倍以上。目前，阿里云已经拥有超过 20 款 Serverless 产品，其中阿里云函数计算 FC 日调用次数超过 200 亿次，有效支撑历年双 11 百万 QPS 洪峰，业务增速超过 300%，整体规模位居国内首位。在 Forrester 发布的 2021 年第一季度 FaaS 平台评估报告中，阿里云凭借函数计算产品能力全面领先的优势，成为全球前三的 FaaS 领导者，这也是首次有国内科技公司进入 FaaS 领导者象限。
发表了文章
2022-11-04
可观测实践｜如何利用 Prometheus 精细化观测云产品
引言随着云计算的普及，企业用到越来越多云产品，例如：ECS、RDS、Redis 等。服务众多企业之后，阿里云可观测团队发现在运维场景愈发精细化的今天，对于指标按需再加工、对于告警规则的灵活设置成为刚需，云监控等基础默认监控能力，无法满足当下的运维需求，例如：查看各 Region ECS CPU 使用率 Top10；为 Kafka 服务连续 10 分钟堆积增量超过 500 的 ConsumerGroup 设置告警；基于磁盘空间的变化预测清理时间，避免告警无法及时处理导致故障。 与此同时，Prometheus + Grafana 成为可观测性事实标准。运维团队可以使用 Prometheus 监控云原生 Kubernetes 体系 Node、ApiServer、workload 等基础指标的同时，还可以通过 Prometheus Exporters 采集各种组件（如 Redis、Kafka 等）和业务应用的相关指标，最后通过 Grafana 进行整体可视化展示，借助 AlertManager 进行告警，实现云原生时代的指标可观测闭环。回到最开始的话题，随着云产品应用愈发普及，基于“Prometheus + Grafana”的指标可观测体系是否可以针对云产品的相关指标提供更加精细化的加工与应用能力，实现对云产品的指标可观测闭环？答案是肯定的。自建 Prometheus 监控云产品的挑战虽然 Prometheus 官方社区维护了很多 Exporter，第三方厂商或者主流开源项目也参与到贡献及维护中。但由于云产品的特殊性，如果用户想要通过自建 Prometheus 去监控云产品，就需要用户通过 Prometheus Exporter 形式将观测到的 Metric 数据收集到服务端。但这里就会出现一些关于 Exporter 的额外工作量：额外的研发工作量虽然官方提供了四种语言（Go/Java/Python/Rubby）的正式客户端库用来开发一个集成 http server 的 Exporter 库，并提供了完整的开发规范。但这需要运维工程师针对不同云产品开发定制 Exporter（调用企业云监控实时导出服务获取 Metric 数据），对于开箱即用的云服务而言，拖慢了业务上线效率。额外的 Exporter 资源消耗由于 Exporter 本身提供了一个 REST 服务器，会带来一些线程消耗，随着 Exporter 接入云产品越多、指标越多消耗的资源也会随之越多。可以看到，虽然运维工程师可以通过自研 Eexporter 完成对于云产品的监控，但有没有更简单的方式？阿里云 Prometheus 服务(下面简称 Prometheus)成为最佳选择，提供全托管、开箱即用的云产品指标监控能力，并结合常见运维场景，预置若干多维度监控大盘以满足常见监控场景。针对不同云产品可观测性集成情况，提供「企业云监控集成」以及「云产品自监控集成」两种不同接入模式，最大限度的降低运维接入成本。如何通过阿里云 Prometheus 服务监控云产品根据不同云产品的 Prometheus 集成情况，Prometheus 服务的云产品监控分为「企业云监控集成」以及「云产品自监控集成」两种形式，接下来我们将进行详细解读。企业云监控集成阿里云部分云产品在产品控制台默认集成了 Prometheus 监控，但还有众多云产品尚未集成 Prometheus。为了能通过 Prometheus 服务监控这部分云产品，我们提供企业云监控集成模式，通过企业云监控获取监控指标，指标上报流量费用由云监控收取(收费标准)，Prometheus 免费存储及应用。在用户运维成本未增加的前提下，获得了 Prometheus 更精细与灵活的的指标加工与应用能力。部署形式如下图：Exporter：以 Pod 方式部署在 Prometheus 企业云监控集成的托管 K8s 集群，通过调用企业云监控实时导出 API 收集已集成的云产品指标数据；Agent：Arms Prometheus AgentAlarm：定义集成的云产品告警模板Grafana：提供已集成的云产品默认大盘 对于云产品控制台目前尚不支持Prometheus监控的产品，通过该方式实现产品指标监控，目前支持 25 款云产品并不断扩增。企业云监控集成目前仅支持国内 Region，海外 Region 暂未开放。云产品接入后，包含全部 Region 监控指标。目前已接入产品包括：弹性计算类：阿里云 ECS；存储类、阿里云 SLS、阿里云 OSS；网络类：阿里云 ALB、阿里云 API 网关、阿里云 Connector、阿里云 CDN、阿里云 CEN、阿里云 DCDN、阿里云 Cloud NAT、阿里云 EIP；大数据类：阿里云 E-MapReduce、阿里云 Elasticsearch、阿里云 Logstash；数据库类：阿里云 PolarDB、阿里云 RDS PostgreSQL、阿里云 RDS MySQL、阿里云 Redis、阿里云 RDS SQLServer、阿里云 Hologres、阿里云 ADB、阿里云 DRDS、阿里云 DTS；安全类：阿里云 WAF； 云产品自监控集成目前，部分云产品在各自控制台提供了自身产品的可观测性，但这些云产品的指标及看板散落在各个控制台。为了能将这些数据进行统一展现。Prometheus 服务提供了云产品自监控集成形式，云产品自监控集成的相关指标来源于各云产品，为运维团队提供更加便捷的日常运维监控界面。部署形式如下：Exporter：以 Pod 方式部署在云产品侧 K8s 集群，负责收集云产品指标数据；Agent：Arms Prometheus AgentAlarm：定义告警模板Grafana：提供云产品默认大盘 Prometheus 自监控集成 Tab 页是云产品控制台支持 Prometheus 监控的所有云产品的概览页，展现当前账号下云产品的 Promehtheus 集成状态、指标占比、大盘预览、告警配置。目前已接入的产品包括：数据库类：阿里云 Clickhouse、阿里云 Lindorm、云数据库 MongoDB；消息队列类：消息队列 RabbitMQ、消息队列 Kafka、消息队列 RocketMQ；中间件类：企业级分布式应用服务 EDAS、微服务引擎 MSE - 云原生网关、微服务应用引擎 SAE、应用高可用服务 AHAS；运维类：Grafana 服务、性能测试 PTS； 最佳实践企业云监控集成云产品接入 登录 Prometheus 控制台，点击左侧菜单“接入中心”选择任意云产品后弹出接入页面，选择待接入的云产品安装即可，安装完成后会创建一个名为“企业云服务”的 Prometheus 实例。监控指标点击“云服务实例”，选择相应云产品图标会弹出一个包含指标、大盘和告警 3 个 tab 页的窗口。指标页默认包括：指标、类别、描述 3 项基本信息，已集成云产品除默认项外还包括最近 10 分钟的指标量和占比。ECS 如图：Grafana 大盘大盘页默认显示该云产品的所有 Grafana 默认大盘缩略图。已集成的云产品点击缩略图或 Title 链接会跳转至阿里云 Grafana 监控大盘，未集成的云产品点击缩略图或 Title 链接会显示 Grafana 监控大图。ECS 实例详情：提供 ECS 实例的 CPU、内存、磁盘、网络等系统指标的监控，筛选维度包括：区域、ECS 标签、实例名、实例 ID；ECS 全局公网大盘：提供 ECS 实例公网流入、流出带宽合计、TOP 等指标；ECS 实例利用率排序大盘：支持 region 和全局维度 TOP 实例，主要指标：CPU 利用率、内存利用率、网络连接等；ECS 资源区域分布大盘：支持 ECS 实例、CPU、内存、磁盘、网络连接等按区域分布统计； 告警配置 告警页默认显示该云产品配置的所有告警规则：点击“创建 Prometheus 告警规则”通过默认告警模板设置或自定义 PromQL 完成告警规则的创建(自定义 PromQL 指标名可参考步骤“云产品指标”)。默认告警规则 CPU 利用率AliyunEcs_cpu_total{} > 80内存利用率AliyunEcs_memory_usedutilization{} > 90磁盘利用率：磁盘使用率超过 90%时需要进行磁盘清理AliyunEcs_diskusage_utilization{} > 90磁盘剩余空间不足：当磁盘剩余空间小于 5G 时考虑清理AliyunEcs_diskusage_free{} < 1024*1024*1024*5热点指标 云产品自监控集成在开通云产品并创建实例时，会有开通 ARMS Prometheus 相关选项，创建完成后即可通过 Prometheus 实现该产品的指标监控。以“MSE 服务-云服务网关”为例：1. 创建实例时开通 Prometheus 监控2. 产品控制台监控入口Grafana 专业版云服务实例默认使用 Grafana 共享版，如果默认大盘不能满足运维团队可观测需求或者想在默认大盘基础上进行优化，可增购 Grafana 专家版或高级版。关于阿里云 Prometheus 监控阿里云 Prometheus 服务是基于云原生可观测事实标准 - Prometheus 开源项目构建的全托管监控服务。默认集成常见云服务，兼容主流开源组件，全面覆盖业务监控/应用层监控/中间件监控/系统层监控。通过开箱即用的 Grafana 看板与智能告警功能，并全面优化探针性能与系统可用性，帮助企业快速搭建一站式指标可观测体系。助业务快速发现和定位问题，减轻故障给业务带来的影响，并免去系统搭建与日常维护工作量，有效提升运维监控效率。与此同时，阿里云 Prometheus 作为阿里云可观测套件的重要组成部分，与 Grafana 服务、链路追踪服务，形成指标存储分析、链路存储分析、异构构数据源集成的可观测数据层，同时通过标准的 PromQL 和 SQL，提供数据大盘展示，告警和数据探索能力。为 IT 成本管理、企业风险治理、智能运维、业务连续性保障等不同场景赋予数据价值，让可观测数据真正做到不止于观测。
发表了文章
2022-11-03
详解 Serverless 架构的 6 大应用场景
作者：ServerlessServerless 架构将成为未来云计算领域重要的技术架构，将会被更多的业务所采纳。进一步深究，Serverless 架构在什么场景下有优秀的表现，在什么场景下可能表现得并不是很理想呢？或者说，有哪些场景更适合 Serverless 架构呢？​Serverless 架构的应用场景   Serverless 架构的应用场景通常是由其特性决定的，所支持的触发器决定具体场景。如图 1-1 所示，CNCF Serverless Whitepaper v1.0 描述的关于 Serverless 架构所适合的用户场景如下。异步并发，组件可独立部署和扩展的场景。突发或服务使用量不可预测的场景。短暂、无状态的应用，对冷启动时间不敏感的场景。需要快速开发、迭代的业务。1-1 CNCF Serverless Whitepaper v1.0 描述的 Serverless 架构所适合的用户场景CNCF 除基于 Serverless 架构的特性给出 4 个适用的用户场景之外，还结合常见的触发器提供了详细的例子。响应数据库更改（插入、更新、触发、删除）的执行逻辑。对物联网传感器输入消息（如 MQTT 消息）进行分析。执行流处理（分析或修改动态数据）。数据单次提取、转换和存储需要在短时间内进行大量处理（ETL）。通过聊天机器人界面提供认知计算（异步）。调度短时间内执行的任务，例如 CRON 或批处理的调用。机器学习和人工智能模型。持续集成管道，按需为构建作业提供资源。CNCF Serverless Whitepaper v1.0 基于 Serverless 架构的特点，从理论上描述了 Serverless 架构适合的场景或业务。云厂商则站在自身业务角度来描述 Serverless 架构的典型应用场景。通常情况下，当对象存储作为 Serverless 相关产品触发器时，典型的应用场景包括视频处理、数据 ETL 处理等；API 网关更多会为用户赋能对外的访问链接以及相关联的功能等，当 API 网关作为 Serverless 相关产品的触发器时，典型的应用场景就是后端服务，包括 App 后端服务、网站后端服务甚至微信小程序等相关产品的后端服务。一些智能音箱也会开放相关接口，这个接口也可以通过 API 网关触发云函数，获得相应的服务等；除了对象存储触发以及 API 网关触发，常见的触发器还有消息队列触发器、Kafka 触发器、日志触发器等。Web 应用或移动应用后端​如果 Serverless 架构和云厂商所提供的其他云产品结合，开发者能够构建可弹性扩展的移动应用或 Web 应用程序 ，轻松创建丰富的无服务器后端。而且这些程序在多个数据中心可用。图 1-2 所示为 Web 应用后端处理示例。1-2 Web 应用后端处理示例实时文件/数据处理在视频应用、社交应用等场景下，用户上传的图片、音视频往往总量大、频率高，对处理系统的实时性和并发能力都有较高要求。此时，对于用户上传的图片，我们可以使用多个函数对其分别处理，包括图片的压缩、格式转换等，以满足不同场景下的需求。图 1-3 所示为实时文件处理示例。1-3 实时文件处理示例我们可以通过 Serverless 架构所支持的丰富的事件源、事件触发机制、代码和简单的配置对数据进行实时处理，例如：对对象存储压缩包进行解压、对日志或数据库中的数据进行清洗、对 MNS 消息进行自定义消费等。图 1-4 所示为实时数据处理示例。1-4 实时数据处理示例离线数据处理​通常，要对大数据进行处理，我们需要搭建 Hadoop 或者 Spark 等相关的大数据框架，同时要有一个处理数据的集群。但通过 Serverless 技术，我们只需要将获得到的数据不断存储到对象存储，并且通过对象存储配置的相关触发器触发数据拆分函数进行相关数据或者任务的拆分，然后再调用相关处理函数，之后存储到云数据库中。例如：某证券公司每 12 小时统计一次该时段的交易情况并整理出该时段交易量 top5；每天处理一遍秒杀网站的交易流日志获取因售罄而产生的错误，以便准确分析商品热度和趋势等。函数计算近乎无限扩容的能力可以使用户轻松地进行大容量数据的计算。利用 Serverless 架构可以对源数据并发执行 mapper 和 reducer 函数，在短时间内完成工作。相比传统的工作方式，使用 Serverless 架构更能避免资源的闲置，从而节省成本。数据 ETC 处理流程可以简化为图 1-5。1-5 数据 ETL 处理示例人工智能领域​在 AI 模型完成训练，对外提供推理服务时，基于 Serverless 架构，将数据模型包装在调用函数中，在实际用户的请求到达时再运行代码。相对于传统的推理预测，这样做的好处是无论是函数模块还是后端的 GPU 服务器，以及对接的其他相关机器学习服务，都可以进行按量付费以及自动伸缩，从而在保证性能的同时确保服务的稳定。图 1-6 为机器学习（AI 推理预测）处理示例。1-6 机器学习（AI 推理预测）处理示例物联网（IoT）领域​目前，很多厂商都在推出自己的智能音箱产品—用户对智能音箱说一句话，智能音箱通过互联网将这句话传递给后端服务，然后得到反馈结果，再返给用户。通过 Serverless 架构，厂商可以将 API 网关、云函数以及数据库产品结合起来，以替代传统的服务器或者虚拟机等。Serverless 架构一方面可以确保资源能按量付费，即用户只有在使用的时候，函数部分才会计费；另一方面当用户量增加时，通过 Serverless 架构实现的智能音箱系统的后端也会进行弹性伸缩，保证用户侧的服务稳定，且对其中某个功能的维护相当于对单个函数的维护，并不会给主流程带来额外风险，相对来说会更加安全、稳定等。图 1-7 为 IoT 后端处理示例。图1-7 IoT 后端处理示例监控与自动化运维​在实际生产中，我们经常需要做一些监控脚本来监控网站服务或者 API 服务是否健康，包括是否可用、响应速度等。传统的方法是通过一些网站监控平台（例如 DNSPod 监控、360 网站服务监控，以及阿里云监控等）进行监控和告警。这些监控平台的原理是用户自己设置要监控的网站和预期的时间阈值，由监控平台部署在各地区的服务器定期发起请求，进而判断网站或服务的可用性。当然，这些服务器虽然说通用性很强，但实际上并不一定适合。例如，现在需要监控某网站状态码和不同区域的延时，同时设置一个延时阈值，当网站状态异常或者延时过大时，平台通过邮件等进行通知和告警。目前，针对这样一个定制化需求，大部分监控平台很难直接实现，所以开发一个网站状态监控工具就显得尤为重要。除此之外，在实际生产运维中，对所使用的云服务进行监控和告警也非常有必要。例如：在使用 Hadoop、Spark 时要对节点的健康进行监控；在使用 Kubernetes 时要对 API Server、ETCD 等的指标进行监控；在使用 Kafka 时要对数据积压量，以及 Topic、Consumer 等的指标进行监控。对于这些服务的监控，我们往往不能通过简单的 URL 以及某些状态进行判断。在传统的运维中，我们通常会在额外的机器上设置一个定时任务，以对相关服务进行旁路监控。Serverless 架构的一个很重要的应用场景就是运维、监控与告警，即通过与定时触发器结合使用，实现对某些资源健康状态的监控与感知。图 1-8 为网站监控告警示例。1-8 网站监控告警示例​新书推荐​阿里云、蚂蚁集团的 4 位专家刘宇、田初东、卢萌凯、王仁达（排名不分先后）系统梳理阿里在 Serverless 架构下的 AI 经验，联袂推出新书《Serverless 架构下的 AI 应用开发：入门、实战与性能优化》 。​​​本书是关于 Serverless 架构下机器学习实战的技术书，我们希望通过简单明了的语言、真实的案例，以及开放的源代码，为读者介绍 Serverless 架构与机器学习相关的基础知识，帮助读者在 Serverless 架构下开发、上线机器学习项目。新书将在免费在 Serverless  公众号连载，欢迎大家订阅关注
发表了文章
2022-11-02
Dubbo 可观测性实践之 Metrics 功能解析
作者：姚辉在 2018 年，Observability（即可观测性）首次被引入 IT 领域，并逐渐取代只关注系统整体可用性的传统监控。随着云原生技术的不断发展，企业从单体架构发展到分布式架构，使用容器部署拆分出来的一众微服务、与业务联系紧密，传统的监控仅适合报告系统的整体运行情况无法进行高度细化的分析与关联，于是需要将研发视角融入监控，发展具有比原有监控更广泛、更主动、更细粒度的能力，这种能力就是可观测性。Dubbo 3 的建设规划有上云，可观测性是上云必不可少的能力，集群间根据实例可用性负载均衡、Kubernetes 弹性伸缩、建立实例健康模型等等运用场景都需要可观测性。目前 Dubbo 3 的可观测性正在建设中，本文主要介绍 Metrics 模块基础知识与进度。零-APM 介绍APM全称是 application performance management，翻译过来就是应用的性能管理，主要是用来管理和监控软件系统的性能和可用性。可以保障线上服务的质量，是一个重要的服务治理工具。如果从系统职能上分的话，APM 系统的话可以可以分为三个子系统，分别是 Metrics、Tracing 和 Logging。Metrics 也叫指标监控，主要是负责处理一些结构化的可以聚合的一些指标数据。Tracing 又叫链路追踪，主要是围绕单次请求进行信息处理，然后所有的数据都被绑定到系统的单个请求或者说单个事务上。Logging 是日志监控，主要梳理一些非结构化的事件。Metrics 结构与类型一个 Metrics 由四部分组成，第一个是指标名称；第二个是 labels 或者说 tags 也就是标签，是一些维度数据，这些维度数据可以用来做一些过滤或者聚合查询；第三个是时间戳，就是它的时间字段；第四个就是具体的指标的一个值。除了上述四个部分之外，还有一个非常重要的字段没有体现在数据模型里，就是这条数据的指标类型。不同的指标类型的话它是会用在不同的监控场景，同时它的一些查询和可视化的一些方式，也会有一些区别。下面简单介绍一些常用的指标类型。第一个是 Gague，这个类型的特点就是他是可增可减的。比如说 CPU 负载、活跃线程数、内存使用率、磁盘使用率，这些数它都是会随着时间进行波动的。它存储和展示的都是一个瞬时值。第二个指标类型 Counter，这个类型的特点是只增不减，比如说接口请求总量，对于这个类型，一般会有几个衍生的处理，一个是可以比较两个时间点前后的一个差值，这样可以计算出这个单位时间内的请求的一个波动量。第二个就是对时间进行求导之后，就得到 QPS 这种类型的一个字段。第三个指标类型是 Summary，主要做的是一个汇总统计，比如说平均值，分位数这样的一些指标。然后这个指标类型的话主要用于接口响应延迟这样的一个场景。因为我们平时在看接口响应延迟这个指标的时候，一般除了看它的平均值，可能还会看一些那种分位数指标。第四个指标类型是 Historgram，它是一个柱状统计，一般是会先对指标进行一个分桶，分桶之后再去统计它的一些值。比如说我们的还是以那个接口响应延迟为例的话，它会比如说有一些那种可视化展示的话，展示它的那个柱状图。指标收集Dubbo 的指标体系，总共涉及三个模块，分别是指标收集、本地聚合、指标推送。指标收集：将 Dubbo 内部需要监控的指标推送至统一的 collector 中进行存储。本地聚合：指标收集获取的均为基础指标，而一些分位数指标则需通过本地聚合计算得出。指标推送：而获取指标的话有两种方式，第一种是直接访问 Dubbo 暴露的接口就可以获得 Dubbo 内部统计的指标，第二种是接入第三方服务器进行指标推送，Dubbo 会将收集和聚合后的指标通过 pull 或者push的方式推送至第三方服务器，目前只涉及 Prometheus，其中 pull 或者 push 由用户选择。 指标收集指标收集的目的是为了存储微服务的运行状态，相当于给微服务拍了一个快照，以及为进一步的分析（比如指标聚合）提供基础数据。上图为 Dubbo 的架构图，本方案中指标收集的埋点位置或者说切入位置是在 provider 中通过 SPI 的方式添加一个 Filter。这里贴了部分代码，展示了其中一部分指标收集的逻辑。我们是通过 interfaceName、methodName、group、version 四个维度的信息作为 map 存储结构的 key ，当然这四个维度的信息最后在指标导出的时候都会转换成前面 metrics 存储结构的 labels 或者说 tags。接下来给大家展示一个的是我们一个默认存储器的成员变量。运用分段锁结构的 ConcurrentHashMap 来保证并发度，其中的 MethodMetric 就是前文说的四个维度信息组成的一个 class。有一个比较重要的结构是一个 MetricsListener 的 list ，这里其实是一种生产者消费者的模式，因为默认收集器是我们默认接入的，但是如果需要收集其他指标则需要继续在此添加监听，让其他收集器监听默认收集器的状态，当默认收集器收集到了值就向监听列表推送一个事件，这样其他收集器就能收集到元信息再进一步加工处理。这里也是本地聚合实现的一个逻辑，具体细节不展示了，有兴趣的同学可以去看看 Dubbo 3.1 的代码。本地聚合-滑动窗口与 TDigest本地聚合主要使用滑动窗口与 TDigest，滑动窗口原理如图，假设我们初始有 6 个 bucket，每个窗口时间（即一个 bucket 在 current 指针下的停留时间）设置为2分钟，每次写入指标数据时，会将数据分别写入 6 个 bucket 内，也就是一条数据写六遍，我们会每隔两分钟移动一个 bucket 并且清除原来 bucket 内的数据，读取指标时，会读取当前 current 指向的 bucket 内的指标数据，以达到滑动窗口的效果。滑动窗口的作用是为了能够对近期的数据做一个聚合，使得我们每次指向的 bucket 里面存储的都是从当前时间到过去一个 bucket 生命周期（即 [ now - bucketLiveTime * bucketNum, now ] 这样一个时间区间）的指标数据。其中 bucket 的生命周期受窗口时间和 bucket 数量控制，这个支持用户自定义配置。接下来是介绍 Dubbo 分位数指标的处理，我们常说的 p99，p95 这样的指标就是分位数指标，p99 是指在 100 个请求里面，响应时延排名第 99 位的值，可以较好的反应一个服务的可用性，被称为黄金指标。Dubbo 在计算分位数指标的时候使用了 TDigest 算法，TDigest 是一个简单，快速，精确度高，可并行化的近似百分位算法。TDigest 使用的思想是近似算法常用的 Sketch，也就是素描，用一部分数据来刻画整体数据集的特征，就像我们日常的素描画一样，虽然和实物有差距，但是却看着和实物很像，能够展现实物的特征。下面是 TDigest 的原理。假如有 500 个 -30 ~ 30 间的数字，可以使用概率密度函数也就是 PDF 函数表示这一数据集该函数上的某一点的 y 值就是其 x 值在整体数据集中的出现概率，整个函数的面积相加就正好为 1 ，可以说它刻画了数据在数据集中的分布态势，也就是大家熟悉的正态分布。有了数据集对应的 PDF 函数，数据集的百分位数也能用 PDF 函数的面积表示。如下图所示，百分位数 P75 就是面积占了 75% 时对应的 x 坐标。PDF 函数曲线中的点都对应着数据集中的数据，当数据量较少时，我们可以使用数据集的所有点来计算该函数，但是当数据量较大时，只有通过少量数据来代替数据集的所有数据。这里，需要将数据集进行分组，相邻的数据分为一组，用平均数和来代替这一组数。这两个数合称为质心数，然后用这个质心数来计算 PDF，这就是 TDigest 算法的核心思想。如下图所示，质心数的平均值作为x值，个数作为 y 值，可以通过这组质心数大致绘制出这个数据集的 PDF 函数：对应的，计算百分位数也只需要从这些质心数中找到对应的位置的质心数，它的平均值就是百分位数值。很明显，质心数的个数值越大，表达它代表的数据越多，丢失的信息越大，也就越不精准。如这张图所示，太大的质心数丢失精准度太多，太小的质心数则有消耗内存等资源较大，达不到近似算法实时性高的效果。所以，TDigest 在压缩比率的基础上，按照百分位数来控制各个质心数代表的数据的多少，在两侧的质心数较小，精准度更高，而在中间的质心数则较大，以此达到 P1 或 P99 的值要比 P20 更准确的效果。指标推送之 Prometheus指标推送的作用是为了将目前 Dubbo 提供的指标进行进一步的存储、运算和可视化，目前第三方服务器只支持 Prometheus。Prometheus 是 CNCF 开源的一个应用于应用监控的系统。主要有三个模块组成，分别是获取数据，存储数据，数据查询。获取数据有 Pull 和 Push 两种方式，也是 Dubbo 接入的方式；存储数据 Prometheus 是用的时序数据库这里就不展开讲了；数据查询是其自定义的一套查询 IDL，可以接入 Grafana 这一类报警系统，当监控指标异常时候可以使用邮件报警或者电话报警。目前的设计：指标推送只有用户在设置了配置且配置 protocol 参数后才开启，若只开启指标聚合，则默认不推送指标。Promehteus Pull ServiceDiscovery：启动时根据配置将本机 IP、Port、MetricsURL 推送地址信息至中间层，暴露 HTTP ServiceDiscovery 供 Prometheus 读取，配置方式如 ，其中在 Pull 模式下 address 为可选参数，若不填则需用户手动在 Prometheus 配置文件中配置地址。 Prometheus Push Pushgateway：用户直接在 Dubbo 配置文件中配置 Prometheus Pushgateway 的地址即可其中 interval 代表推送间隔相关 Dubbo Metrics 功能我们预计会在 3.1.2 / 3.1.3 版本中正式 release 发布。服务治理与商业化Dubbo 3 的可观测性建设是 Dubbo 3 上云必不可少的一个环节。在 Dubbo 3 对标的商业化产品微服务引擎 MSE 中，针对 Dubbo 3 做了全方面的增强，以一种无侵入的方式增强 Dubbo 3 服务，使其具备完整的微服务治理能力。在建设 Dubbo 可观测性的同时，我们也在结合 OpenSergo 标准构建 Dubbo 3 的完整的服务治理体系。OpenSergo 在联合各个社区进行进一步的合作，希望通过社区来一起讨论与定义统一的服务治理标准。当前社区也在联合 bilibili、CloudWeGo 等企业、社区一起共建标准，也欢迎感兴趣的开发者、社区与企业一起加入到 OpenSergo 服务治理标准共建中。欢迎大家加入 OpenSergo 社区交流群（钉钉群）进行讨论：34826335
发表了文章
2022-10-28
可观测实践｜如何使用阿里云 Prometheus 观测 ECS 应用
作者：颍川引言Prometheus + Grafana 已经成为云原生时代的可观测性事实标准。我们使用 Prometheus 观测云原生时代的 Kubernetes 体系下的 Node、ApiServer、workload 等的基础 metric，同时通过 Prometheus Exporters 采集各种组件（如 Redis、Kafka 等）和业务应用的 metric，最后通过 Grafana 展示大盘、AlertManager 进行告警，实现了云原生 Kubernetes 体系下 metric 可观测闭环。由于大量非云原生的历史系统演进到云原生体系是个长时期过程，因此这些非云原生系统的可观测闭环也是我们必须解决的问题。我们很自然地想到“既然 Prometheus + Grafana 实现了云原生体系的 metric 可观测闭环，是否可以使用这套神器来解决非云原生体系应用的同样问题呢？”，答案是肯定的。本文介绍如何使用阿里云 Prometheus 来实现非 Kubernetes 应用（即 ECS 应用）的 metric 观测。ECS 应用的典型部署场景场景 1：纯公有云 VPC业务应用部署在一个或多个 VPC 内，每个 VPC 内购买了一批 ECS，在这些 ECS 上部署了基础组件（数据库和中间件等）和业务应用。此场景下，我们需要对这些 ECS OS（Linux 或 Windows）、基础组件和业务应用本身进行 metric 观测。场景 2：公有云 VPC+线下 IDC业务除了部署公有云 VPC 上外，还需要与线下 IDC 机房进行互通互联。通常，我们使用专线方式打通云上 VPC 和线下 IDC 机房。此场景下，我们期望有一套完整的 metric 观测平台，同时解决线上 VPC 和线下 IDC 的 metric 观测。场景 3：公有云 VPC+多云 ECS业务除了部署在阿里云 VPC 上外，还通过公网与其它云上的 ECS 进行互通互联。此场景下，我们也期望有一套完整的 metric 观测平台，实现一体化全局视角观测。自建 Prometheus 观测 ECS 应用的痛点自建 Prometheus 观测 ECS 应用，我们将面临的典型问题有：由于安全、组织管理等因素，用户业务通常部署在多个相互隔离的 VPC，需要在多个 VPC 内都重复、独立部署 Prometheus，导致部署和运维成本高。 每套完整的自建观测系统都需要安装并配置 Prometheus、Grafana、AlertManager 以及各组件 Exporter，过程复杂、实施周期长。 缺少与阿里云 ECS 无缝集成的服务发现（ServiceDiscovery）机制，无法根据 ECS 标签来灵活定义抓取 targets。如果自行实现类似功能，则需要使用 Golang 语言开发代码（调用阿里云 ECS POP 接口）、集成进开源 Prometheus 代码、编译打包后部署，实现门槛高、过程复杂、版本升级困难。 常用组件的开源 Grafana 大盘不够专业，缺少结合观测组件的原理和最佳实践进行深入定制。 缺少常用组件的告警项模板，需要用户自行研究、配置告警项，工作量大，且很可能缺少各组件领域的专业技术沉淀。 阿里云 Prometheus 监控的能力框架阿里云 Prometheus 监控[1]是一款全面对接开源 Prometheus 生态，支持类型丰富的组件观测，提供多种开箱即用的预置观测大盘，且提供全面托管的混合云/多云 Prometheus 服务。除了支持阿里云容器服务、自建 Kubernetes、Remote Write 外，阿里云 Prometheus 还提供混合云+多云 ECS 应用的 metric 观测能力；并且支持多实例聚合观测能力，实现 Prometheus 指标的统一查询，统一 Grafana 数据源和统一告警。其逻辑架构如下示意：对于 ECS 应用，阿里云 Prometheus 提供以下 metric 数据采集方式：托管 exporter：提供 MySQL、Redis 等数十种常见组件[2]（持续更新中）的托管部署。用户只需要在阿里云 Prometheus 控制台配置观测组件相关信息（如 IP 地址、端口等），即可实现 VPC 内 ECS 上这些组件的 metric 监控。由于线下 IDC 通过专线与 VPC 互通，因此托管 exporter 同时也能采集到线下 IDC 内的组件 metric。 非托管 exporter：对于我们暂未提供托管 exporter 的组件，或用户业务应用的自定义 metric，用户可以在 VPC 或 IDC 内部署自定义 exorter，然后在阿里云 Prometheus 控制台上配置自定义服务发现（ServiceDiscovery），最后阿里云 Prometheus 主动发现这些 exporter，并定时抓取和存储 metric。 Node/Windows exporter：它们是一类特殊的非托管 exporter，因为需要部署在每台 ECS 上，以便采集 ECS OS 上观测信息。阿里云 Prometheus 提供了 Node exporter 的原生支持，Windows exporter 原生支持也即将上线。ECS 应用场景下，自建 Prometheus 与阿里云 Prometheus 对比如何使用阿里云 Prometheus 观测 ECS 应用步骤 1：创建 VPC 实例登录 Prometheus 控制台[3]，选择新建 Prometheus 实例，根据界面提示，填写实例名、选择 VPC / VSwitch / SecurityGroup / Grafana 工作区，即可创建 VPC 实例成功。操作说明详见阿里云帮助中心文档[4]。步骤 2：接入组件监控目前阿里云 Prometheus 已支持 Node exporter、MySQL、Redis、ElasticSearch、Kafka、Nginx、MongoDB、PostgreSQL、RabbitMQ、RocketMQ、BlackBox 等组件观测。阿里云 Prometheus 天然内置支持了 static_configs和aliyun_sd_configs 两种最常用/实用的服务发现方式，方便用户进行组件观测目标 ECS 的配置。此处以 MySQL 为例，简要描述接入配置方法。登录 Prometheus 控制台后，进入已创建的 VPC 实例详情的集成中心界面，新建 MySQL 接入，填写 MySQL 监控名称、MySQL 地址、端口、用户名/密码等信息即可。详细操作步骤和说明，参见阿里云帮助中心文档[5]。步骤 3：查看大盘阿里云 Prometheus 无缝集成了共享版 Grafana 和专家版 Grafana，用户无需单独安装 Grafana，即可查看各个组件的观测大盘。接入需要监控的组件后，在集成中心点击对应组件图标的已安装 Exporter，可以看到该组件的大盘略缩图和链接，点击即可进入阿里云 Grafana，查看对应观测大盘。详见阿里云帮助中心文档[6]。步骤 4：配置告警进入 VPC 实例详情的集成中心界面，进入 MySQL 组件的告警界面，即可创建 Prometheus 告警规则，详见阿里云帮助中心文档[7]。阿里云 Prometheus 提供了免运维、开箱即用的 VPC（以及和 VPC 打通的线下 IDC 机房）内 ECS 的 OS、常见中间件、业务应用的 metric 观测能力，实现了一站式的云原生和非云原生环境的 metric 观测协同和闭环。同时我们正在持续升级和丰富常用组件的观测能力（如 Windows、JMX、ClickHouse、Jenkins、Process 等），敬请期待。关于阿里云 Prometheus 监控阿里云 Prometheus 服务是基于云原生可观测事实标准 - Prometheus 开源项目构建的全托管观测服务。默认集成常见云服务，兼容主流开源组件，全面覆盖业务观测/应用层观测/˙中间件观测/系统层观测。通过开箱即用的 Grafana 看板与智能告警功能，并全面优化探针性能与系统可用性，帮助企业快速搭建一站式指标可观测体系。助业务快速发现和定位问题，减轻故障给业务带来的影响，并免去系统搭建与日常维护工作量，有效提升运维观测效率。与此同时，阿里云 Prometheus 作为阿里云可观测套件的重要组成部分，与 Grafana 服务、链路追踪服务，形成指标存储分析、链路存储分析、异构构数据源集成的可观测数据层，同时通过标准的 PromQL 和 SQL，提供数据大盘展示，告警和数据探索能力。为 IT 成本管理、企业风险治理、智能运维、业务连续性保障等不同场景赋予数据价值，让可观测数据真正做到不止于观测。更具性价比的计费选择，Prometheus 包年包月相关链接[1] 阿里云Prometheus监控https://help.aliyun.com/document_detail/122123.html[2] 常见组件https://help.aliyun.com/document_detail/251830.html[3] 应用实时监控服务ARMShttps://arms.console.aliyun.com/#/home[4] Prometheus实例 for ECShttps://help.aliyun.com/document_detail/274450.html[5] 使用阿里云Prometheus监控MySQLhttps://help.aliyun.com/document_detail/161838.html[6] 集成中心https://help.aliyun.com/document_detail/427600.html[7] Prometheus告警规则https://help.aliyun.com/document_detail/331981.html
发表了文章
2022-10-28
可观测可回溯 | Continuous Profiling 实践解析
作者：虚镜概述Continuous Profiling 在软件开发生命周期的位置CI/CD 的概念非本文重点，不解释了。从上图可以看出。Continuous Profiling（持续性能分析，下文简称为 CP）是生产向开发进行反馈的非常重要的手段。发展历史CP 概念的起源于 Google 的论文[1]：Google Wide Profiling：A continuous Profiling infrastucture for data centers基本思路CP 意义可以分解为两个：性能分析(Profile)的意义：识别计算，存储，网络上的性能瓶颈问题，建立代码和性能瓶颈的关联性，从而协助开发者优化代码，解决瓶颈问题； 持续(Continuous)的意义：让性能分析贯穿应用的整个生命周期，从而解决非持续方案(如 ]on-demand)中无法抓到现场的问题。 Profiling 的基本思想  衡量程序性能最直观的方法就是通过响应时间（Response Time，简称 RT）。但仅仅知道程序的运行时间很难指导我们如何把程序优化地更快，我们想要更进一步地了解这段时间之内到底发生了什么。让我们先从一个例子开始，了解 Linux 下的时间统计告诉了用户什么信息：下面我们利用 Linux time 计算两件事情的时间消耗：生成一个 10M 的文件，随机生成数据；（IO 密集）对上一步生成的文件做个 CRC 计算；（CPU 密集） time 的输出告诉用户 3 个信息：real：总消耗时间user：用户态消耗时间sys：内核态消耗时 观察 time 的输出，可以看出 user + sys 不等于 real，这是因为程序并不是总是 CPU 上运行的，还可能因为 IO，Lock 等等原因处于睡眠，等待的状态，这段时间既不算在 user CPU time 也不算在 system CPU time。程序在 CPU 上执行的时间（即 user CPU time  + system CPU time）称为 CPU time（或 on-CPU time）；程序处于睡眠等状态的时间称为 off-CPU time（or blocked time）；程序实际运行的时间称为 wall clock time（挂钟时间）； time 的输出 real 对应的概念的是 wall clock time，因此可以看到：对于 IO 密集型的 workload（负载），off-CPU time 是不能忽略的；对于 CPU 密集型 workload（负载），on-CPU time 基本和 wall clock time 相等； 对于一个给定的线程（Linux 上称为轻量级进程）：wall clock time = CPU time + off CPU time因此 Profile 整体分为：On-CPU: where threads are spending time running on-CPU.Off-CPU: where time is spent waiting while blocked on I/O, locks, timers, paging/swapping, etc. 可以看到 Off-CPU 分析类型是一系统结果的汇总统计，因此也可以将 Off-CPU 因为引起睡眠或者等待的原因不同，可以进一步划分为 file profiling，socket profiling，lock profiling 等等类型。Continuous 的基本思想 持续（Continuous）相对的概念是按需（On-Demand）。按需（或者触发式）比较常见的问题就是无法精准的抓取现场从而导致一些偶发（难以复现）的问题无法被识别。比如上图这样一条曲线（不管它表达什么），反正是有一段异常（或者说和大部分情况不一样的情形），随着自然时间的流逝；用户发现这个异常的时候，曲线已经恢复了，因此无法在去回溯现场。这种情况下，我们发现了一段异常，但是没有更多细节，开发者就无法知道代码内部发生了什么，因此也无从谈起修复和改善代码了。持续则意味着贯穿整个程序的完整生命周期，不会漏掉任何一个历史上产生过的异常。Continuous+Profiling 带给开发者的意义是：在生产环节，永远知道代码的所有执行细节。理解 profiling用户交互和可视化 性能分析的展现形式通常以 Flame Graph 火焰图来表达：理解火焰图 对火焰图理解的本质是了解性能分析数据(profiling data)究竟是什么。性能分析数据(profiling data)就是堆栈统计数据。为了帮助读者理解，举个简单的例子：横坐标表达的一个数值，在不同的场景下，可以赋予不同的含义，比如：在 cpu profiling 上，表达花费时间多少；在 alloc profling 上，表达成内存大小；...... 纵坐标是表达是一个 stack trace。因此上图表达的含义和下面一组数据是一致的。每一行以空格分割，左边的是 stack trace，右边是数值。a();b();c() 1
a();b();d() 2
c();b() 3到这里，读者应该对性能分析(profiling)的工作原理有个感性的认识，性能分析的整体流程如图：因此实现 profiling 的关键点：获取堆栈数据（爬栈）：如何护获取问题点（瓶颈）点的堆栈数据；生成火焰图； 常见的 Profiling Tools（生成堆栈数据） 常见的工具如 Linux perf，eBPF profile，DTrace，SystemTap 等等，本文将这类用于获取堆栈数据工具统称为 Profiling Tools；Linux 这类工具的用法本文不多介绍，这类工具非常通用并且有效，但对于非C系开发者是没那么友好的。高级语言绝大部分应用开发者其实并不关心很低层次的内容，比如 page fault，numa banlance，context switch，L3 Cache miss 等问题，通常都不在应用开发者的知识图谱中。这部分内容的优化也不再本文的目标读者范围，因此不多叙述。对于 Profile Tools，我们可以将其分为两类：System Profile：which shows system code paths (eg, JVM GC, syscalls, TCP), but not Java methods. language Profile：These show language methods(eg java method), but usually not system code paths.JVM Profilegolang Profile.... 不难理解，Profiling Tools 能够爬栈就是因为在特定的代码里进行的 Hook 操作，这类操作一定会产生额外的开销。因此 Profiling Tools 会带来额外的开销（Overhead），不同类型的 Profiling 的 Hook 点不同，因此不同的性能分析类型会导致不同的 Overhead。很长一段时间，无法将 Profiling 带入生产环节最重要的阻塞点就是 Overhead 太高导致应用的业务逻辑受损严重。因此评价 Profiling Tools 是否适合上生产最重要的评估就是估算 Overhead。JVM Profiling上文提到的工具基本属于 System Profiling Tools 提供的能力，这部分工具的核心能力关注的是 system code paths；对于高级语言上一些特性，能力是不够强的。下面我们了解高级语言自身的 Profiling Tools 是如何帮助开发者来做性能优化的。golang 内置 pprof[2]java11 内置 JFR[3]其他高级语言有的有自身的工具，有的没有高级语言没有自身工具，这类通常可以借助 System Profiling Tools（如 perf 或者 ebpf）来实现性能分析。 以 java 为例子，认识下 java 程序运行的代码结构 ，如下图：对于 java 开发者而言，大部分场景是不考虑 JVM code，glibc code，kernel code 出问题的可能性的，这部分代码相对稳定，而且有稳定的组织去推动解决。因此 JVM Profiling 要表达的核心其实是：爬堆栈，只爬 Java code 这一层次（java stack），这个是大部分应用开发者关注的核心部分，对于下面的部分（native stack）则不在 java 开发者关心的范围。JVM 还有一个特征，就是把 Linux 底层的概念屏蔽，替换成自己的概念体系，比如：java 开发者更关心 java 线程状态机而不是 JVM 进程的进程状态机；java 开发者更关心 java heap，stack，nio 等内存统计而不是 native heap，native stack 以及 rss，pagecache 的统计；java 开发者关心 CMS 或 G1 垃圾回收情况而不是 Page Reclaim；java 开发者更关心 synchronized，JUC 锁，而不是 OS 锁； 因此，JVM Profiling中的性能分析类型会更贴近 java 开发者的概念体系，而不是 system profile 关心的内容。举个例子，相较于 on-cpu profiling，作为 java 开发者，你是否会关心 JVM code 或者 glibc 是否存在问题，也许会，但是不可否认，这是非常少见的场景，更多关心的还是 Java code 这一层的问题，因此 JVM Profiling 的 cpu profiling 表达的是 on-cpu profiling for java code。同理对于内存申请速率 alloc profiling：system alloc profiling 关心的是用户态内存分配器（malloc 分配器或者其他的）的分配速度；JVM alloc profiling 关心的则是 TLAB 分配器的分配速度；JVM Profiling 和 System profiling 关注点是有不同的：JVM Profiling 关注的是 JVM 上的性能，而不是贯穿从用户态到内核态的整个流程，这是非常重要的一个区别，其他高级语言也是类似的情况。JVM Profiling Tools JAVA 社区有非常丰富的 JVM Profiling Tools：Async-profiler[4]：jetbrains IntelliJ IDEA[5]alibaba ArthasJProfilerHonest profiler[6]Uber JVM Profiler[7]Fight Recorder[8]JEP 349: JFR Event Streaming[9]1. JFRJFR (Java Flight Recorder)是深度嵌入在 JVM 中的功能强大的应用问题诊断与性能剖析工具，在其低开销的加持下，JFR 可在生产环境持续开启。JFR 最开始是 JRockit 和 Oracle JDK 中的商业化特性，Oracle 在 Java 11 对其进行了开源。2019 年阿里巴巴作为主要贡献者，联合 Azul、Datadog、RedHat 等公司，一起将 JFR 移植进 OpenJDK 8 中。目前 Alibaba Dragonwell 8 和 11 中也包含完整的 JFR 功能。JFR 的事件包括下面几类信息：一般信息：关于虚拟机、操作系统和记录的一般信息；内存：关于内存管理和垃圾收集的信息；代码：关于方法、异常错误、编译和类加载的信息；线程：关于应用程序和线程和锁的信息；I/O：关于文件和套接字输入、输出的信息；系统：关于正在运行 Java 虚拟机的系统、进程和环境变量的信息；类型：关于记录中的事件类型的信息。 通过 JFR 的 Event，可以覆盖几乎所有需要进行性能分析的场景:on cpu profilingalloc profilinglock profilingfile read(write) profilingsocket read(write) profiling...... JFR 非常优秀，但是在国内环境，依然存在适配问题：java 迭代速度太快了，java 已经发布了 17 了，但是国内不乏依旧跑在 java8 上的应用；而 JFR 从 11backport 到的最低版本是 8u272（8u262 只是有 JFR 的代码，但是不可用），这就导致了 8u272 之前的 java 没办法用 JFR；JFR 本身也在发展迭代中，如 jdk.ObjectAllocationInNewTLAB。jdk.ObjectAllocationOutsideTLAB 在 java16 之前的实现产生的 overhead 过高导致根本不适合在生产环境常态化采集；2. Async Profiler组合使用 Perf_events 和 AsyncGetCallTrace 解决 JVM SafePoint Bias 问题，解决了 overhead 高问题。主流的 java IDE IntelliJ IDEA 和 alibaba 的 Arthas 提供的 profiling 能力通过 Async-profiler 实现的。因此 Arms 的方案里面也借助了这个工具。Arms Continuous JVM Profiler为了更好的为用户提供价值，Arms 联合 Alibaba Dragonwell 团队，基于业界主流设计，进行了深度优化，设计出了全新的采集、分析技术方案。其中采集方案兼顾性能和财务成本，优先使用更成熟和完善的 JFR，但在JFR是商业化特性的 OracleJDK 或 Async-Profiler 性能更优的情况下，采用 Async-Profiler 作为替代方案，并且是全自动的，用户无需关注配置细节。Support listOpenJDK说明：jdk8u272 以下的版本选择 Async-Profilier 和核心原因是没有 JFR 可用；jdk8u272 之后直到 jdk16 之前，JFR 实现的 alloc 相关事件的开销比较大，因此选择 Async-Profilier；其他情况，能用 JFR 都用 JFR Oracle JDK说明：OracleJDK8 上 JFR 是商业特性，因此选择 Async-ProfilierOracleJDK11 之后的版本的 JFR 是开源特性，alloc 选择 Async-Profilier 的原因一样是因为 JFR 实现的 alloc 相关事件的开销比较大，因此选择 Async-Profilier其他情况，能用 JFR 都用 JFR。 性能分析类型目前 Arms 产品化部分包含 2 类 3 个性能分析类型，解决 java 开发者最常见的 CPU 和内存方面的问题：CPU Time：全称 On-CPU Profiling In Java Code，统计 java 代码占用 CPU 时间；Allocations：统计 TLAB 分配次数Allocated Memory：统计 TLAB 分配内存总量，单位 bytes；产品的 roadmap 中后续会考虑搞 lock，file，socket 等等性能分析的能力，这中间的主要核心考量是每一种实现对应的 overhead 评估和实现约束情况。OverHead前文说过评价一款 Profiling Tools 是否适合上生产主要是看额外开销是否足够小，Arms 提供的能力整体依赖于 Async-profiler 以及 JFR，这两个工具的开销是关键：Async-profiler：官方未给出数据性结论，只是说开销很低；JFR：按照缺省配置，整体性能下降低于 2%。[10] 因此 Async-profiler 和 Oracle 官方并没有更细节的数据，因此我们实际在进行一些测试，供参考：压力测试模型 压力测试模型如下图示：测试代码包含数据库查询、JSON 序列化、日志文件顺序写、网络收发等。压力测试客户端 使用 wrk 做并发测试，命令如下：wrk -t2 -d 10 -c 10http://172.22.230.30:8088/queryRandom客户端的压力的总体目标是把服务端的 CPU 压力控制在 50%左右。压力测试结果这里评估对应用的影响主要通过 QPS（吞吐）和 RT（时延）作为标准（系统 CPU 压力控制在 50%左右）：JFR Alloc 依赖的两个 JFR Event 有非常严重的性能问题：1. jdk.ObjectAllocationInNewTLAB2. jdk.ObjectAllocationOutsideTLAB因此本测试不包含 JFR Alloc；JFR 的这个问题直到 JAVA15 以后才得到解决。我们还做了一组极限压测，将 CPU 全部打满，这种情况的出的结论为 QPS 和 RT 的开销低于 10%。这种极端情况也是存在，数据供参考。最佳实践路径CPU 高排查路径1. JVM 程序 CPU 高的传统方式我们聚焦 User time 高的情况，java 开发者的排查流程：1.定位 CPU 高的 java 进程的 pid，top；2.定位具体线程 id，top -p ${pid} -H；3.计算线程 ID 的 16 进制值，printf "%x\n" ${线程 ID}；4.根据 stack trace，定位具体瓶颈点，jstack ${pid}| grep ${线程 ID} -A 10；5.查看 stack trace，识别代码，解决问题。2. 利用 Arms Continuous Java Profile 解决 JVM user 高的问题1. 确定是 JVM 业务进程导致 user CPU 升高；2. 找到 CPU 变高时间点，打开火焰图和人点方法统计，识别代码消耗，解决问题。直接定位到方法，并且把每个方法的耗时统计出来，如上图左边所示的热点方法。过滤掉线程等相关条件（当 CPU 瓶颈是因为用户代码导致的，开发者是不需要特别关心线程的，直接将所有线程中的 stack trace 全部进行统计汇总，然后按照每个方法的 Response time 进行汇总）。频繁 GC 第一步，开启压力程序，同时设定 heap 大小为 128M（-Xms128m-Xmx128m）第二步，压力程序的 gc 日志部分如下图，非常频繁的进行 gc 操作；85.013: [GC (Allocation Failure) [PSYoungGen: 29518K->3328K(36352K)] 47116K->21252K(123904K), 0.0065644 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
89.993: [GC (Allocation Failure) [PSYoungGen: 31736K->3328K(35840K)] 49660K->21260K(123392K), 0.0061679 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
94.062: [GC (Allocation Failure) [PSYoungGen: 31608K->3232K(36864K)] 49540K->21196K(124416K), 0.0070968 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
99.090: [GC (Allocation Failure) [PSYoungGen: 32934K->1344K(36864K)] 50898K->19332K(124416K), 0.0051987 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
103.114: [GC (Allocation Failure) [PSYoungGen: 29079K->2368K(37376K)] 47067K->20432K(124928K), 0.0056821 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
108.134: [GC (Allocation Failure) [PSYoungGen: 32528K->1344K(36864K)] 50592K->19464K(124416K), 0.0067361 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
113.086: [GC (Allocation Failure) [PSYoungGen: 31748K->3264K(37376K)] 49869K->21503K(124928K), 0.0059270 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
117.178: [GC (Allocation Failure) [PSYoungGen: 31709K->3328K(37376K)] 49948K->21591K(124928K), 0.0049904 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
121.192: [GC (Allocation Failure) [PSYoungGen: 32615K->3607K(37376K)] 50878K->21878K(124928K), 0.0076185 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
126.217: [GC (Allocation Failure) [PSYoungGen: 33278K->1312K(37376K)] 51549K->19615K(124928K), 0.0045188 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
131.159: [GC (Allocation Failure) [PSYoungGen: 32080K->3488K(37376K)] 50383K->21799K(124928K), 0.0046074 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
135.256: [GC (Allocation Failure) [PSYoungGen: 33274K->3488K(37376K)] 51585K->21807K(124928K), 0.0044789 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
140.276: [GC (Allocation Failure) [PSYoungGen: 33871K->1472K(37888K)] 52190K->19799K(125440K), 0.0043370 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
145.296: [GC (Allocation Failure) [PSYoungGen: 32925K->1472K(37888K)] 51252K->19799K(125440K), 0.0044817 secs] [Times: user=0.01 sys=0.01, real=0.00 secs]
150.321: [GC (Allocation Failure) [PSYoungGen: 32944K->1440K(37888K)] 51271K->19767K(125440K), 0.0041987 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
155.345: [GC (Allocation Failure) [PSYoungGen: 32896K->1472K(37888K)] 51223K->19799K(125440K), 0.0045417 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
160.374: [GC (Allocation Failure) [PSYoungGen: 33168K->1568K(37888K)] 51495K->19903K(125440K), 0.0051167 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
165.261: [GC (Allocation Failure) [PSYoungGen: 33469K->3616K(37888K)] 51804K->21959K(125440K), 0.0048307 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]
170.286: [GC (Allocation Failure) [PSYoungGen: 35284K->3552K(37888K)] 53627K->21895K(125440K), 0.0143238 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
175.316: [GC (Allocation Failure) [PSYoungGen: 35008K->3584K(37888K)] 53351K->21927K(125440K), 0.0060600 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
180.338: [GC (Allocation Failure) [PSYoungGen: 35061K->3584K(37888K)] 53404K->21935K(125440K), 0.0044581 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
185.359: [GC (Allocation Failure) [PSYoungGen: 35044K->3584K(35840K)] 53395K->21935K(123392K), 0.0054453 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
190.384: [GC (Allocation Failure) [PSYoungGen: 35314K->3584K(37376K)] 53665K->21943K(124928K), 0.0050957 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
194.502: [GC (Allocation Failure) [PSYoungGen: 33085K->3584K(37376K)] 51444K->22007K(124928K), 0.0045832 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
199.526: [GC (Allocation Failure) [PSYoungGen: 33952K->1600K(37888K)] 52375K->20039K(125440K), 0.0051886 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]第三步，利用 Allocated  Memory 定位 collect-heap 内存是的主要申请是哪些方法：第四步，优化代码。Roadmap1. 诊断类型增强；（file io，socket io，lock 等等）2. 聚合能力增强；（merge 和 diff）3. 查询能力增强；（预处理能力，支持长时间聚合）4. 火焰图交互增强（StackFrame 表达更多含义，当前仅仅包含一个简单字符串）；5. RPC tracing 和 profiling 联动；6. 多语言（其他高级语言适配）；参考链接[1] Google 论文：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36575.pdf[2] golang内置pprof：https://go.dev/blog/pprof[3] java11内置JFR：https://docs.oracle.com/en/java/java-components/jdk-mission-control/8/user-guide/using-jdk-flight-recorder.html#GUID-D38849B6-61C7-4ED6-A395-EA4BC32A9FD6[4] Async-profiler：https://github.com/jvm-profiling-tools/async-profiler[5] jetbrains IntelliJ IDEA ：https://www.jetbrains.com/help/idea/async-profiler.html[6] Honest profiler：https://github.com/jvm-profiling-tools/honest-profiler/[7] Uber JVM Profilerhttps://github.com/uber-common/jvm-profiler[8] Fight Recorderhttps://docs.oracle.com/en/java/java-components/jdk-mission-control/8/user-guide/using-jdk-flight-recorder.html#GUID-D38849B6-61C7-4ED6-A395-EA4BC32A9FD6[9] JEP 349: JFR Event Streaminghttps://openjdk.org/jeps/349[10] JFR Overheadhttps://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/performissues001.html
发表了文章
2022-10-28
KubeVela 插件指南：轻松扩展你的平台专属能力
作者：姜洪烨KubeVela 插件（addon）可以方便地扩展 KubeVela 的能力。正如我们所知，KubeVela 是一个微内核高度可扩展的平台，用户可以通过模块定义（Definition）[1]扩展 KubeVela 的系统能力，而 KubeVela 插件正是方便将这些自定义扩展及其依赖打包并分发的核心功能。不仅如此，KubeVela 社区的插件中心也在逐渐壮大，如今已经有超过 50 款插件，涵盖可观测性、微服务、FinOps、云资源、安全等大量场景功能。本文将会全方位介绍 KubeVela 插件的核心机制，教你如何编写一个自定义插件。在最后，我们将展示最终用户使用插件的体验，以及插件将如何融入到 KubeVela 平台，为用户提供一致的体验。为什么要使用 KubeVela 插件用户使用插件的一个典型方法是通过 KubeVela 团队维护的插件中心（addon catalog）[2] ，它包含了 KubeVela 团队与社区开发者精心编写的系统扩展功能，并以插件的形式发布于插件中心，这样你可以一键下载并安装这些插件。例如安装 FluxCD 可以快速给你的 KubeVela Application 提供部署 Helm Chart 的能力。相较于使用 KubeVela 的插件功能，如果你自己的内部平台想要集成一个云原生的功能，你大概会这么做：通过 Helm Chart 或者下载 yaml 文件手动安装 FluxCD 或类似的 CRD Operator。编写系统集成的代码，让用户界面可以通过统一的方式使用 FluxCD 等 CRD 的功能，在 KubeVela 系统中就是通过编写模块定义（OAM Definition）完成。 实际上，在 KubeVela 1.1 版本之前，我们也是通过类似的方式完成的。这会带来如下问题：操作繁琐：用户需要手动查阅文档如何安装 FluxCD 并处理可能发生的错误资源分散：用户需要下载不同的文件，既需要安装 Helm 安装 FluxCD 还需要下载模块定义等系统扩展的集成配置难以分发复用：用户需要手动下载模块定义就注定了这些资源难以以一个统一的方式分发给用户，也无法形成社区生态让不同的用户可以享受社区便利缺少多集群支持：KubeVela 将多集群交付作为一等公民，而这样的手动安装系统扩展的方式显然难以维护多集群的环境无版本管理：用户需要手动管理模块定义和 Controller 之间的版本 而 KubeVela 插件就是为了逐一解决这些问题而诞生的。KubeVela 插件是如何工作的KubeVela 的插件主要包含两部分：一部分是安装能力的提供者，通常是一个 CRD Operator/Controller。这个安装过程实质上就是运行一个 OAM 应用，addon 交付中所使用的功能与普通应用能力完全等价。另一部分就是扩展能力跟 KubeVela 体系的粘合层，也就是模块定义和其他的一些集成配置。OAM 模块定义为用户提供了插件扩展出的组件、运维特征以及工作流步骤等功能，也帮助 CRD Operator 提供用户友好的抽象，使得最终用户无需理解复杂的 CRD 参数，只需要根据最佳实践提供必要的参数。插件的工作机制如上图所示，KubeVela 的应用具备多集群交付的能力，所以也能帮助插件中的 CRD Operator 部署到这些集群中。模块定义文件仅需要在控制面被 KubeVela 使用，所以无需部署到被管控的集群中。提示一旦插件被安装，就会创建一个 KubeVela 应用，包含所有的相关资源和配置，这些配置都会设置 KubeVela 应用对外作为 OwnerReference（父节点）。当我们想要卸载一个插件时，只需要删除这个应用，Kubernetes 提供的资源回收机制会自动将标记了 OwnerReference 的资源一并删除。例如一个 Redis 插件，它能让用户在自己的应用中使用 Redis 集群类型的组件（Component），这样可以快速创建 Redis 集群。那么这个插件至少会包括一个 Redis Operator 来提供创建 Redis 集群的能力（通过 Application 描述），还有一个组件的模块定义 （ComponentDefinition） 来提供 Redis 集群的组件类型。所有整个插件的安装过程会将 Redis Operator 放在一个 KubeVela 应用中下发到多集群，而组件定义和 UI 扩展等配置文件则只部署到控制面集群并设置应用对象为 OwnerReference。创建自己的插件提示为保证以下内容功能全部可用，请确保你的 KubeVela 版本 为 v1.5+。我们将以 Redis 插件为例，讲解如何从头创建一个 KubeVela 插件的实际过程。本次完整的 Redis 插件代码见文末参考[3]。提示在这里我们会尽可能全面的介绍制作插件中涉及的核心知识，但是作为一个介绍性博客，我们会尽量避免讨论过深的细节以免篇幅过于膨胀，了解完整的功能及细节可以参考自定义插件文档[4]。首先我们需要思考我们要创建的插件有什么作用？例如我们假设 Redis 插件可以提供 redis-failover 类型的 Component，这样用户只需在 Application 中定义一个redis-failover  Component 即可快速创建 Redis 集群。然后考虑如何达到这个目的？要提供 redis-failover 类型的 Component 我们需要定义一个 ComponentDefinition ；要提供创建 Redis 集群的能力支持，我们可以使用 Redis Operator[5]。那至此我们的大目标就明确了：编写插件的应用描述文件（OAM Application），这将会用于安装 Redis Operator （完整代码可以到插件中心的 template.cue[6]及resources/目录[7]查看。）编写 redis-failover 类型的 ComponentDefinition[8]（完整代码请查看 definitions/目录[9]） 不过在开始编写之前，我们首先需要了解一个 KubeVela 插件的目录结构。后续我们会在编写的过程中详细说明每个文件的作用，在这里只需大致了解有哪些文件即可。提示命令行工具 vela addon init 可以帮助你创建目录结构的初始化脚手架。redis-operator/
├── definitions
│ └── redis-failover.cue
├── resources
│ ├── crd.yaml
│ ├── redis-operator.cue
│ └── topology.cue
├── metadata.yaml
├── parameter.cue
├── README.md
└── template.cue让我们逐一来解释它们：1. redis-operator/ 是目录名，同时也是插件名称，请保持一致。2. definitions/ 用于存放模块定义, 例如 TraitDefinition 和 ComponentDefinition。3. redis-failover.cue 定义我们编写的 redis-failover 组件类型，包含了用户如何使用这个组件的参数以及这个组件与底层资源交互的细节。4. resources/ 用于存放资源文件, 之后会在 template.cue 中使用他们共同组成一个 KubeVela 应用来部署插件。5. crd.yaml 是 Redis Operator 的 Kubernetes 自定义资源定义，在 resources/ 文件夹中的 YAML 文件会被直接部署到集群中。6. redis-operator.cue 一个 web-service 类型的 Component ，用于安装 Redis Operator。7. topology.cue 是可选的，帮助 KubeVela 建立应用所纳管资源的拓扑关系。8. metadata.yaml 是插件的元数据，包含插件名称、版本、维护人等，为插件中心提供了概览信息。9. parameter.cue 插件参数定义，用户可以利用这些参数在插件安装时做轻量级自定义。10. README.md 提供给最终用户阅读，包含插件使用指南等。11. template.cue 定义插件最终部署时的完整应用形态，包含一个 OAM 应用模板以及对其他资源对象的引用。提示在插件中制作中我们会广泛使用 CUE 语言来编排配置，如果对 CUE 不熟悉，可以花 10 分钟快速查阅入门指南有一个基本了解。parameter.cueparameter: {
//+usage=Redis Operator image.
image: *"quay.io/spotahome/redis-operator:v1.1.0" | string
// 其余省略
}在 parameter.cue 中定义的参数都是用户可以自定义的（类似于 Helm Values），后续在 template.cue 或者 resources 中可以通过 parameter.<parameter-name> 访问参数。在我们的例子中，用户可以自定义 image ，这样后续我们创建 Redis Operator (redis-operator.cue) 的时候可以通过 parameter.image 使用用户指定的容器镜像。参数不仅可以给用户预留安装时的自定义输入，还可以作为安装时的条件进行部分安装。比如fluxcd 插件有一个参数叫 onlyHelmComponents[10]，它的作用就是可以帮助用户只部署用于安装 Helm Chart 的组件能力，而其他控制器就可以不安装。如果你对于实现细节感兴趣，可以参考fluxcd 插件的部分配置[11]。在设计提供什么参数供用户自定义插件安装时，我们也应该遵循一下这些最佳实践来为用户提供更好的使用体验。最佳实践不要在 parameter.cue 中提供大量的细节参数，将大量细节抽象出少量参数供用户调节是一个更好的做法为参数提供默认值（如样例中的 image 参数）或将参数标记为可选（如样例的 clusters 参数），确保用户仅使用默认值可以得到一个可用的配置为参数提供使用说明（通过注释标记实现，见样例）尽量保持插件不同版本间的参数一致，防止因为升级导致不兼容template.cue 和 resources/ 目录这是存放我们应用描述文件的地方，即一个 OAM Application 。这描述了实际的插件安装过程。我们主要会在这里包含 Redis Operator ，给集群提供管理 Redis 集群的能力。template.cue 和 resources/ 目录本质上是相同的，都是构成 KubeVela 应用的组成部分，且都是在同一个 package 下的 CUE 文件。那为什么需要 resources 目录呢？除去历史原因，这主要是为了可读性的考虑，在 Application 中包含大量资源的时候 template.cue 可能变得很长，这时我们可以把资源放置在 resource 中增加可读性。一般来说，我们将 Application 的框架放在 template.cue 中，将 Application 内部的 Components、Traits 等信息放在 resource 目录中。template.cue  template.cue 定义了应用的框架，绝大多数内容都是固定写法，具体的作用可以参考代码块中的注释。// template.cue 应用描述文件
// package 名称需要与 resources 目录中 cue 的 package 一致，方便引用 resources 目录中的内容
package main
// Application 模板中多数字段均为固定写法，你需要注意的只有 spec.components
output: {
// 这是一个经典的 OAM Application
apiVersion: "core.oam.dev/v1beta1"
kind: "Application"
// 不需要 metadata
spec: {
components: [
// 创建 Redis Operator
redisOperator // 定义于 resources/redis-operator.cue 中
policies: [
// 这里会指定安装插件的 namespace ，是否安装至子集群等
// 多为固定写法，无需记忆，可查阅本次样例的完整代码
// https://github.com/kubevela/catalog/blob/master/experimental/addons/redis-operator/template.cue
// 文档可参照 https://kubevela.net/zh/docs/end-user/policies/references
// 定义资源关联规则，用于将资源粘合在一起。后续会着重介绍
// Documentation: https://kubevela.net/zh/docs/reference/topology-rule
outputs: topology: resourceTopology // 定义于 resources/topology.cue 中在插件安装时，系统主要关注两个关键字：一是 output 字段，定义了插件对应的应用，在应用内部 spec.components 定义了部署的组件，在我们的例子中引用了存放在 resources/ 目录中的 redisOperator 组件。output 中的 Application 对象不是严格的 Kubernetes 对象，其中 metadata 里的内容（主要是插件名称）会被插件安装的过程自动注入。 另一个是 outputs 字段，定义了除了常规应用之外的配置，任何你想要跟插件一同部署的额外 Kubernetes 对象都可以定义在这里。请注意 outputs 中的这些对象必须遵循 Kubernetes API。 resources/ 资源文件 我们这里使用一个webservice类型的 Component 来安装 Redis Operator。当然，如果你可以接受依赖 FluxCD 的话，你也可以使用 helm 类型的 Component 直接安装一个 Helm Chart（因为 helm 类型的 Component 主要由 FluxCD 插件提供）。不过编写 addon 的一个原则是尽量减少外部依赖，所以我们这里使用 KubeVela 内置的 webservice 类型，而不是 helm。// resources/redis-operator.cue
// package 名称与 template.cue 一致，方便在 template.cue 中引用以下的 redisOperator
package main
redisOperator: {
// 这是 OAM Application 中的 Component ，它将会创建一个 Redis Operator
// https://kubevela.net/zh/docs/end-user/components/references
name: "redis-operator"
type: "webservice"
properties: {
// Redis Operator 镜像名称，parameter.image 即在 parameter.cue 中用户可自定义的参数
image: parameter.image
imagePullPolicy: "IfNotPresent"
traits: [
// 略
}你可以阅读代码块中的注释了解字段的具体作用。KubeVela 提供的资源粘合能力 值得注意的一个功能是资源关联规则 (Resource Topology)[12]。虽然它不是必须的，但是它能帮助 KubeVela 建立应用所纳管资源的拓扑关系。这就是 KubeVela 如何将各种各样的资源粘合成 Application 的。这在我们使用 Kubernetes 自定义资源（CR）的时候特别有用。// resources/topology.cue
package main
import "encoding/json"
resourceTopology: {
apiVersion: "v1"
kind: "ConfigMap"
metadata: {
name: "redis-operator-topology"
namespace: "vela-system"
labels: {
"rules.oam.dev/resources": "true"
"rules.oam.dev/resource-format": "json"
data: rules: json.Marshal([{
parentResourceType: {
group: "databases.spotahome.com"
kind: "RedisFailover"
// RedisFailover CR 会创建以下三类资源
childrenResourceType: [
apiVersion: "apps/v1"
kind: "StatefulSet"
},
// KubeVela 内置 Deployment 等资源的拓扑，因此无需继续向下编写
apiVersion: "apps/v1"
kind: "Deployment"
},
apiVersion: "v1"
kind: "Service"
},
}])
}在本例中，redis-failover 类型的 Component 会创建一个 CR ，名为 RedisFailover 。但是在没有资源关联规则的情况下，假设在你的 Application 中使用了 RedisFailover ，虽然我们知道 RedisFailover 管控了数个 Redis Deployment ，但是 KubeVela 并不知道 RedisFailover 之下有 Deployment 。这时我们可以通过 资源关联规则 将我们对于 RedisFailover 的了解告诉 KubeVela，这样 KubeVela 可以帮助我们建立起整个应用下面纳管资源的拓扑层级关系。此时你将获得 KubeVela 提供的许多有用功能，效果见运行插件[13]。提示资源的拓扑关联功能给我们带来了许多有用的功能，最重要的是为 KubeVela 最终用户使用扩展能力提供了统一体验：VelaUX 资源拓扑视图，从应用到底层资源 Pod 的关联关系一应俱全，包括多集群统一的 vela exec 命令可以在不同应用组件类型关联的底层容器中执行命令，包括多集群统一的 vela port-forward 转发不同类型应用组件关联的底层容器端口，包括多集群统一的 vela log 查看不同类型应用组件关联的底层容器日志，包括多集群统一的 vela status --pod/--endpoint 查看不同类型应用组件关联的底层容器日志，获得可供访问的地址等，包括多集群definitions/ 目录Definitions 目录存放 KubeVela 模块定义（Definition）[14]，包括组件定义（ComponentDefinition）、策略定义（TraitDefinition）等。这是插件中最重要的部分，因为它包含了最终用户安装这个插件以后可以获得哪些功能。有了这里定义的组件、运维特征、工作流等类型，最终用户就可以在应用中使用他们了。在插件中编写模块定义跟常规的编写流程一致，这是一个很大的话题，在这里我们就不详细展开了。你可以通过阅读模块定义对应的文档了解其中的细节：自定义组件 Component Definition[15]自定义运维特征 Trait Definition[16]自定义策略 Policy Definition[17]自定义工作流步骤 Workflow Step Definition。[18] 在本例中，我们编写 Redis 组件类型主要参照自定义组件[19]与 Redis Operator 使用文档[20]，我们将组件类型命名为 redis-failover，它会创建一个 RedisFailover 的 CR ，这样刚刚添加的 Redis Operator 就可以帮助创建 Redis 集群，见文末完整代码[21]。metadata.yaml这里包含了插件的元数据，即插件的名称、版本、系统要求等，可以参考文末文档[22]。需要注意的是，本次介绍的为 KubeVela v1.5 之后的新写法，因此需要避免使用某些不兼容的元数据字段，以下样例中包含了所有的可用元数据。提示例如传统的 deployTo.runtimeCluster （安装至子集群）等元数据在新写法中已有代替（使用 topology Policy），应当使用新写法。可见完整代码中的 template.cue[23]# 插件名称，与目录名一致
name: redis-operator
# 插件描述
description: Redis Operator creates/configures/manages high availability redis with sentinel automatic failover atop Kubernetes.
# 展示用标签
tags:
- redis
# 插件版本
version: 0.0.1
# 展示用图标
icon: https://xxx.com
# 插件所包含项目的官网地址
url: https://github.com/spotahome/redis-operator
# 可能依赖的其他插件，例如 fluxcd
dependencies: []
# 系统版本要求
system:
vela: ">=v1.5.0"
kubernetes: ">=1.19"运行插件至此我们已经将插件的主要部分编写完成，下载文末完整代码[24]补全部分细节后，即可尝试运行。下载得到 redis-operator 目录后，我们可以通过 vela addon enable redis-operator 安装本地的 redis-operator 插件，这种本地安装插件的方式也可以方便你再制作时做一些调试。安装完成后就可以参考插件的 README[25]试用我们的 Redis 插件了！提示这里也体现出插件的 README 的重要性，其中需要包括插件的作用、详细使用指南等，确保用户可以快速上手。​在用户使用你编写的插件时，只需如下 4 行 yaml 即可在 Application 中创建包含 3 个 Node 的高可用 Redis 集群！相比于手动安装 Redis Operator 并创建 CR ，甚至逐一手动配置 Redis 集群，插件的方式极大地方便了用户。apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: redis-operator-sample
spec:
components:
# This component is provided by redis-operator addon.
# In this example, 2 redis instance and 2 sentinel instance
# will be created.
- type: redis-failover
name: ha-redis
properties:
# You can increase/decrease this later to add/remove instances.
replicas: 3只需 apply 仅仅数行的 yaml 文件，我们就轻松创建了如下图所示的整个复杂的资源。并且由于我们编写了资源关联规则 (Resource Topology) ，用户可以通过 VelaUX 轻松获得刚刚创建的 Redis 集群的资源拓扑状态，了解 Application 底层资源的运行状况，不再受限于 Application Component 级别的可观测性。如图我们能直接观测到整个 Application 的拓扑，直至每个 Redis Pod ，可见图中部分 Pod 仍在准备中：在执行 vela exec/log/port-forward 等命令时也可以精确地看到 Application 底层包含的资源（即支撑 Redis 集群的 3 个 Redis Pod 和 3 个 Sentinel Pod）。如果你在使用单集群，乍一看你可能不会觉得 exec 进一个 Pod 是很特殊的功能。但是一旦考虑到多集群，能够在横跨多个集群的资源中跟单集群一样以统一的方式进行选择查看能够极大的节省时间。使用 vela status 命令能获取这个 Application 的运行状态，有了资源关联规则后可以更进一步，直接通过 vela 寻找出 Redis Sentinel 的 Endpoint 来访问 Redis 集群：结语通过本文，相信你已经了解插件的作用及制作插件的要点。通过插件体系，我们将获得如下优势：将平台的能力打包成一个易于安装、便于分发复用、且可以形成社区生态的插件市场。充分复用 CUE 和 KubeVela 应用通过的强大能力，将基础设施资源灵活定义并进行多集群分发。无论扩展的资源类型是什么，均可以接入应用体系，为最终用户提供一致的体验。最后，如果你成功制作了属于自己的插件，KubeVela 社区非常欢迎开发者贡献插件至插件中心[26]，这样你的插件还能够被其他 KubeVela 社区用户发现并使用！您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节：项目代码库：github.com/oam-dev/kubevela 欢迎 Star/Watch/Fork！项目官方主页与文档：kubevela.io ，从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢迎开发者进行翻译。项目钉钉群：23310022；Slack：CNCF #kubevela Channel加入微信群：请先添加以下 maintainer 微信号，表明进入KubeVela用户群： 戳此处：查看 KubeVela 项目官网！！相关链接[1] 模块定义（Definition）https://kubevela.net/zh/docs/platform-engineers/oam/x-definition[2] 插件中心（addon catalog）https://github.com/kubevela/catalog[3] catalog/redis-operatorhttps://github.com/kubevela/catalog/tree/master/experimental/addons/redis-operator[4] 自定义插件文档https://kubevela.net/zh/docs/platform-engineers/addon/intro[5] Redis Operatorhttps://github.com/spotahome/redis-operator[6] template.cuehttps://github.com/kubevela/catalog/blob/master/experimental/addons/redis-operator/template.cue[7] resources/https://github.com/kubevela/catalog/tree/master/experimental/addons/redis-operator/resources[8] ComponentDefinition https://kubevela.net/zh/docs/platform-engineers/components/custom-component[9] definitions/目录https://github.com/kubevela/catalog/tree/master/experimental/addons/redis-operator/definitions[10] onlyHelmComponentshttps://github.com/kubevela/catalog/blob/master/addons/fluxcd/parameter.cue[11] fluxcd 插件部分配置https://github.com/kubevela/catalog/blob/master/addons/fluxcd/template.cue#L25[12] 资源关联规则 (Resource Topology) https://kubevela.net/zh/docs/reference/topology-rule[13] 运行插件https://kubevela.io/zh/blog/2022/10/18/building-addon-introduction#%E8%BF%90%E8%A1%8C%E6%8F%92%E4%BB%B6[14] 模块定义（Definition）https://kubevela.io/docs/getting-started/definition[15] 自定义组件 Component Definitionhttps://kubevela.io/docs/platform-engineers/components/custom-component[16] 自定义运维特征 Trait Definitionhttps://kubevela.io/docs/platform-engineers/traits/customize-trait[17] 自定义策略 Policy Definitionhttps://kubevela.io/docs/platform-engineers/policy/custom-policy[18] 自定义工作流步骤 Workflow Step Definitionhttps://kubevela.io/docs/platform-engineers/workflow/workflow[19] 自定义组件https://kubevela.net/zh/docs/platform-engineers/components/custom-component[20] Redis Operator 使用文档 https://github.com/spotahome/redis-operator/blob/master/README.md[21] 完整代码https://github.com/kubevela/catalog/blob/master/experimental/addons/redis-operator/definitions/redis-failover.cue[22] 文档https://kubevela.net/zh/docs/platform-engineers/addon/intro#%E6%8F%92%E4%BB%B6%E7%9A%84%E5%9F%BA%E6%9C%AC%E4%BF%A1%E6%81%AF%E6%96%87%E4%BB%B6[23] template.cuehttps://github.com/kubevela/catalog/blob/958a770a9adb3268e56ca4ec2ce99d2763617b15/experimental/addons/redis-operator/template.cue#L28[24] 完整代码https://github.com/kubevela/catalog/tree/master/experimental/addons/redis-operator[25] READMEhttps://github.com/kubevela/catalog/tree/master/experimental/addons/redis-operator/README.md[26] 插件中心https://github.com/kubevela/catalog11 月 5 日杭州云栖小镇-云原生峰会阿里云将联手识货、传音、禾连健康、新东方、心动网络、小红书等实战企业技术负责人向你发出邀请扫码即刻参会！
发表了文章
2022-10-28
阿里云云边一体容器架构创新论文被云计算顶会 ACM SoCC 录用
近日，由阿里云撰写的关于 KOLE 创新论文被 ACM SoCC 国际会议长文录用。ACM Symposium on Cloud Computing（以下简称 SoCC）是由美国计算机协会主办、聚焦云计算技术的一项学术会议，是云计算的首要会议。它汇集了对云计算感兴趣的研究人员、开发人员、用户和实践者，是唯一由 SIGMOD（数据管理特别兴趣组）和 SIGOPS（操作系统特别兴趣组）联合主办的会议, 这个会议在近些年蓬勃发展，旨在聚集数据库和计算机系统两大领域的学者，共同推进云计算技术在工业界的研究与发展。此次被录用的论文为《KOLE: Breaking the Scalability Barrier for Managing Far Edge Nodes in Cloud》。此论文灵感诞生于阿里云边缘容器产品 ACK@Edge ，ACK@Edge 是阿里云容器服务针对边缘计算场景推出的云边一体化协同托管方案,采用非侵入方式增强，提供边缘自治、边缘单元、边缘流量管理、原生运维 API 支持等能力，以原生方式支持边缘计算场景下的应用统一生命周期管理和统一资源调度，现阶段已经覆盖了 CDN、音视频直播、物联网、物流、工业大脑、城市大脑、地产、票务、新零售、能源、交通等实际业务场景，并服务于阿里云 LinkEdge、盒马、优酷、视频云、大麦、CDN 等多个业务或项目中。KOLE  全称：A framework built on top of Kubernetes to Orchestrate Limitless (far)  Edge nodes。KOLE 针对 Kubernetes 在云边一体，大规模边缘节点管理方面的挑战，创新性的提出了基于 Kubernetes的新的云边架构，通过利用新的云边通信协议以及缓存快照的方式，使 Kubernetes 能够轻松管理数百万节点。为了突破 Kubernetes 管理大量边缘节点的可扩展性限制，KOLE 的设计遵循三个标准：避免创建大量对象来持久化边缘节点的状态；避免在节点与 APIServer 中保持大量的 HTTP 连接；使用 Kubernetes CRD 支持对边缘节点及其运行的应用程序进行所需的管理操作。 基于以上原则，KOLE 创新性的使用了 MQTT 协议作为云边通信机制，MQTT 被设计用于轻量级的发布/订阅式消息传输，旨在为低带宽和不稳定的网络环境中的物联网设备提供可靠的网络服务,是专门针对物联网开发的轻量级传输协议，并且适合百万级设备连接, MQTT 协议针对低带宽网络，低计算能力的设 备，做了特殊的优化，MQTT 的传输格式非常精小，最小的数据包只有 2 个比特，相对于 HTTP 协议具有更低的能耗。经过我们大量的实验测试评估，KOLE 可以支持多达 100 万个节点，而不会给 Kubernetes 的核心组件(如 Apiserver 和 etcd)带来显著的开销。我们能够使用 KOLE 在约 73 秒内将工作负载规范分发到 100 万个节点，在 5 分钟内处理 100 万个节点注册，并在约 20 秒内使用快照中的 100 万个节点重建云状态缓存。具体特点如下：更强的处理节点心跳的性能实验数据表明 KOLE 处理所有心跳的时间几乎随着节点数量的增加呈线性增加。处理一百万个注册心跳需要 ∼9.2 秒。更低的云端控制器组件的消耗对于 100 万个节点，KOLE 控制器和 MQTT Broker 的内存消耗分别为 10.6GB 和 57.3GB，CPU 使用率适中，KOLE 控制器消耗~1.4 个核心，MQTT Broker 消耗~2 个核心。更快的工作负载分发KOLE 通过 MQTT Topic 发送到单个节点时提供了线性可扩展性。将工作负载分别分发到一百万个节点需要 73 秒。线性来自 KOLE 控制器按顺序发布所有 MQTT Topic 的事实。更高效的云状态缓存快照由于 Kubernetes 对 CRD 的限制为 1MB 大小，因此 KOLE 将云状态缓存的序列化字节流设置为为 500MB，对于一百万个节点，这意味着需要 ∼500 个快照用于保存一张快照的 CR 实例。另外为了对数据进一步压缩，KOLE 对常见的压缩算法进行了测试，最终在 KOLE 中，我们选择 gzip 作为默认压缩算法，因为它提供了高压缩比和快速压缩时间，将快照 CR 的数量从 503 个减少到 33 个（减少 93%）。在极端情况下， 我们需要从快照中恢复最原始的数据，上图展示了从快照构建云状态缓存所需要时间，其中包括从 APIServer 加载所有快照 CR 的时间以及运行解压缩算法以恢复数据结构的时间。使用 gzip 算法构建具有 100 万个节点的缓存需要 ∼20 秒。为了突出 KOLE 中快速状态恢复的优势，我们通过列出来自 APIServer 的大量单个节点对象来检查 Kubernetes List API 的性能。结果如上图所示。正如预期的那样，从 APIServer 列出大量对象是低效的。列出一百万个节点对象需要 900 秒。很多 Kubernetes 控制器如 kube-scheduler，kube-controller-manager 需要在启动过程中列出所有节点, List API 性能是他们支持大量节点的瓶颈之一。更迅速的批量节点注册实验结果表明，在拥有 100 万个节点情况下，同时批量注册成功需要 260 秒左右。此次论文入选 ACM SoCC，是阿里云在云原生容器技术领域，拓展服务边界，实现云边协同的又一次创新。附论文信息录用论文题目：KOLE: Breaking the Scalability Barrier for Managing Far Edge Nodes in Cloud作者：张杰，晋晨，黄玉奇，易立，叔同，郭飞论文概述：在边缘计算领域，越来越多的趋势是利用容器化和 Kubernetes 等云原生技术和平台来管理边缘应用程序以提高运营效率。不幸的是，Kubernetes 中每个集群支持的节点数量只有几千个，这远远少于在典型边缘计算场景中所能管理的设备节点数量。在本文中，我们提出了 KOLE 方案，这是一个扩展上游 Kubernetes 以支持大量边缘节点的框架。它用 MQTT 消息系统代替了 Kubernetes 中现有的 Apiserver 与节点的通信机制。MQTT 代理完全卸载了为 Apiserver 中的节点保持大量 HTTP 连接的开销。在 KOLE 中，我们通过在云状态缓存中维护它们来避免在 Apiserver 中创建大量单独的对象。缓存会定期生成快照以进行灾难恢复。总体而言，KOLE 通过牺牲拥有单个对象的可管理性实现了出色的可扩展性。实验结果表明，KOLE 具有可扩展性，可支持百万级别的节点。点击此处，了解边缘容器服务 ACK@Edge 更多详情！
发表了文章
2022-10-28
阿里云容器服务 ACK 产品技术动态（202209）
点击此处即可查看容器服务 ACK 产品详情！
发表了文章
2022-10-26
全嘉宾阵容官宣 | 2022 云原生峰会即将启动，实战派企业向你发出邀请
作者：云原生峰会小组今天，企业应用构建依然面临很大挑战，资源如何按需使用，实现降本增效？如何在复杂系统架构下，充分保障业务稳定和连续性？如何做到应用的敏捷和业务的智能化？如何保障系统的可信和安全？企业亟需充分挖掘云计算的技术红利，助力业务发展，创造更多的商业价值。云原生可以激活应用构建范式，以解决企业在新时期遇到的挑战。为探寻企业数字化转型的未来方向及技术重点深度解密云原生技术新动向11 月 5 日杭州云栖小镇-云原生峰会阿里云将联手识货、传音、禾连健康、新东方、心动网络等实战企业技术负责人向你发出邀请11 月 5 日，杭州云栖小镇 B 馆，我们不见不散！扫码或者点击此处，即可报名参会。
发表了文章
2022-10-26
2022云原生峰会开启报名 | 一年一度云原生技术风向标就看这里！
一年一度云原生技术风向标云原生峰会，来了！2022 年 11 月5 日，杭州云栖小镇锁定云栖大会，预约云原生峰会去年云栖大会，阿里云面向业界提出：“阿里巴巴实现了全球最大规模的云原生实践，所有业务100%跑在公共云上，应用100%云原生化。同时发布了全新升级的容器服务 ACK Anywhere，以及多款容器产品：ACK 敏捷版、ACK 发行版、分布式云容器平台 ACK One，并推出业内首款云原生技术中台 CNStack……”云栖第一天：解密两个100%背后的云原生云栖大会第二天：ACK Anywhere 来了一图看懂云栖大会「云原生」重磅发布（往期回顾）今年云原生峰会，有哪些你不能错过的热点呢？从应用构建看云原生今年的云原生峰会以激活应用构建新范式为主题① 从四大章节全面展开议题：全面容器化应用 Serverless 化核心技术互联网化专有云产品重磅发布② 您将收获到：√ 全球云原生应用洞察与趋势√ 阿里云在云原生领域的最新产品与技术布局√ 阿里云 All on Serverless 全新思考与投入√ 识货、传音、新东方等企业实战经验√ 圆桌论道云原生架构落地的挑战与机会全云开发新体验技术展区见证全新的云原生产品发布在 B 馆阿里云核心技术展区共同见证 All on Serverless 全新布局与产品以及容器、微服务、可观测产品全景在 D 馆开发者展区云原生开发者体验岛：让您快速上手容器、中间件、微服务、可观测、消息队列等核心产品，并全面了解云原生开源项目，体验更智能、更高效、更弹性的全云开发同时将举办飞天 Club 云原生开发者技术嘉年华解密云原生领域热点开源项目与开源“扫地僧”直接对话11 月 5 日，邀您相聚杭州，见证一场不能错过的云原生峰会！扫描下方二维码报名直播扫描上方二维码或者点击此处，领取云原生峰会门票！前100名报名11月5日云原生峰会的小伙伴，可以在峰会现场领取定制礼物！期待相聚！
发表了文章
2022-10-21
阿里云可观测 9 月产品动态
发表了文章
2022-10-20
可观测实践｜如何使用阿里云 Prometheus 观测 ECS 应用
作者：颍川引言Prometheus + Grafana 已经成为云原生时代的可观测性事实标准。我们使用 Prometheus 观测云原生时代的 Kubernetes 体系下的 Node、ApiServer、workload 等的基础 metric，同时通过 Prometheus Exporters 采集各种组件（如 Redis、Kafka 等）和业务应用的 metric，最后通过 Grafana 展示大盘、AlertManager 进行告警，实现了云原生 Kubernetes 体系下 metric 可观测闭环。由于大量非云原生的历史系统演进到云原生体系是个长时期过程，因此这些非云原生系统的可观测闭环也是我们必须解决的问题。我们很自然地想到“既然 Prometheus + Grafana 实现了云原生体系的 metric 可观测闭环，是否可以使用这套神器来解决非云原生体系应用的同样问题呢？”，答案是肯定的。本文介绍如何使用阿里云 Prometheus 来实现非 Kubernetes 应用（即 ECS 应用）的 metric 观测。ECS 应用的典型部署场景场景 1：纯公有云 VPC业务应用部署在一个或多个 VPC 内，每个 VPC 内购买了一批 ECS，在这些 ECS 上部署了基础组件（数据库和中间件等）和业务应用。此场景下，我们需要对这些 ECS OS（Linux 或 Windows）、基础组件和业务应用本身进行 metric 观测。场景 2：公有云 VPC+线下 IDC业务除了部署公有云 VPC 上外，还需要与线下 IDC 机房进行互通互联。通常，我们使用专线方式打通云上 VPC 和线下 IDC 机房。此场景下，我们期望有一套完整的 metric 观测平台，同时解决线上 VPC 和线下 IDC 的 metric 观测。场景 3：公有云 VPC+多云 ECS业务除了部署在阿里云 VPC 上外，还通过公网与其它云上的 ECS 进行互通互联。此场景下，我们也期望有一套完整的 metric 观测平台，实现一体化全局视角观测。自建 Prometheus 观测 ECS 应用的痛点自建 Prometheus 观测 ECS 应用，我们将面临的典型问题有：由于安全、组织管理等因素，用户业务通常部署在多个相互隔离的 VPC，需要在多个 VPC 内都重复、独立部署 Prometheus，导致部署和运维成本高。 每套完整的自建观测系统都需要安装并配置 Prometheus、Grafana、AlertManager 以及各组件 Exporter，过程复杂、实施周期长。 缺少与阿里云 ECS 无缝集成的服务发现（ServiceDiscovery）机制，无法根据 ECS 标签来灵活定义抓取 targets。如果自行实现类似功能，则需要使用 Golang 语言开发代码（调用阿里云 ECS POP 接口）、集成进开源 Prometheus 代码、编译打包后部署，实现门槛高、过程复杂、版本升级困难。 常用组件的开源 Grafana 大盘不够专业，缺少结合观测组件的原理和最佳实践进行深入定制。 缺少常用组件的告警项模板，需要用户自行研究、配置告警项，工作量大，且很可能缺少各组件领域的专业技术沉淀。 阿里云 Prometheus 监控的能力框架阿里云 Prometheus 监控[1]是一款全面对接开源 Prometheus 生态，支持类型丰富的组件观测，提供多种开箱即用的预置观测大盘，且提供全面托管的混合云/多云 Prometheus 服务。除了支持阿里云容器服务、自建 Kubernetes、Remote Write 外，阿里云 Prometheus 还提供混合云+多云 ECS 应用的 metric 观测能力；并且支持多实例聚合观测能力，实现 Prometheus 指标的统一查询，统一 Grafana 数据源和统一告警。其逻辑架构如下示意：对于 ECS 应用，阿里云 Prometheus 提供以下 metric 数据采集方式：托管 exporter：提供 MySQL、Redis 等数十种常见组件[2]（持续更新中）的托管部署。用户只需要在阿里云 Prometheus 控制台配置观测组件相关信息（如 IP 地址、端口等），即可实现 VPC 内 ECS 上这些组件的 metric 监控。由于线下 IDC 通过专线与 VPC 互通，因此托管 exporter 同时也能采集到线下 IDC 内的组件 metric。 非托管 exporter：对于我们暂未提供托管 exporter 的组件，或用户业务应用的自定义 metric，用户可以在 VPC 或 IDC 内部署自定义 exorter，然后在阿里云 Prometheus 控制台上配置自定义服务发现（ServiceDiscovery），最后阿里云 Prometheus 主动发现这些 exporter，并定时抓取和存储 metric。 Node/Windows exporter：它们是一类特殊的非托管 exporter，因为需要部署在每台 ECS 上，以便采集 ECS OS 上观测信息。阿里云 Prometheus 提供了 Node exporter 的原生支持，Windows exporter 原生支持也即将上线。ECS 应用场景下，自建 Prometheus 与阿里云 Prometheus 对比如何使用阿里云 Prometheus 观测 ECS 应用步骤 1：创建 VPC 实例登录 Prometheus 控制台[3]，选择新建 Prometheus 实例，根据界面提示，填写实例名、选择 VPC / VSwitch / SecurityGroup / Grafana 工作区，即可创建 VPC 实例成功。操作说明详见阿里云帮助中心文档[4]。步骤 2：接入组件监控目前阿里云 Prometheus 已支持 Node exporter、MySQL、Redis、ElasticSearch、Kafka、Nginx、MongoDB、PostgreSQL、RabbitMQ、RocketMQ、BlackBox 等组件观测。阿里云 Prometheus 天然内置支持了 static_configs和aliyun_sd_configs 两种最常用/实用的服务发现方式，方便用户进行组件观测目标 ECS 的配置。此处以 MySQL 为例，简要描述接入配置方法。登录 Prometheus 控制台后，进入已创建的 VPC 实例详情的集成中心界面，新建 MySQL 接入，填写 MySQL 监控名称、MySQL 地址、端口、用户名/密码等信息即可。详细操作步骤和说明，参见阿里云帮助中心文档[5]。步骤 3：查看大盘阿里云 Prometheus 无缝集成了共享版 Grafana 和专家版 Grafana，用户无需单独安装 Grafana，即可查看各个组件的观测大盘。接入需要监控的组件后，在集成中心点击对应组件图标的已安装 Exporter，可以看到该组件的大盘略缩图和链接，点击即可进入阿里云 Grafana，查看对应观测大盘。详见阿里云帮助中心文档[6]。步骤 4：配置告警进入 VPC 实例详情的集成中心界面，进入 MySQL 组件的告警界面，即可创建 Prometheus 告警规则，详见阿里云帮助中心文档[7]。阿里云 Prometheus 提供了免运维、开箱即用的 VPC（以及和 VPC 打通的线下 IDC 机房）内 ECS 的 OS、常见中间件、业务应用的 metric 观测能力，实现了一站式的云原生和非云原生环境的 metric 观测协同和闭环。同时我们正在持续升级和丰富常用组件的观测能力（如 Windows、JMX、ClickHouse、Jenkins、Process 等），敬请期待。关于阿里云 Prometheus 监控阿里云 Prometheus 服务是基于云原生可观测事实标准 - Prometheus 开源项目构建的全托管观测服务。默认集成常见云服务，兼容主流开源组件，全面覆盖业务观测/应用层观测/˙中间件观测/系统层观测。通过开箱即用的 Grafana 看板与智能告警功能，并全面优化探针性能与系统可用性，帮助企业快速搭建一站式指标可观测体系。助业务快速发现和定位问题，减轻故障给业务带来的影响，并免去系统搭建与日常维护工作量，有效提升运维观测效率。与此同时，阿里云 Prometheus 作为阿里云可观测套件的重要组成部分，与 Grafana 服务、链路追踪服务，形成指标存储分析、链路存储分析、异构构数据源集成的可观测数据层，同时通过标准的 PromQL 和 SQL，提供数据大盘展示，告警和数据探索能力。为 IT 成本管理、企业风险治理、智能运维、业务连续性保障等不同场景赋予数据价值，让可观测数据真正做到不止于观测。更具性价比的计费选择，Prometheus 包年包月相关链接[1] 阿里云Prometheus监控https://help.aliyun.com/document_detail/122123.html[2] 常见组件https://help.aliyun.com/document_detail/251830.html[3] 应用实时监控服务ARMShttps://arms.console.aliyun.com/#/home[4] Prometheus实例 for ECShttps://help.aliyun.com/document_detail/274450.html[5] 使用阿里云Prometheus监控MySQLhttps://help.aliyun.com/document_detail/161838.html[6] 集成中心https://help.aliyun.com/document_detail/427600.html[7] Prometheus告警规则https://help.aliyun.com/document_detail/331981.html
发表了文章
2022-10-20
OpenYurt v1.0 正式发布！一文了解三大社区 SIG 重点更新
作者：何淋波（新胜），阿里云技术专家陈锦赐（敬易），阿里云开发工程师熊峰（籁鸣），阿里云技术专家OpenYurt 定位为云边协同的云原生边缘基础设施，经过 2 年多的发展，社区在云边协同治理，边缘自治，边缘网络与存储，以及 IoT 等方向已经孵化超过 20+子项目，为更好的提升社区协同效率和完善社区治理，OpenYurt 社区成立了 3 个 SIG：ControlPlane, DataPlane, IoT 来统筹管理社区所有项目，同时社区会议也由双周会调整为周会。经过 OpenYurt 社区各个 SIG 的一齐努力，OpenYurt v1.0 版本于北京时间 9 月 9 号正式发布。v1.0 版本重点关注代码品质提升，降低 OpenYurt 的入门门槛，以及核心组件的性能测试，同时统一 API 的自动化治理。SIG ControlPlane重点更新API 治理：NodePool 资源版本升级到`v1beta1`，同时 OpenYurt 所有 API 管理迁移到 openyurtio/api[1]，建议用户通过引用这个项目来使用 OpenYurt 的资源 API  完善测试覆盖率：使用 CodeCov[2]来跟踪各个项目的 unit test 覆盖率。目前 ControlPlane 各个项目的测试覆盖率基本达到 50%。同时完善了 yurt-app-manager 项目的 E2E 和 Fuzz 测试  性能测试：重点关注 Yurthub 组件的性能和云边断网状态下节点重启时 Pod 恢复效率，相关测试报告可以参考：Yurthub 性能测试报告[3]，节点重启时 Pod 恢复效率测试[4] OpenYurt 安装部署优化: 移除了早期的 K8s 和 OpenYurt 相互转换工具，同时 OpenYurt 安装优化为: OpenYurt Control-Plane 组件安装[5]，边缘节点接入[6]详细更新可以参考：https://github.com/orgs/openyurtio/projects/6未来规划SIG ControlPlane 仍将继续提升云边协同场景下的治理能力，目前规划的能力包括：支持节点池为入口的运维监控能力，确保云边网络断连状态下，仍可对节点池内资源进行运维监控操作 #775[7] 支持节点池维度的 Pod 驱逐管理策略，确保边缘业务的可用性 #779[8] 支持云边流量复用能力，大幅降低云边通信的管控流量，以及减少 95%+的list/watch 请求 #778[9] 探索边缘业务的新型升级模型，如 DaemonSet 工作负载的 OTA 升级和 Auto 升级 #914[10] 基于 kubeadm 重构 yurtadm join command #889[11] 优化服务流量拓扑能力，解决 Service 和 NodePool 变化时引发的流量拓扑的更新问题 #871[12] 优化基于流水线打包 OpenYurt 集群镜像(基于 sealer) #942[13]详细规划可以参考：https://github.com/orgs/openyurtio/projects/7/views/1SIG DataPlane重点更新raven 支持 WireGuard 作为 VPN 后端；相比于 IPSec 作为 VPN 后端有更好的性能raven 支持 Calico，适配 Calico 对于单节点多容器网络网段的特性 raven 支持网络链路最小 MTU 的探测 完善测试覆盖率: 使用 CodeCov 来跟踪 raven 和 raven-controller-manager 的 unit test 覆盖率，目前 DataPlane 各个项目中测试覆盖率都有效提升，其中 raven 项目的测试覆盖率已经达到 60%以上详细更新可以参考: https://github.com/orgs/openyurtio/projects/8未来规划SIG DataPlane 仍将继续提升云边协同场景下的网络能力，目前规划的能力包括：raven 支持 SLB 作为公网暴露方式，当前仅支持云端 eip 或公网 ip 的方式打通边-边、云边网络 #22[14] raven 支持 NAT 穿越，使得边端的网络能够不借助于云端的转发，达到互相打通的效果 #45[15]  raven 支持接管 yurt-tunnel 的能力，将 OpenYurt 的网络组件统一收口到 raven 项目 #40[16] #41[17]详细规划可以参考：https://github.com/orgs/openyurtio/projects/8SIG IoT重点更新1. yurt-edgex-managerHelm Chart 支持。#17[18]支持 1.22 及以上版本 Kubernetes。#21[19]针对 EdgeX CRD 新增 Webhook 支持。#22优化 EdgeX 微服务的 Service 类型及网络监听方式，避免端口冲突，提升开发测试易用性。#29[20] #37[21] 2. yurt-device-controller支持指定 device、deviceprofile、deviceservice 资源双向同步名称，解决自动通过过程中重复创建资源问题。#50[22] 升级 Kube-Builder 版本，调整 Project Layout为Multi-Group，便于后续 Device 相关 API 的 ClientSet 生成。调整 DeviceProfile CRD DeviceResource.Attributes 数据类型，修复支持 2.x 版本 EdgeX 后，make generate 失败问题。#43[23] Helm Chart 支持。#57[24] 3. 完善测试覆盖使用 CodeCov 来跟踪各个项目的 unit test 覆盖率。通过增加单元测试，E2E 测试，持续提升 IoT SIG 中各个项目的测试覆盖率，其中，yurt-device-controller 测试覆盖率提升至 45%。未来规划（SIG IoT v0.3）yurt-edgex-manager 调整为 yurt-iot-manager，提供自动化支持 EdgeX 新 release 版本的能力；统一 IoT SIG 中所有组件的部署，提供更加便捷的安装部署方式；支持组件定制化部署。OpenYurt 设备管理 Benchmark。 基于 OpenYurt+EdgeX+OpenVINO 的摄像头管理及适配识别 End-to-End 参考架构及实现。详细规划可以参考：https://github.com/orgs/openyurtio/projects/2/views/1如果您对于 OpenYurt 有任何疑问，欢迎使用钉钉扫描二维码加入钉钉交流群。相关链接[1] openyurtio/apihttps://github.com/openyurtio/api[2] CodeCovhttps://about.codecov.io/[3] Yurthub性能测试报告https://openyurt.io/docs/test-report/yurthub-performance-test[4] 节点重启时Pod恢复效率测试https://openyurt.io/docs/test-report/pod-recover-efficiency-test[5] OpenYurt Control-Plane组件安装https://openyurt.io/docs/installation/summary[6] 边缘节点接入https://openyurt.io/docs/installation/yurtadm-join[7] #775https://github.com/openyurtio/openyurt/issues/775[8] #779https://github.com/openyurtio/openyurt/issues/779[9] #778https://github.com/openyurtio/openyurt/issues/778[10] #914https://github.com/openyurtio/openyurt/issues/914[11] #889https://github.com/openyurtio/openyurt/issues/889[12] #871https://github.com/openyurtio/openyurt/issues/871[13] #942https://github.com/openyurtio/openyurt/issues/942[14] #22https://github.com/openyurtio/raven/issues/22[15] #45https://github.com/openyurtio/raven/issues/45[16] #40https://github.com/openyurtio/raven/issues/40[17] #41https://github.com/openyurtio/raven/issues/41[18] #17https://github.com/openyurtio/yurt-edgex-manager/pull/17[19] #21https://github.com/openyurtio/yurt-edgex-manager/issues/21[20] #29https://github.com/openyurtio/yurt-edgex-manager/pull/29[21] #37https://github.com/openyurtio/yurt-edgex-manager/pull/37[22] #50https://github.com/openyurtio/yurt-device-controller/pull/50[23] #43https://github.com/openyurtio/yurt-device-controller/pull/43[24] #57https://github.com/openyurtio/yurt-device-controller/pull/57点击此处，立即了解 OpenYurt 项目！
发表了文章
2022-10-19
vivo 鲁班平台 RocketMQ 消息灰度方案
本文作者：区二立 - vivo 技术架构总监方案背景RocketMQ使用广泛，技术场景下，可以用于异步解耦，比如不同系统间调用业务链上做分段式处理或使用不同语言的两个系统间的解耦；可以用于数据同步，比如基础数据通过 MQ 广播到各个业务领域，实现业务领域的提效；高并发订单或 IM 的推送服务中，可以使用MQ做削峰填谷；此外，在分布式事务中，也可以通过 MQ 做最终一致性的事务方案。RocketMQ在业务场景下可覆盖很多系统，包括营销系统、生产制造上的各种管控系统、公共平台上人资、移动办公等流程类系统、类似于钉钉的自建IM 工具以及大数据等。随着以微服务化为基础的数字化建设转型，完成一项业务必须串联不同团队和不同应用。而不同应用的开发和发布周期相对独立，需要对接的版本不一，因此需要灰度方案。对于HTTP的灰度，很多时候通用的网关即可提供较好的支持，甚至简单地用 Nginx 实现也可以达到效果。微服务层，以Dubbo为例，有各种分组比如有扩展的 SPI 补充实现，可以轻松解决灰度方面的困扰。而 MQ 的灰度却没有标准支持，很多系统直接放弃了MQ灰度，因此也不得不接受一定时间段内的错误重试。MQ技术特点Broker是消息服务的核心，提供了消息服务最重要的计算与存储功能。消息发送时会对应一个 Topic，Topic为逻辑上的概念，内部执行往往是以 Queue 为单位。以普通消息类型的 Topic为例，Topic一般有多个 Queue，如图中的TOPIC_V_PLACE_ORDER 共有四个Queue，分别在两个 broker 里， broker a 与 broker b 里各有两个Queue。任何一条消息都必定属于四个Queue中的某一条。每条消息内可指定 tag 标志，用于在逻辑上进一步切分 topic，如上图中的tagA、tagB。切分维度有多种，可以是IoT，也可以是增值服务类的产品order等。不同tab 表示不同分类，但它们共享一个 topic。Queue可以理解为物理上的区分，broker的commitLog用于存放消息。commitLog不区分 Topic和Queue，不同的 Topic消息内容会按实际接收的Queue存储到其对应的broker commitLog上，该消息只会在集群中的某个 broker commitlog 中存在。Broker commitLog是公用的，到达某一个 broker的消息都会存在同一个 commitLog上，即一个commitLog会同时保存不同topic的内容。CommitLog达到一定大小时（一般为1G），会新建新的commitLog用于存储和接收新消息。commitLog在物理上存储具体消息，因此必然需要文件记录Queue与 commitLog存储消息之间的位置映射。minOffset（最小位移）和maxOffset（最大位移）也是存储位置中的重要概念。ConsumeGroupID与 groupID 强关联， groupID 消费时会在 broker上记录 topic Queue的消费位移，即会根据Queue记录不同 groupID 的consumerOffset。无论是生产者还是消费者，MQ都使用 groupID 表示交互的角色。在集群消费的情况下，使用同一个 groupID 的两个 client 会做Queue的消费订阅分配，一般会尽量采取平分的方式。而独立的消费组比如上图中GID_V_PAYMENT，会独占 topic中的 4 条Queue。消费组之间相互独立、互不干扰，有各自的消费位移点。不同的 RocketMQ 实例都有独立的 clientID，作为唯一标识与 broker打交道。提交消费位点时，只能提交该消费位点前都已完成消息位移的消息。如上图，3、4两条消息都已被消费线程处理完成，但2依然在处理中，因此实际触发的提交位点为1。消息2完成处理后，会触发消息4的提交。不同的 groupID 之间互相绝缘，但同一个 groupID 却会相互影响。订阅关系指标记了当前应用实例的 groupID 订阅了哪些 Topic（或topic的tag）。每一个应用实例或clientID 的订阅关系都会随着心跳包一起发送到 broker上，并在 broker上以 groupID 作为 key 来存储。每个broker每次接收到不同实例的心跳包时，都会按 groupID 的维度校验、替换订阅关系，即同一个 groupID 的订阅关系会被替换。同一个 groupID 在不同应用实例、不同 clientID ，只要订阅的 Topic和 tag 有任何不同，都会被最后到来的心跳包的订阅关系覆盖。如果在不同的应用实例中使用同一个 groupID ，而实例因版本原因导致订阅 Topic发生变化，则两组实例共存时会互相干扰，导致有些应用实例收不到想要的消息或收到错误的消息。而订阅关系是影响 MQ 灰度方案的核心因素。上图clientID_001 和clientID_002同属一个消费组GID_C_INVENTORY， clientID_001订阅了TOPIC_A，clientID_002 订阅TOPIC_B，都使用同一消费组执行订阅，因此，按照分配策略，它们会被交叉分配。分配结果可能是clientID_001 和clientID_002平分TOPIC_A的两条Queue， 也可能会平分TOPIC_B的两条Queue，从而导致异常。这就是订阅方式不一致导致的分配错乱以及处理错乱。常见灰度方案常规的灰度方案一般都会选择不同的消费组，处理方式有影子 Topic、Tag过滤以及userProperty过滤。以上几种处理方式都会存在一些缺陷：比如如何保证所有灰度消息都被消费完毕？灰度需要切换时，如何保证灰度消息是被灰度环境消费？灰度订阅切换为正常订阅关系的时候，如何确认消费位点，如何衔接才能保证消息不丢失？此外，运维人员可能对RocketMQ或应用内部逻辑不清楚，实际的操控对运维人员而言也是巨大的挑战。鲁班灰度方案鲁班灰度方案的核心解决思路是将Queue隔离使用。Queue是 Topic的实际执行单元，一个Topic有多个Queue。可以选择一部分Queue用于灰度，灰度Queue的数量、开始位置等可以在具体的实现里进行定义。如上图，首尾两个Queue专门用于灰度。因此，我们只需保障生产者与消费者的灰度与正常环境隔离使用即可，灰度环境的消息只从灰度的Queue里取，正常环境的消息从正常环境的Queue里拉取。消费者中无论是灰度还是正常的应用集群，都使用同一个消费组。这会导致订阅关系非常容易不一致。针对于此，我们的解决方案是改造订阅关系。Broker的订阅关系维护在 ConsumerGroupInfo 里，其中 subscriptionTable 负责维护 groupID 发送来的订阅心跳包。如果心跳包的订阅关系不一样，则会进行替换。我们新增了graySubscriptionTable 类，专门负责维护灰度的订阅关系。虽然是同一个groupID，但使用不同的类来分别维护灰度和非灰度的订阅关系。生产者的发送策略如下：首先判断目标topic是否有灰度消费者，再判断当前消息是否属于灰度范围。如果是，则将灰度消失投递到灰度的Queue里；否则，投递到正常的Queue。消费者按灰度拉取，正常集群只平分正常的Queue，灰度集群只平分灰度的Queue。如上图，ClientID_001与ClientID_002 只会分享正常的Queue，而ClientID_003与ClientID_004只分享灰度的Queue，他们共用一个消费组。如果本消费组使用的topic没有灰度，但由于其他消费组影响涉及到灰度topic，则它也会平分拉取灰度的Queue。此外，如果topic没有涉及灰度集群，则灰度Queue会空置不使用，消费者不拉取，生产者不发送。将灰度集群切换为正常集群时，原先灰度的集群会保证将灰度Queue消费完成后才真正进行切换，业务上动态切换服务时，MQ 会自动根据实际消费进度进行细节上的管控，保障所有消息不丢弃。除了业务灰度标识外，MQ也有自己的灰度标识需要处理，存储于Namesrv。生产者和消费者获取 Topic路由消息都由Namesrv提供，这也意味着生产者和消费者已经与Namesrv建立了连接。可以通过定期将灰度消息更新到Namesrv上，生产者也会定期将灰度信息拉到本地来打通整个链路。Namesrv存储灰度关系时，需要一个有状态的数据库来进行保存。如果灰度期间的延时消息在灰度结束后才投递，则会投递到正常Queue。延时消息临时存在数据库里，能够支持比较细粒度的延时定义。全局顺序消息会由一条Queue变成两条Queue。我们修改了创建Queue的定义，灰度切换回正常环境时，会保证将灰度的消息处理完以后再处理正常的消息。细节上的控制主要依赖灰度开关grayFlag和graySwitch两个标识位进行控制。graySwitch标志使用灰度的逻辑以及平分所有 Topic里Queue的逻辑，能够兼容不参与灰度的应用，可以平分所有受其他灰度消费组影响的 Topic的所有Queue。grayFlag 用于标记本实例是否为灰度实例，这会影响到订阅关系的保存。它会先查看graySwitch，再进行自己的判断。灰度场景校验实践是检验真理的唯一标准，我们进行了详细的灰度功能校验，分别是灰度版本订阅的topic&tag不变、灰度版本订阅的topic增加、灰度版本订阅的topic减少、灰度版本订阅的tage变化以及灰度版本订阅的topic&tag混合变化。加入 Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献，相信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅可以结识社区大牛，提升技术水平，也可以提升个人影响力，促进自身成长。社区 5.0 版本正在进行着如火如荼的开发，另外还有接近 30 个 SIG（兴趣小组）等你加入，欢迎立志打造世界级分布式系统的同学加入社区，添加社区开发者微信：rocketmq666 即可进群，参与贡献，打造下一代消息、事件、流融合处理平台。微信扫码添加小火箭进群另外还可以加入钉钉群与 RocketMQ 爱好者一起广泛讨论：钉钉扫码加群关注「Apache RocketMQ」公众号，获取更多技术干货
发表了文章
2022-10-17
年度大促将至，企业如何进行性能压测
作者：拂衣​为什么要做压测随着无线设备的普及和 5G 的大力建设，越来越多的线上系统、小程序成为了人们生活中必不可少的工具。与此同时，年底各类大促活动接踵而至，对于这些电商软件而言，都会面对一个问题：系统能承受多少用户同时访问，面对突发的流量洪峰，能否保证系统无故障稳定运行？为了回答这个问题，就需要在系统上线前做多轮压力测试，提前模拟出复杂的,  高仿真的线上流量来验证整体系统的高可用性,  这也是实施系统高可用方案的关键环节。另外,通过不同阶段的压测，也完成对系统的容量规划、瓶颈探测，对系统整体能力进行验收，确保在流量洪峰来临前，系统确实能够承受即将来临的真实线上压力。从某种意义上来说，压测是系统稳定性的验证者。如何实施一次准确的性能压测1. 准备压测环境压测的执行环境是一个老生常谈的话题，如果直接在生产环境执行压测，会有 2 个问题：1. 会影响线上业务，对正常访问系统的用户造成影响2.会污染线上数据，将压测数据写入线上数据库为了解决这 2 个问题，一般业内采用如下几种方案：以上方案各有优缺点，适用场景也不尽相同，可以根据自己项目所处的阶段灵活选择方案。2. 构建压测脚本业内常用的压测工具包括 JMeter、Gatling、Locust、k6、Tsung、阿里云 PTS 等。这些工具无一例外，都需要将压测业务的 API，编排为一个压测脚本。这一步工作的重点在确认压测的 API，不要有遗漏，且 API 编排的顺序要符合用户的操作逻辑。对于电商业务的压测来说，如果脚本中遗漏了登录鉴权 API，那后面的订单、物流、库存等 API 都会在权限校验这步就报错，不会执行正常的业务逻辑，也就无法模拟真实的业务场景。以上压测工具编排脚本都有 2 个方式：手动输入脚本，这需要脚本的编写人员对业务非常熟悉，保证不会遗漏 API。自动录制脚本，上述开源压测工具都提供了录制请求的代理功能，开启并配置代理后，只要在页面上模拟用户的操作和点击行为，即可自动录制请求，并生成压测脚本。同时 PTS 还提供了 Chrome 录制插件（链接1），免代理配置，可以一键生成 JMeter 和 PTS 压测脚本。提升了脚本编写的效率，也能保证不遗漏 API。为了避免复杂脚本中遗漏 API 的风险，推荐使用录制功能生成脚本。3. 确认压力模型这一步是在配置压测中模拟的压力峰值、不同 API 的压力分布比例以及压力值递增模型。压力值指的是模拟并发用户数，或每秒发送的请求数。施压模式 在设置之前，需要确认施压模式，业内主要有 2 种施压模式：1. 虚拟用户(VU)模式，可以理解为一个线程模拟一个真实用户，压测时线程一直循环执行，模拟用户不停地发送请求。2. 吞吐量模式，即每秒请求数(QPS)，可以直接衡量服务端的吞吐量。在项目验收阶段，很重要的一个指标就是系统的吞吐量，即可支持的QPS。对于这种压测场景，更推荐使用吞吐量模式，可以直观的看到施压机每秒发出的请求数，并和服务端的吞吐量直接对应起来。各 API 压力分布比例 确认了施压模式后，需要配置不同 API 的压力分布比例。每个 API 的准确压力分布比例，也是一次成功压测中不可获取的因素。压力值递增模型 常见有脉冲模型，阶梯递增，均匀递增。脉冲模型会模拟流量在瞬间突然增大，常用于秒杀、抢购的业务场景。递增模型可以模拟在一定时间段内，用户量不断增大，常用于模拟有预热的业务场景。除了常规的递增模型，最好在压测中可以实现手动调速功能，一是可以模拟一些非常规的流量递增情况，二是可以反复调整压力值，来复现和排查问题。施压流量地域分布 确定了压力值和递增模型后，还需要确定施压流量的地域分布，应尽量拟合真实的用户分布，才能保证测试结果真实可信。对于区域性的在线业务，施压机分布在当地的同一机房，是可以理解的。如果是全国性的在线业务，施压机也应该按照用户分布，在全国各地域部署。4. 执行压测，观察压测指标压测中核心指标分为：请求成功率，请求响应时间（RT），系统吞吐量（QPS）1. 请求成功率不止要看全局的请求成功率，还要关注一些核心 API 的成功率，避免整体成功率达标，核心 API 成功率不足的情况。2. 请求响应时间，需要关注 99、95、90、80...等一些关键分位的指标是否符合预期，而平均响应时间没有太大的参考意义，因为压测需要保证绝大部分用户的体验，在不清楚离散程度的情况下，平均值容易造成误判。3. 系统吞吐量是衡量系统能承受多大访问量的指标，是压测不可缺少的标准。上面三个指标遇到拐点时，就可以认为系统已经出现性能瓶颈，可以停止压测或调小压力值，准备分析、定位性能问题了。除了这三个业务指标，同时还应该同时观测系统的应用监控、中间件监控和硬件监控的一些指标，包括但不限于：服务器：网络吞吐量CPU使用率内存使用率磁盘吞吐量......数据库：连接数SQL 吞吐量慢 SQL 数索引命中率锁等待时间锁等待次数..... 中间件：JVM GC 次数JVM GC 耗时堆内、堆外内存使用量Tomcat 线程池活跃线程数...... 更多压测时需要关注的指标，见文末文档[2]如果系统已经达到预期，往往还可以可以按照 10-20%的比例，不断加大压力值，为系统做一次峰值“摸高”，观察系统的极限值是多少，做到心里有底。5. 复盘，性能优化压测结束，如果未达到预期，可以配合监控排定位，分析性能问题，性能优化完成后，在下一轮压测中继续验证。测试中问题分析和调优的方法这里不展开描述，可以参考文末文档[3]如果系统表现已经符合预期，可以用压测得到的系统吞吐量指标，配置流控、降级、系统或隔离规则，保障系统稳定性。阿里云性能测试 PTS，助您系统无忧性能测试 PTS（Performance Testing Service）是一款阿里云 SaaS 化的性能测试工具，从最早为了精准模拟双十一流量洪峰诞生，到现在已经走过了 10 个年头。每年支持包括双十一在内的全集团范围的几万次压测任务，是阿里内部双十一技术架构的"提前验证者"。技术让利 1：自研 PTS 压测引擎，压力模型准，性能优PTS 完全自研的压测引擎，在并发模型的实现上相较传统线程模型性能更优。并且支持 API 维度的吞吐量配置，比开源工具更精细，可以准确模拟流量漏斗模型。PTS 压测还支持多种客户端的流量录制功能，可以快速构建压测脚本，并支持完全白屏化的操作，让压测脚本构建的门槛大大降低。技术让利 2：全面兼容 JMeter，上线 JMeter 插件PTS 在全面兼容 JMeter 的同时，针对 JMeter 分布式压测做了很多优化：优化点 1：全球分布施压机，即压即用，可支持百万并发，千万 QPS 压测优化点 2：支持吞吐量模式，可以设置全局目标 QPS，更直观衡量服务端性能优化点 3：支持压测中调速，可以灵活调整并发或 QPS，不断逼近性能极限点优化点 4：支持浏览器插件录制，一键导出 JMeter 脚本，无需配置代理，大大降低构建脚本的工作量优化点 5：针对分布式压测，支持自动切分文件，支持全局生效 Timer、Controller 组件，零门槛开启分布式压测优化点 6：发布 JMeter PTS 插件，使用 JMeter GUI 客户端即可发起云端分布式压测，无缝衔接脚本调试和执行阶段[4]技术让利 3：VPC 内网压测在全面正式压测前，重点微服务应用需要在日常态做单应用的压测，摸清楚局部的性能极限。对于部署在阿里云上的服务，单个微服务应用不会暴露公网入口，这时就需要压测工具有打通 VPC 内网的能力。PTS 支持 VPC 内网压测，可以在压测时快速打通施压机与用户 VPC 网络，保证内网压测的网络畅通。在压测结束后，也会即时关闭网路通道，保证网络安全。用户只需要在压测配置中，选择微服务应用所在的 VPC 内网、安全组、交换机，即可开启 VPC 内网压测。让您的服务无需暴露公网入口，也可以探测出性能指标。操作示例如下：技术让利 4：流量地域定制大部分业务的用户并不是按地域均分的，相反，往往很不均匀。要模拟真实流量分布，施压机需要在各地分散部署，并且支持按地域、按量分配，在压测时，还要支持实时的统一调度。如果施压机都分布在一个 Region，甚至是一个可用区内，那是无法模拟出来自全球用户请求的。使用阿里云性能测试服务（PTS）压测时，开启流量地域定制功能，只需简单勾选地域，即可指定施压机的地域分布，目前支持全球 22 个地域定制。技术让利 5：问题诊断工具压测的目的是发现性能问题，在压测报告中，PTS 有异常请求状态码的统计，并提供了请求采样日志，可以直观的看到请求、响应的全部信息，对于响应时间较长的请求，也会直观的展示请求在各个阶段的耗时。对于 Java 应用，PTS 提供了基于 Java Agent 的问题诊断工具，只需在 Java 应用上挂载探针，即可自动获取应用、API、机器维度的秒级监控。对于报错的请求，可以直接定位到调用链上报错的方法堆栈，省去了大量排查问题的时间，是定位问题的“利器”。定位报错方法堆栈示例如下：相关链接[1] Chrome录制插件使用指导：https://help.aliyun.com/document_detail/187749.html[2] 压测指标：https://help.aliyun.com/document_detail/29338.html[3] 测试问题分析及调优：https://help.aliyun.com/document_detail/29342.html[4] JMeter插件使用指导：https://help.aliyun.com/document_detail/379921.html[5] PTS产品购买页：https://common-buy.aliyun.com/?commodityCode=ptsbag
发表了文章
2022-10-15
Apache RocketMQ 在阿里云大规模商业化实践之路
作者：周新宇阿里云消息队列 RocketMQ 商业化历程RocketMQ 诞生于 2012 年，诞生即开源。2012～2015 年，RocketMQ 一直在通过内部电商业务打磨自身服务能力,并在 2015 年于阿里云上线公测。2016 年，阿里云 RocketMQ 完成商业化，同时被捐赠给 Apache 基金会，同年获得了年度受欢迎中国开源软件荣誉。在 Apache 孵化期间，Apache RocketMQ 经历了快速发展，2017 年即毕业成为了 Apache 顶级项目。同年，Apache RocketMQ TLP RocketMQ 4.0 正式发布。此后，RocketMQ 4.0 经历了长足发展，期间阿里云商业和开源相辅相成、齐头并进，直到今天，共同迈入 RocketMQ 5.0 时代。RocketMQ 5.0 发布后，阿里云商业会持续采取 OpenCore 的发展模式，秉承上游优先的社区发展原则，与社区一起将 RocketMQ 打造为一个超融合的数据处理平台。阿里云消息队列产品矩阵阿里云基于 RocketMQ 消息底座，构建了多元化的消息产品系列。RocketMQ 是阿里云主打的消息品牌，互联网新兴业务领域首选的数据通道。消息队列 Kafka 是大数据的首选数据通道，微消息队列 MQTT 是移动互联网和物联网的数据通道，消息队列 RocketMQ 是传统业务领域的数据通道。消息服务 MNS 是 RocketMQ 轻量版，主要应用于应用集成领域，为平台型应用提供简单的队列服务。事件总线 Event Bridge 定位为云上事件枢纽，旨在阿里云上构建统一的事件中心。阿里云消息队列产品矩阵完全构建在 RocketMQ 之上，基本实现了应用场景全覆盖，包括微服务解耦、SaaS 集成、物联网、大数据或日志收集生态，同时也在内部覆盖了阿里巴巴所有业务，在云上为数万阿里云企业提供了优质的消息服务。阿里云的消息产品矩阵涵盖了互联网、大数据、移动互联网等领域业务场景，为云原生客户提供不可或缺的一站式解决方案。RocketMQ 在阿里云商业化历程中，一直致力于探索业务消息实践，也孵化了大量业务消息特性，并持续反哺到开源社区。RocketMQ 4.0 业务消息探索之路RocketMQ 在商业化过程中，陆续推出了四种消息类型来满足丰富的业务场景。普通消息：普通消息提供极致弹性、海量堆积能力，内置重试与死信队列来满足业务对失败重试的需求，同时具备高吞吐、高可用、低延迟等特性，广泛应用于应用集成、异步解耦、削峰填谷等场景。 定时消息：提供秒级定时精度， 40 天超长定时，主要面向分布式定时调度、任务超时处理等场景，目前正在开源中。 顺序消息：支持全局与局部严格有序，从发送、存储到消费，保证端到端有序。面向有序事件处理、撮合交易、数据实时增量同步等场景。 事务消息：分布式、高性能、高可用的最终一致性事务解决方案，广泛应用于电商交易系统中服务的一致性协调场景并且已经开源。 RocketMQ 4.0 期间，商业和开源都致力于全方位拓展消息接入能力，使 RocketMQ 能够非常轻松地连接应用开源和云产品生态。比如商业上提供了多语言 SDK ，开源也有相应的 SDK 能够覆盖 Java、Go、Python 、C++使用 RocketMQ。同时支持 Spring 生态，能够通过 Spring Cloud 的方式使用 RocketMQ。商业上提供了一组非常简单易用的 HTTP API，提供了 6-7 种语言的实现。除了 SDK 接入，RocketMQ 也在积极拥抱社区标准，在云产品侧提供了 AMQP 和 MQTT 的接入能力，其中 MQTT 已开源。RocketMQ 也大力在发展 connector 生态，能够通过 RocketMQ connector 接入很多数据源，包括 Redis、MongoDB、Hudi 等大数据系统。另外，阿里云构建的事件总线 EventBridge 也已开源，通过该产品能够将阿里云的云产品、SaaS 应用、自建数据平台的数据引入 RocketMQ。RocketMQ 4.0 版本做了大量尝试，提供了全方位的消息接入能力。RocketMQ 在服务阿里集团用户和商业化历程中，沉淀了大量领先的业务消息处理与服务能力。比如消息订阅方面，RocketMQ 支持集群分布式消费能力，也支持广播消费。在消息处理方面支持基于 Tag 和 SQL 做灵活过滤，其中基于 SQL 过滤是电商交易中非常重要的特性，能够支持在非常订阅比的情况下实现较低的投递比。全球消息路由能力具备性能高、实时性强的特点。在云时代，数据中心天然分布在各个地域，各个地域之间还有 VPC 网络隔离。但是通过全球消息路由功能可以将地域与网络打通，能够满足更多业务场景。比如在阿里内部基于该能力实现了异地多活、异地容灾等企业级特性。另外，全球消息路由具备非常高的易用性，提供了可视化任务管理界面，通过简单配置即可创建复制链路。消息治理方面，RocketMQ 提供了访问控制、命名空间、实例限流、消息回放、重试消息、死信消息、堆积治理等能力。服务能力方面，RocketMQ 经历了非常多沉淀，它在为交易链路服务了 12  年，参加了 10 年双 11，这也保证了 RocketMQ 能够在阿里云上提供非常高的可靠性。双 11 消息收发 TPS 峰值过亿，日消息收发总量超过 3 万亿。而即使在双十一万亿级数据洪峰下，消息也能做到 99.996% 毫秒级响应能力，消息发布平均响应时间不超过 3 毫秒，最大不超过 20 毫秒，真正实现了低延迟消息发布。商业化初期，客户遇到最大难题是在分布式环境下如何完整地追踪异步消息链路。基于此背景，我们打造了可视化全生命周期消息轨迹追踪系统，能够提供丰富的消息查询、消息下载、定点重投、轨迹追踪能力，通过可观测系统帮助用户解决分布式环境中不可观测的问题。如上图所示，一条消息从产生、发送至服务端存储到最终投递到消费者，整个发送和消费轨迹都有迹可循，包括投递给哪些消费者、哪些消费者在什么地方成功消费或者消费失败、何时进行重投，真正帮助客户解决了分布式观测难题。除了功能特性，RocketMQ 在稳定性方面也做了很多建设。我们始终坚持，SLA 是云原生的根本，因此整个研发运维链路都有严格的稳定性保障措施：架构开发：每个方案设计都会面向失败设计，代码开发阶段会有严格 Code Review 阶段，也会完整经历单元测试、集成测试、性能测试和容灾测试流程。变更管理：有着非常严格的变更制度，要做到每个变更可灰度、可监控、可回滚、可降级。稳定性防护：提供了限流、降级、容量评估、应急方案、大促保障等能力，会定期进行故障和预案演练，定期进行风险梳理。体系化巡检：在云上有全方位的生产环境黑盒巡检。基于用户视角，会对全地域所有功能做全功能扫描，包含高达 50 多项检测项，任意项功能出问题都能立刻被监测到。在白盒巡检方面，会对 JVM 运行时指标、内核系统、集群指标进行巡检。故障应急：有完整地故障应急流程，包括监控报警、故障发生、快速止血、排查根因、故障复盘。RocketMQ 5.0 云原生架构升级之路云原生时代，云上用户对云产品服务化程度、弹性能力、可控制性能力以及韧性都有了更高的要求。在此背景之下，我们对 RocketMQ 进行了云原生架构升级，这也是 RocketMQ 5.0 的诞生背景。轻量级 SDK：基于云原生通信标准 gRPC 开发了一组轻量级 SDK，能够与当前富客户端优势互补。  无状态消息网关：在核心数据链路推出了无状态消息网关。通过搭建无状态服务节点Proxy，再通过 LB 进行服务暴露，将存储节点数据分离来独立负责核心消息存储和高可用。Proxy 与 Store 节点分离部署，独立弹性。 Leaderless 高可用架构：Store 节点身份完全对等，完全 Leaderless 化，去 ZK 和 HA 管控节点，能够做到非常高的可用性。同时相比传统的 Raft 一致性协议，该 Leaderless 架构能够做到副本数灵活选择，同步异步自动升降级，实现秒级故障转移。高可用架构目前已经完成开源并与 Dledger 进行了融合。 云原生基础设施：可观测验能力云原生化，OpenTelemetry 标准化。整体架构走向 Kubernetes 化，能够充分利用售卖区的资源弹性能力。RocketMQ 4.0 推荐的接入方式主要是富客户端。富客户端提供了诸如客户端侧负载均衡、消息缓存、故障转移等一系列企业级特性。但在云原生时代，轻量级、高性能的客户端更容易被云原生技术栈所集成。因此，RocketMQ 5.0 重磅推出了全新多语言轻量级 SDK，具有以下优势：全新极简 API 设计：不可变 API，有完善的错误处理。多语言 SDK 保障 API 在 Native 层面对齐。同时引入了全新的 Simple Consumer，能够支持按消息模型进行消费，用户不再需要关心消息队列，只需要关注消息。 通信层采用 gRPC 协议：拥抱云原生通信标准，gRPC 能够使服务更易被集成。多语言 SDK 通信代码也可以通过 gRPC 快速生成，更 Native 。 轻量级实现：采用无状态消费模式，能够大幅降低客户端的实现复杂度。客户端更轻量，采用的应用也更容易被 Serverless化、Mesh 化。 云原生可观测性：客户端实现了 OpenTelemetry 标准，能够支持以 OpenTelemetry 形式导出 Metrics 与 Tracing。RocketMQ 5.0 的另一个重大升级是引入了全新的无状态消费模型。该消费模型完全构建在原先的队列模型之上。队列模型是与存储模型一致的消费模型，消费者完全按照队列做负载均衡，也按照队列做消息拉取，非常适合批量高速拉取以及对单条消息状态不敏感的场景，比如流计算等。RocketMQ 5.0 推出了 PoP 机制，巧妙地在队列模型之上构建了消息模型，实现了鱼与熊掌兼得。在此消息模型的设计上，业务可以只关心消息而无需关心队列，所有 API 都能够支持单条消息级别的消费、重试、修改不可见时间、删除。在消息模型下，消息发送过来被存储后，即对消费者可见。消费者通过 Receive Message API 对消息进行消费后，消息进入定时不可见状态。消息超时过后又会重新处于可见状态，能被其他消费者继续消费。某消费者确认消息后，服务端会对该消息进行删除，随即不可见。基于消息系模型的消费流程下，API 完全面向消息而不是面向队列。而当 PoP 机制遇见了无状态 Proxy，除了存储层，其他节点都是无状态的；客户端、连接和消费也是无状态的，可任意在 Proxy 节点上飘移，真正做到轻量级。经过重构，RocketMQ 5.0 的可观测性也走向了云原生标准。Metrics 侧：指标涵盖丰富：设计了更丰富的指标，包含消息量、堆积量、各个阶段耗时等指标，每个指标从实例、Topic、消费 GroupID 多维度做聚合和展示。消息团队实践模板：为用户提供实践模板，并持续迭代更新。Prometheus + Grafana：Prometheus 标准数据格式，利用 Grafana 展示。除了模板，用户也可以自定义展示大盘。Tracing 侧：OpenTelemetry Tracing 标准：RocketMQ Tracing 标准已经合并到 OpenTelemetry 开源标准，提供了规范和丰富的 messaging tracing 场景定义。消息领域定制化展示：按照消息维度重新组织抽象的请求 span数据，展示一对多的消费，多次消费信息直观且方便理解。可衔接 tracing 链路上下游：消息的 tracing 可继承调用上下文，补充到完整的调用链路中，消息链路信息串联了异步链路的上游和下游链路信息。Logging 侧：Error Code 标准化：不同的错误有唯一的 Error Code。Error Message 完整：包含完整的错误信息和排序所需要的资源信息。Error Level 标准化：细化了各种不同错误信息的日志级别，用户可根据 Error、Warn 等级别配置更适合的监控告警。弹性方面，RocketMQ 5.0 商业版能够充分撬动云的计算、存储和网络的池化资源。比如在计算方面，RocketMQ 5.0 所有工作负载完全部署在 ACK 之上，充分利用了 ACK 弹性能力，撬动 ACK 弹性资源。主要依赖 ACK 的两项技术，一是弹性资源池，另一个是 HPA 支持计算能力快速弹性。同时也会在 ACK 之上做跨可用区部署以提供高可用保障。网络层面，RocketMQ 5.0 也会充分利用阿里云网络设施，为用户提供更便捷的网络访问能力。比如 RocketMQ 5.0 实例能够支持公网随开随用，需要依赖公网做测试的时候即开即用，测试完立即关闭，安全与方便兼具。同时支持多种私网类型的网络形态，包括 Single Tunnel、Private Link，另外也基于 CEN 构建了全球互通设计网络。存储方面，RocketMQ 5.0 商业版率先引入多级存储概念，基于 OSS 构建二级存储，能够充分利用 OSS 存储的弹性能力，存储计费也转向了按量付费。而用户能够在 RocketMQ 之上自定义消息存储时长，比如将消息从 3 天有效时长延长至 30 天，能够真正将消息变为数据资产。同时利用二级存储能力，将冷热数据分离，为用户提供一致的冷读 SLA 。RocketMQ 5.0 商业版发布预告RocketMQ 4.0 历经了五年发展，开源和商业版本共同迈入了 5.0 时代。7 月底，阿里云消息队列将会基于开源版发布全新的 5.0 商业化版本。注：截止发稿前，RocketMQ 5.0 已经在阿里云消息队列 RocketMQ 产品上全新发布，目前支持国内主要地域。RocketMQ 5.0 版相对于 4.0 版实例主要有以下几大改变：第一，新版本、新售卖，更便宜。新版本采取了全新计量方式，有包年、包月型，也有按量付费和公网流量弹性计费。也有更全的售卖体系，比如新增专业版实例，能够满足部分用户需求。同时每个商品系列都新增了测试环境专用实例，能够方便用户以低成本的方式搭建自己的开发环境。第二，更强弹性，降本提效利器。存储完全走向弹性，能够通过 Serverless 按需使用，按量付费。预留弹性，实例基础规格支持实时升降配，用户可以很方便地在流量到来之前做弹性。此外，专业版支持突发流量弹性，能够解决线上稳定性风险。第三，全新架构，增强可观测运维。无状态消息消费模型能够解决一些老版本的痛点。同时在可观测上全面采取了云原生接入栈。消息的全新形态：事件总线 EventBridge事件总线 EventBridge 已经开源到 RocketMQ 社区中。云原生时代，事件无处不在，云计算资源散落在各地，各类生态孤岛随处可见。因此，以事件和事件驱动的方式来集成这一切是大势所趋。基于此，阿里云推出了全新事件型产品 EventBridge。该产品构建在 RocketMQ 之上，是 RocketMQ 之上的一个事件驱动架构实践。EventBridge 的事件源包括阿里云服务的管控事件比如资源变更事件、审计事件、配置变更事件，阿里云服务的数据事件，也包括自定义应用、SaaS 应用、自建数据平台、其他云厂商服务等。事件经过 EventBridge 处理后会投递到事件目标，事件目标包括函数计算、消息服务、自建网关、HTTP(S)、短信、邮箱、钉钉等。事件源到事件目标之间会经历完整的事件处理，包括事件源接入到 EB 后，可以对事件进行过滤、转换、归档、回放等。事件在 EventBridge 整个流程中也有完善的可观测性设计，包括事件查询、链路追踪。事件的接入方式非常丰富，可以通过 OpenAPI 来接入、7 种多语言 SDK、CloudEvents SDK、Web Console 和 Webhook 。EventBridge 具有如下特点：能够大幅度减少用户开发成本，用户无需额外开发，通过创建 EventBridge 源、事件目标、事件规则等资源即可实现事件架构。用户可以编写事件规则，对事件做过滤、转换。 提供原生 CloudEvents 支持，拥抱 CNCF 社区，能够无缝对接社区 SDK 。标准协议也能统一个阿里云事件规范。 事件 Schema 支持：能够支持事件 Schema 自动探测和校验，支持 Source 和 Target 的 Schema 绑定。 全球事件任意互通：组建了全球事件任意互通网络，组件了跨地域、跨账户的事件网络，能够支持跨云、跨数据中心的事件路由。EventBridge在云上生态已经初具规模，已经集成了 255+ 云产品事件源和 1000+ 事件类型。EventBridge率先对消息生态做了融合。阿里云的消息产品矩阵生态均通过 EventBridge 做了完全融合。任何一款消息产品与另一款消息产品的数据都能互通。同时，依靠 EventBridge 的全球事件网络，能够为所有消息产品赋予全球消息路由的能力。EventBridge 目前已经在内部接入钉钉 ISV、聚石塔 ISV，外部也有 50+ SaaS 系统可以通过 Webhook 的方式接入。另外，海量事件源可以触达 10 多种事件目标，已经对接了全系云产品 API ，任何事件都可以驱动全量云产品 API。加入 Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献，相信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅可以结识社区大牛，提升技术水平，也可以提升个人影响力，促进自身成长。感兴趣的同学可以加入钉钉群与 RocketMQ 爱好者一起广泛讨论：钉钉扫码加群作者介绍：周新宇 - Apache Member，Apache RocketMQ PMC Member，阿里云消息队列 RocketMQ 研发负责人。点击此处，进入官网了解更多详情～
发表了文章
2022-10-12
Koordinator v0.7: 为任务调度领域注入新活力
作者： 李涛（吕风）Koordinator[1]继上次 v0.6版本​[2]发布后，经过 Koordinator 社区的努力，我们迎来了具有重大意义的 v0.7 版本。在这个版本中着重建设了机器学习、大数据场景需要的任务调度能力，例如 Coscheduling、ElasticQuota 和精细化的 GPU 共享调度能力。并在调度问题诊断分析方面得到了增强，重调度器也极大的提升了安全性，降低了重调度的风险。版本功能特性解读任务调度Enhanced Coscheduling Gang scheduling 是在并发系统中将多个相关联的进程调度到不同处理器上同时运行的策略，其最主要的原则是保证所有相关联的进程能够同时启动，防止部分进程的异常，导致整个关联进程组的阻塞。例如当提交一个 Job 时会产生多个任务，这些任务期望要么全部调度成功，要么全部失败。这种需求称为 All-or-Nothing，对应的实现被称作 Gang Scheduling(or Coscheduling) 。Koordinator 在启动之初，期望支持 Kubernetes 多种工作负载的混部调度，提高工作负载的运行时效率和可靠性，其中就包括了机器学习和大数据领域中广泛存在的具备 All-or-Nothing 需求的作业负载。为了解决 All-or-Nothing 调度需求，Koordinator v0.7.0 基于社区已有的 Coscheduling 实现了 Enhanced Coscheduling。Enhanced Coscheduling 秉承着 Koordiantor 兼容社区的原则，完全兼容社区 scheduler-plugins/Coscheduling 和依赖的 PodGroup CRD。已经使用 PodGroup 的用户可以无缝升级到 Koordinator。除此之外，Enhanced Coscheduling 还实现了如下增强能力：1. 支持 Strict 和 NonStrict 两种模式scheduler-plugins/Coscheduling 在调度失败时会 Reject 所有分配到资源但处于 Wait 状态的 Pod。这种模式我们定义为 Strict 模式，也是默认模式。但这种模式对于体量较大的 Job 并不是很友好，有可能会导致这种大体量的 Job 拿不到资源。为了解决这个问题，我们允许调度失败时不立即 Reject，并通过重试调度尝试拿到资源满足 MinMember。这种模式我们称为 NonStrict。虽然这种模式对于体量大的 Job 友好，可以让这种 Job 更快的调度完成，但同时也增加了资源死锁的风险。后续 Koordinator 会提供 NonStrict 模式下解决死锁的方案实现。要使用这种模式也比较简单，在 PodGroup 或者 Pod 中追加 annotation gang.scheduling.koordinator.sh/mode=NonStrict 开启 NonStrict 模式。2. 改进 PodGroup 调度失败的处理机制，实现更高效的重试调度社区 scheduler-plugins/Coscheduling 在调度失败后会在一段时间不在尝试处理该 PodGroup。这个时间一般是 20 秒。并且只支持按照插件维度配置，不支持用户按业务配置不同的时间。另外这种时间参数一般也难配置合适的值。而在 Enhanced Coscheduling 中，实现了一种基于 ScheduleCycle 的重试机制。可以简单的理解为一种熔断机制。每个 PodGroup 会有一个单调递增的变量，我们定义为 ScheduleCycle(PodGroup)，初始值为 1。该 PodGroup 关联的所有 Pod 也有一个 ScheduleCycle 变量，我们定义为 ScheduleCycle(Pod)，初始值为 ScheduleCycle(PodGroup) - 1。每次 Pod 调度时，ScheduleCycle(Pod) 等于当前 ScheduleCycle(PodGroup)。当一个 PodGroup 中的一个 Pod 调度失败时，会标记当前的 ScheduleCycle(PodGroup) 无效，后续其他 Pod 都会调度失败。当该 PodGroup 中所有 Pod ScheduleCycle(Pod) 都与当前 ScheduleCycle(PodGroup) 相等时，ScheduleCycle(PodGroup) 开始递增，允许重新开始进行调度。这种方式可以有效规避基于过期时间的缺陷，完全取决于调度队列的配置重试调度。基于 ScheduleCycle 的重试机制3. 支持多个 PodGroup 为一组完成 Gang Scheduling一些复杂的 Job 有多种角色，每个角色管理一批任务，每个角色的任务要求支持 All-or-Nothing ，每个角色的 MinMember 要求也不一样，并且每个角色之间也要求 All-or-Nothing。这就导致每个角色都有一个对应的 PodGroup ，并且还要求 PodGroup 即使满足了也需要等待其他角色的 PodGroup 必须满足。社区 Coscheduling 无法满足这种场景需求。而 Koordinator 实现的 Enhanced Coscheduling 支持用户在多个 PodGroup 中增加 anntation 相关关联实现，并支持跨Namespace。例如用户有 2 个 PodGroup ，名字分别是PodGroupA 和 PodGroupB，可以按照如下例子关联两个 PodGroup：apiVersion: v1alpha1
kind: PodGroup
metadata:
name: podGroupA
namespace: default
annotations:
gang.scheduling.koordinator.sh/groups: ["namespaceA/podGroupA", "namespaceB/podGroupB"]
spec:
...4. 支持轻量化 Gang 协议如果用户不希望创建 PodGroup，认为创建 PodGroup 太繁琐，那么可以考虑在一组 Pod 中填充相同的  annotation  gang.scheduling.koordinator.sh/name=<podGroupName> 表示这一组 Pod 使用 Coscheduling 调度。如果期望设置 minMember ，可以追加  Annotation gang.scheduling.koordinator.sh/min-available=<availableNum>。举个例子：apiVersion: v1
kind: Pod
metadata:
annotations:
gang.scheduling.koordinator.sh/name: "pod-group-a"
gang.scheduling.koordinator.sh/min-available: "5"
name: demo-pod
namespace: default
spec:
...ElasticQuota Scheduling 一家中大型公司内有多个产品和研发团队，共用多个比较大规模的 Kubernetes 集群，这些集群内含有的大量 CPU/Memory/Disk 等资源被资源运营团队统一管理。运营团队往往在采购资源前，通过额度预算的机制让公司内每个团队根据自身的需求提交额度预算。业务团队此时一般根据业务当前和对未来的预期做好额度预算。最理想的情况是每一份额度都能够被使用，但现实告诉我们这是不现实的。往往出现的问题是：团队 A 高估了业务的发展速度，申请了太多的额度用不完团队 B 低估了业务的发展速度，申请的额度不够用团队 C 安排了一场活动，手上的额度不够多了，但是活动只持续几周，申请太多额度和资源也会浪费掉。团队 D 下面还有各个子团队和业务，每个子团队内也会出现类似 A B C 三个团队的情况，而且其中有些团队的业务临时突发需要提交一些计算任务要交个客户，但是没有额度了，走额度预算审批也不够了。...... 以上大家日常经常遇到的场景，在混部场景、大数据场景，临时性突发需求又是时常出现的，这些资源的需求都给额度管理工作带来了极大的挑战。做好额度管理工作，一方面避免过度采购资源降低成本，又要在临时需要额度时不采购资源或者尽量少的采购资源；另一方面不能因为额度问题限制资源使用率，额度管理不好就会导致即使有比较好的技术帮助复用资源，也无法发挥其价值。总之，额度管理工作是广大公司或组织需长期面对且必须面对的问题。Kubernetes ResourceQuota 可以解决额度管理的部分问题。原生 Kubernetes ResourceQuota API 用于指定每个 Namespace 的最大资源额度量，并通过 admission 机制完成准入检查。如果 Namespace 当前资源分配总量超过 ResourceQuota 指定的配额，则拒绝创建 Pod。Kubernetes ResourceQuota 设计有一个局限性：Quota  用量是按照 Pod Requests 聚合的。虽然这种机制可以保证实际的资源消耗永远不会超过 ResourceQuota 的限制，但它可能会导致资源利用率低，因为一些 Pod 可能已经申请了资源但未能调度。Kuberenetes Scheduler-Sig 后来给出了一个借鉴 Yarn Capacity Scheduling，称作 ElasticQuota 的设计方案并给出了具体的实现。允许用户设置 max 和 min：max 表示用户可以消费的资源上限min 表示需要保障用户实现基本功能/性能所需要的最小资源量  通过这两个参数可以帮助用户实现如下的需求：用户设置 min < max 时，当有突发资源需求时，即使当前 ElasticQuota 的总用量超过了 min， 但只要没有达到 max，那么用户可以继续创建新的 Pod 应对新的任务请求。当用户需要更多资源时，用户可以从其他 ElasticQuota 中“借用(borrow)” 还没有被使用并且需要通保障的 min。当一个 ElasticQuota 需要使用 min 资源时，会通过抢占机制从其他借用方抢回来，即驱逐一些其他 ElasticQuota 超过 min 用量的 Pod。  ElasticQuota 还有一些局限性：没有很好的保障公平性。假如同一个 ElasticQuota 有大量新建的 Pod，有可能会消耗所有其他可以被借用的 Quota，从而导致后来的 Pod 可能拿不到 Quota。此时只能通过抢占机制抢回来一些 Quota。另外 ElasticQuota 和 Kubernetes ResourceQuota 都是面向 Namespace 的，不支持多级树形结构，对于一些本身具备复杂组织关系的企业/组织不能很好的使用 ElasticQuota/Kubenretes ResourceQuota 完成额度管理工作。Koordinator 针对这些额度管理问题，给出了一种基于社区 ElasticQuota 实现的支持多级管理方式的弹性 Quota 管理机制(multi hierarchy quota management)。具备如下特性：兼容社区的 ElasticQuota API。用户可以无缝升级到 Koordinator支持树形结构管理 Quota。支持按照共享权重(shared weight)保障公平性。允许用户设置是否允许借用 Quota 给其他消费对象。 1. Pod 关联 ElasticQuota 方式用户可以非常使用的使用该能力，可以完全按照 ElasticQuota 的用法，即每个 Namespace 设置一个 ElasticQuota 对象。也可以在 Pod 中追加 Label 关联 ElasticQuota：apiVersion: v1
kind: Pod
metadata:
labels:
quota.scheduling.koordinator.sh/name: "elastic-quota-a"
name: demo-pod
namespace: default
spec:
...2. 树形结构管理机制和使用方法需要使用树形结构管理 Quota 时，需要在 ElasticQuota 中追加 Label  quota.scheduling.koordinator.sh/is-parent表示当前 ElasticQuota 是否是父节点，quota.scheduling.koordinator.sh/parent表示当前 ElasticQuota 的父节点 ElasticQuota 的名字。举个例子：我们创建一个 ElasticQuota parentA 作为父节点，资源总量为CPU 100C，内存 200Gi，以及子节点 childA1apiVersion: scheduling.sigs.k8s.io/v1alpha1
kind: ElasticQuota
metadata:
name: parentA
namespace: default
labels:
quota.scheduling.koordinator.sh/is-parent: "true"
quota.scheduling.koordinator.sh/allow-lent-resource: "true"
spec:
max:
cpu: 100
memory: 200Gi
min:
cpu: 100
memory: 200Gi
---
apiVersion: scheduling.sigs.k8s.io/v1alpha1
kind: ElasticQuota
metadata:
name: childA1
namespace: default
labels:
quota.scheduling.koordinator.sh/is-parent: "false"
quota.scheduling.koordinator.sh/parent: "parentA"
quota.scheduling.koordinator.sh/allow-lent-resource: "true"
spec:
max:
cpu: 40
memory: 100Gi
min:
cpu: 20
memory: 40Gi在使用树形结构管理 ElasticQuota 时，有一些需要遵循的约束：除了根节点，其他所有子节点的 min 之和要小于父节点的 min。 不限制子节点 max，允许子节点的 max 大于父节点的 max。考虑以下场景，集群中有 2 个 ElasticQuota 子树：dev-parent 和 production-parent，每个子树都有几个子 ElasticQuota。当 production-parent 忙时，我们可以通过只降低 dev-parent 的 max 限制  dev-parent 整颗子树的资源使用量，而不是降低 dev-parent 子树的每个子 ElasticQuota 的 max 限制用量。 Pod 不能使用父节点 ElasticQuota。如果放开这个限制，会导致整个弹性 Quota 的机制变的异常复杂，暂时不考虑支持这种场景。 只有父节点可以挂子节点，不允许子节点挂子节点。 暂时不允许改变 ElasticQuota 的 quota.scheduling.koordinator.sh/is-parent 属性 我们将在下个版本中通过 webhook 机制实现这些约束。3. 公平性保障机制Koordinator ElasticQuota  支持按照共享权重(shared weight)保障公平性。shared-weight 表示一个 ElasticQuota 对象 的竞争力，默认等于 ElasticQuota Max。通过公平性保障机制，会给所有 min < max 的 ElasticQuota 分配实际可用的资源量，该资源量用 runtime表示，并保障 runtime 在min 与 max 之间，即 max >= runtime >= min。当一个 ElasticQuota 对象关联的所有 Pod 的资源请求量（我们定义为 request）大于 min 时，会借用其他 ElasticQuota 对象中 min 未分配的部分。被借出去的 Quota 需要使用时，会再次通过该公平性保障机制拿回来。另外还有一种日常生产时会遇到的情况：即集群内资源总量会随着节点故障、资源运营等原因降低，导致所有 ElasticQuota 的 min 之和大于资源总量。当出现这种情况时，我们无法确保 min 的资源需求。此时我们会按照一定的比例调整各个 ElasticQuota 的 min，确保所有 min 之和小于或者等于当前实际的资源总量。4. 抢占机制Koordinator ElasticQuota 机制在调度阶段如果发现 Quota 不足，会进入抢占阶段，按照优先级排序，抢占属于同一个ElasticQuota 内的 低优先级 Pod。同时，我们不支持跨 ElasticQuota 抢占其他 Pod。但是我们也提供了另外的机制支持从借用 Quota 的 ElasticQuota 抢回。举个例子，在集群中，有两个 ElasticQuota，ElasticQuota A {min = 50, max = 100}， ElasticQuota B {min = 50,  max = 100}。用户在上午 10 点使用 ElasticQuota A 提交了一个 Job， Request = 100 ，此时因为 ElasticQuota B 无人使用，ElasticQuota A 能从 B 手里借用 50 个 Quota，满足了 Request = 100， 并且此时 Used = 100。在 11 点钟时，另一个用户开始使用 ElasticQuota B 提交 Job，Request = 100，因为 ElasticQuota B 的 min = 50，是必须保障的，通过公平性保障机制，此时 A 和 B 的 runtime 均为 50。那么此时对于 ElasticQuota A ，Used = 100 是大于当前 runtime = 50 的，因此我们会提供一个 Controller，驱逐掉一部分 Pod ，使得当前 ElasticQuota A 的 Used 降低到 runtime 相等的水位。精细化资源调度Device Share Scheduling机器学习领域里依靠大量强大算力性能的 GPU 设备完成模型训练，但是 GPU 自身价格十分昂贵。如何更好地利用 GPU 设备，发挥 GPU 的价值，降低成本，是一个亟待解决的问题。Kubernetes 社区现有的 GPU 分配机制中，GPU 是由 kubelet 分配的，并只支持分配一个或多个完整的 GPU 实例。这种方法简单可靠，但类似于 CPU 和 Memory，GPU 并不是一直处于高利用率水位，同样存在资源浪费的问题。因此，Koordinator 希望支持多工作负载共享使用 GPU 设备以节省成本。此外，GPU 有其特殊性。比如下面的 NVIDIA GPU 支持的 NVLink 和超卖场景，都需要通过调度器进行中央决策，以获得全局最优的分配结果。从图中我们可以发现，虽然该节点有 8 个 GPU 实例，型号为 A100/V100，但 GPU 实例之间的数据传输速度是不同的。当一个 Pod 需要多个 GPU 实例时，我们可以为 Pod 分配具有最大数据传输速度组合关系的 GPU 实例。此外，当我们希望一组 Pod 中的 GPU 实例具有最大数据传输速度组合关系时，调度器应该将最佳 GPU 实例批量分配给这些 Pod，并将它们分配到同一个节点。1. GPU 资源协议Koordinator 兼容社区已有的 nvidia.com/gpu 资源协议，并且还自定义了扩展资源协议，支持用户更细粒度的分配 GPU 资源。kubernetes.io/gpu-core 代表 GPU 的计算能力。与 Kuberetes MilliCPU 类似，我们将 GPU 的总算力抽象为 100，用户可以根据需要申请相应数量的 GPU 算力。kubernetes.io/gpu-memory 表示 GPU 的内存容量，以字节为单位。kubernetes.io/gpu-memory-ratio 代表 GPU 内存的百分比。  假设一个节点有 4 个 GPU 设备实例，每个 GPU 设备实例有 8Gi 显存。用户如果期望申请一个完整的 GPU 实例，除了使用 nvidia.com/gpu 之外，还可以按照如下方式申请：apiVersion: v1
kind: Pod
metadata:
name: demo-pod
namespace: default
spec:
containers:
- name: main
resources:
limits:
kubernetes.io/gpu-core: 100
kubernetes.io/gpu-memory: "8Gi"
requests:
kubernetes.io/gpu-core: 100
kubernetes.io/gpu-memory: "8Gi"如果期望只使用一个 GPU 实例一半的资源，可以按照如下方式申请：apiVersion: v1
kind: Pod
metadata:
name: demo-pod
namespace: default
spec:
containers:
- name: main
resources:
limits:
kubernetes.io/gpu-core: 50
kubernetes.io/gpu-memory: "4Gi"
requests:
kubernetes.io/gpu-core: 50
kubernetes.io/gpu-memory: "4Gi"2. 设备信息和设备容量上报在 Koordinator v0.7.0 版本中，单机侧 koordlet 安装后会自动识别节点上是否含有 GPU 设备，如果存在的话，会上报这些 GPU 设备的 Minor ID、 UUID、算力和显存大小到一个类型为 Device CRD 中。每个节点对应一个 Device CRD 实例。Device CRD 不仅支持描述 GPU，还支持类似于 FPGA/RDMA 等设备类型，目前 v0.7.0 版本只支持 GPU， 暂未支持这些设备类型。Device CRD 会被 koord-manager 内的 NodeResource controller 和 koord-scheduler 消费。NodeResource controller 会根据 Device CRD 中描述的信息，换算成 Koordinator 支持的资源协议 kubernetes.io/gpu-core,kubernetes.io/gpu-memory 更新到  Node.Status.Allocatable 和 Node.Status.Capacity 字段，帮助调度器和 kubelet 完成资源调度。gpu-core 表示 GPU 设备实例的算力，一个实例的完整算力为100。假设一个节点有 8 个 GPU 设备实例，那么节点的 gpu-core 容量为 8 * 100 = 800；gpu-memory 表示 GPU 设备实例的显存大小，单位为字节，同样的节点可以分配的显存总量为 设备数量 * 每个实例的单位容量，例如一个 GPU 设备的显存是 8G，节点上有 8 个 GPU 实例，总量为 8 * 8G = 64G。apiVersion: v1
kind: Node
metadata:
name: node-a
status:
capacity:
koordinator.sh/gpu-core: 800
koordinator.sh/gpu-memory: "64Gi"
koordinator.sh/gpu-memory-ratio: 800
allocatable:
koordinator.sh/gpu-core: 800
koordinator.sh/gpu-memory: "64Gi"
koordinator.sh/gpu-memory-ratio: 8003. 中心调度分配设备资源Kuberetes 社区原生提供的设备调度机制中，调度器只负责校验设备容量是否满足 Pod，对于一些简单的设备类型是足够的，但是当需要更细粒度分配 GPU 时，需要中心调度器给予支持才能实现全局最优。Koordinator 调度器 koord-scheduler 新增了调度插件 DeviceShare，负责精细度设备资源调度。DeviceShare 插件消费 Device CRD，记录每个节点可以分配的设备信息。DeviceShare 在调度时，会把 Pod 的GPU资源请求转换为 Koordinator 的资源协议，并过滤每个节点的未分配的 GPU 设备实例。确保有资源可用后，在 Reserve 阶段更新内部状态，并在 PreBind 阶段更新 Pod Annotation，记录当前 Pod 应该使用哪些 GPU 设备。DeviceShare 将在后续版本支持 Binpacking  和 Spread 策略，实现更好的设备资源调度能力。4. 单机侧精准绑定设备信息Kubernetes 社区在 kubelet 中提供了 DevicePlugin 机制，支持设备厂商在 kubelet 分配好设备后有机会获得设备信息，并填充到环境变量或者更新挂载路径。但是不能支持 中心化的 GPU 精细化调度场景。针对这个问题， Koordinator 扩展了 koord-runtime-proxy ，支持在 kubelet 创建容器时更新环境变量，注入调度器分配的 GPU 设备信息。调度器诊断分析大家在使用 Kubernetes 时经常会遇到一些调度相关的问题：我这个 Pod 为什么不能调度？这个 Pod 为什么会调度到这个节点，不是应该被另一个打分插件影响到么？我新开发了一个插件，发现调度结果不符合预期，但是有不知道哪里出了问题。 要诊断分析这些问题，除了要掌握 Kubernetes 基本的调度机制和资源分配机制外，还需要调度器自身给予支持。但是 Kubernetes kube-scheduler 提供的诊断能力比较有限，有时候甚至没有什么日志可以查看。kube-scheduler 原生是支持通过 HTTP 更改日志等级，可以获得更多日志信息，例如执行如下命令可以更改日志等级到 5：$ curl -X PUT schedulerLeaderIP:10251/debug/flags/v --data '5'
successfully set klog.logging.verbosity to 5Koordinator 针对这些问题，实现了一套 Restful API ，帮助用户提升问题诊断分析的效率分析 Score 结果 PUT /debug/flags/s  允许用户打开 Debug Score 开关，在打分结束后，以Markdown 格式打印 TopN 节点各个插件的分值。例如：$ curl -X PUT schedulerLeaderIP:10251/debug/flags/s --data '100'
successfully set debugTopNScores to 100当有新 Pod 调度时，观察 scheduler log 可以看到如下信息| # | Pod | Node | Score | ImageLocality | InterPodAffinity | LoadAwareScheduling | NodeAffinity | NodeNUMAResource | NodeResourcesBalancedAllocation | NodeResourcesFit | PodTopologySpread | Reservation | TaintToleration |
| --- | --- | --- | ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:|
| 0 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.51 | 577 | 0 | 0 | 87 | 0 | 0 | 96 | 94 | 200 | 0 | 100 |
| 1 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.50 | 574 | 0 | 0 | 85 | 0 | 0 | 96 | 93 | 200 | 0 | 100 |
| 2 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.19 | 541 | 0 | 0 | 55 | 0 | 0 | 95 | 91 | 200 | 0 | 100 |
| 3 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.18 | 487 | 0 | 0 | 15 | 0 | 0 | 90 | 82 | 200 | 0 | 100 |找个 Markdown 工具，就可以转为如下表格：调度插件导出内部状态 像 koord-scheduler 内部的 NodeNUMAResource 、 DeviceShare 和 ElasticQuota 等插件内部都有维护一些状态帮助调度。koord-scheduler 自定义了一个新的插件扩展接口（定义见下文），并会在初始化插件后，识别该插件是否实现了该接口并调用该接口，让插件注入需要暴露的 RestfulAPI。以 NodeNUMAResource 插件为例，会提供/cpuTopologyOptions/:nodeName 和/availableCPUs/:nodeName 两个 Endpoints，可以查看插件内部记录的 CPU 拓扑信息和分配结果。type APIServiceProvider interface {
RegisterEndpoints(group *gin.RouterGroup)
}用户在使用时，按照 /apis/v1/plugins/<pluginName>/<pluginEndpoints>方 式构建 URL 查看数据，例如要查看 /cpuTopologyOptions/:nodeName：$ curl schedulerLeaderIP:10252/apis/v1/plugins/NodeNUMAResources/cpuTopologyOptions/node-1
{"cpuTopology":{"numCPUs":32,"numCores":16,"numNodes":1,"numSockets":1,"cpuDetails":....查看当前支持的插件 API 为了方便大家使用，koord-scheduler 提供了 /apis/v1/__services__ 查看支持的 API Endpoints$ curl schedulerLeaderIP:10251/apis/v1/__services__
"GET": [
"/apis/v1/__services__",
"/apis/v1/nodes/:nodeName",
"/apis/v1/plugins/Coscheduling/gang/:namespace/:name",
"/apis/v1/plugins/DeviceShare/nodeDeviceSummaries",
"/apis/v1/plugins/DeviceShare/nodeDeviceSummaries/:name",
"/apis/v1/plugins/ElasticQuota/quota/:name",
"/apis/v1/plugins/NodeNUMAResource/availableCPUs/:nodeName",
"/apis/v1/plugins/NodeNUMAResource/cpuTopologyOptions/:nodeName"
}更安全的重调度在 Koordinator v0.6 版本中我们发布了全新的 koord-descheduler，支持插件化实现需要的重调度策略和自定义驱逐机制，并内置了面向 PodMigrationJob 的迁移控制器，通过 Koordinator Reservation 机制预留资源，确保有资源的情况下发起驱逐。解决了 Pod 被驱逐后无资源可用影响应用的可用性问题。Koordinator v0.7 版本中，koord-descheduler 实现了更安全的重调度支持 Evict 限流，用户可以根据需要配置限流策略，例如允许每分钟驱逐多少个 Pod支持配置 Namespace 灰度重调度能力，让用户可以更放心的灰度支持按照 Node/Namespace 配置驱逐数量，例如配置节点维度最多只驱逐两个，那么即使有插件要求驱逐该节点上的更多 Pod，会被拒绝。感知 Workload ，如果一个 Workload 正在发布、缩容、已经有一定量的 Pod 正在被驱逐或者一些 Pod NotReady，重调度器会拒绝新的重调度请求。目前支持原生的 Deployment，StatefulSet 以及 Kruise  CloneSet，Kruise AdvancedStatefulSet。 后续重调度器还会提升公平性，防止一直重复的重调度同一个 workload ，尽量降低重调度对应用的可用性的影响。其他改动Koordinator 进一步增强了 CPU 精细化调度能力，完全兼容 kubelet ( <= v1.22) CPU Manager static 策略。调度器分配 CPU 时会避免分配被 kubelet 预留的 CPU，单机侧 koordlet 完整适配了 kubelet 从 1.18 到 1.22 版本的分配策略，有效避免了 CPU 冲突。资源预留机制支持 AllocateOnce 语义，满足单次预留场景。并改进了 Reservation 状态语义，更加准确描述 Reservation 对象当前的状态。改进了离线资源(Batch CPU/Memory) 的声明方式，支持 limit 大于 request 的资源描述形式，可以方便原 burstable 类型的任务直接转换为混部模式运行。 你可以通过 Github release[3]页面，来查看更多的改动以及它们的作者与提交记录。社区参与非常欢迎你通过 Github/Slack/钉钉/微信 等方式加入我们来参与 Koordinator 开源社区。你是否已经有一些希望与我们社区交流的内容呢？可以通过以下渠道参与讨论：加入社区 Slack channel[4] (English)加入社区钉钉群：搜索群号 33383887 (Chinese) 或者扫描下方二维码 相关链接[1] Koordinatorhttps://koordinator.sh/[2] Koordinator 0.6 Release Notehttps://mp.weixin.qq.com/s/YdoxVxz_91ZFemF8JuxRvQ[3] Github Releasehttps://github.com/koordinator-sh/koordinator/releases/tag/v0.6.1[4] Slack Channelhttps://join.slack.com/t/koordinator-sh/shared_invite/zt-1756qoub4-Cn4~esfdlfAPsD7cwO2NzA[5] Design: Gang Schedulinghttps://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/scheduling/20220901-gang-scheduling.md[6] Design: Multi Hierarchy ElasticQuota Managementhttps://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/scheduling/20220722-multi-hierarchy-elastic-quota-management.md[7] Design: Fine-grained Device Schedulinghttps://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/scheduling/20220629-fine-grained-device-scheduling.md[8] 云原生混部系统 Koordinator 架构详解https://mp.weixin.qq.com/s/y8k_q6rhTIubQ-lqvDp2hw点击此处，立即了解 Koordinator 项目！
发表了文章
2022-10-10
RocketMQ 5.0：无状态代理模式的探索与实践
本文作者：金吉祥， Apache RocketMQ PMC Member，阿里云智能高级技术专家背景首先，让我们来看下是遇到了哪些痛点问题，促使我们去探索一种无状态代理的RocketMQ新架构的；RocketMQ 拥有一套极简的架构，多语言客户端通过自定义的 Remoting 协议与后端 NameServer 和 Broker建立 TCP 长连接，然后进行消息的路由发现以及完整的消息收发。这套架构的优势是：架构极简，客户端 与 Broker 通过 TCP 直连的模式，拥有较高的性能以及较低的延迟。同时，这套架构采取的是队列模型，非常适合基于队列批量高速拉取消息的场景。同时，RocketMQ 在上云过程中面临了各种各样的挑战。首先，云上用户需要更为丰富的业务语义消息，包括事务、定时、顺序以及死信等。为了满足用户的业务侧需求，需要在原先架构的客户端侧和 Broker侧分别进行开发，用户必须升级客户端之后才能享受新功能。其次，上云过程需要面对更为复杂的网络环境，不同场景下需要不同类型网络的接入。有些用户为了便捷性，期望能够交付公网的接入点，让不同地域的消费者、发送者都能连接到同一个消息服务；而另一种用户为了安全性，需要内网接入点来隔离一些非法的网络请求；RocketMQ原先的架构在应对多网络类型的接入诉求时，成本是比较高的，多网络类型的接入必须同时覆盖NameServer和Broker的每一台机器才行。比如我们需要对内部 Broker进行扩容场景下，如果原先的 Broker 拥有多种类型的网络接入诉求，那么新扩容的 Broker也需要额外绑定上多种类型的网络接入点之后才能正常对外交付。做下总结，面对上云的挑战，此前的架构逐渐暴露出了如下诸多痛点：① 富客户端形态：客户端包含了大量企业级特性。用户必须升级客户端才能享受新功能，过程十分漫长。且同样的功能交付必须在多个多语言版本里都进行适配才能满足多语言客户端的接入，工作量巨大。② 客户端与Broker所有节点的直连模式满足多类型网络接入的成本较高。③ 按照队列进行负载均衡和消息拉取，后端扩缩容时会触发客户端rebalance，导致消息延迟或重复消费，消费者会有明显的感知；此外， 基于队列的模型非常容易导致一个用户饱受困扰的问题：单个故障消费者消费卡住会导致消息在服务端大量堆积。RocketMQ5.0无状态代理模式为了解决上述痛点，RocketMQ 5.0 提出了无状态代理模式。新架构在原先的客户端和Broker中间插入了代理层。策略上是将客户端的无状态功能尽可能下移到代理层，同时也将 Broker侧的无状态功能尽可能上移到代理层。在这里，我们将客户端的原有的负载均衡机制、故障隔离、push/pop消费模型下移到了代理层，将 Broker 的访问控制、多协议适配、客户端治理以及NameServer 的消息路由能力上移到了代理层，最终打造出的代理层的丰富能力，包含访问控制、多协议适配、通用业务能力、治理能力以及可观测性等。在构建代理层的过程中，我们必须坚持的一个原则就是：客户端和 Broker 往代理层迁移的能力必须是无状态的，这样才能保证后续代理层是可以随着承接的流量大小进行动态扩缩容的。在引入无状态代理层后，RocketMQ原先客户端、Broker的直连架构就演变为上图的无状态代理模式架构：从流量上看，代理层承接了客户端侧所有流量， Broker 和 NameServer 不再直接对用户暴露，用户唯一能看到的组件只有代理层（Proxy）。这里，Proxy的职责包括以下几个方面：多协议适配: Proxy具备解析和适配不同协议的能力，包含 remoting 、gRPC、HTTP 以及后续可能衍生出来的MQTT和AMQP等协议。Proxy对不同协议进行适配、解析，最终统一翻译成与后端 Broker 和 NameServer 之间的 remoting协议。流量治理和流量分发: Proxy承接了客户端侧所有流量，因此能够很轻松地基于某些规则识别出当前流量的特性，然后根据一定的规则将流量分发到后端不同的 Broker集群，甚至进行精准的流量控制、限流等。功能扩展：包括访问控制比如允许哪个用户访问后端Broker集群中的哪个 Topic、消息轨迹的统一收集以及整体的可观测性等。Proxy能扮演NameServer，交付给客户端查询TopicRoute的能力。Proxy能够无缝兼容用户侧的Pop或者Push消费模式：在Proxy和Broker侧采用Pop消费模式来避免单个队列被锁导致消息在服务端堆积的历史遗留问题。同时，我们也可以看到Proxy具有以下两大特性：① 无状态，可根据用户以及客户端的流量进行水平扩缩容。② 计算型，比较消耗CPU，因此在部署时需要尽可能给Proxy分配多些CPU。做下总结，无状态代理模式解决了原先架构的多个痛点：① 将客户端大量业务逻辑下移到代理层，打造出轻量客户端。同时，依托于 gRPC协议的标准化以及传输层代码自动生成的能力，能够快速适配多种语言的客户端。② 客户端只会与Proxy层连接，针对多网络类型接入的诉求，可以将多网络类型绑定到Proxy层，由于Broker 和 NameServer不再直接对客户端暴露，转而只需对 Proxy暴露内网的连接即可，多网络类型接入的诉求可以只在Proxy这个组件就封闭掉；同时，Proxy的无状态的特性保证了多类型网络接入是与集群规模无关的。③ 消费模式进行了无感知切换，无论客户端侧选择的是Pop还是Push消费模式，最终统一替换为Proxy与Broker侧的Pop消费模式，避免单个客户端消费卡住导致服务端消息堆积的历史问题。RocketMQ无状态代理模式技术详解新架构在客户端和 Broker 之间引入了代理层，客户端所有流量都需要多一跳网络、多经历一次序列化/反序列化的过程，这对端到端消息延迟敏感的用户是极其不友好的，因此我们设计了合并部署形态。合并部署形态下，Proxy和 Broker 按照1：1的方式对等部署，且 Proxy和 Broker 实现进程内通信，满足低延迟、高吞吐的诉求。同时，Proxy仍然具备多协议适配的能力，客户端会与所有 Proxy建立连接进行消息收发保证能够消费到所有消息。代码实现上，我们通过构造器来实现合并部署和分离部署的两种形态。用户可自行选择部署形态。如果用户选择合并部署的形态，则在构建 Proxy处理器之前，会先构造 BrokerController，并向 Proxy的处理器注册,本质上是为了告知Proxy处理器：后续的请求往我这个BrokeController 发；如果用户选择分离部署模式，则无须构建BrokerController，直接启动Proxy处理器即可。对于这两种部署模式的比较，首先，合并部署和分离部署同时具备了多协议的适配能力，都能够解析用户侧和客户端侧的多协议请求；且具备模型抽象，能够解决富客户端带来的一系列痛点。部署架构上，合并部署是一体化的架构，易于运维；分离部署是分层的架构，Proxy组件独立部署，Proxy和 broker按业务水位分别进行扩缩。性能上，合并部署架构少一跳网络和一次序列化，有较低的延迟和较高的吞吐；分离部署多一跳网络和一次序列化，开销和延迟有所增加。延迟具体增加多少主要依赖于 Proxy和 Broker 之间的网络延迟。资源调度上，合并部署状态下比较容易获得稳定的成本模型，因为组件单一；分离部署形态下Proxy是 CPU 密集型，Broker和NameServer 也逐渐退化成存储和 IO 密集型，需要分配比较多的内存和磁盘空间，因此需要进行细粒度的分配和资源规划，才能让分离部署形态资源的利用率达到最大化。多网络类型接入成本上，合并部署成本较高，客户端需要与每一个 Proxy副本都尝试建立连接，然后进行消息收发。因此，多网络接入类型场景下，Proxy进行扩缩容时需要为每台Proxy绑定不同类型的网络；分离部署模式成本较低，仅需要在独立部署的 Proxy层尝试绑定多网络类型的接入点即可，同时是多台Proxy绑定到同一个类型的网络接入点即可。针对业务上的选型建议：如果对端到端的延迟比较敏感，或期望使用较少的人力去运维很大集群规模的RocketMQ部署，或只需要在单一的网络环境中使用RocketMQ的，比如只需内网访问，则建议采用合并部署的模式。如果有多网络类型接入的诉求比如同时需要内网和公网的访问能力或想要对RocketMQ进行个性化定制，则建议采用分离部署的模式，可以将多网络类型的接入点封闭在 Proxy层，将个性化定制的改造点也封闭在Proxy层。社区新推出的PopConsumer消费模式和原先的PushConsumer 消费模式存在较大区别。PushConsumer 是基于队列模型的消费模式，但存在一些遗留问题。比如单个 PushConsumer 消费卡住会导致服务端侧消息堆积。新推出的Pop消费模式是基于消息的消费模型，PopConsumer 会尝试和所有 broker 连接并消费消息，即便有一个PopConsumer消费卡住，其他正常的PopConsumer依然能从所有 broker里拉取到消息进行消费，不会出现消息堆积。从Proxy代理层角度看，它能够无缝适配 PushConsumer 和 PopConsumer，最终将两种消费模式都映射到 Pop 消费模式，与后端 Broker 建立消费连接。具体来看，PushConsumer 里的pull请求会被转成PopConsumer 消费模式里的 pop 请求，提交位点的 UpdateConsumeOffset 请求会被转换成消息级别的 ACK 请求，SendMessageBack会被转换成修改消息的不可见时间的请求，以达到重新被消费的目的。Proxy最上层为协议的适配层，通过不同的端口对客户端暴露服务，不同协议通过不同端口请求到Proxy之后，协议适配层会进行适配，通过通用的 MessagingProcessor 模块，将send、pop、ack、ChangeInvisibleTime等请求转换成后端 Remoting 协议的请求，与后端的 Broker 和NameServer建立连接，进行消息收发。多协适配的优势有以下几个方面：① 加速了RocketMQ的云原生化，比如更容易与Service Mesh相结合。② 基于 gRPC 的标准性、兼容性及多协议多语言传输层代码的生成能力，打造RocketMQ的多语言瘦客户端，能够充分利用gRPC插件化的连接多路复用、序列化/反序列化的能力，让RocketMQ客户端更加轻量化，将更多精力聚焦在消息领域的业务逻辑。做下技术方案的总结：无状态代理模式通过客户端下移、Broker侧上移无状态的能力到代理层，将访问控制、客户端治理、流量治理等业务收敛到代理层，既能够满足快速迭代的诉求，又能对变更进行收敛，更好保障整个架构的稳定性：有了分层架构之后，更多业务逻辑的开发会聚焦在 Proxy层,下一层的 Broker和 NameServer 趋于稳定，可以更多地关注存储的特性。Proxy的发布频率远远高于底层 Broker 的发布频率，因此问题收敛之后，稳定性也得到了保证。多协议适配，基于gRPC的标准性、兼容性以及多语言传输层代码生成的能力打造RocketMQ的多语言瘦客户端。Push 到 Pop 消费模式的无感知切换，将消费位点的维护收敛到 Broker， 解决了单一消费者卡住导致消息堆积的历史遗留问题。另外，我们也尝试探索了可分可合的部署形态，保证同一套代码可分可合，满足不同场景下对性能部署成本、易运维性的差异化诉求。在大部分的场景下，依然建议选择合并部署的形态。如果有对多网络类型接入的诉求，或对RocketMQ 有极强的定制化诉求，则建议选择分离部署的形态，以达到更好的可扩展性。代理层无状态的特性，极大降低了适配多类型网络接入诉求的成本。未来规划未来，我们期望RocketMQ底层的Broker和NameServer 更多聚焦在存储的特性上，比如业务型消息存储的事务、定时、顺序等，快速构建消息索引、打造一致性多副本提升消息可靠性、多级存储来达到更大的存储空间等。其次，对无状态代理层依照可插拔的特性开发，比如对访问控制、抽象模型、协议适配、通用业务能力、治理能力等按模块进行划分，使语义更丰富，可按照不同场景的诉求可插拔地部署各种组件。最后，我们期望这一套架构能够支持阿里云上的多产品形态，致力于打造云原生消息非常丰富的产品矩阵。加入 Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献，相信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅可以结识社区大牛，提升技术水平，也可以提升个人影响力，促进自身成长。社区 5.0 版本正在进行着如火如荼的开发，另外还有接近 30 个 SIG（兴趣小组）等你加入，​欢迎立志打造世界级分布式系统的同学加入社区，添加社区开发者微信：rocketmq666 即可进群，参与贡献，打造下一代消息、事件、流融合处理平台。​​​​微信扫码添加小火箭进群​​另外还可以加入钉钉群与 RocketMQ 爱好者一起广泛讨论：​​​​钉钉扫码加群​​关注「Apache RocketMQ」公众号，获取更多技术干货
发表了文章
2022-10-10
快手 RocketMQ 高性能实践
本文作者：黄理，快手在线消息系统负责人。快手对于 RocketMQ 社区版本的优化一般为在其外层进行能力的构建，而不是对其内部进行大改动，因为内部大改不利于后期的版本升级。即使对内部 RocketMQ 进行了修改，我们也会尽量通过 PR 将新特性回馈到社区。快手会定期对 RocketMQ 进行升级。2022年春节，我们大胆使用了尚未正式发布的 RocketMQ 4.9.3-SNAPSHOT 版本，平稳度过了快手一年中最重要的活动，这也证实了社区版本 RocketMQ 的兼容性和稳定性。应用篇RocketMQ 进入快手两年内，从 0 发展到每天数千亿消息级别。快手是 RocketMQ 社区版本的事务消息最早的大规模用户，目前每天有百亿以上的事务消息和定时消息，实现了跨 IDC的自动负载均衡以及容灾，实现了多级泳道（项目）互不干扰，多个项目可同时开发，以及可回落。RocketMQ的落地方式一般为两种。方式一：在开源软件的基础上进行修改，能够快速轻松地实现需要的功能，但后续升级存在很大不便。方式二：对RocketMQ的 client 和 server 只进行少量修改。如果 server 存在能力缺失，会开发辅助的 server 或以 proxy 进行补充。我们在 client 之上包装了一层 MQ SDK，对用户屏蔽了具体实现。快手也是基于此方式对RocketMQ进行了落地。MQ SDK如上图，分为三层：最上层为 API ，用户与该层打交道；中间为核心层，能够实现各种通用的能力；最底层负责与具体的 MQ 交互，当前只有 RocketMQ 的实现，但未来也许会有其他消息中间件的实现。中间层实现了热变更的能力。用户配置不写在代码里，而是在平台进行指定，指定以后热生效，SDK 会直接加载新的配置并自动 reload 用户程序，无需重启。RocketMQ 会分配 Logic topic，业务代码无需关心集群在哪，无需关心当前环境，也无需关心数据标记比如压测、泳道，只需使用我们提供的非常简单的 API ，复杂的过程全部在核心层进行封装，对业务用户屏蔽。上图为跨机房负载均衡的实现流程。所有Logic topic 都会映射到上图中间的两个机房，每个机房部署一个集群。RocketMQ 集群可以有多个 broker ，生产者和消费者对 broker 有故障感知和转移能力，能够通过 NameServer 发现哪个 broker 故障以避免与其进行连接。为了实现更好的控制，我们在集群之上又封装了一层负载均衡，并在 client 端实现。每一个 Logic topic 都被分配到两个集群，生产者在生产时会同时连接到两个集群。两个集群分别位于不同 IDC，同一地区的两个IDC之间延时大约为1-2ms。消费者侧也是双连，一旦某机房或集群发生故障，流量会立刻自动转移到另一机房。我们将生产端的自动负载均衡（自动failover）进行了抽象封装，做成了开源项目。Failover 组件与 RocketMQ 无关，在主调方做 RPC 或消息生产等调用时，会检查被调方的健康度。如果被调方不健康或响应很慢，则会调低其权重。扫描上方二维码，了解更多关于该组件的功能。RocketMQ 实现了简单的延迟消息，但是只能实现几个固定级别的延时，而实际的业务更希望发消息时可以任意指定延迟时间。因此我们通过外挂 Delay Server 的方式实现了任意精度的延迟消息。Delay Server 会将用户要求延迟投递的消息进行保存，等到指定时间以后，再将消息送回原来的业务 topic 。基于PULL的模式（RocketMQ的PUSH Consumer也是基于PULL），很难直接实现动态的多泳道隔离。因此很多公司会选择根据泳道的不同将消息投递到不同的 topic，这样虽然实现了功能，但是侵入性太强，并且也不好实现多级回落。而在快手，我们将所有泳道的消费都放在同一个 topic 里，并且实现了多级泳道回落。比如项目 A 和项目 B 同时在开发，项目 A 生产的消息由项目 A 的消费者消费。项目 A 下面有子项目A.X和A.Y，那么A.X生产的消息由A.X的消费者消费，但是如果A.Y没有消费者，因此A.Y生产的消息会回落到由 A 的消费者进行消费。快手的泳道隔离主要通过 RPC 转发实现。如上图，黄色线代表项目 A 的数据流向，橙色线代表项目 B 的数据流向。SDK 会在将数据交给业务用户之前，先检查数据的泳道标记是否匹配，如果不匹配，则会通过 RPC 的方式转发至匹配的消费者。这样我们等于是将 PULL 转为了 PUSH，在主调方进行选择，所以能够将所有项目放在同一个 topic 里，且能够实现隔离。RocketMQ 是基于 queue 来进行客户端的 rebanance，如果消费者的数量大于queue，则会导致部分消费者无事可做；或有时 queue 分配不均匀，导致部分消费者负担大、部分消费者负担小。我们通过RPC的方式实现了消费 Proxy，先从 RocketMQ 的 broker 消费数据，再通过 RPC 的方式  PUSH 到 consumer。消费 proxy 的 RPC 与前文的 RPC 转发使用同一套机制，因此RocketMQ 不需要过多的 queue， 但可以有很多消费者。消费 proxy 为可选项，只需在平台指定消费方式，无需修改代码也无需重启，即可直接热生效。此外，我们开发了拨测程序，生成了一个模拟的生产者和消费者。生产者会往线上所有集群的每一个 broker 发送消息，包括普通消息、定时消息和事务消息。消费者消费到消息后，会取出消息体内生产者的 IP 地址，然后通过 TCP 的方式 ACK 回生产者，告知生产者消息是否丢失、是否重复以及从生产到消费的延迟是多少。另外，还可以针对生产者和消费者进行各种配置，比如消息体大小、生产速率、对账抽样比例、对账周期等。比如在配置中将速率调大，即可实现压测，生产者和消费者会进行打点，最终可在 Grafana 上进行查看和告警。性能篇对 RocketMQ 进行性能优化后，300字节小消息生产 TPS 提升54%，同时 CPU占用降低11%；600 queue消费性能提升200%，跨IDC 100KB大消息单线程生产 TPS 提升693%，跨IDC 100KB集群消费吞吐提升250%。优化主要分为两批。第一批优化集中在RocketMQ4.9.1版本，包括清除多余的日志、消除不必要的锁、消除主从复制中的数组拷贝、优化Broker的默认参数、优化锁内操作的性能并将部分操作抽取到锁外、优化消息属性编解码的性能以及优化消息Header解析的性能。扫描二维码可阅读本次优化相关的完整文章。另外，RocketMQ 4.9.0版本的默认参数设置不合理，因此我们在4.9.1版本对其进行了优化，使得性能有了巨大提升。上图为第二批优化的目标：降低 CPU 开销。RocketMQ 不消耗 CPU，但是在混合部署场景下，CPU 极有可能会成为问题，因此需要对 CPU 开销进行优化。  提升跨机房的生产、消费的吞吐。提升大消息的吞吐。提升queue特别多的场景下的消费性能。第二批优化大部分集中在社区的ISSUE3585 里，扫描上方二维码可阅读完整文章。上图为第二批优化CPU 方面的具体内容，字母编号与 ISSUE3585 相对应。此前RocketMQ 使用 Fastjson 做序列化，而有一个自定义的协议性能略微优于 Fastjson，我们对其进行了深入研究和优化，最终使得 RocketMQ 在编解码上性能也得到了很大提升。RocketMQ 构建 Queue 的程序为单线程，因此我们使用mmap buffer 代替 FileChannel，性能得到了极大提高。上图红框中为某方法优化前后对比。此外，我们将 Pull 通知移动到另外的线程，使其不占用线程的资源。同时，将通知自动聚批，兼顾高吞吐和低延迟，只有 TPS 较高时才会自动打开，阈值可设置，避免 Pull 通知在 Broker 和消费者之间震荡频率过高，消耗 CPU。大消息性能不佳也是一直以来很大的困扰，经过分析我们发现 RocketMQ remoting 的 TCP 参数设置有待优化。原先的buffer 设置为固定值，当机房延迟很大时，过小的 buffer 会导致 TCP 连接的吞吐受到严重影响。因此，我们将 buffer 修改为由操作系统自动管理，以保证吞吐。上图列出了线上实测的数据表，可以看出消费的性能提升了数倍。在极高的 TPS 场景下，如果消息体较大，则操作系统内存分配可能会成为 RocketMQ 的瓶颈，4.X 的内核下的表现远远优于 3 .X 。极端场景下，3.X内核通常需要将参数 min_free_kbytes 调至较大值。我们于2021年12月社区开发者会议现场演示了性能测试，对比了第二批优化前后的4.9.2版本和4.9.3 Snapshot版本（包括当时还未合并进该版本的B和K的优化）的性能。测试时，在电脑上同时运行所有 broker、生产者、消费者。老版本TPS不到 3w，而新版本有了自动聚批的能力，TPS 可达 6 w，相比于老版本提升了一倍。加入 Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献，相信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅可以结识社区大牛，提升技术水平，也可以提升个人影响力，促进自身成长。社区 5.0 版本正在进行着如火如荼的开发，另外还有接近 30 个 SIG（兴趣小组）等你加​入，欢迎立志打造世界级分布式系统的同学加入社区，添加社区开发者微信：rocketmq666 即可进群，参与贡献，打造下一代消息、事件、流融合处理平台。​​微信扫码添加小火箭进群​另外还可以加入钉钉群与 RocketMQ 爱好者一起广泛讨论：​钉钉扫码加群​关注「Apache RocketMQ」公众号，获取更多技术干货
发表了文章
2022-10-08
已结束｜【仅剩10席】阿里云 Serverless Developer Meetup 杭州站报名倒计时！
来现场，一起谈天论技本周六我们邀请到 Serverless 一线技术讲师与 Serverless 技术爱好者在阿里巴巴西溪园区聚焦 Serverless 领域的新趋势进行技术分享助力各位实现技术成长名额不多，仅剩10席，报名从速！报名方式 1：点击文末“ 此处 ”进行报名报名方式 2：扫描下方or海报二维码Serverless 架构在不断的发展，也在不断的更新迭代，但是在当前阶段 Serverless 架构是什么样子的？企业落地究竟会带来哪些优势？带着这些问题，2022 Serverless Developer Meetup 首站集结！延续「Serverless 技术开发者实操与学习」的主题带领各位快速了解：如何使用 Serverless 架构进行 CICD 探索，助力企业加速创新？高德是如何在复杂业务场景中实践 Serverless？站在 K8s 生态角度看看 Serverless；Serverless 原子化能力如何帮助企业扩展业务系统？Serverless Workshop 杭州站限定开张：手把手体验有趣场景!活动详情此次活动仅限开放120个报名席位，我们在现场准备了超多精美礼品和茶歇等你，还有 Serverless Workshop 限定开张，阿里云专家手把手带你体验超级有趣，千人打磨的场景实验。活动时间：2022年9月17日（周六） 13：00-17：00活动地点：浙江省杭州市余杭区五常街道永寿街阿里巴巴西溪园区B区访客中心415A详细路线：（现场会有引导指示牌）到场嘉宾&议题介绍13:30 -14:05 | Serverless 架构的 CICD 探索分享嘉宾：袁坤（丹坤）阿里云云原生前端技术专家，Serverless Devs 开发者工具 PMC议题简介：现代化应用具备满足快速响应变化，敏捷的开发以及交付的特点，让企业能够加速创新、降低风险、加快上市速度并降低总体拥有成本。CICD 更是现代化应用的核心组成部分。本次分享主要和大家一起讨论下基于 Serverless 架构的 CICD 的探索以及实践。14:05-14:35 | 高德的 Serverless 落地实践分享嘉宾：刘金龙（福辰）高德服务端架构组 高级技术专家议题简介：FaaS 在高德复杂场景落地实践以及针对 FaaS 的高德建设了哪些能力，作为集团 FaaS 量最大的部分之一，是如何在复杂的业务体系中做到降本提效的。14:40-15:10 | Serverless 系统原子化能力 如何帮助企业扩展自己的业务系统史明伟（世如）阿里云高级技术专家议题简介：Serverless 系统凭借灵活的可扩展性和丰富的连接能力，一方面，客户可以按照函数计算的编程规范实现自己的业务逻辑， 凭借其轻量的开发体验和无服务器运维特征，快速构建自己的业务系统；另一方面，函数计算系统本身可以作为客户在公有云环境开箱即用的系统功能的延展，在实际的业务系统构建中，可以将核心系统的一部分能力进行分割后构建在公有云函数计算的系统架构上，可以为企业的业务系统提供弹性以及可靠性方面的灵活扩展性。15:25-15:55 | 从 Kubernetes 到 Serverless李健（一分）阿里云 Serverless 应用引擎技术专家议题简介：容器和 K8s 生态奠定了一系列应用交付的形态，其不可变基础设施以及面向终态等设计原则和 Serverless 的理念是极其一致的，某种程度来说 Kubernetes 就是 Serverless 理念的 Paas, 促进了 Serverless 的发展, 并再次让 Serverless 成为企业和开发人员关注的焦点。那么我们就一起站在 Kubernetes 生态的角度看看 Serverless。16:00-17:00 | Workshop 场景体验** 此环节无线上直播，如需参加务必带上电脑**场景体验竞赛！现场讲师贴心指导，4个经典 Serverless 场景，大家一起进行一场 Serverless 技术极限 PK，奖品丰富！实验场景：Serverless 函数计算一键部署线上商城基于函数计算 x Kafka 快速创建 ETL 任务基于 Serverless 极速搭建高性能网盘Serverless 应用引擎搭建五子棋游戏平台直播预约整场活动将会同步直播，不能到现场的小伙伴可以通过以下方式在线预约观看~阿里云开发者社区直播间地址：https://developer.aliyun.com/live/249994活动流程注意事项本次活动全程免费，临行前我们将以短信的形式通知各位，请凭码入场请到场开发者持72h核酸检测证明，戴好口罩绿码入园参加 Workshop 的开发者请自备个人电脑如有其它问题可钉钉搜索 33947367 进群联系我们具体活动时间以现场为准，请各位13：00前入场，我们在现场准备了茶歇等候各位距离 9.17 只剩 5 天还没有报名的开发者，赶快抓紧啦！点击文末【此处】或扫描海报二维码我们杭州现场见！
发表了文章
2022-10-08
5 分钟完成 ZooKeeper 数据迁移
作者：草谷前言MSE 提供了托管版的 ZooKeeper，包含比开源 ZooKeeper 更强大更稳定的功能，能帮助您免去运维 ZooKeeper 集群的烦恼，当我们需要从自建 ZooKeeper 迁移到 MSE ZooKeeper 上面时，往往依赖旧集群的数据，MSE 提供了多种数据迁移的方案，其中主流的方案可以通过 MSE Sync 进行实时同步，这样能够达到平滑不停机的目的，本文将介绍另外一种数据迁移的方式，主要针对业务支持停机的场景，进行一个补充，操作相比更加简单快速。实现原理在对 ZooKeeper 进行了若干次事务操作之后，ZooKeeper 会将内存数据全量写入到本地磁盘中，生成一个 snapshot 开头的快照文件，这个快照文件就包含了该集群的全量数据。同时 ZooKeeper 在节点启动的时候，会首先加载该快照文件进行一次数据初始化。基于此原理，我们可以将任意要迁移集群的快照文件，放到目标集群的快照路径中，然后重启目标集群就可以将迁移集群的数据加载到自己的内存中了，这样就完成了一次全量数据的迁移。数据导入实践步骤一：获取快照文件“支持开源 ZooKeeper 3.4.x～3.8.x 的数据迁移导入到 MSE ZooKeeper”我们先找到自建 ZooKeeper 的 Snap 缓存文件：文件名为 “snapshot.xxx”格式的：是 ZooKeeper 某个时刻的全量数据，ZooKeeper 会定时写到磁盘中的。文件路径 snapshot.xxx 文件的存储路径：会配置在 ZooKeeper 的 zoo.cfg（zoo.cfg 默认放在 zookeeper 目录的 conf 文件夹下）配置文件中，dataDir 项，例如：dataDir=/home/admin/zookeeper/zkData获取文件snapshot.xxx 一般在目录中会存在多个，拿最近时间生成那个即可：步骤二 ：准备 MSE 集群以下表格供参考，购买还需要参考 QPS/TPS 等维度的约束，例如读写数据较小，QPS/TPS 相应也能提高，具体以业务场景为准：步骤三：上传快照文件从注册配置中心列表页点击你购买的实例，进入 ZooKeeper 的基础信息页：从“节点管理”进入管理页面：点击“数据导入”，上传 Snapshot 文件，文件大小限制会根据你当前 ZooKeeper 配置自动提示，例如本次购买的 4C8G，提示最大不可超过 800M 大小：上传完了之后，3 个节点的集群大概 5 分钟左右，数据即可导入重启完成。结果验证数据导入完成之后，即可通过 endpoint 进行 MSE ZooKeeper 的访问，获取到迁移数据。“mse-xxxx-p.zk.mse.aliyuncs.com” 为集群的 endpoint： CuratorFrameworkFactory.builder().connectString("mse-xxxx-p.zk.mse.aliyuncs.com:2181")
.sessionTimeoutMs(10000).retryPolicy(
retryPolicy).
build().start();
ZooKeeper zk = new ZooKeeper("mse-xxxx-p.zk.mse.aliyuncs.com:2181", 30000,
new Watcher() {
@Override
public void process(WatchedEvent event) {
System.out.println("ZooKeeper=====" + event);
});购买 MSE Zookeeper 享受企业级服务
发表了文章
2022-10-08
传统大型国企云原生转型，如何解决弹性、运维和团队协同等问题
作者：王彬|杏祉尧|黄枫项目背景贵州酒店集团有限公司于 2019 年 2 月 28 日注册成立，是经贵州省人民政府批准并授权省国资委履行出资人职责的省管大一型企业，全资及控股子企业 23 家，自营及委管酒店（项目）80 余家，客房近 1.3 万间。酒店集团组建以来，构建了以酒店运营与管理为核心业务，以旅游商品、教育培训、会议会展、电商科技、黔菜餐饮为支柱业务的“1+N”主营业务架构，正逐步培育打造系列酒店、特色餐饮、教育培训等旅游产业化服务品牌体系。在 2020 年，成立了贵州乐旅网络科技有限公司专门负责酒店集团信息化建设，贵州乐旅网络科技有限公司肩负着建设酒店集团现代化信息系统的使命，初期在三四个人的快速迭代下，快速构建起了支撑全集团内外部业务的信息系统。随着公司的发展和市场需求的迅速变化，乐旅网络科技也不断壮大，从最初的三四个人发展到了十几人，系统模块越来越多，同时各种问题也开始显现。现状问题&分析酒店集团的信息系统最初部署在阿里云 ECS 上。系统按照微服务的架构拆分成多个组件，基于 ASP.NET Core 框架开发。在开发运维过程中遇到一系列问题：组件缺少扩展性：集团的业务有明显的峰谷特性，平台会定期上线一些活动，如土特产秒杀，酒店房间优惠，通过这些活动，用户可以获取抢购贵州名牌白酒的资格等。在活动期间访问量巨大，峰值最高能达到几十万 qps，是平时的几十倍。同时信息系统依旧延续第一代架构，扩展性不好，没法做到很好的弹性伸缩，对于越来越大的流量，系统稳定性问题愈发凸显。多环境建设不完善：线下测试环境与线上生产环境隔离，线下测试中并不能完全覆盖线上生产环境的场景，在上线时会出现需要上线的组件在线上真实环境中出现预期之外的异常，需要快速恢复，这就需要有很好的版本管理，这一块也是缺失的。团队协同效率低：整个系统有多个模块，分散在不同团队，ECS 机器也都是独立维护，发版过程需要上下游链路一起协同，按照依赖关系顺序发布，消耗时间长，协同难度大。监控系统不完善：运行状态没有统一的观测平台，遇到问题也只能子系统分别排查，且缺少问题排查协助工具。技术选型&对比为了更好的对应系统发展的需要，乐旅网络科技决定同阿里云达成战略合作，基于阿里云打造信息平台 2.0。在新架构的设计上，针对当前遇到的痛点问题，项目组在技术选型时定下了以下几个目标：1. 自动化运维，团队需求多，开发任务重，专门负责运维的同学并不多，希望 2.0 系统可以借助体系化的运维平台，提升运维效率，大幅减轻运维压力。2. 自动弹缩，团队的业务活动较多，活动到来时有不可预知的流量波峰，之前通过预估扩容的方式存在预估不准和扩展困难的问题，2.0 系统希望可以更加简单的扩缩系统，最好能够通过自动化的方式避免重复的部署和下线操作。3. 版本管理，测试环境并不能完全模拟线上生产环境，新上线的组件上线后可能会出现问题，希望能够有版本管理的工具，当遇到问题时，可以很方便的切换到指定版本，实现代码资产的可选管理。4. 团队协同，目前团队协作主要靠人为线下沟通，不同团队的组件都由自己维护，ECS 机器彼此也都权限隔离，2.0 版本希望可以使用统一的系统管理权限，实现不同团队，不同角色都可以使用同一套权限体系，简化团队之间协同的工作。5. 监控平台，目前的系统缺少监控，于实时运行状态监控几乎没有，目前只有基于机器运行指标的监控。各组件按照开发人员设计自行打日志，当出现问题时，排查问题链路冗长，且没法做到统一的链路追踪。由于系统缺少量化指标，对系统的把控性偏低，没法做到异常预警，也没法很好的做针对性的持续优化。2.0 系统希望在这方面有所改观，能多维度的对系统进行监控，增强对系统的控制力。为此，项目组在阿里云上进行了第一轮全面筛选，很快选型目标缩小到了自建 K8s 和 SAE，并对这两种技术进行了一系列的比对，主要比对指标如下：对比这两种技术后，考虑到自建 K8s 本身的复杂性，对技术栈的深度，技术的持续投入和业务的收益，项目组进行了多方面衡量，最终选择了 SAE。SAE 这款产品在免运维，自动弹缩，可观测等方面都深度符合酒店集团当前项目的需求，项目组在最初选型时就对以下几个功能非常感兴趣：免运维：SAE 能够免运维底层基础设施，例如 IaaS、K8s、微服务组件和 APM 组件等，无需自建 ZooKeeper、Eureka、Consul 和 Skywalking 等，极大降低开发运维成本。提供商业化稳定性兜底。自动弹缩：SAE 提供了精准容量+弹性+限流降级一整套高可用产品化解决方案。通过该方案，SAE 能够帮助应用轻松应对流量高峰，在保证业务 SLA 的同时也节省了资源成本。体系化监控：SAE 无缝集成的 ARMS 产品，具有白屏化应用监控和诊断能力，可用定位到慢 SQL、慢方法、方法的调用堆栈、对于线上问题的分析、排查、预警和解决，提供强有力支持，节省大量的排查时间。所以，最终项目组毫无疑问的选择了 SAE。项目开发过程&效果在项目组确定选型之后，项目组很快开始着手迁移系统到 SAE，迁移的过程比原计划的更加顺利，由于一开始设计集团的系统时便是基于微服务理念的，所以 ECS 上的组件迁移到 SAE 能够做到很顺滑，代码层面没有大的改动，迁移过程见下图：随着迁移工作的进行，项目组对 SAE 有了深入的了解，项目组又发现了更多贴合业务的功能点，具体表现：对 CICD 的支持：SAE 支持云效、Jenkins、源代码、Cloud Toolkit 插件、容器镜像服务等多种部署方式，自动完成从代码提交到应用和任务部署的 DevOps 完整流程，高效替代业内部署复杂、迭代缓慢的传统方式，实现了高效的持续交付流程。高可用和稳定性的支持：SAE 支持批量发布，微服务无损上下线，使组件在发布更新时，不会影响影响整体链路的可用性，另外 SAE 还支持多可用区的部署，使得应用的稳定性得到进一步的加强。权限助手：权限助手可以对 SAE 的权限进行可视化配置，精确到应用、任务的读写操作，并在 SAE 控制台生成对应的权限语句，避免因直接在 RAM 控制台手动编辑权限语句而出现纰漏。操作审计：SAE 记录了所有应用及资源相关的操作详情，包括操作时间、操作内容、操作人 ID 等信息，在出现问题时可以快速追溯原因。结合这些 SAE 的能力，本次信息平台 2.0 的建设，项目组没有大的改造原来代码逻辑的同时，基本完成了最初定下的目标，同时在开发，运维和协作的几个方面建设了自己的流程规范，快速追平了业内的优秀实践。总结&展望项目组最终在 2022 年 2 月份完成了整体的迁移，新系统上线后，通过 SAE 白屏化的操作界面，运维难度和压力都大大降低。根据 rt 和定时的混合策略，应用有了很好的弹缩表现，并且这一切都是自动化的，不再需要运维同学人为的介入，这一点大大的降低了重复劳动。在团队协作方面，通过阿里云的 RAM 体系，开发，测试，运维同学都统一在 SAE 控制台各司其职，减少了很多不必要的沟通消耗。总体来看，系统上线 SAE 之后，开发运效率提升了 50%+，机器成本下降了 20%，运维人力成本下降了 60%，扩容速度更是比之前快了十几倍，很好的完成了之前定下的目标。第一期上线后，项目组计划信息平台还会有更多的技术优化点，其中有些 SAE 目前还有所欠缺，后面还需要与SAE团队共同探讨解决：对多语言的支持：目前系统基于.net 框架 C#语言，SAE 的微服务治理和链路追踪没有很好的支持，这方面需要加强建设。 多应用版本的联动：SAE 的灰度发布是对单应用操作，单次发布有时会发布多个应用，不同应用之间还有依赖关系，项目组希望能够提供多应用的联动，根据依赖关系自动完成多应用的发布更新。 最后，相信 SAE 这个产品能够越来越好，希望 SAE 能够持续建设更多的功能，用在更多的场景，服务国内外更多的企业。
发表了文章
2022-09-30
资源画像，看得见的容器资源优化助手
作者：张佐玮（佑祎）背景介绍K8s 为集群资源提供了良好的抽象，用户可以直接根据应用的资源需求填写容器资源规格，这种方式有效提升了集群资源的管理效率。然而，一直以来，容器资源规格填写的难题一直都让应用管理员们无法摆脱，过高的资源规格会导致资源浪费，而过低的规格又会为应用带来潜在的稳定性风险。往期文章《资源画像，让容器资源规格的填写不再纠结》中我们介绍了阿里云容器服务 Kubernetes 版（Alibaba Cloud Container Service for Kubernetes，以下简称 ACK）提供的资源规格智能推荐功能，用户可以通过 ack-slo-manager 组件提供的 CRD 对象查询到容器的资源推荐值。日前，ACK 控制台在此基础上正式发布了资源画像功能，为用户提供了可视化的交互页面，便于管理员快速分析应用资源规格的合理性，并进行资源规格配置的变更。该功能目前已经正式开放公测，ACK 用户可以直接申请白名单试用。容器资源配置K8s 使用了 request 和 limit 来描述容器对 CPU 和内存资源的需求，reqeust 影响 Pod 的节点分配结果，调度器会使用节点的“资源容量”（capacity）进行匹配，确保容量充足，而 limit 决定了容器在节点运行时可以使用的资源上限，当容器尝试超用资源时会被约束（throttled）甚至终止（kill）。一直以来，容器资源规格 request 和 limit 的填写都让 K8s 的用户饱受困扰，一方面，应用管理员需要预留相当数量的资源冗余来应对上下游链路的负载波动，保障线上应用的稳定性；而另一方面的现实是，在大部分在线服务的生产环境中，集群的资源利用率处于相当低的水平，存在大量的资源浪费。应用的资源画像数据可以提供有效帮助，所谓资源画像，指的是应用 CPU、内存等资源的使用特征，如果我们能够将资源使用的历史数据收集起来，并进行汇总分析，在设置容器资源规格时就可以做到有的放矢。ACK 控制台资源画像功能的发布，就旨在解决这一难题，帮助运维人员优化容器资源规格，提升管理效率，保障应用稳定运行的同时，充分提升集群资源使用率。资源画像ACK 资源画像会持续收集容器的资源用量进行汇总分析，为每个容器生成资源规格的推荐值，控制台会针对工作负载原始的资源请求量（request）给出调整建议，包括“升配”、“降配”、以及”保持“三种，若工作负载有多个容器，控制台会优先使用偏差幅度最大的容器作为推荐。应用管理员可以通过该页面直接筛选出需要调整的应用，并在详情页进行修改。策略管理资源画像支持按需开启的的管理策略，可以指定命名空间和应用类型范围。策略同时还支持为应用配置资源消耗冗余，所谓资源消耗冗余，对应的场景是管理员在评估应用业务容量时（例如 QPS），通常不会将物理资源使用到 100%。原因既包括超线程等物理资源的局限性，也包括应用自身需要考虑留有余量以应对高峰时段的负载请求。当资源画像的推荐值与原始资源请求的差距超过安全冗余时，才会提示降配建议。资源用量分析在资源画像控制台主页，点击工作负载名称，可以进入对应的画像详情页面，在画像详情页可以对应用的资源消耗数据做进一步的详细分析。详情页的资源曲线分别展示了各容器的资源限制值（limit）、资源请求值（request）、资源画像功能提供的推荐值（recommend），以及应用各副本资源使用量的平均值和最大值（average/max usage）。通过应用的画像详情页，用户可以对资源使用情况进行直观的分析，评估容器当前的资源规格（request/limit）是否合理。资源配置变更画像详情页面底部还同时提供了资源变配的功能，变配窗口内默认展示了各容器当前的所需资源（request）和限制资源（limit），以及资源画像为容器生成的推荐值，推荐值来自于对容器资源消耗历史数据的聚合分析，确保推荐值可以尽量满足容器资源消耗的需求。这里同时还展示了策略管理中为应用配置的冗余系数，方便应用管理员在修改资源规格配置时参考。填写完成后点击确定按钮，将执行资源规格更新操作并自动跳转到工作负载详情页。资源规格更新后，控制器会对工作负载进行滚动更新并重新创建 Pod。使用建议资源冗余配置资源画像的变配建议是比较推荐值与当前应用资源申请量（request）得到的，当推荐值高于 request 时，说明容器实际的资源用量已经超过了申请量，应提高请求规格；而当推荐值低于 request 时，说明容器实际的资源用量低于请求量，但这并不代表着一定要降低请求规格。原因是应用管理员在填写资源申请时，通常都会在原始的资源需求基础上额外增加一定程度的资源冗余，用于应对流量高峰，或是做例如“同城多活”这类高可用场景的切换。此外，部分应用还对资源较为敏感，无法在宿主机负载较高时平稳运行，这也需要在基础值上调高规格。因此资源画像的变配建议会参考用户在策略管理中配置的冗余系数，只有当推荐值显著低于请求量时才会提示“降配”操作。冗余系数只影响资源变配的提示，不影响推荐值算法的计算过程，原因是资源画像提供的推荐值是对应用当前资源需求情况的总结，管理员在使用时应结合应用自身特性，在推荐值的基础之上进行加工。应用适用类型目前资源画像的推荐值会优先考虑满足容器的资源使用，确保可以覆盖绝大部分历史数据样本，因而更适用于在线类型的应用，因为它们通常以服务的形式部署，对响应时间（RT）会有严格的约束，要求资源必须及时得到满足。与“在线”相对应的是“离线”应用，通常为批处理类型的任务，其更关注数据处理的整体吞吐量，可以接受一定程度的资源竞争，以提高集群资源的整体利用率，因此当前资源画像的推荐值对于离线应用来说会显得有些保守。此外，集群内还会有一些关键的系统组件，通常以“主备”的形式部署多个副本，处于“备份”角色的副本长期处于资源闲置状态。这些“备份”角色的资源用量样本数据会对画像算法产生一定程度的干扰，影响推荐值的准确性。针对这些场景，管理员应基于应用特点对资源画像的推荐值二次加工后再使用，后续我们也将开放更多能力，提供更加精细的资源画像策略管理。数据累积时长资源画像推荐值的算法涉及一套多维度的数据模型，核心关注以下几个方面：算法会持续不断的收集容器的资源用量数据，取 CPU 和内存的聚合统计值作为推荐。 针对样本数据的时间因素进行了优化，在聚合统计时，较新的数据采样点会拥有更高的权重。 算法参考了容器出现 OOM 等运行状态信息，可以进一步提高推荐值的准确性。 通过以上原理可以看出，资源画像结果的准确性会随着数据样本的累积逐渐提升，因此在初次使用时建议至少保持一天以上的数据累积。原因是当前互联网类型的在线应用会受到人们生产生活习惯的影响，流量负载的峰谷会在不同时间段出现，例如出行类应用会有早晚高峰，文娱类应用会在工作日和节假日的呈现不同特征。因此最好的使用方式，是确保工作负载稳定运行一段时间，收集的数据完整覆盖了流量的波峰波谷之后再使用。未来计划ACK 资源画像控制台后续的产品功能已经在规划中，未来我们将提供更为精细化的管理策略以及更为便捷的使用方式，敬请期待！往期文章《Koordinator 0.6：企业级容器调度系统解决方案，引入 CPU 精细编排、资源预留与全新的重调度框架》中我们介绍了云原生混部开源系统 Koordinator 的一系列功能，近期 Koordinator 刚刚发布了最新的 0.7 版本，欢迎大家访问官网"koordinaotr.sh"查阅。接下来我们将逐步把资源画像相关的技术能力也贡献到开源社区，帮助更广大的行业人士改善云原生工作负载运行的效率、稳定性和计算成本。Koordinator 是一个开放的社区，非常欢迎广大云原生爱好者们通过各种方式一起参与共建，无论您在 K8s 领域是初学乍练还是驾轻就熟，我们都非常期待听到您的声音！Github 地址：https://github.com/koordinator-sh/koordinator欢迎扫描下方微信二维码加入 Koordinator 微信群：您也可以使用钉钉扫描下方二维码或搜索群号 33383887 加入 Koordinator 社区钉钉群：点击此处，即可查看阿里云 ACK 资源画像控制台的详细介绍和使用方法！
发表了文章
2022-09-27
基于 RocketMQ 的 MQTT 服务架构在小米的实践
本文作者：房成进 - 小米高级研发工程师小米 MQTT应用场景小米之家门店的支付通知是小米MQTT落地的重要场景之一，流程如上图所示。店员通过终端发送下单请求到后端服务，后端在接收到下单请求后，调用支付服务，等待用户付款。门店终端如何知道本次付款是否成功呢？我们采用MQTT协议来实现支付消息的通知。支付服务将本次订单的支付结果发布到MQTT 服务的一个 Topic中，门店终端与服务保持长连接，订阅 Topic来实时获取支付结果，从而进行下一步操作如打印发票等。得益于 TCP长连接和MQTT协议的轻量化，门店终端系统的支付响应能力从 200 毫秒下降至 10 毫秒内，MQTT服务发布端到订阅端的平均延时为2.6ms。手机智能制造工厂是小米MQTT落地的另一个核心场景。MQTT主要应用于设备状态数据采集以及设备控制指令下发。上图右侧为小米智能制造工厂架构图。上行链路流程为：手机生产线上的众多工业设备会将操作日志、设备参数、环境参数等通过工业控制层发布到MQTT服务，MQTT服务的存储层通过数据集成任务将数据打入大数据系统，进行数据的分析、建模和处理等，最后实现最上层应用工业 BI 和数字孪生的需求。下行链路流程为：工厂的工作人员通过云端服务将控制指令下发到MQTT集群，生产线上的设备与MQTT服务集群保持长连接，以接受来自云端的控制指令并执行相应动作。这两个链路对时效性要求很高。目前， MQTT 服务能保证上行和下行链路延时在 20ms以内，服务可用性为99.95%。小米 MQTT服务架构演进过程早期，小米主要基于RocketMQ 社区在 18 年开源的RocketMQ-IoT-Bridge来构建自己的 MQTT 服务。RocketMQ-IoT-Bridge为单机架构，一是不支持水平扩展，总连接数存在瓶颈，自然无法保证高可用。二是数据无法持久化，只提供内存存储，一旦重启服务，必然导致消息丢失。三是只支持MQTT 协议QoS0，消息存在丢失风险，无法满足小米的业务要求。如图所示，服务整体为单机服务架构，发布端和订阅端连接到同一个进程。小米基于单机的架构进行了一系列的拓展。高可用方面，从单机变为分布式的可扩展架构，连接数从单机的 5 万变为可横向扩展的模式；可靠性方面，在QoS0 的基础上实现了MQTT协议规定的 QoS 1 和 QoS 2；消费模式方面，除了默认的广播消费，支持了MQTT5.0新增的共享消费模式，同时还支持了离线消息。上图右侧是小米基于 RocketMQ 的分布式 MQTT 架构图。最上层为客户端，发布者和订阅者连接到负载均衡器，这里使用四层的负载均衡LVS, 主要目的是将请求均摊到各个MQTT Bridge。MQTT Bridge 即MQTT的服务节点，负责连接、订阅、解析协议和消息转发。RocketMQ 作为存储层，负责持久化消息。类似于存算分离设计，MQTT Bridge 和 RocketMQ 均可独立水平扩展。得益于 RocketMQ 从 2020 年开始在小米大规模落地，我们采用RocketMQ来持久化 MQTT 消息。整个发布订阅的过程演变成消息从 Bridge发送到RocketMQ，再从RocketMQ消费数据然后推送到订阅端。每一个MQTT Bridge 内嵌 RocketMQ SDK ，充当 RocketMQ的客户端，既作为生产者也作为消费者。此外，持久化层支持了小米自研的消息队列Talos，提供了可插拔模式。根据业务数据的下游使用场景，部署时可灵活选择任意一个消息队列作为持久化层。MQTT协议的消息结构和 RocketMQ 的消息结构互相独立，因此如果将MQTT协议的消息持久化到 RocketMQ 中，必然需要做一定的匹配。MQTT Topic有多级，如图中T1/T2/T3所示，为多级树形结构。将 T1 看作一级 Topic，对应 RocketMQ 中的 Topic T1，则所有发往以 T1 开头的 MQTT Topic的消息都会持久化到 RocketMQ 的 T1 Topic中。此时问题演变成如何区分一条消息属于哪个MQTT Topic，我们选择将MQTT Topic设为消息的 tag，MQTT消息中的一些可变 header 直接放在RocketMQ 消息属性 KV 中，消息体可以直接映射到 RocketMQ消息的 Payload 中，这样完成了MQTT消息到RocketMQ消息的映射。除消息数据之外，元数据是 MQTT 服务非常重要的一部分。MQTT Bridge 中保存了两类元数据，分别是客户端元数据和订阅元数据。客户端元数据保存了客户端的连接信息、连接时间、客户端 ID、Netty channel 等信息，我们实现了可视化的控制台，支持查询MQTT服务的连接数，支持通过连接 ID 和客户端 ID 查询客户端的信息。此外，实现了客户端上下线通知，用户可以通过订阅 MQTT  Topic实时获取到某个客户端的上线和下线事件。订阅元数据保存了客户端和MQTT的映射关系，主要通过Trie树来保存订阅关系，可以满足通配符的方式订阅，实现快速匹配。Bridge 通过订阅 Topic找到客户端，将消息定向推送。MQTT协议主要有三个服务质量等级 QoS 0、 QoS 1 和 QoS 2。QoS 0表示消息最多发一次，可能存在丢失消息的情况，性能最好，对于数据可靠性要求不高的业务较为实用。QoS 1 为消息保证能至少到达一次，可能会重复，性能相对差一些。QoS 2 为消息不丢不重，但性能最差。上图为QoS0的实现流程。QoS 指发送端和接收端之间的消息传输质量。发布消息时，MQTT Bridge 作为消息的接收端，IoT 设备作为发布端。订阅消息时，MQTT Bridge作为发布端，IoT设备作为接收端。发布和订阅是两个独立的 QoS 过程，整条链路的 QoS 是这两部分 QoS 的最低值，比如发布是 QoS 1，订阅是 QoS 0，则整条链路的 QoS 等级就是 0。左侧是 QoS 0 发布的过程。发布端IoT将消息推送给MQTT Bridge，Bridge 将消息异步推送到 RocketMQ，无需等待响应。图中两个箭头的请求都可能失败，可能会丢数据，可靠性很低。但由于链路短，因此性能较高。上图为 QoS 1的实现流程。IoT 终端发布消息之前，会先将其持久化到本地内存里，Bridge 收到消息之后，将消息异步推送到 RocketMQ，等待消息持久化成功的结果后，再返回pubAck包给IoT，IoT 将内存里的这条消息删除。发送的请求可能会失败，发送端内存里存储了消息，因此可以通过重试来实现消息至少被发一次，但也导致消息可能会重复发送。订阅端同理。QoS 2 的实现流程如上图。在QoS 1时， Bridge接受到消息后没有将消息持久化在自己的内存里，而是直接将消息推送到RocketMQ中。如果发送端一直没有收到 pubAck 包，则执行重发，重发之后 Bridge无法获知收到的消息是新消息还是重发消息，会造成消息重复。QoS 2基于 messageID 来实现消息去重。MQTT 协议要求 message ID 可以被重复使用，且有一定范围，不会一直递增。所以在利用 messageID 去重的同时，还要保证 messageID 在传输过程中不能有重复，用完后必须释放。依据这两点前提，sender在发送消息之前，会将消息持久化在自己的内存里，再推送给 receiver。receiver 收到消息之后也会放在本地内存里，返回 PubRec 包给 sender，通知其已经收到消息。如果 sender 一直没有收到PubRec包，会不断地重复发送消息。由于receiver 内存里已经保存了消息，因此可以通过 messageID 来实现消息的去重。发送端在接收到 PubRec 包后发布PubRel包，通知 receiver 可以清理内存中的消息，也意味着sender已经知道消息已被 receiver 持久化，此时再由 receiver 将消息推给RocketMQ 并等待持久化响应。receiver 发送 PubComp 包给 sender通知其可将PubRel包删除。上图中步骤 3.3可能失败，因此sender必须在内存中缓存PubRel包。上述流程存在两步确认机制，第一个是保证消息能到达 receiver ；第二个是保证将用过的 messageID 释放掉，能够实现 message ID 的重用。推拉模型是 MQTT Bridge 实现消息发布订阅的核心模型。假设以下场景：有四个订阅端，其中订阅端IoT-1和IoT-2分别订阅了 Topic1/a、Topic1/b，IoT-3和IoT-4分别订阅了Topic2/ a。第一、二台设备连接到第一个 Bridge，第三、四台设备连接到第二个 Bridge。当有新的订阅关系过来时，会检查订阅一级 Topic。上图中Bridge1 维护的两个订阅关系分别是Topic1/a、Topic1/b，它会启动 RocketMQ的消费任务，从RocketMQ中消费 Topic1 中的数据。消费到的每条消息通过tag判断属于哪个 MQTT Topic，再通过匹配树将消息推送给客户端。每一个 RocketMQ Topic对应一个拉取消息的任务，而一级 Topic下面可能有很多MQTT Topic，一旦MQTT Topic增多，推送给客户端的延时就会变高。此外，一级 Topic下可能会存在很多终端，存在大量没有被订阅的无用消息。Topic级别的任务无法为每个客户端都维护独立的 offset 进度。只要 Bridge 接收到客户端订阅的请求就会开启消费线程，Topic没有订阅时再将线程停掉。这样存在的问题是如果长时间没有消息发布，但订阅关系一直存在，会导致线程空转，存在很大的资源浪费。社区在今年 3 月份开源新版MQTT架构，架构中引入了 notify 组件。作用为通知所有MQTT Bridge 一级Topic中是否有新的消息产生。每一个 Bridge 中都内置 notify 组件，负责启动针对 RocketMQ一级 Topic的集群模式消费者，一旦一级 Topic中有消息产生时，notify 组件能够感知到消息的产生，同时将消息作为事件广播给所有Bridge。其他 Bridge 收到消息事件的通知后，会为连接在这台 Bridge 上的每个终端开启独立拉取任务。拉取时不是拉取一级 Topic中的所有数据，而是通过消费 4.9.3 版本新引入的 LMQ，避免拉取一级 Topic中其他没有被当前客户端订阅的消息，以此避免了读放大。另外，每个终端独立的拉取任务可以为每个终端维护独立的 offset 进度，方便实现离线消息。因此，只有新的消息事件到来时，才会为终端开启拉取任务。Topic没有消息或没有任何订阅关系之后，拉取任务将停止。升级后的推拉模型能够支持离线消息，大幅降低了延时，合理的启停机制有效避免线程资源的浪费。共享订阅是MQTT5.0 协议新增的订阅模式，可以理解为类似RocketMQ中的集群模式消费。上图左侧为简单的共享队列实例。IoT 发送几条消息到 Topic1/a 中，Topic1/a有三个订阅端，每一条消息只会被推送给其中一个订阅端，比如IoT-sub-1会收到message1和message4，IoT-sub-1 会收到 message2 和message5，message 会收到message 3和message 6。其实现原理为：每个 MQTT Bridge 会启动一个针对Topic的拉取任务。RocketMQ 本身能够支持集群模式，MQTT Bridge又作为RocketMQ的客户端，因此可以复用RocketMQ的共享订阅模型。订阅端订阅时以某种特殊方式带上消费者组名称，连接到某台 Bridge 后，该Bridge上就会用消费者组和订阅的一级 Topic来启动一个RocketMQ的集群模式消费者。第二个订阅端连接了第二台 Bridge，该Bridge也会启动一个消费者。只要Bridge 上有终端连接且他们处于一组内并订阅了同一个 RocketMQ的一级 Topic，则所有符合要求的 Bridge 会组成集群模式的消费者集群。有新的消息到达 Topic1 之后，只会被其中一个 Bridge 消费，那么也只会被连接到该 Bridge 上的 IoT 订阅端消费到。如果有多个订阅端同时连到一个 Bridge 上，消息应该推给哪个客户端呢？我们在MQTT Bridge 内置多种策略，默认选择轮询策略。一条消息发到 Bridge 后，Bridge可以轮询发送给任意一个IoT订阅端，实现单 Bridge 多订阅端的共享消费。未来工作未来，小米MQTT的工作将从以下四个方面继续深入探索：架构：推拉模型继续升级完善；功能：离线消息、保留消息、遗嘱消息等功能的完善；社区：拥抱开源社区，跟随社区升级RocketMQ端云一体化的架构；业务：小米汽车等IoT的场景推广和应用。加入 Apache RocketMQ 社区十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献，相信在下个版本你就是 Apache RocketMQ 的贡献者，在社区不仅可以结识社区大牛，提升技术水平，也可以提升个人影响力，促进自身成长。社区 5.0 版本正在进行着如火如荼的开发，另外还有接近 30 个 SIG（兴趣小组）等你加入，欢迎立志打造世界级分布式系统的同学加入社区，添加社区开发者微信：rocketmq666 即可进群，参与贡献，打造下一代消息、事件、流融合处理平台。微信扫码添加小火箭进群另外还可以加入钉钉群与 RocketMQ 爱好者一起广泛讨论：钉钉扫码加群关注【Apache RocketMQ】公众号，获取更多技术干货！
发表了文章
2022-09-26
开发者测评：相比 Harbor，我选择 ACR 的三点原因
2022 年 8 月起，阿里云容器镜像服务 ACR 开发者评测活动持续火热开展。截至目前，本次活动已累计吸引 600 余位开发者参与，产生了 30 位发布优质测评内容的开发者并获得相应奖励。云原生生态的繁荣大大丰富了云原生应用制品的多样性，容器镜像作为承载云原生应用的重要载体，是云原生应用生命周期的源头，因此，在企业架构升级、开发者技能个人提升中发挥了越来越重要的价值。阿里云  ACR（Alibaba Cloud Container Registry）是面向容器镜像、Helm Chart 等符合 OCI 标准的云原生制品安全托管及高效分发平台。产品分为个人版和企业版，个人版面向容器开发者限额免费使用，企业版面向对安全及性能要求较高的企业客户。本次活动是为了帮助更多开发者了解容器镜像服务 ACR 的功能、使用方式和产品体验，从而在不同应用场景下，更好地进行容器镜像管理方案的选型。不少开发者在活动中发表了他们在这个过程中的思考，以及选择阿里云容器镜像服务 ACR 的原因。相比 Harbor，我选择阿里云 ACR 的三点原因测评员 ID：197***870在很多人看来，Harbor 几乎已经是事实上的镜像仓库自建标准。但是在其能力不断发展的同时，相关组件的复杂度也给相关开发运维人员的能力带来巨大的挑战。本人曾参与过 Harbor 的社区特性开发，对 Harbor 的生产环境应用也有较多实战经验。但是在跳槽到当前公司（一家中小型互联网企业）后，最终还是选择了阿里云 ACR 仓库。主要基于以下几点：1. 跨境镜像同步能力，这点是重中之重。ACR 基于阿里云的全球化网络能力，十分契合我们公司的全球化部署应用场景。相比自建的跨境 Harbor 仓库，需要额外占用一些专线带宽。2. 节省成本。虽然 Harbor 是开源的，乍一看肯定比云厂商的付费镜像服务划算，但是实际上并不一定。Harbor 的部署涉及到众多组件，在高可用性、可靠性上需要投入一定的人力成本；同时公司原方案中境外用于部署 Harbor 的机器也都是云上虚拟机，加上网络、存储等费用并结合人力成本，Harbor 实际上并无太多成本优势。3. 可维护性。Harbor 的 Redis、Postgres（可以选择云上相关服务，但是成本优势就不明显了）等组件，至少需要有一个人力有相关技术储备来维护，虽然 Harbor 功能强大，也够可靠，但是依然会有一些潜在的 bug 存在，在生产级应用中还是会有一定风险。在替换到 ACR 后将近一年的时间里，服务足够稳定，还没有发生功能性故障，几乎不需要维护成本。给 ACR 在金融场景下的能力点个大大的赞测评员 ID：n3c***m6o很多金融企业在面对合规、安全等保要求下，需要对业务进行多账号的多 ACK（阿里云容器服务 Kubernetes 版） 集群拆分。与此同时，面对业务扩展，服务跨账号、跨地域部署的问题随之而来。阿里云 ACR 提供了容器镜像、Helm Chart 等 OCI 制品安全托管和高效的分发能力，其产品的分发管理功能，很好地支持了不同业务根据不通命名空间镜像分发，进而完成应用服务的版本更新，大大提升运维工作效率。首先，通过实例同步，解决跨账号镜像同步，解决镜像镜像分发问题：其次，通过同步记录可以发现，镜像同步速度还是比较快的，跨地域的镜像同步过程也是依赖阿里云自身带宽：最后，对于同步过程中异常问题，通过阿里云 ACR 服务实例管理-事件通知功能，通过配置相关告警策略，实现异常告警通知：通过以上跨账号、跨地域镜像同步及告警配置，有效实现了整个镜像同步过程跟踪与掌控，对 ACR 产品功能的完整及稳定给一个大大赞！倒计时 7 天：加入 ACR 开发者测评团，赢取千元机械键盘本次活动将持续至 2022 年 9 月 30 日，开发者们参与测评的热情持持高涨（推荐阅读：《开发者测评：阿里云 ACR 与其他的镜像仓库到底有什么不同？》 ）现在，距离活动正式结束还有 7 天的时间，把握机会，免费开通并体验阿里云容器镜像服务 ACR，发布原创测评内容，机械键盘、定制晴雨伞等定制好礼还在等你 ！赶快喊上小伙伴们一起参加吧！扫描图片二维码或点击下方“此处”，即可直达 ACR 开发者测评活动现场，把握！
发表了文章
2022-09-26
龙湖千丁基于 ACK@Edge 的云原生智慧停车系统架构实践
作者：蔡佩、刘涛在物联网、大数据、云服务等的快速发展及规模化应用下，今天，大量在日常生活中产生的数据可以被更好地连接和利用，为智能设备的运转提供支持，在推进社会高效协作，建设有温度、有速度的智慧生活中发挥价值。龙湖千丁是国内最早一批参与智慧城市、智慧社区建设的高科技企业，已被纳入“专精特新”、国家高新技术认证企业名录等。龙湖千丁专注社区、商业、公寓、园区等空间化智能解决方案，以 AI+大数据驱动业降本增效，为高效、节能与安全加码。智慧停车是龙湖千丁生活服务的主要场景之一。依托龙湖千丁停车云系统，千丁智能已为全国范围内自有及托管的 1000+车场的智慧停车业务提供统一的车管解决方案。随着服务规模的不断扩大及用户需求的快速变化，系统挑战也随之而来。智慧停车场景下的应用管理挑战具体来说，龙湖千丁停车云是一套以停车和管理服务为核心，全面整合停车管理问题的智慧化停车系统，结合车牌识别一体机、道闸、停车对讲立柱等 IoT 设备的协同，实现社区车库智慧通行。业主可通过线上登记车牌、月卡车辆信息、预约登记客车牌信息等操作，享受出行自动抬杆放行等便捷高效的停车管理服务。图 1：龙湖千丁停车云系统架构不难看出，智慧停车场业务对于服务响应速度的要求非常高，并且有大量近场传感器、控制设备等需要协同管控。如果完全依赖传统的中心云模式，势必会为边缘应用的管理带来一系列挑战：网络通信问题：各个车场地理位置位置分散，彼此网络隔离，车场内的计算资源无法直接被公网访问，无论是业务发布，还是问题排查，往往需要相关人员现场处理。业务的开发、测试、升级和运维面临巨大挑战。 异构环境差异：绝大部分车场的节点环境为 Windows PC 服务器，且车场之间的业务部署环境差异较大，如何屏蔽底层环境差异，确保业务平稳运行也是需要重点解决的问题。 应用发布效率：不同接入平台的运营主体不同，且用户需求更迭频繁，需要根据业务特点实现分批发布、灰度发布，在保证业务的稳定运行的同时提高发布效率。 基于 ACK@Edge 的边缘云原生智慧停车系统实践为了解决以上问题，龙湖千丁停车云平台通过阿里云边缘容器服务 ACK@Edge 提供的标准 Kubernetes 服务以及云边一体化协同解决方案。阿里云边缘容器（ACK@Edge），依托 ACK 托管服务构建，打造通用的边缘容器云原生基础设施。基于主流云原生非侵入式设计原则，实现云边端一体化。阿里云边缘容器采用原生与插件化组合方式，非常利于业务快速集成及扩展，且不会增加额外的边缘资源成本和维护成本。在方案选型对比过程中，龙湖千丁对于 ACK @Edge 的如下特点也很感兴趣：支持云端托管，帮助用户快速构建边缘计算的云原生基础设施。支持丰富的应用场景，包括边缘智能、智慧楼宇、智慧工厂、音视频直播、在线教育、CDN 等。支持多种边缘计算资源的快速接入，包括 IoT 网关设备、端设备、CDN 资源、自建 IDC 资源等。支持丰富的异构边缘节点资源，包括自建 IDC 资源、ENS、IoT 设备、X86、ARM 架构等；并支持异构资源的混合调度。面向边缘计算弱网络连接场景，提供节点自治和网络自治能力，保证边缘节点和边缘业务的高可靠运行。提供边缘单元管理、单元化部署、单元流量管理能力。 方案的整体架构和实现功能如下所示：图 2: 基于 ACK@Edg 的云边一体化协同解决方案云端管控：只需一条命令，即可快速将节点接入到 ACK@Edge 提供的标准 Kubernetes 集群中，通过云端实现地域分布的计算资源统一管理，通过云端进行统一的应用分发。 单元化发布：根据业务特点，划分不同的节点池，不同车场的算力接入不同的节点池，从而形成不同的发布单元。通过选择不同的发布单元，实现分批发布、灰度发布。 云端运维，远程调试：借助 ACK@Edge 提供的 Tunnel 通道， 可以让开发运维人员快速查看容器日志和进入容器调试。 边缘自治：借助 ACK@Edge 的边缘自治能力，可以在云边网络断开、主机重启这种极端情况下，保证本地边缘服务器上的业务能正常运行。效果&价值结合龙湖千丁自研的新版停车云系统以及 ACK@Edge 提供的标准 Kubernetes 服务以及云边一体化协同解决方案，整体来着，边缘部署时间成本由 1 天缩短到 3 小时，将之前的手动升级方式迭代为自动 OTA 升级，升级时间由 3 小时缩短到 5 分钟，计算下来每年节约 740 人天。具体表现为：1. 极大地降低了停车云业务开发运维过程中的人员和时间成本。（业务的发布与运维不再需要提前公告，停服，去现场发布；日常也不需要派人现场巡检）2. 极大地提高了业务的发布效率。（发布时间从以往的周为单位，降低到分钟为单位）3. 有效降低了业务整体的报障率。 点击此处，了解 ACK@Edge 更多详情！
发表了文章
2022-09-26
Fluid 助力阿里云 Serverless 容器极致提速
作者：东伝背景数据对于当今互联网业务的重要性不言而喻，它几乎渗透到了当今这个世界的每一个角落。但单有数据是不够的，真正让数据产生价值的，是针对各业务场景运行的对大量数据的密集分析与计算，如机器学习、大数据分析、OLAP 聚合分析等等。近些年，随着数据规模的增大，这些对于资源有着更高要求的数据密集应用自然地导向了以弹性资源著称的云服务。在这种数据密集应用上云的趋势下，Serverless 似乎并不是这个趋势的明显受益者。尽管几乎所有人都对这种计算资源无限扩容、弹性敏捷交付、低运维成本的架构不吝赞美之词，但由于它将计算存储分离的架构推向了一个更纯粹的极端，具有强数据依赖的数据密集应用想要高效运行于 Serverless 环境变得极其困难。举例来说，如果我们想将 AI 推理服务应用部署在 Serverless 架构下，每个服务应用启动前必须将存放在外部存储系统的 AI 模型首先拉取到本地内存中。考虑到近年来 AI 大模型已经成为业界主流，让我们假设这个 AI 模型的大小为 30GB，并且存储于 OSS 对象存储服务中，如果需要同时启动 100 个这样的 AI 推理服务应用，那么总共的数据读取量就是 3000GB。OSS 存储默认的数据访问限速是 10Gbps，这就意味着 100 个应用都需要等待 2400 秒（3000GB * 8 / 10Gbps）才可以真正开始对外提供服务。如果每个服务我们创建一个 ecs.gn7i-c32g1.16xlarge 的实例（按每小时单价折算每秒 0.008 元），这意味着光在等待数据上就已经花掉了 1920 元（0.008 元/秒 * 2400 秒 * 100）。总结来说，我们大量的费用没有花在产生价值的计算上，这显然不是我们想要的。（*实际价格以阿里云官网显示为准）那么，有没有什么方法可以优化上述过程？这就引入了本文的主角：Fluid。Fluid 是一个 Kubernetes 原生的分布式数据集编排和加速引擎。Fluid 诞生的初衷即是为应用的数据访问延时问题提供云原生的解决方案。对于困扰着 Serverless 数据密集应用的上述相关问题，Fluid 在保证用户简单易用的使用体验前提下，给出了一套 Serverless 环境新的数据访问架构方案，帮助用户提升数据访问效率。本文将 step by step 地介绍 Fluid 的运行示例，帮助大家了解如何在阿里云 ASK（Alibaba Serverless Kubernetes）环境中使用 Fluid，展示如何借助 Fluid 实现 zero to zero 的（从零资源使用开始到全部资源释放结束）规模化数据密集型任务执行模式，并取得降本提速的效果。Fluid on ASK 运行示例Fluid 数据编排加速 Serverless Kubernetes 功能尚处于公测阶段，可点击阅读原文申请体验席位。Fluid 部署在运行以下示例前，首先需要搭建一个 ASK 集群，并配置好连接该集群的 Kubeconfig。相关步骤可参考文末文档《如何创建 ASK 集群》。在使用 Fluid 的各项功能前，需要将 Fluid 的各控制面组件部署到 ASK 集群中。这个部署过程可以通过阿里云容器服务-Kubernetes 控制台轻松完成。如下图所示：选择 ASK 集群面板右侧的“应用-Helm”子面板点击"创建"按钮在 Chart 市场中搜索 ack-fluid 即可找到 Fluid 对应的 Helm Chart，填写“应用名”（例：ack-fluid)。点击“下一步”后，选择使用默认的 fluid-system 作为部署的命名空间接着无需对 Chart Values 进行任何修改，直接点击“确定”，即可将 Fluid 部署到 ASK 集群中。在配置完 ASK 集群对应的 Kubeconfig 信息后，输入以下命令：$ kubectl get pod -n fluid-system可以观察到 Fluid 的几个组件已经正常运行起来：NAME READY STATUS RESTARTS AGE
dataset-controller-d99998f79-dgkmh 1/1 Running 0 2m48s
fluid-webhook-55c6d9d497-dmrzb 1/1 Running 0 2m49s其中：Dataset Controller：负责维护各个 Fluid 所引入的 Dataset CRs 的完整生命周期。Fluid Webhook: 负责对用户需要访问数据的应用 Pod 进行自动化变换（Mutation），无感知地帮助用户实现 Serverless 场景的数据访问功能。 除了上述描述的两个组件外，Fluid 的控制面仍然包含了一些与各类缓存系统（例如：JindoFS、JuiceFS、Alluxio 等）紧密关联的控制器组件，这些组件在初始部署状态下不会创建，仅当用户指定需要使用某种缓存系统时，与其相关联的缓存系统控制器组件 Pod 才会按需扩容，从而在按量付费的 ASK 环境中尽可能地帮助用户节省成本。数据缓存部署Fluid 世界中的一切都以 Dataset 这一自定义资源为中心：无论是对外部存储中已有数据的抽象管理还是应用 Pod 的数据访问，用户都需要和 Dataset 资源进行交互。每当用户创建一个 Dataset CR 并指定了它的缓存系统后端，Fluid 就会自动地将数据缓存部署到 Kubernetes 集群中。在下面的实践过程中，我们以阿里云 OSS 对象存储作为外部存储系统为例，模拟一个完整的 “缓存部署-数据访问-资源回收”的标准数据使用过程。数据文件准备 首先，准备一个待访问的文件。例如，这里我们使用 dd 命令快速创建一个大小约为 30G 的文件：$ cd $(mktemp -d)
$ dd if=/dev/zero of=./largefile-30G bs=10M count=3072
3072+0 records in
3072+0 records out
32212254720 bytes (32 GB) copied, 108.189 s, 298 MB/s
$ ls -lh ./largefile-30G
-rw-r--r-- 1 root root 30G Sep 7 21:11 ./largefile-30G接着，把上述创建的待访问文件上传到 OSS Bucket 中，这里以一个位于 Beijing Region 的名为 fluid-demo 的 OSS Bucket 为例。$ ossutil cp -i <access_key_id> -k <access_key_secret> -e oss-cn-beijing-internal.aliyuncs.com ./largefile-30G oss://fluid-demo/创建 Fluid Dataset 和 Runtime 资源数据准备和上传后，即可在 Fluid 中声明上述待访问的数据。具体而言，我们需要提交一个 Dataset CR 和一个 Runtime CR。Dataset CR 中描述数据在外部存储系统中的 URL 位置，Runtime CR 描述缓存系统及系统具体配置。首先，把访问 OSS Bucket 所需的身份凭证信息存储于 Secret 中：$ kubectl create secret generic oss-access-key \
--from-literal=fs.oss.accessKeyId=<access_key_id> \
--from-literal=fs.oss.accessKeySecret=<access_key_secret>接着，定义 Dataset CR 和 Runtime CR。这里我们选择 JindoFS 作为缓存系统后端，Fluid Runtime 资源为 JindoRuntime:apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
name: demo-dataset
spec:
mounts:
- mountPoint: oss://fluid-demo # OSS Bucket URL
name: demo
path: /
options:
fs.oss.endpoint: oss-cn-beijing-internal.aliyuncs.com # OSS Bucket内网访问端点
encryptOptions:
- name: fs.oss.accessKeyId
valueFrom:
secretKeyRef:
name: oss-access-key
key: fs.oss.accessKeyId
- name: fs.oss.accessKeySecret
valueFrom:
secretKeyRef:
name: oss-access-key
key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
name: demo-dataset
spec:
# 缓存Worker节点数量
replicas: 5
podMetadata:
annotations:
# 选择JindoFS Pod使用的实例规格
k8s.aliyun.com/eci-use-specs: ecs.d1ne.6xlarge
# 启用实例镜像缓存，加速Pod启动过程
k8s.aliyun.com/eci-image-cache: "true"
tieredstore:
levels:
# 以40GiB的内存作为每个缓存Worker节点的缓存介质
- mediumtype: MEM
volumeType: emptyDir
path: /dev/shm
quota: 40Gi
high: "0.99"
low: "0.99"创建上述 Dataset CR 和 JindoRuntime CR 到 ASK 集群：$ kubectl create -f dataset.yaml查看 Dataset 部署状态Dataset CR 和 JindoRuntime CR 创建后，约 1 到 2 分钟后，Dataset 将部署完成，届时可以查看到与缓存系统以及后端存储系统中数据的相关信息。$ kubectl get dataset demo-dataset
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
demo-dataset 30.00GiB 0.00B 200.00GiB 0.0% Bound 2m9s例如，上方示例展示了 Fluid Dataset 的相关信息OSS 中数据集总大小(UFS TOTAL SIZE) ：30.00GiB当前缓存量（CACHED）：0.00B缓存系统容量（CACHE CAPACITY）：200.00GiB数据集缓存百分比（CACHED PERCENTAGE）： 0.0%Dataset 状态（PHASE）：Bound，表示已成功部署。 数据缓存预热Fluid 实现的 Kubernetes 集群内数据访问加速不是什么 Magic Trick：其本质是通过数据分流（Data Offloading）来降低中心存储的访问压力：Fluid 会把需要访问的数据缓存到与应用 Pod 更近的分布式缓存系统（例如：JindoFS、JuiceFS、Alluxio 等）中，于是，与缓存系统位于同一 VPC 网络的应用 Pod，就能够以远比直接访问中心存储带宽更高的 VPC 内网带宽进行数据访问。进一步地，由于对接的是分布式缓存系统，所以当单个缓存系统 Worker 节点提供带宽不足时，可将分布式缓存系统扩容，从而实现数据访问带宽的弹性伸缩，匹配 Serverless 场景下的计算资源弹性。因此，为了通过数据分流实现高带宽数据访问，在应用 Pod 进行数据访问前执行数据缓存预热是一个“磨刀不误砍柴工”的必要操作。创建 DataLoad CR 在 Fluid 中执行数据缓存预热只需创建如下的 DataLoad CR：apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
name: demo-dataset-warmup
spec:
# 指定需要预热的Dataset
dataset:
name: demo-dataset
namespace: default
loadMetadata: true
target:
- path: / # 指定预热的数据子路径，“/”表示预热整个数据集
replicas: 5 # 预热后数据在缓存系统中的副本数量$ kubectl create -f dataload.yaml查看预热后 Dataset 状态查看 DataLoad CR 状态，直至其 PHASE 变为 Complete 状态：$ kubectl get dataload demo-dataset-warmup
NAME DATASET PHASE AGE DURATION
demo-dataset-warmup demo-dataset Complete 2m38s 2m20s通过 Duration 可以查看数据预热耗费的时间，上述示例中预热耗时为 2m20s。在数据缓存预热完成后，Dataset 上相关的缓存状态也会随即更新：$ kubectl get dataset demo-dataset
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
demo-dataset 30.00GiB 150.00GiB 200.00GiB 100.0% Bound 8m27s可以看到，数据预热完成后，整个数据集都已经被缓存在了分布式缓存系统中，缓存比例 100.0%，由于预热时指定了预热的缓存副本数量为 5，预热后缓存占用总量为数据集大小的 5 倍。注：增加缓存副本数量有助于减轻数据访问时对分布式缓存 Worker 节点的单点访问性能瓶颈。数据访问紧接着，尝试创建应用 Pod 来访问 OSS 中的数据。我们将会一次性拉起 100 个应用 Pod，让这些 Pod 同时访问 OSS 中的数据文件。这样的数据读取模式在 AI 推理服务弹性扩容、自动驾驶仿真等具体场景中都十分常见。创建数据访问应用 例如：下面是一个 Argo Workflow 应用示例：apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: parallelism-fluid-
spec:
entrypoint: parallelism-fluid
# Argo Workflow Task最大并发数，即同时启动100个Pod
parallelism: 100
podSpecPatch: '{"terminationGracePeriodSeconds": 0}'
podMetadata:
labels:
# 添加如下label打开Fluid对Serverless场景的数据访问支持
alibabacloud.com/fluid-sidecar-target: eci
annotations:
# 启用实例镜像缓存，加速Pod启动过程
k8s.aliyun.com/eci-image-cache: "true"
# 选择Argo Workflow Pod使用的实例规格
k8s.aliyun.com/eci-use-specs: ecs.g6e.4xlarge
templates:
- name: parallelism-fluid
steps:
- - name: domd5sum
template: md5sum
withSequence:
start: "1"
end: "100"
- name: md5sum
container:
imagePullPolicy: IfNotPresent
image: alpine:latest
# 每个pod计算待读取文件的md5sum
command: ["/bin/sh", "-c", "md5sum /data/largefile-30G"]
volumeMounts:
- name: data-vol
mountPath: /data
volumes:
- name: data-vol
persistentVolumeClaim:
claimName: demo-dataset # claimName须与Fluid Dataset名字一致$ argo submit workflow.yaml查看数据访问应用状态上述示例的 Argo Workflow 将会一次性拉起 100 个 Pod 进行并行数据访问。待上述 100 个 Pod 全部完成后，可以看到如下结果：$ argo list
NAME STATUS AGE DURATION PRIORITY
parallelism-fluid-x677t Succeeded 8m 5m 0查看任务的具体信息：$ argo get parallelism-fluid-x677t
Name: parallelism-fluid-x677t
Namespace: default
ServiceAccount: unset (will run with the default ServiceAccount)
Status: Succeeded
Conditions:
PodRunning False
Completed True
Created: Wed Sep 07 21:25:30 +0800 (7 minutes ago)
Started: Wed Sep 07 21:25:30 +0800 (7 minutes ago)
Finished: Wed Sep 07 21:31:28 +0800 (1 minute ago)
Duration: 5 minutes 58 seconds
Progress: 100/100
ResourcesDuration: 8h10m22s*(1 alibabacloud.com/vfuse),24h15m6s*(1 cpu),24h15m6s*(100Mi memory)
STEP TEMPLATE PODNAME DURATION MESSAGE
✔ parallelism-fluid-x677t parallelism-fluid
└─┬─✔ domd5sum(0:1) md5sum parallelism-fluid-x677t-2855796525 5m
├─✔ domd5sum(1:2) md5sum parallelism-fluid-x677t-1226856655 5m
├─✔ domd5sum(2:3) md5sum parallelism-fluid-x677t-2858910973 5m
├─✔ domd5sum(3:4) md5sum parallelism-fluid-x677t-2609269875 4m
├─✔ domd5sum(4:5) md5sum parallelism-fluid-x677t-616770109 5m
├─✔ domd5sum(5:6) md5sum parallelism-fluid-x677t-3071900311 5m
├─✔ domd5sum(6:7) md5sum parallelism-fluid-x677t-3841084237 5m
├─✔ domd5sum(7:8) md5sum parallelism-fluid-x677t-120540963 5m
├─✔ domd5sum(8:9) md5sum parallelism-fluid-x677t-1353329645 5m
├─✔ domd5sum(9:10) md5sum parallelism-fluid-x677t-2391364586 5m
├─✔ domd5sum(10:11) md5sum parallelism-fluid-x677t-4083824607 5m
├─✔ domd5sum(11:12) md5sum parallelism-fluid-x677t-258640575 5m
├─✔ domd5sum(12:13) md5sum parallelism-fluid-x677t-3913466863 5m
├─✔ domd5sum(13:14) md5sum parallelism-fluid-x677t-1949266799 5m
├─✔ domd5sum(14:15) md5sum parallelism-fluid-x677t-214569823 5m
├─✔ domd5sum(15:16) md5sum parallelism-fluid-x677t-684353087 5m可以看到，整个任务的运行时长为 5m58s。资源回收数据缓存资源回收 用户可以在不再需要数据缓存时，将缓存从 ASK 集群中回收以节省集群资源并降低成本。Fluid 中对于缓存系统的回收仅需要将关联的 Fluid Dataset 删除，例如：$ kubectl delete dataset demo-dataset执行上述删除命令后等待一段时间（Fluid 将会进行一些清理工作），缓存系统的相关 Pod 都会被回收。Fluid 控制面组件回收 在缓存系统相关 Pod 回收后，用户同样可以试情况回收控制面组件占用的资源。执行下面的脚本，缩容控制面组件。$ kubectl get deployments.apps -n fluid-system | awk 'NR>1 {print $1}' | xargs kubectl scale deployments -n fluid-system --replicas=0当再次需要使用 Fluid 时，执行下面的扩容命令，创建新的控制面组件 Pod 即可：$ kubectl scale -n fluid-system deployment dataset-controller --replicas=1
$ kubectl scale -n fluid-system deployment fluid-webhook --replicas=1方案效果多次运行上述示例，并调整缓存系统 Worker 的数量（5 个或 10 个）或选择直接访问 OSS 对象存储，我们得到了如下效果数据：效果 1：可弹性伸缩的数据访问带宽图 1 缓存/存储系统提供的有效数据访问带宽对比根据数据访问应用的整体耗时、访问的数据文件大小以及数据访问的 Pod 数量，我们可以计算出图 1 中的“有效数据访问带宽*”性能表现。从图 1 来看，相比于 OSS 存储系统提供的默认带宽（10Gbps），Fluid 的数据分流机制可以为 Serverless 应用提供更大的有效访问带宽，并且该带宽可通过增加缓存 Worker 节点数量弹性提升。*有效数据访问带宽 = Serverless 数据访问 Pod 数量 x 每 Pod 访问的数据量 / 数据访问应用整体耗时效果 2：因数据访问加速而降低的费用成本图 2 直接访问 OSS vs. Fluid 成本对比上述示例中我们使用如下的 ECI 实例规格：Argo Workflow 任务 Pod：ecs.g6e.4xlarge (每秒单价 0.0012 元)缓存系统 Pod：ecs.d1ne.6xlarge (每秒单价 0.0056 元) 由此可计算得到“图 2 直接访问 OSS vs. Fluid 成本对比”。观察图 2 不难发现，通过 Fluid 访问 OSS 中的数据能够将成本削减为原来的约六分之一到八分之一。另外，在同样使用 Fluid 访问数据的前提下，使用更多的缓存 Worker 节点可以节省更多成本。这背后的主要原因是 Fluid 提供了更大的数据访问带宽，从而使得数据访问性能提升，缩短了应用花在数据读取上的时间（见图 3），从而使得购买的 Serverless 弹性算力真正做到物尽其用。图 3 Argo Workflow 任务耗时对比总结本文展示了一个在 ASK 环境中运行 Fluid 的完整数据访问示例，希望能够帮助大家了解 Fluid 的使用体验、运行效果以及 Serverless 和数据密集型应用结合的更多可行性。具体而言，我们看到：用户使用 Fluid 访问数据是简单易用的：用户只需要把原来访问 OSS 的 PVC 修改为 Fluid Dataset 对应的 PVC。Fluid 能够提供可弹性伸缩的数据访问带宽，帮助规模化的数据访问应用提升数据读取效率。由于数据读取效率的提升，Fluid 能够帮助规模化的数据访问应用大幅降低费用成本。 参考链接[1] 如何创建 ASK 集群：https://help.aliyun.com/document_detail/86377.html[2] ACK 云原生 AI 套件详情：https://help.aliyun.com/document_detail/201994.html[3] Fluid 项目 github 地址：https://github.com/fluid-cloudnative/fluid点击此处，申请 ACK 云原生 AI 套件免费体验席位！
发表了文章
2022-09-20
【重磅】Serverless Devs 进入 CNCF 沙箱，成首个入选的 Serverless 工具项目！
近日，经过云原生计算基金会（CNCF）TOC 例会上投票决议，Serverless Devs 正式成为 CNCF 官方沙箱项目。开源开放的 Serverless 开发者平台 —— Serverless Devs 由阿里云开源，致力于为开发者提供强大的工具链体系。通过该平台，开发者不仅可以一键体验多云 Serverless 产品，极速部署 Serverless 项目，还可以在 Serverless 应用全生命周期进行项目的管理，并且非常简单快速地将 Serverless Devs 与其他工具/平台进行结合，进一步提升研发、运维效能。Serverless Devs 是 CNCF 首个  Serverless Tool 项目。未来，Serverless Devs 社区将与更多开发者和用户共建，持续致力于打造无厂商锁定的 Serverless 应用全生命周期管理工具，让 Serverless 更简单，更好用。CNCF TOC 在会议上对 Serverless Devs 作出如下评价：Davanum Srinivas (CNCF TOC ) 表示如果你是一位普通的开发者，你有很多 Serverless 应用需要运行，你一定希望自主选择去哪个平台运行，这个平台最好有基于不同语言的模版，你可以基于此快速开始。Serverless Devs 就是这样一个平台，它已经准备好了很多模版，帮助开发者在一个Serverless 运行时中进行部署。它让开发者可以轻松开启 Serverless 之旅。Emily Fox (CNCF TOC ) 认为 Serverless Devs 非常关注开发者的体验体验，同时也非常关注 Serverless 应用在不同云平台的部署。Serverless Devs 项目地址：https://github.com/serverless-devs/serverless-devsServerless Devs 的六个优势无厂商锁定：得益于功能的可插拔特性，可以非常简单的支持不同云厂商的项目部署，或者一键部署到不同云平台。目前 Serverless Devs 已经支持了阿里云函数计算 、AWS Lambda 、百度智能云函数计算 、华为云函数工作流 、腾讯云云函数等多云的 FaaS 产品； 开源形式建设：项目通过开源代码，开放生态进行建设的，开发者可以随时查看和参与 Serverless Devs 开发者工具的贡献，也可以随时随地进行相关组件和应用的贡献。当然，除了这种开源开放的形态，我们也鼓励一些企业级团队，通过 Serverless Registry Model 建设自己的私有 Registry 以定制化某些不便公开的自定义组件； 功能灵活可插拔：Serverless Devs 开发者工具本身，不具备任何业务能力，所有的业务能力均是通过组件化的形式，进行可插拔式使用，并且每个组件可以根据需要，自定义相对应的命令和功能；开发者可以在一个应用中，选择不同的组件完成对应的业务能力，以满足对不同模块的诉求； 简单快速上手：通过开放 Serverless Registry 的模型/规范，该项目可以通过应用的模式，为开发者提供多种形式，多种领域以及多种场景的上手案例，帮助开发者快速了解、学习、深入、上手 Serverless 架构； 应用全生命周期管理：通过组件化的支持，Serverless Devs 可以在应用的全生命周期发挥重要的作用，以 阿里云函数计算的 FC 组件 为例，开发者可以在项目创建、项目的开发、调试、可观测性等多个层面进行项目的建设和管理； 良好的集成与被集成性：项目具有非常好的集成性与被集成性，可以通过组件化的支持，非常简单的与传统的生态进行有机结合。同时，Serverless Devs 开发者工具也可以非常简单的被集成到海量的自动化流程中； 设计哲学Serverless Devs 是一个开源开放的 Serverless 领域的工具链项目，他不仅仅表示单纯的某个命令行工具，在一定程度上指的是一个完整的工具链体系。在 Serverless Devs 中，拥有两个角色：开源贡献者：开源贡献者将按照 Serverless Package Model 进行组件/应用的开发 ，并将内容发布到Serverless Regsitry 中，既可以被更多人所使用； Serverless 开发者：通过开发者工具（包括命令行工具以及桌面端等工具），进行应用的初始化，以及组件的使用；通过开发者工具，将业务按照预期部署到线上；  除此之外，在 Serverless Registry 中，有两种形态的 Package（组件和应用）：Component 和 Application：Component：指的是组件；是由 Package developer 开发并发布的符合 Serverless Package Model 规范的一段代码，通常这段代码会在应用中被引用，并在 Serverless Devs 开发者工具 中被加载，并按照预定的规则进行执行某些动作。例如，将用户的代码部署到 Serverless 平台；将 Serverless 应用进行构建和打包；对 Serverless 应用进行调试等；  Application：指的是应用；可以由 Package developer 公开发布到 Registry，以供更多人学习和使用，例如某位贡献者贡献了一个猫狗识别的案例到 Registry；也可以由 Serverless developer 开发，例如某人开发了一个 人脸识别的应用；通常情况下一个应用可以引用一个或者多个组件，并通过 Serverless Devs 开发者工具部署到 Serverless 平台，例如我开发了一个猫狗识别的应用，在这个应用中引用了 Lambda 组件帮助我将部分业务逻辑部署到 FaaS 平台，同时我也引用了 Website 组件帮助我把前端业务代码部署到对象存储中； Serverless Devs 的模型设计原则，是希望可以通过更加简单、科学、规范的 Serverless 工具链体系，让开发者更专注于业务逻辑，提升 Serverless 应用开发、部署、运维效率，通过该模型。开发者可以通过一种更灵活、更通用的方法使用不同云厂商以及开源的 Serverless 产品，进而更高效、更简洁、更便利的实现 Serverless 应用管理。成长历史如果说 Serverless 提升了传统应用的开发效能，那么 Serverless Devs 开发者工具就是提升了 Serverless 应用开发的效能。随着时间的发展，Serverless Devs 更是从简单的单纯的效能提升，变成了更加规范、更加科学的效能提升。我们真切希望可以通过 Serverless Devs 的工具链模式和思路，为应用的开发，传统项目上 Serverless 架构提供巨大的便利和更科学的管理：2020 年 10 月 23 日，Serverless 开发者平台 Serverless Devs 正式开源；2020 年 11 月，Serverless Devs 被 CNCF Landsacpe 收录, 成为国内首个进驻的 Serverless 工具；2020 年 11 月，Serverless Developer Meetup 首召开，成 Serverless 开发者技术新渠道；2020 年 11 月，入围 InfoQ 评选 2020 年度十大开源新锐项目；2021 年 4 月，Serverless Developer Meetup 在上海召开，并正式发布 Serverless Devs 2.0；2021 年 7 月，Serverless Developer Meetup 在杭州召开，阿里云函数计算团队在会上正式发布端云联调、桌面客户端等功能；2021 年 10 月，在 2021 OpenInfra Days China 会议上，Serverless Devs 带来了《Serverless Devs：Serverless 全生命周期的工具链建设》的主题演讲；2021 年 12 月，Serverless Developer Meetup 在深圳召开，并尝试性的对外展示了 Serverless Devs Model；2022 年 5 月，Serverless Devs Model 作为 Serverless 工具链模型最佳实践，亮相信通院云原生产业大会；2022 年 9 月，Serverless Developer Meetup 在杭州召开；Serverless Devs 在云原生计算基金会（CNCF）的 TOC 例会上投票决议通过，正式成为 CNCF 官方沙箱项目；未来展望Serverless Devs 将会在未来支持：支持更多的云厂商，云产品；Hosted：Azure，Google Cloud PlatformInstallable：Knative，OpenWhisk，Kubeless，Laf 功能支持：Serverless Devs K8s Controller编辑器插件（VScode Plugin）Logs 能力完善（Serverless Devs Logs）云执行环境（Serverless Devs Cloud）全局行为能力（Global Actions） 其他规划：更多形式的 Serverless 服务支持，如 Serverless Application Hosting 模型；支持更多 BaaS 产品；探索 IaC 方向；与 Terraform 结合；欢迎参与贡献Serverless Devs Repo：https://github.com/Serverless-Devs/Serverless-DevsServerless Devs 官网：https://www.serverless-devs.com/Serverless Devs 文档：https://docs.serverless-devs.com/Serverless Regsitry：https://registry.serverless-devs.com/Serverless Devs Model：https://docs.serverless-devs.com/sdm/readme
...
39
跳转至：
2022年12月
12.23
11:16:51
发布了视频
2022-12-23 11:16:51
《十万个可观测冷知识》—前端监控怎么用 第一期
《十万个可观测冷知识》—前端监控怎么用 第一期
12.22
17:27:32
发表了文章
2022-12-22 17:27:32
统一观测｜如何使用 Prometheus 监控 Windows
统一观测｜如何使用 Prometheus 监控 Windows
12.22
17:27:27
发表了文章
2022-12-22 17:27:27
统一观测｜如何使用 Prometheus 监控 Windows
统一观测｜如何使用 Prometheus 监控 Windows
12.20
10:23:01
发表了文章
2022-12-20 10:23:01
【观看直播有礼】第三届云原生实战峰会正式官宣启动
【观看直播有礼】第三届云原生实战峰会正式官宣启动
12.19
17:54:27
发表了文章
2022-12-19 17:54:27
优化 20% 资源成本，新东方的 Serverless 实践之路
优化 20% 资源成本，新东方的 Serverless 实践之路
12.19
17:00:46
发表了文章
2022-12-19 17:00:46
聊聊与前端工程师天然互补的 Serverless
聊聊与前端工程师天然互补的 Serverless
12.19
14:11:23
发表了文章
2022-12-19 14:11:23
如何用 7 分钟玩转函数计算？
如何用 7 分钟玩转函数计算？
12.19
13:32:14
发表了文章
2022-12-19 13:32:14
TapTap 算法平台的 Serverless 探索之路
TapTap 算法平台的 Serverless 探索之路
12.19
11:32:23
发表了文章
2022-12-19 11:32:23
【直播】直播预告 | 云原生游戏第4讲：游戏服的网络接入和状态管理【直播已生成回放】
【直播】直播预告 | 云原生游戏第4讲：游戏服的网络接入和状态管理【直播已生成回放】
12.19
11:24:14
发表了文章
2022-12-19 11:24:14
Spring Cloud 应用 Proxyless Mesh 模式探索与实践
Spring Cloud 应用 Proxyless Mesh 模式探索与实践
12.06
10:14:49
发布了视频
2022-12-06 10:14:49
从上云到用云，Serverless 引领下一代应用架构
从上云到用云，Serverless 引领下一代应用架构
12.01
18:17:53
发表了文章
2022-12-01 18:17:53
阿里云可观测 11 月产品动态
阿里云可观测 11 月产品动态
12.01
18:15:11
发表了文章
2022-12-01 18:15:11
问题盘点｜使用 Prometheus 监控 Kafka，我们该关注哪些指标
问题盘点｜使用 Prometheus 监控 Kafka，我们该关注哪些指标
12.01
17:47:28
发表了文章
2022-12-01 17:47:28
跟误告警说再见，Smart Metrics 帮你用算法配告警
跟误告警说再见，Smart Metrics 帮你用算法配告警
12.01
17:43:12
发表了文章
2022-12-01 17:43:12
Prometheus 监测 RocketMQ 最佳实践
Prometheus 监测 RocketMQ 最佳实践
12.01
17:35:17
发表了文章
2022-12-01 17:35:17
全面焕新｜详解 Grafana v9.0.x 新增功能特性
全面焕新｜详解 Grafana v9.0.x 新增功能特性
12.01
15:44:50
发表了文章
2022-12-01 15:44:50
在低容错业务场景下落地微服务的实践经验
在低容错业务场景下落地微服务的实践经验
12.01
15:31:59
发表了文章
2022-12-01 15:31:59
1-5-10 快恢在数字化安全生产平台 DPS 中的设计与落地
1-5-10 快恢在数字化安全生产平台 DPS 中的设计与落地
12.01
10:32:10
发表了文章
2022-12-01 10:32:10
RocketMQ 5.0 可观测能力升级：Metrics 指标分析
RocketMQ 5.0 可观测能力升级：Metrics 指标分析
2022年11月
11.30
18:54:41
发表了文章
2022-11-30 18:54:41
新课程发布 | 如何用 7 分钟击破 Serverless 落地难点？
新课程发布 | 如何用 7 分钟击破 Serverless 落地难点？
11.30
18:33:35
发表了文章
2022-11-30 18:33:35
RocketMQ 的消费者类型详解与最佳实践
RocketMQ 的消费者类型详解与最佳实践
11.30
18:01:25
发表了文章
2022-11-30 18:01:25
【活动已结束】就在明天！我们在 QCon 上海站聊聊 Serverless 架构
【活动已结束】就在明天！我们在 QCon 上海站聊聊 Serverless 架构
11.30
17:47:22
发表了文章
2022-11-30 17:47:22
构建基于 Ingress 的全链路灰度能力
构建基于 Ingress 的全链路灰度能力
11.30
16:10:05
发表了文章
2022-11-30 16:10:05
跟误告警说再见，Smart Metrics 帮你用算法配告警
跟误告警说再见，Smart Metrics 帮你用算法配告警
11.30
14:51:51
发表了文章
2022-11-30 14:51:51
ZooKeeper 避坑实践：如何调优 jute.maxbuffer
ZooKeeper 避坑实践：如何调优 jute.maxbuffer
11.30
13:20:43
发表了文章
2022-11-30 13:20:43
阿里云容器服务 ACK 产品技术动态（202210）
阿里云容器服务 ACK 产品技术动态（202210）
11.30
11:57:11
发表了文章
2022-11-30 11:57:11
降价背后，函数计算规格自主选配功能揭秘
降价背后，函数计算规格自主选配功能揭秘
11.30
11:24:46
发表了文章
2022-11-30 11:24:46
如何通过链路追踪进行定时任务诊断
如何通过链路追踪进行定时任务诊断
11.29
17:42:19
发表了文章
2022-11-29 17:42:19
Kubernetes 多集群管理平台 OCM v0.9.0 发布：进一步改善托管集群安全性问题
Kubernetes 多集群管理平台 OCM v0.9.0 发布：进一步改善托管集群安全性问题
11.29
17:14:44
发表了文章
2022-11-29 17:14:44
Higress 实战：30 行代码写一个 Wasm Go插件
Higress 实战：30 行代码写一个 Wasm Go插件
11.29
16:23:22
发表了文章
2022-11-29 16:23:22
Serverless Devs 重大更新，基于 Serverless 架构的 CI/CD 框架：Serverless-cd
Serverless Devs 重大更新，基于 Serverless 架构的 CI/CD 框架：Serverless-cd
11.29
15:28:02
发表了文章
2022-11-29 15:28:02
RocketMQ 客户端负载均衡机制详解及最佳实践
RocketMQ 客户端负载均衡机制详解及最佳实践
11.29
11:29:29
发表了文章
2022-11-29 11:29:29
谈谈我工作中的23个设计模式
谈谈我工作中的23个设计模式
11.29
10:38:09
发表了文章
2022-11-29 10:38:09
报名即将结束！11 大云原生领域开源技术干货一场拿下
报名即将结束！11 大云原生领域开源技术干货一场拿下
11.28
16:44:58
发表了文章
2022-11-28 16:44:58
Prometheus 监测 RocketMQ 最佳实践
Prometheus 监测 RocketMQ 最佳实践
11.25
14:55:12
发表了文章
2022-11-25 14:55:12
又一创新！阿里云 Serverless 调度论文被云计算顶会 ACM SoCC 收录
又一创新！阿里云 Serverless 调度论文被云计算顶会 ACM SoCC 收录
11.25
14:16:18
发表了文章
2022-11-25 14:16:18
阿里云与信通院邀您参与云原生安全用户调研
阿里云与信通院邀您参与云原生安全用户调研
11.24
18:30:14
发表了文章
2022-11-24 18:30:14
容器服务 ACK 结合 MSE Ingress，让集群入口流量管理更丰富、更容易
容器服务 ACK 结合 MSE Ingress，让集群入口流量管理更丰富、更容易
11.24
17:59:44
发表了文章
2022-11-24 17:59:44
阿里 CTO 程立：Severless 化正加速重塑阿里应用架构和研发模式
阿里 CTO 程立：Severless 化正加速重塑阿里应用架构和研发模式
11.24
17:41:23
发表了文章
2022-11-24 17:41:23
关于平台工程的开发者工具链，你还想加点啥？
关于平台工程的开发者工具链，你还想加点啥？
11.24
17:21:38
发表了文章
2022-11-24 17:21:38
企业如何利用 Serverless 快速扩展业务系统？
企业如何利用 Serverless 快速扩展业务系统？
11.24
16:50:29
发表了文章
2022-11-24 16:50:29
阿里云云原生加速器成员企业袋鼠云创始人陈吉平：深耕国产自研数字化技术与服务，持续为客户创造价值
阿里云云原生加速器成员企业袋鼠云创始人陈吉平：深耕国产自研数字化技术与服务，持续为客户创造价值
11.24
16:31:05
发表了文章
2022-11-24 16:31:05
Serverless Devs 社区联合信通院邀请您参加 2022 中国 Serverless 用户调查
Serverless Devs 社区联合信通院邀请您参加 2022 中国 Serverless 用户调查
11.24
15:33:18
发表了文章
2022-11-24 15:33:18
大规模 Spring Cloud 微服务无损上下线探索与实践
大规模 Spring Cloud 微服务无损上下线探索与实践
11.24
13:55:13
发表了文章
2022-11-24 13:55:13
全面焕新｜详解 Grafana v9.0.x 新增功能特性
全面焕新｜详解 Grafana v9.0.x 新增功能特性
11.24
10:31:49
发表了文章
2022-11-24 10:31:49
上海 Meetup | 一键获取 11 大云原生热门开源项目技术分享入场券
上海 Meetup | 一键获取 11 大云原生热门开源项目技术分享入场券
11.23
18:10:54
发表了文章
2022-11-23 18:10:54
OpenSergo & ShardingSphere 社区共建微服务视角的数据库治理标准
OpenSergo & ShardingSphere 社区共建微服务视角的数据库治理标准
11.23
18:00:15
发表了文章
2022-11-23 18:00:15
2022 云原生编程挑战赛圆满收官，见证冠军战队的诞生
2022 云原生编程挑战赛圆满收官，见证冠军战队的诞生
...
39
跳转至：
发表了文章
2022-12-22
统一观测｜如何使用 Prometheus 监控 Windows
发表了文章
2022-12-22
统一观测｜如何使用 Prometheus 监控 Windows
发表了文章
2022-12-20
【观看直播有礼】第三届云原生实战峰会正式官宣启动
发表了文章
2022-12-19
优化 20% 资源成本，新东方的 Serverless 实践之路
发表了文章
2022-12-19
聊聊与前端工程师天然互补的 Serverless
发表了文章
2022-12-19
如何用 7 分钟玩转函数计算？
发表了文章
2022-12-19
TapTap 算法平台的 Serverless 探索之路
发表了文章
2022-12-19
【直播】直播预告 | 云原生游戏第4讲：游戏服的网络接入和状态管理【直播已生成回放】
发表了文章
2022-12-19
Spring Cloud 应用 Proxyless Mesh 模式探索与实践
发表了文章
2022-12-01
阿里云可观测 11 月产品动态
发表了文章
2022-12-01
问题盘点｜使用 Prometheus 监控 Kafka，我们该关注哪些指标
发表了文章
2022-12-01
跟误告警说再见，Smart Metrics 帮你用算法配告警
发表了文章
2022-12-01
Prometheus 监测 RocketMQ 最佳实践
发表了文章
2022-12-01
全面焕新｜详解 Grafana v9.0.x 新增功能特性
发表了文章
2022-12-01
在低容错业务场景下落地微服务的实践经验
发表了文章
2022-12-01
1-5-10 快恢在数字化安全生产平台 DPS 中的设计与落地
发表了文章
2022-12-01
RocketMQ 5.0 可观测能力升级：Metrics 指标分析
发表了文章
2022-11-30
新课程发布 | 如何用 7 分钟击破 Serverless 落地难点？
发表了文章
2022-11-30
RocketMQ 的消费者类型详解与最佳实践
发表了文章
2022-11-30
【活动已结束】就在明天！我们在 QCon 上海站聊聊 Serverless 架构
正在加载, 请稍后...
滑动查看更多
正在加载, 请稍后...
暂无更多信息
《十万个可观测冷知识》—前端监控怎么用 第一期
发布时间：2022-12-23 11:16:51
视频时长：3分23秒
播放量：6
随着网站、小程序成为生活必需品，用户体验成为重要话题。那么，如何识别单个用户在应用程序中的性能体验
从上云到用云，Serverless 引领下一代应用架构
发布时间：2022-12-06 10:14:49
视频时长：41分54秒
播放量：474
以前构建应用，需要买ECS实例，搭建开源软件体系然后维护它，流量大了扩容，流量小了缩容，整个过程非常复杂繁琐。用了Serverless服务以后，这些问题都简化了，从半托管到全托管，所有服务API化，无限容量充分弹性，可以组装使用，生产力大幅改变。同时推动软件研发模式升级，组装式研发将成为主流。基于阿里云推进核心产品全面 Serverless 化的经历，阿里巴巴研究员、阿里云智能云原生应用平台总经理丁宇（叔同）阐述了企业应用架构的演进历程，以及Serverless兴起带来的行业变化。
ARMS实践｜日志在可观测场景下的应用-LiveTail
发布时间：2022-08-24 17:26:10
视频时长：0分16秒
播放量：37
ARMS实践｜日志在可观测场景下的应用-LiveTail
阿里云 ACK One、ACK 云原生 AI 套件新发布，解决算力时代下场景化需求
发布时间：2022-06-14 18:07:52
视频时长：22分49秒
播放量：89
阿里云 ACK One、ACK 云原生 AI 套件新发布，解决算力时代下场景化需求
为 Serverless Devs 插上 Terraform 的翅膀，实现企业级多环境部署（上）— 研发：使用环境模板创建环境
发布时间：2022-06-14 16:42:35
视频时长：0分20秒
播放量：72
为 Serverless Devs 插上 Terraform 的翅膀，实现企业级多环境部署（上）— 研发：使用环境模板创建环境
【抢先观看】全面进化：阿里云 ACK One、ACK 云原生 AI 套件新发布
发布时间：2022-06-13 12:14:14
视频时长：1分0秒
播放量：72
2022 阿里云峰会上，阿里巴巴高级研究员蒋江伟宣布 ACK One 公测开启及 ACK 云原生 AI 套件发布，使 ACK Anywhere “计算无界、承载无限” 的服务能力迈向新阶段。今天下午14:00，将开启 ACK One 及 ACK 云原生 AI 套件全面解读，通过专家解读+大咖对话的形式，聊聊算力时代的ACK One、ACK 云原生 AI 套件的新解法。
《Serverless Job——传统任务新变革》XXL Job 0 改造迁移流程
发布时间：2022-06-01 10:47:20
视频时长：3分41秒
播放量：126
《Serverless Job——传统任务新变革》XXL Job 0 改造迁移流程
《Serverless Job——传统任务新变革》SAE Job 的整体使用流程
发布时间：2022-06-01 10:46:23
视频时长：0分53秒
播放量：208
《Serverless Job——传统任务新变革》SAE Job 的整体使用流程
聊聊 sealer 开源背后的故事​
发布时间：2022-05-27 17:36:51
视频时长：45分53秒
播放量：91
直播讲师：​​中弈｜sealer发起人​摩羯｜政采云交付技术负责人​吕莫｜ADP-online产品负责人​​直播简介：​ ​4 月，CNCF TOC 例会投票，一致通过 sealer 开源项目成为 CNCF 官方沙箱项目。sealer 的核心理念是像 Docker 一样构建整个集群以及分布式应用，在整个集群纬度保障一致性，实现整个集群里所有分布式软件的 Build、 Share、 Run！开源一年多时间，sealer 在 ISV 市场得到了广大用户的青睐。​本期「开源夜聊」邀请 sealer 发起人、政采云技术负责人以及阿里云ADP-online产品负责人做客直播间，畅聊项目背后的故事。​
《更省更快，如何使用 Serverless 搭建个人专属网盘？》—畅想
发布时间：2022-05-16 16:53:46
视频时长：4分35秒
播放量：50
《更省更快，如何使用 Serverless 搭建个人专属网盘？》—畅想
《更省更快，如何使用 Serverless 搭建个人专属网盘？》—部署实战
发布时间：2022-05-16 16:52:38
视频时长：8分7秒
播放量：69
《更省更快，如何使用 Serverless 搭建个人专属网盘？》—部署实战实操
《重磅发布 | Serverless 应用中心：Serverless 应用全生命周期管理平台》—通过 Github 等代码仓库进行项目创建
发布时间：2022-05-16 16:20:33
视频时长：1分57秒
播放量：76
《重磅发布 | Serverless 应用中心：Serverless 应用全生命周期管理平台》—通过 Github 等代码仓库进行项目创建演示
《重磅发布 | Serverless 应用中心：Serverless 应用全生命周期管理平台》—创建应用案例
发布时间：2022-05-16 16:19:21
视频时长：0分52秒
播放量：103
《重磅发布 | Serverless 应用中心：Serverless 应用全生命周期管理平台》文章中创建应用案例时的演示
【科普】如果程序员穿越到古代当皇帝，会发生什么？
发布时间：2022-05-16 14:52:34
视频时长：4分37秒
播放量：719
皇帝组建一个内阁团队，不仅可以提高办事效率，而且还能帮助自己分担一部分的工作。而云计算中的EventBridge，就是一个可以分析、归类和传递奏折，并且能处理突发状况的“内阁”。
0115 KubeMeet 成都站「云原生应用交付与管理」开发者沙龙
发布时间：2022-04-22 01:04:04
视频时长：193分17秒
播放量：471
伴随着 Kubernetes 生态逐步完善，越来越多的大型互联网终端企业开始加入到云原生梯队中，云原生应用管理与交付正在成为 Kubernetes 之上重要的价值聚焦点。本次活动将结合云原生应用交付、自动化部署、跨集群管理等环节中的落地挑战，分享 KubeVela、OpenKruise、OCM、Sealer 等开源技术的应对思路和企业级应用实践。
1127 KubeMeet 深圳站「云原生边缘计算」专场开发者沙龙
发布时间：2022-04-22 00:53:16
视频时长：201分50秒
播放量：439
在 5G、物联网等新技术的持续推动下，边缘计算产业已然走向大风口，未来越来越多的种类，越来越大的规模和越来越复杂的应用和工作负载都会被部署到边缘侧。11月27日 KubeMeet 深圳站，将以「云原生边缘计算」为主题，围绕业界第一个以无侵入方式延伸原生 Kubernetes 到边缘计算领域的项目——OpenYurt 展开技术分享和企业实践经验交流。整体活动聚焦云原生和边缘计算融合难题，帮助开发者解决大规模应用场景下的交付、运维、管控等挑战，让开发者能更好的应对云原生边缘计算难题。本次活动将邀请招商云Paas平台部总经理，段嘉、深信服云计算开发工程师，赵震、电信天翼云研发工程师，张力方以及VMware主任工程师，刘武明，共同为大家分享云原生在边缘的实践与应用。
1016 KubeMeet 上海站「云原生应用管理」专场开发者沙龙
发布时间：2022-04-22 00:30:57
视频时长：200分9秒
播放量：390
KubeMeet 是由云原生基金会 CNCF 与阿里巴巴、阿里云开发者 ACE 联合主办的、面向一线开发者的技术交流活动，整体内容聚焦云原生& Kubernetes 方向，旨在通过热门的开源技术、云原生在企业的应用实践案例、架构设计思维等，帮助开发者学习云原生技术、交流实践中的问题和痛点，推进云原生和 Kubernetes 在国内的规模化应用落地。10月16日上海站， KubeMeet 将以「云原生应用管理」为主题，围绕 KubeVela 和 OpenKruise 两个项目的技术分享和企业实践展开，帮助开发者更好的应对云原生应用管理痛点。
0626 【EDGE X Kubernetes Meetup】 杭州站：云原生在边缘的实践与应用
发布时间：2022-04-20 18:47:17
视频时长：265分21秒
播放量：371
云原生在边缘的实践与应用将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控正在成为新趋势。近期，阿里云与 VMWare 中国研发中心宣布达成依托开源社区 OpenYurt 与 EdgeX Foundry 的云原生边缘计算战略合作，也印证了业界对于 Kubernetes 在未来几年将成为边缘计算主导平台地位这一方向的认可。6 月 26 日，阿里云联合 VMware、Intel 举办 KubeMeet 定制专场，发起一次 OpenYurt 社区和 EdgeX Foundry 社的“聚会”，并且焦云原生和边缘计算融合难题，帮助开发者解决大规模应用场景下的交付、运维、管控等挑战。12 位来自不同行业和场景的贡献者，将和两个开源项目的核心成员一起，共同探讨云原生在边缘的实践与应用。
0417 KubuMeet 杭州站「云原生应用管理专场」开发者沙龙
发布时间：2022-04-19 18:05:33
视频时长：150分46秒
播放量：474
伴随着 Kubernetes 生态逐步完善，越来越多的大型互联网终端企业开始加入到云原生梯队中，云原生应用管理与交付正在成为 Kubernetes 之上重要的价值聚焦点。KubeMeet是由云原生基金会CNCF与阿里巴巴联合主办的、面向一线开发者的技术交流活动，整体内容聚焦云原生&Kubernetes方向。4月17日杭州站，KubeMeet 将以「云原生应用管理」为主题，帮助开发者应对云原生应用管理痛点。本次活动邀请到了阿里云高级技术专家王仁达(花名: 封崇)、阿里云技术专家 & OpenKruise 负责人王思宇（花名：酒祝）、第四范式-机器学习平台资深工程师马浩以及携程资深软件工程师施燕，为大家分享 KubeVela、OpenKruise 等热门开源技术实践、云原生在企业的应用案例等。
正在加载, 请稍后...
滑动查看更多
勋章
关注
粉丝