1 背景

银行IT系统经历了从总分行数据分离，到全行数据大集中架构，再到基于SOA的服务化架构，目前已经走到了基于云计算的分布式架构转型的路口。

《中国金融业信息技术“十三五”发展规划》指出，金融机构主动探索系统架构完善升级，继续深入研究数据中心“双活”、“多活”模式应用。在巩固集中式架构安全稳定运行的基础上，综合成本、效率、资源等方面，以业务适用性为原则，研究分布式架构应用的可行性。

我们可以看到无论是从监管指导还是银行自身实践，都已经有大量的银行已经或者正在进行集中式向分布架构甚至云计算架构的转型。

分布式与云计算架构对于传统的银行IT从业者来说，可以说是一整套复杂庞大的技术栈。作为一名从传统集中式架构转变为分布式架构的从业人员，希望借此文谈谈自己的切身感受，同时借助自己对分布式和云计算的理解，希望能够帮助对于有志于转向分布式架构的传统岗位同行，对分布式和云计算有提纲挈领的理解，逐步完成从集中式架构到分布式架构的华丽转身。

2 银行架构转型的必然性

从集中式架构向分布式架构转型，可以实现IT系统的“自主掌控、降本增效”。纵观近几年尤其是最近的国际环境，“自主掌控”的必要性已经毋庸置疑；而银行面对外部激烈的竞争，IT系统“降本增效”也显得日益重要。

2.1 应对外部竞争带来的冲击

从当前银行所处的外部环境来看，互联网公司已经越来越多的切入金融业务，从开始的余额宝到现在的各种支付方式、以及场景化金融等等。

传统银行为了适应这个冲击也都很迅速的跟进，从各个直销银行到场景化金融，金融场景越来越互联网化，对于银行IT系统提出了新的要求：“如何解决三个海量问题：海量客户、海量账户、海量交易”。显然，传统集中式架构在应对三个海量问题方面捉襟见肘，采用分布式架构是业务发展的必然选择。

另外，从当前国际大环境和监管指导来看，基于国产化或开源软件、采用x86服务器的分布式架构在自主掌控、知识产权保护方面有着天然优势。

2.2 内部降本增效提升竞争力

银行业已经过了日进斗金、躺着赚钱的年代，迫于经营压力也需要后台部门降本生效。

相对于集中式架构需要采购商业软件、价格昂贵的大型机、小型机等硬件，分布式与云计算架构通常可以基于开源软件、廉价的x86服务器，大幅降低IT采购成本。

同时，采用云计算之后，应用开发部署涉及到基础环境准备时间将会大大缩短，甚至可以做到开箱即用、没有等待期，极大提升IT系统研发效率，更好的服务企业业务发展需求。

3 集中式架构向分布式架构演化路径

《The art of scalability》一书中，提出了一个系统扩展模型（scale cube），描述了分布式系统弹性扩展的三个维度：

• X轴：代表运行多个负载均衡器之后运行的实例，即通过应用服务器集群提供系统的处理能力和可用性，但数据库层面不支持水平扩展；
• Y轴：应用功能分解，将应用层和数据模型层的垂直切分，实现微服务架构。各应用可以独立的进行水平扩展，单一应用内部数据库层面仍然无法实现水平扩展；
• Z轴：数据分片，对应用内的数据进行分库分表，实现数据库层面的水平扩展。
  

这三个维度的划分，在一定意义上也代表了一个单体系统向分布式系统演进的一个路径：

第一阶段：单体应用，通过应用服务器集群来提高系统的可用性，支持应用层级的弹性扩展。但是，随着数据量的不断增大，开发人员已经使用了缓存、读写分离等策略，仍然会达到单一数据库集群处理能力瓶颈，无论再怎么增加应用服务器都无法提高系统的处理能力，这是系统往往会演进到第二阶段；

第二阶段：微服务应用，应用和数据库按照业务领域独立部署，形成多个微服务应用集群。该阶段一定程度上缓解了系统压力，能够提供更好的性能；同时，各微服务应用之间相互独立部署，在交付周期和故障隔离方面能够提供更高的灵活性。但是，每个微服务应用由于还是使用单一数据集群，在系统的容量、高并发等方面，存在着无法逾越的瓶颈；

第三阶段：数据分布式，领域数据库进行分库分表或者读写分离，在数据库层面提供水平扩展能力。基于数据的分布式，可以有效的解决数据库瓶颈问题，让系统处理能力形成进步一的提升；

第四阶段：采用逻辑数据中心设计来实现系统容量的无线扩容，并同时保持恒定的交易响应时间。辑数据中心的含义是：对物理数据中心进行逻辑上的划分，每个逻辑数据中心相互独立；每个逻辑数据中心部署相同的应用，但应用数据库通过分库分表之后均匀分布在每个逻辑数据中心中；每个客户的交易请求只会在一个逻辑数据中心内处理。由于每个逻辑数据中心里可以稳定支撑固定数量的客户交易请求，当系统容量达到上限时，可以通过增加新的逻辑分区实现系统容量的提升，满足更大的数据量、更高的并发量。

