背景和目的 are interchangeable terms and can be translated as “background and objective” or “background and purpose” in Chinese.

去年12月，我读了O’Reilly出版的《大数据管理》（日语版）。本页面将对第5章进行总结。

总结

整理词汇

在本页面中，我们使用以下术语。

第五章：事件与响应的管理：流媒体架构

这个章节将解释流媒体架构。

流媒体架构

流媒体架构是指连续实时处理和分析从各种来源生成的数据的方法。
（流媒体架构这个名称来源于流媒体数据和事件流处理。）

该应用程序和系统通过与事件的互动和对事件的响应来重点实现非同步连接。实时流数据带来了以下业务竞争优势：

• より素早い対応により顧客満足度を高める。

• 不正行為判定

Webのカスタマーエクスペリエンス改善

非同步事件模型帶來的東西

在应用程序和综合平台中，将事件和消息发送到队列中，等待其他系统获取它。通过松耦合，消除了依赖关系。借助这种异步通信，使得可扩展架构具备弹性。

事件驱动架构（event-driven architecture）的定义是

指的是以事件驱动为中心而不是以服务驱动为中心的架构。事件指的是“状态的变化”，例如，以下内容：

• 新規顧客の登録・注文

飛行機の着陸

每次事件发生时，都会生成一条消息并传送到消息平台。每个消息都包含与事件相关的数据。
有两种不同的设计思想，即「中介者拓扑」和「代理者拓扑」的参考模型。

中文：调解器拓扑结构

在进行事件处理时，如果需要一定程度的中央控制和调整，则会在架构设计中使用。

• 一般的には、メディエーターとメッセージキューで構成されます。

• 受信したトピックやチャネルごとにイベントコンシューマに一度だけ配信され処理されます。

• 一度だけ処理されることを保証するため、コンシューマーで受信したあとにメッセージは削除orフラグが立てられます。

• ソフトウェアアーキテクチャ実装には、下記が利用できます。

ESB（Enterprise Service Bus）
Apache Camel
Spring Integration

经纪网络

与传统的中央调解者不同，中央的中介者不存在这一点是中介拓扑的特殊之处。

• イベントは軽量なメッセージブローカーにブロードキャストされる。

• イベントの流れが比較的単純＆中央でのオーケストレーションが不要な場合にこのモデルが使用できる。

• 不正検知のように、複数のシステムに一度に通知する場合、同じメッセージを複数のイベントコンシューマーに配信するときに便利とのこと。

• イベント処理は比較的単純＆中央でのイベントオーケストレーションや調整が必要ないのでスケーラブル。

• ソフトウェアアーキテクチャ実装には、下記が利用できます。

Apache Kafka
RabbitMQ
ActiveMQ

事件处理风格

对于EDA（事件驱动架构）拓扑模型来说，存在着用于事件处理的不同风格。这些风格的选择取决于事件的复杂性和已实施的用例，通常会将多种风格结合在一起。

流媒体架构

事件流是一种能够构建实时应用程序、实时转换传输数据、并向其他应用程序和系统提供数据的技术。
事件的响应能力、分布式功能和应用程序数据库的传输功能是流媒体架构中必不可少的要素，其中包括以下内容。

• イベントプロデューサー

• イベントコンシューマー

イベントプラットフォーム

活动制作人

被称为事件提供者，它需要添加组件来从数据源收集数据、进行消息格式转换、过滤和聚合，以及进行协议转换。以下是可选的方法和选择。

• フロントエンドとユーザインターフェイスイベント。Webページの閲覧、商品をカートに入れるなど

• アプリケーションイベント。JavaなどのCRMアプリケーションなどでKafkaにデータをプッシュする

アプリケーションデータベースの読み出し。ストレージ層を読み出すことでDBに加えられrた変更をキャプチャしてイベントを発生させる。CDCなど

事件消费者

在使用事件消费者时，变化取决于用例的需求和选择哪种技术。最简单的用例是通过使用消息代理将事件提供者和事件消费者分离。

活动平台

管理事件提供者和事件消费者之间的相互操作。基本操作是接收消息并发送给多个消费者。
有多种方法来设计EDA的核心功能。

• データの保存

RESTインターフェイスを持つような最新のデータベース

データ統合、分析

マイクロサービス
Apache Flink
Apache NiFi
Apache Spark
Active MQ
ZeroMQ
RabbitMQ
Apache Kafka

在公共云中可以使用以下内容。

• AWS

DynamoDB
SQS
Kinesis

Azure

Event Grid
Event Hubs
Service Bus
CosmosDB
Queue Storage

Google

Dataflow
Apache Beam

通过使用上述类似的平台和工具作为EDA的支撑，可以实现以下内容：

• イベントの流通・保存

アプリケーションとの履歴を保持

通过这个，可以实现一些高级模式。

• イベント駆動型サービスコレオグラフィ

プロセスの更新、コマンドを非同期で流通させて複数のアプリケーションが対応できるようにするもの

保持期間を高めに設定することで、イベントソーシングとコマンドソーシングという2つのパターンが使える。

事件溯源和命令溯源

事件溯源是指一种软件开发方法，其中事件被视为系统中的关键数据，并通过记录和追踪事件的发生和处理来构建应用程序的状态。

应用程序状态和数据库更改将以全部不可变的日志或附加数据存储的形式保存为一个连续的事件。以下是其中的一些优点。
应用程序的状态和数据库的变化都将保存在一个不可变的日志或追加数据存储中，作为一系列事件的记录。以下是其中的一些优点：

• 変更しないので、監査証跡が残る。

• 全てのイベントを時系列で詳しく確認できる

• 過去の任意の時点の状態に復旧可能

• イベントの巻き戻し、再生、操作が可能

• イベントを集約し、具体化できる

