互联网技术架构给我们的启示

可以理解为自白书,知道自己太落后啦~

——中国建设银行信息技术管理部副总经理 王申科

据阿里官方公布的数据,2013年“双11”这一天,天猫、淘宝成交额共计350.19亿元,相当于10月全国日均消费额的一半,较去年的191亿元增长83%。支付宝交总交易笔数达到1.88亿笔,其中无线支付达到4518万笔,分别是去年同一天的1.77倍和5倍。

参照央行发布的2013年第二季度支付体系运行数据,二季度全国银行卡消费业务笔数约为30.6亿笔,平均每天约3400万笔,那么支付宝“双11”1天的支付笔数就相当于二季度全国的POS机交易量的5.5倍,也相当于国际支付机构Paypal一个月的支付量,比肩Visa全球日刷卡量。

作为一名商业银行IT从业人员,笔者一直关注阿里、腾讯、Google等互联网企业的技术路线、技术架构和技术管理理念,探究其如何能够支持如此的业务创新和技术保障能力。

一、几个基本计算机理论与模型

1.分布式系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统和分布式数据库系统等。

Google在构建搜索系统时,第一次将分布式系统和互联网结合起来,用分布式系统来解决互联网问题。Google的分布式系统设计有几个重要的特征:视失败为常态;重视横向伸缩性;预测性能,追求低延迟,廉价的硬件和软件,推崇重用,灵活设计,加入足够的监测点和调试功能来帮助日后的调试,优先虚拟计算。 Google的这些设计思想,成为互联网应用开发事实上的标准和规范。

2.CAP:一致性理论。CAP理论(C: Consistency 一致性,A: Availability 可用性,P: Tolerance of network Partition 分区容忍性)指出,一个分布式系统不可能满足一致性、可用性和分区容错性这3个需求,最多只能同时满足其中的两个需求。因此应用系统的关注点不同,采用的策略也是不一样的,只有准确把握了应用需求,才有可能利用好CAP理论。对互联网应用,可用性与分区容忍性优先级要高于数据一致性。

3.ACID 和 BASE 模型。ACID 是指在数据库管理系统中事务具有的4个特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。在数据库系统中,一个事务是由一系列数据库操作组成的一个完整的逻辑过程。事务的核心思想就是为了保证数据的一致性。ACID 模型被引申为强调数据一致性的开发理念,被银行、证券等机构广泛采用。

BASE 则是另外一个理念和思路,Basically Available 为基本可用,Soft-state 为软状态/柔性事务,Eventual Consistency 为最终一致性。BASE模型完全不同于ACID模型。牺牲高一致性,获得可用性。对一个“基本可用”系统来说,需要把系统中的所有功能点进行优先级的划分,对于系统内部的状态,采用一种柔性的策略,假如系统内分布了3个功能模块,允许它们在某一时刻3个模块的状态可以不一致。然后通过业务和技术的手段,例如采用异步机制或者批处理方式,来保证系统通过柔性状态一致来获得可用性。当前互联网应用在业务允许范围里普遍参考 BASE 模型来进行系统设计。

4.SOA 面向服务架构。是一种松散耦合的架构理念和模型,针对粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用。

二、互联网应用的技术基础

1.基于x86服务器集群和开源软件搭建技术设施,分布式架构+开源软件是其基本特征。X86服务器是互联网应用基本计算资源,例如Google、阿里等公司,每个数据中心动辄部署上万台、几十万台和百万台X86服务器,进行动态资源调度。开源操作系统Linux、开源web服务器Apache、开源数据库MySQL、开源脚本语言Php/Perl……这些著名的开源软件支撑了互联网公司发展。开源软件的发展同样离不开互联网发展的支持。初期的开源软件代码缺陷和设计缺陷很多,正是通过应用发现软件缺陷、不断修补的方式,既支持了互联网公司的发展,又促进了开源软件的发展。从对开源软件的使用和修改开始,互联网公司就逐步积累和掌握了自主研发能力。

2.积极进取的创新精神。以阿里巴巴为例,短短几年先后自主开发了如下技术产品:分布式文件系统和分布式存储、搜索引擎技术、分布式计算、分布式机房、消息中间件、分布式锁管理、虚拟化和计算资源调度;Apache和Nginx等开源软件定制、Java虚拟机调优(JVM)、开源数据库调优;文件系统优化、网卡协议栈优化、操作系统资源隔离、操作系统资源管理、操作系统内存优化、虚拟化软件底层研发;低功耗处理机、协处理器辅助应用、数据中心省电技术、新一代存储技术、新一代网卡应用。

