作为聊聊架构群里的新人,今天很荣幸在这里和大家分享一些自己的心得体会。做过码农,带过项目,倒腾过产品,现在在看银行基础架构上的一些事情。资历浅薄,只能从自己熟悉的领域跟大家做一些分享,就算是抛砖引玉,给大家一个靶子来讨论。 我自06年开始做兼职,就一直在金融行业,更准确地说,一直在银行业。这样的经历是幸运的,也是比较悲催的。悲催的是,基本上只懂银行,而且银行IT的压力比较大。幸运的是,银行在信息化建设中是前沿行业,同时要求高,所以也呆过很多不错团队,见到过很多比较好的东西。 今天的分享主要是基于我最近的工作,基于自主可控技术的新一代银行架构,来看银行这个领域的一些架构特点。 首先,为什么把基于自主可控技术的架构称为新一代架构?这里说的新一代本身并不是指采用了像“量子计算”这样的前沿技术的架构。这里的“新一代”是相对于当前银行业的主流的“IOE”架构而 言的。“IOE”指代的是由以IBM、ORACLE和EMC(被收购之前)为代表的商业解决方案。这些解决方案对于银行来说,是一个黑盒子,无法自主掌 握。一切的开发、运维均需要服务商的支持与协助。而新一代的基于自主可控技术的银行架构,则更多的选择开放性的技术平台以及开源的技术产品,例如 XML:X86框架的PC服务器、MySQL为代表的开源数据库和LINUX为代表的开源操作系统。是的,没什么了不起的技术,但是从来没有哪个银行把一 家银行的架构完完全全地交给XML来构建。 既然从来没有发生过,那么为什么突然想要去做呢?三大外因驱动新一代银行架构的诞生。
因此,寻求基于自主可控技术的架构,几乎是新一代架构的必然选择。
在业务形态上,互联网银行往往有以下一些特点:“纯线上、轻人力、强系统”。因此,互联网作为这些机构唯一的客户触点, 完全打破了所有已知的银行运营模式。一个看似简单的远景:“任何人在任何地点、任何时间、任何场景下,通过多种手段均可使用银行服务”,同时这也令新一代 架构站在了海量挑战的风口浪尖:源源不断的来自各个不同阶层、不同背景的海量客户,随之而来的海量交易以及需要处理于存储的海量数据。而这一切,成为了新 一代银行架构从第一天起就不断研究、解算的命题。
这道命题的答题思路被总结成了8个字“融合创新、平衡互补”。融合什么?融合互联网和银行。互补什么?以银行IT的诉求和互联网技术之间形成互补。简单来说,新一代需要在做到互联网行业所擅长的“高性能、高弹性和低成本”的同时,保持传统金融行业对于“高可用、高标准和低风险”的追求。
之前看到一篇文章,忘记作者是哪位大咖(诚惶诚恐。。。),其中有一段话记忆尤为深刻。在“如何称为一个合格的架构师”这个章节下,大咖提出了四门必修课,其中一门是“能和稀泥”。这“和稀泥”其实是指一个妥协的过程。而我个人的理解是:架构没有最好的,最正确的,只有最合适的。按最合适的方式,在最合适的时间点,以最合适的成本获得一个可能获得的最好的结果。这个就是架构师要做的。 为什么说这些呢?因为大家肯定已经看到了,要融合银行和互联网,难度不亚于要让油溶于水。那么,这里面很重要的一点就是如何在不同的场景下,对架构设计进行取舍。 诚然,很多时候的讨论都是case by case并且激烈的。但是,一个核心价值逐渐成为主导性因素:业务连续性。首先,它是监管机构悬在所有金融机构头顶的利剑。其次,它是一个金融机构的信誉所在。业务连续性的两个主要考核指标:RPO和RTO,一个决定了金融业务的安全性,一个决定了业务的可用性。老百姓不会相信一个动不动丢数据或者动不动因为市政工程就停业务的金融机构。然而,单点的可用性和稳定性往往是XML(重要事情再说一遍:XML指代新一代自主可控技术的主要代表:X86服务器、MySQL数据库和LINUX操作系统)的短板。 因此,我们围绕着构成整个架构的4个关键底层资源, 做了很多工作来保证业务连续性。在必要的时候,我们会舍弃单点的性能和灵活性,来保证业务连续性。例如,在数据库网关上进行QPS的限制,将数据库的负载 在一个合理的范围,确保分布式数据库中存储相同数据的多个副本的多个节点间的数据同步的强一致性。那么性能怎么办呢?一个节点被限制了,那么通过逻辑将数 据进行分布,用更多的节点来承载业务,聚沙成塔。
如何聚沙成塔?如何在金融行业构建一个全分布式架构?一种实践解决方案是以客户为单位进行数据分布。以我熟悉的银行业为例,具体来看:将银行的所有服务功能分成了两大类:对客户服务和后台管理服务。所有对客服务的能力,按照分布式架构设计理念,构建了多个服务相同类型客户的数据中心节点,DCN。每个DCN承载一个独立的客户群体,拥有服务这个客群的所有能力以及属于这个客群的每个客户的所有数据。 而熟悉银行业务的老师们可能会指出,很多银行的关键数据是要以整个银行作为整体来 看的,例如:会计科目的余额、授信额度和理财产品销售额度等。确实如此,针对处理此类数据的后台管理服务,可以采用集中部署的方式,实现对全行的数据处理 的支撑。分布式架构不适合这样的业务处理场景。因此,这部分系统可以采用集中部署,通过其他的分布式技术、可无限扩展的计算集群以及可按功能拆分的应用架 构,最终实现对这个节点的加固。
前 面讲的是自主可控架构的一种逻辑实现。在技术组建的规划和选择上,也有一些特殊的考虑。在我自己的实践过程中,不知不觉地实践了MVP(minimum viable product)和极简主义。之所以说不知不觉,是因为在一开始的时候,我们并没有明确地提出这两个观点作为架构基本法。极简主义的一些理念在讨论中浮现 过,而MVP则并没有被提及。但是,最后,我们发现,即使是底层架构这种相对较硬,灵活性较差的事物,依然可以通过MVP这种强调快速迭代的方式来规划建 设。期间有很多挫折,也走了很多弯路。 但恰恰是MVP这种理念,使得我们最终能以较小的代价摸索出一条并无太多可借鉴的架构建设道路。至于极简主义,则是刻意的让每个组件只做一件事情,避免使用一个过于复杂,功能过于强大的“平台”。这个架构不能有明显的“死穴”。其实想想,这个做法更像《失控》里面描述的“Subsumption Architecture”。
这种实践其实最终和MVP理念浑然一体。
讲了这么多,附上一张对比图,对比的是传统IOE架构和新一代的XML架构。图上的内容很多,这里就不冗余述。
问题:全文围绕可控做了精彩论述,但去IOE成本着实不小,如何衡量value?
问题:想问一下,xml中,对核心账务部分怎么处理的?
问题:每个DCN承载着独立的客户群,这个客户群是按什么划分的?
问题:那张“以客户为单位的全分布式架构总览”图中,客户端节点1到N之间的“数据备份”是通过什么技术实现的?备份的频率?
问题:想问下有没有遇到架构扩展性不太好的事情,后面怎么解决?
问题:架构合适就好,但是可扩展这个怎么把控呢?
问题:之前的IOE时,项目进度是如何管理,代码行?功能点?还是其他呢?在新的公司,这方面又是如何管理呢?有什么相同与不同呢?
问题:数据中心节点是按照客户划分的,但一般金融机构都有自己的业务管理机构,客户分属不同的机构,这样如果按照业务管理机构去做一些事情,就存在跨节点的操作了。不知道微众银行存不存在这方面的问题。
问题:DCN客户如果是随机划分,怎么做的数据路由(根据用户什么值做的路由),算法是一致性哈希么?是否用过分库的中间件产品?银行业务在oralce中有大量的过程,在转到mysql都进行了剔除了么?
问题:如果采用XML架构,这里所说的“每个DCN是随机分布的”,是采取什么技术方式实现随机分布的呢?
问题:去IOE是个困难的过程,但是在去IOE的过度时期怎么把握新架构系统和老系统的共存?
原文:http://www.oschina.net/news/71490/future-bank-opensource 转载请保留固定链接: https://linuxeye.com/news/2880.html |