在实际的流处理场景下，Operation（也叫算子）可根据 State 分为两类：
Flink 应用的可用性及扩展性，都建立在围绕 State 的特性当中。在实际的使用场景中，通常会通过 Checkpoints 和 Savepoints 来实现容错（Fault Tolerant），配置 StateBackends 满足对 State 持久化的需要。此外，Flink 还支持跨并行实例重分配 State，以便进行横向扩展 。
支付对账系统（Payment Reconciliation System）是一种金融系统，它用于对比和核对不同支付渠道和来源的交易数据，以确保交易的准确性和一致性。这个系统通常用于商业和金融机构，以管理大量的金融交易记录，包括但不限于信用卡交易、银行转账、电子支付、现金交易等等。
以下是支付对账系统的主要功能和目的：
支付对账系统有助于金融机构和企业确保其金融交易的准确性、透明性和合规性。这对于管理大量交易记录、减少风险、防止欺诈和维护客户信任都至关重要。不同组织可能会根据其需求和规模实施不同类型和复杂程度的支付对账系统。
常见的 DDD 实现架构有很多种，如经典四层架构、六边形（适配器端口）架构、整洁架构（Clean Architecture）、CQRS 架构等。架构无优劣高下之分，只要熟练掌握就都是合适的架构。
常见架构方案有以下几种：
EBI架构(Entity-Boundary-Interactor Architecture)
领域驱动设计(Domain-Driven Design)
端口与适配器架构(Ports & Adapters Architecture,又称为六边形架构)
洋葱架构(Onion Architecture)
整洁架构(Clean Architecture)
事件驱动架构(Event-Driven Architecture)
命令查询职责分离模式(CQRS，即Command Query Responsibility Segregation)
面向服务的架构(Service Oriented Architecture)
清晰架构（Explicit Architecture，直译为显式架构）是将上述架构的部分优势整合之后产生的另一种架构，因其 2017 年已经出现，已经不算是一种新的架构，实际应用的项目尚且较少。以下主要介绍架构的形成及各步骤的意义。
LangChain 是一个用于开发由语言模型支持的应用程序的框架。它支持以下应用程序：
LangChain 的主要价值有：
C 端消费者购买商品进行支付，付款的金额会通过三方支付机构送达银联或网联，银联或网联转发扣款指令到付款银行卡的发卡行来扣除付款人的付款资金。清算机构会在 T＋1 日把支付的金额结算给支付机构，支付机构再把资金结算给售卖商品的商户。结算资金给商户就涉及结算的资金是多少，结算的资金对应的支付订单是哪些，这些问题可以通过账务系统来统一处理。账务系统最核心的功能是记账，商户通过三方支付机构交易的每一笔订单都可以通过账务系统进行登记入账，账务系统给商户开设一个虚拟的账户，每一笔支付、退款订单都通过账务系统进行记录，清结算系统每天会发起清分，计算当天需要结算给商户的资金，并计入商户的余额账户，然后通过结算任务把余额账户的资金结算到商户的银行卡中。
计费系统是三方支付机构重要的子系统，三方支付机构最核心的收入来源是赚取手续费差值（手续费差值=收取的商户手续费-渠道收取的手续费），合理收取商户的手续费是支付机构得以存活的保障。要保证收取商户的手续费比渠道收取的手续费略高，但也不能太高，太高会给商户造成资金上的压力，在行业内失去党争力。所以计费系统要解决的核心问题是，既要保证收取的手续费能够让支付机构很好的活下去，又要保证不能给商户造成太大的压力，失去价格的竞争优势。但大部分支付机构初期的计费规则都较为简单，通常按百分比收取交易手续费。
支付的两大核心能力一是收款（入金），二是付款（出金），收款是把 C 端客户在购买商品时候的资金收到了三方支付机构备付金账户中，付款是三方支付机构把备付金账户中的资金付给售卖商品的商户。清结算系统是三方支付系统按照与商户的协议，将一个结算周期内的收付款项轧差汇总生成待结算金额，并将待结算金额结算给商户的一个功能模块，是支付体系中负责付款模块的一个子系统。
支付系统核心主要分为三大块：支付网关、支付核心、支付路由。支付网关主要负责通用的业务处理、资源隔离以及限流、熔断、降级。支付核心提供主要的支付服务。而支付路由则负责整体的支付渠道调度。
支付系统架构，主要介绍了通用支付系统相关的支付网关、支付核心、商户系统、账务系统、清结算系统和渠道系统。