3.基于场景的需求分析和应用开发。总结阿里巴巴开发的原则如下:SOA服务化,所有系统采取服务化模式,系统之间进行必要的分拆和隔离,通过服务调用和消息通知的方式进行协同;BASE和ACID相结合,能够采取BASE模式的业务一定是异步方式,而核心的账务信息一定是采取实时方式,保证ACID;无单点设计、可监控、可测试、可回滚、可禁用、短事务与柔性事务、异步设计、无状态、使用成熟技术、业务分等级、业务可降级、多数据中心部署。

4.平台化建设理念,提高开发效率和系统质量。苹果公司的App store提供标准的开发平台,全球开发者可以充分发挥自己的聪明才智,开发个性化的应用,并通过苹果应用商店发布。苹果公司向开发者提供了应用程序开发框架,以方便开发者的开发工作。开发框架包含三类组件:应用程序接口库、开发工具和测试模拟器。

5.自动化部署和运维体系。阿里巴巴开发了一套资产信息采集程序和采集流程,将服务器、网络设备、存贮等资产信息,采集到数据库中。应用系统不再关心具体的资源信息,无论资产还是资源都是处于动态的变化中。通过资产信息和资源的变更流程,资产信息,硬件信息和应用信息的任何变更,必须通过系统进行变更记录,详细记录每个设备的生命周期里的各种变化。变更流程和工作流系统对接,通过工作流系统进行分级审批之后,才能进行相应的变更。以自动化采集为核心的资产管理体系,主动监控确保资源池一致性,保证资产信息的准确性。对资源进行回收和重新分配的时候,先要确保资源的状态。对于资源的数据,必须采取主动监控的做法,确保数据的可靠性,其具体做法是每天对设备的信息进行重新抓取,并与数据库里的状态进行匹配,发现不一致的数据,报警并锁定资源,不允许对资源进行任何操作。通过这种自动化的方式,杜绝人为错误,确保资产数据和资源池信息的数据一致性,是资源池可信的重要保证。

6.成本控制意识和自主掌控能力。互联网企业的IT成本控制意识较强,面对激烈的市场竞争和客户体验的需求,需要敏捷的技术反应,完全依赖通用技术和国际大名牌的IT设备和软件供应商无法满足这类需求。开源和廉价的X86服务器是最佳的选择。短短几年时间,互联网公司的技术研发能力和研发速度,明显强于老牌的IT公司。这是一种以市场需求为导向,以客户体验为基础,以技术架构创新为手段,引领业务和技术创新的新模式。

三、商业银行应用系统的技术基础

1.通用信息技术和商业化软件是基础,集中式系统部署。多数商业银行信息化建设遵循通用信息技术的路线,即采用商业化的大、中、小型计算机硬件系统及其配套的编程语言、操作系统、中间件工具软件和数据库,进行集中式部署。例如采用IBM大型机和P系列服务器、Unix操作系统、Oracle或DB2数据库等,采用Cisco公司网络设备和EMC等公司的存贮设备。银行的各种应用基本运行在这样的技术平台上。最近几年,随着云计算理念的普及和X86服务器性能和可用性的不断提升,已经出现规模性部署X86服务器,构建云环境的趋势。

2.面临完全依赖供应商的被动局面。商业银行在信息技术支持和保障能力、技术进步和创新能力、技术采购议价能力、设备升级周期和扩容、成本控制等方面,很大程度上依赖信息技术供应商。从历史看,商业银行应用系统大多采用三层架构:服务层、应用层和数据层,最近几年逐步加入ESB层。每层采用双机或集群技术支撑业务应用。早期以纵向(scale-up)升级扩容为主,现在逐步采用横向(scale-out)扩容方式或虚拟化方式。这种历史发展过程中形成的架构和技术路线,很难适应发展迅速的互联网时代应用需求。

