关于apache:Function-MeshServerless-在消息与流数据场景下的火花

3次阅读

共计 8829 个字符，预计需要花费 23 分钟才能阅读完成。

导语

Pulsar Functions 是 Apache Pulsar 推出的轻量级、函数式计算架构，借助 Pulsar Functions 无需部署独自零碎，即可基于单条音讯创立简单的解决逻辑，简化事件流并引入 Serverless，加重运维累赘。本文由 StreamNative 联结创始人、腾讯云 TVP 翟佳在 Techo TVP 开发者峰会 ServerlessDays China 2021 上的演讲《Function Mesh：Serverless 在音讯与流数据场景的翻新实际》整顿而成，向大家分享。

点击链接，可观看精彩演讲视频：Techo TVP 开发者峰会 ServerlessDays China 2021「无服务器，大有将来 Serverless，Empower More」翟佳

Function Mesh 是 StreamNative 最新开源的一个我的项目。Serverless 和 K8s 联合得十分严密，Function Mesh 也是同样的初衷。之前咱们做的 Pulsar Functions 是将 Pulsar 跟 Serverless 做更好的整合。Function Mesh 则不便大家利用云上的资源，更好地治理 Functions。

明天的分享次要从四个方向开展。Pulsar 的简介、Pulsar Functions 和 Function Mesh，Pulsar 社区。

Pulsar 社区为什么诞生，想做什么样的事件？Pulsar 最开始是一个音讯零碎，在雅虎外部诞生，过后是为了解决什么样的问题？在音讯这个场景里，可能做基础设施的小伙伴都会明确，因为架构技术的起因，依据不同的场景，需要人造分成两个方向。一个是削峰填谷，外部的互相交互的 MQ；另外一个场景，须要做大数据数据引擎，做数据传输的管道。这两个场景的应用场景、数据一致性、技术架构齐全不同。2012 年，雅虎过后次要面临的问题是各个部门之间也会保护多套零碎，在外部就有三四套，相当于整个外部曾经发现运维的瓶颈特地厉害，各个部门之间，数据的孤岛变得特地厉害。所以，雅虎过后做 Pulsar 的最次要的初衷是：对于用户来说，心愿做一个对立的数据平台，提供对立的运维和治理，加重运维压力，进步资源利用率；对于业务部门来说，2012 年也是流计算刚刚衰亡的时候，大家心愿让更多的数据可能买通，让实时计算抓取更多的数据源，失去更准确的计算结果，更好地施展数据的价值。从这两方面登程，Pulsar 的诞生次要提供两个场景的对立，利用同一个平台，解决之前两套在音讯相干场景外面的利用。

有了这样一个需要，看 Pulsar 为什么可能做到这样一件事件？与以下两个方面无关：

第一，云原生架构。背地有几个点，首先是服务层 - 计算层和存储层是齐全隔离的状态。在服务层，不会保留任何数据，所有的数据都交给底层的存储层。同时，在对用户裸露的还是逻辑上的分区的概念。这个分区不像其余的零碎间接绑定文件系统——绑定单节点文件夹，而是把分区又依照用户指定的大小或者工夫划分成了一系列的分片，通过分片模式保障一个分区的数据能够在多个存储节点上做平衡的搁置。通过这种策略，它对于每个分区都实现了分布式的存储、更加分布式的逻辑。扩容、缩容的时候也不会带来任何的数据搬迁，这是云原生架构的劣势。

在架构上第二点是，节点对等的架构。这和雅虎做大集群、多租户的需要密不可分。只有节点之间状态足够简略，状态保护足够简略，能力保护比拟大的集群。在推特外部，底层的存储层有两个机房，每个机房有 1500 个节点。对这种节点对等来说，下层 Broker 很好了解，不存储任何数据，所以是 leaderless 的概念，没有主从之分。在多个备份落到底层存储节点的时候，每个存储节点之间也是对等的状态，要写一个数据，会并发地写多个节点，单节点外部通过 CRC 放弃一致性，然而对多节点的多份数据是并发写入的，所以多个存储节点也是对等的架构。通过这样一套机制，通过自身的 cap 设计，放弃一致性，就有了下面提到存储计算拆散的架构，又有节点对等的根底，所以会给扩大、运维、容错带来更好的体验。

