Lib.rs

一个基于 ABCI 的接口，构建在 Tower 之上，它定义了一个异步函数，具有背压，并提供了一些组合子，允许通用组合额外的行为，例如超时、缓冲、卸载、速率限制、监控等。

ABCI 是 Tendermint（一个用于 BFT 复制状态机的共识引擎）与任意应用程序（要复制的状态机）之间的接口。ABCI 接口由共识引擎对应用程序做出的请求和响应组成。 Tower 是一个用于构建网络客户端和服务器模块化组件的库。Tower 定义了一个核心抽象，即 Service trait，它代表一个异步函数，具有背压，并提供了一些组合子，允许通用组合额外的行为，例如超时、缓冲、卸载、速率限制、监控等。

这个 crate 使用 Tower 定义一个异步 ABCI 接口。它包含两个部分：

1. 一个 ABCI 服务器，它监听连接并将 ABCI 请求转发到四个由用户提供的 Service 中，每个负责处理一类请求（共识、内存池、信息或快照）。

2. 将实现所有ABCI的中间件拆分为四个可复制的组件服务，每个服务处理一类请求。这些组件服务通过消息传递共享对主服务的访问，主服务根据以下基于类别的优先级处理请求：

   1. 发送到Consensus服务的ConsensusRequest；
   2. 发送到Mempool服务的MempoolRequest；
   3. 发送到Snapshot服务的SnapshotRequest；
   4. 发送到Info服务的InfoRequest。

由于ABCI服务器每个类别只取一个服务，用户可以将Tower层应用到传递给ABCI Server的服务上，以添加特定于类别的行为，例如削峰填谷、缓冲等。

这些部分可以以不同的方式组合，以提供在实现复杂性和性能之间的权衡曲线上的不同点。

1. 在最低复杂度级别，应用程序开发人员可以完全同步地实现ABCI应用程序。为此，他们实现Service<Request>，使Service::call执行请求处理并返回一个就绪的future。然后他们使用split::service创建四个共享对其应用程序访问的组件服务，并使用这些服务构建ABCI Server。应用程序开发人员不需要管理其应用程序不同副本之间的共享状态同步，因为只有一个应用程序副本。

2. 在下一个复杂度级别，应用程序开发人员可以部分同步地实现ABCI应用程序。与之前一样，他们实现Service<Request>以创建单个ABCI应用程序，但他们可以在Service::call的主体中延迟处理某些请求，通过立即返回一个在调用者的任务上执行的future来执行。尽管所有请求都由应用程序任务接收，但并非所有请求处理都需要在应用程序任务上执行。在这个级别，开发人员必须更加注意利用Tower层来控制上述单个服务的并发性。特别是，Consensus服务应使用ServiceBuilder::concurrency_limit为1进行包装，以避免由并发执行引起的共识消息效果的潜在重排序，以及ServiceBuilder::buffer以避免由于有限的并发性而在Connection中处理消息时的任何死锁。

3. 在最高复杂度级别，应用程序开发人员可以实现多个不同的Service，并手动控制它们之间共享状态的同步，然后使用这些服务构建ABCI Server。