apacheeventphp技巧_深度解读分布式应用提效框架 Apache EventMesh

在 2021 年 11 月 12 日落地的 ArchSummit 环球架构师峰会（深圳站）上，我们约请了微众银行的资深技能专家陈广胜为大家带来了《分布式运用提效框架 Apache EventMesh》的分享，他从 EventMesh 的特色入手，为大家深入先容了 EventMesh 在微众银行的探索与实践。
本文为演讲整理文章~

本日禀享 Apache EventMesh 事宜驱动的分布式运用运行时，这是一个比较新的观点，希望可以通过本次的分享，给大家带来一些启示。

我们都理解两个观点——和事宜，指的是详细事宜的更新，这种更新是从一个点发送到其余一个点之后，就会被删除，是临时存在的状态；而事宜是指在特定时间发生的，它并没有绑定到详细的吸收者或客户端，它每每是可以被回放、回溯和再加工。

根据 Gartner 的一份报告显示，随着韶光的推移，数据的代价将逐渐减少。
在很多实时场景下，如果能够对事宜进行实时的剖析和数据挖掘，那将会带来很大的代价，像现在非常火的流式打算 Flink、Spark 以及 ClickHouse 等，他们都非常关注数据的实时性，EventMesh 可以及时地通报数据。

我们先来理解 EventMesh 架构图，EventMesh 的定位是事宜驱动分布式运用运行时。
EventMesh 可以供应非常轻量级、多措辞的客户端以及各种各样的协议，例如 MQTT、Cloudevents、Web Socket 和 MQP，与此同时，它可以供应 gRPC、TCP 和 HTTP 等传输的协议。

EventMesh Runtime 是一个插件化的架构，可以对接到后真个中间件或者做事，比如事宜的存储 RocketMQ、Kafaka 以 及 Apache Pulsar 等；如果须要有一些状态更新掩护的时候，可以对接到后真个 Redis、MySQL 以及 Mongo DB 等；如果须要有一些冷数据更新的时候，也是可以通过插件化的形式连接到 S3，ES 等存储。

在掌握层面，如果须要对事宜的调用链进行跟踪、元数据进行管理以及分布式折衷性的时候，EventMesh Runtime 也可以对接到 ETCD、NACOS、 Prometheus、Zipkin、Skywalking

、OpenTelemetry 等。
我们内部最常用的是 RocketMQ 以及 Redis 两个插件，不过 EventMesh 也可以很方便地与 Kubernetes 进行集成，这是由于 EventMesh Runtime 可以作为 Sidecar 支配，也可以作为 Gateway 支配。

我们再看一下当前在微做事领域的 REST Drive 和 Event Drive，他们各自的优缺陷非常明显。
就 Spring Cloud、HTTP2、gRPC 通信而言，当 REST 调用做事的时候，由于工业界非常完善的工具文档以及开拓工具客户端，开拓起来非常方便，但是 REST Drive 的所有调用都是同步的，同步则意味着壅塞。
如果在一个链中，任何节点的做事涌现缓慢调用或故障，那么便会影响到最前真个做事调用，那么当 Spring Cloud 与 Dubbo 做事建立通信的时候，须要付出更多的本钱。

然而在事宜驱动领域，当接入网关或进行业务层面的框架层适配的时候，它的调用是异步的，所有的状态是终极同等的，并且可以与很多的做事以及中间层解耦。
其余像 Queue 订阅发布办法，扩容非常方便。
但是它须要依赖一层中间件，中间件的繁芜度须要人工处理，不过这层繁芜度可以利用 EventMesh 屏蔽掉，以是对运用的开拓本身而言，轻量又便捷。

接下来分享一下 SeviceMesh vs EventMesh 的差异。

SeviceMesh 须要 Sidecar，所有数据层面的通信是在 Sidecar 之间的转发，不过在 EventMesh 中，我们看到单个或多个做事可以挂在 EventMesh 的单个节点，EventMesh 具备较强的微做事编排能力，但是 EventMesh 并不能办理所有的问题，它的上风在于事宜驱动，它也可以做到 Request、Reply。

做事有同步和异步之分，同步调用可以采取 SeviceMesh，异步调用可以采取 EventMesh 。
当然 EventMesh 也可以做同步调用，SeviceMes 也可以做异步调用，但是两者本身的定位以及处理的场景不一样，以是 SeviceMesh 与 EventMesh 可以结合利用。

例如，前端 Web App 通过 API 网关进来的调用，转发到前置或某个业务领域的做事，它会进行内部做事之间的调用，这个过程便会产生数据，数据会进入到关系型数据库或者 NoSQL 数据库。
但是入数据库的这一动作，可能须要让其他的做事订阅或关注到，这个时候，我们可以将事宜或者做事转发给 EventMesh，让 EventMesh 驱动关心这些事宜的做事进行后续事情。

