导语
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」翟佳
一、Apache Pulsar 是什么？
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
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都提供了很好的体验和很丰盛的工具反对。
三、Function Mesh
然而，尽管有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走一遍，包含微信的红包、腾讯游戏很多的计费。过后腾讯外部也调研了其余的零碎，最初做了一个这样的衡量，因为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。
举荐浏览
- 初创企业的福音，还有这么贴心的云原生数据库？
- 用了 Serverless 这么久，这里有其底层技术的一点教训
- Serverless + 低代码，让技术小白也能成为全栈工程师？
- 左耳朵耗子：Serverless 到底是什么？
错过了直播懊悔不已？本次峰会所有嘉宾的演讲视频回顾上线啦，点击 链接 即可观看~
看视频不过瘾还想要干货PPT？扫描二维码 ↓，关注公众号，在后盾回复关键词「serverless」即可获取！