本指南为构建 Universal Ledger API 客户端的开发者提供了架构和实现指南。了解如何：
- 利用网络拓扑实现高可用性。
- 提交交易并了解执行结果。
- 实现轮询、超时和重试策略。
连接到 Universal Ledger API 端点
请求会通过 Universal Ledger API 路由到特定的网络端点。 网络端点是区域级 Cloud 资源，可将请求分发到该区域内的验证者。如需访问网络端点，客户端必须连接到与该网络端点所在的 Cloud 区域匹配的区域级 API 端点 (REP)。
区域端点名称采用以下格式：
universalledger.REGION.rep.googleapis.com
将 REGION 替换为网络端点所在的受支持区域。
网络拓扑和高可用性
Universal Ledger 网络由分布在多个可用区和区域中的多个验证器组成，从而确保整个网络的高可用性。
可用区故障：如果某个 Cloud 可用区内的单个验证器发生故障，同一区域内的其他验证器将无缝继续处理请求。
区域级服务中断：如果整个区域变得不可用，其他区域中的验证者仍可正常运行。为了继续提交事务，您的客户端可以安全地回退并尝试通过其他端点重新提交事务。
交易执行特征
原子执行：事务要么完全成功，要么完全失败。系统绝不会执行部分事务，例如因余额不足而仅转账部分请求的资金。这包括事务链，可让您将多个任意事务合并为一个原子序列。
不自动重试：网络会尝试仅执行一次提交的事务。如果执行失败，账本不会自动将事务加入队列或重试事务。
幂等重新提交：每笔提交的交易都会根据其确切的序列化载荷（包括序列号和发送者）生成唯一的交易 ID。多次提交完全相同的载荷会产生相同的交易 ID。账本可确保交易最多执行一次，因此，如果某个端点似乎不可用，则可以安全地将同一交易载荷重新提交到其他端点。
如需了解详情，请参阅
SubmitTransactionRequest参考页面。
延迟时间、轮询和重试策略
当您提交交易时，验证器会首先执行快速检查，确保其签名和序列号有效。如果成功，Universal Ledger API 将立即返回 SubmitTransactionResponse，其中包含分配的交易 ID。
大多数交易会在 3 秒内完成。如需查看交易状态，请使用提供的交易 ID 轮询 QueryTransactionState 方法。
如果交易状态仍为
PENDING，请使用指数退避算法策略再次检索状态。例如，以 3 秒、9 秒、27 秒和 60 秒的间隔进行查询。如果
QueryTransactionState返回NOT_FOUND，请重新提交事务。
交易尝试FINALIZED后，响应中还会包含一个 TransactionCertificate，其中包含各种详细信息，例如：
- 交易最终完成时的轮次 ID。
- 执行状态（正常或失败）。
- 交易事件，包括任何交易输出。
超时协议
在极少数情况下，如果交易在 60 秒后仍处于 PENDING 或 NOT_FOUND 状态，请假设处理您请求的验证器未能跟上网络中的其他验证器。请完成以下步骤：
- 请选择其他网络区域中的其他端点。
- 重新提交完全相同的已签名交易载荷。
- 使用本页面顶部的“发送反馈”按钮报告问题，以便 Universal Ledger 团队进行调查。
检查交易状态时，如果您多次提交了相同的载荷，则响应可能包含多条 TransactionAttempt 消息。最多只有一次尝试会以 OK 交易状态完成（可在 TransactionEffects 中找到），而其他尝试将处于待处理或失败状态。这是预期行为；账本已成功执行其中一个交易提交，并正确拒绝或最终将拒绝重复的重新提交。
网络一致性
最终确定的交易：当某个验证者将交易报告为最终确定后，同一网络上的所有其他验证者最终都会处理该交易并重现完全相同的结果。使用交易最终确定的轮次 ID（可在其
TransactionCertificate中找到）提交QueryAccountRequest，会在所有同步的验证器上产生相同的结果。未最终确定的交易：由于交易在网络中异步传播，因此不同验证者报告的交易是否最终确定可能会有所不同。
正在从服务中断中恢复或遇到同步延迟的验证器可能会暂时将已完成的交易报告为
PENDING或NOT_FOUND。验证器赶上进度后，交易状态就会解析。
客户端责任和错误处理
事务跟踪：客户端应用必须跟踪所有已提交事务的状态，直到它们完成。
错误处理：如果交易失败，请检索并检查
TransactionCertificate中包含的失败详细信息，以触发适当的业务级修复。