消息中间件:为什么我们选择 RocketMQ

alicloudnative阅读(1644)评论(0)

6.13头图.jpg

作者:李伟

说起消息队列,ActiveMQ、RabbitMQ、RocketMQ、Kafka、Pulsar 等纷纷涌入我们的脑海中, 在如此众多的开源消息队列产品中,作为一名合格的架构师如何给出高性价比的方案呢?商业化的产品暂不纳入选项中。

接下来我将从选型要素、RocketMQ 的优势两个方面解释为什么选择 RocketMQ 。

选型要素


首先从公司、消息队列服务提供者(一般是中间件团队)、最终用户三个角度来简单总结分析。

一、从公司层面看, 关注如下几点:


1. 技术成本

技术成本,一般包含服务器成本、二次开发成本、后期维护成本等,言而总之:都是钱。

服务器目前基本都使用云服务器,不同的云厂商的相同配置的服务器性能也有一定差异, 服务器成本一般需要了解:云厂商机器性能、云厂商优惠、所需服务器配置、服务器台数、单台服务器目前的价格、单台服务器优惠后的价格等。

2. 人力成本

人力成本,一般包含现有技术人员成本、新人招聘成本。

新的技术选型对于目前的技术人员接受程度怎么样,学习的难易程度怎样等,都是需要考虑的。如果太难的话,上线周期会变长、业务需求实现速度慢,甚至有人直接离职。

新人招聘成本,一般招聘一个新人有如下几个过程:简历筛选、预约面试、数轮面试、发 offer 、接受 offer 、正式入职、试用期、转正。这中间涉及到猎头成本、人力资源沟通成本、面试成本、新人入职后环境适应成本等等。

3. 其他

目前处于不同阶段的互联网公司对于技术成本、人力成本有着不一样的要求,但是很多有一定规模的公司实际上还是用“买买买”的心态来对待的:只要业务发展快速,买服务器、招人都不是问题,如果成本高了就做技术降成本、裁员。这不仅是员工之痛,也是业务之痛,更是公司之痛。

二、从中间件组层面看, 关注如下几点:


1. 稳定

公司级的服务首要的一点就是稳定。拥有稳定的组件、稳定的服务,业务才能有条不紊的进行。所以说,无论什么时候, 稳定都是王道。

2. 功能支持

不同的业务场景需要的功能也不尽相同,通常我们会考虑重试、死信机制,位点重置,定时延迟消息、事物消息,主从切换,权限控制等方面。

3. 性能

目前包含写入延迟和吞吐。

4. 管理平台

首先需要满足最终用户接入、查看、排障,管理员管控 topic 、消费者方便等。管理平台有现成的最好,方便二次开发 。

5. 监控、报警

监控报警是否完善、是否方便接入公司内部自研体系,或者行业的事实标准 Prometheus 。

6. 运维 & 支持 & 开源社区

如果产品上线后, 大部分时间,我们都是在做运维&支持。运维包含服务部署、迁移、服务升级、解决系统 Bug 、用户使用答疑、管理平台和监控报警平台升级等。

7. 其他

我们除了依赖自身以外,也可以借助社区的力量,同一个问题可能别人遇到过并且提交过 PR ,已经得到解决,我们就可以以此作为借鉴。所以社区的活跃情况也是非常重要的考虑。

三、从最终用户(一般包含业务后端研发以及他们的 Leader )看


1. 稳定性

对于业务的研发和他们的 Leader ,他们的核心任务是实现业务逻辑。如果一个服务三天两头总是有问题, 对于他们来说是比较致命的,所以稳定性是比较核心的一部分。

2. 改造现有项目的难度

旧项目改造其实是业务研发接入新中间件实际操作最多的部分。

3. 新项目接入是否便捷

是否便捷接入跟他们的工作量有着直接的关联。

4. 与目前的 App 微服务框架兼容怎样

新项目的接入和公司微服务框架兼容都比较容易。一般中间件在提供服务时都会考虑业务研发接入的便利性。

RocketMQ 的优势


下面将按照选项要素的要求, 分析 RocketMQ 在这方面的优势。

一、RocketMQ 如何解决和友好面对公司层面的诉求


1. 技术成本

2.png

就技术成熟度而言,在经历阿里双十一数万亿洪峰、微众银行、民生银行、蚂蚁金服、平安、字节跳动、快手、美团、京东、网易等各种行业大厂的考验后,就不言而喻了。

RocketMQ 对于服务器的配置要求不高, 普通的云主机都可以。曾经我们验证 8C 16G 500G SSD 的 2 主 2 从的集群,发送 tps 可以到 4~5w ,消费 tps 峰值 20w +,稳定在 8w~9w 。并且,还能根据业务实际的需求无感的横向扩展。

综合而言, 技术成本相对可控且人才多。

2. 人力成本

人力成本主要是现有的技术人员的学习成本、招新人的成本。

RocketMQ 是 java 开发的,代码也非常稳定、有条理,各个版本之间除了功能有差异之外,Api 、传输协议几乎没有太多变化,对于升级而言也更加方便。

java 也是目前中间件采用的比较主流的语言,使用的技术人员非常广泛。RocketMQ 在金融行业比如:微众银行、民生银行、蚂蚁金服、平安; 其他行业公司,比如阿里、字节跳动、快手、美团、京东、网易等与大量中小企业都在使用,候选人范围相对较大。

RocketMQ 社区也比较活跃,钉钉群、微信群、QQ 群众多,社区文档非常丰富和完善,原理剖析视频、文档也非常多,非常易于学习和入门。

下面是钉钉群,欢迎大家加群留言、答疑。

3F8FC69E-02B9-4A45-B842-B4C3A0D94FEA.png

对于 java 方面的消息队列方面的人才相比 C/C++、C#、Python、Go 等还是更多的:主流的 Kafka 是 scala + java、pulsar 是 java ,对于招聘也有极大的优势。

综合而言,RocketMQ 技术员对于人力成本比较友好。

二、从中间件组层面看,RocketMQ 是如何提供优秀的能力,为业务保驾护航呢?


1. 稳定性

金融级可靠、阿里双十一稳定支持万亿级消息洪峰,在笔者之前所在公司也有过 2 年+零事故的佳绩

2. 功能丰富,支持的场景众多

  • 重试、死信机制,友好、无感的业务重试机制。
  • 顺序消息、事物消息
  • 万级 Topic 数量支持
  • 消息过滤
  • 消息轨迹追踪
  • 主从自动切换
  • 原生支持 Prometheus 监控
  • 原生支持易用管理平台:RocketMQ Console
  • 访问权限控制(ACL)

3. 性能

  • RocketMQ 可以支持 99.9% 的写入延迟在 2 ms ,其他的开源消息队列中间件基本都是大于 5 ms ;目前大部分消息队列中间间都支持横向扩展,吞吐上横向扩展几乎都可以满足。RocketMQ 的在滴滴做的性能测试: _https://developer.aliyun.com/article/664608 _, 大家参考。
  • 发送、消费 tps 和 kafka 一个数量级,Topic 数量剧增对于性能影响较小。

4. 管理平台

RocketMQ Console 原生支持:
https://github.com/apache/rocketmq-externals/tree/master/rocketmq-console

5. 监控、报警

RocketMQ Exporter 原生支持 Prometheus:
https://github.com/apache/rocketmq-exporter

6. 运维 & 支持 & 开源社区

  • 无 zk 等第三方依赖,开箱即用
  • 社区钉钉群、微信群、QQ 群非常活跃,钉钉群、微信群有问必答。
  • 社区最近新来一位小姐姐 Commiter ,团队也在不断壮大。

综合看来,RocketMQ 稳定、可靠、性能好,开箱即用,不依赖 Zookeeper ,系统的稳定性更高,复杂度更小。监控报警等周边设施完善,场景支持全,社区活跃、文档丰富,是中间件团队的不二之选。

三、对于最终用户:业务研发、业务研发 Leader,他们的核心担忧是提供的技术是否稳定可靠、是否快速方便的接入


从中间件组层面看这个问题时,RocketMQ 稳定、可靠,那对于接入是否友好呢?

RocketMQ 提供 java 原生客户端、Spring 客户端,C++ 客户端、Python 客户端、Go 客户端等多类型、多语言的客户端,对于各种项目都可以统一接入。

微服务框架中 Spring Cloud 基本已经成为事实标准,RocketMQ 支持 Spring boot Starter 和 Spring Cloud Function 等多种方式融合入微服务框架,对于 Spring 体系支持更加方便快捷。

Kafka vs RocketMQ


实际中,很多人应该面临过 RocketMQ vs Kafka ,Kafka 适合对于延迟不敏感、批量型、Topic 数量可控、对于消息丢失不敏感的场景。比如大数据场景的 MySQL-2Hive、MySQL-2-Flink 的数据流通道,日志数据流通道等。

RocketMQ 适用于金融转账消息、订单状态变更消息、手机消息 Push 等业务场景。这些场景 Topic 数量通常过万,对于消息延迟和丢失极度敏感,数据通常是论条处理。对于海量数据的问题,一般地横向扩容完全可以解决。

合适的场景选择合适的产品,万能的产品是不存在的,都是折中,都是取舍。

作者介绍


李伟,Apache RocketMQ 社区 Commiter ,Python 客户端项目负责人, Apache RocketMQ 北京社区联合发起人,Apache Doris Contributor 。目前就职于腾讯,主要负责 OLAP 数据库开发,对分布式存储系统设计和研发有丰富经验,也热衷于知识分享和社区活动。

RocketMQ 学习资料


阿里云知行实验室提供一系列的 RocketMQ 在线实操环境,包含操作文档、ubuntu 实验环境,大家随时尝试玩玩:

  • Apache RocketMQ 开源入门最佳实践:

https://start.aliyun.com/course?spm=a2ck6.17690074.0.0.53c52e7dSi19ML&id=eAz6VTK5

4.png

5.png

  • 在 Spring 生态中玩转 RocketMQ:

https://start.aliyun.com/course?spm=a2ck6.17690074.0.0.241e2e7d0aEIxJ&id=hzidp9W1

6.png

实验预览图如下:

7.png

其他资源

  • RocketMQ vs. ActiveMQ vs. Kafka:

http://rocketmq.apache.org/docs/motivation/

  • RocketMQ 源码:

https://github.com/apache/rocketmq

  • RocketMQ Exporter 源码:

https://github.com/apache/rocketmq-exporter

  • RocketMQ Spring 源码:

https://github.com/apache/rocketmq-spring

  • RocketMQ C++ 客户端源码:

https://github.com/apache/rocketmq-client-cpp

  • RocketMQ Python 客户端源码:

https://github.com/apache/rocketmq-client-python

  • RocketMQ Go 客户端源码:

https://github.com/apache/rocketmq-client-go

  • RocketMQ Console 源码:

https://github.com/apache/rocketmq-externals/tree/master/rocketmq-console

  • RocketMQ Flink Connector 源码:

https://github.com/apache/rocketmq-externals/tree/master/rocketmq-flink

微服务拆分之道

alicloudnative阅读(1449)评论(0)

头图.png

 作者| 修冶

背 景


微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,同时,随着 Docker 容器技术和自动化运维等相关技术发展,微服务变得更容易管理,这给了微服务架构良好的发展机会。

在做微服务的路上,拆分服务是个很热的话题。我们应该按照什么原则将现有的业务进行拆分?是否拆分得越细就越好?接下来一起谈谈服务拆分的策略和坚持的原则。

拆分目的是什么?


在介绍如何拆分之前,我们需要了解下拆分的目的是什么,这样才不会在后续的拆分过程中忘了最初的目的。

拆分的本质是为了将复杂的问题简单化,那么我们在单体架构阶段遇到了哪些复杂性问题呢?首先来回想下当初为什么选用了单体架构,在电商项目刚启动的时候,我们只希望能尽快地将项目搭建起来,方便将产品更早的投放市场进行快速验证。在开发初期,这种架构确实给开发和运维带来了很大的便捷,主要体现在:

  • 开发简单直接,代码和项目集中式管理。
  • 排查问题时只需要排查这个应用就可以了,更有针对性。
  • 只需要维护一个工程,节省维护系统运行的人力成本。

但是随着功能越来越多,开发团队的规模越来越大,单体架构的缺陷慢慢体现出来,主要有以下几个方面:

在技术层面,数据库的连接数成为应用服务器扩容的瓶颈,因为连接 MySQL 的客户端数量是有限制的。

除此之外,单体架构增加了研发的成本抑制了研发效率的提升。比如公司的垂直电商系统团队会被按业务线拆分为不同的组。当如此多的小团队共同维护一套代码和一个系统时,在配合的过程中就会出现问题。不同的团队之间沟通少,假如一个团队需要一个发送短信的功能,那么有的研发同学会认为最快的方式不是询问其他团队是否有现成的,而是自己写一套,但是这种想法是不合适的,会造成功能服务的重复开发。由于代码部署在一起,每个人都向同一个代码库提交代码,代码冲突无法避免;同时功能之间耦合严重,可能你只是更改了很小的逻辑却导致其它功能不可用,从而在测试时需要对整体功能回归,延长了交付时间。模块之间互相依赖,一个小团队中的成员犯了一个错误,就可能会影响到其它团队维护的服务,对于整体系统稳定性影响很大。

最后,单体架构对于系统的运维也会有很大的影响。想象一下,在项目初期你的代码可能只有几千行,构建一次只需要一分钟,那么你可以很敏捷灵活地频繁上线变更修复问题。但是当你的系统扩充到几十万行甚至上百万行代码的时候,一次构建的过程包括编译、单元测试、打包和上传到正式环境,花费的时间可能达到十几分钟,并且任何小的修改,都需要构建整个项目,上线变更的过程非常不灵活。

