加入收藏 | 设为首页 | 会员中心 | 我要投稿 青岛站长网 (https://www.0532zz.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长资讯 > 外闻 > 正文

分布式架构之高可用

发布时间:2021-04-19 01:26:16 所属栏目:外闻 来源:互联网
导读:领域取得进步。 今天的分享内容主要集中在三个方面:第一,微众银行的分布式架构的设计思路;第二,分布式的核心系统是如何来匹配分布式架构的;第三,基于分布式架构的运维管控如何进行。此外,我也会就微众银行的分布式架构和微服务之间的关系进行解释。 0

领域取得进步。

今天的分享内容主要集中在三个方面:第一,微众银行的分布式架构的设计思路;第二,分布式的核心系统是如何来匹配分布式架构的;第三,基于分布式架构的运维管控如何进行。此外,我也会就微众银行的分布式架构和微服务之间的关系进行解释。

01 分布式架构的设计思路

1.1 整体原则:通过架构实现安全可控,解除对底层技术的依赖

建设分布式架构的前提:作为第一家民营互联网银行,微众银行起步比较晚,没有太多历史负担;出于合规限制,当时获准的筹建期是六个月,初始资本为30亿;定位是普惠金融,因此需要全面降低成本。

纵观这些前置条件,可以看到启动资金的规模意味着我们在进行IT建设时天生不具备采购IOE的条件,普惠金融的定位在某种角度上意味着成本控制和底部组件的设定基本已确定。基于这一情况,我们从设计角度定义了三个不同原则

其一,坚持技术通用性,不被单一厂商锁定;

其二,极简主义。尽量采用稳定成熟的技术,不依赖技术性能来完成整体的性能指标;

其三,依靠可控的。对一家金融机构的IT部门来说,从架构角度出发,可控的主要是架构规划以及业务系统相关的程序代码。其他无法独立研发完成的部分就通过技术通用性来解决。

对于提供技术支持的厂商,我们希望他们的解决方案尽量白盒化,尽可能采用开源组件,开源社区本身具备一定的通用性,厂商自身有比较核心的研发能力。另外需要明确的一点是,如果计划用X86来完成分布式架构,就要默认你的底层技术和系统是不稳定的。如何通过运维手段来面对和解决这种不稳定性也是需要提前在设计中有一定规划的。

1.2 安全可控的核心技术建设理念:通过XML实现安全可控

下面将具体说明为了实现安全可控,我们如何设计搭建分布式架构。

主机:一般情况下,由几十到一百台X86服务器组成1个固定集群。这样1个单独的集群在分布式架构里也可以理解为1个单元。这个服务器集群提供应用计算服务、数据库服务和存储服务。我们通常也称之为数据中心的1个节点,这种单元化的节点在我们内部被命名为DCN(后文将有所提及)。

数据库:我们需要一个基于MySQL,至少是与其高度兼容的数据库。而这个数据库的特点在于——设计原则秉持“三幅本强同步”(稍后详述);数据放在本地磁盘上,而不依赖存储;实现自动化的故障监控和恢复。

其他技术:目前基本上是以Linux和KVM为代表的开源技术的组合,来完成整个底层的支撑。

1.2.1 数据库选型:以客户为单位的分布式松耦合单主多副本强同步架构

关于数据库选型,我们当时选择的是腾讯TDSQL数据库。在实践过程中,我们发现所有分布式架构的设计实质上就需要对你的客群或者业务来进行划分。

传统银行的IOE架构,程序基本运行在一、两台主机服务器上,数据一致性没问题,但在需要扩容的时候,更换硬件、数据迁移都极为复杂,闲置和风险都比较高。相对地,很多互联网企业在数据库优化中会进行分库分表,全量的分布式方式会获得很好的灵活性和扩展性,但数据一致性很难保证,而且金融业务的安全性和稳定性要求比一般的互联网业务也要高。综合来看,这两种模式就是各有千秋,所以我们思考的是能不能设计一种架构结合两者的特点。

基于这种考虑,我们采用了分布式松耦合架构。首先把所有的分布式节点按客群和业务两个维度做一次划分,即每个数据中心的分布式节点只支持一部分客群,也只支持某一类型的业务。其次在数据库层面,我们选择采用一主两从的节点强同步结构,以此来保证数据的最终一致性。

这样做的优势是:按客群拆分计算节点,每一个节点只支持部分客群,有效降低了单节点故障影响面,同时能够控制运营风险;业务逻辑分散到多个计算节点上去,实现高性能要求;数据层则通过一主两从的方式来实现数据高度冗余,满足高

(编辑:青岛站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读