南云鹏
金谷农商银行科技部运维中心主任
国内金融企业迁移到分布式数据库前后，在技术背景、选型、部署、成果与反思等方面都有哪些经验可以参考？
金谷农商银行工程师南云鹏带来了主题为《分布式数据库在金融场景下的实战》的分享，介绍了该行迁移到腾讯分布式数据库的项目实践经验。
金融机构面临的挑战与机遇
金融科技给农商银行等中小型金融机构带来了重要的挑战，包括几个方面。一是应用场景被第三方、大型金融机构大幅占据；二是客户的服务体验与要求不断提升，年轻客源不断流失，存款理财等负债资金成本越来越高，线下渠道使用率大幅降低。
但农商银行金融机构普遍承担着发展落实乡村振兴战略，推动普惠金融的落地重任，又是支持县域经济发展与服务三农的金融主力军。在普惠金融过程中我们普遍遇到客户难以高效触达，风险防控能力较弱，客户满意度低等诸多问题，所以金谷银行亟需使用金融科技力量来解决上述难题，挑战与机遇并存。经过充分调研研究论证，我们启动了互联网金融平台的建设工作。
准备建设一套互联网平台的时候，我们当初从以下几个方面做了重点考虑：
第一，大并发与高可用。因为面向的是互联网的业务，在技术架构上一定要考虑 7*24 小时不间断业务与交易峰值的场景。第二是易于维护与管理。因为在选型落地时要考虑农商银行普遍存在的 IT 基础薄弱、人力资源有限的问题，所以一定要选操作简单、学习成本比较低的平台。第三，采用分布式存储。分布式存储指的是金融机构传统业务大部分使用的是集中式存储，成本高、管理难度大、技术要求也较高，所以为了解决这些困难，我们一定要采用分布式存储来落地未来业务平台。技术选型的前瞻性、架构的合理性也是当初重点考虑的内容。
传统运维面临的问题
传统数据库运维管理工作中存在的一些难题。
1. 传统架构下数据库版本多、种类多，人员学习成本高，掌握的知识泛而不精；
2. 烟囱式数据库，运维自动化程度低，工作时效性差，维护成本高，只能手工巡检；
3. 日常维护繁琐，需要手工建库、实例、用户、权限、表空间等一系列脚本，出错率高；
4. 扩展性差：集中式架构的横向水平扩展能力非常低。面对性能不足问题，解决措施有限；
5. 高可用性难以保证：集中式架构主机一旦出现故障，运行的服务就会受到影响；
6. 数据库备份、恢复、归档管理困难，难以制定全面兼顾的备份策略；
7. 统一监控管理困难，各类数据库定制不同监控脚本并与监控平台对接，配置管理难度大；
8. 运维缺乏统一标准，工作规范性差。
运维整体架构
金融机构应该制定合理恰当的运维体系架构，规范日常工作，满足监管要求。在这里我介绍一下金谷农商银行目前正在运转的一套运维架构，并且围绕腾讯云典型的功能组件，讲述几个与腾讯云相关的运维工作的内容。
我们的大部分业务系统都在腾讯云平台上，在平台基础上我们又形成了相应的规范与制度。比如说针对操作系统中间件、网络配置、数据库等日常基础的标准环境，我们都形成了相应的约束与规范，保证所有的业务系统尽可能地在同一套安全、标准的环境下开展运维工作，减少日常管理难度。
我们也制定了相应的运维制度，比如容量管理是根据当前与未来业务的需求，在恰当的时间、用恰当的成本协调、提供需要的资源，为容量的规划与预算提供理论支撑的依据。比如我们根据业务的峰值、每年业务的增长量等来做第二年的容量规划，以及申报预算等。问题的管理办法就是记录日常运维过程当中遇到的所有问题，如何去解决，以及当中是不是有系统性的缺陷，或者人为操作风险，将问题管理起来，不断优化改善，从问题当中最终提出一些相应的运维知识库标准化，为运维连续性提供一些知识与沉淀。
变更管理讲的是变更操作、变更流程、变更等级，以及变更的类型，如何守流程，如何进行反馈，如何执行变更等等。运维管理办法规范运维人员的日常操作、行为规范等等。生产事件管理办法规范生产事件等级、生产事件的响应流程，以及不同流程驱动不同的汇报路径等。上面是业务层的业务系统。
在此基础上我们又构建了工具的平台，包括堡垒机、运维管理平台，还有自动化发布工具。堡垒机是日常运维操作的一个入口，所有对后端业务系统的操作都是通过堡垒机操作。运维管理平台对一些资源进行管理，比如说资源的增加、减少，以及对物理主机等进行管理。Jenkins 是自动化开源发布工具，做日常系统的变更、生产版本的发布，以及反馈信息，都是靠这个自动化工具来做处理。
再往上是运维监控平台。监控平台纳管了所有业务的监控。系统监控平台监控着物理主机 CPU、内存等物理信息、基础信息，同时监控了一些业务系统的服务端口，比如说开启 7001、8003 等，保证业务是健康存活的状态。如果业务端口宕掉了，我们也会有及时的短信告知等。业务监控平台是偏向于交易类型，比如说大量业务的攻击、访问的行为，以及对用户行为所用的基站、热点等行为的信息，保证系统不要被羊毛党恶意攻击，偏向于业务行为的监控。最后一块是行为监控，指的是操作行为的监控，包括生产操作所有人员的操作行为都会被监控起来，以方便追溯后边的操作。什么时间、什么地点，执行了什么操作，以及操作是不是有风险，包括问题的排查，以及事件的追溯，也支持关键命令、关键字的收缩。
左侧是客服与工单。运维靠这两个渠道去推动日常工作，比如说客户发现无法开展交易，通过客服渠道以工单的形式提到运维里。右侧是日常运维主要工作内容。
下面围绕架构里日常典型的几个操作展开。首先分享一下数据备份恢复。为了保障金融机构系统稳健运行与业务连续性，以及对金融机构关键业务 RTO、RPO 的要求约束，数据备份恢复工作是非常重要的日常工作。我们目前使用的备份策略就是全量+增量备份。因为每一个全量备份的成本很高，所以目前用比较灵活的全量+增量的方式。备份的方式包括逻辑备份+冷备份，以及手工+自动备份。工具目前用的是腾讯云平台+自动化工具配合使用。右侧是一个简单的样例图，最左侧是靠平台做数据的备份，备份完了之后把温数据通过自动化工具再拉取到目标机器，做冷出、介质转存等操作。因为这个平台是在一个数据中心，再往右侧的过程是拿到同城的另外一个数据中心去。为什么叫温数据？为了预防后续可能出现紧急问题，考虑数据紧急恢复要求，我们不可能把所有数据一备份下来都拿到另外一个地方转存，同时这也考虑了备份成本。为了保障备份策略及时有效性，我们也会不定期做数据备份恢复验证的工作。
再和大家交流一下切换演练。监管方面有要求，每年金融机构要组织重要系统开展应急演练的工作。另外，金融机构自身也要保证系统的稳定，以及业务的连续，不断提高业务系统运行管理能力，以及应急场景下系统救护保障工作的熟练度。
为了更好地开展应急演练的工作，要有相应的组织架构职能。应急指挥组一般都是高级领导担任，负责应急预案的启动以及对外宣传。口径要统一管理，不能随意发布公告、信息。应急管理办公室负责上传下达，收集各小组的情况，还有日常的汇报。技术支持组是三方或者远场保障人员。还有应急实施组，做应急事件的评估、响应等工作。业务支持组做业务的验证，包括业务的可用性，是否可以对外营业等。还有支持保障组做一些后勤保障，保障出现应急之后的场地、财力、物力、人力。
上面的演练是为了贴合真实生产环境场景的案例。这里模拟分布式数据库一台主机异常宕机之后，数据库是否可以对外提供服务能力，以及业务能否继续运行、交易能否正常响应。当时做了两项操作，模拟 agent 主库宕机，看看能不能监管，以及如何进行操作。
上面是当初操作过程中的截图。我们分了两个租户，一个是生产租户，一个是测试租户。杀掉服务之后，看看是否能发生切换。把主库的 agent 杀掉之后，左上角第一个图显示的是什么时间点主库发生异常，第二、第三个图，都是一些详细的告警信息。它会展示哪个数据库发生了切换，以及相应的告警信息，还有一些详细的日志，写了为什么发生了切换，什么事件导致切换的过程，日志会打印出来详情。第四个图展示的是切换完成之后，主库 IP 地址变成备库，备库的 IP 地址变成主库。
通过本次演练，真实地验证了 TDSQL 分布式高可用性架构是否真实有效，防止我们在真实环境当中，万一某一台机器死机或者坏掉就不能用了。在这个过程当中，数据库的主、备切换大约持续 5-6s，业务恢复大约持续 40s 时间。业务恢复指的是正常做交易，通过事件触发之后，可以看到交易数据、业务数据进来的时候，故障大约持续了 40s。整个过程当中都是系统自愈，没有人为干预。我们演练过程一直是在测试环境搞的，不是在生产环境搞的，因为测的过程当中确实发现了问题。发现什么问题呢？数据库正常的主备切换，但是业务数据没有重新连接机制，导致业务确实中断了，数据库还是能对外进行服务，但是业务系统在尝试连接数据库异常连接的瞬间也中断了。所以日常工作当中，在这块建议大家也着重考虑。
上图是容量管理的样例。
为了保障业务的连续，我们肯定要开展日常的巡检工作。上面是监控平台，因为所有的业务系统都靠它接通，一旦它死掉，整个监控是无效的。腾讯云对数据库监控的平台做的比较好。
使用经验分享
随着互联网业务的开展，数据也出现爆发型增长，所以必须要考虑可扩展性，采用分布式数据库。切记在业务初始规划的时候不要把分片设的太多。我们最初切了 32 个分片，后来降低到 4 个分片。32 个分片给后期的管理、维护带来很大困难，所以根据业务的增长应该是逐步扩容，不能一下子规划得太大。
腾讯云在金谷农商银行落地之后，系统的部署规划如上图。我们通过 VPC 虚拟网络把业务逻辑区通过 VPC 隔离出了五个区。
上图就是典型的业务系统在腾讯云架构的部署方案。绿色箭头就是内部系统的通信，我们架构是微服务分布式架构，最右侧是后端的一些系统，通过 Zookeeper 注册到这里。还有内网关设置权限的管理，权限管理就是不同的交易码之间的访问关系，要设置是否进行访问。还有对交易流量进行限流管控等。APP 怎么外调第三方？比如说 APP 系统主动调反欺诈功能，以及友盟的数据。首先 APP 数据出来之后，通过 F5 负载，通过 Nginx URL 出去了，然后到了第三方外调。外部业务系统怎么进来呢？通过外部的客户、用户，通过域名，到互联网 F5，再到 Nginx，Nginx 通过 Local 定位服务。
