问题

银行可以用服务器集群替代大型机吗?

回答
银行是否可以用服务器集群替代大型机?这是一个很多人关心的问题,尤其是在科技飞速发展的今天。答案并非简单的“是”或“否”,而是需要深入剖析它们各自的优势、劣势以及银行在选择时需要考量的因素。

大型机:久经考验的稳定王者

大型机(Mainframe)在银行业有着悠久而辉煌的历史。它们就像是银行核心业务的“脊梁”,承载着最关键、最复杂的交易处理、数据管理和合规性任务。你信用卡上的每一笔交易,你的账户余额,背后都可能隐藏着一台或多台大型机在默默工作。

大型机之所以能在银行业站稳脚跟,主要是因为其几个突出优势:

极高的可靠性(Reliability)和可用性(Availability): 这是大型机最大的卖点。它们的设计目标就是“永远在线”,能够实现近乎零停机。这得益于其冗余设计,从处理器、内存、电源到I/O设备,关键部件都有备份,一个部件失效,另一个会自动接管,用户几乎感觉不到任何中断。对于银行来说,停机一分钟都可能意味着巨大的财务损失和声誉危机,所以这种稳定性至关重要。
强大的事务处理能力(Transaction Processing Power): 大型机擅长处理海量、高并发的事务,并且能够保证事务的原子性、一致性、隔离性和持久性(ACID特性)。想想每天全球有多少笔银行转账、支付、查询,大型机就是为了应对这种“洪峰”而生的。
安全性(Security): 大型机通常拥有强大的内置安全功能,从硬件层到操作系统层,都有多重防护机制,能够抵御各种网络攻击和内部威胁。在数据高度敏感的银行业,这一点尤为重要。
长期稳定性和投资保护: 尽管初始投入可能很高,但大型机的生命周期往往很长,并且许多银行已经对其投入了巨额的软件开发和系统集成费用。更换大型机会涉及巨大的迁移成本和风险。

然而,大型机也有其不可忽视的缺点:

高昂的成本: 购买、维护和运行大型机的成本非常高昂,包括硬件、软件许可证、专业技术人员的工资等。
灵活性较低: 大型机的硬件和软件架构相对封闭,扩展性虽然有,但不如分布式系统那样灵活和快速。开发新应用或集成新技术也可能面临挑战。
人才稀缺: 懂得如何操作和维护大型机的专业技术人才越来越少,这给银行带来了招聘和留用方面的压力。
传统技术栈: 很多大型机上运行的应用程序是几十年前开发的,技术栈比较老旧,与当前主流的互联网技术和云计算技术存在隔阂。

服务器集群:灵活强大的分布式力量

服务器集群(Server Cluster)是指将多台独立的服务器通过网络连接起来,作为一个整体协同工作的系统。这种架构在现代IT领域非常普遍,特别是在互联网公司和云计算服务中。

服务器集群的优势在于:

成本效益(CostEffectiveness): 相较于大型机,标准的商用服务器(Commodity Servers)通常更便宜,采购和维护成本更低。可以根据需求弹性地增加或减少服务器数量,实现成本的精细化管理。
高扩展性(Scalability): 服务器集群可以非常容易地水平扩展。需要处理更多任务?增加几台服务器就行。这种弹性是大型机难以比拟的。
灵活性和开放性(Flexibility and Openness): 服务器集群通常运行在开放的操作系统(如Linux)上,可以使用各种标准的软件和编程语言进行开发和集成。这使得银行能够更快地采用新技术,开发创新服务。
多样化的技术支持: 服务器集群的生态系统非常庞大,有大量的开源软件和商业解决方案可供选择,人才也相对更容易找到。
故障转移和高可用性(Failover and High Availability): 通过合理的集群设计,服务器集群也可以实现高可用性。当一台服务器发生故障时,其他服务器可以接管其工作,用户体验到的是服务不中断。

但是,服务器集群在银行核心业务场景下,也面临一些挑战:

复杂性管理: 管理成百上千台服务器组成的集群,其复杂性远超管理一台大型机。需要强大的自动化运维工具、监控系统和专业的团队来保证其稳定运行。
事务一致性: 在分布式环境中,保证海量数据的强一致性(Strong Consistency)比在单台大型机上要困难得多。需要专门的分布式事务管理技术,如两阶段提交(2PC)或Paxos、Raft等共识算法。
安全性挑战: 分布式系统拥有更多的节点和网络连接点,理论上存在更大的攻击面。需要更精细化的安全策略和防护措施。
集成和迁移风险: 将银行核心业务从大型机迁移到服务器集群,是一个极其复杂且风险巨大的工程。需要进行大量的系统改造、数据迁移和严格的测试,以确保数据不丢失、业务不中断、合规性不受影响。

银行的选择:并非简单替代,而是演进

那么,银行能否用服务器集群“替代”大型机呢?

