编者荐语：
云原生的诞生是为了解决传统利用在架构、故障解决、零碎迭代等方面的问题，而开源则为企业打造云原生的架构奉献了中坚力量。本文作者在全身心投入开源以及每日参加云原生的过程中，对开源行业和云原生流零碎解决方案有了不一样的思考与实际。
以下文章来源于 CSDN，作者李鹏辉
本文出自《新程序员·云原生和全面数字化实际》。作者李鹏辉，Apache Pulsar PMC 成员，StreamNative 首席工程师。责编 CSDN 唐小引。
随着业务与环境的变动，云原生的趋势越来越显著。当初正是企业从云计算向云原生转型的时代，云原生理念通过几年落地实际的打磨曾经失去了企业的宽泛认可，云上利用治理更是成为企业数字化转型的必选项。能够说，当初的开发者，或正在应用基于云原生技术架构衍生的产品和工具，或正是这些产品和工具的开发者。
云原生成为根底策略
那么，什么是云原生？每个人都有不同的解释。我认为，首先，云原生就是为了在云上运行而开发的利用，是对于企业继续疾速、牢靠、规模化地交付业务的解决方案。云原生的几个关键词，如容器化、继续交付、DevOps、微服务等无一不是在诠释其作为解决方案的个性与能力，而 Kubernetes 更以其开创性的申明式 API 和调节器模式，奠定了云原生的根底。
其次，云原生是一种策略。云原生的诞生是为了解决传统利用在架构、故障解决、零碎迭代等方面存在的问题。从传统利用到云，与其说是一次技术升级，不如说将其视为策略转型。企业上云面临利用开发、零碎架构、企业组织架构，甚至商业产品的全面整合，是否退出云原生大潮一次是将从方方面面影响企业长期倒退的战略性决策。
搭配开源底色的云原生
近几年诞生的与架构相干的开源我的项目大部分采纳云原生架构设计，开源为企业打造云原生的架构奉献了中坚力量。
开源技术与生态值得信赖，云能够给用户带来好的伸缩性，升高资源节约。云原生和开源的关系也能够从以 CNCF 为主的开源基金会继续推动云原生的倒退中略窥一二。许多开源我的项目自身就是为云原生架构而生的，这是用户上云会优先思考的根底软件特点。
以 Apache 软件基金会为例，它是一个中立的开源软件孵化和治理平台。Apache 软件基金会在长期的开源治理中，总结出的 Apache 之道（Apache Way）被大家奉为圭臬，其中“社区大于代码”广为流传，即没有社区的我的项目是难以短暂的。一个社区和代码放弃高活跃度的开源我的项目，通过全世界开发者在多种场景的打磨，能够不断完善、频繁地降级迭代，并诞生丰盛的生态以满足不同的用户需要。云原生大潮与以后开源大环境两种因素叠加，就会使那些随同技术环境一直降级的优良技术新陈代谢、怀才不遇，不适应时代的技术会慢慢落后，甚至被淘汰。正如我之前所说，云原生是战略性决策，企业的战略性决策必定会首选最先进、最牢靠的技术。
为云而生的音讯流数据系统
前文讲述了云原生环境下开源的重要性，那么一个云原生的开源我的项目须要如何去设计、布局和演进？云原生时代的企业数字化转型应如何抉择音讯和流零碎？在本文中，我将以本人全身心投入的开源云原生音讯和流数据系统 Apache Pulsar 的设计和布局为例进行分析。心愿可能为大家提供参考思路，并为寻求音讯和流数据系统解决方案带来启发。
回顾历史：音讯与流的双轨制
音讯队列通常用于构建外围业务应用程序服务，流则通常用于构建包含数据管道等在内的实时数据服务。音讯队列领有比流更长的历史，也就是开发者们所相熟的消息中间件，它偏重在通信行业，常见的零碎有 RabbitMQ 和 ActiveMQ。相对来说，流零碎是一个新概念，多用于挪动和解决大量数据的场景，如日志数据、点击事件等经营数据就是以流的模式展现的，常见的流零碎有 Apache Kafka 和 AWS Kinesis。
因为之前的技术起因，人们把音讯和流分为两种模型别离看待。企业须要搭建多种不同的零碎来反对这两种业务场景（见图 1），由此造成基础架构存在大量“双轨制”景象，导致数据隔离、数据孤岛，数据无奈造成顺畅流转，治理难度大大晋升，架构复杂度和运维老本也都居高不下。
图 1 企业搭建不同的零碎反对业务场景导致的“双轨制”
基于此，咱们亟须一个集成音讯队列和流语义的对立实时数据基础设施，Apache Pulsar 由此而生。音讯在 Apache Pulsar 主题上存储一次，但能够通过不同订阅模型，以不同的形式进行生产（见图 2），这样就解决了传统音讯和流“双轨制”造成的大量问题。
图 2 Apache Pulsar 集成音讯队列与流语义
实现人造云原生的要害因素
上文提到，云原生时代带给开发者的是可能疾速扩缩容、升高资源节约，减速业务推动落地。有了相似 Apache Pulsar 这种人造云原生的音讯和流数据基础设施，开发者能够更好地聚焦在应用程序和微服务开发，而不是把工夫节约在保护简单的根底零碎上。
为什么说 Apache Puslar 是“人造云原生”？这与在当初设计原型的底层架构无关。存储计算拆散、分层分片的云原生架构，极大地加重了用户在音讯零碎中遇到的扩大和运维艰难，能在云平台以更低成本给用户提供优质服务，可能很好地满足云原生时代音讯零碎和流数据系统的需要。
生物学有一个论断，叫“构造与性能相适应”。从单细胞原生生物到哺乳动物，其生命构造越来越简单，具备的性能也越来越高级。根底零碎同理，“架构与性能相实用”体现在 Apache Pulsar 上有这样几点：
- 存储计算拆散架构可保障高可扩展性，能够充分发挥云的弹性劣势。
- 跨地区复制，能够满足跨云数据多备的需要。
- 分层存储，可充分利用如 AWS S3 等的云原生存储，无效升高数据存储老本。
- 轻量化函数计算框架 Pulsar Functions，相似于 AWS Lambda 平台，将 FaaS 引入 Pulsar。而 Function Mesh 是一种 Kubernetes Operator，助力用户在 Kubernetes 中原生应用 Pulsar Functions 和连接器，充分发挥 Kubernetes 资源分配、弹性伸缩、灵便调度等个性。
基础架构：存储计算拆散、分层分片
上文说到，Pulsar 在诞生之初就采纳了云原生的设计，即存储计算拆散的架构，存储层基于 Apache 软件基金会开源我的项目 BookKeeper。BookKeeper 是一个高一致性、分布式只追加（Append-only）的日志形象，与音讯零碎和流数据场景相似，新的音讯一直追加，刚好利用于音讯和流数据畛域。
Pulsar 架构中数据服务和数据存储是独自的两层（见图 3），数据服务层由无状态的 Broker 节点组成，数据存储层则由 Bookie 节点组成，服务层和存储层的每个节点对等。Broker 仅负责音讯的服务反对，不存储数据，这为服务层和存储层提供了独立的扩缩容能力和高可用能力，大幅缩小了服务不可用工夫。BookKeeper 中的对等存储节点，能够保障多个备份被并发拜访，也保障了即便存储中只有一份数据可用，也能够对外提供服务。
图 3 Pulsar 架构
在这种分层架构中，服务层和存储层都可能独立扩大，提供灵便的弹性扩容，特地是在弹性环境（如云和容器）中能主动扩缩容，动静适应流量峰值。同时，显著升高集群扩大和降级的复杂性，进步零碎的可用性和可管理性。此外，这种设计对容器也十分敌对。
Pulsar 将主题分区依照更小的分片粒度来存储（见图 4）。这些分片被平均打散，将会散布在存储层的 Bookie 节点上。这种以分片为核心的数据存储形式，将主题分区作为一个逻辑概念，分为多个较小的分片，并均匀分布和存储在存储层中。这样的设计能够带来更好的性能、更灵便的扩展性和更高的可用性。
图 4 分片存储模型
从图 5 可见，相比大多数音讯队列或流零碎（包含 Apache Kafka）均采纳单体架构，其音讯解决和音讯长久化（如果提供了的话）都在集群内的同一个节点上。此类架构设计适宜在小型环境部署，当大规模应用时，传统音讯队列或流零碎就会面临性能、可伸缩性和灵活性方面的问题。随着网络带宽的晋升、存储提早的显著升高，存储计算拆散的架构劣势变得更加显著。
图 5 传统单体架构 vs 存储计算分层架构
读写区别
接着上述内容，咱们来看一下音讯的写入、读取等方面的区别体现在哪里。
首先看写入。图 6 左侧是单体架构的利用，数据写入 leader，leader 将数据复制到其余 follower，这是典型的存储计算不拆散的架构设计。在图 6 右侧则是存储计算拆散的利用，数据写入 Broker，Broker 并行地往多个存储节点上写。如果要求 3 个正本，在抉择强一致性、低提早时两个正本返回才算胜利。如果 Broker 有 leader 的角色，就会受限于 leader 所在机器的资源状况，因为 leader 返回，咱们能力确认音讯胜利写入。
图 6 单体架构与分层架构写入比照
在右侧对等的分层架构中，三个中任意两个节点在写入后返回即为胜利写入。咱们在 AWS 上进行性能测试时发现，两种构造在刷盘时的提早也会有几毫秒的差距：在单机零碎中落在 leader 上的 topic 会有提早，而在分层架构中受到提早影响较小。
在实时数据处理中，实时读取占据了 90% 的场景（见图 7）。在分层架构中，实时读取能够间接通过 Broker 的 topic 尾部缓存进行，不须要接触存储节点，可能在很大水平上晋升数据读取的效率和实时性。
图 7 单体架构与分层架构读取实时数据比照
架构也导致了读取历史数据时的区别。从图 8 可见，在单体架构中，回放音讯时间接找到 leader，从磁盘上读取音讯。在存储计算拆散的架构上，须要将数据加载到 Broker 再返回客户端，以此保证数据读取的程序性。当读取数据对程序性没有严格要求时，Apache Pulsar 反对同时并行从多个存储节点读取数据段，即便是读取一个 topic 的数据也能够利用多台存储节点的资源晋升读取的吞吐量，Pulsar SQL 也是利用这种形式来读取的。
图 8 单体架构与分层架构读取历史数据比照
IO 隔离
BookKeeper 外部做了很好的数据写入和读取的 IO 隔离。BookKeeper 能够指定两类存储设备，图 9 左侧是 Journal 盘寄存 writeheadlog，右侧才是真正存储数据的中央。即便在读取历史数据时，也会尽可能地保障写入的提早不会受到影响。
图 9 BookKeeper 的 IO 隔离
如果利用云平台的资源，Pulsar 的 IO 隔离能够让用户抉择不同的资源类型。因为 Journal 盘并不需要寄存大量的数据，很多云用户会依据本人的需要配置来达到低成本、高服务质量的目标，如 Journal 盘应用低存储空间、高吞吐低提早的资源，数据盘抉择对应吞吐能够寄存大量数据的设施。
扩缩容
存储计算拆散容许 Broker 和 BookKeeper 别离进行扩缩容，上面为大家介绍扩缩容 topic 的过程。假如 n 个 topic 散布在不同的 Broker 上，新的 Broker 退出可能在 1s 内进行 topic ownership 的转移，可视为无状态的 topic 组的转移。这样，局部 topic 能够疾速地转移至新的 Broker。
对于存储节点来说，多个数据分片分布在不同的 BookKeeper 节点上，扩容时即新退出一个 BookKeeper，并且这种行为不会导致历史数据的复制。每一个 topic 在经验一段时间的数据写入后，会进行分片切换，即切换到下一个数据分片。在切换时会从新抉择 Bookies 搁置数据，由此达到逐步均衡。如果有 BookKeeper 节点挂掉，BookKeeper 会主动补齐正本数，在此过程中，topic 不会受到影响。
跨云数据多备
Pulsar 反对跨云数据多备（见图 10），容许组成跨机房集群来进行数据的双向同步。很多国外用户在不同的云厂商部署跨星散群，当有一个集群呈现问题时，能够疾速切换到另外的集群。异步复制只会产生轻微的数据同步缺口，但能够取得更高的服务质量，同时订阅的状态也能够在集群间同步。
图 10 跨云数据多备
进入无服务器架构时代
Pulsar Functions 与 Function Mesh 让 Pulsar 跨入了无服务器架构时代。Pulsar Functions 是一个轻量级的计算框架，次要是为了提供一个部署和运维都能非常简单的平台。Pulsar Functions 主打轻量、简略，可用于解决简略的 ETL 作业（提取、转化、加载）、实时聚合、事件路由等，根本能够笼罩 90% 以上的流解决场景。Pulsar Functions 借鉴了无服务器架构（Serverless）和函数即服务（FaaS）理念，能够让数据失去“就近”解决，让价值失去即时开掘（见图 11）。
图 11 单条 Pulsar Function 音讯流转
Pulsar Functions 只是单个利用函数，为了让多个函数关联在一起，组合实现数据处理指标，诞生了 Function Mesh（已开源）。Function Mesh 同样采纳无服务器架构，它也是一种 Kubernetes Operator，有了它，开发者就能够在 Kubernetes 上原生应用 Pulsar Functions 和各种 Pulsar 连接器，充分发挥 Kubernetes 资源分配、弹性伸缩、灵便调度等个性。例如，Function Mesh 依赖 Kubernetes 的调度能力，确保 Functions 的故障恢复能力，并且能够在任意工夫适当调度 Functions。
Function Mesh 次要由 Kubernetes Operator 和 Function Runner 两个组件组成。Kubernetes Operator 监测 Function Mesh CRD、创立 Kubernetes 资源（即 StatefulSet），从而在 Kubernetes 运行 Function、连接器和 Mesh。Function Runner 负责调用 Function 和连接器逻辑，解决从输出流中接管的事件，并将处理结果发送到输入流。目前，Function Runner 基于 Pulsar Functions Runner 实现。
当用户创立 Function Mesh CRD 时（见图 12），Function Mesh 控制器从 Kubernetes API 服务器接管已提交的 CRD，而后解决 CRD 并生成相应的 Kubernetes 资源。例如，Function Mesh 控制器在解决 Function CRD 时，会创立 StatefulSet，它的每个 Pod 都会启动一个 Runner 来调用对应的 Function。
图 12 Function Mesh 解决 CRD 过程
Function Mesh API 基于现有 Kubernetes API 实现，因而 Function Mesh 资源与其余 Kubernetes 原生资源兼容，集群管理员能够应用现有 Kubernetes 工具治理 Function Mesh 资源。Function Mesh 采纳 Kubernetes Custom Resource Definition（CRD），集群管理员能够通过 CRD 自定义资源，开发事件流应用程序。
用户能够应用 kubectl CLI 工具将 CRD 间接提交到 Kubernetes 集群，而无须应用 pulsar-admin CLI 工具向 Pulsar 集群发送 Function 申请。Function Mesh 控制器监测 CRD 并创立 Kubernetes 资源，运行自定义的 Function、Source、Sink 或 Mesh。这种办法的劣势在于 Kubernetes 间接存储并治理 Function 元数据和运行状态，从而防止在 Pulsar 现有计划中可能存在的元数据与运行状态不统一的问题。
结语
在本文中，我分享了本人在云原生环境下，对于开源行业的思考和云原生流平台解决方案的技术实际。作为一名全身心投入的开源人，我很快乐看到近几年有越来越多的人认可开源理念并成为开源开发者与贡献者，开源行业正在蓬勃发展。我心愿能和有数的开发者一样，在开源路线上裹足不前，助力更多企业减速云原生和数字化过程。
作者简介
李鹏辉：Apache 软件基金会顶级我的项目 Apache Pulsar PMC 成员和 Committer，目前就任于 StreamNative 公司负责首席架构师。长期以来，其工作畛域都与音讯零碎、微服务和 Apache Pulsar 非亲非故，曾于 2019 年推动 Pulsar 在智联招聘的落地，构建外部对立音讯服务，之后退出 Apache Pulsar 商业化公司 StreamNative，实现个人身份从一名开源我的项目用户到开源我的项目开发者的转变。他和他的团队在 StreamNative 负责反对海量规模音讯场景用户落地 Apache Pulsar。
关注公众号「Apache Pulsar」，获取干货与动静
退出 Apache Pulsar 中文交换群 👇🏻