银行互联网业务正在快速发展。互联网业务典型的特征就是高并发,比如说秒杀,天猫上天天有秒杀,京东上天天有抢购,12306到了春节,每张票都是秒杀。这种高并发场景对基础架构的压力,不仅是Web、应用服务器,更重要的是对数据库的考验。
网银系统涉及到的主要业务是交易,是金钱的交易,所有交易数据都必须符合核心系统的对账。它和银行柜面系统涉及到的交易一样重要。数据强一致性是对其的最基本要求。
1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?
2. 怎么解决互联网业务系统数据库层面的扩展能力问题?
3. 互联网业务架构如何选择合适的服务器?
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+(民用计算机最高认证),并且价格也跟普通的高端小型机相差不多(真是物美价廉)。
收起感觉互联网业务的场景下,压力不应由架构中单独的一个或几个部分来扛,分布、缓存、应用优化、异步处理、数据分区、内存数据库、横向扩展等等多种手段相互配合才能有效解决问题。人员配置上最好也能跨部门组成产品团队。
收起第一个问题。分布式存储对于保证数据的可用性,提高数据访问效率还是相对集中式存储有一定优势,但是保证强一致性方面传统的集中式存储通过硬件层面的技术实现能够很好的保证强一致性,同时也对整体性能不会造成太大影响,还是比较占优的。
第二个问题。数据库扩展基本上可以通过采用数据库集群增加处理节点来实现,比较简单,也比较安全。
第三个问题。互联网时代由于x86服务器的总体拥有成本低,对UNIX服务器市场造成的冲击是有目共睹的。如果不太关心价格因素,选择UNIX服务器肯定是不二之选。如果手头紧选择x86服务器集群也无可厚非。
收起1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?
网银这类带有强烈互联网属性的业务系统如果设计的合理还是可以实现分布式的,首先从入口上可用结合CDN,GSLB等技术实现入口的分流,最简单的比如就是南北分流,用户登录以后可以根据水平拆分的原则落到不同的处理单元,拆分规则根据业务而定,哈希,取模用的比较多。简单的说选择集中还是分布式是看业务量,业务量不大,集中式完全也够用,现在绝大多数银行都是集中式,部分大行实现了从入口的分流。
2. 怎么解决互联网业务系统数据库层面的扩展能力问题?
还是建议从业务着手,scale out的扩展能力总会遇到天花板,scale up 已经是互联网的主流,而且也逐步走向成熟。不过一般都是通过MYSQL实现,传统的DB2,ORACLE还是比较困难,除非自己写一个DB路由分发中间层。
3. 互联网业务架构如何选择合适的服务器?
DMZ的前置服务器主要承载交易入口,CPU不用太高,但网络带宽一定要大,网卡需要好一点
后端APP和DB如果采用分布式的,目前主流的2路PC服务器性能足够好了,DB可以考虑加载SSD盘。
收起1. 觉得核心还是得集中式吧 上层再怎么变化的眼花缭乱,落到底层还是一笔笔的实打实的交易,要求的强一致性、稳定等是不会变化的。这也是IOE喊了这么长时间迟迟去不完全的原因。 而且,IOE本身也在适应这种变化,闪存市场、oracle 12c都是强化自身竞争力的产品。
3. x86服务器即可,可选的太多了,也可以找厂商定制。
收起1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?
是否采用集中或分布式架构建议根据实际的网络环境,企业地区分布,业务管理需求。
2. 怎么解决互联网业务系统数据库层面的扩展能力问题?
数据库本身可以建集群,如需要数据分析也可以引入大数据分析和展现。
3. 互联网业务架构如何选择合适的服务器?
服务器建议按需选择就可以,推荐用闪存卡,闪盘阵列。
收起数据库层面的扩展能力,可以通过集群或分布式架构来满足扩展能力
集群采用(负载均衡式)将对数据库的负载分布到集群中的多个节点上,在集群中的每一个节点都可以对外提供服务,从而达到更高的吞吐量,更好的资源利用率和更低的响应时间。
通过增加集群中的节点来满足扩展
收起分布式架构强调的是并发处理能力,也是针对需要高计算资源的应用需求,例如图形化软件在 对图像进行编辑制作的时候需要高计算资源来运算,此时需要采用分布式架构来分布处理和并发提供计算资源来处理
而现有的应用系统的性能瓶颈往往都不会是在服务器端(现在的CPU和内存可以增加很多),大部分都是后端的存储资源也就是IO的瓶颈;
由于分布式架构需要借助网络和节点之间的协议协商等,同样受限于网络延时和节点之间的协商等问题,可以通过副本方式满足提供一种冗余的方式提供数据和处理服务,但是对于数据的一致性高的应用不太适合
收起 在服务器选型上,我觉得X86服务器架构是趋势,尽管像楼主所说,原有的小型机、大型机等在稳定性、性能等方面可能优于目前的X86架构,但是X86架构也在不断完善和发展,而且现在好多新技术也都是基于X86架构的,同时加之虚拟化、软件定义等新鲜技术血液,都是基于X86架构的,以后随着软件定义和虚拟化的大量部署和应用,X86是基础,相对于封闭的小型机和昂贵的维护和维修成本,X86都有很多的优势