而这些问题都可以通过微服务化拆分来解决。

为了方便你更好的理解这块,在此附上一份表格(内容来源:《持续演进的 Cloud Native:云原生架构下微服务最佳》一书),可以更直观地帮助你认识拆分的目的。

1.png

拆分时机应该如何决策?


产品初期,应该以单体架构优先。因为面对一个新的领域,对业务的理解很难在开始阶段就比较清晰,往往是经过一段时间之后,才能逐步稳定,如果拆分过早,导致边界拆分不合理或者拆的过细,反而会影响生产力。很多时候,从一个已有的单体架构中逐步划分服务,要比一开始就构建微服务简单得多。同时公司的产品并没有被市场验证过,有可能会失败,所以这个投入的风险也会比较高。

另外,在资源受限的情况下,采用微服务架构很多优势无法体现,性能上的劣势反而会比较明显。如下图所示。当业务复杂度达到一定程度后,微服务架构消耗的成本才会体现优势,并不是所有的场景都适合采用微服务架构,服务的划分应逐步进行,持续演进。产品初期,业务复杂度不高的时候,应该尽量采用单体架构。

2.png

随着公司的商业模式逐渐得到验证,且产品获得了市场的认可,为了能加快产品的迭代效率快速占领市场,公司开始引进更多的开发同学,这时系统的复杂度会变得越来越高,就出现单体应用和团队规模之间出现矛盾,研发效率不升反降。上图中的交叉点表明,业务已经达到了一定的复杂度,单体应用已经无法满足业务增长的需求,研发效率开始下降,而这时就是需要考虑进行服务拆分的时机点。这个点需要架构师去权衡。笔者所在的公司,是当团队规模达到百人的时候,才考虑进行服务化。

当我们清楚了什么时候进行拆分,就可以直接落地了吗?不是的,微服务拆分的落地还要提前准备好配套的基础设施,如服务描述、注册中心、服务框架、服务监控、服务追踪、服务治理等几大基本组件,以上每个组件缺一不可,每个组件展开又包括很多技术门槛,比如,容器技术、持续部署、DevOps 等相关概念,以及人才的储备和观念的变化。微服务不仅仅是技术的升级,更是开发方式、组织架构、开发观念的转变。

至此,何时进行微服务的拆分,整体总结如下:

  1. 业务规模:业务模式得到市场的验证,需要进一步加快脚步快速占领市场,这时业务的规模变得越来越大,按产品生命周期来划分(导入期、成长期、成熟期、衰退期)这时一般在成长期阶段。如果是导入期,尽量采用单体架构。
  2. 团队规模:一般是团队达到百人的时候。
  3. 技术储备:领域驱动设计、注册中心、配置中心、日志系统、持续交付、监控系统、分布式定时任务、CAP 理论、分布式调用链、API 网关等等。
  4. 人才储备:精通微服务落地经验的架构师及相应开发同学。
  5. 研发效率:研发效率大幅下降,具体问题参加上面拆分目的里提到的。

拆分时应该坚守哪些指导原则?

1. 单一服务内部功能高内聚低耦合

也就是说每个服务只完成自己职责内的任务,对于不是自己职责的功能交给其它服务来完成。

2. 闭包原则( CCP )

微服务的闭包原则就是当我们需要改变一个微服务的时候,所有依赖都在这个微服务的组件内,不需要修改其他微服务。

3. 服务自治、接口隔离原则

尽量消除对其他服务的强依赖,这样可以降低沟通成本,提升服务稳定性。服务通过标准的接口隔离,隐藏内部实现细节。这使得服务可以独立开发、测试、部署、运行,以服务为单位持续交付。

4. 持续演进原则

在服务拆分的初期,你其实很难确定服务究竟要拆成什么样。从微服务这几个字来看,服务的粒度貌似应该足够小,但是服务多了也会带来问题,服务数量快速增长会带来架构复杂度急剧升高,开发、测试、运维等环节很难快速适应,会导致故障率大幅增加,可用性降低,非必要情况,应逐步划分,持续演进,避免服务数量的爆炸性增长,这等同于灰度发布的效果,先拿出几个不太重要的功能拆分出一个服务做试验,如果出现故障,则可以减少故障的影响范围。

5. 拆分的过程尽量避免影响产品的日常功能迭代

也就是说要一边做产品功能迭代,一边完成服务化拆分。比如优先剥离比较独立的边界服务( 如短信服务等 ),从非核心的服务出发减少拆分对现有业务的影响,也给团队一个练习、试错的机会。同时当两个服务存在依赖关系时优先拆分被依赖的服务。

6. 服务接口的定义要具备可扩展性

服务拆分之后,由于服务是以独立进程的方式部署,所以服务之间通信就不再是进程内部的方法调用而是跨进程的网络通信了。在这种通信模型下服务接口的定义要具备可扩展性,否则在服务变更时会造成意想不到的错误。比如微服务的接口因为升级把之前的三个参数改成了四个,上线后导致调用方大量报错,推荐做法服务接口的参数类型最好是封装类,这样如果增加参数就不必变更接口的签名,而只需要在类中添加字段就可以了

7. 避免环形依赖与双向依赖

尽量不要有服务之间的环形依赖或双向依赖,原因是存在这种情况说明我们的功能边界没有化分清楚或者有通用的功能没有下沉下来。

3.png

8. 阶段性合并

随着你对业务领域理解的逐渐深入或者业务本身逻辑发生了比较大的变化,亦或者之前的拆分没有考虑的很清楚,导致拆分后的服务边界变得越来越混乱,这时就要重新梳理领域边界,不断纠正拆分的合理性。

拆分的粒度是不是越细越好?


目前很多传统的单体应用再向微服务架构进行升级改造,如果拆分粒度太细会增加运维复杂度,粒度过大又起不到效果,那么改造过程中如何平衡拆分粒度呢?

4.png

1. 弓箭原理

平衡拆分粒度可以从两方面进行权衡,一是业务发展的复杂度,二是团队规模的人数。如上图,它就像弓箭一样,只有当业务复杂度和团队人数足够大的时候,射出的服务拆分粒度这把剑才会飞的更远,发挥出最大的威力。

比如说电商的商品服务,当我们把商品从大的单体里拆分出来的时候,就商品服务本身来讲,逻辑并没有足够复杂到 2 ~ 3 个人没法维护的地步,这时我们没有必要继续将商品服务拆的更细,但是随着业务的发展,商品的业务逻辑变的越来越复杂,可能同时服务公司的多个平台,此时你会发现商品服务本身面临的问题跟单体架构阶段面临的问题基本一样,这个阶段就需要我们将商品拆成更细粒度的服务,比如,库存服务、价格服务、类目服务、商品基础信息服务等等。

虽然业务复杂度已经满足了,如果公司此时没有足够的人力(招聘不及时或员工异动比较多),服务最好也不要拆分,拆分会因为人力的不足导致更多的问题,如研发效率大幅下降(一个开发负责与其不匹配数量的服务)。这里引申另外一个问题,一个微服务究竟需要几个开发维护是比较理性的?我引用下李云华老师在”从零开始学架构“ 中的一段经典论述,可以解决此问题。

2. 三个火枪手原则

为什么说是三个人分配一个服务是比较理性的?而不是 4 个,也不是 2 个呢?

首先,从系统规模来讲,3 个人负责开发一个系统,系统的复杂度刚好达到每个人都能全面理解整个系统,又能够进行分工的粒度;如果是 2 个人开发一个系统,系统的复杂度不够,开发人员可能觉得无法体现自己的技术实力;如果是 4 个甚至更多人开发一个系统,系统复杂度又会无法让开发人员对系统的细节都了解很深。

其次,从团队管理来说,3 个人可以形成一个稳定的备份,即使 1 个人休假或者调配到其他系统,剩余 2 个人还可以支撑;如果是 2 个人,抽调 1 个后剩余的 1 个人压力很大;如果是 1 个人,这就是单点了,团队没有备份,某些情况下是很危险的,假如这个人休假了,系统出问题了怎么办?

最后,从技术提升的角度来讲,3 个人的技术小组既能够形成有效的讨论,又能够快速达成一致意见;如果是 2 个人,可能会出现互相坚持自己的意见,或者 2 个人经验都不足导致设计缺陷;如果是 1 个人,由于没有人跟他进行技术讨论,很可能陷入思维盲区导致重大问题;如果是 4 个人或者更多,可能有的参与的人员并没有认真参与,只是完成任务而已。

“三个火枪手”的原则主要应用于微服务设计和开发阶段,如果微服务经过一段时间发展后已经比较稳定,处于维护期了,无须太多的开发,那么平均 1 个人维护 1 个微服务甚至几个微服务都可以。当然考虑到人员备份问题,每个微服务最好都安排 2 个人维护,每个人都可以维护多个微服务。

综上所诉,拆分粒度不是越细越好,粒度需要符合弓箭原理及三个火枪手原则。

拆分策略有哪些?


拆分策略可以按功能和非功能维度进行考虑,功能维度主要是划分清楚业务的边界,非功能维度主要考虑六点包括扩展性、复用性、高性能、高可用、安全性、异构性。接下来详细介绍下。

功能维度

功能维度主要是划分清楚业务边界,采用的主要设计方法可以利用 DDD(关于 DDD 的理论知识可以参考网上其它资料),DDD 的战略设计会建立领域模型,可以通过领域模型指导微服务的拆分,主要分四步进行:

  • 第一步,找出领域实体和值对象等领域对象。
  • 第二步,找出聚合根,根据实体、值对象与聚合根的依赖关系,建立聚合。
  • 第三步,根据业务及语义边界等因素,定义限界上下文。
  • 第四步,每一个限界上下文可以拆分为一个对应的微服务,但也要考虑一些非功能因素。

以电商的场景为例,交易链路划分的限界上下文如下图左半部分,根据一个限界上下文可以设计一个微服务,拆解出来的微服务如下图右侧部分。

5.png

2. 非功能维度

当我们按照功能维度进行拆分后,并不是就万事大吉了,大部分场景下,我们还需要加入其它维度进一步拆分,才能最终解决单体架构带来的问题。

  • 扩展性:区分系统中变与不变的部分,不变的部分一般是成熟的、通用的服务功能,变的部分一般是改动比较多、满足业务迭代扩展性需要的功能,我们可以将不变的部分拆分出来,作为共用的服务,将变的部分独立出来满足个性化扩展需要。同时根据二八原则,系统中经常变动的部分大约只占 20%,而剩下的 80 % 基本不变或极少变化,这样的拆分也解决了发布频率过多而影响成熟服务稳定性的问题。
  • 复用性:不同的业务里或服务里经常会出现重复的功能,比如每个服务都有鉴权、限流、安全及日志监控等功能,可以将这些通过的功能拆分出来形成独立的服务,也就是微服务里面的 API 网关。在如,对于滴滴业务,有快车和顺风车业务,其中都涉及到了订单支付的功能,那么就可以将订单支付独立出来,作为通用服务服务好上层业务。如下图:

6.png

  • 高性能:将性能要求高或者性能压力大的模块拆分出来,避免性能压力大的服务影响其它服务。常见的拆分方式和具体的性能瓶颈有关,例如电商的抢购,性能压力最大的是入口的排队功能,可以将排队功能独立为一个服务。同时,我们也可以基于读写分离来拆分,比如电商的商品信息,在 App 端主要是商详有大量的读取操作,但是写入端商家中心访问量确很少。因此可以对流量较大或较为核心的服务做读写分离,拆分为两个服务发布,一个负责读,另外一个负责写。还有数据一致性是另一个基于性能维度拆分需要考虑的点,对于强一致的数据,属于强耦合,尽量放在同一个服务中(但是有时会因为各种原因需要进行拆分,那就需要有响应的机制进行保证),弱一致性通常可以拆分为不同的服务。

7.png

  • 高可用:将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来,然后重点保证核心服务的高可用。具体拆分的时候,核心服务可以是一个也可以是多个,只要最终的服务数量满足“三个火枪手”的原则就可以。比如针对商家服务,可以拆分一个核心服务一个非核心服务,核心服务供交易服务访问,非核心提供给商家中心访问 。
  • 安全性:不同的服务可能对信息安全有不同的要求,因此把需要高度安全的服务拆分出来,进行区别部署,比如设置特定的 DMZ 区域对服务进行分区部署,可以更有针对性地满足信息安全的要求,也可以降低对防火墙等安全设备吞吐量、并发性等方面的要求,降低成本,提高效率。
  • 异构性:对于对开发语言种类有要求的业务场景,可以用不同的语言将其功能独立出来实现一个独立服务。

以上几种拆分方式不是多选一,而是可以根据实际情况自由排列组合。同时拆分不仅仅是架构上的调整,也意味着要在组织结构上做出相应的适应性优化,以确保拆分后的服务由相对独立的团队负责维护。

服务都拆了为什么还要合并?


古希腊哲学家赫拉克利特曾经说过:“人不能两次踏进同一条河流。”随着时间的流逝,任何事物的状态都会发生变化。线上系统同样如此,即使一个系统在不同时刻的状况也绝不会一模一样。现在拆分出来的服务粒度也许合适,但谁能保证这个粒度能够一直正确呢。

服务都拆了为什么还要合,就是要不断适应新的业务发展阶段,笔者这里做个类比看大家是否清晰,拆相当于我们开发代码,合相当于重构代码,为什么要重构呢,相信你肯定知道。微服务的合也是一样的道理,随着我们对应用程序领域的了解越来越深,它们可能会随着时间的推移而变化。例如,你可能会发现由于过多的进程间通信而导致特定的分解效率低下,导致你必须把一些服务组合在一起。

