核心系统是否适合部署分布式存储，如何设计和实施？

先说结论，如果业务逻辑不改变，我认为现在能看到的分布式存储基本上都不适合银行的核心系统。焦点矛盾在于一致性和时延。

先从理论上探讨。分布式存储也要必须遵循分布式系统的基本理论，逃不掉的CAP。一致性，可用性，分区容忍性，这三者是互相矛盾的，你只能取其二舍其一。但是对于银行的核心系统来说，其实这三者都相当重要，很难舍弃掉其中一项。首先必须是个强一致性的产品，否则数据有可能会出现不一致，对不上账，那肯定是不行的。如果放弃可用性了，你的系统会出现偶尔不可用，想想用户的体验也很差吧。如果分区容忍性有问题，意味着一部分节点坏掉，会牵累整个系统，这也有点难受吧。这样的系统实现了也有扩展性不好的问题。

分布式存储，顾名思义它的节点一定是分开的，节点之间的数据通讯一定是通过某种网络。普通以太网或者光纤网，都无法提供很好的时延。目前看来只有IB网，时延才可以控制得比较好，但这也远远无法和一套本地的存储背板带宽的时延相比。这个时延问题不解决，整体系统的时延只会比它长不会比它短。所以很可能最后是无法满足银行核心系统的需求的。

那我们来看看具体的行业应用，如果按照金融核心系统的特点来看，相对合理的选择也许是强一致性高可用性，但是这样的系统往往性能不好，所以也是有点勉强。

  在其他行业来讲，分布式系统在互联网用得比较早，实践也最多，但这个和应用特点是有关联的。我们看到很多在互联网行业使用的分布式存储产品都是采用最终一致性。这实际上意味着舍弃掉了强一致性。保留了高可用和分区容忍性，结合互联网的应用场景。这样其实是适合的，对互联网和电商行业，焦点矛盾是必须支持更多的并发请求，所以必须有更多的节点分担工作负载，提升系统整体可用性。先让客户把商品装到购物车里，后续可以慢慢的同步数据，“最终实现一致”。

另外，互联网行业的一个强需求是扩展性，他必须要支持这么多的数据量，例如淘宝后面的图片存储系统tfs，他首要解决的问题就是有如此之多的商品图片需要存储，并且能够及时的被各个网页连接所调用。他的数据量绝对值相比银行核心系统，是有数量级的差距。银行的核心系统应该没有这样的需求，分布式系统的这一优势特点也就无从发挥。

分布式存储还有另外一个应用的行业是物联网。同样也是数据数量特别多，但每一条数据倒不是很大，同样，他们也没有强一致性和及时响应的强需求，但是数据的绝对总量非常大，所以分布式存储可以满足，但是这个需求特点和银行核心系统相去甚远。

所以分布式存储即使在一些行业应用比较适合，看起来也比较成功。但是考虑到银行核心系统对于数据一致性的强需求和低时延容忍度，如果现有的业务逻辑不做改变，其实是有点勉强的，要做很多工作，无法拿过来就用。