• CQRSを実現する際に、イベントソースのマテリアライズドビューを構築するときにも利用できる

• 複数の分散読み出し専用データストアを構築できる。

他のドメインとの調整を気にしない、イベントをSubscribeするアプリから分離される。

指令外包是什么意思？

通过拦截命令，它能够以与事件溯源相反的方式运行。
在命令发出系统的API之前，首先将其推送到队列或主题中。从这里进行溯源，并最终传递到目标系统中。
通过将所有命令永久化，可以在出现问题时进行处理。

治理模型

在同一个集群中，推荐将私人通信和公共通信分离，以防止来自其他域的消费者捕获其他域的私人通信通道，其中包括主题和队列等流式通道，由事件提供者拥有。

商务流程

如果域名与其他域名进行数据交换或者传递事件时，需要遵循与RDS和API架构相同的政策。
为了实现创建有效的业务流的目标，有可能需要强制事件提供者对事件进行重写。
有几种选择方法可供选择。

应用程序内部的范围

将复杂的内部数据结构转换为更符合商业意义的结构。
最终结果是将转换后的非规范化表存储在应用数据库中，并使该表成为数据流的输入。
这样一来，消费者就不必再被复杂的逻辑所困扰。（被隐藏起来）

使用第三方工具

在复杂的数据结构中，调整和访问困难的应用程序可以在生成业务事件之前使用第三方工具。从原始技术数据转换为公共流数据时，该过程在应用程序外部进行，但在域边界内执行。（如：Apache NiFi，Apache Flume可部署在应用程序和流平台之间。）这样可以实现事件的丰富化。在丰富化后，将数据推送到中央的流平台，使其可以在其他域中被消耗。

摘要处理

流媒体的消费模式

由于需求更加多样且依赖于使用情况，复杂度增加。事件消费者有几种处理流数据的方法变化。

• ①②プラットフォームの機能の利用

中央プラットフォームを直接使用する。
変換されてプラットフォームから持ち出されて、コンシューマーアプリに所望の形式でルーティングされるようにもできる

③マイクロサービスとイベントフレームワーク

イベントコンシューマのユースケースに合わせてイベントを変換し、リッチ化する
Kafka Streams、Spring Cloud Stream、Akka、Axonなど使用できる
変換されたデータを中央プラットフォームにインジェストし直すか、コンシュマーアプリに直接インジェストするか選択できる。中央にインジェストすると他のドメインでも利用可能。

④ストリーミング分析サービス

分析的なユースケースをサポートする
ストリーミングコンポーネントを追加dケイル
Apache Samza、Spark Streaming、Beam、StormなどのOSSフレームワークを利用できる

根据事件情况进行状态转移

在域名內，還存在著使用私有流來傳輸應用程序狀態的模式（例如，當我們想使用雲服務提供商提供的分析功能進行運營系統時）。

实现RDS的功能

如果需要长期保存数据，则可以将流媒体平台作为数据库使用，并承担只读数据存储的角色。

使用流媒体构建RDS。

只需要一种选择,我可以用中文将其改述如下：可通过流构建只读数据存储。数据首先被摄取并转换，然后传输到从流平台创建的新数据库中。

管理和政策，以统一领域

不建议将中央流媒体平台作为应用程序的后端使用，因为非同步、不持久化以及企业数据流转目标的紧密耦合容易造成混淆。

保证和一致性

流媒体处理比批处理更复杂，对于故障和不一致性的处理也更加复杂。请见下文的注意事项。

一致性（综合性）水平

有两种类型的一致性：最终一致性和强一致性。

• 結果整合性(Eventual Consistency)

イベントは受信者がいるかにかかわらずプラットフォームに送信される
重要ではないデータに対しては有効

強一貫性(Strong Consistency)

イベントが失われないことを保証するために、イベントによっては何度も配信されるものもある

至少一次、仅一次、至多一次

在上述的”最终一致性”和”强一致性”中，有多种不同的处理模式。

• at least once

少なくとも一回
メッセージが失われないことを保証
一意性や一度だけ配信されることを保証されるわけではない

once、exactly

正確に一回
各イベントが正確に一度だけ配信
メッセージは失われず、重複もない

once at most

多くても一回
失われても良い可能性あり

请按照消息顺序排列

如果需要按照生成顺序处理所有的信息，可以使用Kafka等工具，只需使用一个分区即可实现。
如果需要多个分区，可以使用消息内的属性。

死信队列

在流媒体平台上，有一个用于存储未成功发送的消息的队列。例如，以下是一个例子，这些消息不会从系统中删除，可用于调查等。

• サイズ超過

• 不正な形式のメッセージ

• 存在しないトピックに送信されたメッセージ

メッセージが取り出されなかったためにしきい値に到達したメッセージ

流媒体的互操作性

在Pub/Sub之间的接口上，有一些平台可以实现不同编程语言之间的透明互操作性。一般情况下，使用接口描述语言来编码消息是常见的做法，还应考虑使用支持数据序列化的框架。数据序列化框架的角色和特点如下所示，这样可以让许多系统、编程语言和其他框架能够使用数据，并提高数据处理能力。

以下是一些序列化框架和协议的示例。

• Apache Avro

• Protocol Buffers

• Apache Thrift

• MQTT

AMQP

用于治理和自助服务模型的元数据。

在流媒体架构中，附加了元数据功能和元数据要求。其中，有一个重要的内容是主题注册表，包括以下内容：

• メッセージキューとトピックの所有権登録

• スキーマドキュメント管理

メッセージキュートとプックレジストリは、メッセージのスキーマレイアウトをドキュメント化する必要がある

XML、JSONなどは、XMLスキーマ、JSONスキーマを使用する
AvroやProtobufなどはIDLを使用する

バージョン管理
リネージ

请参考