同时因为人员和服务数量的不匹配,导致的维护成本增加,也是导致服务合并的一个重要原因。例如,今年疫情的影响导致很多企业开始大量裁员,人员流失但是服务的数量确没有变,造成服务数量和人员的不平衡,一个开发同学同时要维护至少 5 个服务的开发,效率大幅下降。

那么如果微服务数量过多和资源不匹配,则可以考虑合并多个微服务到服务包,部署到一台服务器,这样可以节省服务运行时的基础资源消耗也降低了维护成本。需要注意的是,虽然服务包是运行在一个进程中,但是服务包内的服务依然要满足微服务定义,以便在未来某一天要重新拆开的时候可以很快就分离。服务合并到服务包示意图如下:

8.png

拆分过程中要注意的风险


1. 不打无准备之仗

开发团队是否具备足够的经验,能否驾驭微服务的技术栈,可能是第一个需要考虑的点。这里并不是要求团队必须具备完善的经验才能启动服务拆分,如果团队中有这方面的专家固然是最好的。如果没有,那可能就需要事先进行充分的技术论证和预演,至少不打无准备之仗。避免哪个简单就先拆哪个,哪个新业务要上了,先起一个服务再说。否则可能在一些分布式常见的问题上会踩坑,比如服务器资源不够、运维困难、服务之间调用混乱、调用重试、超时机制、分布式事务等等。

2. 不断纠正

我们需要承认我们的认知是有限的,只能基于目前的业务状态和有限的对未来的预测来制定出一个相对合适的拆分方案,而不是所谓的最优方案,任何方案都只能保证在当下提供了相对合适的粒度和划分原则,要时刻做好在未来的末一个时刻会变得不和时宜、需要再次调整的准备。因此随着业务的演进,需要我们重新审视服务的划分是否合理,如服务拆的太细,导致人员效率反而下降,故障的概率也大大增加,则需要重新划分好领域边界。

3. 要做行动派,而不是理论派

在具体怎么拆分上,也不要太纠结于是否合适,不动手怎么知道合不合适呢?如果拆了之后发现真的不合适,在重新调整就好了。你可能会说,重新调整成本比较高。但实际上这个问题的本质是有没有针对服务化架构搭建起一套完成的能力体系,比如服务治理平台、数据迁移工具、数据双写等等,如果有的话,重新调整的成本是不会太高的。

进击的云原生,为开发者提供更多可能性

alicloudnative阅读(1124)评论(0)

头图.png

作者|易立 阿里云容器服务负责人

背景

云原生是云计算发展的必然产物,而云原生的持续生长也绝非偶然。


2021年,云原生呈现怎样的面貌、又带来了哪些新变化?阿里云容器服务研发总监易立近日在阿里云开发者大会发表了《云原生应用新边界》的演讲,并表示,云原生为开发者提供了三方面便利:应用基础设施“零”维护、应用架构现代化“零”阻力、数字与物理世界“零”边界。

云原生:因云而生


云原生是因云而生的技术,它根植于开发者,并提供最大云价值。

在 CNCF 2020 开发者现状报告中,现在全球有超过 470 万开发者在使用云原生技术,占全部后端开发者的 36%。开发者已经成为云原生变革最主要的推动力量。

1.png

应用基础设施“零”维护


容器、Serverless 等云原生技术持续推动计算界面上移,复杂性下沉,让开发者可以关注于业务创新而非基础设施,这样可以极大提升研发效率。

阿里云为开发者提供了全国最丰富的云原生产品,帮助企业专注于业务创新、而非基础设施建设。企业可以通过容器服务, 函数计算,服务网格,实现应用架构的互联网化,在此之上,云原生数据库、云原生 AI,云原生大数据等产品更可以帮助企业加速业务流程的数字化与智能化。

应用架构现代化“零”阻力


越来越多的企业希望通过应用现代化改造,比如微服务化、Mesh 化,带来新的的收益,更好地满足业务发展的需求。不过新技术也会给现有应用架构带来很大的冲击。利用云原生技术,可以循序渐进将现有应用架构平滑升级。
2.png

在对现有应用进行现代化改造时, 开发者需要把一个单体应用程序分拆为分布式的微服务架构, Spring Cloud / Dubbo 等微服务架构都是以 SDK 代码库的方式把服务治理逻辑构建在应用程序之中。但这种架构存在几个问题:

  • 侵入性:在微服务框架中,服务治理能力的实现和生命周期与业务逻辑耦合在一起的。服务治理能力的变更和增强需要应用的重新构建和部署,导致升级和维护成本提升。
  • 实现绑定:由于微服务框架代码库通常由特定语言实现,难以支持多语言(polyglot)异构系统之间的集成为挑战。

因此,社区提出 Service Mesh(服务网格)架构 —— 将应用的业务逻辑与服务治理能力解耦。服务治理的能力运行在一个独立的 Sidecar 进程之中,独立部署。通过网络拦截来实现对应用透明的服务发现、流量管理、可观测性、安全等能力。

解决了上述侵入性、绑定的问题,具体优势如下:

  • 复杂性下沉:服务治理实现下沉到基础设施,可以独立演进。使得开发人员可以更加聚焦于业务应用本身。
  • 零侵入:无需代码改造既可以实现零信任安全,可观测性等高阶能力。
  • 多语言支持:可以透明支持多种编程语言和编程框架。

那么,微服务与服务网格是否非此即彼,鱼与熊掌不可得兼?在进行服务网格改造的同时,如何与现有微服务架构兼容并存?

随着社区的努力,服务网格和微服务可以很好地结合在一起, 支撑企业微服务架构平滑演进。

3.png

阿里云提供的托管服务网格 ASM

  • 支持 Dubbo 通信协议, 通过声明式方式支持灰度发布、金丝雀发布、无损下线等能力。
  • 利用阿里开源的 Nacos 服务注册中心,可以统一支持 Mesh 应用和微服务应用的服务注册与发现。Nacos 2.0 性能提升 10 倍, 有效地支持大规模服务网格应用落地。
  • Apache Dubbo 3.0 也在探索 Proxyless 式,也就是采用无代理方式支持服务网格; 在 Proxyless 模式下无需 Sidecar 即可直接通过服务网格的 UDPA 协议实现对 Dubbo 应用的流量管理。这种方式可以进一步网络延迟,减少资源开销。
  • 服务网格也加强了对虚拟机应用部署的支持,助力遗留应用的平滑升级。

4.png

以东风日产汽车为例,介绍企业的服务网格化迁移之路。首先,它的数据服务采用 Python / Java 等不同语言开发,Java 应用使用 Dubbo 微服务框架,Python 使用 REST/HTTP 进行服务调用,缺乏统一的服务治理能力;其次,虚拟机、容器化部署等多种方式并存,希望全面迁移到容器架构。

通过 ASM 服务网格, 无论 Python / Java 应用,是虚拟机不是还是容器化部署, 都可以加入服务网格, 以统一的、声明的方式实现服务治理。其中,现有 Dubbo 微服务应用和网格中的应用, 可以统一使用 Nacos 注册中心实现服务注册与发现, 保持现有应用架构的兼容性。

数字与物理世界“零”边界


数字化创新需要深入行业,将物理和数字世界融合在一起,才能实现创新的业务价值。云边端计算一体协同成为趋势,昨天的阿里云峰会描绘了未来云发展的方向,一云多芯,一云多形态,云与 AIoT 相结合,这有这样才能支撑无处不在的计算。而以容器为代表的云原生技术,因为其敏捷、轻量、可移植的优势,将成为下一代分布式云应用的最重要的载体。

物流是数字化创新的典型场景,围绕着人、货、机、车四个维度,涉及大量的数据处理,智能调度等复杂业务场景。以申通快递为例,每天涉及数亿包裹的中转、运输和派送。数字化技术在物流供应链优化方面发挥重要作用。申通快递基于阿里云边缘容器产品构建了整体云边端一体化架构的物流云 PaaS 平台。

  • PaaS 平台在中心云负责分布式资源调度和应用管理,大数据处理和智能化分析。
  • 位于各地仓储中心的边缘云节点结合 IoT 设备支持快递业务的核心流程,扫描校验等操作在本地即可完成,降低了延迟,减少了对云端的强依赖。

这样架构能够帮助企业成本下降 30%, 稳定性从 99.9% 提升到 99.95%,不但支撑了日常的业务开展,也能从容应对双十一这样的业务高峰。
6.png

菜鸟物流云 PaaS 正是利用阿里云边缘容器服务 ACK@Edge,解决了计算下沉后的分布式资源调度、应用管理、自治运维等挑战。而其背后的核心技术就是阿里云开源的 OpenYurt 项目,该项目已经成为 CNCF 沙箱项目。

边缘计算面临着算力分散,资源异构以及弱网连接等技术挑战。OpenYurt 是基于 Kubernetes 打造的云边协同计算框架,具备边缘应用管理,边缘自治自愈、边缘算力管理等核心能力。

此外,OpenYurt 坚持在原生 K8s 非侵入实现,主打标准化和开放性。在过去两年 OpenYurt 已实现在 CDN、优酷、菜鸟、工业大脑、城市大脑等行业的落地,也支撑了声网、快手等客户。

7.png

如果云是企业智能化的大脑,而 IoT 设备就是眼和手,实现了与物理世界的交互。利用 K8s 降低海量分布式设备的管理复杂性,可以将分布式应用和 IoT 设备实现统一管理和更好的协同。将云原生与 IoT 相结合,会有巨大的创新机遇。

携手VMware共建云原生IoT生态聚开源社区合力打造领域标准


阿里云容器服务负责人易立、VMware 中国研发中心研发总监路广联合宣布达成双方在“云原生边缘计算”领域的技术战略合作,希望未来依托开源社区力量,加速边缘云原生生态系统的构建,共同推动云边融合进程,帮助更多企业全面拥抱数智化转型升级。

8.png

基于共同的理想和愿景,OpenYurt 社区与 Linux 基金会下属 EdgeX Foundry 社区会在边缘计算、IoT、云原生领域深入合作:一方面,通过云原生方式重新定义 IoT 领域的设备管理模式,实现设备孪生能力;一方面,并利用 EdgeX Foundry 成熟的技术生态,让云原生应用支持各种物联网协议和设备。

阿里云开源项目 OpenYurt 和由 VMware 共同发起并维护其中国社区的开源项目 EdgeX Foundry 展开深度合作,将帮助企业和边缘业务开发者在不需要对 K8s 进行任何改造的基础下,轻松打造云边端一体化协同的 IT 架构。作为“即插即用”的开源 IoT Edge 平台,Edge X Foundry(EdgeX)支持来自不同制造商,使用不同协议的设备。同时,OpenYurt 通过原生插件即可将 Kubernetes 延伸至边缘场景,并且支持所有的上游 Kubernetes 特性。

9.png

此外,会上宣布《阿里云云原生架构实践》正式出版。这是一部从技术和商业双重视角剖析云原生如何赋能实际业务的著作,是阿里云智能云原生应用平台团队的经验总结,得到了阿里云智能总裁兼达摩院院长张建锋、阿里巴巴首席技术官程立、阿里云智能基础产品事业部负责人蒋江伟等专家的联袂推荐。

10.png

本书内容全面,对云原生所涵盖的技术和业务特性一览无余,从设计原则、模式/反模式、技术选项、设计方法、行业案例等多个维度全面总结阿里云云原生架构的方法论和实践经验。

Cilium 首次集成国内云服务,阿里云 ENI 被纳入新版本特性

alicloudnative阅读(1812)评论(0)

头图1111.png

作者:清弦
阿里云技术专家,主要负责 ACK 容器网络设计与研发,阿里云开源 CNI 项目 Terway 主要维护者,Cilium Alibaba IPAM 负责人

背景


近期 Cilium 社区发布了 Cilium 1.10 正式版本,在这个版本中正式支持阿里云 ENI 模式,阿里云也是国内首家支持 Cilium 的云厂商。

1.png

Cilium 是一个基于 eBPF 的高性能容器网络项目,提供网络、可观测性、安全三方面的解决方案。

2.png

Cilium 本身支持 Overlay 网络模式部署在各种云平台或者自建的集群上,但是这种非云原生的网络模式会带来不小的性能损耗。阿里巴巴云原生容器服务团队向 Cilium 社区贡献了阿里云 ENI 模式,使得在阿里云上可以以云原生方式运行 Cilium 。

云原生容器服务团队贡献 PR
https://github.com/cilium/cilium/pull/15160
https://github.com/cilium/cilium/pull/15512

架构


AlibabaCloud Operator 是集群内的网络资源控制器,承担对网络资源(ENI、ENIIP)统一管理、分配工作。

3.png

Cilium agent 通过 list-watch 机制、CNI 请求对 Operator 分配的地址资源进行配置、管理。

这种架构将所有阿里云 OpenAPI 调用集中到 Operator 中,可以有效的进行 API 请求管理,避免大规模集群下 API 流控问题。

4.png

基于 Cilium 1.10 + 阿里云 ENI 的高性能云原生网络


Cilium 使用了 EBPF 内核技术对传统数据链路进行了优化,绕过了Conntrack 模块,对容器场景下网络性能有了非常大的提高。在阿里云上使用 Cilium 1.10 + 阿里云 ENI 模式有多种按照方式,请阅读 Cilium 社区的安装文档[1]。