在某些领域,答案是肯定的,并且银行正在这样做。 许多银行已经将非核心业务、数据分析、客户关系管理(CRM)、网上银行、移动支付等应用部署在服务器集群上,甚至迁移到云计算平台上。这些应用对实时性、稳定性的要求虽然也很高,但相对于核心交易系统,容错能力会更强一些。

然而,对于承载着最核心、最关键的交易处理和核心账务的大型机,直接、完全的“替代”则是一个极其谨慎的过程,往往是渐进式的。 银行并非一下子就把大型机抛弃,而是:

1. 引入服务器集群/分布式系统处理新业务和非核心业务: 就像前面提到的,将新的应用和服务部署在更具弹性和成本效益的分布式平台上。
2. 对大型机上的应用进行现代化改造(Modernization): 这可能包括将大型机上的部分功能用新的技术栈在分布式平台上重新实现(称为“解耦”或“拆分”),然后逐渐将流量从大型机迁移到新的系统。或者,对大型机上的应用程序进行优化,使其更能适应现代化的IT环境。
3. 混合架构(Hybrid Architecture): 很多银行采取的是一种混合架构,即大型机继续处理最核心、最可靠的业务,而服务器集群则处理其他业务。这种方式可以最大化利用现有投资,同时逐步引入新的技术。
4. 云原生(CloudNative)和微服务(Microservices)的演进: 很多银行正在将应用迁移到私有云、公有云或混合云,并采用微服务架构。这本质上也是一种基于服务器集群(虽然是云平台提供的虚拟化服务器集群)的演进。

关键考量点:

银行在做这个决策时,会非常谨慎,主要考虑以下几点:

风险评估: 任何涉及核心系统的改动,首先要考虑的就是风险,包括数据安全、业务连续性、合规性。
成本效益分析: 不仅仅是硬件成本,还要考虑软件、开发、测试、运维、人才等所有环节的总拥有成本(TCO)。
技术成熟度和生态系统: 分布式技术和云计算技术虽然发展迅速,但在某些极端场景下的成熟度、可靠性和安全性,仍需银行审慎评估。
人才储备和培养: 银行需要有足够的技术人才来支撑新的技术架构。
合规性和监管要求: 银行业受到严格的监管,任何技术变革都需要满足监管机构的要求。

总结来说, 服务器集群凭借其成本效益、灵活性和扩展性,已经在银行的非核心业务和新业务领域扮演着越来越重要的角色。银行也在积极探索如何将这些优势应用到更广泛的业务场景中。

但是,要说用服务器集群“完全替代”大型机,尤其是在承载银行命脉的核心交易系统方面,目前来看还不是一个一蹴而就的替代,更多的是一个演进和融合的过程。银行需要通过应用现代化、架构重构、分步迁移等策略,逐步将部分业务从大型机转移到更现代化的分布式平台,同时保留大型机在特定领域的独特价值,最终形成一个更具活力、更具成本效益,同时又能保证极高可靠性和安全性的IT架构。这个过程是漫长而复杂的,需要深厚的专业知识和审慎的规划。

网友意见

user avatar

要看具体业务需求,甚至是「相同的业务」也要看具体的需求是如何做取舍的。

传统银行,追求的是「不需要让客户爽但要保证不会让客户痛」,或者说是「不求有功但求无过」,过去的系统做在大型机上就不要改了,新做的系统也没必要冒险尝试新技术,什么能用就继续用吧。大客户都在自己手上,何必冒险?

金融科技创业,所谓的 fintech,取舍是反过来的,「必须要让客户觉得爽,即使有时候让用户觉得痛」。创业意味着从零客户做起,同样是不痛的话别人为什么要从传统银行切换过来?必须要让人爽到了才能抢到市场份额。因为没有历史包袱,想要怎么做就怎么做,自己摸着石头过河,服务器群集能用好就能上。

技术的取舍,最终不是因为技术要取舍,而是因为业务要取舍。就算做相同的业务,一家大国企和一个海外融资的创业公司,做出来的业务取舍显然不会一样。

user avatar

利益相关:现微众银行行员

简单回答

  1. 技术上完全可行,以微众银行为例:500万账户为一个单元模块DCN上限,支持两地六活;单个DCN完全由数百台x86服务器构成,内部就是一个完整的银行核心系统+关键业务系统+风控业务系统;服务软件采用基于自研消息总线的微服务架构;VM/K8S等虚拟化技术也在投产应用过程中
  2. 管理上是否可行应不同银行具体状况而定,银行IT风险偏好极低,如果是老银行历史包袱重,全部替换代价和风险过大,一般没人负的起决策失误责任的
user avatar

真正的一线人员来解答一下:能。下面详细说一下,由于除夕在保障大家发红包,并且单位电脑没有外网,只能用手机回答了,格式上可能不太好看。

