由于互联网金融行业的发展，传统数据库的处理能力出现了瓶颈，数据库扩张的成本压力也越来越大。本次演讲将主要与大家分享应对这些问题的分布式架构与分布式数据库发展趋势及应用实践。

背景

传统数据库曾尝试使用集群技术，即将多台服务器连接组合成为一个集群，用多台机器去扩展整个数据库的处理能力。但是这种方法的问题是，当机器的数量到达一个值之后，由于数据访问的冲突问题，必定会出现瓶颈，也就限制了集群扩展的规模。同时，集中式系统本身的购买和运维成本过高。以金融行业为例，由于银行的全年业务峰值仅出现在某些时间点，如双十一零点和春节前3-5天等，如果按照这样的特定时间点峰值付费，在峰值过后会造成资源的浪费。

总结来看，集中式架构存在以下问题，这些问题也是分布式架构转型的驱动力：

• 集中式架构普遍缺乏弹性伸缩的能力，随着交易量和数据量的增长，系统支持的容量容易遇到硬件或技术的瓶颈。尤其在支持面向互联网海量客户相关业务时，不能有效处理瞬时爆发的海量交易，严重制约了海量客户的获取以及大规模业务营销。
  

• 集中式架构采用单体应用设计，软件开发和运行管理的最小单元是应用，管理力度较粗，容易“牵一发而动全身”。应用的开发过程不易践行轻量化敏捷开发理念，系统在运行过程中容易出现单点故障，难以有效进行故障隔离。

• 基于集中式架构的核心系统基础设施使用小型机或大型机，硬件和软件采购成本高，开发和运维主要依赖于服务厂商，服务成本高，也无法做到完全自主掌控。

• 技术体系封闭，技术的发展高度依赖于厂商，特别是依赖国外厂商，商业银行的IT团队缺乏自主可控能力，在一定程度上存在信息安全风险。

分布式架构演进

从整个分布式技术的发展历程来看，它经历了原有的大集中架构，到后来SOA的分布式架构，到应用服务器的虚拟化阶段，再到以文件系统和对象存储为代表的数据存储分布式阶段。而现在进入了一个新的阶段，那就是基于分布式数据库技术与微服务架构及容器做整合，在联机交易业务上实现弹性伸缩和扩展。

下面来分享一下分布式架构的演进。

• 集中式架构，它的好处是部署简单。

• 应用与数据分离技术，这是SOA最早的理念，其优点是系统分治、并行开发。

• 使用应用服务器做一个集群，把应用负载做一个分担，提升并行处理能力，但是在数据层面没有实现改进。

• Share-Disk数据库集群可以通过两台机器共享一个磁盘，提升数据库性能，但是其扩展能力较差，底层数据并没有实现分布式存储。

• Share-Nothing数据库集群(MPP)，与前者不同之处在于每个节点是区域自治的，可以把每个数据打散在每台机器上。该架构适合做分析，可以快速把数据分布到多台服务器上，但是不适合高并发联机交易处理。

• 读/写分离能够将数据库读的负载分担出来，提高读性能。

• 数据缓存，Cache数据的总量受限，同时存在引入Cache与Data同步问题，且Cache 分片难以管理。

• 分布式数据缓存和分布式文件系统，通过Redis把常访问的数据在应用服务器上做一个Cache，能够提升性能，增加容错，但是却增加了复杂度。

• 分布式数据库，底层的服务器是能快速扩展的数据库集群，数据库能根据容量弹性伸缩，也能够适用前端应用的负载变化。

那么这是不是最终的分布式架构呢？我认为真正的分布式架构是在一个微服务集群当中，一个微服务组件能够满足一个业务功能，这个组件当中包含所有应用逻辑，缓存，应用中间件和数据库。一个服务组件分装在一个容器当中，能够实现弹性伸缩，应对业务前端的压力。所以微服务架构才是未来极致的分布式架构，因为它已经把前面讲的这些组件变成了分布式的，支持弹性伸缩和水平扩展。这和传统的架构完全不一样，微服务架构能够实现“去中心化”数据管理(Decentralized Data Management)，它带来的演进是设计、开发一体化的技术。