为了使云上用户享受到更加出色的网络性能,阿里云自研的开源 CNI 插件 Terway [2] 与 Cilium 实现了更好的结合。Terway 支持使用阿里云的弹性网卡来实现的容器网络。使得容器网络和虚拟机网络在同一个网络平面,在不同主机之间容器网络通信时不会有封包等损失,不依赖于分布式路由也能让集群规模不受限于路由条目限制。目前,Terway IPvlan 模式已经深度集成 Cilium 。

使用 Terway IPvlan

使用 Terway 模式非常简单,在阿里云容器服务控制台,创建集群中选择网络插件 Terway ,并勾选 IPvlan 即可启用。

5.png

IPvlan + eBPF 性能对比:


测试环境:

  • 2 节点 ecs . g5ne . 4xlarge 机型
  • 对比测试

Terway 独占 ENI ( ipvs )
Terway 共享 ENI IPvlan ( ebpf )
Terway 共享 ENI veth ( ipvs )
Flanne l vxlan ( ipvs )

Netperf 性能对比 TCP_CRR

测试场景:使用 netperf 测试 Pod 间通讯

6.png

上图数字越大性能越好

通过测试,可以看到基于 IPvlan 的 Pod 网络延迟较低,在 TCP_CRR 的测试中性能指标和独占 ENI 模式相当。

wrk + nginx 性能对比

测试场景:采用 wrk 压测 nginx 的 Service 的方式,采用 100 字节的小页面模拟常见的集群中微服务通信。

7.png

上图数字越小性能越好

8.png

上图数字越大性能越好

Terway IPvlan 模式在 wrk- nginx 的短连接测试中相对于传统的 Terway veth 策略路由方式:

  • ClusterIP 吞吐增加 277% , 延迟降低 50%。

总结


随着 Kubernetes 已经成为容器调度的事实标准,企业上云的首选。容器网络做为应用的底层基础资源,得到越来越多的关注。

在阿里云上我们默认提供高性能的 Terway 网络插件 [3] 帮助用户充分使用云原生的网络资源。Cilium 作为社区新兴的容器网络方案,在可观测性、安全性上有许多出色的特性,本次增加的阿里云ENI模式,可以帮助 Cilium 的用户充分使用阿里云上的网络资源。我们也将继续与社区同行,推动高性能的云原生网络实现规模化落地。

安装文档:_https://docs.cilium.io/en/v1.10/gettingstarted/alibabacloud-eni/#k8s-alibabacloud-eni_

Terway: https://www.alibabacloud.com/help/zh/doc-detail/97467.htm
Terway 网络插件:_ https://help.aliyun.com/document_detail/86500.html_

K8s 边缘节点抓不到监控指标?试试这个方法

KubeSphere阅读(3064)评论(0)

KubeSphere v3.1.0 通过集成 KubeEdge,将节点和资源的管理延伸到了边缘,也是 KubeSphere 正式支持边缘计算的第一个版本。

笔者也第一时间搭建和试用了边缘节点相关的功能,但是在边缘节点纳管之后遇到了一些监控的小问题,在排查过程中也顺带了解了一下 KubeSphere 对于边缘节点的监控原理,发出来和大家分享,方便其他的开发者能够更快的排查问题或进行二次开发。

环境版本和构成

通过 KubeKey 安装,参数如下,其余组件版本默认未改动。Kubernetes : v1.19.8KubeSphere : v3.1.0

主机名称 角色
k8s-worker-03 worker
k8s-worker-02 master
k8s-worker-01 master,etcd

问题现象

通过生成的 keadm 命令行将边缘节点加入集群,并在边缘节点上部署 POD,该 POD 的监控信息不能显示。

K8s 边缘节点抓不到监控指标?试试这个方法

监控原理

定位和解决问题之前,肯定是要先搞懂工作原理。

1. KubeEdge

KubeEdge 的 Edgecore 组件对 Kubelet 进行了轻量化改造,Edgecore 和 Cloudcore(云端)也不在同一个 Cluster 网络中,通过 k8s 默认的方式进行 metrics 获取肯定是行不通的(logs 和 exec 原理相同)。

当前 KubeEdge 的实现方法是 kube-apiserver 上的 iptables 转发给云端的 Cloudcore,Cloudcore 通过和 Edgecore 之间的 WebSocket 通道向边缘端进行消息和数据传递。

KubeEdge 官方的使用手册和文档:
https://kubeedge.io/en/docs/advanced/metrics/

为了便于大家理解,作者画了一张图,整体的流程请参考如下:

K8s 边缘节点抓不到监控指标?试试这个方法

2. Metrics-server

原生的 K8S 中就是通过 Metrics-server 这个官方组件进行节点和 POD 的 CPU/Memory 等数据的监控。

简而言之,Metrics-server 通过 Pull 的方式去每个节点上拉取监控数据,放在自身的内存中,提供 K8S 的 API 供 kubectl top 这样的 client 来查询。

Metrics-server 的详细设计,可以参考 github 的官方说明:
https://github.com/kubernetes-sigs/metrics-server

Metrcis-server 的启动参数中,有一个参数要特别说明一下:”kubelet-use-node-status-port“。

在 KubeEdge 的官方文档中,也提到了启动 Metrics-server 时要指定该参数,至于原因文档中并未提及,这里简单说明一下。这个参数的意思是:“调用 kubelet 服务时,用该 Node 上报的 port,而不是默认的 port”。我们知道 kubelet 的 metrcis 接口默认是监听在 10250 端口的,而 KubeEdge 的 edgecore 将 metrics 接口默认监听在 10350 端口,如果不加这个参数,metrice-server 就会通过类似”edgenodeIP:10250/stat/summary“这样的请求去获取监控数据,结果肯定获取失败的。

我们通过 KubeSphere 环境的 yaml 文件,也能清晰地看到这一点配置:

K8s 边缘节点抓不到监控指标?试试这个方法

3. KubeSphere

上面讲到了,Metrics-server 已经从 KubeEdge 那里获取到了边缘节点的监控数据,那么 KubeSphere 只要从 Metrics-server 提供的 K8S API 中即可获取到边缘节点的实时监控数据用来在前端进行展示。

稍微翻了一下 KubeSphere 的代码,和我们的预想是一致的,KubeSphere 通过 metrics-server 拿到了当前版本展示的监控数据。

K8s 边缘节点抓不到监控指标?试试这个方法

K8s 边缘节点抓不到监控指标?试试这个方法

4. EdgeWatcher

从上述第 1 点 KubeEdge 的工作原理来看,是需要在 kube-apiserver 所在的节点上进行 iptables 转发规则设置的(将所有 10350 的请求都转发给 Cloudcore 的 10003 端口进行处理)。

那么每一个边缘节点加入集群的时候不可能由运维人员手动进行 iptables 的规则设置,所以 KubeSphere 就自研了 EdgeWatcher 这样一个组件。这个组件的目的应该是有以下几点:

  • 提供 kubeedge group API(添加边缘节点时前端调用该 group API)
  • 边缘节点加入集群时,设置 IPtables 规则(logs exec metrics 都需要)
  • 验证边缘节点指定的 IP 是否可用,IP 需要全局唯一

EdgeWatcher 暂未开源,作者从社区转载了下面这张 EdgeWatcher 的工作原理图,供大家参考:

K8s 边缘节点抓不到监控指标?试试这个方法

关于边缘节点 IP 需要全局唯一的问题,作者还是有很多想说的,后续有时间再开一篇,和大家一起探讨。

5. 总体概览

其实通过对上述监控组件的了解,我们也基本能勾勒出 KubeSphere v3.1 在基于 KubeEdge 的边缘集成中,所作的努力和工作。下面是作者简单画的一张整体组件架构的图,供大家参考:

K8s 边缘节点抓不到监控指标?试试这个方法

问题定位

既然原理都搞清楚了,下面就简单说一下定位的过程和思路。

1. Metrics-server

首先我们判断 metrics-server 有没有正常提供服务,能不能获取到边缘数据。

从下面的命令结果可以看出,边缘节点(k8s-agent)的监控数据和非边缘节点的 POD 的监控数据都是没有问题的。

K8s 边缘节点抓不到监控指标?试试这个方法

只有边缘节点上的 POD 的监控数据获取不到。

K8s 边缘节点抓不到监控指标?试试这个方法

2. KubeEdge

再来看 KubeEdge 提供的 10350 端口的 metrics 服务,有没有问题。

K8s 边缘节点抓不到监控指标?试试这个方法

K8s 边缘节点抓不到监控指标?试试这个方法

我们可以看到,KubeEdge 的 edgecore 提供的 10350 端口的服务也是没有问题的,可以从中获取到边缘节点和边缘 POD(nginx-xxx)的监控数据。

3. 总结

从上面的分析可以得出以下结论:

  • Metrcis-server 没问题
  • KubeEdge 的 edgecore 在边缘节点的服务没问题
  • cloudcore 和 edgecore 之间的通路没有问题(通过查看 edgecore 的日志,可以看到 stat/summary 的调用,但是 POD 的监控数据调用则没有)

最后再去确认其他可以获取边缘 POD 节点的信息,发现只有 docker 版本的差别,出问题的是 v18.09.1,而正常的节点版本如下:

K8s 边缘节点抓不到监控指标?试试这个方法

至此,基本能断定是 docker 版本过低造成的,至于是哪个接口和 metrics-server 不能兼容,就不花太多时间去调查分析,有经验的开发者可以留言共享一下。

结论

基于这个问题,我们对 Docker 版本进行了测试,最终确认在 Kubesphere v3.1、 metrics-server 版本(v0.4.2)、 KubeEdge v1.6.1 的场景下,Docker 版本要大于等于 v19.3.0 才能支持边缘 POD 的监控。KubeEdge 官方最新版本 v1.7.1 已经发布,从 v1.6.2 的 Changelog 来看,该问题已经被修复了。造成该 pod metrics 丢失的原因,应该是 edgecore 使用的 K8s 版本过低导致的。详情可参考官方 KubeEdge v1.6.2的 Changelog。

后记

虽然问题不是很大,但是通过这个小问题能把边缘监控的脉络搞清楚,是比问题本身更有意义的。

通过这样的分析和总结,问题定位和二次开发的效率才会更高,希望我们社区的开发者一起把 KubeSphere 做得更好更完善。

关于 KubeSphere

KubeSphere (https://kubesphere.io)是在 Kubernetes 之上构建的开源容器混合云,提供全栈的 IT 自动化运维的能力,简化企业的 DevOps 工作流。

KubeSphere 已被 Aqara 智能家居、本来生活、新浪、华夏银行、四川航空、国药集团、微众银行、紫金保险、中通、中国人保寿险、中国太平保险、中移金科、Radore、ZaloPay 等海内外数千家企业采用。KubeSphere 提供了开发者友好的向导式操作界面和丰富的企业级功能,包括多云与多集群管理、Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、审计事件、存储与网络管理、GPU support 等功能,帮助企业快速构建一个强大和功能丰富的容器云平台。

 ✨ GitHub:https://github.com/kubesphere
 💻 官网(中国站):https://kubesphere.com.cn
 👨‍💻‍ 微信群:请搜索添加群助手微信号 kubesphere

6.19 成都站云原生 Meetup,KubeSphere 和 APISIX 等你来!

KubeSphere阅读(4038)评论(0)

以容器技术和容器编排为基础的云原生应用,被越来越多的企业用户接受和使用,并且在生产环境中使用容器技术的比例逐年增加。KubeSphere 作为一款面向应用的开源容器混合云,经过 3 年的发展和 10 个版本的迭代,收获了一百多位开源贡献者,超过十万次下载,并有数千名社区用户用 KubeSphere 作为企业容器云平台。

KubeSphere 之所以能够如此快速发展,得益于开源社区带来的天然优势,以及社区里长期活跃的用户、贡献者积极参与社区,帮助推动产品和社区快速成长,我们坚持认为 KubeSphere 开源社区的每一位用户和贡献者朋友都是 KubeSphere 生态中的重要组成部分。

为了跟社区新老朋友们零距离交流,社区计划从五月到七月,在上海、杭州、成都、北京这四个城市分别为大家带来技术的交流与碰撞。KubeSphere 3.1.0 已在应用商店内置集成了 Apache APISIX,在上海站和杭州站圆满落幕之后,KubeSphere 社区将与 APISIX 联合主办,并与 CNCF 等其他合作伙伴一起,延续 KubeSphere and Friends 的主题,于 6 月 19 日在成都为大家带来 Kubernetes and Cloud Native Meetup。

活动议程

活动时间和地点

活动时间:6月19日 下午 13:00-18:00

活动地点:四川省成都市高新区天府大道中段 500 号天祥广场 B 座 45A

报名已经开启

成都站目前已经开启招募,若您希望获取经验,期待和各位极客交流,那就抓紧报名吧!位置有限,先到先得!

扫描下方二维码即可进入到报名页面进行报名。

活动礼品

KubeSphere 社区特别定制了 KubeSphere 全套纪念周边礼品:T 恤、马克杯、纪念徽章、帆布袋、口罩…… 只要到场即可获取。

由电子工业出版社赞助提供

由图灵教育提供

除此之外,联合主办方 APISIX 也准备了定制 T 恤和电脑贴纸,以及机械工业出版社华章公司赞助的以下书籍,参与互动交流的同学即有机会获得。

下一站预告

第四站 Meetup 将在北京进行,时间是 7 月 29 日,后续我们会放出报名渠道。目前公开向大家招募演讲议题。

任何关于云原生和 KubeSphere 的观点、干货、技术实践、用户故事都是我们社区非常欢迎的。只要您有兴趣分享,就可以提交您的议题。一旦通过,就可以获得讲师大礼包一份!

扫描下方二维码提交您的议题吧!

DevOps Workshop

与杭州站一样,成都站 Meetup 同样设置了 DevOps Workshop,有兴趣的同学可以单独报名哦!

时间:6 月 19 日 10:00-12:30

地点:四川省成都市高新区天府大道中段 500 号天祥广场 B 座 45A

人数:上限 15 人,先到先得,报满即止

参与者需要:

  • 携带笔记本电脑
  • 确保有可以访问 SSH 的客户端

活动安排(以下内容根据实际参加者的情况做适当的增减):

  • KubeSphere DevOps 介绍
    • SIG 介绍
    • 功能介绍
  • Jenkins 稳健性方案介绍
    • 可观测性
    • 告警
  • 案例分享
    • 如何在私有环境中构建、发布 Java 应用
    • 如何实现基于 SpringBoot 的持续交付
  • 参会者实际演练
  • Q&A

报名 Workshop 可加入 DevOps Workshop 现场交流群。

若七天后二维码失效,可添加 小kk 微信:KubeSphere

Apach APISIX 简介

Apache APISIX 是一个动态、实时、高性能的 API 网关, 提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。

APISIX 于 2019 年 4 月由中国的支流科技(api7.ai)创建,于 6 月开源,并于同年 10 月进入 Apache 孵化器。支流科技(api7.ai)对应的商业化产品的名字叫API7 :)。APISIX 旨在处理大量请求,并具有较低的二次开发门槛。