Pulsar 另一个特点是有专门为音讯流做的存储引擎 Apache BookKeeper，BookKeeper 是一个更老的零碎，是 2008、2009 年诞生的产品，也是雅虎开源的零碎，BookKeeper 的诞生次要是为了解决 HDFS 这一层的 HA，它的诞生就是为了保留 namenode 每一次更改，诞生之初就是为了保留元数据的元数据。所以，对一致性、低提早、吞吐，可靠性都有特地高的要求。然而，它的模型很简略，就是一个 write-ahead-log 的形象。这跟咱们的音讯很匹配，因为音讯次要的模式也是 append only 追尾写，随着工夫流逝，之前老的数据价值可能会越来越低，再整体删除。

有了这样一个 BookKeeper 能够提供比较稳定的服务质量，一致性又特地高的反对，Pulsar 就有能力撑持刚刚提到的 MQ 的场景；同时因为 log 这种简略形象，基于数据追加写的模式进步数据的带宽，反对了流的模式。MQ、Kafka 两种场景，都通过底层的存储层提供很好的反对，通过底层的存储层失去保障。

有了后面的根底，要构建 Pulsar 底层对于用户特地实用的企业级 feature 也会特地容易。Pulsar 诞生的起因，是须要有一个大集群，多租户。在这一层对于用户来说，每一个 topic 不再是单级的概念，而是相似于文件系统外面文件夹，是一级目录，二级目录层级的治理。第一级目录就是咱们的租户，次要给用户提供更多的隔离策略，能够给每个租户分不同的权限，每个租户的管理员治理跟其余的租户、外部各个用户之间权限的治理，比方让不让第一个租户拜访第二个租户的信息？相似这种鉴权的信息。

再往下，namespace 这层存的是各种策略，能够不便做很多企业级的管制，比方流控；最底层就是咱们说的 topic。通过层级的概念、大集群的反对，能够更不便地买通用户外部各个组织、各个部门之间的数据。

另外，Pulsar 因为有很好的数据一致性，也有很多用户把它用在跨集群复制的场景里。Pulsar 的跨区域复制，是 broker 自带的内嵌的性能，用户如果须要这个性能，简略地调 Pulsar 的命令，就能够实现跨级群的搭建。外部内嵌的 producer 能够把本地刚刚落盘的数据间接同步到远端机房，时效性特地高。用户的体验是配置起来特地简略，用起来效率特地高，提早特地低，同时又可能提供很好的数据一致性的保障。所以，在很多的场景里有很丰盛的利用，包含腾讯外部、苏宁外部，很多用户都是因为繁多的场景而抉择了 Pulsar。

因为有了这些根底，Pulsar 在社区里的增长也是特地显著的。当初社区里有 403 contributors，github star 数靠近 9000。非常感激腾讯云有很多小伙伴对 Pulsar 做了很多很有用，很丰盛的场景测验。

Pulsar 诞生之初还是从音讯的畛域登程，咱们通过云跟整个生态做买通。明天跟大家探讨的次要集中在计算层上面的 Functions，在计算层做一个具体的开展。在咱们罕用的大数据计算外面，大略分为三种：交互式的查问，Presto 是一个比拟罕用的场景；再往下比方批处理、流解决，相应的 Spark、Flink 等都是用户罕用的，下面这两种，Pulsar 做的事件是提供对应 connector 的反对，让这些引擎可能了解 Pulsar 的 schema，间接把 Pulsar 一个主题当做一个表来读取和应用。Functions 的概念是我明天想跟大家重点开展的重点，它是一个轻量级的计算，跟下面简单的计算场景，齐全不是一个同样的概念。这个图可能比拟直观，外部相当于是把用户罕用的在音讯的场景外面要做的简略计算的场景形象进去，提供 Functions 的形象。Function 右边内嵌 consumer 会订阅产生的音讯，两头用户体检的函数提供计算，左边 producer 会把用户传进来的函数、计算的后果再写回到目标的 topic，通过这样一种模式，把用户罕用的两头须要创立、治理、调度正本数等信息作为对立的基础设施提供进去。

现场有同学问 topic 是什么概念？topic 跟音讯畛域比拟相干，是管道的形象，是一个载体，所有的数据都通过 topic 做一个缓存，producer 会产生音讯交给 topic。consumer 再依照生产的程序，用 topic 做生产，就是一个缓存的载体、管道。

