银行互联网业务正在快速发展。互联网业务典型的特征就是高并发,比如说秒杀,天猫上天天有秒杀,京东上天天有抢购,12306到了春节,每张票都是秒杀。这种高并发场景对基础架构的压力,不仅是Web、应用服务器,更重要的是对数据库的考验。
网银系统涉及到的主要业务是交易,是金钱的交易,所有交易数据都必须符合核心系统的对账。它和银行柜面系统涉及到的交易一样重要。数据强一致性是对其的最基本要求。
1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?
2. 怎么解决互联网业务系统数据库层面的扩展能力问题?
3. 互联网业务架构如何选择合适的服务器?
1. 网银系统对数据强一致性有要求,就目前来看,它还没办法实现真正的分布式,集中式架构更符合现实情况。
2.高并发场景,前端的Web和应用很容易靠应用负载集群的横向扩展能力来解决。但数据库就没那么好解决了,常见的思路有这么几个:1)数据库缓存剥离为单独的集群缓存。2)NOSQL内存数据库的应用。3)增加数据库节点的固有处理能力。但是不是说所有业务都能用内存数据库,也不是说所有业务都能剥离缓存,传统方式还是靠增加数据库节点的处理能力。但是这个扩展能力可不像应用集群扩展节点那么容易。
3. X86服务器集群架构代替大型机小型机等重量级服务器的热潮一波接一波,是不是传统小型机上的所有优势都能被X86集群架构代替掉?
对于应用服务器,基本没什么太大的疑问,大部分系统都可以用应用集群方式实现横向扩展,将集中式处理能力转化为分布式处理能力。
但是对于数据库服务器(关系型数据库),尤其是重量型OLTP业务,X86还是不能完美成为替身。
对于传统OLTP业务来讲,尤其是银行的交易业务,数据库的模式并没有因服务器的架构改变而随之发生质变,仅仅是兼容性的支持,融合性的提高,数据的强一致性要求没有丝毫减弱。所以我们不能简单的为了使用X86而迁移?过去用小型机是因为其良好的稳定性、系统的健壮性以及处理能力的强大,去小型机是因为其昂贵的成本以及其独有的封闭性。今天我们用X86是因为其低廉的成本和相对已经得到质的提升的性能,今天成熟的集群技术,良好的X86服务器生态环境,这三者综合的性价比。按照企业宣扬的精神:客户是第一位的,企业自己是第二位的。所以我坚持认为核心系统的选型还是要以质为第一目标,对于非核心系统要以性价比来衡量。
收起1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?
2002年麻省理工学院MIT的教授在数学上证明了CAP理论,在分布式计算(存储)的架构里,由于网络引起的时延是必然的(Partition Network Toleration),因此对于一个操作在数据一致性(C=Consistency)和数据可用性(A=Availability)方面必须取舍一个。
许多互联网的业务类型(电商、搜索引擎等等),可以接受最终的数据弱一致性,而对于金融业需要数据实时强一致性的业务,采用关系型商业数据库集中式架构来满足ACID(代表Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性,是实现实时强一致性的基础)也是历史的正确选择。
分布式计算、集中式计算不是谁替代谁,而是各有不同的用点,各适合不同的业务场景需求。
很多互联网业务对数据不一致性及耦合程度要求低,可以使用无共享分布式计算架构。这种架构中的每一个节点( node)都是独立、自给的,而且整个系统中没有单点竞争。无共享分布式架构在Web 应用开发中尤其受到欢迎。
对于银行核心业务或【网银等有数据强一致性的系统】对数据有着严苛的实时事务完整性的要求,即使在高峰时段也要保持高可用并确保交易能快速完成,因此更注重数据的实时强一致性,采用集中处理架构是一种正确的选择。
2. 怎么解决互联网业务系统数据库层面的扩展能力问题?
数据库层的扩展一般分为横向扩展和纵向扩展,比如对于Oracle数据库,横向扩展可以用Oracle RAC,但是现实问题是,Oracle RAC的节点达到3个以上,整体性能急剧下降,且多个节点之间的通讯的性能消耗和延迟也很大,这也是市面上3节点(包括)以上的Oracle Rac架构不常见的原因。
既然横向扩展有瓶颈,那么我们就应该考虑纵向扩展,这就需要从单台服务器的扩展能力来寻求解决问题的能力。比如,可以选高端的小型机或IBM最新推出的LinuxOne服务器(运行Linux操作系统,全面支持开源,完全开放的主机)。顺便提一下,在LinuxOne服务器上运行z/VM系统(虚拟化的鼻祖,是PowerVM和VMware的爸爸),可以非常方便的实现在线动态横向或纵向扩展。且LinuxOne内部的通信是通过内存交换,特别适合Oracle RAC节点之间的通信,不仅可以很好的缩短交易的响应时间和增加网络吞吐,还可以多一种稳定的心跳途径避开HA“脑裂”。^_^
3. 互联网业务架构如何选择合适的服务器?
如上面所说,不同的业务可以选择不同的架构,各有各的优点,各有各的道,没有哪一种架构可以放之四海皆准。一般来说,前端应用等可以用分布式来部署,属于CPU运算型负载的前端应用服务器,适合用X86架构的服务器或用PowerLinux来做应用整合。对于后端数据库服务器,适合采用集中式部署,数据库是整个系统的核心,一般选型时要考虑服务器的可靠性、I/O吞吐能力、可扩展性和安全性。举个例子来说,IBM高端服务器LinuxOne就特别适合作为数据库服务器或数据库服务器整合。顺便掰扯一下,IBM LinuxOne秉承大型机50年的经典硬件特性,可以运行Linux系统,全面支持OpenStack、KVM等开源技术,CPU最多可以扩展到141颗,内存可扩展到10TB,服务器内部系统I/O总线带宽高达832GB/Sec,安全认证达到EAL5+(民用计算机最高认证),并且价格也跟普通的高端小型机相差不多(真是物美价廉)。
收起1. 网银等有数据强一致性要求的系统还是建议选择集中式架构,分布式架构受限于网络时延和应用状态始终保持强一致还是有困难的。例如一个典型的场景,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。
2. 怎么解决互联网业务系统数据库层面的扩展能力问题?
数据库的扩展性,很多传统数据库都有很大提升。比如ORACLE 12C就很更好的解决扩展性问题。而MYSQL在5.5之后的版本,扩展性也有很大的提升。
3. 互联网业务架构如何选择合适的服务器?
这个完全看需求,2路 、4路、8路都可以,很多厂商的服务器也都可以定制,依据跑应用还是跑数据库等做不同的定制化会很好,国产的服务器也可很好的满足这方面需求。
收起2. 怎么解决互联网业务系统数据库层面的扩展能力问题?
扩展能力问题:
一般从两个方面考虑,一个是硬件扩展,一个是软件扩展
硬件扩展一般是遇到了性能问题。简单的说是DB层面出现了瓶颈,一般是遇到了计算能力,IO处理能力不足的问题。需要进行扩展升级扩容,现在的服务器本身硬件配置都非常高,CPU和mem一般很难是瓶颈。经常出现问题无非是IO。处理IO瓶颈方法较多,一般常见的升级存储,扩容存储.最简单快速的方法就是采购新的闪存阵列,一劳永逸解决IO层面的问题.
软件扩展就是处理DB层面高并发和高可用,这个还是要根据实际的使用的数据库进行针对性的设计和配置.
1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?
首先对于秒杀类业务场景典型特点的高并发。实际上业务整个系统架构(WEB-> APP-> DB)不是来自最终的后端业务交易,可能在web端或者app端就已经出现了堵塞。都没有机会到db层提交自己的订单交易。所以有时候不是db处理不过来。而是web或者app已经不能承受如此大的高并发了,就像当初的双11.我抢到了商品,结果在支付环节出了问题。选集中式和分布式都有自己的特点和优势,任何一种架构不天生就没有任何缺点。重要的整个架构整体相互协调,尽量避免出现木桶效应。
个人觉得银行目前的架构考虑还是以维稳为主,任何形式的上的变化引起的任何不确定性都不能接受。固然从技术层面可以承诺,但是领导决策的时候不是以单一的因素来判定。目前看过去,大多中小银行由于自身的因素,网银还是集中式为其主要结构。
收起应用层采用分布式架构应该没有问题,
后端账务处理,目前分布式架构没有广泛应用,的确很多用户有数据强一致的顾虑,还需要有更多的应用场景给予支撑。
另外,在更多关注正常运行时候的性能问题的时候,也需要关注一下,当分布式节点发生问题的时候,对整个性能的影响。
收起