从其主要功能和特点角度来看,Apache APISIX 可以替代 Nginx 来处理南北流量,也可以扮演 Istio 控制平面和 Envoy 数据平面的角色来处理东西向流量。

在云原生时代,动态和可观测性是 API 网关的标准特性。

Apache APISIX 不仅覆盖了 Nginx 的传统功能,在可观测性上也和 SkyWalking 深度合作,大大提升了服务治理能力。

于 KubeSphere

KubeSphere (https://kubesphere.io)是在 Kubernetes 之上构建的开源容器混合云,提供全栈的 IT 自动化运维的能力,简化企业的 DevOps 工作流。

KubeSphere 已被 Aqara 智能家居、本来生活、新浪、华夏银行、四川航空、国药集团、微众银行、紫金保险、中通、中国人保寿险、中国太平保险、中移金科、Radore、ZaloPay 等海内外数千家企业采用。KubeSphere 提供了开发者友向导式操作界面和丰富的企业级功能,包括多云与多集群管理、Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、审计事件、存储与网络管理、GPU support 等功能,帮助企业快速构建一个强大和功能丰富的容器云平台。

 ✨ GitHub:https://github.com/kubesphere
 💻 官网(中国站):https://kubesphere.com.cn
 👨‍💻‍ 微信群:请搜索添加群助手微信号 kubesphere

OpenKruise :SidecarSet 助力 Mesh 容器热升级

alicloudnative阅读(2893)评论(0)

作者| 赵明山(立衡)

头图.jpg

前言


OpenKruise 是阿里云开源的云原生应用自动化管理套件,也是当前托管在 Cloud Native Computing Foundation ( CNCF ) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀,是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件,也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。

OpenKruise 在 2021.5.20 发布了最新的 v0.9.0版本( ChangeLog ),上一篇文章我们介绍了新增 Pod 重启、删除防护等重磅功能,今天向大家介绍另一个核心特性,即 SidecarSet 基于上一个版本扩展了特别针对 Service Mesh 场景的支持。

背景:如何独立升级 Mesh 容器


SidecarSet 是 Kruise 提供的独立管理 Sidecar 容器的 workload。用户通过 SidecarSet 能够便利的完成对 Sidecar 容器的自动注入独立升级,详情请参考:OpenKruise 官网

默认情况下,Sidecar 的独立升级顺序是先停止旧版本的容器,然后再创建新版本的容器。这种方式尤其适合不影响 Pod 服务可用性的 Sidecar 容器,例如日志收集 agent ,但是对于很多代理或运行时的 Sidecar 容器,如 Istio Envoy,这种升级方法就有问题了。Envoy 作为 Pod 中的一个 Proxy 容器代理了所有的流量,这种场景下如果直接重启升级,Pod 服务的可用性必然会受到影响,因此需要考虑应用自身的发布和容量情况,无法完全独立于应用做 Sidecar 的发布。
1--1.png

阿里巴巴集团内部拥有上万的 Pod 都是基于 Service Mesh 来实现相互间的通信,由于 Mesh 容器升级会导致业务 Pod 的不可用,因而 Mesh 容器的升级将会极大阻碍 Service Mesh 的迭代。针对这种场景,我们同集团内部的 Service Mesh 团队一起合作实现了 Mesh 容器的热升级能力。本文将重点介绍在实现 mesh 容器热升级能力的过程中 SidecarSet 是扮演了怎样的重要角色。

SidecarSet 助力 Mesh 容器无损热升级

Mesh 容器不能像日志采集类容器直接原地升级,其原因在于:Mesh 容器必须要不间断地对外提供服务,而独立升级方式会导致 Mesh 服务存在一段不可用时间。虽然社区中已有一些知名的 Mesh 服务如 Envoy 、Mosn 等默认能够提供平滑升级的能力,但是这些升级方式无法与云原生进行恰当地结合,且 kubernetes 本身也缺乏对此类 Sidecar 容器的升级方案。

OpenKruise SidecarSet 为此类 Mesh 容器提供了 Sidecar 热升级机制,能够通过云原生的方式助力 Mesh 容器实现无损热升级。

apiVersion: apps.kruise.io/v1alpha1

kind: SidecarSet
metadata:
name: hotupgrade-sidecarset
spec:
selector:

matchLabels:
app: hotupgrade

containers:

- name: sidecar
image: openkruise/hotupgrade-sample:sidecarv1
imagePullPolicy: Always
lifecycle:
postStart:
exec:
command:
- /bin/sh
- /migrate.sh
upgradeStrategy:
upgradeType: HotUpgrade
hotUpgradeEmptyImage: openkruise/hotupgrade-sample:empty

  • upgradeType : HotUpgrade 代表该 sidecar 容器的类型是 Hot upgrade ,即热升级方案。
  • HotUpgradeEmptyImage : 当热升级 Sidecar 容器时,业务须要提供一个 empty 容器用于热升级过程中的容器切换。Empty 容器同 Sidecar 容器具有相同的配置(镜像地址除外),例如 command , lifecycle , probe 等。

SidecarSet 热升级机制主要包含注入热升级 Sidecar 容器和 Mesh 容器平滑升级两个过程。

注入热升级 Sidecar 容器

针对热升级类型的 Sidecar 容器,在 Pod 创建时 SidecarSet Webhook 将会注入两个容器:

  • {Sidecar.name} -1: 如下图所示 envoy -1,这个容器代表正在实际工作的 sidecar 容器,例如:envoy :1.16.0
  • {Sidecar.name} -2: 如下图所示 envoy-2,这个容器是业务提供的 HotUpgradeEmptyImage 容器,例如:empty :1.0

2-2.png

上述 Empty 容器在 Mesh 容器运行过程中,并没有做任何实际的工作。

Mesh 容器平滑升级

热升级流程主要分为一下三个步骤:

  1. Upgrade: 将 Empty 容器替换为最新版本的 Sidecar 容器,例如:envoy-2.Image = envoy:1.17.0
  2. Migration : 执行 Sidecar 容器的 PostStartHook 脚本,完成 mesh 服务的平滑升级
  3. Reset: Mesh 服务平滑升级后,将老版本 Sidecar 容器替换为 Empty 容器,例如:envoy-1.Image = empty : 1.0

仅需上述三个步骤即可完成热升级中的全部流程,若对 Pod 执行多次热升级,则重复执行上述三个步骤即可。

3-3.png

Migration 核心逻辑

SidecarSet 热升级机制不仅完成了 Mesh 容器的切换,并且提供了新老版本的协调机制( PostStartHook ),但是至此还只是万里长征的第一步,Mesh 容器同时还需要提供 PostSartHook 脚本来完成 Mesh 服务自身的平滑升级(上述 Migration 过程),如:Envoy 热重启、Mosn 无损重启。

Mesh 容器一般都是通过监听固定端口来对外提供服务,此类 Mesh 容器的migration 过程可以概括为:通过 UDS 传递 ListenFD 和停止 Accpet 、开始排水。针对不支持热重启的 Mesh 容器可以参考此过程完成改造,逻辑图如下:
4-4.png

热升级 Migration Demo

不同 Mesh 容器对外提供的服务以及内部实现逻辑各有差异,进而具体的 Migration也有所不同,上述逻辑只是对其中一些要点做了一些总结,希望能对有需要的各位有所裨益,同时在 Github 上面我们也提供了一个热升级 Migration Demo 以供参考,下面将对其中的一些关键代码进行介绍。

1. 协商机制

Mesh 容器启动逻辑首先就需要判断第一次启动还是热升级平滑迁移过程,为了减少Mesh 容器沟通成本,Kruise 在两个 sidecar 容器中注入了两个环境变量 SIDECARSET_VERSION 和 SIDECARSET_VERSION_ALT ,通过判断两个环境变量的值来判断是否是热升级过程以及当前 sidecar 容器是新版本还是老版本。

// return two parameters:

// 1. (bool) indicates whether it is hot upgrade process

// 2. (bool ) when isHotUpgrading=true, the current sidecar is newer or older

func isHotUpgradeProcess() (bool, bool) {// 当前sidecar容器的版本
version := os.Getenv("SIDECARSET_VERSION")
// 对端sidecar容器的版本
versionAlt := os.Getenv("SIDECARSET_VERSION_ALT")
// 当对端sidecar容器version"0"时,表明当前没有在热升级过程
if versionAlt == "0" {
return false, false
}
// 在热升级过程中
versionInt, _ := strconv.Atoi(version)
versionAltInt, _ := strconv.Atoi(versionAlt)
// version是单调递增的int类型,新版本的version值会更大
return true, versionInt > versionAltInt

}

2. ListenFD 迁移

通过 Unix Domain Socket 实现 ListenFD 在不同容器间的迁移,此步同样也是热升级中非常关键的一步,代码示例如下:

// 为了代码的简洁,所有的失败都将不捕获

/ 老版本sidecar通过Unix Domain Socket迁移ListenFD到新版本sidecar /
// tcpLn *net.TCPListener
f, _ := tcpLn.File()
fdnum := f.Fd()
data := syscall.UnixRights(int(fdnum))
// 与新版本sidecar容器通过 Unix Domain Socket建立链接
raddr, _ := net.ResolveUnixAddr(“unix”, “/dev/shm/migrate.sock”)
uds, _ := net.DialUnix(“unix”, nil, raddr)
// 通过UDS,发送ListenFD到新版本sidecar容器
uds.WriteMsgUnix(nil, data, nil)
// 停止接收新的request,并且开始排水阶段,例如:http2 GOAWAY
tcpLn.Close()

/ 新版本sidecar接收ListenFD,并且开始对外服务 /
// 监听 UDS
addr, _ := net.ResolveUnixAddr(“unix”, “/dev/shm/migrate.sock”)
unixLn, _ := net.ListenUnix(“unix”, addr)
conn, _ := unixLn.AcceptUnix()
buf := make([]byte, 32)
oob := make([]byte, 32)
// 接收 ListenFD
, oobn, _, _, := conn.ReadMsgUnix(buf, oob)
scms, _ := syscall.ParseSocketControlMessage(oob[:oobn])
if len(scms) > 0 {

// 解析FD,并转化为 *net.TCPListener 
fds, _ := syscall.ParseUnixRights(&(scms[0]))
f := os.NewFile(uintptr(fds[0]), "")
ln, _ := net.FileListener(f)
tcpLn, _ := ln.(*net.TCPListener)
// 基于接收到的Listener开始对外提供服务,以http服务为例
http.Serve(tcpLn, serveMux)

}

已知 Mesh 容器热升级案例

阿里云服务网格( Alibaba Cloud Service Mesh,简称 ASM)提供了一个全托管式的服务网格平台,兼容社区 Istio 开源服务网格。当前,基于 OpenKruise SidecarSet 的热升级能力,ASM 实现了数据平面 Sidecar 热升级能力( Beta ),用户可以在应用无感的情况下完成服务网格的数据平面版本升级,正式版也将于近期上线。除热升级能力外,ASM 还支持配置诊断、操作审计、访问日志、监控、服务注册接入等能力,全方位提升服务网格使用体验,欢迎您前往试用。

总结

云原生中 Mesh 容器的热升级一直都是迫切却又棘手的问题,本文中的方案也只是阿里巴巴集团在此问题上的一次探索,在反馈社区的同时也希望能够抛砖引玉,引发各位对此中场景的思考。同时,我们也欢迎更多的同学参与到 OpenKruise 社区来,共同建设一个场景更加丰富、完善的 K8s 应用管理、交付扩展能力,能够面向更加规模化、复杂化、极致性能的场景。

 

Seata 新特性,APM 支持 SkyWalking

alicloudnative阅读(1632)评论(0)

简介: Seata、SkyWalking 分别是分布式事务领域、一站式 APM 领域的的佼佼者,早在 2019 年,Seata 的用户就提出了使用 SkyWalking 观测的诉求。

头图.jpg

作者:赵禹光,Seata Contributor,SkyWalking PMC

背景前序

正如所看到的文章题目,就在此时,Seata 与 SkyWalking 两个生态融合,取得了阶段性成果。下面就结合文章内容,给你徐徐道来。

事情的起因是这样的,Seata、SkyWalking 分别是分布式事务领域、一站式 APM 领域的的佼佼者,这一点通过 Github Star 排名就可以知道,也就不再赘述了。所以早在 2019 年,Seata 的用户就提出了使用 SkyWalking 观测的诉求。

Seata 融入 SkyWalking 监控后,就有了 APM 特性,用户在定位 Seata 分布式事务的问题时,可以通过分布式链路、机器指标、日志内容等多个维度进行问题剖析,实现定位问题的提效。

那结合这个诉求,两个社区感兴趣的同学就开始展开了初步讨论和实践,但是由于当时 Seata 的传输协议中,没有类似于 HTTP Header 的面向传输的消息头部,所以实现的第一版虽然实现了监控观测,但是兼容性非常不友好,这在解决分布式事务的监控中,显然是有欠缺的。故此,我们开启了二番讨论,结论是兼容性的前置条件是必须的,所以,Seata 要实现传输协议升级,就此 Seata 将此事放在了 RoadMap 中。SkyWalking 社区这边也暂时搁置了这件事。

时光荏苒,转眼 1 年多就过去了,Seata 社区在过程中已经完成了传输协议的升级,那我们就重启此事。

一、Seata 接入 SkyWalking 后,用户得到了什么

背景已经叙述完了,由于时间有些久,可能大家对两个生态融合之后带来的效果,也不是很清晰了,这里就我的个人的理解,介绍下两个生态融合后,给用户带来的益处:

  • Seata的性能可被更好的观测:

我看到很多 Seata 分享的时候都有用户提问,Seata性能消耗数据,因为分布式事务的性能消耗与场景关系非常大,所以用户通过 SkyWalking 可以更简单的观测自己的场景,自己给自己答案。

  • 分布式事务执行过程有痕迹

在 AT 模式下,Seata 通过面向传输的消息头部,传递全局事务 XID ,全局事务执行完成后,每个在 DB 中的执行过程都会被清理掉,这在回溯执行过程的时候非常不友好,这些海量数据 Seata 可不会存储,这严重增加分布式事务关联数据库表的空间,带来不必要的性能消耗。所以两个生态融合后,SkyWalking 相关的数据库监控,就可以记录这些执行过程的海量数据。

  • 定位问题的提效

在日志中打印 XID 的同时打印 TraceId ,当出现问题想回溯 XID 相关联的全局链路时,在 SkyWalking 的展示端输入 TraceId 即可,通过 Seata 整体监控融入 SkyWalking ,不仅拥有全链路领域的监控,还在仪表盘、拓扑图、在线剖析和报警都得到了监控。

  • 入门 Seata 提高一个维度

分布式事务一直被炒得很热,但真正能在市场上落地的也只有 Seata ,所以 Seata 并没有开源的学习范本,所以快速带领大家入门的资料也比较少。而且 Seata 有3个角色、4种经典模式,可以多种组合,综上所诉,不由得让使用者云里雾里,两个生态融合后,用户可以清晰从上帝(监控)知道 Seata 的执行过程,进而透析工作原理。

二、典型 AT 模式监控场景

下面就官方 AT 模式的 Demo ,展示下接入后的 APM 特性。

官方描述的 ToC 交易场景

  1. 用户请求交易服务
  2. 交易服务锁定库存
  3. 交易服务创建账单
  4. 账单服务进行扣款

当 Seata 与 SkyWalking 融合后,场景复原

全局事务正常链路描述


全局事务异常链路描述


用户手册

官网

SkyWalking APM:
http://seata.io/zh-cn/docs/user/apm/skywalking.html

常用链接

Seata: https://github.com/seata/seata
Samples: https://github.com/seata/seata-samples
Release: https://github.com/seata/seata/releases
官网: https://seata.io

投稿

欢迎大家将 Seata 相关的实践文章投稿至:_slievrly@gmail.com_

春色满园关不住,带你体验阿里云 Knative

alicloudnative阅读(1101)评论(0)

首图.jpg

作者 | 元毅

导读:Knative 是基于 Kubernetes 的开源 Serverless 应用编排框架。阿里云 Knative 在社区 Knative 基础之上,与阿里云产品进行了深度的融合,给你带来最纯粹的容器化 Serverless 体验。

关于 Knative

Knative 是基于 Kubernetes 的开源 Serverless 应用编排框架。实际上 Knative 包含的不单单是 Workload,它还有 Kubernetes 原生的流程编排引擎和完备的事件系统。Knative 目标是基于 Kubernetes 提供应用 Serverless 工作负载编排的标准化。Knative 核心模块主要包括事件驱动框架 Eventing 和部署工作负载的 Serving。

1. Serverless 服务引擎 – Serving

Knative Serving 核心能力就是其简洁、高效的应用托管服务,这也是其支撑 Serverless 能力的基础。当然作为 Serverless Framework 就离不开按需分配资源的能力,Knative 可以根据应用的请求量在高峰时期自动扩容实例数,当请求量减少以后自动缩容实例数,可以非常自动化地帮助您节省成本。

Serving 还提供了流量管理能力和灵活的灰度发布能力。流量管理能力可以根据百分比切分流量,灰度发布能力可以根据流量百分比进行灰度。

1)简单的应用模型