3.交易系统突出资金安全和核算的准确性,数据一致性要求高,客户体验差。从模拟手工流程一路走来,商业银行信息化建设始终围绕内部业务管理、经营和风险控制的目标。应用系统存在存在如下问题:一是烟囱式结构,渠道不统一,整合性差;二是应用范围小,非企业级;三是标准不一致和数据质量差;四是着眼银行内部流程,对外客户体验不佳;五是网上银行和手机银行等具有互联网特征的应用,仍然构建在传统的技术架构上,其应用系统也主要是把柜面应用搬到网上银行和手机银行之上而已。

四、5点启示

1.用互联网的思维,认真思考和规划商业银行的信息化建设工作。互联网的创新正快速改变人们行为习惯、思维习惯,改变整个社会。银行的生存和发展离不开外部的世界,银行不去适应这种社会的变革,就会落后甚至淘汰。时下互联网金融和金融互联网的讨论和创新如火如荼,显著地影响人们的金融习惯,势必引起银行业重大变革。面???这样汹涌的互联网浪潮和变化越来越快的世界,我们必须要有危机感。

2.引入分布式架构和开源软件,构建集中式和分布式共存的架构体系。从应对市场的整体效果看,互联网分布式架构明显优于商业银行传统集中式架构,核心差别在于两类不同的应用架构理念,以及两类不同的技术团队管理、支持方式。因此,从应用入手,着手调整商业银行传统的技术架构和供应商管理方式,制定商业银行的技术架构设计规范和部署策略,实现架构的科学管理。

3.突出核心能力,理性看待“去IOE”。仅从技术角度看,“去IOE”的实质是分布式架构和集中式架构、开源软件和商用软件的选择问题,各自的利弊见仁见智。商业银行IT从业人员的核心竞争力主要体现在对银行业务理解,以及对信息技术的熟练应用和应用架构设计能力,用信息化支持、推动和引领业务创新。

4.从设备供应商向服务供应商转型。著名的IT公司要加快从设备供应商向服务供应商转型,成为用户可信赖的战略合作伙伴。从采购成本、服务水平、硬件和软件能力、安全和掌控能力等方面看,用户对诸如IBM、Oracle、EMC等国际著名公司的满意度不断下降,随之出现“去IOE”的呼声和行动。商业银行新一轮信息化建设为供应商转型提供了一个很好的机会,供应商可以和一些商业银行建立战略合作联盟,成立专门的行业队伍,搜集需求,优化升级通用技术和软件,及时解决用户实际遇到的问题,顺应并引领互联网时代的技术需求。

5.积极主动与互联网公司开展合作。当前互联网公司已经取得了丰硕的成果,不但在业务创新上领先于传统行业,而且在新技术研究和应用中也积累了丰富的经验,在云计算、分布式系统和大数据处理等技术上领先传统IT厂商,并且还在不断加大投入,以保持技术优势。商业银行要开始与先进的互联网公司开展深入合作,学习和吸收可能为银行所用的新业务模式和新技术,进一步拓宽业务思路,拓展技术视野和选择范围。

时间: 2024-11-05 20:38:41

互联网技术架构给我们的启示的相关文章

大型互联网技术架构4-分布式存储-II Google

The largest single database on earth - Google Spanner. 我们继续互联网技术架构-分布式存储. 上文大篇幅介绍了一些分布式存储的理论,偏重理论.可别小看这些理论,Google的各个神器都是建立在这些理论之上,甚至整个Apache的大数据3剑客项目都是受惠于这些理论.难怪@Tiger大牛讲Google靠的是一大批世界顶尖数据,物理,计算领域的Ph.D.,这些大神以及他们的Paper是Google为什么是Google的原因,以及Google没有开源

大型互联网技术架构3-分布式存储-I

我们继续互联网技术架构-分布式存储. 总目录: 分布式存储概述 分布式存储特性 - 哈希分布/一致性哈希分布 分布式存储协议 - 两阶段与Paxos 1. 概述 分布式存储作为互联网之核心基石,没有分布式海量存储就好比无源之水.分布式系统不是什么新鲜事物,教科书里已经研究了好多年,但是不温不火,直到近年互联网大数据应用的兴起才使得它大规模的应用到工程实践中,其主要特点概括为:规模大+成本低.现在的大型互联网公司少则几百几千个PC服务器,多的达到数百万级别低成本PC服务器集群; 总体来说,分布式存

《架构真经:互联网技术架构的设计原则》