Pulsar Functions 不是要再做简单的计算引擎，次要想把 Serverless 的理念跟音讯零碎做更好的联合，让 Pulsar 自身在音讯端、数据端就可能解决很多轻量级的数据。常见的场景，比方 ETL、aggregation 等很简略的场景，大略占到整个数据处理量的 60%—70%。特地是在 IoT 场景里会占到百分之八九十。对于这样一些简略的场景，通过简略的 Function Mesh 解决，不须要再构建简单的集群。简略的计算都能够在咱们的音讯端做完解决，这些资源能够节约下来，传输的资源、计算资源都能够失去很好的节约的利用。

给大家做一个简略的演示，Functions 对于用户来说是什么样的体验？这个函数须要解决的事件很简略，我对于一个 topic，用户扔进来的数据“hello”，对它增加一个感叹号。对于用户这样一个函数，无论什么语言，都能够在咱们的 Functions 外面有对应的运行时来做反对。在这个过程中，用户不须要学习任何新的逻辑，不须要学习新的 API，相熟什么语言就能够用什么语言做一个编写。编写完之后交给 Pulsar Functions，Functions 会订阅传进来所有的数据，依据这个数据做函数里相应的解决。

Functions 跟 Serverless 无关，大家的理念是一样的，跟音讯做很好的联合，用 Serverless 的形式解决音讯，解决计算。然而跟 Serverless 不太一样的中央是，跟数据的解决比拟相干，会有各种语义的反对。在 Pulsar Function 外部，也提供三种语义灵便的反对。

同时，在 Function Mesh 外部内嵌了状态的存储，把做两头计算的后果保留到 BookKeeper 自身。比方要做一个统计，用户传进来的是一个句子，会把句子分成多个分词，每个词能够统计它呈现的次数，这样一个次数的信息就能够记到 Pulsar 自身，这样的话能够通过简略的函数，实现要做的统计在 topic 外面呈现的次数，实时更新。同时，Pulsar 外部做了基于 REST 的 admin 接口，让用户更不便地应用、调度、治理 Pulsar Function。背地它其实是一个 REST API，能够通过本人的编程，间接调用接口，和用户利用做更好的集成。

简略地总结，Pulsar Functions 简略来说就是为你的利用中、生态中的各个小伙伴都提供比拟好的体验，比方对于你的开发者来说，它能够撑持各种各样的语言。咱们最近也在做 web 的反对。另外，能够撑持不同的模型，最简略的形式能够把它扔在 broker 上，同时 run 成 process 的模式。部署模式也很灵便，如果资源很无限，那就部署在 broker 上，让它跟 broker 一起运行。如果须要更好的隔离性，能够拿进去独自做一个集群，通过这个集群运行你的 Functions。在 Function Mesh 之前，咱们提供了很简略的 Kubernetes 的反对。

它给大家带来的益处，对于使用者来说，会更加容易，因为使用者可能都是大数据的专家，相熟各种语言，就能够依据本人相熟的语言来编写这套逻辑。它的操作也特地简略，因为原本做大数据的解决，很多须要 Pulsar。既然相熟 Pulsar，也能够跟 Pulsar 很好地做一个集成。有了 Pulsar，跟 broker 运行在一起，不必另外的 server。在咱们的开发和部署里，也提供了一个 local run 的模式，用户能够很不便地调试 Functions，对在整个计算的门路上各个使用者来说，Pulsar Functions 都提供了很好的体验和很丰盛的工具反对。

然而，尽管有 K8s 反对，但之前不是原生的反对。之前用户是怎么调用 Functions？Functions 能够和 broker 部署在一起，当初在每个 broker 有一个 Functions woker，对应 Functions 所有治理和运维的接口，用户提交 Functions 到 Functions worker，再把 Functions 一些源数据的信息保留到 Pulsar 外部的 topic 外面。在调度的时候通知 K8s 去 topic 外面拿源数据、有几个正本，从源数据外面读出来，而后起对应数据量 Functions 的实例。