提供了极简的应用模型 – Knative Service ,同时满足服务部署、服务访问以及灰度发布的能力。可以用下面的公式表述:Knative Service = 工作负载(Deployment)+ 服务访问( Service )+ 灰度流量( Ingress )。

应用模型如下图

1.png

  • Service:对 Serverless 应用模型的抽象,通过 Service 管理应用的生命周期;
  • Configuration:用于配置应用期望的信息。每次更新 Service 就会更新 Configuration;
  • Revision:Configuration 的每次更新都会创建一个快照,用来做版本管理;
  • Route:将请求路由到 Revision,并可以向不同的 Revision 转发不同比例的流量。

  • 应用托管
    • Kubernetes 是面向 IaaS 管理的抽象,通过 Kubernetes 直接部署应用需要维护的资源比较多;
    • 通过 Knative Service 一个资源就能定义应用的托管。
  • 流量管理
    • Knative 通过 Gateway 结果应用流量,然后可以对流量按百分比进行分割,这为这为弹性、灰度等基础能力做好了基础。

  • 灰度发布
    • 支持多版本管理,应用同时有多个版本在线提供服务很容易实现;
    • 不同版本可以设置不同的流量百分比,对灰度发布等功能实现起来很容易。

  • 弹性
    • Knative 帮助应用节省成本的核心能力是弹性,在流量增加的时候自动扩容,容,流量下降的时候自动缩容;
    • 每一个灰度的版本都有自己的弹性策略,并且弹性策略和分配到当前版本的流量流量是相关联的。Knative 会根据分配过来的流量多少进行扩容或者缩容的决策。

2)丰富的弹性策略


作为 Serverless 框架,其核心能力就是自动弹性,Knative 中提供了丰富的弹性策略:

  • 基于流量请求的自动扩缩容 – KPA
  • 基于 CPU、Memory 的自动扩缩容 – HPA
  • 支持定时 + HPA 的自动扩缩容策略
  • 事件网关,提供请求与 Pod 1 对 1 处理能力

2. Serverless 事件驱动框架 – Eventing


事件驱动是 Serverless 的标配,在 Knative 中同样提供了事件驱动框架 – Eventing。

Knative 的 Eventing 提供了完整的事件模型,可以很容易地接入各个外部系统的事件。事件接入以后通过 CloudEvent 标准在内部流转。

在 Knative Eventing 提供两种事件转发方式:

  • 事件源直接转发到服务;
  • 事件源转发到 Broker / Trigger ,然后通过过滤转发到服务。

2.png

对于在使用过程中究竟应该使用哪种方式进行转发呢?其实很简单,Broker / Trigger 模型是基于底层消息系统实现的,对于像 Github、Gitlab、K8s APIserver 这样的事件源来说,需要对消息事件进行缓冲处理、保证消息传输可靠性,那么我们建议通过事件源转发到 Broker / Trigger 进行事件流转。

对于事件源本身就是消息系统来说,像 MNS、Kafka、RocketMQ来说,使用事件源直接转发到服务更为高效。

讲到这里,就不得不提 Knative 的事件源。我把它比喻成事件驱动引擎,Knative Eventing 正是通过这些事件源驱动事件流转。

Knative 社区提供了丰富的事件源,如 Kafka、GitHub 等。此外还接入消息云产品事件源,如 MNS、RocketMQ 等。

阿里云 Knative


阿里云 Knative 在社区原生的 Knative 之上,与阿里云资源体系进行了全方位的整合,提供了更为丰富的能力以及云产品级别的支持。

3.png

1. 与阿里云产品融合

  • 丰富的消息云产品事件源:Kafka 、MNS 、RocketMQ
  • 服务访问:SLB
  • 存储:NAS 、云盘等
  • 可观测性:日志服务、ARMS
  • IaaS 资源:ECS 、ECI

2. 天然集成阿里云 K8s 生态

  • 支持阿里云标准版 Kubernetes,专有版 Kubernetes;
  • 支持阿里云 Serverless Kubernetes(ASK), 并且在 ASK 中将 Knative 管控组件全托管,为用户节省了资源以及运维成本。

一个例子


接下来以一个发送弹幕的示例来介绍一下如何玩转阿里云 Knative。先看一下效果:

4.png

架构示意图:

5.png

流程说明:

  • 用户通过弹幕 Web 服务发送弹幕到阿里云 Kafka;
  • Kafka Source 事件源监听到弹幕消息,然后发送到弹幕消息处理服务;
  • 弹幕消息处理服务接收到消息,然后自动弹性扩容实例进行消息处理,并将处理完成的消息发送给弹幕服务;
  • 最后弹幕通过 Web 服务界面展示给用户;

总结


最后我们总结一下阿里云 Knative 能给我们带来哪些能力:

  • 服务部署低门槛、易上手
  • Serverless 按需使用资源
  • 事件驱动与消息云产品无缝对接
  • 天然集成阿里云 K8s 生态
  • 与阿里云产品打通

希望这些能力能给你带来真正的按需使用,降低运维、资源使用成本的诉求,这也是 Serverless 思想理念所追求的目标。

分享:

阿里云边缘容器服务、申通 IoT 云边端架构入选 2021 云边协同发展阶段性领先成果

alicloudnative阅读(1422)评论(0)

简介: 2021 年 6 月 4 日,由中国信息通信研究院(以下简称“中国信通院”)主办的 “ 2021 云边协同大会 ” 在北京举行。本次会议以 “ 开启分布式云新时代 ” 为主题,旨在搭建数字经济与 5G 时代下云服务与边缘计算融合发展的桥梁,并面向行业发布多项云边协同发展阶段性成果。其中,阿里云边缘容器服务 ACK @ Edge 获得 “ 2021 云边协同能力 ”标准认证,在边缘容器技术能力要求的 33 项测评中全部通过;基于 ACK@Edge 实现的申通快递 IoT 云边端架构,入选“ 2021 分布式云与云边协同十佳实践案例 ”。

1.png

2021 年 6 月 4 日,由中国信息通信研究院(以下简称“中国信通院”)主办的 “ 2021 云边协同大会 ” 在北京举行。本次会议以 “ 开启分布式云新时代 ” 为主题,旨在搭建数字经济与 5G 时代下云服务与边缘计算融合发展的桥梁,并面向行业发布多项云边协同发展阶段性成果。其中,阿里云边缘容器服务 ACK @ Edge 获得 “ 2021 云边协同能力 ”标准认证,在边缘容器技术能力要求的 33 项测评中全部通过;基于 ACK@Edge 实现的申通快递 IoT 云边端架构,入选“ 2021 分布式云与云边协同十佳实践案例 ”。

2.png

3.png

阿里云与中国信通院共建云边协同体系标准


国家“ 十四五 ”规划纲要明确指出要 “协同发展云服务与边缘计算服务”。云边协同技术为各行业提供更加全局化的弹性算力资源,为边缘侧提供有针对性的算力,加速各行各业与云计算的协同发展。

然而,各大企业对云边协同架构的认知不尽相同,市场上相关技术和产品水平参差不齐,标准体系的建设就显得尤为重要。在此背景下,中国信通院携手阿里云等 30 余家企业和机构,共推云边协同标准体系。经过广泛征集和深入研讨,在本次大会上,云边协同标准体系宣布建立,并正式发布《云原生边缘技术白皮书( 2021 年)》。

阿里云边缘容器服务 ACK@Edge 通过 33 项能力测评


云边协同标准体系的建立,一方面能够帮助企业准确评估自身的云边协同能力,制定科学、合理的演进路径;另一方面,基于标准体系,云边协同产品提供商能够对于市场需求和技术发展方向精准把握,推进产品形态的演进。

在以该标准体系为指导的 2021 云边协同类能力测评中,阿里云边缘容器服务 ACK@Edge 通过包含对基础能力、协同能力、安全能力、服务保证、质量保证等能力检验维度的全部 33 项测评,获得“ 2021 云边协同能力 ”标准认证。

ACK@Edge 是阿里云容器服务深度挖掘边缘计算+云原生落地实施诉求后推出的云边一体化协同托管方案。以 CNCF Sandbox 项目 OpenYurt 为核心框架,秉持“云端标准管控,边缘适度自治”的服务理念,采用非侵入方式增强,提供边缘自治、边缘单元、边缘流量管理、原生运维 API 支持等能力。架构设计上“云边端”三层结构分层明显,能力协同:

4.png

图:阿里云边缘容器服务( ACK@Edge )技术架构