架构真经:互联网技术架构的设计原则 主旨 这本书的英文名是scalability rules,但这里的scalability比狭义的可扩展性含义更广泛,不止是架构上,也涉及到工程.团队等方面的经验总结. 50条可扩展性规则 规则1 避免过度设计 产品的设计超出设计需求.完成的产品对于用户过度复杂.技术实现复杂到令他人难以理解都是过度设计的表现.复杂的系统实施成本高.维护困难,简单的系统容易扩展.可维护性强且成本低. 规则2 方案中包括扩展 在早期考虑到容量扩展的需求,但借助IaaS等服务可以在容

互联网技术架构演变过程-软件架构设计学习第四天(非原创)

文章大纲 一.演变过程思路图二.何为大型网站三.架构体系演进四.架构总结五.参考文章 一.演变过程思路图 二.何为大型网站 1. 大型网站特性 既然说的是大型网站架构,那么架构的背后自然是解决人因面对大型网站特性而带来的问题.这样可以先给大家说下大型网站的特性,这些特性带来的问题就是人要解决的问题:(1)高并发.大流量:PV 量巨大:(2)高可用:7*24 小时不间断服务:(3)海量数据:文件数目分分钟 xxTB:(4)用户分布广泛,网络情况复杂:网络运营商:(5)安全环境恶劣:黑客的攻击:(6

互联网电商技术架构之一

架构目标 业务系统 架构设计原则 应用架构 基础架构 数据库架构 分布式数据库特性 ? 支持MySQL,MariaDB,MongoDB等数据库 ? 服务高可用,主库故障,从库自动切换 ? 数据高可靠,定期快照备份,增量备份 ? 数据自动拆分,一键无缝迁移扩容 ? 针对特殊业务需求,定制优化特殊的数据库版本 Proxy 节点 原生MySQL协议,接入使用标准MySQL客户端 数据根据路由规则分库分表,对业务访问透明 单库容量满,可以快速在线无缝迁移,不影响业务 Proxy 数据拆分 Transfe

BAT解密:互联网技术发展之路(3)- 牛逼公司的技术架构都是这个范

大部分人对于BAT的技术有一种莫名的崇拜感,觉得只有非常牛逼和天才才能做出现在的这些系统,但经过前面两篇博文的分析,我们可以看到其实并没有什么神秘的力量和魔力融合在技术里面,而是业务的不断发展推动技术的不断发展,一步一个脚印,持续几年甚至10几年的发展,才能达到当前技术复杂度.先进性.牛逼度. 抛开BAT各自差异很大的业务,站在技术的角度来看,其实BAT的技术架构基本是一样的,再将视角放大,你会发现整个互联网行业的技术发展,最后都是殊途同归. 如果你正处于一个创业公司,或者正在成为另一个BAT的

传统企业如何转型互联网?苏宁六年技术架构的演进总结

https://mp.weixin.qq.com/s/ADTO5sAli0WvMViqgVOnaA 下面两张图可能让大家有一个印象:苏宁的业务是很复杂的.2012年,第一次接触苏宁的时候,我还在IBM工作,单纯地想苏宁不就是卖电器的吗?可能直到今天,很多人还是有这个误解.实际情况当然不是,这是非常大的误解.比如苏宁有体育版块,包括江苏足球以及今天的国际米兰.苏宁的零售是全品类经营,不只卖电器,还卖其他商品.上市的公司只是苏宁云商,苏宁没有上市的置业,包括酒店.房地产等.这么多业务都需要IT总部去

《大型网站技术架构》读书笔记之七:随需应变之网站的可扩展架构

此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. 一.可伸缩与可扩展-傻傻分不清楚 上篇笔记我们学习了可伸缩架构,但在实际场合中,包括许多架构师也常常混淆可伸缩和可扩展,用可扩展表示伸缩性.那么在此,跟随作者我们来理清这两个概念,避免我们以后对其傻傻分不清楚. (1)扩展性(Extensibiltiy) 指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力.我们不禁想到了面向对象中一大原则:开闭原则,对扩展开放,对修改封闭.也就说,当系统新增一个功能时

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. 首先,所谓网站的伸缩性,指不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力.在整个互联网行业的发展渐进演化中,最重要的技术就是服务器集群,通过不断地向集群中添加服务器来增强整个集群的处理能力. 一.网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 (1)纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性: (2)横向分离:将不同的业务模块分离部署