这个过程有一些不敌对的中央。它的源数据自身是存储在 Pulsar 的 topic 外面，会带来一个问题，很多用户把 Functions woker 提起来，读 topic 自身的数据，获取源数据的信息，如果 topic 服务的 broker 没起来，会有一个循环 crush，等到真正服务 Functions worker 源数据的 broker 起来之后，才会起来。另外，这个过程中有两局部源数据的治理，第一局部提交到 Functions worker 里，保留在 Pulsar 自身，同时会调 Kubernetes，把源数据又交了一份，这样的话源数据管理就会比拟麻烦。一个很简略的例子，曾经把 Functions 交给 Kubernetes，两边没有互相协调的机制。第三，做扩容、动静治理、弹性伸缩，自身就是 Kubernetes 很大的劣势，如果再做一遍这样的事件，可能跟 Kubernetes 是反复的过程。

第二个问题，也是很多 Pulsar Functions 的用户提到的问题，Pulsar Functions 运行在 cluster 里，很多场景不限 cluster 外部，须要跨多个 cluster，这个时候交互会变得比较复杂。比方联邦学习的场景，用户心愿数据交给 Functions 帮着训练，再把模型写到集群里，然而有很多场景，联邦学习 Functions 训练的是 A 用户的数据，把训练的后果写到 B 用户里，这个时候须要跨集群的操作。之前的操作绑定在一个集群外部，很难做到 Functions 跨集群级别的共享。

还有一个问题是咱们过后做 Pulsar Functions 最间接、次要的起因，咱们发现用户不是解决简略的一个问题只用一个函数，有可能须要把多个 Function 做一个串联，心愿把多个函数多个 Function 作为一个整体，来做经营和管控。用之前的模式，会写很多这样的命令，而且每个命令的治理也会特地简单，而且命令订阅、输入的 topic，之间的关系很难掌控，不能做一个直观形容，治理和运维会特地麻烦。

Function Mesh 次要的目标不是做更简单的、全量的、对所有的计算都通用的框架，而是提供更好的治理，让用户更方便使用 function 的一个工具。比方刚刚提到的多个 Function 之间须要做串联，作为一个整体，给用户提供服务。所以，有了这样一个简略的需要，咱们在 2020 年 8、9 月份提了一点 proposal，想得很简略：心愿有一个对立的中央，来形容输出和输入的关系，这样一眼就可能看进去，第一个 Function 的输入就是第二个 Function 的输出，它们之间的逻辑就能够通过 yaml file 做很好的形容，用户一眼就晓得这两个 Function 之间组合的关系。

如果再把刚刚提到的逻辑和 K8s 做更好的整合，能够联合 Kubernetes 原本有的调度和弹性策略，为用户提供更好的治理和应用的体验。Pulsar Functions、Function Mesh 次要以 Kubernetes CRD 作为外围，把每一个 Function 的类型，比方咱们常见的 Function，还有 Source、Sink（相当于是 Function 的特例），把订阅的 topic 产生的数据输入到指定的中央，或者是从指定的源头 (比方从数据库里) 把数据输入，是 Function 的特例。

CRD 形容 Function 要起几个并发，要怎么运行，前后 topic 之间串联的关系。CRD 之外，会有 Function Mesh 的 controller，负责具体的调度和执行。这样对于用户的体验首先从最右边来说，用户交给 K8s 里边，帮你形容好了各个 Function 之间串联的关系，同时又形容了最大、最小的并发度，须要的一些资源的信息，都能够通过 yaml file 来形容。yaml file 交给 K8s 后，通过 API server 开始调度外部的资源，同时也会监控扭转，如果有 CRD 形容扭转了，那就会依据扭转再更改 pod 信息，就是扩缩 pod，pod 和 Pulsar cluster 的信息更加清晰，不保留任何的信息，它作为数据的源头，或者数据的进口，只是数据的管道，不会波及到所有元数据的治理。它的 feature 是刚刚提到的想要联合 K8s 给用户带来更好的体验，借助 K8s 能够很好地实现基于 CPU 的弹性扩缩容。

K8s 有弹性的调度，能够给 Function 的运维带来更好的体验。CRD 一旦扭转，能够依据 CRD 的形容，管制 pod 的增删改。也是通过这样一种模式，运行在 K8s 之上，和单个 pulsar 的 cluster 是齐全解耦的关系，通过这种模式，让多个 cluster 之间的 Function 共享和买通。