接着，我们一起看看 EventMesh 的浸染。

在 DMZ 区或 ECN 区域，支配网关或者前置做事的浸染是为了进行协议的转换——从外部的 HTTP 或 HTTPS 接口协议的做事，转换到内部门歧的做事框架（例如 Dubbo、Spring Cloud）的协议。
当外部、公网或者互助方流量进入此区域的时候，内部区域将会形成非常繁芜网状的构造，边界区流量管理非常未便利。

现在的通用做法是在边界支配网关，但是当有了 EventMesh 之后，我们只须要在外联区和内部区域支配两个 EventMesh（可以是集群，也可以是节点），这样边界区的做事只须要在 EventMesh 之间进行通讯，而且当要求到了内部做事的时候，通过内部区域的 EventMesh 可以形成很多网格，每一个 EventMesh 网格代理了向其注册的做事。
不同的 EventMesh 以及其代理的做事连接起来，形成较大的事宜网格，很多繁芜调用场景的管理将会变得极其大略。

这一部分我将会先容几个主要的 EventMesh Feature。

现在有非常多各种云以及私有支配环境下的做事，做事与做事之间的连接可以通过 EventMesh 来完成。
不同的区域的做事，利用的协议和措辞不一样，但是通过 Pub/Sub+的形式增加的任何协议、节点、做事，都可以统一汇聚到 EventMesh 形成的网格中。

举个例子，昔时夜家在亚马逊云上发布事宜之后，私有化支配 Kubernetes 的某做事节点订阅了这个，可以超过很多节点路由到 Kubernetes 做事。
同时，当多个区域的做事订阅了相同的主题，只要将发送到对应的主题，对应的做事会自动将吸收下来。
EventMesh 可以办理连接协议的多样性、措辞的多样性，并且可以办理边界区的连接问题。

事宜驱动架构（EDA）是一种以事宜为纽带，将不同系统进行解耦的异步架构设计模型。
在 EDA 中，事宜驱动的运行流程天然地划分了各个别系的业务语义，用户可以根据需求对事宜与针对此事宜做出的相应灵巧定制，这使得基于 EDA 架构可以方便地构建出高伸缩性的运用。

HTTP Source 事宜源是 EventMesh 支持的事宜源的一种，它以 Webhook 形式暴露了发布事宜的 HTTP 要求地址，用户可以在有 URL 回调的场景配置 HTTP Source 事宜源，或者直策应用最大略的 HTTP 客户端来完成事宜的发布。
HTTP Source 事宜源供应了支持 HTTP 与 HTTPS，公有云 VPC 平分歧要求办法、不同网络环境的 Webhook URL，便于用户将其集成到各种运用中。
接入时无需利用客户端，仅需担保运用可以访问到对应 Webhook URL 即可，这使得接入过程变得大略而高效。

在将 HTTP 要求转换为 CloudEvent 的时候，EventMesh 会将要求的头部和体部分置于 CloudEvents 字段中，别的字段会依据用户 EventMesh 资源属性以及系统默认规则进行添补。
用户可以在事宜规则中，对所需的内容进行过滤、提取，终极按照模板拼装成所需的内容投递给事宜目标。

在当前的微做事下，当我们进行流量调度的时候，肯定须要解船埠，根据头的特定字段，路由到对应的做事上以便增加策略。

实际上在事宜驱动中，首先我们不须要解码报文，我们在它的主题设计上，可以办理类似的问题。
比如可以设计非常多 Topic 层级，层级与层级之间有递进关系，以此来实现动态的过滤。
其次，当到达之后，可以很方便地针对进行报文解析，在产生的事宜上面，我们可以增加非常多的 Match 处理函数，产生的可以实时地经由 filter chain 的处理。
事宜的处理都可以由 EventMesh 来完成。

在上图的左边区域，当写入繁芜的 Case、If else 条件或引入事情流之后，它的编排有很多串行的分支，但是如果采取 EventMesh 编排，看起来将会非常简洁。

我们只须要订阅感兴趣的事宜，发送对应的事宜到对方主题上就可以，我们并不须要关注对方 IP 的所在地，也不须要关注做事支配在虚拟机还是在容器上，以及对方做事实例数量，当然更不须要关注对方实例挂了之后，我们是否须要进行熔断等等。
下贱的 EventMesh 可以完成所有的事情，例如，当它下贱的做事发生故障，将会自动分发到当前在线的做事实例。
从上面这张图，大家可以看出，采取 EventMesh 可以使得编排与折衷过程更加清晰。

