银行传统应用和敏态应用适合存算一体架构还是存算分离的架构？

就银行传统应用即稳态和网络金融即敏态，这2种业务类型随着技术的发展已经在银行业普遍使用，就使用场景而言，2种形态目前而言还是并存的，但对使用的规模而言，两种还是有区别的。
普遍而言，敏态业务比较适合存算分离架构，因为敏态业务规模比较大，计算和存储分离有利于各自扩展的需要，且在性能上有一定提升。
而传统应用的话目前还是复用现有的传统架构，如改造成分布式存储，还是要看规模量和业务量。如果规模比较小，建议采用存算一体；如果规模大点，对性能有所要求建议存算分离。

在目前银行 IT 基础架构中，主流的存储形态依然是存算分离架构，计算层与存储层是松耦合的（物理机+集中存储或虚拟化+集中存储），即便是传统的数据库一体机，计算与存储也是分开的，之间通过高速网络连接（例如 IB），存算一体的架构目前比较主流的应用场景是分布式数据库、超融合架构和容器场景，下面简要展开。

分布式数据库天生就不需要外部存储，利用节点本地磁盘做数据持久化，通过分布式数据库软件进行数据分片，实现数据的冗余，节点故障，并不会破坏数据的完整性。

超融合架构是一种 IT 基础架构解决方案，将计算、存储和网络资源整合在一个统一系统（计算服务器）中。超融合基础架构由虚拟化、分布式存储和软件定义网络组成。利用分布式架构实现集群的可靠性和容错性，并通过将计算与存储集成在一起，灵活部署在通用标准硬件上，来降低数据中心复杂性和占用空间，并支持更多的现代工作负载。

容器场景通常会支持敏态应用，这里主要指有状态应用，例如 MySQL 数据库，为了保障数据库高性能，会使用服务器本地的磁盘（SSD）做为数据库持久化，为了容错 Pod 和 Worknode，需要配置一主多从的方案，数据库性能和可用性得到保障。

选择存算一体还是存算分离，需要结合业务场景，体现为对存储系统的服务要求，包括性能、容量、扩展能力、可靠性等多维度，对银行的核心/关键应用，目前更多采用传统IOE架构，如果转向分布式架构，结合数据量和性能要求，更多偏向存算一体方案，对于转向云/分布式架构的外围敏态应用，更多的是采用存算分离的架构。

1、技术选型
要从实际业务需求考虑，包括吞吐量、时延、带宽、IO等性能指标，看看业务对哪些指标要求高，进而选择适合的存储方案。

2、存算一体
有效降低数据搬运的损耗，提高了性能。
适用小规模、低负载的业务，且业务相对固定
不适合高性能计算等高负载、大规模的业务。

3、存算分离
需要频繁搬运数据，容易出现性能瓶颈。
适用大规模、高负载、弹性诉求的业务，如：云平台存储
不适合小规模场景，算力和存储分别部署，成本较高。