咱们最近在做一个工作，想要通过 Function Package Management 的工具，加重用户在操作相干的难度，应该在 2.8 的版本里跟大家见面。咱们做 Function Mesh 的初衷，次要还是不便用户应用 Pulsar Function，在这个根底之上，之前的接口通过 rest 接口做拜访，所以也做了往前的兼容。基于当初的 K8s，API 的实现，Function Admin 做了买通，用户能够通过之前的接口做管控。之前的老用户，如果不习惯间接提交 CRD、提供变更形式，也能够通过这种模式领有跟之前一样操作的体验。

前面是社区的状况。腾讯是 Pulsar 社区很重要的贡献者，之前在第一个很要害的业务场景里，提到了腾讯的计费平台，所有的业务通过 Pulsar 走一遍，包含微信的红包、腾讯游戏很多的计费。过后腾讯外部也调研了其余的零碎，最初做了一个这样的衡量，因为 Pulsar 有很好的一致性，有很好的数据的沉积和运维能力，特地是云原生的架构，可能加重大规模集群运维的痛点。

另外一个典型的场景，是在大数据场景里，须要用 Kafka，对 Kafka 来说，这是大集群用户很常见的问题，存储计算和绑定。之前有一篇文章介绍了一些案例做了一些总结，比方存储计算绑定带来运维的不不便，扩缩容会带来集群性能降落。Kafka 里有一个很头疼的问题是 reblance，一旦要扩容缩容，会主动触发 reblance，把 topic 从一个节点搬到另一个节点达到数据的再平衡。在这个过程中，搬数据可能会对线上业务带来肯定的影响，因为把集群之间的带宽或者网络带宽给占了，对外部业务可能响应不及时。呈现数据失落。mirror maker 性能和稳定性的问题等。其实最次要的问题还是咱们提到扩缩容的问题，Bigo 外部发现扩缩容极大耗费人力，也是因为这些起因，他们从 Kafka 的集群切换到 Pulsar 的集群，最近跟腾讯的小伙伴给 Pulsar 奉献的很重要的 feature，叫 KoP，在 server 端做 Kafka 协定的解析，通过这种形式，让用户失去零老本的迁徙。

这个图次要是想跟大家介绍用 Function 的一些用户。它的场景很多是轻量级的，特地是 IoT 场景下，比方 EMQ 是 Pulsar Function 很晚期的用户，之前的涂鸦智能、丰田智能等等都是 IoT 的场景，利用外面用了很多的 Functions。

社区的增长有一个值得关注的点，从 2019 年起增长变得更加疾速，这是开源社区很常见的景象，每一个开源社区背地都会有一个商业化公司。咱们公司是 2019 年成立的，商业化公司和之前开源 Pulsar 的雅虎的目标不太一样。雅虎的目标是心愿让更多的用户用 Pulsar，帮忙打磨，然而没有很强的能源保护社区，花更大的精力开发更多的 feature 吸引社区用户。但这是咱们商业公司的目标，依附社区做本人的商业化，做本人的成长。所以公司成立之后，咱们就会做很多开发者的沟通和协调，帮忙开发者更不便地应用 Pulsar，提供更多的性能来满足用户的需要。

最初是相干的社区信息，欢送想要理解更多信息的小伙伴，通过这些渠道，找到 Pulsar 更多的资源。这些资源包含在 B 站上有很多很丰盛的视频资源，其余的 Apache 罕用的邮件列表; slack 里有 4000 多位用户，中美大略各占一半。左边是保护的两个微信公众号，Pulsar 社区和咱们公司的，大家如果对 Pulsar 感兴趣或者对社区的工作机会感兴趣，也欢送扫码获取更多信息，这就是明天跟大家分享的次要内容，感激大家的工夫。

翟佳

StreamNative 联结创始人，腾讯云 TVP

StreamNative 联结创始人，腾讯云 TVP。在此之前任职于 EMC，负责北京 EMC 实时处理平台技术负责人。次要从事实时计算和分布式存储系统的相干开发，在开源我的项目 Apache BookKeeper, Apache Pulsar 等我的项目中继续奉献代码，是开源我的项目 Apache Pulsar 和 Apache BookKeeper 的 PMC 成员和 Committer。