接下来是扩缩容场景，当现有的 Kubernetes 在进行扩缩容的时候，有两个常见的场景。

首先是扩容场景，例如，在当前的 CPU 占用很高的时候，正常情形会触发扩容事宜，但我们在行列步队中，并没有看到特殊多的堆积，也便是说，这个时候并不须要扩容，实际上这个扩容是摧残浪费蹂躏的；其次是缩容场景，例如在行列步队里，当前没有堆积，理论上实例是可以缩容，乃至可以缩容到零，但是由于 CPU 的利用导致无法顺利缩容。

但是这两种场景，如果在事宜驱动的做事下，我们采取 Queue 行列步队堆积的监控办法可以实现以下效果。
首先是在资源占用很高，但行列步队的任务没有堆积的情形下，可以不进行扩容；其次，在占用当前的 CPU 的资源，但没有任务处理的情形下，可以进行缩容。
在我看来，伸缩监控的指标该当根据当前处理的任务堆积情形来判断。

没有管理前，就如下图一样，各个不同区域之间形成了数据的孤岛。

但当管理之后，就变成了下图一样的这样网格状态，清晰且简洁。

在过去十年的大部分韶光里，企业都在与数据孤岛作斗争，数据孤岛是伶仃的持久性存储，拥有无数但无法访问的知识，他们的紧张武器是数据湖：一个巨大的集中式数据存储，将 TB 级的特定于域的数据保存在一个逻辑位置。
没有领域知识的数据专​家试图从不同的数据集中挖掘数据代价是很困难的，而且险些没有动力向数据湖贡献高质量数据的数据生产者。

EventMesh 具备实时剖析、大规模数据网络、平台无关的连接以及对开放标准的支持等能力，空想情形下，对客户数据的任何变动都应通过事宜网格之类的东西实时推送给依赖的消费者，但如果数据不太主要或不及时，数据消费者可以在须要时提取（或查询）数据。

我们正在从数据无政府状态过渡到联合管理和成熟的企业数据策略——空想情形下，可以将策略有效地表示为代码的终极状态。
联合管理须要特定于任务的工具、事宜目录和 AsyncAPI 等标准。
企业级数据策略还包括访问掌握、法规（即 GDPR）、机密性（如 PII 和 PHI）、编辑和加密等特性/功能。
功能的示例可能包括逼迫性标头元数据（将数据高下文化）、可不雅观察性哀求、主题构造（用于路由）以及通过模式验证和其他工具实现的数据质量。

在微众银行，已经开源的总线 DeFiBus 如上图所示，这里以三个 EventMesh 的节点为例，每一个 EventMesh 节点，可以在其上面订阅做事。
当发送方发布一个事宜之后，其他的 EventMesh 上的任何做事，只要订阅了 Topic，这个事宜便可以发送到对应的做事上，它能够自动地学习和更新路由表。

EventMesh 在微众银行内部办理了以下问题，首先是多措辞管理问题，例如 AI 打算利用 Python、很多银行的系统利用 C 措辞，EventMesh 能够简化接入总线的繁芜度，同时我们知道，推动业务的 SDK 的升级非常麻烦，当 SDK 轻量简化之后，我们只须要卖力中间件层的发布，就可以节省掉运用推动升级的本钱。
除了运用在业务系统外，EventMesh 还运用在流量复制回放平台，旁途经滤，多活路由，AI 联邦学习，区块链等场景，更多的场景在持续探索实践过程中，未来有机会再分享给大家。

本日的 IT 系统正在天生、网络和处理比以往更多的数据。
而且，他们正在处理高度繁芜的流程（正在自动化）以及超过范例组织边界的系统和设备之间的集成。
同时，估量 IT 系统的开拓速率更快、本钱更低，同时还具有高可用性、可扩展性和弹性。
为了实现这些目标，开拓职员正在采取架构风格和编程范式，例如微做事、事宜驱动架构、DevOps 等。
正在构建新的工具和框架来帮助开拓职员实现这些期望。
开拓职员正在结合事宜驱动架构 (EDA) 和微做事架构风格来构建具有极强可扩展性、可用、容错、并发且易于开拓和掩护的系统。

EventMesh 作为事宜根本举动步伐，紧张卖力事宜的传输、路由和序列化。
它可以供应用于处理事宜流的 API。
事宜根本举动步伐供应对多种序列化格式的支持，并对架构质量（例如容错、弹性可伸缩性、吞吐量等）产生重大影响，也可以存储事宜以创建事宜存储，事宜存储是规复和弹性的关键架构模式。

理解更多软件开拓与干系领域知识，点击访问 InfoQ 官网：https://www.infoq.cn/，获取更多精彩内容！