功能上以原生方式支持对边缘计算场景的容器应用和资源全生命周期管理,包括:

  • 通过纳管边缘节点将云上应用延伸到边缘,联动边缘和云端的数据,使得边缘节点拥有云端相同能力。
  • 在云端提供对边缘设备、边缘应用的统一 Ops 能力,保证边缘设备及边缘智能应用少运维、高可用。

5.png

图:阿里云边缘容器服务( ACK@Edge )功能概览

ACK@Edge 目前已经广泛应用于 CDN 、实时音视频云服务、在线教育、交通、智慧城市、智慧工业、 IoT 、物流、水利、能源、农业等场景,覆盖行业用户数百家、管理数百万容器实例,助力企业简化集群运维工作,专注于边缘业务应用的开发与管理。

以 ACK@Edge 为底座,申通 IoT 云边端架构“入选十佳实践案例”


物流行业作为 IoT 业务的典型落地场景,围绕着人、货、机、车四个维度,涉及大量的自动化、人机辅助等系统交互,并正在逐步形成一个庞大的数字体系。传统云到端的架构根本无法满足实际边端场景需求,亟需一套面向海量设备接入的高可用、高稳定性、可扩展的云边端一体化架构。

申通快递整体云边端架构的边缘 PaaS 平台,正是基于 ACK @ Edge 解决了物理资源分散、云管边端、边缘自治、云边协同的边缘资源管控问题。申通快递 IoT 云边端架构是快递行业在边缘侧演进云原生架构的首例落地方案,将快递实操的核心扫描校验业务通过云边协同能力,在边缘完成整个扫描校验核心流程,支撑快递业务拦截件、预售等业务,从容应对双十一等海量数据大促,使快递实操扫描用户体验上一层新台阶,迈入数字化 2.0 时代。

6.png

图:申通 IoT 云边端一体化架构示意图

申通快递基于 ACK@Edge 的边缘端容器化也是快递行业截至目前首例边缘端演进云原生技术落地实践,并在快递行业的边端场景处于领先水平,为业界打造云边协同技术理念在 IoT 行业落地应用的标杆。

云边协同时代来临,阿里云将携手业界持续拓展云计算边界


随着互联网智能终端设备数量的急剧增加,以及 5G 和物联网时代的到来,将云计算的能力下沉到边缘侧、设备侧,并通过中心进行统一交付、运维、管控,将成为云计算的重要发展趋势。阿里云将会持续通过开放技术生态和全球合作伙伴计划,推动云边融合技术发展和云边协同体系落地,与更多企业分享云时代技术红利,加速业务智能化升级。

云原生推动全云开发与实践

alicloudnative阅读(1371)评论(0)

简介: 今天,千行百业都在拥抱云计算和云原生,进行数字化创新和升级,云原生内涵得到了极大丰富,使得我们今天可以重新定义云原生。云原生技术的出现,有利于帮助开发者构建弹性扩展、容错性好、易于管理,便于观测的松耦合系统,代表技术 Kubernetes 、容器、 DevOps 、微服务、服务网格、 Serverless ,可以看到,这样的技术是一组应用层技术的集合,而云计算的传统优势是资源的池化,这种集约化管理,会带来弹性分布式和基于 API 自动化管理的能力,可以说云原生只有和云计算结合起来,才可以发挥真正的威力。

作者|丁宇

1.jpg

今天,千行百业都在拥抱云计算和云原生,进行数字化创新和升级,云原生内涵得到了极大丰富,使得我们今天可以重新定义云原生。云原生技术的出现,有利于帮助开发者构建弹性扩展、容错性好、易于管理,便于观测的松耦合系统,代表技术 Kubernetes 、容器、 DevOps 、微服务、服务网格、 Serverless ,可以看到,这样的技术是一组应用层技术的集合,而云计算的传统优势是资源的池化,这种集约化管理,会带来弹性分布式和基于 API 自动化管理的能力,可以说云原生只有和云计算结合起来,才可以发挥真正的威力。

因云而生的云原生

2.jpg

云原生技术和云计算结合起来是什么呢?就是我们今天说的云原生产品,今天的云平台提供了大量的云原生产品,包括大数据、数据库、容器服务、中间件、应用 PaaS 、云原生安全、开发者工具、音视频服务、弹性裸金属服务器等,因云而生的产品、软件、硬件、技术、架构才是真正的云原生。

云原生开启全云开发时代


3.jpg

今天我们认为云原生成为云计算的一次再升级。对于云平台来讲,以容器为代表的技术,成为了云计算新的服务界,面向开发者,向下能够封装基础设施,屏蔽异构环境的差异性,以阿里云容器服务 ACK 为例,能够向下封装三十款云产品,带来非常简单的使用界面;向上支持三十多款云产品,支持异构负载和架构。对于企业来讲,云原生正在加速企业的数字化创新,从基础设施云化、核心技术互联网化、应用架构现代化、业务数据化智能化四个方向发力,帮助企业实现业务创新。

今天云原生成为企业数字创新的最短路径和基石,对于开发者来讲,云原生重塑软件生命周期,一方面向下优化,实现软硬一体协同优化,降低技术成本,提升技术效率;另一方面向上支撑多种工作负载,让架构带来更多美好特性。关注云原生的朋友肯定知道, CNCF 已经有几百个项目,从整个应用的开发到具体的开发框架、开发工具 IDE 、测试 CI/CD ,整个发布上线,变更运维容量管理,监控整体升级,可以说是方方面面完全覆盖,云原生给全生命周期带来了一个全新开放标准解决方案,所以,我们认为今天云原生已经开启了全云开发的时代。

云原生带来开发模式革新

4.jpg

云原生带来开发模式的革新,为开发者提供一些非常有优势的特点。

1)架构层面:云原生开发模式是模块化的架构,通过标准化的接口和协议进行通信。

2)应用交付和更新层面:可以进行持续的自动化的迭代、集成和交付。

3)运维层面:标准化、自动化的运维模式。

4)扩展性方面:可按需自动弹性扩展。

5)依赖性层面:具有良好的可移植性,即完全没有厂商锁定的问题,不依赖于系统环境和硬件。

6)企业组织与文化:跨职能沟通与合作顺畅,应对变化能力强。

所以我们认为云原生正在驱动新的开发时代的到来,这是属于开发者的时代。

云原生驱动新开发时代到来

5.jpg

今天的行业调研报告显示,容器的使用正在持续迅猛增长。经过 CNCF 的调研, 2021 年,有 68% 的机构和企业会在生产环境中使用容器,较两年前提升了 240% ,可以说容器无处不在。市场调研显示,对于前端/后端开发,网页/移动端/小程序,逻辑/组件/框架等等, 2021 年开发者云上开发意愿度同样达到了 68% 。 Serverless 比重大幅增加, 2021 年底, 25% 开发者开始使用 Serverless 的技术和产品。

阿里云持续构建开源生态


6.jpg

为了应对和引领时代的变化,以及赋能开发者,阿里云打造了大量的产品技术和开源项目。面向整个技术社区,把云计算研发多年的技术成果回馈给全球顶级基金会,如开放原子开源基金会、 Apache 基金会等,阿里云希望用这样的投入,打造一个开放的、标准的、拥有健康良性的发展技术生态。国内面向微服务的标准,阿里云为云原生基金会孵化了超过 8 个项目,如开放的基于边缘容器的平台 OpenYurt 、分布式高可用领域的混沌工程工具 ChaosBlade 、服务注册发现的 Nacos 等都有非常完整的开源项目。可以说一位开发者想要基于云原生技术、开源技术构建一套开源架构,完全可以找到自己的解决方案。阿里云已经服务了大量企业级头部的用户,如爱奇异、虎牙直播、南方航空、平安科技等等,同时希望构建一套开放标准的技术体系,能够服务于全球开发者。目前,阿里云在开源社区 GitHub 贡献排名目前居中国企业榜首,开源项目超过 2600 个, Contributor 超过3万名, Star 和关注数超过百万。

面向云原生应用,阿里云打造了一站式应用管理和交付平台

7.jpg

云原生技术的出现,最开始是以资源管理为中心的,对应用的友好度不够。基于此,阿里云联合微软提出来 OAM 的开放应用模型,一种能够让开发者、运维人员、测试人员界面变为清晰的、标准化的协同方式。OAM 具备统一的应用描述和应用交付的界面,功能丰富、集成能力强的 PaaS 平台,多环境、多版本应用管理和交付的能力。目前镜像下载量超过 10 万,有字节跳动、第四范式、有赞等 20 多个企业用户。同时,阿里云也推动 OAM 应用管理的规范,成为行业标准。上周信通院刚刚发布,立项 OAM 作为行业标准。

云原生 DevOps 工具链,让研发运维更高效


8.jpg

面向应用的开发运维,阿里云提供了云原生一站式的 DevOps ,让开发运维更加高效。一站式的工具平台从需求管理到整个 CI/CD 上线变更,打破了本地和云的壁垒,实现全云端开发,让整个开发更加高效。如上图所示,具备项目管理、需求管理、代码仓库、代码管理、镜像管理、 CI/CD 测试上线和整个开发者套件,包括外部 IDE ,都是全云端开发工具平台。数据化、智能化具备一体化的平台,可以把全链条的数据打通,打通以后进行全面度量,找出企业和开发者整个生产流程中效率瓶颈的地方,做到优化有据可循。企业级的安全保障,无缝的云产品集成,云效产品和 ECS 的应用管理、 ACK 容器服务、函数计算等集成,融合了信通院研发能力最高等级认证。目前已服务了一百万服务开发者,超过 10 万企业客户。

容器服务助力企业提升资源弹性,大幅降低计算成本

9.jpg

今天容器已经成为开发者所必备的技能。阿里云的容器服务,提供 ACK 、ASK 、多云/混合云管理、异构算力调度、智能化运维体系、 ASM 服务网格、容器应用市场等等基础设施,向上支撑丰富的架构体系,比如微服务、有状态应用,大数据智能化应用和创新应用(区块链 IOT )。基于此,阿里云形成了丰富行业的产品技术解决方案,包括微服务技术架构的方案、云原生大数据的方案、基因计算的方案、 DevOps 方案、容器神龙一体化联合优化的方案、混合云的容器管控方案等等。根据 Gartner 的公共云容器服务的报告,阿里云连续三年成为唯一入选的中国企业,被评为全球容器产品最完善的云服务厂商,目前已经服务了数万企业客户,和数十万企业开发者。

最受国内用户欢迎的 Serverless 产品


10.jpg

随着云原生的发展,云计算使用界面正在上移,带来了更高的开发效率, DevOps 带来全托管免运维极致弹性、快速上线等特性,让开发者更加聚焦于业务逻辑本身。今天 Serverless 逐渐成为了云计算的主流技术,今后也会成为大趋势。

阿里云提供的 Serverless 的产品是基于阿里云的 Serverless 容器 2.0 、第三代的神龙架构、盘古存储和洛神网络形成的自己的 Serverless 的运行池,提供四种形态:面向函数计算 FC 、面向应用 SAE 、面向容器编排 ASK 、面向容器实例 ECI ,支撑了丰富的应用场景,包括全端全站的开发、小程序的开发、在线教育音视频领域开发、应用打包、数据智能的开发,同时也支持非常主流的微服务的架构。

阿里云提供了一整套开发者工具、组件和云端一体化的开发能力,也打造了应用中心,提供了非常多的体验优化、应用模板、经典的案例库,能够让我们开发更加高效,进行更好的二次开发和创新。同时我们也把 Serverless 白盒化,能够更好知道技术栈里边发生了什么,更好的可掌控性。2021 年 Forrester FaaS 报告显示,阿里云的 Serverless 产品能力被评为全球第一, 2020 年信通院面向整个中国的开发者调研,阿里云的 Serverless 市场占有率 66% 。

满足开发者面向应用的一站式可观测需求


11.jpg

面对开发者可观测的诉求,阿里云打造了面向应用全站一站式的可观测产品 ARMS ,可在基础设施层、容器编排与调度层、应用架构层、业务应用层和端测体验层,提供完整的日志事件链路指标分析、 APP 监测能力、前端监控能力、应用监控、链路追踪性能诊断、 Prometheus 的监控,云告警服务等,希望通过统一的运维能力和可观测能力输出产品化,实现自动化的运维。当前,阿里云已选了 2021 年 Gartner APM 魔力象限,是国内唯一入选的云厂商,已服务万家企业客户及数十万开发者。

阿里云是云原生的引领者和最佳实践者


12.jpg

阿里云拥有国内最丰富的云原生产品家族,接近三百个云原生的产品和近千个技术解决方案,有容器层、现代化应用架构层、 aPaaS 微服务消息事件驱动,应用工具 Serverless ,云原生大数据 AI 等等产品体系。生长在云原生时代的企业,可以完全基于云产品构建 IT 技术体系,每一位想要提升自身价值和创造更大生产力的开发者,都可以在阿里云找到完整的丰富的工具和产品体系。阿里云为企业提供五大技术价值,包括资源弹性、安全可信、业务智能、应用敏捷、系统稳定,已经服务了千行百业,像交通、制造、政务、传媒、互联网、金融、零售、通信,服务超过 80% 中国科技公司, 60% 的 A 股上市公司,客户来自于两百个国家和地区,服务超过三百万客户,五百万开发者,已经成为千行百业背后的技术力量。

云原生推动全云开发时代到来,让每一位开发者成为更好的自己,开发者通过使用云原生技术,创造更大的技术价值和商业价值,加速数字经济的发展。

【云原生AI】Fluid + JindoFS 助力微博海量小文件模型训练速度提升 18 倍

alicloudnative阅读(1959)评论(0)