在完成分布式架构转型的过程中，相关的DevOps配套设施也必须同步建设完成；与此同时，云原生和云计算已经变得炙手可热，Docker容器和K8S的使用也是我们需要掌握的必备技能。

4 银行IT研发岗位面临的新挑战

作为一名从集中式架构转型为分布式架构的IT开发人员，从我自身感受看来，转型面临的困难主要表现在以下几个方面：

• 多：需要掌握的技术栈激增。从集中式架构下，只需要掌握一门开发语言（如Java），数据库使用（如DB2、Oracle）和Web容器（weblogic、tomcat），转变为在分布式架构下，需要从分布式的理论、微服务架构、数据分布式、DevOps、容器与K8S等多个方面的技能领域；而在每一个领域下又有众多的细分技能点（例如微服务架构就包含了微服务网关、RPC服务框架、注册中心、配置中心、服务跟踪等多个必须的技术组件）。同时，分布式涉及到的技术栈中，通常采用的是JAVA语言，但也会涉及到GO、C和Scala等各种语言。对于技术平台、应用开发和系统运维方面的不同岗位，需要结合自己岗位的特点，有针对性的进行学习；
• 快：技术更新迭代快，需具备快速与持续学习能力。由于多采用开源技术，兼受益于近年来分布式技术的快速发展，各个领域、各种技术迭代飞速、层出不穷。往往是刚刚研究完微服务又出现了云原生，刚看完Swarm风向又转向了K8S。对于开发人员学习强度大，疲于应付；
• 难：开发难、运维难。对于应用研发人员，应用微服务改造，如何切分合适的微服务粒度；数据分布式存储，采用何种分布式策略、如何处理分布式事务、如何进行数据分布式之后的汇聚查询，都需要精心设计。对于系统运维人员，除了需要学习分布式相关知识，还需要掌握如何运维大规模应用和数据库集群；如何形成完善的服务治理体系以应对复杂的服务调用，出现服务调用问题是如何快速定位故障。

5 转变心态，充实自我，拥抱变化

面对技术的快速变更，IT从业者唯一的不变就是变，时刻保持一颗持续学习的心。活到老学到老，对于IT从业者来说太适合不过。

那么，如果需要向分布式与计算架构转型，我们需要学习哪些方面的知识来不断提升我们自己呢？本节主要对分布式技术进行提纲挈领的介绍，希望能给大家有所帮助。

5.1 应用微服务架构

现阶段，大多数银行已经完成IT架构SOA化转型，在已经实现IT系统服务化的情况下，微服务架构能给银行带来什么好处，我想主要可以归纳为以下几点：

• 更快：敏捷迭代，快速响应业务需求；
• 更稳：故障隔离，业务连续性高；
• 更省：按需扩容，资源利用率高。

目前业界主流的微服务架构主要有以下几个流派，各自起源与发展侧重点各不相同：

• Spring Cloud：Spring生态圈面向微服务架构的开源框架，涵盖了微服务架构中必须的注册中心、配置管理、服务调用跟踪等主要组件；
• Dubbo生态圈：阿里巴巴开源的微服务框架，目前已经以“Spring Cloud Alibaba”的方式融入了SpringCloud生态圈；其提供的dubbo、nacos、Sentinel等组件已经有广泛的应用，面向微服务体系下分布式一致性的Seata也在快速发展；
• SOFAStack：蚂蚁金服开源的微服务框架，有其独立的RPC、服务注册、服务跟踪等组件。由于直接来源于金融行业，其宣传的特点是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践。

就目前实际使用情况来看，国内企业使用Dubbo起步早、应用广泛，加之现在也积极融入Spring Cloud生态圈，可以重点关注。

5.2 分布式数据访问中间件与分布式数据库

数据分布式涉及到两种不同类型的实现逻辑：基于中间件+传统关系型数据库的实现方式、基于新兴的分布式数据库（例如OceanBase等）。

两种实现方式各有优势：

• 自主掌控能力：中间件+关系型数据库模式对于企业的技术储备要求低，在传统关系型数据库的基础上，只需在对数据访问中间件有深入的研究即可，通常只需投入一两人即可实现源码级掌控；而分布式数据库涉及到复杂的分布式理论、一致性算法等技术，作为使用方很难做到自主掌控，对厂商的依赖较重；
• 使用复杂度：分布式数据库在底层对分布式事务、跨数据分片查询等提供了天然的支持，应用在使用时无需考虑太多的限制，使用简单；而中间件模式则需要自行处理相关跨分片的场景。

5.2.1 数据访问中间件

第一种基于中间件+传统关系型数据库方式，具体实现原理如下：

1.数据存储：采用传统的关系型数据库（例如：Mysql、Oracle等），按照一定的策略对数据进行分库分表或读写分离存储；

2.数据访问：通过数据访问中间件屏蔽底层数据库分布式存储策略，应用开发人员还可以使用传统ORM工具访问数据库，分库分表等策略对应用开发人员透明。常见的中间件分为两种类型：SDK和独立代理模式。

