银行重要交易类账务系统存储架构改造的可行性？

这是一个大的命题，是需要业务场景或技术瓶颈驱动，如果命中以下几项，需要进行存储架构的迭代优化。
1、可靠性低：“服务器可靠性低，出问题数据无法访问甚至就都丢了，必须用多从同步来补可靠性的缺口”，“服务器网络抖动或磁盘亚健康问题很难监控处理，影响系统稳定性”，“服务器故障修复需要比较长时间，不能放太多实例”。
2、运维困难：“更换设备或扩容需要搬迁数据库，全量同步数据很慢”，“以前数据库数量小，现单库拆分成数10个实例，未来全网整改后，预计上千个实例，运维太复杂”，“原来只有两台小型机，现在需要20多台机器，4、5个机柜，机房和电都不够了”。
3、成本高：“存算绑定，无法弹性扩容”，“资源闲置，CPU利用率低”，“为保证可靠性增加副本数，现有架构成本是原来的1.5倍”。

银行领域，重要交易类业务系统已经有很多成功投产案例
小银行有条件的话可以多向股份制和大银行取经。

对于核心系统来说，目前的分布式存储主要在时延上还不能满足要求，有的行虽然把核心的数据库改造成分布式，但是存储还是使用的本地存储。

      银行的重要交易类账务系统目前还是以传统架构为主，外围系统采用的分布式/云架构，即业界俗称的稳态+敏态双模架构；核心下移需要一个长期的过程，需要经过开发测试环境严格测评，目前很多银行客户会结合应用层的改造，通过读写分析等手段，把读业务做下移，数据库也从传统的集中式转向MySQL等分布式数据库，应对海量的业务访问量，是否会做存算分离，更多需要依赖性能、数据量、成本、网络条件等综合因素考虑；针对存储底层共用的方式担心过高的并发会出现IO占用率高，分布式存储可以做到资源和性能占用隔离，确保重要业务的优先性。

对于银行来说，没有必要进行大刀阔斧改造，如新机房部署，云化推进的契机的情况在确保稳定的情况下进行有条件尝试改造即可，银行还是对稳定要求比较高，特别是人行和银监监管力度越来越大，一旦发生业务问题，引起的后果是比较严重的。
如现在存储为集中式存储，对于互联网类业务，数据量大的业务，特别是云化类可以往存算分离方向改造。