构建可扩展架构：架构策略解析

### 构建可扩展架构：架构策略解析 #### 1. 可扩展性概述 在系统架构设计中，可扩展性是一个关键的质量属性。对于TFX系统而言，随着业务的发展和用户数量的增加，系统需要能够应对不断增长的工作负载。为了实现可扩展性，需要考虑多个方面，包括数据库的可扩展性、数据的分布与复制、缓存技术的应用以及异步通信的使用等。 #### 2. 数据库可扩展性 TFX团队对TFX合同管理数据库处理大量工作负载的能力进行了讨论。理论上，TFX平台的数据在一系列松散耦合的数据库中进行了良好的分区，且数据共享和复制需求被降至最低，这种设计应能使平台实现扩展。然而，团队决定通过早期的可扩展性测试来评估架构的可扩展性上限。 - **测试过程**：团队设计并构建了一个简化的TFX平台原型，仅实现了一些关键交易，如开具简单信用证（L/C）和支付。使用该原型，团队基于今年和未来两年的交易量预测，并增加了100%的安全余量，对预期的TFX交易组合进行了模拟压力测试。 - **测试结果**：随着测试工作负载的增加，与多个TFX服务相关的一些数据库，如合同管理器和交易对手管理器，成为了瓶颈，影响了整个平台的性能。访问和更新这些组件的服务出现明显的减速，对TFX平台的性能和可用性产生了不利影响。 - **初步解决方案**：团队验证了数据库查询，特别是与报告相关的查询，是预期TFX工作负载的重要组成部分，并带来了可扩展性问题。他们采取了一些初步措施，如优化查询和重新配置服务以增加容量，但随着测试工作负载的进一步增加，这些措施并不足以解决问题。此外，很难对TFX数据库设计进行优化，以同时支持更新和查询工作负载。 - **新方案**：团队考虑使用一个单独的数据库（分析数据库）来处理与报告要求相关的TFX查询。该数据库摄取TFX事务数据，并以优化的格式存储，以满足TFX报告要求。TFX事务数据库更新时，使用TFX数据库管理系统（DBMS）复制机制将更新复制到分析数据库。另一种考虑的方法是使用事件总线进行更新复制，但分析后发现，使用事件总线在高流量下可能会增加延迟，而使用TFX DBMS复制机制可以减少传播延迟，这对一致性和可扩展性非常重要。 以下是TFX服务高工作负载扩展的流程图： ```mermaid graph LR A[TFX事务] --> B[TFX事务性数据库] B --> C[DB复制] C --> D[TFX分析数据库] E[TFX报告查询] --> D D --> F[TFX分析数据] F --> G[TFX UI层] A --> H[TFX报告] H --> G ``` #### 3. 数据分布、复制和分区 为了更好地理解不同数据架构选项的优缺点，团队使用为压力测试开发的TFX原型，探索了几种数据架构选项。 - **克隆计算服务器和共享数据库**：团队克隆了一些可能出现可扩展性问题的TFX服务，如交易对手管理器，并在单独的容器集上运行每个克隆。所有数据库更新都在一个实例（主数据库）上进行，然后使用DBMS复制过程将这些更新复制到其他数据库。压力测试表明，这种方法比当前架构有一定的可扩展性优势，但无法解决管理多个克隆服务安装的问题。 - **数据分区**：团队考虑对特定服务的TFX数据进行分区，例如按用户组或银行对数据库行进行分区。他们在TFX原型中为交易对手管理器和合同管理器数据库实现了表分区，并进行了压力测试，测试结果成功。然而，使用表分区会增加架构的复杂性，数据库设计变更也会变得更加复杂。团队决定在初始部署TFX时不实施表分区，但在未来需要切换到其他多租户方法时，可能会重新评估。 | 数据架构选项 | 优点 | 缺点 | | --- | --- | --- | | 克隆计算服务器和共享数据库 | 有一定可扩展性优势 | 无法解决管理多个克隆服务安装的问题 | | 数据分区 | 可实现多租户，测试成功 | 增加架构复杂性，数据库设计变更复杂 | #### 4. 缓存技术提升可扩展性 早期的压力测试不仅揭示了数据库问题，还发现了一些与应用程序相关的性能问题。例如，一些TFX交易，如L/C支付，在使用早期版本的交易对手管理器、合同管理器和费用与佣金管理器服务时，出现了意外的减速。为了解决这些问题