业务需求分析
在规划整体架构之前,我们首先需了解业务,然后据此明确架构目标及科技发展战略。互联网银行在建设之初,就与传统银行存在诸多不同之处(如下表所示)。
可见其在覆盖人群、服务模式、服务理念等均有较大差异,这也对后续架构产生影响。从业务角度来讲,微众银行也据此确立了"普惠金融为目标,个存小贷为特色,数据科技为抓手,同行合作为依托"的整体战略定位。作为与之辅助的科技发展战略,微众银行制定了"纯线上、轻人力、强系统"的科技发展战略。通过完全依托互联网作为客户服务渠道,由计算机系统提供的自动化服务替代传统的人工服务,规避线下渠道建设以及运营所带来的高昂成本,最终实现整体运营成本的大幅度降低、运营效率的明显提升。
架构建设目标
在明确了业务战略定位及科技发展目标后,对于架构有了明确的要求。这里既有来自传统银行模式下,对高可用、安全、规范性的要求;也有来自互联网模式下,对高性能、高弹性、低成本的要求。整体可以将其概括为“四高两低”,即高性能、高弹性、高可用、高规范、低成本、低风险。可概括为下图:
1.高性能
银行需具备处理亿级存量用户及每日千万级交易量的能力。对架构的要求,可分解为
2.高弹性
在弹性方面,传统银行的Scale Up方式,显然已经走到了尽头。新一代架构,势必需要依托于分布式架构设计理念,有针对性地解决扩展性的问题。在扩展维度上,可考虑横向和纵向两个方向。
3.高可用
金融业务对RPO、RTO的严格要求,自不必说,是需要满足国家监管要求。互联网银行,对这一点还有其特殊性。相较于传统银行,互联网银行更强调面向社会提供7X24小时不间断的银行服务,这与其服务群体、服务形式有关。
4.高规范
银行基础架构,是很庞大、繁杂的体系。这需要在架构规划之初,就秉承标准化理念,因此来应对复杂运营维护工作。通过整体的高规范性,也有利于构建自动化、智能化的运维体系。
5.低成本
很多传统银行在IT架构上的投入是巨大的,其严重依赖外部(甚至国外)厂商不仅丧失了技术自主性,甚至连基本的商务议价能力也不具备。那么在新一代银行架构中,应秉承高性价比原则,充分运用低端计算计算和开源技术,有效地降低架构建设和后续运营的相关成本投入。
6.低风险
风险问题,是银行业基础架构的重中之重,在规划指出就应遵循下列原则:
理论基础:模块化与耦合性
1.模块化理念
模块化是软件解决复杂问题所具备的手段,可降低软件的复杂性,减少开发工作量,从而降低开发成本,提高软件生产率。"分而治之"的结论,把复杂的问题分解为很多容易解决的小问题,原来的问题也就容易解决,这就是模块化的依据。当然,我们也要防止过度划分问题。当我们无限制划分软件,那么开发所需要的工作量会变得很小,但是其他因素开始起作用,整体成本不降反升。如下图所示,开发单个软件模块所需要的工作量(成本)的确随着模块的数量的增加而下降,给定同样的需求,更多的模块意味着每个模块的尺寸更小。然而,随着模块数量的增长,集成模块所需要的工作量(成本)也在增大。这些特征导致其总成本的工作曲线成下述特征。存在一个模块数量M,可以导致最小的开发成本。一般无法预测M的值,但应该在模块化设计时尽量保持在M的附近,避免过高或过低的模块性。
2.耦合性设计
通过上面的模块化设计,每个模块完成一个相对对立的子功能,并且与其他模块之间的关系很简单。模块的独立性是模块化、抽象、信息隐藏和局部化概念的直接结果,具有独立模块的软件容易开发、测试和维护。模块的独立性通过两项质量标准来衡量:耦合和内聚。其中耦合是指不同模块间相互依赖的紧密程度;内聚是指模块内部各元素彼此结合的紧密程度。这里我们不谈内聚,重点谈谈耦合问题。概念上来说耦合性是对一个软件结构内不同模块之间互连程度的度量。它取决于各个模块之间接口的复杂程度、进入或访问一个模块的点以及哪些信息通过接口传递。
微众架构设计思想演讲
1.集中式紧耦合
集中式紧耦合,是指由一台或多台主计算机组成中心节点,将数据集中存储于这个中心节点中,并且整个系统的所有业务单元都集中部署在这个中心节点上,系统的所有功能均由其集中处理。这是一种典型的业务集中、计算集中、数据集中的策略。
优点
缺点
2.集中式紧耦合
从上面紧耦合拆分,将全量业务拆分成多个业务,由不同的计算节点分别处理,但每个计算节点处理的仍然是全量客户。集中式松耦合架构在一定程度上降低了集中式紧耦合架构的风险集中度,但是在整体可用性、性能和成本上,依然存在较明显的缺陷。
优点
缺点
业务之间的高度关联仍可能导致全局故障。
3.分布式松耦合
在集中式松耦合架构的基础上,横向切分集中式松耦合架构的部署方式,在每个节点上以客户为单位,部署用于支撑该客户群的全部应用系统。每个应用系统在保持集中式松耦合架构的特性的同时,在每个客户服务节点中有独立的物理资源。在以客户为单位的分布式松耦合架构下,每个节点成为一个自包含的客户服务节点。其中,一个客户的全生命周期数据集中的一个节点上;涉及单一客户的交易处理在单一节点上完成,节点间无依赖关系。
优点
缺点
节点数量增加,增加管理难度。
4.局部架构:主从架构
在上述模式的局部处理单元,为了提升单元的数据可用性,可采取多种数据冗余方式。最初是采用多主设计,这是一种较为“完美”的方式,但面临CAP理论在实现上的挑战。为了简化设计,后面采用单主设计,维护多个从节点,保证每份数据拥有多个副本从而实现架构整体可用性。在保证高可用的前提下,牺牲单节点的处理性能,但这样的设计模型可以规避CAP理论对整体架构的限制。对于任何一份数据,在保证存储三个副本的前提下,仅由一个主节点对外提供读写服务;所有从节点与主节点之间依托现有网络技术,通过强化后的数据库同步机制实现与主节点间的数据同步,并对外提供只读服务。单主节点确保了在任何一个时间点对外提供数据的唯一性,强同步的多个从副本则确保了数据的高可用性。
优点
缺点
5.终极形态:分布式松耦合一主多从多副本强一致
在分布式松耦合一主多从多副本强一致的架构下,每个节点承载一个独立客户群体。节点之间的客户群上不重叠,一个客户的整个生命周期只会在一个节点上进行处理和存储。节点之间不共享物理资源,从而实现最大程度的独立性。每个节点服务全行客户中的一个客户子集,具备服务所承载客户群所需的全部技术支撑能力,能够存储该客户群所有客户的全部数据。所部署的应用系统,在应用层面采用松耦合部署,不同应用域的应用系统不共享物理资源;在数据层面,采用一主两从强同步架构实现数据的高可用性,同时还能规避CAP理论对分布式架构的限制。新一代架构中分布式的核心理念为去中心化,去除任何可能影响所有业务的所有客户的任何类型节点的存在。即使出现了整个节点不可用,也不会影响整个银行的客户。
优点
缺点
微众架构的关键技术
1.分布式数据库
2.分布式缓存
分布式缓存是一种基于内存/高性能SSD介质的数据存储服务,是分布式系统中的重要组件,主要解决高并发、大数据场景下,热点数据访问的性能问题,提供高性能的数据快速访问能力,减轻关系型数据库的压力。
3.分布式存储
提供分布式的块、文件、对象存储能力。做到灵活扩展、高性能、数据可靠的同时,尽量实现低成本。
4.分布式MQ
提供分布式的消息队列服务,其需保证消息数据的可靠,整体服务高可用,同时具备容量、性能的扩展能力,并可应对跨数据中心的出散户需求。
5.分布式LB
提供多形式、多层面的分布式负载均衡服务。
写在最后:如何实现技术转型