简介: 深度学习平台在微博社交业务扮演着重要的角色。计算存储分离架构下,微博深度学习平台在数据访问与调度方面存在性能低效的问题。本文将介绍微博内部设计实现的一套全新的基于 Fluid(内含 JindoRuntime)的新架构方案,显著提升了海量小文件场景模型训练的性能和稳定性,多机多卡分布式训练场景可将模型训练的速度提升 18 倍。

1.png

作者 |
吴彤 微博深度学习平台工程师
郝丽 微博深度学习平台工程师

导读:深度学习平台在微博社交业务扮演着重要的角色。计算存储分离架构下,微博深度学习平台在数据访问与调度方面存在性能低效的问题。本文将介绍微博内部设计实现的一套全新的基于 Fluid(内含 JindoRuntime)的新架构方案,显著提升了海量小文件场景模型训练的性能和稳定性,多机多卡分布式训练场景可将模型训练的速度提升 18 倍。

背景​


新浪微博是中国最大的社交媒体平台,每天上亿条内容产生并在万亿级关系的社交网络上进行传播。下图是微博的业务生态图,通过优质用户生产、传播优质内容,普通用户消费这些内容,进而关注自己喜欢的博主,建立联系,形成闭环生态。

2.png

微博机器学习平台的主要作用是让整个过程流转得更高效流畅:通过理解优质内容,构建用户画像,把用户感兴趣的优质内容推给用户,让他们和内容生产者互动,进而刺激生产者生产更多更好的内容, 实现信息消费者和信息生产者的双赢。而随着多媒体内容变成主流,深度学习技术就变得更为重要。从多媒体的内容理解,到 CTR 任务的优化,都离不开深度学习技术的支持。

大规模深度学习模型训练挑战


随着深度学习在微博业务场景中的广泛使用,微博深度学习平台扮演了非常核心的角色。该平台采用了存储与计算分离的架构,使得计算资源得以与存储资源解耦,从而实现了灵活的资源配比以及便捷的存储扩展,并且降低了存储成本。

3.png

然而,这种架构也带来了一些挑战,其中比较关键的问题体现在数据访问性能和稳定性方面:

  1. 计算存储分离架构导致数据访问高延时,导致训练慢:业务团队使用的深度学习任务(图像或语音模型)会访问海量小文件。实验表明,HDFS 读取海量小文件场景与本地读取对比性能相差近十倍甚至百倍。
  2. Kubernetes 调度器数据缓存无感知,同一数据源多次运行访问依旧慢:相同模型、不同超参的;微调模型、相同输入的;AutoML 等深度学习任务运行会不断重复访问同一数据,产生可以复用的数据缓存。但是由于原生的 Kubernetes 调度器无法感知缓存,导致应用调度的结果不佳,缓存无法重用,性能得不到提升。
  3. 多数深度学习框架并不支持 HDFS 接口,导致开发难:比如 PyTorch,MxNet 等框架只支持 POSIX 协议接口,HDFS 接口需要额外的对接开发。因此需要同时支持模型开发阶段的 POSIX 接口以及模型训练阶段的 HDFS 接口,引入模型代码适配不同存储的复杂性。
  4. HDFS 成为数据并发访问的瓶颈点,稳定性挑战大:微博机器学习平台上百台 GPU 机器同时训练都会并发访问 HDFS 集群,同时深度学习训练的 IO 压力比较大,HDFS 服务成为了性能单点,这对 HDFS 的性能和稳定性提出了巨大的挑战。一旦某个任务拖慢了 HDFS 系统,其他的训练任务也会受到影响。而且,一旦 HDFS 无法工作,整个训练集群也会受到影响。

通过对微博深度学习平台的监控分析,我们发现:一方面由于 IO 性能问题导致 GPU 等昂贵计算资源不能被充分利用;另一方面,我们也发现集群中的内存和本地硬盘的水位很低,余量较多并且稳定,这是由于多数的深度学习任务并不使用本地磁盘,同时内存使用率也不高。因此我们考虑如果能够充分利用集群自身的内存和磁盘资源加速数据访问会是一种更好的方案。

Fluid + JindoRuntime:为微博深度学习平台提供高效支撑


为了能更好满足大规模深度学习模型训练的计算需求,需要取得更好的数据本地性效果。因此,我们希望达到以下目标:

  1. 计算能够充分利用本地化访问数据,这样数据就不需通过网络反复读取,加速深度学习模型训练的速度和提升集群的 GPU 使用率。
  2. 降低 HDFS 负载压力,通过应用对于部分数据的本地读取,减小数据访问延时和提升 HDFS 的可用性。
  3. 充分发挥热点数据集的缓存节点优势,在对用户无感知的前提下,智能的将任务调度到数据缓存节点上。让常用的模型训练程序越来越快。
  4. 通过 POSIX 接口读取数据,这样无需在模型开发和训练阶段使用不同的数据访问接口,降低开发深度学习模型程序的成本。

为了达到上述目标,我们迫切希望找到 Kubernetes 上具有分布式缓存加速能力的软件。很幸运,我们发现 CNCF Sandbox 项目 Fluid 正好可以满足我们的诉求。于是,我们设计了基于 Fluid 的新架构方案,经过验证比较,我们选择 JindoRuntime 作为加速运行时。

4.png

1. 架构组件介绍

1)Fluid

Fluid[1] 是一个运行在 Kubernetes 上可扩展的分布式数据编排和加速系统,它通过数据的编排和使用数据的应用调度,解决云原生编排框架运行此类应用面临数据访问延时高、多数据源联合分析难、应用使用数据过程复杂等痛点。

2)JindoRuntime

JindoRuntimed[2] 是 Fluid 一种分布式缓存 Runtime 的实现,基于 JindoFS 分布式缓存加速引擎。JindoFS 是阿里云 EMR 团队自研大数据存储优化引擎,完全兼容 Hadoop 文件系统接口,给客户带来更加灵活、高效的计算存储方案。JindoRuntime 使用 JindoFS 的 Cache 模式进行远端文件的访问和缓存,支持 OSS、HDFS、标准 S3 协议等多种存储产品的访问和缓存加速。在 Fluid 上使用和部署 JindoRuntime 流程简单、兼容原生 K8s 环境、可以开箱即用。深度结合对象存储特性,使用 Navite 框架优化性能,并支持免密、checksum 校验等云上数据安全功能。

2. 使用基于 JindoRuntime 的 Fluid 的原因

  1. Fluid 可以将数据集编排在 Kubernetes 集群中,实现数据和计算的同置,并且提供基于 Persistent Volume Claim 接口,实现 Kubernetes 上应用的无缝对接。同时 JindoRuntime 提供对 HDFS 上数据的访问和缓存加速能力,并且可以利用 FUSE 的 POSIX 文件系统接口实现可以像本地磁盘一样轻松使用 HDFS 上的海量文件,pytorch 等深度学习训练工具可利用 POSIX 文件接口读取训练数据。
  2. 针对海量小文件的远程数据访问性能问题,JindoRuntime 对小文件的数据组织管理和访问性能进行了大量针对性的优化,能够提供高效的小文件访问性能,远高于直接对 HDFS 的数据访问性能。
  3. 提供元数据和数据分布式分层缓存,以及高效小文件检索。
  4. 提供数据预热机制,避免在训练时刻拉取数据造成的数据访问竞争。
  5. Slab allocation 方式组织文件数据,高效利用缓存空间。
  6. 通过 Fluid 的数据感知调度能力,用户无需知道缓存节点信息就可以将任务放置到有缓存数据的节点,实现数据访问性能的优势最大化。
  7. 对于大文件和小文件提供不同的缓存策略和存储方式,对于小文件 AI 训练场景具有很好的自适应性,无需用户配置。

3. 落地实践

  1. 选择合适的缓存节点:使用 JindoRuntime 可以获得更好的数据本地性能,在实际生产中我们也发现不是所有的节点都来做缓存性能就比较好。原因是有些节点的磁盘和网络 IO 性能不是很好,这个时候需要我们能够把缓存节点尽量选择一些大容量磁盘和网络较好的节点上去。Fluid 支持 dataset 的可调度性,换言之就是缓存节点的可调度性,我们通过指定 dataset 的 nodeAffinity 来进行数据集缓存节点的调度,从而保证缓存节点可高效的提供缓存服务。
  2. 指定 Master 调度策略:JindoRuntime 由 master/worker/fuse 三部分组成,master 负责集群的大脑,负责元数据和集群缓存的管理,所以 master 节点得具有很强的可靠性和故障恢复速度。在生产过程中我们发现在不使用多 master 的条件下,单个 master 也具有很强的稳定性和故障恢复速度,影响 master 节点稳定性的重要因素还是宿主机的稳定性,比如宿主机满磁盘、通信故障等,基于此我们对 mater 节点使用 nodeselector 来选择性能较好的宿主机作为 master 容器的环境,进一步保证 master 环境的稳定性。
  3. 定时数据预热:在进行训练前的一个重要的步骤是进行元数据和数据的预热,Fluid 提供了 CRD 的形式进行元数据和数据的缓存,在训练前将训练文件的元数据和数据缓存到本地,可大大加速训练速度。但是存储在 HDFS 上的训练文件是每天一次更新,于是需要进行周期性定时的进行数据预热流程,基于 dataload 的 CRD,我们使用 cronJob 的形式进行周期性调度,使得在每次训练前都能够完成元数据和数据的准备,从而进行高效训练。当然 JindoRuntime 本身也支持增量同步的功能,所以每次只需要更新变化的文件即可,也大大加快了数据预热的速度。

4. 性能测试方案


为了验证以上方案的整体效果,我们从稳定性、性能不同角度进行了验证,这里着重介绍性能测试方案,训练的模型都是基于 mmaction 的视频理解模型,采用的是 rawframes_train 方式,是拥有 400w 图片的训练数据集实验,数据是从真实业务场景中提取的 40w 视频中抽帧得到,每个场景下抽 10 帧图片,由于视频清晰度各异,每张图片大小由几 KB 到十几 M 各异,总计大小 780G 左右,每个缓存节点提供 300G 的缓存空间;同时根据经验一般在 50epoch 左右会实现模型收敛。

而当我们把测试的视频数据量调整到 100w,总共的数据大小 2T,由于数据量大和延时长,HDFS 接口的方式完全不能工作;而通过 Fluid+JindoRuntime 则可以满足业务的需要。

测试的流程是会通过 Fluid JindoRuntime 进行数据预热,之后进行模型训练。

5. 性能测试结果


结合 Fluid+JindoRuntime 方案,在数据预热的前提下,我们取得了非常明显的训练速度提升,从下图可以看到:在 3 机 12 卡的场景下,我们发现基于 HDFS 接口读取数据的实验往往会因为网络通信等问题中断,导致实验不能跑完,增加异常处理后,workers 之间的等待时间加长,导致增加卡数并不能增加训练速度,反而会拖慢。可以观察到 1 机 8 卡和 3 机 12 卡的场景总体训练速度基本持平,计算资源的扩容。而通过新的方案,我们发现相比于 HDFS 接口,1 机 4 卡可以得到 5 倍的加速,2 机 8 卡可以得到 9 倍的加速,3 机 12 卡可以得到 18 倍的加速。

5.png

由于训练的速度和稳定性得到了保障,端到端的模型训练时间也得到了显著的提升,训练总时长由原来的 389 小时(16 天)缩短到了 16 小时。

6.png

总结:从两周到 16 小时的训练速度跃升


集成了 Fluid+JindoRuntime 后,显著提升了小文件场景模型训练的性能和稳定性,在多机多卡分布式训练的情况下,可以将模型训练的速度提升 18 倍;将过去需要两周才能完成的训练缩减到了 16 个小时。更短的训练时间和更小的 HDFS 压力,也提升了训练任务的稳定性,将训练的成功率从 37.1% 提升到了 98.3%。目前我们在生产环境的数据量是 4TB,同时随着不断迭代数据量还在持续增长。

微博 AI 训练场景对于数据读取有很高的性能要求,而且海量的小文件对于访问延时也非常敏感,通过 JindoRuntime 的缓存能力可以有效地对大数据存储系统上的数据进行缓存加速,提供稳定可靠的高吞吐、低延时的数据访问性能,同时也可以有效地缓解对后端存储系统的的压力,保证后端存储的稳定性。结合自身的具体场景,优化小文件读取和缓存,不仅可以缓解 HDFS 集群的 IO 压力,也大大提高训练效率。

展望


目前 Fluid+JindoRuntime 更像是杀手锏,用来加速小文件场景,而非常规性武器对于所有数据集进行加速优化,我们期望能够把弹性的数据加速作为微博深度学习平台的差异化能力,提升整体训练任务速度和计算资源的利用率;另一方面也帮助社区不断演进,帮助到更多的开发者。具体来说:

  • 支持定时任务支持动态扩缩容
  • 数据预热性能的提升和元数据备份机制的提供,实现快速重建数据集的能力
  • 提供性能监控控制台
  • 支持 Runtime 元数据的高可用和镜像升级
  • 支持规模化 K8s 集群中多数据集的全生命周期管理

致谢

感谢阿里云 JindoFS 团队的辰山、扬礼和容器团队的车漾在整个方案设计和优化过程中的巨大帮助,在几乎没有任何应用改造前提下,将数据加速能力赋予了现有应用;同时对于测试和生产环境中的需求和问题也及时专业的提供了支持。

相关链接

更多 Fluid 和 JindoFS 相关介绍请参考以下链接:

下方链接,直达项目 GitHub 地址!

https://github.com/fluid-cloudnative/fluid