概要
- Flows 使同意更新账本的流程变得自动化
- 节点之间的沟通只能够在这些 Flows 的上下文中发生，并且是点对点的（point-to-point）
- 内置的 flows 提供了常用的一些任务（tasks）
动机 Motivation
Corda 网络使用点对点的消息传输而不是全局广播。也就是说协调一个关于账本的更新需要网络上的参与者明确的指定需要发送什么信息，发送给谁，按照什么顺序发送。
下边的图片动态地展示了对于一个简单在 Alice 和 Bob 之间的同意账本更新的流程。
The flow framework
Corda 使用了 flows 来使上边的步骤变得自动化。一个 flow 是一系列有顺序的步骤来告诉一个节点应该如何实现一个指定的账本更新，比如发行一个资产或者结算一笔交易。
下边是一个上边图片所描述的简单账本更新所涉及到的顺序的流程：
运行 flows
一旦一个业务流程被封装在了一个 flow 中并且在节点中作为 CorDapp 的一部分被安装好之后，节点的 owner 可以在任何时间通过使用一个 RPC call 来告诉节点开始这个业务流程。Flow 将所有的网络，I/O 和并发问题都抽象了出来，这个节点 owner 就不需要关注这些了
节点上所有的动作都是发生在这些 flows 的上下文上的。与 contract 不同，flows 不是在 sandbox 里执行的，也就是说节点可以在执行一个 flow 的过程中来进行一些动作比如 networking，I/O 或者随机地使用一些资源。
Inter-node communication
节点间是通过在不同的 flows间传递消息来进行沟通的。每个节点有0个或者多个注册的 flow classes 来回复另外个一个单独的 flow 的消息。
假设 Alice 是网络中的一个节点，并且她希望同 Bob（网络中的另一个节点） 一起同意一次账本的更新。为了跟 Bob 进行沟通， Alice 必须：
- 开始一个 Bob 已经注册过的 flow（Bob 会回复这个 flow 发来的消息）
- Alice 在这个 flow 的上下文中给 Bob 发送一个消息
- Bob 会启动它注册的这个 conterparty flow
连接已经建立起来了，Alice 和 Bob 就可以来回地沟通关于一个更新账本的改动并且最终达成一致。
Subflows
作为子流程被启动的 Flow 被称为 subflow。父 flow 需要等待所有的 subflow 完成后才会继续运行。
The flow library
Corda 对于一些常规的任务都提供了一套代码库，所以开发者就不需要自己去定义这些常见流程背后的逻辑了，比如：
- 公正（notarising）和记录一个 transaction
- 从相关节点搜集签名
- 确认一个交易链（transactions chain）
并发 concurrency
Flow framework 允许节点可以同时运行多个 flows。这些 flows 可能由于节点的重启甚至升级会持续几天。
当然任何时候 flows 进入了一个阻塞状态的时候（比如他们在等待 I/O 或者是网络的调用），这就需要将 flows 进行序列化（serialization）然后存储在磁盘中。出现这种情况的时候，节点不会等待这个阻塞状态的 flow变成非阻塞的状态，而会立即运行其他的 flow，只会在稍后返回到原来这个阻塞的flow。