替代这个事最好还是分成“部分替代”和“完全替代”两种。这两种替代方式,从策略、风险、收益等等都是完全不一样的。两种方式我都大概谈一谈。部分替代像是并行替代,目标是分流,尽力减小主机的使用率,减少采购节约成本。完全替代像是串行替代,最终目标是完全替代,中间过程存在新老系统共存的情况。

如果是部分替代,那还是比较简单且风险较小。可以将部分交易在x86集群的架构重新开发,然后新老系统之间使用在线的数据同步工具同步。

这样操作的优点在于:1.新老并行,前期不稳定时可以用回老系统,风险小。2.可以逐步替代,一点一点做,时间充足,还是风险小。3.可以逐步摸索新平台的特点,还是风险小。

缺点在于:1.存在上限,做到一定程度就做不下去了,最后还是要大块大块的替代。2.数据同步问题。3.上下游系统配合改造。

如果是完全替代,时间和人力上都要有很大投入。而且一个新系统要有十年左右的使用周期,那系统架构、业务架构等等也会一起优化,还涉及到业务部门,是一个全行性的工作。

优点在于:1.完全摆脱主机,成本下降巨大。2.业务和科技整体升级,不是补丁式的更新。3.领导升职、对外宣传。

缺点在于:1.动作大、风险大,发生事件影响客户体验,考验技术能力,考验公关能力。2.全行总动员,工程浩大,需紧密配合。3.业务需求挖掘,有没有自然而然的需求,还是为了改而改,没有业务升级需求但是不得不搭车升级。


下面说部分(并行)替代要解决的问题。

1.到底能分流多少,到底能省多少钱。相当多的交易是可以直接拆出来的,比如查询类的,比如逻辑上比较独立的部分或功能等等。但是因为数据同步存在延时,时间敏感型的交易是不能拆的。比如开卡后立刻查询并回显成功,就需要用原交易或加延时。实际上虽然查询交易占大多数(因为修改类交易往往前后也会串上查询交易),但考虑到时间敏感型、使用频率和开发成本,只会做常用的一些。而且查询交易往往逻辑简单,能节约的Mips(就是性能或者算力,IBM大机按每Mips多少钱算)并没有想象中高。

2.数据问题。如果新系统只涉及查询交易,那数据只有单向同步。如果新系统涉及修改,还可能涉及双向同步,会更复杂些。还有就是数据同步受io影响比较大,一些时段io使用较大时数据同步会受影响。当然也可以新系统直连老系统数据库,不过这里会有一些性能问题需要解决。

3.上下游系统改造。因为涉及时间敏感性梳理,以及交易路径的改变,上下游系统也有一定的工作量,并且增加一定的系统复杂度。说白了就是麻烦且花钱。

部分替代的方式可以一点一点的投产,能够在短时间内看到效果。所以几大行在前几年大多都做了这方面工作,多多少少分流了交易出去,节约了或多或少的成本。当然与此同时IBM的收入减少。


下面说完全(串行)替代要解决的问题。

1.个人觉得最重要的,到底有没有业务升级需求。最完美的情况自然是业务要升级、技术上有突破、政策和国际环境上有要求,大家一拍即合自然而然。最怕因为政策和环境变化,甚至单纯某个领导要升级或退休急需成果,就强行推动这个大工程。不过现实往往是复杂的,做不到最好也做不到最坏。

2.技术和平台的选择。分布式可以使用的技术和平台不止一家,一个系统要用10年以上,自然要好好选择。现实中存在各种各样的阻碍,全看各位领导以及食物链上游的部门们pk。

3.工作量问题,这个和我们息息相关。工作量翻倍不止,用的又是新东西,混沌期内谁也不了解情况,混乱是难以避免的。这种情况下,只能说996都是恩赐,007不至于,但是6-11-7也有可能。大领导再一催,倒霉的都是干活的。这个阶段会留下多少坑?能不能处理好工作量问题很重要。

4.风险问题。新系统的质量如何?在3的情况下,赶工、凑合,出来的东西好不好用?有没有新工艺新流程来降低风险?程序员们经常说,如果程序以一种奇怪的姿势运行了起来,就不要去动它。那一下子全都动了,全都换新的,风险肯定超大。

5.替代肯定也是逐步进行的,新旧系统自然也存在并行期。新旧系统的相互调用,数据传输等等也是需要思考的。


最后,其实替代这个事肯定是能做的,现在的技术已经完全满足银行的需要了。但为什么没做,或者说没做完呢?因为银行稳定大于天的特点,替代这个事是大家都不想做的。领导不愿意担责任,干活的不想出舒适区,没有替代的动力,所以这几年才开始这个工作。现在各家行都还在努力,相信再过几年就能看到很多成果了。

最后还是要说一句,IBM真的太黑了。太黑太黑太黑了……但也是真好用。哎…

类似的话题

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有