SDK模式中间件，使用广泛的开源组件有Apache ShardingSphere，阿里的TDDL等。SDK模式的优点是与应用一起部署，应用之间连接数据，没有中间代理环节，效率与可用性都高；缺点是各种语言的SDK需要重复编写（目前大部分只支持Java），对应用有一定的侵入性。 独立代理模式中间件，典型的有MyCat和DRDS。该模式支持数据库原生协议，跨语言，跨平台；应用在使用时只需要将原先的数据库链接，直接修改为代理提供的数据库链接即可。

该模式的缺点一方面是应用与数据之间添加了一个代理中间环节，性能会有一定的下降；另一方面是需要充分考虑代理服务器的高可用，避免因为代理服务器故障导致应用无法访问数据库。

5.2.2 分布式数据库

随着阿里OceanBase的崛起，分布式数据库也迅速进入人们的视野。最早的分布式数据库是Google Spanner，而国内则有阿里的OceanBase、PingCAP的TiDB、华为的GaussDB和中兴的GoldenDB等。国产的几个分布式数据库在银行业都有一定的应用，可以重点关注大厂出品的产品。

5.3 DevOps

在分布式架构下，DevOps成为了一个必不可少的基础平台，贯穿了从开发的代码管理、持续集成、持续发布，到运维的监控、告警等方方面面。

5.3.1 开发

从开发视角来看，应用微服务化之后会有大量的应用出现，每个应用都应有自己独立代码仓库；而应用的编译、集成、单元测试和打包都需要DevOps平台提供流水线支持。

对于应用代码的管理，可以使用成熟的SVN或GitLab，而对于应用的从编译到发布的整个流程，可以基于开源的Jenkins进行定制化开发，形成符合企业自己需求的工具、规范和流程。

5.3.2 运维

从运维视角来看，将面临更加巨大的挑战：

• 多：应用集群和数据库规模呈指数级增长，发布、维护工作量剧增；
• 乱：应用间服务调用关系纵横交错，服务治理难度增加；
• 难：一次交易请求经过多个服务调用，出现故障排查困难；数据分布式之后，快速查询到数据困难。

那么，在分布式架构运维方面，我觉得最重要的一个字就是“合”。运维人员看到的是各个视角的合集：

• 配置管理：独立于应用部署包的应用配置管理，便于统一的配置管理和配置变更即时推送，可以参考阿里开源的Nacos、携程的Apollo和百度的Disconf等；
• 数据查询：对于分布式存储之后的数据，能够提供一个便捷的跨分片数据查询工具；
• 主机管理与应用发布：集中的应用部署主机管理和统一的应用发布管理，能够快速的完成大规模应用发布；
• 服务调用：展示从服务入口到微服务之间相互调用、调用数据库、调用缓存等所有产生分布式调用、甚至应用内部调用的完整调用链路。服务链路跟踪起源于Google的Dapper论文，目前已经形成OpenTracing规范，可以关注大量优秀的开源实现，如zipkin、Skywalking、Jaeger等；
• 日志：大量应用节点产生的海量日志，需要通过ELK等工具汇聚起来，供运维人员方便快捷的查看；
• 监控：这里说的监控主要是指Metrics，通过Metrics可以洞察到应用运行的每个细节，如JVM情况、CPU、数据库连接池、请求处理情况等。可以关注CNCF的Promethues和Grafana，很好很强大。

5.4 容器与K8S

提到分布式与云计算，Docker容器和K8s是必须了解的内容。

自Docker问世以来，围绕容器服务编排就出现了Mesos、Swarm和K8S三雄鼎立的局面。随着CNCF的强势崛起，最终K8S一统天下，成为了事实上的标准。

当前互联网大厂已经广泛的采用了K8S，并在其上通过ServiceMesh技术（ISTIO等）开始向云原生架构进行演进。而在银行业内的使用情况来看，K8S已经进入了实质性的应用阶段，ServiceMesh技术则处在一个观望期，并没有太多实际的落地案例。

对于传统运维岗位的人员来说，K8S几乎已经是一个必须掌握的技能，而对于技术平台与应用研发人员来说，如何适配K8S并且用好K8S的特性，则是一个需要研究的方向。

5.5 技能学习侧重点

分布式架构技术栈庞大，技能点重点，一个人很难做到面面俱到、样样精通。以下是我梳理的不同的岗位针对各项技能点的掌控程度表，供大家参考：

• 精通：熟悉相关技能点业界主流技术，能够按照企业内部需求进行技术选型，并在选型基础能够完成自主研发，形成企业内部使用的平台与规范；
• 熟练：明白相关技能点原理，对企业内部使用的相关技术有较深入的了解，能够基于企业内部的平台/技术进行应用研发、快速故障定位与解决。

6 总结与展望

在谈了这么多分布式架构的内容之后，回归一个老问题，是不是采用了分布式架构之后就不要集中式架构了？作为一个IT人员可以肯定的回答，每一种架构都有其适用的场景，没有好坏之分。对于每个业务系统采用何种架构，做到按需选择，是所谓“无招胜有招”。

在这个技术变革日新月异的时代、内外环境异常复杂的时代、处处充满危机感的时代，持续学习、技术保鲜，才能让我们永远保持竞争力，不被这个时代所打败！