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

像数据库瓶颈，顶配数据库空间仍然无法支撑业务半年发展；慢SQL数量爆发式增长，应用稳定性岌岌可危；人工运维风险极高；人工运维频率高，研发幸福感下降这些大家都会遇到的问题也会逐渐地遇到，他山之石，可以攻玉，我们完全可以把别人的挫折拿过来，避免自己走弯路。
4、MySQL上云
在逐步推进的过程中，完善选型体系建设后，为了确保资源的有效利用，上云实际上是一种必然的选择。从工行来看，经历1-2年的发展， MySQL数据库节点就已经增至几千套，机房和设备实际上已成为一个瓶颈，再这么玩儿下去机房容量不足了，所以必须提升资源的使用效率。

文章插图

我行新建应用时，一般都会进行1-3年的一个超前规划，业界也是同样的做法，为了稳定运行，避免出现资源瓶颈，基本上提交资源申请时，都选择物理机。但是大规模的申请物理机，而当前应用的交易量又无法达标，所以资源浪费非常严重。
根据评测，相较Oracle ， MySQL数据库实例单体性能容量较小，数据容量普遍小于500G ，同时超过一定容量的就要进行分库，但是一台物理机部署1个数据库的方式并未发生变化， MySQL的服务器资源密度较低；同时运维效率低，在服务器、存储、网络等基础设施环节的运维和交付仍然需要大量手工操作。
业界普遍的做法就是将MySQL上云，实现云化部署，借助成熟的云体系实现弹性伸缩和动态扩容。工行有个优势， IAAS和PAAS云处于同业领先地位，有着丰富的经验积累，为此结合行内对于云战略的规划， MySQL上云是一种必然趋势。
我们提供了MySQL的容器镜像，提供了一键式的环境供给能力，通过上容器把IAAS、PAAS全部打通，支持快速搭建符合行内标准的基础环境，提升环境支持能力。
工行基于K8S、SDN、IAAS建设持久性的状态容器运行集群，通过SDN实现容器网络资源的自动化申请，通过底层扩展K8S实现容器的固定IP ，业界一般会采用K8S Operator实现容器的有状态资源绑定，也包含了固定IP绑定。
保守估计，资源的使用效率至少提升了4到5倍。而且，我们的工作成果也相当喜人，截止当前工行的MySQL云化部署节点已达4300多个。
5、工行实施效果

文章插图

我们可以看下工行的转型成效，首先看下数据：
1）我们已实施200多个应用，高灾备等级应用占比高达53% 。
2）6000多个MySQL节点, 高灾备等级应用占比高达87.31% 。
3）实施的应用涉及很多核心业务，包括个人、对公、基金以及很多高灾备等级应用，大多数为主机下平台迁移应用，少量应用是从Oracle迁移过来的，因为工行将PLSQL存储过程用到了极致，所以应用层也因此需要重构。
4）我们通过MySQL支持的核心交易可以达到日均7亿的交易量，经历过双十一和春节的多重考验，峰值TPS至少可以达到1.5万TPS ，同时支持横向扩展，理论上通过扩展设备还可以无限地增加。而如果通过主机想达成这个目标，那么挑战就会比较大，这就是建摩天大厦和建排屋的区别。
5）通过良好的架构设计，我们可以满足两地三中心的架构要求，做到同城RPO=0 ， RTO<60s 。
6）在自主能力方面，初步建立了企业级的基于MySQL的分布式解决的自主能力：首先是分布式框架+MySQL的应用级分布式解决方案，该方案承载了我行很多主机下平台应用。
其次是基于分布式中间件DBLE（原型为MyCat ，后经爱可生公司优化为DBLE ，同时我行进行了深度优化和开发）建立数据访问层，支持应对一些不是很复杂的场景，通过良好设计的分库分表方案即可满足需求。
7）在成本方面，我行在主机上的成本投入明显下降，近几年我行的业务交易量每年以20%的速度增长，但是主机并没有进行扩容，投入还逐年降低。商业产品的数据库的使用不仅实现零增长，还有所下降。从整个经费上来说，有非常大的降幅。