工行“去O”数据库选型与分布式架构设计( 二 ) _分布式架构

1）高并发问题，我们可以看到，阿里为了提升峰值，做了大量的缓存，鼓励使用花呗，降低与外系统的交互，但是依然对金融行业产生额外的压力。
2）高可靠性要求，确保系统稳定可靠，客户可以稳定支付成功，避免因不佳的客户体现导致用户流失。
3）高成本压力，大幅扩容的设备，以及随之产生的运维成本，以及昂贵的商业liscence ，给金融行业带来一定的成本负担。
4）同业竞争要求，大家都在做竞品分析，和同行进行比较，所以别人ok ，你挂了，你面子上还挂的住么，所以各机构在双十一前进行大量的模拟测试，类似于高考前的黑暗日子。
3、金融行业分布式的核心诉求及策略

文章插图

为此，金融行业分布式的核心诉求及策略可以总结为以下5点：
1）应该具备企业级的业务支撑能力，支持高并发、可扩展和海量数据库存储及访问；原则上应支持同城双活，实现集中式向分布式的转型。工行的两地三中心容灾体系在国有大型银行中属于第一梯队。
2）应能大幅降低使用成本，可以基于通用的廉价的X86硬件基础设施；降低商业产品依赖，拥抱开源产品，互联网企业已经给我们做了一个很好的参考。
3）应该提升数据库的运维自动化和智能化能力，支持与自身系统进行适配性定制，工行即实现了行内系统适配定制。
4）金融行业还应考虑到社会声誉性要求，客户对金融行业的期望很高，特别是对银行等金融组织，所以要求也更加严格，原则上应该是7*24小时的不间断服务。像当年支付宝在15年的支付瘫痪事件仅仅上了下热搜，但是13年工行因为IBM主机bug的问题却上了新闻联播，这就是所谓的爱之深责之切吧。
5）要考虑到政治因素风险，虽然全球化要求技术无国界，但是从去年开始的贸易战，以及美国的实体管制清单，我们可以看到技术是有国界的。近期HashiCorp发布公告，其企业版产品禁止中国使用已经引发了一种担忧。说起HashCorp ，大家可能不一定熟悉，但是其旗下有大名鼎鼎的产品Consul ，可以简化分布式环境中的服务注册与发现流程，大家一定耳熟能详。
最后中国人民银行在2019年8月23日发布了《金融科技（FinTech）发展规划（2019-2021）》中提到“做好分布式数据库金融应用的长期规划，加大研发与应用投入力度，妥善解决分布式数据库产品在数据一致性、实际场景验证、迁移保障规范、新型运维体系等方面的问题，这也给金融行业指明了方向。
二、选型的发展历程（方案选型历程）
接下来，给大家介绍下如何选型以及工行的选型历程。
1、工行分布式转型发展历程
大家可以看下工行分布式的发展历程：